RE: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property
Hi Shawn, Regarding below patch, Felipe has suggested to talk to you: > [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116 talk to you ARM-SoC maintainer. https://lkml.org/lkml/2015/9/4/7 Please provide your comments. Inform me in case, if a resend is required. Best Regards, Rajesh Bhagat -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Saturday, October 03, 2015 1:29 AM To: Bhagat Rajesh-B56421 Cc: ba...@ti.com; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-usb@vger.kernel.org Subject: Re: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property On Thu, Sep 24, 2015 at 09:42:59AM +, RAJESH BHAGAT wrote: > Hi Felipe, > > Any comments on the below [v4] patches? > > [PATCH 1/3][v4] Documentation: dt: dwc3: Add > snps,quirk-frame-length-adjustment property https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=3737c54418c35034127bf2837e9b27a3c3c67940 > [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3 > [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116 talk to you ARM-SoC maintainer. > I will be taking forward these patches, as Nikhil has left freescale. okay, thanks for letting me know. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()
On Mon, Oct 05, 2015 at 12:08:26AM +0300, Sergei Shtylyov wrote: > Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE(). Why? I hate PCI_VDEVICE(), it's impossible to grep for things and does not help with readability and is pointless. My one wish was that when I was the PCI maintainer I would have just deleted the thing from the kernel entirely instead of leaving it there hoping no one would use it. I don't like these types of pointless patches, sorry. 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] usb-host: Remove fusbh200 driver
Hi Balbi,
>> John Feng-Hsin Chiang, can you confirm that from your side the
>> fusbh200 driver can be deleted?
>... but let's get this confirmation.
Yes, you can delete fusbh200.
Best Regards,
John Chiang
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Sunday, October 04, 2015 5:21 AM
To: Peter Senna Tschudin
Cc: John Feng-Hsin Chiang(江峰興); Yuan-Hsin Chen; Greg Kroah-Hartman; Alan Stern;
mathias.ny...@linux.intel.com; r...@linux-mips.org;
alexandre.bell...@free-electrons.com; ramneek.mehr...@freescale.com; Laurent
Pinchart; abres...@chromium.org; sb...@codeaurora.org; Rafał Miłecki;
haoke...@gmail.com; pebo...@tiscali.nl; Sergei Shtylyov; Masanari Iida; Randy
Dunlap; ch...@rorvick.com; linux-ker...@vger.kernel.org;
linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb-host: Remove fusbh200 driver
Peter Senna Tschudin writes:
> On Fri, Oct 2, 2015 at 7:39 PM, Felipe Balbi wrote:
>> On Fri, Oct 02, 2015 at 01:18:27PM +0200, Peter Senna Tschudin wrote:
>>> fusbh200 and fotg210 are very similar. The initial idea was to
>>> consolidate both drivers but I'm afraid fusbh200 is not being used.
>>>
>>> This patch remove the fusbh200 source code, update Kconfig and two
>>> Makefiles.
>>>
>>> Signed-off-by: Peter Senna Tschudin
>>
>> after all this work on these previous patches, you just remove fusbh200 ?
>>
>> that's a bit odd. Are you sure there are no users for this driver ?
>> It has been in tree since 2013.
> I don't know about users, but I could not find devices using fusbh200.
> The closest I got was:
>
> http://www.ebay.fr/itm/Digital-Video-Langzeit-Recorder-H264-DVR-3G-4-K
> anal-/370525106495
>
> But it only says: Main Processor: Faraday. I don't know which usb host
> controller it uses.
>
> The idea of deleting fusbh200 came from contacting the driver authors.
> I was asking where to find hw for testing, and I was told that the
> fusbh200 driver can be deleted. Also at least Fedora and Ubuntu build
> modules for these host controllers by default. If fusbh200 and fotg210
> are only available integrated into SOCs, maybe building the modules by
> default for x86 is not a good idea. But if there are users I'll be
> happy to continue the integration work, even better if I find hardware
> for testing.
fair enough, if can be deleted it's fine...
> John Feng-Hsin Chiang, can you confirm that from your side the
> fusbh200 driver can be deleted?
... but let's get this confirmation.
> For the patches I sent, 10 of 14 are for fotg210 which I'll fix and resend.
cool, thanks
--
balbi
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{군펐왲^n뇊⊆쫧�곷h솳鈺�&�� 췍쳺�h�(��쉸듶줷"얎�m��곴�z받뻿筬f＂톒쉱�~늤
Re: [PATCH v4 1/5] gadget: Introduce the notifier functions
On Fri, Oct 02, 2015 at 02:11:25PM -0500, Felipe Balbi wrote:
> On Fri, Oct 02, 2015 at 07:49:09PM +0100, Mark Brown wrote:
> > On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote:
> > > > Things more difficult, if nothing else it means we need to get whatever
> > > > userspace component deployed in all relevant userspace stacks with
> > > > appropriate configuration in order to do things.
> > > but that will be a thing for the kernel too. We will have to deploy this
> > > new
> > > kernel component in all relevant stacks with appropriate configuration in
> > > order
> > > to do things :-) No changes there.
> > Sure, but it's one project which is developed entirely in the open -
> > that's a lot more manageable.
> We can have a fully open source userland daemon too. Much like systemd, bluez,
> neard, and many, many others. Why wouldn't that be a thing ?
The trouble is getting traction on adoption. Vendors have a habit of
doing things like finding problems and rather than reporting them
deciding that the open source solution isn't great and going and writing
their own thing (especially when they're in stealth mode) rather than
talking to anyone. Sometimes we manage to avoid that but it can be
challenging, and often we only even hear about the new thing after it's
shipping and there's a lot of inertia behind changing it. The kernel
ABIs tend to be a lot sticker than userspace things here.
> Similar applies to power delivery charging profile themselves. Not all
> profiles
> are mandatory. Some are optional and that will be completely device/board
> specific. How an OEM implements that in the PCB is also completely
> board-specific :-) Some might have a dumb IC hardcoding some messages, some
> might have something largely more flexible.
Right, and what I was trying to say was that it seems like the kernel
ought to be worrying about the board specific bits and userspace
worrying about what to do with those bits.
> > The things we've got with audio are a combination of tuning to taste and
> > (even more importantly) very different ideas about what you want to do
> > with an audio subsystem that influence how you set things up in a given
> > use case.
> the same thing will happen with Type-C and power delivery. There won't be
> tuning
> to taste, of course :-) But there will be "very different ideas what what you
> want to do with" your charging methodology.
Are those very different things about the use cases ("don't bother with
high speed data, get all the power you can" or whatever) or are they
about the details of the board?
> > > Actually, I was thinking about it in a more granular fashion. Kernel
> > > exposes a
> > > charger/power_supply, a few regulators, a UDC view and this single
> > > userspace
> > > daemon figures out how to tie those together.
> > That sounds worrying - it means that new hardware support needs
> > supporting in every userspace (it seems inevitable that there will be at
> > least some reimplementations because that's fun) which gets old really
> > fast, and every userspace needs to understand every topology.
> very true, but it's also true for a kernel solution.
> It seems like you want it in the kernel because of it being convenient :-)
Yes, definitely - my experience both in terms of watching how people
like handset vendors often work internally and in terms of getting
things adopted is that it's a lot easier if you can have one component
you need to update to handle new hardware rather than multiple ones that
need to be upgraded for things that are purely board differences.
> > > The view here isn't really a USB port, it's just a source of power. But
> > > how much
> > > power we can draw from it depends on, possibly, a ton of different chips
> > > and
> > > different notifications.
> > Right, yes - it's the power input/output associated with the USB port.
> > The USB port is just the physical thing users can see so it's a good way
> > to label it. That could mean that we ought to move the aggregation bit
> > into the power supply code of course, but then a lot of the decisions
> > are going to be specific to USB.
> in a sense, yes. But they can happen at a layer which knows nothing (or very
> little) about USB. Here's an example:
> Not everybody follows USB Battery Charging class. Some chargers don't short
> D+/D- to signify they are a wall charger. Some will use different resistance
> values on the ID pin to tell you how much current you can draw from them.
> From a PMIC (or something else) point of view, all it needs is a tiny current
> source and a an ADC, then it reports the ADC value to the upper layer. This
> really doesn't even need to know that it's using an ID pin, or whatever.
This doesn't seem much different to things like the various GPIO to
subsystem X drivers we've got - we already have some for IIO type
things IIRC.
> > How different are the end goals of these designs really going to be
> > though - that's more of the questi
[PATCH 8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/gadget/udc/bdc/bdc_pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/gadget/udc/bdc/bdc_pci.c
===
--- usb.orig/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ usb/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -113,7 +113,7 @@ static void bdc_pci_remove(struct pci_de
}
static struct pci_device_id bdc_pci_id_table[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BDC_PCI_PID), },
+ { PCI_VDEVICE(BROADCOM, BDC_PCI_PID), },
{} /* Terminating Entry */
};
--
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 7/8] pch_udc: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/gadget/udc/pch_udc.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
Index: usb/drivers/usb/gadget/udc/pch_udc.c
===
--- usb.orig/drivers/usb/gadget/udc/pch_udc.c
+++ usb/drivers/usb/gadget/udc/pch_udc.c
@@ -3232,23 +3232,22 @@ finished:
static const struct pci_device_id pch_udc_pcidev_id[] = {
{
- PCI_DEVICE(PCI_VENDOR_ID_INTEL,
- PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC),
+ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
+ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ML7213_IOH_UDC),
+ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_IOH_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ML7831_IOH_UDC),
+ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_IOH_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] amd5536udc: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/gadget/udc/amd5536udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/gadget/udc/amd5536udc.c
===
--- usb.orig/drivers/usb/gadget/udc/amd5536udc.c
+++ usb/drivers/usb/gadget/udc/amd5536udc.c
@@ -3405,7 +3405,7 @@ static int udc_remote_wakeup(struct udc
/* PCI device parameters */
static const struct pci_device_id pci_id[] = {
{
- PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x2096),
+ PCI_VDEVICE(AMD, 0x2096),
.class =(PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbhid: Fix for the WiiU adapter from Mayflash
On Sat, 3 Oct 2015, Felipe Balbi wrote: > > The WiiU adapter from Mayflash (see > > http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not > > working correctly. > > > > The "XInput" mode works fine, the controller is recognized as a xbox > > controller. But it is only possible to connect one controller with > > this method. > > > > In "DInput" mode the device is recognized as some kind of mouse input > > but no joystick is created. This commit will change this behavior with > > HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that > > it will also create joysticks in /dev/input/js*. > > > > Please split your commit log so that sentences don't go over 72 > characters. > > Other than that: > > Reviewed-by: Felipe Balbi I've fixed up the formatting and applied to hid.git#for-4.3/upstream-fixes (please note that this doesn't guarantee that this patch will not go to 4.3 still, because it alone is not going to be reason for pull request, but might eventually piggy-back on something that'll be needed for 4.3). Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] dwc3-pci: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/dwc3/dwc3-pci.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
Index: usb/drivers/usb/dwc3/dwc3-pci.c
===
--- usb.orig/drivers/usb/dwc3/dwc3-pci.c
+++ usb/drivers/usb/dwc3/dwc3-pci.c
@@ -174,16 +174,13 @@ static void dwc3_pci_remove(struct pci_d
}
static const struct pci_device_id dwc3_pci_id_table[] = {
- {
- PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
- PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
- },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
- { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB), },
+ { PCI_VDEVICE(SYNOPSYS, PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3), },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BSW), },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BYT), },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_NL_USB), },
{ }/* Terminating Entry */
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] dwc2: pci: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/dwc2/pci.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: usb/drivers/usb/dwc2/pci.c
===
--- usb.orig/drivers/usb/dwc2/pci.c
+++ usb/drivers/usb/dwc2/pci.c
@@ -145,11 +145,10 @@ err:
static const struct pci_device_id dwc2_pci_ids[] = {
{
- PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, PCI_PRODUCT_ID_HAPS_HSOTG),
+ PCI_VDEVICE(SYNOPSYS, PCI_PRODUCT_ID_HAPS_HSOTG),
},
{
- PCI_DEVICE(PCI_VENDOR_ID_STMICRO,
- PCI_DEVICE_ID_STMICRO_USB_OTG),
+ PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_USB_OTG),
},
{ /* end: all zeroes */ }
};
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] chipidea: ci_hdrc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/chipidea/ci_hdrc_pci.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: usb/drivers/usb/chipidea/ci_hdrc_pci.c
===
--- usb.orig/drivers/usb/chipidea/ci_hdrc_pci.c
+++ usb/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -142,16 +142,16 @@ static const struct pci_device_id ci_hdr
.driver_data = (kernel_ulong_t)&pci_platdata,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811),
+ PCI_VDEVICE(INTEL, 0x0811),
.driver_data = (kernel_ulong_t)&langwell_pci_platdata,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829),
+ PCI_VDEVICE(INTEL, 0x0829),
.driver_data = (kernel_ulong_t)&penwell_pci_platdata,
},
{
/* Intel Clovertrail */
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006),
+ PCI_VDEVICE(INTEL, 0xe006),
.driver_data = (kernel_ulong_t)&penwell_pci_platdata,
},
{ 0 } /* end: all zeroes */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] ohci-pci:-use-PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/host/ohci-pci.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: usb/drivers/usb/host/ohci-pci.c
===
--- usb.orig/drivers/usb/host/ohci-pci.c
+++ usb/drivers/usb/host/ohci-pci.c
@@ -167,27 +167,27 @@ static int ohci_quirk_amd700(struct usb_
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
- PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x740c),
+ PCI_VDEVICE(AMD, 0x740c),
.driver_data = (unsigned long)ohci_quirk_amd756,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_OPTI, 0xc861),
+ PCI_VDEVICE(OPTI, 0xc861),
.driver_data = (unsigned long)ohci_quirk_opti,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_ANY_ID),
+ PCI_VDEVICE(NS, PCI_ANY_ID),
.driver_data = (unsigned long)ohci_quirk_ns,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xa0f8),
+ PCI_VDEVICE(COMPAQ, 0xa0f8),
.driver_data = (unsigned long)ohci_quirk_zfmicro,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA_2, 0x01b6),
+ PCI_VDEVICE(TOSHIBA_2, 0x01b6),
.driver_data = (unsigned long)ohci_quirk_toshiba_scc,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB),
+ PCI_VDEVICE(NEC, PCI_DEVICE_ID_NEC_USB),
.driver_data = (unsigned long)ohci_quirk_nec,
},
{
@@ -199,19 +199,19 @@ static const struct pci_device_id ohci_p
.driver_data= (unsigned long) broken_suspend,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152),
+ PCI_VDEVICE(ITE, 0x8152),
.driver_data = (unsigned long) broken_suspend,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4397),
+ PCI_VDEVICE(ATI, 0x4397),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4398),
+ PCI_VDEVICE(ATI, 0x4398),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
{
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
+ PCI_VDEVICE(ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ehci-pci: use PCI_VDEVICE() instead of PCI_DEVICE()
Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().
Signed-off-by: Sergei Shtylyov
---
drivers/usb/host/ehci-pci.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: usb/drivers/usb/host/ehci-pci.c
===
--- usb.orig/drivers/usb/host/ehci-pci.c
+++ usb/drivers/usb/host/ehci-pci.c
@@ -49,9 +49,9 @@ static inline bool is_intel_quark_x1000(
*/
static const struct pci_device_id bypass_pci_id_table[] = {
/* ChipIdea on Intel MID platform */
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
+ { PCI_VDEVICE(INTEL, 0x0811), },
+ { PCI_VDEVICE(INTEL, 0x0829), },
+ { PCI_VDEVICE(INTEL, 0xe006), },
{}
};
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] USB: use PCI_VDEVICE() instead of PCI_DEVICE()
Hello. Here's a set of 8 patches against the 'usb-next' branch of Greg KH's 'usb.git' repo. It's to eliminate the use of the PCI_DEVICE() macro where less verbose PCI_VDEVICE() should have been used. [1/8] ehci-pci: use PCI_VDEVICE() instead of PCI_DEVICE() [2/8] ohci-pci:-use-PCI_VDEVICE() instead of PCI_DEVICE() [3/8] chipidea: ci_hdrc_pci: use PCI_VDEVICE() instead of PCI_DEVICE() [4/8] dwc2: pci: use PCI_VDEVICE() instead of PCI_DEVICE() [5/8] dwc3-pci: use PCI_VDEVICE() instead of PCI_DEVICE() [6/8] amd5536udc: use PCI_VDEVICE() instead of PCI_DEVICE() [7/8] pch_udc: use PCI_VDEVICE() instead of PCI_DEVICE() [8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE() WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: hcd: use USB_DT_*
Fix using the bare numbers to set the 'bDescriptorType' descriptor fields
while the values are #define'd in .
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
I's been laying around from the end of March. :-(
drivers/usb/core/hcd.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -131,7 +131,7 @@ static inline int is_root_hub(struct usb
/* usb 3.0 root hub device descriptor */
static const u8 usb3_rh_dev_descriptor[18] = {
0x12, /* __u8 bLength; */
- 0x01, /* __u8 bDescriptorType; Device */
+ USB_DT_DEVICE, /* __u8 bDescriptorType; Device */
0x00, 0x03, /* __le16 bcdUSB; v3.0 */
0x09, /* __u8 bDeviceClass; HUB_CLASSCODE */
@@ -152,7 +152,7 @@ static const u8 usb3_rh_dev_descriptor[1
/* usb 2.5 (wireless USB 1.0) root hub device descriptor */
static const u8 usb25_rh_dev_descriptor[18] = {
0x12, /* __u8 bLength; */
- 0x01, /* __u8 bDescriptorType; Device */
+ USB_DT_DEVICE, /* __u8 bDescriptorType; Device */
0x50, 0x02, /* __le16 bcdUSB; v2.5 */
0x09, /* __u8 bDeviceClass; HUB_CLASSCODE */
@@ -173,7 +173,7 @@ static const u8 usb25_rh_dev_descriptor[
/* usb 2.0 root hub device descriptor */
static const u8 usb2_rh_dev_descriptor[18] = {
0x12, /* __u8 bLength; */
- 0x01, /* __u8 bDescriptorType; Device */
+ USB_DT_DEVICE, /* __u8 bDescriptorType; Device */
0x00, 0x02, /* __le16 bcdUSB; v2.0 */
0x09, /* __u8 bDeviceClass; HUB_CLASSCODE */
@@ -196,7 +196,7 @@ static const u8 usb2_rh_dev_descriptor[1
/* usb 1.1 root hub device descriptor */
static const u8 usb11_rh_dev_descriptor[18] = {
0x12, /* __u8 bLength; */
- 0x01, /* __u8 bDescriptorType; Device */
+ USB_DT_DEVICE, /* __u8 bDescriptorType; Device */
0x10, 0x01, /* __le16 bcdUSB; v1.1 */
0x09, /* __u8 bDeviceClass; HUB_CLASSCODE */
@@ -223,7 +223,7 @@ static const u8 fs_rh_config_descriptor[
/* one configuration */
0x09, /* __u8 bLength; */
- 0x02, /* __u8 bDescriptorType; Configuration */
+ USB_DT_CONFIG, /* __u8 bDescriptorType; Configuration */
0x19, 0x00, /* __le16 wTotalLength; */
0x01, /* __u8 bNumInterfaces; (1) */
0x01, /* __u8 bConfigurationValue; */
@@ -248,7 +248,7 @@ static const u8 fs_rh_config_descriptor[
/* one interface */
0x09, /* __u8 if_bLength; */
- 0x04, /* __u8 if_bDescriptorType; Interface */
+ USB_DT_INTERFACE, /* __u8 if_bDescriptorType; Interface */
0x00, /* __u8 if_bInterfaceNumber; */
0x00, /* __u8 if_bAlternateSetting; */
0x01, /* __u8 if_bNumEndpoints; */
@@ -259,7 +259,7 @@ static const u8 fs_rh_config_descriptor[
/* one endpoint (status change endpoint) */
0x07, /* __u8 ep_bLength; */
- 0x05, /* __u8 ep_bDescriptorType; Endpoint */
+ USB_DT_ENDPOINT, /* __u8 ep_bDescriptorType; Endpoint */
0x81, /* __u8 ep_bEndpointAddress; IN Endpoint 1 */
0x03, /* __u8 ep_bmAttributes; Interrupt */
0x02, 0x00, /* __le16 ep_wMaxPacketSize; 1 + (MAX_ROOT_PORTS / 8) */
@@ -270,7 +270,7 @@ static const u8 hs_rh_config_descriptor[
/* one configuration */
0x09, /* __u8 bLength; */
- 0x02, /* __u8 bDescriptorType; Configuration */
+ USB_DT_CONFIG, /* __u8 bDescriptorType; Configuration */
0x19, 0x00, /* __le16 wTotalLength; */
0x01, /* __u8 bNumInterfaces; (1) */
0x01, /* __u8 bConfigurationValue; */
@@ -295,7 +295,7 @@ static const u8 hs_rh_config_descriptor[
/* one interface */
0x09, /* __u8 if_bLength; */
- 0x04, /* __u8 if_bDescriptorType; Interface */
+ USB_DT_INTERFACE, /* __u8 if_bDescriptorType; Interface */
0x00, /* __u8 if_bInterfaceNumber; */
0x00, /* __u8 if_bAlternateSetting; */
0x01, /* __u8 if_bNumEndpoints; */
@@ -306,7 +306,7 @@ static const u8 hs_rh_config_descriptor[
/* one endpoint (status change endpoint) */
0x07, /* __u8 ep_bLength; */
- 0x05, /* __u8 ep_bDescriptorType; Endpoint */
+ USB_DT_ENDPOINT, /* __u8 ep_bDescriptorType; Endpoint */
0x81, /* __u8 ep_bEndpointAddress; IN Endpoint 1 */
0x03, /* __u8 ep_bmAttributes; Interrupt */
/* __le16 ep_wMaxPacketSize; 1 + (MAX_ROOT_PORTS / 8)
@@ -318,7 +318,7 @@ static const u8 hs_rh_config_descriptor[
static con
Re: Problems with printk logs and my driver
On Sun, 4 Oct 2015, Eric Curtin wrote: > Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my > keyboard to use the driver for this samsung Wireless keyboard and > mouse, crazy I know since I have a different piece of hardware, but I > wanted to see what happens or at least does it change driver. When I > reboot to this kernel, my keyboard still uses the usbhid driver. Why > does this happen? Because the Samsung wireless keyboard and mouse also use the usbhid driver. Besides, the choice of driver depends just as much on the bInterfaceClass, -Subclass, and -Protocol as on the vendor and product IDs. Basically, nothing needs to use usbkbd. Anything that driver can handle will also work with usbhid. The only reason for keeping usbkbd as a separate driver is because it is smaller than usbhid, so it's better suited to some embedded applications with limited memory. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] RFC: usb/host/fotg210: replace msleep by usleep_range
On Sun, 4 Oct 2015, Peter Senna Tschudin wrote: > On Fri, Oct 2, 2015 at 7:52 PM, Alan Stern wrote: > > On Fri, 2 Oct 2015, Felipe Balbi wrote: > > > >> On Mon, Sep 21, 2015 at 05:01:10PM +0200, Peter Senna Tschudin wrote: > >> > msleep under 20ms can result in sleeping up to 20ms, which may not be > >> > intended. Replace msleep(5) by usleep_range(5000, 6000). > >> > > >> > Signed-off-by: Peter Senna Tschudin > >> > >> good catch. I'd apply this straight away. Alan ? > > > > It really doesn't matter. As long as the delay is at least 5 ms, it > > can be arbitrarily long. This won't hurt, and if it prevents automated > > tools from complaining then it's worthwhile. > Then is it a good idea to increase the range to reduce chances of > creating an interrupt? > > usleep_range(5000, 1)? That wold be okay. > > Peter, a lot of the changes you have been making will also apply to the > > ehci-hcd driver. Do you want to update it as well? One caution: The > > style used for continuation lines is to add two extra tab stops, not to > > align things with an open paren on the original line. > The drivers with more checkpatch errors and warnings are: > > > > 117 586 drivers/usb/host/fusbh200-hcd.c > 38 124 drivers/usb/host/ohci-q.c > 38 122 drivers/usb/host/ehci-dbg.c > 37 118 drivers/usb/host/ohci-dbg.c > 36 129 drivers/usb/host/ehci-sched.c > 24 136 drivers/usb/host/ohci-hcd.c > 23 16 drivers/usb/host/sl811-hcd.c > 20 105 drivers/usb/host/ohci-hub.c > 18 48 drivers/usb/host/ehci-hub.c > > 17 70 drivers/usb/host/ehci-hcd.c > > 13 4 drivers/usb/host/uhci-debug.c > 12 93 drivers/usb/host/ehci-q.c > 9 83 drivers/usb/host/isp116x-hcd.c > 9 32 drivers/usb/host/fotg210-hcd.c > 7 29 drivers/usb/host/oxu210hp-hcd.c > 6 4 drivers/usb/host/sl811_cs.c > > I'll fix ehci-hcd. Do you want patches for the others? I was speaking of ehci-*.c, because the code in there is extremely similar to the code you've already been working on. There's no point in trying to fix _all_ those checkpatch violations. A lot of them are trivial things like an extra space character between a function name and the following left paren. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On 30 September 2015 at 13:07, Austin S Hemmelgarn wrote: > On 2015-09-29 18:11, Eric Curtin wrote: >> >> On 25 September 2015 at 16:45, Austin S Hemmelgarn >> wrote: >>> >>> On 2015-09-25 08:02, Jiri Kosina wrote: On Fri, 25 Sep 2015, Felipe Tonello wrote: > Maybe a better description on Kconfig and/or comments on source code > it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. >>> For some reason there seem to be a lot of people who go to configure >>> there >>> own kernel and don't read the help text (I understand if you've been >>> building your own Linux kernel's for years and actually understand what a >>> Kconfig option is really asking, but most people who I've heard of doing >>> this have never built a kernel before in their life). >>> >>> On the other hand, can anyone think of any real reason to use this >>> outside >>> of embedded systems? I know there are a lot of distros that build this >>> and >>> the USB HIDBP mouse support as modules, but I have yet to hear/find any >>> reports of hardware that _only_ works with this driver and not the >>> generic >>> HID driver. If this is the case, it might make sense to make this depend >>> on >>> EXPERT or at least remove the bit about 'simple keyboards'. >>> >> >> As regards renaming usbkbd.c, @Austin there are some reasons why you would >> not read the Kconfig. As a beginner, I didn't even configure this part or >> read the help text as I used the configuration that comes with Fedora, I >> don't know if that's a valid excuse or not though. I'll leave you guys >> decide, you're the experts! >> >> As regards the issue with my capslock led I'm still looking into it. >> > Personally, I would not ever advocate not reading the help text for an > option (although in some cases it's pretty un-helpful, especially for some > staging drivers). > > Your case is one of the common ones, and it's not a bad place to start, but > you have to keep in mind that most distro's turn on a huge amount of stuff > that more than 90% of people aren't ever going to need (for example, I'm > pretty sure Ubuntu still builds a module for SLIP, which has been an > essentially dead technology for more than a decade now). For anyone starting > from a distro's kconfig, I'd suggest at least: > a. Turn off CONFIG_EXPERT unless you intend to actually try and understand > the options it enables (most distro's turn this on for some of the fine > tuning features it enables, most regular people don't actually need it). > b. Go through using menuconfig, and turn off stuff under the drivers menu > that you know you will never need (and take the time to use stuff like lspci > and lsusb to figure out what actually need). > c. Read the help text before trying to change anything, and if you don't > understand it after that, look it up online, and even then be careful > changing it. > d. If you intend on actually using it with a particular distro, don't turn > off too much outside of the drivers menu, other stuff can cause things to > fail in unusual ways, and you often won't get a great amount of help from > the distro maintainers when using a custom kernel. > > The real problem is when people just read the option name and think they > understand it when they don't really (or just don't think about the > implications), and then wonder why something stops working suddenly (like > one guy I know who was building a kernel for a server, and thought he could > just disable everything under the 'Graphics' menu, then wondered why he > didn't get console output on his monitor). > Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my keyboard to use the driver for this samsung Wireless keyboard and mouse, crazy I know since I have a different piece of hardware, but I wanted to see what happens or at least does it change driver. When I reboot to this kernel, my keyboard still uses the usbhid driver. Why does this happen? diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index f769208..350a6f8 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @
Re: [PATCH 06/14] RFC: usb/host/fotg210: replace msleep by usleep_range
On Fri, Oct 2, 2015 at 7:52 PM, Alan Stern wrote: > On Fri, 2 Oct 2015, Felipe Balbi wrote: > >> On Mon, Sep 21, 2015 at 05:01:10PM +0200, Peter Senna Tschudin wrote: >> > msleep under 20ms can result in sleeping up to 20ms, which may not be >> > intended. Replace msleep(5) by usleep_range(5000, 6000). >> > >> > Signed-off-by: Peter Senna Tschudin >> >> good catch. I'd apply this straight away. Alan ? > > It really doesn't matter. As long as the delay is at least 5 ms, it > can be arbitrarily long. This won't hurt, and if it prevents automated > tools from complaining then it's worthwhile. Then is it a good idea to increase the range to reduce chances of creating an interrupt? usleep_range(5000, 1)? > > Peter, a lot of the changes you have been making will also apply to the > ehci-hcd driver. Do you want to update it as well? One caution: The > style used for continuation lines is to add two extra tab stops, not to > align things with an open paren on the original line. The drivers with more checkpatch errors and warnings are: 117 586 drivers/usb/host/fusbh200-hcd.c 38 124 drivers/usb/host/ohci-q.c 38 122 drivers/usb/host/ehci-dbg.c 37 118 drivers/usb/host/ohci-dbg.c 36 129 drivers/usb/host/ehci-sched.c 24 136 drivers/usb/host/ohci-hcd.c 23 16 drivers/usb/host/sl811-hcd.c 20 105 drivers/usb/host/ohci-hub.c 18 48 drivers/usb/host/ehci-hub.c 17 70 drivers/usb/host/ehci-hcd.c 13 4 drivers/usb/host/uhci-debug.c 12 93 drivers/usb/host/ehci-q.c 9 83 drivers/usb/host/isp116x-hcd.c 9 32 drivers/usb/host/fotg210-hcd.c 7 29 drivers/usb/host/oxu210hp-hcd.c 6 4 drivers/usb/host/sl811_cs.c I'll fix ehci-hcd. Do you want patches for the others? I'll fix the alignment using two extra tabs instead of aligning with opening parenthesis. Thank you. -- Peter -- 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 15/15] dma: remove external references to dma_supported
On Sat, Oct 03, 2015 at 05:19:39PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > Documentation/DMA-API.txt | 13 - > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/fotg210-hcd.c | 2 +- > drivers/usb/host/fusbh200-hcd.c | 2 +- > drivers/usb/host/oxu210hp-hcd.c | 2 +- > 5 files changed, 4 insertions(+), 17 deletions(-) Acked-by: Greg Kroah-Hartman -- 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 V5 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Sun, Sep 27, 2015 at 03:48:24PM +0200, Rafael J. Wysocki wrote: > On Sun, Sep 27, 2015 at 12:04 AM, Viresh Kumar > wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need to consider other 32 bits > > for big endian 64-bit systems. There are no such platforms yet, but the > > code needs to be robust for such a case. > > > > Fix that by changing type of 'global_lock' to u32. > > > > Signed-off-by: Viresh Kumar > > Acked-by: Rafael J. Wysocki > > Greg, please take this one along with the [2/2] if that one looks good to you. Thanks, will do. 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 1/1] usb: misc: usbtest: add bulk queue test
On Mon, Sep 07, 2015 at 02:13:57PM +0800, Peter Chen wrote: > The bulk queue tests are used to show 'best performance' for bulk > transfer, we are often asked this question by users. The implementation > is the same with iso test, that is queue request at interrupt completion, > so we reuse the iso structures, and rename them as common one. > > It's result should be very close to IC simulation, in order > to get that, the device side should also need to prepare enough > queue. > > We have got the 'best performance' (IN: 41MB, OUT: 39MB) at i.mx platform > (USB2, ARM Cortex A9, stream mode need to enable) with below command: > > Host side: > modprobe usbtest > ./testusb -a -t 27 -g 64 -s 16384 > ./testusb -a -t 28 -g 64 -s 16384 > Gadget side: > modprobe g_zero loopdefault=1 qlen=64 buflen=16384 > > Signed-off-by: Peter Chen > --- > drivers/usb/misc/usbtest.c | 104 > +++-- > 1 file changed, 73 insertions(+), 31 deletions(-) Doesn't apply to the usb-next branch :( -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] lsusb: Fix issue with lengthy string descriptors
On Fri, Jul 31, 2015 at 12:49:10AM +0530, Muthu M wrote: > Fixed the issue in displaying lengthy string descriptor (more than 128 bytes) > > Signed-off-by: Muthu M > --- > usbmisc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, 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 0/9] USB 3.1 initial support for usb core and xhci
On Thu, Oct 01, 2015 at 06:40:30PM +0300, Mathias Nyman wrote: > This patchseries adds the USB 3.1 groundwork. > > USB 3.1 specification includes a new SuperSpeedPlus protocol supporting > up to 10Gbps speeds. USB 3.1 devices using the new SuperSpeedPlus protocol > are called USB 3.1 Gen2 devices. > > Devices announce their SuperSpeedPlus capability with a new SuperSpeedPlus > device capability descriptor included in the device BOS descriptor. > > I short, this series does for > usb core: > Parse and store the new SuperSpeedPlus capability descriptor > Allow hosts to define themselves as USB 3.1 capable > > xhci: > Check if host hardware support USB 3.1 and define hcd as USB 3.1 capable > Create a SuperSpeedPlus descriptor for the roothub that support USB 3.1 > Support the USB 3.1 get ext port status hub requests which returns > more detailed information about port speed, not yet used by usb core. > > latest usbutils source supports parsing the SuperSpeedPlus capability > descriptor. With this patchseries lsusb -v shows a SuperSpeedPlus > capability descriptor for the xhci USB 3.1 roothub Very nice work, glad to see this stuff land in the tree. 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 v8 0/3] usb: xhci-platform: Configure 64-bit DMA mask if the platform is capable
On Wed, Sep 30, 2015 at 02:24:30PM -0700, Duc Dang wrote: > On Thu, Sep 17, 2015 at 11:19 AM, Duc Dang wrote: > > The xhci platform driver does not work with system that only supports > > 64-bit DMA as it requests 32-bit DMA mask during driver initialization. > > This patch set addresses this issue and also adds XHCI-compliant USB > > Controller ACPI identification into xhci-platform driver. > > Hi Greg, Mathias, > > Arnd already ack-ed the first patch, please let me know if you have > more comment on this set? I'm waiting for Mathias to forward this on to me as he's the xhci maintainer. 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
