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]
Message-ID: <20181214151825.GU6707@atomide.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ