Re: [PATCH v2 1/2] watchdog: Add watchdog driver for Sunplus SP7021

[Guenter Roeck]

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