lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 7 May 2019 19:37:43 +0200
From:   Heiner Kallweit <>
To:     Martin Blumenstingl <>,
        Serge Semin <>
Cc:     Vladimir Oltean <>,
        Florian Fainelli <>,
        Andrew Lunn <>,
        "David S. Miller" <>,
        Serge Semin <>,
        netdev <>,
Subject: Re: [PATCH v2 2/2] net: phy: realtek: Change TX-delay setting for
 RGMII modes only

On 06.05.2019 19:21, Martin Blumenstingl wrote:
> Hi Serge,
> On Mon, May 6, 2019 at 4:39 PM Serge Semin <> wrote:
> [...]
>>> the changes in patch 1 are looking good to me (except that I would use
>>> phy_modify_paged instead of open-coding it, functionally it's
>>> identical with what you have already)
>> Nah, this isn't going to work since the config register is placed on an extension
>> page. So in order to reach the register first I needed to enable a standard page,
>> then select an extended page, then modify the register bits.
> I'm probably missing something here. my understanding about
> phy_modify_paged is that it is equal to:
> - select extension page
> - read register
> - calculate the new register value
> - write register
> - restore the original extension page
What maybe causes the confusion: Realtek has two kinds of pages.
First there is the following, let's call it simple page:
You select a page via register 0x1f and then access the paged register.

Then there are extended pages. First you select a page via register 0x1f,
then the extended page via register 0x1e, and then the paged register.

> if phy_modify_paged doesn't work for your use-case then ignore my comment.
> [...]
>>>> (Martin, I also Cc'ed you in this discussion, so if you have anything to
>>>> say in this matter, please don't hesitate to comment.)
>>> Amlogic boards, such as the Hardkernel Odroid-C1 and Odroid-C2 as well
>>> as the Khadas VIM2 use a "RTL8211F" RGMII PHY. I don't know whether
>>> there are multiple versions of this PHY. all RTL8211F I have seen so
>>> far did behave exactly the same.
>>> I also don't know whether the RX delay is configurable (by pin
>>> strapping or some register) on RTL8211F PHYs because I don't have
>>> access to the datasheet.
>>> Martin
>> Ok. Thanks for the comments. I am sure the RX-delay is configurable at list
>> via external RXD pin strapping at the chip powering up procedure. The only
>> problem with a way of software to change the setting.
>> I don't think there is going to be anyone revealing that realtek black boxed
>> registers layout anytime soon. So as I see it it's better to leave the
>> rtl8211f-part as is for now.
> with the RTL8211F I was not sure whether interrupt support was
> implemented correctly in the mainline driver.
> I asked Realtek for more details:
> initially they declined to send me a datasheet and referred me to my
> "partner contact" (which I don't have because I'm doing this in my
> spare time).
> I explained that I am trying to improve the Linux driver for this PHY.
> They gave me the relevant bits (about interrupt support) from the
> datasheet (I never got the full datasheet though).
Same with me for the r8169 driver: They answer single questions quite
exact and fast, but no chance to get a datasheet or errata even for
10 yrs old chips.

> if you don't want to touch the RTL8211F part for now then I'm fine
> with that as well
> Regards
> Martin

Powered by blists - more mailing lists