netdev - Re: [PATCH v2 1/2] r8169: fix RTL8111EVL EEE and green settings

lists.openwall.net		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, 21 Nov 2017 07:45:40 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     nic_swsd@...ltek.com, Chun-Hao Lin <hau@...ltek.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] r8169: fix RTL8111EVL EEE and green settings

Am 21.11.2017 um 02:34 schrieb Andrew Lunn:
> Hi Heiner
Hi Andrew,

> 
> Do you have access to the data sheet?
> 
Not to more recent ones. I only have two older data sheets for early
members of the rtl8169 family.

> I had a quick look through the driver. It would be nice to refactor it
> to follow the usual Linux conventions:
> 
> Turn the MDIO read/write functions into an MDIO bus driver.
> 
I thought the same when looking at this driver.
It's a nightmare to maintain a driver with almost 9.000 lines of code
and numerous "switch mac_id" clauses.
Not sure whether still members of this chip family are being
developed that we may have to add in future.

My first thought was to factor out support for the original 8169 family
(mac id <= 6) into a separate driver as first step as it differs
significantly from later members of the chip family (e.g. TBI support
in addition to MII).

> Move the PHY code into drivers/net/phy/realtek.c, and in the process,
> replace all the magic numbers with #defines.
> 
Yes, this definitely would be desirable. However I found that the
available datasheets for the external PHY's usually only document
the registers on page 0. All the magic settings on other pages often
are just copied from vendor drivers.
Or are there other, more comprehensive versions of the datasheets
being available under NDA?

> Do you have any interest in doing this?
> 
Would be a nice challenge. I'm willing to look into this if I can
get hold of the official datasheets.

>    Andrew
> 
Heiner