1. 19 Mar, 2002 9 commits
  2. 18 Mar, 2002 19 commits
  3. 19 Mar, 2002 2 commits
  4. 18 Mar, 2002 1 commit
  5. 17 Mar, 2002 9 commits
    • David Woodhouse's avatar
      Switch cramfs and zisofs from zlib_fs to common zlib. · a2f1b7bc
      David Woodhouse authored
      Remove remnants of zlib_fs.
      a2f1b7bc
    • David Woodhouse's avatar
      Remove jffs2_sb from struct super_block union. · 5bb3575c
      David Woodhouse authored
      Remove FS_REQUIRES_DEV from JFFS2. We never really used the block device anyway.
      5bb3575c
    • David S. Miller's avatar
      Make wanpipe build again after struct sock cleanups. · 5942e595
      David S. Miller authored
      From Arnaldo Carvalho de Melo.
      5942e595
    • David S. Miller's avatar
      Fix netfilter IPv4 conntrack build. · e2a2533d
      David S. Miller authored
      e2a2533d
    • Taisuke Yamada's avatar
      USB printer patch · 90b49267
      Taisuke Yamada authored
      added NEC printer to quirks list
      90b49267
    • Vojtech Pavlik's avatar
      USB HID driver · a0e5d52b
      Vojtech Pavlik authored
        
      Workaround for the ATEN switches
      a0e5d52b
    • Ganesh Varadarajan's avatar
      USB serial drivers · c3cdeb68
      Ganesh Varadarajan authored
      Several functions in the serial drivers can be called from bottom
      half or interrupt context. They must use the GFP_ATOMIC flag for
      calls to kmalloc() and usb_submit_urb().
        
      Functions which must use GFP_ATOMIC:
      1. All *_callback() functions.
      2. Any code which is inside a spinlock.
      3. write(), throttle(), unthrottle(), which may be called by
         the line discipline in bottom half context.
        
      Functions which can use GFP_KERNEL:
      1. open(), close(), startup(), shutdown(), set_termios().
      c3cdeb68
    • Simon Evans's avatar
      USB catc driver · 869de8b7
      Simon Evans authored
        
      Here is a patch to add support for F5U011 to catc.c driver. The
      patch has been compile tested against 2.5.6 and 2.5.7pre1
      (and tested against 2.5.5-dj1) and should apply cleanly.
      869de8b7
    • Paul Stewart's avatar
      USB Urefs for hid-core/hiddev · 36a9bab9
      Paul Stewart authored
        I've written a patch Vojtech and I discussed for enhancing the
      hiddev code to optionally provide more detailed output on read().
      The old functionality is still supported by default, and in
      situations where HID usage codes are unique across reports, the
      old method is still preferable due to its terseness.
          
        The new method provides the ability to determine exactly which
      value has changed, in cases where the HID usage codes are not  
      unique.  It also provides a means to optionally receive notification
      when input reports are received from the device, whether or not
      any of the values in the report have changed.
      
        The details of the changes are as follows:
        
        - All current code behaves identically
      
        - A new ioctl pair HIDIOCGFLAG/HIDIOCSFLAG gets and clears
          flags on the hiddev device.                             
      
        - If you set the flag HIDDEV_FLAG_UREF, the read() call switches
          from reading hiddev_event structures to hiddev_usage_ref
          structures.  The change takes effect immediately, even to
          already queued events that haven't been read() yet.  Here's
          an example of enabling FLAG_UREF:                          
      
          {
              int flag = HIDDEV_FLAG_UREF;
              if (ioctl(fd, HIDIOCSFLAG, &flag) != 0) {
                      perror("ioctl");
                      exit(1);
              }
          }
        
        - With the HIDDEV_FLAG_REPORT set (which is only allowed if
          HIDDEV_FLAG_UREF is also set), there is a special uref that
          will be read() in addition to the ones corresponding to
          changes in the device state: when uref.field_index is set to
          HID_FIELD_INDEX_NONE, this uref is a notification that the
          report referred to by report_type and report_id has been
          received from the device.  This can be useful in situations
          when the notification of the arrival of a report is useful
          even if there is no change in state.
      36a9bab9