| Message ID | 20080923224630.6927.28967.stgit@jtkirshe-mobile.jf.intel.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | Jeff Garzik |
| Headers | show |
Jeff Kirsher wrote: > From: Bruce Allan <bruce.w.allan@intel.com> > > When the driver fails to acquire the control flag used to serialize > NVM and PHY accesses between the driver, firmware and hardware, remove the > request for the flag otherwise the hardware might grant the flag when it > becomes available but the driver will not release the flag. This could > cause the firmware to prevent the driver getting the flag for all future > attempts. > > Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> > --- > > drivers/net/e1000e/ich8lan.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) 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
On Wed, 24 Sep 2008, Jeff Garzik wrote: > > When the driver fails to acquire the control flag used to serialize > > NVM and PHY accesses between the driver, firmware and hardware, remove the > > request for the flag otherwise the hardware might grant the flag when it > > becomes available but the driver will not release the flag. This could > > cause the firmware to prevent the driver getting the flag for all future > > attempts. > applied BTW are you going to take the whole series, or just this fix? I don't think that the other patches should be really applied to upstream (they could be very handy for debugging this horrible issue, once we could do any debugging of it, thoug), as they don't protect against anyone creating a new rw mapping, which can then be freely used to still overwrite the mmio area without any problems.
Jiri Kosina wrote: > On Wed, 24 Sep 2008, Jeff Garzik wrote: > >>> When the driver fails to acquire the control flag used to serialize >>> NVM and PHY accesses between the driver, firmware and hardware, remove the >>> request for the flag otherwise the hardware might grant the flag when it >>> becomes available but the driver will not release the flag. This could >>> cause the firmware to prevent the driver getting the flag for all future >>> attempts. >> applied > > BTW are you going to take the whole series, or just this fix? Just this fix Jeff -- 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/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c index f47c60e..6b14ea8 100644 --- a/drivers/net/e1000e/ich8lan.c +++ b/drivers/net/e1000e/ich8lan.c @@ -409,6 +409,8 @@ static s32 e1000_acquire_swflag_ich8lan(struct e1000_hw *hw) if (!timeout) { hw_dbg(hw, "FW or HW has locked the resource for too long.\n"); + extcnf_ctrl &= ~E1000_EXTCNF_CTRL_SWFLAG; + ew32(EXTCNF_CTRL, extcnf_ctrl); return -E1000_ERR_CONFIG; }