linux-kernel - Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"

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: <a1ae54dd-7294-90e1-db6b-1f2f5de7fe64@free.fr>
Date:   Fri, 8 Feb 2019 11:03:51 +0100
From:   Marc Gonzalez <marc.w.gonzalez@...e.fr>
To:     Alim Akhtar <alim.akhtar@...sung.com>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Yaniv Gardi <ygardi@...eaurora.org>,
        Hannes Reinecke <hare@...e.de>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Evan Green <evgreen@...omium.org>,
        Douglas Anderson <dianders@...omium.org>,
        Avri Altman <avri.altman@....com>,
        Pedro Sousa <pedrom.sousa@...opsys.com>,
        Subhash Jadavani <subhashj@...eaurora.org>,
        Bart Van Assche <bvanassche@....org>,
        SCSI <linux-scsi@...r.kernel.org>, Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed
 by UFS device"

+ Yaniv (just in case)
+ Hannes (if he remembers)

We're discussing commit 60f0187031c05e04cbadffb62f557d0ff3564490

On 08/02/2019 10:09, Alim Akhtar wrote:

> On 07/02/19 8:22 PM, Jeffrey Hugo wrote:
> 
>> Did you see https://lkml.org/lkml/2019/2/5/659 where I indicated VCCQ 
>> powers components within the host controller, and by not setting load on 
>> the regulator properly, we are likely undervolting those components due 
>> to the current draw?
>
> In theory may be true. But looks like we dont have a solid evidence yet 
> (correct me if I am wrong or misunderstood anything here)
> So that means its some short of hardware/board quirk, right?
> Can you please recheck the schematic and see what Bjorn is telling 
> (about having right entries in the DT for regulator) resolve your issue?

I think there might be a misunderstanding on your side.

Basically, Bjorn is saying that code to disable a regulator is not needed.
(Therefore he is in favor of the patch to revert.)

If a board does not require some power rail, then it should simply *not*
list it in the DT. My board *does* require that power rail, so I must
list it in the DT. The driver should not attempt to work around that
simple fact (by disabling a regulator that was erroneously listed).

> Marc, Can you disabled pmic on that board (hope your board boots with 
> default PMIC supply) and see if this issue still occurs?
> I am just trying to understand and see what is the real cause.

I don't know how to disable the PMIC.

> @Yaniv Gardi, will you be able to comment on reason for adding 
> 60f0187031c05e04cbadffb62f557d0ff3564490 (any issue faced)?

AFAIU, Yaniv no longer works for CA, so he is unlikely to reply.

I'll resend the series and CC the regulators maintainers so they
can share their thoughts.

Regards.