Patchwork Lucid pull request, sfc driver stable updates

login
register
mail settings
Submitter Tim Gardner
Date June 2, 2010, 4:45 p.m.
Message ID <4C068ABA.1000904@canonical.com>
Download mbox | patch
Permalink /patch/54389/
State Accepted
Delegated to: Steve Conklin
Headers show

Comments

Tim Gardner - June 2, 2010, 4:45 p.m.
Stefan,

Please consider including these 2.6.33.4 stable updates for the sfc driver.

 From the maintainer: 
https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html

For everyone else, note that sfc was backported from 2.6.33.

rtg
Stefan Bader - June 7, 2010, 12:03 p.m.
On 06/02/2010 06:45 PM, Tim Gardner wrote:
> Stefan,
> 
> Please consider including these 2.6.33.4 stable updates for the sfc driver.
> 
> From the maintainer:
> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
> 
> For everyone else, note that sfc was backported from 2.6.33.
> 
> rtg

Given that this is on upstream stable for the kernel version that driver is
based on, I think it is acceptable for SRU. ACK for the patches (with one more
to go), but could you please create a tracking bug with a short justification?

Thanks,
Stefan
Tim Gardner - June 7, 2010, 12:44 p.m.
On 06/07/2010 06:03 AM, Stefan Bader wrote:
> On 06/02/2010 06:45 PM, Tim Gardner wrote:
>> Stefan,
>>
>> Please consider including these 2.6.33.4 stable updates for the sfc driver.
>>
>>  From the maintainer:
>> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
>>
>> For everyone else, note that sfc was backported from 2.6.33.
>>
>> rtg
>
> Given that this is on upstream stable for the kernel version that driver is
> based on, I think it is acceptable for SRU. ACK for the patches (with one more
> to go), but could you please create a tracking bug with a short justification?
>
> Thanks,
> Stefan

Why not include these patches as a regular part of the stable updates 
bug, just as you've done for DRM from 2.6.33 ? The sfc patches are no 
different.

rtg
Stefan Bader - June 7, 2010, 1:07 p.m.
On 06/07/2010 02:44 PM, Tim Gardner wrote:
> On 06/07/2010 06:03 AM, Stefan Bader wrote:
>> On 06/02/2010 06:45 PM, Tim Gardner wrote:
>>> Stefan,
>>>
>>> Please consider including these 2.6.33.4 stable updates for the sfc
>>> driver.
>>>
>>>  From the maintainer:
>>> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
>>>
>>> For everyone else, note that sfc was backported from 2.6.33.
>>>
>>> rtg
>>
>> Given that this is on upstream stable for the kernel version that
>> driver is
>> based on, I think it is acceptable for SRU. ACK for the patches (with
>> one more
>> to go), but could you please create a tracking bug with a short
>> justification?
>>
>> Thanks,
>> Stefan
> 
> Why not include these patches as a regular part of the stable updates
> bug, just as you've done for DRM from 2.6.33 ? The sfc patches are no
> different.
> 
> rtg

I could do that. But for a fact those are somewhat different in that respect
that I am not automatically following sfc in 2.6.33. Like the mutlitouch stuff
which is 2.6.34 (now). And somehow it feels to me that giving this its own
tracking bug carries the message of this being on its own better than hiding it
into one of the stable.
And why not including it generally? This slowly grows a bit into brain damaging
variety...

Stefan
Ben Hutchings - June 7, 2010, 1:37 p.m.
On Mon, 2010-06-07 at 14:03 +0200, Stefan Bader wrote:
> On 06/02/2010 06:45 PM, Tim Gardner wrote:
> > Stefan,
> > 
> > Please consider including these 2.6.33.4 stable updates for the sfc driver.
> > 
> > From the maintainer:
> > https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
> > 
> > For everyone else, note that sfc was backported from 2.6.33.
> > 
> > rtg
> 
> Given that this is on upstream stable for the kernel version that driver is
> based on, I think it is acceptable for SRU. ACK for the patches (with one more
> to go), but could you please create a tracking bug with a short justification?

I'm happy to file bugs if you need such references.

In any case I don't expect the 2.6.33.y series to continue much longer
so I won't be able to refer to that in future.

Ben.
Tim Gardner - June 7, 2010, 1:40 p.m.
On 06/07/2010 07:07 AM, Stefan Bader wrote:
> On 06/07/2010 02:44 PM, Tim Gardner wrote:
>> On 06/07/2010 06:03 AM, Stefan Bader wrote:
>>> On 06/02/2010 06:45 PM, Tim Gardner wrote:
>>>> Stefan,
>>>>
>>>> Please consider including these 2.6.33.4 stable updates for the sfc
>>>> driver.
>>>>
>>>>   From the maintainer:
>>>> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
>>>>
>>>> For everyone else, note that sfc was backported from 2.6.33.
>>>>
>>>> rtg
>>>
>>> Given that this is on upstream stable for the kernel version that
>>> driver is
>>> based on, I think it is acceptable for SRU. ACK for the patches (with
>>> one more
>>> to go), but could you please create a tracking bug with a short
>>> justification?
>>>
>>> Thanks,
>>> Stefan
>>
>> Why not include these patches as a regular part of the stable updates
>> bug, just as you've done for DRM from 2.6.33 ? The sfc patches are no
>> different.
>>
>> rtg
>
> I could do that. But for a fact those are somewhat different in that respect
> that I am not automatically following sfc in 2.6.33. Like the mutlitouch stuff
> which is 2.6.34 (now). And somehow it feels to me that giving this its own
> tracking bug carries the message of this being on its own better than hiding it
> into one of the stable.
> And why not including it generally? This slowly grows a bit into brain damaging
> variety...
>
> Stefan

http://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/590783
Stefan Bader - June 7, 2010, 1:59 p.m.
On 06/07/2010 03:37 PM, Ben Hutchings wrote:
> On Mon, 2010-06-07 at 14:03 +0200, Stefan Bader wrote:
>> On 06/02/2010 06:45 PM, Tim Gardner wrote:
>>> Stefan,
>>>
>>> Please consider including these 2.6.33.4 stable updates for the sfc driver.
>>>
>>> From the maintainer:
>>> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
>>>
>>> For everyone else, note that sfc was backported from 2.6.33.
>>>
>>> rtg
>>
>> Given that this is on upstream stable for the kernel version that driver is
>> based on, I think it is acceptable for SRU. ACK for the patches (with one more
>> to go), but could you please create a tracking bug with a short justification?
> 
> I'm happy to file bugs if you need such references.
> 
> In any case I don't expect the 2.6.33.y series to continue much longer
> so I won't be able to refer to that in future.
> 
> Ben.
> 

Tim already did one. Yeah, the currently queued list might be the last. But that
has been said about 2.6.31.y, too. But likely not for too much longer, now that
.34.y is added. For that it might be possible to reference 2.6.34.y in future
and with a separate bug to track.


Stefan
Steve Conklin - June 24, 2010, 9:45 p.m.
Applied as the original three patches which are now in Greg's stable
tree.

Steve

On Wed, 2010-06-02 at 10:45 -0600, Tim Gardner wrote:
> Stefan,
> 
> Please consider including these 2.6.33.4 stable updates for the sfc driver.
> 
>  From the maintainer: 
> https://lists.ubuntu.com/archives/kernel-team/2010-June/010894.html
> 
> For everyone else, note that sfc was backported from 2.6.33.
> 
> rtg

Patch

diff --git a/drivers/net/sfc/siena.c b/drivers/net/sfc/siena.c
index f8c6771..afbac2d 100644
--- a/drivers/net/sfc/siena.c
+++ b/drivers/net/sfc/siena.c
@@ -454,8 +454,17 @@  static int siena_try_update_nic_stats(struct efx_nic *efx)
 
 static void siena_update_nic_stats(struct efx_nic *efx)
 {
-	while (siena_try_update_nic_stats(efx) == -EAGAIN)
-		cpu_relax();
+	int retry;
+
+	/* If we're unlucky enough to read statistics wduring the DMA, wait
+	 * up to 10ms for it to finish (typically takes <500us) */
+	for (retry = 0; retry < 100; ++retry) {
+		if (siena_try_update_nic_stats(efx) == 0)
+			return;
+		udelay(100);
+	}
+
+	/* Use the old values instead */
 }
 
 static void siena_start_nic_stats(struct efx_nic *efx)
-- 
1.7.0.4


From 4ab4cb7404641cb676d772ec04e231f6986abaf2 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 28 Apr 2010 09:01:33 +0000
Subject: [PATCH 2/3] sfc: Always close net device at the end of a disabling reset

commit f49a4589e9e25ef525da449b1ce5597cb659bbb5 upstream.

This fixes a regression introduced by commit
eb9f6744cbfa97674c13263802259b5aa0034594 "sfc: Implement ethtool
reset operation".

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
 drivers/net/sfc/efx.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 46997e1..fb52e47 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1862,6 +1862,7 @@  out:
 	}
 
 	if (disabled) {
+		dev_close(efx->net_dev);
 		EFX_ERR(efx, "has been disabled\n");
 		efx->state = STATE_DISABLED;
 	} else {
@@ -1885,8 +1886,7 @@  static void efx_reset_work(struct work_struct *data)
 	}
 
 	rtnl_lock();
-	if (efx_reset(efx, efx->reset_pending))
-		dev_close(efx->net_dev);
+	(void)efx_reset(efx, efx->reset_pending);
 	rtnl_unlock();
 }
 
-- 
1.7.0.4


From 6865f0be5194076886e81e486674bece49bde463 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 28 Apr 2010 09:01:50 +0000
Subject: [PATCH 3/3] sfc: Change falcon_probe_board() to fail for unsupported boards

commit e41c11ee0cc602bcde68916be85fb97d1a484324 upstream.

The driver needs specific PHY and board support code for each SFC4000
board; there is no point trying to continue if it is missing.
Currently unsupported boards can trigger an 'oops'.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
 drivers/net/sfc/falcon.c        |    4 +++-
 drivers/net/sfc/falcon_boards.c |   13 +++----------
 drivers/net/sfc/nic.h           |    2 +-
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 9d009c4..e20a824 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -1317,7 +1317,9 @@  static int falcon_probe_nvconfig(struct efx_nic *efx)
 
 	EFX_LOG(efx, "PHY is %d phy_id %d\n", efx->phy_type, efx->mdio.prtad);
 
-	falcon_probe_board(efx, board_rev);
+	rc = falcon_probe_board(efx, board_rev);
+	if (rc)
+		goto fail2;
 
 	kfree(nvconfig);
 	return 0;
diff --git a/drivers/net/sfc/falcon_boards.c b/drivers/net/sfc/falcon_boards.c
index 5712fdd..c7a933a 100644
--- a/drivers/net/sfc/falcon_boards.c
+++ b/drivers/net/sfc/falcon_boards.c
@@ -728,15 +728,7 @@  static const struct falcon_board_type board_types[] = {
 	},
 };
 
-static const struct falcon_board_type falcon_dummy_board = {
-	.init		= efx_port_dummy_op_int,
-	.init_phy	= efx_port_dummy_op_void,
-	.fini		= efx_port_dummy_op_void,
-	.set_id_led	= efx_port_dummy_op_set_id_led,
-	.monitor	= efx_port_dummy_op_int,
-};
-
-void falcon_probe_board(struct efx_nic *efx, u16 revision_info)
+int falcon_probe_board(struct efx_nic *efx, u16 revision_info)
 {
 	struct falcon_board *board = falcon_board(efx);
 	u8 type_id = FALCON_BOARD_TYPE(revision_info);
@@ -754,8 +746,9 @@  void falcon_probe_board(struct efx_nic *efx, u16 revision_info)
 			 (efx->pci_dev->subsystem_vendor == EFX_VENDID_SFC)
 			 ? board->type->ref_model : board->type->gen_type,
 			 'A' + board->major, board->minor);
+		return 0;
 	} else {
 		EFX_ERR(efx, "unknown board type %d\n", type_id);
-		board->type = &falcon_dummy_board;
+		return -ENODEV;
 	}
 }
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 9351c03..3166baf 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -156,7 +156,7 @@  extern struct efx_nic_type siena_a0_nic_type;
  **************************************************************************
  */
 
-extern void falcon_probe_board(struct efx_nic *efx, u16 revision_info);
+extern int falcon_probe_board(struct efx_nic *efx, u16 revision_info);
 
 /* TX data path */
 extern int efx_nic_probe_tx(struct efx_tx_queue *tx_queue);