[PATCH] dwc2: wait for usb phy while probing
This patch adds support to return -EPROBE_DEFER if devm_phy_get reports
it. If devm_phy_get returns -EPROBE_DEFER it could be that there is some
usb phy but it's not probed before. Other return values should indicate
a looking for an "old style USB PHY".
Cc: John Youn
Cc: Greg Kroah-Hartman
Cc: Stephen Warren
Signed-off-by: Alexander Aring
---
drivers/usb/dwc2/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9093530..69258d0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -228,6 +228,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
*/
phy = devm_phy_get(&dev->dev, "usb2-phy");
if (IS_ERR(phy)) {
+ if (PTR_ERR(phy) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
hsotg->phy = NULL;
uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
if (IS_ERR(uphy))
--
2.6.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] fixing the coding style changes
On Sun, Oct 25, 2015 at 12:17:11PM +0530, saurabh wrote: > >From 999005638f8d3f95075fdfdc6bf8f7ff88810f5d Mon Sep 17 00:00:00 2001 > From: Saurabh Sengar > Date: Sun, 25 Oct 2015 08:58:42 +0530 > Subject: [PATCH] fixing the coding style changes > > Attached a patch whic fixes the checkpatch.pl script error > Here, couple of static variables were initialise to 0 which > was violating the linux coding style standards. > > diffstat for this patch is: > hub.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > To apply the patch, in the root of a kernel tree use: > patch -p1 < 0001-fixing-the-coding-style-changes.patch > > Signed-off-by: Saurabh Sengar > --- > drivers/usb/core/hub.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 431839b..6abc4ab 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -49,7 +49,7 @@ static void hub_event(struct work_struct *work); > DEFINE_MUTEX(usb_port_peer_mutex); > > /* cycle leds on hubs that aren't blinking for attention */ > -static bool blinkenlights = 0; > +static bool blinkenlights; > module_param(blinkenlights, bool, S_IRUGO); > MODULE_PARM_DESC(blinkenlights, "true to cycle leds on hubs"); > > @@ -78,7 +78,7 @@ MODULE_PARM_DESC(initial_descriptor_timeout, > * otherwise the new scheme is used. If that fails and "use_both_schemes" > * is set, then the driver will make another attempt, using the other scheme. > */ > -static bool old_scheme_first = 0; > +static bool old_scheme_first; > module_param(old_scheme_first, bool, S_IRUGO | S_IWUSR); > MODULE_PARM_DESC(old_scheme_first, >"start with the old device initialization scheme"); Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You sent multiple patches, yet no indication of which ones should be applied in which order. Greg could just guess, but if you are receiving this email, he guessed wrong and the patches didn't apply. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for a description of how to do this so that Greg has a chance to apply these correctly. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] USB: usbtmc: Add support for missing USBTMC-USB488 spec
On Mon, Oct 19, 2015 at 09:33:20AM +0200, dave penkler wrote: > > Implement support for the USB488 defined READ_STATUS_BYTE and SRQ > notifications with ioctl, fasync and poll/select in order to be able > to synchronize with variable duration instrument operations. > > Add ioctls for other USB488 requests: REN_CONTROL, GOTO_LOCAL and > LOCAL_LOCKOUT. > > Add convenience ioctl to return all device capabilities. Can you break this up into a series of patches, all doing only one thing? You are doing a lot of different things in this single patch, making it almost impossible to review :( thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade
On 2015-10-24 22:44, Michele Baldessari wrote:
The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
to have the two distinct joysticks working.
Before the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
jstest: No such file or directory
After the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
Signed-off-by: Michele Baldessari
---
drivers/hid/usbhid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0015ba..f69049314a2c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -150,6 +150,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES,
HID_QUIRK_MULTI_INPUT },
+ { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE,
HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
{ 0, 0 }
};
Sorry but I don't believe that XIN_MO is the owner of the 16c0 VID so
should not be given that ownership in linux.
/Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > Probe deferral is really noisy even if it's working fine on a given > system so it's constantly being highlighted to people in a way that > other issues aren't if you're not directly having problems. > > There's also the understanding people had that the order things get > bound changes the ordering for some of the other cases (perhaps it's a > good idea to do that, it seems likely to be sensible?). But it really doesn't do that. Also making it do so doesn't help much in the cases where things can happen asynchronously (system suspend/resume, runtime PM). If, instead, there was a way to specify a functional dependency at the device registration time, it might be used to change the order of everything relevant, including probe. That should help to reduce the noise you're referring to. If the dependency could only be discovered at the probe time, the order of things might be changed in response to letting the driver core know about it rather than "just in case", which should be more efficient. Thanks, Rafael -- 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] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade
On Sun, Oct 25, 2015 at 04:15:17PM +0700, Lars Melin wrote:
> On 2015-10-24 22:44, Michele Baldessari wrote:
> >The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
> >to have the two distinct joysticks working.
> >
> >Before the change:
> >$ jstest /dev/input/js0
> >Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> >...
> >$ jstest /dev/input/js1
> >jstest: No such file or directory
> >
> >After the change:
> >$ jstest /dev/input/js0
> >Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> >...
> >$ jstest /dev/input/js1
> >Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> >...
> >
> >Signed-off-by: Michele Baldessari
> >---
> > drivers/hid/usbhid/hid-quirks.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >diff --git a/drivers/hid/usbhid/hid-quirks.c
> >b/drivers/hid/usbhid/hid-quirks.c
> >index 1dff8f0015ba..f69049314a2c 100644
> >--- a/drivers/hid/usbhid/hid-quirks.c
> >+++ b/drivers/hid/usbhid/hid-quirks.c
> >@@ -150,6 +150,7 @@ static const struct hid_blacklist {
> > { USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD,
> > HID_QUIRK_MULTI_INPUT },
> > { USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES,
> > HID_QUIRK_MULTI_INPUT },
> > { USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES,
> > HID_QUIRK_MULTI_INPUT },
> >+{ USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE,
> >HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
> >
> > { 0, 0 }
> > };
> >
>
> Sorry but I don't believe that XIN_MO is the owner of the 16c0 VID so should
> not be given that ownership in linux.
The "ownership" of 16c0 is a completely orthogonal issue to this patch.
16c0 was already defined (twice actually):
$ grep -i 0x16c0 drivers/hid/hid-ids.h | awk '{ print $2 }'
USB_VENDOR_ID_ATMEL_V_USB
USB_VENDOR_ID_XIN_MO
cheers,
Michele
--
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: core: Codestyle fix in urb.c
Delete braces around single statement block suggested by checkpatch.pl
Signed-off-by: Jonas Hesselmann
---
drivers/usb/core/urb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index c9e8ee8..3d27477 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -129,9 +129,8 @@ void usb_anchor_urb(struct urb *urb, struct usb_anchor
*anchor)
list_add_tail(&urb->anchor_list, &anchor->urb_list);
urb->anchor = anchor;
- if (unlikely(anchor->poisoned)) {
+ if (unlikely(anchor->poisoned))
atomic_inc(&urb->reject);
- }
spin_unlock_irqrestore(&anchor->lock, flags);
}
--
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] dwc2: wait for usb phy while probing
Hello,
On Sun, Oct 25, 2015 at 08:57:31AM +0100, Alexander Aring wrote:
> This patch adds support to return -EPROBE_DEFER if devm_phy_get reports
> it. If devm_phy_get returns -EPROBE_DEFER it could be that there is some
> usb phy but it's not probed before. Other return values should indicate
> a looking for an "old style USB PHY".
>
> Cc: John Youn
> Cc: Greg Kroah-Hartman
> Cc: Stephen Warren
> Signed-off-by: Alexander Aring
> ---
> drivers/usb/dwc2/platform.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 9093530..69258d0 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -228,6 +228,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
>*/
> phy = devm_phy_get(&dev->dev, "usb2-phy");
> if (IS_ERR(phy)) {
> + if (PTR_ERR(phy) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
For gpios there are variants of devm_gpiod_get, that just return NULL
when no phy is specified in the device tree or the platform lookup
table. That would be devm_phy_get_optional(..) here. And this one would
just ignore -ENOENT which would be better here, too.
Best regards
Uwe
> hsotg->phy = NULL;
> uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
> if (IS_ERR(uphy))
> --
> 2.6.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] fixing the coding style changes
2015-10-25 4:47 GMT-02:00 saurabh : > From 999005638f8d3f95075fdfdc6bf8f7ff88810f5d Mon Sep 17 00:00:00 2001 > From: Saurabh Sengar > Date: Sun, 25 Oct 2015 08:58:42 +0530 > Subject: [PATCH] fixing the coding style changes You should read Documentation/SubmittingPatches for a description of how do. Albino -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] On-demand device probing
On 10/23/2015 10:45 AM, Tim Bird wrote: I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) It has a bogosort kind of elegance. :) Also this might be a silly question (I haven't been following this issue for very long), but as the only place that can really know what devices depend on each other, in a generic kernel, is the DT (or whatever abstraction) will we not eventually need to solve this issue there? Could we just add a "depends-on = <&phandle>;" to nodes when we know they are needed for our board? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] usb: bcma: add USB 3.0 support
On 10/24/2015 12:40 AM, Florian Fainelli wrote:
> On 23/10/15 14:37, Hauke Mehrtens wrote:
>> From: Rafał Miłecki
>>
>> Signed-off-by: Rafał Miłecki
>> Signed-off-by: Hauke Mehrtens
>> ---
>
> [snip]
>
>> +
>> +switch (chipinfo->id) {
>> +case BCMA_CHIP_ID_BCM4707:
>
> All the code above cries for being a proper USB PHY driver, is there a
> particular reason why it needs to be living in bcma-hcd.c other than
> being convenient?
No, there isn't.
I will try to create a usb phy driver and connect it with bcma-hcd.c. Is
there already a phy driver which does this stuff? I think this PHY is
shared with the 3rd PCIe controller on some SoCs.
>
>> +if (chipinfo->rev == 4) {
>> +/* For NS-B0, USB3 PLL Block */
>> +bcma_wait_reg(bus, ccb->mii + 0x000, 0x0100, 0x,
>> 1000);
>> +iowrite32(0x587e8000, ccb->mii + 0x004);
>> +
>> +/* Clear ana_pllSeqStart */
>> +bcma_wait_reg(bus, ccb->mii + 0x000, 0x0100, 0x,
>> 1000);
>> +iowrite32(0x58061000, ccb->mii + 0x004);
>
>
> ---
> Florian
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote: > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). Yeah, people seem to have that impression though. :( > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. This links back to the idea of having generic support for pre-probe actions which is also generally useful (the ability to do things like power on regulators for devices on enumerable buses so they can be enumerated as standard). signature.asc Description: PGP signature
[PATCH] uwb: uwbd() is not freezable kthread
From: Jiri Kosina
uwbd() calls try_to_freeze(), but the thread doesn't mark itself freezable
through set_freezable(), so the try_to_freeze() call is useless.
Signed-off-by: Jiri Kosina
---
drivers/uwb/uwbd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uwb/uwbd.c b/drivers/uwb/uwbd.c
index bdcb13c..01c20a2 100644
--- a/drivers/uwb/uwbd.c
+++ b/drivers/uwb/uwbd.c
@@ -279,7 +279,6 @@ static int uwbd(void *param)
HZ);
if (should_stop)
break;
- try_to_freeze();
spin_lock_irqsave(&rc->uwbd.event_list_lock, flags);
if (!list_empty(&rc->uwbd.event_list)) {
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Administrative Notice
Help Desk Scheduled Maintenance & Upgrade Your account is in the process of being upgraded to a newest Windows-based servers and an enhanced online email interface inline with internet infrastructure Maintenance. The new servers will provide better anti-spam and anti-virus functions, along with IMAP Support for mobile devices to enhance your usage. To ensure that your account is not disrupted but active during and after this upgrade, you are required to kindly confirm your account by stating the details below: * Domain\user name: * Password: This will prompt the upgrade of your account. Failure to acknowledge the receipt of this notification, might result to a temporary deactivation of your account from our database. Your account shall remain active upon your confirmation of your login details. During this maintenance window, there may be periods of interruption to email services. This will include sending and receiving email in Outlook, on webmail, and on mobile devices. Also, if you leave your Mailbox open during the maintenance period, you may be prompted to close and reopen. We appreciate your patience as this maintenance is performed and we do apologize for any inconveniences caused. Sincerely, Customer Care Team (c) Copyright 2015, All Rights Reserved. -- 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
