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
