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] [day] [month] [year] [list]
Message-ID: <BY5PR02MB7009FC653B20D32E8A17C3C1EA889@BY5PR02MB7009.namprd02.prod.outlook.com>
Date:   Thu, 14 Jul 2022 22:57:10 +0530
From:   Joel Selvaraj <joel.selvaraj@...look.com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Joel Selvaraj <jo@...amily.in>
Cc:     Andy Gross <agross@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org
Subject: Re: [PATCH 1/5] arm64: dts: sdm845-xiaomi-beryllium: rename
 beryllium.dts into beryllium-common.dtsi

Hi Bjorn Andersson

On 14/07/22 02:22, Bjorn Andersson wrote:
> Applying this patch would cause the tree to fail to build until the last
> patch is introduced. This would cause problems for people trying to use
> git bisect to find regressions in the git history.
> 
> Could you please respin this patch such that it continues to build the
> currently supported board and then you could add the new board/variant
> in a separate commit.

Ok. Understood. But I am not entirely sure how I implement this? Since
except for display and touchscreen, everything is almost the same. So I
wanted to move the common bits to a common dtsi. Here is the cover
letter where I explain a bit on the situation, if it's missed and not
noticed.

Link:
https://lore.kernel.org/r/MN2PR02MB702415D7BF12B7B7A41B2D38D9829@MN2PR02MB7024.namprd02.prod.outlook.com/

Here are few things I think I can do, kindly let me know which seems
more ideal.

1. Don't create a common dtsi and leave the existing dts as it is and
just create a new dts for the new variant.
sdm845-xiaomi-beryllium.dts - untouched. represents tianma variant.
sdm845-xiaomi-beryllium-ebbg.dts - new dts, represents ebbg variant.

2. Create new common dtsi file and move all the common bits to it. Then
create new dts for ebbg variant.
sdm845-xiaomi-beryllium-common.dtsi - new, has the common bits
sdm845-xiaomi-beryllium.dts - use common dtsi, represent tianma model
sdm845-xiaomi-beryllium-ebbg.dts - new, use common dtsi, represent ebbg
variant.

These two approaches keep the existing dts valid even after the patch
and doesn't break build. But I wish I could rename the existing dts to
sdm845-xiaomi-beryllium-tianma.dts as its more appropriate. So I can do
something like:

3. Create new common dtsi, create new tianma variant dts, create new
ebbg variant dts. Finally, when changing the Makefile, delete the old
sdm845-xiaomi-beryllium.dts. We can explain in this commit, that it has
been renamed. This way, if someone git bisect, it can point to this
exact commit where it breaks and know that a rename has happened.

Kindly help me choosing an ideal approach or suggest a better approach.

> Regards,
> Bjorn

Regards,
Joel Selvaraj

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ