[PATCH v12 0/6] Driver for at91 usart in spi mode
alexandre.belloni at bootlin.com
Wed Sep 12 05:14:20 PDT 2018
On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > But ... we can't have it both ways. *Either* it's a true MFD, in
> > > which case it can/should have 2 separate compatible strings which can
> > > be specified directly from the DT. *Or* it's not an MFD. In the
> > > latter case, which I think we're all agreeing on (else we'd have 2
> > > compatible strings), MFD is not the place to handle this (my original
> > > point).
> > >
> > If that is what bothers you, then let's move it out of mfd.
> As I've already mentioned. I don't just want it moved out of MFD and
> shoved somewhere else. My aim is to fix this properly.
If it is out of MFD, then I'm not sure why you would care too much about
it as you won't be maintaining that code. And I still this what was done
was correct but I'm open to test what you suggest.
> > > So ... this is a USART device which can do SPI, right?
> > >
> > > My current thinking is that; as this is a USART device first &
> > > foremost, the USART should be probed in the first instance regardless,
> > > then if SPI mode is specified it (the USART driver) registers the SPI
> > > platform driver (as MFD does currently) and exits gracefully, allowing
> > > the SPI driver to take over.
> > >
> > > Spanner in the works: is it physically possible to change the mode at
> > > run-time? :s
> > Yes it is possible but on Linux that will not happen without probing
> > the drivers again.
> Not sure I understand what you mean.
I was just commenting on changing the mode at runtime.
> I'm suggesting that you use the same platform_* interfaces MFD uses to
> register the SPI driver if SPI mode has been selected. Only do so
> from the appropriate driver i.e. USART.
Yeah, I understood that but I didn't comment because I'm not sure this
will work yet.
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
More information about the linux-arm-kernel