Re: [PATCH 1/5] arm64: dts: sdm845-xiaomi-beryllium: rename beryllium.dts into beryllium-common.dtsi

[Joel Selvaraj]

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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

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