[PATCH] dt-bindings: mfd: Use full path to other schemas

Lee Jones lee at kernel.org
Fri May 3 01:41:39 PDT 2024


On Fri, 03 May 2024, Krzysztof Kozlowski wrote:

> On 03/05/2024 10:24, Lee Jones wrote:
> > On Fri, 03 May 2024, Krzysztof Kozlowski wrote:
> > 
> >> On 03/05/2024 10:08, Tudor Ambarus wrote:
> >>>
> >>>
> >>> On 5/3/24 08:21, Krzysztof Kozlowski wrote:
> >>>>  .../bindings/mfd/samsung,s2mpa01.yaml         |  2 +-
> >>>>  .../bindings/mfd/samsung,s2mps11.yaml         | 12 ++---
> >>>>  .../bindings/mfd/samsung,s5m8767.yaml         |  4 +-
> >>>
> >>> Reviewed-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>
> >> So this should be Ack. You cannot review part of the patch ("I have
> >> carried out a technical review of this patch...").
> >> https://elixir.bootlin.com/linux/v6.8-rc5/source/Documentation/process/submitting-patches.rst
> > 
> > Reviewed-by is totally appropriate here.
> 
> Submitting patches is clear on that:
> "A Reviewed-by tag is a statement of opinion that the patch is an"
> Not "the patch or part of patch"
> 
> And ack:
> " It is a record that the acker has at least reviewed the patch ....
> Acked-by: does not necessarily indicate acknowledgement of the entire
> patch."
> 
> So no, reviewing part of the patch means you Ack it. Especially that in
> git log the Rb tag will suggest entire patch was reviewed, while it was
> not true. Review of 80% of patch did not happen.

I read this differently.

I don't see any reason why only a relevant part of a patch can't be
covered by a Reviewed-by.  It doesn't explicitly say that you can't do
that.  If the statement meant that, it would have used more inclusive
language like "whole patch" or "all of the patch", but it refrains from
doing so.

My interpretation is that the explicitness of the Acked-by statement is
to provide extra protection to Maintainers that only review and provide
Acks for chunks that they are responsible for.

Whatever the case, this is a pretty nitpicky point.

-- 
Lee Jones [李琼斯]



More information about the linux-arm-kernel mailing list