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]
Message-ID: <20190220210127.GU15711@atomide.com>
Date:   Wed, 20 Feb 2019 13:01:27 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     David Miller <davem@...emloft.net>
Cc:     grygorii.strashko@...com, kishon@...com, robh+dt@...nel.org,
        netdev@...r.kernel.org, nsekhar@...com,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel
 driver

* David Miller <davem@...emloft.net> [190220 20:42]:
> From: Tony Lindgren <tony@...mide.com>
> Date: Wed, 20 Feb 2019 12:33:26 -0800
> 
> > * David Miller <davem@...emloft.net> [190220 19:23]:
> >> From: Grygorii Strashko <grygorii.strashko@...com>
> >> Date: Wed, 20 Feb 2019 17:25:19 +0200
> >> 
> >> > Deprecate cpsw-phy-sel driver as it's been replaced with new
> >> > TI phy-gmii-sel PHY driver.
> >> > 
> >> > Signed-off-by: Grygorii Strashko <grygorii.strashko@...com>
> >> 
> >> Acked-by: David S. Miller <davem@...emloft.net>
> > 
> > Thanks for the ack, but actually I'd prefer you to pick
> > this patch at some future date. I suggest Grygorii just
> > repost this one after v5.1-rc1.
> 
> It's so much easier if you group this with those DT changes, they
> logically belong together as well and it helps someone reading
> the changes in the tree also if they are side by side.

I agree that a group of patches should go together in
most cases.

> Why don't you want to integrate this with them?

Because the arm-soc tree wants dts changes separately in
general. The dts changes are considered firmware describing
hardware. And it makes it possible to split the arm-soc pile
of patches into multiple pull requests. In theory there
should be no dependency between dts changes and driver
changes, but in reality that's not always the case :)

What I can do is set up a separate branch with just this
patch on top of the dts changes that the arm-soc guys can
then merge towards the end of the merge cycle. If that
works for you, let me know and I'll do it.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ