linux-kernel - Re: [PATCH v2] i2c: i2c-qcom-geni: Serve transfer during early resume stage

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: <f96fbfc5-ed5a-4def-a7e0-df4098dea4b3@quicinc.com>
Date: Sat, 23 Nov 2024 17:43:09 +0530
From: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>
To: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
CC: <andi.shyti@...nel.org>, <quic_bjorande@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <konrad.dybcio@...aro.org>,
        <quic_vdadhani@...cinc.com>, <vkoul@...nel.org>
Subject: Re: [PATCH v2] i2c: i2c-qcom-geni: Serve transfer during early resume
 stage

Thanks Bjorn.

On 11/19/2024 8:29 PM, Bjorn Andersson wrote:
> On Tue, Nov 19, 2024 at 8:29 AM Mukesh Kumar Savaliya
> <quic_msavaliy@...cinc.com> wrote:
>> On 10/11/2024 11:28 PM, Bjorn Andersson wrote:
>>> On Fri, Oct 11, 2024 at 05:47:57PM +0530, Mukesh Kumar Savaliya wrote:
> [..]
>>>> pm_runtime_get_sync() function fails during PM early resume and returning
>>>> -EACCES because runtime PM for the device is disabled at the early stage
>>>> causing i2c transfer to fail. Make changes to serve transfer with forced
>>>> resume.
>>>>
>>>> Few i2c clients like PCI OR touch may request i2c transfers during early
>>>> resume stage. In order to serve transfer request do :
>>>>
>>>
>>> This problem description is too generic. I am not aware of any use case
>>> upstream where PCI or touch might need to perform i2c transfers during
>>> early resume; your commit message should educate me.
>>>
>> yes, it's generic as of now since we have an internal usecase with PCI
>> is yet to be enabled in upstream. Not tied up with any usecase in
>> upstream, i just heard recently.
>>
>> Provided the scenario is generic and possible by any client, can this
>> code change be reviewed or shall be kept on halt till PCI usecase gets
>> enabled ?
>>
> 
> If this is a valid scenario in the upstream kernel, yes. If it solves
> a problem only manifesting itself based on a downstream design then
> you need to exactly describe that scenario so that reviewers can
> decide if this is a problem with the upstream kernel or your
> downstream design.
> 
The exact scenario from PCIe switch is as below.  Hope it describes the 
usecase at high level to understand PCIe client -> PCIe Driver -> I2C 
driver.

PCIe switch needs certain configurations through i2c after powering on 
the switch, as part of suspend we are using suspend_noirq() to turn off 
the switch because some PCIe clients do some transfers till 
suspend_noirq() phase. And as part of resume_noirq(), we will enable the 
power to the switch and configures the switch again through i2c.


> Regards,
> Bjonr
>