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: Mon, 31 Jan 2022 17:01:02 -0800 From: Doug Anderson <dianders@...omium.org> To: Bjorn Andersson <bjorn.andersson@...aro.org> Cc: Stephen Boyd <swboyd@...omium.org>, Viresh Kumar <viresh.kumar@...aro.org>, Konrad Dybcio <konrad.dybcio@...ainline.org>, kgodara@...eaurora.org, Matthias Kaehlcke <mka@...omium.org>, Sibi Sankar <sibis@...eaurora.org>, Prasad Malisetty <pmaliset@...eaurora.org>, quic_rjendra@...cinc.com, Andy Gross <agross@...nel.org>, Rob Herring <robh+dt@...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 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1 Hi, On Mon, Jan 31, 2022 at 8:50 AM Doug Anderson <dianders@...omium.org> wrote: > > > Either we leave it as is - which follows my interpretation of what the DT > > spec says - or we (and the DT maitainers) agree that it shouldn't be > > there (because this dtb won't run on any random qcom,sc7180 anyways) at > > all. > > I'm curious what part of the DT spec says that we should have the SoC > in there? I know I've always done it, but it's always just been > following the examples of what was done before. When talking about the > root node, I see this in the `devicetree-specification-v0.4-rc1` spec: > > --- > > Specifies a list of platform architectures with which this platform is > compatible. This property can be used by operating systems in > selecting platform specific code. The recommended form of the property > value is: "manufacturer,model" > > For example: > compatible = "fsl,mpc8572ds" > > --- > > That doesn't say anything about putting the SoC there. > > > I would also note that I'd be at least moderately inclined to land > things as-is and deal with this in a follow-up patch, though I'm happy > to spin if that's what people agree upon too. This is not a new > problem and so it doesn't seem like it makes sense to glom dealing > with it into this patch series... I noticed that you applied the first 4 patches in the series (thanks!) but not this one. Are we waiting to get agreement on this before landing? As per above, I think it'd be OK to land as-is and then I'm happy to do a follow-up patch to clean this up since this isn't a new issue. Having this patch outstanding makes it a little confusing with the other cleanup patches that I'm posting... ;-) Thanks! -Doug
Powered by blists - more mailing lists