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]
Date:   Mon, 18 Jul 2022 14:51:13 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Bhupesh Sharma <bhupesh.sharma@...aro.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm@...r.kernel.org, bhupesh.linux@...il.com,
        linux-kernel@...r.kernel.org, robh@...nel.org
Subject: Re: [PATCH v2 6/6] arm64: dts: qcom: ipq8074: Fix 'max-frequency'
 value for sdhci node

On Mon, 18 Jul 2022 at 10:47, Bhupesh Sharma <bhupesh.sharma@...aro.org> wrote:
>
> On 7/1/22 4:24 AM, Bjorn Andersson wrote:
> > On Sat 14 May 16:54 CDT 2022, Bhupesh Sharma wrote:
> >
> >> Since the Qualcomm sdhci-msm device-tree binding has been converted
> >> to yaml format, 'make dtbs_check' reports issues with
> >> 'max-frequency' value for ipq8074 sdhci node:
> >>
> >>   arch/arm64/boot/dts/qcom/ipq8074-hk01.dtb: mmc@...4900:
> >>    max-frequency:0:0: 384000000 is greater than the maximum of 200000000
> >>
> >> Fix the same.
> >>
> >> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> >> Cc: Rob Herring <robh@...nel.org>
> >> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@...aro.org>
> >> ---
> >>   arch/arm64/boot/dts/qcom/ipq8074.dtsi | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> index ab2a1e7955b5..b2d71af9b419 100644
> >> --- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
> >> @@ -388,7 +388,7 @@ sdhc_1: mmc@...4900 {
> >>                               <&gcc GCC_SDCC1_APPS_CLK>,
> >>                               <&xo>;
> >>                      clock-names = "iface", "core", "xo";
> >> -                    max-frequency = <384000000>;
> >> +                    max-frequency = <200000000>;
> > This might match the binding, but someone put 384000000 there for a
> > reason. Perhaps the binding needs to be updated instead?
>
> I was waiting for getting access to ipq8074 reference manual / documentation.
> I double-checked and it seems SDCC1 on this SoC does support a max frequency
> of 384 MHz which is strange as the SDCC2 supports 200 MHz as max frequency
> instead.

I guess it depends on what the property is being used for from the mmc
host driver perspective. So, to answer the question, we probably need
to look at the code in the host driver to best understand what to do
here.

>
> Also the eMMC and MMC controllers on other SoCs (i.MX etx( usually support only
> a max frequency of 200 MHz, so may be we need an exceptional addition to the
> binding documentation here.
>
> @Ulf - what's your view on updating the binding documentation here? I can
> send a v3 accordingly.

The point with the property is to let host controllers specify whether
there is an upper limit of the frequency that it can support. No
matter what, the mmc core will not use a frequency greater than stated
by the eMMC/SD/SDIO specs.

For eMMC, 200MHz is the maximum frequency.

For SD/SDIO cards, the SDR104 mode has 208MHz. So it seems like we
need an update to the binding, no matter what. :-)

I have no strong opinions around this, but perhaps just raising the
limit of the binding to cover the qcom case makes best sense.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ