linux-kernel - Re: [PATCH] ARM: dts: am33xx: Remove unnecessary properties

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

Date:   Fri, 14 Dec 2018 07:18:25 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Felix Brack <fb@...c.ch>
Cc:     linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        bcousson@...libre.com, mpfj@...flow.co.uk, mark.rutland@....com,
        robh+dt@...nel.org, linux@...linux.org.uk,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: am33xx: Remove unnecessary properties

* Felix Brack <fb@...c.ch> [181214 15:12]:
> Hi Tony,
> 
> On 11.12.2018 17:43, Tony Lindgren wrote:
> > * Tony Lindgren <tony@...mide.com> [181211 16:36]:
> >> * Felix Brack <fb@...c.ch> [181210 05:25]:
> >>> Remove the unnecessary properties #address-cells and #size-cells
> >>> of node pinmux as there are no child-nodes with property reg.
> >>
> >> Applying into omap-for-v4.21/dt thanks.
> > 
> > Actually this currently conflicts with the pending
> > am33xx l4 ti-sysc changes, so let's wait on this
> > one to avoid causing merge conflicts between
> > branches.
> >
> Okay, I see. The changes introduced by my patch would then affect the
> new file am33xx-l4.dtsi instead of am33xx.dtsi

Yup, and I wanted to keep the am33xx-l4.dtsi in a separate
branch from the rest of the dts changes.

> > So dropping for now.
> >
> Will you "apply" my patch once the am33xx l4 ti-sysc changes are applied
> or do you expect me to send V2 patch (to be applied to the new
> am33xx-l4.dtsi) ?

I'd prefer you to send an updated version against
Linux next as the am33xx-l4.dtsi changes have been
in next for a while now. It is unlikely at this point
that they would not get merged, but I'd rather wait
a bit before applying to avoid mixing the two otherwise
independent branches :)

Regards,

Tony