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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
