Message-ID: <eb4327d0-b31b-b6ea-e0d3-d5cff3508f39@postmarketos.org>
Date:   Sat, 6 Aug 2022 15:58:17 +0100
From:   Caleb Connolly <kc@...tmarketos.org>
To:     Tom Fitzhenry <tom@...-fitzhenry.me.uk>, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, heiko@...ech.de
Cc:     megi@....cz, martijn@...xit.nl, ayufan@...fan.eu,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add initial support for
 Pine64 PinePhone Pro



On 06/08/2022 03:37, Tom Fitzhenry wrote:
> On 6/8/22 12:10, Caleb Connolly wrote:
>> I was surprised to see this series, and this patch especially.
>> An almost ready to submit version of this patch with considerably more 
>> functionality has been sat around for a while but unfortunately never sent [1].
> 
> Firstly, thank you for your review!
> 
> I'm not sure why that other patch series has never been submitted. It was 
> prepared 3 months ago (unbeknownst to me, at the time of v1), but since then has 
> not been submitted.
> 
> I would feel uncomfortable submitting that patch series, since I am not familiar 
> with parts of the full DT. In time I intend to be, but for now I think we'd 
> benefit from having a base DT mainlined, on top of which we can iterate and 
> parallelise.
> 
>> According to the link below (and my own knowledge of PPP development) Kamil is 
>> the original author of this patch, both Kamil and Martijn created the initial 
>> version of the devicetree. Given that you're using their work as a base, 
>> Kamil's authorship should be respected in the patch you submit.
> 
> I agree authorship is important, and thus Kamil, Martijn and Megi are listed as 
> Co-developed-by in this patch.
To be clear, by authorship I mean literally the author of the patch, the 
previous patch in this series was created by Samuel and you left his authorship 
intact - it has "From: Samuel Dionne-Riel <samuel@...nne-riel.com>" at the top, 
so when a maintainer picks it up and it ends up in Linux, anyone looking at it 
will see that he was the author of the patch.

This patch is from you, there is no From: tag overriding it, and the diffstat in 
your cover letter shows you as the author. Whilst you have obviously made some 
heavy changes to this patch, it isn't your original work as you state yourself 
in the commit message. Authorship should be attributed to Kamil as they are the 
author of the earliest version of this patch we have.
> 
>> Their original patch [2] contained SoBs from them and Martijn, those are both 
>> missing below. Both of their signed-off-by tags should be added before this 
>> patch hits the mailing list, and the same for Ondrej. The order also seems 
>> wrong (Ondrej should be last before you).
> 
> Yes, this patch's acceptance is blocked until all Co-developed-by authors 
> (Kamil, Martjin, Megi) provide their Signed-off-by to this patch.
You should obtain SoBs from Co-developers /before/ sending this patch upstream, 
this indicates that everyone is on board and that the patch has some sensible 
history. The mailing list isn't the place to ask your co-developers to sign off 
a patch after you've made extensive changes to it.

I missed the following points in my original email:

Please read the documentation on modifying patches [1] as it applies here, and 
add a comment before your SoB explaining your changes, something like

[tom: strip down to minimal booting DT for initial support]

This way the history of the patch is preserved properly for anyone looking back 
at it in the future. In a similar vein, replace the external git links with 
links to exact commits so they don't degrade over time.
> 
>> Support for the volume keys, accelerometer, magnetometer, GPIO LEDs, 
>> touchscreen, modem codec and audio support are all missing here, but they're 
>> included in the patches you referenced. In their current state (see Martijn's 
>> commit [1] or my 5.19 rebase [3]) the DT for these components has been worked 
>> on by several people, tested by the larger user community, and are already 
>> supported in mainline. It seems strange not to include them and just leads to 
>> a bunch of extra busywork to add them back later. It's easy enough to drop any 
>> of these nodes during review if they become an issue.
> 
> To keep this patch series light and easy-to-review, I'd be keen to keep it as
fwiw, a few extra nodes now is a lot easier to review than a bunch of individual 
small patches later. But yes, better to get this done in some form than not at all.
> small as possible for now. This DT is >18 months old out-of-tree (across 
> multiple repos), so I think this minimal DT being mainlined is an improvement 
> over the status quo.
definitely, it'll be nice to start to see some upstream story for the famed 
"linux phone" ;)

[1]: https://www.kernel.org/doc/html/latest/maintainer/modifying-patches.html
> 
> The existing work that the community has done will still be useful, albeit in 
> future patch series. This DT just allows that future work to be done 
> iteratively, and in parallel.
> 
>> With that being said, I've left some feedback below, with it addressed and the 
>> authorship/SoB situation sorted out:
>>
>> Reviewed-by: Caleb Connolly <kc@...tmarketos.org>
> 
> Thank you for your comments, I appreciate your review! I will ensure v3 
> addresses those.

Powered by blists - more mailing lists