[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170624140406.GL4875@lunn.ch>
Date: Sat, 24 Jun 2017 16:04:06 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Heiko Stuebner <heiko@...ech.de>
Cc: David Wu <david.wu@...k-chips.com>, davem@...emloft.net,
robh+dt@...nel.org, mark.rutland@....com, catalin.marinas@....com,
will.deacon@....com, olof@...om.net, linux@...linux.org.uk,
arnd@...db.de, f.fainelli@...il.com, peppe.cavallaro@...com,
alexandre.torgue@...com, huangtao@...k-chips.com,
hwg@...k-chips.com, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] net: phy: Add rockchip phy driver support
> hmm, we do have quite a number of non-net phys in the phy subsystem
> (DP, PCIe, ...) and given that the above would be CONFIG_ROCKCHIP_PHY
> in a global sense, sounds like it could make things confusing.
>
> So some addition sounds reasonable ... ROCKCHIP_ETH_PHY or so?
I follow you reasoning, but generic phy is the new kid on the
block. It is well established that Ethernet PHYs are called
<MANUFACTURER>_PHY.
If you do want to consider generic phy, the logical name would be
ROCKCHIP_PHY_PHY, since generic phy postfixes with _SATA, _USB, _PCIE,
etc. But that does leave an issues when we have an Ethernet PHY which
needs a generic PHY. In some sense, SERDES could be considered as
something supported by a generic PHY...
Andrew
Powered by blists - more mailing lists