[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c57adeeb-b51c-5ac8-776e-1ead474f7b48@codeaurora.org>
Date: Mon, 22 May 2017 16:19:26 -0500
From: Timur Tabi <timur@...eaurora.org>
To: Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>
Cc: Zefir Kurtisi <zefir.kurtisi@...atec.com>, netdev@...r.kernel.org,
David Miller <davem@...emloft.net>,
Manoj Iyer <manoj.iyer@...onical.com>, jhugo@...eaurora.org
Subject: Re: [PATCH 2/2] at803x: double check SGMII side autoneg
On 05/22/2017 04:10 PM, Florian Fainelli wrote:
> Even a module argument would be rejected. If you need platform/SoC
> specific behavior propagated down to the PHY driver, several options exist:
>
> - pass an agreed upon value for phy_flags to of_phy_connect() see
> drivers/net/ethernet/broadcom/tg3.c and
> drivers/net/ethernet/broadcom/genet/bcmgenet.c for instance and update
> the driver to act on that "flags" see drivers/net/phy/broadcom.c and
> drivers/net/phy/bcm7xxx.c
Will this work on ACPI systems as well? I call phy_connect_direct() instead
of of_phy_connect(). I see some drivers set phydev->dev_flags before
calling phy_connect_direct().
My concern is that this problem occurs only on an at8031 chip, so having my
network driver passing an at8031-specific flag seems out of place. What
happens if, on some other board, a different PHY is used, and that flag
means something else?
> - register a PHY fixup which is specific to the board/SoC, and have the
> PHY fixup do whatever is necessary for your platform (like setting
> specific registers)
Do you have an example of that?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists