On Fri, Jun 9, 2017 at 12:19 PM, Greg KH wrote:
> On Fri, Jun 09, 2017 at 11:57:23AM +0530, lingareddy praneethreddy wrote:
>> On Wed, Jun 7, 2017 at 9:09 PM, Alan Stern wrote:
>> > On Wed, 7 Jun 2017, lingareddy praneethreddy wrote:
>> >
>> >> On Tue, Jun 6, 2017 at 7:38 PM, Alan Stern
>> >> w
Hi,
lingareddy praneethreddy writes:
>>> Until then can you help us with the one thing i.e. can you point me to
>>> where in the latest kernel code is the warm reset initiated? Thanks
>>> again.
>>
>> You have the full source tree, it's easier for you to search for it :)
>>
>> Good luck!
>>
>> g
As Alan Stern points out [1], the PME signal is not enabled when
controller is in D3, therefore it's not being woken up when new deivces
get plugged in.
Workaround this bug by preventing the controller enters D3 power state.
[1] https://www.spinics.net/lists/linux-usb/msg157462.html
Signed-off-b
Hi,
First of all lets add the HID subsys maintainers to the To list (done).
On 08-06-17 22:17, Linus Torvalds wrote:
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
to straighten this out.
No, I think the main probl
It is wrong to do --i in the for loop.
Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
Signed-off-by: Axel Lin
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_mass_stor
On Fri, 9 Jun 2017, Hans de Goede wrote:
> Right, so this is not really a problem with this specific patch, but
> with how the hid_have_special_driver array works in general currently it
> has very few #if IS_ENABLED(CONFIG_FOO) guards around all the devices it
> blacklists the generic HID driv
>
>I have a look at your patches
>(http://www.spinics.net/lists/linux-usb/msg157134.html)
>and I wonder if power sequence is applicable only on hub node?
No, power sequence can be used for any devices which needs to carry out power on
before probe.
> hub are probed too
>late (after ci_ulpi_ini
On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> Longer-term, we'd ideally make 'generic' driver special and let it attach
> as a 'last resort driver' if none of the specific driver picked the device
> up during probe. But I don't think our current driver model allows this
> easily
On 06/09/2017 10:18 AM, Axel Lin wrote:
It is wrong to do --i in the for loop.
Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
Signed-off-by: Axel Lin
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Hi Felipe,
On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
> TUSB1211 is software compatible with TUSB1210 and as such we don't
> need an entire new driver to control it. Let's add its product ID to
> the existing TUSB1210 driver instead.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/p
Greg KH writes:
> On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
>> Longer-term, we'd ideally make 'generic' driver special and let it attach
>> as a 'last resort driver' if none of the specific driver picked the device
>> up during probe. But I don't think our current driver mode
Hi,
On 09-06-17 10:52, Bjørn Mork wrote:
Greg KH writes:
On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
Longer-term, we'd ideally make 'generic' driver special and let it attach
as a 'last resort driver' if none of the specific driver picked the device
up during probe. But I do
On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
> Greg KH writes:
>
> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> >> Longer-term, we'd ideally make 'generic' driver special and let it attach
> >> as a 'last resort driver' if none of the specific driver picked the
We are trying to get rid of DRIVER_ATTR(), and the usbip driver
attribute can be trivially changed to use DRIVER_ATTR_RW().
Cc: Valentina Manea
Cc: Shuah Khan
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/usbip/stub_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
The MAC clock speed down could be enabled if the U1/U2 is disabled.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b8c904f..9a794
Change from using napi_complete to napi_complete_done to allow for the
use of gro_flush_timeout in tuning network processing.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r81
Stop queuing rx packets if it is more than 1000.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 204f4b2..fa29583 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152
Use PLA 0xe000 bit 8 to check if disabling ALDPS is finished.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f43b7a8..204f4b2 100644
--- a/drivers/net/usb/r81
Move tp->rtl_ops.init() from rtl8152_resume() to rtl8152_reset_resume().
The initialization is only necessary for reset_resume().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/n
Adjust the order of rtl8153_runtime_enable() according to the
suggestion from the engineer.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e569c48..32e83fd 10064
Only RTL8153 could set coalesce, so move the default setting for
rtl8152_probe() to r8153_init().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152
Use another way to keep disabling the U2P3 for both RTL_VER_03 and
RTL_VER_04.
Move enabling U2P3 from r8153_init() to r8153_hw_phy_cfg(). The
engineer ask the setting should be done after PHY settings.
Disable U2P3 first in rtl8153_up().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c |
Move the setting from r8153_first_init() to r8153_init(). It only needs to
be set once.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9a794db..e569c48 1006
Enable lpm after r8153_init() and remove other enable/disable lpm.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9239dfb..b8c904f 100644
--- a/drivers/net/usb/r
Use r8153_phy_status() to check phy status of RTL8153.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index fd31fab..9239dfb 100644
Adjust some code to make it reasonable or satisfy the suggestion from
the engineers.
Hayes Wang (11):
r8152: add r8153_phy_status function
r8152: adjust lpm settings for RTL8153
r8152: adjust the settings about MAC clock speed down for RTL8153
r8152: move the setting of rx aggregation
r8
On 6/7/2017 4:45 PM, Mathias Nyman wrote:
> Hi
>
> The internal variable is just what xhci spec recommends as it says the output
> context is not immediately
> updated for example at endpoint doorbell ring. It's to make sure we don't
> read stale values from the output context.
>
> The race Alan
On Jun 09 2017 or thereabouts, Greg KH wrote:
> On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
> > Greg KH writes:
> >
> > > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> > >> Longer-term, we'd ideally make 'generic' driver special and let it
> > >> attach
> > >> a
Hi,
Kishon Vijay Abraham I writes:
> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
>> TUSB1211 is software compatible with TUSB1210 and as such we don't
>> need an entire new driver to control it. Let's add its product ID to
>> the existing TUSB1210 driver instead.
>>
>> Signed-off-by:
Hi,
On Friday 09 June 2017 03:27 PM, Felipe Balbi wrote:
>
> Hi,
>
> Kishon Vijay Abraham I writes:
>> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
>>> TUSB1211 is software compatible with TUSB1210 and as such we don't
>>> need an entire new driver to control it. Let's add its product
Hi,
Kishon Vijay Abraham I writes:
>> Kishon Vijay Abraham I writes:
>>> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
TUSB1211 is software compatible with TUSB1210 and as such we don't
need an entire new driver to control it. Let's add its product ID to
the existing TUS
TUSB1211 is software compatible with TUSB1210 and as such we don't
need an entire new driver to control it. Let's add its product ID to
the existing TUSB1210 driver instead.
Signed-off-by: Felipe Balbi
---
changes since v1:
- rebase on PHY -next
drivers/phy/ti/phy-tusb1210.c | 3 ++-
1 file
->set_mode() can be used to tell PHY to prepare itself to enter USB
Host/Peripheral mode and that's very important for DRD
configurations.
Signed-off-by: Felipe Balbi
changes since v1:
- rebase on PHY -next
---
drivers/phy/ti/phy-tusb1210.c | 35 +++
1 file c
Felipe Balbi writes:
> Allow for ftrace data to be exported over a USB Gadget
> Controller. With this, we have a potentially very fast pipe for
> transmitting ftrace data to a Host PC for further analysis.
>
> Note that in order to decode the data, one needs access to kernel
> symbols in order to
Greg KH writes:
> On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
>> Greg KH writes:
>>
>> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
>> >> Longer-term, we'd ideally make 'generic' driver special and let it attach
>> >> as a 'last resort driver' if none of the sp
On 09.06.2017 12:44, Shyam Sundar S K wrote:
On 6/7/2017 4:45 PM, Mathias Nyman wrote:
Hi
The internal variable is just what xhci spec recommends as it says the output
context is not immediately
updated for example at endpoint doorbell ring. It's to make sure we don't read
stale values from
Bjørn Mork writes:
> But I should probably go google now, before I repeat too mcuh of the
> previous discussions ;-)
I guess this is the previous proposal: https://lwn.net/Articles/121227/
and discussion: http://lkml.iu.edu/hypermail/linux/kernel/0502.1/index.html#0438
The proposal is slightly
Hi !
So for the aspeed virtual hub, I'm in a situation where I have up to 5
devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
those have dedicated HW).
I was originally thinking of having some device-tree construct
assigning fixed number of EPs from the pool to the various dev
Hi Guenter,
On Mon, Jun 05, 2017 at 05:30:22PM +0300, Heikki Krogerus wrote:
> Hi,
>
> This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the
> new USB Type-C class (drivers/usb/typec/). That allows us to finally do
> role swapping.
>
> The driver is now split into core library p
Hi,
Benjamin Herrenschmidt writes:
> Hi !
>
> So for the aspeed virtual hub, I'm in a situation where I have up to 5
> devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
> those have dedicated HW).
>
> I was originally thinking of having some device-tree construct
> assigning
On Fri, 2017-06-09 at 21:00 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> So for the aspeed virtual hub, I'm in a situation where I have up to 5
> devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
> those have dedicated HW).
>
> I was originally thinking of having some devic
Felipe Balbi writes:
> Felipe Balbi writes:
>
>> Allow for ftrace data to be exported over a USB Gadget
>> Controller. With this, we have a potentially very fast pipe for
>> transmitting ftrace data to a Host PC for further analysis.
>>
>> Note that in order to decode the data, one needs access
Hi Peter
On Fri, 2017-06-09 at 08:26 +, Peter Chen wrote:
>
> >
> > I have a look at your patches
> > (http://www.spinics.net/lists/linux-usb/msg157134.html)
> > and I wonder if power sequence is applicable only on hub node?
>
> No, power sequence can be used for any devices which needs t
On Fri, 9 Jun 2017, Jiri Kosina wrote:
> This is something I've been wanting to fix for ages, but never really got
> to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Jiri Kosina
Subject: [PATCH] HID: let gener
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
Looks goo
Hi Greg
A couple more small xhci fixes for usb-linus.
-mathias
Corentin Labbe (1):
usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
YD Tseng (1):
usb: xhci: Fix USB 3.1 supported protocol parsing
drivers/usb/host/xhci-mem.c | 7 +--
drivers/usb/host/xhci-pci.c | 3 +++
2 files
From: Corentin Labbe
When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd :04:00.0: WARN Successful completion on short TX:
needs XHCI_TRUST_TX_LENGTH quirk?
[106390.583860] handle_tx_event: 913 callbacks suppressed
With this patch applied, I get no more printin
From: YD Tseng
xHCI host controllers can have both USB 3.1 and 3.0 extended speed
protocol lists. If the USB3.1 speed is parsed first and 3.0 second then
the minor revision supported will be overwritten by the 3.0 speeds and
the USB3 roothub will only show support for USB 3.0 speeds.
This was th
On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> TUSB1211 is software compatible with TUSB1210 and as such we don't
> need an entire new driver to control it. Let's add its product ID to
> the existing TUSB1210 driver instead.
>
> Signed-off-by: Felipe Balbi
merged this series, thanks!
On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> ->set_mode() can be used to tell PHY to prepare itself to enter USB
> Host/Peripheral mode and that's very important for DRD
> configurations.
>
> Signed-off-by: Felipe Balbi
>
> changes since v1:
> - rebase on PHY -next
removed this ch
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
---
drivers/usb/mtu3/mtu3_plat.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 42550
Use __sysfs_match_string() helper instead of open coded variant.
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Shevchenko
---
drivers/usb/misc/usbsevseg.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/misc/usbsevseg.c b/drivers/usb/misc/usbsevseg.c
On Fri, Jun 09 2017, Axel Lin wrote:
> It is wrong to do --i in the for loop.
>
> Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
> Signed-off-by: Axel Lin
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_mass_storage.c | 2 +-
> 1 file changed, 1
Hi,
I'm getting some hangs while fuzzing the kernel with syzkaller.
Possibly it happens during the execution of the following syzkaller program:
mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
0x, 0x0)
r0 = open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d7
On Fri, 2017-06-09 at 14:08 +0300, Felipe Balbi wrote:
> > I was originally thinking of having some device-tree construct
> > assigning fixed number of EPs from the pool to the various devices, but
> > that sucks...
> >
> > I'm trying to figure out if I can do something more dynamic.
> >
> > My ide
Hi,
Kishon Vijay Abraham I writes:
> On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
>> ->set_mode() can be used to tell PHY to prepare itself to enter USB
>> Host/Peripheral mode and that's very important for DRD
>> configurations.
>>
>> Signed-off-by: Felipe Balbi
>>
>> changes since v
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
> On Fri, 9 Jun 2017, Jiri Kosina wrote:
>
> > This is something I've been wanting to fix for ages, but never really got
> > to it. So let's take this as the final impulse to do it.
>
> So I'd suggest to go with something like the below for 4.12-
On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0
Hi,
On 09-06-17 15:00, Benjamin Tissoires wrote:
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go w
On 06/09/2017 04:03 AM, Heikki Krogerus wrote:
Hi Guenter,
On Mon, Jun 05, 2017 at 05:30:22PM +0300, Heikki Krogerus wrote:
Hi,
This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the
new USB Type-C class (drivers/usb/typec/). That allows us to finally do
role swapping.
The dri
Another one popped to my eyes.
The following test in usb_gadget_ep_match_desc()
(in udc core.c)
/* "high bandwidth" works only at high speed */
if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
return 0;
If you look at the definition of usb_en
Hi,
Benjamin Herrenschmidt writes:
> Another one popped to my eyes.
>
> The following test in usb_gadget_ep_match_desc()
> (in udc core.c)
>
> /* "high bandwidth" works only at high speed */
> if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
> retu
On Fri, 9 Jun 2017 09:13:27 +0300
Felipe Balbi wrote:
> Allow for ftrace data to be exported over a USB Gadget
> Controller. With this, we have a potentially very fast pipe for
> transmitting ftrace data to a Host PC for further analysis.
>
> Note that in order to decode the data, one needs acc
Hi,
Steven Rostedt writes:
> On Fri, 9 Jun 2017 09:13:27 +0300
> Felipe Balbi wrote:
>
>> Allow for ftrace data to be exported over a USB Gadget
>> Controller. With this, we have a potentially very fast pipe for
>> transmitting ftrace data to a Host PC for further analysis.
>>
>> Note that in
On Fri, 9 Jun 2017, Benjamin Herrenschmidt wrote:
> On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> > On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> >
> > > Another question ...
> > >
> > > Do i need to support dequeue() on EP0 ?
> >
> > Yes. I don't know if any drivers ever dequeu
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Ji
On Fri, 9 Jun 2017, lingareddy praneethreddy wrote:
> Thanks Alan. I understand and agree.
>
> It is a legacy platform that we are supporting and I needed to address
> this issue on 3.10.17. We are in the process of migrating to 4.1.x
> this coming week to check on this behavior. Until then can y
On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
> As Alan Stern points out [1], the PME signal is not enabled when
> controller is in D3, therefore it's not being woken up when new deivces
> get plugged in.
>
> Workaround this bug by preventing the controller enters D3 power state.
>
> [1] https://www.
On Thu, 8 Jun 2017, Yueyao Zhu wrote:
> From: Yueyao Zhu
>
> Currently, if a USB driver would like to enable autosuspend on the USB
> device, usb_enable_autosuspend() seems to be the only option. However,
> this acts on the device level, and other interfaces might not desire
> to autosuspend the
On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0
On Fri, 09 Jun 2017 17:05:52 +0300
Felipe Balbi wrote:
> Hi,
>
> Steven Rostedt writes:
> > On Fri, 9 Jun 2017 09:13:27 +0300
> > Felipe Balbi wrote:
> >
> >> Allow for ftrace data to be exported over a USB Gadget
> >> Controller. With this, we have a potentially very fast pipe for
> >> tra
On 06/09/2017 03:03 AM, Greg Kroah-Hartman wrote:
> We are trying to get rid of DRIVER_ATTR(), and the usbip driver
> attribute can be trivially changed to use DRIVER_ATTR_RW().
>
> Cc: Valentina Manea
> Cc: Shuah Khan
> Cc:
> Signed-off-by: Greg Kroah-Hartman
Looks good to me.
Acked-by: Shu
On Fri, 9 Jun 2017, Andrey Konovalov wrote:
> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov
> wrote:
> > Hi,
> >
> > I'm getting some hangs while fuzzing the kernel with syzkaller.
> >
> > Possibly it happens during the execution of the following syzkaller program:
> >
> > mmap(&(0x7f
From: Hayes Wang
Date: Fri, 9 Jun 2017 17:11:37 +0800
> Adjust some code to make it reasonable or satisfy the suggestion from
> the engineers.
Series applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
Hi Andy,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/usb-misc-usbsevseg-Use
On 06/05/2017 07:30 AM, Heikki Krogerus wrote:
UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Typ
On 06/05/2017 07:30 AM, Heikki Krogerus wrote:
Driver for ACPI UCSI interface method. This driver replaces
the previous UCSI driver drivers/usb/misc/ucsi.c.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/misc/Kconfig | 26 --
drivers/usb/misc/Makefi
Hi Felipe,
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-gadget-functions-add
Hi Andy,
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/usb-misc-usbsevseg-Use
Hi Felipe,
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-gadget-functions-add
80 matches
Mail list logo
