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

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

 




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/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux