On Mon, Sep 27, 2021 at 02:30:56PM +0100, Mark Brown wrote:
> On Mon, Sep 27, 2021 at 02:24:17PM +0100, Daniel Thompson wrote:
>
> > In that case what is the point of including unconsumed driver data? Most
> > DT centric drivers that included this for modalias reasons leave it
> > NULL.
>
> It's
On Mon, Sep 27, 2021 at 02:24:17PM +0100, Daniel Thompson wrote:
> In that case what is the point of including unconsumed driver data? Most
> DT centric drivers that included this for modalias reasons leave it
> NULL.
It's mainly there because it's generated fairly mechanically from the OF
ID tab
On Mon, Sep 27, 2021 at 12:47:27PM +0100, Mark Brown wrote:
> On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote:
>
> > Based on this I had expected to find spi_get_device_id() and a ->driver_data
> > somewhere in this patch.
>
> > Where will this .driver_data be consumed?
>
> It w
On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote:
> Based on this I had expected to find spi_get_device_id() and a ->driver_data
> somewhere in this patch.
> Where will this .driver_data be consumed?
It will never be consumed unless someone writes a board file - the
runtime match
On Wed, Sep 22, 2021 at 04:10:14PM +0100, Mark Brown wrote:
> Currently autoloading for SPI devices does not use the DT ID table, it uses
> SPI modalises. Supporting OF modalises is going to be difficult if not
> impractical, an attempt was made but has been reverted, so ensure that
> module autolo
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.
Fixes:
