From: Heiner Kallweit <hkallweit1@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
Andrew Lunn <andrew@lunn.ch>, David Miller <davem@davemloft.net>,
Realtek linux nic maintainers <nic_swsd@realtek.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 0/3] r8169: use rtl821x_modify_extpage exported from Realtek PHY driver
Date: Wed, 13 Nov 2019 07:25:57 +0100 [thread overview]
Message-ID: <3e605bec-f0ec-9c22-e2c8-58bf2587ba92@gmail.com> (raw)
In-Reply-To: <6706c94a-2252-c0b2-6dcb-511f0b3ad2a6@gmail.com>
On 13.11.2019 05:13, Florian Fainelli wrote:
>
>
> On 11/12/2019 1:22 PM, Heiner Kallweit wrote:
>> Certain Realtek PHY's support a proprietary "extended page" access mode
>> that is used in the Realtek PHY driver and in r8169 network driver.
>> Let's implement it properly in the Realtek PHY driver and export it for
>> use in other drivers like r8169.
>>
>> Heiner Kallweit (3):
>> net: phy: realtek: export rtl821x_modify_extpage
>> r8169: use rtl821x_modify_extpage
>> r8169: consider new hard dependency on REALTEK_PHY
>>
>> drivers/net/ethernet/realtek/Kconfig | 3 +-
>> drivers/net/ethernet/realtek/r8169_main.c | 41 +++++++++--------------
>> drivers/net/phy/realtek.c | 36 ++++++++++++--------
>> include/linux/realtek_phy.h | 8 +++++
>> 4 files changed, 46 insertions(+), 42 deletions(-)
>
> The delta is not that impressive and this creates not quite a layering
> violation, but some really weird inter dependency if nothing else. Could
> we simply move all the PHY programming down the PHY driver instead or is
> this too cumbersome/fragile to do right now?
>
The Realtek chips come with integrated MAC and PHY, so the dependency
reflects the physical structure. Moving all PHY configuration to the
PHY driver would be best of course, but:
- Even though few chip versions use the PHY ID of a PHY that exists
also standalone, the configuration sequence differs. So it seems
they differ.
- From a certain chip version the PHY ID is always the same:
Realtek OUI, but model and revision number being zero. Means we'd have
to intercept the PHY ID reads and return artificial PHY ID's.
- PHY config sequence partially includes efuse reads from MAC registers,
see rtl8168d_1_hw_phy_config. OK, maybe we could read the efuse first,
and hand over the value to the PHY driver via PHY driver private data
structure.
Heiner
prev parent reply other threads:[~2019-11-13 6:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-12 21:22 [PATCH net-next 0/3] r8169: use rtl821x_modify_extpage exported from Realtek PHY driver Heiner Kallweit
2019-11-12 21:23 ` [PATCH net-next 1/3] net: phy: realtek: export rtl821x_modify_extpage Heiner Kallweit
2019-11-13 11:24 ` kbuild test robot
2019-11-12 21:24 ` [PATCH net-next 2/3] r8169: use rtl821x_modify_extpage Heiner Kallweit
2019-11-12 21:25 ` [PATCH net-next 3/3] r8169: consider new hard dependency on REALTEK_PHY Heiner Kallweit
2019-11-13 3:56 ` [PATCH net-next 0/3] r8169: use rtl821x_modify_extpage exported from Realtek PHY driver David Miller
2019-11-13 4:08 ` David Miller
2019-11-13 4:13 ` Florian Fainelli
2019-11-13 6:25 ` Heiner Kallweit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e605bec-f0ec-9c22-e2c8-58bf2587ba92@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).