> > Doesn't make this writing device drivers a bit harder, I wonder? If we > > follow the above, we need to know per driver (like i2c-rcar.c) if > > reset_control_reset() is enough or if we need to call > > reset_control_status() additionally. For a driver author, it would be > > much less error prone IMHO, if reset_control_reset() just does the right > > thing. It has also the advantage that we can handle special handling on > > different SoCs differently (if that is ever needed) because MSSR driver > > is per SoC. > > True. > > But this seems to be a bug in the R-Car Gen3 I2C controller implementation. I see. If this is more of "a bug in the IP core", then I can live with having the workaround in the I2C driver. With a comment explaining the situation, of course. If it was more like "intended" special handling needed for different IP cores (not only I2C), then we should maybe reconsider. > > > Note that reset controller support is optional, so we want to add > > > > > > select RESET_CONTROLLER if ARCH_RENESAS && ARM64 > > > > > > to the I2C_RCAR section drivers/i2c/busses/Kconfig. Else reset will fail > > > silently. > > > > Technically, it should also be "&& HAS_DMA". But this is maybe a tad too > > defensive? > > s/HAS_DMA/RCAR_DMAC/ :-) Yes, this is better. Thanks!
Attachment:
signature.asc
Description: PGP signature
