On 11/28/21 11:57 PM, xt.hu[胡先韬] wrote:
-----Original Message-----
From: Guenter Roeck [mailto:groeck7@xxxxxxxxx] On Behalf Of Guenter Roeck
Sent: Thursday, November 25, 2021 12:26 PM
To: xt.hu[胡先韬] <xt.hu@xxxxxxxxxxx>
Cc: wim@xxxxxxxxxxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
linux-watchdog@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; Wells Lu 呂芳騰
<wells.lu@xxxxxxxxxxx>; qinjian[覃健] <qinjian@xxxxxxxxxxx>
Subject: Re: [PATCH v2 1/2] watchdog: Add watchdog driver for Sunplus SP7021
On 11/24/21 6:42 PM, xt.hu[胡先韬] wrote:
Hi
Thanks for your review. I explain this in detail below the comment.
Best Regards,
Xiantao
-----Original Message-----
From: Guenter Roeck [mailto:groeck7@xxxxxxxxx] On Behalf Of Guenter Roeck
Sent: Wednesday, November 24, 2021 10:25 PM
To: xt.hu[胡先韬] <xt.hu@xxxxxxxxxxx>
Cc: wim@xxxxxxxxxxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
linux-watchdog@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; Wells Lu 呂芳
騰
<wells.lu@xxxxxxxxxxx>; qinjian[覃健] <qinjian@xxxxxxxxxxx>
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:
Sunplus SP7021 requires watchdog timer support.
Add watchdog driver to enable this.
Signed-off-by: Xiantao Hu <xt.hu@xxxxxxxxxxx>
---
+
+ 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 functions
to
ensure that accesses are synchronized.
The register used by this driver consists of two parts. The first part which contains WDT_CTRL and
WDT_CNT
registers is exclusive by watchdog.
In specially, the second part is belong to a multifunctional register group which control IP and bus.
Refer to
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 system
reset(default)
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 system
reset(default)
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 trigger
system
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 is
removed.
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
