linux-kernel - Re: [PATCH] soc: qcom: pd

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: <18e971c6-a0ef-4d48-a592-ec035b05d2b7@quicinc.com>
Date: Fri, 20 Sep 2024 07:00:11 -0700
From: Chris Lew <quic_clew@...cinc.com>
To: Johan Hovold <johan@...nel.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konradybcio@...nel.org>,
        Stephan Gerhold <stephan.gerhold@...aro.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH] soc: qcom: pd_mapper: fix ADSP PD maps



On 9/20/2024 2:02 AM, Johan Hovold wrote:
> On Fri, Sep 20, 2024 at 11:49:46AM +0300, Dmitry Baryshkov wrote:
>> On Fri, Sep 20, 2024 at 10:21:03AM GMT, Johan Hovold wrote:
>>> On Wed, Sep 18, 2024 at 04:02:39PM +0300, Dmitry Baryshkov wrote:
>>>> On X1E8 devices root ADSP domain should have tms/pdr_enabled registered.
>>>> Change the PDM domain data that is used for X1E80100 ADSP.
>>>
>>> Please expand the commit message so that it explains why this is
>>> needed and not just describes what the patch does.
>>
>> Unfortunately in this case I have no idea. It marks the domain as
>> restartable (?), this is what json files for CRD and T14s do. Maybe
>> Chris can comment more.
> 
> Chris, could you help sort out if and why this change is needed?
> 
> 	https://lore.kernel.org/all/20240918-x1e-fix-pdm-pdr-v1-1-cefc79bb33d1@linaro.org/	
> 

I don't think this change would help with the issue reported by Johan. 
 From a quick glance, I couldn't find where exactly the restartable 
attribute is used, but this type of change would only matter when the 
ChargerPD is started or restarted.

The PMIC_GLINK channel probing in rpmsg is dependent on ChargerPD 
starting, so we know ChargerPD can start with or without this change.

I can give this change a try next week to help give a better analysis.

>>> What is the expected impact of this and is there any chance that this is
>>> related to some of the in-kernel pd-mapper regression I've reported
>>> (e.g. audio not being registered and failing with a PDR error)?
>>>
>>> 	https://lore.kernel.org/all/ZthVTC8dt1kSdjMb@hovoldconsulting.com/
>>
>> Still debugging this, sidetracked by OSS / LPC.
> 
> Johan