[PATCH v2 5/6] dt-bindings: clock: drop NUM_CLOCKS define for EN7581

[Tom Rini]

On Tue, Apr 01, 2025 at 05:27:30PM +0200, Krzysztof Kozlowski wrote:
> On 01/04/2025 16:44, Tom Rini wrote:
> > On Thu, Mar 27, 2025 at 03:58:52PM +0100, Krzysztof Kozlowski wrote:
> >> On 27/03/2025 15:50, Christian Marangi wrote:
> >>> On Thu, Mar 27, 2025 at 03:43:47PM +0100, Krzysztof Kozlowski wrote:
> >>>> On 14/03/2025 19:59, Christian Marangi wrote:
> >>>>> Drop NUM_CLOCKS define for EN7581 dts/upstream/src/include. This is not a binding and
> >>>>> should not be placed here. Value is derived internally in the user
> >>>>> driver.
> >>>>>
> >>>>> Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
> >>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> >>>> Please drop my Ack. I have never acked such patch for uboot. If I did,
> >>>> it was by mistake - probably you CC-ed me for some reason.
> >>>>
> >>>
> >>> Some explaination, uboot introduced the concept of upstream where they
> >>> "import" linux patch for dts and dt-bindings.
> >>
> >> I expected OF_UPSTREAM to be taking the sources, not patches.
> >>
> >>>
> >>> This and the other patch are the exact upstream patch with only the path
> >>> changed so I keep all the patch commit message with tags and added the
> >>>
> >>> [ upstream commit ] thing.
> >>>
> >>> Hope Tom can better suggest how this should be done. You were CC
> >>> probably because the git send-email included you as present in the
> >>> different tags.
> >>
> >> Well, Ack is still not valid because I did not Ack exactly that change.
> >> It does not matter for the ack, but for Reviewed-by it would matter,
> >> because it is a statement (of oversight...). I cannot control what you
> >> put into patches taken out of kernel, but at least do not Cc me on that.
> > 
> > In specifics, yes, we should update doc/develop/devicetree/control.rst
> > and maybe doc/develop/sending_patches.rst to use --suppress-cc=all for
> > dts/upstream.
> > 
> > But in general, what do you expect people to be doing with content from
> > devicetree-rebasing? We're doing some direct cherry-picks in between
> > merging of the tags. I think it would be weird to be dropping the tags
> > and un-attributing peoples work.
> 
> 
> I rather expected something like how kernel is importing dtc. You just
> list the commits you get. If you want the full git history, then I would
> expect simple git submodule. In both cases there will be no such patches
> on the lists.
> 
> For the Ack it does not matter, but I would feel uncomfortable if people
> were sending stripped and modified patches with my Rb tag.

I guess I'm confused. Looking at
https://patchwork.ozlabs.org/project/uboot/patch/20250314185941.27834-6-ansuelsmth@gmail.com/
we're doing the normal thing of havig "[ upstream commit <sha>]" after
the imported log. When I merge the subtree and tag it indeed gives what
you're expecting too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250401/14300541/attachment.sig>