linux-kernel - Re: [PATCH v3 04/10] dt-bindings: iio: dac: ad3552r: add io-backend support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c8de40cb-5509-4699-a847-0a4c1f00ed08@kernel.org>
Date: Wed, 2 Oct 2024 07:54:22 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jonathan Cameron <jic23@...nel.org>, Nuno Sá
 <noname.nuno@...il.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Angelo Dureghello <adureghello@...libre.com>,
 Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Olivier Moysan <olivier.moysan@...s.st.com>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, dlechner@...libre.com
Subject: Re: [PATCH v3 04/10] dt-bindings: iio: dac: ad3552r: add io-backend
 support

On 01/10/2024 20:29, Jonathan Cameron wrote:
>>>
>>> Makes all sorts of assumptions about the SPI controllers being designed
>>> for multi controllers on the same SPI buses but I'm not aware of a reason
>>> you can't do that.
>>>
>>> As the only control message that would need to go over the offload engine
>>> would be the exit DDR (I think) that might be hard coded into a slightly
>>> simpler soft IP along with the bulk data transfer stuff.
>>>   
>>
>> Not even sure if DDR would be a problem. Right now, I __think__ we need to
>> enable DDR both the peripheral and on the backend. On the peripheral we could
>> use the control link on the non offload controller. On the offload controller,
>> we would set it through IIO backend and that would be a backend config and not
>> go over the bus.
> 
> It's the path back to SDR that I wasn't sure about as it might need a
> DDR register write?
> 
>>
>> To make a correction on my previous reply to Krzysztof, the HW folks made some
>> experiments with the SPI ENIGINE IP (with the offload engine) but without the
>> AXI DAC IP. So, effectively only one controller in place. That said, I'm also
>> not seeing any reason why something like the above would not be possible.
> 
> Conclusion / summary for Krzystoff and other DT binding
> folk. It's possible to use this with another backend (which no one has
> written the IP for yet) so I (at least) think the reference is needed
> even though the only one we have right now is also the parent.
> 
> Driver wise, we could in theory poke the parent if the property isn't there
> on the off chance it is a suitable backend, but we can't assume that's
> the one in use even if it has some suitable support.  Maybe there
> is a more capable one double wired?
> 
> So I'd like to keep the io-backend phandle there.

Ack.

Best regards,
Krzysztof