Re: [PATCH v3 3/6] spi: expand device name to include all CS lines for multi-CS devices

On Tue, Aug 18, 2026 at 05:14:20PM +0100, Nuno Sá wrote:
> On 2026-08-18 09:45:05+03:00, Andy Shevchenko wrote:
> > On Mon, Aug 17, 2026 at 08:32:57PM -0300, Jonathan Santos wrote:

...

> > > -	dev_set_name(&spi->dev, "%s.%u", dev_name(&spi->controller->dev),
> > > -		     spi_get_chipselect(spi, 0));
> > > +	cs_len = scnprintf(cs_str, sizeof(cs_str), "%u", spi_get_chipselect(spi, 0));
> > > +	for (unsigned int idx = 1; idx < spi->num_chipselect; idx++)
> > > +		cs_len += scnprintf(cs_str + cs_len, sizeof(cs_str) - cs_len,
> > > +				    "+%u", spi_get_chipselect(spi, idx));
> > 
> > So, if this won't support sparse CS list, I would just go with a standard range:
> > 
> > 	dev_set_name(&spi->dev, "%s.%u-%u", dev_name(&spi->controller->dev),
> > 		     spi_get_chipselect(spi, 0), spi_get_chipselect(spi, 0) + spi->num_chipselect - 1);
> 
> I don't think there's anything forcing cs to be contiguous. So cs4-0 does
> not mean we have 0,1,2,3 and 4 which I think the above implies.
> 
> Moreover, i also don't think is guaranteed that `spi_get_chipselect(spi,
> 0) + spi->num_chipselect - 1)` yields a valid cs. IOW, in theory
> 
> spi_get_chipselect(spi, spi->num_chipselect - 1) might be different
> than spi_get_chipselect(spi, 0) + spi->num_chipselect - 1

So, I would expect then two things:
- following the KISS and make sure we operate on the sequential CS ranges.
- definitely add some test cases, now it's a time (I consider NAKing any
version without test cases of this rather complex mapping logic)

> > (yes, need a variation for num_chipselect == 1, but I leave the rest for you)
> > 
> > Note, I do not see that we are expecting to see the sparse CS list here. It
> > would make too complex logic to follow. So, range approach is KISS in my opinion.

-- 
With Best Regards,
Andy Shevchenko