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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa3ee895-5353-44f5-b816-9d17b6a7d199@kernel.org>
Date: Mon, 2 Dec 2024 12:13:29 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: 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 12:04, Krzysztof Kozlowski wrote:
> On 02/12/2024 11:38, Mukesh Kumar Savaliya wrote:
>>>
>>> Come with one flag or enum, if needed, covering all your cases like this.
>>>
>> Let me explain, this feature is one of the additional software case 
>> adding on base protocol support. if we dont have more than one usecase 
>> or repurposing this feature, why do we need to add enums ? I see one 
>> flag gpi_mode but it's internal to driver not exposed to user or expose 
>> any usecase/feature.
>>
>> Below was our earlier context, just wanted to add for clarity.
>> --
>>  > Is sharing of IP blocks going to be also for other devices? If yes, then
>>  > this should be one property for all Qualcomm devices. If not, then be
>>  > sure that this is the case because I will bring it up if you come with
>>  > one more solution for something else.
> 
> 
> You keep repeating the same. You won't receive any other answer.
> 
>>  >
>> 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?
> 
> Please confirm that you Qualcomm engineers understand the last statement
> and that every block will use se-shared, even if we speak about UFS for
> example.
> 

I think I was pretty clear also 2 months ago what do I expect from this:

https://lore.kernel.org/all/52f83419-cc5e-49f3-90a7-26a5b4ddd5a0@kernel.org/


I do not see this addressing qcom-wide way at all. Four new versions of
patch and you still did not address first fedback you got.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ