Thread (50 messages) 50 messages, 7 authors, 2017-07-02

Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

From: Chen-Yu Tsai <hidden>
Date: 2017-06-27 08:12:16
Also in: linux-arm-kernel, linux-devicetree, lkml

On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
[off-list ref] wrote:
On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
quoted
On 31/05/17 08:18, Corentin Labbe wrote:
quoted
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.
Hi,

I know I am a bit late with this, but while adapting the U-Boot driver
to the new binding I was wondering about the internal PHY detection:


So here you seem to deduce the usage of the internal PHY by the PHY
interface specified in the DT (MII = internal, RGMII = external).
I think I raised this question before, but isn't it perfectly legal for
a board to use MII with an external PHY even on those SoCs that feature
an internal PHY?
On the first glance that does not make too much sense, but apart from
not being the correct binding to describe all of the SoCs features I see
two scenarios:
1) A board vendor might choose to not use the internal PHY because it
has bugs, lacks features (configurability) or has other issues. For
instance I have heard reports that the internal PHY makes the SoC go
rather hot, possibly limiting the CPU frequency. By using an external
MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
2) A PHY does not necessarily need to be directly connected to
magnetics. Indeed quite some boards use (RG)MII to connect to a switch
IC or some other network circuitry, for instance fibre connectors.

So I was wondering if we would need an explicit:
      allwinner,use-internal-phy;
boolean DT property to signal the usage of the internal PHY?
Alternatively we could go with the negative version:
      allwinner,disable-internal-phy;

Or what about introducing a new "allwinner,internal-mii-phy" compatible
string for the *PHY* node and use that?

I just want to avoid that we introduce a binding that causes us
headaches later. I think we can still fix this with a followup patch
before the driver and its binding hit a release kernel.

Cheers,
Andre.
I just see some patch, where "phy-mode = internal" is valid.
I will try to find a way to use it
Can you provide a link?

I'm not a fan of using phy-mode for this. There's no guarantee what
mode the internal PHY uses. That's what phy-mode is for.

In any case, we should fix this before 4.13 is released.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help