linux-kernel - Re: [PATCH v2] usb: typec: qcom: check regulator enable status before disabling it

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: <6187e719-d1a4-4985-b43f-efaeca2dde89@quicinc.com>
Date:   Mon, 28 Aug 2023 13:51:01 +0800
From:   hui liu <quic_huliu@...cinc.com>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>
CC:     Guenter Roeck <linux@...ck-us.net>, Andy Gross <agross@...nel.org>,
        "Bjorn Andersson" <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_fenglinw@...cinc.com>,
        <subbaram@...cinc.com>
Subject: Re: [PATCH v2] usb: typec: qcom: check regulator enable status before
 disabling it



On 8/25/2023 6:11 PM, Bryan O'Donoghue wrote:
> On 25/08/2023 11:03, hui liu wrote:
>> Hi Heikki,
>>
>> I will let Bryan to comment, I am using the driver to support the 
>> pdphy in SMB2352 and there is no external regulator required, so I am 
>> just using a dummy regulator device and I saw this unbalanced 
>> regulator disabling warnings, so my intention for this change is just 
>> fixing the warning message. However, I am fine with whatever 
>> suggestion you have, since the logic is straightforward, and I can 
>> make the changes once you have the agreement.
>>
>> Thanks,
>> Hui
> 
> Err well on real hardware with a real regulator I don't see this error.
Just a doublt, if real regulator has no this error, who enabled it 
before it was reseted?
> 
> I'd say we should try the second proposed changed in pdphy_start 
> pdphy_stop since it looks neater.
> 
I updated the code refer to the proposal, and it worked well,but I just 
thought it makes code a little redundant. Why don't we only keep one 
pdphy_enable/pdphy_disable or pdphy_start/pdphy_stop?
> If it works then fine, else lets stick to your original fix.
> 
> ---
> bod