[PATCH] ARM: shmobile: r8a7791: add USB3.0 device node
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
arch/arm/boot/dts/r8a7791.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index d343099..cdf4b46 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1146,6 +1146,16 @@
status = disabled;
};
+ xhci: usb@ee00 {
+ compatible = renesas,xhci-r8a7791;
+ reg = 0 0xee00 0 0xc00;
+ interrupts = 0 101 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp3_clks R8A7791_CLK_SSUSB;
+ phys = usb2 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
pci0: pci@ee09 {
compatible = renesas,pci-r8a7791;
device_type = pci;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: shmobile: lager: enable USB3.0
Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:
phy phy-e6590100.usb-phy.3: phy init failed -- -16
xhci-hcd: probe of ee00.usb failed with error -16
If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
the USB3.0 driver as the following:
echo :02:02.0 /sys/bus/pci/drivers/ehci-pci/unbind
echo :02:01.0 /sys/bus/pci/drivers/ohci-pci/unbind
echo ee00.usb /sys/bus/platform/drivers/xhci-hcd/bind
Note that there will be pinctrl-related error messages if both
internal PCI and USB3.0 are enabled but they should be just ignored:
sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot
claim for ee00.usb
sh-pfc e606.pfc: pin-182 (ee00.usb) status -22
ata1: SATA link down (SStatus 0 SControl 300)
sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2 on
device sh-pfc
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
arch/arm/boot/dts/r8a7790-lager.dts |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 719979e..3f51be1 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -419,6 +419,12 @@
pinctrl-names = default;
};
+xhci {
+ status = okay;
+ pinctrl-0 = usb2_pins;
+ pinctrl-names = default;
+};
+
pci2 {
status = okay;
pinctrl-0 = usb2_pins;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: shmobile: add USB3.0 device node on r8a7790
This series is based on Simon's renesas.git branch and renesas-devel-20141007-v3.17 tag. If we use the generic phy driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use the USB3.0 on lager. Yoshihiro Shimoda (2): ARM: shmobile: r8a7790: add USB3.0 device node ARM: shmobile: lager: enable USB3.0 arch/arm/boot/dts/r8a7790-lager.dts |6 ++ arch/arm/boot/dts/r8a7790.dtsi | 10 ++ 2 files changed, 16 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: add USB3.0 device node on r8a7791
This patch is based on Simon's renesas.git branch and renesas-devel-20141007-v3.17 tag. Since koelsch and henninger doesn't have a USB3.0 connector, I submit a patch for r8a7791.dtsi only. Yoshihiro Shimoda (1): ARM: shmobile: r8a7791: add USB3.0 device node arch/arm/boot/dts/r8a7791.dtsi | 10 ++ 1 file changed, 10 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: shmobile: r8a7790: add USB3.0 device node
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
arch/arm/boot/dts/r8a7790.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 2380fd5..16f8646 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1140,6 +1140,16 @@
status = disabled;
};
+ xhci: usb@ee00 {
+ compatible = renesas,xhci-r8a7790;
+ reg = 0 0xee00 0 0xc00;
+ interrupts = 0 101 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp3_clks R8A7790_CLK_SSUSB;
+ phys = usb2 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
pci0: pci@ee09 {
compatible = renesas,pci-r8a7790;
device_type = pci;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: add USB3.0 device node on r8a7791
(2014/10/08 15:24), Yoshihiro Shimoda wrote: This patch is based on Simon's renesas.git branch and renesas-devel-20141007-v3.17 tag. Since koelsch and henninger doesn't have a USB3.0 connector, I submit a patch for r8a7791.dtsi only. Yoshihiro Shimoda (1): ARM: shmobile: r8a7791: add USB3.0 device node arch/arm/boot/dts/r8a7791.dtsi | 10 ++ 1 file changed, 10 insertions(+) Oops, this patch means [PATCH 0/1]... Also the [PATCH] ARM: shmobile: r8a7791: add USB3.0 device node email means [PATCH 1/1]. Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller
-Original Message- From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold Sent: Monday, October 06, 2014 7:03 PM To: Muthu Mani Cc: Samuel Ortiz; Lee Jones; Wolfram Sang; linux-...@vger.kernel.org; Linus Walleij; Alexandre Courbot; linux-g...@vger.kernel.org; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux- ker...@vger.kernel.org; Rajaram Regupathy Subject: Re: [PATCH v3 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller On Mon, Oct 06, 2014 at 06:22:29PM +0530, Muthu Mani wrote: Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor CYUSBS234 USB-Serial Bridge controller. Details about the device can be found at: http://www.cypress.com/?rID=84126 Signed-off-by: Muthu Mani m...@cypress.com Signed-off-by: Rajaram Regupathy r...@cypress.com --- Please resend this series and include a revision changelog per patch (you can keep it under the cut-off line). Also, make sure not to drop thread participants from CC when resending. Thanks, I have resent it. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
-Original Message-
From: Alexandre Courbot [mailto:gnu...@gmail.com]
Sent: Tuesday, October 07, 2014 3:34 PM
To: Muthu Mani
Cc: Samuel Ortiz; Lee Jones; Wolfram Sang; Linus Walleij; Greg Kroah-
Hartman; linux-...@vger.kernel.org; linux-g...@vger.kernel.org; linux-
u...@vger.kernel.org; Linux Kernel Mailing List; Rajaram Regupathy; Johan
Hovold
Subject: Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-
GPIO adapter
On Mon, Oct 6, 2014 at 11:47 PM, Muthu Mani m...@cypress.com wrote:
+
+static int cy_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset) {
+ return 0;
+}
+
+static int cy_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value) {
+ return 0;
+}
If that chip is capable of both output and input, shouldn't these functions be
implemented? I think this has already been pointed out in a previous version
but you did not reply.
Thanks for your inputs.
Only the GPIOs which are configured to be output GPIO can be set.
The set operation would fail trying to set the input or unconfigured GPIOs.
In this version of driver, this support is not added, it can be introduced in
future versions.
I will add a TODO note in the code.
+
+static int cyusbs23x_gpio_probe(struct platform_device *pdev) {
+ struct cyusbs23x *cyusbs;
+ struct cyusbs_gpio *cy_gpio;
+ int ret = 0;
+
+ dev_dbg(pdev-dev, %s\n, __func__);
+
+ cyusbs = dev_get_drvdata(pdev-dev.parent);
+
+ cy_gpio = devm_kzalloc(pdev-dev, sizeof(*cy_gpio), GFP_KERNEL);
+ if (cy_gpio == NULL)
+ return -ENOMEM;
+
+ cy_gpio-cyusbs = cyusbs;
+ /* registering gpio */
+ cy_gpio-gpio.label = dev_name(pdev-dev);
+ cy_gpio-gpio.dev = pdev-dev;
+ cy_gpio-gpio.owner = THIS_MODULE;
+ cy_gpio-gpio.base = -1;
+ cy_gpio-gpio.ngpio = 12; /* total GPIOs */
Isn't there a way to get the number of GPIOs from a reliable source?
If not, please at least use a macro here.
CYUSBS234 has 12 GPIOs in total as per the datasheet. I will add a macro and
use it.
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Hi Oussama, On 10/07/2014 02:02 PM, Oussama Ghorbel wrote: The USB OTG port does not work since v3.16 on omap platform. This is a regression introduced by the commit eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove). This because the call to pm_runtime_enable() function is moved after the call to devm_phy_create() function, which has side effect since later in the subsequent calls of devm_phy_create() there is a check with pm_runtime_enabled() to configure few things. Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com Acked-by: Roger Quadros rog...@ti.com Could you please send the patch to Cc: sta...@vger.kernel.org[3.16+] That way it will get into 3.16 onwards. Thanks. cheers, -roger -- 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: xhci_hcd can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)
On Tue, Oct 07, 2014 at 11:07:53AM -0400, Alan Stern wrote:
That's the difference. It appears to be caused by a bug in xhci-hcd.
Does the patch below fix the problem?
Hi,
Your patch fixes it for me. So now USB port works well.
Thanks!
Index: usb-3.17/drivers/usb/host/xhci-hub.c
===
--- usb-3.17.orig/drivers/usb/host/xhci-hub.c
+++ usb-3.17/drivers/usb/host/xhci-hub.c
@@ -1136,13 +1136,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, bus_state-bus_suspended);
}
- /* USB core sets remote wake mask for USB 3.0 hubs,
- * including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
- * is enabled, so also enable remote wake here.
+ /* USB core sets remote wake mask for USB 3.0 hubs but
+ * not for USB 2.0 hubs (and only if CONFIG_PM_RUNTIME
+ * is enabled), so enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
- device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
WBR, Dmitry
--
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: btusb_intr_complete returns -EPIPE
On Tue, 2014-10-07 at 20:01 +0530, Naveen Kumar Parna wrote: The new patch clears the halt condition. I mean usb_clear_halt( ) returned zero. That probably means that the device doesn't just produce spurious stalls. Does hcidump show anything when the stalls happen? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices
On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
+static void dln2_rx_transfer(struct dln2_dev *dln2, struct urb *urb,
+ u16 handle, u16 rx_slot)
+{
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+ struct dln2_rx_context *rxc;
+ struct device *dev = dln2-interface-dev;
+
+ spin_lock(rxs-lock);
You must use spin_lock_irqsave here as you call it from the completion
handler.
+
+ rxc = rxs-slots[rx_slot];
+
+ if (rxc-in_use !rxc-urb) {
+ rxc-urb = urb;
+ complete(rxc-done);
+ /* URB will be resubmitted in free_rx_slot */
+ } else {
+ dev_warn(dev, bad/late response %d/%d\n, handle, rx_slot);
+ dln2_submit_urb(dln2, urb, GFP_ATOMIC);
+ }
+
+ spin_unlock(rxs-lock);
+}
+static int _dln2_transfer(struct dln2_dev *dln2, u16 handle, u16 cmd,
+ const void *obuf, unsigned obuf_len,
+ void *ibuf, unsigned *ibuf_len)
+{
+ int ret = 0;
+ u16 result;
+ int rx_slot;
+ struct dln2_response *rsp;
+ struct dln2_rx_context *rxc;
+ struct device *dev;
+ const int timeout = DLN2_USB_TIMEOUT * HZ / 1000;
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+
+ spin_lock(dln2-disconnect_lock);
How did you test this version? You never initialise disconnect_lock so
lockdep complains loudly when calling _dln2_transfer during probe.
+ if (!dln2-disconnect)
+ dln2-active_transfers++;
+ else
+ ret = -ENODEV;
+ spin_unlock(dln2-disconnect_lock);
+
+ if (ret)
+ return ret;
+
+ rx_slot = alloc_rx_slot(dln2, handle);
+ if (rx_slot 0) {
+ ret = rx_slot;
+ goto out_decr;
+ }
+
+ dev = dln2-interface-dev;
+
+ ret = dln2_send_wait(dln2, handle, cmd, rx_slot, obuf, obuf_len);
+ if (ret 0) {
+ dev_err(dev, USB write failed: %d\n, ret);
+ goto out_free_rx_slot;
+ }
+
+ rxc = rxs-slots[rx_slot];
+
+ ret = wait_for_completion_interruptible_timeout(rxc-done, timeout);
+ if (ret = 0) {
+ if (!ret)
+ ret = -ETIMEDOUT;
+ goto out_free_rx_slot;
+ }
+
+ if (!rxc-urb) {
+ ret = -ENODEV;
+ goto out_free_rx_slot;
+ }
+
+ /* if we got here we know that the response header has been checked */
+ rsp = rxc-urb-transfer_buffer;
+
+ if (rsp-hdr.size sizeof(*rsp)) {
+ ret = -EPROTO;
+ goto out_free_rx_slot;
+ }
+
+ result = le16_to_cpu(rsp-result);
+ if (result) {
+ dev_dbg(dev, %d received response with error %d\n,
+ handle, result);
+ ret = -EREMOTEIO;
+ goto out_free_rx_slot;
+ }
+
+ if (!ibuf) {
+ ret = 0;
+ goto out_free_rx_slot;
+ }
+
+ if (*ibuf_len rsp-hdr.size - sizeof(*rsp))
+ *ibuf_len = rsp-hdr.size - sizeof(*rsp);
+
+ memcpy(ibuf, rsp + 1, *ibuf_len);
+
+out_free_rx_slot:
+ free_rx_slot(dln2, handle, rx_slot);
+out_decr:
+ spin_lock(dln2-disconnect_lock);
+ dln2-active_transfers--;
+ spin_unlock(dln2-disconnect_lock);
+ if (dln2-disconnect)
+ wake_up(dln2-disconnect_wq);
+
+ return ret;
+}
+static void dln2_disconnect(struct usb_interface *interface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(interface);
+ int i, j;
+
+ /* don't allow starting new transfers */
+ spin_lock(dln2-disconnect_lock);
+ dln2-disconnect = true;
+ spin_unlock(dln2-disconnect_lock);
+
+ /* cancel in progress transfers */
+ for (i = 0; i DLN2_HANDLES; i++) {
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[i];
+ unsigned long flags;
+
+ spin_lock_irqsave(rxs-lock, flags);
Just stick to spin_lock in this function.
+
+ /* cancel all response waiters */
+ for (j = 0; j DLN2_MAX_RX_SLOTS; j++) {
+ struct dln2_rx_context *rxc = rxs-slots[j];
+
+ if (rxc-in_use)
+ complete(rxc-done);
+ }
+
+ spin_unlock_irqrestore(rxs-lock, flags);
+ }
+
+ /* wait for transfers to end */
+ wait_event(dln2-disconnect_wq, !dln2-active_transfers);
+
+ mfd_remove_devices(interface-dev);
+
+ dln2_free(dln2);
+}
+
+static int dln2_probe(struct usb_interface *interface,
+ const struct usb_device_id *usb_id)
+{
+ struct usb_host_interface *hostif = interface-cur_altsetting;
+ struct device *dev = interface-dev;
+ struct dln2_dev *dln2;
+ int ret;
+ int i, j;
+ int id;
+
+ if (hostif-desc.bInterfaceNumber != 0 ||
+
Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices
On Tue, Oct 07, 2014 at 09:01:27PM +0300, Octavian Purdila wrote: On Tue, Oct 7, 2014 at 8:10 PM, Johan Hovold jo...@kernel.org wrote: On Mon, Oct 06, 2014 at 03:17:22PM +0300, Octavian Purdila wrote: On Fri, Oct 3, 2014 at 8:12 PM, Johan Hovold jo...@kernel.org wrote: On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote: This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO Master Adapter DLN-2. Details about the device can be found here: snip + + ret = dln2_submit_urb(dln2, dln2-rx_urb[i], GFP_KERNEL); + if (ret 0) + return ret; Is it really worth having this helper only to save a couple of lines on a dev_err? If you do all resubmissions on completion inline in the handler, you only have three places where usb_submit_urb is called. I moved the completion in the handler as you suggested. I have kept the helper, would you prefer to remove it? Moved the completion? I was suggesting that the URB resubmission should be done inline the URB completion handler. [ Completion may be a little ambiguous. The URB callback is called an URB completion handler. Not be confused with the completion structures you use to wait for responses. ] Sorry, I meant to say resubmission instead of completion. It's fine to keep the helper as long as it's clear that the urb has been cached and should not be resubmitted (inline) in the completion handler in that case. Not sure I follow you here. I kept the helper and I call it from the completion handler, from free_rx_slot and from dln2_setup_rx_ubs. Ah sorry, I was referring to your other helper dln2_rx_transfer(). I still think you should do away with the dln2_submit_urb() helper as it needlessly hides what's on going without any real gain. Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: gadget: configfs: for_device attribute in configuration directory
Provide interface for setting for_device function designated in a
configuration for handling setup requests directed to device.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/usb/gadget/configfs.c | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index d25f9f3..9648d2a 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -430,7 +430,6 @@ static int config_usb_cfg_unlink(
struct usb_function_instance *fi = container_of(group,
struct usb_function_instance, group);
struct usb_function *f;
-
/*
* ideally I would like to forbid to unlink functions while a gadget is
* bound to an UDC. Since this isn't possible at the moment, we simply
@@ -444,6 +443,8 @@ static int config_usb_cfg_unlink(
list_for_each_entry(f, cfg-func_list, list) {
if (f-fi == fi) {
+ if (f == cfg-c.for_device)
+ cfg-c.for_device = NULL;
list_del(f-list);
usb_put_function(f);
mutex_unlock(gi-lock);
@@ -509,6 +510,51 @@ static ssize_t
gadget_config_desc_bmAttributes_store(struct config_usb_cfg *cfg,
return len;
}
+static ssize_t gadget_config_desc_for_device_show(struct config_usb_cfg *cfg,
+ char *page)
+{
+ return sprintf(page, %s\n, cfg-c.for_device ?
+ cfg-c.for_device-fi-group.cg_item.ci_name : );
+}
+
+static ssize_t gadget_config_desc_for_device_store(struct config_usb_cfg *cfg,
+ const char *page, size_t len)
+{
+ struct usb_composite_dev *cdev = cfg-c.cdev;
+ struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+ struct usb_function *f = NULL;
+ ssize_t ret = -EBUSY;
+ char *name;
+
+ name = kstrdup(page, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+ if (name[len - 1] == '\n')
+ name[len - 1] = '\0';
+
+ mutex_lock(gi-lock);
+ if (gi-udc_name)
+ goto out;
+
+ if (!len || !*page || *page == '\n')
+ goto set_ret;
+
+ list_for_each_entry(f, cfg-func_list, list)
+ if (!strncmp(f-fi-group.cg_item.ci_name, name, len))
+ break;
+ if (f-list == cfg-func_list) {
+ ret = -EINVAL;
+ goto out;
+ }
+set_ret:
+ ret = len;
+ cfg-c.for_device = f;
+out:
+ mutex_unlock(gi-lock);
+ kfree(name);
+ return ret;
+}
+
#define CFG_CONFIG_DESC_ITEM_ATTR(name)\
static struct config_usb_cfg_attribute gadget_usb_cfg_##name = \
__CONFIGFS_ATTR(name, S_IRUGO | S_IWUSR, \
@@ -517,10 +563,12 @@ static ssize_t
gadget_config_desc_bmAttributes_store(struct config_usb_cfg *cfg,
CFG_CONFIG_DESC_ITEM_ATTR(MaxPower);
CFG_CONFIG_DESC_ITEM_ATTR(bmAttributes);
+CFG_CONFIG_DESC_ITEM_ATTR(for_device);
static struct configfs_attribute *gadget_config_attrs[] = {
gadget_usb_cfg_MaxPower.attr,
gadget_usb_cfg_bmAttributes.attr,
+ gadget_usb_cfg_for_device.attr,
NULL,
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Handling per-device setup requests
There are some hosts (e.g. with a popular, proprietary operating system), which issue setup requests directed at a device even though they mean setup requests directed at a particular interface (usb function). This series adds optional for_device attribute in struct usb_configuration. If the attribute is non-NULL, the USB function it points to is used as the last fallback when searching for handlers in composite_setup(). If the attribute is NULL, then the composite_setup() behaviour remains unchanged. The second patch adds a method to get/set the function to be used as for_device in a configfs-composed gadget. Since Felipe closed his tree for 3.18 this is meant for 3.19. Andrzej Pietrasiewicz (2): usb: gadget: composite: optional handling of per-device requests usb: gadget: configfs: for_device attribute in configuration directory drivers/usb/gadget/composite.c | 16 +- drivers/usb/gadget/configfs.c | 50 +- include/linux/usb/composite.h | 1 + 3 files changed, 60 insertions(+), 7 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: gadget: composite: optional handling of per-device requests
Some not-so-well-behaving USB hosts with a popular proprietary operating
system sometimes issue per-device requests even though they mean requests
for a particular function, e.g. for ptp (picture transfer protocol).
This patch adds optional for_device function in usb_configuration so that
it can be used as the last fallback when handling unknown requests. If it
is not set then the composite_setup() behaviour remains unchanged.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/usb/gadget/composite.c | 16 ++--
include/linux/usb/composite.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6178353..32b0104 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1785,12 +1785,16 @@ unknown:
}
/* try the only function in the current config */
- if (!list_is_singular(c-functions))
- goto done;
- f = list_first_entry(c-functions, struct usb_function,
-list);
- if (f-setup)
- value = f-setup(f, ctrl);
+ if (list_is_singular(c-functions)) {
+ f = list_first_entry(c-functions,
+struct usb_function, list);
+ if (f-setup)
+ value = f-setup(f, ctrl);
+ } else {
+ f = c-for_device;
+ if (f f-setup)
+ value = f-setup(f, ctrl);
+ }
}
goto done;
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 3d87def..080aaa2 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -313,6 +313,7 @@ struct usb_configuration {
unsignedhighspeed:1;
unsignedfullspeed:1;
struct usb_function *interface[MAX_CONFIG_INTERFACES];
+ struct usb_function *for_device;
};
int usb_add_config(struct usb_composite_dev *,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: configfs: add suspend/resume
USB gadgets composed with configfs lack suspend and resume
methods. This patch uses composite_suspend()/composite_resume()
the same way e.g. composite_setup() or composite_disconnect()
are used in a configfs-based gadget.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
Since Felipe closed his tree for 3.18 this is meant for 3.19.
drivers/usb/gadget/composite.c | 6 ++
drivers/usb/gadget/configfs.c | 3 +++
include/linux/usb/composite.h | 2 ++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index e071d58..6178353 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2064,8 +2064,7 @@ fail:
/*-*/
-static void
-composite_suspend(struct usb_gadget *gadget)
+void composite_suspend(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
struct usb_function *f;
@@ -2088,8 +2087,7 @@ composite_suspend(struct usb_gadget *gadget)
usb_gadget_vbus_draw(gadget, 2);
}
-static void
-composite_resume(struct usb_gadget *gadget)
+void composite_resume(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
struct usb_function *f;
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 3403433..d25f9f3 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1453,6 +1453,9 @@ static const struct usb_gadget_driver
configfs_driver_template = {
.reset = composite_disconnect,
.disconnect = composite_disconnect,
+ .suspend= composite_suspend,
+ .resume = composite_resume,
+
.max_speed = USB_SPEED_SUPER,
.driver = {
.owner = THIS_MODULE,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index ed3811c..3d87def 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -506,6 +506,8 @@ extern int usb_string_ids_n(struct usb_composite_dev *c,
unsigned n);
extern void composite_disconnect(struct usb_gadget *gadget);
extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
+extern void composite_suspend(struct usb_gadget *gadget);
+extern void composite_resume(struct usb_gadget *gadget);
/*
* Some systems will need runtime overrides for the product identifiers
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fs: configfs: add allow_drop() to configfs_item_operations
Sometimes it might be desirable to prohibit removing a symbolic link
in configfs. One example is USB gadget: when a gadget is already bound,
if USB function symlink (used to associate USB functions with USB
configurations) is removed, the gadget must be thrown away, too.
A better solution would be to fail with e.g. -EBUSY.
Why add a new method? Even though (*drop_link)() does have a return value,
it is ignored in fs/configfs/symlink.c:configfs_unlink(). It could be
tempting to just check the return value, but some users of configfs might
already depend on the fact that (*drop_link)() is called _after_
corresponding filesystem entities are torn down. In other words, the
semantics of (*drop_link)() is the final, unconditional cleanup. In order
not to break this semantics, a new method is added and its value is checked
in fs/configfs/symlink.c:configfs_unlink().
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
fs/configfs/symlink.c| 11 +--
include/linux/configfs.h | 1 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
index cc9f254..52851dc 100644
--- a/fs/configfs/symlink.c
+++ b/fs/configfs/symlink.c
@@ -198,6 +198,13 @@ int configfs_unlink(struct inode *dir, struct dentry
*dentry)
parent_item = configfs_get_config_item(dentry-d_parent);
type = parent_item-ci_type;
+ if (type type-ct_item_ops
+ type-ct_item_ops-allow_drop) {
+ ret = type-ct_item_ops-allow_drop(parent_item,
+ sl-sl_target);
+ if (ret)
+ goto out_put;
+ }
spin_lock(configfs_dirent_lock);
list_del_init(sd-s_sibling);
@@ -224,10 +231,10 @@ int configfs_unlink(struct inode *dir, struct dentry
*dentry)
config_item_put(sl-sl_target);
kfree(sl);
- config_item_put(parent_item);
-
ret = 0;
+out_put:
+ config_item_put(parent_item);
out:
return ret;
}
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 34025df..29df5e1 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -226,6 +226,7 @@ struct configfs_item_operations {
ssize_t (*show_attribute)(struct config_item *, struct
configfs_attribute *,char *);
ssize_t (*store_attribute)(struct config_item *,struct
configfs_attribute *,const char *, size_t);
int (*allow_link)(struct config_item *src, struct config_item *target);
+ int (*allow_drop)(struct config_item *src, struct config_item *target);
int (*drop_link)(struct config_item *src, struct config_item *target);
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: f_fs: add zombie mode
Hi, -Original Message- From: Mike Nazarewicz [mailto:m...@google.com] On Behalf Of Michal Nazarewicz Sent: Tuesday, October 07, 2014 10:08 PM To: Alan Stern; Felipe Balbi Cc: Krzysztof Opasiak; 'Robert Baldyga'; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux- ker...@vger.kernel.org; andrze...@samsung.com Subject: Re: [PATCH] usb: gadget: f_fs: add zombie mode On Tue, 7 Oct 2014, Felipe Balbi wrote: Right, but if we allow this, I can already see folks abusing to connect to the host early and only when necessary do some trickery to e.g. start adbd (not saying Android will do this, just using it as an easy example). I don't really see that happening. For the gadget to start all descriptors need to be known. Functionfs will know the descriptors only once the user space daemon provides them. Therefore, with the current features (or even with addition of Robert's feature) there is no way to let the gadget start without having the daemon running. Well, to be honest we do some lazy daemon startup in gadgetd. The idea is to provide functionality quite similar to inet. So we have divided functionfs services into two parts: - Descriptors - provided in configuration file - function implementation - provided in binary Now user can create ffs function using gadgetd without worrying about mounting the file system, running daemon and many other stuff. Gadgetd is system-wide usb gadget manager which provides abstraction layer for kernel functions and ffs-based functions. Example: User would like to create gadget which contains MTP in first configuration and ADB in second. When gadgetd receives such request via DBUS it creates suitable functions on configfs, find suitable configuration files, mount two instances of ffs, write descriptors from config files and run poll() on both ep0. Please notice here that any other daemon has not been run but the whole gadget can be bound to UDC. When usb device is connected to host then host will select one of available configurations. All functions in that configuration receive ENABLE event. When gadgetd receives such event from one of ep0 then fork() is executed and desired service is being run with all file descriptors opened and ready to use. Please also notice here that if host select first configuration, only one of those daemon is going to be run. (...) -- Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics k.opas...@samsung.com -- 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: btusb_intr_complete returns -EPIPE
hcidump does not show anything when the stalls happen. Here is the hcidump log: [root@banunxcas29 np03]# hcidump -x -t HCI sniffer - Bluetooth packet analyzer ver 2.1 device: hci0 snap_len: 1028 filter: 0x Corresponding usbmon log 8801265343c0 2826295762 C Ii:1:021:1 -32:1 0 880126418840 2826297275 S Ii:1:021:1 -115:1 16 880126534240 2826298730 C Ii:1:020:1 -32:1 0 880126418840 2826298856 C Ii:1:021:1 -32:1 0 880126418840 2826299789 S Ii:1:020:1 -115:1 16 880126418900 2826300154 S Ii:1:021:1 -115:1 16 8801266329c0 2837941755 C Ii:1:018:1 -32:1 0 880126632c00 2837941884 C Ii:1:016:1 -32:1 0 880126418b40 2837942862 S Ii:1:016:1 -115:1 16 880126418300 2837943184 S Ii:1:018:1 -115:1 16 880126418300 2897160790 C Ii:1:018:1 -32:1 0 880126418300 2897162701 S Ii:1:018:1 -115:1 16 880126632cc0 2897332778 C Ii:1:019:1 -32:1 0 880126418840 2897332909 C Ii:1:020:1 -32:1 0 880126418900 2897332959 C Ii:1:021:1 -32:1 0 880126418b40 2897333002 C Ii:1:016:1 -32:1 0 880126418300 2897333035 C Ii:1:018:1 -32:1 0 880126418900 2897334155 S Ii:1:021:1 -115:1 16 880126418b40 2897334405 S Ii:1:020:1 -115:1 16 880126418300 2897334635 S Ii:1:019:1 -115:1 16 880126418f00 2897335015 S Ii:1:018:1 -115:1 16 880126418840 2897335367 S Ii:1:016:1 -115:1 16 Corresponding kernel log: Oct 8 15:29:38 banunxcas29 kernel: [ 3244.604776] hci7 urb 8801265343c0 status -32 count 0 Oct 8 15:29:38 banunxcas29 kernel: [ 3244.606273] hci7 Oct 8 15:29:38 banunxcas29 kernel: [ 3244.607741] hci6 urb 880126534240 status -32 count 0 Oct 8 15:29:38 banunxcas29 kernel: [ 3244.607862] hci7 urb 880126418840 status -32 count 0 Oct 8 15:29:38 banunxcas29 kernel: [ 3244.608787] hci6 Oct 8 15:29:38 banunxcas29 kernel: [ 3244.609155] hci7 Oct 8 15:29:49 banunxcas29 kernel: [ 3256.251736] hci4 urb 8801266329c0 status -32 count 0 Oct 8 15:29:49 banunxcas29 kernel: [ 3256.251857] hci2 urb 880126632c00 status -32 count 0 Oct 8 15:29:49 banunxcas29 kernel: [ 3256.252828] hci2 Oct 8 15:29:49 banunxcas29 kernel: [ 3256.253153] hci4 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.476287] hci4 urb 880126418300 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.478179] hci4 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648289] hci5 urb 880126632cc0 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648411] hci6 urb 880126418840 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648461] hci7 urb 880126418900 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648504] hci2 urb 880126418b40 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648537] hci4 urb 880126418300 status -32 count 0 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.649651] hci7 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.649905] hci6 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.650134] hci5 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.650514] hci4 Oct 8 15:30:49 banunxcas29 kernel: [ 3315.650866] hci2 Thanks, Naveen On Wed, Oct 8, 2014 at 2:39 PM, Oliver Neukum oneu...@suse.de wrote: On Tue, 2014-10-07 at 20:01 +0530, Naveen Kumar Parna wrote: The new patch clears the halt condition. I mean usb_clear_halt( ) returned zero. That probably means that the device doesn't just produce spurious stalls. Does hcidump show anything when the stalls happen? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM: shmobile: lager: enable HS-USB
On 10/8/2014 8:51 AM, Yoshihiro Shimoda wrote:
Enable HS-USB device for the Lager board, defining the GPIO that the driver
should check when probing. Since this board doesn't have the OTG ID pin, we
assume that GP5_18 (USB0_PWEN) is an ID pin because it is 1 when the SW5 is
in position 2-3 (meaning USB function) and 0 in other positions.
snip
Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -226,6 +226,11 @@
renesas,function = usb0;
};
+ hsusb_pins: usb0 {
+ renesas,groups = usb0_ovc_vbus;
Thank you for the v3 patch.
I tested this, and kernel log said GP_5_19 already requested.
GP5_19 is also USB0_OVC_VBUS. It's used by PCI [EO]HCI.
However, the hsusb on lager uses GP_5_18. Is this correct behavior?
Yes, this error needs to be ignored (I wrote about that in the changelog
but you cut out that part). If you disable the internal PCI driver, this error
will disappear.
sh-pfc e606.pfc: pin GP_5_19 already requested by ee09.pci; cannot
claim for e659.usb
sh-pfc e606.pfc: pin-179 (e659.usb) status -22
sh-pfc e606.pfc: could not request pin 179 (GP_5_19) from group
usb0_ovc_vbus on device sh-pfc
The kernel log already tells you well about the source of error.
Best regards,
Yoshihiro Shimoda
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] usb: gadget: f_uac1: remove an unneeded NULL check
This NULL check sets off a static checker warning because we already dereferenced card earlier in the function. However, since card is never NULL so we can just remove the check. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/usb/gadget/function/u_uac1.c b/drivers/usb/gadget/function/u_uac1.c index a44a07f..53842a1 100644 --- a/drivers/usb/gadget/function/u_uac1.c +++ b/drivers/usb/gadget/function/u_uac1.c @@ -213,9 +213,6 @@ static int gaudio_open_snd_dev(struct gaudio *card) fn_cap = opts-fn_cap; fn_cntl = opts-fn_cntl; - if (!card) - return -ENODEV; - /* Open control device */ snd = card-control; snd-filp = filp_open(fn_cntl, O_RDWR, 0); -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btusb_intr_complete returns -EPIPE
On Wed, 2014-10-08 at 15:51 +0530, Naveen Kumar Parna wrote: hcidump does not show anything when the stalls happen. There is nothing in all logs. Do you see the problem with single devices? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter
On Thu, Sep 25, 2014 at 07:07:32PM +0300, Octavian Purdila wrote: diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 b/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 new file mode 100644 index 000..ad55af6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 This is a nonstandard path that does not match the attribute path (or any other convention followed under ABI/). I suggest you rename it sysfs-class-i2c-adapter-dln2 @@ -0,0 +1,5 @@ +What:/sys/bus/i2c/devices/.../dln2_i2c_freq I think you should rename the attribute bus_frequency and name the attribute group dln2. That way the attribute will show up as .../device/dln2/bus_frequency Then the What: field should read What: /sys/class/i2c-adapter/device/dln2/bus_frequency +Date:September 2014 +Contact: Octavian Purdila octavian.purd...@intel.com +Description: + This attribute shows/sets the frequency (in Hz) of the I2C bus. I'd reword this Set the frequency Please also describe under what circumstances this may fail, that is, when setting a frequency less than or greater than the min or max frequencies reported by the device. Perhaps you should even consider exporting those two values? Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices
On Wed, Oct 8, 2014 at 12:23 PM, Johan Hovold jo...@kernel.org wrote:
On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
+static void dln2_rx_transfer(struct dln2_dev *dln2, struct urb *urb,
+ u16 handle, u16 rx_slot)
+{
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+ struct dln2_rx_context *rxc;
+ struct device *dev = dln2-interface-dev;
+
+ spin_lock(rxs-lock);
You must use spin_lock_irqsave here as you call it from the completion
handler.
Why? AFAICS the completion handler gets called from the HCD irq handler:
[2.503945] Call Trace:
[2.503945] IRQ [81a73d14] dump_stack+0x4e/0x7a
[2.503945] [81639fcb] dln2_rx+0x1eb/0x2d0
[2.503945] [81742202] __usb_hcd_giveback_urb+0x72/0x120
[2.503945] [817423cf] usb_hcd_giveback_urb+0x3f/0x120
[2.503945] [81786ffa] uhci_giveback_urb+0xaa/0x290
[2.503945] [811d36d7] ? dma_pool_free+0xa7/0xd0
[2.503945] [81788fe3] uhci_scan_schedule+0x493/0xb20
[2.503945] [81789c9e] uhci_irq+0x9e/0x180
[2.503945] [81741546] usb_hcd_irq+0x26/0x40
[2.503945] [8110e46e] handle_irq_event_percpu+0x3e/0x1e0
[2.503945] [8110e64d] handle_irq_event+0x3d/0x60
[2.503945] [87f9] handle_fasteoi_irq+0x99/0x160
[2.503945] [810492c2] handle_irq+0x102/0x190
[2.503945] [810e493a] ? atomic_notifier_call_chain+0x3a/0x50
[2.503945] [81a7fbcb] do_IRQ+0x5b/0x100
[2.503945] [81a7dd6f] common_interrupt+0x6f/0x6f
[2.503945] EOI [810512ed] ? default_idle+0x1d/0x100
+
+ rxc = rxs-slots[rx_slot];
+
+ if (rxc-in_use !rxc-urb) {
+ rxc-urb = urb;
+ complete(rxc-done);
+ /* URB will be resubmitted in free_rx_slot */
+ } else {
+ dev_warn(dev, bad/late response %d/%d\n, handle, rx_slot);
+ dln2_submit_urb(dln2, urb, GFP_ATOMIC);
+ }
+
+ spin_unlock(rxs-lock);
+}
+static int _dln2_transfer(struct dln2_dev *dln2, u16 handle, u16 cmd,
+ const void *obuf, unsigned obuf_len,
+ void *ibuf, unsigned *ibuf_len)
+{
+ int ret = 0;
+ u16 result;
+ int rx_slot;
+ struct dln2_response *rsp;
+ struct dln2_rx_context *rxc;
+ struct device *dev;
+ const int timeout = DLN2_USB_TIMEOUT * HZ / 1000;
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+
+ spin_lock(dln2-disconnect_lock);
How did you test this version? You never initialise disconnect_lock so
lockdep complains loudly when calling _dln2_transfer during probe.
Oops, missed that as lockdep was not enable in the lastest test setup.
+ if (!dln2-disconnect)
+ dln2-active_transfers++;
+ else
+ ret = -ENODEV;
+ spin_unlock(dln2-disconnect_lock);
+
+ if (ret)
+ return ret;
+
+ rx_slot = alloc_rx_slot(dln2, handle);
+ if (rx_slot 0) {
+ ret = rx_slot;
+ goto out_decr;
+ }
+
+ dev = dln2-interface-dev;
+
+ ret = dln2_send_wait(dln2, handle, cmd, rx_slot, obuf, obuf_len);
+ if (ret 0) {
+ dev_err(dev, USB write failed: %d\n, ret);
+ goto out_free_rx_slot;
+ }
+
+ rxc = rxs-slots[rx_slot];
+
+ ret = wait_for_completion_interruptible_timeout(rxc-done, timeout);
+ if (ret = 0) {
+ if (!ret)
+ ret = -ETIMEDOUT;
+ goto out_free_rx_slot;
+ }
+
+ if (!rxc-urb) {
+ ret = -ENODEV;
+ goto out_free_rx_slot;
+ }
+
+ /* if we got here we know that the response header has been checked */
+ rsp = rxc-urb-transfer_buffer;
+
+ if (rsp-hdr.size sizeof(*rsp)) {
+ ret = -EPROTO;
+ goto out_free_rx_slot;
+ }
+
+ result = le16_to_cpu(rsp-result);
+ if (result) {
+ dev_dbg(dev, %d received response with error %d\n,
+ handle, result);
+ ret = -EREMOTEIO;
+ goto out_free_rx_slot;
+ }
+
+ if (!ibuf) {
+ ret = 0;
+ goto out_free_rx_slot;
+ }
+
+ if (*ibuf_len rsp-hdr.size - sizeof(*rsp))
+ *ibuf_len = rsp-hdr.size - sizeof(*rsp);
+
+ memcpy(ibuf, rsp + 1, *ibuf_len);
+
+out_free_rx_slot:
+ free_rx_slot(dln2, handle, rx_slot);
+out_decr:
+ spin_lock(dln2-disconnect_lock);
+ dln2-active_transfers--;
+ spin_unlock(dln2-disconnect_lock);
+ if (dln2-disconnect)
+ wake_up(dln2-disconnect_wq);
+
+ return ret;
+}
+static void dln2_disconnect(struct usb_interface *interface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(interface);
+ int i, j;
+
+ /* don't allow starting new transfers */
+
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Hi Roger, Should I resend this v2 version of the patch to sta...@vger.kernel.org which is suitable for v3.17 and which will require a very tiny adaptation? Or I should resend the first version of this patch which is suitable for 3.16 but might seems confusing a little sine I'm resend the outdated version. Thanks, Oussama On 10/08/2014 09:17 AM, Roger Quadros wrote: Hi Oussama, On 10/07/2014 02:02 PM, Oussama Ghorbel wrote: The USB OTG port does not work since v3.16 on omap platform. This is a regression introduced by the commit eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove). This because the call to pm_runtime_enable() function is moved after the call to devm_phy_create() function, which has side effect since later in the subsequent calls of devm_phy_create() there is a check with pm_runtime_enabled() to configure few things. Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com Acked-by: Roger Quadros rog...@ti.com Could you please send the patch to Cc: sta...@vger.kernel.org[3.16+] That way it will get into 3.16 onwards. Thanks. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter
On Wed, Oct 8, 2014 at 1:42 PM, Johan Hovold jo...@kernel.org wrote: On Thu, Sep 25, 2014 at 07:07:32PM +0300, Octavian Purdila wrote: diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 b/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 new file mode 100644 index 000..ad55af6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-busses-dln2 This is a nonstandard path that does not match the attribute path (or any other convention followed under ABI/). I suggest you rename it sysfs-class-i2c-adapter-dln2 @@ -0,0 +1,5 @@ +What:/sys/bus/i2c/devices/.../dln2_i2c_freq I think you should rename the attribute bus_frequency and name the attribute group dln2. That way the attribute will show up as .../device/dln2/bus_frequency Then the What: field should read What: /sys/class/i2c-adapter/device/dln2/bus_frequency +Date:September 2014 +Contact: Octavian Purdila octavian.purd...@intel.com +Description: + This attribute shows/sets the frequency (in Hz) of the I2C bus. I'd reword this Set the frequency Please also describe under what circumstances this may fail, that is, when setting a frequency less than or greater than the min or max frequencies reported by the device. Perhaps you should even consider exporting those two values? I noticed that a few other USB boards support this. Perhaps it is time to add these entries to the core i2c layer? In that case I think is better to remove the setting and update the drievr when the patches for the i2c layer are ready? -- 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: gadget: f_fs: add zombie mode
-Original Message- From: Mike Nazarewicz [mailto:m...@google.com] I don't really see that happening. For the gadget to start all descriptors need to be known. Functionfs will know the descriptors only once the user space daemon provides them. Therefore, with the current features (or even with addition of Robert's feature) there is no way to let the gadget start without having the daemon running. On Wed, Oct 08 2014, Krzysztof Opasiak k.opas...@samsung.com wrote: Well, to be honest we do some lazy daemon startup in gadgetd. The idea is to provide functionality quite similar to inet. So we have divided functionfs services into two parts: - Descriptors - provided in configuration file - function implementation - provided in binary Sure, and I'm not surprised to hear that has been implemented, but from kernel point of view, the daemon is there and running. Furthermore, such behaviour is possible with or without the zombie feature, and in fact kernel isn't able to prevent it, so it's immaterial to discussion of the zombie feature. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- -- 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: gadget: configfs: for_device attribute in configuration directory
Provide interface for setting for_device function designated in a
configuration for handling setup requests directed to device.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
Documentation/ABI/testing/configfs-usb-gadget | 4 +++
drivers/usb/gadget/configfs.c | 49 +++
2 files changed, 53 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget
b/Documentation/ABI/testing/configfs-usb-gadget
index 95a3658..7f193ce 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -39,6 +39,10 @@ Description:
bmAttributes- configuration characteristics
MaxPower- maximum power consumption from the bus
+ for_device - name of function to be used as the last
+ fallback when looking for setup request
+ handlers; the function must be one of
+ functions linked to this configuration
What: /config/usb-gadget/gadget/configs/config/strings
Date: Jun 2013
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index d25f9f3..357f887 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -444,6 +444,8 @@ static int config_usb_cfg_unlink(
list_for_each_entry(f, cfg-func_list, list) {
if (f-fi == fi) {
+ if (f == cfg-c.for_device)
+ cfg-c.for_device = NULL;
list_del(f-list);
usb_put_function(f);
mutex_unlock(gi-lock);
@@ -509,6 +511,51 @@ static ssize_t
gadget_config_desc_bmAttributes_store(struct config_usb_cfg *cfg,
return len;
}
+static ssize_t gadget_config_desc_for_device_show(struct config_usb_cfg *cfg,
+ char *page)
+{
+ return sprintf(page, %s\n, cfg-c.for_device ?
+ cfg-c.for_device-fi-group.cg_item.ci_name : );
+}
+
+static ssize_t gadget_config_desc_for_device_store(struct config_usb_cfg *cfg,
+ const char *page, size_t len)
+{
+ struct usb_composite_dev *cdev = cfg-c.cdev;
+ struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+ struct usb_function *f = NULL;
+ ssize_t ret = -EBUSY;
+ char *name;
+
+ name = kstrdup(page, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+ if (name[len - 1] == '\n')
+ name[len - 1] = '\0';
+
+ mutex_lock(gi-lock);
+ if (gi-udc_name)
+ goto out;
+
+ if (!len || !*page || *page == '\n')
+ goto set_ret;
+
+ list_for_each_entry(f, cfg-func_list, list)
+ if (!strncmp(f-fi-group.cg_item.ci_name, name, len))
+ break;
+ if (f-list == cfg-func_list) {
+ ret = -EINVAL;
+ goto out;
+ }
+set_ret:
+ ret = len;
+ cfg-c.for_device = f;
+out:
+ mutex_unlock(gi-lock);
+ kfree(name);
+ return ret;
+}
+
#define CFG_CONFIG_DESC_ITEM_ATTR(name)\
static struct config_usb_cfg_attribute gadget_usb_cfg_##name = \
__CONFIGFS_ATTR(name, S_IRUGO | S_IWUSR, \
@@ -517,10 +564,12 @@ static ssize_t
gadget_config_desc_bmAttributes_store(struct config_usb_cfg *cfg,
CFG_CONFIG_DESC_ITEM_ATTR(MaxPower);
CFG_CONFIG_DESC_ITEM_ATTR(bmAttributes);
+CFG_CONFIG_DESC_ITEM_ATTR(for_device);
static struct configfs_attribute *gadget_config_attrs[] = {
gadget_usb_cfg_MaxPower.attr,
gadget_usb_cfg_bmAttributes.attr,
+ gadget_usb_cfg_for_device.attr,
NULL,
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] Handling per-device setup requests
There are some hosts (e.g. with a popular, proprietary operating system), which issue setup requests directed at a device even though they mean setup requests directed at a particular interface (usb function). This series adds optional for_device attribute in struct usb_configuration. If the attribute is non-NULL, the USB function it points to is used as the last fallback when searching for handlers in composite_setup(). If the attribute is NULL, then the composite_setup() behaviour remains unchanged. The second patch adds a method to get/set the function to be used as for_device in a configfs-composed gadget. Since Felipe closed his tree for 3.18 this is meant for 3.19. v1..v2: - added ABI documentation entry - removed unnecessary line removal Andrzej Pietrasiewicz (2): usb: gadget: composite: optional handling of per-device requests usb: gadget: configfs: for_device attribute in configuration directory Documentation/ABI/testing/configfs-usb-gadget | 4 +++ drivers/usb/gadget/composite.c| 16 + drivers/usb/gadget/configfs.c | 49 +++ include/linux/usb/composite.h | 1 + 4 files changed, 64 insertions(+), 6 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] usb: gadget: composite: optional handling of per-device requests
Some not-so-well-behaving USB hosts with a popular proprietary operating
system sometimes issue per-device requests even though they mean requests
for a particular function, e.g. for ptp (picture transfer protocol).
This patch adds optional for_device function in usb_configuration so that
it can be used as the last fallback when handling unknown requests. If it
is not set then the composite_setup() behaviour remains unchanged.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/usb/gadget/composite.c | 16 ++--
include/linux/usb/composite.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6178353..32b0104 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1785,12 +1785,16 @@ unknown:
}
/* try the only function in the current config */
- if (!list_is_singular(c-functions))
- goto done;
- f = list_first_entry(c-functions, struct usb_function,
-list);
- if (f-setup)
- value = f-setup(f, ctrl);
+ if (list_is_singular(c-functions)) {
+ f = list_first_entry(c-functions,
+struct usb_function, list);
+ if (f-setup)
+ value = f-setup(f, ctrl);
+ } else {
+ f = c-for_device;
+ if (f f-setup)
+ value = f-setup(f, ctrl);
+ }
}
goto done;
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 3d87def..080aaa2 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -313,6 +313,7 @@ struct usb_configuration {
unsignedhighspeed:1;
unsignedfullspeed:1;
struct usb_function *interface[MAX_CONFIG_INTERFACES];
+ struct usb_function *for_device;
};
int usb_add_config(struct usb_composite_dev *,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Oussama, On 10/08/2014 01:54 PM, Oussama Ghorbel wrote: Hi Roger, Should I resend this v2 version of the patch to sta...@vger.kernel.org which is suitable for v3.17 and which will require a very tiny adaptation? Or I should resend the first version of this patch which is suitable for 3.16 but might seems confusing a little sine I'm resend the outdated version. If it is a trivial conflict then I think you can just send the patch which applies to the most recent kernel. Greg can clarify if I'm wrong as he maintains the stable trees. cheers, -roger Thanks, Oussama On 10/08/2014 09:17 AM, Roger Quadros wrote: Hi Oussama, On 10/07/2014 02:02 PM, Oussama Ghorbel wrote: The USB OTG port does not work since v3.16 on omap platform. This is a regression introduced by the commit eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove). This because the call to pm_runtime_enable() function is moved after the call to devm_phy_create() function, which has side effect since later in the subsequent calls of devm_phy_create() there is a check with pm_runtime_enabled() to configure few things. Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com Acked-by: Roger Quadros rog...@ti.com Could you please send the patch to Cc: sta...@vger.kernel.org[3.16+] That way it will get into 3.16 onwards. Thanks. cheers, -roger -- 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: ffs: fix regression when quirk_ep_out_aligned_size flag is set
On Tue, Oct 07 2014, David Cohen david.a.co...@linux.intel.com wrote:
The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
quirk implemented to align buffer size to maxpacketsize on out endpoint.
As result, functionfs does not work on Intel platforms using dwc3 driver
(i.e. Bay Trail and Merrifield). This patch fixes the issue.
This code is based on a previous Qiuxu's patch.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Signed-off-by: Qiuxu Zhuo qiuxu.z...@intel.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
Hi,
Since this is a feature that worked in past, this patch is meant for 3.17
kernel. If/when we pass review and accept it on 3.17, I'll send a version for
stable 3.16 kernel too. It is not required for 3.14, since the regression came
later.
Br, David Cohen
---
drivers/usb/gadget/function/f_fs.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 0dc3552d1360..6e2b8063b170 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -648,15 +648,26 @@ static void ffs_user_copy_worker(struct work_struct
*work)
if (io_data-read ret 0) {
int i;
size_t pos = 0;
+
+ /*
+ * Since req-length may be bigger than io_data-len (after
+ * being rounded up to maxpacketsize), we may end up with more
+ * data then user space has space for.
+ */
+ ret = min_t(int, ret, io_data-len);
+
use_mm(io_data-mm);
for (i = 0; i io_data-nr_segs; i++) {
+ size_t len = min_t(size_t, ret - pos,
+ io_data-iovec[i].iov_len);
+ if (!len)
+ break;
if (unlikely(copy_to_user(io_data-iovec[i].iov_base,
- io_data-buf[pos],
- io_data-iovec[i].iov_len))) {
+ io_data-buf[pos], len))) {
ret = -EFAULT;
break;
}
- pos += io_data-iovec[i].iov_len;
+ pos += len;
}
unuse_mm(io_data-mm);
}
@@ -794,7 +805,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
goto error_lock;
req-buf = data;
- req-length = io_data-len;
+ req-length = data_len;
io_data-buf = data;
io_data-ep = ep-ep;
@@ -816,7 +827,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
req = ep-req;
req-buf = data;
- req-length = io_data-len;
+ req-length = data_len;
req-context = done;
req-complete = ffs_epfile_io_complete;
--
2.1.0
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices
On Wed, Oct 08, 2014 at 01:54:07PM +0300, Octavian Purdila wrote:
On Wed, Oct 8, 2014 at 12:23 PM, Johan Hovold jo...@kernel.org wrote:
On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
+static void dln2_rx_transfer(struct dln2_dev *dln2, struct urb *urb,
+ u16 handle, u16 rx_slot)
+{
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+ struct dln2_rx_context *rxc;
+ struct device *dev = dln2-interface-dev;
+
+ spin_lock(rxs-lock);
You must use spin_lock_irqsave here as you call it from the completion
handler.
Why? AFAICS the completion handler gets called from the HCD irq handler:
The completion handler is currently called with local interrupts
disabled but that is about to change once all drivers have been updated:
http://marc.info/?l=linux-usbm=137353360511003w=2
In this case you could probably get away with not disabling interrupts
anyway, but using the irqsave versions would make it obvious.
+static void dln2_disconnect(struct usb_interface *interface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(interface);
+ int i, j;
+
+ /* don't allow starting new transfers */
+ spin_lock(dln2-disconnect_lock);
+ dln2-disconnect = true;
+ spin_unlock(dln2-disconnect_lock);
+
+ /* cancel in progress transfers */
+ for (i = 0; i DLN2_HANDLES; i++) {
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[i];
+ unsigned long flags;
+
+ spin_lock_irqsave(rxs-lock, flags);
Just stick to spin_lock in this function.
AFAICS disconnect is called from a kernel thread. Are there guarantees
that we can't get a call to the completion routine while we are
running it?
Brain fart, nevermind.
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices
On Wed, Oct 8, 2014 at 3:04 PM, Johan Hovold jo...@kernel.org wrote:
On Wed, Oct 08, 2014 at 01:54:07PM +0300, Octavian Purdila wrote:
On Wed, Oct 8, 2014 at 12:23 PM, Johan Hovold jo...@kernel.org wrote:
On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
+static void dln2_rx_transfer(struct dln2_dev *dln2, struct urb *urb,
+ u16 handle, u16 rx_slot)
+{
+ struct dln2_mod_rx_slots *rxs = dln2-mod_rx_slots[handle];
+ struct dln2_rx_context *rxc;
+ struct device *dev = dln2-interface-dev;
+
+ spin_lock(rxs-lock);
You must use spin_lock_irqsave here as you call it from the completion
handler.
Why? AFAICS the completion handler gets called from the HCD irq handler:
The completion handler is currently called with local interrupts
disabled but that is about to change once all drivers have been updated:
http://marc.info/?l=linux-usbm=137353360511003w=2
In this case you could probably get away with not disabling interrupts
anyway, but using the irqsave versions would make it obvious.
I was not assuming that interrupts are disabled while running the
completion handler. Since that spinlock is not touched by any other
interrupt context code I don't think irqsave is necessary.
--
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: btusb_intr_complete returns -EPIPE
Do you see the problem with single devices? If I connect only one device to system then I did not see this issue. Usually I will use 8 devices(all with the same firmware) for testing. I tried different method to get some clue. First I disconnected all the devices and rebooted the system and later connected only one device and observed hci0 related debug print statements in the kernel log. Waited for 16mins idle, but did not get –EPIPE. Oct 8 16:41:46 banunxcas29 kernel: [ 488.018751] usb 1-1.5.1.7: new full speed USB device number 13 using ehci_hcd Oct 8 16:41:46 banunxcas29 kernel: [ 488.093487] usb 1-1.5.1.7: New USB device found, idVendor=0451, idProduct=2036 Oct 8 16:41:46 banunxcas29 kernel: [ 488.093494] usb 1-1.5.1.7: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Oct 8 16:41:46 banunxcas29 kernel: [ 488.093499] usb 1-1.5.1.7: Product: General Purpose USB Hub Oct 8 16:41:46 banunxcas29 kernel: [ 488.094581] hub 1-1.5.1.7:1.0: USB hub found Oct 8 16:41:46 banunxcas29 kernel: [ 488.094811] hub 1-1.5.1.7:1.0: 2 ports detected Oct 8 16:41:46 banunxcas29 kernel: [ 488.261141] usb 1-1.5.2: new full speed USB device number 14 using ehci_hcd Oct 8 16:41:46 banunxcas29 kernel: [ 488.323983] usb 1-1.5.2: device descriptor read/64, error -32 Oct 8 16:41:47 banunxcas29 kernel: [ 488.518202] usb 1-1.5.2: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 16:41:47 banunxcas29 kernel: [ 488.518208] usb 1-1.5.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551389] Bluetooth: Core ver 2.16 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551402] NET: Registered protocol family 31 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551404] Bluetooth: HCI device and connection manager initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551406] Bluetooth: HCI socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551408] Bluetooth: L2CAP socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551411] Bluetooth: SCO socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.565663] Bluetooth: Generic Bluetooth USB driver ver 0.6 Oct 8 16:41:47 banunxcas29 kernel: [ 488.565693] intf 880128640800 id a0197f00 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580231] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580236] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580258] intf 880128641000 id a0197f00 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580296] usbcore: registered new interface driver btusb Oct 8 16:41:47 banunxcas29 kernel: [ 488.580480] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580486] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580503] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.581314] hci0 urb 880131dbe3c0 status 0 count 6 Later connected one more device to system and noticed hci1 related debug print statements in the kernel log. Waited for 20mins idle and now also not received –EPIPE. Oct 8 16:57:44 banunxcas29 kernel: [ 1443.815276] usb 1-1.5.3: new full speed USB device number 17 using ehci_hcd Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400987] usb 1-1.5.3: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400993] usb 1-1.5.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403218] intf 880124c45800 id a0197f00 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403360] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403364] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403500] intf 880124c44c00 id a0197f00 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403511] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403515] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403529] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.404872] hci1 urb 880129162840 status 0 count 6 Later connected third device(hci2) and after 2mins observed –EPIPE for hci2(hci2 urb 880124f11cc0 status -32 count 0) Oct 8 17:18:21 banunxcas29 kernel: [ 2677.069853] usb 1-1.5.4: new full speed USB device number 18 using ehci_hcd Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681729] usb 1-1.5.4: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681735] usb 1-1.5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683689] intf 880119c3b400 id a0197f00 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683886] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683889] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684083] intf 880119c3a800 id a0197f00 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684161] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684166] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684184] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.685364] hci2 urb 880124f11cc0 status 0
Re: [PATCHv2 1/2] usb: gadget: composite: optional handling of per-device requests
Hi,
On Wed, Oct 08, 2014 at 01:32:31PM +0200, Andrzej Pietrasiewicz wrote:
Some not-so-well-behaving USB hosts with a popular proprietary operating
system sometimes issue per-device requests even though they mean requests
for a particular function, e.g. for ptp (picture transfer protocol).
which request would that be ?
This patch adds optional for_device function in usb_configuration so that
it can be used as the last fallback when handling unknown requests. If it
is not set then the composite_setup() behaviour remains unchanged.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/usb/gadget/composite.c | 16 ++--
include/linux/usb/composite.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6178353..32b0104 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1785,12 +1785,16 @@ unknown:
}
/* try the only function in the current config */
- if (!list_is_singular(c-functions))
- goto done;
- f = list_first_entry(c-functions, struct usb_function,
- list);
- if (f-setup)
- value = f-setup(f, ctrl);
+ if (list_is_singular(c-functions)) {
+ f = list_first_entry(c-functions,
+ struct usb_function, list);
+ if (f-setup)
+ value = f-setup(f, ctrl);
+ } else {
+ f = c-for_device;
+ if (f f-setup)
+ value = f-setup(f, ctrl);
+ }
instead, why don't you just list_for_each_entry() here ?
--
balbi
signature.asc
Description: Digital signature
Re: btusb_intr_complete returns -EPIPE
On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote: Later connected third device(hci2) and after 2mins observed –EPIPE for hci2(hci2 urb 880124f11cc0 status -32 count 0) This points to a problem in the USB HC driver. Can you enable debugging in that driver. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
On Wed, Oct 08, 2014 at 02:42:56PM +0300, Roger Quadros wrote: Oussama, On 10/08/2014 01:54 PM, Oussama Ghorbel wrote: Hi Roger, Should I resend this v2 version of the patch to sta...@vger.kernel.org which is suitable for v3.17 and which will require a very tiny adaptation? Or I should resend the first version of this patch which is suitable for 3.16 but might seems confusing a little sine I'm resend the outdated version. If it is a trivial conflict then I think you can just send the patch which applies to the most recent kernel. Greg can clarify if I'm wrong as he maintains the stable trees. Please read Documentation/stable_kernel_rules.txt for how to submit patches to the stable trees. Note, it has to be in Linus's tree _first_ before you ever worry about the stable trees. Do that first please. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Nothing to send then. Oussama On 10/08/2014 02:26 PM, Greg KH wrote: On Wed, Oct 08, 2014 at 02:42:56PM +0300, Roger Quadros wrote: Oussama, On 10/08/2014 01:54 PM, Oussama Ghorbel wrote: Hi Roger, Should I resend this v2 version of the patch to sta...@vger.kernel.org which is suitable for v3.17 and which will require a very tiny adaptation? Or I should resend the first version of this patch which is suitable for 3.16 but might seems confusing a little sine I'm resend the outdated version. If it is a trivial conflict then I think you can just send the patch which applies to the most recent kernel. Greg can clarify if I'm wrong as he maintains the stable trees. Please read Documentation/stable_kernel_rules.txt for how to submit patches to the stable trees. Note, it has to be in Linus's tree _first_ before you ever worry about the stable trees. Do that first please. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci_hcd can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)
On 10/07/2014 06:07 PM, Alan Stern wrote:
On Mon, 6 Oct 2014, Dmitry Nezhevenko wrote:
What does the debugging log show if you don't disable wakeup?
$It looks like same, but later it resumes once again.
[ 2836.134277] hub 2-0:1.0: state 7 ports 6 chg evt
[ 2836.134340] hub 2-0:1.0: hub_suspend
[ 2836.134346] usb usb2: bus auto-suspend, wakeup 1
[ 2838.797692] usb 1-12: usb auto-suspend, wakeup 0
[ 2839.237510] usb 1-5: usb auto-suspend, wakeup 0
[ 2839.405473] usb 1-7: usb auto-suspend, wakeup 0
[ 2839.421487] hub 1-0:1.0: hub_suspend
[ 2839.421497] usb usb1: bus auto-suspend, wakeup 1
[ 2839.421586] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: 0
[ 2839.421622] xhci_hcd :00:14.0: PME# enabled
[ 2839.453479] xhci_hcd :00:14.0: power state changed by ACPI to D3cold
[ 2854.647991] xhci_hcd :00:14.0: power state changed by ACPI to D0
[ 2854.751914] xhci_hcd :00:14.0: PME# disabled
[ 2854.751928] xhci_hcd :00:14.0: enabling bus mastering
[ 2854.751989] xhci_hcd :00:14.0: hcd_pci_runtime_resume: 0
[ 2854.751994] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: -16
[ 2854.752017] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x40
[usbcore] returns -16
[ 2854.752019] usb usb1: usb wakeup-resume
[ 2854.752026] usb usb1: usb auto-resume
[ 2854.752056] hub 1-0:1.0: hub_resume
[ 2854.752095] usb usb1-port5: status 0107 change
[ 2854.752107] usb usb1-port7: status 0107 change
[ 2854.752125] usb usb1-port12: status 0507 change
[ 2854.855937] hub 1-0:1.0: state 7 ports 15 chg evt
[ 2854.855951] hub 1-0:1.0: hub_suspend
[ 2854.855966] usb usb1: bus auto-suspend, wakeup 1
[ 2854.856002] usb usb1: suspend raced with wakeup event
That's the difference. It appears to be caused by a bug in xhci-hcd.
Does the patch below fix the problem?
Alan Stern
Index: usb-3.17/drivers/usb/host/xhci-hub.c
===
--- usb-3.17.orig/drivers/usb/host/xhci-hub.c
+++ usb-3.17/drivers/usb/host/xhci-hub.c
@@ -1136,13 +1136,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, bus_state-bus_suspended);
}
- /* USB core sets remote wake mask for USB 3.0 hubs,
- * including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
- * is enabled, so also enable remote wake here.
+ /* USB core sets remote wake mask for USB 3.0 hubs but
+ * not for USB 2.0 hubs (and only if CONFIG_PM_RUNTIME
+ * is enabled), so enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
- device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
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
Hi
The device_may_wakeup() check was recently added in patch:
commit ff8cbf250b448aac35589f6075082c3fcad8a8fe
xhci: clear root port wake on bits if controller isn't wake-up capable
http://marc.info/?l=linux-usbm=140261803101225w=2
Seems it caused some unexpected issues.
Is there some way to fix both cases before ending up reverting that patch?
Any idea why hcd_bus_suspend() doesn't see the suspend race when calling
hcd-driver-hub_status_data() in any case?
Are the wake-on [dis]connect bits somehow tied to connect status change bits?
When hcd_bus_suspend() checks for the suspend race condition it checks all xhci
status change bits.
Shouldn't those indicate a connect change and prevent the second suspend?
Or maybe we should check for those bits resume as well?
Baolu, do you still have the hardware that caused spurious wakeups? do we know
in detail what caused the wakeup?
-Mathias
--
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: btusb_intr_complete returns -EPIPE
This points to a problem in the USB HC driver. Can you enable debugging in that driver. Is it enabling dynamic debugging? Could you please point me the steps to enable debugging in USB HC driver? Thanks, Naveen On Wed, Oct 8, 2014 at 6:47 PM, Oliver Neukum oneu...@suse.de wrote: On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote: Later connected third device(hci2) and after 2mins observed –EPIPE for hci2(hci2 urb 880124f11cc0 status -32 count 0) This points to a problem in the USB HC driver. Can you enable debugging in that driver. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btusb_intr_complete returns -EPIPE
On Wed, 8 Oct 2014, Oliver Neukum wrote: On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote: Later connected third device(hci2) and after 2mins observed –EPIPE for hci2(hci2 urb 880124f11cc0 status -32 count 0) This points to a problem in the USB HC driver. Can you enable debugging in that driver. It could also be a bug in the hub that the BT devices are plugged into. I have seen a report of a hub that sends STALL when a bunch of devices are plugged in, even though the devices themselves did not send a STALL. 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: fat32-vfat differences?
On Tue, 7 Oct 2014, Gene Heskett wrote: I have some update firmware on a vfat key. While that system reports the key as being plugged in when I do the insertion, when I ask its update facility to do an update, the sandisks led blinks a time or 2 reports it can't find the update. Have you tried mounting the VFAT filesystem and getting a file listing to see what's there? How about running dosfsck on the filesystem's partition? I tried to mountr it as fat32, but linux says it has no knowledge of fat32, yet the target system is expecting fat32 only. FAT32 support is part of the regular FAT support. If your kernel understands FAT filesystems at all then it understands FAT32. Is this something I can fix with a fresh usb key? Probably not. In fact, this probably has nothing to do with USB at all. 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: gadget: f_fs: add zombie mode
On Tue, 7 Oct 2014, Michal Nazarewicz wrote: On Tue, 7 Oct 2014, Felipe Balbi wrote: Right, but if we allow this, I can already see folks abusing to connect to the host early and only when necessary do some trickery to e.g. start adbd (not saying Android will do this, just using it as an easy example). I don't really see that happening. For the gadget to start all descriptors need to be known. Functionfs will know the descriptors only once the user space daemon provides them. Therefore, with the current features (or even with addition of Robert's feature) there is no way to let the gadget start without having the daemon running. On Tue, Oct 07 2014, Alan Stern st...@rowland.harvard.edu wrote: We can still keep the pullup turned off until all the functions are ready. That's a part of normal behavior -- unlike what happens when a userspace component crashes or is killed. Then how do we differentiate a normal close() from a oh-crap-I-died close() ? We can't, so why worry about it? We actually might be able to distinguish those cases with another ioctl which daemon must issue on the ep0 prior to closing it. I'm not saying that we should implement that though. If a file handle was closed for normal reasons then userspace probably in the middle of shutting down the gadget anyway. If not then the user will get what they deserve. If the file handle was closed for abnormal reasons, we can behave like crashed firmware. Which means, in the end, doing the same thing as in the normal-reason case -- i.e., do nothing. In particular, don't disconnect. If you want to allow for the possibility of orderly shutdown (and maybe even possible restart) of a userspace handler, the function library should first tell the kernel explicitly to disconnect. Then function components can be changed around completely, and when everything is ready, userspace can tell the kernel to connect again. I'm wondering if it would be possible to support user-space daemon restarts with O_APPEND flag. This is probably looking too far to the future though. Actually, we shouldn't need to consider the case where the descriptors change. That _always_ requires a disconnect, and the user can cause a disconnect simply by killing the daemon and starting it again. No separate restart capability is needed. 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: xhci_hcd can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)
On Wed, 8 Oct 2014, Mathias Nyman wrote:
Index: usb-3.17/drivers/usb/host/xhci-hub.c
===
--- usb-3.17.orig/drivers/usb/host/xhci-hub.c
+++ usb-3.17/drivers/usb/host/xhci-hub.c
@@ -1136,13 +1136,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, bus_state-bus_suspended);
}
- /* USB core sets remote wake mask for USB 3.0 hubs,
-* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
-* is enabled, so also enable remote wake here.
+ /* USB core sets remote wake mask for USB 3.0 hubs but
+* not for USB 2.0 hubs (and only if CONFIG_PM_RUNTIME
+* is enabled), so enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
-device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
Hi
The device_may_wakeup() check was recently added in patch:
commit ff8cbf250b448aac35589f6075082c3fcad8a8fe
xhci: clear root port wake on bits if controller isn't wake-up capable
The description of that commit doesn't agree with the title. The
description says that some platforms get spurious wakeups, so the
wake-on bits should be cleared if do_wakeup is false. It says nothing
about the controller not being wakeup-capable.
Also, the commit description says:
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits...
This makes no sense, because xhci_bus_suspend() is not called from
xhci_pci_suspend(). They are two completely separate pathways.
http://marc.info/?l=linux-usbm=140261803101225w=2
Seems it caused some unexpected issues.
Evidently the commit was meant to fix a problem with system suspend,
and the author totally failed to realize that the code it touched also
gets used for runtime suspend.
Is there some way to fix both cases before ending up reverting that patch?
The commit altered the wrong routine. If the controller isn't allowed
to wake up then the port wake-on bits should be cleared in
xhci_suspend(), not in xhci_bus_suspend(). In fact, it would be a good
idea to check in xhci_suspend() for a wakeup-in-progress as well.
Unfortunately, the curent code doesn't tell xhci_suspend() whether
wakeup should be enabled. This can easily be fixed;
xhci_pci_suspend() should pass its do_wakeup argument on to
xhci_suspend().
Any idea why hcd_bus_suspend() doesn't see the suspend race when calling
hcd-driver-hub_status_data() in any case?
I don't really understand what went wrong on Dmitry's system, or why
enabling the wake-on bits should make a difference. I merely noticed
that xhci_bus_suspend() was doing the wrong thing, and it seemed like
it might be related to the bug.
Are the wake-on [dis]connect bits somehow tied to connect status change bits?
I assume they are. Only the hardware designers know for sure. :-)
When hcd_bus_suspend() checks for the suspend race condition it checks all
xhci status change bits.
Shouldn't those indicate a connect change and prevent the second suspend?
Or maybe we should check for those bits resume as well?
Suspect something rather subtle must be going on.
xhci_hub_status_data() tests for resume-in-progress by checking
bus_state-resuming_ports. That variable gets set by
handle_port_status() in response to a Port Status Change Event TRB.
Maybe under some circumstances the controller doesn't generate those
events unless the corresponding wake-on bit is set; I don't know.
What actually happened on Dmitry's system is a little strange. When he
plugged in the device there was a wakeup request, and the
port-connect-status-change bit was set. But the port-connect-status
bit was _not_ set, even after a 100 ms delay, so the system tried to
suspend the root hub again. Without my patch, resuming_ports wasn't
set, and so the suspend succeeded and the connection ended up getting
lost. With my patch, resuming_ports was set, and so the suspend was
aborted and the connection was eventually detected.
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: xhci_hcd can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)
On Wed, 8 Oct 2014, Alan Stern wrote:
What actually happened on Dmitry's system is a little strange. When he
plugged in the device there was a wakeup request, and the
port-connect-status-change bit was set. But the port-connect-status
bit was _not_ set, even after a 100 ms delay, so the system tried to
suspend the root hub again. Without my patch, resuming_ports wasn't
set, and so the suspend succeeded and the connection ended up getting
lost. With my patch, resuming_ports was set, and so the suspend was
aborted and the connection was eventually detected.
Dmitry, this gave me another idea. Can you test the patch below,
_without_ the previous patch? And post the corresponding usbmon trace
and dmesg log?
Alan Stern
Index: usb-3.17/drivers/usb/core/hub.c
===
--- usb-3.17.orig/drivers/usb/core/hub.c
+++ usb-3.17/drivers/usb/core/hub.c
@@ -1171,7 +1171,8 @@ static void hub_activate(struct usb_hub
* check for a new connection
*/
if (udev || (portstatus USB_PORT_STAT_CONNECTION) ||
- (portstatus USB_PORT_STAT_OVERCURRENT))
+ (portstatus USB_PORT_STAT_OVERCURRENT) ||
+ (portchange USB_PORT_STAT_C_CONNECTION))
set_bit(port1, hub-change_bits);
} else if (portstatus USB_PORT_STAT_ENABLE) {
--
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
BUG (maybe) with find_get_entry()
Hi, With today's linus/master and with greg/usb-next I keep getting random kernel oops from find_get_entry() (see below): [ 47.700065] Unable to handle kernel paging request at virtual address [ 47.707667] pgd = c0004000 [ 47.710506] [] *pgd=ae7f6821, *pte=, *ppte= [ 47.717135] Internal error: Oops: 17 [#1] SMP ARM [ 47.722047] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs xhci_plat_hcd xhci_hcd snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap snd_soc_evm snd_soc_tlv320aic3x dwc3 snd_soc_core snd_compress omapdrm snd_pcm_dmaengine snd_pcm snd_timer snd fb_sys_fops lis3lv02d_i2c panel_dpi matrix_keypad lis3lv02d dwc3_omap input_polldev soundcore [ 47.755668] CPU: 0 PID: 1440 Comm: file-storage Not tainted 3.17.0-02899-ga7d2165 #229 [ 47.763958] task: ed1b22c0 ti: ed20e000 task.ti: ed20e000 [ 47.769609] PC is at find_get_entry+0x64/0x100 [ 47.774281] LR is at 0xfffa [ 47.777590] pc : [c01065b4]lr : [fffa]psr: a00f0013 [ 47.777590] sp : ed20fc80 ip : fp : ed20fcb4 [ 47.789564] r10: 600f0013 r9 : c014c854 r8 : 0004 [ 47.795031] r7 : ec1909b8 r6 : 0001 r5 : r4 : ec190880 [ 47.801837] r3 : ed20fc6c r2 : r1 : 0004 r0 : [ 47.808640] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 47.816251] Control: 10c5387d Table: ad768059 DAC: 0015 [ 47.822237] Process file-storage (pid: 1440, stack limit = 0xed20e248) [ 47.829034] Stack: (0xed20fc80 to 0xed21) [ 47.833585] fc80: c0106550 ed20fcf8 ec190880 ec1909b4 0004 [ 47.842119] fca0: 0004 ec19090c ed20fcd4 ed20fcb8 c010716c c010655c 00013ef0 ec190880 [ 47.850657] fcc0: 0002 ed20fd4c ed20fcd8 c011df94 c0107150 0006 ed1b22c0 [ 47.859183] fce0: c014c854 600f0013 ed20fd1c ed20fcf8 0002 ed20fd84 00d0 [ 47.867707] fd00: 4000 ec1909b4 0004 c011efd0 c0089b64 c00899dc [ 47.876241] fd20: ec190880 ec190880 0004 ec19090c c014c854 600f0013 [ 47.884761] fd40: ed20fdb4 ed20fd50 c011efd0 c011df08 000200da c014c854 bf2047f8 [ 47.893280] fd60: 0005 ed721e80 ed20fde0 ec1909b4 0002 ed1b22c0 ed20fdcc [ 47.901816] fd80: ed20fdb4 c0089a3c 4000 ed20fe80 ed721e80 ed1b22c0 [ 47.910340] fda0: 4000 ed20fe3c ed20fdb8 c014c854 c011eed4 4000 4000 [ 47.918866] fdc0: ed20fdf4 ec504000 4000 0002 4000 ed20fdc4 0001 [ 47.927387] fde0: ed721e80 ed1b22c0 [ 47.935922] fe00: 4000 4000 ec504000 ed721e80 [ 47.944452] fe20: ec504000 ed20fe80 ed73ec00 4000 ed20fe6c ed20fe40 c014d054 c014c7bc [ 47.952984] fe40: ed20fe6c ed20fe50 ed2769e0 ed2bf104 ed2bf000 ed73ec00 4000 [ 47.961505] fe60: ed20feb4 ed20fe70 bf2b57cc c014cfc8 3732333d ed20e000 4000 [ 47.970032] fe80: 4000 ed2bf000 ed2769c0 ed2bf038 ed2bf000 [ 47.978575] fea0: ed20e038 ed2bf07c ed20ff24 ed20feb8 bf2b6a08 bf2b56b8 0001 c00899dc [ 47.987100] fec0: a00f0013 ed401bd4 00052000 ed20fee0 c0089c50 c0089a70 [ 47.995631] fee0: ed20ff04 ed20fef0 c064f3a4 ed276840 ed2bf000 bf2b6244 ed276840 [ 48.004154] ff00: ed2bf000 bf2b6244 ed20ffac ed20ff28 [ 48.012683] ff20: c0065bdc bf2b6250 c0089c50 ed20ff54 ed2bf000 [ 48.021204] ff40: dead4ead c0a8a238 c08070f8 ed20ff5c [ 48.029735] ff60: ed20ff5c dead4ead c0a8a238 [ 48.038265] ff80: c08070f8 ed20ff88 ed20ff88 ed276840 c0065af8 [ 48.046785] ffa0: ed20ffb0 c000eea8 c0065b04 [ 48.055307] ffc0: [ 48.063837] ffe0: 0013 ebfe e89da830 [ 48.072389] [c01065b4] (find_get_entry) from [c010716c] (find_lock_entry+0x28/0x7c) [ 48.080753] [c010716c] (find_lock_entry) from [c011df94] (shmem_getpage_gfp+0x98/0x7f8) [ 48.089469] [c011df94] (shmem_getpage_gfp) from [c011efd0] (shmem_file_read_iter+0x108/0x3a0) [ 48.098731] [c011efd0] (shmem_file_read_iter) from [c014c854] (new_sync_read+0xa4/0xcc) [ 48.107435] [c014c854] (new_sync_read) from [c014d054] (vfs_read+0x98/0x158) [ 48.115189] [c014d054] (vfs_read) from [bf2b57cc] (do_read+0x120/0x2c8 [usb_f_mass_storage]) [ 48.124382] [bf2b57cc] (do_read [usb_f_mass_storage]) from [bf2b6a08] (fsg_main_thread+0x7c4/0x13f8 [usb_f_mass_storage]) [ 48.136199] [bf2b6a08] (fsg_main_thread [usb_f_mass_storage]) from [c0065bdc] (kthread+0xe4/0x100) [ 48.145919]
Multiple LUNs not detected with SCM USB-SCSI converter
Hi,
SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
MCDISK-D dual PCMCIA SCSI device in a Windows XP VM (with SCM driver
installed). Windows detected cards in both slots and added drive letters
for them.
With Linux however, only the lower slot (LUN 0) is detected. It seems the
us-max_lun field is zero for SCM converters.
SCM converters use the US_FL_SCM_MULT_TARG quirk. I first thought the
problem might be this code in usb_stor_scan_dwork():
/* For bulk-only devices, determine the max LUN value */
if (us-protocol == USB_PR_BULK !(us-fflags US_FL_SINGLE_LUN)) {
mutex_lock(us-dev_mutex);
us-max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(us-dev_mutex);
}
scsi_scan_host(us_to_host(us));
usb_stor_Bulk_max_lun() returns 0 for an SCM converter; with usb-storage
debugging enabled, I see this in the log:
GetMaxLUN command result is -32, data is 0
So us-max_lun gets set to 0 which is presumably why LUNs 0 are not
scanned. I tried changing the above code to
/* For bulk-only devices, determine the max LUN value */
if (us-protocol == USB_PR_BULK
!(us-fflags (US_FL_SINGLE_LUN | US_FL_SCM_MULT_TARG))) {
mutex_lock(us-dev_mutex);
...
But that change alone didn't seem to make any difference; with USB
debugging enabled I got this log output:
[ 205.823597] *** thread awakened
[ 205.823605] Command INQUIRY (6 bytes)
[ 205.823607] bytes:
[ 205.823608] 12 00 00 00 24 00
[ 205.823620] Bulk Command S 0x43425355 T 0x12 L 36 F 128 Trg 3 LUN 0 CL 6
[ 205.823622] xfer 31 bytes
[ 205.824455] Status code 0; transferred 31/31
[ 205.824459] -- transfer complete
[ 205.824462] Bulk command transfer result=0
[ 205.824466] xfer 36 bytes, 1 entries
[ 205.841459] Status code 0; transferred 36/36
[ 205.841463] -- transfer complete
[ 205.841466] Bulk data transfer result 0x0
[ 205.841469] Attempting to get CSW...
[ 205.841473] xfer 13 bytes
[ 205.843450] Status code 0; transferred 13/13
[ 205.843454] -- transfer complete
[ 205.843458] Bulk status result = 0
[ 205.843462] Bulk Status S 0x53425355 T 0x12 R 0 Stat 0x0
[ 205.843466] scsi cmd done, result=0x0
[ 205.843471] *** thread sleeping
[ 205.843521] scsi 7:0:3:0: Direct-Access MPL MC-DISK-D-1S[0] 3.3
PQ: 0 ANSI: 2
[ 205.843581] *** thread awakened
[ 205.843585] Bad LUN (3:1)
[ 205.843589] scsi cmd done, result=0x4
[ 205.843594] *** thread sleeping
[ 205.843654] *** thread awakened
[ 205.843657] Command INQUIRY (6 bytes)
[ 205.843659] bytes:
[ 205.843660] 12 00 00 00 24 00
[ 205.843666] Bulk Command S 0x43425355 T 0x13 L 36 F 128 Trg 4 LUN 0 CL 6
[ 205.843668] xfer 31 bytes
Note the Bad LUN message. That's produced by this code in
usb_stor_control_thread():
else if (us-srb-device-lun us-max_lun) {
usb_stor_dbg(us, Bad LUN (%d:%llu)\n,
us-srb-device-id,
us-srb-device-lun);
us-srb-result = DID_BAD_TARGET 16;
}
So at that point, us-max_lun must be zero. What is us-max_lun initially
set to?
usb_stor_probe1() calls get_transport() then get_protocol().
get_transport() looks like this:
/* Get the transport settings */
static void get_transport(struct us_data *us)
{
switch (us-protocol) {
case USB_PR_CB:
us-transport_name = Control/Bulk;
us-transport = usb_stor_CB_transport;
us-transport_reset = usb_stor_CB_reset;
us-max_lun = 7;
break;
case USB_PR_CBI:
us-transport_name = Control/Bulk/Interrupt;
us-transport = usb_stor_CB_transport;
us-transport_reset = usb_stor_CB_reset;
us-max_lun = 7;
break;
case USB_PR_BULK:
us-transport_name = Bulk;
us-transport = usb_stor_Bulk_transport;
us-transport_reset = usb_stor_Bulk_reset;
break;
}
}
us-max_lun isn't set to 7 in the USB_PR_BULK case. Should it be?
get_protocol() looks like this:
/* Get the protocol settings */
static void get_protocol(struct us_data *us)
{
switch (us-subclass) {
case USB_SC_RBC:
us-protocol_name = Reduced Block Commands (RBC);
us-proto_handler = usb_stor_transparent_scsi_command;
break;
case USB_SC_8020:
us-protocol_name = 8020i;
us-proto_handler = usb_stor_pad12_command;
us-max_lun = 0;
break;
case USB_SC_QIC:
us-protocol_name = QIC-157;
us-proto_handler = usb_stor_pad12_command;
us-max_lun = 0;
break;
case USB_SC_8070:
us-protocol_name
Re: RCU bug with v3.17-rc3 ?
Hi, On Fri, Sep 05, 2014 at 02:32:16PM -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 03:04:03PM -0500, Felipe Balbi wrote: Hi, On Thu, Sep 04, 2014 at 02:25:35PM -0500, Felipe Balbi wrote: On Thu, Sep 04, 2014 at 12:16:42PM -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote: Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: v3.17-rc3, correct? yup, as in subject ;-) I take it that the test passes on some earlier version? about to test v3.14.17. coudln't get v3.14 working on this board but at least v3.16 is also affected except that on now it happened during boot, I didn't even need to run my test: [ 17.438195] Unable to handle kernel paging request at virtual address [ 17.446109] pgd = ec36 [ 17.448947] [] *pgd=ae7f6821, *pte=, *ppte= [ 17.455639] Internal error: Oops: 17 [#1] SMP ARM [ 17.460578] Modules linked in: dwc3(+) udc_core lis3lv02d_i2c lis3lv02d input_polldev dwc3_omap matrix_keypad [ 17.471060] CPU: 0 PID: 1381 Comm: accounts-daemon Tainted: G W 3.16.0-5-g8a6cdb4 #811 [ 17.480735] task: ed716040 ti: ec026000 task.ti: ec026000 [ 17.486405] PC is at find_get_entry+0x7c/0x128 [ 17.491070] LR is at 0xfffa [ 17.494364] pc : [c0110b4c]lr : [fffa]psr: a013 [ 17.494364] sp : ec027dc8 ip : fp : ec027dfc [ 17.506384] r10: c0c6f6bc r9 : 0005 r8 : ecdf22f8 [ 17.511860] r7 : ec026008 r6 : 0001 r5 : r4 : [ 17.518705] r3 : ec027db4 r2 : r1 : 0005 r0 : [ 17.525526] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 17.533007] Control: 10c5387d Table: ac360059 DAC: 0015 [ 17.539020] Process accounts-daemon (pid: 1381, stack limit = 0xec026248) [ 17.546151] Stack: (0xec027dc8 to 0xec028000) [ 17.550710] 7dc0: c0110ad0 ecdf0b80 ecdf22f4 [ 17.559259] 7de0: ecdf22f4 0005 ec027e34 ec027e00 c0111874 c0110adc [ 17.567824] 7e00: ecdf0b80 c03565b4 ed7165f8 ec3dddf0 ecdf22f4 0005 ec3ddd00 0001 [ 17.576385] 7e20: ecdf21a0 ec027ebc ec027e38 c0112978 c0111844 c06af938 [ 17.584950] 7e40: ecdf0b70 ecdf0b70 ec027e6c ec027e58 0005 0006 0b80 ecdf0b70 [ 17.593514] 7e60: c0163264 ec3dddf0 ec027ee8 ec027ed4 0b80 ec027eac ec027e88 [ 17.602087] 7e80: c0178d98 c0356590 0002 5b80 ec027f78 [ 17.610653] 7ea0: ec3ddd00 ed716040 b6cab018 ec027f44 ec027ec0 c0163264 c0112780 [ 17.619202] 7ec0: 0180 0180 ec027efc b6cab018 0180 0180 [ 17.627772] 7ee0: ec027ecc 0001 ec3ddd00 ed716040 [ 17.636371] 7f00: 5b80 0180 [ 17.644946] 7f20: b6cab018 ec3ddd00 b6cab018 ec027f78 ec3ddd00 0180 ec027f74 ec027f48 [ 17.653524] 7f40: c0163a6c c01631cc b6cab018 5b80 ec3ddd03 ec3ddd00 [ 17.662085] 7f60: 0180 b6cab018 ec027fa4 ec027f78 c0164198 c01639e0 5b80 [ 17.670658] 7f80: be91badc be91ba50 00044a00 0003 c000f044 ec026000 ec027fa8 [ 17.679222] 7fa0: c000edc0 c0164158 be91badc be91ba50 0008 b6cab018 0180 be91ba38 [ 17.687794] 7fc0: be91badc be91ba50 00044a00 0003 be91bbac b6cab008 [ 17.696370] 7fe0: 0020 be91ba40 b6c78e8c b6c78ea8 6010 0008 ae7f6821 ae7f6c21 [ 17.704956] [c0110b4c] (find_get_entry) from [c0111874] (pagecache_get_page+0x3c/0x1f4) [ 17.713687] [c0111874] (pagecache_get_page) from [c0112978] (generic_file_read_iter+0x204/0x794) [ 17.723259] [c0112978] (generic_file_read_iter) from [c0163264] (new_sync_read+0xa4/0xcc) [ 17.732185] [c0163264] (new_sync_read) from [c0163a6c] (vfs_read+0x98/0x158) [ 17.739945] [c0163a6c] (vfs_read) from [c0164198] (SyS_read+0x4c/0xa0) [ 17.747149] [c0164198] (SyS_read) from [c000edc0] (ret_fast_syscall+0x0/0x48) [ 17.754994] Code: e1a01009 eb08ffa9 e350 0a1f (e5904000) [ 17.761476] ---[ end trace 49c4ed35a1c01157 ]--- It seems to be a difficult-to-reproduce race though. On a second boot it didn't die during boot, but died with my USB test case. Unfortunately, the platform I'm using is pretty new and only goes as far back as v3.16 (which I had to backport 11 patches to get it to boot good enough for this test). I wonder if a corrupt file system could cause such problems... I keep seeing EXT4 errors every now and again; considering that this dies in a path through VFS, I wonder... I recall hearing of similar
Re: [PATCH] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set
On Tue, Oct 07, 2014 at 07:31:44PM -0500, Felipe Balbi wrote: Hi, Hi Felipe, On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote: The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the did that commit non-aio or is only aio broken ? That commit broke the quirk on both cases. quirk implemented to align buffer size to maxpacketsize on out endpoint. As result, functionfs does not work on Intel platforms using dwc3 driver (i.e. Bay Trail and Merrifield). This patch fixes the issue. and Braswell. This code is based on a previous Qiuxu's patch. How have you tested this ? Do you have a test-case to share ? Then I can add it to my tests which I have been running on my platforms too (they include USB20CV and USB30CV where applicable - quite a few fixes coming soon). My testcase is to use Android's adbd service via function_fs (no out-of-tree android gadget). Without the quitk, it doesn't work. Br, David cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set
On Tue, Oct 07, 2014 at 07:32:56PM -0500, Felipe Balbi wrote: Hi again, On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote: The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the quirk implemented to align buffer size to maxpacketsize on out endpoint. As result, functionfs does not work on Intel platforms using dwc3 driver (i.e. Bay Trail and Merrifield). This patch fixes the issue. This code is based on a previous Qiuxu's patch. btw, please resend and add below right here: Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support) Cc: sta...@vger.kernel.org # v3.16+ Sure. But v3.16 doesn't have the new 'function' directory under usb/gadget. Not sure if same patch is useful for v3.16+. The patch I sent is intended for v3.17.1 and v3.18-rc1. Br, David Signed-off-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Qiuxu Zhuo qiuxu.z...@intel.com -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU bug with v3.17-rc3 ?
Hi,
On Wed, Oct 08, 2014 at 12:13:22PM -0500, Felipe Balbi wrote:
On Fri, Sep 05, 2014 at 02:32:16PM -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 03:04:03PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Sep 04, 2014 at 02:25:35PM -0500, Felipe Balbi wrote:
On Thu, Sep 04, 2014 at 12:16:42PM -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote:
Hi,
I keep triggering the following Oops with -rc3 when writing to the
mass
storage gadget driver:
v3.17-rc3, correct?
yup, as in subject ;-)
I take it that the test passes on some earlier version?
about to test v3.14.17.
coudln't get v3.14 working on this board but at least v3.16 is also
affected except that on now it happened during boot, I didn't even need
to run my test:
[ 17.438195] Unable to handle kernel paging request at virtual address
[ 17.446109] pgd = ec36
[ 17.448947] [] *pgd=ae7f6821, *pte=, *ppte=
[ 17.455639] Internal error: Oops: 17 [#1] SMP ARM
[ 17.460578] Modules linked in: dwc3(+) udc_core lis3lv02d_i2c
lis3lv02d input_polldev dwc3_omap matrix_keypad
[ 17.471060] CPU: 0 PID: 1381 Comm: accounts-daemon Tainted: G W
3.16.0-5-g8a6cdb4 #811
[ 17.480735] task: ed716040 ti: ec026000 task.ti: ec026000
[ 17.486405] PC is at find_get_entry+0x7c/0x128
[ 17.491070] LR is at 0xfffa
[ 17.494364] pc : [c0110b4c]lr : [fffa]psr: a013
[ 17.494364] sp : ec027dc8 ip : fp : ec027dfc
[ 17.506384] r10: c0c6f6bc r9 : 0005 r8 : ecdf22f8
[ 17.511860] r7 : ec026008 r6 : 0001 r5 : r4 :
[ 17.518705] r3 : ec027db4 r2 : r1 : 0005 r0 :
[ 17.525526] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 17.533007] Control: 10c5387d Table: ac360059 DAC: 0015
[ 17.539020] Process accounts-daemon (pid: 1381, stack limit =
0xec026248)
[ 17.546151] Stack: (0xec027dc8 to 0xec028000)
[ 17.550710] 7dc0: c0110ad0
ecdf0b80 ecdf22f4
[ 17.559259] 7de0: ecdf22f4 0005 ec027e34
ec027e00 c0111874 c0110adc
[ 17.567824] 7e00: ecdf0b80 c03565b4 ed7165f8 ec3dddf0 ecdf22f4
0005 ec3ddd00 0001
[ 17.576385] 7e20: ecdf21a0 ec027ebc ec027e38 c0112978
c0111844 c06af938
[ 17.584950] 7e40: ecdf0b70 ecdf0b70 ec027e6c ec027e58 0005
0006 0b80 ecdf0b70
[ 17.593514] 7e60: c0163264 ec3dddf0 ec027ee8 ec027ed4
0b80 ec027eac ec027e88
[ 17.602087] 7e80: c0178d98 c0356590 0002
5b80 ec027f78
[ 17.610653] 7ea0: ec3ddd00 ed716040 b6cab018 ec027f44
ec027ec0 c0163264 c0112780
[ 17.619202] 7ec0: 0180 0180 ec027efc b6cab018 0180
0180
[ 17.627772] 7ee0: ec027ecc 0001 ec3ddd00
ed716040
[ 17.636371] 7f00: 5b80 0180
[ 17.644946] 7f20: b6cab018 ec3ddd00 b6cab018 ec027f78 ec3ddd00
0180 ec027f74 ec027f48
[ 17.653524] 7f40: c0163a6c c01631cc b6cab018 5b80
ec3ddd03 ec3ddd00
[ 17.662085] 7f60: 0180 b6cab018 ec027fa4 ec027f78 c0164198
c01639e0 5b80
[ 17.670658] 7f80: be91badc be91ba50 00044a00 0003 c000f044
ec026000 ec027fa8
[ 17.679222] 7fa0: c000edc0 c0164158 be91badc be91ba50 0008
b6cab018 0180 be91ba38
[ 17.687794] 7fc0: be91badc be91ba50 00044a00 0003 be91bbac
b6cab008
[ 17.696370] 7fe0: 0020 be91ba40 b6c78e8c b6c78ea8 6010
0008 ae7f6821 ae7f6c21
[ 17.704956] [c0110b4c] (find_get_entry) from [c0111874]
(pagecache_get_page+0x3c/0x1f4)
[ 17.713687] [c0111874] (pagecache_get_page) from [c0112978]
(generic_file_read_iter+0x204/0x794)
[ 17.723259] [c0112978] (generic_file_read_iter) from [c0163264]
(new_sync_read+0xa4/0xcc)
[ 17.732185] [c0163264] (new_sync_read) from [c0163a6c]
(vfs_read+0x98/0x158)
[ 17.739945] [c0163a6c] (vfs_read) from [c0164198]
(SyS_read+0x4c/0xa0)
[ 17.747149] [c0164198] (SyS_read) from [c000edc0]
(ret_fast_syscall+0x0/0x48)
[ 17.754994] Code: e1a01009 eb08ffa9 e350 0a1f (e5904000)
[ 17.761476] ---[ end trace 49c4ed35a1c01157 ]---
It seems to be a difficult-to-reproduce race though. On a second boot it
didn't die during boot, but died with my USB test case. Unfortunately,
the platform I'm using is pretty new and only goes as far back as v3.16
(which I had to backport 11 patches to get it to boot good enough for
this test).
I wonder if a corrupt file system
[PATCH v3 1/3] Add HS-USB device tree support for R8A7791/Koelsch/Henninger board
Hello. Here's the set of 3 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20141007-v3.17' tag. Here we add the HS-USB device tree support on the R8A7791/Koelsch/Henninger reference boards. The patchset requires the USB PHY driver (already merged by Kishon and Greg) and the generic PHY support patches for the HS-USB driver posted by Yoshihiro Shimoda in order to work... [1/3] ARM: shmobile: r8a7791: add HS-USB device node [2/3] ARM: shmobile: koelsch: enable HS-USB [3/3] ARM: shmobile: henninger: enable HS-USB WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: shmobile: r8a7791: add HS-USB device node
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Define the R8A7791 generic part of the HS-USB device node. It is up to the board
file to enable the device.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: fixed summary, added changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 2:
- uppercased arm in the summary;
- added changelog.
arch/arm/boot/dts/r8a7791.dtsi | 11 +++
1 file changed, 11 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -637,6 +637,17 @@
status = disabled;
};
+ hsusb: usb@e659 {
+ compatible = renesas,usbhs-r8a7791;
+ reg = 0 0xe659 0 0x100;
+ interrupts = 0 107 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp7_clks R8A7791_CLK_HSUSB;
+ renesas,buswait = 4;
+ phys = usb0 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
usbphy: usb-phy@e6590100 {
compatible = renesas,usb-phy-r8a7791;
reg = 0 0xe6590100 0 0x100;
--
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 v3 2/3] ARM: shmobile: koelsch: enable HS-USB
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Enable HS-USB device for the Koelsch board, defining the GPIO that the driver
should check when probing (which is the ID output from MAX3355 OTG chip).
Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: added pin function/group and prop, moved device node, fixed summary,
added changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 3:
- added pinctrl-related properties;
- moved the HS-USB node to precede the USB PHY node;
- uppercased arm in the summary;
- added changelog.
arch/arm/boot/dts/r8a7791-koelsch.dts |7 +++
1 file changed, 7 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -464,6 +464,13 @@
pinctrl-names = default;
};
+hsusb {
+ status = okay;
+ pinctrl-0 = usb0_pins;
+ pinctrl-names = default;
+ renesas,enable-gpio = gpio5 31 GPIO_ACTIVE_HIGH;
+};
+
usbphy {
status = okay;
};
--
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 v3 3/3] ARM: shmobile: henninger: enable HS-USB
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Enable HS-USB device for the Henninger board, defining the GPIO that the driver
should check when probing (which is the ID output from MAX3355 OTG chip).
Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: added pin function/group and prop, moved device node, fixed summary,
added changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 2:
- added pinctrl-related properties;
- moved the HS-USB node to precede the USB PHY node;
- uppercased arm in the summary;
- added changelog.
arch/arm/boot/dts/r8a7791-henninger.dts |7 +++
1 file changed, 7 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ renesas/arch/arm/boot/dts/r8a7791-henninger.dts
@@ -272,6 +272,13 @@
pinctrl-names = default;
};
+hsusb {
+ status = okay;
+ pinctrl-0 = usb0_pins;
+ pinctrl-names = default;
+ renesas,enable-gpio = gpio5 31 GPIO_ACTIVE_HIGH;
+};
+
usbphy {
status = okay;
};
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] Add HS-USB device tree support for R8A7791/Koelsch/Henninger board
Oops, this should have been [PATCH v 0/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: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
On Wed, Oct 08, 2014 at 10:02:44PM +0400, Sergei Shtylyov wrote: From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Enable HS-USB device for the Koelsch board, defining the GPIO that the driver should check when probing (which is the ID output from MAX3355 OTG chip). Note that there will be pinctrl-related error messages if both internal PCI and HS-USB drivers are enabled but they should be just ignored. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com [Sergei: added pin function/group and prop, moved device node, fixed summary, added changelog] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- Changes in version 3: - added pinctrl-related properties; did you miss pinctrl here ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
On Wed, Oct 08, 2014 at 10:07:50PM +0400, Sergei Shtylyov wrote: Hello. On 10/08/2014 10:05 PM, Felipe Balbi wrote: From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Enable HS-USB device for the Koelsch board, defining the GPIO that the driver should check when probing (which is the ID output from MAX3355 OTG chip). Note that there will be pinctrl-related error messages if both internal PCI and HS-USB drivers are enabled but they should be just ignored. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com [Sergei: added pin function/group and prop, moved device node, fixed summary, added changelog] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- Changes in version 3: - added pinctrl-related properties; did you miss pinctrl here ? No, AFAICS. Or what do you mean? usb0_pins doesn't appear to be defined anywhere. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
On 10/08/2014 10:08 PM, Felipe Balbi wrote: From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Enable HS-USB device for the Koelsch board, defining the GPIO that the driver should check when probing (which is the ID output from MAX3355 OTG chip). Note that there will be pinctrl-related error messages if both internal PCI and HS-USB drivers are enabled but they should be just ignored. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com [Sergei: added pin function/group and prop, moved device node, fixed summary, added changelog] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- Changes in version 3: - added pinctrl-related properties; did you miss pinctrl here ? No, AFAICS. Or what do you mean? usb0_pins doesn't appear to be defined anywhere. They are defined in the same file, just not in this patch. If you're looking at some of the USB trees or Linus' tree, the corresponding patch just hasn't hit them yet, it's in renesas.git ATM. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG (maybe) with find_get_entry()
On Wed, Oct 08, 2014 at 11:57:14AM -0500, Felipe Balbi wrote: Hi, With today's linus/master and with greg/usb-next I keep getting random kernel oops from find_get_entry() (see below): [ 47.700065] Unable to handle kernel paging request at virtual address [ 47.707667] pgd = c0004000 [ 47.710506] [] *pgd=ae7f6821, *pte=, *ppte= [ 47.717135] Internal error: Oops: 17 [#1] SMP ARM [ 47.722047] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs xhci_plat_hcd xhci_hcd snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap snd_soc_evm snd_soc_tlv320aic3x dwc3 snd_soc_core snd_compress omapdrm snd_pcm_dmaengine snd_pcm snd_timer snd fb_sys_fops lis3lv02d_i2c panel_dpi matrix_keypad lis3lv02d dwc3_omap input_polldev soundcore [ 47.755668] CPU: 0 PID: 1440 Comm: file-storage Not tainted 3.17.0-02899-ga7d2165 #229 [ 47.763958] task: ed1b22c0 ti: ed20e000 task.ti: ed20e000 [ 47.769609] PC is at find_get_entry+0x64/0x100 [ 47.774281] LR is at 0xfffa What GCC version are you using? 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these find_get_entry() crashes with 0x involved smell a lot like the earlier reports from kernels build with those compilers: https://lkml.org/lkml/2014/6/25/456 https://lkml.org/lkml/2014/6/30/375 https://lkml.org/lkml/2014/6/30/660 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 https://lkml.org/lkml/2014/5/9/330 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
Hello. On 10/08/2014 10:05 PM, Felipe Balbi wrote: From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Enable HS-USB device for the Koelsch board, defining the GPIO that the driver should check when probing (which is the ID output from MAX3355 OTG chip). Note that there will be pinctrl-related error messages if both internal PCI and HS-USB drivers are enabled but they should be just ignored. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com [Sergei: added pin function/group and prop, moved device node, fixed summary, added changelog] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- Changes in version 3: - added pinctrl-related properties; did you miss pinctrl here ? No, AFAICS. Or what do you mean? WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
On Wed, Oct 08, 2014 at 10:11:59PM +0400, Sergei Shtylyov wrote: On 10/08/2014 10:08 PM, Felipe Balbi wrote: From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Enable HS-USB device for the Koelsch board, defining the GPIO that the driver should check when probing (which is the ID output from MAX3355 OTG chip). Note that there will be pinctrl-related error messages if both internal PCI and HS-USB drivers are enabled but they should be just ignored. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com [Sergei: added pin function/group and prop, moved device node, fixed summary, added changelog] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- Changes in version 3: - added pinctrl-related properties; did you miss pinctrl here ? No, AFAICS. Or what do you mean? usb0_pins doesn't appear to be defined anywhere. They are defined in the same file, just not in this patch. If you're looking at some of the USB trees or Linus' tree, the corresponding patch just hasn't hit them yet, it's in renesas.git ATM. oh, alright then. :-) cheers -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: musb_dsps: fix NULL pointer in suspend
So testing managed to configure musb in DMA mode but not load the matching cppi41 driver for DMA. This results in |musb-hdrc musb-hdrc.0.auto: Failed to request rx1. |musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 |platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral which is okay. Once the driver is loaded we re-try probing and everyone is happy. Until then if you try suspend say echo mem /sys/power/state then you go boom |Unable to handle kernel NULL pointer dereference at virtual address 03a4 |pgd = cf50c000 |[03a4] *pgd=8f6a3831, *pte=, *ppte= |Internal error: Oops: 17 [#1] ARM |PC is at dsps_suspend+0x18/0x9c [musb_dsps] |LR is at dsps_suspend+0x18/0x9c [musb_dsps] |pc : [bf08e268] lr : [bf08e268] psr: a013 |sp : cbd97e00 ip : c0af4394 fp : |r10: c0831d90 r9 : 0002 r8 : cf6da410 |r7 : c03ba4dc r6 : bf08f224 r5 : r4 : cbc5fcd0 |r3 : bf08e250 r2 : bf08f264 r1 : cf6da410 r0 : |[bf08e268] (dsps_suspend [musb_dsps]) from [c03ba508] (platform_pm_suspend+0x2c/0x54) |Code: e1a04000 e9900041 e2800010 eb4caa8e (e59053a4) because platform_get_drvdata(glue-musb) returns a NULL pointer as long as the device is not fully probed. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_dsps.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index c791ba5da91a..2f71f04ed8f7 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -868,8 +868,13 @@ static int dsps_suspend(struct device *dev) struct dsps_glue *glue = dev_get_drvdata(dev); const struct dsps_musb_wrapper *wrp = glue-wrp; struct musb *musb = platform_get_drvdata(glue-musb); - void __iomem *mbase = musb-ctrl_base; + void __iomem *mbase; + if (!musb) + /* This can happen if the musb device is in -EPROBE_DEFER */ + return 0; + + mbase = musb-ctrl_base; glue-context.control = dsps_readl(mbase, wrp-control); glue-context.epintr = dsps_readl(mbase, wrp-epintr_set); glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set); @@ -886,8 +891,12 @@ static int dsps_resume(struct device *dev) struct dsps_glue *glue = dev_get_drvdata(dev); const struct dsps_musb_wrapper *wrp = glue-wrp; struct musb *musb = platform_get_drvdata(glue-musb); - void __iomem *mbase = musb-ctrl_base; + void __iomem *mbase; + + if (!musb) + return 0; + mbase = musb-ctrl_base; dsps_writel(mbase, wrp-control, glue-context.control); dsps_writel(mbase, wrp-epintr_set, glue-context.epintr); dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr); -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] USB: quirks: enable device-qualifier quirk for another Elan touchscreen
Yet another device affected by this.
Tested-by: Kevin Fenzi ke...@scrye.com
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 92125f9..cbbe701 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -98,6 +98,10 @@ static const struct usb_device_id usb_quirk_list[] = {
USB_QUIRK_DEVICE_QUALIFIER },
/* Elan Touchscreen */
+ { USB_DEVICE(0x04f3, 0x016f), .driver_info =
+ USB_QUIRK_DEVICE_QUALIFIER },
+
+ /* Elan Touchscreen */
{ USB_DEVICE(0x04f3, 0x009b), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add one more elan touch screen to quirk list
Hi, Here is yet another device that need those quirks. See: https://bugzilla.redhat.com/show_bug.cgi?id=1149509 Adel Gadllah (2): USB: quirks: enable device-qualifier quirk for another Elan touchscreen HID: usbhid: enable always-poll quirk for Elan Touchscreen 016f drivers/hid/hid-ids.h | 1 + drivers/hid/usbhid/hid-quirks.c | 1 + drivers/usb/core/quirks.c | 4 3 files changed, 6 insertions(+) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] HID: usbhid: enable always-poll quirk for Elan Touchscreen 016f
This device needs the quirk as well.
Tested-by: Kevin Fenzi ke...@scrye.com
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2c3c4d3..fbdef74 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -299,6 +299,7 @@
#define USB_VENDOR_ID_ELAN 0x04f3
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B0x009b
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F0x016f
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index e72c7b0..efb0316 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -72,6 +72,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] r8152: use mutex for hw settings
From: Hayes Wang hayesw...@realtek.com Date: Tue, 7 Oct 2014 13:36:30 +0800 Use mutex to avoid that the serial hw settings would be interrupted by other settings. Although there is no problem now, it makes the driver more safe. Signed-off-by: Hayes Wang hayesw...@realtek.com I think a much simpler fix is to take rtnl_lock() in the workqueue function and suspend/resume ops. Every other place you are adding the mutex already holds the RTNL mutex. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] Add HS-USB device tree support for R8A7790/Lager board
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20141007-v3.17' tag. Here we add the HS-USB device tree support on the R8A7790/Lager reference board. The patchset requires the USB PHY driver (already merged by Kishon and Greg) and the generic PHY support patches for the HS-USB driver posted by Yoshihiro Shimoda in order to work... [1/2] ARM: shmobile: r8a7790: add HS-USB device node [2/2] ARM: shmobile: lager: enable HS-USB WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] ARM: shmobile: r8a7790: add HS-USB device node
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Define the R8A7790 generic part of the HS-USB device node. It is up to the board
file to enable the device.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: fixed summary, added changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 3:
- uppercased arm in the summary;
- added changelog.
arch/arm/boot/dts/r8a7790.dtsi | 11 +++
1 file changed, 11 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -600,6 +600,17 @@
status = disabled;
};
+ hsusb: usb@e659 {
+ compatible = renesas,usbhs-r8a7790;
+ reg = 0 0xe659 0 0x100;
+ interrupts = 0 107 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp7_clks R8A7790_CLK_HSUSB;
+ renesas,buswait = 4;
+ phys = usb0 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
usbphy: usb-phy@e6590100 {
compatible = renesas,usb-phy-r8a7790;
reg = 0 0xe6590100 0 0x100;
--
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: ffs: fix regression when quirk_ep_out_aligned_size flag is set
Hi, On Wed, Oct 08, 2014 at 10:55:58AM -0700, David Cohen wrote: On Tue, Oct 07, 2014 at 07:32:56PM -0500, Felipe Balbi wrote: Hi again, On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote: The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the quirk implemented to align buffer size to maxpacketsize on out endpoint. As result, functionfs does not work on Intel platforms using dwc3 driver (i.e. Bay Trail and Merrifield). This patch fixes the issue. This code is based on a previous Qiuxu's patch. btw, please resend and add below right here: Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support) Cc: sta...@vger.kernel.org # v3.16+ Sure. But v3.16 doesn't have the new 'function' directory under usb/gadget. Not sure if same patch is useful for v3.16+. The patch I sent is intended for v3.17.1 and v3.18-rc1. code is the same anyway right ? It's just a path change :-) -- balbi signature.asc Description: Digital signature
[PATCH v4 2/2] ARM: shmobile: lager: enable HS-USB
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Enable HS-USB device for the Lager board, defining the GPIO that the driver
should check when probing. Since this board doesn't have the OTG ID pin, we
assume that GP5_18 (USB0_PWEN) is an ID pin because it is 1 when the SW5 is
in position 2-3 (meaning USB function) and 0 in other positions.
Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: added pin node and prop, moved device node, fixed summary, supplemented
changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 4:
- fixed pin node name;
- moved pin node before USB0's one.
Changes in version 3:
- added pin function/group and the pinctrl-related prop;
- moved the HS-USB node to precede the USB PHY node;
- uppercased arm in the summary;
- supplemented changelog.
arch/arm/boot/dts/r8a7790-lager.dts | 12
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -221,6 +221,11 @@
renesas,function = iic3;
};
+ hsusb_pins: hsusb {
+ renesas,groups = usb0_ovc_vbus;
+ renesas,function = usb0;
+ };
+
usb0_pins: usb0 {
renesas,groups = usb0;
renesas,function = usb0;
@@ -425,6 +430,13 @@
pinctrl-names = default;
};
+hsusb {
+ status = okay;
+ pinctrl-0 = hsusb_pins;
+ pinctrl-names = default;
+ renesas,enable-gpio = gpio5 18 GPIO_ACTIVE_HIGH;
+};
+
usbphy {
status = okay;
};
--
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: Multiple LUNs not detected with SCM USB-SCSI converter
On Wed, 8 Oct 2014, Mark Knibbs wrote:
Hi,
SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
MCDISK-D dual PCMCIA SCSI device in a Windows XP VM (with SCM driver
installed). Windows detected cards in both slots and added drive letters
for them.
With Linux however, only the lower slot (LUN 0) is detected. It seems the
us-max_lun field is zero for SCM converters.
...
I can think of several ways to fix this, and would like some input on which
is the best/neatest:
1. Change usb_stor_Bulk_max_lun() to return 7 in the US_FL_SCM_MULT_TARG
case (don't issue Get Max LUN to the USB device).
2. In usb_stor_scan_dwork(), don't call usb_stor_Bulk_max_lun() in the
US_FL_SCM_MULT_TARG case, and one of:
(a) In usb_stor_probe2(), set us-max_lun to 7 in the
US_FL_SCM_MULT_TARG case
(b) In get_transport(), set us-max_lun to 7 in the USB_PR_BULK case
(c) In get_protocol(), set us-max_lun to 7 in the USB_SC_SCSI case
Either way, usb_stor_Bulk_max_lun() shouldn't do anything for
SCM_MULT_TARG devices. Indeed, the value would be meaningless because
each target can have a different number of logical units.
Since it isn't going to do anything for those devices, you might as
well avoid calling it, which means using approach 2. But instead of a,
b, or c, just do something simple like this in usb_stor_scan_dworkd():
/* For bulk-only devices, determine the max LUN value */
if (us-protocol == USB_PR_BULK !(us-fflags US_FL_SINGLE_LUN)) {
if (us-fflags US_FL_SCM_MULT_TARG) {
/*
* Multiple-target devices can have different numbers
* of LUNs on different targets. We will allow all
* of them to be probed.
*/
us-max_lun = 7;
} else {
mutex_lock(us-dev_mutex);
us-max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(us-dev_mutex);
}
}
Do you know that all SCM_MULT_TARG devices use the Bulk-only transport?
I compiled a kernel with option 2+(a) and it does detect LUNs 0; here's
part of lsscsi output with the modified kernel:
[9:0:0:0]optical HP C1113M 1.19 /dev/sdg /dev/sg7
[9:0:3:0]diskMPL MC-DISK-D-1S[0] 3.3 /dev/sdh /dev/sg8
[9:0:3:1]diskMPL MC-DISK-D-1S[0] 3.3 - /dev/sg9
[9:0:3:2]diskMPL MC-DISK-D-1S[1] 3.3 - /dev/sg10
[9:0:3:3]diskMPL MC-DISK-D-1S[1] 3.3 /dev/sdi /dev/sg11
[9:0:3:4]diskMPL MC-DISK-D-1S[1] 3.3 /dev/sdj /dev/sg12
[9:0:3:5]diskMPL MC-DISK-D-1S[1] 3.3 /dev/sdk /dev/sg13
[9:0:3:6]diskMPL MC-DISK-D-1S[0] 3.3 /dev/sdl /dev/sg14
[9:0:3:7]diskMPL MC-DISK-D-1S[0] 3.3 /dev/sdm /dev/sg15
Could any other multiple-LUN-supporting devices be affected by this issue?
Every multiple-target USB device will be affected.
Perhaps option 2+(c) might be better if so?
[Also, looking at get_protocol(), should max_lun be set to 0 for the
US_SC_RBC case?]
Explicitly setting max_lun to 0 may be useful for documentation
purposes but it isn't really necessary, because the entire structure is
initialized to 0 when it is allocated. I don't know why three of the
cases bother to do it. Maybe the specifications for those protocols
forbid multiple LUNs.
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
Displaylink Attached Display Adapater and Monitor Not Recognized
Apologies in advance if I'm posting to the wrong list. I began by filing this as a bug on launchpad.net. Folks on that site indicated that it should be filed at kernel.org as it is upstream but not until after asking first on the mailling lists. My issue touches many parts usb/graphics/etc so I tried to choose the most general list. linux-x86_64 sent me to linux-kernel linux-kernel sent me to linux-usb Below is my collected information. Please let me know If I should post to a different list or if this is OK to file in the bug system. Thanks, Dennis [1.] One line summary of the problem: Displaylink Attached Display Adapater and Monitor Not Recognized [2.] Full description of the problem/report: DisplayLink Plug and Play Universal docking Station DELL Model: D3000 MFG: ACP075US SN: 1309017059 All ports on the device are recognized and function correctly except the display adapter. My intention is to drive 2 external monitors with this device. [3.] Keywords [4.] Kernel version Linux version 3.17.0-031700rc7-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201409281835 SMP Sun Sep 28 22:36:30 UTC 2014 [5.] Output of Oops N/A [6.] A small shell script or example program which triggers the problem (if possible) N/A [7.] Environment Description: Ubuntu Utopic Unicorn (development branch) Release: 14.10 [7.1.] Software (add the output of the ver_linux script here) linux-headers-3.17.0- 031700rc7-generic_3.17.0-031700rc7.201409281835_amd64.deb failed to install. Could not override with --force. So, could not run ver_linux script. [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz stepping : 9 microcode : 0x12 cpu MHz : 1290.335 cache size : 6144 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4589.68 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz stepping : 9 microcode : 0x12 cpu MHz : 1224.031 cache size : 6144 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4589.68 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz stepping : 9 microcode : 0x12 cpu MHz : 1226.636 cache size : 6144 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4589.68 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz stepping : 9 microcode : 0x12 cpu MHz : 1232.027 cache size : 6144 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
Re: Displaylink Attached Display Adapater and Monitor Not Recognized
On Wed, 8 Oct 2014, Dennis Gesker wrote: Apologies in advance if I'm posting to the wrong list. I began by filing this as a bug on launchpad.net. Folks on that site indicated that it should be filed at kernel.org as it is upstream but not until after asking first on the mailling lists. My issue touches many parts usb/graphics/etc so I tried to choose the most general list. linux-x86_64 sent me to linux-kernel linux-kernel sent me to linux-usb Below is my collected information. Please let me know If I should post to a different list or if this is OK to file in the bug system. Thanks, Dennis [1.] One line summary of the problem: Displaylink Attached Display Adapater and Monitor Not Recognized Is the display adapter a USB device? If it is, can you provide the output that lsusb -v shows for it? What shows up the dmesg log when you plug in the display adapter? 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: ffs: fix regression when quirk_ep_out_aligned_size flag is set
The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
quirk implemented to align buffer size to maxpacketsize on out endpoint.
As result, functionfs does not work on Intel platforms using dwc3 driver
(i.e. Bay Trail and Merrifield). This patch fixes the issue.
This code is based on a previous Qiuxu's patch.
Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support)
Cc: sta...@vger.kernel.org # v3.16+
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Signed-off-by: Qiuxu Zhuo qiuxu.z...@intel.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
Hi,
Since this is a feature that worked in past, this is meant for stable
versions = 3.16 too.
v1 to v2: just added Fixes, Cc and Acked-by lines on patch description.
Br, David Cohen
---
drivers/usb/gadget/function/f_fs.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 0dc3552d1360..6e2b8063b170 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -648,15 +648,26 @@ static void ffs_user_copy_worker(struct work_struct *work)
if (io_data-read ret 0) {
int i;
size_t pos = 0;
+
+ /*
+* Since req-length may be bigger than io_data-len (after
+* being rounded up to maxpacketsize), we may end up with more
+* data then user space has space for.
+*/
+ ret = min_t(int, ret, io_data-len);
+
use_mm(io_data-mm);
for (i = 0; i io_data-nr_segs; i++) {
+ size_t len = min_t(size_t, ret - pos,
+ io_data-iovec[i].iov_len);
+ if (!len)
+ break;
if (unlikely(copy_to_user(io_data-iovec[i].iov_base,
-io_data-buf[pos],
-io_data-iovec[i].iov_len))) {
+io_data-buf[pos], len))) {
ret = -EFAULT;
break;
}
- pos += io_data-iovec[i].iov_len;
+ pos += len;
}
unuse_mm(io_data-mm);
}
@@ -794,7 +805,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
goto error_lock;
req-buf = data;
- req-length = io_data-len;
+ req-length = data_len;
io_data-buf = data;
io_data-ep = ep-ep;
@@ -816,7 +827,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
ffs_io_data *io_data)
req = ep-req;
req-buf = data;
- req-length = io_data-len;
+ req-length = data_len;
req-context = done;
req-complete = ffs_epfile_io_complete;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] renesas_usbhs: fix platform init error message
There is a typo (prove instead of probe) in the error message printed when
the platform initialization fails. Replace that word with more fitting init.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/usb/renesas_usbhs/common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/renesas_usbhs/common.c
===
--- usb.orig/drivers/usb/renesas_usbhs/common.c
+++ usb/drivers/usb/renesas_usbhs/common.c
@@ -572,7 +572,7 @@ static int usbhs_probe(struct platform_d
*/
ret = usbhs_platform_call(priv, hardware_init, pdev);
if (ret 0) {
- dev_err(pdev-dev, platform prove failed.\n);
+ dev_err(pdev-dev, platform init failed.\n);
goto probe_end_mod_exit;
}
--
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: RCU bug with v3.17-rc3 ?
Hi, On Wed, Oct 08, 2014 at 12:57:07PM -0500, Felipe Balbi wrote: [ snip ] It seems to be a difficult-to-reproduce race though. On a second boot it didn't die during boot, but died with my USB test case. Unfortunately, the platform I'm using is pretty new and only goes as far back as v3.16 (which I had to backport 11 patches to get it to boot good enough for this test). I wonder if a corrupt file system could cause such problems... I keep seeing EXT4 errors every now and again; considering that this dies in a path through VFS, I wonder... I recall hearing of similar things in the past, but must defer to the FS/VFS experts on this one. resurrecting this thread. I'm facing the same issues with a brand new filesystem mounted through NFS. The way to reproduce is the same though: using g_mass_storage with either tmpfs or mmc as backing store. However it seems to die much more frequently than before. I can reproduce all the time. It's definitely not a problem with my board as I have two boards with different SoCs (ARM Cortex A8 and ARM Cortex A9) with two different USB peripheral controllers (MUSB and DWC3), using the same rootfs and they die the exact same way no matter if I use tmpfs or MMC as backing store. Adding a few more folks here. alright, first stable kernel with Cortex A8 was v3.14. All other kernel versions die starting with v3.15 to today's Linus. I'll start bisecting now. Finally bisected it down to commit 139e561660fe11e0fc35e142a800df3dd7d03e9d (lib: radix_tree: tree node interface). Here's full bisect log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15 git bisect bad 1860e379875dfe7271c649058aeddffe5afd9d0d # bad: [74a475acea49459721ae4b062d3da68c74259009] SubmittingPatches: add style recommendation to use imperative descriptions git bisect bad 74a475acea49459721ae4b062d3da68c74259009 # good: [c12e69c6aaf785fd307d05cb6f36ca0e7577ead7] Merge tag 'staging-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging git bisect good c12e69c6aaf785fd307d05cb6f36ca0e7577ead7 # good: [0fc31966035d7a540c011b6c967ce8eae1db121b] Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next git bisect good 0fc31966035d7a540c011b6c967ce8eae1db121b # good: [bdfc7cbdeef8cadba0e5793079ac0130b8e2220c] Merge branch 'mips-for-linux-next' of git://git.linux-mips.org/pub/scm/ralf/upstream-sfr git bisect good bdfc7cbdeef8cadba0e5793079ac0130b8e2220c # good: [0f1b1e6d73cb989ce2c071edc57deade3b084dfe] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid git bisect good 0f1b1e6d73cb989ce2c071edc57deade3b084dfe # good: [181e7d5d7bd7747e882e3ca89ecbf0fc3e72d0da] ixgbe: remove redundant if clause from PTP work git bisect good 181e7d5d7bd7747e882e3ca89ecbf0fc3e72d0da # good: [59ecc26004e77e100c700b1d0da7502b0fdadb46] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 git bisect good 59ecc26004e77e100c700b1d0da7502b0fdadb46 # good: [2b665e276c15ba7d9fc8cdd16931883a51ed13e4] fs/direct-io.c: remove redundant comparison git bisect good 2b665e276c15ba7d9fc8cdd16931883a51ed13e4 # bad: [f412c97abef71026d8192ca8efca231f1e3906b3] mm, hugetlb: mark some bootstrap functions as __init git bisect bad f412c97abef71026d8192ca8efca231f1e3906b3 # good: [4e35f483850ba46b838adfd312b3052416e15204] mm, hugetlb: use vma_resv_map() map types git bisect good 4e35f483850ba46b838adfd312b3052416e15204 # good: [6dbaf22ce1f1dfba33313198eb5bd989ae76dd87] mm: shmem: save one radix tree lookup when truncating swapped pages git bisect good 6dbaf22ce1f1dfba33313198eb5bd989ae76dd87 # good: [91b0abe36a7b2b3b02d7500925a5f8455334f0e5] mm + fs: store shadow entries in page cache git bisect good 91b0abe36a7b2b3b02d7500925a5f8455334f0e5 # bad: [139e561660fe11e0fc35e142a800df3dd7d03e9d] lib: radix_tree: tree node interface git bisect bad 139e561660fe11e0fc35e142a800df3dd7d03e9d # good: [a528910e12ec7ee203095eb1711468a66b9b60b0] mm: thrash detection-based file cache sizing git bisect good a528910e12ec7ee203095eb1711468a66b9b60b0 # first bad commit: [139e561660fe11e0fc35e142a800df3dd7d03e9d] lib: radix_tree: tree node interface I tried reverting that commit on v3.15 but it's non-trivial; I'll leave that for tomorrow. Meanwhile, adding folks involved with that commit to Cc list and another backtrace for reference: [ 113.696647] Unable to handle kernel paging request at virtual address [ 113.704370] pgd = c0004000 [ 113.707276] [] *pgd=9fef6821, *pte=, *ppte= [ 113.713998] Internal error: Oops: 17 [#1] SMP ARM [ 113.718912] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs musb_dsps musb_hdrc musb_am335x [ 113.730144] CPU: 0 PID: 1368 Comm: file-storage Not
Re: [PATCH] renesas_usbhs: fix platform init error message
On 10/09/2014 01:42 AM, Sergei Shtylyov wrote: There is a typo (prove instead of probe) in the error message printed when the platform initialization fails. Replace that word with more fitting init. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Oops, forgot to mention the patch is atop of the 'usb-linus' branch of GregKH's repo. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Add support for GPIOs for SMSC LAN95xx chips.
There might be 11 GPIOs in total.
Last three GPIOs (offsets 8-10, 0-based) are shared with FDX, LNKA, SPD
LEDs respectively. The LEDs are driven by chip by default at startup time.
Once the corresponding GPIO is requested, the chip LED drive logic is disabled.
The numbering scheme according to datasheets differs a bit between LAN9500
and LAN951x.
For LAN951x:
GPIOs with offsets 0-7 are named GPIO3 - GPIO7,
offsets 8-10 are for GPIO0 - GPIO2 (these three are multiplexed with
nFDX_LED,
nLNKA_LED, nSPD_LED).
For LAN9500:
The datasheet name is the same as the corresponding offset, i.e. offsets 0-10
are
for GPIO0-GPIO10.
Signed-off-by: Evgeny Boger bo...@contactless.ru
---
Changes:
v3: Remove more unnecessary newlines and return statement.
Fix typo in commit message (max offset 10, was: 11)
Add note on GPIO numbering scheme
v2: Remove unnecessary newlines.
Store cached gpio register values in order to
1) speed-up gpio_set by avoiding reading gpio
register prior to writing
2) restore gpio register settings after chip reset
which is triggered for instance on link up
drivers/net/usb/smsc95xx.c | 295 +++--
drivers/net/usb/smsc95xx.h | 1 +
2 files changed, 287 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index f3cef7c..d5d8735 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -31,6 +31,7 @@
#include linux/crc32.h
#include linux/usb/usbnet.h
#include linux/slab.h
+#include linux/gpio.h
#include smsc95xx.h
#define SMSC_CHIPNAME smsc95xx
@@ -70,6 +71,14 @@ struct smsc95xx_priv {
spinlock_t mac_cr_lock;
u8 features;
u8 suspend_flags;
+ struct usbnet *dev;
+#ifdef CONFIG_GPIOLIB
+ struct gpio_chip gpio;
+ struct mutex gpio_lock; /* lock for GPIO functions */
+#endif
+
+ u32 reg_gpio_cfg;
+ u32 reg_led_gpio_cfg;
};
static bool turbo_mode = true;
@@ -877,7 +886,7 @@ static int smsc95xx_phy_initialize(struct usbnet *dev)
static int smsc95xx_reset(struct usbnet *dev)
{
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev-data[0]);
- u32 read_buf, write_buf, burst_cap;
+ u32 read_buf, burst_cap;
int ret = 0, timeout;
netif_dbg(dev, ifup, dev-net, entering smsc95xx_reset\n);
@@ -886,6 +895,24 @@ static int smsc95xx_reset(struct usbnet *dev)
if (ret 0)
return ret;
+ /* restore and re-read GPIO registers immediately after requesting Lite
Reset */
+
+ ret = smsc95xx_write_reg(dev, GPIO_CFG, pdata-reg_gpio_cfg);
+ if (ret 0)
+ return ret;
+
+ ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, pdata-reg_led_gpio_cfg);
+ if (ret 0)
+ return ret;
+
+ ret = smsc95xx_read_reg(dev, GPIO_CFG, pdata-reg_gpio_cfg);
+ if (ret 0)
+ return ret;
+
+ ret = smsc95xx_read_reg(dev, LED_GPIO_CFG, pdata-reg_led_gpio_cfg);
+ if (ret 0)
+ return ret;
+
timeout = 0;
do {
msleep(10);
@@ -1019,13 +1046,6 @@ static int smsc95xx_reset(struct usbnet *dev)
return ret;
netif_dbg(dev, ifup, dev-net, ID_REV = 0x%08x\n, read_buf);
- /* Configure GPIO pins as LED outputs */
- write_buf = LED_GPIO_CFG_SPD_LED | LED_GPIO_CFG_LNK_LED |
- LED_GPIO_CFG_FDX_LED;
- ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, write_buf);
- if (ret 0)
- return ret;
-
/* Init Tx */
ret = smsc95xx_write_reg(dev, FLOW, 0);
if (ret 0)
@@ -1101,6 +1121,237 @@ static const struct net_device_ops smsc95xx_netdev_ops
= {
.ndo_set_features = smsc95xx_set_features,
};
+/* GPIO * */
+/* Note: the numbering scheme according to datasheets differs a bit
+ * between LAN9500 and LAN951x.
+ *
+ * For LAN951x:
+ * GPIOs with offsets 0-7 are named GPIO3 - GPIO7, offsets 8-10 are
+ * for GPIO0 - GPIO2 (these three are multiplexed with nFDX_LED,
+ * nLNKA_LED, nSPD_LED).
+ *
+ * For LAN9500:
+ * the datasheet name is the same as the corresponding offset, i.e.
+ * offsets 0-10 are for GPIO0-GPIO10.
+*/
+
+#ifdef CONFIG_GPIOLIB
+
+static inline u32 smsc95xx_gpio_get_register(unsigned gpio)
+{
+ if (gpio 8)
+ return GPIO_CFG;
+ else
+ return LED_GPIO_CFG;
+}
+
+static inline u8 smsc95xx_gpio_get_enable_offset(unsigned gpio)
+{
+ return (gpio 8) ? (24 + gpio) : (gpio * 4 - 16);
+}
+
+static inline u8 smsc95xx_gpio_get_type_offset(unsigned gpio)
+{
+ return (gpio 8) ? (16 + gpio) : gpio;
+}
+
+static inline u8 smsc95xx_gpio_get_dir_offset(unsigned gpio)
+{
+ return (gpio 8) ? (8 + gpio) : (gpio - 4);
+}
+
+static inline u8
Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Wed, Oct 8, 2014 at 12:18 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Wed, Oct 8, 2014 at 4:09 PM, Muthu Mani m...@cypress.com wrote:
-Original Message-
From: Alexandre Courbot [mailto:gnu...@gmail.com]
Sent: Tuesday, October 07, 2014 3:34 PM
To: Muthu Mani
Cc: Samuel Ortiz; Lee Jones; Wolfram Sang; Linus Walleij; Greg Kroah-
Hartman; linux-...@vger.kernel.org; linux-g...@vger.kernel.org; linux-
u...@vger.kernel.org; Linux Kernel Mailing List; Rajaram Regupathy; Johan
Hovold
Subject: Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-
GPIO adapter
On Mon, Oct 6, 2014 at 11:47 PM, Muthu Mani m...@cypress.com wrote:
+
+static int cy_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset) {
+ return 0;
+}
+
+static int cy_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value) {
+ return 0;
+}
If that chip is capable of both output and input, shouldn't these functions
be
implemented? I think this has already been pointed out in a previous version
but you did not reply.
Thanks for your inputs.
Only the GPIOs which are configured to be output GPIO can be set.
In that case cy_gpio_set() should return an error for GPIOs which are
not configured as outputs. Is that guaranteed by the current
implementation?
The set operation would fail trying to set the input or unconfigured GPIOs.
In this version of driver, this support is not added, it can be introduced
in future versions.
I will add a TODO note in the code.
Argh, no TODO please. Actual code that will turn this code into a
solid driver that can be merged.
Does a driver targeted for a custom device has to implement every
functionality in the 1st version ? My understanding is that Linux
follows incremental model and allows incremental merge.
(On a side note the driver is functionally verified with the necessary hardware)
Please correct me if I am missing something
Can all GPIOs be set as input or output? If so, please implement
cy_gpio_direction_*() and make sure that cy_gpio_set() behaves
properly if a GPIO is not an output. If the input/output GPIOs are
fixed, please make cy_gpio_direction_*() return an error if the GPIO
capabilities does not correspond to what is asked, and again ensure
that cy_gpio_set() works as expected.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] u_serial.c - Force destroy tty_port in gserial_free_port
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
WARN_ON(port-port_usb != NULL);
- tty_port_destroy(port-port);
kfree(port);
}
--
--
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] u_serial.c - Force destroy tty_port in gserial_free_port
Hi,
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
does anybody know if this is a valid usecase ? I'd expect us to return
-EBUSY in such a case, no ? In any case, using g_serial to rmmod
g_serial is, from what I can tell, not supported.
Let's wait to hear from Alan Cox or somebody else.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
WARN_ON(port-port_usb != NULL);
- tty_port_destroy(port-port);
kfree(port);
}
--
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 2/3] ARM: shmobile: koelsch: enable HS-USB
Hello.
(2014/10/09 3:02), Sergei Shtylyov wrote:
From: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Enable HS-USB device for the Koelsch board, defining the GPIO that the driver
should check when probing (which is the ID output from MAX3355 OTG chip).
Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
[Sergei: added pin function/group and prop, moved device node, fixed summary,
added changelog]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes in version 3:
- added pinctrl-related properties;
- moved the HS-USB node to precede the USB PHY node;
- uppercased arm in the summary;
- added changelog.
arch/arm/boot/dts/r8a7791-koelsch.dts |7 +++
1 file changed, 7 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -464,6 +464,13 @@
pinctrl-names = default;
};
+hsusb {
+ status = okay;
+ pinctrl-0 = usb0_pins;
+ pinctrl-names = default;
Perhaps I don't understand the pinctrl world yet, but I have a question.
In r8a7791, the USB0_PWEN is GP7_23 and the USB0_OVC is GP7_24. And,
the usb0_pins is related to these USB0 pins. But, as you know,
the koelsch has a OTG ID pin and it connects to GP5_31 via MAX3355 chip.
So, would you tell me why koelsch needs the pinctrl?
Best regards,
Yoshihiro Shimoda
+ renesas,enable-gpio = gpio5 31 GPIO_ACTIVE_HIGH;
+};
+
usbphy {
status = okay;
};
--
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] u_serial.c - Force destroy tty_port in gserial_free_port
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
Isn't this now a use-after-free issue?
--
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] u_serial.c - Force destroy tty_port in gserial_free_port
On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
Isn't this now a use-after-free issue?
Are you referring to the subsequent call to wait event() on gs_closed()?
Testing the use-case with this patch applied seemed to work without any
issues. The ttyGS0 reference in /dev/ is gone after running modprobe -r
but I'm just a newbie, so I could be doing sometime horrible here.
--
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 1/2] USB: quirks: enable device-qualifier quirk for another Elan touchscreen
On 2014-10-09 02:23, Adel Gadllah wrote:
Yet another device affected by this.
Tested-by: Kevin Fenzi ke...@scrye.com
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 92125f9..cbbe701 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -98,6 +98,10 @@ static const struct usb_device_id usb_quirk_list[] = {
USB_QUIRK_DEVICE_QUALIFIER },
/* Elan Touchscreen */
+ { USB_DEVICE(0x04f3, 0x016f), .driver_info =
+ USB_QUIRK_DEVICE_QUALIFIER },
+
+ /* Elan Touchscreen */
{ USB_DEVICE(0x04f3, 0x009b), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
In the beginning of quirk.c you will find the following text:
* Please keep the lists ordered by:
* 1) Vendor ID
* 2) Product ID
* 3) Class ID
--
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] u_serial.c - Force destroy tty_port in gserial_free_port
On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
Isn't this now a use-after-free issue?
Are you referring to the subsequent call to wait event() on gs_closed()?
Yes.
Testing the use-case with this patch applied seemed to work without any
issues. The ttyGS0 reference in /dev/ is gone after running modprobe -r
but I'm just a newbie, so I could be doing sometime horrible here.
Hm, I dug into the tty core, it should be ok, but it just seems really
odd, and bad-form to be doing something with port-port after calling a
destroy function with it, don't you agree?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] u_serial.c - Force destroy tty_port in gserial_free_port
On 09/10/14 14:38, Greg KH wrote:
On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
Isn't this now a use-after-free issue?
Are you referring to the subsequent call to wait event() on gs_closed()?
Yes.
Testing the use-case with this patch applied seemed to work without any
issues. The ttyGS0 reference in /dev/ is gone after running modprobe -r
but I'm just a newbie, so I could be doing sometime horrible here.
Hm, I dug into the tty core, it should be ok, but it just seems really
odd, and bad-form to be doing something with port-port after calling a
destroy function with it, don't you agree?
I do. The call to wait_event() can be removed as we no longer care whether
gs_closed(port) is returning true - if it even can, having destroyed the
tty_port.
cheers.
--
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: host: xhci-plat: fix suspend/resume on xhci-rcar
This patch fixes an issue that suspend/resume cannot work correctly
on xhci-rcar because the xhci driver output the following log:
xhci-hcd ee00.usb: WARN: xHC CMD_RUN timeout
So, this patch adds to set the XHCI_SLOW_SUSPEND quirk if xhci-rcar.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
This patch is based on the Greg's usb.git / usb-next branch.
(commit id : 4ed9a3d48406cad83d38764ee659de25851c)
drivers/usb/host/xhci-plat.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..a266883 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -27,12 +27,18 @@ static struct hc_driver __read_mostly xhci_plat_hc_driver;
static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
{
+ struct device_node *of_node = dev-of_node;
/*
* As of now platform drivers don't provide MSI support so we ensure
* here that the generic code does not try to make a pci_dev from our
* dev struct in order to setup MSI
*/
xhci-quirks |= XHCI_PLAT;
+
+ /* QUIRK: R-Car xHCI must be suspended extra slowly */
+ if (of_device_is_compatible(of_node, renesas,xhci-r8a7790) ||
+ of_device_is_compatible(of_node, renesas,xhci-r8a7791))
+ xhci-quirks |= XHCI_SLOW_SUSPEND;
}
/* called during probe() after chip reset completes */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: musb_dsps: fix NULL pointer in suspend
On 10/08/2014 11:59 PM, Sebastian Andrzej Siewior wrote: So testing managed to configure musb in DMA mode but not load the matching cppi41 driver for DMA. This results in |musb-hdrc musb-hdrc.0.auto: Failed to request rx1. |musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 |platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral which is okay. Once the driver is loaded we re-try probing and everyone is happy. Until then if you try suspend say echo mem /sys/power/state then you go boom |Unable to handle kernel NULL pointer dereference at virtual address 03a4 |pgd = cf50c000 |[03a4] *pgd=8f6a3831, *pte=, *ppte= |Internal error: Oops: 17 [#1] ARM |PC is at dsps_suspend+0x18/0x9c [musb_dsps] |LR is at dsps_suspend+0x18/0x9c [musb_dsps] |pc : [bf08e268] lr : [bf08e268] psr: a013 |sp : cbd97e00 ip : c0af4394 fp : |r10: c0831d90 r9 : 0002 r8 : cf6da410 |r7 : c03ba4dc r6 : bf08f224 r5 : r4 : cbc5fcd0 |r3 : bf08e250 r2 : bf08f264 r1 : cf6da410 r0 : |[bf08e268] (dsps_suspend [musb_dsps]) from [c03ba508] (platform_pm_suspend+0x2c/0x54) |Code: e1a04000 e9900041 e2800010 eb4caa8e (e59053a4) because platform_get_drvdata(glue-musb) returns a NULL pointer as long as the device is not fully probed. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Tested-by: George Cherian george.cher...@ti.com --- drivers/usb/musb/musb_dsps.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index c791ba5da91a..2f71f04ed8f7 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -868,8 +868,13 @@ static int dsps_suspend(struct device *dev) struct dsps_glue *glue = dev_get_drvdata(dev); const struct dsps_musb_wrapper *wrp = glue-wrp; struct musb *musb = platform_get_drvdata(glue-musb); - void __iomem *mbase = musb-ctrl_base; + void __iomem *mbase; + if (!musb) + /* This can happen if the musb device is in -EPROBE_DEFER */ + return 0; + + mbase = musb-ctrl_base; glue-context.control = dsps_readl(mbase, wrp-control); glue-context.epintr = dsps_readl(mbase, wrp-epintr_set); glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set); @@ -886,8 +891,12 @@ static int dsps_resume(struct device *dev) struct dsps_glue *glue = dev_get_drvdata(dev); const struct dsps_musb_wrapper *wrp = glue-wrp; struct musb *musb = platform_get_drvdata(glue-musb); - void __iomem *mbase = musb-ctrl_base; + void __iomem *mbase; + + if (!musb) + return 0; + mbase = musb-ctrl_base; dsps_writel(mbase, wrp-control, glue-context.control); dsps_writel(mbase, wrp-epintr_set, glue-context.epintr); dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr); -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
On Mon, Sep 29, 2014 at 11:28:57AM +0300, Heikki Krogerus wrote:
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?
Declare a fixup quirk. I'm not a pci expert, but I think something
like this should work..
static void dwc3_fix_amd_nl_class(struct pci_dev *pdev)
{
pdev-class = 0x0c03fe;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL,
dwc3_fix_amd_nl_class);
Heikki, your info inspires me. :)
I looked at pci driver, this update should put in pci/quirks.c.
Because the behavior of the global pci_fixups_header array is
maintained at that file.
When system inits, pci driver would load fixup devices before driver
attached. So it should define the fixup header under pci/quirks.c.
After do some tests in my side. This quirk works well.
Thanks,
Rui
--
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
