linux/drivers/usb/dwc3/dwc3-qcom.c

887 lines
21 KiB
C
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*
* Inspired by dwc3-of-simple.c
*/
#include <linux/io.h>
#include <linux/of.h>
#include <linux/clk.h>
#include <linux/irq.h>
#include <linux/of_clk.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/extcon.h>
#include <linux/interconnect.h>
#include <linux/platform_device.h>
#include <linux/phy/phy.h>
#include <linux/usb/of.h>
#include <linux/reset.h>
#include <linux/iopoll.h>
#include <linux/usb/hcd.h>
#include <linux/usb.h>
#include "core.h"
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
#include "glue.h"
/* USB QSCRATCH Hardware registers */
#define QSCRATCH_HS_PHY_CTRL 0x10
#define UTMI_OTG_VBUS_VALID BIT(20)
#define SW_SESSVLD_SEL BIT(28)
#define QSCRATCH_SS_PHY_CTRL 0x30
#define LANE0_PWR_PRESENT BIT(24)
#define QSCRATCH_GENERAL_CFG 0x08
#define PIPE_UTMI_CLK_SEL BIT(0)
#define PIPE3_PHYSTATUS_SW BIT(3)
#define PIPE_UTMI_CLK_DIS BIT(8)
#define PWR_EVNT_LPM_IN_L2_MASK BIT(4)
#define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
#define SDM845_QSCRATCH_BASE_OFFSET 0xf8800
#define SDM845_QSCRATCH_SIZE 0x400
#define SDM845_DWC3_CORE_SIZE 0xcd00
/* Interconnect path bandwidths in MBps */
#define USB_MEMORY_AVG_HS_BW MBps_to_icc(240)
#define USB_MEMORY_PEAK_HS_BW MBps_to_icc(700)
#define USB_MEMORY_AVG_SS_BW MBps_to_icc(1000)
#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(2500)
#define APPS_USB_AVG_BW 0
#define APPS_USB_PEAK_BW MBps_to_icc(40)
/* Qualcomm SoCs with multiport support has up to 4 ports */
#define DWC3_QCOM_MAX_PORTS 4
static const u32 pwr_evnt_irq_stat_reg[DWC3_QCOM_MAX_PORTS] = {
0x58,
0x1dc,
0x228,
0x238,
};
struct dwc3_qcom_port {
int qusb2_phy_irq;
int dp_hs_phy_irq;
int dm_hs_phy_irq;
int ss_phy_irq;
enum usb_device_speed usb2_speed;
};
struct dwc3_qcom {
struct device *dev;
void __iomem *qscratch_base;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 dwc;
struct clk_bulk_data *clks;
int num_clocks;
struct reset_control *resets;
struct dwc3_qcom_port ports[DWC3_QCOM_MAX_PORTS];
u8 num_ports;
struct extcon_dev *edev;
struct extcon_dev *host_edev;
struct notifier_block vbus_nb;
struct notifier_block host_nb;
enum usb_dr_mode mode;
bool is_suspended;
bool pm_suspended;
struct icc_path *icc_path_ddr;
struct icc_path *icc_path_apps;
};
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
#define to_dwc3_qcom(d) container_of((d), struct dwc3_qcom, dwc)
static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
{
u32 reg;
reg = readl(base + offset);
reg |= val;
writel(reg, base + offset);
/* ensure that above write is through */
readl(base + offset);
}
static inline void dwc3_qcom_clrbits(void __iomem *base, u32 offset, u32 val)
{
u32 reg;
reg = readl(base + offset);
reg &= ~val;
writel(reg, base + offset);
/* ensure that above write is through */
readl(base + offset);
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
/*
* TODO: Make the in-core role switching code invoke dwc3_qcom_vbus_override_enable(),
* validate that the in-core extcon support is functional, and drop extcon
* handling from the glue
*/
static void dwc3_qcom_vbus_override_enable(struct dwc3_qcom *qcom, bool enable)
{
if (enable) {
dwc3_qcom_setbits(qcom->qscratch_base, QSCRATCH_SS_PHY_CTRL,
LANE0_PWR_PRESENT);
dwc3_qcom_setbits(qcom->qscratch_base, QSCRATCH_HS_PHY_CTRL,
UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
} else {
dwc3_qcom_clrbits(qcom->qscratch_base, QSCRATCH_SS_PHY_CTRL,
LANE0_PWR_PRESENT);
dwc3_qcom_clrbits(qcom->qscratch_base, QSCRATCH_HS_PHY_CTRL,
UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
}
}
static int dwc3_qcom_vbus_notifier(struct notifier_block *nb,
unsigned long event, void *ptr)
{
struct dwc3_qcom *qcom = container_of(nb, struct dwc3_qcom, vbus_nb);
/* enable vbus override for device mode */
dwc3_qcom_vbus_override_enable(qcom, event);
qcom->mode = event ? USB_DR_MODE_PERIPHERAL : USB_DR_MODE_HOST;
return NOTIFY_DONE;
}
static int dwc3_qcom_host_notifier(struct notifier_block *nb,
unsigned long event, void *ptr)
{
struct dwc3_qcom *qcom = container_of(nb, struct dwc3_qcom, host_nb);
/* disable vbus override in host mode */
dwc3_qcom_vbus_override_enable(qcom, !event);
qcom->mode = event ? USB_DR_MODE_HOST : USB_DR_MODE_PERIPHERAL;
return NOTIFY_DONE;
}
static int dwc3_qcom_register_extcon(struct dwc3_qcom *qcom)
{
struct device *dev = qcom->dev;
struct extcon_dev *host_edev;
int ret;
if (!of_property_present(dev->of_node, "extcon"))
return 0;
qcom->edev = extcon_get_edev_by_phandle(dev, 0);
if (IS_ERR(qcom->edev))
return dev_err_probe(dev, PTR_ERR(qcom->edev),
"Failed to get extcon\n");
qcom->vbus_nb.notifier_call = dwc3_qcom_vbus_notifier;
qcom->host_edev = extcon_get_edev_by_phandle(dev, 1);
if (IS_ERR(qcom->host_edev))
qcom->host_edev = NULL;
ret = devm_extcon_register_notifier(dev, qcom->edev, EXTCON_USB,
&qcom->vbus_nb);
if (ret < 0) {
dev_err(dev, "VBUS notifier register failed\n");
return ret;
}
if (qcom->host_edev)
host_edev = qcom->host_edev;
else
host_edev = qcom->edev;
qcom->host_nb.notifier_call = dwc3_qcom_host_notifier;
ret = devm_extcon_register_notifier(dev, host_edev, EXTCON_USB_HOST,
&qcom->host_nb);
if (ret < 0) {
dev_err(dev, "Host notifier register failed\n");
return ret;
}
/* Update initial VBUS override based on extcon state */
if (extcon_get_state(qcom->edev, EXTCON_USB) ||
!extcon_get_state(host_edev, EXTCON_USB_HOST))
dwc3_qcom_vbus_notifier(&qcom->vbus_nb, true, qcom->edev);
else
dwc3_qcom_vbus_notifier(&qcom->vbus_nb, false, qcom->edev);
return 0;
}
static int dwc3_qcom_interconnect_enable(struct dwc3_qcom *qcom)
{
int ret;
ret = icc_enable(qcom->icc_path_ddr);
if (ret)
return ret;
ret = icc_enable(qcom->icc_path_apps);
if (ret)
icc_disable(qcom->icc_path_ddr);
return ret;
}
static int dwc3_qcom_interconnect_disable(struct dwc3_qcom *qcom)
{
int ret;
ret = icc_disable(qcom->icc_path_ddr);
if (ret)
return ret;
ret = icc_disable(qcom->icc_path_apps);
if (ret)
icc_enable(qcom->icc_path_ddr);
return ret;
}
/**
* dwc3_qcom_interconnect_init() - Get interconnect path handles
* and set bandwidth.
* @qcom: Pointer to the concerned usb core.
*
*/
static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
{
enum usb_device_speed max_speed;
struct device *dev = qcom->dev;
int ret;
qcom->icc_path_ddr = of_icc_get(dev, "usb-ddr");
if (IS_ERR(qcom->icc_path_ddr)) {
return dev_err_probe(dev, PTR_ERR(qcom->icc_path_ddr),
"failed to get usb-ddr path\n");
}
qcom->icc_path_apps = of_icc_get(dev, "apps-usb");
if (IS_ERR(qcom->icc_path_apps)) {
ret = dev_err_probe(dev, PTR_ERR(qcom->icc_path_apps),
"failed to get apps-usb path\n");
goto put_path_ddr;
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
max_speed = usb_get_maximum_speed(qcom->dwc.dev);
if (max_speed >= USB_SPEED_SUPER || max_speed == USB_SPEED_UNKNOWN) {
ret = icc_set_bw(qcom->icc_path_ddr,
USB_MEMORY_AVG_SS_BW, USB_MEMORY_PEAK_SS_BW);
} else {
ret = icc_set_bw(qcom->icc_path_ddr,
USB_MEMORY_AVG_HS_BW, USB_MEMORY_PEAK_HS_BW);
}
if (ret) {
dev_err(dev, "failed to set bandwidth for usb-ddr path: %d\n", ret);
goto put_path_apps;
}
ret = icc_set_bw(qcom->icc_path_apps, APPS_USB_AVG_BW, APPS_USB_PEAK_BW);
if (ret) {
dev_err(dev, "failed to set bandwidth for apps-usb path: %d\n", ret);
goto put_path_apps;
}
return 0;
put_path_apps:
icc_put(qcom->icc_path_apps);
put_path_ddr:
icc_put(qcom->icc_path_ddr);
return ret;
}
/**
* dwc3_qcom_interconnect_exit() - Release interconnect path handles
* @qcom: Pointer to the concerned usb core.
*
* This function is used to release interconnect path handle.
*/
static void dwc3_qcom_interconnect_exit(struct dwc3_qcom *qcom)
{
icc_put(qcom->icc_path_ddr);
icc_put(qcom->icc_path_apps);
}
/* Only usable in contexts where the role can not change. */
static bool dwc3_qcom_is_host(struct dwc3_qcom *qcom)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
return qcom->dwc.xhci;
}
static enum usb_device_speed dwc3_qcom_read_usb2_speed(struct dwc3_qcom *qcom, int port_index)
{
struct usb_device *udev;
struct usb_hcd __maybe_unused *hcd;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = &qcom->dwc;
/*
* FIXME: Fix this layering violation.
*/
hcd = platform_get_drvdata(dwc->xhci);
#ifdef CONFIG_USB
udev = usb_hub_find_child(hcd->self.root_hub, port_index + 1);
#else
udev = NULL;
#endif
if (!udev)
return USB_SPEED_UNKNOWN;
return udev->speed;
}
static void dwc3_qcom_enable_wakeup_irq(int irq, unsigned int polarity)
{
if (!irq)
return;
if (polarity)
irq_set_irq_type(irq, polarity);
enable_irq(irq);
enable_irq_wake(irq);
}
static void dwc3_qcom_disable_wakeup_irq(int irq)
{
if (!irq)
return;
disable_irq_wake(irq);
disable_irq_nosync(irq);
}
static void dwc3_qcom_disable_port_interrupts(struct dwc3_qcom_port *port)
{
dwc3_qcom_disable_wakeup_irq(port->qusb2_phy_irq);
if (port->usb2_speed == USB_SPEED_LOW) {
dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
} else if ((port->usb2_speed == USB_SPEED_HIGH) ||
(port->usb2_speed == USB_SPEED_FULL)) {
dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
} else {
dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
}
dwc3_qcom_disable_wakeup_irq(port->ss_phy_irq);
}
static void dwc3_qcom_enable_port_interrupts(struct dwc3_qcom_port *port)
{
dwc3_qcom_enable_wakeup_irq(port->qusb2_phy_irq, 0);
/*
* Configure DP/DM line interrupts based on the USB2 device attached to
* the root hub port. When HS/FS device is connected, configure the DP line
* as falling edge to detect both disconnect and remote wakeup scenarios. When
* LS device is connected, configure DM line as falling edge to detect both
* disconnect and remote wakeup. When no device is connected, configure both
* DP and DM lines as rising edge to detect HS/HS/LS device connect scenario.
*/
if (port->usb2_speed == USB_SPEED_LOW) {
dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
IRQ_TYPE_EDGE_FALLING);
} else if ((port->usb2_speed == USB_SPEED_HIGH) ||
(port->usb2_speed == USB_SPEED_FULL)) {
dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
IRQ_TYPE_EDGE_FALLING);
} else {
dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
IRQ_TYPE_EDGE_RISING);
dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
IRQ_TYPE_EDGE_RISING);
}
dwc3_qcom_enable_wakeup_irq(port->ss_phy_irq, 0);
}
static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
{
int i;
for (i = 0; i < qcom->num_ports; i++)
dwc3_qcom_disable_port_interrupts(&qcom->ports[i]);
}
static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
{
int i;
for (i = 0; i < qcom->num_ports; i++)
dwc3_qcom_enable_port_interrupts(&qcom->ports[i]);
}
static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
{
u32 val;
int i, ret;
if (qcom->is_suspended)
return 0;
for (i = 0; i < qcom->num_ports; i++) {
val = readl(qcom->qscratch_base + pwr_evnt_irq_stat_reg[i]);
if (!(val & PWR_EVNT_LPM_IN_L2_MASK))
dev_err(qcom->dev, "port-%d HS-PHY not in L2\n", i + 1);
}
clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks);
ret = dwc3_qcom_interconnect_disable(qcom);
if (ret)
dev_warn(qcom->dev, "failed to disable interconnect: %d\n", ret);
/*
* The role is stable during suspend as role switching is done from a
* freezable workqueue.
*/
if (dwc3_qcom_is_host(qcom) && wakeup) {
for (i = 0; i < qcom->num_ports; i++)
qcom->ports[i].usb2_speed = dwc3_qcom_read_usb2_speed(qcom, i);
dwc3_qcom_enable_interrupts(qcom);
}
qcom->is_suspended = true;
return 0;
}
static int dwc3_qcom_resume(struct dwc3_qcom *qcom, bool wakeup)
{
int ret;
int i;
if (!qcom->is_suspended)
return 0;
if (dwc3_qcom_is_host(qcom) && wakeup)
dwc3_qcom_disable_interrupts(qcom);
ret = clk_bulk_prepare_enable(qcom->num_clocks, qcom->clks);
if (ret < 0)
return ret;
ret = dwc3_qcom_interconnect_enable(qcom);
if (ret)
dev_warn(qcom->dev, "failed to enable interconnect: %d\n", ret);
/* Clear existing events from PHY related to L2 in/out */
for (i = 0; i < qcom->num_ports; i++) {
dwc3_qcom_setbits(qcom->qscratch_base,
pwr_evnt_irq_stat_reg[i],
PWR_EVNT_LPM_IN_L2_MASK | PWR_EVNT_LPM_OUT_L2_MASK);
}
qcom->is_suspended = false;
return 0;
}
static irqreturn_t qcom_dwc3_resume_irq(int irq, void *data)
{
struct dwc3_qcom *qcom = data;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = &qcom->dwc;
/* If pm_suspended then let pm_resume take care of resuming h/w */
if (qcom->pm_suspended)
return IRQ_HANDLED;
/*
* This is safe as role switching is done from a freezable workqueue
* and the wakeup interrupts are disabled as part of resume.
*/
if (dwc3_qcom_is_host(qcom))
pm_runtime_resume(&dwc->xhci->dev);
return IRQ_HANDLED;
}
static void dwc3_qcom_select_utmi_clk(struct dwc3_qcom *qcom)
{
/* Configure dwc3 to use UTMI clock as PIPE clock not present */
dwc3_qcom_setbits(qcom->qscratch_base, QSCRATCH_GENERAL_CFG,
PIPE_UTMI_CLK_DIS);
usleep_range(100, 1000);
dwc3_qcom_setbits(qcom->qscratch_base, QSCRATCH_GENERAL_CFG,
PIPE_UTMI_CLK_SEL | PIPE3_PHYSTATUS_SW);
usleep_range(100, 1000);
dwc3_qcom_clrbits(qcom->qscratch_base, QSCRATCH_GENERAL_CFG,
PIPE_UTMI_CLK_DIS);
}
static int dwc3_qcom_request_irq(struct dwc3_qcom *qcom, int irq,
const char *name)
{
int ret;
/* Keep wakeup interrupts disabled until suspend */
ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
qcom_dwc3_resume_irq,
IRQF_ONESHOT | IRQF_NO_AUTOEN,
name, qcom);
if (ret)
dev_err(qcom->dev, "failed to request irq %s: %d\n", name, ret);
return ret;
}
static int dwc3_qcom_setup_port_irq(struct dwc3_qcom *qcom,
struct platform_device *pdev,
int port_index, bool is_multiport)
{
const char *irq_name;
int irq;
int ret;
if (is_multiport)
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dp_hs_phy_%d", port_index + 1);
else
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dp_hs_phy_irq");
if (!irq_name)
return -ENOMEM;
irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq > 0) {
ret = dwc3_qcom_request_irq(qcom, irq, irq_name);
if (ret)
return ret;
qcom->ports[port_index].dp_hs_phy_irq = irq;
}
if (is_multiport)
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dm_hs_phy_%d", port_index + 1);
else
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dm_hs_phy_irq");
if (!irq_name)
return -ENOMEM;
irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq > 0) {
ret = dwc3_qcom_request_irq(qcom, irq, irq_name);
if (ret)
return ret;
qcom->ports[port_index].dm_hs_phy_irq = irq;
}
if (is_multiport)
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ss_phy_%d", port_index + 1);
else
irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ss_phy_irq");
if (!irq_name)
return -ENOMEM;
irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq > 0) {
ret = dwc3_qcom_request_irq(qcom, irq, irq_name);
if (ret)
return ret;
qcom->ports[port_index].ss_phy_irq = irq;
}
if (is_multiport)
return 0;
irq = platform_get_irq_byname_optional(pdev, "qusb2_phy");
if (irq > 0) {
ret = dwc3_qcom_request_irq(qcom, irq, "qusb2_phy");
if (ret)
return ret;
qcom->ports[port_index].qusb2_phy_irq = irq;
}
return 0;
}
static int dwc3_qcom_find_num_ports(struct platform_device *pdev)
{
char irq_name[14];
int port_num;
int irq;
irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_1");
if (irq <= 0)
return 1;
for (port_num = 2; port_num <= DWC3_QCOM_MAX_PORTS; port_num++) {
sprintf(irq_name, "dp_hs_phy_%d", port_num);
irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq <= 0)
return port_num - 1;
}
return DWC3_QCOM_MAX_PORTS;
}
static int dwc3_qcom_setup_irq(struct dwc3_qcom *qcom, struct platform_device *pdev)
{
bool is_multiport;
int ret;
int i;
qcom->num_ports = dwc3_qcom_find_num_ports(pdev);
is_multiport = (qcom->num_ports > 1);
for (i = 0; i < qcom->num_ports; i++) {
ret = dwc3_qcom_setup_port_irq(qcom, pdev, i, is_multiport);
if (ret)
return ret;
}
return 0;
}
static int dwc3_qcom_probe(struct platform_device *pdev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3_probe_data probe_data = {};
struct device *dev = &pdev->dev;
struct dwc3_qcom *qcom;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct resource res;
struct resource *r;
int ret;
bool ignore_pipe_clk;
bool wakeup_source;
qcom = devm_kzalloc(&pdev->dev, sizeof(*qcom), GFP_KERNEL);
if (!qcom)
return -ENOMEM;
qcom->dev = &pdev->dev;
qcom->resets = devm_reset_control_array_get_optional_exclusive(dev);
if (IS_ERR(qcom->resets)) {
return dev_err_probe(&pdev->dev, PTR_ERR(qcom->resets),
"failed to get resets\n");
}
ret = devm_clk_bulk_get_all(&pdev->dev, &qcom->clks);
if (ret < 0)
return dev_err_probe(dev, ret, "failed to get clocks\n");
qcom->num_clocks = ret;
ret = reset_control_assert(qcom->resets);
if (ret) {
dev_err(&pdev->dev, "failed to assert resets, err=%d\n", ret);
return ret;
}
usleep_range(10, 1000);
ret = reset_control_deassert(qcom->resets);
if (ret) {
dev_err(&pdev->dev, "failed to deassert resets, err=%d\n", ret);
return ret;
}
ret = clk_bulk_prepare_enable(qcom->num_clocks, qcom->clks);
if (ret < 0)
return ret;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
ret = -EINVAL;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
goto clk_disable;
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
res = *r;
res.end = res.start + SDM845_QSCRATCH_BASE_OFFSET;
qcom->qscratch_base = devm_ioremap(dev, res.end, SDM845_QSCRATCH_SIZE);
if (!qcom->qscratch_base) {
dev_err(dev, "failed to map qscratch region\n");
ret = -ENOMEM;
goto clk_disable;
}
ret = dwc3_qcom_setup_irq(qcom, pdev);
if (ret) {
dev_err(dev, "failed to setup IRQs, err=%d\n", ret);
goto clk_disable;
}
/*
* Disable pipe_clk requirement if specified. Used when dwc3
* operates without SSPHY and only HS/FS/LS modes are supported.
*/
ignore_pipe_clk = device_property_read_bool(dev,
"qcom,select-utmi-as-pipe-clk");
if (ignore_pipe_clk)
dwc3_qcom_select_utmi_clk(qcom);
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
qcom->dwc.dev = dev;
probe_data.dwc = &qcom->dwc;
probe_data.res = &res;
probe_data.ignore_clocks_and_resets = true;
ret = dwc3_core_probe(&probe_data);
if (ret) {
ret = dev_err_probe(dev, ret, "failed to register DWC3 Core\n");
goto clk_disable;
}
ret = dwc3_qcom_interconnect_init(qcom);
if (ret)
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
goto remove_core;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
qcom->mode = usb_get_dr_mode(dev);
/* enable vbus override for device mode */
if (qcom->mode != USB_DR_MODE_HOST)
dwc3_qcom_vbus_override_enable(qcom, true);
/* register extcon to override sw_vbus on Vbus change later */
ret = dwc3_qcom_register_extcon(qcom);
if (ret)
goto interconnect_exit;
wakeup_source = of_property_read_bool(dev->of_node, "wakeup-source");
device_init_wakeup(&pdev->dev, wakeup_source);
qcom->is_suspended = false;
return 0;
interconnect_exit:
dwc3_qcom_interconnect_exit(qcom);
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
remove_core:
dwc3_core_remove(&qcom->dwc);
clk_disable:
clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks);
return ret;
}
static void dwc3_qcom_remove(struct platform_device *pdev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = platform_get_drvdata(pdev);
struct dwc3_qcom *qcom = to_dwc3_qcom(dwc);
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
dwc3_core_remove(&qcom->dwc);
clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks);
dwc3_qcom_interconnect_exit(qcom);
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
static int dwc3_qcom_pm_suspend(struct device *dev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = dev_get_drvdata(dev);
struct dwc3_qcom *qcom = to_dwc3_qcom(dwc);
bool wakeup = device_may_wakeup(dev);
int ret;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
ret = dwc3_pm_suspend(&qcom->dwc);
if (ret)
return ret;
ret = dwc3_qcom_suspend(qcom, wakeup);
if (ret)
return ret;
qcom->pm_suspended = true;
return 0;
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
static int dwc3_qcom_pm_resume(struct device *dev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = dev_get_drvdata(dev);
struct dwc3_qcom *qcom = to_dwc3_qcom(dwc);
bool wakeup = device_may_wakeup(dev);
int ret;
ret = dwc3_qcom_resume(qcom, wakeup);
if (ret)
return ret;
qcom->pm_suspended = false;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
ret = dwc3_pm_resume(&qcom->dwc);
if (ret)
return ret;
return 0;
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
static void dwc3_qcom_complete(struct device *dev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = dev_get_drvdata(dev);
dwc3_pm_complete(dwc);
}
static int dwc3_qcom_prepare(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
return dwc3_pm_prepare(dwc);
}
static int dwc3_qcom_runtime_suspend(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
struct dwc3_qcom *qcom = to_dwc3_qcom(dwc);
int ret;
ret = dwc3_runtime_suspend(&qcom->dwc);
if (ret)
return ret;
return dwc3_qcom_suspend(qcom, true);
}
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
static int dwc3_qcom_runtime_resume(struct device *dev)
{
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
struct dwc3 *dwc = dev_get_drvdata(dev);
struct dwc3_qcom *qcom = to_dwc3_qcom(dwc);
int ret;
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
ret = dwc3_qcom_resume(qcom, true);
if (ret)
return ret;
return dwc3_runtime_resume(&qcom->dwc);
}
static int dwc3_qcom_runtime_idle(struct device *dev)
{
return dwc3_runtime_idle(dev_get_drvdata(dev));
}
static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
SYSTEM_SLEEP_PM_OPS(dwc3_qcom_pm_suspend, dwc3_qcom_pm_resume)
RUNTIME_PM_OPS(dwc3_qcom_runtime_suspend, dwc3_qcom_runtime_resume,
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
dwc3_qcom_runtime_idle)
.complete = pm_sleep_ptr(dwc3_qcom_complete),
.prepare = pm_sleep_ptr(dwc3_qcom_prepare),
};
static const struct of_device_id dwc3_qcom_of_match[] = {
usb: dwc3: qcom: Transition to flattened model The USB IP-block found in most Qualcomm platforms is modelled in the Linux kernel as 3 different independent device drivers, but as shown by the already existing layering violations in the Qualcomm glue driver they can not be operated independently. With the current implementation, the glue driver registers the core and has no way to know when this is done. As a result, e.g. the suspend callbacks needs to guard against NULL pointer dereferences when trying to peek into the struct dwc3 found in the drvdata of the child. Even with these checks, there are no way to fully protect ourselves from the race conditions that occur if the DWC3 is unbound. Missing from the upstream Qualcomm USB support is handling of role switching, in which the glue needs to be notified upon DRD mode changes. Several attempts has been made through the years to register callbacks etc, but they always fall short when it comes to handling of the core's probe deferral on resources etc. Moving to a model where the DWC3 core is instantiated in a synchronous fashion avoids above described race conditions. It is however not feasible to do so without also flattening the DeviceTree binding, as assumptions are made in the DWC3 core and frameworks used that the device's associated of_node will the that of the core. Furthermore, the DeviceTree binding is a direct representation of the Linux driver model, and doesn't necessarily describe "the USB IP-block". The Qualcomm DWC3 glue driver is therefor transitioned to initialize and operate the DWC3 within the one device context, in synchronous fashion. To provide a limited time backwards compatibility, a snapshot of the driver is retained in a previous commit. As such no care is taken in the dwc3-qcom driver for the qcom,dwc3 backwards compatibility. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414-dwc3-refactor-v7-6-f015b358722d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-14 20:21:55 -05:00
{ .compatible = "qcom,snps-dwc3" },
{ }
};
MODULE_DEVICE_TABLE(of, dwc3_qcom_of_match);
static struct platform_driver dwc3_qcom_driver = {
.probe = dwc3_qcom_probe,
.remove = dwc3_qcom_remove,
.driver = {
.name = "dwc3-qcom",
.pm = pm_ptr(&dwc3_qcom_dev_pm_ops),
.of_match_table = dwc3_qcom_of_match,
},
};
module_platform_driver(dwc3_qcom_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DesignWare DWC3 QCOM Glue Driver");