linux-kernel - Re: [PATCH 2/2] dt-bindings: clock: update rk3588 clock definitions

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:   Sun, 26 Mar 2023 17:59:25 +0100
From:   Shane Francis <bigbeeshane@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        heiko@...ech.de, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: clock: update rk3588 clock definitions

Hi Krzysztof


> So mention this in the commit msg.

> Then commit msg should also mention it.

Sorry for not expanding on this more in the initial commit message, I will
expand on this in the next patch set.

However I think in general for most modern platforms it can be assumed
that replacing the bootloader is not always something that is achievable
for one reason or another


Thanks In Advance

On Sun, Mar 26, 2023 at 3:51 PM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 26/03/2023 14:02, Shane Francis wrote:
> >> Please wrap commit message according to > > Linux coding style /
> > submission
> >
> > Will do, I haven't submitted patches for a while totally forgot the
> > wrapping guidelines
> >
> >> Unfortunately the reason is not good enough > for ABI break. Replace
> >> vendor boot uboots with open-source one or > just correct them (it's still
> >> U-Boot so even for vendor one you have the source).
> >
> > Replacing uboot is fine for this case, however I can foresee that can cause
> > issues further down the line.
> >
> >
> > 1. No uboot source from the vendor, we all know no everyone respects code
> > licencing
> >
> > 2. Secure environments (like android tables), this chipset will likely end
> > up in android tablets that have the secure boot chain enable. These will be
> > unable to replace uboot even if source is available.
>
> So mention this in the commit msg.
>
> >
> > As this SoC is new to the Linux kernel (not even useable for much it's
> > current state) would it not be better to aling on this so vendor and
> > mainline DTS "agree" now rather than possibly have to address is in the
> > future ?
>
> Then commit msg should also mention it.
>
>
>
> Best regards,
> Krzysztof
>