- 04 Jan, 2024 33 commits
-
-
Chunfeng Yun authored
Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in transfer issue which send out unexpected ACK even after device already finished the burst transfer with a short patcket, specially for a 4K camera device. Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20240104061640.7335-3-chunfeng.yun@mediatek.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chunfeng Yun authored
For Gen1 isoc-in transfer, host still send out unexpected ACK after device finish the burst with a short packet, this will cause an exception on the connected device, such as, a usb 4k camera. It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use 3k here, the side-effect is that may cause performance drop about 10%, including bulk transfer. Fixes: 926d60ae ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195") Reviewed-by:
-
Chunfeng Yun authored
For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it still send out unexpected ACK after receiving a short packet in burst transfer, this will cause an exception on connected device, specially for a 4k camera. Add a quirk property "rx-fifo-depth" to work around this hardware issue, prefer to use 3k bytes; The side-effect is that it may cause performance drop about 10%, including bulk transfer. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Konrad Dybcio authored
The PNoC clock is a clock for the entire PNoC bus, managed from within the interconnect driver. Attaching it to MSS was a total hack. Get rid of it and take the liberty to make the clock-names entries more readable. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230721-topic-rpm_clk_cleanup-v3-9-a66e698932e3@linaro.orgSigned-off-by:
-
Konrad Dybcio authored
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from within the interconnect driver. Attaching it to SLPI was a total hack. Get rid of it. Signed-off-by:
-
Konrad Dybcio authored
The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from within the interconnect driver. Attaching it to SLPI was a total hack. Get rid of it. Signed-off-by:
-
Konrad Dybcio authored
Some nodes are abusingly referencing some of the internal bus clocks, that were recently removed in Linux (because the original implementation did not make much sense), managing them as if they were the only devices on an NoC bus. These clocks are now handled from within the icc framework and are no longer registered from within the CCF. Remove them. Reviewed-by:
-
Konrad Dybcio authored
Some nodes are abusingly referencing some of the internal bus clocks, that were recently removed in Linux (because the original implementation did not make much sense), managing them as if they were the only devices on an NoC bus. These clocks are now handled from within the icc framework and are no longer registered from within the CCF. Remove them. Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
-
Konrad Dybcio authored
Some nodes are abusingly referencing some of the internal bus clocks, that were recently removed in Linux (because the original implementation did not make much sense), managing them as if they were the only devices on an NoC bus. These clocks are now handled from within the icc framework and are no longer registered from within the CCF. Remove them. Signed-off-by:
-
Konrad Dybcio authored
Some nodes are abusingly referencing some of the internal bus clocks, that were recently removed in Linux (because the original implementation did not make much sense), managing them as if they were the only devices on an NoC bus. These clocks are now handled from within the icc framework and are no longer registered from within the CCF. Remove them. Signed-off-by:
-
Konrad Dybcio authored
Some nodes are abusingly referencing some of the internal bus clocks, that were recently removed in Linux (because the original implementation did not make much sense), managing them as if they were the only devices on an NoC bus. These clocks are now handled from within the icc framework and are no longer registered from within the CCF. Remove them. Signed-off-by:
-
Konrad Dybcio authored
SDM660 was abusingly referencing one of the internal bus clocks, that were recently dropped from Linux (because the original implementation did not make much sense), circumventing the interconnect framework. Drop it. Signed-off-by:
-
Krishna Kurapati authored
For wakeup to work, driver needs to enable interrupts that depict what is happening on the DP/DM lines. On QUSB targets, this is identified by qusb2_phy whereas on SoCs using Femto PHY, separate {dp,dm}_hs_phy_irq's are used instead. The implementation incorrectly names qusb2_phy interrupts as "hs_phy_irq". Clean this up so that driver would be using only qusb2/(dp & dm) for wakeup purposes. For devices running older kernels, this won't break any functionality because the interrupt configurations in QUSB2 PHY based SoCs is done by configuring QUSB2PHY_INTR_CTRL register in PHY address space and it was never armed properly right from the start. Signed-off-by:Krishna Kurapati <quic_kriskura@quicinc.com> Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20231227091951.685-3-quic_kriskura@quicinc.comSigned-off-by:
-
Krishna Kurapati authored
The high speed related interrupts present on QC targets are as follows: 1. dp/dm irq's These IRQ's directly reflect changes on the DP/DM pads of the SoC. These are used as wakeup interrupts only on SoCs with non-QUSB2 targets with exception of SDM670/SDM845/SM6350. 2. qusb2_phy irq SoCs with QUSB2 PHY do not have separate DP/DM IRQs and expose only a single IRQ whose behavior can be modified by the QUSB2PHY_INTR_CTRL register. The required DPSE/DMSE configuration is done in QUSB2PHY_INTR_CTRL register of phy address space. 3. hs_phy_irq This is completely different from the above two and is present on all targets with exception of a few IPQ ones. The interrupt is not enabled by default and its functionality is mutually exclusive of qusb2_phy on QUSB targets and DP/DM on femto phy targets. The DTs of several QUSB2 PHY based SoCs incorrectly define "hs_phy_irq" when they should have been "qusb2_phy_irq". On Femto phy targets, the "hs_phy_irq" mentioned is either the actual "hs_phy_irq" or "pwr_event", neither of which would never be triggered directly are non-functional currently. The implementation tries to clean up this issue by addressing the discrepencies involved and fixing the hs_phy_irq's in respective DT's. Classify SoC's into four groups based on whether qusb2_phy interrupt or {dp/dm}_hs_phy_irq is used for wakeup in high speed and whether the SoCs have hs_phy_irq present in them or not. The ss_phy_irq is optional interrupt because there are mutliple SoC's which either support only High Speed or there are multiple controllers within same Soc and the secondary controller is High Speed only capable. This breaks ABI on targets running older kernels, but since the interrupt definitions are given wrong on many targets and to establish proper rules for usage of DWC3 interrupts on Qualcomm platforms, DT binding update is necessary. The bindings put pwr_event as the first interrupt and ss_phy as the last. Since all SoCs have the pwr_event (HS) interrupt, but not all controllers have the SS PHY interrupt, this would prevent, to some extent, expressing that the SS PHY is optional by keeping it last in the binding schema and making sure that minItems = maxItems - 1. No new targets have been added to schema. Only the existing ones have been re-ordered. Signed-off-by: -
Richard Acayan authored
In 6.7-rc1, there was a netif_device_detach call added to the gether_disconnect function. This clears the __LINK_STATE_PRESENT bit of the netif device and suppresses pings (ICMP messages) and TCP connection requests from the connected host. If userspace temporarily disconnects the gadget, such as by temporarily removing configuration in the gadget configfs interface, network activity should continue to be processed when the gadget is re-connected. Mirror the netif_device_detach call with a netif_device_attach call in gether_connect to fix re-connecting gadgets. Link: https://gitlab.com/postmarketOS/pmaports/-/tree/6002e51b7090aeeb42947e0ca7ec22278d7227d0/main/postmarketos-base-ui/rootfs-usr-lib-NetworkManager-dispatcher.d-50-tethering.sh Cc: stable <stable@kernel.org> Fixes: f49449fb ("usb: gadget: u_ether: Replace netif_stop_queue with netif_device_detach") Signed-off-by:
Richard Acayan <mailingradian@gmail.com> Tested-by:
Luca Weiss <luca@z3ntu.xyz> Tested-by:
Duje Mihanović <duje.mihanovic@skole.hr> Link: https://lore.kernel.org/r/20231218164532.411125-2-mailingradian@gmail.comSigned-off-by:
-
Wesley Cheng authored
There is a scenario where DWC3 runtime suspend is blocked due to the dwc->connected flag still being true while PM usage_count is zero after DWC3 giveback is completed and the USB gadget session is being terminated. This leads to a case where nothing schedules a PM runtime idle for the device. The exact condition is seen with the following sequence: 1. USB bus reset is issued by the host 2. Shortly after, or concurrently, a USB PD DR SWAP request is received (sink->source) 3. USB bus reset event handler runs and issues dwc3_stop_active_transfers(), and pending transfer are stopped 4. DWC3 usage_count decremented to 0, and runtime idle occurs while dwc->connected == true, returns -EBUSY 5. DWC3 disconnect event seen, dwc->connected set to false due to DR swap handling 6. No runtime idle after this point Address this by issuing an asynchronous PM runtime idle call after the disconnect event is completed, as it modifies the dwc->connected flag, which is what blocks the initial runtime idle. Fixes: fc8bb91b ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by:Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20240103214946.2596-1-quic_wcheng@quicinc.comSigned-off-by:
-
Xu Yang authored
When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return false. This behaviour is wrong. Since phy.last_event will always be set for either host or device mode. Therefore, CONFIG_USB_OTG condition can be removed. Fixes: 5eda42ae ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()") cc: <stable@vger.kernel.org> Acked-by:
Peter Chen <peter.chen@kernel.org> Signed-off-by:
Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20231228110753.1755756-3-xu.yang_2@nxp.comSigned-off-by:
-
Xu Yang authored
After the chipidea driver introduce extcon for id and vbus, it's able to wakeup from another irq source, in case the system with extcon ID cable, wakeup from usb ID cable and device removal, the usb device disconnect irq may come firstly before the extcon notifier while system resume, so we will get 2 "wakeup" irq, one for usb device disconnect; and one for extcon ID cable change(real wakeup event), current driver treat them as 2 successive wakeup irq so can't handle it correctly, then finally the usb irq can't be enabled. This patch adds a check to bypass further usb events before controller resume finished to fix it. Fixes: 1f874edc ("usb: chipidea: add runtime power management support") cc: <stable@vger.kernel.org> Acked-by:
Li Jun <jun.li@nxp.com> Link: https://lore.kernel.org/r/20231228110753.1755756-2-xu.yang_2@nxp.comSigned-off-by:
-
Xu Yang authored
Some platform using ChipIdea IP may keep 32KHz wakeup clock always on without usb driver intervention. And some may need driver to handle this clock. For now only i.MX93 needs this wakeup clock. This patch will get wakeup clock and keep it always on to make controller work properly. Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20231228110753.1755756-1-xu.yang_2@nxp.comSigned-off-by:
-
Frank Li authored
This reverts commit 3c5b006f. gadget_is_{super|dual}speed() API check UDC controller capitblity. It should pass down highest speed endpoint descriptor to UDC controller. So UDC controller driver can reserve enough resource at check_config(), especially mult and maxburst. So UDC driver (such as cdns3) can know need at least (mult + 1) * (maxburst + 1) * wMaxPacketSize internal memory for this uvc functions. Cc: <stable@vger.kernel.org> Signed-off-by:
Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20231224153816.1664687-5-Frank.Li@nxp.comSigned-off-by:
-
Frank Li authored
Supposed DMA cross 4k bounder problem should be fixed at DEV_VER_V2, but still met problem when do ISO transfer if sg enabled. Data pattern likes below when sg enabled, package size is 1k and mult is 2 [UVC Header(8B) ] [data(3k - 8)] ... The received data at offset 0xd000 will get 0xc000 data, len 0x70. Error happen position as below pattern: 0xd000: wrong 0xe000: wrong 0xf000: correct 0x10000: wrong 0x11000: wrong 0x12000: correct ... To avoid DMA cross 4k bounder at ISO transfer, reduce burst len according to start DMA address's alignment. Cc: <stable@vger.kernel.org> Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by:
-
Frank Li authored
ISO basic transfer is ITP(SOF) Package_0 Package_1 ... Package_n CDNS3 DMA start dma transfer from memmory to internal FIFO when get SOF, controller will transfer data to usb bus from internal FIFO when get IN token. According USB spec defination: Maximum number of packets = (bMaxBurst + 1) * (Mult + 1) Internal memory should be the same as (bMaxBurst + 1) * (Mult + 1). DMA don't fetch data advance when ISO transfer, so only reserve (bMaxBurst + 1) * (Mult + 1) internal memory for ISO transfer. Need save Mult and bMaxBurst information and set it into EP_CFG register, otherwise only 1 package is sent by controller, other package will be lost. Cc: <stable@vger.kernel.org> Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by:
-
Frank Li authored
When IP version >= DEV_VER_V2, gadget:sg_supported is true. So uvc gadget function driver will use sg to equeue data, first is 8bytes header, the second is 1016bytes data. cdns3_prepare_trb: ep2in: trb 0000000000ac755f, dma buf: 0xbf455000, size: 8, burst: 128 ctrl: 0x00000415 (C=1, T=0, ISP, CHAIN, Normal) cdns3_prepare_trb: ep2in: trb 00000000a574e693, dma buf: 0xc0200fe0, size: 1016, burst: 128 ctrl: 0x00000405 (C=1, T=0, ISP, Normal) But cdns3_ep_run_transfer() can't correctly handle this case, which only support one TRB for ISO transfer. The controller requires duplicate the TD for each SOF if priv_ep->interval is not 1. DMA will read data from DDR to internal FIFO when get SOF. Send data to bus when receive IN token. DMA always refill FIFO when get SOF regardless host send IN token or not. If host send IN token later, some frames data will be lost. Fixed it by below major steps: 1. Calculate numembers of TRB base on sg_nums and priv_ep->interval. 2. Remove CHAIN flags for each end TRB of TD when duplicate TD. 3. The controller requires LINK TRB must be first TRB of TD. When check there are not enough TRBs lefts, just fill LINK TRB for left TRBs. .... CHAIN_TRB DATA_TRB, CHAIN_TRB DATA_TRB, LINK_TRB ... LINK_TRB ^End of TRB List Cc: <stable@vger.kernel.org> Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: -
Krishna Kurapati authored
The max segment size is currently limited to the ethernet frame length of the kernel which happens to be 1514 at this point in time. However the NCM specification limits it to 64K for sixtenn bit NTB's. For peer to peer connections, increasing the segment size gives better throughput. Add support to configure this value before configfs symlink is created. Also since the NTB Out/In buffer sizes are fixed at 16384 bytes, limit the segment size to an upper cap of 8000 to allow at least a minimum of 2 MTU sized datagrams to be aggregated. Set the default MTU size for the ncm interface during function bind before network interface is registered allowing MTU to be set in parity with wMaxSegmentSize. Update gadget documentation describing the new configfs property. Signed-off-by:
-
Frank Wang authored
For device mode, if PM runtime autosuspend feature enabled, the runtime power status of dwc3 may be suspended when run dwc3_resume(), and dwc3 gadget would not be configured in dwc3_gadget_run_stop(). It would cause gadget connected failed if USB cable has been plugged before PM resume. So move forward pm_runtime_set_active() to fix it. Signed-off-by:
Frank Wang <frank.wang@rock-chips.com> Link: https://lore.kernel.org/r/20231206065939.16958-1-frank.wang@rock-chips.comSigned-off-by:
-
Manan Aurora authored
Support configuration and use of bulk endpoints in the so-called EBC mode described in the DBC_usb31 databook (appendix E) Added a bit fifo_mode to usb_ep to indicate to the UDC driver that a specific endpoint is to operate in the EBC (or equivalent) mode when enabled Added macros for bits 15 and 14 of DEPCFG parameter 1 to indicate EBC mode and write back behaviour. These bits will be set to 1 when configuring an EBC endpoint as described in the programming guide Signed-off-by:
Manan Aurora <maurora@google.com> Link: https://lore.kernel.org/r/20231031034641.660606-1-maurora@google.comSigned-off-by:
-
Kyle Tso authored
Refactor tcpm_fw_get_caps to support the multiple pd capabilities got from fwnode. For backward compatibility, the original single capability is still applicable. The fetched data is stored in the newly defined structure "pd_data" and there is an array "pd_list" to store the pointers to them. A dedicated array "pds" is used to store the handles of the registered usb_power_delivery instances. Also implement the .pd_get and .pd_set ops which are introduced in commit a7cff92f ("usb: typec: USB Power Delivery helpers for ports and partners"). Once the .pd_set is called, the current capability will be updated and state machine will re-negotiate the power contract if possible. Signed-off-by:
Kyle Tso <kyletso@google.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231216104630.2720818-3-kyletso@google.comSigned-off-by:
-
Kyle Tso authored
Commit 662a6010 ("usb: typec: Separate USB Power Delivery from USB Type-C") allows userspace to configure the PD of a port by selecting different set of predefined PD capabilities. Define the PD capability sets in DT for better configurability in device modules. Define an optional child node "capabilities" to contain multiple USB Power Delivery capabilities. Define child nodes with pattern (e.g. caps-0, caps-1) under "capabilities". Each node contains PDO data of a selectable Power Delivery capability. Also define common properties for source-pdos, sink-pdos, and op-sink-microwatt that can be referenced. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231216104630.2720818-2-kyletso@google.comSigned-off-by:
-
Yinbo Zhu authored
The xhci retaining bogus hardware states cause usb disconnect devices connected before hibernation(s4) and refer to the commit 'f3d47885 ("usb: ohci-platform: fix usb disconnect issue after s4")' which set flag "hibernated" as true when resume-from-hibernation and that the drivers will reset the hardware to get rid of any existing state and make sure resume from hibernation re-enumerates everything for xhci. Signed-off-by:
Yinbo Zhu <zhuyinbo@loongson.cn> Link: https://lore.kernel.org/r/20231228071113.1719-1-zhuyinbo@loongson.cnSigned-off-by:
-
Krishna Kurapati authored
Currently for dwc3_usb31 controller, if maximum_speed is limited to super-speed in DT, then device mode is limited to SS, but host mode still works in SSP. The documentation for max-speed property is as follows: "Tells USB controllers we want to work up to a certain speed. Incase this isn't passed via DT, USB controllers should default to their maximum HW capability." It doesn't specify that the property is only for device mode. There are cases where we need to limit the host's maximum speed to SuperSpeed only. Use this property for host mode to contrain host's speed to SuperSpeed. Signed-off-by:
-
Uttkarsh Aggarwal authored
Current implementation blocks the running operations when Plug-out and Plug-In is performed continuously, process gets stuck in dwc3_thread_interrupt(). Code Flow: CPU1 ->Gadget_start ->dwc3_interrupt ->dwc3_thread_interrupt ->dwc3_process_event_buf ->dwc3_process_event_entry ->dwc3_endpoint_interrupt ->dwc3_ep0_interrupt ->dwc3_ep0_inspect_setup ->dwc3_ep0_stall_and_restart By this time if pending_list is not empty, it will get the next request on the given list and calls dwc3_gadget_giveback which will unmap request and call its complete() callback to notify upper layers that it has completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET, whereas it should be -ESHUTDOWN based on condition if not dwc->connected is true. Cc: <stable@vger.kernel.org> Fixes: d742220b ("usb: dwc3: ep0: giveback requests on stall_and_restart") Signed-off-by:
Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com> Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.comSigned-off-by:
-
Kevin Hao authored
A freezable kernel thread can enter frozen state during freezing by either calling try_to_freeze() or using wait_event_freezable() and its variants. So for the following snippet of code in a kernel thread loop: wait_event_interruptible_timeout(); try_to_freeze(); We can change it to a simple wait_event_freezable_timeout() and then eliminate a function call. Signed-off-by:
Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20231218074730.1898699-1-haokexin@gmail.comSigned-off-by:
-
Wesley Cheng authored
Current EP0 dequeue path will share the same as other EPs. However, there are some special considerations that need to be made for EP0 transfers: - EP0 transfers never transition into the started_list - EP0 only has one active request at a time In case there is a vendor specific control message for a function over USB FFS, then there is no guarantee on the timeline which the DATA/STATUS stage is responded to. While this occurs, any attempt to end transfers on non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and defer issuing of the end transfer command. If the USB FFS application decides to timeout the control transfer, or if USB FFS AIO path exits, the USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request. In case of the AIO exit path, the AIO FS blocks until all pending USB requests utilizing the AIO path is completed. However, since the dequeue of ep0 req does not happen properly, all non-control EPs with the DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will be stuck waiting for the USB FFS data endpoints to receive a completion callback. Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0 is brought back to the SETUP state, and ensures that any deferred end transfer commands are handled. This also will end any active transfers on EP0, compared to the previous implementation which directly called giveback only. Fixes: fcd2def6 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue") Cc: stable <stable@kernel.org> Signed-off-by:
-
- 02 Jan, 2024 7 commits
-
-
Harshit Mogalapalli authored
Unlock before returning on the error path. Fixes: 86b20af1 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant") Reported-by:
Dan Carpenter <error27@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202312170252.3udgrIcP-lkp@intel.com/Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20231219063639.450994-1-harshit.m.mogalapalli@oracle.comSigned-off-by:
-
Javier Carrasco authored
The TPS6598x PD controller supports firmware updates that can be loaded either from an external flash memory or a host using the device's I2C host interface. This patch implements the second approach, which is especially relevant if no flash memory is available. In order to make patch bundle updates, a series of tasks (special commands) must be sent to the device as it is documented in the TPS65987DDH and TPS65988DH Host Interface Technical Reference Manual[1], section 4.11 (Patch Bundle Update Tasks). The update sequence is as follows: 1. PTCs - Start Patch Load Sequence: the proposed approach includes device and application configuration data. 2. PTCd - Patch Download: 64-byte data chunks must be sent until the end of the firmware file is reached (the last chunk may be shorter). 3. PTCc - Patch Data Transfer Complete: ends the patch loading sequence. After this sequence and if no errors occurred, the device will change its mode to 'APP' after SETUP_MS milliseconds, and then it will be ready for normal operation. [1] https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf?ts=1697623299919&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTPS65987DSigned-off-by:
Javier Carrasco <javier.carrasco@wolfvision.net> Reviewed-by:
-
Javier Carrasco authored
The input data passed to execute commands with tps6598x_exec_cmd() is not supposed to be modified by the function. Moreover, this data is passed to tps6598x_exec_cmd_tmo() and finally to tps6598x_block_write(), which expects a const pointer. The current implementation does not produce any bugs, but it discards const qualifiers from the pointers passed as arguments. This leads to compile issues if 'discarded-qualifiers' is active and a const pointer is passed to the function, which is the case if data from a firmware structure is passed to execute update commands. Adding the const modifier to in_data prevents such issues and provides code consistency. Signed-off-by:
-
Javier Carrasco authored
The firmware request process is device agnostic and can be used for other parts. Signed-off-by:
-
Javier Carrasco authored
The current implementation includes a number of special cases for the tps25750. Nevertheless, init and reset functions can be generalized by adding function pointers to the tipd_data structure in order to offer that functionality to other parts without additional conditional clauses. Some functionality like the cold reset request (GAID) is shared by the tps25750 and the tps6598x, so they can use the same reset function. Signed-off-by:
-
liyouhong authored
Fix spelling typo in comments. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
liyouhong <liyouhong@kylinos.cn> Link: https://lore.kernel.org/r/20231221023425.1316397-1-liyouhong@kylinos.cnSigned-off-by:
-
Thinh Nguyen authored
This reverts commit e835c0a4. Don't omit soft-reset. During initialization, the driver may need to perform a soft reset to ensure the phy is ready when the controller updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset. Many platforms often have access to DCTL register for soft-reset despite being host-only. If there are actual reported issues from the platforms that don't expose DCTL registers, then we will need to revisit (perhaps to teach dwc3 to perform xhci's soft-reset USBCMD.HCRST). Cc: <stable@vger.kernel.org> Fixes: e835c0a4 ("usb: dwc3: don't reset device side if dwc3 was configured as host-only") Signed-off-by:
-
