| Message ID | 1297810270-4690-1-git-send-email-mcarlson@broadcom.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > If management firmware is present and the device is down, the firmware > will assume control of the phy. If a phy access were allowed from the > host, it will collide with firmware phy accesses, resulting in > unpredictable behavior. This patch fixes the problem by disallowing phy > accesses during the problematic condition. > > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 There is no such upstream git commit id in Linus's tree. What am I doing wrong here? confused, greg k-h -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: > On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > > If management firmware is present and the device is down, the firmware > > will assume control of the phy. If a phy access were allowed from the > > host, it will collide with firmware phy accesses, resulting in > > unpredictable behavior. This patch fixes the problem by disallowing phy > > accesses during the problematic condition. > > > > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 > > There is no such upstream git commit id in Linus's tree. What am I > doing wrong here? The commit is in Dave Miller's net-next-2.6 tree. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Matt Carlson" <mcarlson@broadcom.com> Date: Wed, 16 Feb 2011 15:06:13 -0800 > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: >> > If management firmware is present and the device is down, the firmware >> > will assume control of the phy. If a phy access were allowed from the >> > host, it will collide with firmware phy accesses, resulting in >> > unpredictable behavior. This patch fixes the problem by disallowing phy >> > accesses during the problematic condition. >> > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 >> >> There is no such upstream git commit id in Linus's tree. What am I >> doing wrong here? > > The commit is in Dave Miller's net-next-2.6 tree. > If it wasn't appropriate for net-2.6, it absolutely it not appropriate for -stable. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote: > From: "Matt Carlson" <mcarlson@broadcom.com> > Date: Wed, 16 Feb 2011 15:06:13 -0800 > > > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: > >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > >> > If management firmware is present and the device is down, the firmware > >> > will assume control of the phy. If a phy access were allowed from the > >> > host, it will collide with firmware phy accesses, resulting in > >> > unpredictable behavior. This patch fixes the problem by disallowing phy > >> > accesses during the problematic condition. > >> > > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 > >> > >> There is no such upstream git commit id in Linus's tree. What am I > >> doing wrong here? > > > > The commit is in Dave Miller's net-next-2.6 tree. > > > > If it wasn't appropriate for net-2.6, it absolutely it not appropriate > for -stable. net-2.6 was the target tree for the patch. The stable_kernel_rules.txt seemed to suggest that I could just CC stable@kernel.org with the commit ID, and Greg would pull it in as the process dictates. If that isn't correct, what is the preferred way to expedite the integration of a patch? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 16, 2011 at 03:52:48PM -0800, Matt Carlson wrote: > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote: > > From: "Matt Carlson" <mcarlson@broadcom.com> > > Date: Wed, 16 Feb 2011 15:06:13 -0800 > > > > > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: > > >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > > >> > If management firmware is present and the device is down, the firmware > > >> > will assume control of the phy. If a phy access were allowed from the > > >> > host, it will collide with firmware phy accesses, resulting in > > >> > unpredictable behavior. This patch fixes the problem by disallowing phy > > >> > accesses during the problematic condition. > > >> > > > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 > > >> > > >> There is no such upstream git commit id in Linus's tree. What am I > > >> doing wrong here? > > > > > > The commit is in Dave Miller's net-next-2.6 tree. > > > > > > > If it wasn't appropriate for net-2.6, it absolutely it not appropriate > > for -stable. > > net-2.6 was the target tree for the patch. The stable_kernel_rules.txt > seemed to suggest that I could just CC stable@kernel.org with the > commit ID, and Greg would pull it in as the process dictates. If that > isn't correct, what is the preferred way to expedite the integration of > a patch? Keep reading that file, it says to put the Cc: in the signed-off-by area of the original patch. Also, that file says the patch has to be in Linus's tree, otherwise sending me a git commit id of some other tree isn't going to help at all. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Matt Carlson" <mcarlson@broadcom.com> Date: Wed, 16 Feb 2011 15:52:48 -0800 > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote: >> From: "Matt Carlson" <mcarlson@broadcom.com> >> Date: Wed, 16 Feb 2011 15:06:13 -0800 >> >> > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: >> >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: >> >> > If management firmware is present and the device is down, the firmware >> >> > will assume control of the phy. If a phy access were allowed from the >> >> > host, it will collide with firmware phy accesses, resulting in >> >> > unpredictable behavior. This patch fixes the problem by disallowing phy >> >> > accesses during the problematic condition. >> >> > >> >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 >> >> >> >> There is no such upstream git commit id in Linus's tree. What am I >> >> doing wrong here? >> > >> > The commit is in Dave Miller's net-next-2.6 tree. >> > >> >> If it wasn't appropriate for net-2.6, it absolutely it not appropriate >> for -stable. > > net-2.6 was the target tree for the patch. The stable_kernel_rules.txt > seemed to suggest that I could just CC stable@kernel.org with the > commit ID, and Greg would pull it in as the process dictates. If that > isn't correct, what is the preferred way to expedite the integration of > a patch? You are posting a commit ID for the net-next-2.6 tree, that's what triggered my response. Unless it also went into the net-2.6 tree (in which case you should give Greg the net-2.6 commit ID, which is also what the commit ID must be in Linus's tree right now), the change is not appropriate for -stable submission. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 16, 2011 at 04:00:35PM -0800, Greg KH wrote: > On Wed, Feb 16, 2011 at 03:52:48PM -0800, Matt Carlson wrote: > > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote: > > > From: "Matt Carlson" <mcarlson@broadcom.com> > > > Date: Wed, 16 Feb 2011 15:06:13 -0800 > > > > > > > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: > > > >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > > > >> > If management firmware is present and the device is down, the firmware > > > >> > will assume control of the phy. If a phy access were allowed from the > > > >> > host, it will collide with firmware phy accesses, resulting in > > > >> > unpredictable behavior. This patch fixes the problem by disallowing phy > > > >> > accesses during the problematic condition. > > > >> > > > > >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 > > > >> > > > >> There is no such upstream git commit id in Linus's tree. What am I > > > >> doing wrong here? > > > > > > > > The commit is in Dave Miller's net-next-2.6 tree. > > > > > > > > > > If it wasn't appropriate for net-2.6, it absolutely it not appropriate > > > for -stable. > > > > net-2.6 was the target tree for the patch. The stable_kernel_rules.txt > > seemed to suggest that I could just CC stable@kernel.org with the > > commit ID, and Greg would pull it in as the process dictates. If that > > isn't correct, what is the preferred way to expedite the integration of > > a patch? > > Keep reading that file, it says to put the Cc: in the signed-off-by area > of the original patch. Ah. Yes. I see that now. > Also, that file says the patch has to be in Linus's tree, otherwise > sending me a git commit id of some other tree isn't going to help at > all. I see. Thanks for the tips. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 16, 2011 at 04:10:25PM -0800, David Miller wrote: > From: "Matt Carlson" <mcarlson@broadcom.com> > Date: Wed, 16 Feb 2011 15:52:48 -0800 > > > On Wed, Feb 16, 2011 at 03:11:03PM -0800, David Miller wrote: > >> From: "Matt Carlson" <mcarlson@broadcom.com> > >> Date: Wed, 16 Feb 2011 15:06:13 -0800 > >> > >> > On Wed, Feb 16, 2011 at 02:39:35PM -0800, Greg KH wrote: > >> >> On Tue, Feb 15, 2011 at 02:51:10PM -0800, Matt Carlson wrote: > >> >> > If management firmware is present and the device is down, the firmware > >> >> > will assume control of the phy. If a phy access were allowed from the > >> >> > host, it will collide with firmware phy accesses, resulting in > >> >> > unpredictable behavior. This patch fixes the problem by disallowing phy > >> >> > accesses during the problematic condition. > >> >> > > >> >> > Upstream commit ID f746a3136a61ae535c5d0b49a9418fa21edc61b5 > >> >> > >> >> There is no such upstream git commit id in Linus's tree. What am I > >> >> doing wrong here? > >> > > >> > The commit is in Dave Miller's net-next-2.6 tree. > >> > > >> > >> If it wasn't appropriate for net-2.6, it absolutely it not appropriate > >> for -stable. > > > > net-2.6 was the target tree for the patch. The stable_kernel_rules.txt > > seemed to suggest that I could just CC stable@kernel.org with the > > commit ID, and Greg would pull it in as the process dictates. If that > > isn't correct, what is the preferred way to expedite the integration of > > a patch? > > You are posting a commit ID for the net-next-2.6 tree, that's what triggered > my response. > > Unless it also went into the net-2.6 tree (in which case you should > give Greg the net-2.6 commit ID, which is also what the commit ID must > be in Linus's tree right now), the change is not appropriate for > -stable submission. So the proper thing to do here is recall the patch, submit a new patch to net-2.6 with a CC: stabel@kernel.org in the signed-off-by section. Would I do the exact same thing if I were posting to net-next-2.6? (i.e. the CC line tells you I want this patch to go to net-next-2.6, net-2.6, then Linus's tree, then stable?) Or would you rather I posted a completely different patchset against net-2.6? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Matt Carlson" <mcarlson@broadcom.com> Date: Wed, 16 Feb 2011 16:39:47 -0800 > So the proper thing to do here is recall the patch, submit a new patch > to net-2.6 with a CC: stabel@kernel.org in the signed-off-by section. No. I have not applied your patch yet, but when I do and I also get my tree pulled next time into Linus's tree, you can ask stable to apply it. Because only at that point will it exist as a commit in Linus's tree. Before that happens you cannot ask Greg to apply it to his tree. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Matt Carlson" <mcarlson@broadcom.com> Date: Tue, 15 Feb 2011 14:51:10 -0800 > If management firmware is present and the device is down, the firmware > will assume control of the phy. If a phy access were allowed from the > host, it will collide with firmware phy accesses, resulting in > unpredictable behavior. This patch fixes the problem by disallowing phy > accesses during the problematic condition. > > Signed-off-by: Matt Carlson <mcarlson@broadcom.com> > Reviewed-by: Michael Chan <mchan@broadcom.com> > Signed-off-by: David S. Miller <davem@davemloft.net> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 93b32d3..06c0e503 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -11158,7 +11158,9 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) if (tp->phy_flags & TG3_PHYFLG_PHY_SERDES) break; /* We have no PHY */ - if (tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) + if ((tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) || + ((tp->tg3_flags & TG3_FLAG_ENABLE_ASF) && + !netif_running(dev))) return -EAGAIN; spin_lock_bh(&tp->lock); @@ -11174,7 +11176,9 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) if (tp->phy_flags & TG3_PHYFLG_PHY_SERDES) break; /* We have no PHY */ - if (tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) + if ((tp->phy_flags & TG3_PHYFLG_IS_LOW_POWER) || + ((tp->tg3_flags & TG3_FLAG_ENABLE_ASF) && + !netif_running(dev))) return -EAGAIN; spin_lock_bh(&tp->lock);