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@xxxxxxxxxx> 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 >
