Re: [PATCH v3 2/3] iio: adc: hx711: refactor to per-chip hx711_chip_info structure

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 22 Apr 2026 23:29:09 +0530
Piyush Patle <piyushpatle228@gmail.com> wrote:

> Introduce hx711_chip_info to hold per-variant static configuration:
> device name, IIO channel spec, channel count, and iio_info pointer.
> Store a chip_info pointer in hx711_data and populate indio_dev fields
> from it at probe instead of hardcoding them.
> 
> Pass trailing pulse count directly to hx711_read() instead of
> computing it inside the function, and change hx711_reset_read() to
> take a const struct iio_chan_spec * instead of an integer channel
> index so callers can pass the full channel descriptor.
> 
> Use device_get_match_data() to look up the chip_info from the
> of_device_id table. No functional change for existing HX711 users.
> 
> Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Couple of things sashiko raised on this...

One about hx711_gain_to_scale() is an existing driver bug.
Need to take a per instance copy of that so as to support
more than one sensor.  Ideally fix that whilst you are touching the
driver (as a precursor patch - maybe we'll backport it) but if you
want to leave it for another day then just say that in the cover letter.

The other one about matching via non DT routes is an interesting corner
that i suspect applies to other drivers.  The module alias in this
driver is also rather odd.


>  
> @@ -571,7 +602,6 @@ static struct platform_driver hx711_driver = {
>  module_platform_driver(hx711_driver);
>  
>  MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
> -MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> +MODULE_DESCRIPTION("HX711 and compatible bitbanging ADC driver");
>  MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:hx711-gpio");
So Sashiko thinks (and it's plausible) that this module alias is a problem
as if the driver match is against it might be possible to probe the
driver without the match data getting set.  I think it's referring to
the final driver match fallback path
https://elixir.bootlin.com/linux/v7.0/source/drivers/base/platform.c#L1370

Whilst unlikely anyone would get to this, I guess the fix is to ensure
we get a match by having a platform_device_id table for legacy matching
and making sure that covers such a match and provides data.

We don't (I think) currently have an equivalent of the catch all matching
functions that exist for i2c and spi.
Bit ugly for platform data as I think you need to get it via
platform_get_device_id()

Maybe we just check if device_get_match_data() returns NULL and fail instead.

> -