linux-kernel - Re: [PATCH 1/5] dt-bindings: media: i2c: Add bindings for OX05B1S sensor driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241029124609.GP22600@pendragon.ideasonboard.com>
Date: Tue, 29 Oct 2024 14:46:09 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Mirela Rabulea <mirela.rabulea@....com>, mchehab@...nel.org,
	sakari.ailus@...ux.intel.com, hverkuil-cisco@...all.nl,
	laurentiu.palcu@....com, robert.chiras@....com,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	LnxRevLi@....com, kieran.bingham@...asonboard.com,
	hdegoede@...hat.com, dave.stevenson@...pberrypi.com,
	mike.rudenko@...il.com, alain.volmat@...s.st.com,
	julien.vuillaumier@....com, alice.yuan@....com,
	devicetree@...r.kernel.org
Subject: Re: [PATCH 1/5] dt-bindings: media: i2c: Add bindings for OX05B1S
 sensor driver

(CC'ing the devicetree mailing list)

On Tue, Oct 29, 2024 at 01:28:51PM +0100, Krzysztof Kozlowski wrote:
> On 29/10/2024 13:21, Laurent Pinchart wrote:
> > On Tue, Oct 29, 2024 at 01:15:46PM +0100, Krzysztof Kozlowski wrote:
> >> On 29/10/2024 13:10, Laurent Pinchart wrote:
> >>> On Tue, Oct 29, 2024 at 07:14:28AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 28/10/2024 20:06, Mirela Rabulea wrote:
> >>>>> Add bindings for OX05B1S sensor driver
> >>>>>
> >>>>> Signed-off-by: Mirela Rabulea <mirela.rabulea@....com>
> >>>>
> >>>> <form letter>
> >>>> Please use scripts/get_maintainers.pl to get a list of necessary people
> >>>> and lists to CC. It might happen, that command when run on an older
> >>>> kernel, gives you outdated entries. Therefore please be sure you base
> >>>> your patches on recent Linux kernel.
> >>>>
> >>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> >>>> people, so fix your workflow. Tools might also fail if you work on some
> >>>> ancient tree (don't, instead use mainline) or work on fork of kernel
> >>>> (don't, instead use mainline). Just use b4 and everything should be
> >>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
> >>>> patches to the patchset.
> >>>>
> >>>> You missed at least devicetree list (maybe more), so this won't be
> >>>> tested by automated tooling. Performing review on untested code might be
> >>>> a waste of time.
> >>>>
> >>>> Please kindly resend and include all necessary To/Cc entries.
> >>>> </form letter>
> >>>>
> >>>> Binding also looks very different than all other devices, so re-write it
> >>>> starting from EXISTING GOOD bindings. Not some downstream stuff.
> >>>
> >>> Krzysztof, please point to a good example when making this kind of
> >>> comment.
> >>
> >> Anything recently added. Git log tells which files were recently added.
> > 
> > If the review comment is a copy&paste (given that you review lots of
> > bindings and constantly have to repeat the same things, that would make
> > sense), expanding it with that information for future reviews could help
> > patch authors. Thanks for considering it, it would be much appreciated.
> 
> Sorry, but that's not the point. You do not take 10 yo, unmaintained
> driver and use it as template for your new one. Instead you rather take
> something recent or something which you know is correct. Same with bindings.

I wouldn't know for sure which driver or binding was used as a starting
point. My point was unrelated to this particular patch series. I think
that including clear information in ready-made answers will help
everybody. It will tell the submitters what they need to know, it will
avoid this kind of conversation being repeated, and it could even in the
end increase the quality of submissions. Even better, it won't cost
anything to add it to answer templates.

> NXP is not a small company which does not know how to use Linux or how
> to upstream stuff. This is not individual's contribution, where one does
> not have colleagues or 3 billions USD of revenue behind, to be able to
> get some internal help prior sending something downstream.
> 
> They can spend something out of these 3 billions of revenue or 700
> millions of net income to hire you guys or any other open-source
> company, if basics of upstreaming are unknown.
>
> That's the comment I was giving about NXP since a year. Some things
> around SoC improved, some things from this unit of NXP here did not
> change at all.

If I were on the receiving end of this, as an individual developer, I
would consider it very patronizing and insulting. Treating the authors
of contributions you don't consider as good enough in such a harsh way
will not improve the situation, and will drive people away. You may be
frustrated by some companies, but this kind of comment will not help.
Please soften your tone towards individual developers, they're not
punching balls on which to dump frustration and anger. Firm and polite
will work better than lashing out.

> So again, it's not about me giving them more things. They will keep
> ignoring it over and over, because that's how big companies sometimes
> behave. You know, community people work for free, right?

-- 
Regards,

Laurent Pinchart