Re: [PATCH RFC 1/3] spi: Allow SPI controller override device buswidth

[John Garry]

Hi Geert,

> On Fri, Feb 28, 2020 at 4:23 PM John Garry <john.garry@xxxxxxxxxx> wrote:
> > Currently ACPI firmware description for a SPI device does not have any
> > method to describe the data buswidth on the board.
> >
> > So even through the controller and device may support higher modes than
> > standard SPI, it cannot be assumed that the board does - as such, that
> > device is limited to standard SPI in such a circumstance.
> >
> > As a workaround, allow the controller driver supply buswidth override bits,
> > which are used inform the core code that the controller driver knows the
> > buswidth supported on that board for that device.
>
> Just wondering: can't the controller just override this (e.g. in the .setuup()
> callback) without having to touch the generic code?

I think that this is a good idea.

However, where we call .setup() in spi_setup() looks a little too late - 
at the point we call .setup(), most of the work on vetting/fixing the 
mode bits is complete. And I would not want the SPI controller driver 
just to disregard this work and overwrite the bits (in this way).

And if we wanted to move the .setup callback earlier, then I would be 
worried here with 2 things:
1. Some SPI controller drivers may rely on spi->mode being set finally 
when .setup() is called
2. We may need to undo the work of .setup() if we later error in 
spi_setup(), like for invalid mode bits

However, maybe another callback could be introduced, .early_setup().

Thanks,
John