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
| ||
|
Date: Wed, 31 Aug 2022 07:52:52 -0700 From: Doug Anderson <dianders@...omium.org> To: Johan Hovold <johan@...nel.org> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>, Andrew Halaney <ahalaney@...hat.com>, Mark Brown <broonie@...nel.org>, Andy Gross <agross@...nel.org>, AngeloGioacchino Del Regno <angelogioacchino.delregno@...ainline.org>, Bhupesh Sharma <bhupesh.sharma@...aro.org>, Johan Hovold <johan+linaro@...nel.org>, Konrad Dybcio <konrad.dybcio@...ainline.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Rob Herring <robh+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2 0/6] arm64: dts: qcom: Fix broken regulator spec on RPMH boards Hi, On Tue, Aug 30, 2022 at 11:47 PM Johan Hovold <johan@...nel.org> wrote: > > On Mon, Aug 29, 2022 at 09:49:46AM -0700, Douglas Anderson wrote: > > Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement > > get_optimum_mode(), not set_load()") several boards were able to > > change their regulator mode even though they had nothing listed in > > "regulator-allowed-modes". After that commit (and fixes [1]) we'll be > > stuck at the initial mode. Discussion of this (again, see [1]) has > > resulted in the decision that the old dts files were wrong and should > > be fixed to fully restore old functionality. > > > > This series attempts to fix everyone. I've kept each board in a > > separate patch to make stable / backports work easier. > > Should you also update the bindings so that this can be caught during > devicetree validation? That is, to always require > "regulator-allowed-modes" when "regulator-allow-set-load" is specified. Yeah, it's probably a good idea. I'm happy to review a patch that does that. I'm already quite a few patches deep of submitting random cleanups because someone mentioned it in a code review. ;-) That's actually how I got in this mess to begin with. The RPMH change was in response to a request in a different code review. ...and that came about in a code review that was posted in response to a comment about how awkward setting regulator loads was... Need to get back to my day job. In any case, I think these dts patches are ready to land now. > Perhaps at least for RPMh as it seemed you found some cases were this > wasn't currently needed (even if that sounded like an Linux-specific > implementation detail). I think you're talking about the RPM vs. RPMH difference? It's actually not Linux specific. In RPM the API to the "hardware" (actually a remote processor) is to pass the load. In RPMH the API to the hardware is to pass a mode. This is why RPMH has "regulator-allowed-modes" and "regulator-initial-mode". Both RPM and RPMH have "regulator-allow-set-load" though... -Doug
Powered by blists - more mailing lists