Re: [PATCH v7 11/11] iio: adc: hx711: add support for HX710B

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 11 May 2026 14:27:16 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, May 11, 2026 at 01:56:55AM +0530, Piyush Patle wrote:
> > Add support for the AVIA HX710B ADC, which shares the HX711 GPIO
> > interface but uses trailing PD_SCK pulses to select the active mode.
> > 
> > Model the HX710B with variant-specific channel tables and IIO info,
> > track the active channel across conversions, and use the fixed gain
> > value when computing scale.
> > 
> > Also update the adjacent Kconfig text, file header, and module
> > description so the driver text matches the newly supported variant.  
> 
> ...
> 
> >  #include <linux/slab.h>
> >  #include <linux/sched.h>  
> 
> >  #include <linux/delay.h>
> > +#include <linux/types.h>  
> 
> Seems wrong order.
> 
> And here + blank line to make linux/iio/* to be a separate group.
> 
> >  #include <linux/iio/iio.h>
> >  #include <linux/iio/sysfs.h>
> >  #include <linux/iio/buffer.h>  
> 
> ...
> 
> >  	/*
> >  	 * triggered buffer
> > -	 * 2x32-bit channel + 64-bit naturally aligned timestamp
> > +	 * up to 3x32-bit channels + 64-bit naturally aligned timestamp
> > +	 *
> > +	 * aligned_s64 satisfies the 8-byte alignment requirement for the
> > +	 * timestamp. For HX711 (at most 2 active channels), iio_push_to_
> > +	 * buffers_with_timestamp() places the timestamp at offset 8
> > +	 * (scan_bytes=8, already 8-byte aligned), identical to the original
> > +	 * 2-channel layout. The extra channel slot for HX710B does not affect
> > +	 * the HX711 ABI.
> >  	 */
> >  	struct {
> > -		u32 channel[2];
> > +		u32 channel[3];
> >  		aligned_s64 timestamp;
> >  	} buffer;  
> 
> Why can't we used a recently introduced macro for this?
> IIO_DECLARE_BUFFER_WITH_TS().
Putting it more strongly - we should be using that macro.
The timestamp is only there if all 3 channels are enabled
and present on a given device.  So this structure is actively missleading
and hence the need for the complicated comment.

Just remove that implication by using the more flexible buffer declaration
macro that Andy is suggesting.  We have that macro for precisely this case!

Jonathan


>