Re: [PATCH v4 00/13] USB: OTG/DRD Core functionality
On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote: > Hi, > > This series centralizes OTG/Dual-role functionality in the kernel. > As of now I've got Dual-role functionality working pretty reliably on > dra7-evm and am437x-gp-evm. > > DWC3 controller and platform related patches will be sent separately. > > Series is based on Greg's usb-next tree. Hi Roger, Will you go on for this patch set? Peter > > Changelog: > - > v4: > - Added DT support for tying otg-controller to host and gadget > controllers. For DT we no longer have the constraint that > OTG controller needs to be parent of host and gadget. They can be > tied together using the "otg-controller" property. > - Relax the requirement for DT case that otg controller must register before > host/gadget. We maintain a wait list of host/gadget devices > waiting on the otg controller. > - Use a single struct usb_otg for otg data. > - Don't override host/gadget start/stop APIs. Let the controller > drivers do what they want as they know best. Helper API is provided > for controller start/stop that controller driver can use. > - Introduce struct usb_otg_config to pass the otg capabilities, > otg ops and otg timer timeouts during otg controller registration. > - rebased on Greg's usb.git/usb-next > > v3: > - all otg related definations now in otg.h > - single kernel config USB_OTG to enable OTG core and FSM. > - resolved symbol dependency issues. > - use dev_vdbg instead of VDBG() in usb-otg-fsm.c > - rebased on v4.2-rc1 > > v2: > - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable > the host controller > - added dual-role-device (DRD) state machine which is a much simpler > mode of operation when compared to OTG. Here we don't support fancy > OTG features like HNP, SRP, on the fly role-swap. The mode of operation > is determined based on ID pin (cable type) and the role doesn't change > till the cable type changes. > > Why?: > > > Most of the OTG drivers have been dealing with the OTG state machine > themselves and there is a scope for code re-use. This has been > partly addressed by the usb/common/usb-otg-fsm.c but it still > leaves the instantiation of the state machine and OTG timers > to the controller drivers. We re-use usb-otg-fsm.c but > go one step further by instantiating the state machine and timers > thus making it easier for drivers to implement OTG functionality. > > Newer OTG cores support standard host interface (e.g. xHCI) so > host and gadget functionality are no longer closely knit like older > cores. There needs to be a way to co-ordinate the operation of the > host and gadget in OTG mode. i.e. to stop and start them from a > central location. This central location should be the USB OTG core. > > Host and gadget controllers might be sharing resources and can't > be always running. One has to be stopped for the other to run. > This can't be done as of now and can be done from the OTG core. > > What?: > - > > The OTG core instantiates the OTG/DRD Finite State Machine > per OTG controller and manages starting/stopping the > host and gadget controllers based on the bus state. > > It provides APIs for the following > > - Registering an OTG capable controller > struct otg_fsm *usb_otg_register(struct device *dev, > struct usb_otg_config *config); > > int usb_otg_unregister(struct device *dev); > > - Registering Host controllers to OTG core (used by hcd-core) > int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum, > unsigned long irqflags, struct otg_hcd_ops *ops); > int usb_otg_unregister_hcd(struct usb_hcd *hcd); > > > - Registering Gadget controllers to OTG core (used by udc-core) > int usb_otg_register_gadget(struct usb_gadget *gadget, > struct otg_gadget_ops *ops); > int usb_otg_unregister_gadget(struct usb_gadget *gadget); > > > - Providing inputs to and kicking the OTG state machine > void usb_otg_sync_inputs(struct otg_fsm *fsm); > int usb_otg_kick_fsm(struct device *hcd_gcd_device); > > - Getting controller device structure from OTG state machine instance > struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm); > > 'struct otg_fsm' is the interface to the OTG state machine. > It contains inputs to the fsm, status of the fsm and operations > for the OTG controller driver. > > - Helper APIs for starting/stopping host/gadget controllers > int usb_otg_start_host(struct otg_fsm *fsm, int on); > int usb_otg_start_gadget(struct otg_fsm *fsm, int on); > > Usage model: > --- > > - The OTG core needs to know what host and gadget controllers are > linked to the OTG controller. For DT boots we can provide that > information by adding "otg-controller" property to the host and > gadget controller nodes that points to the right otg controller. > For legacy boot we assume that OTG controller is the parent > of the host and gadget controllers. For DT if "ot
Re: [PATCH] USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
Le 02/12/2015 20:36, Alexandre Belloni a écrit :
> The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
> after registration. At that time, pdev->dev.platform_data is not yet set,
> leading to a NULL pointer dereference.
>
> Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in
> ohci_hcd_at91_drv_probe)
Yes, with:
Cc: sta...@vger.kernel.org # 4.3+
> Reported-by: Peter Rosin
> Tested-by: Peter Rosin
> Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Alan, I think it's a good candidate to enter the 4.4-rcX...
Thanks, bye.
> ---
> drivers/usb/host/ohci-at91.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index 342ffd140122..8c6e15bd6ff0 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -473,6 +473,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
> *pdev)
> if (!pdata)
> return -ENOMEM;
>
> + pdev->dev.platform_data = pdata;
> +
> if (!of_property_read_u32(np, "num-ports", &ports))
> pdata->ports = ports;
>
> @@ -483,6 +485,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
> *pdev)
>*/
> if (i >= pdata->ports) {
> pdata->vbus_pin[i] = -EINVAL;
> + pdata->overcurrent_pin[i] = -EINVAL;
> continue;
> }
>
> @@ -513,10 +516,8 @@ static int ohci_hcd_at91_drv_probe(struct
> platform_device *pdev)
> }
>
> at91_for_each_port(i) {
> - if (i >= pdata->ports) {
> - pdata->overcurrent_pin[i] = -EINVAL;
> - continue;
> - }
> + if (i >= pdata->ports)
> + break;
>
> pdata->overcurrent_pin[i] =
> of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
> @@ -552,8 +553,6 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
> *pdev)
> }
> }
>
> - pdev->dev.platform_data = pdata;
> -
> device_init_wakeup(&pdev->dev, 1);
> return usb_hcd_at91_probe(&ohci_at91_hc_driver, pdev);
> }
>
--
Nicolas Ferre
--
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 00/13] USB: OTG/DRD Core functionality
Peter, On 03/12/15 13:49, Peter Chen wrote: > On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote: >> Hi, >> >> This series centralizes OTG/Dual-role functionality in the kernel. >> As of now I've got Dual-role functionality working pretty reliably on >> dra7-evm and am437x-gp-evm. >> >> DWC3 controller and platform related patches will be sent separately. >> >> Series is based on Greg's usb-next tree. > > Hi Roger, > > Will you go on for this patch set? Yes, but I can only work on this from Feb onwards. cheers, -roger > > Peter >> >> Changelog: >> - >> v4: >> - Added DT support for tying otg-controller to host and gadget >> controllers. For DT we no longer have the constraint that >> OTG controller needs to be parent of host and gadget. They can be >> tied together using the "otg-controller" property. >> - Relax the requirement for DT case that otg controller must register before >> host/gadget. We maintain a wait list of host/gadget devices >> waiting on the otg controller. >> - Use a single struct usb_otg for otg data. >> - Don't override host/gadget start/stop APIs. Let the controller >> drivers do what they want as they know best. Helper API is provided >> for controller start/stop that controller driver can use. >> - Introduce struct usb_otg_config to pass the otg capabilities, >> otg ops and otg timer timeouts during otg controller registration. >> - rebased on Greg's usb.git/usb-next >> >> v3: >> - all otg related definations now in otg.h >> - single kernel config USB_OTG to enable OTG core and FSM. >> - resolved symbol dependency issues. >> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c >> - rebased on v4.2-rc1 >> >> v2: >> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable >> the host controller >> - added dual-role-device (DRD) state machine which is a much simpler >> mode of operation when compared to OTG. Here we don't support fancy >> OTG features like HNP, SRP, on the fly role-swap. The mode of operation >> is determined based on ID pin (cable type) and the role doesn't change >> till the cable type changes. >> >> Why?: >> >> >> Most of the OTG drivers have been dealing with the OTG state machine >> themselves and there is a scope for code re-use. This has been >> partly addressed by the usb/common/usb-otg-fsm.c but it still >> leaves the instantiation of the state machine and OTG timers >> to the controller drivers. We re-use usb-otg-fsm.c but >> go one step further by instantiating the state machine and timers >> thus making it easier for drivers to implement OTG functionality. >> >> Newer OTG cores support standard host interface (e.g. xHCI) so >> host and gadget functionality are no longer closely knit like older >> cores. There needs to be a way to co-ordinate the operation of the >> host and gadget in OTG mode. i.e. to stop and start them from a >> central location. This central location should be the USB OTG core. >> >> Host and gadget controllers might be sharing resources and can't >> be always running. One has to be stopped for the other to run. >> This can't be done as of now and can be done from the OTG core. >> >> What?: >> - >> >> The OTG core instantiates the OTG/DRD Finite State Machine >> per OTG controller and manages starting/stopping the >> host and gadget controllers based on the bus state. >> >> It provides APIs for the following >> >> - Registering an OTG capable controller >> struct otg_fsm *usb_otg_register(struct device *dev, >> struct usb_otg_config *config); >> >> int usb_otg_unregister(struct device *dev); >> >> - Registering Host controllers to OTG core (used by hcd-core) >> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum, >> unsigned long irqflags, struct otg_hcd_ops *ops); >> int usb_otg_unregister_hcd(struct usb_hcd *hcd); >> >> >> - Registering Gadget controllers to OTG core (used by udc-core) >> int usb_otg_register_gadget(struct usb_gadget *gadget, >> struct otg_gadget_ops *ops); >> int usb_otg_unregister_gadget(struct usb_gadget *gadget); >> >> >> - Providing inputs to and kicking the OTG state machine >> void usb_otg_sync_inputs(struct otg_fsm *fsm); >> int usb_otg_kick_fsm(struct device *hcd_gcd_device); >> >> - Getting controller device structure from OTG state machine instance >> struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm); >> >> 'struct otg_fsm' is the interface to the OTG state machine. >> It contains inputs to the fsm, status of the fsm and operations >> for the OTG controller driver. >> >> - Helper APIs for starting/stopping host/gadget controllers >> int usb_otg_start_host(struct otg_fsm *fsm, int on); >> int usb_otg_start_gadget(struct otg_fsm *fsm, int on); >> >> Usage model: >> --- >> >> - The OTG core needs to know what host and gadget controllers are >> linked to the OTG controller. For DT boots we can provide that >> information by adding "otg-
Re: [PATCH v2] usb: dwc3: gadget: handle request->zero
Hi Felipe,
On 12/02/2015 07:55 PM, Felipe Balbi wrote:
> So far, dwc3 has always missed request->zero
> handling for every endpoint. Let's implement
> that so we can handle cases where transfer must
> be finished with a ZLP.
>
> Note that dwc3 is a little special. Even though
> we're dealing with a ZLP, we still need a buffer
> of wMaxPacketSize bytes; to hide that detail from
> every gadget driver, we have a preallocated buffer
> of 1024 bytes (biggest bulk size) to use (and
> share) among all endpoints.
>
> Reported-by: Ravi B
> Signed-off-by: Felipe Balbi
> ---
>
> since v1:
> - remove unnecessary 'free_on_complete' flag
>
> drivers/usb/dwc3/core.h | 3 +++
> drivers/usb/dwc3/gadget.c | 51
> +--
> 2 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 36f1cb74588c..29130682e547 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -37,6 +37,7 @@
> #define DWC3_MSG_MAX 500
>
> /* Global constants */
> +#define DWC3_ZLP_BUF_SIZE1024/* size of a superspeed bulk */
> #define DWC3_EP0_BOUNCE_SIZE 512
> #define DWC3_ENDPOINTS_NUM 32
> #define DWC3_XHCI_RESOURCES_NUM 2
> @@ -647,6 +648,7 @@ struct dwc3_scratchpad_array {
> * @ctrl_req: usb control request which is used for ep0
> * @ep0_trb: trb which is used for the ctrl_req
> * @ep0_bounce: bounce buffer for ep0
> + * @zlp_buf: used when request->zero is set
> * @setup_buf: used while precessing STD USB requests
> * @ctrl_req_addr: dma address of ctrl_req
> * @ep0_trb: dma address of ep0_trb
> @@ -734,6 +736,7 @@ struct dwc3 {
> struct usb_ctrlrequest *ctrl_req;
> struct dwc3_trb *ep0_trb;
> void*ep0_bounce;
> + void*zlp_buf;
> void*scratchbuf;
> u8 *setup_buf;
> dma_addr_t ctrl_req_addr;
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index e341f034296f..5a77e9925939 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1158,6 +1158,32 @@ out:
> return ret;
> }
>
> +static void __dwc3_gadget_ep_zlp_complete(struct usb_ep *ep,
> + struct usb_request *request)
> +{
> + dwc3_gadget_ep_free_request(ep, request);
> +}
> +
> +static int __dwc3_gadget_ep_queue_zlp(struct dwc3 *dwc, struct dwc3_ep *dep)
> +{
> + struct dwc3_request *req;
> + struct usb_request *request;
> + struct usb_ep *ep = &dep->endpoint;
> +
> + dwc3_trace(trace_dwc3_gadget, "queueing ZLP\n");
> + request = dwc3_gadget_ep_alloc_request(ep, GFP_ATOMIC);
> + if (!request)
> + return -ENOMEM;
> +
> + request->length = 0;
> + request->buf = dwc->zlp_buf;
> + request->complete = __dwc3_gadget_ep_zlp_complete;
> +
> + req = to_dwc3_request(request);
> +
> + return __dwc3_gadget_ep_queue(dep, req);
> +}
> +
> static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request
> *request,
> gfp_t gfp_flags)
> {
> @@ -1171,6 +1197,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
> struct usb_request *request,
>
> spin_lock_irqsave(&dwc->lock, flags);
> ret = __dwc3_gadget_ep_queue(dep, req);
> +
> + /*
> + * Okay, here's the thing, if gadget driver has requested for a ZLP by
> + * setting request->zero, instead of doing magic, we will just queue an
> + * extra usb_request ourselves so that it gets handled the same way as
> + * any other request.
> + */
> + if (ret == 0 && request->zero && (request->length % ep->maxpacket == 0))
> + ret = __dwc3_gadget_ep_queue_zlp(dwc, dep);
> +
> +out:
This 'out' label is never used.
> spin_unlock_irqrestore(&dwc->lock, flags);
>
> return ret;
> @@ -2743,6 +2780,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
> goto err3;
> }
>
> + dwc->zlp_buf = kzalloc(DWC3_ZLP_BUF_SIZE, GFP_KERNEL);
> + if (!dwc->zlp_buf) {
> + ret = -ENOMEM;
> + goto err4;
> + }
> +
> dwc->gadget.ops = &dwc3_gadget_ops;
> dwc->gadget.max_speed = USB_SPEED_SUPER;
> dwc->gadget.speed = USB_SPEED_UNKNOWN;
> @@ -2762,16 +2805,19 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>
> ret = dwc3_gadget_init_endpoints(dwc);
> if (ret)
> - goto err4;
> + goto err5;
>
> ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
> if (ret) {
> dev_err(dwc->dev, "failed to register udc\n");
> - goto err4;
> + goto err5;
> }
>
> return 0;
>
> +err5:
> + kfree(dwc->zlp_buf);
> +
> err4:
> dwc3_gadget_free_endpoints(dwc);
> dma_free_coherent(dwc->dev, DWC3_EP0_BOUNCE_SIZE,
> @@ -2804,6 +2850,7 @@ void dwc3_g
[PATCHv2 1/2] extcon: add driver for Intel USB mux
Several Intel PCHs and SOCs have an internal mux that is
used to share one USB port between USB Device Controller and
xHCI. The mux is normally handled by System FW/BIOS, but not
always. For those platforms where the FW does not take care
of the mux, this driver is needed.
Signed-off-by: Heikki Krogerus
---
drivers/extcon/Kconfig | 5 ++
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-intel-usb.c| 118 +++
include/linux/extcon/intel_usb_mux.h | 31 +
4 files changed, 155 insertions(+)
create mode 100644 drivers/extcon/extcon-intel-usb.c
create mode 100644 include/linux/extcon/intel_usb_mux.h
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 0cebbf6..0a7ccb1 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -118,3 +118,8 @@ config EXTCON_USB_GPIO
Used typically if GPIO is used for USB ID pin detection.
endif
+
+config EXTCON_INTEL_USB
+ bool
+ depends on X86 && USB
+ select EXTCON
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index ba787d0..e6e031a 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
+obj-$(CONFIG_EXTCON_INTEL_USB) += extcon-intel-usb.o
diff --git a/drivers/extcon/extcon-intel-usb.c
b/drivers/extcon/extcon-intel-usb.c
new file mode 100644
index 000..3da6039
--- /dev/null
+++ b/drivers/extcon/extcon-intel-usb.c
@@ -0,0 +1,118 @@
+/**
+ * extcon-intel-usb.c - Driver for Intel USB mux
+ *
+ * Copyright (C) 2015 Intel Corporation
+ * Author: Heikki Krogerus
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+
+#define INTEL_MUX_CFG0 0x00
+#define INTEL_MUX_CFG1 0x04
+
+#define CFG0_SW_DRD_MODE_MASK 0x3
+#define CFG0_SW_DRD_DYN0
+#define CFG0_SW_DRD_STATIC_HOST1
+#define CFG0_SW_DRD_STATIC_DEV 2
+#define CFG0_SW_SYNC_SS_AND_HS BIT(2)
+#define CFG0_SW_SWITCH_EN BIT(16)
+#define CFG0_SW_IDPIN BIT(20)
+#define CFG0_SW_IDPIN_EN BIT(21)
+#define CFG0_SW_VBUS_VALID BIT(24)
+
+#define CFG1_MODE BIT(29)
+
+struct intel_usb_mux {
+ struct notifier_block nb;
+ struct extcon_dev edev;
+ void __iomem *regs;
+ u32 cfg0_ctx;
+};
+
+static const int intel_mux_cable[] = {
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+};
+
+static int intel_usb_mux_notifier(struct notifier_block *nb,
+ unsigned long old, void *ptr)
+{
+ struct intel_usb_mux *mux = container_of(nb, struct intel_usb_mux, nb);
+ u32 val;
+
+ if (mux->edev.state)
+ val = CFG0_SW_IDPIN_EN | CFG0_SW_DRD_STATIC_HOST;
+ else
+ val = CFG0_SW_IDPIN_EN | CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID |
+ CFG0_SW_DRD_STATIC_DEV;
+
+ writel(val, mux->regs);
+ return NOTIFY_OK;
+}
+
+struct intel_usb_mux *intel_usb_mux_register(struct device *dev,
+struct resource *r)
+{
+ struct intel_usb_mux *mux;
+ int ret;
+
+ mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+ if (!mux)
+ return ERR_PTR(-ENOMEM);
+
+ mux->regs = ioremap_nocache(r->start, resource_size(r));
+ if (!mux->regs) {
+ kfree(mux);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ mux->cfg0_ctx = readl(mux->regs + INTEL_MUX_CFG0);
+
+ mux->edev.dev.parent = dev;
+ mux->edev.supported_cable = intel_mux_cable;
+
+ ret = extcon_dev_register(&mux->edev);
+ if (ret)
+ goto err;
+
+ mux->edev.name = "intel_usb_mux";
+ mux->edev.state = !!(readl(mux->regs + INTEL_MUX_CFG1) & CFG1_MODE);
+
+ /* An external source needs to tell us what to do */
+ mux->nb.notifier_call = intel_usb_mux_notifier;
+ ret = extcon_register_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
+ if (ret) {
+ dev_err(&mux->edev.dev, "failed to register notifier\n");
+ extcon_dev_unregister(&mux->edev);
+ goto err;
+ }
+ return mux;
+err:
+ iounmap(mux->regs);
+ kfree(mux);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(intel_usb_mux_register);
+
+void intel_usb_mux_unregister(struct intel_usb_mux *mux)
+{
+ if (!mux)
+ return;
+
+ if (WARN_ON(IS_ERR_OR_NULL(extcon_get_extcon_dev(mux->edev.name
+ return;
+
+ extcon_unregister_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
+ extcon_dev_unregister(&mux->edev);
+ writel(mux->cfg0_ctx, mu
[PATCHv2 0/2] extcon: driver for Intel USB MUX
Changes since v1: - Using xhci_find_next_ext_cap() as suggested by Baolu - Protection agains unbalanced uregistering as suggested by David Cohen Hi, This is a driver for an internal mux which is available on most modern Intel platforms that shares an USB port between USB Device Controller and xHCI. Normally BIOS or ACPI take care of it, but on some platforms that is not possible, and the OS has to control it. When the mux needs to be handled by OS, there is always an external component that detects connection changes in the port behind the mux, for example PMIC. The driver for that component needs to notify this driver. The mux itself has no means to detect connection changes on the port. User selectable kconfig option is deliberately left out. The driver for the mux needs to be always selected by the drivers for the component that can notify the mux driver about connection changes. The only platforms the need the OS to be in control of the mux so far are Cherrytrail based, and on Cherrytrail SOC the mux control registers are mapped to xHCI MMIO. The second patch will register an instance of the mux from pci_quirks.c if the mux is detected and if the driver has been loaded. The mux control registers are defined in Cherrytrail datasheets [1] page 2230-2234. I think these should go via extcon tree, but it's up to you guys of course. [1] http://www.intel.es/content/www/es/es/processors/atom/atom-z8000-datasheet-vol-2.html Heikki Krogerus (2): extcon: add driver for Intel USB mux usb: pci-quirks: register USB mux found on Cherrytrail SOC drivers/extcon/Kconfig | 5 ++ drivers/extcon/Makefile | 1 + drivers/extcon/extcon-intel-usb.c| 118 +++ drivers/usb/host/pci-quirks.c| 26 +++- include/linux/extcon/intel_usb_mux.h | 31 + 5 files changed, 180 insertions(+), 1 deletion(-) create mode 100644 drivers/extcon/extcon-intel-usb.c create mode 100644 include/linux/extcon/intel_usb_mux.h -- 2.6.2 -- 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
[PATCHv2 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
Intel Braswell/Cherrytrail has an internal mux that shares
one USB port between USB Device Controller and xHCI. The
same mux is found on several SOCs from Intel, but only on
a few Cherrytrail based platforms the OS is expected to
configure it. Normally BIOS takes care of it.
The driver for the mux is an "extcon" driver. With this we
only register the mux if it's detected.
Suggested-by: Lu Baolu
Signed-off-by: Heikki Krogerus
---
drivers/usb/host/pci-quirks.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..ee875e1 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "pci-quirks.h"
#include "xhci-ext-caps.h"
@@ -1022,9 +1023,32 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
hc_init:
- if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
usb_enable_intel_xhci_ports(pdev);
+ /*
+* Initialize the internal mux that shares a port between USB
+* Device Controller and xHCI on platforms that have it.
+*/
+#define XHCI_INTEL_VENDOR_CAPS 192
+#define XHCI_INTEL_USB_MUX_OFFSET 0x80d8
+ if (xhci_find_next_ext_cap(base, 0, XHCI_INTEL_VENDOR_CAPS)) {
+ struct intel_usb_mux *mux;
+ struct resource r;
+
+ r.start = pci_resource_start(pdev, 0) +
+ XHCI_INTEL_USB_MUX_OFFSET;
+ r.end = r.start + 8;
+ r.flags = IORESOURCE_MEM;
+
+ mux = intel_usb_mux_register(&pdev->dev, &r);
+ if (IS_ERR(mux) && PTR_ERR(mux) == -ENOTSUPP)
+ dev_dbg(&pdev->dev, "USB mux not supported\n");
+ else if (IS_ERR(mux))
+ dev_err(&pdev->dev, "failed to register mux\n");
+ }
+ }
+
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
/* Wait for the host controller to be ready before writing any
--
2.6.2
--
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 3/3] usb: musb: remove redundant stack buffer
On Tue, Dec 01 2015, Felipe Balbi wrote: > Hi, > > Rasmus Villemoes writes: >> aRevision is only used once, so we might as well do the formatting as >> part of the pr_debug. This eliminates the stack buffer, and avoids >> doing the formatting at all when pr_debug is compiled out. >> >> Signed-off-by: Rasmus Villemoes > > this needs to be rebased on top of my testing/next: git url, please. > checking file drivers/usb/musb/musb_core.c > Hunk #1 FAILED at 1458. > Hunk #2 FAILED at 1506. > 2 out of 2 hunks FAILED Did 1/3 and 2/3 apply? They touch some of the same lines, so clearly 3/3 wouldn't apply by itself. Rasmus -- 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: [PATCHv2 1/2] extcon: add driver for Intel USB mux
Hi Heikki,
I'm sorry for delay reply.
On 2015년 12월 03일 18:29, Heikki Krogerus wrote:
> Several Intel PCHs and SOCs have an internal mux that is
> used to share one USB port between USB Device Controller and
> xHCI. The mux is normally handled by System FW/BIOS, but not
> always. For those platforms where the FW does not take care
> of the mux, this driver is needed.
>
> Signed-off-by: Heikki Krogerus
> ---
> drivers/extcon/Kconfig | 5 ++
> drivers/extcon/Makefile | 1 +
> drivers/extcon/extcon-intel-usb.c| 118
> +++
> include/linux/extcon/intel_usb_mux.h | 31 +
> 4 files changed, 155 insertions(+)
> create mode 100644 drivers/extcon/extcon-intel-usb.c
> create mode 100644 include/linux/extcon/intel_usb_mux.h
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 0cebbf6..0a7ccb1 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -118,3 +118,8 @@ config EXTCON_USB_GPIO
> Used typically if GPIO is used for USB ID pin detection.
>
> endif
> +
> +config EXTCON_INTEL_USB
> + bool
> + depends on X86 && USB
> + select EXTCON
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index ba787d0..e6e031a 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -15,3 +15,4 @@ obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
> +obj-$(CONFIG_EXTCON_INTEL_USB) += extcon-intel-usb.o
> diff --git a/drivers/extcon/extcon-intel-usb.c
> b/drivers/extcon/extcon-intel-usb.c
> new file mode 100644
> index 000..3da6039
> --- /dev/null
> +++ b/drivers/extcon/extcon-intel-usb.c
> @@ -0,0 +1,118 @@
> +/**
> + * extcon-intel-usb.c - Driver for Intel USB mux
> + *
> + * Copyright (C) 2015 Intel Corporation
> + * Author: Heikki Krogerus
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +
> +#include
> +
> +#define INTEL_MUX_CFG0 0x00
> +#define INTEL_MUX_CFG1 0x04
> +
> +#define CFG0_SW_DRD_MODE_MASK0x3
> +#define CFG0_SW_DRD_DYN 0
> +#define CFG0_SW_DRD_STATIC_HOST 1
> +#define CFG0_SW_DRD_STATIC_DEV 2
> +#define CFG0_SW_SYNC_SS_AND_HS BIT(2)
> +#define CFG0_SW_SWITCH_ENBIT(16)
> +#define CFG0_SW_IDPINBIT(20)
> +#define CFG0_SW_IDPIN_EN BIT(21)
> +#define CFG0_SW_VBUS_VALID BIT(24)
> +
> +#define CFG1_MODEBIT(29)
> +
> +struct intel_usb_mux {
> + struct notifier_block nb;
> + struct extcon_dev edev;
> + void __iomem *regs;
> + u32 cfg0_ctx;
> +};
> +
> +static const int intel_mux_cable[] = {
> + EXTCON_USB_HOST,
> + EXTCON_NONE,
> +};
> +
> +static int intel_usb_mux_notifier(struct notifier_block *nb,
> + unsigned long old, void *ptr)
> +{
> + struct intel_usb_mux *mux = container_of(nb, struct intel_usb_mux, nb);
> + u32 val;
> +
> + if (mux->edev.state)
> + val = CFG0_SW_IDPIN_EN | CFG0_SW_DRD_STATIC_HOST;
> + else
> + val = CFG0_SW_IDPIN_EN | CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID |
> + CFG0_SW_DRD_STATIC_DEV;
> +
> + writel(val, mux->regs);
> + return NOTIFY_OK;
> +}
> +
> +struct intel_usb_mux *intel_usb_mux_register(struct device *dev,
> + struct resource *r)
> +{
> + struct intel_usb_mux *mux;
> + int ret;
> +
> + mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> + if (!mux)
> + return ERR_PTR(-ENOMEM);
> +
> + mux->regs = ioremap_nocache(r->start, resource_size(r));
> + if (!mux->regs) {
> + kfree(mux);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + mux->cfg0_ctx = readl(mux->regs + INTEL_MUX_CFG0);
> +
> + mux->edev.dev.parent = dev;
> + mux->edev.supported_cable = intel_mux_cable;
> +
> + ret = extcon_dev_register(&mux->edev);
> + if (ret)
> + goto err;
> +
> + mux->edev.name = "intel_usb_mux";
> + mux->edev.state = !!(readl(mux->regs + INTEL_MUX_CFG1) & CFG1_MODE);
> +
> + /* An external source needs to tell us what to do */
> + mux->nb.notifier_call = intel_usb_mux_notifier;
> + ret = extcon_register_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
> + if (ret) {
> + dev_err(&mux->edev.dev, "failed to register notifier\n");
> + extcon_dev_unregister(&mux->edev);
> + goto err;
> + }
> + return mux;
> +err:
> + iounmap(mux->regs);
> + kfree(mux);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(intel_usb_mux_register);
> +
> +void intel_usb_mux_unregister(struct int
Re: [PATCH 01/18] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
Hello.
On 12/2/2015 10:11 PM, John Youn wrote:
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.
Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set. This will avoid
some delays for any ports that have forced host mode.
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 66523fa..7198f4e 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3121,18 +3121,20 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- gusbcfg |= GUSBCFG_FORCEHOSTMODE;
- dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
+ hsotg->regs + GUSBCFG);
+ usleep_range(10, 15);
+ }
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
- gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
- gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
- dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- usleep_range(10, 15);
+ if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
Condition reversed here, perhaps?
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
What's the use of writing back the same value?
[...]
MBR, 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: [PATCH 01/18] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
On 12/3/2015 5:46 PM, Sergei Shtylyov wrote:
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.
Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set. This will avoid
some delays for any ports that have forced host mode.
Signed-off-by: Douglas Anderson
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 66523fa..7198f4e 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -3121,18 +3121,20 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
/* Force host mode to get HPTXFSIZ / GNPTXFSIZ exact power on value */
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
-gusbcfg |= GUSBCFG_FORCEHOSTMODE;
-dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-usleep_range(10, 15);
+if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+dwc2_writel(gusbcfg | GUSBCFG_FORCEHOSTMODE,
+hsotg->regs + GUSBCFG);
+usleep_range(10, 15);
+}
gnptxfsiz = dwc2_readl(hsotg->regs + GNPTXFSIZ);
hptxfsiz = dwc2_readl(hsotg->regs + HPTXFSIZ);
dev_dbg(hsotg->dev, "gnptxfsiz=%08x\n", gnptxfsiz);
dev_dbg(hsotg->dev, "hptxfsiz=%08x\n", hptxfsiz);
-gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
-gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
-dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
-usleep_range(10, 15);
+if (!(gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
Condition reversed here, perhaps?
+dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
What's the use of writing back the same value?
Misunderstood the code, nevermind. :-)
[...]
MBR, 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: [PATCH v2] usb: dwc3: gadget: handle request->zero
Hi, Robert Baldyga writes: >> @@ -1171,6 +1197,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep, >> struct usb_request *request, >> >> spin_lock_irqsave(&dwc->lock, flags); >> ret = __dwc3_gadget_ep_queue(dep, req); >> + >> +/* >> + * Okay, here's the thing, if gadget driver has requested for a ZLP by >> + * setting request->zero, instead of doing magic, we will just queue an >> + * extra usb_request ourselves so that it gets handled the same way as >> + * any other request. >> + */ >> +if (ret == 0 && request->zero && (request->length % ep->maxpacket == 0)) >> +ret = __dwc3_gadget_ep_queue_zlp(dwc, dep); >> + >> +out: > > This 'out' label is never used. good catch. I'll remove it in v3. Thanks -- balbi signature.asc Description: PGP signature
[PATCH v3] usb: dwc3: gadget: handle request->zero
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: Ravi B
Signed-off-by: Felipe Balbi
---
since v1:
- remove unnecessary 'free_on_complete' flag
since v2:
- remove unnecessary 'out' label
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/gadget.c | 50 +--
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 36f1cb74588c..29130682e547 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -37,6 +37,7 @@
#define DWC3_MSG_MAX 500
/* Global constants */
+#define DWC3_ZLP_BUF_SIZE 1024/* size of a superspeed bulk */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
#define DWC3_XHCI_RESOURCES_NUM2
@@ -647,6 +648,7 @@ struct dwc3_scratchpad_array {
* @ctrl_req: usb control request which is used for ep0
* @ep0_trb: trb which is used for the ctrl_req
* @ep0_bounce: bounce buffer for ep0
+ * @zlp_buf: used when request->zero is set
* @setup_buf: used while precessing STD USB requests
* @ctrl_req_addr: dma address of ctrl_req
* @ep0_trb: dma address of ep0_trb
@@ -734,6 +736,7 @@ struct dwc3 {
struct usb_ctrlrequest *ctrl_req;
struct dwc3_trb *ep0_trb;
void*ep0_bounce;
+ void*zlp_buf;
void*scratchbuf;
u8 *setup_buf;
dma_addr_t ctrl_req_addr;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e341f034296f..e916c11ded59 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1158,6 +1158,32 @@ out:
return ret;
}
+static void __dwc3_gadget_ep_zlp_complete(struct usb_ep *ep,
+ struct usb_request *request)
+{
+ dwc3_gadget_ep_free_request(ep, request);
+}
+
+static int __dwc3_gadget_ep_queue_zlp(struct dwc3 *dwc, struct dwc3_ep *dep)
+{
+ struct dwc3_request *req;
+ struct usb_request *request;
+ struct usb_ep *ep = &dep->endpoint;
+
+ dwc3_trace(trace_dwc3_gadget, "queueing ZLP\n");
+ request = dwc3_gadget_ep_alloc_request(ep, GFP_ATOMIC);
+ if (!request)
+ return -ENOMEM;
+
+ request->length = 0;
+ request->buf = dwc->zlp_buf;
+ request->complete = __dwc3_gadget_ep_zlp_complete;
+
+ req = to_dwc3_request(request);
+
+ return __dwc3_gadget_ep_queue(dep, req);
+}
+
static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
gfp_t gfp_flags)
{
@@ -1171,6 +1197,16 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
struct usb_request *request,
spin_lock_irqsave(&dwc->lock, flags);
ret = __dwc3_gadget_ep_queue(dep, req);
+
+ /*
+* Okay, here's the thing, if gadget driver has requested for a ZLP by
+* setting request->zero, instead of doing magic, we will just queue an
+* extra usb_request ourselves so that it gets handled the same way as
+* any other request.
+*/
+ if (ret == 0 && request->zero && (request->length % ep->maxpacket == 0))
+ ret = __dwc3_gadget_ep_queue_zlp(dwc, dep);
+
spin_unlock_irqrestore(&dwc->lock, flags);
return ret;
@@ -2743,6 +2779,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err3;
}
+ dwc->zlp_buf = kzalloc(DWC3_ZLP_BUF_SIZE, GFP_KERNEL);
+ if (!dwc->zlp_buf) {
+ ret = -ENOMEM;
+ goto err4;
+ }
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.max_speed = USB_SPEED_SUPER;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
@@ -2762,16 +2804,19 @@ int dwc3_gadget_init(struct dwc3 *dwc)
ret = dwc3_gadget_init_endpoints(dwc);
if (ret)
- goto err4;
+ goto err5;
ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
if (ret) {
dev_err(dwc->dev, "failed to register udc\n");
- goto err4;
+ goto err5;
}
return 0;
+err5:
+ kfree(dwc->zlp_buf);
+
err4:
dwc3_gadget_free_endpoints(dwc);
dma_free_coherent(dwc->dev, DWC3_EP0_BOUNCE_SIZE,
@@ -2804,6 +2849,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
dwc->ep0_bounce, dwc->ep0_bounce_addr);
kfree(dwc->setup_buf);
+ kfree(dwc->zlp_buf);
dma_free_coherent(dwc->dev, sizeof(*dwc->
Re: [Bug 89511] USB-storage mount error
On Thu, 3 Dec 2015 bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=89511 > > bradha...@fastmail.us changed: > >What|Removed |Added > > CC||bradha...@fastmail.us > > --- Comment #69 from bradha...@fastmail.us --- > This bug affects me. I'm trying the workaround shown here > https://bugzilla.kernel.org/show_bug.cgi?id=89511#c19 > > sudo echo 'temporary write through' > >/sys/block/sdb/device/scsi_disk/6\:0\:0\:0/cache_type > > and I'm getting an operation not permitted error no matter how I try it. If I > run lsatter, I get > lsattr: Inappropriate ioctl for device While reading flags on cache_type Please provide complete information, including such things as your kernel version and the relevant parts of the kernel log. What makes you so sure that your problem is the same as this bug? 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] USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
On Thu, 3 Dec 2015, Nicolas Ferre wrote: > Le 02/12/2015 20:36, Alexandre Belloni a �crit : > > The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right > > after registration. At that time, pdev->dev.platform_data is not yet set, > > leading to a NULL pointer dereference. > > > > Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in > > ohci_hcd_at91_drv_probe) > > Yes, with: > Cc: sta...@vger.kernel.org # 4.3+ > > > > Reported-by: Peter Rosin > > Tested-by: Peter Rosin > > Signed-off-by: Alexandre Belloni > > Acked-by: Nicolas Ferre > > Alan, I think it's a good candidate to enter the 4.4-rcX... I agree. Greg, please merge this with a CC: stable tag added. Acked-by: Alan Stern 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: Infrastructure for zerocopy I/O
On Thu, 3 Dec 2015, Steinar H. Gunderson wrote: > On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote: > >> [ 28.796244] DMAR: Allocating domain for 2-2 failed > > I don't know what the reason is for that. It may be that your kernel > > isn't configured to allocate as much coherent memory as you are asking > > for. We'll have to investigate further, maybe ask somebody who knows > > more about how the DMA subsystem works. > > I'm thinking; maybe should the memory not be allocated against the USB > device, but against the controller it hangs on? (Note that it complains about > allocating the _domain_, not the memory itself.) Do you know if that's > possible from this point in the code? Ah, I see the problem. In usb_alloc_dev(), we set the new USB device's dma_mask equal to the controller's dma_mask, but we don't set the other DMA parameters -- in particular, we don't set the coherent_dma_mask. In fact, it looks like the best approach is to use usb_alloc_coherent() and usb_free_coherent(). Unfortunately this routine doesn't zero out the memory buffer, so you'll have to keep the memset(). > FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any > error messages, but still returns NULL. I'm at a loss. 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: [Bug 89511] USB-storage mount error
dt1:uname -a Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux See attached for relevant kernel log. I have the error: blk_update_request: critical target error, dev sdb, sector 0 JBD2: recovery failed EXT4-fs (sdb): error loading journal which is the same as here: https://bugzilla.kernel.org/show_bug.cgi?id=89511#c2 https://bugzilla.kernel.org/show_bug.cgi?id=89511#c4 On 12/03/2015 08:24 AM, Alan Stern wrote: On Thu, 3 Dec 2015 bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=89511 bradha...@fastmail.us changed: What|Removed |Added CC||bradha...@fastmail.us --- Comment #69 from bradha...@fastmail.us --- This bug affects me. I'm trying the workaround shown here https://bugzilla.kernel.org/show_bug.cgi?id=89511#c19 sudo echo 'temporary write through' /sys/block/sdb/device/scsi_disk/6\:0\:0\:0/cache_type and I'm getting an operation not permitted error no matter how I try it. If I run lsatter, I get lsattr: Inappropriate ioctl for device While reading flags on cache_type Please provide complete information, including such things as your kernel version and the relevant parts of the kernel log. What makes you so sure that your problem is the same as this bug? Alan Stern Dec 3 09:06:50 dt1 kernel: [ 2388.047701] usb 1-1.4: new high-speed USB device number 4 using ehci-pci Dec 3 09:06:50 dt1 kernel: [ 2388.140693] usb 1-1.4: New USB device found, idVendor=0d49, idProduct=7110 Dec 3 09:06:50 dt1 kernel: [ 2388.140698] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2 Dec 3 09:06:50 dt1 kernel: [ 2388.140701] usb 1-1.4: Product: OneTouch II Dec 3 09:06:50 dt1 kernel: [ 2388.140703] usb 1-1.4: Manufacturer: Maxtor Dec 3 09:06:50 dt1 kernel: [ 2388.140706] usb 1-1.4: SerialNumber: B2044FVH Dec 3 09:06:50 dt1 kernel: [ 2388.141073] usb-storage 1-1.4:1.0: USB Mass Storage device detected Dec 3 09:06:50 dt1 kernel: [ 2388.141221] scsi host5: usb-storage 1-1.4:1.0 Dec 3 09:06:51 dt1 kernel: [ 2389.193359] scsi 5:0:0:0: Direct-Access Maxtor OneTouch II 023g PQ: 0 ANSI: 4 Dec 3 09:06:51 dt1 kernel: [ 2389.193816] sd 5:0:0:0: Attached scsi generic sg2 type 0 Dec 3 09:06:51 dt1 kernel: [ 2389.247074] sd 5:0:0:0: [sdb] 195813072 512-byte logical blocks: (100 GB/93.3 GiB) Dec 3 09:06:51 dt1 kernel: [ 2389.300837] sd 5:0:0:0: [sdb] Write Protect is off Dec 3 09:06:51 dt1 kernel: [ 2389.300843] sd 5:0:0:0: [sdb] Mode Sense: 24 00 00 00 Dec 3 09:06:52 dt1 kernel: [ 2389.354586] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 3 09:06:52 dt1 kernel: [ 2389.535697] sdb: unknown partition table Dec 3 09:06:52 dt1 kernel: [ 2389.716201] sd 5:0:0:0: [sdb] Attached SCSI disk Dec 3 09:06:54 dt1 kernel: [ 2391.632947] blk_update_request: critical target error, dev sdb, sector 0 Dec 3 09:06:54 dt1 kernel: [ 2391.632991] JBD2: recovery failed Dec 3 09:06:54 dt1 kernel: [ 2391.632997] EXT4-fs (sdb): error loading journal
Re: [Bug 89511] USB-storage mount error
On Thu, 3 Dec 2015, brad wrote: > dt1:uname -a > Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > See attached for relevant kernel log. The log was short enough to be included directly in the email message rather than as an attachment. Here are the interesting parts: Dec 3 09:06:50 dt1 kernel: [ 2388.047701] usb 1-1.4: new high-speed USB device number 4 using ehci-pci Dec 3 09:06:50 dt1 kernel: [ 2388.140693] usb 1-1.4: New USB device found, idVendor=0d49, idProduct=7110 ... Dec 3 09:06:52 dt1 kernel: [ 2389.354586] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 3 09:06:52 dt1 kernel: [ 2389.535697] sdb: unknown partition table Dec 3 09:06:52 dt1 kernel: [ 2389.716201] sd 5:0:0:0: [sdb] Attached SCSI disk Dec 3 09:06:54 dt1 kernel: [ 2391.632947] blk_update_request: critical target error, dev sdb, sector 0 Dec 3 09:06:54 dt1 kernel: [ 2391.632991] JBD2: recovery failed Dec 3 09:06:54 dt1 kernel: [ 2391.632997] EXT4-fs (sdb): error loading journal > I have the error: > blk_update_request: critical target error, dev sdb, sector 0 > JBD2: recovery failed > EXT4-fs (sdb): error loading journal > > which is the same as here: > https://bugzilla.kernel.org/show_bug.cgi?id=89511#c2 > https://bugzilla.kernel.org/show_bug.cgi?id=89511#c4 Just because the error message is the same doesn't mean the bug has to be the same. > >> sudo echo 'temporary write through' > >>> /sys/block/sdb/device/scsi_disk/6\:0\:0\:0/cache_type > >> and I'm getting an operation not permitted error no matter how I try it. sudo and output redirection don't mix well. Instead of doing it like that, do this: $ sudo -s # echo 'temporary write through' >/sys/block/sdb/device/scsi_disk/*/cache_type # exit 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: [Bug 89511] USB-storage mount error
Thanks! That worked. I was able to read & write. How to make that permanent? On 12/03/2015 10:00 AM, Alan Stern wrote: On Thu, 3 Dec 2015, brad wrote: dt1:uname -a Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux See attached for relevant kernel log. The log was short enough to be included directly in the email message rather than as an attachment. Here are the interesting parts: Dec 3 09:06:50 dt1 kernel: [ 2388.047701] usb 1-1.4: new high-speed USB device number 4 using ehci-pci Dec 3 09:06:50 dt1 kernel: [ 2388.140693] usb 1-1.4: New USB device found, idVendor=0d49, idProduct=7110 ... Dec 3 09:06:52 dt1 kernel: [ 2389.354586] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 3 09:06:52 dt1 kernel: [ 2389.535697] sdb: unknown partition table Dec 3 09:06:52 dt1 kernel: [ 2389.716201] sd 5:0:0:0: [sdb] Attached SCSI disk Dec 3 09:06:54 dt1 kernel: [ 2391.632947] blk_update_request: critical target error, dev sdb, sector 0 Dec 3 09:06:54 dt1 kernel: [ 2391.632991] JBD2: recovery failed Dec 3 09:06:54 dt1 kernel: [ 2391.632997] EXT4-fs (sdb): error loading journal I have the error: blk_update_request: critical target error, dev sdb, sector 0 JBD2: recovery failed EXT4-fs (sdb): error loading journal which is the same as here: https://bugzilla.kernel.org/show_bug.cgi?id=89511#c2 https://bugzilla.kernel.org/show_bug.cgi?id=89511#c4 Just because the error message is the same doesn't mean the bug has to be the same. sudo echo 'temporary write through' /sys/block/sdb/device/scsi_disk/6\:0\:0\:0/cache_type and I'm getting an operation not permitted error no matter how I try it. sudo and output redirection don't mix well. Instead of doing it like that, do this: $ sudo -s # echo 'temporary write through' >/sys/block/sdb/device/scsi_disk/*/cache_type # exit 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: [Bug 89511] USB-storage mount error
It seems to be permanent? After reboot I still have this and I can mount the drive dt1:cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/cache_type write through On 12/03/2015 10:17 AM, brad wrote: Thanks! That worked. I was able to read & write. How to make that permanent? On 12/03/2015 10:00 AM, Alan Stern wrote: On Thu, 3 Dec 2015, brad wrote: dt1:uname -a Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux See attached for relevant kernel log. The log was short enough to be included directly in the email message rather than as an attachment. Here are the interesting parts: Dec 3 09:06:50 dt1 kernel: [ 2388.047701] usb 1-1.4: new high-speed USB device number 4 using ehci-pci Dec 3 09:06:50 dt1 kernel: [ 2388.140693] usb 1-1.4: New USB device found, idVendor=0d49, idProduct=7110 ... Dec 3 09:06:52 dt1 kernel: [ 2389.354586] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 3 09:06:52 dt1 kernel: [ 2389.535697] sdb: unknown partition table Dec 3 09:06:52 dt1 kernel: [ 2389.716201] sd 5:0:0:0: [sdb] Attached SCSI disk Dec 3 09:06:54 dt1 kernel: [ 2391.632947] blk_update_request: critical target error, dev sdb, sector 0 Dec 3 09:06:54 dt1 kernel: [ 2391.632991] JBD2: recovery failed Dec 3 09:06:54 dt1 kernel: [ 2391.632997] EXT4-fs (sdb): error loading journal I have the error: blk_update_request: critical target error, dev sdb, sector 0 JBD2: recovery failed EXT4-fs (sdb): error loading journal which is the same as here: https://bugzilla.kernel.org/show_bug.cgi?id=89511#c2 https://bugzilla.kernel.org/show_bug.cgi?id=89511#c4 Just because the error message is the same doesn't mean the bug has to be the same. sudo echo 'temporary write through' /sys/block/sdb/device/scsi_disk/6\:0\:0\:0/cache_type and I'm getting an operation not permitted error no matter how I try it. sudo and output redirection don't mix well. Instead of doing it like that, do this: $ sudo -s # echo 'temporary write through' >/sys/block/sdb/device/scsi_disk/*/cache_type # exit 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: [Bug 89511] USB-storage mount error
On Thu, 3 Dec 2015, brad wrote: > Thanks! That worked. I was able to read & write. How to make that > permanent? You can create a udev rule that will do it automatically. 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
[PATCH 4/6] net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index e3727b66d850..98add3bf8821 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,11 +49,93 @@
struct qmi_wwan_state {
struct usb_driver *subdriver;
atomic_t pmcount;
- unsigned long unused;
+ unsigned long flags;
struct usb_interface *control;
struct usb_interface *data;
};
+enum qmi_wwan_flags {
+ QMI_WWAN_FLAG_RAWIP = 1 << 0,
+};
+
+static void qmi_wwan_netdev_setup(struct net_device *net)
+{
+ struct usbnet *dev = netdev_priv(net);
+ struct qmi_wwan_state *info = (void *)&dev->data;
+
+ if (info->flags & QMI_WWAN_FLAG_RAWIP) {
+ net->header_ops = NULL; /* No header */
+ net->type= ARPHRD_NONE;
+ net->hard_header_len = 0;
+ net->addr_len= 0;
+ net->flags = IFF_POINTOPOINT | IFF_NOARP |
IFF_MULTICAST;
+ netdev_dbg(net, "mode: raw IP\n");
+ } else if (!net->header_ops) { /* don't bother if already set */
+ ether_setup(net);
+ netdev_dbg(net, "mode: Ethernet\n");
+ }
+
+ /* recalculate buffers after changing hard_header_len */
+ usbnet_change_mtu(net, net->mtu);
+}
+
+static ssize_t raw_ip_show(struct device *d, struct device_attribute *attr,
char *buf)
+{
+ struct usbnet *dev = netdev_priv(to_net_dev(d));
+ struct qmi_wwan_state *info = (void *)&dev->data;
+
+ return sprintf(buf, "%c\n", info->flags & QMI_WWAN_FLAG_RAWIP ? 'Y' :
'N');
+}
+
+static ssize_t raw_ip_store(struct device *d, struct device_attribute *attr,
const char *buf, size_t len)
+{
+ struct usbnet *dev = netdev_priv(to_net_dev(d));
+ struct qmi_wwan_state *info = (void *)&dev->data;
+ bool enable;
+ int err;
+
+ if (strtobool(buf, &enable))
+ return -EINVAL;
+
+ /* no change? */
+ if (enable == (info->flags & QMI_WWAN_FLAG_RAWIP))
+ return len;
+
+ /* we don't want to modify a running netdev */
+ if (netif_running(dev->net)) {
+ netdev_err(dev->net, "Cannot change a running device\n");
+ return -EBUSY;
+ }
+
+ /* let other drivers deny the change */
+ err = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
+ err = notifier_to_errno(err);
+ if (err) {
+ netdev_err(dev->net, "Type change was refused\n");
+ return err;
+ }
+
+ if (enable)
+ info->flags |= QMI_WWAN_FLAG_RAWIP;
+ else
+ info->flags &= ~QMI_WWAN_FLAG_RAWIP;
+ qmi_wwan_netdev_setu
[PATCH 5/6] net: qmi_wwan: document the qmi/raw_ip sysfs file
Signed-off-by: Bjørn Mork --- Documentation/ABI/testing/sysfs-class-net-qmi | 23 +++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi new file mode 100644 index ..d240b7bf6587 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-qmi @@ -0,0 +1,23 @@ +What: /sys/class/net//qmi/raw_ip +Date: Dec 2015 +KernelVersion: 4.4 +Contact: Bjørn Mork +Description: + Boolean. Default: 'N' + + Set this to 'Y' to change the network device link + framing from '802.3' to 'raw-ip'. + + The netdev will change to reflect the link framing + mode. The netdev is an ordinary ethernet device in + '802.3' mode, and the driver expects to exchange + frames with an ethernet header over the USB link. The + netdev is a headerless p-t-p device in 'raw-ip' mode, + and the driver expects to echange IPv4 or IPv6 packets + without any L2 header over the USB link. + + Userspace is in full control of firmware configuration + through the delegation of the QMI protocol. Userspace + is responsible for coordination of driver and firmware + link framing mode, changing this setting to 'Y' if the + firmware is configured for 'raw-ip' mode. -- 2.1.4 -- 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/6] net: qmi_wwan: remove 1199:9070 device id
This turned out to be a bootloader device ID. No need for
that in this driver. It will only provide a single serial
function.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index fc9dd452a3b5..e3727b66d850 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -753,8 +753,6 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
{QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
- {QMI_FIXED_INTF(0x1199, 0x9070, 8)},/* Sierra Wireless
MC74xx/EM74xx */
- {QMI_FIXED_INTF(0x1199, 0x9070, 10)}, /* Sierra Wireless
MC74xx/EM74xx */
{QMI_FIXED_INTF(0x1199, 0x9071, 8)},/* Sierra Wireless
MC74xx/EM74xx */
{QMI_FIXED_INTF(0x1199, 0x9071, 10)}, /* Sierra Wireless
MC74xx/EM74xx */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II
(Alcatel One Touch L100V LTE) */
--
2.1.4
--
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/6] net: qmi_wwan: MDM9x30 specific power management
MDM9x30 based modems appear to go into a deeper sleep when
suspended without "Remote Wakeup" enabled. The QMI interface
will not respond unless a "set DTR" control request is sent
on resume. The effect is similar to a QMI_CTL SYNC request,
resetting (some of) the firmware state.
We allow userspace sessions to span multiple character device
open/close sequences. This means that userspace can depend
on firmware state while both the netdev and the character
device are closed. We have disabled "needs_remote_wakeup" at
this point to allow devices without remote wakeup support to
be auto-suspended.
To make sure the MDM9x30 keeps firmware state, we need to
keep "needs_remote_wakeup" always set. We also need to
issue a "set DTR" request to enable the QMI interface.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 9a5be8b85186..fc9dd452a3b5 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -223,6 +223,20 @@ err:
return rv;
}
+/* Send CDC SetControlLineState request, setting or clearing the DTR.
+ * "Required for Autoconnect and 9x30 to wake up" according to the
+ * GobiNet driver. The requirement has been verified on an MDM9230
+ * based Sierra Wireless MC7455
+ */
+static int qmi_wwan_change_dtr(struct usbnet *dev, bool on)
+{
+ u8 intf = dev->intf->cur_altsetting->desc.bInterfaceNumber;
+
+ return usbnet_write_cmd(dev, USB_CDC_REQ_SET_CONTROL_LINE_STATE,
+ USB_DIR_OUT | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ on ? 0x01 : 0x00, intf, NULL, 0);
+}
+
static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
{
int status = -1;
@@ -280,6 +294,24 @@ static int qmi_wwan_bind(struct usbnet *dev, struct
usb_interface *intf)
usb_driver_release_interface(driver, info->data);
}
+ /* disabling remote wakeup on MDM9x30 devices has the same
+* effect as clearing DTR. The device will not respond to QMI
+* requests until we set DTR again. This is similar to a
+* QMI_CTL SYNC request, clearing a lot of firmware state
+* including the client ID allocations.
+*
+* Our usage model allows a session to span multiple
+* open/close events, so we must prevent the firmware from
+* clearing out state the clients might need.
+*
+* MDM9x30 is the first QMI chipset with USB3 support. Abuse
+* this fact to enable the quirk.
+*/
+ if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
+ qmi_wwan_manage_power(dev, 1);
+ qmi_wwan_change_dtr(dev, true);
+ }
+
/* Never use the same address on both ends of the link, even if the
* buggy firmware told us to. Or, if device is assigned the well-known
* buggy firmware MAC address, replace it with a random address,
@@ -307,6 +339,12 @@ static void qmi_wwan_unbind(struct usbnet *dev, struct
usb_interface *intf)
if (info->subdriver && info->subdriver->disconnect)
info->subdriver->disconnect(info->control);
+ /* disable MDM9x30 quirk */
+ if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
+ qmi_wwan_change_dtr(dev, false);
+ qmi_wwan_manage_power(dev, 0);
+ }
+
/* allow user to unbind using either control or data */
if (intf == info->control)
other = info->data;
--
2.1.4
--
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 0/6] net: qmi_wwan: MDM9x30 support
We add new device IDs all the time, often without any testing on actual hardware. This is usually OK as long as the device is similar to already supported devices, using the same chipset and firmware basis. But the Sierra Wireless MC7455 is an example of a new chipset generation. Adding it based on assumed similarity with its ancestors proved too optimistic. This series adds the missing bits and pieces necessary to support LTE Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to Sierra Wireless for providing MC7455 samples for testing The most important change is the "raw-ip" support. The series also adds a necessary control request, removes an unsupported device ID, and adds a driver specific entry in MAINTAINERS. A few random notes about "raw-ip": "I rather have these all running in raw IP mode. The 802.3 framing is utterly stupid." - Marcel Holtmann in Jan 2012 [1] Marcel was right. I should have listened to him. What more can I say? The 802.3 framing has provided a steady supply of firmware bugs for many years. We've added driver workarounds for many of these, but there are still known bugs where the workaround is so yucky that we have refused to apply it. But all that is over now. The latest generation Qualcomm chips no longer supports 802.3 framing at all. I had two open questions regarding the "raw-ip" userspace API: 1) Should we continue faking an ethernet device, even if we don't use the L2 headers on the USB link anymore? There was a vote in favour of the "headerless" device. This is the honest representation of the hardware/firmware interface. 2) What input should the driver base its framing on? Snooping or directly manipulating QMI is considered out of the question. We delegated all QMI handling to userspace from the beginning. We have so far required userspace to configure the firmware for "802.3" framing, or fail if that proved impossible. This requirement is now changed. Userspace must now inform the driver if it negotiates "raw-ip" framing. Two alternative interfaces were proposed: - ethtool private driver flag, or - sysfs file The NetworkManager/ModemManager developers were in favour of the sysfs alternative. These questions (or any other you migh have :) are of course still open. This patch set presents the solutions I currently prefer, considering the above. All comments are appreciated, even simple '+1' ones. Bjørn [1] http://www.spinics.net/lists/linux-usb/msg57056.html Bjørn Mork (6): net: qmi_wwan: MDM9x30 specific power management net: qmi_wwan: remove 1199:9070 device id usbnet: allow mini-drivers to consume L2 headers net: qmi_wwan: support "raw IP" mode net: qmi_wwan: document the qmi/raw_ip sysfs file MAINTAINERS: add qmi_wwan driver entry Documentation/ABI/testing/sysfs-class-net-qmi | 23 + MAINTAINERS | 7 ++ drivers/net/usb/qmi_wwan.c| 138 +- drivers/net/usb/usbnet.c | 5 +- 4 files changed, 169 insertions(+), 4 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi -- 2.1.4 -- 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 6/6] MAINTAINERS: add qmi_wwan driver entry
Signed-off-by: Bjørn Mork --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ea1751283b49..e9d444a88e48 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11159,6 +11159,13 @@ L: linux-usb@vger.kernel.org S: Supported F: drivers/usb/class/usblp.c +USB QMI WWAN NETWORK DRIVER +M: Bjørn Mork +L: net...@vger.kernel.org +S: Maintained +F: Documentation/ABI/testing/sysfs-class-net-qmi +F: drivers/net/usb/qmi_wwan.c + USB RTL8150 DRIVER M: Petko Manolov L: linux-usb@vger.kernel.org -- 2.1.4 -- 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 3/6] usbnet: allow mini-drivers to consume L2 headers
Assume the minidriver has taken care of all L2 header parsing if it sets skb->protocol. This allows the minidriver to support non-ethernet L2 headers, and even operate without any L2 header at all. Signed-off-by: Bjørn Mork --- drivers/net/usb/usbnet.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 0744bf2ef2d6..0b0ba7ef14e4 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -324,7 +324,10 @@ void usbnet_skb_return (struct usbnet *dev, struct sk_buff *skb) return; } - skb->protocol = eth_type_trans (skb, dev->net); + /* only update if unset to allow minidriver rx_fixup override */ + if (skb->protocol == 0) + skb->protocol = eth_type_trans (skb, dev->net); + dev->net->stats.rx_packets++; dev->net->stats.rx_bytes += skb->len; -- 2.1.4 -- 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: [Bug 89511] USB-storage mount error
On Thu, 3 Dec 2015, brad wrote: > It seems to be permanent? After reboot I still have this and I can > mount the drive > > dt1:cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/cache_type > write through I don't understand. The change you make by writing to the sysfs file is not permanent. It will reset on every reboot and also every time you unplug and replug the drive. 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] USB: storage: add "no SYNCHRONIZE CACHE" quirk
This is an old problem, but it was never resolved and it still affects people (Bugzilla #89511). In short, there are USB-(S)ATA bridges that claim to be write-back but don't support the SYNCHRONIZE CACHE command. This causes errors when filesystems try to flush data out to the disk. On Mon, 22 Jun 2015, James Bottomley wrote: > On Mon, 2015-06-22 at 13:48 -0400, Alan Stern wrote: > > On Mon, 22 Jun 2015, James Bottomley wrote: > > > > > On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote: > > > > On Mon, 22 Jun 2015, James Bottomley wrote: > > > > > > > > > I'm not sure I entirely like this: we are back again treating data > > > > > corruption problems silently. > > > > > > > > > > However, I also believe treating a single flush failure as a critical > > > > > filesystem error is also wrong: The data's all there correctly; all > > > > > it > > > > > does is introduce a potential window were the FS could get corrupted > > > > > in > > > > > the unlikely event the system crashed. > > > > > > > > > > Obviously, for a disk with a writeback cache that can't do flush, that > > > > > window is much wider and the real solution should be to try to switch > > > > > the cache to write through. > > > > > > > > I agree. Doing the switch manually (by writing to the "cache_type" > > > > attribute file) works, but it's a nuisance to do this when you have a > > > > portable USB drive that gets moved among a bunch of machines. > > > > > > Perhaps it might be wise to do this to every USB device ... for external > > > devices, the small performance gain doesn't really make up for the > > > potential data loss. > > > > > > > > How about something like this patch? It transforms FS FLUSH into a > > > > > log > > > > > warning from an error but preserves the error on any other path. > > > > > You'll > > > > > still get a fairly continuous dump of warnings for one of these > > > > > devices, > > > > > though ... do they respond to mode selects turning off the writeback? > > > > > > > > I would be very surprised if any of those drives support MODE SELECT at > > > > all. > > > > > > I assume the cache type attribute file you refer to above is just > > > pretending their cache is write through rather than actually setting it > > > to be so? > > > > Yes; I'm referring to cache_type_store() in sd.c, and writing > > "temporary write through", which does not issue a MODE SELECT command. > > It would be easy enough for people to try leaving out the "temporary", > > but I don't expect it to work. > > > > > The original IDE device had no way of turning their cache > > > types to write through either, but the manufacturers were eventually > > > convinced of the error of their ways. > > > > In this case the stupidity resides in the USB-ATA bridge. You can see > > the gory details at > > > > https://bugzilla.kernel.org/show_bug.cgi?id=89511#c19 > > OK, so that says the SAT in the bridge doesn't know what to do with > MODE_SELECT (probably unsurprising given that it's a usb bridge). the > SATA disk should respond to the ATA command SET FEATURES, though. > Presuming we can get it through the bridge. > > You can try it with > > hdparm -W 0 > > optionally with --prefer_ata_12 to do the 12 instead of 16 byte > encapsulation and see if that makes a difference. As reported by Dan Williams, the SET FEATURES command results in an "Illegal Request: Invalid command operation code" error response. So the question remains, what should we do about these things? We can have a blacklist flag that overrides the cache setting, as in my original patch. We can leave the setting alone and change the errors to warnings, as in James's patch earlier in this thread (but that will generate a lot of warnings). James, what do you think? 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: [Bug 89511] USB-storage mount error
Well, If you don't understand, then I sure don't :) When I wrote 'temporary write through' to cache_type, and cat'd the file it read 'write through' After 2 reboots and at least one power cycle on the ext HD cache_type still has 'write through' dmesg shows this now: ... [sdb] Assuming drive cache: write through when before it always had this: ... [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA On 12/03/2015 11:30 AM, Alan Stern wrote: On Thu, 3 Dec 2015, brad wrote: It seems to be permanent? After reboot I still have this and I can mount the drive dt1:cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/cache_type write through I don't understand. The change you make by writing to the sysfs file is not permanent. It will reset on every reboot and also every time you unplug and replug the drive. 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: [PATCHv2 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
Hello.
On 12/03/2015 12:29 PM, Heikki Krogerus wrote:
Intel Braswell/Cherrytrail has an internal mux that shares
one USB port between USB Device Controller and xHCI. The
same mux is found on several SOCs from Intel, but only on
a few Cherrytrail based platforms the OS is expected to
configure it. Normally BIOS takes care of it.
The driver for the mux is an "extcon" driver. With this we
only register the mux if it's detected.
Hm, I had somewhat identical case on the Renesas SoC: the 2 channel mux
was mapped to the USB device PHY register space, so I chose to implement a PHY
driver, not extcon...
I don't quite understand how mux maps to the extcon core -- doesn't it
provide support only the input signals?
Suggested-by: Lu Baolu
Signed-off-by: Heikki Krogerus
---
drivers/usb/host/pci-quirks.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..ee875e1 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
[...]
@@ -1022,9 +1023,32 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
hc_init:
- if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
usb_enable_intel_xhci_ports(pdev);
+ /*
+* Initialize the internal mux that shares a port between USB
+* Device Controller and xHCI on platforms that have it.
+*/
+#define XHCI_INTEL_VENDOR_CAPS 192
+#define XHCI_INTEL_USB_MUX_OFFSET 0x80d8
+ if (xhci_find_next_ext_cap(base, 0, XHCI_INTEL_VENDOR_CAPS)) {
+ struct intel_usb_mux *mux;
+ struct resource r;
+
+ r.start = pci_resource_start(pdev, 0) +
+ XHCI_INTEL_USB_MUX_OFFSET;
+ r.end = r.start + 8;
+ r.flags = IORESOURCE_MEM;
+
+ mux = intel_usb_mux_register(&pdev->dev, &r);
+ if (IS_ERR(mux) && PTR_ERR(mux) == -ENOTSUPP)
I think you can drop IS_ERR() check here...
+ dev_dbg(&pdev->dev, "USB mux not supported\n");
+ else if (IS_ERR(mux))
+ dev_err(&pdev->dev, "failed to register mux\n");
+ }
+ }
+
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
/* Wait for the host controller to be ready before writing any
MBR, 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: [PATCHv2 1/2] extcon: add driver for Intel USB mux
On 12/03/2015 12:29 PM, Heikki Krogerus wrote:
Several Intel PCHs and SOCs have an internal mux that is
used to share one USB port between USB Device Controller and
xHCI. The mux is normally handled by System FW/BIOS, but not
always. For those platforms where the FW does not take care
of the mux, this driver is needed.
Signed-off-by: Heikki Krogerus
[...]
diff --git a/drivers/extcon/extcon-intel-usb.c
b/drivers/extcon/extcon-intel-usb.c
new file mode 100644
index 000..3da6039
--- /dev/null
+++ b/drivers/extcon/extcon-intel-usb.c
@@ -0,0 +1,118 @@
[...]
+struct intel_usb_mux *intel_usb_mux_register(struct device *dev,
+struct resource *r)
+{
+ struct intel_usb_mux *mux;
+ int ret;
+
+ mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+ if (!mux)
+ return ERR_PTR(-ENOMEM);
+
+ mux->regs = ioremap_nocache(r->start, resource_size(r));
+ if (!mux->regs) {
+ kfree(mux);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ mux->cfg0_ctx = readl(mux->regs + INTEL_MUX_CFG0);
+
+ mux->edev.dev.parent = dev;
+ mux->edev.supported_cable = intel_mux_cable;
+
+ ret = extcon_dev_register(&mux->edev);
I don't see where are you calling extcon_set_cable_state() fot the
"USB-HOST" cable...
This doesn't seem a legitimate extcon driver to me... :-/
+ if (ret)
+ goto err;
+
+ mux->edev.name = "intel_usb_mux";
+ mux->edev.state = !!(readl(mux->regs + INTEL_MUX_CFG1) & CFG1_MODE);
+
+ /* An external source needs to tell us what to do */
+ mux->nb.notifier_call = intel_usb_mux_notifier;
+ ret = extcon_register_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
So in reality this is an extcon client, not a provider? BTW, this API
isn't recommended...
MBR, 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: [PATCH 0/6] net: qmi_wwan: MDM9x30 support
On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote: > We add new device IDs all the time, often without any testing on > actual hardware. This is usually OK as long as the device is similar > to already supported devices, using the same chipset and firmware > basis. But the Sierra Wireless MC7455 is an example of a new chipset > generation. Adding it based on assumed similarity with its ancestors > proved too optimistic. > > This series adds the missing bits and pieces necessary to support LTE > Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks > to > Sierra Wireless for providing MC7455 samples for testing > > The most important change is the "raw-ip" support. The series also > adds a necessary control request, removes an unsupported device ID, > and adds a driver specific entry in MAINTAINERS. > > A few random notes about "raw-ip": > > "I rather have these all running in raw IP mode. The 802.3 framing is > utterly stupid." - Marcel Holtmann in Jan 2012 [1] > > Marcel was right. I should have listened to him. What more can I > say? The decision was less clear-cut at the time, since all the devices did support 802.3 framing and DHCP. And people wanted easy-1-2-3 DHCP and bridging capability too. We still get a lot of people asking about issues with DHCP and even bridging. 802.3 makes it *look* simple but of course we know it's not that simple... > The 802.3 framing has provided a steady supply of firmware bugs for > many years. We've added driver workarounds for many of these, but > there are still known bugs where the workaround is so yucky that we > have refused to apply it. But all that is over now. The latest > generation Qualcomm chips no longer supports 802.3 framing at all. > > I had two open questions regarding the "raw-ip" userspace API: > > 1) Should we continue faking an ethernet device, even if we don't use >the L2 headers on the USB link anymore? > >There was a vote in favour of the "headerless" device. This is the >honest representation of the hardware/firmware interface. I like the approach of the current patchset where it's more like a tun device. Simple. > 2) What input should the driver base its framing on? > >Snooping or directly manipulating QMI is considered out of the >question. We delegated all QMI handling to userspace from the >beginning. > >We have so far required userspace to configure the firmware for >"802.3" framing, or fail if that proved impossible. This >requirement is now changed. Userspace must now inform the driver >if it negotiates "raw-ip" framing. Two alternative interfaces > were >proposed: > - ethtool private driver flag, or > - sysfs file > >The NetworkManager/ModemManager developers were in favour of the >sysfs alternative. Sysfs is the easiest for most things to touch; ethtool requires being able to do ioctls and bit operations or shell out to ethtool. Just stating the reasons for my above vote. Dan > These questions (or any other you migh have :) are of course still > open. This patch set presents the solutions I currently prefer, > considering the above. > > All comments are appreciated, even simple '+1' ones. > > > Bjørn > > [1] http://www.spinics.net/lists/linux-usb/msg57056.html > > > Bjørn Mork (6): > net: qmi_wwan: MDM9x30 specific power management > net: qmi_wwan: remove 1199:9070 device id > usbnet: allow mini-drivers to consume L2 headers > net: qmi_wwan: support "raw IP" mode > net: qmi_wwan: document the qmi/raw_ip sysfs file > MAINTAINERS: add qmi_wwan driver entry > > Documentation/ABI/testing/sysfs-class-net-qmi | 23 + > MAINTAINERS | 7 ++ > drivers/net/usb/qmi_wwan.c| 138 > +- > drivers/net/usb/usbnet.c | 5 +- > 4 files changed, 169 insertions(+), 4 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi > -- 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 3/6] usbnet: allow mini-drivers to consume L2 headers
On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote: > Assume the minidriver has taken care of all L2 header parsing > if it sets skb->protocol. This allows the minidriver to > support non-ethernet L2 headers, and even operate without > any L2 header at all. > > Signed-off-by: Bjørn Mork Acked-by: Oliver Neukum > --- > drivers/net/usb/usbnet.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c > index 0744bf2ef2d6..0b0ba7ef14e4 100644 > --- a/drivers/net/usb/usbnet.c > +++ b/drivers/net/usb/usbnet.c > @@ -324,7 +324,10 @@ void usbnet_skb_return (struct usbnet *dev, struct > sk_buff *skb) > return; > } > > - skb->protocol = eth_type_trans (skb, dev->net); > + /* only update if unset to allow minidriver rx_fixup override */ > + if (skb->protocol == 0) > + skb->protocol = eth_type_trans (skb, dev->net); > + > dev->net->stats.rx_packets++; > dev->net->stats.rx_bytes += skb->len; > -- 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: [Bug 89511] USB-storage mount error
On Thu, 3 Dec 2015, brad wrote: > Well, If you don't understand, then I sure don't :) > When I wrote 'temporary write through' to cache_type, and cat'd the file > it read 'write through' > > After 2 reboots and at least one power cycle on the ext HD cache_type > still has 'write through' > > dmesg shows this now: > ... [sdb] Assuming drive cache: write through > > when before it always had this: > ... [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO > or FUA I can't imagine why that's happening. Still, you can't complain, right? :-) 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: Infrastructure for zerocopy I/O
On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote: >> FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any >> error messages, but still returns NULL. > I'm at a loss. Seemingly controller is already a pointer, so the & is redundant. No idea why it didn't crash plain out. Fixing that, I can allocate, although I have some other bug causing an oops somewhere else. But you still think usb_alloc_coherent() is the better way to go? Should be easy enough to change, just let me know. /* Steinar */ -- Homepage: https://www.sesse.net/ -- 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: trace: show request flags
struct usb_request have 3 flags which might be
important to know about during debug. This patch
shows each of the 3 flags as a single letter:
z -> for zero
s -> short not okay
i -> interrupt
A capital letter means the feature is enabled
while a lower case letter means it is disabled;
Thus 'zsI' indicates that a ZLP is not needed,
that we can accept a short packet and interrupt
for this request should be enabled.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/trace.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h
index 9c10669ab91f..3ac7252f4427 100644
--- a/drivers/usb/dwc3/trace.h
+++ b/drivers/usb/dwc3/trace.h
@@ -117,6 +117,9 @@ DECLARE_EVENT_CLASS(dwc3_log_request,
__field(unsigned, actual)
__field(unsigned, length)
__field(int, status)
+ __field(int, zero)
+ __field(int, short_not_ok)
+ __field(int, no_interrupt)
),
TP_fast_assign(
snprintf(__get_str(name), DWC3_MSG_MAX, "%s", req->dep->name);
@@ -124,9 +127,15 @@ DECLARE_EVENT_CLASS(dwc3_log_request,
__entry->actual = req->request.actual;
__entry->length = req->request.length;
__entry->status = req->request.status;
+ __entry->zero = req->request.zero;
+ __entry->short_not_ok = req->request.short_not_ok;
+ __entry->no_interrupt = req->request.no_interrupt;
),
- TP_printk("%s: req %p length %u/%u ==> %d",
+ TP_printk("%s: req %p length %u/%u %s%s%s ==> %d",
__get_str(name), __entry->req, __entry->actual, __entry->length,
+ __entry->zero ? "Z" : "z",
+ __entry->short_not_ok ? "S" : "s",
+ __entry->no_interrupt ? "i" : "I",
__entry->status
)
);
--
2.6.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: Infrastructure for zerocopy I/O
On Thu, 3 Dec 2015, Steinar H. Gunderson wrote: > On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote: > >> FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any > >> error messages, but still returns NULL. > > I'm at a loss. > > Seemingly controller is already a pointer, so the & is redundant. No idea why > it didn't crash plain out. Fixing that, I can allocate, although I have some > other bug causing an oops somewhere else. Ah, an easy mistake to miss. But you should have gotten a warning from the compiler about incompatible pointer types. > But you still think usb_alloc_coherent() is the better way to go? Should be > easy enough to change, just let me know. Yes, definitely you should use usb_alloc_coherent(). 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
[PATCH v2] usb: Quiet down false peer failure messages
My recent Intel box is spewing these messages:
xhci_hcd :00:14.0: xHCI Host Controller
xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: :00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none)
(usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none)
(usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none)
(usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none)
(usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)
Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports. Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).
Further the unused ports have location data initialized to 0x8000.
Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely
match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.
These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.
The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.
Tested on my Intel box.
Signed-off-by: Don Zickus
---
v2: modified patch to just quiet down the warns instead of skipping the ports
---
drivers/usb/core/port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..5487fe3 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -206,7 +206,7 @@ static int link_peers(struct usb_port *left, struct
usb_port *right)
else
method = "default";
- pr_warn("usb: failed to peer %s and %s by %s (%s:%s) (%s:%s)\n",
+ pr_debug("usb: failed to peer %s and %s by %s (%s:%s)
(%s:%s)\n",
dev_name(&left->dev), dev_name(&right->dev), method,
dev_name(&left->dev),
lpeer ? dev_name(&lpeer->dev) : "none",
@@ -265,7 +265,7 @@ static void link_peers_report(struct usb_port *left, struct
usb_port *right)
if (rc == 0) {
dev_dbg(&left->dev, "peered to %s\n", dev_name(&right->dev));
} else {
- dev_warn(&left->dev, "failed to peer to %s (%d)\n",
+ dev_dbg(&left->dev, "failed to peer to %s (%d)\n",
dev_name(&right->dev), rc);
pr_warn_once("usb: port power management may be unreliable\n");
usb_port_block_power_off = 1;
--
1.8.4
--
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: Quiet down false peer failure messages
On Thu, Dec 3, 2015 at 2:26 PM, Don Zickus wrote: > My recent Intel box is spewing these messages: > > xhci_hcd :00:14.0: xHCI Host Controller > xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 > usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 > usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb2: Product: xHCI Host Controller > usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd > usb usb2: SerialNumber: :00:14.0 > hub 2-0:1.0: USB hub found > hub 2-0:1.0: 6 ports detected > usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) > (usb1-port1:usb2-port1) > usb usb2-port2: failed to peer to usb1-port1 (-16) > usb: port power management may be unreliable > usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) > (usb1-port1:usb2-port1) > usb usb2-port3: failed to peer to usb1-port1 (-16) > usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) > (usb1-port1:usb2-port1) > usb usb2-port5: failed to peer to usb1-port1 (-16) > usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) > (usb1-port1:usb2-port1) > usb usb2-port6: failed to peer to usb1-port1 (-16) > > Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the > XHCI > hub has 8 ports. Most of those ports are of connect type USB_PORT_NOT_USED > (including port 1 of the EHCI hub). > > Further the unused ports have location data initialized to 0x8000. > > Now each unused port on the xhci hub walks the port list and finds a matching > peer with port1 of the EHCI hub because the zero'd out group id bits falsely > match. > After port1 of the XHCI hub, each following matching peer will generate the > above warning. > > These warnings seem to be harmless for this scenario as I don't think it > matters that unused ports could not create a peer link. > > The attached patch utilizes that assumption and just turns the pr_warn into > pr_debug to quiet things down. > > Tested on my Intel box. > > Signed-off-by: Don Zickus Acked-by: Dan Williams -- 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: Infrastructure for zerocopy I/O
On Thu, Dec 03, 2015 at 10:18:20PM +0100, Steinar H. Gunderson wrote: > But you still think usb_alloc_coherent() is the better way to go? Should be > easy enough to change, just let me know. I must be doing something wrong, because I don't seem to get any frames from my video capture, and when I close the application, I get a slowpath warning: [ 188.781392] [ cut here ] [ 188.781409] WARNING: CPU: 0 PID: 1747 at include/asm-generic/dma-mapping-common.h:274 hcd_buffer_free+0xe9/0x130 [usbcore]() [ 188.781422] Modules linked in: ctr ccm joydev nls_utf8 nls_cp437 vfat fat ext2 arc4 intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support kvm crct10dif_pclmul crc32_pclmul crc32c_intel jitterentropy_rng sha256_generic hmac drbg evdev aesni_intel psmouse aes_x86_64 iwlmvm glue_helper lrw serio_raw gf128mul ablk_helper pcspkr cryptd mac80211 efivars i2c_i801 sg thinkpad_acpi lpc_ich iwlwifi nvram snd_hda_intel rtsx_pci_ms memstick snd_hda_codec snd_seq cfg80211 snd_hwdep mei_me snd_seq_device snd_hda_core i915 snd_pcm mei snd_timer wmi i2c_algo_bit drm_kms_helper snd ac drm rfkill tpm_tis tpm battery i2c_core soundcore video button processor autofs4 ext4 crc16 mbcache jbd2 dm_mod sd_mod [ 188.781526] rtsx_pci_sdmmc mmc_core ahci libahci libata scsi_mod ehci_pci ehci_hcd rtsx_pci mfd_core xhci_pci xhci_hcd e1000e ptp usbcore pps_core usb_common thermal [ 188.781550] CPU: 0 PID: 1747 Comm: QXcbEventReader Tainted: GW 4.3.0-usb+ #34 [ 188.781554] Hardware name: LENOVO 20ALCT01WW/20ALCT01WW, BIOS GIET83WW (2.33 ) 08/25/2015 [ 188.781557] c003bb40 812a5113 81068a2c [ 188.781563] 4000 8802340c1098 8189c400 8802345d8400 [ 188.781570] 0282 c002e279 88020c968000 ffeb [ 188.781578] Call Trace: [ 188.781584] [] ? dump_stack+0x40/0x5d [ 188.781596] [] ? warn_slowpath_common+0x7c/0xb0 [ 188.781613] [] ? hcd_buffer_free+0xe9/0x130 [usbcore] [ 188.781630] [] ? dec_usb_memory_use_count+0x56/0x80 [usbcore] [ 188.781647] [] ? free_async+0xa2/0xf0 [usbcore] [ 188.781666] [] ? usbdev_release+0xde/0x130 [usbcore] [ 188.781680] [] ? __fput+0xc5/0x1d0 [ 188.781694] [] ? task_work_run+0x6f/0x90 [ 188.781711] [] ? do_exit+0x36e/0xa80 [ 188.781724] [] ? check_preempt_curr+0x74/0x80 [ 188.781737] [] ? ttwu_do_wakeup+0xf/0xc0 [ 188.781753] [] ? try_to_wake_up+0x3e/0x330 [ 188.781767] [] ? do_group_exit+0x34/0xb0 [ 188.781783] [] ? get_signal+0x297/0x680 [ 188.781799] [] ? do_signal+0x1e/0x670 [ 188.781812] [] ? wake_up_q+0x60/0x60 [ 188.781828] [] ? vfs_write+0x13e/0x180 [ 188.781834] [] ? prepare_exit_to_usermode+0xa3/0xf0 [ 188.781840] [] ? int_ret_from_sys_call+0x25/0x8f [ 188.781844] ---[ end trace 8fd705c87c4a8887 ]--- [ 188.781850] [ cut here ] I'm attaching the current patch for reference. I know I have comments of yours to attend to, but I'd like to try to figure out what's wrong before I embark on polish. /* Steinar */ -- Homepage: https://www.sesse.net/ >From e00443ca99bf5bb4871a7714ce244b63b35e8f83 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" Date: Thu, 26 Nov 2015 01:19:13 +0100 Subject: [PATCH] Add support for usbfs zerocopy. Add a new interface for userspace to preallocate memory that can be used with usbfs. This gives two primary benefits: - Zerocopy; data no longer needs to be copied between the userspace and the kernel, but can instead be read directly by the driver from userspace's buffers. This works for both bulk and isochronous transfers; isochronous also no longer need to memset() the buffer to zero to avoid leaking kernel data. - Once the buffers are allocated, USB transfers can no longer fail due to memory fragmentation; previously, long-running programs could run into problems finding a large enough contiguous memory chunk, especially on embedded systems or at high rates. Memory is allocated by using mmap() against the usbfs file descriptor, and similarly deallocated by munmap(). Once memory has been allocated, using it as pointers to a bulk or isochronous operation means you will automatically get zerocopy behavior. Note that this also means you cannot modify outgoing data until the transfer is complete. The same holds for data on the same cache lines as incoming data; DMA modifying them at the same time could lead to your changes being overwritten. Largely based on a patch by Markus Rechberger with some updates. The original patch can be found at: http://sundtek.de/support/devio_mmap_v0.4.diff Signed-off-by: Steinar H. Gunderson Signed-off-by: Markus Rechberger --- drivers/usb/core/devio.c | 201 --- 1 file changed, 191 insertions(+), 10 deletions(-) diff --git a/drivers/usb
[RESEND,PATCH] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()
On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac..8c7f27d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @np: node containing the phy
* @index: index of the phy
*
- * Gets the phy using _of_phy_get(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
+ * Gets the phy using _of_phy_get(), then gets a refcount to it,
+ * and associates a device with it using devres. On driver detach,
+ * release function is invoked on the devres data,
* then, devres data is freed.
*
*/
@@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device *dev,
struct device_node *np,
return ERR_PTR(-ENOMEM);
phy = _of_phy_get(np, index);
- if (!IS_ERR(phy)) {
- *ptr = phy;
- devres_add(dev, ptr);
- } else {
+ if (IS_ERR(phy)) {
devres_free(ptr);
+ return phy;
}
+ if (!try_module_get(phy->ops->owner)) {
+ devres_free(ptr);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ get_device(&phy->dev);
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
return phy;
}
EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
--
1.8.1.1.dirty
--
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
[RESEND,PATCH] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity
when use the default value 8 of RG_USB20_SQTH, the HS receiver sensitivity test of HQA will fail, set it as 2 to fix up the issue. Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index f30b28b..dc480d3 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -49,6 +49,8 @@ #define PA6_RG_U2_ISO_EN BIT(31) #define PA6_RG_U2_BC11_SW_EN BIT(23) #define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) +#define PA6_RG_U2_SQTH GENMASK(3, 0) +#define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) #define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) #define P2C_RG_USB20_GPIO_CTL BIT(9) @@ -165,9 +167,10 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, writel(tmp, port_base + U3P_U2PHYDTM0); } - /* DP/DM BC1.1 path Disable */ tmp = readl(port_base + U3P_USBPHYACR6); - tmp &= ~PA6_RG_U2_BC11_SW_EN; + tmp &= ~PA6_RG_U2_BC11_SW_EN; /* DP/DM BC1.1 path Disable */ + tmp &= ~PA6_RG_U2_SQTH; + tmp |= PA6_RG_U2_SQTH_VAL(2); writel(tmp, port_base + U3P_USBPHYACR6); tmp = readl(port_base + U3P_U3PHYA_DA_REG0); -- 1.8.1.1.dirty -- 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
[RESEND,PATCH] phy: phy-mt65xx-usb3: improve HS eye diagram
calibrate HS slew rate and switch 100uA current to SSUSB
to improve HS eye diagram of HQA test.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 99 +--
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index dc480d3..9069162 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +28,7 @@
* relative to USB3_SIF2_BASE base address
*/
#define SSUSB_SIFSLV_SPLLC 0x
+#define SSUSB_SIFSLV_U2FREQ0x0100
/* offsets of sub-segment in each port registers */
#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
@@ -41,6 +43,7 @@
#define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18)
#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
#define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12)
#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
@@ -113,6 +116,24 @@
#define XC3_RG_U3_XTAL_RX_PWD BIT(9)
#define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
+#define U3P_U2FREQ_FMCR0 (SSUSB_SIFSLV_U2FREQ + 0x00)
+#define P2F_RG_MONCLK_SEL GENMASK(27, 26)
+#define P2F_RG_MONCLK_SEL_VAL(x) ((0x3 & (x)) << 26)
+#define P2F_RG_FREQDET_EN BIT(24)
+#define P2F_RG_CYCLECNTGENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define U3P_U2FREQ_VALUE (SSUSB_SIFSLV_U2FREQ + 0x0c)
+
+#define U3P_U2FREQ_FMMONR1 (SSUSB_SIFSLV_U2FREQ + 0x10)
+#define P2F_USB_FM_VALID BIT(0)
+#define P2F_RG_FRCK_EN BIT(8)
+
+#define U3P_REF_CLK26 /* MHZ */
+#define U3P_SLEW_RATE_COEF 28
+#define U3P_SR_COEF_DIVISOR1000
+#define U3P_FM_DET_CYCLE_CNT 1024
+
struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
@@ -128,6 +149,77 @@ struct mt65xx_u3phy {
int nphys;
};
+static void hs_slew_rate_calibrate(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
+{
+ void __iomem *sif_base = u3phy->sif_base;
+ int calibration_val;
+ int fm_out;
+ u32 tmp;
+
+ /* enable USB ring oscillator */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp |= PA5_RG_U2_HSTX_SRCAL_EN;
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+ udelay(1);
+
+ /*enable free run clock */
+ tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+ tmp |= P2F_RG_FRCK_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+ /* set cycle count as 1024, and select u2 channel */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
+ tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
+ tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /* enable frequency meter */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp |= P2F_RG_FREQDET_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /* ignore return value */
+ readl_poll_timeout(sif_base + U3P_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+ fm_out = readl(sif_base + U3P_U2FREQ_VALUE);
+
+ /* disable frequency meter */
+ tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+ tmp &= ~P2F_RG_FREQDET_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+ /*disable free run clock */
+ tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+ tmp &= ~P2F_RG_FRCK_EN;
+ writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+ if (fm_out) {
+ /* ( 1024 / FM_OUT ) x reference clock frequency x 0.028 */
+ tmp = U3P_FM_DET_CYCLE_CNT * U3P_REF_CLK * U3P_SLEW_RATE_COEF;
+ tmp /= fm_out;
+ calibration_val = DIV_ROUND_CLOSEST(tmp, U3P_SR_COEF_DIVISOR);
+ } else {
+ /* if FM detection fail, set default value */
+ calibration_val = 4;
+ }
+ dev_dbg(u3phy->dev, "phy:%d, fm_out:%d, calib:%d\n",
+ instance->index, fm_out, calibration_val);
+
+ /* set HS slew rate */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp &= ~PA5_RG_U2_HSTX_SRCTRL;
+ tmp |= PA5_RG_U2_HSTX_SRCTRL_VAL(calibration_val);
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+
+ /* disable USB ring oscillator */
+ tmp = readl(instance->port_base + U3P_USBPHYACR5);
+ tmp &= ~PA5_RG_U2_HSTX_SRCAL_EN;
+ writel(tmp, instance->port_base + U3P_USBPHYACR5);
+}
+
static void phy_instance_init(struct mt65xx_u3phy *u3phy,
struct mt65xx_phy_instance *instance)
{
@@ -226,9 +318,9 @@ static void phy_instance_power_on(struct mt65xx_u3phy
*u3phy,
tmp |= XC
[PATCH] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling
when ip fail to enter sleep mode, register access protection will
be disabed, at the same time if all clocks are disabled, access
register will hang up AHB bus.
the common case causes ip sleep fail is that after all ports enter
U3 but before ip enters sleep mode, a port receives a resume
signal('K'). this will happens when such as clicks mouse to try to
do remote wakeup to stop system enter suspend.
so stop polling roothubs to avoid access xHCI register on bus
suspend, and restart it when bus resume.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c9ab6a4..38635fb 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
}
#ifdef CONFIG_PM_SLEEP
+/*
+ * if ip sleep fail, and all clocks are disabled, access register will hang
+ * AHB bus, so stop poll roothubs to avoid regs access on bus suspend.
+ * and no need to check whether ip sleep fail or not; this will cause SPM to
+ * wakeup system immediately after system suspend complete if ip sleep
+ * fail, it is what we wanted.
+ */
static int xhci_mtk_suspend(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ xhci_dbg(xhci, "%s: stop port polling\n", __func__);
+ clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+ del_timer_sync(&hcd->rh_timer);
+ clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
+ del_timer_sync(&xhci->shared_hcd->rh_timer);
xhci_mtk_host_disable(mtk);
xhci_mtk_phy_power_off(mtk);
@@ -710,11 +725,19 @@ static int xhci_mtk_suspend(struct device *dev)
static int xhci_mtk_resume(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
usb_wakeup_disable(mtk);
xhci_mtk_clks_enable(mtk);
xhci_mtk_phy_power_on(mtk);
xhci_mtk_host_enable(mtk);
+
+ xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+ set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+ usb_hcd_poll_rh_status(hcd);
+ set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
+ usb_hcd_poll_rh_status(xhci->shared_hcd);
return 0;
}
--
1.8.1.1.dirty
--
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: gadget: forbid queuing request to a disabled ep
From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive_file_work, mtp queues a request
to ep. (The mtp driver need improve its synchronization logic!)
3) mtp_function_unbind is invoked and all mtp requests are freed.
4) when udc process the request queued on step 2, will cause kernel
NULL pointer dereference exception.
Signed-off-by: Du, Changbin
---
This patch is seprated from below patches because gadget layer has
added the 'enabled' flag in v4.4. so abandon it and submit new one.
[PATCH 0/2] Two fix for dwc2 gadget driver
usb: dwc2: add ep enabled flag to avoid double enable/disable
usb: dwc2: forbid queuing request to a disabled ep
---
include/linux/usb/gadget.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..d813bd2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep *ep,
static inline int usb_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
+ if (!ep->enabled)
+ return -ESHUTDOWN;
+
return ep->ops->queue(ep, req, gfp_flags);
}
--
2.5.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] usb: gadget: make usb_ep_enable return -EBUSY if ep has already enabled
From: "Du, Changbin" When usb_ep_enable on a enabled ep, the configuration of the ep probably has changed. In this scenario, the ep configuration in hw should be reprogrammed by udc driver. Hence, it is better to return an error to inform the caller. Signed-off-by: Du, Changbin --- include/linux/usb/gadget.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index d813bd2..89f9fdd 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -268,7 +268,7 @@ static inline int usb_ep_enable(struct usb_ep *ep) int ret; if (ep->enabled) - return 0; + return -EBUSY; ret = ep->ops->enable(ep, ep->desc); if (ret) -- 2.5.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] usb: dwc2: fix transfer stop programming for out endpoint
From: "Du, Changbin"
To stop an out endpoint, software should set sets the Global OUT NAK,
but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
failed be in disabled state with below error.
dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
Signed-off-by: Du, Changbin
---
drivers/usb/dwc2/gadget.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0abf73c..92a182f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2911,15 +2911,15 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
*hsotg,
"%s: timeout DIEPINT.NAKEFF\n", __func__);
} else {
/* Clear any pending nak effect interrupt */
- dwc2_writel(GINTSTS_GINNAKEFF, hsotg->regs + GINTSTS);
+ dwc2_writel(GINTSTS_GOUTNAKEFF, hsotg->regs + GINTSTS);
- __orr32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+ __orr32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
/* Wait for global nak to take effect */
if (dwc2_hsotg_wait_bit_set(hsotg, GINTSTS,
- GINTSTS_GINNAKEFF, 100))
+ GINTSTS_GOUTNAKEFF, 100))
dev_warn(hsotg->dev,
- "%s: timeout GINTSTS.GINNAKEFF\n", __func__);
+ "%s: timeout GINTSTS.GOUTNAKEFF\n", __func__);
}
/* Disable ep */
@@ -2944,7 +2944,7 @@ static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg
*hsotg,
/* TODO: Flush shared tx fifo */
} else {
/* Remove global NAKs */
- __bic32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+ __bic32(hsotg->regs + DCTL, DCTL_SGOUTNAK);
}
}
--
2.5.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
