1. 18 12月, 2021 7 次提交
  2. 04 12月, 2021 1 次提交
  3. 03 12月, 2021 10 次提交
    • C
      tty: mips_ejtag_fdc: Make use of the helper function kthread_run_on_cpu() · 13a5fad3
      Cai Huoqing 提交于
      Replace kthread_create/kthread_bind/wake_up_process() with
      kthread_run_on_cpu() to simplify the code.
      Signed-off-by: NCai Huoqing <cai.huoqing@linux.dev>
      Link: https://lore.kernel.org/r/20211202140737.94832-1-cai.huoqing@linux.devSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13a5fad3
    • A
      serial: 8250_bcm7271: UART errors after resuming from S2 · 9cabe26e
      Al Cooper 提交于
      There is a small window in time during resume where the hardware
      flow control signal RTS can be asserted (which allows a sender to
      resume sending data to the UART) but the baud rate has not yet
      been restored. This will cause corrupted data and FRAMING, OVERRUN
      and BREAK errors. This is happening because the MCTRL register is
      shadowed in uart_port struct and is later used during resume to set
      the MCTRL register during both serial8250_do_startup() and
      uart_resume_port(). Unfortunately, serial8250_do_startup()
      happens before the UART baud rate is restored. The fix is to clear
      the shadowed mctrl value at the end of suspend and restore it at the
      end of resume.
      
      Fixes: 41a46948 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NAl Cooper <alcooperx@gmail.com>
      Link: https://lore.kernel.org/r/20211201201402.47446-1-alcooperx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cabe26e
    • L
      serial: amba-pl011: do not request memory region twice · d1180405
      Lino Sanfilippo 提交于
      With commit 3873e2d7 ("drivers: PL011: refactor pl011_probe()") the
      function devm_ioremap() called from pl011_setup_port() was replaced with
      devm_ioremap_resource(). Since this function not only remaps but also
      requests the ports io memory region it now collides with the .config_port()
      callback which requests the same region at uart port registration.
      
      Since devm_ioremap_resource() already claims the memory successfully, the
      request in .config_port() fails.
      
      Later at uart port deregistration the attempt to release the unclaimed
      memory also fails. The failure results in a “Trying to free nonexistent
      resource" warning.
      
      Fix these issues by removing the callbacks that implement the redundant
      memory allocation/release. Also make sure that changing the drivers io
      memory base address via TIOCSSERIAL is not allowed any more.
      
      Fixes: 3873e2d7 ("drivers: PL011: refactor pl011_probe()")
      Signed-off-by: NLino Sanfilippo <LinoSanfilippo@gmx.de>
      Link: https://lore.kernel.org/r/20211129174238.8333-1-LinoSanfilippo@gmx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1180405
    • L
      tty: serial: uartlite: allow 64 bit address · 3672fb65
      Lizhi Hou 提交于
      The base address of uartlite registers could be 64 bit address which is from
      device resource. When ulite_probe() calls ulite_assign(), this 64 bit
      address is casted to 32-bit. The fix is to replace "u32" type with
      "phys_addr_t" type for the base address in ulite_assign() argument list.
      
      Fixes: 8fa7b610 ("[POWERPC] Uartlite: Separate the bus binding from the driver proper")
      Signed-off-by: NLizhi Hou <lizhi.hou@xilinx.com>
      Link: https://lore.kernel.org/r/20211129202302.1319033-1-lizhi.hou@xilinx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3672fb65
    • S
      tty: serial: fsl_lpuart: add timeout for wait_event_interruptible in .shutdown() · ffccc78a
      Sherry Sun 提交于
      Use wait_event_interruptible in lpuart_dma_shutdown isn't a reasonable
      behavior, since it may cause the system hang here if the condition
      !sport->dma_tx_in_progress never to be true in some corner case, such as
      when enable the flow control, the dma tx request may never be completed
      due to the peer's CTS setting when run .shutdown().
      
      So here change to use wait_event_interruptible_timeout instead of
      wait_event_interruptible, the tx dma will be forcibly terminated if the
      tx dma request cannot be completed within 300ms.
      Considering the worst tx dma case is to have a 4K bytes tx buffer, which
      would require about 300ms to complete when the baudrate is 115200.
      Signed-off-by: NSherry Sun <sherry.sun@nxp.com>
      Link: https://lore.kernel.org/r/20211203030441.22873-1-sherry.sun@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffccc78a
    • Z
      usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init() · 37307f70
      Zhou Qingyang 提交于
      In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring
      and there is a dereference of it in cdnsp_endpoint_init(), which could
      lead to a NULL pointer dereference on failure of cdnsp_ring_alloc().
      
      Fix this bug by adding a check of pep->ring.
      
      This bug was found by a static analyzer. The analysis employs
      differential checking to identify inconsistent security operations
      (e.g., checks or kfrees) between two code paths and confirms that the
      inconsistent operations are not recovered in the current function or
      the callers, so they constitute bugs.
      
      Note that, as a bug found by static analysis, it can be a false
      positive or hard to trigger. Multiple researchers have cross-reviewed
      the bug.
      
      Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings,
      and our static analyzer no longer warns about this code.
      
      Fixes: 3d829045 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NPawel Laszczak <pawell@cadence.com>
      Acked-by: NPeter Chen <peter.chen@kernel.org>
      Signed-off-by: NZhou Qingyang <zhou1615@umn.edu>
      Link: https://lore.kernel.org/r/20211130172700.206650-1-zhou1615@umn.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37307f70
    • F
      usb: cdns3: gadget: fix new urb never complete if ep cancel previous requests · 387c2b6b
      Frank Li 提交于
      This issue was found at android12 MTP.
      1. MTP submit many out urb request.
      2. Cancel left requests (>20) when enough data get from host
      3. Send ACK by IN endpoint.
      4. MTP submit new out urb request.
      5. 4's urb never complete.
      
      TRACE LOG:
      
      MtpServer-2157    [000] d..3  1287.150391: cdns3_ep_dequeue: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -115, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:1 SID: 0
      MtpServer-2157    [000] d..3  1287.150410: cdns3_gadget_giveback: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -104, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:0 SID: 0
      MtpServer-2157    [000] d..3  1287.150433: cdns3_ep_dequeue: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -115, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:1 SID: 0
      MtpServer-2157    [000] d..3  1287.150446: cdns3_gadget_giveback: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -104, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:0 SID: 0
      	....
      MtpServer-2157    [000] d..1  1293.630410: cdns3_alloc_request: ep1out: req: 00000000afbccb7d, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0
      MtpServer-2157    [000] d..2  1293.630421: cdns3_ep_queue: ep1out: req: 00000000afbccb7d, req buff 00000000871caf90, length: 0/512 zsi, status: -115, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0
      MtpServer-2157    [000] d..2  1293.630445: cdns3_wa1: WA1: ep1out set guard
      MtpServer-2157    [000] d..2  1293.630450: cdns3_wa1: WA1: ep1out restore cycle bit
      MtpServer-2157    [000] d..2  1293.630453: cdns3_prepare_trb: ep1out: trb 000000007317b3ee, dma buf: 0xffd5bc00, size: 512, burst: 128 ctrl: 0x00000424 (C=0, T=0, ISP, IOC, Normal) SID:0 LAST_SID:0
      MtpServer-2157    [000] d..2  1293.630460: cdns3_doorbell_epx: ep1out, ep_trbaddr ffd50414
      	....
      irq/241-5b13000-2154    [000] d..1  1293.680849: cdns3_epx_irq: IRQ for ep1out: 01000408 ISP , ep_traddr: ffd508ac ep_last_sid: 00000000 use_streams: 0
      irq/241-5b13000-2154    [000] d..1  1293.680858: cdns3_complete_trb: ep1out: trb 0000000021a11b54, dma buf: 0xffd50420, size: 16384, burst: 128 ctrl: 0x00001810 (C=0, T=0, CHAIN, LINK) SID:0 LAST_SID:0
      irq/241-5b13000-2154    [000] d..1  1293.680865: cdns3_request_handled: Req: 00000000afbccb7d not handled, DMA pos: 185, ep deq: 88, ep enq: 185, start trb: 184, end trb: 184
      
      Actually DMA pos already bigger than previous submit request afbccb7d's TRB (184-184). The reason of (not handled) is that deq position is wrong.
      
      The TRB link is below when irq happen.
      
      	DEQ LINK LINK LINK LINK LINK .... TRB(afbccb7d):START  DMA(EP_TRADDR).
      
      Original code check LINK TRB, but DEQ just move one step.
      
      	LINK DEQ LINK LINK LINK LINK .... TRB(afbccb7d):START  DMA(EP_TRADDR).
      
      This patch skip all LINK TRB and sync DEQ to trb's start.
      
      	LINK LINK LINK LINK LINK .... DEQ = TRB(afbccb7d):START  DMA(EP_TRADDR).
      Acked-by: NPeter Chen <peter.chen@kernel.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NFrank Li <Frank.Li@nxp.com>
      Signed-off-by: NJun Li <jun.li@nxp.com>
      Link: https://lore.kernel.org/r/20211130154239.8029-1-Frank.Li@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      387c2b6b
    • B
      usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnect · fbcd13df
      Badhri Jagan Sridharan 提交于
      Stub from the spec:
      "4.5.2.2.4.2 Exiting from AttachWait.SNK State
      A Sink shall transition to Unattached.SNK when the state of both
      the CC1 and CC2 pins is SNK.Open for at least tPDDebounce.
      A DRP shall transition to Unattached.SRC when the state of both
      the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."
      
      This change makes TCPM to wait in SNK_DEBOUNCED state until
      CC1 and CC2 pins is SNK.Open for at least tPDDebounce. Previously,
      TCPM resets the port if vbus is not present in PD_T_PS_SOURCE_ON.
      This causes TCPM to loop continuously when connected to a
      faulty power source that does not present vbus. Waiting in
      SNK_DEBOUNCED also ensures that TCPM is adherant to
      "4.5.2.2.4.2 Exiting from AttachWait.SNK State" requirements.
      
      [ 6169.280751] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected]
      [ 6169.280759] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS]
      [ 6169.280771] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS]
      [ 6169.282427] CC1: 0 -> 0, CC2: 5 -> 5 [state SNK_ATTACH_WAIT, polarity 0, connected]
      [ 6169.450825] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms]
      [ 6169.450834] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS]
      [ 6169.930892] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms]
      [ 6169.931296] disable vbus discharge ret:0
      [ 6169.931301] Setting usb_comm capable false
      [ 6169.932783] Setting voltage/current limit 0 mV 0 mA
      [ 6169.932802] polarity 0
      [ 6169.933706] Requesting mux state 0, usb-role 0, orientation 0
      [ 6169.936689] cc:=0
      [ 6169.936812] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS]
      [ 6169.937157] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected]
      [ 6170.036880] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
      [ 6170.036890] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev2 NONE_AMS]
      [ 6170.036896] Start toggling
      [ 6170.041412] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]
      [ 6170.042973] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected]
      [ 6170.042976] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS]
      [ 6170.042981] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS]
      [ 6170.213014] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms]
      [ 6170.213019] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS]
      [ 6170.693068] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms]
      [ 6170.693304] disable vbus discharge ret:0
      [ 6170.693308] Setting usb_comm capable false
      [ 6170.695193] Setting voltage/current limit 0 mV 0 mA
      [ 6170.695210] polarity 0
      [ 6170.695990] Requesting mux state 0, usb-role 0, orientation 0
      [ 6170.701896] cc:=0
      [ 6170.702181] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS]
      [ 6170.703343] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected]
      
      Fixes: f0690a25 ("staging: typec: USB Type-C Port Manager (tcpm)")
      Cc: stable@vger.kernel.org
      Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
      Link: https://lore.kernel.org/r/20211130001825.3142830-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbcd13df
    • O
      USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub · d2a00403
      Ole Ernst 提交于
      This is another branded 8153 device that doesn't work well with LPM:
      r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71
      
      Disable LPM to resolve the issue.
      Signed-off-by: NOle Ernst <olebowle@gmx.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20211127090546.52072-1-olebowle@gmx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2a00403
    • M
      xhci: Fix commad ring abort, write all 64 bits to CRCR register. · 09f736aa
      Mathias Nyman 提交于
      Turns out some xHC controllers require all 64 bits in the CRCR register
      to be written to execute a command abort.
      
      The lower 32 bits containing the command abort bit is written first.
      In case the command ring stops before we write the upper 32 bits then
      hardware may use these upper bits to set the commnd ring dequeue pointer.
      
      Solve this by making sure the upper 32 bits contain a valid command
      ring dequeue pointer.
      
      The original patch that only wrote the first 32 to stop the ring went
      to stable, so this fix should go there as well.
      
      Fixes: ff0e50d3 ("xhci: Fix command ring pointer corruption while aborting a command")
      Cc: stable@vger.kernel.org
      Tested-by: NPavankumar Kondeti <quic_pkondeti@quicinc.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Link: https://lore.kernel.org/r/20211126122340.1193239-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09f736aa
  4. 02 12月, 2021 22 次提交