netdev - Re: net: macb: fail when there's no PHY

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]

Message-ID: <66c0a032-4d20-69f1-deb4-6c65af6ec740@gmail.com>
Date:   Thu, 21 Sep 2017 13:05:57 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Grant Edwards <grant.b.edwards@...il.com>, netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY

On 09/21/2017 12:59 PM, Grant Edwards wrote:
> Several years back (circa 2.6.33) I had to hack up macb.c to work on
> an at91 board that didn't have a PHY connected to the macb controller.
> Now I might need to get a recent kernel version running on that board.
> 
> It looks like the macb driver still can't handle boards that don't
> have a PHY.  Is that correct?

Not since:

dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link
node support")

> 
> What's the right way to deal with this?

Declaring a fixed PHY that will present an emulated link UP, with a
fixed speed/duplex etc. is the way to go.

> 
> With the older macb driver, I ended up adding code to macb.c that
> presented a "fake" PHY that discarded MDIO writes and returned some
> hard-wired values for MDIO reads.  That seemed like a pretty ugly way
> to deal with the situation, so I never bothered to submit a patch.
> 

Yeah, no :)
-- 
Florian