Re: [PATCH] iio: adc: ti-ads7138: explicitly include <linux/slab.h>

[Jonathan Cameron]

On Fri, 24 Apr 2026 12:07:24 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Fri, Apr 24, 2026 at 12:18:10PM +0400, Giorgi Tchankvetadze wrote:
> > ti-ads7138.c uses kmalloc() and kfree(), which are provided by
> > linux/slab.h, but does not include that header directly.
> > The driver currently gets these declarations through linux/i2c.h.
> > Include linux/slab.h explicitly instead of relying on the transitive
> > include.  
> 
> If you want to make it real patch, please convert it to follow IWYU.
> What you are saying is basically comes from kernel.h (yeah, i2c.h happens
> earlier, but the kernel.h is PITA currently).
> 
> WRT to the kmalloc() use, wouldn't it be simply better to use
> i2c_master_send_dmasafe() and kill that kmalloc() dance in the driver?
> 

That sounds backwards. IIRC i2c_master_send_dmasafe() needs a heap allocation
to ensure a DMA safe buffer.  See i2c_get_dma_safe_msg_buf() and
the check on I2C_M_DMA_SAFE.

This function is just overly flexible. 
 
static int ads7138_i2c_write_block(const struct i2c_client *client, u8 reg,
				   u8 *values, u8 length)
{
	int ret;
	int len = length + 2; /* "+ 2" for OPCODE and reg */

	u8 *buf __free(kfree) = kmalloc(len, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;

	buf[0] = ADS7138_OPCODE_BLOCK_WRITE;
	buf[1] = reg;
	memcpy(&buf[2], values, length);

	ret = i2c_master_send(client, buf, len);
	if (ret < 0)
		return ret;
	if (ret != len)
		return -EIO;

	return 0;
}
But length is always 2.  You could hammer it into i2c_smbus_write_i2c_block_data()
but that would be confusing at best as it would be putting the magic block write
in where the address normally goes and the address into the first data byte.

So I'd just go with
u8 buf[4];

if (length != 2)
	return -EINVAL;

Then use buf directly.

If you want to get fancy the caller could actually pass a u16 with val << 4
in the one caller (I think) and end up with same data but then we'd need
mess around with a memcpy to land that in the right bytes so maybe not
worth it.

To me either of these last two ways would be fine.

Jonathan