linux-kernel - Re: [PATCH v2 01/10] dt-bindings: iio: pressure: honeywell,mprls0025pa.yaml fix

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]

Date: Sat, 30 Dec 2023 11:28:52 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Petre Rodan <petre.rodan@...dimension.ro>
Cc: linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Andreas Klinger <ak@...klinger.de>,
 Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
 <conor+dt@...nel.org>
Subject: Re: [PATCH v2 01/10] dt-bindings: iio: pressure:
 honeywell,mprls0025pa.yaml fix

On Wed, 27 Dec 2023 09:11:35 +0200
Petre Rodan <petre.rodan@...dimension.ro> wrote:

> Hello Cameron,
> 
> On Tue, Dec 26, 2023 at 04:28:39PM +0000, Jonathan Cameron wrote:
> > On Sun, 24 Dec 2023 16:34:46 +0200
> > Petre Rodan <petre.rodan@...dimension.ro> wrote:
> >   
> > > Define enum inside the honeywell,transfer-function property block.
> > > 
> > > Set the correct irq edge in the example block.
> > > Based on the datasheet, in table 13 on page 11:
> > > "End-of-conversion indicator: This pin is set high when a measurement
> > > and calculation have been completed and the data is ready to be
> > > clocked out"
> > > 
> > > Add description on End-of-conversion interrupt.
> > > 
> > > Signed-off-by: Petre Rodan <petre.rodan@...dimension.ro>
> > > Signed-off-by: Andreas Klinger <ak@...klinger.de>  
> > What's the relationship between Andreas and this patch?
> > 
> > Petre seems to have sent it so either Andreas should have a Co-authored-by or
> > should be the author... Or not there at all  
> 
> Andreas has written this driver as it is in the mainline tree right now and he
> is marked as a maintainer for it.
> A month back I told him about the enum off-by-one problem and also about my plan
> of adding more features to the driver.
> He was happy to accept my code and once I sent v1 of this patch to the list has
> asked to work together for the v2 you see here. This has helped with cleaning up
> the code. He requested the additional 'Signed-off-by' tag, but if you have a more
> explicit one I will happily use it. 'Co-developed-by' it is.

Yup, needs combination of Co-developed-by and a Sign off for this case as in
effect both of you wrote the code.

> 
> He also owns an i2c version of the sensor so he was able to make sure that the
> original half of the driver still works after my refactor, hence the 'Tested-by'
> tag in the last patch.

That's fine.

> 
> please tell me how do the 'fixes'/feature/improvement tags/keywords look like?
> are these to be added on the subject line, or should they reside near my
> 'Signed-off-by' inside the email body? I probably missed the documentation where
> these are covered :)
See https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst
for lots of detail.  The fixes tag has a particular format and goes in the main
tag block. Lots of examples in tree so can just take a look at the git history for
how to apply these rules in practice.

> 
> also, should I add a 'Reviewed-by:' you for 09/10 and 10/10 (the last two patches)?
No. Tags should be explicitly given.  I tend not to give RB for stuff I'll pick up
because they will have my SoB anyway as the person who applies the patches
and that includes reviewing.

In this case, Andreas asked for a tag to be included whereas I have not.

Jonathan


> 
> best regards,
> peter