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: <c55d8212-9b7e-4ede-a15d-3fbeeb95f956@kernel.org>
Date: Tue, 10 Dec 2024 16:56:26 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konradybcio@...il.com>,
 Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>,
 Konrad Dybcio <konrad.dybcio@....qualcomm.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

>> There would be spare register but i think it should be in sync with hardware team. let me check with them and update back if any bit can be repurposed for this feature. I agree, if any register is available, it can programmed prior to kernel.
>>> It would need to be reserved on all SoCs though (future and
>>> past), to make sure the contract is always held up, but I
>>> think finding a persistent bit that has never been used
>>> shouldn't be impossible.
>>>
>> Yes, let me check it with hardware and firmware team and update back. Does this mean, there can't be a such software sharing mechanism (purely software decision) based on DTSI flag ?
> 
> I suppose that depends on our needs. If we can set that bit
> before Linux starts (i.e. in UEFI), we can avoid touching
> the pinctrl state regardless of whether the other entities
> have started up yet to avoid overcomplicating it.
> 
> If we need Linux to set that bit, we would still need some
> mechanism like a dt property. But I really think that the
> bootloader should be burdened with this instead, given it
> has a better understanding of the hardware due to it being
> well, the bootloader).
> 
> Krzysztof, I'm assuming that sounds sane from your
> perspective too?
Yes, sound okay.

Best regards,
Krzysztof