Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R

[Janani Sunil]

On 6/22/26 14:14, Conor Dooley wrote:
> On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
> > > > > > Why do you think the microchip devices won't work? Does the spi core
> > > > > > reject multiple devices with the same chip select being registered or
> > > > > > something like that?
> > > > > Not sure how things work atm. But I'm fairly sure it used to be like
> > > > > that. SPI would reject devices on the same controller and CS. Now that
> > > > > we support more than one CS per controller, not sure how things work.
> > > > We always supported more than one per CS per controller. I guess you mean
> > > > per device.
> > > Obviously :)
> > > > > Janani, maybe you can give it a try?
> > > > I think we'd need to get it to work with shared gpio proxy which maybe
> > > > will just get set up under the hood.  This used to be opt in, but seems
> > > > that changed fairly recently so maybe some of us are working with out
> > > > of date knowledge!  I haven't played with it yet, so might not be
> > > > that simple.
> > > What I meant for Janani was basically testing two devices on the same CS
> > > as in my pseudo DT. For the GPIO, you mean having a way to select
> > > between devices on the same CS?
> > >
> > > For these devices the pin id numbers get's setted up as part of the spi message
> > > so my assumption is that all of them will receive the message but only one acks it.
> > >
> > > - Nuno Sá
> > Hi Everyone,
> >
> > I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
> > https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
>
> Can you try again, but delete that check and allow the code to continue?
> Worth knowing if the problem is policy (which makes sense for 99.99% of
> devices that cannot share a chip select) or actually not supported by
> the spi core code.

Hi Conor,

The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer.
The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory.

- Janani Sunil