Re: [PATCH 18/44] drivers/gpio: use min() instead of min_t()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Nov 20, 2025 at 09:37:43AM +0000, David Laight wrote:
> On Thu, 20 Nov 2025 10:01:29 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Nov 19, 2025 at 10:41:14PM +0000, david.laight.linux@gmail.com wrote:
> > > 
> > > min_t(u16, a, b) casts an 'unsigned long' to 'u16'.
> > > Use min(a, b) instead as it promotes the both values to int
> > > and so cannot discard significant bits.
> > > 
> > > In this case the values should be ok.
> > > 
> > > Detected by an extra check added to min_t().  

...

> > > acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address,  
> > 
> > > -	length = min_t(u16, agpio->pin_table_length, pin_index + bits);
> > > +	length = min(agpio->pin_table_length, pin_index + bits);  
> > 
> > Now, if you look closer at the code, the pin_index alone has the problem you
> > are targeting here.
> 
> The compiler warning happens because 'pin_index + bits' is 'int' and the compiler
> doesn't know the value fits in 16 bits.
> It should fit, but only if the caller passes in valid data.

I meant that assignment to pin_index already cuts the higher bits
from the input.

> > On top of that the iterator and 'length' are signed, while
> > the result of min_t(u16) is unsigned (however it has no difference in this case).
> 
> Actually the result type of min_t(u16) is 'int' (:? promotes char/short to int).
> So the u16 cast does '(pin_index + bits) & 0xffff', everything is then promoted
> to 'int' for all the comparisons (etc).

Sure, but the value is positive even if int is signed. That's why I put
a remark in the parentheses that it has no difference in this case.

...

> > TL;DR: I apply this patch with subject changed, but I think more work needs to
> > be done if you want to fix it fully.

-- 
With Best Regards,
Andy Shevchenko