- 28 May, 2023 24 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230517230239.187727-26-u.kleine-koenig@pengutronix.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230517230239.187727-24-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20230517230239.187727-23-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
- 19 May, 2023 1 commit
-
-
Lukas Bulwahn authored
Commit a4422ff2 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") adds the section QUALCOMM TYPEC PORT MANAGER DRIVER in MAINTAINERS with two file entries for header files in include/dt-bindings/usb/typec/. However, these files are not added to the repository with this commit or any commit in the related patch series. Probably, these file entries are just needless leftover after the work went through some refactoring. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Remove the two file entries for non-existent header files. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20230519041307.32322-1-lukas.bulwahn@gmail.comSigned-off-by:
-
- 13 May, 2023 15 commits
-
-
Bryan O'Donoghue authored
This commit adds a QCOM PMIC TCPM driver with an initial pm8150b block. The driver is layered as follows: qcom_pmic_typec.c : Responsible for registering with TCPM and arbitrates access to the Type-C and PDPHY hardware blocks in one place. This presents a single TCPM device to device to the Linux TCPM layer. qcom_pmic_typec_pdphy.c: Responsible for interfacing with the PDPHY hardware and processing power-delivery related calls from TCPM. This hardware binding can be extended to facilitate similar hardware in different PMICs. qcom_pmic_typec_port.c: Responsible for notifying and processing Type-C related calls from TCPM. Similar to the pdphy this layer can be extended to handle the specifics of different Qualcomm PMIC Type-C port managers. This code provides all of the same functionality as the existing qcom typec driver plus power-delivery as well. As a result commit 6c8cf369 ("usb: typec: Add QCOM PMIC typec detection driver") can be deleted entirely. References code from Jonathan Marek, Jack Pham, Wesley Cheng, Hemant Kumar, Guru Das Srinagesh and Ashay Jaiswal. Acked-by:Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
Add a description for the Type-C silicon interface inside Qualcomm's PM8150b hardware block. Based on original work by Wesley. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Wesley Cheng <wcheng@codeaurora.org> Signed-off-by:
-
Dmitry Rokosov authored
From now, the Amlogic A1 USB controller is capable of switching between host and gadget modes based on the status of the OTG_ID signal or via manual USB role change. Previously, only the Amlogic A1 IP version did not use OTG support for host only mode, but this is no longer applicable. Therefore, the 'otg_switch_supported' option can now be removed as it is no longer required. Signed-off-by:
Dmitry Rokosov <ddrokosov@sberdevices.ru> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
Dmitry Rokosov authored
Provide the appropriate compatible string for the DWC2 IP that is found inside the Amlogic A1 SoC and used in peripheral mode. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Dmitry Rokosov authored
The Amlogic A1 uses dwc2 Synopsys IP as its USB peripheral (gadget) endpoint, with different DWC2 parameters when compared to previous Amlogic SoCs. Signed-off-by:
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/20230511210455.6634-2-ddrokosov@sberdevices.ruSigned-off-by:
-
Krishna Kurapati authored
In the event, gadget_connect call (which invokes pullup) fails, propagate the error to udc bind operation which inturn sends the error to configfs. The userspace can then retry enumeartion if it chooses to. Signed-off-by:
Krishna Kurapati <quic_kriskura@quicinc.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20230510075252.31023-3-quic_kriskura@quicinc.comSigned-off-by:
-
Krishna Kurapati authored
If the core soft reset timeout happens, avoid setting up event buffers and starting gadget as the writes to these registers may not reflect when in reset and setting the run stop bit can lead the controller to access wrong event buffer address resulting in a crash. Signed-off-by:
-
Christophe JAILLET authored
dwc2_driver_probe() calls dwc2_lowlevel_hw_init() which deassert some reset lines. Should an error happen in dwc2_lowlevel_hw_init() after calling reset_control_deassert() or in the probe after calling dwc2_lowlevel_hw_init(), the reset lines remain deasserted. Add some devm_add_action_or_reset() calls to re-assert the lines if needed. Update the remove function accordingly. This change is compile-tested only. Fixes: 83f8da56 ("usb: dwc2: Add reset control to dwc2") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/c64537b5339342bd00f7c2152b8fc23792b9f95a.1683306479.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Roy Luo authored
In cases where the controller somehow fails to write to event buffer memory (e.g. due to incorrect MMU config), the driver would receive all-zero dwc3 events. However, the abnormal event is silently dropped as a regular ep0out event. Add error logs when an unknown endpoint event is received to highlight the anomaly. Signed-off-by:
Roy Luo <royluo@google.com> Acked-by:
-
Michal Simek authored
The Microchip usb5744 is a SS/HS USB 3.0 hub controller with 4 ports. Add description for USB related aspects of the USB5744 hub, it as well cover the option of connecting the controller as an i2c slave. When i2c interface is connected hub needs to be initialized first. Hub itself has fixed i2c address 0x2D but hardcoding address is not good idea because address can be shifted by i2c address translator in the middle. Signed-off-by:
Piyush Mehta <piyush.mehta@amd.com> Signed-off-by:
Michal Simek <michal.simek@amd.com> Reviewed-by:
-
Henry Lin authored
This commit enables stream transfer protocol for Tegra XHCI. Signed-off-by:
Henry Lin <henryl@nvidia.com> Signed-off-by:
Jim Lin <jilin@nvidia.com> Link: https://lore.kernel.org/r/20230512080423.27978-1-jilin@nvidia.comSigned-off-by:
-
Stanley Chang authored
Remove this log to avoid non-error conditions. If CONFIG_USB_PHY is disabled, the following error message appears: [ 0.231609] xhci-hcd f10f0000.usb3: xhci_plat_probe get usb3phy fail (ret=-6) [ 0.239716] xhci-hcd f10f8000.usb3: xhci_plat_probe get usb3phy fail (ret=-6) In this case, devm_usb_get_phy_by_phandle is declared static inline and returns -ENXIO. It is easy to pinpoint the failure to get the usb-phy using the debug log in drivers/usb/phy/phy.c. Therefore, it can be removed. Signed-off-by:
Stanley Chang <stanley_chang@realtek.com> Tested-by:
Klaus Kudielka <klaus.kudielka@gmail.com> Link: https://lore.kernel.org/r/20230510075129.28047-1-stanley_chang@realtek.comSigned-off-by:
-
Stanley Chang authored
The Realtek RTD SoCs were designed with the global register address offset at 0x8100. The default address offset is constant at DWC3_GLOBALS_REGS_START (0xc100). Therefore, add a check if the compatible name of the parent is realtek,rtd-dwc3, then global register start address will remap to 0x8100. Signed-off-by:
-
Basavaraj Natikar authored
Avoid extra 120ms delay during system resume. The xHC controller may signal wake up to 120ms before showing which usb device caused the wake on the xHC port registers. The xhci driver therefore checks for port activity up to 120ms during resume, making sure that the hub driver can see the port change, and won't immediately runtime suspend back due to no port activity. This is however only needed for runtime resume as system resume will resume all child hubs and other child usb devices anyway. Fixes: 253f588c ("xhci: Improve detection of device initiated wake signal.") Signed-off-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230428140056.1318981-3-Basavaraj.Natikar@amd.comSigned-off-by:
-
Basavaraj Natikar authored
Currently, the pci_resume method has only a flag indicating whether the system is resuming from hibernation. In order to handle all PM events like AUTO_RESUME (runtime resume from device in D3), RESUME (system resume from s2idle, S3 or S4 states) etc change the pci_resume method to handle all PM events. Signed-off-by:
-
