1. 14 8月, 2012 1 次提交
    • J
      TTY: use tty_port_register_device · 734cc178
      Jiri Slaby 提交于
      Currently we have no way to assign tty->port while performing tty
      installation. There are two ways to provide the link tty_struct =>
      tty_port. Either by calling tty_port_install from tty->ops->install or
      tty_port_register_device called instead of tty_register_device when
      the device is being set up after connected.
      
      In this patch we modify most of the drivers to do the latter. When the
      drivers use tty_register_device and we have tty_port already, we
      switch to tty_port_register_device. So we have the tty_struct =>
      tty_port link for free for those.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      734cc178
  2. 17 7月, 2012 1 次提交
  3. 19 5月, 2012 1 次提交
    • S
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      Sarah Sharp 提交于
      Hub-initiated LPM is not good for USB communications devices.  Comms
      devices should be able to tell when their link can go into a lower power
      state, because they know when an incoming transmission is finished.
      Ideally, these devices would slam their links into a lower power state,
      using the device-initiated LPM, after finishing the last packet of their
      data transfer.
      
      If we enable the idle timeouts for the parent hubs to enable
      hub-initiated LPM, we will get a lot of useless LPM packets on the bus
      as the devices reject LPM transitions when they're in the middle of
      receiving data.  Worse, some devices might blindly accept the
      hub-initiated LPM and power down their radios while they're in the
      middle of receiving a transmission.
      
      The Intel Windows folks are disabling hub-initiated LPM for all USB
      communications devices under a xHCI USB 3.0 host.  In order to keep
      the Linux behavior as close as possible to Windows, we need to do the
      same in Linux.
      
      Set the disable_hub_initiated_lpm flag for for all USB communications
      drivers.  I know there aren't currently any USB 3.0 devices that
      implement these class specifications, but we should be ready if they do.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Jan Dumon <j.dumon@option.com>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Roland Vossen <rvossen@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Kan Yan <kanyan@broadcom.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Daniel Drake <dsd@gentoo.org>
      Cc: Ulrich Kunitz <kune@deine-taler.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1f12eb6
  4. 10 4月, 2012 5 次提交
  5. 09 3月, 2012 1 次提交
  6. 23 2月, 2012 1 次提交
  7. 09 7月, 2011 1 次提交
    • G
      hso: fix a use after free condition · 5e2cd082
      Greg KH 提交于
      This needs to go to netdev:
      
      From: Octavian Purdila <octavian.purdila@intel.com>
      
      In hso_free_net_device hso_net pointer is freed and then used to
      cleanup urb pools. Catched with SLAB_DEBUG during S3 resume:
      
      [   95.824442] Pid: 389, comm: khubd Tainted: G         C  2.6.36greenridge-01400-g423cf13-dirty #154 Type2 - Board Product Name1/OakTrail
      [   95.824442] EIP: 0060:[<c1151551>] EFLAGS: 00010202 CPU: 0
      [   95.824442] EIP is at kref_put+0x29/0x42
      [   95.824442] EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: c2806b40 EDX: 00000037
      [   95.824442] ESI: c1258d56 EDI: edd3d128 EBP: ee8cde0c ESP: ee8cde04
      [   95.824442]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [   95.824442] Process khubd (pid: 389, ti=ee8cc000 task=ee95ed10 task.ti=ee8cc000)
      [   95.824442] Stack:
      [   95.824442]  edd07020 00000000 ee8cde14 c1258b77 ee8cde38 ef933a44 ef93572b ef935dec
      [   95.824442] <0> 0000099a 6b6b6b6b 00000000 ee2da748 edd3e0c0 ee8cde54 ef933b9f ee3b53f8
      [   95.824442] <0> 00000002 ee2da748 ee2da764 ef936658 ee8cde60 ef933d0c ee2da748 ee8cde84
      [   95.824442] Call Trace:
      [   95.824442]  [<c1258b77>] ? usb_free_urb+0x11/0x13
      [   95.824442]  [<ef933a44>] ? hso_free_net_device+0x81/0xd8 [hso]
      [   95.824442]  [<ef933b9f>] ? hso_free_interface+0x104/0x111 [hso]
      [   95.824442]  [<ef933d0c>] ? hso_disconnect+0xb/0x18 [hso]
      [   95.824442]  [<c125b7f1>] ? usb_unbind_interface+0x44/0x14a
      [   95.824442]  [<c11e56e8>] ? __device_release_driver+0x6f/0xb1
      [   95.824442]  [<c11e57c7>] ? device_release_driver+0x18/0x23
      [   95.824442]  [<c11e4e92>] ? bus_remove_device+0x8a/0xa1
      [   95.824442]  [<c11e3970>] ? device_del+0x129/0x163
      [   95.824442]  [<c11e2dc0>] ? put_device+0xf/0x11
      [   95.824442]  [<c11e39bc>] ? device_unregister+0x12/0x15
      [   95.824442]  [<c125915f>] ? usb_disable_device+0x90/0xf0
      [   95.824442]  [<c125544f>] ? usb_disconnect+0x6d/0xf8
      [   95.824442]  [<c1255f91>] ? hub_thread+0x3fc/0xc57
      [   95.824442]  [<c1048526>] ? autoremove_wake_function+0x0/0x2f
      [   95.824442]  [<c102529d>] ? complete+0x34/0x3e
      [   95.824442]  [<c1255b95>] ? hub_thread+0x0/0xc57
      [   95.824442]  [<c10481fc>] ? kthread+0x63/0x68
      [   95.824442]  [<c1048199>] ? kthread+0x0/0x68
      [   95.824442]  [<c1002d76>] ? kernel_thread_helper+0x6/0x10
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e2cd082
  8. 18 2月, 2011 3 次提交
  9. 14 2月, 2011 1 次提交
    • J
      Net, USB, Option, hso: Do not dereference NULL pointer · 5b89db0e
      Jesper Juhl 提交于
      In drivers/net/usb/hso.c::hso_create_bulk_serial_device() we have this
      code:
      ...
      	serial = kzalloc(sizeof(*serial), GFP_KERNEL);
      	if (!serial)
      		goto exit;
      ...
      exit:
      	hso_free_tiomget(serial);
      ...
      hso_free_tiomget() directly dereferences its argument, which in the
      example above is a NULL pointer, ouch.
      I could just add a 'if (serial)' test at the 'exit' label, but since most
      freeing functions in the kernel accept NULL pointers (and it seems like
      this was also assumed here) I opted to instead change 'hso_free_tiomget()'
      so that it is safe to call it with a NULL argument. I also modified the
      function to get rid of a pointles conditional before the call to
      'usb_free_urb()' since that function already tests for NULL itself -
      besides fixing the NULL deref this change also buys us a few bytes in
      size.
      Before:
      $ size drivers/net/usb/hso.o
         text    data     bss     dec     hex filename
        32200     592    9960   42752    a700 drivers/net/usb/hso.o
      After:
      $ size drivers/net/usb/hso.o
         text    data     bss     dec     hex filename
        32196     592    9960   42748    a6fc drivers/net/usb/hso.o
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b89db0e
  10. 21 12月, 2010 1 次提交
  11. 10 12月, 2010 1 次提交
  12. 29 11月, 2010 1 次提交
  13. 16 11月, 2010 1 次提交
  14. 23 10月, 2010 1 次提交
  15. 17 9月, 2010 1 次提交
  16. 17 8月, 2010 1 次提交
  17. 04 8月, 2010 1 次提交
  18. 13 7月, 2010 1 次提交
  19. 23 6月, 2010 1 次提交
  20. 03 6月, 2010 1 次提交
  21. 26 5月, 2010 1 次提交
  22. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      Joe Perches 提交于
      This patch removes from drivers/net/ all the unnecessary
      return; statements that precede the last closing brace of
      void functions.
      
      It does not remove the returns that are immediately
      preceded by a label as gcc doesn't like that.
      
      It also does not remove null void functions with return.
      
      Done via:
      $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
        xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'
      
      with some cleanups by hand.
      
      Compile tested x86 allmodconfig only.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  23. 10 5月, 2010 1 次提交
  24. 16 3月, 2010 1 次提交
  25. 07 1月, 2010 6 次提交
  26. 04 12月, 2009 1 次提交
  27. 24 11月, 2009 2 次提交
  28. 12 9月, 2009 1 次提交
    • M
      net: Add DEVTYPE support for Ethernet based devices · 384912ed
      Marcel Holtmann 提交于
      The Ethernet framing is used for a lot of devices these days. Most
      prominent are WiFi and WiMAX based devices. However for userspace
      application it is important to classify these devices correctly and
      not only see them as Ethernet devices. The daemons like HAL, DeviceKit
      or even NetworkManager with udev support tries to do the classification
      in userspace with a lot trickery and extra system calls. This is not
      good and actually reaches its limitations. Especially since the kernel
      does know the type of the Ethernet device it is pretty stupid.
      
      To solve this problem the underlying device type needs to be set and
      then the value will be exported as DEVTYPE via uevents and available
      within udev.
      
        # cat /sys/class/net/wlan0/uevent
        DEVTYPE=wlan
        INTERFACE=wlan0
        IFINDEX=5
      
      This is similar to subsystems like USB and SCSI that distinguish
      between hosts, devices, disks, partitions etc.
      
      The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
      device type. All device types are free form, but for convenience the
      same strings as used with RFKILL are choosen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      384912ed