Skip to content
Snippets Groups Projects
  1. Dec 07, 2021
  2. Dec 03, 2021
    • Rafael J. Wysocki's avatar
      powercap: DTPM: Drop unused local variable from init_dtpm() · 1ac5e21d
      Rafael J. Wysocki authored
      
      The dtpm_descr variable in init_dtpm() is not used after commit
      f751db8a ("powercap/drivers/dtpm: Disable DTPM at boot time"),
      so drop it.
      
      Fixes: f751db8a ("powercap/drivers/dtpm: Disable DTPM at boot time")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1ac5e21d
    • Al Cooper's avatar
      serial: 8250_bcm7271: UART errors after resuming from S2 · 9cabe26e
      Al Cooper authored
      
      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: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarAl Cooper <alcooperx@gmail.com>
      Link: https://lore.kernel.org/r/20211201201402.47446-1-alcooperx@gmail.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cabe26e
    • Zhou Qingyang's avatar
      usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init() · 37307f70
      Zhou Qingyang authored
      
      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: default avatarPawel Laszczak <pawell@cadence.com>
      Acked-by: default avatarPeter Chen <peter.chen@kernel.org>
      Signed-off-by: default avatarZhou Qingyang <zhou1615@umn.edu>
      Link: https://lore.kernel.org/r/20211130172700.206650-1-zhou1615@umn.edu
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37307f70
    • Frank Li's avatar
      usb: cdns3: gadget: fix new urb never complete if ep cancel previous requests · 387c2b6b
      Frank Li authored
      
      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: default avatarPeter Chen <peter.chen@kernel.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarFrank Li <Frank.Li@nxp.com>
      Signed-off-by: default avatarJun Li <jun.li@nxp.com>
      Link: https://lore.kernel.org/r/20211130154239.8029-1-Frank.Li@nxp.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      387c2b6b
    • Badhri Jagan Sridharan's avatar
      usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnect · fbcd13df
      Badhri Jagan Sridharan authored
      
      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: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarBadhri Jagan Sridharan <badhri@google.com>
      Link: https://lore.kernel.org/r/20211130001825.3142830-1-badhri@google.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbcd13df
    • Ole Ernst's avatar
      USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub · d2a00403
      Ole Ernst authored
      
      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: default avatarOle Ernst <olebowle@gmx.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20211127090546.52072-1-olebowle@gmx.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2a00403
    • Mathias Nyman's avatar
      xhci: Fix commad ring abort, write all 64 bits to CRCR register. · 09f736aa
      Mathias Nyman authored
      
      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: default avatarPavankumar Kondeti <quic_pkondeti@quicinc.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Link: https://lore.kernel.org/r/20211126122340.1193239-2-mathias.nyman@linux.intel.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09f736aa
  3. Dec 02, 2021
  4. Dec 01, 2021
Loading