| Message ID | 4C068ABA.1000904@canonical.com |
|---|---|
| State | Accepted |
| Delegated to: | Steve Conklin |
| Headers | show |
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
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
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
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.
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
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
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
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);