1. 23 1月, 2011 2 次提交
  2. 21 1月, 2011 1 次提交
    • S
      firewire: core: fix unstable I/O with Canon camcorder · 6044565a
      Stefan Richter 提交于
      Regression since commit 10389536, "firewire: core: check for 1394a
      compliant IRM, fix inaccessibility of Sony camcorder":
      
      The camcorder Canon MV5i generates lots of bus resets when asynchronous
      requests are sent to it (e.g. Config ROM read requests or FCP Command
      write requests) if the camcorder is not root node.  This causes drop-
      outs in videos or makes the camcorder entirely inaccessible.
      https://bugzilla.redhat.com/show_bug.cgi?id=633260
      
      Fix this by allowing any Canon device, even if it is a pre-1394a IRM
      like MV5i are, to remain root node (if it is at least Cycle Master
      capable).  With the FireWire controller cards that I tested, MV5i always
      becomes root node when plugged in and left to its own devices.
      
      Reported-by: Ralf Lange
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: <stable@kernel.org> # 2.6.32.y and newer
      6044565a
  3. 13 1月, 2011 1 次提交
    • C
      firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO · 14271304
      Clemens Ladisch 提交于
      PAGE_KERNEL_RO is not available on all architectures, so its use
      in the new AR code broke compilation on sparc64.
      
      Because the read-only mapping was just a debugging aid, just use
      PAGE_KERNEL instead.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      
      James Bottomley wrote:
      > On Thu, 2011-01-13 at 08:27 +0100, Clemens Ladisch wrote:
      >> firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO, e.g. sparc
      >>
      >> PAGE_KERNEL_RO is not available on all architectures, so its use in the
      >> new AR code broke compilation on sparc64.
      >>
      >> Because the R/O mapping is only used to catch drivers that try to write
      >> to the reception buffer and not actually required for correct operation,
      >> we can just use a normal PAGE_KERNEL mapping where _RO is not available.
      [...]
      >> +/*
      >> + * For archs where PAGE_KERNEL_RO is not supported;
      >> + * mapping the AR buffers readonly for the CPU is just a debugging aid.
      >> + */
      >> +#ifndef PAGE_KERNEL_RO
      >> +#define PAGE_KERNEL_RO PAGE_KERNEL
      >> +#endif
      >
      > This might cause interesting issues on sparc64 if it ever acquired a
      > PAGE_KERNEL_RO.  Sparc64 has extern pgprot_t for it's PAGE_KERNEL types
      > rather than #defines, so the #ifdef check wouldn't see this.
      >
      > I think either PAGE_PROT_RO becomes part of our arch API (so all
      > architectures are forced to add it), or, if it's not part of the API,
      > ohci isn't entitled to use it.  The latter seems simplest since you have
      > no real use for write protection anyway.
      Reported-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      14271304
  4. 04 1月, 2011 5 次提交
  5. 19 12月, 2010 2 次提交
    • S
      firewire: net: set carrier state at ifup · c1671470
      Stefan Richter 提交于
      At ifup, carrier status would be shown on even if it actually was off.
      Also add an include for ethtool_ops rather than to rely on the one from
      netdevice.h.
      
      Note, we can alas not use fwnet_device_mutex to serialize access to
      dev->peer_count (as I originally wanted).  This would cause a lock
      inversion:
        - fwnet_probe | takes fwnet_device_mutex
            + register_netdev | takes rtnl_mutex
        - devinet_ioctl | takes rtnl_mutex
            + fwnet_open | ...must not take fwnet_device_mutex
      
      Hence use the dev->lock spinlock for serialization.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      c1671470
    • M
      firewire: net: add carrier detection · 18bb36f9
      Maxim Levitsky 提交于
      To make userland, e.g. NetworkManager work with firewire, we need to
      detect whether cable is plugged or not.  Simple and correct way of doing
      that is just counting number of peers.  No peers - no link and vice
      versa.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      18bb36f9
  6. 14 12月, 2010 10 次提交
  7. 12 12月, 2010 4 次提交
  8. 07 12月, 2010 7 次提交
  9. 06 12月, 2010 6 次提交
  10. 05 12月, 2010 2 次提交
    • G
      parisc: Fix GSC PS/2 driver name for keyboard and mouse · 7bfbeae9
      Guy Martin 提交于
      Fix kernel warnings caused by the driver name of GSC PS/2 containing '/'.
      
      The following warnings are observed on a K410 system :
      
      [   10.700000] name 'GSC PS/2 keyboard'
      [   10.732000] ------------[ cut here ]------------
      [   10.772000] WARNING: at fs/proc/generic.c:323
      [   10.828000] Modules linked in:
      [   10.916000]
      [   10.916000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   10.936000] PSW: 00000000000001000000000000001111 Not tainted
      [   10.992000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   11.060000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   11.124000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   11.184000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   11.248000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   11.308000] r20-23  00000000 00000028 104cd858 00000000
      [   11.372000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   11.436000] r28-31  0000002b 00000078 4fc40800 0000000d
      [   11.496000] sr00-03  00000000 00000000 00000000 00000000
      [   11.560000] sr04-07  00000000 00000000 00000000 00000000
      [   11.624000]
      [   11.688000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   11.704000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   11.772000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   11.836000]  ORIG_R28: 4fc40940
      [   11.904000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   11.940000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   11.996000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   12.052000] Backtrace:
      [   12.108000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   12.136000]
      [   12.188000] ---[ end trace 91bf6ece17e322dd ]---
      [   12.208000] serio: GSC PS/2 keyboard port at 0x0001c000 irq 19 @ 10:12:7
      [   12.264000] name 'GSC PS/2 mouse'
      [   12.344000] ------------[ cut here ]------------
      [   12.384000] WARNING: at fs/proc/generic.c:323
      [   12.436000] Modules linked in:
      [   12.524000]
      [   12.528000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   12.544000] PSW: 00000000000001000000000000001111 Tainted: G        W
      [   12.600000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   12.680000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   12.740000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   12.804000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   12.868000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   12.928000] r20-23  00000000 00000025 104cd858 00000000
      [   12.992000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   13.056000] r28-31  00000028 00000078 4fc40800 0000000d
      [   13.116000] sr00-03  00000000 00000000 00000000 00000000
      [   13.180000] sr04-07  00000000 00000000 00000000 00000000
      [   13.244000]
      [   13.308000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   13.324000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   13.392000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   13.456000]  ORIG_R28: 4fc40940
      [   13.524000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   13.560000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   13.616000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   13.672000] Backtrace:
      [   13.728000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   13.756000]
      [   13.808000] ---[ end trace 91bf6ece17e322de ]---
      [   13.828000] serio: GSC PS/2 mouse port at 0x00020100 irq 19 @ 10:12:8
      Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>
      Acked-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      7bfbeae9
    • G
      parisc: KittyHawk LCD fix · 79a04296
      Guy Martin 提交于
      K class aka KittyHawk don't have LED support on their LCD. Installing
      HP-UX confirmed this. The current led_wq fills the LCD with black
      characters each time it runs.
      
      The patch prevents the led_wq workqueue and its proc entry to be
      created for KittyHawk machines.
      
      It also increase min_cmd_delay as currently, one character out of two
      is lost when a string is sent to the LCD.
      Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.c>
      79a04296