Re: [PATCH] usb: gadget: USB_RENESAS_USBHS_UDC should depend on HAS_DMA
Hi Geert, (2014/08/30 4:31), Geert Uytterhoeven wrote: If NO_DMA=y: drivers/built-in.o: In function `usbhsg_dma_map_ctrl': mod_gadget.c:(.text+0x53b226): undefined reference to `usb_gadget_map_request' mod_gadget.c:(.text+0x53b242): undefined reference to `usb_gadget_unmap_request' Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/usb/gadget/udc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig index 5151f947a4f5..00171d436cf8 100644 --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -163,7 +163,7 @@ config USB_R8A66597 config USB_RENESAS_USBHS_UDC tristate 'Renesas USBHS controller' - depends on USB_RENESAS_USBHS + depends on USB_RENESAS_USBHS HAS_DMA help Renesas USBHS is a discrete USB host and peripheral controller chip that supports both full and high speed USB 2.0 data transfers. Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: renesas_usbhs: fix driver dependencies
(2014/09/02 8:39), Simon Horman wrote: On Mon, Sep 01, 2014 at 06:40:50PM +0200, Geert Uytterhoeven wrote: On Mon, Sep 1, 2014 at 4:24 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Renesas USBHS controller support should be available only on Renesas ARM SoCs and SuperH architecture. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com --- v2: - s/ARCH_SH/SUPERH/ (thanks to Sergei Shtylyov) Acked-by: Geert Uytterhoeven geert+rene...@glider.be Acked-by: Simon Horman horms+rene...@verge.net.au Acked-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: gadget: Fix desc NULL pointer in dwc3_gadget_ep_queue()
dep-endpoint.desc is checked at the beginning of
dwc3_gadget_ep_queue(), but after that it may be set to NULL
by another thread and then accessed again in dwc3_gadget_ep_queue().
This will lead to kernel oops.
Expand spinlock protection area to aviod race condition.
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
Signed-off-by: Jiebing Li jiebing...@intel.com
---
drivers/usb/dwc3/gadget.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 349cacc..e8fb231 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1225,16 +1225,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
struct usb_request *request,
int ret;
+ spin_lock_irqsave(dwc-lock, flags);
if (!dep-endpoint.desc) {
dev_dbg(dwc-dev, trying to queue request %p to disabled %s\n,
request, ep-name);
+ spin_unlock_irqrestore(dwc-lock, flags);
return -ESHUTDOWN;
}
dev_vdbg(dwc-dev, queing request %p to %s length %d\n,
request, ep-name, request-length);
- spin_lock_irqsave(dwc-lock, flags);
ret = __dwc3_gadget_ep_queue(dep, req);
spin_unlock_irqrestore(dwc-lock, flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: add tracepoints to aid debugging
On Wed, Aug 27, 2014 at 05:26:37AM +0800, Felipe Balbi wrote: Hi Felipe, Hi, On Tue, Aug 26, 2014 at 09:21:55PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, August 26, 2014 1:42 PM On Fri, Aug 22, 2014 at 04:56:46PM -0500, Felipe Balbi wrote: ... yeah, it took longer than expected (been busy lately), but here's an example trace with all trace points enabled: # tracer: nop # # entries-in-buffer/entries-written: 1038/1038 #P:1 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | idle-0 [000] d.h. 155.653881: dwc3_readl: add fa39c40c value 0004 idle-0 [000] d.h. 155.653903: dwc3_readl: add fa39c408 value 0100 idle-0 [000] d.h. 155.653908: dwc3_writel: addr fa39c408 value 8100 Looks like there is an inconsistency between readl/writel (add vs. addr). eagle eyes :-) Other than that, I really like this. Reviewed-by: Paul Zimmerman pa...@synopsys.com thanks, pushed to my dwc3-tracepoints branch with your Reviewed-by, if nobody makes any other comments until Friday, I'll promote it to testing/next and later to next. If we can also add following two items: -- depcmd: trace depcmd params and cmd in dwc3_send_gadget_ep_cmd -- TRB: trace trb fields, trb address and ep number for which trb has been prepared in dwc3_prepare_one_trb These items were pretty helpful in debugging isoc issues. ~Pratyush cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi Felipe, On Tue, Sep 2, 2014 at 8:04 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK(0x3f 1) #define LINKSYSTEM_FLADJ(_x) ((_x) 1) #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) #define EXYNOS5_DRD_PHYUTMI 0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE 0x0c #define EXYNOS5_DRD_PHYCLKRST0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 21) #define PHYCLKRST_SSC_RANGE(_x) ((_x) 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 8) #define PHYCLKRST_FSEL(_x) ((_x) 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - #define PHYCLKRST_PORTRESET BIT(1) #define PHYCLKRST_COMMONONN BIT(0) #define EXYNOS5_DRD_PHYREG0 0x14 +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) +#define PHYREG0_SSC_RANGEBIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READ BIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) 2) +#define PHYREG0_CR_CAP_DATA BIT(1) +#define PHYREG0_CR_CAP_ADDR BIT(0) + #define EXYNOS5_DRD_PHYREG1 0x18 +#define PHYREG1_CR_DATA_OUT(_x) ((_x) 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM00x1c - #define PHYPARAM0_REF_USE_PADBIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 26) #define EXYNOS5_DRD_PHYPARAM10x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM 0x24 #define EXYNOS5_DRD_PHYTEST 0x28 - #define PHYTEST_POWERDOWN_SSP
[PATCH v4 9/9] usb: chipidea: add support to the generic PHY framework in ChipIdea
This patch adds support of the PHY framework for ChipIdea drivers.
Changes are done in both the ChipIdea common code and in the drivers
accessing the PHY. This is done by adding a new PHY member in
ChipIdea's structures and by taking care of it in the code.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/ci.h | 5 ++-
drivers/usb/chipidea/core.c| 74 ++
drivers/usb/chipidea/debug.c | 3 +-
drivers/usb/chipidea/host.c| 5 ++-
drivers/usb/chipidea/otg_fsm.c | 6 +++-
include/linux/usb/chipidea.h | 2 ++
6 files changed, 78 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index dac5ab6adfa2..7e9e8223672a 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -161,7 +161,8 @@ struct hw_bank {
* @test_mode: the selected test mode
* @platdata: platform specific information supplied by parent device
* @vbus_active: is VBUS active
- * @usb_phy: pointer to USB PHY, if any
+ * @phy: pointer to PHY, if any
+ * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
* @hcd: pointer to usb_hcd for ehci host driver
* @debugfs: root dentry for this controller in debugfs
* @id_event: indicates there is an id event, and handled at ci_otg_work
@@ -202,6 +203,8 @@ struct ci_hdrc {
struct ci_hdrc_platform_data*platdata;
int vbus_active;
+ struct phy *phy;
+ /* old usb_phy interface */
struct usb_phy *usb_phy;
struct usb_hcd *hcd;
struct dentry *debugfs;
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a8cd35fd8175..7c617b765bf2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -47,6 +47,7 @@
#include linux/delay.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/module.h
#include linux/idr.h
@@ -293,6 +294,49 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
}
/**
+ * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
+ * interfaces
+ * @ci: the controller
+ *
+ * This function returns an error code if the phy failed to init
+ */
+static int _ci_usb_phy_init(struct ci_hdrc *ci)
+{
+ int ret;
+
+ if (ci-phy) {
+ ret = phy_init(ci-phy);
+ if (ret)
+ return ret;
+
+ ret = phy_power_on(ci-phy);
+ if (ret) {
+ phy_exit(ci-phy);
+ return ret;
+ }
+ } else {
+ ret = usb_phy_init(ci-usb_phy);
+ }
+
+ return ret;
+}
+
+/**
+ * _ci_usb_phy_exit: deinitialize phy taking in account both phy and usb_phy
+ * interfaces
+ * @ci: the controller
+ */
+static void ci_usb_phy_exit(struct ci_hdrc *ci)
+{
+ if (ci-phy) {
+ phy_power_off(ci-phy);
+ phy_exit(ci-phy);
+ } else {
+ usb_phy_shutdown(ci-usb_phy);
+ }
+}
+
+/**
* ci_usb_phy_init: initialize phy according to different phy type
* @ci: the controller
*
@@ -306,7 +350,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_UTMI:
case USBPHY_INTERFACE_MODE_UTMIW:
case USBPHY_INTERFACE_MODE_HSIC:
- ret = usb_phy_init(ci-usb_phy);
+ ret = _ci_usb_phy_init(ci);
if (ret)
return ret;
hw_phymode_configure(ci);
@@ -314,12 +358,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
case USBPHY_INTERFACE_MODE_ULPI:
case USBPHY_INTERFACE_MODE_SERIAL:
hw_phymode_configure(ci);
- ret = usb_phy_init(ci-usb_phy);
+ ret = _ci_usb_phy_init(ci);
if (ret)
return ret;
break;
default:
- ret = usb_phy_init(ci-usb_phy);
+ ret = _ci_usb_phy_init(ci);
}
return ret;
@@ -595,23 +639,27 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (ci-platdata-usb_phy)
+ if (ci-platdata-phy)
+ ci-phy = ci-platdata-phy;
+ else if (ci-platdata-usb_phy)
ci-usb_phy = ci-platdata-usb_phy;
else
- ci-usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ ci-phy = devm_phy_get(dev, usb-phy);
- if (IS_ERR(ci-usb_phy)) {
- ret = PTR_ERR(ci-usb_phy);
+ if (IS_ERR(ci-phy) || (ci-phy == NULL ci-usb_phy == NULL)) {
/*
* if -ENXIO is returned, it means PHY layer wasn't
* enabled, so it makes no sense to return -EPROBE_DEFER
* in that case, since no PHY
[PATCH v4 8/9] usb: chipidea: move usb_otg into struct ci_hdrc
Move the usb_otg member from struct usb_phy to struct ci_hdrc. Rework
its initialization taking in account this modification.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/ci.h | 1 +
drivers/usb/chipidea/host.c| 5 +++--
drivers/usb/chipidea/otg_fsm.c | 16 +++-
3 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b2caa1772712..dac5ab6adfa2 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -177,6 +177,7 @@ struct ci_hdrc {
struct ci_role_driver *roles[CI_ROLE_END];
enum ci_rolerole;
boolis_otg;
+ struct usb_otg otg;
struct otg_fsm fsm;
struct ci_otg_fsm_timer_list*fsm_timer;
struct work_struct work;
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 0b67d78dd953..4fcebb6a6d14 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -85,10 +85,11 @@ static int host_start(struct ci_hdrc *ci)
if (ret) {
goto disable_reg;
} else {
- struct usb_otg *otg = ci-usb_phy-otg;
+ struct usb_otg *otg = ci-otg;
ci-hcd = hcd;
- if (otg) {
+
+ if (ci_otg_is_fsm_mode(ci)) {
otg-host = hcd-self;
hcd-self.otg_port = 1;
}
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 8a64ce87364e..862d7cb01b92 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -778,20 +778,10 @@ void ci_hdrc_otg_fsm_start(struct ci_hdrc *ci)
int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
{
int retval = 0;
- struct usb_otg *otg;
- otg = devm_kzalloc(ci-dev,
- sizeof(struct usb_otg), GFP_KERNEL);
- if (!otg) {
- dev_err(ci-dev,
- Failed to allocate usb_otg structure for ci hdrc otg!\n);
- return -ENOMEM;
- }
-
- otg-usb_phy = ci-usb_phy;
- otg-gadget = ci-gadget;
- ci-fsm.otg = otg;
- ci-usb_phy-otg = ci-fsm.otg;
+ ci-otg.usb_phy = ci-usb_phy;
+ ci-otg.gadget = ci-gadget;
+ ci-fsm.otg = ci-otg;
ci-fsm.power_up = 1;
ci-fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
ci-fsm.otg-state = OTG_STATE_UNDEFINED;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/12] ARM: dts: berlin: enable USB on the Google Chromecast
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Enable usb1 on Google Chromecast which is connected to micro-USB
plug used for external power supply, too.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index bcd81ffc495d..5c42c3bfb613 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -27,3 +27,7 @@
};
uart0 { status = okay; };
+
+usb_phy1 { status = okay; };
+
+usb1 { status = okay; };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/9] usb: rename phy to usb_phy in HCD
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/chipidea/host.c | 2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c| 8
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c | 2 +-
drivers/usb/host/ehci-msm.c | 4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
include/linux/usb/hcd.h | 2 +-
9 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index a93d950e9468..fc7541c906a2 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci)
hcd-has_tt = 1;
hcd-power_budget = ci-platdata-power_budget;
- hcd-phy = ci-transceiver;
+ hcd-usb_phy = ci-transceiver;
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index c4ed66cb9ff3..86fdce55ae16 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2628,7 +2628,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) !hcd-phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
if (IS_ERR(phy)) {
@@ -2641,7 +2641,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd-phy = phy;
+ hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2819,10 +2819,10 @@ err_create_buf:
hcd-gen_phy = NULL;
}
err_phy:
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
return retval;
}
@@ -2902,10 +2902,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
phy_put(hcd-gen_phy);
hcd-gen_phy = NULL;
}
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
usb_put_invalidate_rhdev(hcd);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 46f5161c7891..bf023b3d0366 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4461,8 +4461,8 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
if (retval)
goto fail;
- if (hcd-phy !hdev-parent)
- usb_phy_notify_connect(hcd-phy, udev-speed);
+ if (hcd-usb_phy !hdev-parent)
+ usb_phy_notify_connect(hcd-usb_phy, udev-speed);
/*
* Some superspeed devices have finished the link training process
@@ -4617,9 +4617,9 @@ static void hub_port_connect(struct usb_hub *hub, int
port1, u16 portstatus,
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd-phy !hdev-parent
+ if (hcd-usb_phy !hdev-parent
!(portstatus USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd-phy, udev-speed);
+ usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index cf2734b532a7..4bdcd3439d47 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- hcd-phy = usb_get_phy(USB_PHY_TYPE_USB2);
+ hcd-usb_phy = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(pdev-dev, hcd=0x%p ehci=0x%p, phy=0x%p\n,
- hcd, ehci, hcd-phy);
+ hcd, ehci, hcd-usb_phy);
- if (!IS_ERR_OR_NULL(hcd-phy)) {
- retval = otg_set_host(hcd-phy-otg,
+ if (!IS_ERR_OR_NULL(hcd-usb_phy)) {
+ retval =
[PATCH v4 1/9] usb: move the OTG state from the USB PHY to the OTG structure
Before using the PHY framework instead of the USB PHY one, we need to
move the OTG state into another place, since it won't be available when
USB PHY isn't used. This patch moves the OTG state into the OTG
structure, and makes all the needed modifications in the drivers
using the OTG state.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Peter Chen peter.c...@freescale.com
---
drivers/phy/phy-omap-usb2.c | 8 +---
drivers/usb/chipidea/debug.c| 3 +-
drivers/usb/chipidea/otg_fsm.c | 12 ++---
drivers/usb/common/usb-otg-fsm.c| 8 ++--
drivers/usb/host/ohci-omap.c| 2 +-
drivers/usb/musb/am35x.c| 28 +--
drivers/usb/musb/blackfin.c | 18 +++
drivers/usb/musb/da8xx.c| 28 +--
drivers/usb/musb/davinci.c | 18 +++
drivers/usb/musb/musb_core.c| 94 ++---
drivers/usb/musb/musb_dsps.c| 26 +-
drivers/usb/musb/musb_gadget.c | 36 +++---
drivers/usb/musb/musb_host.c| 8 ++--
drivers/usb/musb/musb_virthub.c | 22 -
drivers/usb/musb/omap2430.c | 30 ++--
drivers/usb/musb/tusb6010.c | 40
drivers/usb/musb/ux500.c| 10 ++--
drivers/usb/phy/phy-ab8500-usb.c| 10 ++--
drivers/usb/phy/phy-fsl-usb.c | 10 ++--
drivers/usb/phy/phy-generic.c | 4 +-
drivers/usb/phy/phy-gpio-vbus-usb.c | 10 ++--
drivers/usb/phy/phy-msm-usb.c | 34 +++---
drivers/usb/phy/phy-mv-usb.c| 46 +-
include/linux/usb/otg.h | 2 +
include/linux/usb/phy.h | 1 -
25 files changed, 252 insertions(+), 256 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 93d78359246c..3bb54e55c762 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -80,11 +80,9 @@ static int omap_usb_start_srp(struct usb_otg *otg)
static int omap_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
{
- struct usb_phy *phy = otg-phy;
-
otg-host = host;
if (!host)
- phy-state = OTG_STATE_UNDEFINED;
+ otg-state = OTG_STATE_UNDEFINED;
return 0;
}
@@ -92,11 +90,9 @@ static int omap_usb_set_host(struct usb_otg *otg, struct
usb_bus *host)
static int omap_usb_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
{
- struct usb_phy *phy = otg-phy;
-
otg-gadget = gadget;
if (!gadget)
- phy-state = OTG_STATE_UNDEFINED;
+ otg-state = OTG_STATE_UNDEFINED;
return 0;
}
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 795d6538d630..787671d40379 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -219,8 +219,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
fsm = ci-fsm;
/* -- State - */
- seq_printf(s, OTG state: %s\n\n,
- usb_otg_state_string(ci-transceiver-state));
+ usb_otg_state_string(ci-transceiver-otg.state));
/* -- State Machine Variables - */
seq_printf(s, a_bus_drop: %d\n, fsm-a_bus_drop);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index caaabc58021e..8cb2508a6b71 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -328,7 +328,7 @@ static void b_ssend_srp_tmout_func(void *ptr, unsigned long
indicator)
set_tmout(ci, indicator);
/* only vbus fall below B_sess_vld in b_idle state */
- if (ci-transceiver-state == OTG_STATE_B_IDLE)
+ if (ci-fsm.otg-state == OTG_STATE_B_IDLE)
ci_otg_queue_work(ci);
}
@@ -582,11 +582,11 @@ int ci_otg_fsm_work(struct ci_hdrc *ci)
* when there is no gadget class driver
*/
if (ci-fsm.id !(ci-driver)
- ci-transceiver-state OTG_STATE_A_IDLE)
+ ci-fsm.otg-state OTG_STATE_A_IDLE)
return 0;
if (otg_statemachine(ci-fsm)) {
- if (ci-transceiver-state == OTG_STATE_A_IDLE) {
+ if (ci-fsm.otg-state == OTG_STATE_A_IDLE) {
/*
* Further state change for cases:
* a_idle to b_idle; or
@@ -600,7 +600,7 @@ int ci_otg_fsm_work(struct ci_hdrc *ci)
ci_otg_queue_work(ci);
if (ci-id_event)
ci-id_event = false;
- } else if (ci-transceiver-state == OTG_STATE_B_IDLE) {
+ } else if (ci-fsm.otg-state == OTG_STATE_B_IDLE) {
if (ci-fsm.b_sess_vld) {
ci-fsm.power_up = 0;
/*
@@ -627,7 +627,7 @@ static void ci_otg_fsm_event(struct ci_hdrc *ci)
otg_bsess_vld = hw_read_otgsc(ci,
[PATCH v4 0/9] usb: add support for the generic PHY framework
Hi all, This is an attempt to add more common USB code aware of the generic PHY framework, while keeping the compatibility for the USB PHY one. It does not add the full support, some USB PHY specific functions not being available currently in the generic PHY subsystem (e.g. usb_phy_set_power()). But it allows to use the generic PHY framework in other cases, and might help others to convert their USB PHY drivers. A little background: I submitted a series to support USB on Berlin SoCs[1]. One patch added a new PHY driver in drivers/usb/phy and Felipe asked it to be in the generic PHY framework instead[2]. This PHY being used by a ChipIdea driver, changes were needed in ChipIdea, OTG and HCD. This is done in 3 steps: 1. moving the OTG state from the USB PHY structure to the OTG one 2. renaming the field 'phy' to 'usb_phy' 3. adding a field for the generic framework PHY and dissociating its use from the USB PHY one Step 1 is in the first patch. Steps 2 and 3 are done for OTG, and ChipIdea subsystems in patches 2-3, 7 and 9. HCD generic PHY support was made by Sergei and Yoshihiro[1]. I added some modifications to make this support consistent with this series in patches 4-6. The usb_otg has been moved into the ci_hdrc structure in ChipIdea, in patch 8. I tested it by using the ChipIdea driver I introduced, both with an USB PHY and a PHY driver successfully. I also compiled a multi_v7 kernel (ARM), with every driver I could enable in the USB section. Patches can also be found at: git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy The series applies on top of Sergei and Yoshihiro generic PHY support in HCD[2]. Thanks a lot! Antoine Changes since v3: - moved phy_exit() after phy_power_on() - fixed the PHY handling in ci_hdrc_probe() - some little fixes Changes since v2: - rebased the series on top of v3.17-rc1 (and [2]) - switched to devm_phy_get() to handle non DT cases - moved usb_otg into the ci_hdrc structure Changes since v1: - rebased the series on top of [2] (generic PHY support for HCD) - split s/phy/usb_phy/ renaming and generic PHY support in separate patches [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/272840.html [2] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg43471.html Antoine Tenart (9): usb: move the OTG state from the USB PHY to the OTG structure usb: rename phy to usb_phy in OTG usb: add support to the generic PHY framework in OTG usb: rename phy to usb_phy in HCD usb: rename gen_phy to phy in HCD usb: allow to supply the PHY in the drivers when using HCD usb: rename transceiver and phy to usb_phy in ChipIdea usb: chipidea: move usb_otg into struct ci_hdrc usb: chipidea: add support to the generic PHY framework in ChipIdea drivers/phy/phy-omap-usb2.c | 14 ++ drivers/usb/chipidea/ci.h | 8 +++- drivers/usb/chipidea/ci_hdrc_imx.c | 2 +- drivers/usb/chipidea/ci_hdrc_msm.c | 8 ++-- drivers/usb/chipidea/core.c | 74 - drivers/usb/chipidea/debug.c| 2 +- drivers/usb/chipidea/host.c | 10 ++-- drivers/usb/chipidea/otg_fsm.c | 30 +--- drivers/usb/chipidea/udc.c | 4 +- drivers/usb/common/usb-otg-fsm.c| 8 ++-- drivers/usb/core/hcd.c | 45 +- drivers/usb/core/hub.c | 8 ++-- drivers/usb/host/ehci-fsl.c | 16 +++ drivers/usb/host/ehci-hub.c | 2 +- drivers/usb/host/ehci-msm.c | 4 +- drivers/usb/host/ehci-tegra.c | 16 +++ drivers/usb/host/ohci-omap.c| 20 drivers/usb/musb/am35x.c| 28 +-- drivers/usb/musb/blackfin.c | 18 +++ drivers/usb/musb/da8xx.c| 28 +-- drivers/usb/musb/davinci.c | 18 +++ drivers/usb/musb/musb_core.c| 94 ++-- drivers/usb/musb/musb_dsps.c| 26 +- drivers/usb/musb/musb_gadget.c | 36 +++--- drivers/usb/musb/musb_host.c| 8 ++-- drivers/usb/musb/musb_virthub.c | 22 - drivers/usb/musb/omap2430.c | 30 ++-- drivers/usb/musb/tusb6010.c | 40 drivers/usb/musb/ux500.c| 10 ++-- drivers/usb/phy/phy-ab8500-usb.c| 16 +++ drivers/usb/phy/phy-fsl-usb.c | 23 - drivers/usb/phy/phy-generic.c | 6 +-- drivers/usb/phy/phy-gpio-vbus-usb.c | 14 +++--- drivers/usb/phy/phy-isp1301-omap.c | 10 ++-- drivers/usb/phy/phy-msm-usb.c | 95 +++-- drivers/usb/phy/phy-mv-usb.c| 50 +-- drivers/usb/phy/phy-samsung-usb2.c | 2 +- drivers/usb/phy/phy-tahvo.c | 8 ++-- drivers/usb/phy/phy-ulpi.c | 6 +-- include/linux/usb/chipidea.h| 4 +- include/linux/usb/hcd.h | 6
[PATCH v4 5/9] usb: rename gen_phy to phy in HCD
The patch adding support to the generic PHY framework introduced a
'gen_phy' member in the HCD structure. Rename it to 'phy' to have a
consistent USB framework.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 22 +++---
include/linux/usb/hcd.h | 4 +++-
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 86fdce55ae16..6619239baf6d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2665,7 +2665,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
phy_put(phy);
goto err_phy;
}
- hcd-gen_phy = phy;
+ hcd-phy = phy;
}
}
@@ -2812,11 +2812,11 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_create_buf:
- if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-gen_phy) {
- phy_power_off(hcd-gen_phy);
- phy_exit(hcd-gen_phy);
- phy_put(hcd-gen_phy);
- hcd-gen_phy = NULL;
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-phy) {
+ phy_power_off(hcd-phy);
+ phy_exit(hcd-phy);
+ phy_put(hcd-phy);
+ hcd-phy = NULL;
}
err_phy:
if (hcd-remove_phy hcd-usb_phy) {
@@ -2896,11 +2896,11 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
- if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-gen_phy) {
- phy_power_off(hcd-gen_phy);
- phy_exit(hcd-gen_phy);
- phy_put(hcd-gen_phy);
- hcd-gen_phy = NULL;
+ if (IS_ENABLED(CONFIG_GENERIC_PHY) hcd-phy) {
+ phy_power_off(hcd-phy);
+ phy_exit(hcd-phy);
+ phy_put(hcd-phy);
+ hcd-phy = NULL;
}
if (hcd-remove_phy hcd-usb_phy) {
usb_phy_shutdown(hcd-usb_phy);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 604d2e6e0c1c..19b3fbd1f9e1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -105,9 +105,11 @@ struct usb_hcd {
/*
* OTG and some Host controllers need software interaction with phys;
* other external phys should be software-transparent
+*
+* Keep the usb_phy for compatibility reasons, for now
*/
struct usb_phy *usb_phy;
- struct phy *gen_phy;
+ struct phy *phy;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/9] usb: add support to the generic PHY framework in OTG
This patch adds support of the PHY framework in OTG and keeps the USB
PHY compatibility. Here the only modification is to add PHY member in
the OTG structure, along with the USB PHY one.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
include/linux/usb/otg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 978fbbb0e266..52661c5da690 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -9,11 +9,14 @@
#ifndef __LINUX_USB_OTG_H
#define __LINUX_USB_OTG_H
+#include linux/phy/phy.h
#include linux/usb/phy.h
struct usb_otg {
u8 default_a;
+ struct phy *phy;
+ /* old usb_phy interface */
struct usb_phy *usb_phy;
struct usb_bus *host;
struct usb_gadget *gadget;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/12] ARM: dts: berlin: add a required reset property in the chip controller node
The chip controller node now also describes the Marvell Berlin reset
controller. Add the required 'reset-cells' property.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
arch/arm/boot/dts/berlin2.dtsi | 1 +
arch/arm/boot/dts/berlin2cd.dtsi | 1 +
arch/arm/boot/dts/berlin2q.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 9d7c810ebd0b..d7e81e124de0 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -249,6 +249,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk;
clock-names = refclk;
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index cc1df65da504..68f7032b4686 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -231,6 +231,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2cd-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk;
clock-names = refclk;
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 400c40fceccc..ffba5c3bdab8 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -332,6 +332,7 @@
chip: chip-control@ea {
compatible = marvell,berlin2q-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400, 0xdd0170 0x10;
clocks = refclk;
clock-names = refclk;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/12] ARM: dts: Berlin: enable USB on the BG2Q DMP
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index a357ce02a64e..663aedb173e0 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -7,6 +7,8 @@
*/
/dts-v1/;
+
+#include dt-bindings/gpio/gpio.h
#include berlin2q.dtsi
/ {
@@ -21,6 +23,39 @@
choosen {
bootargs = console=ttyS0,115200 earlyprintk;
};
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ reg_usb0_vbus: regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = usb0_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 8 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb1_vbus: regulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = usb1_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 10 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb2_vbus: regulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = usb2_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 12 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+ };
};
sdhci1 {
@@ -45,3 +80,21 @@
uart0 {
status = okay;
};
+
+usb_phy0 {
+ status = okay;
+};
+
+usb_phy2 {
+ status = okay;
+};
+
+usb0 {
+ vbus-supply = reg_usb0_vbus;
+ status = okay;
+};
+
+usb2 {
+ vbus-supply = reg_usb2_vbus;
+ status = okay;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/12] usb: chipidea: add a usb2 driver for ci13xxx
Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
and DMA mask, to support USB2 ChipIdea controllers that don't need
specific functions.
Tested on the Marvell Berlin SoCs USB controllers.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/usb/chipidea/Makefile | 1 +
drivers/usb/chipidea/ci_hdrc_usb2.c | 137
2 files changed, 138 insertions(+)
create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7df7b5..1fc86a2ca22d 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
# Glue/Bridge layers go here
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_usb2.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
b/drivers/usb/chipidea/ci_hdrc_usb2.c
new file mode 100644
index ..75bdbfa362b9
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Tenart antoine.ten...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/usb/chipidea.h
+#include linux/usb/hcd.h
+#include linux/usb/ulpi.h
+
+#include ci.h
+
+struct ci_hdrc_usb2_priv {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static int ci_hdrc_usb2_dt_probe(struct device *dev,
+struct ci_hdrc_platform_data *ci_pdata)
+{
+ ci_pdata-phy = of_phy_get(dev-of_node, 0);
+ if (IS_ERR(ci_pdata-phy)) {
+ if (PTR_ERR(ci_pdata-phy) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* PHY is optional */
+ ci_pdata-phy = NULL;
+ }
+
+ return 0;
+}
+
+static struct ci_hdrc_platform_data ci_default_pdata = {
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER |
+ CI_HDRC_DISABLE_STREAMING,
+};
+
+static int ci_hdrc_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct ci_hdrc_usb2_priv *priv;
+ struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(pdev-dev);
+ int ret;
+
+ if (!ci_pdata)
+ ci_pdata = ci_default_pdata;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv-clk = devm_clk_get(dev, NULL);
+ if (!IS_ERR(priv-clk)) {
+ ret = clk_prepare_enable(priv-clk);
+ if (ret) {
+ dev_err(dev, failed to enable the clock: %d\n, ret);
+ return ret;
+ }
+ }
+
+ if (dev-of_node) {
+ ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
+ if (ret)
+ return ret;
+ } else {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
+ ci_pdata-name = dev_name(pdev-dev);
+
+ priv-ci_pdev = ci_hdrc_add_device(dev, pdev-resource,
+ pdev-num_resources, ci_pdata);
+ if (IS_ERR(priv-ci_pdev)) {
+ ret = PTR_ERR(priv-ci_pdev);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev,
+ failed to register ci_hdrc platform device:
%d\n,
+ ret);
+ goto clk_err;
+ }
+
+ platform_set_drvdata(pdev, priv);
+
+ pm_runtime_no_callbacks(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+
+clk_err:
+ if (!IS_ERR(priv-clk))
+ clk_disable_unprepare(priv-clk);
+ return ret;
+}
+
+static int ci_hdrc_usb2_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_usb2_priv *priv = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(priv-ci_pdev);
+ clk_disable_unprepare(priv-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_usb2_of_match[] = {
+ { .compatible = chipidea,usb2 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
+
+static struct platform_driver ci_hdrc_usb2_driver = {
+ .probe = ci_hdrc_usb2_probe,
+ .remove = ci_hdrc_usb2_remove,
+ .driver = {
+ .name = chipidea-usb2,
+ .owner = THIS_MODULE,
+ .of_match_table =
[PATCH v4 09/12] ARM: dts: berlin: add BG2Q nodes for USB support
Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
SoC has 3 USB host controller, compatible with ChipIdea.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
arch/arm/boot/dts/berlin2q.dtsi | 52 +
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index ffba5c3bdab8..faf7cbe2af20 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -114,6 +114,39 @@
#interrupt-cells = 3;
};
+ usb_phy2: phy@a2f400 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xa2f400 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 14;
+ status = disabled;
+ };
+
+ usb2: usb@a3 {
+ compatible = chipidea,usb2;
+ reg = 0xa3 0x1;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB2;
+ phys = usb_phy2;
+ status = disabled;
+ };
+
+ usb_phy0: phy@b74000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 12;
+ status = disabled;
+ };
+
+ usb_phy1: phy@b78000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 13;
+ status = disabled;
+ };
+
cpu-ctrl@dd {
compatible = marvell,berlin-cpu-ctrl;
reg = 0xdd 0x1;
@@ -348,6 +381,24 @@
};
};
+ usb0: usb@ed {
+ compatible = chipidea,usb2;
+ reg = 0xed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = chipidea,usb2;
+ reg = 0xee 0x1;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ phys = usb_phy1;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 1;
@@ -440,5 +491,6 @@
interrupts = GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
};
};
+
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/12] Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs
Add the reset binding documentation to the SoC binding documentation as
the reset driver in Marvell Berlin SoC is part of the chip/system
control registers. This patch adds the required properties to configure
the reset controller.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
Documentation/devicetree/bindings/arm/marvell,berlin.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 904de5781f44..a99eb9eb14c0 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -106,11 +106,21 @@ Required subnode-properties:
- groups: a list of strings describing the group names.
- function: a string describing the function used to mux the groups.
+* Reset controller binding
+
+A reset controller is part of the chip control registers set. The chip control
+node also provides the reset. The register set is not at the same offset
between
+Berlin SoCs.
+
+Required property:
+- #reset-cells: must be set to 2
+
Example:
chip: chip-control@ea {
compatible = marvell,berlin2-chip-ctrl;
#clock-cells = 1;
+ #reset-cells = 2;
reg = 0xea 0x400;
clocks = refclk, externaldev 0;
clock-names = refclk, video_ext0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/12] Documentation: bindings: add doc for the USB2 ChipIdea USB driver
Document the USB2 ChipIdea driver (ci13xxx) bindings.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
new file mode 100644
index ..8dd6d8285dab
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -0,0 +1,22 @@
+* USB2 ChipIdea USB controller for ci13xxx
+
+Required properties:
+- compatible: should be chipidea,usb2
+- reg: base address and length of the registers
+- interrupts: interrupt for the USB controller
+
+Optional properties:
+- clocks: reference to the USB clock
+- phys: reference to the USB PHY
+- vbus-supply: reference to the VBUS regulator
+
+Example:
+
+ usb@f7ed {
+ compatible = chipidea,usb2;
+ reg = 0xf7ed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ vbus-supply = reg_usb0_vbus;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/12] reset: add the Berlin reset controller driver
Add a reset controller for Marvell Berlin SoCs which is used by the
USB PHYs drivers (for now).
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-berlin.c | 131 +++
2 files changed, 132 insertions(+)
create mode 100644 drivers/reset/reset-berlin.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 60fed3d7820b..157d421f755b 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/reset-berlin.c b/drivers/reset/reset-berlin.c
new file mode 100644
index ..f8b48a13cf0b
--- /dev/null
+++ b/drivers/reset/reset-berlin.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Tenart antoine.ten...@free-electrons.com
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/reset-controller.h
+#include linux/slab.h
+#include linux/types.h
+
+#define BERLIN_MAX_RESETS 32
+
+#define to_berlin_reset_priv(p)\
+ container_of((p), struct berlin_reset_priv, rcdev)
+
+struct berlin_reset_priv {
+ void __iomem*base;
+ unsigned intsize;
+ struct reset_controller_dev rcdev;
+};
+
+static int berlin_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct berlin_reset_priv *priv = to_berlin_reset_priv(rcdev);
+ int offset = id 8;
+ int mask = BIT(id 0x1f);
+
+ writel(mask, priv-base + offset);
+
+ /* let the reset be effective */
+ udelay(10);
+
+ return 0;
+}
+
+static struct reset_control_ops berlin_reset_ops = {
+ .reset = berlin_reset_reset,
+};
+
+static int berlin_reset_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ struct berlin_reset_priv *priv = to_berlin_reset_priv(rcdev);
+ unsigned offset, bit;
+
+ if (WARN_ON(reset_spec-args_count != rcdev-of_reset_n_cells))
+ return -EINVAL;
+
+ offset = reset_spec-args[0];
+ bit = reset_spec-args[1];
+
+ if (offset = priv-size)
+ return -EINVAL;
+
+ if (bit = BERLIN_MAX_RESETS)
+ return -EINVAL;
+
+ return (offset 8) | bit;
+}
+
+static int __berlin_reset_init(struct device_node *np)
+{
+ struct berlin_reset_priv *priv;
+ struct resource res;
+ resource_size_t size;
+ int ret;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ goto err;
+
+ size = resource_size(res);
+ priv-base = ioremap(res.start, size);
+ if (!priv-base) {
+ ret = -ENOMEM;
+ goto err;
+ }
+ priv-size = size;
+
+ priv-rcdev.owner = THIS_MODULE;
+ priv-rcdev.ops = berlin_reset_ops;
+ priv-rcdev.of_node = np;
+ priv-rcdev.of_reset_n_cells = 2;
+ priv-rcdev.of_xlate = berlin_reset_xlate;
+
+ reset_controller_register(priv-rcdev);
+
+ return 0;
+
+err:
+ kfree(priv);
+ return ret;
+}
+
+static const struct of_device_id berlin_reset_of_match[] __initconst = {
+ { .compatible = marvell,berlin2-chip-ctrl },
+ { .compatible = marvell,berlin2cd-chip-ctrl },
+ { .compatible = marvell,berlin2q-chip-ctrl },
+ { },
+};
+
+static int __init berlin_reset_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ for_each_matching_node(np, berlin_reset_of_match) {
+ ret = __berlin_reset_init(np);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+arch_initcall(berlin_reset_init);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/12] ARM: berlin: USB support
This series adds the support for ChipIdea USB2 (ci13xxx) controllers, the USB PHYs of the Marvell Berlin SoCs and also adds a reset controller for these SoCs. The reset controller is used by the PHY driver and shares the existing chip controller node with the clocks and one pin controller. The Marvell Berlin USB controllers are host only on the BG2Q and are compatible with USB ChipIdea. We here add a glue to use the available common functions for this kind of controllers, and add a generic USB2 ChipIdea driver. A PHY driver is also added to control the USB PHY. This series applies on top of the generic PHY support in the USB framework[1]. Changes since v3: - removed the DMA mask property - moved the clock handling in the common probe function - fixed the documentation for the USB2 ChipIdea USB PHY binding - made sure the reset bit is 0-31 in the reset driver Changes since v2: - moved the PHY driver to the generic PHY framework - changed the compatible to 'chipidea,usb2' - added a property to set the DMA mask in the USB2 CI driver - separated dt specific calls in the CI probing function - rebased on top of the generic PHY support for CI[1] Changes since v1: - made the Berlin CI USB driver a generic one - added support to custom offset for the reset register - added fixed regulators to support supply the VBUS - modified the PHY driver to support the one one the BG2CD as well - documented the reset properties - added bindings for the BG2CD - cosmetic fixes [1] git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy https://lkml.org/lkml/2014/9/3/78 Antoine Tenart (10): reset: add the Berlin reset controller driver Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs ARM: Berlin: select the reset controller ARM: dts: berlin: add a required reset property in the chip controller node phy: add the Berlin USB PHY driver Documentation: bindings: add doc for the Berlin USB PHY usb: chipidea: add a usb2 driver for ci13xxx Documentation: bindings: add doc for the USB2 ChipIdea USB driver ARM: dts: berlin: add BG2Q nodes for USB support ARM: dts: Berlin: enable USB on the BG2Q DMP Sebastian Hesselbarth (2): ARM: dts: berlin: add BG2CD nodes for USB support ARM: dts: berlin: enable USB on the Google Chromecast .../devicetree/bindings/arm/marvell,berlin.txt | 10 + .../devicetree/bindings/phy/berlin-usb-phy.txt | 16 ++ .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 22 ++ arch/arm/boot/dts/berlin2.dtsi | 1 + arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4 + arch/arm/boot/dts/berlin2cd.dtsi | 35 arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 + arch/arm/boot/dts/berlin2q.dtsi| 53 + arch/arm/mach-berlin/Kconfig | 2 + drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-berlin-usb.c | 224 + drivers/reset/Makefile | 1 + drivers/reset/reset-berlin.c | 131 drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c| 137 + 16 files changed, 698 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/berlin-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt create mode 100644 drivers/phy/phy-berlin-usb.c create mode 100644 drivers/reset/reset-berlin.c create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/12] ARM: Berlin: select the reset controller
The Marvell Berlin SoCs now has a reset controller. Add the needed configuration. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- arch/arm/mach-berlin/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig index 24f85be71671..5803f773a065 100644 --- a/arch/arm/mach-berlin/Kconfig +++ b/arch/arm/mach-berlin/Kconfig @@ -1,11 +1,13 @@ menuconfig ARCH_BERLIN bool Marvell Berlin SoCs if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB select ARM_GIC select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF select PINCTRL + select RESET_CONTROLLER if ARCH_BERLIN -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/12] phy: add the Berlin USB PHY driver
Add the driver driving the Marvell Berlin USB PHY. This allows to initialize the PHY and to use it from the USB driver later. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/phy/Kconfig | 7 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-berlin-usb.c | 224 +++ 3 files changed, 232 insertions(+) create mode 100644 drivers/phy/phy-berlin-usb.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 0dd742719154..d1d73dd8c1fb 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -15,6 +15,13 @@ config GENERIC_PHY phy users can obtain reference to the PHY. All the users of this framework should select this config. +config PHY_BERLIN_USB + tristate Marvell Berlin USB PHY Driver + depends on ARCH_BERLIN HAS_IOMEM OF + select GENERIC_PHY + help + Enable this to support the USB PHY on Marvell Berlin SoCs. + config PHY_BERLIN_SATA tristate Marvell Berlin SATA PHY driver depends on ARCH_BERLIN HAS_IOMEM OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 95c69ed5ed45..b12e84b69c23 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_GENERIC_PHY) += phy-core.o +obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c new file mode 100644 index ..f9f13067f50f --- /dev/null +++ b/drivers/phy/phy-berlin-usb.c @@ -0,0 +1,224 @@ +/* + * Copyright (C) 2014 Marvell Technology Group Ltd. + * + * Antoine Tenart antoine.ten...@free-electrons.com + * Jisheng Zhang jszh...@marvell.com + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed as is without any + * warranty of any kind, whether express or implied. + */ + +#include linux/gpio.h +#include linux/io.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_gpio.h +#include linux/phy/phy.h +#include linux/platform_device.h +#include linux/reset.h + +#define USB_PHY_PLL0x04 +#define USB_PHY_PLL_CONTROL0x08 +#define USB_PHY_TX_CTRL0 0x10 +#define USB_PHY_TX_CTRL1 0x14 +#define USB_PHY_TX_CTRL2 0x18 +#define USB_PHY_RX_CTRL0x20 +#define USB_PHY_ANALOG 0x34 + +/* USB_PHY_PLL */ +#define CLK_REF_DIV(x) ((x) 4) +#define FEEDBACK_CLK_DIV(x)((x) 8) + +/* USB_PHY_PLL_CONTROL */ +#define CLK_STABLE BIT(0) +#define PLL_CTRL_PIN BIT(1) +#define PLL_CTRL_REG BIT(2) +#define PLL_ON BIT(3) +#define PHASE_OFF_TOL_125 (0x0 5) +#define PHASE_OFF_TOL_250 BIT(5) +#define KVC0_CALIB (0x0 9) +#define KVC0_REG_CTRL BIT(9) +#define KVC0_HIGH (0x0 10) +#define KVC0_LOW (0x3 10) +#define CLK_BLK_EN BIT(13) + +/* USB_PHY_TX_CTRL0 */ +#define EXT_HS_RCAL_EN BIT(3) +#define EXT_FS_RCAL_EN BIT(4) +#define IMPCAL_VTH_DIV(x) ((x) 5) +#define EXT_RS_RCAL_DIV(x) ((x) 8) +#define EXT_FS_RCAL_DIV(x) ((x) 12) + +/* USB_PHY_TX_CTRL1 */ +#define TX_VDD15_14(0x0 4) +#define TX_VDD15_15BIT(4) +#define TX_VDD15_16(0x2 4) +#define TX_VDD15_17(0x3 4) +#define TX_VDD12_VDD (0x0 6) +#define TX_VDD12_11BIT(6) +#define TX_VDD12_12(0x2 6) +#define TX_VDD12_13(0x3 6) +#define LOW_VDD_EN BIT(8) +#define TX_OUT_AMP(x) ((x) 9) + +/* USB_PHY_TX_CTRL2 */ +#define TX_CHAN_CTRL_REG(x)((x) 0) +#define DRV_SLEWRATE(x)((x) 4) +#define IMP_CAL_FS_HS_DLY_0(0x0 6) +#define IMP_CAL_FS_HS_DLY_1BIT(6) +#define IMP_CAL_FS_HS_DLY_2(0x2 6) +#define IMP_CAL_FS_HS_DLY_3(0x3 6) +#define FS_DRV_EN_MASK(x) ((x) 8) +#define HS_DRV_EN_MASK(x) ((x) 12) + +/* USB_PHY_RX_CTRL */ +#define PHASE_FREEZE_DLY_2_CL (0x0 0) +#define PHASE_FREEZE_DLY_4_CL BIT(0) +#define ACK_LENGTH_8_CL(0x0 2) +#define ACK_LENGTH_12_CL BIT(2) +#define ACK_LENGTH_16_CL (0x2 2) +#define ACK_LENGTH_20_CL (0x3 2) +#define SQ_LENGTH_3(0x0 4) +#define SQ_LENGTH_6BIT(4) +#define SQ_LENGTH_9(0x2 4) +#define SQ_LENGTH_12 (0x3 4) +#define DISCON_THRESHOLD_260 (0x0 6) +#define DISCON_THRESHOLD_270 BIT(6) +#define DISCON_THRESHOLD_280 (0x2 6) +#define DISCON_THRESHOLD_290 (0x3 6) +#define SQ_THRESHOLD(x)((x) 8) +#define LPF_COEF(x)((x) 12) +#define INTPL_CUR_10 (0x0 14) +#define INTPL_CUR_20 BIT(14) +#define INTPL_CUR_30 (0x2
[PATCH v4 06/12] Documentation: bindings: add doc for the Berlin USB PHY
Document the bindings of the Marvell Berlin USB PHY driver.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
Documentation/devicetree/bindings/phy/berlin-usb-phy.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
b/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
new file mode 100644
index ..be33780f668e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
@@ -0,0 +1,16 @@
+* Marvell Berlin USB PHY
+
+Required properties:
+- compatible: marvell,berlin2-usb-phy or marvell,berlin2cd-usb-phy
+- reg: base address and length of the registers
+- #phys-cells: should be 0
+- resets: reference to the reset controller
+
+Example:
+
+ usb-phy@f774000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xf774000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 14;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gadget serial driver - configuration value
Hi, This is regarding an issue we are facing with the gadget serial driver (driver/usb/gadget/serial.c). We have a hardware limitation and the USB hardware can only have bconfigurationvalue 0 or 1. In the CDC ACM config in gadget serial driver the configuration value is set to 2. Is there a specific reason why this was done? We see that, the three configurations listed in serial driver (CDC ACM, CDC OBEX, generic serial) cannot be present together as per the current implementation. Is there a specific reason why the configuration values were set as 1, 2 and 3 instead of setting all to 1? -- Anjana -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbhid: improve handling of Clear-Halt and reset
On Tue, 2014-09-02 at 11:39 -0400, Alan Stern wrote: This patch changes the way usbhid carries out Clear-Halt and reset. Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver immediately restarts the interrupt URB, even if the Clear-Halt failed. This doesn't work out well when the reason for the failure was that the device was disconnected (when a low- or full-speed device is connected through a hub to an EHCI controller, transfer errors caused by disconnection are reported as stalls by the hub). Instead now the driver will attempt a reset after a failed Clear-Halt. The way resets are carried out is also changed. Now the driver will call usb_queue_reset_device() instead of calling usb_reset_device() directly. This avoids a deadlock that would arise when a device is unplugged: The hid_reset() routine runs as a workqueue item, a reset attempt after the device has been unplugged will fail, failure will cause usbhid to be unbound, and the disconnect routine will try to do cancel_work_sync(). The usb_queue_reset_device() implementation is carefully written to handle scenarios like this one properly. Please disregard my first analysis, I missed a check of the open counter. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
EHCI Isochronous schedule full?
I've probably got this wrong... I try to run several cameras with compressed streams (MJPEG) using maxpacket 3*1024 isoc-endpoints. EHCI should be able to transmit 8 microframes * 1024 bytes * 3 packets of data per frame (approx 24MB/sec). Two cameras work fine, but when I connect a third camera I get -ENOSPC from the scheduler. I don't get how the schedule can be full. One camera should be able to fit within one microframe. (3 * 1024b). That leaves atleast 7 microframes available if 100% of bandwith is used for isochronous transfers (not likely, but anyway). Debugfs lists the periodic schedule as (two cameras connected): /sys/kernel/debug/usb/ehci/fsl-ehci.0 cat periodic size = 512 1: qh256-0001/c3b0bd40 (h2 ep1in [1/0] q1 p1) 6: qh16-0001/c301d080 (h7 ep3in [1/0] q1 p8) 7: qh256-0001/c3b72180 (h8 ep1in [1/0] q1 p1) 9: qh16-0001/c30dd100 (h10 ep7in [1/0] q1 p16) 22: qh16-0001/c301d080 25: qh16-0001/c30dd100 38: qh16-0001/c301d080 41: qh16-0001/c30dd100 54: qh16-0001/c301d080 57: qh16-0001/c30dd100 70: qh16-0001/c301d080 73: qh16-0001/c30dd100 86: qh16-0001/c301d080 89: qh16-0001/c30dd100 102: qh16-0001/c301d080 105: qh16-0001/c30dd100 118: qh16-0001/c301d080 121: qh16-0001/c30dd100 134: qh16-0001/c301d080 137: qh16-0001/c30dd100 150: qh16-0001/c301d080 153: qh16-0001/c30dd100 166: qh16-0001/c301d080 169: qh16-0001/c30dd100 182: qh16-0001/c301d080 185: qh16-0001/c30dd100 198: qh16-0001/c301d080 201: qh16-0001/c30dd100 214: qh16-0001/c301d080 217: qh16-0001/c30dd100 230: qh16-0001/c301d080 233: qh16-0001/c30dd100 246: qh16-0001/c301d080 249: qh16-0001/c30dd100 257: qh256-0001/c3b0bd40 262: qh16-0001/c301d080 263: qh256-0001/c3b72180 265: qh16-0001/c30dd100 278: qh16-0001/c301d080 281: qh16-0001/c30dd100 294: qh16-0001/c301d080 297: qh16-0001/c30dd100 310: qh16-0001/c301d080 313: qh16-0001/c30dd100 326: qh16-0001/c301d080 329: qh16-0001/c30dd100 342: qh16-0001/c301d080 345: qh16-0001/c30dd100 358: qh16-0001/c301d080 361: qh16-0001/c30dd100 374: qh16-0001/c301d080 377: qh16-0001/c30dd100 390: qh16-0001/c301d080 393: qh16-0001/c30dd100 406: qh16-0001/c301d080 409: qh16-0001/c30dd100 422: qh16-0001/c301d080 425: qh16-0001/c30dd100 438: qh16-0001/c301d080 441: qh16-0001/c30dd100 453: itd/c32901e0 itd/c3290500 454: itd/c33c1d20 itd/c20ec000 qh16-0001/c301d080 455: itd/c20eca00 itd/c20d5320 456: itd/c32d08c0 itd/c32d05a0 457: itd/c20e83c0 itd/c20e86e0 qh16-0001/c30dd100 458: itd/c20e8460 itd/c20e8780 459: itd/c20ecaa0 itd/c20ec6e0 460: itd/c33c16e0 itd/c20ece60 461: itd/c33c1aa0 itd/c20ec140 462: itd/c21eaaa0 itd/c21eadc0 463: itd/c32900a0 itd/c32903c0 464: itd/c33c1960 itd/c20ecf00 465: itd/c3155dc0 itd/c3155aa0 466: itd/c20ec320 itd/c33cc0a0 467: itd/c3155c80 itd/c3155960 468: itd/c3155e60 itd/c3155b40 469: itd/c21ea1e0 itd/c21ea500 470: itd/c20ec780 itd/c33c1780 qh16-0001/c301d080 471: itd/c21eabe0 itd/c21ea8c0 472: itd/c21ea140 itd/c21ea460 473: qh16-0001/c30dd100 486: qh16-0001/c301d080 489: qh16-0001/c30dd100 502: qh16-0001/c301d080 505: qh16-0001/c30dd100 which is ~90 entries out of the 512 uframe schedule size. So why do I get -ENOSPC? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: EHCI Isochronous schedule full?
It does not matter if I reduce resolution to 640x480x1 fps. I still can only use two cameras. maxpacket requirement for those streams drop a bit, but it doesn't help. Kernel is 3.6.4, powerpc 8347 machine.-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: gadget: How should an udc handle reception of more data than req.length?
Hi! In short: How should a udc driver handle a situation when the host sends more data than req.length in the receiving OUT request? What should be reported to the gadget driver? What should be done with the excess data? Currently the gr_udc driver does not accept OUT requests if req.length is not a multiple of ep.maxpacket. This is because the hardware cannot be told to write smaller data sizes than ep.maxpacket. (This works fine for mass storage for instance that makes sure to supply request buffers that are even multiples of ep.maxpacket, but not all gadget drivers do this.) I am looking into lifting this limitation by using an internal buffer in gr_udc.c in that is used instead of end of the req.buf that is not (necessarily) a full multiple of ep.maxpacket and then copy received data from the internal buffer to the request buffer. The problem is that the gr_udc driver then can end up in the situation where it receives more data than req.length (e.g. a full sized packet of size ep.maxpacket). What should be done in the udc driver in this case? What should be reported to the gadget driver? What should be done with the excess data? Best regards, Andreas Larsson Software Engineer Aeroflex Gaisler AB Aeroflex Microelectronic Solutions – HiRel Kungsgatan 12 SE-411 19 Gothenburg, Sweden Phone: +46 31 7758669 andr...@gaisler.com www.Aeroflex.com/Gaisler -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Tue, Sep 2, 2014 at 6:23 PM, Johan Hovold jo...@kernel.org wrote: On Tue, Sep 02, 2014 at 11:45:55AM +0300, Octavian Purdila wrote: On Tue, Sep 2, 2014 at 11:00 AM, Lee Jones lee.jo...@linaro.org wrote: On Mon, 01 Sep 2014, Johan Hovold wrote: I haven't looked at the details of the protocol for the device in question, but it might even be possible to use regmap here (as I mentioned in my comments on v1). Obviously that would be preferred. Octavian, did you look into that? Yes, I did. Since this is the first time I am looking at regmap I may be wrong but I don't see a way to use it. The dln2 i2c driver needs to be able to send and receive arbitrary size buffers and this does not seem possible to do with the regmap API. That should be possible using the regmap bus read and write operations. I took a closer look on the regmap bus read/write operations and I think they are not fit for what we need in the driver. The driver uses a request/response model which, IMHO, does not fit well with a register read/write API. Yes, maybe we can emulate it, but why do that? (Also creating a regmap class for a particular device seems over engineering since nobody else is going to use it) Possibly, but it would allow subdrivers to be implemented using a standard interface and also provide register caching for free. Using a standard interface is nice, but I think that using the right interface type is more important. This hardware does not use registers but a messages to communicate with the OS. Also caching is not useful for i2c and only partially useful for GPIO (to cache the pin direction, and pin status in output mode only) so its not a big win. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB fixes for v3.17-rc3
Hi Greg,
Here's a new set of fixes. Pretty minor stuff. I tested with platforms
which I have access to.
Cheers
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:
Linux 3.17-rc3 (2014-08-31 18:23:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
tags/fixes-for-v3.17-rc3
for you to fetch changes up to 9ce9ec95fb9b82e09b55a52f1bb8a362bf8f74d8:
usb: phy: tegra: Avoid use of sizeof(void) (2014-09-03 09:16:01 -0500)
usb: fixes for v3.17-rc3
A new set of fixes which have been pending for a while. All patches
have been randconfig build-tested and boot tested where applicable.
The most important fixes are MUSB on AM335x learned how to transfer
ZLPs, and net2280 got a fix for reset IRQ handling.
Signed-of-by: Felipe Balbi ba...@ti.com
Bin Liu (1):
usb: musb: cppi41: fix not transmitting zero length packet issue
Peter Chen (2):
usb: phy: mxs: add imx6sx support
doc: dt: mxs-phy: add compatible string for imx6sx-usbphy
Rasmus Villemoes (1):
usb: gadget: fusb300_udc.h: Fix typo in include guard
Ricardo Ribalda Delgado (1):
usb: gadget: net2280: Fix invalid handling of Reset irq
Robert Baldyga (1):
usb: gadget: f_fs: fix the redundant ep files problem
Thierry Reding (1):
usb: phy: tegra: Avoid use of sizeof(void)
Yoshihiro Shimoda (4):
usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle
usb: renesas_usbhs: protect mod-irq_{bemp,brdy}sts by spin lock
usb: renesas_usbhs: fix the condition of is_done in usbhsf_dma_push_done
usb: renesas_usbhs: fix the usb_pkt_pop()
Documentation/devicetree/bindings/usb/mxs-phy.txt | 1 +
drivers/usb/gadget/function/f_fs.c| 66 +
drivers/usb/gadget/function/u_fs.h| 2 +
drivers/usb/gadget/udc/fusb300_udc.h | 2 +-
drivers/usb/gadget/udc/net2280.c | 2 +-
drivers/usb/musb/musb_cppi41.c| 17 +-
drivers/usb/phy/phy-mxs-usb.c | 8 ++-
drivers/usb/phy/phy-tegra-usb.c | 4 +-
drivers/usb/renesas_usbhs/fifo.c | 72 +--
drivers/usb/renesas_usbhs/mod.c | 5 ++
drivers/usb/renesas_usbhs/pipe.c | 13
drivers/usb/renesas_usbhs/pipe.h | 4 ++
12 files changed, 172 insertions(+), 24 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Wed, Sep 03, 2014 at 09:32:14AM +0530, Vivek Gautam wrote: On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi dfo...@gmail.com wrote: 2014-08-28 10:02 GMT+02:00 Vivek Gautam: This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) OF shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like that idea. The thing is that this will likely need to be patches for exynos8, 9, 10, 11... Yes, after we have the 2nd version of Exynos7 support patches, it makes more sense to keep dependency on ARCH_EXYNOS. thank you, that'll help new silicon wakeup; one less thing to patch :-p -- balbi signature.asc Description: Digital signature
Re: gadget serial driver - configuration value
On Wed, Sep 03, 2014 at 02:48:43PM +0530, Anjana V Kumar wrote: Hi, This is regarding an issue we are facing with the gadget serial driver (driver/usb/gadget/serial.c). We have a hardware limitation and the USB hardware can only have bconfigurationvalue 0 or 1. what kind of limitation is this. Configuration value is a SW-only choice. What HW are you using ? Which kernel are you using ? Do you have logs of the problem ? In the CDC ACM config in gadget serial driver the configuration value is set to 2. Is there a specific reason why this was done? We see that, the three configurations listed in serial driver (CDC ACM, CDC OBEX, generic serial) cannot be present together as per the current implementation. Is there a specific reason why the configuration values were set as 1, 2 and 3 instead of setting all to 1? well, setting configuration 0 means that you're not selecting any configuration. Basically you go back to Addressed state, so you can't use configuration 0 for anything, really. -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: cppi41: tweak hrtimer values
Intensive tests with USB audio devices connected to a musb host port
have shown reproducible pops and clicks in both the playback and the
capture stream.
These are related to how the early_tx hrtimer is set up, and it turns
out they can be fixed by reducing the timer's slack value from 40 to
25 us. Also, when the callback is ran without taking action, it should
be rescheduled 20 us later instead of 50 us.
Reported-and-tested-by: Sven Neumann neum...@teufel.de
Signed-off-by: Daniel Mack dan...@zonque.org
---
drivers/usb/musb/musb_cppi41.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 47ae645..ecdd632 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -200,7 +200,7 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct
hrtimer *timer)
if (!list_empty(controller-early_tx_list)) {
ret = HRTIMER_RESTART;
hrtimer_forward_now(controller-early_tx,
- ktime_set(0, 50 * NSEC_PER_USEC));
+ ktime_set(0, 20 * NSEC_PER_USEC));
}
spin_unlock_irqrestore(musb-lock, flags);
@@ -278,7 +278,7 @@ static void cppi41_dma_callback(void *private_data)
hrtimer_start_range_ns(controller-early_tx,
ktime_set(0, usecs * NSEC_PER_USEC),
- 40 * NSEC_PER_USEC,
+ 20 * NSEC_PER_USEC,
HRTIMER_MODE_REL);
}
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/usb/host/ehci-xilinx-of.c: Include linux/of_irq.h to avoid compiling error
Need include it for irq_of_parse_and_map(), the related error with allmodconfig under microblaze: drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’: drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration of function ‘irq_of_parse_and_map’ [-Werror=implicit-function-declaration] irq = irq_of_parse_and_map(dn, 0); ^ Signed-off-by: Chen Gang gang.chen.5...@gmail.com --- drivers/usb/host/ehci-xilinx-of.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/ehci-xilinx-of.c b/drivers/usb/host/ehci-xilinx-of.c index fe57710..a232836 100644 --- a/drivers/usb/host/ehci-xilinx-of.c +++ b/drivers/usb/host/ehci-xilinx-of.c @@ -31,6 +31,7 @@ #include linux/of.h #include linux/of_platform.h #include linux/of_address.h +#include linux/of_irq.h /** * ehci_xilinx_port_handed_over - hand the port out if failed to enable it -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: gadget: How should an udc handle reception of more data than req.length?
On Wed, 3 Sep 2014, Andreas Larsson wrote: Hi! In short: How should a udc driver handle a situation when the host sends more data than req.length in the receiving OUT request? What should be reported to the gadget driver? What should be done with the excess data? It depends. If req.length is a multiple of the endpoint's maxpacket size then any excess must take the form of extra packets. The UDC should NAK these packets or apply them toward the next request on the endpoint's queue, if there is one. If req.length is not a multiple of the maxpacket size then an excess could take the form of a packet that's too long. The UDC should store as much of the data as possible (i.e., to up req.length) in the request's buffer and drop the rest, and the request should complete with a status code of -EOVERFLOW. Currently the gr_udc driver does not accept OUT requests if req.length is not a multiple of ep.maxpacket. This is because the hardware cannot be told to write smaller data sizes than ep.maxpacket. (This works fine for mass storage for instance that makes sure to supply request buffers that are even multiples of ep.maxpacket, but not all gadget drivers do this.) I am looking into lifting this limitation by using an internal buffer in gr_udc.c in that is used instead of end of the req.buf that is not (necessarily) a full multiple of ep.maxpacket and then copy received data from the internal buffer to the request buffer. In other words, a bounce buffer. The problem is that the gr_udc driver then can end up in the situation where it receives more data than req.length (e.g. a full sized packet of size ep.maxpacket). What should be done in the udc driver in this case? What should be reported to the gadget driver? What should be done with the excess data? See above. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/9] of: Add NVIDIA Tegra XUSB mailbox binding
On 09/02/2014 03:34 PM, Andrew Bresticker wrote: Add device-tree bindings for the Tegra XUSB mailbox which will be used for communication between the Tegra xHCI controller's firmware and the host processor. The series, Reviewed-by: Stephen Warren swar...@nvidia.com I'd like Thierry to review at least the XUSB pinctrl and all DT binding changes too, if possible. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
On 09/02/2014 03:34 PM, Andrew Bresticker wrote:
Add support for the on-chip xHCI host controller present on Tegra SoCs.
The driver is currently very basic: it loads the controller with its
firmware, starts the controller, and is able to service messages sent
by the controller's firmware. The hardware also supports device mode
as well as powergating of the SuperSpeed and host-controller logic
when not in use, but support for these is not yet implemented.
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
+static bool is_host_mbox_message(u32 cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ return true;
+ case MBOX_CMD_SET_BW:
+ /*
+* TODO: Request bandwidth once EMC scaling is supported.
+* Ignore for now since ACK/NAK is not required for SET_BW
+* messages.
+*/
I think that TODO belongs inside tegra_xhci_mbox_work() where the
message would actually be handled, if implemented.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, 3 Sep 2014, Peter Chen wrote: PS: I also have an old patch that adds a reset callback to g-mass-storage. Peter asked for this around the same time the other work was done. The idea was that disconnect must flush the buffers to the backing storage device, whereas a reset could avoid flushing anything -- Peter found that the flushing was taking so long, the gadget might not be able to carry out a reset quickly enough if it used the disconnect callback. The version I have of this patch is incomplete; it requires a reset callback to be added to the composite driver. Peter, do you still want to make this change to g-mass-storage? Alan, this problem seems not to be existed at g_mass_storage, g_mass_storage has not .disconnect API and only fsg_disable will be called when bus reset occurs. That sounds like a bug. Shouldn't there be a disconnect callback? Don't we want to flush the dirty buffers when a disconnect occurs? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, 3 Sep 2014, Peter Chen wrote: Okay. Let's start by adding the reset field to struct usb_gadget_driver. The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. (At some later time we can add a -reset callback to struct usb_composite_driver; then the reset handler in composite.c can invoke that callback for all function drivers that define it.) Next, add routines to udc-core to handle Vbus changes, function activation changes, and resets. The Vbus routine will invoke the gadget driver's -disconnect callback when Vbus goes off and then call usb_gadget_disconnect. The activation routine will call usb_gadget_disconnect if any functions are deactivated, and usb_gadget_connect if all the functions are activated (basically, do whatever composite.c would do). And the reset routine will invoke the gadget driver's -reset callback. I suppose we'll also have to add fields to struct usb_gadget, to store the current Vbus and activation statuses. If the usb_gadget_disconnect will be not called at gadget driver's -disconnect, it has no much meaning we still have gadget driver's -reset, since the content of its -disconnect and -reset are the same if we don't consider to add function's reset handler. No, they aren't always the same. For example, g_mass_storage ought to flush its dirty buffers when a disconnect occurs, but it doesn't have to flush them when a reset occurs. Then modify all the UDC drivers; make them invoke the new udc-core routines whenever there's a change in Vbus status or a reset, instead of invoking the gadget driver's callbacks directly. At the same time we can remove the code that turns off the pullup when Vbus goes down, because now the udc-core routine will take care of it. Why we need to record the reset at udc-core? We don't really need to. But it seems like a good idea to have events that affect the entire device (including connect, disconnect, reset, and probably also bus suspend and bus resume) all pass through udc-core. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] usb: host: change TPL support behaviour
On Wed, 3 Sep 2014, Peter Chen wrote: On Fri, Aug 22, 2014 at 02:31:18PM +0530, Pratyush Anand wrote: On Tue, Aug 19, 2014 at 09:51:51AM +0800, Peter Chen wrote: Changes for v3: - Add possible role switch for unsupported HNP capable OTG B-peripheral, see USB OTG EH 2.0 spec page 38, this feature was deleted wrongly at previous revision patches. Changes for v2: - Move TPL support judgement out of is_target, the user can be easy to know if it needs to do TPL judgement. [patch 1/6] - Keep the unsupport device message unchange [patch 1/6] According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, a Targeted Host (non-PC host, OTG or Embedded host) is not required to support operation with all types of USB peripherals. It is up to the manufacturer of each Targeted Host to declare which peripherals the host will support and provide a list of those peripherals. This is called the Targeted Host's Targeted Peripheral List (TPL). The TPL shall accurately represent the device classes supported by the Targeted Host. And the TPL support is a must for USB OTG EH certification test, and TPL support needs to apply for both OTG and EH, it should be decided by platform setting. This patchset changes TPL support behaviour like below: - Apply possible TPL support for all kinds of host - Effect TPL in code is decided by both configuration (CONFIG_USB_OTG_WHITELIST) and platform flag, it can avoid the enumeration failure by choosing TPL configuration wrongly. Besides, TPL can be have a good supplement for authorized feature supplied by sys, Eg, TPL can be modified to match by class using interface descriptor, etc. It may help give some suggestions for recently badUSB report. http://venturebeat.com/2014/07/31/why-you-can-no-longer-trust-any-usb-device-plugged-into-your-pc/ https://srlabs.de/badusb/ Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB fixes for v3.17-rc3
On Wed, Sep 03, 2014 at 09:27:30AM -0500, Felipe Balbi wrote: Hi Greg, Here's a new set of fixes. Pretty minor stuff. I tested with platforms which I have access to. Cheers The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.17-rc3 Pulled and pushed out. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
From: Alan Stern st...@rowland.harvard.edu On Fri, 29 Aug 2014, Matthew Dharm wrote: Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. The value would most sanely be extracted from the partition table. (After verifying that the partition table looks correct.) That seems to be what Windows does, and it seems to work consistently enough for Windows to trust that method. Or at least, it could take the disk size to be the end of the last partition, which would at least make all the partitions accessible. As somebody else hinted at, the userspace program could check the USB device against a list of device types known to have this problem. It could even verify that the SCSI-reported size matches the size reported by the partition table (modulo two-to-the-whatever) (at least for GPT tables, I don't know if MBR tables report the disk size). Do we have any way of knowing what algorithm Windows uses in this situation? Dale -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Wed, 3 Sep 2014, Dale R. Worley wrote: From: Alan Stern st...@rowland.harvard.edu On Fri, 29 Aug 2014, Matthew Dharm wrote: Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. The value would most sanely be extracted from the partition table. (After verifying that the partition table looks correct.) That seems to be what Windows does, and it seems to work consistently enough for Windows to trust that method. Or at least, it could take the disk size to be the end of the last partition, which would at least make all the partitions accessible. If there is a partition table. It might be worthwhile to try an ATA pass-through command as well. As somebody else hinted at, the userspace program could check the USB device against a list of device types known to have this problem. It could even verify that the SCSI-reported size matches the size reported by the partition table (modulo two-to-the-whatever) (at least for GPT tables, I don't know if MBR tables report the disk size). They don't. Just the start and end of each partition. Do we have any way of knowing what algorithm Windows uses in this situation? Ask Microsoft. I suspect you're not likely to get an answer, though. Anyway, I can try writing a patch to add this capability. We'll see if it can solve your problem. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RES: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Sat, 30 Aug 2014, Matthew Dharm wrote I was thinking of something that could notice a USB device which is formatted NTFS and has a partition table and filesystem that indicates a much bigger capacity than what the drive reports. Under this circumstances, you could do something like pop-up a dialog box saying this drive is confused -- is it 2TB or 3TB? Well, maybe that would say Drive capacity is not consistent with partition table. This can happen with certain USB drives designed for use with Windows. Override drive capacity (emulating Windows)? You could imagine increasing complex heuristics to try to detect this scenario. Even without an automated helper program to do it, if there was a sysfs interface then when we got the periodic e-mails reporting this same type of problem, we could offer a quick-and-clean solution. Hi Matt, I did small hack to skip is_pte_valid() on efi.c and now I have sdc1 partition listed on /proc/partition, but I hit other issue: ntfs-3g mount userspace tool that comes with Fedora now fails with Failed to read last sector (7814037100): Invalid argument. I also tried to override disk capacity, but SD driver fails with Invalid command failure and Illegal Request (I'll investigate it later) Many places rely on disk capacity value, I think emulate Windows behavior for these HDD docks will not be an easy task []'s Alfredo -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
modprobe -r hangs XHCI and panics on dwc3-omap
Hi,
I've been tracking down two issues and one of them seems to be a problem
with either usbcore or xhci.
DWC3, when acting as host, instantiates an xhci platform-device and sets
itself as the parent of that. That's all fine and dandy until I try to
modprobe -r dwc3.ko which causes XHCI to hang:
| # lsmod
| Module Size Used by
| xhci_hcd 116180 0
| dwc3 46765 0
| udc_core 10472 1 dwc3
| dwc3_omap 5402 0
| matrix_keypad 7218 0
| lis3lv02d_i2c 3718 0
| lis3lv02d 16439 1 lis3lv02d_i2c
| input_polldev 5315 1 lis3lv02d
| # lsusb
| Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
| Bus 001 Device 005: ID 0b95:7720 ASIX Electronics Corp. AX88772
| Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
| Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd
FT232 USB-Serial (UART) IC
| Bus 001 Device 002: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
| Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
| # modprobe -r dwc3
| [ 53.016798] xhci-hcd xhci-hcd.0.auto: remove, state 4
| [ 53.023083] usb usb2: USB disconnect, device number 1
| [ 53.082845] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
| [ 53.090732] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
| [ 53.112511] xhci-hcd xhci-hcd.0.auto: remove, state 1
| [ 53.117883] usb usb1: USB disconnect, device number 1
| [ 53.123301] usb 1-1: USB disconnect, device number 2
| [ 53.128503] usb 1-1.6: USB disconnect, device number 3
| [ 90.539781] INFO: task modprobe:1792 blocked for more than 30 seconds.
| [ 90.546607] Not tainted 3.17.0-rc2-4-ge0b64425 #800
| [ 90.552672] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
| [ 90.560855] modprobeD c06bf5a0 0 1792 1662 0x
| [ 90.567541] [c06bf5a0] (__schedule) from [c06bfa94]
(schedule+0x40/0x8c)
| [ 90.574925] [c06bfa94] (schedule) from [c06c3e48]
(schedule_timeout+0x154/0x220)
| [ 90.583031] [c06c3e48] (schedule_timeout) from [c06c0554]
(wait_for_common+0xdc/0x178)
| [ 90.591672] [c06c0554] (wait_for_common) from [c06c0610]
(wait_for_completion+0x20/0x24)
| [ 90.600537] [c06c0610] (wait_for_completion) from [bf0569d4]
(xhci_configure_endpoint+0xc8/0x590 [xhci_hcd])
| [ 90.611226] [bf0569d4] (xhci_configure_endpoint [xhci_hcd]) from
[bf057664] (xhci_check_bandwidth+0x16c/0x294 [xhci_hcd])
| [ 90.623100] [bf057664] (xhci_check_bandwidth [xhci_hcd]) from
[c04e5578] (usb_hcd_alloc_bandwidth+0x1dc/0x320)
| [ 90.633938] [c04e5578] (usb_hcd_alloc_bandwidth) from [c04e8160]
(usb_disable_device+0x198/0x1f8)
| [ 90.643586] [c04e8160] (usb_disable_device) from [c04df3fc]
(usb_disconnect+0x7c/0x224)
| [ 90.652323] [c04df3fc] (usb_disconnect) from [c04df54c]
(usb_disconnect+0x1cc/0x224)
| [ 90.660778] 8 locks held by modprobe/1792:
| [ 90.665055] #0: (dev-mutex){..}, at: [c0439c04]
driver_detach+0x54/0xc8
| [ 90.672929] #1: (dev-mutex){..}, at: [c0439c10]
driver_detach+0x60/0xc8
| [ 90.680798] #2: (dev-mutex){..}, at: [c0439524]
device_release_driver+0x28/0x3c
| [ 90.689373] #3: (usb_bus_list_lock){+.+.+.}, at: [c04e4e04]
usb_remove_hcd+0xa0/0x1b4
| [ 90.697971] #4: (dev-mutex){..}, at: [c04df3d0]
usb_disconnect+0x50/0x224
| [ 90.706022] #5: (dev-mutex){..}, at: [c04df3d0]
usb_disconnect+0x50/0x224
| [ 90.714069] #6: (dev-mutex){..}, at: [c04df3d0]
usb_disconnect+0x50/0x224
| [ 90.722109] #7: (hcd-bandwidth_mutex){+.+.+.}, at: [c04e814c]
usb_disable_device+0x184/0x1f8
This only happens when I have devices attached to the XHCI port on my
platform (AM437x, but I suppose any XHCI would die similarly if you can
destroy the underlying {platform,pci}_device.
If I first remove xhci then remove dwc3, it works fine:
| # lsmod
| Module Size Used by
| xhci_hcd 116180 0
| dwc3 46765 0
| udc_core 10472 1 dwc3
| matrix_keypad 7218 0
| dwc3_omap 5402 0
| lis3lv02d_i2c 3718 0
| lis3lv02d 16439 1 lis3lv02d_i2c
| input_polldev 5315 1 lis3lv02d
| # lsusb
| Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
| Bus 001 Device 005: ID 0b95:7720 ASIX Electronics Corp. AX88772
| Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
| Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd
FT232 USB-Serial (UART) IC
| Bus 001 Device 002: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
| Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
| # modprobe -r xhci-hcd
| [ 38.895745] xhci-hcd xhci-hcd.0.auto: remove, state 4
| [ 38.902034] usb usb2: USB disconnect, device number 1
| [ 38.933439] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
| [
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
From: Alan Stern st...@rowland.harvard.edu Anyway, I can try writing a patch to add this capability. We'll see if it can solve your problem. Unfortunately, I think there is genuine value in such a hack. E.g., I've got two USB-to-SATA adapters. One works correctly. One does not. But at this point, I can't attach both of my high-capacity disks to the laptop at the same time, which makes it difficult to bulk-transfer files from one to the other. If, for the deficient adapter, the kernel assumed the disk size was the end of the last partition (or the backup GPT partition table, if that follows), then I could use it for everything other than repartitioning. And that would make life easier. Thanks for trying, Dale -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Allow xHCI drivers to be built as separate modules
Mathias, On Tue, Aug 19, 2014 at 10:01 AM, Andrew Bresticker abres...@chromium.org wrote: It was suggested in the review of the Tegra xHCI driver [1] that we allow xHCI drivers to be built as individual modules (like EHCI) instead of building them all into the single xhci-hcd module as they are today. Patches 1-3 prepare for making the xHCI PCI and platform drivers able to be built as individual modules and patch 4 actually creates the 3 separate modules (core, platform, PCI). Based on 3.17-rc1. Changes from v2: - fixed typo in xhci_register_plat - exported another symbol needed by xhci-pci module Changes from v1: - rebased on changes introduced by xhci-rcar driver [1] http://patchwork.ozlabs.org/patch/361265/ Andrew Bresticker (4): xhci: Introduce xhci_init_driver() xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold xhci: Export symbols used by host-controller drivers xhci: Allow xHCI drivers to be built as separate modules Any thoughts/comments on this series? Thanks, Andrew -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Wed, 2014-09-03 at 15:05 -0400, Alan Stern wrote: On Wed, 3 Sep 2014, Dale R. Worley wrote: From: Alan Stern st...@rowland.harvard.edu On Fri, 29 Aug 2014, Matthew Dharm wrote: Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. You mean, force a Media Change event and override the capacity reported by the hardware? I'm not aware of any API for doing that, although it probably wouldn't be too hard to add one. How would the user know what value to put in for the capacity? Unless the drive had been hooked up to a different computer and the user manually noted the correct capacity and typed it in, it would have to be guesswork. The value would most sanely be extracted from the partition table. (After verifying that the partition table looks correct.) That seems to be what Windows does, and it seems to work consistently enough for Windows to trust that method. Or at least, it could take the disk size to be the end of the last partition, which would at least make all the partitions accessible. If there is a partition table. It might be worthwhile to try an ATA pass-through command as well. As somebody else hinted at, the userspace program could check the USB device against a list of device types known to have this problem. It could even verify that the SCSI-reported size matches the size reported by the partition table (modulo two-to-the-whatever) (at least for GPT tables, I don't know if MBR tables report the disk size). They don't. Just the start and end of each partition. Do we have any way of knowing what algorithm Windows uses in this situation? Ask Microsoft. I suspect you're not likely to get an answer, though. Anyway, I can try writing a patch to add this capability. We'll see if it can solve your problem. Before we embark on elaborate hacks, why don't we just make the capacity writeable (by root) in sysfs from userspace (will require block change)? We can then encode all the nasty heuristics (including gpt reading) in userspace as a udev rule. James -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 3/7] usb: phy: mxs: Add VF610 USB PHY support
Hi, On Mon, Sep 01, 2014 at 06:36:50PM +0530, Stefan Agner wrote: I think I still miss a Signed-Off-By Felipe Balbi here... All the rest should make it into 3.18, but USB without PHY is no fun to use ;-) this is already in my testing/next https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/nextid=d0ee68b59e6aa33221445dc555efac3736b89026 -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Tue, Sep 02, 2014 at 06:08:47PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
you might want to use of_platform_depopulate() instead :-) Sorry I
didn't notice this earlier.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Wed, 3 Sep 2014, James Bottomley wrote: Before we embark on elaborate hacks, why don't we just make the capacity writeable (by root) in sysfs from userspace (will require block change)? We can then encode all the nasty heuristics (including gpt reading) in userspace as a udev rule. That's what I'm working on. Except that I don't know where to do it in the block layer, so for now I'm adding the attribute to sd.c. Where in the block layer would the right place be? We want this to apply only to entire devices, not to individual partitions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: modprobe -r hangs XHCI and panics on dwc3-omap
On Wed, 3 Sep 2014, Felipe Balbi wrote:
Hi,
I've been tracking down two issues and one of them seems to be a problem
with either usbcore or xhci.
DWC3, when acting as host, instantiates an xhci platform-device and sets
itself as the parent of that. That's all fine and dandy until I try to
modprobe -r dwc3.ko which causes XHCI to hang:
| # modprobe -r dwc3
| [ 53.016798] xhci-hcd xhci-hcd.0.auto: remove, state 4
| [ 53.023083] usb usb2: USB disconnect, device number 1
| [ 53.082845] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
| [ 53.090732] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
| [ 53.112511] xhci-hcd xhci-hcd.0.auto: remove, state 1
| [ 53.117883] usb usb1: USB disconnect, device number 1
| [ 53.123301] usb 1-1: USB disconnect, device number 2
| [ 53.128503] usb 1-1.6: USB disconnect, device number 3
| [ 90.539781] INFO: task modprobe:1792 blocked for more than 30 seconds.
| [ 90.546607] Not tainted 3.17.0-rc2-4-ge0b64425 #800
| [ 90.552672] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
| [ 90.560855] modprobeD c06bf5a0 0 1792 1662 0x
| [ 90.567541] [c06bf5a0] (__schedule) from [c06bfa94]
(schedule+0x40/0x8c)
| [ 90.574925] [c06bfa94] (schedule) from [c06c3e48]
(schedule_timeout+0x154/0x220)
| [ 90.583031] [c06c3e48] (schedule_timeout) from [c06c0554]
(wait_for_common+0xdc/0x178)
| [ 90.591672] [c06c0554] (wait_for_common) from [c06c0610]
(wait_for_completion+0x20/0x24)
| [ 90.600537] [c06c0610] (wait_for_completion) from [bf0569d4]
(xhci_configure_endpoint+0xc8/0x590 [xhci_hcd])
| [ 90.611226] [bf0569d4] (xhci_configure_endpoint [xhci_hcd]) from
[bf057664] (xhci_check_bandwidth+0x16c/0x294 [xhci_hcd])
It sounds like unloading dwc3 breaks the communication with the
controller before it has been unbound from xhci. This is probably
caused by dwc3's removal routine doing something in the wrong order.
This only happens when I have devices attached to the XHCI port on my
platform (AM437x, but I suppose any XHCI would die similarly if you can
destroy the underlying {platform,pci}_device.
It looks like dwc3/host.c:dwc3_host_exit() simply calls
platform_device_unregister(). That ought to work okay.
On the other hand, core.c:dwc3_remove() doesn't call
dwc3_core_exit_mode() until after doing a lot of other things.
Shouldn't it call dwc3_core_exit_mode() first?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: modprobe -r hangs XHCI and panics on dwc3-omap
Hi,
On Wed, Sep 03, 2014 at 04:41:34PM -0400, Alan Stern wrote:
On Wed, 3 Sep 2014, Felipe Balbi wrote:
Hi,
I've been tracking down two issues and one of them seems to be a problem
with either usbcore or xhci.
DWC3, when acting as host, instantiates an xhci platform-device and sets
itself as the parent of that. That's all fine and dandy until I try to
modprobe -r dwc3.ko which causes XHCI to hang:
| # modprobe -r dwc3
| [ 53.016798] xhci-hcd xhci-hcd.0.auto: remove, state 4
| [ 53.023083] usb usb2: USB disconnect, device number 1
| [ 53.082845] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
| [ 53.090732] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
| [ 53.112511] xhci-hcd xhci-hcd.0.auto: remove, state 1
| [ 53.117883] usb usb1: USB disconnect, device number 1
| [ 53.123301] usb 1-1: USB disconnect, device number 2
| [ 53.128503] usb 1-1.6: USB disconnect, device number 3
| [ 90.539781] INFO: task modprobe:1792 blocked for more than 30 seconds.
| [ 90.546607] Not tainted 3.17.0-rc2-4-ge0b64425 #800
| [ 90.552672] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
| [ 90.560855] modprobeD c06bf5a0 0 1792 1662 0x
| [ 90.567541] [c06bf5a0] (__schedule) from [c06bfa94]
(schedule+0x40/0x8c)
| [ 90.574925] [c06bfa94] (schedule) from [c06c3e48]
(schedule_timeout+0x154/0x220)
| [ 90.583031] [c06c3e48] (schedule_timeout) from [c06c0554]
(wait_for_common+0xdc/0x178)
| [ 90.591672] [c06c0554] (wait_for_common) from [c06c0610]
(wait_for_completion+0x20/0x24)
| [ 90.600537] [c06c0610] (wait_for_completion) from [bf0569d4]
(xhci_configure_endpoint+0xc8/0x590 [xhci_hcd])
| [ 90.611226] [bf0569d4] (xhci_configure_endpoint [xhci_hcd]) from
[bf057664] (xhci_check_bandwidth+0x16c/0x294 [xhci_hcd])
It sounds like unloading dwc3 breaks the communication with the
controller before it has been unbound from xhci. This is probably
caused by dwc3's removal routine doing something in the wrong order.
HAH! I guess you just found the issue for me :-) We're killing the PHYs
as the first step, before even trying to unregister XHCI's
platform_device.
This only happens when I have devices attached to the XHCI port on my
platform (AM437x, but I suppose any XHCI would die similarly if you can
destroy the underlying {platform,pci}_device.
It looks like dwc3/host.c:dwc3_host_exit() simply calls
platform_device_unregister(). That ought to work okay.
On the other hand, core.c:dwc3_remove() doesn't call
dwc3_core_exit_mode() until after doing a lot of other things.
Shouldn't it call dwc3_core_exit_mode() first?
yup. At least the PHYs still need to the be alive for as long as XHCI is
:-)
Let me try that out. There's nothing an extra set of eyes :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 01/12] reset: add the Berlin reset controller driver
On 09/03/2014 09:48 AM, Antoine Tenart wrote: Add a reset controller for Marvell Berlin SoCs which is used by the USB PHYs drivers (for now). Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Acked-by: Philipp Zabel p.za...@pengutronix.de --- drivers/reset/Makefile | 1 + drivers/reset/reset-berlin.c | 131 +++ 2 files changed, 132 insertions(+) create mode 100644 drivers/reset/reset-berlin.c I guess the reset stuff is quite independent from usb-phy and can be picked up now. Applied 01/12 and 03/12 to berlin/soc and 02/12 and 04/12 to berlin/dt. Thanks! For the usb-phy dts patches, I'll wait for the corresponding genphy patches. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: modprobe -r hangs XHCI and panics on dwc3-omap
HI,
On Wed, Sep 03, 2014 at 03:47:16PM -0500, Felipe Balbi wrote:
Hi,
On Wed, Sep 03, 2014 at 04:41:34PM -0400, Alan Stern wrote:
On Wed, 3 Sep 2014, Felipe Balbi wrote:
Hi,
I've been tracking down two issues and one of them seems to be a problem
with either usbcore or xhci.
DWC3, when acting as host, instantiates an xhci platform-device and sets
itself as the parent of that. That's all fine and dandy until I try to
modprobe -r dwc3.ko which causes XHCI to hang:
| # modprobe -r dwc3
| [ 53.016798] xhci-hcd xhci-hcd.0.auto: remove, state 4
| [ 53.023083] usb usb2: USB disconnect, device number 1
| [ 53.082845] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
| [ 53.090732] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
| [ 53.112511] xhci-hcd xhci-hcd.0.auto: remove, state 1
| [ 53.117883] usb usb1: USB disconnect, device number 1
| [ 53.123301] usb 1-1: USB disconnect, device number 2
| [ 53.128503] usb 1-1.6: USB disconnect, device number 3
| [ 90.539781] INFO: task modprobe:1792 blocked for more than 30
seconds.
| [ 90.546607] Not tainted 3.17.0-rc2-4-ge0b64425 #800
| [ 90.552672] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
| [ 90.560855] modprobeD c06bf5a0 0 1792 1662 0x
| [ 90.567541] [c06bf5a0] (__schedule) from [c06bfa94]
(schedule+0x40/0x8c)
| [ 90.574925] [c06bfa94] (schedule) from [c06c3e48]
(schedule_timeout+0x154/0x220)
| [ 90.583031] [c06c3e48] (schedule_timeout) from [c06c0554]
(wait_for_common+0xdc/0x178)
| [ 90.591672] [c06c0554] (wait_for_common) from [c06c0610]
(wait_for_completion+0x20/0x24)
| [ 90.600537] [c06c0610] (wait_for_completion) from [bf0569d4]
(xhci_configure_endpoint+0xc8/0x590 [xhci_hcd])
| [ 90.611226] [bf0569d4] (xhci_configure_endpoint [xhci_hcd]) from
[bf057664] (xhci_check_bandwidth+0x16c/0x294 [xhci_hcd])
It sounds like unloading dwc3 breaks the communication with the
controller before it has been unbound from xhci. This is probably
caused by dwc3's removal routine doing something in the wrong order.
HAH! I guess you just found the issue for me :-) We're killing the PHYs
as the first step, before even trying to unregister XHCI's
platform_device.
This only happens when I have devices attached to the XHCI port on my
platform (AM437x, but I suppose any XHCI would die similarly if you can
destroy the underlying {platform,pci}_device.
It looks like dwc3/host.c:dwc3_host_exit() simply calls
platform_device_unregister(). That ought to work okay.
On the other hand, core.c:dwc3_remove() doesn't call
dwc3_core_exit_mode() until after doing a lot of other things.
Shouldn't it call dwc3_core_exit_mode() first?
yup. At least the PHYs still need to the be alive for as long as XHCI is
:-)
Let me try that out. There's nothing an extra set of eyes :-)
yup, works like a charm. Thanks. Can I add your Suggested-by or
something else ?
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usbhid: improve handling of Clear-Halt and reset
On Tue, 2 Sep 2014, Alan Stern wrote: This patch changes the way usbhid carries out Clear-Halt and reset. Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver immediately restarts the interrupt URB, even if the Clear-Halt failed. This doesn't work out well when the reason for the failure was that the device was disconnected (when a low- or full-speed device is connected through a hub to an EHCI controller, transfer errors caused by disconnection are reported as stalls by the hub). Instead now the driver will attempt a reset after a failed Clear-Halt. The way resets are carried out is also changed. Now the driver will call usb_queue_reset_device() instead of calling usb_reset_device() directly. This avoids a deadlock that would arise when a device is unplugged: The hid_reset() routine runs as a workqueue item, a reset attempt after the device has been unplugged will fail, failure will cause usbhid to be unbound, and the disconnect routine will try to do cancel_work_sync(). The usb_queue_reset_device() implementation is carefully written to handle scenarios like this one properly. Signed-off-by: Alan Stern st...@rowland.harvard.edu And I actually like the way this makes hid_reset() nicer code as a bonus. Applied, thanks Alan. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: dwc3: core: fix order of PM runtime calls
Currently, we disable pm_runtime before all register accesses are done, this is dangerous and might lead to abort exceptions due to the driver trying to access a register which is clocked by a clock which was long gated. Fix that by moving pm_runtime_put_sync() and pm_runtime_disable() as the last thing we do before returning from our -remove() method. Fixes: 72246da (usb: Introduce DesignWare USB3 DRD Driver) Cc: sta...@vger.kernel.org # v3.2+ Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index b769c1f..a664d5b 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -804,15 +804,15 @@ static int dwc3_remove(struct platform_device *pdev) phy_power_off(dwc-usb2_generic_phy); phy_power_off(dwc-usb3_generic_phy); - pm_runtime_put_sync(pdev-dev); - pm_runtime_disable(pdev-dev); - dwc3_debugfs_exit(dwc); dwc3_core_exit_mode(dwc); dwc3_event_buffers_cleanup(dwc); dwc3_free_event_buffers(dwc); dwc3_core_exit(dwc); + pm_runtime_put_sync(pdev-dev); + pm_runtime_disable(pdev-dev); + return 0; } -- 2.0.1.563.g66f467c -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: dwc3: core: fix ordering for PHY suspend
We can't suspend the PHYs before dwc3_core_exit_mode()
has been called, that's because the host and/or device
sides might still need to communicate with the far end
link partner.
Fixes: 8ba007a (usb: dwc3: core: enable the USB2 and USB3 phy in probe)
Cc: sta...@vger.kernel.org # v3.9+
Suggested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a664d5b..9069984 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -799,15 +799,16 @@ static int dwc3_remove(struct platform_device *pdev)
{
struct dwc3 *dwc = platform_get_drvdata(pdev);
+ dwc3_debugfs_exit(dwc);
+ dwc3_core_exit_mode(dwc);
+ dwc3_event_buffers_cleanup(dwc);
+ dwc3_free_event_buffers(dwc);
+
usb_phy_set_suspend(dwc-usb2_phy, 1);
usb_phy_set_suspend(dwc-usb3_phy, 1);
phy_power_off(dwc-usb2_generic_phy);
phy_power_off(dwc-usb3_generic_phy);
- dwc3_debugfs_exit(dwc);
- dwc3_core_exit_mode(dwc);
- dwc3_event_buffers_cleanup(dwc);
- dwc3_free_event_buffers(dwc);
dwc3_core_exit(dwc);
pm_runtime_put_sync(pdev-dev);
--
2.0.1.563.g66f467c
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbhid: improve handling of Clear-Halt and reset
On Wed, 3 Sep 2014, Alan Stern wrote: What happens if we lose events? Especially with keyboards I see a problem with dropping a release event because this will trigger autorepeat. So should we generate a release event for all pressed keys on reset? That's a separate issue, not directly related to what the patch does. It probably needs to be addressed in the HID core. Hmm ... how about reinitializing all the reports after reset instead (except for devices which have HID_QUIRK_NO_INIT_REPORTS flag set)? That seems like a more generic solution to this (potential) problem. But I agree with Alan, let's handle this completely independently from this. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/9] usb: rename phy to usb_phy in HCD
Hello. On 09/03/2014 11:40 AM, Antoine Tenart wrote: The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com Acked-by: Alan Stern st...@rowland.harvard.edu I'm going to steal this patch and post it along with the HCD generic PHY support to avoid the need for the follow-up 'gen_phy'-'phy' rename. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: omap: fix ordering for runtime pm calls
we don't to gate clocks until our children are done with their remove path. Fixes: af310e9 (usb: dwc3: omap: use runtime API's to enable clocks) Cc: sta...@vger.kernel.org # v3.9+ Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/dwc3-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index 9dcfbe7..fc0de375 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -576,9 +576,9 @@ static int dwc3_omap_remove(struct platform_device *pdev) if (omap-extcon_id_dev.edev) extcon_unregister_interest(omap-extcon_id_dev); dwc3_omap_disable_irqs(omap); + device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core); pm_runtime_put_sync(pdev-dev); pm_runtime_disable(pdev-dev); - device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core); return 0; } -- 2.0.1.563.g66f467c -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: dwc3: core: fix ordering for PHY suspend
On Wed, Sep 03, 2014 at 04:41:03PM -0500, Felipe Balbi wrote: We can't suspend the PHYs before dwc3_core_exit_mode() has been called, that's because the host and/or device sides might still need to communicate with the far end link partner. Fixes: 8ba007a (usb: dwc3: core: enable the USB2 and USB3 phy in probe) Cc: sta...@vger.kernel.org # v3.9+ Suggested-by: Alan Stern st...@rowland.harvard.edu Alan, let me know if you prefer that I remove this line. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 4/9] usb: rename phy to usb_phy in HCD
Hello. On 09/03/2014 11:40 AM, Antoine Tenart wrote: The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/chipidea/host.c | 2 +- drivers/usb/core/hcd.c| 20 ++-- drivers/usb/core/hub.c| 8 drivers/usb/host/ehci-fsl.c | 16 drivers/usb/host/ehci-hub.c | 2 +- drivers/usb/host/ehci-msm.c | 4 ++-- drivers/usb/host/ehci-tegra.c | 16 drivers/usb/host/ohci-omap.c | 20 ++-- include/linux/usb/hcd.h | 2 +- 9 files changed, 45 insertions(+), 45 deletions(-) It looks like you left out drivers/usb/misc/lvstest.c... WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
On Wed, 3 Sep 2014, James Bottomley wrote:
Before we embark on elaborate hacks, why don't we just make the capacity
writeable (by root) in sysfs from userspace (will require block change)?
We can then encode all the nasty heuristics (including gpt reading) in
userspace as a udev rule.
That's what I'm working on. Except that I don't know where to do it in
the block layer, so for now I'm adding the attribute to sd.c.
Where in the block layer would the right place be? We want this to
apply only to entire devices, not to individual partitions.
The bottom layer for this is part0.nr_sects which is the size attribute
you see in the block sysfs. However, it looks like we keep a separate
value in sdkp, but we don't ever seem to use it (except to see if the
capacity has changed).
So this could be done in two ways: add a writeable capacity attribute in
sd.c, as you were originally thinking (it would call set_capacity() on
write and that would update the block layer) or make the size parameter
writeable.
This is how you would do the block layer one below, but there's no way
to inform the lower layer (so it better not have any information cached
that it makes use of).
James
---
diff --git a/block/genhd.c b/block/genhd.c
index 791f419..a114636 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -980,7 +980,7 @@ static DEVICE_ATTR(range, S_IRUGO, disk_range_show, NULL);
static DEVICE_ATTR(ext_range, S_IRUGO, disk_ext_range_show, NULL);
static DEVICE_ATTR(removable, S_IRUGO, disk_removable_show, NULL);
static DEVICE_ATTR(ro, S_IRUGO, disk_ro_show, NULL);
-static DEVICE_ATTR(size, S_IRUGO, part_size_show, NULL);
+static DEVICE_ATTR(size, S_IRUGO|S_IWUSR, part_size_show, part_size_store);
static DEVICE_ATTR(alignment_offset, S_IRUGO, disk_alignment_offset_show,
NULL);
static DEVICE_ATTR(discard_alignment, S_IRUGO, disk_discard_alignment_show,
NULL);
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 789cdea..d0cc418 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -87,6 +87,20 @@ ssize_t part_size_show(struct device *dev,
return sprintf(buf, %llu\n,(unsigned long long)part_nr_sects_read(p));
}
+ssize_t part_size_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hd_struct *p = dev_to_part(dev);
+ u64 size;
+
+ if (count 0 sscanf(buf, %llu, size) 0)
+ part_nr_sects_write(p, size);
+ else
+ return -EINVAL;
+
+ return count;
+}
+
static ssize_t part_ro_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index ec274e0..c9b3473 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -628,6 +628,9 @@ extern void blk_unregister_region(dev_t devt, unsigned long
range);
extern ssize_t part_size_show(struct device *dev,
struct device_attribute *attr, char *buf);
+extern ssize_t part_size_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
extern ssize_t part_stat_show(struct device *dev,
struct device_attribute *attr, char *buf);
extern ssize_t part_inflight_show(struct device *dev,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: usbip: fix usbip.h path in userspace tool
On Thu, Sep 04, 2014 at 01:31:17AM +0200, Piotr Król wrote: Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- tools/usb/usbip/libsrc/usbip_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..a80e73d4f11e 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include ../../../include/uapi/linux/usbip.h Shouldn't you be able to use the same path as ch9.h uses? It's a uapi .h file, no relative paths should be needed. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] usb: host: change TPL support behaviour
On Thu, Sep 04, 2014 at 07:49:23AM +0800, Peter Chen wrote: On Wed, Sep 03, 2014 at 02:02:04PM -0400, Alan Stern wrote: On Wed, 3 Sep 2014, Peter Chen wrote: On Fri, Aug 22, 2014 at 02:31:18PM +0530, Pratyush Anand wrote: On Tue, Aug 19, 2014 at 09:51:51AM +0800, Peter Chen wrote: Changes for v3: - Add possible role switch for unsupported HNP capable OTG B-peripheral, see USB OTG EH 2.0 spec page 38, this feature was deleted wrongly at previous revision patches. Changes for v2: - Move TPL support judgement out of is_target, the user can be easy to know if it needs to do TPL judgement. [patch 1/6] - Keep the unsupport device message unchange [patch 1/6] According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, a Targeted Host (non-PC host, OTG or Embedded host) is not required to support operation with all types of USB peripherals. It is up to the manufacturer of each Targeted Host to declare which peripherals the host will support and provide a list of those peripherals. This is called the Targeted Host's Targeted Peripheral List (TPL). The TPL shall accurately represent the device classes supported by the Targeted Host. And the TPL support is a must for USB OTG EH certification test, and TPL support needs to apply for both OTG and EH, it should be decided by platform setting. This patchset changes TPL support behaviour like below: - Apply possible TPL support for all kinds of host - Effect TPL in code is decided by both configuration (CONFIG_USB_OTG_WHITELIST) and platform flag, it can avoid the enumeration failure by choosing TPL configuration wrongly. Besides, TPL can be have a good supplement for authorized feature supplied by sys, Eg, TPL can be modified to match by class using interface descriptor, etc. It may help give some suggestions for recently badUSB report. http://venturebeat.com/2014/07/31/why-you-can-no-longer-trust-any-usb-device-plugged-into-your-pc/ https://srlabs.de/badusb/ Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. -- Best Regards, Peter Chen -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: usbip: fix usbip.h path in userspace tool
Fixes: 588b48caf65c (usbip: move usbip userspace code out of staging) which introduced build failure by not changing uapi/usbip.h include path according to new location. Signed-off-by: Piotr Król piotr.k...@3mdeb.com --- tools/usb/usbip/libsrc/usbip_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/usb/usbip/libsrc/usbip_common.h b/tools/usb/usbip/libsrc/usbip_common.h index 5a0e95edf4df..a80e73d4f11e 100644 --- a/tools/usb/usbip/libsrc/usbip_common.h +++ b/tools/usb/usbip/libsrc/usbip_common.h @@ -15,7 +15,7 @@ #include syslog.h #include unistd.h #include linux/usb/ch9.h -#include ../../uapi/usbip.h +#include ../../../include/uapi/linux/usbip.h #ifndef USBIDS_FILE #define USBIDS_FILE /usr/share/hwdata/usb.ids -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, Sep 03, 2014 at 01:45:32PM -0400, Alan Stern wrote: On Wed, 3 Sep 2014, Peter Chen wrote: PS: I also have an old patch that adds a reset callback to g-mass-storage. Peter asked for this around the same time the other work was done. The idea was that disconnect must flush the buffers to the backing storage device, whereas a reset could avoid flushing anything -- Peter found that the flushing was taking so long, the gadget might not be able to carry out a reset quickly enough if it used the disconnect callback. The version I have of this patch is incomplete; it requires a reset callback to be added to the composite driver. Peter, do you still want to make this change to g-mass-storage? Alan, this problem seems not to be existed at g_mass_storage, g_mass_storage has not .disconnect API and only fsg_disable will be called when bus reset occurs. That sounds like a bug. Shouldn't there be a disconnect callback? Don't we want to flush the dirty buffers when a disconnect occurs? Maybe the dirty buffers are expected to discard if it is a sudden disconnect. I tried at add debug message before fsg_lun_fsync_sub at f_mass_storage, below are some findings: Windows7: - click cancel button during the transfer: [ 766.500854] do_prevent_allow:1383 [ 766.569848] do_prevent_allow:1383 [ 766.587965] do_synchronize_cache:957 - sudden disconnect fsg_lun_fsync_sub is not called linux pc (Linux version 3.16.0-031600-generic) - click cancel button during the transfer: fsg_lun_fsync_sub is not called - sudden disconnect fsg_lun_fsync_sub is not called I think Linux should be improved for the behaviour when click cancel during the transfer. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, Sep 03, 2014 at 01:53:23PM -0400, Alan Stern wrote: On Wed, 3 Sep 2014, Peter Chen wrote: Okay. Let's start by adding the reset field to struct usb_gadget_driver. The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. (At some later time we can add a -reset callback to struct usb_composite_driver; then the reset handler in composite.c can invoke that callback for all function drivers that define it.) Next, add routines to udc-core to handle Vbus changes, function activation changes, and resets. The Vbus routine will invoke the gadget driver's -disconnect callback when Vbus goes off and then call usb_gadget_disconnect. The activation routine will call usb_gadget_disconnect if any functions are deactivated, and usb_gadget_connect if all the functions are activated (basically, do whatever composite.c would do). And the reset routine will invoke the gadget driver's -reset callback. I suppose we'll also have to add fields to struct usb_gadget, to store the current Vbus and activation statuses. If the usb_gadget_disconnect will be not called at gadget driver's -disconnect, it has no much meaning we still have gadget driver's -reset, since the content of its -disconnect and -reset are the same if we don't consider to add function's reset handler. No, they aren't always the same. For example, g_mass_storage ought to flush its dirty buffers when a disconnect occurs, but it doesn't have to flush them when a reset occurs. Then modify all the UDC drivers; make them invoke the new udc-core routines whenever there's a change in Vbus status or a reset, instead of invoking the gadget driver's callbacks directly. At the same time we can remove the code that turns off the pullup when Vbus goes down, because now the udc-core routine will take care of it. Why we need to record the reset at udc-core? We don't really need to. But it seems like a good idea to have events that affect the entire device (including connect, disconnect, reset, and probably also bus suspend and bus resume) all pass through udc-core. Hi Felipe Alan, how about using below steps for this reset/vbus/pullup changes? It mainly uses Alan's suggestion. Step 1: The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. the -reset is mandatory for all gadget drivers (currently, only four, they are composite, configfs, gadgetfs , dbgp. Step 2: Add routines to udc-core to handle Vbus changes, function activation changes, and resets. It will include three sub-steps, from easy to hard: reset handler, vbus handler, and activation handler. Step 3: Modify all UDCs to call udc-core's reset and vbus handler, delete usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers, and delete invoking usb_gadget_connect unconditional at udc_bind_to_driver Step 4: Modify the composite.c to disable pullup for adding every function, and enable pullup when necessary. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: modprobe -r hangs XHCI and panics on dwc3-omap
On Wed, 3 Sep 2014, Felipe Balbi wrote: On the other hand, core.c:dwc3_remove() doesn't call dwc3_core_exit_mode() until after doing a lot of other things. Shouldn't it call dwc3_core_exit_mode() first? yup. At least the PHYs still need to the be alive for as long as XHCI is :-) Let me try that out. There's nothing an extra set of eyes :-) yup, works like a charm. Thanks. Can I add your Suggested-by or something else ? Suggested-by is fine. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] usb: host: change TPL support behaviour
On Thu, 4 Sep 2014, Peter Chen wrote: Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. But usb_enumerate_device_otg() gets called for all types of host, right? At least, it gets called whenever usb_enumerate_device() runs. Yes, it contains #ifdef CONFIG_USB_OTG. But your patch has if (... IS_ENABLED(CONFIG_USB_OTG)), so the behavior is the same. Why move the code if there's no change in behavior? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, 4 Sep 2014, Peter Chen wrote: Alan, this problem seems not to be existed at g_mass_storage, g_mass_storage has not .disconnect API and only fsg_disable will be called when bus reset occurs. That sounds like a bug. Shouldn't there be a disconnect callback? Don't we want to flush the dirty buffers when a disconnect occurs? Maybe the dirty buffers are expected to discard if it is a sudden disconnect. I tried at add debug message before fsg_lun_fsync_sub at f_mass_storage, below are some findings: Windows7: - click cancel button during the transfer: [ 766.500854] do_prevent_allow:1383 [ 766.569848] do_prevent_allow:1383 [ 766.587965] do_synchronize_cache:957 - sudden disconnect fsg_lun_fsync_sub is not called linux pc (Linux version 3.16.0-031600-generic) - click cancel button during the transfer: fsg_lun_fsync_sub is not called - sudden disconnect fsg_lun_fsync_sub is not called I think Linux should be improved for the behaviour when click cancel during the transfer. Maybe, but that means changing the host code, not the gadget code. In general, I think Linux tends to flush caches less often than Windows (at least, for VFAT filesystems). fsg_lun_fsync_sub is probably quite fast if there are no dirty buffers, so adding extra calls won't hurt. The real question is what should the gadget do if the cable gets unplugged _during_ a transfer. I think in that case we really do want to flush the dirty buffers. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] usb: host: change TPL support behaviour
On Wed, Sep 03, 2014 at 09:48:15PM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. But usb_enumerate_device_otg() gets called for all types of host, right? At least, it gets called whenever usb_enumerate_device() runs. Yes, it contains #ifdef CONFIG_USB_OTG. But your patch has if (... IS_ENABLED(CONFIG_USB_OTG)), so the behavior is the same. Why move the code if there's no change in behavior? At former code, the tpl support judgement (in function is_targeted) will only be called if CONFIG_USB_OTG is defined, but now, we need tpl support for all targeted hosts. Why we need IS_ENABLED(CONFIG_USB_OTG) as last conditions at if conditions, the reason is the operation which the B-device may want switch to host even if it is not at A's TPL is only for OTG host. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gadget serial driver - configuration value
On Wed, Sep 3, 2014 at 8:19 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 03, 2014 at 02:48:43PM +0530, Anjana V Kumar wrote: Hi, This is regarding an issue we are facing with the gadget serial driver (driver/usb/gadget/serial.c). We have a hardware limitation and the USB hardware can only have bconfigurationvalue 0 or 1. what kind of limitation is this. Configuration value is a SW-only choice. What HW are you using ? Which kernel are you using ? Do you have logs of the problem ? I am using 3.10 kernel. The issue is that the set_configuration(2) is stalled, while the set_configuration(1) passes with the USB hardware I am using. In the CDC ACM config in gadget serial driver the configuration value is set to 2. Is there a specific reason why this was done? We see that, the three configurations listed in serial driver (CDC ACM, CDC OBEX, generic serial) cannot be present together as per the current implementation. Is there a specific reason why the configuration values were set as 1, 2 and 3 instead of setting all to 1? well, setting configuration 0 means that you're not selecting any configuration. Basically you go back to Addressed state, so you can't use configuration 0 for anything, really. Sorry for not being clear, I am not setting the configuration to 0. The question was, can we set all the three configuration values of CDC ACM, CDC OBEX, and generic serial to 1? Was there any specific reason as to why the configuration values were set as 1,2 and 3. We cannot have all three at the same time according to the current if, elseif, else implementation, -- balbi -- Anjana -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: chipidea: otg initialization is only needed when the gadget is supported
We have only needed to enable otg initialization when both of
below conditions are satisfied:
- The controller is otg capable
- The gadget function is enabled
If the controller is otg capable, but is host-only configuration, we do
not need to access register otgsc and do any otg operations (eg, create
otg workqueue).
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 619d13e..579b353 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -658,7 +658,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
goto deinit_phy;
}
- if (ci-is_otg) {
+ if (ci-is_otg ci-roles[CI_ROLE_GADGET]) {
/* Disable and clear all OTG irq */
hw_write_otgsc(ci, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
OTGSC_INT_STATUS_BITS);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
