linux-kernel - Re: [PATCH v5 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f1fa2bde-95ce-45e9-ad2d-f1d82ec6303c@kernel.org>
Date: Tue, 10 Dec 2024 12:53:43 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konradybcio@...il.com>,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>, konrad.dybcio@...aro.org,
 andersson@...nel.org, andi.shyti@...nel.org, linux-arm-msm@...r.kernel.org,
 dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-i2c@...r.kernel.org, conor+dt@...nel.org, agross@...nel.org,
 devicetree@...r.kernel.org, vkoul@...nel.org, linux@...blig.org,
 dan.carpenter@...aro.org, Frank.Li@....com, konradybcio@...nel.org,
 bryan.odonoghue@...aro.org, krzk+dt@...nel.org, robh@...nel.org
Cc: quic_vdadhani@...cinc.com
Subject: Re: [PATCH v5 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared
 flag

On 10/12/2024 10:09, Konrad Dybcio wrote:
> 
> 
> On 12/10/24 08:28, Krzysztof Kozlowski wrote:
>> On 02/12/2024 15:04, Konrad Dybcio wrote:
>>>>>>    >
>>>>>> IP blocks like SE can be shared. Here we are talking about I2C sharing.
>>>>>> In future it can be SPI sharing. But design wise it fits better to add
>>>>>> flag per SE node. Same we shall be adding for SPI too in future.
>>>>>
>>>>>
>>>>> How flag per SE node is relevant? I did not ask to move the property.
>>>>>
>>>>>>
>>>>>> Please let me know your further suggestions.
>>>>> We do not talk about I2C or SPI here only. We talk about entire SoC.
>>>>> Since beginning. Find other patch proposals and align with rest of
>>>>> Qualcomm developers so that you come with only one definition for this
>>>>> feature/characteristic. Or do you want to say that I am free to NAK all
>>>>> further properties duplicating this one?
>>>
>>> I'm not sure a single property name+description can fit all possible
>>> cases here. The hardware being "shared" can mean a number of different
>>
>> Existing property does not explain anything more, either. To recap -
>> this block is SE and property is named "se-shared", so basically it is
>> equal to just "shared". "shared" is indeed quite vague, so I was
>> expecting some wider work here.
>>
>>
>>> things, with some blocks having hardware provisions for that, while
>>> others may have totally none and rely on external mechanisms (e.g.
>>> a shared memory buffer) to indicate whether an external entity
>>> manages power to them.
>>
>> We have properties for that too. Qualcomm SoCs need once per year for
>> such shared properties. BAM has two or three. IPA has two. There are
>> probably even more blocks which I don't remember now.
> 
> So, the problem is "driver must not toggle GPIO states", because
> "the bus controller must not be muxed away from the endpoint".
> You can come up with a number of similar problems by swapping out
> the quoted text.
> 
> We can either describe what the driver must do (A), or what the
> reason for it is (B).
> 
> 
> If we go with A, we could have a property like:
> 
> &i2c1 {
> 	externally-handled-resources = <(EHR_PINCTRL_STATE | EHR_CLOCK_RATE)>
> };
> 
> which would be a generic list of things that the OS would have to
> tiptoe around, fitting Linux's framework split quite well
> 
> 
> 
> or if we go with B, we could add a property like:
> 
> &i2c1 {
> 	qcom,shared-controller;
> };
> 
> which would hide the implementation details into the driver
> 
> I could see both approaches having their place, but in this specific
> instance I think A would be more fitting, as the problem is quite
> simple.


The second is fine with me, maybe missing information about "whom" do
you share it with. Or maybe we get to the point that all this is
specific to SoC, thus implied by compatible and we do not need
downstream approach (another discussion in USB pushed by Qcom: I want
one compatible and 1000 properties).

I really wished Qualcomm start reworking their bindings before they are
being sent upstream to match standard DT guidelines, not downstream
approach. Somehow these hundreds reviews we give could result in new
patches doing things better, not just repeating the same issues.

Best regards,
Krzysztof