usb: dwc3: Various updates for Synopsys platforms

PATCH In review John Youn 3 participants 19 messages Oct 2, 2015 – Oct 3, 2015

Subsystems (4)

Stable branch Device tree bindings USB DesignWare USB3 DRD IP driver

lore

Share & tools

lore

John Youn

author

2015-10-02 01:41 UTC #1 lore raw

PATCH 1/6 usb: dwc3: Support Synopsys USB 3.1 IP

In reply to John Youn

This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only.

The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However, the underlying IP is different and the GSNPSID and version numbers are different.

The DWC_usb31 version register is actually lower in value than the full GSNPSID of the DWC_usb3 IP. So if we are on DWC_usb3 IP just store the lower word of the GSNPSID instead of the full register. Then adjust the revision constants to match. This will allow existing revision checks to continue to work when running on the new IP.

Finally add a documentation note about the revision numbering and checking with regards to the old and new IP. Because these are different IPs which will both continue to be supported, feature sets and revisions checks may not sync-up across future versions.

Quoted 1 line

From now, any check based on a revision (for STARS, workarounds, and

new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.

Cc <[email protected]> # v3.18+

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/core.c |  9 ++++++--
 drivers/usb/dwc3/core.h | 56 +++++++++++++++++++++++++++++++------------------
 2 files changed, 43 insertions(+), 22 deletions(-)

drivers/usb/dwc3/core.c +7 -2

index c72c8c5..566cca1 100644
@@ -534,12 +534,17 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
 	reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
 	/* This should read as U3 followed by revision number */
-	if ((reg & DWC3_GSNPSID_MASK) != 0x55330000) {
+	if ((reg & DWC3_GSNPSID_MASK) == 0x55330000) {
+		/* Detected DWC_usb3 IP */
+		dwc->revision = reg & DWC3_GSNPSREV_MASK;
+	} else if ((reg & DWC3_GSNPSID_MASK) == 0x33310000) {
+		/* Detected DWC_usb31 IP */
+		dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
+	} else {
 		dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
 		ret = -ENODEV;
 		goto err0;
 	}
-	dwc->revision = reg;
 
 	/*
 	 * Write Linux Version Code to our GUID register so it's easy to figure

drivers/usb/dwc3/core.h +36 ~~-20~~

76 lines not on this page · raw message

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:41 UTC #13 lore raw

PATCH 2/6 usb: dwc3: pci: Add the Synopsys HAPS AXI Product ID

In reply to John Youn

This ID is for the Synopsys DWC_usb3 core with AXI interface on PCIe HAPS platform. This core has the debug registers mapped at a separate BAR in order to support enhanced hibernation.

Cc <[email protected]> # v3.18+

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/dwc3-pci.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/usb/dwc3/dwc3-pci.c +5 -0

index 89eb364..4c44a77 100644
@@ -27,6 +27,7 @@
 #include "platform_data.h"
 
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3	0xabcd
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
 #define PCI_DEVICE_ID_INTEL_BYT		0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD	0x119e
 #define PCI_DEVICE_ID_INTEL_BSW		0x22B7

@@ -179,6 +180,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
 		PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
 				PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
 	},
+	{
+		PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+				PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
+	},
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:41 UTC #15 lore raw

PATCH 4/6 usb: dwc3: pci: Add platform data for Synopsys HAPS

In reply to John Youn

Add platform data and set usb3_lpm_capable and has_lpm_erratum.

Cc <[email protected]> # v3.18+

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/dwc3-pci.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

drivers/usb/dwc3/dwc3-pci.c +15 -0

index e09cb40..4479a41 100644
@@ -108,6 +108,21 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
 		}
 	}
 
+	if (pdev->vendor == PCI_VENDOR_ID_SYNOPSYS &&
+	    (pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 ||
+	     pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI ||
+	     pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31)) {
+
+		struct dwc3_platform_data pdata;
+
+		memset(&pdata, 0, sizeof(pdata));
+		pdata.usb3_lpm_capable = true;
+		pdata.has_lpm_erratum = true;
+
+		return platform_device_add_data(pci_get_drvdata(pdev), &pdata,
+						sizeof(pdata));
+	}
+
 	return 0;
 }

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:42 UTC #18 lore raw

PATCH 6/6 usb: dwc3: pci: trivial: Formatting

In reply to John Youn

Fix the alignment of the PCI device definitions. Also change the hex digit capitalization of one constant to make it consistent with the rest of the file and driver.

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/dwc3-pci.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

drivers/usb/dwc3/dwc3-pci.c +8 -8

index b34bd79..77a622c 100644
@@ -26,14 +26,14 @@
 
 #include "platform_data.h"
 
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3	0xabcd
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31 0xabcf
-#define PCI_DEVICE_ID_INTEL_BYT		0x0f37
-#define PCI_DEVICE_ID_INTEL_MRFLD	0x119e
-#define PCI_DEVICE_ID_INTEL_BSW		0x22B7
-#define PCI_DEVICE_ID_INTEL_SPTLP	0x9d30
-#define PCI_DEVICE_ID_INTEL_SPTH	0xa130
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3		0xabcd
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI	0xabce
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31	0xabcf
+#define PCI_DEVICE_ID_INTEL_BYT			0x0f37
+#define PCI_DEVICE_ID_INTEL_MRFLD		0x119e
+#define PCI_DEVICE_ID_INTEL_BSW			0x22b7
+#define PCI_DEVICE_ID_INTEL_SPTLP		0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH		0xa130
 
 static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
 static const struct acpi_gpio_params cs_gpios = { 1, 0, false };

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:42 UTC #0 lore raw

cover usb: dwc3: Various updates for Synopsys platforms

Hi,

This series contains several updates to dwc3 to support Synopsys platforms.

Patch 1: Initial support for 3.1 IP (applies to all platforms) Patch 2-4: PCI id and platform data for Synopsys platforms Patch 5: Add a quirk to program a global register Patch 6: Formatting

Thanks,
John

John Youn (6):
usb: dwc3: Support Synopsys USB 3.1 IP
usb: dwc3: pci: Add the Synopsys HAPS AXI Product ID
usb: dwc3: pci: Add the PCI Product ID for Synopsys USB 3.1
usb: dwc3: pci: Add platform data for Synopsys HAPS
usb: dwc3: Add dis_enblslpm_quirk
usb: dwc3: pci: trivial: Formatting

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 +
 drivers/usb/dwc3/core.c                        | 15 ++++++-
 drivers/usb/dwc3/core.h                        | 60 +++++++++++++++++---------
 drivers/usb/dwc3/dwc3-pci.c                    | 38 +++++++++++++---
 drivers/usb/dwc3/platform_data.h               |  1 +
 5 files changed, 88 insertions(+), 28 deletions(-)

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:42 UTC #14 lore raw

PATCH 3/6 usb: dwc3: pci: Add the PCI Product ID for Synopsys USB 3.1

This adds the PCI product ID for the Synopsys USB 3.1 IP core (DWC_usb31) on a HAPS-based PCI development platform.

Cc <[email protected]> # v3.18+

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/dwc3-pci.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/usb/dwc3/dwc3-pci.c +5 -0

index 4c44a77..e09cb40 100644
@@ -28,6 +28,7 @@
 
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3	0xabcd
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31 0xabcf
 #define PCI_DEVICE_ID_INTEL_BYT		0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD	0x119e
 #define PCI_DEVICE_ID_INTEL_BSW		0x22B7

@@ -184,6 +185,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
 		PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
 				PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
 	},
+	{
+		PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+				PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31),
+	},
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
 	{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },

Signature · 1 line

2.5.0.GIT

John Youn

author

2015-10-02 01:42 UTC #16 lore raw

PATCH 5/6 usb: dwc3: Add dis_enblslpm_quirk

In reply to John Youn

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls whether the PHY receives the suspend signal from the controller.

Certain Synopsys prototyping PHY boards are not able to meet timings constraints for LPM. This allows the PHY to meet those timings by leaving the PHY clock running during suspend.

Cc <[email protected]> # v3.18+

Signed-off-by John Youn <[email protected]>

---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
 drivers/usb/dwc3/core.c                        | 6 ++++++
 drivers/usb/dwc3/core.h                        | 4 ++++
 drivers/usb/dwc3/dwc3-pci.c                    | 1 +
 drivers/usb/dwc3/platform_data.h               | 1 +
 5 files changed, 14 insertions(+)

Documentation/devicetree/bindings/usb/dwc3.txt +2 -0

index 8c7d585..9ff48e0 100644
@@ -35,6 +35,8 @@ Optional properties:
 			LTSSM during USB3 Compliance mode.
  - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy.
  - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy.
+ - snps,dis_enblslpm_quirk: when set clears the enblslpm in GUSB2PHYCFG,
+			disabling the suspend signal to the PHY.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
 			utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold

drivers/usb/dwc3/core.c +6 -0

index 566cca1..ca19027 100644
@@ -515,6 +515,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	if (dwc->dis_u2_susphy_quirk)
 		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
+	if (dwc->dis_enblslpm_quirk)
+		reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
 	dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
 	return 0;

@@ -911,6 +914,8 @@ static int dwc3_probe(struct platform_device *pdev)
 				"snps,dis_u3_susphy_quirk");
 	dwc->dis_u2_susphy_quirk = device_property_read_bool(dev,
 				"snps,dis_u2_susphy_quirk");
+	dwc->dis_enblslpm_quirk = device_property_read_bool(dev,
+				"snps,dis_enblslpm_quirk");
 
 	dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
 				"snps,tx_de_emphasis_quirk");

@@ -944,6 +949,7 @@ static int dwc3_probe(struct platform_device *pdev)
 		dwc->rx_detect_poll_quirk = pdata->rx_detect_poll_quirk;
 		dwc->dis_u3_susphy_quirk = pdata->dis_u3_susphy_quirk;
 		dwc->dis_u2_susphy_quirk = pdata->dis_u2_susphy_quirk;
+		dwc->dis_enblslpm_quirk = pdata->dis_enblslpm_quirk;
 
 		dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
 		if (pdata->tx_de_emphasis)

drivers/usb/dwc3/core.h +4 -0

index 7446467..a87ef34 100644
@@ -179,6 +179,7 @@
 #define DWC3_GUSB2PHYCFG_PHYSOFTRST	(1 << 31)
 #define DWC3_GUSB2PHYCFG_SUSPHY		(1 << 6)
 #define DWC3_GUSB2PHYCFG_ULPI_UTMI	(1 << 4)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM	(1 << 8)
 
 /* Global USB2 PHY Vendor Control Register */
 #define DWC3_GUSB2PHYACC_NEWREGREQ	(1 << 25)

@@ -721,6 +722,8 @@ struct dwc3_scratchpad_array {
  * @rx_detect_poll_quirk: set if we enable rx_detect to polling lfps quirk
  * @dis_u3_susphy_quirk: set if we disable usb3 suspend phy
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
+ * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
+ *                      disabling the suspend signal to the PHY.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 	0	- -6dB de-emphasis

@@ -862,6 +865,7 @@ struct dwc3 {
 	unsigned		rx_detect_poll_quirk:1;
 	unsigned		dis_u3_susphy_quirk:1;
 	unsigned		dis_u2_susphy_quirk:1;
+	unsigned		dis_enblslpm_quirk:1;
 
 	unsigned		tx_de_emphasis_quirk:1;
 	unsigned		tx_de_emphasis:2;

drivers/usb/dwc3/dwc3-pci.c +1 -0

index 4479a41..b34bd79 100644
@@ -118,6 +118,7 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
 		memset(&pdata, 0, sizeof(pdata));
 		pdata.usb3_lpm_capable = true;
 		pdata.has_lpm_erratum = true;
+		pdata.dis_enblslpm_quirk = true;
 
 		return platform_device_add_data(pci_get_drvdata(pdev), &pdata,
 						sizeof(pdata));

drivers/usb/dwc3/platform_data.h +1 -0

index 400b197..2bb4d3a 100644
@@ -42,6 +42,7 @@ struct dwc3_platform_data {
 	unsigned rx_detect_poll_quirk:1;
 	unsigned dis_u3_susphy_quirk:1;
 	unsigned dis_u2_susphy_quirk:1;
+	unsigned dis_enblslpm_quirk:1;
 
 	unsigned tx_de_emphasis_quirk:1;
 	unsigned tx_de_emphasis:2;

Signature · 1 line

2.5.0.GIT

Felipe Balbi

2015-10-02 02:03 UTC #2 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

In reply to John Youn

Hi,

Quoted 8 lines · John Youn

This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only.
The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However, the underlying IP is different and the GSNPSID and version numbers are different.

Quoted 5 lines

The DWC_usb31 version register is actually lower in value than the full GSNPSID of the DWC_usb3 IP. So if we are on DWC_usb3 IP just store the lower word of the GSNPSID instead of the full register. Then adjust the revision constants to match. This will allow existing revision checks to continue to work when running on the new IP.

I would rather not touch those constants at all. We can have the driver set a is_dwc31 flag and use if !is_dwc31 && rev < XYZ for the revision checks.

It's more work, but it seems better IMO.

Quoted 4 lines

Finally add a documentation note about the revision numbering and checking with regards to the old and new IP. Because these are different IPs which will both continue to be supported, feature sets and revisions checks may not sync-up across future versions.

and this is why I prefer to have the flag :-) We can run different revision check methods depending if we're running on dwc3 or dwc31.

Quoted 5 lines

From now, any check based on a revision (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.
Cc <[email protected]> # v3.18+

I really fail to how any of these patches in this series apply for stable. Care to explain ?

Quoted 11 lines

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/core.c |  9 ++++++--
 drivers/usb/dwc3/core.h | 56 +++++++++++++++++++++++++++++++------------------
 2 files changed, 43 insertions(+), 22 deletions(-)

drivers/usb/dwc3/core.c +0 -0

index c72c8c5..566cca1 100644

drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 539

Quoted 7 lines

drivers/usb/dwc3/core.c +3 -1

@@ -534,12 +534,17 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
 	reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
 	/* This should read as U3 followed by revision number */
-	if ((reg & DWC3_GSNPSID_MASK) != 0x55330000) {
+	if ((reg & DWC3_GSNPSID_MASK) == 0x55330000) {
+		/* Detected DWC_usb3 IP */
+		dwc->revision = reg & DWC3_GSNPSREV_MASK;

leave the mask out of it and ...

drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 542

Quoted 3 lines

drivers/usb/dwc3/core.c +3 -0

+	} else if ((reg & DWC3_GSNPSID_MASK) == 0x33310000) {
+		/* Detected DWC_usb31 IP */
+		dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);

set a dwc->is_dwc31 = true flag here.

Quoted 14 lines

drivers/usb/dwc3/core.c +1 -1

+	} else {
 		dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
 		ret = -ENODEV;
 		goto err0;
 	}
-	dwc->revision = reg;
 
 	/*
 	 * Write Linux Version Code to our GUID register so it's easy to figure

drivers/usb/dwc3/core.h +0 -0

index 9188745..7446467 100644

drivers/usb/dwc3/core.h line 112

Quoted 5 lines

drivers/usb/dwc3/core.h +2 -0

@@ -108,6 +108,9 @@
 #define DWC3_GPRTBIMAP_FS0	0xc188
 #define DWC3_GPRTBIMAP_FS1	0xc18c
 
+#define DWC3_VER_NUMBER		0xc1a0
+#define DWC3_VER_TYPE		0xc1a4

what is this VER_TYPE register ?

Quoted 33 lines

drivers/usb/dwc3/core.h +10 ~~-10~~

@@ -661,7 +664,8 @@ struct dwc3_scratchpad_array {
  * @num_event_buffers: calculated number of event buffers
  * @u1u2: only used on revisions <1.83a for workaround
  * @maximum_speed: maximum speed requested (mainly for testing purposes)
- * @revision: revision register contents
+ * @revision: the core revision. the contents will depend on the whether
+ *            this is a usb3 or usb31 core.
  * @dr_mode: requested mode of operation
  * @usb2_phy: pointer to USB2 PHY
  * @usb3_phy: pointer to USB3 PHY

@@ -771,27 +775,39 @@ struct dwc3 {
 	u32			num_event_buffers;
 	u32			u1u2;
 	u32			maximum_speed;
+
+	/*
+	 * All 3.1 IP version constants are greater than the 3.0 IP
+	 * version constants. This works for most version checks in
+	 * dwc3. However, in the future, this may not apply as
+	 * features may be developed on newer versions of the 3.0 IP
+	 * that are not in the 3.1 IP.
+	 */
 	u32			revision;
 
-#define DWC3_REVISION_173A	0x5533173a
-#define DWC3_REVISION_175A	0x5533175a
-#define DWC3_REVISION_180A	0x5533180a
-#define DWC3_REVISION_183A	0x5533183a
-#define DWC3_REVISION_185A	0x5533185a
-#define DWC3_REVISION_187A	0x5533187a
-#define DWC3_REVISION_188A	0x5533188a
-#define DWC3_REVISION_190A	0x5533190a
-#define DWC3_REVISION_194A	0x5533194a

drivers/usb/dwc3/core.h struct dwc3 { · line 794

Quoted 10 lines

drivers/usb/dwc3/core.h +0 ~~-10~~

-#define DWC3_REVISION_200A	0x5533200a
-#define DWC3_REVISION_202A	0x5533202a
-#define DWC3_REVISION_210A	0x5533210a
-#define DWC3_REVISION_220A	0x5533220a
-#define DWC3_REVISION_230A	0x5533230a
-#define DWC3_REVISION_240A	0x5533240a
-#define DWC3_REVISION_250A	0x5533250a
-#define DWC3_REVISION_260A	0x5533260a
-#define DWC3_REVISION_270A	0x5533270a
-#define DWC3_REVISION_280A	0x5533280a

yeah, I'd rather not do all this.

Quoted 13 lines

drivers/usb/dwc3/core.h +13 -0

+/* DWC_usb3 revisions */
+#define DWC3_REVISION_173A	0x173a
+#define DWC3_REVISION_175A	0x175a
+#define DWC3_REVISION_180A	0x180a
+#define DWC3_REVISION_183A	0x183a
+#define DWC3_REVISION_185A	0x185a
+#define DWC3_REVISION_187A	0x187a
+#define DWC3_REVISION_188A	0x188a
+#define DWC3_REVISION_190A	0x190a
+#define DWC3_REVISION_194A	0x194a
+#define DWC3_REVISION_200A	0x200a
+#define DWC3_REVISION_202A	0x202a
+#define DWC3_REVISION_210A	0x210a

drivers/usb/dwc3/core.h struct dwc3 { · line 810

Quoted 10 lines

drivers/usb/dwc3/core.h +10 -0

+#define DWC3_REVISION_220A	0x220a
+#define DWC3_REVISION_230A	0x230a
+#define DWC3_REVISION_240A	0x240a
+#define DWC3_REVISION_250A	0x250a
+#define DWC3_REVISION_260A	0x260a
+#define DWC3_REVISION_270A	0x270a
+#define DWC3_REVISION_280A	0x280a
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a

are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?

Signature · 1 line

balbi

Felipe Balbi

2015-10-02 02:06 UTC #17 lore raw

Re: [PATCH 5/6] usb: dwc3: Add dis_enblslpm_quirk

In reply to John Youn

Quoted 9 lines · John Youn

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls whether the PHY receives the suspend signal from the controller.
Certain Synopsys prototyping PHY boards are not able to meet timings constraints for LPM. This allows the PHY to meet those timings by leaving the PHY clock running during suspend.
Cc <[email protected]> # v3.18+
Signed-off-by John Youn <[email protected]>

let's split this patch up. First we add the flag, and on a separate patch you use it in dwc3-pci.c

Quoted 108 lines

---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
 drivers/usb/dwc3/core.c                        | 6 ++++++
 drivers/usb/dwc3/core.h                        | 4 ++++
 drivers/usb/dwc3/dwc3-pci.c                    | 1 +
 drivers/usb/dwc3/platform_data.h               | 1 +
 5 files changed, 14 insertions(+)

Documentation/devicetree/bindings/usb/dwc3.txt +2 -0

index 8c7d585..9ff48e0 100644
@@ -35,6 +35,8 @@ Optional properties:
 			LTSSM during USB3 Compliance mode.
  - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy.
  - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy.
+ - snps,dis_enblslpm_quirk: when set clears the enblslpm in GUSB2PHYCFG,
+			disabling the suspend signal to the PHY.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
 			utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold

drivers/usb/dwc3/core.c +6 -0

index 566cca1..ca19027 100644
@@ -515,6 +515,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 	if (dwc->dis_u2_susphy_quirk)
 		reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
+	if (dwc->dis_enblslpm_quirk)
+		reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
 	dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
 	return 0;

@@ -911,6 +914,8 @@ static int dwc3_probe(struct platform_device *pdev)
 				"snps,dis_u3_susphy_quirk");
 	dwc->dis_u2_susphy_quirk = device_property_read_bool(dev,
 				"snps,dis_u2_susphy_quirk");
+	dwc->dis_enblslpm_quirk = device_property_read_bool(dev,
+				"snps,dis_enblslpm_quirk");
 
 	dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
 				"snps,tx_de_emphasis_quirk");

@@ -944,6 +949,7 @@ static int dwc3_probe(struct platform_device *pdev)
 		dwc->rx_detect_poll_quirk = pdata->rx_detect_poll_quirk;
 		dwc->dis_u3_susphy_quirk = pdata->dis_u3_susphy_quirk;
 		dwc->dis_u2_susphy_quirk = pdata->dis_u2_susphy_quirk;
+		dwc->dis_enblslpm_quirk = pdata->dis_enblslpm_quirk;
 
 		dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
 		if (pdata->tx_de_emphasis)

drivers/usb/dwc3/core.h +4 -0

index 7446467..a87ef34 100644
@@ -179,6 +179,7 @@
 #define DWC3_GUSB2PHYCFG_PHYSOFTRST	(1 << 31)
 #define DWC3_GUSB2PHYCFG_SUSPHY		(1 << 6)
 #define DWC3_GUSB2PHYCFG_ULPI_UTMI	(1 << 4)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM	(1 << 8)
 
 /* Global USB2 PHY Vendor Control Register */
 #define DWC3_GUSB2PHYACC_NEWREGREQ	(1 << 25)

@@ -721,6 +722,8 @@ struct dwc3_scratchpad_array {
  * @rx_detect_poll_quirk: set if we enable rx_detect to polling lfps quirk
  * @dis_u3_susphy_quirk: set if we disable usb3 suspend phy
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
+ * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
+ *                      disabling the suspend signal to the PHY.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 	0	- -6dB de-emphasis

@@ -862,6 +865,7 @@ struct dwc3 {
 	unsigned		rx_detect_poll_quirk:1;
 	unsigned		dis_u3_susphy_quirk:1;
 	unsigned		dis_u2_susphy_quirk:1;
+	unsigned		dis_enblslpm_quirk:1;
 
 	unsigned		tx_de_emphasis_quirk:1;
 	unsigned		tx_de_emphasis:2;

drivers/usb/dwc3/dwc3-pci.c +1 -0

index 4479a41..b34bd79 100644
@@ -118,6 +118,7 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
 		memset(&pdata, 0, sizeof(pdata));
 		pdata.usb3_lpm_capable = true;
 		pdata.has_lpm_erratum = true;
+		pdata.dis_enblslpm_quirk = true;
 
 		return platform_device_add_data(pci_get_drvdata(pdev), &pdata,
 						sizeof(pdata));

drivers/usb/dwc3/platform_data.h +1 -0

index 400b197..2bb4d3a 100644
@@ -42,6 +42,7 @@ struct dwc3_platform_data {
 	unsigned rx_detect_poll_quirk:1;
 	unsigned dis_u3_susphy_quirk:1;
 	unsigned dis_u2_susphy_quirk:1;
+	unsigned dis_enblslpm_quirk:1;
 
 	unsigned tx_de_emphasis_quirk:1;
 	unsigned tx_de_emphasis:2;

Signature · 1 line

2.5.0.GIT

Signature · 1 line

balbi

John Youn

author

2015-10-02 03:10 UTC #3 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

In reply to Felipe Balbi

Quoted 17 lines · Felipe Balbi

Hi,
Quoted 8 lines · John Youn
This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only.
The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However, the underlying IP is different and the GSNPSID and version numbers are different.
Quoted 5 lines
The DWC_usb31 version register is actually lower in value than the full GSNPSID of the DWC_usb3 IP. So if we are on DWC_usb3 IP just store the lower word of the GSNPSID instead of the full register. Then adjust the revision constants to match. This will allow existing revision checks to continue to work when running on the new IP.

Quoted 4 lines

I would rather not touch those constants at all. We can have the driver set a is_dwc31 flag and use if !is_dwc31 && rev < XYZ for the revision checks.
It's more work, but it seems better IMO.

I initially did it like that but it got really messy and it would make it harder to port back to stable kernels...

Quoted 8 lines

Quoted 5 lines
Finally add a documentation note about the revision numbering and checking with regards to the old and new IP. Because these are different IPs which will both continue to be supported, feature sets and revisions checks may not sync-up across future versions.
and this is why I prefer to have the flag :-) We can run different revision check methods depending if we're running on dwc3 or dwc31.

All of the existing checks apply to both. The mismatch condition will be the exception.

Quoted 9 lines

Quoted 6 lines
From now, any check based on a revision (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.
Cc <[email protected]> # v3.18+
I really fail to how any of these patches in this series apply for stable. Care to explain ?

We have some prototyping products that are stuck on 3.18 stable kernels and will continue to ship with that for some time. We'd like to run the USB 3.1 controller on those platforms. Without these version id and version number updates dwc3 will not work with the USB 3.1 IP.

I think the plan is to update those platforms to 4.2 eventually. So even then it will still need this patch.

Also it will help out any customers stuck on earlier kernels.

How would you advise we handle this, with the version id and number changes?

I can make the changes as you suggest but it might be a pain to apply it to stable kernels.

The other patches in this series tagged for stable are to support these same platforms on 3.18+. Either so that they can work at all (such as missing PCI IDs) or to pass some compliance tests (LPM flags in platform data, enblslpm quirk).

Quoted 45 lines

Quoted 12 lines

Signed-off-by John Youn <[email protected]>

---
 drivers/usb/dwc3/core.c |  9 ++++++--
 drivers/usb/dwc3/core.h | 56 +++++++++++++++++++++++++++++++------------------
 2 files changed, 43 insertions(+), 22 deletions(-)

drivers/usb/dwc3/core.c +0 -0

index c72c8c5..566cca1 100644

drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 539

Quoted 7 lines

drivers/usb/dwc3/core.c +3 -1

@@ -534,12 +534,17 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
 	reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
 	/* This should read as U3 followed by revision number */
-	if ((reg & DWC3_GSNPSID_MASK) != 0x55330000) {
+	if ((reg & DWC3_GSNPSID_MASK) == 0x55330000) {
+		/* Detected DWC_usb3 IP */
+		dwc->revision = reg & DWC3_GSNPSREV_MASK;

leave the mask out of it and ...

drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 542

Quoted 3 lines

drivers/usb/dwc3/core.c +3 -0

+	} else if ((reg & DWC3_GSNPSID_MASK) == 0x33310000) {
+		/* Detected DWC_usb31 IP */
+		dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);

set a dwc->is_dwc31 = true flag here.

Quoted 17 lines

drivers/usb/dwc3/core.c +1 -1

+	} else {
 		dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
 		ret = -ENODEV;
 		goto err0;
 	}
-	dwc->revision = reg;
 
 	/*
 	 * Write Linux Version Code to our GUID register so it's easy to figure

drivers/usb/dwc3/core.h +0 -0

index 9188745..7446467 100644
@@ -108,6 +108,9 @@
 #define DWC3_GPRTBIMAP_FS0	0xc188
 #define DWC3_GPRTBIMAP_FS1	0xc18c

Quoted 4 lines

drivers/usb/dwc3/core.h line 112
Quoted 2 lines
drivers/usb/dwc3/core.h +2 -0
+#define DWC3_VER_NUMBER		0xc1a0
+#define DWC3_VER_TYPE		0xc1a4
what is this VER_TYPE register ?

It gives the release type, EA, GA, etc. It's not used so I can leave it out if you want.

Quoted 66 lines

Quoted 34 lines

drivers/usb/dwc3/core.h +10 ~~-10~~

@@ -661,7 +664,8 @@ struct dwc3_scratchpad_array {
  * @num_event_buffers: calculated number of event buffers
  * @u1u2: only used on revisions <1.83a for workaround
  * @maximum_speed: maximum speed requested (mainly for testing purposes)
- * @revision: revision register contents
+ * @revision: the core revision. the contents will depend on the whether
+ *            this is a usb3 or usb31 core.
  * @dr_mode: requested mode of operation
  * @usb2_phy: pointer to USB2 PHY
  * @usb3_phy: pointer to USB3 PHY

@@ -771,27 +775,39 @@ struct dwc3 {
 	u32			num_event_buffers;
 	u32			u1u2;
 	u32			maximum_speed;
+
+	/*
+	 * All 3.1 IP version constants are greater than the 3.0 IP
+	 * version constants. This works for most version checks in
+	 * dwc3. However, in the future, this may not apply as
+	 * features may be developed on newer versions of the 3.0 IP
+	 * that are not in the 3.1 IP.
+	 */
 	u32			revision;
 
-#define DWC3_REVISION_173A	0x5533173a
-#define DWC3_REVISION_175A	0x5533175a
-#define DWC3_REVISION_180A	0x5533180a
-#define DWC3_REVISION_183A	0x5533183a
-#define DWC3_REVISION_185A	0x5533185a
-#define DWC3_REVISION_187A	0x5533187a
-#define DWC3_REVISION_188A	0x5533188a
-#define DWC3_REVISION_190A	0x5533190a
-#define DWC3_REVISION_194A	0x5533194a

drivers/usb/dwc3/core.h struct dwc3 { · line 794

Quoted 10 lines

drivers/usb/dwc3/core.h +0 ~~-10~~

-#define DWC3_REVISION_200A	0x5533200a
-#define DWC3_REVISION_202A	0x5533202a
-#define DWC3_REVISION_210A	0x5533210a
-#define DWC3_REVISION_220A	0x5533220a
-#define DWC3_REVISION_230A	0x5533230a
-#define DWC3_REVISION_240A	0x5533240a
-#define DWC3_REVISION_250A	0x5533250a
-#define DWC3_REVISION_260A	0x5533260a
-#define DWC3_REVISION_270A	0x5533270a
-#define DWC3_REVISION_280A	0x5533280a

yeah, I'd rather not do all this.

Quoted 19 lines

drivers/usb/dwc3/core.h +19 -0

+/* DWC_usb3 revisions */
+#define DWC3_REVISION_173A	0x173a
+#define DWC3_REVISION_175A	0x175a
+#define DWC3_REVISION_180A	0x180a
+#define DWC3_REVISION_183A	0x183a
+#define DWC3_REVISION_185A	0x185a
+#define DWC3_REVISION_187A	0x187a
+#define DWC3_REVISION_188A	0x188a
+#define DWC3_REVISION_190A	0x190a
+#define DWC3_REVISION_194A	0x194a
+#define DWC3_REVISION_200A	0x200a
+#define DWC3_REVISION_202A	0x202a
+#define DWC3_REVISION_210A	0x210a
+#define DWC3_REVISION_220A	0x220a
+#define DWC3_REVISION_230A	0x230a
+#define DWC3_REVISION_240A	0x240a
+#define DWC3_REVISION_250A	0x250a
+#define DWC3_REVISION_260A	0x260a
+#define DWC3_REVISION_270A	0x270a

Quoted 9 lines

drivers/usb/dwc3/core.h struct dwc3 { · line 810
Quoted 4 lines
drivers/usb/dwc3/core.h +4 -0
+#define DWC3_REVISION_280A	0x280a
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a
are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?

The one in the source file is wrong. I did run it but not sure how it was working... maybe wrong bitfile. I'll look into it and fix it.

The version value is actually ASCII using all 4
bytes: "110*". The last 'a' is replaced with '*' in the register as that indicates a documentation only change with no IP changes.

John

Felipe Balbi

2015-10-02 14:05 UTC #4 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

HBi,

Quoted 18 lines · John Youn

Quoted 17 lines · Felipe Balbi
Hi,
Quoted 13 lines · John Youn
This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only.
The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However, the underlying IP is different and the GSNPSID and version numbers are different.
The DWC_usb31 version register is actually lower in value than the full GSNPSID of the DWC_usb3 IP. So if we are on DWC_usb3 IP just store the lower word of the GSNPSID instead of the full register. Then adjust the revision constants to match. This will allow existing revision checks to continue to work when running on the new IP.

Quoted 7 lines

Quoted 4 lines
I would rather not touch those constants at all. We can have the driver set a is_dwc31 flag and use if !is_dwc31 && rev < XYZ for the revision checks.
It's more work, but it seems better IMO.
I initially did it like that but it got really messy and it would make it harder to port back to stable kernels...

except that this doesn't apply to stable kernels :-) Stable is strictly for regression fixes. We _do_ get the odd new device id into stable, but only when it's really just a device id. dwc31 requires a bunch of other changes to get it to work with current driver, it's not only a new device id, right ?

Quoted 10 lines

Quoted 7 lines
Quoted 4 lines
Finally add a documentation note about the revision numbering and checking with regards to the old and new IP. Because these are different IPs which will both continue to be supported, feature sets and revisions checks may not sync-up across future versions.
and this is why I prefer to have the flag :-) We can run different revision check methods depending if we're running on dwc3 or dwc31.
All of the existing checks apply to both. The mismatch condition will be the exception.

okay. Let's take one example:

	if (dwc->revision < DWC3_REVISION_220A) {
		reg |= DWC3_DCFG_SUPERSPEED;
	} else {
	...

So this is a check that's only valid for DWC3 because DWC3 was the one which had this bug, not DWC31. In order to skip this for DWC31 we should have something like:

	if (!dwc->is_dwc31 && dwc->revision < DWC3_REVISION_220A) {
	...

it looks awful, but this is only the case because SNPS made the revision of the newer cores lower than the previous ones :-p if you used 0x55340000 for example, we wouldn't have this problem.

Yeah, difficult choice. This is_dwc31 will look awful. How about using bit31 of the revision as a is_dwc31 flag ? We don't touch the older revisions and we're gonna be using a reserved bit as a flag. Then, the revision check would look like:

     reg = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
     
     /**
      * NOTICE: we're using bit 31 as a "is dwc3.1" flag. This is really
      * just so dwc31 revisions are always larger than dwc3.
      */
     reg |= DWC3_REVISION_IS_DWC31;

Quoted 15 lines

Quoted 8 lines
Quoted 5 lines
From now, any check based on a revision (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.
Cc <[email protected]> # v3.18+
I really fail to how any of these patches in this series apply for stable. Care to explain ?
We have some prototyping products that are stuck on 3.18 stable kernels and will continue to ship with that for some time. We'd like to run the USB 3.1 controller on those platforms. Without these version id and version number updates dwc3 will not work with the USB 3.1 IP.

Quoted 7 lines

I think the plan is to update those platforms to 4.2 eventually. So even then it will still need this patch.
Also it will help out any customers stuck on earlier kernels.
How would you advise we handle this, with the version id and number changes?

I have a feeling the answer to that will be that you will need to backport your own patches :-( Or upgrade to the latest kernel around once your patches get merged.

Would you care to explain why upgrading the kernel is so complex for this prototyping solution ? I suppose you're not using HAPS as a PCIe card on a common desktop PC, then ?

Quoted 55 lines

I can make the changes as you suggest but it might be a pain to apply it to stable kernels.
The other patches in this series tagged for stable are to support these same platforms on 3.18+. Either so that they can work at all (such as missing PCI IDs) or to pass some compliance tests (LPM flags in platform data, enblslpm quirk).
Quoted 45 lines
Quoted 12 lines
Signed-off-by John Youn <[email protected]>
---
 drivers/usb/dwc3/core.c |  9 ++++++--
 drivers/usb/dwc3/core.h | 56 +++++++++++++++++++++++++++++++------------------
 2 files changed, 43 insertions(+), 22 deletions(-)
drivers/usb/dwc3/core.c +0 -0
index c72c8c5..566cca1 100644
drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 539
Quoted 7 lines
drivers/usb/dwc3/core.c +3 -1
@@ -534,12 +534,17 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
 	reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
 	/* This should read as U3 followed by revision number */
-	if ((reg & DWC3_GSNPSID_MASK) != 0x55330000) {
+	if ((reg & DWC3_GSNPSID_MASK) == 0x55330000) {
+		/* Detected DWC_usb3 IP */
+		dwc->revision = reg & DWC3_GSNPSREV_MASK;
leave the mask out of it and ...
drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 542
Quoted 3 lines
drivers/usb/dwc3/core.c +3 -0
+	} else if ((reg & DWC3_GSNPSID_MASK) == 0x33310000) {
+		/* Detected DWC_usb31 IP */
+		dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
set a dwc->is_dwc31 = true flag here.
Quoted 17 lines
drivers/usb/dwc3/core.c +1 -1
+	} else {
 		dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
 		ret = -ENODEV;
 		goto err0;
 	}
-	dwc->revision = reg;
 
 	/*
 	 * Write Linux Version Code to our GUID register so it's easy to figure
drivers/usb/dwc3/core.h +0 -0
index 9188745..7446467 100644
@@ -108,6 +108,9 @@
 #define DWC3_GPRTBIMAP_FS0	0xc188
 #define DWC3_GPRTBIMAP_FS1	0xc18c
 

Quoted 7 lines

Quoted 4 lines
drivers/usb/dwc3/core.h line 112
Quoted 2 lines
drivers/usb/dwc3/core.h +2 -0
+#define DWC3_VER_NUMBER		0xc1a0
+#define DWC3_VER_TYPE		0xc1a4
what is this VER_TYPE register ?
It gives the release type, EA, GA, etc. It's not used so I can leave it out if you want.

no, we can keep it here. Was just curious :-)

Quoted 75 lines

Quoted 65 lines

Quoted 33 lines

drivers/usb/dwc3/core.h +10 ~~-10~~

@@ -661,7 +664,8 @@ struct dwc3_scratchpad_array {
  * @num_event_buffers: calculated number of event buffers
  * @u1u2: only used on revisions <1.83a for workaround
  * @maximum_speed: maximum speed requested (mainly for testing purposes)
- * @revision: revision register contents
+ * @revision: the core revision. the contents will depend on the whether
+ *            this is a usb3 or usb31 core.
  * @dr_mode: requested mode of operation
  * @usb2_phy: pointer to USB2 PHY
  * @usb3_phy: pointer to USB3 PHY

@@ -771,27 +775,39 @@ struct dwc3 {
 	u32			num_event_buffers;
 	u32			u1u2;
 	u32			maximum_speed;
+
+	/*
+	 * All 3.1 IP version constants are greater than the 3.0 IP
+	 * version constants. This works for most version checks in
+	 * dwc3. However, in the future, this may not apply as
+	 * features may be developed on newer versions of the 3.0 IP
+	 * that are not in the 3.1 IP.
+	 */
 	u32			revision;
 
-#define DWC3_REVISION_173A	0x5533173a
-#define DWC3_REVISION_175A	0x5533175a
-#define DWC3_REVISION_180A	0x5533180a
-#define DWC3_REVISION_183A	0x5533183a
-#define DWC3_REVISION_185A	0x5533185a
-#define DWC3_REVISION_187A	0x5533187a
-#define DWC3_REVISION_188A	0x5533188a
-#define DWC3_REVISION_190A	0x5533190a
-#define DWC3_REVISION_194A	0x5533194a

drivers/usb/dwc3/core.h struct dwc3 { · line 794

Quoted 10 lines

drivers/usb/dwc3/core.h +0 ~~-10~~

-#define DWC3_REVISION_200A	0x5533200a
-#define DWC3_REVISION_202A	0x5533202a
-#define DWC3_REVISION_210A	0x5533210a
-#define DWC3_REVISION_220A	0x5533220a
-#define DWC3_REVISION_230A	0x5533230a
-#define DWC3_REVISION_240A	0x5533240a
-#define DWC3_REVISION_250A	0x5533250a
-#define DWC3_REVISION_260A	0x5533260a
-#define DWC3_REVISION_270A	0x5533270a
-#define DWC3_REVISION_280A	0x5533280a

yeah, I'd rather not do all this.

Quoted 19 lines

drivers/usb/dwc3/core.h +19 -0

+/* DWC_usb3 revisions */
+#define DWC3_REVISION_173A	0x173a
+#define DWC3_REVISION_175A	0x175a
+#define DWC3_REVISION_180A	0x180a
+#define DWC3_REVISION_183A	0x183a
+#define DWC3_REVISION_185A	0x185a
+#define DWC3_REVISION_187A	0x187a
+#define DWC3_REVISION_188A	0x188a
+#define DWC3_REVISION_190A	0x190a
+#define DWC3_REVISION_194A	0x194a
+#define DWC3_REVISION_200A	0x200a
+#define DWC3_REVISION_202A	0x202a
+#define DWC3_REVISION_210A	0x210a
+#define DWC3_REVISION_220A	0x220a
+#define DWC3_REVISION_230A	0x230a
+#define DWC3_REVISION_240A	0x240a
+#define DWC3_REVISION_250A	0x250a
+#define DWC3_REVISION_260A	0x260a
+#define DWC3_REVISION_270A	0x270a

Quoted 9 lines

drivers/usb/dwc3/core.h struct dwc3 { · line 810
Quoted 4 lines
drivers/usb/dwc3/core.h +4 -0
+#define DWC3_REVISION_280A	0x280a
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a
are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?

Quoted 7 lines

The one in the source file is wrong. I did run it but not sure how it was working... maybe wrong bitfile. I'll look into it and fix it.
The version value is actually ASCII using all 4
bytes: "110*". The last 'a' is replaced with '*' in the register as that indicates a documentation only change with no IP changes.

and I suppose it's already too late to change that :-p It would've been great to maintain the previous method and just make sure it's higher then dwc3.

Signature · 1 line

balbi

John Youn

author

2015-10-02 19:16 UTC #5 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Quoted 26 lines · Felipe Balbi

HBi,
Quoted 23 lines · John Youn
Quoted 21 lines · Felipe Balbi
Hi,
Quoted 8 lines · John Youn
This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only.
The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However, the underlying IP is different and the GSNPSID and version numbers are different.
Quoted 5 lines
The DWC_usb31 version register is actually lower in value than the full GSNPSID of the DWC_usb3 IP. So if we are on DWC_usb3 IP just store the lower word of the GSNPSID instead of the full register. Then adjust the revision constants to match. This will allow existing revision checks to continue to work when running on the new IP.
I would rather not touch those constants at all. We can have the driver set a is_dwc31 flag and use if !is_dwc31 && rev < XYZ for the revision checks.
It's more work, but it seems better IMO.

Quoted 7 lines

Quoted 2 lines
I initially did it like that but it got really messy and it would make it harder to port back to stable kernels...
except that this doesn't apply to stable kernels :-) Stable is strictly for regression fixes. We _do_ get the odd new device id into stable, but only when it's really just a device id. dwc31 requires a bunch of other changes to get it to work with current driver, it's not only a new device id, right ?

My understanding is that small fixes, new device IDs, and quirks are some of the things appropriate to submit to stable. I think everything here tagged for stable is in one of those categories.

This patch is the minimal change required just to get the driver loaded and running with this new hardware. I would put it in the same category of change as a new device ID. We just have a new version ID that needs to be checked against so that the probe doesn't fail.

We don't plan to do any more than this for older kernels, for example to add support for USB 3.1 and gen 2 speed.

Quoted 35 lines

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Finally add a documentation note about the revision numbering and checking with regards to the old and new IP. Because these are different IPs which will both continue to be supported, feature sets and revisions checks may not sync-up across future versions.
and this is why I prefer to have the flag :-) We can run different revision check methods depending if we're running on dwc3 or dwc31.
All of the existing checks apply to both. The mismatch condition will be the exception.
okay. Let's take one example:
	if (dwc->revision < DWC3_REVISION_220A) {
		reg |= DWC3_DCFG_SUPERSPEED;
	} else {
	...
So this is a check that's only valid for DWC3 because DWC3 was the one which had this bug, not DWC31. In order to skip this for DWC31 we should have something like:
	if (!dwc->is_dwc31 && dwc->revision < DWC3_REVISION_220A) {
	...
it looks awful, but this is only the case because SNPS made the revision of the newer cores lower than the previous ones :-p if you used 0x55340000 for example, we wouldn't have this problem.
Yeah, difficult choice. This is_dwc31 will look awful. How about using bit31 of the revision as a is_dwc31 flag ? We don't touch the older revisions and we're gonna be using a reserved bit as a flag. Then, the revision check would look like:

Quoted 8 lines

     reg = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
     
     /**
      * NOTICE: we're using bit 31 as a "is dwc3.1" flag. This is really
      * just so dwc31 revisions are always larger than dwc3.
      */
     reg |= DWC3_REVISION_IS_DWC31;

I'm good with that.

Quoted 23 lines

Quoted 15 lines
Quoted 8 lines
Quoted 5 lines
From now, any check based on a revision (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.
Cc <[email protected]> # v3.18+
I really fail to how any of these patches in this series apply for stable. Care to explain ?
We have some prototyping products that are stuck on 3.18 stable kernels and will continue to ship with that for some time. We'd like to run the USB 3.1 controller on those platforms. Without these version id and version number updates dwc3 will not work with the USB 3.1 IP.
Quoted 7 lines
I think the plan is to update those platforms to 4.2 eventually. So even then it will still need this patch.
Also it will help out any customers stuck on earlier kernels.
How would you advise we handle this, with the version id and number changes?

Quoted 7 lines

I have a feeling the answer to that will be that you will need to backport your own patches :-( Or upgrade to the latest kernel around once your patches get merged.
Would you care to explain why upgrading the kernel is so complex for this prototyping solution ? I suppose you're not using HAPS as a PCIe card on a common desktop PC, then ?

I don't know the technical reasons why. One platform is ARM based and using the 3.18 Linaro stable kernel. Another uses our ARC platform which is also on 3.18.

We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.

Do you have any objections to these going into stable?

Regards,
John

Quoted 152 lines

Quoted 56 lines
I can make the changes as you suggest but it might be a pain to apply it to stable kernels.
The other patches in this series tagged for stable are to support these same platforms on 3.18+. Either so that they can work at all (such as missing PCI IDs) or to pass some compliance tests (LPM flags in platform data, enblslpm quirk).
Quoted 45 lines
Quoted 12 lines
Signed-off-by John Youn <[email protected]>
---
 drivers/usb/dwc3/core.c |  9 ++++++--
 drivers/usb/dwc3/core.h | 56 +++++++++++++++++++++++++++++++------------------
 2 files changed, 43 insertions(+), 22 deletions(-)
drivers/usb/dwc3/core.c +0 -0
index c72c8c5..566cca1 100644
drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 539
Quoted 7 lines
drivers/usb/dwc3/core.c +3 -1
@@ -534,12 +534,17 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
 	reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
 	/* This should read as U3 followed by revision number */
-	if ((reg & DWC3_GSNPSID_MASK) != 0x55330000) {
+	if ((reg & DWC3_GSNPSID_MASK) == 0x55330000) {
+		/* Detected DWC_usb3 IP */
+		dwc->revision = reg & DWC3_GSNPSREV_MASK;
leave the mask out of it and ...
drivers/usb/dwc3/core.c static int dwc3_core_init(struct dwc3 *dwc) · line 542
Quoted 3 lines
drivers/usb/dwc3/core.c +3 -0
+	} else if ((reg & DWC3_GSNPSID_MASK) == 0x33310000) {
+		/* Detected DWC_usb31 IP */
+		dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
set a dwc->is_dwc31 = true flag here.
Quoted 17 lines
drivers/usb/dwc3/core.c +1 -1
+	} else {
 		dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
 		ret = -ENODEV;
 		goto err0;
 	}
-	dwc->revision = reg;
 
 	/*
 	 * Write Linux Version Code to our GUID register so it's easy to figure
drivers/usb/dwc3/core.h +0 -0
index 9188745..7446467 100644
@@ -108,6 +108,9 @@
 #define DWC3_GPRTBIMAP_FS0	0xc188
 #define DWC3_GPRTBIMAP_FS1	0xc18c
 
Quoted 7 lines
Quoted 4 lines
drivers/usb/dwc3/core.h line 112
Quoted 2 lines
drivers/usb/dwc3/core.h +2 -0
+#define DWC3_VER_NUMBER		0xc1a0
+#define DWC3_VER_TYPE		0xc1a4
what is this VER_TYPE register ?
It gives the release type, EA, GA, etc. It's not used so I can leave it out if you want.
no, we can keep it here. Was just curious :-)
Quoted 75 lines
Quoted 65 lines
Quoted 33 lines
drivers/usb/dwc3/core.h +10 ~~-10~~
@@ -661,7 +664,8 @@ struct dwc3_scratchpad_array {
  * @num_event_buffers: calculated number of event buffers
  * @u1u2: only used on revisions <1.83a for workaround
  * @maximum_speed: maximum speed requested (mainly for testing purposes)
- * @revision: revision register contents
+ * @revision: the core revision. the contents will depend on the whether
+ *            this is a usb3 or usb31 core.
  * @dr_mode: requested mode of operation
  * @usb2_phy: pointer to USB2 PHY
  * @usb3_phy: pointer to USB3 PHY
@@ -771,27 +775,39 @@ struct dwc3 {
 	u32			num_event_buffers;
 	u32			u1u2;
 	u32			maximum_speed;
+
+	/*
+	 * All 3.1 IP version constants are greater than the 3.0 IP
+	 * version constants. This works for most version checks in
+	 * dwc3. However, in the future, this may not apply as
+	 * features may be developed on newer versions of the 3.0 IP
+	 * that are not in the 3.1 IP.
+	 */
 	u32			revision;
 
-#define DWC3_REVISION_173A	0x5533173a
-#define DWC3_REVISION_175A	0x5533175a
-#define DWC3_REVISION_180A	0x5533180a
-#define DWC3_REVISION_183A	0x5533183a
-#define DWC3_REVISION_185A	0x5533185a
-#define DWC3_REVISION_187A	0x5533187a
-#define DWC3_REVISION_188A	0x5533188a
-#define DWC3_REVISION_190A	0x5533190a
-#define DWC3_REVISION_194A	0x5533194a
drivers/usb/dwc3/core.h struct dwc3 { · line 794
Quoted 10 lines
drivers/usb/dwc3/core.h +0 ~~-10~~
-#define DWC3_REVISION_200A	0x5533200a
-#define DWC3_REVISION_202A	0x5533202a
-#define DWC3_REVISION_210A	0x5533210a
-#define DWC3_REVISION_220A	0x5533220a
-#define DWC3_REVISION_230A	0x5533230a
-#define DWC3_REVISION_240A	0x5533240a
-#define DWC3_REVISION_250A	0x5533250a
-#define DWC3_REVISION_260A	0x5533260a
-#define DWC3_REVISION_270A	0x5533270a
-#define DWC3_REVISION_280A	0x5533280a
yeah, I'd rather not do all this.
Quoted 19 lines
drivers/usb/dwc3/core.h +19 -0
+/* DWC_usb3 revisions */
+#define DWC3_REVISION_173A	0x173a
+#define DWC3_REVISION_175A	0x175a
+#define DWC3_REVISION_180A	0x180a
+#define DWC3_REVISION_183A	0x183a
+#define DWC3_REVISION_185A	0x185a
+#define DWC3_REVISION_187A	0x187a
+#define DWC3_REVISION_188A	0x188a
+#define DWC3_REVISION_190A	0x190a
+#define DWC3_REVISION_194A	0x194a
+#define DWC3_REVISION_200A	0x200a
+#define DWC3_REVISION_202A	0x202a
+#define DWC3_REVISION_210A	0x210a
+#define DWC3_REVISION_220A	0x220a
+#define DWC3_REVISION_230A	0x230a
+#define DWC3_REVISION_240A	0x240a
+#define DWC3_REVISION_250A	0x250a
+#define DWC3_REVISION_260A	0x260a
+#define DWC3_REVISION_270A	0x270a
Quoted 9 lines
drivers/usb/dwc3/core.h struct dwc3 { · line 810
Quoted 4 lines
drivers/usb/dwc3/core.h +4 -0
+#define DWC3_REVISION_280A	0x280a
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a
are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?
Quoted 7 lines
The one in the source file is wrong. I did run it but not sure how it was working... maybe wrong bitfile. I'll look into it and fix it.
The version value is actually ASCII using all 4
bytes: "110*". The last 'a' is replaced with '*' in the register as that indicates a documentation only change with no IP changes.
and I suppose it's already too late to change that :-p It would've been great to maintain the previous method and just make sure it's higher then dwc3.

Felipe Balbi

2015-10-02 19:21 UTC #6 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Hi,

Quoted 31 lines · John Youn

Quoted 23 lines
Quoted 15 lines
Quoted 8 lines
Quoted 5 lines
From now, any check based on a revision (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP and make the check accordingly.
Cc <[email protected]> # v3.18+
I really fail to how any of these patches in this series apply for stable. Care to explain ?
We have some prototyping products that are stuck on 3.18 stable kernels and will continue to ship with that for some time. We'd like to run the USB 3.1 controller on those platforms. Without these version id and version number updates dwc3 will not work with the USB 3.1 IP.
Quoted 7 lines
I think the plan is to update those platforms to 4.2 eventually. So even then it will still need this patch.
Also it will help out any customers stuck on earlier kernels.
How would you advise we handle this, with the version id and number changes?
Quoted 7 lines
I have a feeling the answer to that will be that you will need to backport your own patches :-( Or upgrade to the latest kernel around once your patches get merged.
Would you care to explain why upgrading the kernel is so complex for this prototyping solution ? I suppose you're not using HAPS as a PCIe card on a common desktop PC, then ?

Quoted 8 lines

I don't know the technical reasons why. One platform is ARM based and using the 3.18 Linaro stable kernel. Another uses our ARC platform which is also on 3.18.
We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.
Do you have any objections to these going into stable?

I'm not the one you need to convince. That would be Greg :-)

--
balbi

John Youn

author

2015-10-02 19:47 UTC #11 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

In reply to John Youn

Quoted 13 lines · John Youn

Quoted 11 lines · Felipe Balbi
Hi,
drivers/usb/dwc3/core.h struct dwc3 { · line 810
Quoted 3 lines · John Youn
drivers/usb/dwc3/core.h +3 -0
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a
are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?

Quoted 8 lines

The one in the source file is wrong. I did run it but not sure how it was working... maybe wrong bitfile. I'll look into it and fix it.
The version value is actually ASCII using all 4
bytes: "110*". The last 'a' is replaced with '*' in the register as that indicates a documentation only change with no IP changes.

Correcting myself, the source is right the first time.

The reason we check for "3331" in probe is because the 3.1 core uses GSNPSID strictly as an ID register not a version.

3.0 IP:
GSNPSID = 0x5533 (ID) + 0x260a (VERSION)

3.1 IP:
GSNPSID = "33313130" (ID)
VER_NUMBER = "3131302a" (VERSION)

Regards,
John

Felipe Balbi

2015-10-02 19:55 UTC #12 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Quoted 28 lines · John Youn

Quoted 13 lines · John Youn
Quoted 11 lines · Felipe Balbi
Hi,
drivers/usb/dwc3/core.h struct dwc3 { · line 810
Quoted 3 lines · John Youn
drivers/usb/dwc3/core.h +3 -0
+
+/* DWC_usb31 revisions */
+#define DWC3_USB31_REVISION_110A	0x3131302a
are you sure you tested this ? Above you check for 0x33310000 but here you use 0x3131 ? What gives ? Also, it seems odd that revision 1.10a is actually 3.02a in HW, is this really correct ?
Quoted 8 lines
The one in the source file is wrong. I did run it but not sure how it was working... maybe wrong bitfile. I'll look into it and fix it.
The version value is actually ASCII using all 4
bytes: "110*". The last 'a' is replaced with '*' in the register as that indicates a documentation only change with no IP changes.
Correcting myself, the source is right the first time.
The reason we check for "3331" in probe is because the 3.1 core uses GSNPSID strictly as an ID register not a version.

Quoted 6 lines

3.0 IP:
GSNPSID = 0x5533 (ID) + 0x260a (VERSION)
3.1 IP:
GSNPSID = "33313130" (ID)
VER_NUMBER = "3131302a" (VERSION)

oh all right, thanks for clarifying. :-)

Signature · 1 line

balbi

Greg KH

maintainer

2015-10-02 22:02 UTC #7 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

In reply to Felipe Balbi

Quoted 6 lines · Felipe Balbi

Quoted 4 lines
We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.
Do you have any objections to these going into stable?
I'm not the one you need to convince. That would be Greg :-)

What's the git commit id of the patch in Linus's tree?

thanks,

greg k-h

Felipe Balbi

2015-10-03 00:33 UTC #8 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Quoted 9 lines · Greg KH

Quoted 6 lines · Felipe Balbi
Quoted 4 lines
We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.
Do you have any objections to these going into stable?
I'm not the one you need to convince. That would be Greg :-)
What's the git commit id of the patch in Linus's tree?

the patch doesn't exist yet. John sent a series wich I don't feel it fits stable. The new device IDs, sure, but all the other changes which, granted, are related, but don't seem like stable material IMO.

For reference, here are all the patches:

http://www.spinics.net/lists/linux-usb/msg130712.html
http://www.spinics.net/lists/linux-usb/msg130711.html
http://www.spinics.net/lists/linux-usb/msg130717.html
http://www.spinics.net/lists/linux-usb/msg130713.html
http://www.spinics.net/lists/linux-usb/msg130716.html
http://www.spinics.net/lists/linux-usb/msg130714.html

Signature · 1 line

balbi

John Youn

author

2015-10-03 01:14 UTC #9 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Quoted 15 lines · Felipe Balbi

Quoted 9 lines · Greg KH
Quoted 6 lines · Felipe Balbi
Quoted 4 lines
We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.
Do you have any objections to these going into stable?
I'm not the one you need to convince. That would be Greg :-)
What's the git commit id of the patch in Linus's tree?
the patch doesn't exist yet. John sent a series wich I don't feel it fits stable. The new device IDs, sure, but all the other changes which, granted, are related, but don't seem like stable material IMO.

Quoted 9 lines

For reference, here are all the patches:
http://www.spinics.net/lists/linux-usb/msg130712.html
http://www.spinics.net/lists/linux-usb/msg130711.html
http://www.spinics.net/lists/linux-usb/msg130717.html
http://www.spinics.net/lists/linux-usb/msg130713.html
http://www.spinics.net/lists/linux-usb/msg130716.html
http://www.spinics.net/lists/linux-usb/msg130714.html

Hi Greg,

I'm in the process of simplifying and resubmitting these.

But to summarize, these are all small changes to get newer hardware to work with older drivers and to address failures with certain hardware for compliance testing.

Patch 1 allows the dwc3 driver to work with newer hardware. An ID register in the hardware has changed causing the probe to fail. And we ensure the new version numbers are higher than older versions.

Patch 2-3 adds PCI Device IDs so that dwc3 will load with various versions of our hardware.

Patch 4 adds the correct driver parameters for our hardware.

Patch 5 adds a quirk for a problem with some PHYs.

Patch 6 is not tagged for stable (formatting only).

Are these kind of changes appropriate for stable?

The reason we want them in stable is because we have some products that are stuck on 3.18 currently and later will be updated to 4.2.

Regards,
John

Greg KH

maintainer

2015-10-03 05:54 UTC #10 lore raw

Re: [PATCH 1/6] usb: dwc3: Support Synopsys USB 3.1 IP

Quoted 42 lines · John Youn

Quoted 15 lines · Felipe Balbi
Quoted 9 lines · Greg KH
Quoted 6 lines · Felipe Balbi
Quoted 4 lines
We're trying to avoid the situation where where we have to ship patches or maintain a separate kernel tree.
Do you have any objections to these going into stable?
I'm not the one you need to convince. That would be Greg :-)
What's the git commit id of the patch in Linus's tree?
the patch doesn't exist yet. John sent a series wich I don't feel it fits stable. The new device IDs, sure, but all the other changes which, granted, are related, but don't seem like stable material IMO.
Quoted 9 lines
For reference, here are all the patches:
http://www.spinics.net/lists/linux-usb/msg130712.html
http://www.spinics.net/lists/linux-usb/msg130711.html
http://www.spinics.net/lists/linux-usb/msg130717.html
http://www.spinics.net/lists/linux-usb/msg130713.html
http://www.spinics.net/lists/linux-usb/msg130716.html
http://www.spinics.net/lists/linux-usb/msg130714.html
Hi Greg,
I'm in the process of simplifying and resubmitting these.
But to summarize, these are all small changes to get newer hardware to work with older drivers and to address failures with certain hardware for compliance testing.
Patch 1 allows the dwc3 driver to work with newer hardware. An ID register in the hardware has changed causing the probe to fail. And we ensure the new version numbers are higher than older versions.
Patch 2-3 adds PCI Device IDs so that dwc3 will load with various versions of our hardware.

Quoted 7 lines

Patch 4 adds the correct driver parameters for our hardware.
Patch 5 adds a quirk for a problem with some PHYs.
Patch 6 is not tagged for stable (formatting only).
Are these kind of changes appropriate for stable?

Read Documentation/stable_kernel_rules.txt and you tell me. I'm not going to dig up the web links at the moment, sorry, as I have over 400 patches in my queue to work on to be applied to the stable trees that are already in Linus's tree. Let me work on those now, instead of hypothetical ones that have not been accepted yet :)

Quoted 3 lines

The reason we want them in stable is because we have some products that are stuck on 3.18 currently and later will be updated to 4.2.

Then submit them properly, and when they are in Linus's tree, I'll get notified of them and if I think they are not acceptable, I'll let you know.

thanks,

greg k-h