Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 8月, 2014 2 次提交
  3. 03 8月, 2014 2 次提交
  5. 01 8月, 2014 5 次提交
  7. 31 7月, 2014 2 次提交
  9. 30 7月, 2014 4 次提交
  11. 29 7月, 2014 2 次提交
  13. 25 7月, 2014 6 次提交
  15. 24 7月, 2014 3 次提交
  17. 23 7月, 2014 1 次提交
  19. 21 7月, 2014 5 次提交
  21. 18 7月, 2014 3 次提交
    • B
      net: huawei_cdc_ncm: add "subclass 3" devices · c2a6c781
      由 Bjørn Mork 提交于 
      Huawei's usage of the subclass and protocol fields is not 100%
clear to us, but there appears to be a very strict system.

A device with the "shared" device ID 12d1:1506 and this NCM
function was recently reported (showing only default altsetting):

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      3
      bInterfaceProtocol     22
      iInterface              8 CDC Network Control Model (NCM)
      ** UNRECOGNIZED:  05 24 00 10 01
      ** UNRECOGNIZED:  06 24 1a 00 01 1f
      ** UNRECOGNIZED:  0c 24 1b 00 01 00 04 10 14 dc 05 20
      ** UNRECOGNIZED:  0d 24 0f 0a 0f 00 00 00 ea 05 03 00 01
      ** UNRECOGNIZED:  05 24 06 01 01
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               9

Cc: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2a6c781
    • B
      net: qmi_wwan: add two Sierra Wireless/Netgear devices · 53433300
      由 Bjørn Mork 提交于 
      Add two device IDs found in an out-of-tree driver downloadable
from Netgear.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53433300
    • D
      wan/x25_asy: integer overflow in x25_asy_change_mtu() · a28d0e87
      由 Dan Carpenter 提交于 
      If "newmtu * 2 + 4" is too large then it can cause an integer overflow
leading to memory corruption.  Eric Dumazet suggests that 65534 is a
reasonable upper limit.

Btw, "newmtu" is not allowed to be a negative number because of the
check in dev_set_mtu(), so that's ok.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a28d0e87
  23. 17 7月, 2014 4 次提交
    • C
      net: ppp: fix creating PPP pass and active filters · cc25eaae
      由 Christoph Schulz 提交于 
      Commit 568f194e ("net: ppp: use
sk_unattached_filter api") inadvertently changed the logic when setting
PPP pass and active filters. This applies to both the generic PPP subsystem
implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP subsystem
implemented by drivers/isdn/i4l/isdn_ppp.c. The original code in ppp_ioctl()
(or isdn_ppp_ioctl(), resp.) handling PPPIOCSPASS and PPPIOCSACTIVE allowed to
remove a pass/active filter previously set by using a filter of length zero.
However, with the new code this is not possible anymore as this case is not
explicitly checked for, which leads to passing NULL as a filter to
sk_unattached_filter_create(). This results in returning EINVAL to the caller.

Additionally, the variables ppp->pass_filter and ppp->active_filter (or
is->pass_filter and is->active_filter, resp.) are not reset to NULL, although
the filters they point to may have been destroyed by
sk_unattached_filter_destroy(), so in this EINVAL case dangling pointers are
left behind (provided the pointers were previously non-NULL).

This patch corrects both problems by checking whether the filter passed is
empty or non-empty, and prevents sk_unattached_filter_create() from being
called in the first case. Moreover, the pointers are always reset to NULL
as soon as sk_unattached_filter_destroy() returns.
Signed-off-by: NChristoph Schulz <develop@kristov.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc25eaae
    • A
      net/mlx4_en: cq->irq_desc wasn't set in legacy EQ's · 858e6c32
      由 Amir Vadai 提交于 
      Fix a regression introduced by commit 35f6f453 ("net/mlx4_en: Don't use
irq_affinity_notifier to track changes in IRQ affinity map").
When core is started in legacy EQ's (number of IRQ's < rx rings), cq->irq_desc
was NULL.  This caused a kernel crash under heavy traffic - when having more
than rx NAPI budget completions.
Fixed to have it set for both EQ modes.
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      858e6c32
    • S
      sunvnet: clean up objects created in vnet_new() on vnet_exit() · a4b70a07
      由 Sowmini Varadhan 提交于 
      Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().
Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: NDave Kleikamp <dave.kleikamp@oracle.com>
Reviewed-by: NKarl Volz <karl.volz@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b70a07
    • M
      r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40 · 7a9810e7
      由 Michel Dänzer 提交于 
      The ethernet port on my ASUS A88X Pro mainboard stopped working
several times a day, with messages like these in dmesg:

AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e address=0x0000000000003000 flags=0x0050]

Searching the web for these messages led me to similar reports about
different hardware supported by r8169, and eventually to commits
3ced8c95 ('r8169: enforce RX_MULTI_EN
for the 8168f.') and eb2dc35d ('r8169:
RxConfig hack for the 8168evl'). So I tried this change, and it fixes
the problem for me.
Signed-off-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a9810e7
  25. 15 7月, 2014 1 次提交
    • O
      hso: fix deadlock when receiving bursts of data · 8f9818af
      由 Olivier Sobrie 提交于 
      When the module sends bursts of data, sometimes a deadlock happens in
the hso driver when the tty buffer doesn't get the chance to be flushed
quickly enough.

Remove the endless while loop in function put_rxbuf_data() which is
called by the urb completion handler.
If there isn't enough room in the tty buffer, discards all the data
received in the URB.

Cc: David Miller <davem@davemloft.net>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jan Dumon <j.dumon@option.com>
Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f9818af