Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi, Michael Niewöhner writes: >> The clocks are same across working/non-working. >> Is it possible to bisect the commit that's causing hang for 4.8x ? > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init > and exit paths > This patch causes both the hang on reboot and the lsusb hang. How to reproduce? Why don't we see this on x86 and TI boards? I'm guessing this is failed bisection, as I can't see anything in that commit that would cause reboot hang. Also, that code path is *NOT* executed when you run lsusb. -- balbi signature.asc Description: PGP signature
Re: [PATCH] extcon: usb-gpio: Add VBUS detection support
Hi Chanwoo,
On 27/09/16 08:48, Peter Chen wrote:
> On Tue, Sep 20, 2016 at 05:53:55PM +0300, Roger Quadros wrote:
>> Driver can now work with both ID and VBUS pins or either one of
>> them.
>>
>> There can be the following 3 cases
>>
>> 1) Both ID and VBUS GPIOs are available:
>>
>> ID = LOW -> USB_HOST active, USB inactive
>> ID = HIGH -> USB_HOST inactive, USB state is same as VBUS.
>>
>> 2) Only ID GPIO is available:
>>
>> ID = LOW -> USB_HOST active, USB inactive
>> ID = HIGH -> USB_HOST inactive, USB active
>>
>> 3) Only VBUS GPIO is available:
>>
>> VBUS = LOW -> USB_HOST inactive, USB inactive
>> VBUS = HIGH -> USB_HOST inactive, USB active
>>
>> Signed-off-by: Roger Quadros
Can you please pick this one for v4.9? Thanks.
cheers,
-roger
>> ---
>> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +
>> drivers/extcon/extcon-usb-gpio.c | 169
>> -
>> 2 files changed, 132 insertions(+), 40 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> index af0b903..dfc14f7 100644
>> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> @@ -5,7 +5,10 @@ connected to a GPIO pin.
>>
>> Required properties:
>> - compatible: Should be "linux,extcon-usb-gpio"
>> +
>> +Either one of id-gpio or vbus-gpio must be present. Both can be present as
>> well.
>> - id-gpio: gpio for USB ID pin. See gpio binding.
>> +- vbus-gpio: gpio for USB VBUS pin.
>>
>> Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
>> extcon_usb1 {
>> diff --git a/drivers/extcon/extcon-usb-gpio.c
>> b/drivers/extcon/extcon-usb-gpio.c
>> index a27d350..d589c5f 100644
>> --- a/drivers/extcon/extcon-usb-gpio.c
>> +++ b/drivers/extcon/extcon-usb-gpio.c
>> @@ -24,7 +24,6 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>> #include
>> @@ -36,7 +35,9 @@ struct usb_extcon_info {
>> struct extcon_dev *edev;
>>
>> struct gpio_desc *id_gpiod;
>> +struct gpio_desc *vbus_gpiod;
>> int id_irq;
>> +int vbus_irq;
>>
>> unsigned long debounce_jiffies;
>> struct delayed_work wq_detcable;
>> @@ -48,31 +49,47 @@ static const unsigned int usb_extcon_cable[] = {
>> EXTCON_NONE,
>> };
>>
>> +/*
>> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
>> + * Both "USB" and "USB-HOST" can't be set as active at the
>> + * same time so if "USB-HOST" is active (i.e. ID is 0) we keep "USB"
>> inactive
>> + * even if VBUS is on.
>> + *
>> + * State |ID | VBUS
>> + *
>> + * [1] USB|H|H
>> + * [2] none |H|L
>> + * [3] USB-HOST |L|H
>> + * [4] USB-HOST |L|L
>> + *
>> + * In case we have only one of these signals:
>> + * - VBUS only - we want to distinguish between [1] and [2], so ID is
>> always 1.
>> + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
>> +*/
>> static void usb_extcon_detect_cable(struct work_struct *work)
>> {
>> -int id;
>> +int id, vbus;
>> struct usb_extcon_info *info = container_of(to_delayed_work(work),
>> struct usb_extcon_info,
>> wq_detcable);
>>
>> -/* check ID and update cable state */
>> -id = gpiod_get_value_cansleep(info->id_gpiod);
>> -if (id) {
>> -/*
>> - * ID = 1 means USB HOST cable detached.
>> - * As we don't have event for USB peripheral cable attached,
>> - * we simulate USB peripheral attach here.
>> - */
>> +/* check ID and VBUS and update cable state */
>> +id = info->id_gpiod ?
>> +gpiod_get_value_cansleep(info->id_gpiod) : 1;
>> +vbus = info->vbus_gpiod ?
>> +gpiod_get_value_cansleep(info->vbus_gpiod) : id;
>> +
>> +/* at first we clean states which are no longer active */
>> +if (id)
>> extcon_set_state_sync(info->edev, EXTCON_USB_HOST, false);
>> -extcon_set_state_sync(info->edev, EXTCON_USB, true);
>> -} else {
>> -/*
>> - * ID = 0 means USB HOST cable attached.
>> - * As we don't have event for USB peripheral cable detached,
>> - * we simulate USB peripheral detach here.
>> - */
>> +if (!vbus)
>> extcon_set_state_sync(info->edev, EXTCON_USB, false);
>> +
>> +if (!id) {
>> extcon_set_state_sync(info->edev, EXTCON_USB_HOST, true);
>> +} else {
>> +if (vbus)
>> +extcon_set_state_sync(info->edev, EXTCON_USB, true);
>> }
>> }
>>
>> @@ -101,12 +118,21 @@ static int usb_extcon_probe(struct platform_device
>> *pdev)
>>
Fwd: HSO driver patch
Hi,
I tried contacting authors of the driver mentioned in the source file
and also in the MAINTAINERS file,
but haven't received any reply so I am sending this to this mailing
list. If I should use another one,
plese advise me which one.
Thanks and BR,
Matej
-- Forwarded message --
From: Matej Kupljen
Date: Thu, Oct 6, 2016 at 11:06 AM
Subject: HSO driver patch
To: Filip Aben , Denis Joseph Barrow
, Jan Dumon
Cc: *
Hi all,
I found your emails in MAINTERNES file and in the source file for the driver.
If you think, someone else should be contacted, please feel free to
forward this mail.
I am using hso driver for my 3G modem (although different manufacturer
with different USB VID/PID) but I have some problems with it. It is
working fine, but if you disconnect the USB connection while the data
is transferring trough AT interface, we get a crash.
There are two patches attached to this mail:
1.) 0001-Reverse-the-order-in-disconnect.patch
This patch first sets the interface to NULL and only then starts
removing the allocated
resources. This is according to documentation and it is also
more similar to other drivers.
2.) 0002-Stop-also-serial-queue-when-device-is-unplugged.patch
Serial device was not stopped when the device got unplugged so
there are continues error
messages that the URB cannot be submitted.
Another problem is that we can hit the WARN macro in hso_serial_open by:
1.) Plug in the USB modem
2.) Load hso.ko module
3.) Create the /dev nodes
4.) do a less -f /dev/ttyHS2
5.) unplug the USB modem
6.) Re-plug it and back
7.) Quit previous less by pressing q
8.) start less again like in 4 and you'll get
[ 198.828136] [ cut here ]
[ 198.832788] WARNING: CPU: 2 PID: 1799 at include/linux/kref.h:47
kobject_get+0x9c/0xa8()
[ 198.840886] Modules linked in: hso
[ 198.844337] CPU: 2 PID: 1799 Comm: less Not tainted
4.1.13-00130-g126c250-dirty #5
[ 198.851917] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 198.858481] [<80017b70>] (unwind_backtrace) from [<800137d0>]
(show_stack+0x10/0x14)
[ 198.866246] [<800137d0>] (show_stack) from [<8063caa0>]
(dump_stack+0x84/0xc4)
[ 198.873492] [<8063caa0>] (dump_stack) from [<8002857c>]
(warn_slowpath_common+0x84/0xb4)
[ 198.881597] [<8002857c>] (warn_slowpath_common) from [<80028648>]
(warn_slowpath_null+0x1c/0x24)
[ 198.890398] [<80028648>] (warn_slowpath_null) from [<802533a8>]
(kobject_get+0x9c/0xa8)
[ 198.898420] [<802533a8>] (kobject_get) from [<80110b90>] (cdev_get+0x2c/0x4c)
[ 198.905571] [<80110b90>] (cdev_get) from [<80110eb0>]
(chrdev_open+0x2c/0x178)
[ 198.912812] [<80110eb0>] (chrdev_open) from [<8010aff0>]
(do_dentry_open+0x1d8/0x2f8)
[ 198.920666] [<8010aff0>] (do_dentry_open) from [<80118958>]
(do_last+0x564/0xce4)
[ 198.928164] [<80118958>] (do_last) from [<8011b0fc>] (path_openat+0x80/0x5cc)
[ 198.935330] [<8011b0fc>] (path_openat) from [<8011c0f8>]
(do_filp_open+0x2c/0x88)
[ 198.942832] [<8011c0f8>] (do_filp_open) from [<8010c36c>]
(do_sys_open+0x108/0x1cc)
[ 198.950508] [<8010c36c>] (do_sys_open) from [<80010140>]
(ret_fast_syscall+0x0/0x60)
[ 198.958292] ---[ end trace d0b32f14e1047616 ]---
If you need any more information, please do not hesitate to contact me.
Thanks and BR,
Matej
From f560b127ca9bb7c52106f0f83091e6c5e0e90b09 Mon Sep 17 00:00:00 2001
From: Matej Kupljen
Date: Wed, 28 Sep 2016 18:37:23 +0200
Subject: [PATCH] Reverse the order in disconnect
When the device is disconnected, we first need to set interface
data to NULL and then do the freeing of resources to avoid race
conditions.
---
drivers/net/usb/hso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b0df61f..16aef06 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3013,10 +3013,10 @@ exit:
/* device removed, cleaning up */
static void hso_disconnect(struct usb_interface *interface)
{
- hso_free_interface(interface);
-
/* remove reference of our private data */
usb_set_intfdata(interface, NULL);
+
+ hso_free_interface(interface);
}
static void async_get_intf(struct work_struct *data)
--
2.7.4
From 95cfca26bbcbb021e9327c03f8edf2ed0878de75 Mon Sep 17 00:00:00 2001
From: Matej Kupljen
Date: Wed, 5 Oct 2016 13:08:31 +0200
Subject: [PATCH] Stop also serial queue when device is unplugged
We need to also stop serial port when the device is unplugged,
the network part is already stopped.
---
drivers/net/usb/hso.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 16aef06..efd1fef 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3157,6 +3157,7 @@ static void hso_free_interface(struct usb_interface *interface)
mutex_lock(&serial->parent->mutex);
serial->parent->usb_gone = 1;
mutex_unlock(&serial->parent->mutex);
+ hso_stop_serial_device(serial->parent);
cancel_work_sync(&serial_table[i]-
Re: PROBLEM: am3517 usb-ohci not working
> Sounds like you're pretty close, in addition to the > pin muxing and PHY configuration, check also that you > have proper VBUS coming to the ports. Thank you. It was hardware problem Finally I received the schematics of the PHY connection from the board vendor. Suspend pin of PHY was pulled up and connected to gpio the expander. After forcing suspend pin to "0", USB HS works like a charm. Luke -- 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: Fwd: HSO driver patch
On Fri, 2016-10-07 at 12:06 +0200, Matej Kupljen wrote: > Hi, > > I tried contacting authors of the driver mentioned in the source file > and also in the MAINTAINERS file, > but haven't received any reply so I am sending this to this mailing > list. If I should use another one, > plese advise me which one. Hi, patches need to go to the maintainer and the list. Please repost them to the list and if the maintainer still doesnät answer we will need to bother Greg. HTH 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: Fwd: HSO driver patch
Hi Oliver, tank you for quick response. >> I tried contacting authors of the driver mentioned in the source file >> and also in the MAINTAINERS file, >> but haven't received any reply so I am sending this to this mailing >> list. If I should use another one, >> plese advise me which one. > > Hi, > > patches need to go to the maintainer and the list. Please repost > them to the list and if the maintainer still doesnät answer we will > need to bother Greg. Actually the email listed in MAINTAINERS file gets rejected: HSO 3G MODEM DRIVER M: Jan Dumon W: http://www.pharscape.org S: Maintained F: drivers/net/usb/hso.c And my mail responded with: Delivery to the following recipient failed permanently: j.du...@option.com How to proceed, please advise. Thanks, Matej -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] USB: ch341: reinitialize chip on reconfiguration
On Thu, Sep 15, 2016 at 04:57:34PM +0100, Aidan Thornton wrote:
> Changing the LCR register after initialization does not seem to be
> reliable on all chips (particularly not on CH341A). Restructure
> initialization and configuration to always reinit the chip on
> configuration changes instead and pass the LCR register value directly
> to the initialization command.
>
> Cleaned-up version of a patch by Grigori Goronzy
>
> Signed-off-by: Aidan Thornton
This series looks good to me, I just a couple of comments to this one.
> ---
> drivers/usb/serial/ch341.c | 38 --
> 1 file changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
> index bdf525f..ce799d0 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -132,10 +132,10 @@ static int ch341_control_in(struct usb_device *dev,
> return r;
> }
>
> -static int ch341_set_baudrate(struct usb_device *dev,
> - struct ch341_private *priv)
> +static int ch341_init_set_baudrate(struct usb_device *dev,
> + struct ch341_private *priv, unsigned ctrl)
> {
> - short a, b;
> + short a;
> int r;
> unsigned long factor;
> short divisor;
> @@ -155,11 +155,9 @@ static int ch341_set_baudrate(struct usb_device *dev,
>
> factor = 0x1 - factor;
> a = (factor & 0xff00) | divisor;
> - b = factor & 0xff;
>
> - r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x1312, a);
> - if (!r)
> - r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x0f2c, b);
> + /* 0x9c is "enable SFR_UART Control register and timer" */
> + r = ch341_control_out(dev, CH341_REQ_SERIAL_INIT, 0x9c | (ctrl << 8), a
> | 0x80);
Please break this line or restructure the code to stay within 80 cols
(checkpatch.pl would have let you know).
> return r;
> }
> @@ -218,16 +216,12 @@ static int ch341_configure(struct usb_device *dev,
> struct ch341_private *priv)
> if (r < 0)
> goto out;
>
> - r = ch341_set_baudrate(dev, priv);
> - if (r < 0)
> - goto out;
> -
> /* expect two bytes 0x56 0x00 */
> r = ch341_control_in(dev, CH341_REQ_READ_REG, 0x2518, 0, buffer, size);
> if (r < 0)
> goto out;
>
> - r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x2518, 0x0050);
> + r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x2518, 0x00c3);
Why is this change needed? I see no write to this register in the
vendor driver.
> if (r < 0)
> goto out;
>
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: Fwd: HSO driver patch
On Fri, 2016-10-07 at 12:47 +0200, Matej Kupljen wrote: Hi, > And my mail responded with: > > Delivery to the following recipient failed permanently: > > j.du...@option.com > > > How to proceed, please advise. ask somebody else @option about Jon and let's see whether he reads this list. 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: Fwd: HSO driver patch
On Fri, Oct 07, 2016 at 12:06:54PM +0200, Matej Kupljen wrote: > Hi, > > I tried contacting authors of the driver mentioned in the source file > and also in the MAINTAINERS file, > but haven't received any reply so I am sending this to this mailing > list. If I should use another one, > plese advise me which one. Can you use the scripts/get_maintainer.pl tool to determine the correct mailing list to send these to, and send them in a format we can apply them in? We will be glad to queue them up, no need to get the option maintainer's response for basic stuff. 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: PROBLEM: am3517 usb-ohci not working
* Łukasz Pułka [161007 03:14]: > > Sounds like you're pretty close, in addition to the > > pin muxing and PHY configuration, check also that you > > have proper VBUS coming to the ports. > > Thank you. It was hardware problem > Finally I received the schematics of the PHY connection from the board > vendor. > Suspend pin of PHY was pulled up and connected to gpio the expander. > After forcing suspend pin to "0", USB HS works like a charm. OK good to hear. Tony -- 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: Fwd: HSO driver patch
Hi,
>> I tried contacting authors of the driver mentioned in the source file
>> and also in the MAINTAINERS file,
>> but haven't received any reply so I am sending this to this mailing
>> list. If I should use another one,
>> plese advise me which one.
>
> Can you use the scripts/get_maintainer.pl tool to determine the correct
> mailing list to send these to,
$ ./scripts/get_maintainer.pl 0001-Reverse-the-order-in-disconnect.patch
Jan Dumon (maintainer:HSO 3G MODEM DRIVER)
linux-usb@vger.kernel.org (open list:USB NETWORKING DR...)
net...@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-ker...@vger.kernel.org (open list)
> and send them in a format we can apply them in?
$ scripts/checkpatch.pl 0001-Reverse-the-order-in-disconnect.patch
total: 0 errors, 0 warnings, 0 checks, 12 lines checked
0001-Reverse-the-order-in-disconnect.patch has no obvious style
problems and is ready for submission.
$ scripts/checkpatch.pl
0002-Stop-also-serial-queue-when-device-is-unplugged.patch
total: 0 errors, 0 warnings, 0 checks, 7 lines checked
0002-Stop-also-serial-queue-when-device-is-unplugged.patch has no
obvious style problems and is ready for submission.
Is this O.K.?
> We will be glad to queue them up, no need to get the option
> maintainer's response for basic stuff.
Thank you and BR,
Matej
From f560b127ca9bb7c52106f0f83091e6c5e0e90b09 Mon Sep 17 00:00:00 2001
From: Matej Kupljen
Date: Wed, 28 Sep 2016 18:37:23 +0200
Subject: [PATCH] Reverse the order in disconnect
When the device is disconnected, we first need to set interface
data to NULL and then do the freeing of resources to avoid race
conditions.
Signed-off-by: Matej Kupljen
---
drivers/net/usb/hso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b0df61f..16aef06 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3013,10 +3013,10 @@ exit:
/* device removed, cleaning up */
static void hso_disconnect(struct usb_interface *interface)
{
- hso_free_interface(interface);
-
/* remove reference of our private data */
usb_set_intfdata(interface, NULL);
+
+ hso_free_interface(interface);
}
static void async_get_intf(struct work_struct *data)
--
2.7.4
From 95cfca26bbcbb021e9327c03f8edf2ed0878de75 Mon Sep 17 00:00:00 2001
From: Matej Kupljen
Date: Wed, 5 Oct 2016 13:08:31 +0200
Subject: [PATCH] Stop also serial queue when device is unplugged
We need to also stop serial port when the device is unplugged,
the network part is already stopped.
Signed-off-by: Matej Kupljen
---
drivers/net/usb/hso.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 16aef06..efd1fef 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3157,6 +3157,7 @@ static void hso_free_interface(struct usb_interface *interface)
mutex_lock(&serial->parent->mutex);
serial->parent->usb_gone = 1;
mutex_unlock(&serial->parent->mutex);
+ hso_stop_serial_device(serial->parent);
cancel_work_sync(&serial_table[i]->async_put_intf);
cancel_work_sync(&serial_table[i]->async_get_intf);
hso_serial_tty_unregister(serial);
--
2.7.4
Re: Fwd: HSO driver patch
On Fri, Oct 07, 2016 at 03:55:03PM +0200, Matej Kupljen wrote: > Hi, > > >> I tried contacting authors of the driver mentioned in the source file > >> and also in the MAINTAINERS file, > >> but haven't received any reply so I am sending this to this mailing > >> list. If I should use another one, > >> plese advise me which one. > > > > Can you use the scripts/get_maintainer.pl tool to determine the correct > > mailing list to send these to, > > $ ./scripts/get_maintainer.pl 0001-Reverse-the-order-in-disconnect.patch > > Jan Dumon (maintainer:HSO 3G MODEM DRIVER) > linux-usb@vger.kernel.org (open list:USB NETWORKING DR...) > net...@vger.kernel.org (open list:NETWORKING DRIVERS) > linux-ker...@vger.kernel.org (open list) Great! Please use netdev and linux-usb for these. > > and send them in a format we can apply them in? > > $ scripts/checkpatch.pl 0001-Reverse-the-order-in-disconnect.patch > total: 0 errors, 0 warnings, 0 checks, 12 lines checked > 0001-Reverse-the-order-in-disconnect.patch has no obvious style > problems and is ready for submission. > > $ scripts/checkpatch.pl > 0002-Stop-also-serial-queue-when-device-is-unplugged.patch > total: 0 errors, 0 warnings, 0 checks, 7 lines checked > 0002-Stop-also-serial-queue-when-device-is-unplugged.patch has no > obvious style problems and is ready for submission. > > Is this O.K.? Yes, but they can't be attached, and they have to be individual emails, one email per patch. Documentation/SubmittingPatches has all of the details. 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
HSO driver patch [1/2]
Hi,
I am using hso driver for my 3G modem (although different manufacturer
with different USB VID/PID) but I have some problems with it. It is
working fine, but if you disconnect the USB connection while the data
is transferring trough AT interface, we get a crash.
There are two patches:
1.) 0001-Reverse-the-order-in-disconnect.patch
This patch first sets the interface to NULL and only then starts
removing the allocated
resources. This is according to documentation and it is also
more similar to other drivers.
2.) 0002-Stop-also-serial-queue-when-device-is-unplugged.patch
Serial device was not stopped when the device got unplugged so
there are continues error
messages that the URB cannot be submitted.
Another problem is that we can hit the WARN macro in hso_serial_open by:
1.) Plug in the USB modem
2.) Load hso.ko module
3.) Create the /dev nodes
4.) do a less -f /dev/ttyHS2
5.) unplug the USB modem
6.) Re-plug it and back
7.) Quit previous less by pressing q
8.) start less again like in 4 and you'll get
[ 198.828136] [ cut here ]
[ 198.832788] WARNING: CPU: 2 PID: 1799 at include/linux/kref.h:47
kobject_get+0x9c/0xa8()
[ 198.840886] Modules linked in: hso
[ 198.844337] CPU: 2 PID: 1799 Comm: less Not tainted
4.1.13-00130-g126c250-dirty #5
[ 198.851917] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 198.858481] [<80017b70>] (unwind_backtrace) from [<800137d0>]
(show_stack+0x10/0x14)
[ 198.866246] [<800137d0>] (show_stack) from [<8063caa0>]
(dump_stack+0x84/0xc4)
[ 198.873492] [<8063caa0>] (dump_stack) from [<8002857c>]
(warn_slowpath_common+0x84/0xb4)
[ 198.881597] [<8002857c>] (warn_slowpath_common) from [<80028648>]
(warn_slowpath_null+0x1c/0x24)
[ 198.890398] [<80028648>] (warn_slowpath_null) from [<802533a8>]
(kobject_get+0x9c/0xa8)
[ 198.898420] [<802533a8>] (kobject_get) from [<80110b90>] (cdev_get+0x2c/0x4c)
[ 198.905571] [<80110b90>] (cdev_get) from [<80110eb0>]
(chrdev_open+0x2c/0x178)
[ 198.912812] [<80110eb0>] (chrdev_open) from [<8010aff0>]
(do_dentry_open+0x1d8/0x2f8)
[ 198.920666] [<8010aff0>] (do_dentry_open) from [<80118958>]
(do_last+0x564/0xce4)
[ 198.928164] [<80118958>] (do_last) from [<8011b0fc>] (path_openat+0x80/0x5cc)
[ 198.935330] [<8011b0fc>] (path_openat) from [<8011c0f8>]
(do_filp_open+0x2c/0x88)
[ 198.942832] [<8011c0f8>] (do_filp_open) from [<8010c36c>]
(do_sys_open+0x108/0x1cc)
[ 198.950508] [<8010c36c>] (do_sys_open) from [<80010140>]
(ret_fast_syscall+0x0/0x60)
[ 198.958292] ---[ end trace d0b32f14e1047616 ]---
Thanks,
Matej
From f560b127ca9bb7c52106f0f83091e6c5e0e90b09 Mon Sep 17 00:00:00 2001
From: Matej Kupljen
Date: Wed, 28 Sep 2016 18:37:23 +0200
Subject: [PATCH] Reverse the order in disconnect
When the device is disconnected, we first need to set interface
data to NULL and then do the freeing of resources to avoid race
conditions.
Signed-off-by: Matej Kupljen
---
drivers/net/usb/hso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b0df61f..16aef06 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3013,10 +3013,10 @@ exit:
/* device removed, cleaning up */
static void hso_disconnect(struct usb_interface *interface)
{
- hso_free_interface(interface);
-
/* remove reference of our private data */
usb_set_intfdata(interface, NULL);
+
+ hso_free_interface(interface);
}
static void async_get_intf(struct work_struct *data)
--
2.7.4
Re: HSO driver patch [2/2]
Hi, second patch.. Thanks, Matej From 95cfca26bbcbb021e9327c03f8edf2ed0878de75 Mon Sep 17 00:00:00 2001 From: Matej Kupljen Date: Wed, 5 Oct 2016 13:08:31 +0200 Subject: [PATCH] Stop also serial queue when device is unplugged We need to also stop serial port when the device is unplugged, the network part is already stopped. Signed-off-by: Matej Kupljen --- drivers/net/usb/hso.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c index 16aef06..efd1fef 100644 --- a/drivers/net/usb/hso.c +++ b/drivers/net/usb/hso.c @@ -3157,6 +3157,7 @@ static void hso_free_interface(struct usb_interface *interface) mutex_lock(&serial->parent->mutex); serial->parent->usb_gone = 1; mutex_unlock(&serial->parent->mutex); + hso_stop_serial_device(serial->parent); cancel_work_sync(&serial_table[i]->async_put_intf); cancel_work_sync(&serial_table[i]->async_get_intf); hso_serial_tty_unregister(serial); -- 2.7.4
Re: HSO driver patch [1/2]
On Fri, Oct 07, 2016 at 04:29:42PM +0200, Matej Kupljen wrote: > Hi, > > > I am using hso driver for my 3G modem (although different manufacturer > with different USB VID/PID) but I have some problems with it. It is > working fine, but if you disconnect the USB connection while the data > is transferring trough AT interface, we get a crash. > > There are two patches: > 1.) 0001-Reverse-the-order-in-disconnect.patch > This patch first sets the interface to NULL and only then starts > removing the allocated > resources. This is according to documentation and it is also > more similar to other drivers. > 2.) 0002-Stop-also-serial-queue-when-device-is-unplugged.patch > Serial device was not stopped when the device got unplugged so > there are continues error > messages that the URB cannot be submitted. Again, patches can not be attached, they just need to be inline, with the needed information. Look at the patches on the mailing lists for plenty of examples of how to do this. 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
HSO driver patch again [2/2]
Hi, second patch: 0002-Stop-also-serial-queue-when-device-is-unplugged.patch Serial device was not stopped when the device got unplugged so there are continues error messages that the URB cannot be submitted. Thanks, Matej From: Matej Kupljen Date: Wed, 5 Oct 2016 13:08:31 +0200 Subject: [PATCH] Stop also serial queue when device is unplugged We need to also stop serial port when the device is unplugged, the network part is already stopped. Signed-off-by: Matej Kupljen --- drivers/net/usb/hso.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c index 16aef06..efd1fef 100644 --- a/drivers/net/usb/hso.c +++ b/drivers/net/usb/hso.c @@ -3157,6 +3157,7 @@ static void hso_free_interface(struct usb_interface *interface) mutex_lock(&serial->parent->mutex); serial->parent->usb_gone = 1; mutex_unlock(&serial->parent->mutex); + hso_stop_serial_device(serial->parent); cancel_work_sync(&serial_table[i]->async_put_intf); cancel_work_sync(&serial_table[i]->async_get_intf); hso_serial_tty_unregister(serial); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HSO driver patch again [1/2]
Hi,
I am using hso driver for my 3G modem (although different manufacturer
with different USB VID/PID) but I have some problems with it. It is
working fine, but if you disconnect the USB connection while the data
is transferring trough AT interface, we get a crash.
First patch
0001-Reverse-the-order-in-disconnect.patch
This patch first sets the interface to NULL and only then starts
removing the allocated resources. This is according to documentation and
it is also more similar to other drivers.
Thanks,
Matej
From: Matej Kupljen
Date: Wed, 28 Sep 2016 18:37:23 +0200
Subject: [PATCH] Reverse the order in disconnect
When the device is disconnected, we first need to set interface
data to NULL and then do the freeing of resources to avoid race
conditions.
Signed-off-by: Matej Kupljen
---
drivers/net/usb/hso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b0df61f..16aef06 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -3013,10 +3013,10 @@ exit:
/* device removed, cleaning up */
static void hso_disconnect(struct usb_interface *interface)
{
- hso_free_interface(interface);
-
/* remove reference of our private data */
usb_set_intfdata(interface, NULL);
+
+ hso_free_interface(interface);
}
static void async_get_intf(struct work_struct *data)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Tue, Oct 04, 2016 at 02:13:26PM +0200, Linus Walleij wrote:
> On Sat, Sep 24, 2016 at 12:50 AM, Martyn Welch
> wrote:
>
> > This patch adds support for the GPIO found on the CP2105.
>
>
> > This device supports either push-pull or open-drain modes, it doesn't
> > provide an explicit input mode, though the state of the GPIO can be read
> > when used in open-drain mode. Like with pin use, the mode is configured in
> > the one-time programable PROM and can't be changed at runtime.
>
> I see.
>
> So implement .direction_input() and .direction_output()
> anyways.
>
> Return failure on .direction_input() if it is in push-pull mode.
>
> Return success on all .direction_output() calls.
>
> Then implement .set_single_ended() and return success for open drain
> if the is in open drain, success for push-pull if the line is in push-pull
> mode, and failure in all other cases. Simple, but correct.
>
This is proving to be problematic, because we are trying to be clever in
gpiolib and the driver.
I have the driver setup as above, if I have a pin that is configured as
open-drain (and can't be changed) and I try to drive it as an open-source
output with a low output value, it succeeds.
This is because, in gpiolib, if the device can't actually be set as o-s,
we configure it as input to emulate o-s (_gpiod_direction_output_raw):
else if (test_bit(FLAG_OPEN_SOURCE, &desc->flags)) {
if (gc->set_single_ended) {
ret = gc->set_single_ended(gc, gpio_chip_hwgpio(desc),
LINE_MODE_OPEN_SOURCE);
if (!ret)
goto set_output_value;
}
/* Emulate open source by not actively driving the line low */
if (!value)
return gpiod_direction_input(desc);
In the driver we can't change it to input, but we are trying to be clever,
so we allow pins which are o-d to be treated as though they are inputs.
However, for the o-d to behave like an input at all, the pin must be driven
with a "1" (i.e. pulled up, rather than driven low), so:
/*
* Return failure if pin is configured in push-pull mode, can only
* emulate input when pin is configured as open-drain
*/
if (priv->gpio_mode & BIT(gpio))
return -ENOTSUPP;
/*
* Ensure we are outputting a high state so that we can use the
* open-drain output as an input
*/
cp210x_gpio_set(gc, gpio, 1);
So now we have a pin that is supposed to be pulling to ground that is
actually pulling to VCC.
Also, if an output can only be open-drain, attempting to set the pin as
push-pull succeeds because gpiolib (currently) assumes that a pin can
always be p-p and doesn't even check the return value of it's call to
.set_single_ended:
/* Make sure to disable open drain/source hardware, if any */
if (gc->set_single_ended)
gc->set_single_ended(gc,
gpio_chip_hwgpio(desc),
LINE_MODE_PUSH_PULL);
This is clearly a separate issue.
WRT this driver, I think I need to keep set_single_ended, but change
.direction_input to always return a failure and have .direction_output always
return success to avoid pins being driven in unexpected ways. Does that sould
acceptable?
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] hid: hid-led: fix issue with transfer buffer not being dma capable
On Oct 03 2016 or thereabouts, Heiner Kallweit wrote:
> The hid-led driver works fine under 4.8.0, however with the next
> kernel from today I get this:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
> usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
> transfer buffer not dma capable
> Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm
> led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic
> x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801
> i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169
> snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb
> btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci
> xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
> CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
> Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
> c90003dbb7e0 81280425 c90003dbb830
> c90003dbb820 8105b086 063003dbb800 88006f374480
> 0001 880079544000
> Call Trace:
> [] dump_stack+0x68/0x93
> [] __warn+0xc6/0xe0
> [] warn_slowpath_fmt+0x4a/0x50
> [] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
> [] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
> [] ? rcu_read_lock_sched_held+0x40/0x80
> [] ? module_assert_mutex_or_preempt+0x13/0x50
> [] ? __module_address+0x27/0xf0
> [] usb_submit_urb+0x2c4/0x520 [usbcore]
> [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
> [] usb_control_msg+0xbc/0xf0 [usbcore]
> [] ? __module_address+0x27/0xf0
> [] usbhid_raw_request+0xa4/0x180 [usbhid]
> [] hidled_recv+0x71/0xe0 [hid_led]
> [] thingm_init+0x2d/0x50 [hid_led]
> [] hidled_probe+0xcb/0x24a [hid_led]
> [] hid_device_probe+0xd2/0x150
> [] driver_probe_device+0x1fd/0x2c0
> [] __driver_attach+0x9a/0xa0
> [] ? driver_probe_device+0x2c0/0x2c0
> [] bus_for_each_dev+0x5d/0x90
> [] driver_attach+0x19/0x20
> [] bus_add_driver+0x11f/0x220
> [] ? 0xa07ac000
> [] driver_register+0x5b/0xd0
> [] ? 0xa07ac000
> [] __hid_register_driver+0x61/0xa0
> [] hidled_driver_init+0x1e/0x20 [hid_led]
> [] do_one_initcall+0x38/0x150
> [] ? rcu_read_lock_sched_held+0x40/0x80
> [] ? kmem_cache_alloc_trace+0x1d0/0x230
> [] do_init_module+0x5a/0x1cb
> [] load_module+0x1e42/0x2530
> [] ? __symbol_put+0x50/0x50
> [] ? show_coresize+0x30/0x30
> [] ? kernel_read_file+0x100/0x190
> [] ? kernel_read_file_from_fd+0x44/0x70
> [] SYSC_finit_module+0xba/0xc0
> [] SyS_finit_module+0x9/0x10
> [] entry_SYSCALL_64_fastpath+0x18/0xad
> ---[ end trace c9e6ea27003ecf9e ]---
>
> Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
>
> Signed-off-by: Heiner Kallweit
> ---
> v2:
> - Based on a comment from Alan Stern allocate the buffer to be provided to
> hid_hw_raw_request separately (and not as part of struct hidled_device).
> Alternative would have been to allocate the buffer dynamically in each
> function calling hidled_send/_recv. However this would mean more overhead
> IMHO, and we'd need an error path in callers to free the buffer in case
> of an error.
> In addition we have better control that a proper buffer is used in case
> the driver is extended by somebody for supporting another LED device.
> ---
Looks like the receive function is only called from .probe(), so this
should be safe.
However, for the send function, is there a chance there can be a
concurrent access of the buffer? (like 2 userspace processes writing a
different values at the same time).
If so, then you'll need to add a locking mechanism (can't recall if the
LED API provide one for us or not), or just alloc/free the buffers
directly.
If no, the patch is:
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
> drivers/hid/hid-led.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
> index d8d55f3..555c88e 100644
> --- a/drivers/hid/hid-led.c
> +++ b/drivers/hid/hid-led.c
> @@ -100,6 +100,7 @@ struct hidled_device {
> const struct hidled_config *config;
> struct hid_device *hdev;
> struct hidled_rgb *rgb;
> + u8 *buf;
> struct mutexlock;
> };
>
> @@ -118,13 +119,19 @@ static int hidled_send(struct hidled_device *ldev, __u8
> *buf)
>
> mutex_lock(&ldev->lock);
>
> + /*
> + * buffer provided to hid_hw_raw_request must not be on the stack
> + * and must not be part of a data structure
> + */
> + memcpy(ldev->buf, buf, ldev->config->report_size);
> +
> if (ldev->config->report_type == RAW_REQUEST)
> - ret = hid_hw_raw_request(ldev->hdev, buf[0], buf,
> + ret = hid_hw_raw_request(ldev->hdev, buf[0], ldev->buf,
>
[PATCH/RFT 05/12] USB: ohci-da8xx: Fix probe for devices with no vbus/oci gpio
From: Axel Haslam
Some boards dont have gpios assigened for vbus or oci.
Allow these boards to enumerate usb without declaring the set_power
and/or the ocic_notify callbacks in platform data.
Signed-off-by: Axel Haslam
---
drivers/usb/host/ohci-da8xx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 3c85d6c..9d9f8e3 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -215,7 +215,7 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
temp ? "Set" : "Clear", wIndex, "POWER");
if (!pdata->set_power)
- return -EPIPE;
+ return 0;
return pdata->set_power(wIndex, temp) ? -EPIPE : 0;
case USB_PORT_FEAT_C_OVER_CURRENT:
@@ -343,10 +343,12 @@ static int usb_hcd_da8xx_probe(const struct hc_driver
*driver,
if (pdata->ocic_notify) {
error = pdata->ocic_notify(ohci_da8xx_ocic_handler);
- if (!error)
- return 0;
+ if (error)
+ goto err_notify;
}
+ return 0;
+err_notify:
usb_remove_hcd(hcd);
err:
usb_put_hcd(hcd);
--
2.7.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/RFT 08/12] ARM: davinci: register the usb20_phy clock on the SoC file
From: Axel Haslam
The usb20_phy clock needs to be registered for the driver to be able
to get and enable a clock. Currently the usb phy clocks are registered
form board files, which will not be called during a device tree based
boot.
To be able to probe correctly usb form a device tree boot, register
the usb phy clocks form the SoC specific init.
Unfourtunatly, davinci does not have proper clock support on device tree
yet, so by registering the clock form de SoC specific file we are
forced to hardcode the parent clock, and cannot select refclkin as
parent for any of the phy clocks of the da850 family.
As none of the current da850 based boards currently in mainline use
refclkin as source. I guess we can live with this limitation until clocks
are correctly represented through CCF/device tree.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 10 --
arch/arm/mach-davinci/da850.c | 2 ++
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 8d72bc1..a78fa16 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -187,16 +187,6 @@ static __init void omapl138_hawk_usb_init(void)
{
int ret;
- /* USB_REFCLKIN is not used. */
- ret = da8xx_register_usb20_phy_clk(false);
- if (ret)
- pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
- __func__, ret);
- ret = da8xx_register_usb11_phy_clk(false);
- if (ret)
- pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
- __func__, ret);
-
ret = da8xx_register_usb_phy();
if (ret)
pr_warn("%s: USB PHY registration failed: %d\n",
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index ed3d0e9..621880d 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1350,4 +1350,6 @@ void __init da850_init(void)
__raw_writel(v, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG));
davinci_clk_init(davinci_soc_info_da850.cpu_clks);
+ da8xx_register_usb20_phy_clk(false);
+ da8xx_register_usb11_phy_clk(false);
}
--
2.7.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/RFT 03/12] ARM: davinci: rename root_hub to platform_data
From: Axel Haslam
To prepare for DT support we will remove the usb callback function
pointers. Since this structure will only pass data to the driver, It
seems better to rename the structure root_hub structure to platform_data
There is no functional change.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 2 +-
drivers/usb/host/ohci-da8xx.c | 36 ++---
include/linux/platform_data/usb-davinci.h | 6 ++---
6 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index c62766e..18d2b10 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -87,7 +87,7 @@ static int da830_evm_usb_ocic_notify(da8xx_ocic_handler_t
handler)
return error;
}
-static struct da8xx_ohci_root_hub da830_evm_usb11_pdata = {
+static struct da8xx_ohci_platform_data da830_evm_usb11_pdata = {
.set_power = da830_evm_usb_set_power,
.get_power = da830_evm_usb_get_power,
.get_oci= da830_evm_usb_get_oci,
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 1dc6112..a2bf3eb 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -226,7 +226,7 @@ static int hawk_usb_ocic_notify(da8xx_ocic_handler_t
handler)
return error;
}
-static struct da8xx_ohci_root_hub omapl138_hawk_usb11_pdata = {
+static struct da8xx_ohci_platform_data omapl138_hawk_usb11_pdata = {
.set_power = hawk_usb_set_power,
.get_power = hawk_usb_get_power,
.get_oci= hawk_usb_get_oci,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index 38d932e..f7d6fd9 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -94,7 +94,7 @@ int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
-int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
+int da8xx_register_usb11(struct da8xx_ohci_platform_data *pdata);
int da8xx_register_emac(void);
int da8xx_register_uio_pruss(void);
int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c
b/arch/arm/mach-davinci/usb-da8xx.c
index 982e105..36e3460 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -337,7 +337,7 @@ static struct platform_device da8xx_usb11_device = {
.resource = da8xx_usb11_resources,
};
-int __init da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata)
+int __init da8xx_register_usb11(struct da8xx_ohci_platform_data *pdata)
{
da8xx_usb11_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_usb11_device);
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 3656d7c..8ed9a52 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -64,20 +64,20 @@ static void ohci_da8xx_disable(void)
/*
* Handle the port over-current indicator change.
*/
-static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub,
+static void ohci_da8xx_ocic_handler(struct da8xx_ohci_platform_data *pdata,
unsigned port)
{
ocic_mask |= 1 << port;
/* Once over-current is detected, the port needs to be powered down */
- if (hub->get_oci(port) > 0)
- hub->set_power(port, 0);
+ if (pdata->get_oci(port) > 0)
+ pdata->set_power(port, 0);
}
static int ohci_da8xx_init(struct usb_hcd *hcd)
{
struct device *dev = hcd->self.controller;
- struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
+ struct da8xx_ohci_platform_data *pdata = dev_get_platdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
int result;
u32 rh_a;
@@ -107,16 +107,16 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
* the correct hub descriptor...
*/
rh_a = ohci_readl(ohci, &ohci->regs->roothub.a);
- if (hub->set_power) {
+ if (pdata->set_power) {
rh_a &= ~RH_A_NPS;
rh_a |= RH_A_PSM;
}
- if (hub->get_oci) {
+ if (pdata->get_oci) {
rh_a &= ~RH_A_NOCP;
rh_a |= RH_A_OCPM;
}
rh_a &= ~RH_A_POTPGT;
- rh_a |= hub->potpgt << 24;
+ rh_a |= pdata->potpgt << 24;
ohci_writel(ohci, rh_a, &ohci->regs->roothub.a);
return result;
@@ -167,7
[PATCH/RFT 10/12] USB: ohci-da8xx: Add device tree support
From: Axel Haslam
This allows the controller to be specified via device tree.
Signed-off-by: Axel Haslam
---
drivers/usb/host/ohci-da8xx.c | 52 +--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index d7a0f11..10db421 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_ARCH_DAVINCI_DA8XX
#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
@@ -311,6 +312,47 @@ static const struct hc_driver ohci_da8xx_hc_driver = {
/*-*/
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_ohci_ids[] = {
+ { .compatible = "ti,da830-ohci" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da8xx_ohci_ids);
+
+static int ohci_da8xx_of_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct da8xx_ohci_platform_data *pdata;
+ u32 tmp;
+
+ if (!np)
+ return 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->gpio_vbus = of_get_named_gpio(np, "vbus-gpio", 0);
+ if (pdata->gpio_vbus >= 0)
+ pdata->flags |= DA8XX_OHCI_FLAG_GPIO_VBUS;
+
+ pdata->gpio_overcurrent = of_get_named_gpio(np, "oci-gpio", 0);
+ if (pdata->gpio_overcurrent >= 0)
+ pdata->flags |= DA8XX_OHCI_FLAG_GPIO_OCI;
+
+ if (!of_property_read_u32(np, "power-on-delay", &tmp))
+ pdata->potpgt = tmp;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+#else
+static int ohci_da8xx_of_init(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
/**
* usb_hcd_da8xx_probe - initialize DA8xx-based HCDs
@@ -323,12 +365,17 @@ static const struct hc_driver ohci_da8xx_hc_driver = {
static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
struct platform_device *pdev)
{
- struct da8xx_ohci_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct da8xx_ohci_platform_data *pdata;
struct usb_hcd *hcd;
struct resource *mem;
int error, irq;
- if (pdata == NULL)
+ error = ohci_da8xx_of_init(pdev);
+ if (error)
+ pr_err("error initializing platform data: %d\n", error);
+
+ pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata)
return -ENODEV;
usb11_clk = devm_clk_get(&pdev->dev, "usb11");
@@ -498,6 +545,7 @@ static struct platform_driver ohci_hcd_da8xx_driver = {
#endif
.driver = {
.name = "ohci",
+ .of_match_table = da8xx_ohci_ids,
},
};
--
2.7.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/RFT 04/12] USB: ohci-da8xx: Divide power up time in the ohci driver
From: Axel Haslam
Instead of requiring platform data to know that the effective time
should be diveded by two, Make that operation in the driver so that
users (platform board files/Device tree) dont have to worry about it.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
drivers/usb/host/ohci-da8xx.c | 8 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 18d2b10..8d126e4 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -94,7 +94,7 @@ static struct da8xx_ohci_platform_data da830_evm_usb11_pdata
= {
.ocic_notify= da830_evm_usb_ocic_notify,
/* TPS2065 switch @ 5V */
- .potpgt = (3 + 1) / 2, /* 3 ms max */
+ .potpgt = 3,/* 3 ms max */
};
static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a2bf3eb..f9cd388 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -232,7 +232,7 @@ static struct da8xx_ohci_platform_data
omapl138_hawk_usb11_pdata = {
.get_oci= hawk_usb_get_oci,
.ocic_notify= hawk_usb_ocic_notify,
/* TPS2087 switch @ 5V */
- .potpgt = (3 + 1) / 2, /* 3 ms max */
+ .potpgt = 3 /* 3 ms max */
};
static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 8ed9a52..3c85d6c 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -115,8 +115,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
rh_a &= ~RH_A_NOCP;
rh_a |= RH_A_OCPM;
}
- rh_a &= ~RH_A_POTPGT;
- rh_a |= pdata->potpgt << 24;
+
+ if (pdata->potpgt) {
+ rh_a &= ~RH_A_POTPGT;
+ rh_a |= (DIV_ROUND_UP(pdata->potpgt, 2) << 24);
+ }
+
ohci_writel(ohci, rh_a, &ohci->regs->roothub.a);
return result;
--
2.7.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/RFT 09/12] usb: host: ohci-da8xx: Add devicetree bindings documentation
From: Axel Haslam
This patch documents the device tree bindings required for
the ohci controller found in TI da8xx family of SoC's
Signed-off-by: Axel Haslam
---
.../devicetree/bindings/usb/ohci-da8xx.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
new file mode 100644
index 000..e954ce5
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
@@ -0,0 +1,32 @@
+DA8XX USB OHCI controller
+
+Required properties:
+
+ - compatible: Should be "ti,da830-ohci"
+ - reg:Should contain one register range i.e. start and length
+ - interrupts: Description of the interrupt line
+ - phys: Phandle for the PHY device
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+ - vbus-gpio: If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+ - oci-gpio: If present, specifies a gpio that needs to be
+ activated for the overcurrent detection.
+ - power_on_delay: Power On to Power Good time - in ms.
+
+Example for omap138-lck:
+
+usb_phy: usb-phy {
+compatible = "ti,da830-usb-phy";
+#phy-cells = <1>;
+status = "disabled";
+};
+usb11: usb11@0225000 {
+compatible = "ti,da830-ohci";
+reg = <0x225000 0x1000>;
+interrupts = <59>;
+phys = <&usb_phy 1>;
+phy-names = "usb-phy";
+status = "disabled";
+};
--
2.7.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/RFT 02/12] ARM: davinci: hawk: add full constraints for ohci plat boot
From: Axel Haslam
The phy framework requests an optional "phy" regulator. If it does
not find one, it returns -EPROBE_DEFER. In the case of non-DT based boot
for the omap138-lcdk board, this would prevent the usb11 phy to probe
correctly and ohci would not enumerate.
By calling "regulator_has_full_constraints", An error would be returned
instead of DEFER for the "optional" regulator, and the probe of
the phy driver can continue normally without a regulator.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index c5cb8d9..1dc6112 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -328,6 +329,7 @@ static __init void omapl138_hawk_init(void)
if (ret)
pr_warn("%s: dsp/rproc registration failed: %d\n",
__func__, ret);
+ regulator_has_full_constraints();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
2.7.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/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver
From: Axel Haslam
Currently requesting the vbus and overcurrent gpio is handled on
the board specific file. But this does not play well moving to
device tree.
In preparation to migrate to a device tree boot, handle requesting
gpios and overcurrent interrupt on the usb driver itself, thus avoiding
callbacks to arch/mach*
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-da830-evm.c | 71 ++-
arch/arm/mach-davinci/board-omapl138-hawk.c | 11
drivers/usb/host/ohci-da8xx.c | 90 +++--
include/linux/platform_data/usb-davinci.h | 16 +++--
4 files changed, 82 insertions(+), 106 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 8d126e4..cfba9fa 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -47,62 +47,15 @@ static const short da830_evm_usb11_pins[] = {
-1
};
-static da8xx_ocic_handler_t da830_evm_usb_ocic_handler;
-
-static int da830_evm_usb_set_power(unsigned port, int on)
-{
- gpio_set_value(ON_BD_USB_DRV, on);
- return 0;
-}
-
-static int da830_evm_usb_get_power(unsigned port)
-{
- return gpio_get_value(ON_BD_USB_DRV);
-}
-
-static int da830_evm_usb_get_oci(unsigned port)
-{
- return !gpio_get_value(ON_BD_USB_OVC);
-}
-
-static irqreturn_t da830_evm_usb_ocic_irq(int, void *);
-
-static int da830_evm_usb_ocic_notify(da8xx_ocic_handler_t handler)
-{
- int irq = gpio_to_irq(ON_BD_USB_OVC);
- int error = 0;
-
- if (handler != NULL) {
- da830_evm_usb_ocic_handler = handler;
-
- error = request_irq(irq, da830_evm_usb_ocic_irq,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
- "OHCI over-current indicator", NULL);
- if (error)
- pr_err("%s: could not request IRQ to watch over-current
indicator changes\n",
- __func__);
- } else
- free_irq(irq, NULL);
-
- return error;
-}
-
static struct da8xx_ohci_platform_data da830_evm_usb11_pdata = {
- .set_power = da830_evm_usb_set_power,
- .get_power = da830_evm_usb_get_power,
- .get_oci= da830_evm_usb_get_oci,
- .ocic_notify= da830_evm_usb_ocic_notify,
-
+ .gpio_vbus = ON_BD_USB_DRV,
+ .gpio_overcurrent = ON_BD_USB_OVC,
+ .flags = (DA8XX_OHCI_FLAG_GPIO_VBUS
+ | DA8XX_OHCI_FLAG_GPIO_OCI),
/* TPS2065 switch @ 5V */
.potpgt = 3,/* 3 ms max */
};
-static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
-{
- da830_evm_usb_ocic_handler(&da830_evm_usb11_pdata, 1);
- return IRQ_HANDLED;
-}
-
static __init void da830_evm_usb_init(void)
{
int ret;
@@ -143,22 +96,6 @@ static __init void da830_evm_usb_init(void)
return;
}
- ret = gpio_request(ON_BD_USB_DRV, "ON_BD_USB_DRV");
- if (ret) {
- pr_err("%s: failed to request GPIO for USB 1.1 port power
control: %d\n",
- __func__, ret);
- return;
- }
- gpio_direction_output(ON_BD_USB_DRV, 0);
-
- ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC");
- if (ret) {
- pr_err("%s: failed to request GPIO for USB 1.1 port
over-current indicator: %d\n",
- __func__, ret);
- return;
- }
- gpio_direction_input(ON_BD_USB_OVC);
-
ret = da8xx_register_usb11(&da830_evm_usb11_pdata);
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 075be1b..8d72bc1 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -178,11 +178,6 @@ static __init void omapl138_hawk_mmc_init(void)
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
-static const short da850_hawk_usb11_pins[] = {
- DA850_GPIO2_4, DA850_GPIO6_13,
- -1
-};
-
static struct da8xx_ohci_platform_data omapl138_hawk_usb11_pdata = {
/* TPS2087 switch @ 5V */
.potpgt = 3 /* 3 ms max */
@@ -192,12 +187,6 @@ static __init void omapl138_hawk_usb_init(void)
{
int ret;
- ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
- if (ret) {
- pr_warn("%s: USB 1.1 PinMux setup failed: %d\n", __func__, ret);
- return;
- }
-
/* USB_REFCLKIN is not used. */
ret = da8xx_register_usb20_phy_clk(false);
if (ret)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 9d9f8e3..d7a0f11 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -17,6
[PATCH/RFT 12/12] ARM: dts: da850-lcdk: enable ohci usb
From: Axel Haslam
This enables the ohci usb controller for the lcdk board.
Signed-off-by: Axel Haslam
---
arch/arm/boot/dts/da850-lcdk.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..6da9d843 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -86,6 +86,15 @@
};
};
+&usb_phy {
+ status = "okay";
+};
+
+&usb11 {
+ status = "okay";
+ power-on-delay = <3>;
+};
+
&serial2 {
pinctrl-names = "default";
pinctrl-0 = <&serial2_rxtx_pins>;
--
2.7.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/RFT 06/12] ARM: davinci: hawk: Remove oci and vbus gpios
From: Axel Haslam
The omap138-lcdk and its predecessor the hawk board don't have gpios
connected to control vbus or get the over current notifications for usb.
for example, in the hawk board gpio6-13 is connected to a LED, and
gpio2-4 is not connected at all. In the lcdk board, gpio 2-4 is a push
button, and gpio6-13 is connected to a LED.
Remove the gpio and interrupt registration for these pins.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 78 +
1 file changed, 1 insertion(+), 77 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index f9cd388..075be1b 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -28,9 +28,6 @@
#define DA850_HAWK_MMCSD_CD_PINGPIO_TO_PIN(3, 12)
#define DA850_HAWK_MMCSD_WP_PINGPIO_TO_PIN(3, 13)
-#define DA850_USB1_VBUS_PINGPIO_TO_PIN(2, 4)
-#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
-
static short omapl138_hawk_mii_pins[] __initdata = {
DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
@@ -181,66 +178,16 @@ static __init void omapl138_hawk_mmc_init(void)
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
-static da8xx_ocic_handler_t hawk_usb_ocic_handler;
-
static const short da850_hawk_usb11_pins[] = {
DA850_GPIO2_4, DA850_GPIO6_13,
-1
};
-static int hawk_usb_set_power(unsigned port, int on)
-{
- gpio_set_value(DA850_USB1_VBUS_PIN, on);
- return 0;
-}
-
-static int hawk_usb_get_power(unsigned port)
-{
- return gpio_get_value(DA850_USB1_VBUS_PIN);
-}
-
-static int hawk_usb_get_oci(unsigned port)
-{
- return !gpio_get_value(DA850_USB1_OC_PIN);
-}
-
-static int hawk_usb_ocic_notify(da8xx_ocic_handler_t handler)
-{
- int irq = gpio_to_irq(DA850_USB1_OC_PIN);
- int error = 0;
-
- if (handler != NULL) {
- hawk_usb_ocic_handler = handler;
-
- error = request_irq(irq, omapl138_hawk_usb_ocic_irq,
- IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
- "OHCI over-current indicator", NULL);
- if (error)
- pr_err("%s: could not request IRQ to watch "
- "over-current indicator changes\n", __func__);
- } else {
- free_irq(irq, NULL);
- }
- return error;
-}
-
static struct da8xx_ohci_platform_data omapl138_hawk_usb11_pdata = {
- .set_power = hawk_usb_set_power,
- .get_power = hawk_usb_get_power,
- .get_oci= hawk_usb_get_oci,
- .ocic_notify= hawk_usb_ocic_notify,
/* TPS2087 switch @ 5V */
.potpgt = 3 /* 3 ms max */
};
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
-{
- hawk_usb_ocic_handler(&omapl138_hawk_usb11_pdata, 1);
- return IRQ_HANDLED;
-}
-
static __init void omapl138_hawk_usb_init(void)
{
int ret;
@@ -266,34 +213,11 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- ret = gpio_request_one(DA850_USB1_VBUS_PIN,
- GPIOF_DIR_OUT, "USB1 VBUS");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "power control: %d\n", __func__, ret);
- return;
- }
-
- ret = gpio_request_one(DA850_USB1_OC_PIN,
- GPIOF_DIR_IN, "USB1 OC");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "over-current indicator: %d\n", __func__, ret);
- goto usb11_setup_oc_fail;
- }
-
ret = da8xx_register_usb11(&omapl138_hawk_usb11_pdata);
- if (ret) {
+ if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
- goto usb11_setup_fail;
- }
return;
-
-usb11_setup_fail:
- gpio_free(DA850_USB1_OC_PIN);
-usb11_setup_oc_fail:
- gpio_free(DA850_USB1_VBUS_PIN);
}
static __init void omapl138_hawk_init(void)
--
2.7.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/RFT 11/12] ARM: dts: da850: Add the usb ohci device node
From: Axel Haslam
This adds the device tree node for the usb11 (ohci)
controller present in the da850 family of SoC's.
Signed-off-by: Axel Haslam
---
arch/arm/boot/dts/da850.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 33fcdce..afae565 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -381,6 +381,14 @@
#phy-cells = <1>;
status = "disabled";
};
+ usb11: usb11@0225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.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/RFT 00/12] Add DT support for ohci-da8xx
From: Axel Haslam The purpose of this patch series is to add DT support to the ohci-da8xx glue driver without breaking the non-DT boot, which is still used in unconverted davinci devices. To Achieve this, the first 8 patches make sure that the non-DT based enumeration works, and prepares the stage for a DT migration by removing dependencies on the board files (moving VBUS, and over current handling to the driver). The last 4 patches actually add the DT documentation and bindings for the ohci-da8xx driver. Testing was done on a omap138-lcdk board, using DT, and non-DT boot, and checking that in both cases the hub, usb mass storage and an input device are correctly enumerated and working. Since there have been some recent and ongoing efforts from David Lechner to clean up davinci-mach code and the ochi-da8xx driver, this series builds upon that work. Specifically: * the accepted but soon to be reposted patch to remove mach code form the ohci driver[1]. * The patch series to add phy nodes, and move usb clocks to a common file [2]. A git branch based on tag: next-20161004 with the dependencies patches is available in my github here [3]. The omap138-lcdk does not have gpios to control vbus and get over current interrupt notifications, hence i was not able to test these and added the RFT tag. If anyone has a da830-evm based board and could confirm that ohci is correctly working, i would appreciate it. (the OHCI option needs to be enabled in menuconfig) P.D: It seems that the davinci-gpio driver is broken for DT based boot and any gpio > 32. (luckly none of the DT based boards use gpios yet) The probelm is that we have 144 gpios in the gpio controller as correctly declared on the DT (they are not separate gpio controllers as in am3xx), but the driver creates several gpio chips of 32 pins each, confusing the "gpio chip to pin" matching logic of gpiolib-of. I think we might need to fix this by creating a single gpio chip in gpio-davinci.c [1] [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach http://www.gossamer-threads.com/lists/linux/kernel/2518807 [2] [PATCH v5 0/5] da8xx USB PHY platform devices and clocks (was "da8xx UBS clocks") http://www.spinics.net/lists/linux-usb/msg140568.html [3] github branch with all dependante patches https://github.com/axelhaslamx/linux-axel/commits/ohci-da8xx-dt Axel Haslam (12): ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable ARM: davinci: hawk: add full constraints for ohci plat boot ARM: davinci: rename root_hub to platform_data USB: ohci-da8xx: Divide power up time in the ohci driver USB: ohci-da8xx: Fix probe for devices with no vbus/oci gpio ARM: davinci: hawk: Remove oci and vbus gpios USB: ohci-da8xx: Request gpios and handle interrupt in the driver ARM: davinci: register the usb20_phy clock on the SoC file usb: host: ohci-da8xx: Add devicetree bindings documentation USB: ohci-da8xx: Add device tree support ARM: dts: da850: Add the usb ohci device node ARM: dts: da850-lcdk: enable ohci usb .../devicetree/bindings/usb/ohci-da8xx.txt | 32 + arch/arm/boot/dts/da850-lcdk.dts | 9 ++ arch/arm/boot/dts/da850.dtsi | 8 ++ arch/arm/mach-davinci/board-da830-evm.c| 75 +- arch/arm/mach-davinci/board-omapl138-hawk.c| 105 +- arch/arm/mach-davinci/da850.c | 2 + arch/arm/mach-davinci/include/mach/da8xx.h | 2 +- arch/arm/mach-davinci/usb-da8xx.c | 15 +- drivers/usb/host/ohci-da8xx.c | 158 + include/linux/platform_data/usb-davinci.h | 22 ++- 10 files changed, 218 insertions(+), 210 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt -- 2.7.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/RFT 01/12] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable
From: Axel Haslam
While probing ochi phy with usb20 phy as a parent clock for usb11_phy,
the usb20_phy clock enable would time out. This is because the usb20
module clock needs to enabled while trying to lock the usb20_phy PLL.
Call clk enable and get for the usb20 peripheral before trying to
enable the phy PLL.
Signed-off-by: Axel Haslam
---
arch/arm/mach-davinci/usb-da8xx.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/usb-da8xx.c
b/arch/arm/mach-davinci/usb-da8xx.c
index 9e41a7f..982e105 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -53,11 +53,19 @@ int __init da8xx_register_usb_refclkin(int rate)
static void usb20_phy_clk_enable(struct clk *clk)
{
+ struct clk *usb20_clk;
u32 val;
u32 timeout = 50; /* 500 msec */
val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ usb20_clk = clk_get(NULL, "usb20");
+ if (IS_ERR(usb20_clk)) {
+ pr_err("could not get usb20 clk\n");
+ return;
+ }
+
+ clk_prepare_enable(usb20_clk);
/*
* Turn on the USB 2.0 PHY, but just the PLL, and not OTG. The USB 1.1
* host may use the PLL clock without USB 2.0 OTG being used.
@@ -70,11 +78,14 @@ static void usb20_phy_clk_enable(struct clk *clk)
while (--timeout) {
val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
if (val & CFGCHIP2_PHYCLKGD)
- return;
+ goto done;
udelay(1);
}
pr_err("Timeout waiting for USB 2.0 PHY clock good.\n");
+done:
+ clk_disable_unprepare(usb20_clk);
+ clk_put(usb20_clk);
}
static void usb20_phy_clk_disable(struct clk *clk)
--
2.7.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 v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Fri, Oct 07, 2016 at 04:31:26PM +0100, Martyn Welch wrote: > Also, if an output can only be open-drain, attempting to set the pin as > push-pull succeeds because gpiolib (currently) assumes that a pin can > always be p-p and doesn't even check the return value of it's call to > .set_single_ended: > > >/* Make sure to disable open drain/source hardware, if any */ > if (gc->set_single_ended) > gc->set_single_ended(gc, > gpio_chip_hwgpio(desc), > LINE_MODE_PUSH_PULL); > > > This is clearly a separate issue. > A bit of testing also show that a "open-drain only" output will succeed when an open-source output driven high is requested. Rather than having a pin pulled hard to VCC, we have a pin pulled to VCC via a resistor and thus (if there are other devices connected to the pin pulling to GND via a resistor, which would kinda stand to reason given the pin is being configured for open-source mode) we have the signal floating at a voltage determined by the effect of the two sets of resistors acting as a voltage divider. Martyn -- 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/RFT 11/12] ARM: dts: da850: Add the usb ohci device node
Hello.
On 10/07/2016 07:42 PM, ahas...@baylibre.com wrote:
From: Axel Haslam
This adds the device tree node for the usb11 (ohci)
controller present in the da850 family of SoC's.
Signed-off-by: Axel Haslam
---
arch/arm/boot/dts/da850.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 33fcdce..afae565 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -381,6 +381,14 @@
#phy-cells = <1>;
status = "disabled";
};
+ usb11: usb11@0225000 {
No, usb@ to comply with the DT spec the node names should be
generic.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] hid: hid-led: fix issue with transfer buffer not being dma capable
Am 07.10.2016 um 18:22 schrieb Benjamin Tissoires:
> On Oct 03 2016 or thereabouts, Heiner Kallweit wrote:
>> The hid-led driver works fine under 4.8.0, however with the next
>> kernel from today I get this:
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584
>> usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
>> transfer buffer not dma capable
>> Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm
>> led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic
>> x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801
>> i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169
>> snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core
>> btusb btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd
>> xhci_pci xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
>> CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
>> Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
>> c90003dbb7e0 81280425 c90003dbb830
>> c90003dbb820 8105b086 063003dbb800 88006f374480
>> 0001 880079544000
>> Call Trace:
>> [] dump_stack+0x68/0x93
>> [] __warn+0xc6/0xe0
>> [] warn_slowpath_fmt+0x4a/0x50
>> [] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
>> [] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
>> [] ? rcu_read_lock_sched_held+0x40/0x80
>> [] ? module_assert_mutex_or_preempt+0x13/0x50
>> [] ? __module_address+0x27/0xf0
>> [] usb_submit_urb+0x2c4/0x520 [usbcore]
>> [] usb_start_wait_urb+0x5a/0xe0 [usbcore]
>> [] usb_control_msg+0xbc/0xf0 [usbcore]
>> [] ? __module_address+0x27/0xf0
>> [] usbhid_raw_request+0xa4/0x180 [usbhid]
>> [] hidled_recv+0x71/0xe0 [hid_led]
>> [] thingm_init+0x2d/0x50 [hid_led]
>> [] hidled_probe+0xcb/0x24a [hid_led]
>> [] hid_device_probe+0xd2/0x150
>> [] driver_probe_device+0x1fd/0x2c0
>> [] __driver_attach+0x9a/0xa0
>> [] ? driver_probe_device+0x2c0/0x2c0
>> [] bus_for_each_dev+0x5d/0x90
>> [] driver_attach+0x19/0x20
>> [] bus_add_driver+0x11f/0x220
>> [] ? 0xa07ac000
>> [] driver_register+0x5b/0xd0
>> [] ? 0xa07ac000
>> [] __hid_register_driver+0x61/0xa0
>> [] hidled_driver_init+0x1e/0x20 [hid_led]
>> [] do_one_initcall+0x38/0x150
>> [] ? rcu_read_lock_sched_held+0x40/0x80
>> [] ? kmem_cache_alloc_trace+0x1d0/0x230
>> [] do_init_module+0x5a/0x1cb
>> [] load_module+0x1e42/0x2530
>> [] ? __symbol_put+0x50/0x50
>> [] ? show_coresize+0x30/0x30
>> [] ? kernel_read_file+0x100/0x190
>> [] ? kernel_read_file_from_fd+0x44/0x70
>> [] SYSC_finit_module+0xba/0xc0
>> [] SyS_finit_module+0x9/0x10
>> [] entry_SYSCALL_64_fastpath+0x18/0xad
>> ---[ end trace c9e6ea27003ecf9e ]---
>>
>> Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>> v2:
>> - Based on a comment from Alan Stern allocate the buffer to be provided to
>> hid_hw_raw_request separately (and not as part of struct hidled_device).
>> Alternative would have been to allocate the buffer dynamically in each
>> function calling hidled_send/_recv. However this would mean more overhead
>> IMHO, and we'd need an error path in callers to free the buffer in case
>> of an error.
>> In addition we have better control that a proper buffer is used in case
>> the driver is extended by somebody for supporting another LED device.
>> ---
>
> Looks like the receive function is only called from .probe(), so this
> should be safe.
> However, for the send function, is there a chance there can be a
> concurrent access of the buffer? (like 2 userspace processes writing a
> different values at the same time).
>
Buffer ldev->buf is accessed with mutex ldev->lock held in hidled_send.
So the locking exists already.
> If so, then you'll need to add a locking mechanism (can't recall if the
> LED API provide one for us or not), or just alloc/free the buffers
> directly.
>
> If no, the patch is:
> Reviewed-by: Benjamin Tissoires
>
> Cheers,
> Benjamin
>
>> drivers/hid/hid-led.c | 23 +++
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/hid/hid-led.c b/drivers/hid/hid-led.c
>> index d8d55f3..555c88e 100644
>> --- a/drivers/hid/hid-led.c
>> +++ b/drivers/hid/hid-led.c
>> @@ -100,6 +100,7 @@ struct hidled_device {
>> const struct hidled_config *config;
>> struct hid_device *hdev;
>> struct hidled_rgb *rgb;
>> +u8 *buf;
>> struct mutexlock;
>> };
>>
>> @@ -118,13 +119,19 @@ static int hidled_send(struct hidled_device *ldev,
>> __u8 *buf)
>>
>> mutex_lock(&ldev->lock);
>>
>> +/*
>> + * buffer provided to hid_hw_raw_request must not be on the stack
>> + * and must not be part of a data structure
>> + */
>> +
[PATCH] usb: dwc3: Fix size used in dma_free_coherent()
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.
This has been spotted with coccinelle, using the following script:
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: Christophe JAILLET
---
Untested
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 07cc8929f271..01d388ea9115 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2980,7 +2980,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
kfree(dwc->setup_buf);
err2:
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
err1:
@@ -3005,7 +3005,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
kfree(dwc->zlp_buf);
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Felipe, On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > Hi, > > Michael Niewöhner writes: > > > > > > > > The clocks are same across working/non-working. > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init > > and exit paths > > This patch causes both the hang on reboot and the lsusb hang. > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > guessing this is failed bisection, as I can't see anything in that > commit that would cause reboot hang. Also, that code path is *NOT* > executed when you run lsusb. > I've tested this procedure multiple times to be sure: - checkout c499ff71, compile, boot the odroid - run lsusb -v => lsusb hangs, can't terminate with ctrl-c - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below) - revert c499ff71, mrproper, compile, boot the odroid - run lsusb -v => shows full output, not hanging - run reboot or poweroff => board powers off / reboots just fine dmesg poweroff not working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. => at this point removing the sd card would show a message "removed mmc0" (not sure what the real message was...) so the board is not completely off. dmesg poweroff working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. [ 121.182331] rebo� Best regards Michael
USB crash on BeagleBoard-xM
Hi, This is on a BeagleBoard-xM with a fresh image from https://eewiki.net/display/linuxonarm/BeagleBoard. I attach the output of dmesg after booting. Some seconds after booting USB seems to crash, since the keyboard no longer works. The board seems to continue alive. The ethernet interface does not seem to work (it is USB based, right?). The lights are out. -- João M. S. Silva [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.8.0-rc6-armv7-x2 (jmss@faust) (gcc version 6.1.1 20160711 (Linaro GCC 6.1-2016.08-rc2) ) #1 SMP Sun Sep 18 01:43:35 WEST 2016 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt:Machine model: TI OMAP3 BeagleBoard xM [0.00] cma: Reserved 24 MiB at 0x9e00 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 130560 [0.00] free_area_init_node: node 0, pgdat c162fdc0, node_mem_map df96d000 [0.00] Normal zone: 1152 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 130560 pages, LIFO batch:31 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] percpu: Embedded 15 pages/cpu @df8f6000 s30924 r8192 d22324 u61440 [0.00] pcpu-alloc: s30924 r8192 d22324 u61440 alloc=15*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129408 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 469328K/522240K available (12288K kernel code, 1429K rwdata, 4976K rodata, 2048K init, 744K bss, 28336K reserved, 24576K cma-reserved, 0K highmem) [0.00] Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xe080 - 0xff80 ( 496 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc0d0 (13280 kB) .init : 0xc130 - 0xc150 (2048 kB) .data : 0xc150 - 0xc16657f4 (1430 kB) .bss : 0xc1667000 - 0xc172105c ( 745 kB) [0.00] Hierarchical RCU implementation. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] clocksource: 32k_counter: mask: 0x max_cycles: 0x, max_idle_ns: 58327039986419 ns [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 6553584741ns [0.30] OMAP clocksource: 32k_counter at 32768 Hz [0.008392] Console: colour dummy device 80x30 [0.008453] WARNING: Your 'console=ttyO2' has been replaced by 'ttyS2' [0.008453] This ensures that you still see kernel messages. Please [0.008453] update your kernel commandline. [0.008514] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032) [0.059936] pid_max: default: 32768 minimum: 301 [0.060241] Security Framework initialized [0.060241] Yama: becoming mindful. [0.060302] AppArmor: AppArmor disabled by boot time parameter [0.060546] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.060577] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.061950] CPU: Testing write buffer coherency: ok [0.062042] ftrace: allocating 41160 entries in 121 pages [0.246185] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.246276] Setting up static identity map for 0x8010 - 0x80100098 [0.257904] Brought up 1 CPUs [0.257934] SMP: Total of 1 processors activated (597.60 BogoMIPS). [0.257934] CPU: All CPU(s) started in SVC mode. [0.260223] devtmpfs: initialized [0.321777] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [0.322479] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.324523] xor: measuring software checksum speed [0.419189]arm4regs : 730.000 MB/se
Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
On Thu, Sep 22, 2016 at 12:02 AM, Sriram Dash wrote:
>>From: Arnd Bergmann [mailto:a...@arndb.de]
>>On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
>>> >From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday, September
>>> >21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>>
>>> ==
>>> From 8b0dea1513e9e73a11dcfa802ddc71cca11d66f8 Mon Sep 17 00:00:00 2001
>>> From: Sriram Dash
>>> Date: Wed, 21 Sep 2016 11:39:30 +0530
>>> Subject: [PATCH] usb: xhci: Fix the patch inherit dma configuration
>>> from parent dev
>>>
>>> Fixes the patch https://patchwork.kernel.org/patch/9319527/
>>> ("usb: dwc3: host: inherit dma configuration from parent dev").
>>>
>>> Signed-off-by: Sriram Dash
>>> ---
>>> drivers/usb/host/xhci-mem.c | 12 ++--
>>> drivers/usb/host/xhci.c | 20 ++--
>>> 2 files changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>>> index 6afe323..79608df 100644
>>> --- a/drivers/usb/host/xhci-mem.c
>>> +++ b/drivers/usb/host/xhci-mem.c
>>
>>All the changes you did to this file seem fine, I completely missed that part.
>>
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index
>>> 01d96c9..9a1ff09 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>
> Yes. Some sanity is required over this patch.
Hi Sriram,
Have you been able to do the sanity check on the patch? I will be
good to have the formal patch submitted for integration as soon as
possible because the dwc3 USB functionality has been broken for a
while in upstream kernel.
Regards,
Leo
--
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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Hi Neil, On 5 October 2016 at 18:44, NeilBrown wrote: > On Wed, Oct 05 2016, Felipe Balbi wrote: > >> Hi Baolin, >> >> Baolin Wang writes: > But you do! > The mA number from the USB configuration is passed to > usb_gadget_vbus_draw. > Your patch passes that to usb_charger_set_cur_limit_by_type() > which calls __usb_charger_set_cur_limit_by_type() which will set the > cur_limit for whichever type uchger->type currently is. > > So when it is not relevant, your code *does* set some current limit. Suppose the charger type is DCP(it is not relevant to the mA number from the USB configuration ), it will not do the USB enumeration, then no USB configuration from host to set current. >>> >>> From the talking, there are some issues (thanks for Neil's comments) >>> need to be fixed as below: >>> 1. Need to add the method getting charger type from extcon subsystem. >>> 2. Need to remove the method getting charger type from power supply. >>> 3. There are still some different views about reporting the maximum >>> current or minimum current to power driver. >>> >>> Now the current v16 patchset can work well on my Spreadtrum platform >>> and Jun's NXP platform, if you like to apply this patchset then I can > > I'm really curious how much testing this has had. Have you actually > plugged in different cable types (SDP DCP DCP ACA) and has each one been > detected correctly? Because I cannot see how that could happen with the > code you have posted. I transplanted the USB charger framework to our Spreadtrum platform with implementing the 'get_charger_type' callback to get the charger type in power driver. Cause we get the charger type from accessing the PMIC registers not from USB PHY. > >>> send out new patches to fix above issues. If you don't like that, I >>> can send out new version patchset to fix above issues. Could you give >>> me some suggestions what should I do next step? Thanks. >> >> Merge window just opened, nothing will happen for about 2 weeks. How >> about you send a new version after merge window closes and we go from >> there? Fixing 1 and 2 is needed. 3 we need to consider more >> carefully. Perhaps report both minimum and maximum somehow? >> >> Neil, comments? > > This probably seems a bit harsh, but I really think the current patchset > should be discarded and the the project started again with a clear > vision of what is required. What we currently have is too confused. Probably not. Now the USB charger framework tried to integrate all different charger plugged/unplugged events, and all different charger type getting methods, then noticed the plugged/unplugged events and charger current to power driver, which I think that is what USB charger should really do. Moreover, this patchset is reviewed and helped by many people (thanks Felipe, Greg, Mark, Peter and Jun), I really hope I can make it better to upstream. > > To respond to the points: >>> 1. Need to add the method getting charger type from extcon subsystem. > > Yes. This should be the only way to get the charger type. Not really. Like I said, some platform's charger detection is done by hardware not USB PHY, thus we can get the charger type from PMIC hardware registers. > >>> 2. Need to remove the method getting charger type from power supply. > > Also need to remove the ->get_charger_type() method as there is no > credible use-case for this. No. User can implement the get_charger_type() method to access the PMIC registers to get the charger type, which is one very common method. > >>> 3. There are still some different views about reporting the maximum >>> current or minimum current to power driver. > > I think those were resolved. There was some confusion over whether a > particular power manager wanted to be told the maximum or the minimum, > but I think both have a clear use case in different hardware. So, seems I should report both minimum and maximum. > > Also: We don't want another notifier_chain. The usb_notifier combined > with the extcon notifier are sufficient. Possibly it would be sensible > to replace the usb notifier with a new new notifier chain, but don't add > something without first cleaning up what is there. USB charger is one virtual device not one actual hardware device, we should not mess it together with usb_notifier or extcon notifier. > > Also: resolve the question of whether it could ever make sense to have > more than one "usb_charger" in a system. If it doesn't, make it an > obvious singleton. If it does, make it clear how the correct > usb_charger is chosen. Usually only one USB charger in one system, I have not seen more than one charger in a system. > > Also: think very carefully before exposing any details through sysfs. > Some of the details are already visible, either in sys/class/extcon > or sys/class/power_supply. Don't duplicate without good reason. I think now the current/state/type attributes are enough, which are USB char
