RE: [PATCH v2 0/2] i2c: Add new driver for Renesas RZ/V2M controller

From: Phil Edworthy <phil.edworthy@renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Wolfram Sang <wsa@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Sam Protsenko <semen.protsenko@linaro.org>,
	Sven Peter <sven@svenpeter.dev>, Jan Dabros <jsd@semihalf.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Tyrone Ting <kfting@nuvoton.com>, Arnd Bergmann <arnd@arndb.de>,
	Olof Johansson <olof@lixom.net>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux I2C <linux-i2c@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH v2 0/2] i2c: Add new driver for Renesas RZ/V2M controller
Date: Thu, 30 Jun 2022 13:43:19 +0000	[thread overview]
Message-ID: <TYYPR01MB7086706381CDCEF4F582690CF5BA9@TYYPR01MB7086.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdXV72_BWOpU=O13Fa3-t001YSRdsFePSHBS=Xvh1jY1EQ@mail.gmail.com>

Hi Philipp, Geert,

On 29 June 2022 18:18 Geert Uytterhoeven wrote:
> On Wed, Jun 29, 2022 at 6:21 PM Philipp Zabel wrote:
> > On Di, 2022-06-28 at 20:45 +0100, Phil Edworthy wrote:
> > > The Renesas RZ/V2M SoC (r9a09g011) has a new i2c controller. This
> series
> > > add the driver. One annoying problem is that the SoC uses a single
> reset
> > > line for two i2c controllers, and unfortunately one of the controllers
> > > is managed by some firmware, not by Linux. Therefore, the driver just
> > > deasserts the reset.
> >
> > This sounds scary. If the driver is never loaded, and the reset is
> > never deasserted, what happens to the firmware trying to access the
> > other i2c controller? Does it hang? Or write to the reset controller
> > registers to deassert the reset? If so, is there any protection against
> > concurrent access from firmware and reset controller driver?
Where a common reset is used by Linux and some firmware, I think we have to
ensure/assume that both only ever de-assert it.
In this particular SoC, the register used to assert/de-assert the reset
has write enable bits in the upper half of the reg. There shouldn't be any
issues with both trying to de-assert the reset at the same time.

> In response to v1, I wrote
> 
> | That is actually an integration issue, not an i2c controller issue.
> |
> | Perhaps we need a RESET_IS_CRITICAL flag, cfr. CLK_IS_CRITICAL,
> | to be set by the reset provider?

From what I understand, there are two main use cases for resets:
1. Often reset lines may be asserted at power on and so a driver needs to
   de-assert them so that the module can be used.
2. A driver may need to reset the module for some reason. I have only
   seen this with watchdog timers with no way out.

So if a driver does not need to reset the module, shouldn't the driver
only ever be de-asserting the reset line?
If so, it also doesn’t matter whether the reset is shared with other
modules or not.
If a driver needs to reset the module, then the reset cannot be shared
with other modules used by firmware or Linux, or we cannot use any
other modules that share the reset line.

Have I missed something?

Thanks
Phil