netdev - Re: [PATCH 3/5] e1000e: do not toggle LANPHYPC value bit when PHY reset is blocked

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: <20141215121639.GB28701@1wt.eu>
Date:	Mon, 15 Dec 2014 13:16:39 +0100
From:	Willy Tarreau <w@....eu>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:	Zhu Yanjun <zyjzyj2000@...il.com>, netdev@...r.kernel.org,
	Zhu Yanjun <Yanjun.Zhu@...driver.com>,
	Bruce Allan <bruce.w.allan@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH 3/5] e1000e: do not toggle LANPHYPC value bit when PHY reset is blocked

Hello,

On Mon, Dec 15, 2014 at 03:01:48PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/15/2014 11:39 AM, Zhu Yanjun wrote:
> 
> >2.6.x kernels require a similar logic change as commit b7d6e335
> >[e1000e: do not toggle LANPHYPC value bit when PHY reset is blocked]
> >introduces for newer kernels.
> 
>    Hm, so is this patch to 2.6.x-stable kernels or a recent kernel?
> If the former, you should follow the rules in 
> Documentation/stable_kernel_rules.txt.

I don't see anything there that does not comply with the rules. This
patchset looks fine and acceptable to me, I'll just wait a bit so that
if either Jeff or Bruce rejects it I respect their wish.

However you just made me realize that I can't find commit b7d6e335.
Zhu, please double-check that this commit (or an equivalent) was merged
upstream, *this* it a prerequisite for going into -stable.

> >When PHY reset is intentionally blocked on 82577/8/9, do not toggle the
> >LANPHYPC value bit (essentially performing a hard power reset of the
> >device) otherwise the PHY can be put into an unknown state.
> 
> >Cleanup whitespace in the same function.
> 
> >[yanjun.zhu: whitespace remains unchanged]
> 
> >Signed-off-by: Bruce Allan <bruce.w.allan@...el.com>
> 
>    So, is this your patch, or Bruce's? If the latter, you should add:
> 
> From: Bruce Allan <bruce.w.allan@...el.com>
> 
> at the start of the change log.
>
> >Tested-by: Jeff Pieper <jeffrey.e.pieper@...el.com>
> >Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> >Signed-off-by: Zhu Yanjun <Yanjun.Zhu@...driver.com>

The case where a commit gets backported is always ambiguous, especially
when the context changes a lot. I'm personally in favor of keeping the
original signed-of-by chain related to the original fix, and adding some
text between it and the backporter's s-o-b indicating that the changes
were, so that original authors do not get blamed for mistakes.

Best regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html