1. 23 10月, 2005 1 次提交
  2. 22 10月, 2005 2 次提交
  3. 21 10月, 2005 8 次提交
  4. 20 10月, 2005 6 次提交
  5. 19 10月, 2005 3 次提交
  6. 18 10月, 2005 8 次提交
    • A
      [PATCH] vesafb: Fix display corruption on display blank · bb7e257e
      Antonino A. Daplas 提交于
      Reported by: Bob Tracy <rct@gherkin.frus.com>
      
       "...I've got a Toshiba notebook (730XCDT -- Pentium 150MMX) for which
        I'm using the Vesa FB driver.  When the machine has been idle for some
        time and the driver attempts to powerdown the display, rather than the
        display going blank, it goes gray with several strange lines.  When I
        hit the "shift" key or other-wise wake up the display, the old video
        state is not fully restored..."
      
      vesafb recently added a blank method which has only 2 states, powerup and
      powerdown.  The powerdown state is used for all blanking levels, but in his
      case, powerdown does not work correctly for higher levels of display
      powersaving. Thus, for intermediate power levels, use software blanking,
      and use only hardware blanking for an explicit powerdown.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb7e257e
    • L
      Add some basic .gitignore files · 1e65174a
      Linus Torvalds 提交于
      This still leaves driver and architecture-specific subdirectories alone,
      but gets rid of the bulk of the "generic" generated files that we should
      ignore.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1e65174a
    • D
      [PATCH] uniput - fix crash on SMP · e7507ed9
      Dmitry Torokhov 提交于
      Only signal completion after marking request slot as free, otherwise other
      processor can free request structure before we finish using it.
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e7507ed9
    • P
      [PATCH] Fix /proc/acpi/events around suspend · 5cc9eeef
      Pavel Machek 提交于
      Fix -EIO on /proc/acpi/events after suspends.  This actually breaks
      suspending by power button in many setups.
      Signed-off-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cc9eeef
    • S
      [PATCH] n_r3964 mod_timer() fix · 9ac0b9c1
      Stephan Brodkorb 提交于
      Since Revision 1.10 was released the n_r3964 module wasn't able to receive any
      data.  The reason for that behavior is because there were some wrong calls of
      mod_timer(...) in the function receive_char (...).  This patch should fix this
      problem and was successfully tested with talking to some kuka industrial
      robots.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ac0b9c1
    • J
      [PATCH] Fix and clean up quirk_intel_ide_combined() configuration · cc675230
      Jeff Garzik 提交于
      This change makes quirk_intel_ide_combined() dependent on the precise
      conditions under which it is needed:
      
      * IDE is built in
      * IDE SATA option is not set
      * ata_piix or ahci drivers are enabled
      
      This fixes an issue where some modular configurations would not cause
      the quirk to be enabled.
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NLinus torvalds <torvalds@osdl.org>
      cc675230
    • C
      [PATCH] USB: fix bug in handling of highspeed usb HID devices · 13b58ee5
      Christian Krause 提交于
      During the development of an USB device I found a bug in the handling of
      Highspeed HID devices in the kernel.
      
      What happened?
      
      Highspeed HID devices are correctly recognized and enumerated by the
      kernel. But even if usbhid kernel module is loaded, no HID reports are
      received by the kernel.
      
      The output of the hardware USB analyzer told me that the host doesn't
      even poll for interrupt IN transfers (even the "interrupt in" USB
      transfer are polled by the host).
      
      After some debugging in hid-core.c I've found the reason.
      
      In case of a highspeed device, the endpoint interval is re-calculated in
      driver/usb/input/hid-core.c:
      
      line 1669:
                   /* handle potential highspeed HID correctly */
                   interval = endpoint->bInterval;
                   if (dev->speed == USB_SPEED_HIGH)
                         interval = 1 << (interval - 1);
      
      Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6).
      This new calculated value of "interval" is used as input for
      usb_fill_int_urb:
      
      line 1685:
      
                  usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0,
                         hid_irq_in, hid, interval);
      
      Unfortunately the same calculation as above is done a second time in
      usb_fill_int_urb in the file include/linux/usb.h:
      
      line 933:
              if (dev->speed == USB_SPEED_HIGH)
                      urb->interval = 1 << (interval - 1);
              else
                      urb->interval = interval;
      
      This means, that if the endpoint descriptor (of a high speed device)
      specifies e.g. bInterval = 7, the urb->interval gets the value:
      
      hid-core.c: interval = 1 << (7-1) = 0x40 = 64
      urb->interval = 1 << (interval -1) = 1 << (63) = integer overflow
      
      Because of this the value of urb->interval is sometimes negative and is
      rejected in core/urb.c:
      line 353:
                      /* too small? */
                      if (urb->interval <= 0)
                              return -EINVAL;
      
      The conclusion is, that the recalculaton of the interval (which is
      necessary for highspeed) should not be made twice, because this is
      simply wrong. ;-)
      
      Re-calculation in usb_fill_int_urb makes more sense, because it is the
      most general approach. So it would make sense to remove it from
      hid-core.c.
      
      Because in hid-core.c the interval variable is only used for calling
      usb_fill_int_urb, it is no problem to remove the highspeed
      re-calculation in this file.
      Signed-off-by: NChristian Krause <chkr@plauener.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      13b58ee5
    • O
      [PATCH] isp116x-hcd: fix handling of short transfers · e9b765de
      Olav Kongas 提交于
      Increased use of scatter-gather by usb-storage driver after 2.6.13 has
      exposed a buggy codepath in isp116x-hcd, which was probably never
      visited before: bug happened only for those urbs, for which
      URB_SHORT_NOT_OK was set AND short transfer occurred.
      
      The fix attached was tested in 2 ways: (a) it fixed failing
      initialization of a flash drive with an embedded hub; (b) the fix was
      tested with 'usbtest' against a modified g_zero driver (on top of
      net2280), which generated short bulk IN transfers of various lengths
      including multiples and non-multiples of max_packet_length.
      Signed-off-by: NOlav Kongas <ok@artecdesign.ee>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e9b765de
  7. 17 10月, 2005 3 次提交
    • R
      [PATCH] fix black/white-only svideo input in vpx3220 decoder · de21eb63
      Ronald S. Bultje 提交于
      Fix the fact that the svideo input will only give input in black/white in
      some circumstances.  Reason is that in the PCI controller driver (zr36067),
      after setting input, we reset norm, which overwrites the input register
      with the default.  This patch makes it always set the correct value for the
      input when changing norm.
      Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      de21eb63
    • R
      [PATCH] fix vpx3220 offset issue in SECAM · 9b3acc21
      Ronald S. Bultje 提交于
      Fix bug #5404 in kernel bugzilla.
      
      It basically updates the vpx3220 initialization tables with some newer
      values that we've had in CVS for a while (and that, for some reason, never
      ended up in the kernel...  must've gotten lost).  Those fix a ~16 pixels
      noise at the top of the picture in at least SECAM, although (now that I
      think about it) PAL was probably affected, also.
      Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9b3acc21
    • S
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault 提交于
      Fix bug 5441.
      
      I didn't know about messy programs like svgatextmode...  Couldn't this be
      integrated in some linux/drivers/video/console/svgacon.c ?...  So because
      of the existence of the svgatextmode program, the kernel is not supposed to
      touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
      
      Disabling the check in vgacon_resize() might help indeed, but I'm really
      not sure whether it will work for any chipset: in my patch, CRT registers
      are set at each console switch, since stty rows/cols apply to consoles
      separately...
      
      The attached solution is to keep the test, but if it fails, we assume that
      the caller knows what it does (i.e.  it is svgatextmode) and then disable
      any further call to vgacon_doresize.  Svgatextmode is usually used to
      _expand_ the display, not to shrink it.  And it is harmless in the case of
      a too big stty rows/cols: the display will just be cropped.  I tested it on
      my laptop, and it works fine with svgatextmode.
      
      A better solution would be that svgatextmode explicitely tells the kernel
      not to care about video timing, but for this an interface needs be defined
      and svgatextmode be patched.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0aec4867
  8. 15 10月, 2005 9 次提交