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: <CADLxj5RD5syLXdVnfsMpEso9VOhWiwdP8_iV12R=mvhKwUY_bA@mail.gmail.com>
Date: Tue, 19 Nov 2024 08:59:00 -0600
From: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
To: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.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

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.

Regards,
Bjonr