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: <e9fb294b-b6b8-4034-84c9-a25b83321399@kernel.org>
Date: Tue, 10 Dec 2024 08:28:38 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: 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 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.

> 
> Even here, I'm not particularly sure whether dt is the right place.
> Maybe we could think about checking for clock_is_enabled()? That's
> just an idea, as it may fall apart if CCF gets a .sync_state impl.



Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ