1. 15 3月, 2012 3 次提交
  2. 01 3月, 2012 4 次提交
  3. 27 2月, 2012 2 次提交
  4. 24 2月, 2012 1 次提交
  5. 23 2月, 2012 8 次提交
  6. 16 2月, 2012 4 次提交
  7. 15 2月, 2012 1 次提交
    • G
      irq_domain/powerpc: Use common irq_domain structure instead of irq_host · bae1d8f1
      Grant Likely 提交于
      This patch drops the powerpc-specific irq_host structures and uses the common
      irq_domain strucutres defined in linux/irqdomain.h.  It also fixes all
      the users to use the new structure names.
      
      Renaming irq_host to irq_domain has been discussed for a long time, and this
      patch is a step in the process of generalizing the powerpc virq code to be
      usable by all architecture.
      
      An astute reader will notice that this patch actually removes the irq_host
      structure instead of renaming it.  This is because the irq_domain structure
      already exists in include/linux/irqdomain.h and has the needed data members.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Milton Miller <miltonm@bga.com>
      Tested-by: NOlof Johansson <olof@lixom.net>
      bae1d8f1
  8. 13 2月, 2012 1 次提交
  9. 10 2月, 2012 8 次提交
    • D
      bna: fix error handling of bnad_get_flash_partition_by_offset() · 027a3b61
      Dan Carpenter 提交于
      The current error handling doesn't work because we flash_part is a u32
      so the checks for negative error codes don't work.  I considered making
      things signed but I don't know the hardware enough to say if that's a
      problem.  Really, we don't use the error codes so just returning zero
      for all problems is fine.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      027a3b61
    • D
      isdn: type bug in isdn_net_header() · 5a46e0f9
      Dan Carpenter 提交于
      We use len to store the return value from eth_header().  eth_header()
      can return -ETH_HLEN (-14).  We want to pass this back instead of
      truncating it to 65522 and returning that.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a46e0f9
    • N
      hwmon: (f75375s) Let f75375_update_device treat pwmX as a measured value · a1c1baf0
      Nikolaus Schulz 提交于
      Treat pwmX as a measured value, not as a (mostly static) limit value, so
      that it is updated more frequently from the device register.
      Signed-off-by: NNikolaus Schulz <mail@microschulz.de>
      Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
      a1c1baf0
    • P
      tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds · 19723452
      Paul Walmsley 提交于
      The receive FIFO wakeup latency estimate in the omap-serial driver is
      three orders of magnitude too small.  This effectively prevents the
      MPU from going to a low-power state when CONFIG_CPU_IDLE=y.  This is a
      major power management regression and masks some other FIFO-related
      bugs in the driver.
      
      Fix by correcting the most egregious problem in the RX wakeup latency
      estimate.  There are several other flaws in the estimator; these will
      be fixed by a separate patch series intended for 3.4.
      
      The difference in low-power states with this patch can be observed via
      debugfs in pm_debug/count.
      
      This estimate does not have any effect when CONFIG_CPU_IDLE=n.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Acked-by: NGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19723452
    • P
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode · be4b0281
      Paul Walmsley 提交于
      Prevent OMAP UARTs from going idle while they are still transferring
      data in PIO mode.  This works around an oversight in the OMAP UART
      hardware present in OMAP34xx and earlier: an idle UART won't send a
      wakeup when the TX FIFO threshold is reached.  This causes long delays
      during data transmission when the MPU powerdomain enters a low-power
      mode.  The MPU interrupt controller is not able to respond to
      interrupts when it's in a low-power state, so the TX buffer is not
      refilled until another wakeup event occurs.
      
      This fix changes the erratum i291 DMA idle workaround.  Rather than
      toggling between force-idle and no-idle, it will toggle between
      smart-idle and no-idle.  The important part of the workaround is the
      no-idle part, so this shouldn't result in any change in behavior.
      
      This fix should work on all OMAP UARTs.  Future patches intended for
      the 3.4 merge window will make this workaround conditional on a
      "feature" flag, and will use the OMAP36xx+ TX event wakeup support.
      
      Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
      workaround, which led to the development of this approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be4b0281
    • P
      tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode · 0ba5f668
      Paul Walmsley 提交于
      In the (default) PIO mode, use a one-byte RX FIFO threshold.  The OMAP
      UART IP blocks do not appear to be capable of waking the system under
      an RX timeout condition.  Since the previous RX FIFO threshold was 16
      bytes, this meant that omap-serial.c did not become aware of any
      received data until all those bytes arrived or until another UART
      interrupt occurred.  This made the serial console and presumably other
      serial applications (GPS, serial Bluetooth) unusable or extremely
      slow.  A 1-byte RX FIFO threshold also allows the MPU to enter a
      low-power consumption state while waiting for the FIFO to fill.
      
      This can be verified using the serial console by comparing the
      behavior when "0123456789abcde" is pasted in from another window, with
      the behavior when "0123456789abcdef" is pasted in.  Since the former
      string is less than sixteen bytes long, the string is not echoed for
      some time, while the latter string is echoed immediately.
      
      DMA operation is unaffected by this patch.
      
      Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
      additional information on the standard behavior of the RX timeout
      event, which was used to improve this commit description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Govindraj Raja <govindraj.r@ti.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ba5f668
    • R
      ARM: omap: fix broken twl-core dependencies and ifdefs · 6252547b
      Russell King 提交于
      In commit aeb5032b, a dependency on IRQ_DOMAIN was added, which causes
      regressions on previously working setups: a previously working non-DT
      kernel configuration now loses its PMIC support.  The lack of PMIC
      support in turn causes the loss of other functionality the kernel had.
      
      This dependency was added because the driver now registers its
      interrupts with the IRQ domain code, presumably to prevent a build error.
      
      The result is that OMAP3 oopses in the vp.c code (fixed by a previous
      commit) due to the lack of PMIC support.
      
      However, even with IRQ_DOMAIN enabled, the driver oopses:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP
      Modules linked in:
      CPU: 1    Not tainted  (3.3.0-rc2+ #271)
      PC is at irq_domain_add+0x1c/0x134
      LR is at twl_probe+0xd0/0x370
      pc : [<c007bad0>]    lr : [<c029baac>]    psr: 00000113
      sp : df843c48  ip : df843c68  fp : df843c64
      r10: c02b93e4  r9 : 00000000  r8 : c029b9dc
      r7 : df9d8a00  r6 : c03bef90  r5 : 00000000  r4 : c03f5240
      r3 : 00000000  r2 : c03f5240  r1 : 00000015  r0 : c03f5240
      Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 8000404a  DAC: 00000015
      Process swapper/0 (pid: 1, stack limit = 0xdf8422f0)
      Stack: (0xdf843c48 to 0xdf844000)
      3c40:                   00000014 00000170 00000014 c03bef90 df843c9c df843c68
      3c60: c029baac c007bac0 00000000 df9d8a20 00000001 c03cd238 c02b93e4 df9d8a20
      3c80: df9d8a04 df9d8a00 c029b9dc df8cae08 df843cc4 df843ca0 c01eee70 c029b9e8
      ...
      Backtrace:
      [<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
       r6:c03bef90 r5:00000014 r4:00000170
      [<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4)
      [<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x178)
       r8:df8f0070 r7:c03cd238 r6:df9d8a20 r5:df9d8a20 r4:df9d8a20
      [<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
       r7:df843d18 r6:df9d8a20 r5:c03cd238 r4:df9d8a20
      [<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d2148>] (__device_attach+0x44/0x48)
       r5:df9d8a20 r4:c03cd238
      [<c01d2104>] (__device_attach+0x0/0x48) from [<c01d0840>] (bus_for_each_drv+0x58/0x98)
       r5:c01d2104 r4:00000000
      [<c01d07e8>] (bus_for_each_drv+0x0/0x98) from [<c01d21f8>] (device_attach+0x80/0xac)
       r7:df9d8a28 r6:df9d8a54 r5:c03cd978 r4:df9d8a20
      [<c01d2178>] (device_attach+0x0/0xac) from [<c01d1430>] (bus_probe_device+0x34/0xa4)
       r6:df9d8a20 r5:c03cd978 r4:df9d8a20
      [<c01d13fc>] (bus_probe_device+0x0/0xa4) from [<c01cffb0>] (device_add+0x2a0/0x420)
       r6:00000000 r5:df9d8a20 r4:df9d8a20
      [<c01cfd10>] (device_add+0x0/0x420) from [<c01d0150>] (device_register+0x20/0x24)
       r8:df9d8a00 r7:df9d8a04 r6:df8f0048 r5:df9d8a00 r4:df9d8a20
      [<c01d0130>] (device_register+0x0/0x24) from [<c01ef8d4>] (i2c_new_device+0x118/0x180)
       r4:df9d8a20
      [<c01ef7bc>] (i2c_new_device+0x0/0x180) from [<c01efc88>] (i2c_register_adapter+0x140/0x204)
       r8:c03cd970 r7:00000000 r6:df8f0070 r5:df8a6300 r4:df8f0048
      [<c01efb48>] (i2c_register_adapter+0x0/0x204) from [<c01efe9c>] (i2c_add_numbered_adapter+0xb4/0xcc)
       r8:df8a4c54 r7:df8cae00 r6:df843e2c r5:df8f0048 r4:00000000
      [<c01efde8>] (i2c_add_numbered_adapter+0x0/0xcc) from [<c029ce1c>] (omap_i2c_probe+0x2f8/0x3b4)
       r6:00000000 r5:df8f0000 r4:df8f0070
      [<c029cb24>] (omap_i2c_probe+0x0/0x3b4) from [<c01d3484>] (platform_drv_probe+0x20/0x24)
      [<c01d3464>] (platform_drv_probe+0x0/0x24) from [<c01d1f34>] (really_probe+0xa0/0x178)
      [<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
       r7:df843ef0 r6:c03cdb2c r5:c03cdb2c r4:df8cae08
      [<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d20e0>] (__driver_attach+0x6c/0x90)
       r5:df8cae3c r4:df8cae08
      [<c01d2074>] (__driver_attach+0x0/0x90) from [<c01d08d8>] (bus_for_each_dev+0x58/0x98)
       r6:c03cdb2c r5:c01d2074 r4:00000000
      [<c01d0880>] (bus_for_each_dev+0x0/0x98) from [<c01d1d80>] (driver_attach+0x20/0x28)
       r7:df880b80 r6:c03cdb2c r5:c03cdb2c r4:c0394f28
      [<c01d1d60>] (driver_attach+0x0/0x28) from [<c01d115c>] (bus_add_driver+0xb4/0x230)
      [<c01d10a8>] (bus_add_driver+0x0/0x230) from [<c01d278c>] (driver_register+0xc8/0x154)
      [<c01d26c4>] (driver_register+0x0/0x154) from [<c01d37e4>] (platform_driver_register+0x4c/0x60)
       r8:00000000 r7:00000013 r6:c00384c8 r5:c0395180 r4:c0394f28
      [<c01d3798>] (platform_driver_register+0x0/0x60) from [<c038626c>] (omap_i2c_init_driver+0x14/0x1c)
      [<c0386258>] (omap_i2c_init_driver+0x0/0x1c) from [<c00087b8>] (do_one_initcall+0x9c/0x164)
      [<c000871c>] (do_one_initcall+0x0/0x164) from [<c036c2f4>] (kernel_init+0x90/0x138)
      [<c036c264>] (kernel_init+0x0/0x138) from [<c00384c8>] (do_exit+0x0/0x2ec)
       r5:c036c264 r4:00000000
      <0>Code: e24dd004 e5903014 e1a04000 e5905010 (e5933000)
      <4>---[ end trace 1b75b31a2719ed1c ]---
      
      This happens because we try to register an IRQ domain with a NULL ops
      structure, and the first thing irq_domain_add() does is try to
      dereference this ops structure.
      
      So, fix the problem by getting rid of the incorrect OF_IRQ ifdef and
      wrapping the IRQ domain bits of the driver with an IRQ_DOMAIN ifdef
      instead.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6252547b
    • R
      ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c · 40410715
      Russell King 提交于
      When a PMIC is not found, this driver is unable to obtain its
      'vdds_dsi_reg' regulator.  Even through its initialization function
      fails, other code still calls its enable function, which fails to
      check whether it has this regulator before asking for it to be enabled.
      
      This fixes the oops, however a better fix would be to sort out the
      upper layers to prevent them calling into a module which failed to
      initialize.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000038
      pgd = c0004000
      [00000038] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT
      Modules linked in:
      CPU: 0    Not tainted  (3.3.0-rc2+ #228)
      PC is at regulator_enable+0x10/0x70
      LR is at omapdss_dpi_display_enable+0x54/0x15c
      pc : [<c01b9a08>]    lr : [<c01af994>]    psr: 60000013
      sp : c181fd90  ip : c181fdb0  fp : c181fdac
      r10: c042eff0  r9 : 00000060  r8 : c044a164
      r7 : c042c0e4  r6 : c042bd60  r5 : 00000000  r4 : c042bd60
      r3 : c084de48  r2 : c181e000  r1 : c042bd60  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 80004019  DAC: 00000015
      Process swapper (pid: 1, stack limit = 0xc181e2e8)
      Stack: (0xc181fd90 to 0xc1820000)
      fd80:                                     c001754c c042bd60 00000000 c042bd60
      fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
      fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
      fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
      fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
      fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
      fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
      fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
      fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
      fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
      fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
      fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
      ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
      ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
      ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
      ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
      ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
      ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
      ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
      ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
      Backtrace:
      [<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
       r6:c042bd60 r5:00000000 r4:c042bd60
      [<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
       r6:c044a338 r5:c042bd60 r4:c042bd60
      [<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
       r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
      [<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
       r4:c042bd60
      [<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
       r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
      [<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
      [<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
      [<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
       r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
      [<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
       r5:c042f02c r4:c042eff8
      [<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
       r6:c0449db8 r5:c01e311c r4:00000000
      [<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
       r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
      [<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
      [<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
      [<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
       r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
      [<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
      [<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
      [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
      [<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
       r5:c03ea208 r4:00000000
      Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
      ---[ end trace 9e2474c2e193b223 ]---
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      40410715
  10. 09 2月, 2012 8 次提交
    • J
      ixgbe: ethtool: stats user buffer overrun · 9cc00b51
      John Fastabend 提交于
      If the number of tx/rx queues changes the ethtool ioctl
      ETHTOOL_GSTATS may overrun the userspace buffer. This
      occurs because the general practice in user space to
      query stats is to issue a ETHTOOL_GSSET cmd to learn the
      buffer size needed, allocate the buffer, then call
      ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of
      real_num_queues is changed or flow control attributes
      are changed after ETHTOOL_GSSET but before the
      ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer
      overrun occurs.
      
      To fix the overrun always return the max buffer size
      needed from get_sset_count() then return all strings
      and stats from get_strings()/get_ethtool_stats().
      
      This _will_ change the output from the ioctl() call
      which could break applications and script parsing in
      theory. I believe these changes should not break existing
      tools because the only changes will be more {tx|rx}_queues
      and the {tx|rx}_pb_* stats will always be returned.
      Existing scripts already need to handle changing number
      of queues because this occurs today depending on system
      and current features. The {tx|rx}_pb_* stats are at the
      end of the output and should be handled by scripts today
      regardless.
      
      Finally get_ethtool_stats and get_strings are free-form
      outputs tools parsing these outputs should be defensive
      anyways. In the end these updates are better then
      having a tool segfault because of a buffer overrun.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9cc00b51
    • J
      ixgbe: dcb: up2tc mapping lost on disable/enable CEE DCB state · 5facb8e0
      John Fastabend 提交于
      Users expect the up2tc mapping to be maintained across a DCB
      enable/disable/enable transition. And since we maintain all
      the other DCB attributes we should do this for up2tc mappings
      as well just to be consistent. Also without this we break
      user space applications that expect this to occur that
      previously worked.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NStephen Ko <stephen.s.ko@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5facb8e0
    • Y
      ixgbe: do not update real num queues when netdev is going away · 9d837ea2
      Yi Zou 提交于
      If the netdev is already in NETREG_UNREGISTERING/_UNREGISTERED state, do not
      update the real num tx queues. netdev_queue_update_kobjects() is already
      called via remove_queue_kobjects() at NETREG_UNREGISTERING time. So, when
      upper layer driver, e.g., FCoE protocol stack is monitoring the netdev
      event of NETDEV_UNREGISTER and calls back to LLD ndo_fcoe_disable() to remove
      extra queues allocated for FCoE, the associated txq sysfs kobjects are already
      removed, and trying to update the real num queues would cause something like
      below:
      
      ...
      PID: 25138  TASK: ffff88021e64c440  CPU: 3   COMMAND: "kworker/3:3"
       #0 [ffff88021f007760] machine_kexec at ffffffff810226d9
       #1 [ffff88021f0077d0] crash_kexec at ffffffff81089d2d
       #2 [ffff88021f0078a0] oops_end at ffffffff813bca78
       #3 [ffff88021f0078d0] no_context at ffffffff81029e72
       #4 [ffff88021f007920] __bad_area_nosemaphore at ffffffff8102a155
       #5 [ffff88021f0079f0] bad_area_nosemaphore at ffffffff8102a23e
       #6 [ffff88021f007a00] do_page_fault at ffffffff813bf32e
       #7 [ffff88021f007b10] page_fault at ffffffff813bc045
          [exception RIP: sysfs_find_dirent+17]
          RIP: ffffffff81178611  RSP: ffff88021f007bc0  RFLAGS: 00010246
          RAX: ffff88021e64c440  RBX: ffffffff8156cc63  RCX: 0000000000000004
          RDX: ffffffff8156cc63  RSI: 0000000000000000  RDI: 0000000000000000
          RBP: ffff88021f007be0   R8: 0000000000000004   R9: 0000000000000008
          R10: ffffffff816fed00  R11: 0000000000000004  R12: 0000000000000000
          R13: ffffffff8156cc63  R14: 0000000000000000  R15: ffff8802222a0000
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #8 [ffff88021f007be8] sysfs_get_dirent at ffffffff81178c07
       #9 [ffff88021f007c18] sysfs_remove_group at ffffffff8117ac27
      #10 [ffff88021f007c48] netdev_queue_update_kobjects at ffffffff813178f9
      #11 [ffff88021f007c88] netif_set_real_num_tx_queues at ffffffff81303e38
      #12 [ffff88021f007cc8] ixgbe_set_num_queues at ffffffffa0249763 [ixgbe]
      #13 [ffff88021f007cf8] ixgbe_init_interrupt_scheme at ffffffffa024ea89 [ixgbe]
      #14 [ffff88021f007d48] ixgbe_fcoe_disable at ffffffffa0267113 [ixgbe]
      #15 [ffff88021f007d68] vlan_dev_fcoe_disable at ffffffffa014fef5 [8021q]
      #16 [ffff88021f007d78] fcoe_interface_cleanup at ffffffffa02b7dfd [fcoe]
      #17 [ffff88021f007df8] fcoe_destroy_work at ffffffffa02b7f08 [fcoe]
      #18 [ffff88021f007e18] process_one_work at ffffffff8105d7ca
      #19 [ffff88021f007e68] worker_thread at ffffffff81060513
      #20 [ffff88021f007ee8] kthread at ffffffff810648b6
      #21 [ffff88021f007f48] kernel_thread_helper at ffffffff813c40f4
      Signed-off-by: NYi Zou <yi.zou@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Tested-by: NStephen Ko <stephen.s.ko@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9d837ea2
    • A
      ixgbe: Fix broken dependency on MAX_SKB_FRAGS being related to page size · 642c680e
      Alexander Duyck 提交于
      This patch fixes an issue in which RSC will generate corrupted frames when
      PAGE_SIZE is larger than 8K.  Specifically it looks like that in 2.6.39 a
      change was made so that GRO would always have at least 16 frags available
      for coalescing, but the ixgbe RSC logic was not updated.  As such the RSC
      feature would generate a frame larger than 64K and then overflow the value
      in the IP length field.
      
      To correct that I am now basing things on the PAGE_SIZE.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NStephen Ko <stephen.s.ko@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      642c680e
    • G
      ixgbe: Fix case of Tx Hang in PF with 32 VFs · 4cd6923d
      Greg Rose 提交于
      A check for the number of VFs allocated should have used a greater than
      equal operator instead of just greater than.  This caused allocation of
      exactly 32 VFs to not enable the PF transmit and receive enables.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NRobert E Garrett <robertX.e.garrett@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4cd6923d
    • G
      ixgbe: fix vf lookup · a4b08329
      Greg Rose 提交于
      Recent addition of code to find already allocated VFs failed to take
      account that systems with 2 or more multi-port SR-IOV capable controllers
      might have already enabled VFs.  Make sure that the VFs the function is
      finding are actually subordinate to the particular instance of the adapter
      that is looking for them and not subordinate to some device that has
      previously enabled SR-IOV.
      
      This bug exists in 3.2 stable as well as 3.3 release candidates.
      
      CC: stable@vger.kernel.org
      Reported-by: NDavid Ahern <daahern@cisco.com>
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NRobert E Garrett <robertX.e.garrett@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a4b08329
    • G
      igb: fix vf lookup · 06292921
      Greg Rose 提交于
      Recent addition of code to find already allocated VFs failed to take
      account that systems with 2 or more multi-port SR-IOV capable controllers
      might have already enabled VFs.  Make sure that the VFs the function is
      finding are actually subordinate to the particular instance of the adapter
      that is looking for them and not subordinate to some device that has
      previously enabled SR-IOV.
      
      This is applicable to 3.2+ kernels.
      
      CC: stable@vger.kernel.org
      Reported-by: NDavid Ahern <daahern@cisco.com>
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NRobert E Garrett <robertX.e.garrett@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      06292921
    • D
      e1000: add dropped DMA receive enable back in for WoL · b868179c
      Dean Nelson 提交于
      Commit d5bc77a2 broke Wake-on-LAN by
      inadvertently dropping the enabling of DMA receives.
      
      Restore the enabling of DMA receives for WoL.
      
      This is applicable to 3.1+ stable trees.
      
      CC: stable@vger.stable.org
      Reported-by: NTobias Klausmann <klausman@schwarzvogel.de>
      Signed-off-by: NDean Nelson <dnelson@redhat.com>
      Tested-by: NTobias Klausmann <klausman@schwarzvogel.de>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b868179c