Re: [PATCH v3 3/4] arm64: dts: qcom: Add base QDU1000/QRU1000 DTSIs

[Rob Herring]

On Fri, Nov 4, 2022 at 4:32 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxx> wrote:
> On 04/11/2022 05:05, Trilok Soni wrote:
> > + Adding Konrad, Bjorn is already there in this email
> >
> > On 11/3/2022 2:13 PM, Melody Olvera wrote:
> >>
> >>
> >> On 11/2/2022 9:24 AM, Krzysztof Kozlowski wrote:
> >>> On 31/10/2022 17:49, Melody Olvera wrote:
> >>>>
> >>>> On 10/27/2022 8:21 AM, Krzysztof Kozlowski wrote:
> >>>>> On 26/10/2022 16:04, Melody Olvera wrote:
> >>>>>> Add the base DTSI files for QDU1000 and QRU1000 SoCs, including base
> >>>>>> descriptions of CPUs, GCC, RPMHCC, QUP, TLMM, and
> >>>>>> interrupt-controller
> >>>>>> to boot to shell with console on these SoCs.

[...]

> >>>> Not sure how much two-sense I have for the conversation at large,
> >>>> but generally I agree with Doug's
> >>>> point in the first paragraph. Pulls for this soc are consistent
> >>>> across boards so I don't think it makes
> >>>> sense to move them to the board files here. I vote that these stay
> >>>> here.
> >>> I would be great if Konrad and Bjorn shared their opinion on this...
> >>> but
> >>> wait, you did not Cc all maintainers... Eh.
> >> I'm not sure why this is being brought up again; we've already
> >> discussed this here
> >> https://lore.kernel.org/all/9707bf67-1b22-8a77-7193-fc909b4f49de@xxxxxxxxxxx/

A bit excessive, yes. If it's just a discussion and the issue has
already been raised, add the people and move on. OTOH, imagine having
to mention the same things multiple times a day in reviews. It is
tiring.

> >> Would you like to discuss this issue here, on the next version, or
> >> not at all?
> >>
> >> On a side note, I'm uncomfortable with how our continued interactions
> >> are going
> >> and do not believe this to be conductive to continued collaboration.
> >> I would ask that
> >> we keep our correspondence polite and professional moving forward.
> >
> > I have added Konrad and Bjorn is already there on the thread. Our
> > understanding is that CCing maintainers comment is for next patch
> > series after this one.
>
> BTW: you can feed git send-email with
> --cc-cmd='./scripts/get_maintainer.pl --norolestats' and
>
> it'll pick the right people for you (most of the time, anyway).

That uses git history which doesn't really work well IMO being on the
receiving end of those. I would suggest something like this in your
.gitconfig:

[sendemail.linux]
        tocmd =" scripts/get_maintainer.pl --nogit --nogit-fallback --nol"
        cccmd ="scripts/get_maintainer.pl --nogit --nogit-fallback --nom"
        confirm = always

Then you do just 'git send-email --identity=linux ...'

Or use b4 as it does the above and works better for series.

> > Bjorn, please check and comment on above? If requires we should start
> > writing the guidelines for MSM boards since lot of comments are based
> > on the experience or knowledge in the community Vs caught by tools -
> > so it is easy to be missed by developers submitting new boards. Thoughts?

Some internal review or training for new contributors is needed IMO.
Some companies are required to have an known/experienced kernel
developer signoff on patches before they are submitted. I don't think
you want to get to that point.

> Big yes! Some of the points should probably even be raised wrt the DT
> spec itself, such as property order.

Ideally, we should only be providing comments that can be referenced
to documentation (if the tooling can't address it). In this case, I
don't think the DT spec would be the right place property order. It's
just a convention for the schema format. However, often the
documentation we do have already isn't followed, so I'm not too
motivated to add more.

Rob