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: <Y6WNfXUQhZot9wcR@e126835.cambridge.arm.com>
Date:   Fri, 23 Dec 2022 11:14:05 +0000
From:   Emekcan Aras <emekcan.aras@....com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Liviu Dudau <liviu.dudau@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Miguel Silva <rui.silva@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] arm: dts: arm: add arm corstone500 device tree

On Fri, Dec 23, 2022 at 09:26:54AM +0100, Krzysztof Kozlowski wrote:
> On 22/12/2022 13:32, Emekcan Aras wrote:
> > Corstone500[0] is a platform from arm, which includes Cortex-A cores and
> > ideal starting point for feature rich System on Chip (SoC) designs
> > based on the Cortex-A5 core.
> > 
> > These device trees contains the necessary bits to support the
> > Corstone 500 FVP (Fixed Virtual Platform) and the
> > FPGA MPS3 board.
> > 
> > 0: https://developer.arm.com/documentation/102262/0000
> > 
> > Signed-off-by: Emekcan Aras <emekcan.aras@....com>
> > ---
> >  arch/arm/boot/dts/Makefile        |   3 +-
> >  arch/arm/boot/dts/corstone500.dts | 182 ++++++++++++++++++++++++++++++
> >  2 files changed, 184 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/boot/dts/corstone500.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 6aa7dc4db2fc..4dc4df0707dc 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -1465,7 +1465,8 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += \
> >  	vexpress-v2p-ca5s.dtb \
> >  	vexpress-v2p-ca9.dtb \
> >  	vexpress-v2p-ca15-tc1.dtb \
> > -	vexpress-v2p-ca15_a7.dtb
> > +	vexpress-v2p-ca15_a7.dtb \
> > +	corstone500.dtb
> 
> Why this is vexpress platform? If it is true, then add it to vexpress
> bindings... It's confusingi and looks disorganized - some bindings here,
> some platform there. Who is overseeing it? Who is maintaining? Who keeps
> it consistent with other Arm platforms?
> 
> >  dtb-$(CONFIG_ARCH_VIRT) += \
> >  	xenvm-4.2.dtb
> >  dtb-$(CONFIG_ARCH_VT8500) += \
> > diff --git a/arch/arm/boot/dts/corstone500.dts b/arch/arm/boot/dts/corstone500.dts
> > new file mode 100644
> > index 000000000000..bcca7d736c85
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/corstone500.dts
> > @@ -0,0 +1,182 @@
> > +// SPDX-License-Identifier: GPL-2.0 or MIT
> > +/*
> > + * Copyright (c) 2022, Arm Limited. All rights reserved.
> > + *
> > + */
> > +
> > +
> 
> kbuild reports that patch does not build. :(
> 
> Except that other topics which you did not solve from previous case:
> 1. Missing maintainers entry
> 2. One binding file for your Corstone platforms, not for each of it.
> 3. failing `dtbs_check` (at least failing due to non-compiling DTS).
> 4. Subject prefix not matching other arm platforms.
> 
> 
> Best regards,
> Krzysztof
>

Hi Krzysztof, sorry for the late reply. My mail client had an issue, and that's�
also the reason why I missed some of your comments before. Anyway, thanks for �
the comments. Ccorstone500 is currently in maintainance mode, and mostly used �
internally nowadays. I don't  expect to see any corstone500 variance in the �
future. We just wanted to upstream few remaing patches on u-boot and kernel so �
that we don't need to keep rebasing the out-of-tree patches for never version �
upgrades. Also corstone500 normally uses device-tree in u-boot, however as you�
know we need to first upstream kernel device tree to be able upstream to u-boot�
device tree. Long story short, let me build this and test it throughly, to make�
sure everything is passing and make sure all your comments are addressed. Sorry�
for inconvience.�
  �
Cheers,�
Emek�

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ