netdev - Re: [PATCH v2 1/1] alx: add a simple AR816x/AR817x device driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1371818751.8771.26.camel@deadeye.wl.decadent.org.uk>
Date:	Fri, 21 Jun 2013 13:45:51 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	netdev@...r.kernel.org, mcgrof@...not-panic.com, kvalo@...rom.com,
	adrian.chadd@...il.com, Johannes Stezenbach <js@...21.net>
Subject: Re: [PATCH v2 1/1] alx: add a simple AR816x/AR817x device driver

On Fri, 2013-06-21 at 00:09 +0200, Johannes Berg wrote:
> On Thu, 2013-06-20 at 22:58 +0100, Ben Hutchings wrote:
> 
> > > Yeah, no idea, just copy/paste. Lots of drivers seem to do this, for no
> > > particular reason it seems?
> > 
> > As I said, most of them select MII which depended on NET_CORE, so they
> > really did need to select NET_CORE too.  I've now fixed that.
> 
> Ok, I can kick out the 'select NET_CORE' here anyway as MDIO doesn't
> need it. Or did you want to do a more general cleanup on this, then I'll
> leave it to you?

See commit a1606c7dc64d8449676d7e840dd2cd0c4e0a0c57.

[...]
> > > > I couldn't find where auto-negotiated flow control is programmed after
> > > > the link comes up.  Maybe it isn't?
> > > 
> > > No idea, sorry. I clearly have a lot to learn about how ethernet devices
> > > typically work, should it be programmed?
> > 
> > When autoneg is enabled, the PHY should perform autonegotiation whenever
> > it detects an electrical link; if successful it will configure itself
> > for the negotiated link speed and duplex, and trigger a link interrupt.
> > But unless there is firmware running on the controller, the driver
> > usually has to read PHY registers to get the result and then configure
> > the MAC speed, duplex and flow control accordingly.
> 
> Ok, makes sense. I guess a bunch of these things are done in
> alx_post_phy_link() or so, but yeah I don't see flow control either.
> 
> How would I even test that? Find random devices that have flow control?
> I don't think I have anything that would be programmable, unless I don't
> know about it being so :-)

Most Ethernet controllers seem to support flow control.  Though, in a
quick test, the e1000e driver on my laptop never seems to turn off Pause
advertising!

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)