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: <350b296b62a982f83e273f0f385f2b6f.sboyd@kernel.org>
Date:   Fri, 10 Feb 2023 14:32:14 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] clk: qcom: restrict drivers per ARM/ARM64

Quoting Krzysztof Kozlowski (2023-01-31 23:12:53)
> On 31/01/2023 00:30, Stephen Boyd wrote:
> > Quoting Krzysztof Kozlowski (2023-01-26 01:31:55)
> >> On 25/01/2023 21:44, Stephen Boyd wrote:
> >>> Quoting Krzysztof Kozlowski (2023-01-23 01:49:25)
> >>>> There is no point to allow selecting pin-controller drivers for Qualcomm
> >>>
> >>> pin controllers?
> >>
> >> Copy-paste, I'll fix it.
> >>
> >>>
> >>>> ARMv7 SoCs when building ARM64 kernel, and vice versa.  This makes
> >>>> kernel configuration more difficult as many do not remember the Qualcomm
> >>>> SoCs model names/numbers.  There won't be a single image for ARMv7 and
> >>>> ARMv8/9 SoCs, so no features/options are lost.
> >>>
> >>> Are the drivers used in arm32 emulation mode on these SoCs? I recall
> >>> there are some SoCs they run with the arm architecture.
> >>
> >> I did not add it to the few SoCs which have upstream DTS in ARM and
> >> ARM64. I added only to the ones which are in one specific folder. Also
> >> my patch does not affect defconfigs (qcom_defconfig and arm64/defconfig).
> > 
> > Cool, thanks for checking. Is it possible to take a dtb from arm64 dts
> > directory and boot it on an armv8 CPU running in 32-bit mode? Just
> > wondering if even having the dts file exist in the arm64 architecture
> > really matters here.
> 
> If DTSI (and/or board DTS) is in arm64, you still need DTS or a link in
> arm directory. If such one is added, then the restrictions here can be
> removed. Have in mind that I did the same already for pinctrl.
> 

I'm saying that you put the dts file in arch/arm64/boot/dts/, compile
the dts to a dtb and stick it on a board that boots the kernel in arm32
mode. If it is possible to boot the dtb on a CPU running in arm32 mode
then this restriction should be loosened to 

	depends on ARM || ARM64 || COMPILE_TEST

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ