Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230326001535.149539-1-bigbeeshane@gmail.com>
 <20230326001535.149539-2-bigbeeshane@gmail.com> <10930783-e1dd-5e75-a2cc-a09af862d949@linaro.org>
 <CABnpCuCzdbWTTp1Gc6wWPsB80J5GYw1QzKtZzzyEYU456E=1JA@mail.gmail.com> <1b9c8e19-10f2-824d-9b50-51e7a9287bb1@linaro.org>
In-Reply-To: <1b9c8e19-10f2-824d-9b50-51e7a9287bb1@linaro.org>
From:   Shane Francis <bigbeeshane@gmail.com>
Date:   Sun, 26 Mar 2023 17:59:25 +0100
Message-ID: <CABnpCuAWm7jh19JKukOquPnZCwHoJispgDPGJzjYy6T_BZSnbg@mail.gmail.com>
Subject: Re: [PATCH 2/2] dt-bindings: clock: update rk3588 clock definitions
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        heiko@sntech.de, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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=E2=80=AFPM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.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 s=
till
> >> U-Boot so even for vendor one you have the source).
> >
> > Replacing uboot is fine for this case, however I can foresee that can c=
ause
> > issues further down the line.
> >
> >
> > 1. No uboot source from the vendor, we all know no everyone respects co=
de
> > licencing
> >
> > 2. Secure environments (like android tables), this chipset will likely =
end
> > up in android tablets that have the secure boot chain enable. These wil=
l 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
>