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:	Sat, 26 Mar 2016 00:51:31 +0100
From:	Phil Sutter <phil@....cc>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Corcodel Marian <asd@...ian1000.go.ro>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3.16]r8169:  Correct value from speed 10 on
 MII_BMCR

On Fri, Mar 25, 2016 at 11:53:25PM +0100, Francois Romieu wrote:
> Phil Sutter <phil@....cc> :
> [...]
> > Your patch submissions are getting better, also good to see you're
> > finally using git-send-email. A few things need to be corrected though:
> > 
> 
> #define BMCR_RESV               0x003f  /* Unused...                   */
> #define BMCR_SPEED1000          0x0040  /* MSB of Speed (1000)         */
> #define BMCR_CTST               0x0080  /* Collision test              */
> #define BMCR_FULLDPLX           0x0100  /* Full duplex                 */
> #define BMCR_ANRESTART          0x0200  /* Auto negotiation restart    */
> #define BMCR_ISOLATE            0x0400  /* Isolate data paths from MII */
> #define BMCR_PDOWN              0x0800  /* Enable low power state      */
> #define BMCR_ANENABLE           0x1000  /* Enable auto negotiation     */
> #define BMCR_SPEED100           0x2000  /* Select 100Mbps              */
> #define BMCR_LOOPBACK           0x4000  /* TXD loopback bits           */
> 
> BMCR_SPEED100 apart, *all* these bits are now set.
> 
> It does not make much sense.

I presumed that already, but didn't care to check myself so instead
ignored the actual code change. Thanks for pointing out the futility of
the whole thing. :)

> > Also detailed instructions on how to trigger the problem you are fixing
> > for would be good. In detail: Which specific hardware was used, in which
> > situation did the problem occur, how did it behave in that situation and
> > what was the expected behaviour?
> 
> Been there. Such requests are usually left unanswered. :o(

That's my impression from following the (somewhat amusing) former
threads, too. I was merely impressed by the sheer quality of this patch
in comparison to previous ones. Speaking of which, the presented
tenacity certainly earns some respect.

Cheers, Phil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ