Re: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux