Hi Phil, On Do, 2022-06-30 at 13:43 +0000, Phil Edworthy wrote: > 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. We also have to make sure that no read-modify-write cycles are required to deassert the resets if we can't lock between firmware and kernel. Otherwise concurrent access could cause a deassert to be reverted. > 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. Which reset driver is handling the reset for this i2c module? > > 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. There are resets that are not initially asserted (among them the self- deasserting resets) that are required to be asserted some time during boot, to put some hardware into a well defined state. I don't think those should be shared, but they sometimes are. > 2. A driver may need to reset the module for some reason. I have only > seen this with watchdog timers with no way out. Grep for device_reset() or reset_control_reset() for some examples. Also there are quite a few assert/udelay/deassert calls in drivers. Also many drivers assert the reset again during remove(). Whether that is always necessary or useful, I can't say. It's sometimes nice during development, to be able to reload a kernel module or rebind a driver to reset some locked up hardware. > So if a driver does not need to reset the module, shouldn't the driver > only ever be de-asserting the reset line? I'm not sure the driver can always know this if it is used on different platforms. > 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. It can be shared for the special case of multiple modules requiring a shared reset line to be asserted once, at some time before the modules are used. The reset controller API supports this for the reset_control_reset() call. regards Philipp
