Re: [PATCH v2 0/4] iio: adc: ad4080: add support for AD4880 dual-channel ADC

[David Lechner]

On 2/15/26 2:03 AM, Andy Shevchenko wrote:
> On Sat, Feb 14, 2026 at 12:31:12PM -0600, David Lechner wrote:
>> On 2/14/26 12:11 PM, Andy Shevchenko wrote:
>>> On Sat, Feb 14, 2026 at 04:08:52PM +0000, Jonathan Cameron wrote:
>>>> On Sun, 8 Feb 2026 14:50:23 +0200
>>>> Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
>>>>> On Fri, Feb 06, 2026 at 06:07:12PM +0200, Antoniu Miclaus wrote:
> 
> ...
> 
>>>>> I believe there is a better approach, what you need is rather a flag
>>>>> to SPI core to tell that this is the device with shared CS.
>>>>
>>>> Antoniu, this comment from Andy needs addressing before we move
>>>> on. It seems fairly fundamental and I'm not seeing a reply to it on list.
>>>>
>>>> I'm not entirely sure what Andy is suggesting will work but this
>>>> is perhaps a mismatch in really understanding what is going on here.
>>>> Andy, how would a flag work given they seem to be separately addressable
>>>> SPI buses. I think this isn't a shared SPI CS, but rather a device
>>>> with two entirely separate SPI buses. I think the only reason
>>>> we are bothering to implement it as a single device at all is the
>>>> shared backend.
>>>
>>> My understanding that there are two devices that for whatever reason share
>>
>> It is the opposite. It is a _single_ device with _two_ CS lines.
> 
> Don't we have already support for that? This changes the picture even more towards
> NAKing this. See below why.

Yes, spi_new_ancillary_device() was introduced exactly for this sort
of thing, which is why I think it makes sense to use it.

> 
>> adc@0 {
>> 	reg = <0>, <1>;
>> 	...
>> };
>>
>>> the same CS line. Yes, I probably misread the idea behind, but I meant
>>> some flag for SPI device that tells SPI core that the CS it wants is shared
>>> (maybe a high bit in the cs field or so), then CS core won't complain on
>>> validation about using the same cs number which is "already in use".
>>
>> There was one existing user in the kernel of spi_new_ancillary_device()
>> that looked like this, so it seemed the right way to approach it. However,
>> code was added later that caused the primary SPI device to "claim" both
>> CS lines for itself and probably broke the one existing user of
>> spi_new_ancillary_device() (hard to tell without hardware to test).
>>
>> The idea here was to unbreak that so we could use spi_new_ancillary_device()
>> just as in the existing use case.
>>
>> The patch for that could have been a bit more strict to only allow the
>> spi_new_ancillary_device() to take CS 1 and fail otherwise, but users
>> are going to notice if it isn't working right anyway, so I didn't ask
>> for more checking.
> 
>>>> There is an argument that maybe we should be looking at how
>>>> to do data muxing backends to support the more general case of two
>>>> separate chips feeding into a single buffer, but that's a complex
>>>> beast and I'm not sure if it is something we actually need.
>>
>> I think it would actually be quite similar to what is done in this
>> series.
> 
> TBH, the change sounds to me like a hack. It doesn't cover other potential ways
> of the multi-cs devices come into play. Given that SPI core supports multi-cs
> I don't see a good justification for this patch.
> 
> What did I miss?

As far as I can tell, other than the one existing user of
spi_new_ancillary_device(), other SPI multi-CS stuff is only used
by SPI flash memory devices, not general SPI devices. There code
that is being modified here was introduced to support the SPI
flash memory devices, so that use case is already covered by
existing code.