[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180217233442.GA24375@lunn.ch>
Date: Sun, 18 Feb 2018 00:34:42 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Paul Burton <paul.burton@...s.com>
Cc: netdev@...r.kernel.org, Hassan Naveed <hassan.naveed@...s.com>,
Matt Redfearn <matt.redfearn@...s.com>,
"David S . Miller" <davem@...emloft.net>, linux-mips@...ux-mips.org
Subject: Re: [PATCH v5 02/14] net: pch_gbe: Pull PHY GPIO handling out of
Minnow code
> Note that this is a driver which is already in mainline, and I didn't
> write it. Claiming that *I* am doing this all wrong is a bit of a
> stretch - all this patch does is make small changes to some existing
> code, which only tangentially relates to a PHY driver, such that it
> ceases to be specific to a single platform.
Hi Paul
I would so you are doing it all wrong for the reset GPIO.
> Even if that is true, rewriting the driver's PHY handling would be a
> very separate change to the changes this series make which allow this
> driver to work on a platform besides the Minnowboard. The *only* thing
> this series does relating to the PHY is allow the reset GPIO to be
> handled properly - rewriting the existing PHY handling is beyond it's
> scope.
Well, you are adding a device tree binding, which needs to be
supported forever. This is going to make things messy in the future
when you do such a cleanup that you follow the PHY binding, in that
you have to handle both what you add here, and the official PHY
binding.
I would prefer that for the moment, you drop the PHY binding patches
in this series. That is what i object to the most. Adding an MDIO
driver and using the standard PHY driver for this PHY is all
internal. You can change that anytime. But adding a binding means an
ABI.
Andrew
Powered by blists - more mailing lists