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

[Conor Dooley]

On Mon, Jun 22, 2026 at 02:39:21PM +0200, Janani Sunil wrote:
> 
> 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.

That doesn't seem insurmountable, since these devices would really need
to be registered with a flag that notes sharing the cs is okay to solve
the problem in spi_dev_check_cs() which could be re-employed in
spi_dev_set_name() to append something.
Something could very well be the top bits of the address field used for
differentiation for spi{bus}.{cs}.{addr7..6}.

Whatever about this being the correct approach for your devices, there's
existing devices for which this would be needed to fully support, and
that doesn't seem like all that much work to do, if that's all that
prevents it.

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature