[PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Kyle Moffett]

The Intel 82571EB chipset can be used in an unmanaged configuration as a
fast dual-port Gig-E controller.  Unfortunately a board constructed that
way would fail to correctly come up because the driver polls for the
completion of a management cycle that will never occur.

To resolve this problem, we disable the poll and error return on chips
whose EEPROMs indicate no management.  As a protection against
misconfigured chipsets, we still delay for the entire management poll
timeout.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 drivers/net/e1000e/82571.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index f654db9..36d736f 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -756,6 +756,13 @@ static s32 e1000_get_cfg_done_82571(struct e1000_hw *hw)
 {
 	s32 timeout = PHY_CFG_TIMEOUT;
 
+	/* Don't bother polling the management registers if unmanaged */
+	if (!e1000e_check_mng_mode(hw)) {
+		hw_dbg(hw, "Unmanaged chip... skipping MNG polling cycle\n");
+		mdelay(timeout);
+		return 0;
+	}
+
 	while (timeout) {
 		if (er32(EEMNGCTL) &
 		    E1000_NVM_CFG_DONE_PORT_0)
-- 
1.7.1

Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Jeff Kirsher]

On Fri, Aug 27, 2010 at 12:10, Kyle Moffett <Kyle.D.Moffett@boeing.com> wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board constructed that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMs indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
>  drivers/net/e1000e/82571.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>

Thanks Kyle, I have added the patch to my queue.

-- 
Cheers,
Jeff

Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Jeff Kirsher]

On Fri, Aug 27, 2010 at 12:10, Kyle Moffett <Kyle.D.Moffett@boeing.com> wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board constructed that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMs indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
>  drivers/net/e1000e/82571.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>

Thanks Kyle, I have added the patch to my queue.

-- 
Cheers,
Jeff

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Jesse Brandeburg]

On Fri, Aug 27, 2010 at 12:10 PM, Kyle Moffett
<Kyle.D.Moffett@boeing.com> wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board constructed that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMs indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>

Hi Kyle, thanks for submitting this patch.  Are you fixing this
problem for a device that is a LOM?  The reason I ask is that most if
not all of our current eeprom images require some firmware interaction
to correctly initialize the PHY when the part is reset, even for the
no_mng (no managability) case.

Your code below will avoid reading of and waiting for the cfg_done
bit, which means that the firmware could end up racing with the
driver, with them both trying to configure the part.

Was there a specific bug you were trying to fix, and can you reply (if
you want to me in private) with your ethtool -e ethX output?

The concern here is that you may simply have an out of date eeprom
image, which might fix the original issue and get the driver to work
correctly, as the behavior you are describing is not how it should
work according to our design.

At the very least we would like to reproduce your issue here so we can
investigate further.

Jesse

Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Jesse Brandeburg]

On Fri, Aug 27, 2010 at 12:10 PM, Kyle Moffett
<Kyle.D.Moffett@boeing.com> wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board constructed that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMs indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>

Hi Kyle, thanks for submitting this patch.  Are you fixing this
problem for a device that is a LOM?  The reason I ask is that most if
not all of our current eeprom images require some firmware interaction
to correctly initialize the PHY when the part is reset, even for the
no_mng (no managability) case.

Your code below will avoid reading of and waiting for the cfg_done
bit, which means that the firmware could end up racing with the
driver, with them both trying to configure the part.

Was there a specific bug you were trying to fix, and can you reply (if
you want to me in private) with your ethtool -e ethX output?

The concern here is that you may simply have an out of date eeprom
image, which might fix the original issue and get the driver to work
correctly, as the behavior you are describing is not how it should
work according to our design.

At the very least we would like to reproduce your issue here so we can
investigate further.

Jesse

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired