mbox series

[0/5,v3] iio: Silence no spi_device_id warnings

Message ID 20220921163620.805879-1-weiyongjun@huaweicloud.com (mailing list archive)
Headers show
Series iio: Silence no spi_device_id warnings | expand

Message

Wei Yongjun Sept. 21, 2022, 4:36 p.m. UTC
From: Wei Yongjun <weiyongjun1@huawei.com>

SPI devices use the spi_device_id for module autoloading even on
systems using device tree.

Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT
compatible") added a test to check that every SPI driver has a
spi_device_id for each DT compatiable string defined by driver
and warns if the spi_device_id is missing.

This series add spi_device_id entries to silence the warnings, and
ensure driver module autoloading works.

v2 -> v3:
 - post as patch series
 - make use of the spi_get_device_id(spi)->driver_data
   path to provide the chip info structure if
   of_device_get_match_data() returns NULL.

Wei Yongjun (5):
  iio: adc: ti-ads131e08: Silence no spi_device_id warnings
  iio: accel: sca3300: Silence no spi_device_id warning
  iio: adc: ad9467: Silence no spi_device_id warnings
  iio: adc: ad7192: Silence no spi_device_id warnings
  iio: adc: ad7124: Silence no spi_device_id warnings

 drivers/iio/accel/sca3300.c    | 12 ++++++++++--
 drivers/iio/adc/ad7124.c       | 10 ++++++++++
 drivers/iio/adc/ad7192.c       | 12 ++++++++++++
 drivers/iio/adc/ad9467.c       | 11 +++++++++++
 drivers/iio/adc/ti-ads131e08.c | 11 +++++++++++
 5 files changed, 54 insertions(+), 2 deletions(-)

Comments

Andy Shevchenko Sept. 21, 2022, 8:41 p.m. UTC | #1
On Wed, Sep 21, 2022 at 7:19 PM Wei Yongjun <weiyongjun@huaweicloud.com> wrote:
>
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> SPI devices use the spi_device_id for module autoloading even on
> systems using device tree.
>
> Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT
> compatible") added a test to check that every SPI driver has a
> spi_device_id for each DT compatiable string defined by driver
> and warns if the spi_device_id is missing.
>
> This series add spi_device_id entries to silence the warnings, and
> ensure driver module autoloading works.

Nice, but I would like to avoid the unneeded churn in the future and
right away use a new API for that. I will submit a patch soon that you
may attach to your series as a prerequisite.
Jonathan Cameron Oct. 2, 2022, 2:03 p.m. UTC | #2
On Wed, 21 Sep 2022 23:41:54 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Wed, Sep 21, 2022 at 7:19 PM Wei Yongjun <weiyongjun@huaweicloud.com> wrote:
> >
> > From: Wei Yongjun <weiyongjun1@huawei.com>
> >
> > SPI devices use the spi_device_id for module autoloading even on
> > systems using device tree.
> >
> > Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT
> > compatible") added a test to check that every SPI driver has a
> > spi_device_id for each DT compatiable string defined by driver
> > and warns if the spi_device_id is missing.
> >
> > This series add spi_device_id entries to silence the warnings, and
> > ensure driver module autoloading works.  
> 
> Nice, but I would like to avoid the unneeded churn in the future and
> right away use a new API for that. I will submit a patch soon that you
> may attach to your series as a prerequisite.
> 

Given Andy's suggestion (which I like, but no one else has replied to!)
isn't moving forwards particularly quickly.... I've applied this series
as it stands.  We will just have to cope with the churn (there will be
a lot beyond these few drivers anyway to fully take advantage of
the utility function Andy has suggested)

Applied to the togreg branch of iio.git as 6.2 material. I'll push out
as testing for now for 0-day to see if it can find any problems. Will be
rebasing that tree on rc1.

Jonathan
Andy Shevchenko Oct. 3, 2022, 7:29 a.m. UTC | #3
On Sun, Oct 2, 2022 at 5:03 PM Jonathan Cameron <jic23@kernel.org> wrote:
> On Wed, 21 Sep 2022 23:41:54 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

...

> Given Andy's suggestion (which I like, but no one else has replied to!)
> isn't moving forwards particularly quickly.... I've applied this series
> as it stands.  We will just have to cope with the churn (there will be
> a lot beyond these few drivers anyway to fully take advantage of
> the utility function Andy has suggested)

dev_fwnode() now takes a const pointer, so the needed API can be
submitted after -rc1, for v6.2 as well, but then conversion can happen
later on.