1. 23 1月, 2020 9 次提交
  2. 21 1月, 2020 1 次提交
  3. 15 1月, 2020 2 次提交
  4. 14 1月, 2020 1 次提交
  5. 08 1月, 2020 1 次提交
  6. 16 12月, 2019 1 次提交
  7. 13 12月, 2019 1 次提交
  8. 10 12月, 2019 1 次提交
  9. 28 11月, 2019 1 次提交
  10. 27 11月, 2019 2 次提交
  11. 25 11月, 2019 1 次提交
  12. 23 11月, 2019 1 次提交
    • H
      r8152: avoid to call napi_disable twice · 5b1d9c17
      Hayes Wang 提交于
      Call napi_disable() twice would cause dead lock. There are three situations
      may result in the issue.
      
      1. rtl8152_pre_reset() and set_carrier() are run at the same time.
      2. Call rtl8152_set_tunable() after rtl8152_close().
      3. Call rtl8152_set_ringparam() after rtl8152_close().
      
      For #1, use the same solution as commit 84811412 ("r8152: Re-order
      napi_disable in rtl8152_close"). For #2 and #3, add checking the flag
      of IFF_UP and using napi_disable/napi_enable during mutex.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b1d9c17
  13. 21 11月, 2019 1 次提交
    • P
      r8152: Re-order napi_disable in rtl8152_close · 84811412
      Prashant Malani 提交于
      Both rtl_work_func_t() and rtl8152_close() call napi_disable().
      Since the two calls aren't protected by a lock, if the close
      function starts executing before the work function, we can get into a
      situation where the napi_disable() function is called twice in
      succession (first by rtl8152_close(), then by set_carrier()).
      
      In such a situation, the second call would loop indefinitely, since
      rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED
      bit.
      
      The rtl8152_close() function in turn issues a
      cancel_delayed_work_sync(), and so it would wait indefinitely for the
      rtl_work_func_t() to complete. Since rtl8152_close() is called by a
      process holding rtnl_lock() which is requested by other processes, this
      eventually leads to a system deadlock and crash.
      
      Re-order the napi_disable() call to occur after the work function
      disabling and urb cancellation calls are issued.
      
      Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e
      Reported-by: http://crbug.com/1017928Signed-off-by: NPrashant Malani <pmalani@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84811412
  14. 16 11月, 2019 1 次提交
  15. 14 11月, 2019 2 次提交
  16. 08 11月, 2019 2 次提交
    • A
      net: usb: qmi_wwan: add support for DW5821e with eSIM support · e497df68
      Aleksander Morgado 提交于
      Exactly same layout as the default DW5821e module, just a different
      vid/pid.
      
      The QMI interface is exposed in USB configuration #1:
      
      P:  Vendor=413c ProdID=81e0 Rev=03.18
      S:  Manufacturer=Dell Inc.
      S:  Product=DW5821e-eSIM Snapdragon X20 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e497df68
    • O
      CDC-NCM: handle incomplete transfer of MTU · 332f989a
      Oliver Neukum 提交于
      A malicious device may give half an answer when asked
      for its MTU. The driver will proceed after this with
      a garbage MTU. Anything but a complete answer must be treated
      as an error.
      
      V2: used sizeof as request by Alexander
      
      Reported-and-tested-by: syzbot+0631d878823ce2411636@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      332f989a
  17. 06 11月, 2019 1 次提交
  18. 29 10月, 2019 1 次提交
    • D
      net: usb: lan78xx: Disable interrupts before calling generic_handle_irq() · 0a29ac5b
      Daniel Wagner 提交于
      lan78xx_status() will run with interrupts enabled due to the change in
      ed194d13 ("usb: core: remove local_irq_save() around ->complete()
      handler"). generic_handle_irq() expects to be run with IRQs disabled.
      
      [    4.886203] 000: irq 79 handler irq_default_primary_handler+0x0/0x8 enabled interrupts
      [    4.886243] 000: WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:152 __handle_irq_event_percpu+0x154/0x168
      [    4.896294] 000: Modules linked in:
      [    4.896301] 000: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.6 #39
      [    4.896310] 000: Hardware name: Raspberry Pi 3 Model B+ (DT)
      [    4.896315] 000: pstate: 60000005 (nZCv daif -PAN -UAO)
      [    4.896321] 000: pc : __handle_irq_event_percpu+0x154/0x168
      [    4.896331] 000: lr : __handle_irq_event_percpu+0x154/0x168
      [    4.896339] 000: sp : ffff000010003cc0
      [    4.896346] 000: x29: ffff000010003cc0 x28: 0000000000000060
      [    4.896355] 000: x27: ffff000011021980 x26: ffff00001189c72b
      [    4.896364] 000: x25: ffff000011702bc0 x24: ffff800036d6e400
      [    4.896373] 000: x23: 000000000000004f x22: ffff000010003d64
      [    4.896381] 000: x21: 0000000000000000 x20: 0000000000000002
      [    4.896390] 000: x19: ffff8000371c8480 x18: 0000000000000060
      [    4.896398] 000: x17: 0000000000000000 x16: 00000000000000eb
      [    4.896406] 000: x15: ffff000011712d18 x14: 7265746e69206465
      [    4.896414] 000: x13: ffff000010003ba0 x12: ffff000011712df0
      [    4.896422] 000: x11: 0000000000000001 x10: ffff000011712e08
      [    4.896430] 000: x9 : 0000000000000001 x8 : 000000000003c920
      [    4.896437] 000: x7 : ffff0000118cc410 x6 : ffff0000118c7f00
      [    4.896445] 000: x5 : 000000000003c920 x4 : 0000000000004510
      [    4.896453] 000: x3 : ffff000011712dc8 x2 : 0000000000000000
      [    4.896461] 000: x1 : 73a3f67df94c1500 x0 : 0000000000000000
      [    4.896466] 000: Call trace:
      [    4.896471] 000:  __handle_irq_event_percpu+0x154/0x168
      [    4.896481] 000:  handle_irq_event_percpu+0x50/0xb0
      [    4.896489] 000:  handle_irq_event+0x40/0x98
      [    4.896497] 000:  handle_simple_irq+0xa4/0xf0
      [    4.896505] 000:  generic_handle_irq+0x24/0x38
      [    4.896513] 000:  intr_complete+0xb0/0xe0
      [    4.896525] 000:  __usb_hcd_giveback_urb+0x58/0xd8
      [    4.896533] 000:  usb_giveback_urb_bh+0xd0/0x170
      [    4.896539] 000:  tasklet_action_common.isra.0+0x9c/0x128
      [    4.896549] 000:  tasklet_hi_action+0x24/0x30
      [    4.896556] 000:  __do_softirq+0x120/0x23c
      [    4.896564] 000:  irq_exit+0xb8/0xd8
      [    4.896571] 000:  __handle_domain_irq+0x64/0xb8
      [    4.896579] 000:  bcm2836_arm_irqchip_handle_irq+0x60/0xc0
      [    4.896586] 000:  el1_irq+0xb8/0x140
      [    4.896592] 000:  arch_cpu_idle+0x10/0x18
      [    4.896601] 000:  do_idle+0x200/0x280
      [    4.896608] 000:  cpu_startup_entry+0x20/0x28
      [    4.896615] 000:  rest_init+0xb4/0xc0
      [    4.896623] 000:  arch_call_rest_init+0xc/0x14
      [    4.896632] 000:  start_kernel+0x454/0x480
      
      Fixes: ed194d13 ("usb: core: remove local_irq_save() around ->complete() handler")
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stefan Wahren <wahrenst@gmx.net>
      Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NDaniel Wagner <dwagner@suse.de>
      Tested-by: NStefan Wahren <wahrenst@gmx.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a29ac5b
  19. 26 10月, 2019 1 次提交
    • H
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      Hayes Wang 提交于
      Fix the pointer rtl_fw->fw would be used before checking in
      rtl8152_apply_firmware() that causes the following kernel oops.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000002
      pgd = (ptrval)
      [00000002] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 131 Comm: kworker/0:2 Not tainted
      5.4.0-rc1-00539-g9370f2d0 #6788
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events_long rtl_hw_phy_work_func_t
      PC is at rtl8152_apply_firmware+0x14/0x464
      LR is at r8153_hw_phy_cfg+0x24/0x17c
      pc : [<c064f4e4>]    lr : [<c064fa18>]    psr: a0000013
      sp : e75c9e60  ip : 60000013  fp : c11b7614
      r10: e883b91c  r9 : 00000000  r8 : fffffffe
      r7 : e883b640  r6 : fffffffe  r5 : fffffffe  r4 : e883b640
      r3 : 736cfe7c  r2 : 736cfe7c  r1 : 000052f8  r0 : e883b640
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6640006a  DAC: 00000051
      Process kworker/0:2 (pid: 131, stack limit = 0x(ptrval))
      Stack: (0xe75c9e60 to 0xe75ca000)
      ...
      [<c064f4e4>] (rtl8152_apply_firmware) from [<c064fa18>]
      (r8153_hw_phy_cfg+0x24/0x17c)
      [<c064fa18>] (r8153_hw_phy_cfg) from [<c064e784>]
      (rtl_hw_phy_work_func_t+0x220/0x3e4)
      [<c064e784>] (rtl_hw_phy_work_func_t) from [<c0148a74>]
      (process_one_work+0x22c/0x7c8)
      [<c0148a74>] (process_one_work) from [<c0149054>] (worker_thread+0x44/0x520)
      [<c0149054>] (worker_thread) from [<c0150548>] (kthread+0x130/0x164)
      [<c0150548>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xe75c9fb0 to 0xe75c9ff8)
      ...
      
      Fixes: 9370f2d0 ("r8152: support request_firmware for RTL8153")
      Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e484ebb
  20. 24 10月, 2019 1 次提交
  21. 23 10月, 2019 4 次提交
  22. 22 10月, 2019 1 次提交
  23. 19 10月, 2019 1 次提交
  24. 18 10月, 2019 1 次提交
  25. 17 10月, 2019 1 次提交
    • H
      r8152: support request_firmware for RTL8153 · 9370f2d0
      Hayes Wang 提交于
      This patch supports loading additional firmware file through
      request_firmware().
      
      A firmware file may include a header followed by several blocks
      which have different types of firmware. Currently, the supported
      types are RTL_FW_END, RTL_FW_PLA, and RTL_FW_USB.
      
      The firmware is used to fix some compatible or hardware issues. For
      example, the device couldn't be found after rebooting several times.
      
      The supported chips are
      	RTL_VER_04 (rtl8153a-2.fw)
      	RTL_VER_05 (rtl8153a-3.fw)
      	RTL_VER_06 (rtl8153a-4.fw)
      	RTL_VER_09 (rtl8153b-2.fw)
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Reviewed-by: NPrashant Malani <pmalani@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9370f2d0