Re: [PATCH v2 1/2] watchdog: Add watchdog driver for Sunplus SP7021
From: Guenter Roeck <linux@roeck-us.net>
Date: 2021-12-03 21:39:39
Also in:
linux-watchdog, lkml
On 11/28/21 11:57 PM, xt.hu[胡先韬] wrote:
quoted
-----Original Message----- From: Guenter Roeck [mailto:groeck7@gmail.com] On Behalf Of Guenter Roeck Sent: Thursday, November 25, 2021 12:26 PM To: xt.hu[胡先韬] <xt.hu@cqplus1.com> Cc: wim@linux-watchdog.org; p.zabel@pengutronix.de; linux-kernel@vger.kernel.org; linux-watchdog@vger.kernel.org; robh+dt@kernel.org; devicetree@vger.kernel.org; Wells Lu 呂芳騰 [off-list ref]; qinjian[覃健] [off-list ref] Subject: Re: [PATCH v2 1/2] watchdog: Add watchdog driver for Sunplus SP7021 On 11/24/21 6:42 PM, xt.hu[胡先韬] wrote:quoted
Hi Thanks for your review. I explain this in detail below the comment. Best Regards, Xiantaoquoted
-----Original Message----- From: Guenter Roeck [mailto:groeck7@gmail.com] On Behalf Of Guenter Roeck Sent: Wednesday, November 24, 2021 10:25 PM To: xt.hu[胡先韬] <xt.hu@cqplus1.com> Cc: wim@linux-watchdog.org; p.zabel@pengutronix.de; linux-kernel@vger.kernel.org; linux-watchdog@vger.kernel.org; robh+dt@kernel.org; devicetree@vger.kernel.org; Wells Lu 呂芳騰quoted
quoted
[off-list ref]; qinjian[覃健] [off-list ref] Subject: Re: [PATCH v2 1/2] watchdog: Add watchdog driver for Sunplus SP7021 On Wed, Nov 24, 2021 at 06:41:48PM +0800, Xiantao Hu wrote:quoted
Sunplus SP7021 requires watchdog timer support. Add watchdog driver to enable this. Signed-off-by: Xiantao Hu <xt.hu@cqplus1.com> --- + + priv->base = devm_platform_ioremap_resource(pdev, 0); + if (IS_ERR(priv->base)) + return PTR_ERR(priv->base); + + /* The registers accessed here shared by multiple drivers. */ + wdt_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);This is unusual. Why would other drivers access WDT_CTRL and WDT_CNT registers, and how is it ensured that the other drivers do not interfer with the accesses by this driver ? Normally such a resource would be shared through a parent driver with appropriate access functionstoquoted
quoted
ensure that accesses are synchronized.The register used by this driver consists of two parts. The first part which contains WDT_CTRL andWDT_CNTquoted
registers is exclusive by watchdog. In specially, the second part is belong to a multifunctional register group which control IP and bus.Refer toquoted
register manual below: ------------------------------------------------------------------------------------------------------------------------------------------------- MO1_STC_WDG_RST_EN 4 RW STC Watchdog Timeout Trigger System Reset Enable 0: STC watchdog 2 timeout will not trigger systemreset(default)quoted
1: STC watchdog 2 timeout will trigger system reset MO1_RI_WDG_RST_EN 1 RW RBUS Watchdog Timeout Trigger System Reset Enable 0: RBUS watchdog timeout will not trigger systemreset(default)quoted
1: RBUS watchdog timeout will trigger system reset MO1_TIMER_STAND_BY_EN 0 RW Timer Standby Mode Enable 0: Disable (default) 1: Enable Active high to enter timer standby mode, default not in standby mode ------------------------------------------------------------------------------------------------------------------------------------------------- You can see that in addition to the bits for watchdog there are bit fields for other modules. I use this register bit4 and bit1. Default value is 0 that watchdog internal interrupt signal can't triggersystemquoted
and RBUS reset. I need set 1 when watchdog probe. Early I implement the operation in arch/arm/mach-sunplus/sp7021.c and configure by macro. But in arch/arm64, directory mach-XXX isremoved.quoted
So I solve in this way. Any better way?If the register at 0x9C000274 is accessed by other drivers, accesses to it must be protected against each other to avoid race conditions. How to do that would be up to you.Hi Guenter, From the perspective of software, 0x9C000274 is only accessed during driver probe. If the driver is build-in and only one core is running at kernel startup. There is no competition. The only possibility of an error is to compile the driver into a module. In this case, the register at 0x9C000274 offer MASK_BITS[31:16] which write valid bit for each LSB 16 bits. Refer to the define in driver: #define MASK_SET(mask) ((mask) | (mask << 16)) Even if both drivers access the register at the same time, the instructions are executed in order on the RBUS. So as long as the same bit in the same register is not accessed at the same time, no error will occur.
This is inherently risky and racy. I am sure there is a better way to solve this without risking race conditions, but I don't have time to analyze it further. The above rationale needs to be added in detail to the driver as comments, including references to all other drivers accessing the same register or memory space. Guenter