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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 29/10/2024 13:46, Laurent Pinchart wrote:
> (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@nxp.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.

I would be very happy to tell it to the managers, decision makers and
CEOs, but they avoid me. :/

Best regards,
Krzysztof