Re: [PATCH v5 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub
On Sat, Mar 17, 2018 at 11:07:27AM +1100, Benjamin Herrenschmidt wrote: On Sat, 2018-03-17 at 04:29 +0800, kbuild test robot wrote: Hi Benjamin, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.16-rc4] [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/Benjamin-Herrenschmidt/usb-gadget-Add-an-EP-dispose-callback-for-EP-lifetime-tracking/20180317-004216 config: m32r-allyesconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 7.2.0 Didn't we drop testing on mr32 ? These are bogus warnings due to bugs in the arch itself... Yeah I just send patch to remove testing on m32r etc. archs according to Arnd's suggestions. Thanks, Fengguang -- 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 v1 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
This series fully update existing ISOC DDMA flow which initially based on 2 descriptor chains. Switching between desc chains performing based on BNA interrupt. Because of BNA interrupt few packets can be lost. 1/3 patch unmask ISOC IN BNA interrupt only. 2/3 patch changing ISOC IN/OUT flow as described above. 3/3 patch add High bandwidth ISOC OUT transfers support. All patches were tested on HAPS-DX7 platform using internal USB test tool. Changes from version 0: Fix kbuild test robot warnings on idents. Minas Harutyunyan (3): usb: dwc2: Enable BNA interrupt for IN endpoints usb: dwc2: Change ISOC DDMA flow usb: dwc2: Add High Bandwidth ISOC OUT support drivers/usb/dwc2/core.h | 2 - drivers/usb/dwc2/gadget.c | 505 -- 2 files changed, 359 insertions(+), 148 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with -ETIMEDOUT.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with -EIO and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with -ENODATA. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW not supported EP's with
bInterval more than 12.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 -
drivers/usb/dwc2/gadget.c | 235 ++
2 files changed, 113 insertions(+), 124 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..093d078adaf4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -231,7 +230,6 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
charname[10];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..1b9c84cb58fb 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 mask = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
- if (len > maxsize) {
- dev_err(hsotg->dev, "wrong len %d\n", len);
- return -EINVAL;
- }
-
- /*
-* If SW has already filled half of chain, then return and wait for
-* the other chain to be processed by HW.
-*/
- if (hs_ep->next_desc == MAX_DMA_DESC_NUM_GENERIC / 2)
- return -EBUSY;
- /* Increment frame number by interval for IN */
- if (hs_ep->dir_in)
- dwc2_gadget_incr_frame_num(hs_ep);
-
- index = (MAX_DMA_DESC_NUM_GENERIC / 2) * hs_ep->isoc_chai
[PATCH v1 3/3] usb: dwc2: Add High Bandwidth ISOC OUT support
Updated checking of chain full condition based on mult count.
For each packet in uframe (dpi) created new desc by
setting size of transfer to mps. Buffer addresses in descs
differ by mps in function dwc2_gadget_fill_isoc_desc().
In function dwc2_gadget_start_isoc_ddma() upadted loop
boundaries according to desc chain length.
In function dwc2_hsotg_ep_queue() added request length
checking for HB ISOC OUT transfers. Added dword aligned
limitation on maxpacket size for HB ISOC OUT's.
In function dwc2_gadget_complete_isoc_request_ddma()
separated processing of descs for HB ISOC OUT.
If completed descs PID equal MDATA do nothing, else
get remaining for frame descs and process them.
Actual length accumulated based on descs. Break
execution of the loop if data packet PID not MDATA.
If host sends less than mult data packets then skipping
unused desc for current uframe by restarting ISOC transfers.
In function dwc2_hsotg_ep_enable() desc chain allocation/
deallocation increased by mult times. Added bInterval
limit checking for HB ISOC OUT because on completion frame
number from desc used to check frame elapsed or no.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 348 +-
1 file changed, 284 insertions(+), 64 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 1b9c84cb58fb..a0de8f2eb0d8 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -806,55 +806,82 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ int dpi, i;
+ /* Get descritor length limits */
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
index = hs_ep->next_desc;
- desc = &hs_ep->desc_list[index];
+
+ dpi = 1;
+ if (!hs_ep->dir_in)
+ dpi = hs_ep->mc;
/* Check if descriptor chain full */
- if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
- DEV_DMA_BUFF_STS_HREADY) {
- dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
- return 1;
+ for (i = 0; i < dpi; i++) {
+ /* Check descriptor chain rollover */
+ if ((index + i) >= dpi * MAX_DMA_DESC_NUM_GENERIC)
+ index = -1;
+
+ desc = &hs_ep->desc_list[index + i];
+ if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
+ DEV_DMA_BUFF_STS_HREADY) {
+ dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
+ return 1;
+ }
}
- /* Clear L bit of previous desc if more than one entries in the chain */
- if (hs_ep->next_desc)
- hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
+ for (i = 0; i < dpi; i++) {
+ index = hs_ep->next_desc;
- dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc # %d\n",
- __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out", index);
+ /* Clear L bit of previous desc if more
+* than one entries in the chain
+*/
+ if (hs_ep->next_desc)
+ hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
- desc->status = 0;
- desc->status |= (DEV_DMA_BUFF_STS_HBUSY << DEV_DMA_BUFF_STS_SHIFT);
+ desc = &hs_ep->desc_list[index];
- desc->buf = dma_buff;
- desc->status |= (DEV_DMA_L | DEV_DMA_IOC |
-((len << DEV_DMA_NBYTES_SHIFT) & mask));
+ dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc #
%d\n",
+ __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out",
+ index);
- if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
- ((hs_ep->target_frame <<
- DEV_DMA_ISOC_FRNUM_SHIFT) &
-DEV_DMA_ISOC_FRNUM_MASK);
- }
+ desc->status = 0;
+ desc->status |= (DEV_DMA_BUFF_STS_HBUSY <<
+ DEV_DMA_BUFF_STS_SHIFT);
- desc->status &= ~DEV_DMA_BUFF_STS_MASK;
- desc->status |= (DEV_DMA_BUFF_STS_HREADY << DEV_DMA_BUFF_STS_SHIFT);
+ desc->buf = dma_buff + i * hs_ep->ep.maxpacket;
+ desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
+ if (hs_ep->dir_in)
+ desc->status |= ((len << DEV_DMA_NBYTES_SHIFT)
+ & mask);
+ else
+ desc->status |= ((hs_ep->ep.maxpacket <<
+ DEV_DMA_NBYTES_SHIFT) & mask);
+
+ if (hs
[PATCH v1 1/3] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] drivers/usb/storage: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
On Fri, 16 Mar 2018, Joe Moriarty wrote:
> The Parfait (version 2.1.0) static code analysis tool found the
> following NULL pointer dereference problem.
>
> dev_to_shost() in include/scsi/scsi_host.h has the ability to return
> NULL if the scsi host device does not have the Scsi_host->parent
> field set. With the possibilty of a NULL pointer being set for
> the Scsi_Host->parent field, calls to host_to_us() have to make
> sure the return pointer is not null. Changes were made to check
> for a return value of NULL on calls to host_to_us().
>
> Signed-off-by: Joe Moriarty
> Reviewed-by: Steven Sistare
> Acked-by: Hakon Bugge
> ---
> drivers/usb/storage/scsiglue.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index c267f2812a04..00a8cb005e83 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -329,7 +329,18 @@ static int slave_configure(struct scsi_device *sdev)
>
> static int target_alloc(struct scsi_target *starget)
> {
> - struct us_data *us = host_to_us(dev_to_shost(starget->dev.parent));
> + struct Scsi_Host *host;
> + struct us_data *us;
> +
> + host = dev_to_shost(starget->dev.parent);
> + if (!host) {
> + dev_dbg(&(starget)->dev,
> + "SCSI Host not found, Error in %s: us = NULL\n",
> + __func__);
> + return -ENODEV;
> + }
> +
> + us = host_to_us(host);
NAK. This condition can never happen; if it does then there's a bug in
the SCSI core and the system _should_ oops.
This routine is called from only one place: scsi_alloc_target(). In
that routine, starget->dev.parent is explicitly set to point at a
Scsi_Host. The NULL return you're worried about cannot happen in that
case, because the "while" loop will not execute at all:
static inline struct Scsi_Host *dev_to_shost(struct device *dev)
{
while (!scsi_is_host_device(dev)) {
if (!dev->parent)
return NULL;
dev = dev->parent;
}
return container_of(dev, struct Scsi_Host, shost_gendev);
}
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 v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub
On Sat, 17 Mar 2018, Benjamin Herrenschmidt wrote: > On Fri, 2018-03-16 at 16:56 -0400, Alan Stern wrote: > > On Fri, 16 Mar 2018, Benjamin Herrenschmidt wrote: > > > > > On Thu, 2018-03-15 at 08:03 +1100, Benjamin Herrenschmidt wrote: > > > > > > Do you have more comments for the rest of the driver or that's it ? > > > > > > > > > > so far, that's it. > > > > > > > > Ok. I'll re-send. > > > > > > So I'll resend in a minute, doing a few more tests, however, I've > > > noticed something which I wont' have time to track down til at > > > best next week, I wonder if it's normal/expected. > > > > > > If I just create a mass storage function set to be "removable" and > > > "cdrom" with no file attached, and enable it, I get an endless stream > > > of resets. It looks like the host constantly does USB resets. > > > > That's not why I get. There's an endless stream of messages, but it > > doesn't include any resets. Just command failures and endpoint halts. > > For example: > > .../... > > In my case, I was getting resets on the host: > > [383250.844611] usb 1-1: new high-speed USB device number 84 using xhci_hcd > [383250.972235] usb 1-1: New USB device found, idVendor=1d6b, idProduct=0107 > [383250.972244] usb 1-1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [383250.972251] usb 1-1: Product: USB Virtual Hub > [383250.972257] usb 1-1: Manufacturer: Aspeed > [383250.972262] usb 1-1: SerialNumber: > [383250.979127] hub 1-1:1.0: USB hub found > [383250.979218] hub 1-1:1.0: 5 ports detected > [383284.910195] usb 1-1.1: new high-speed USB device number 85 using xhci_hcd > [383284.988326] usb 1-1.1: New USB device found, idVendor=1d6b, idProduct=0104 > [383284.988339] usb 1-1.1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [383284.988349] usb 1-1.1: Product: Bar Gadget > [383284.988358] usb 1-1.1: Manufacturer: Foo Inc. > [383284.988366] usb 1-1.1: SerialNumber: 0123456789 > [383285.000159] usb-storage 1-1.1:1.0: USB Mass Storage device detected > [383285.000613] scsi host3: usb-storage 1-1.1:1.0 > [383286.063152] scsi 3:0:0:0: CD-ROMLinuxFile-CD Gadget > 0416 PQ: 0 ANSI: 2 > [383286.064148] sr 3:0:0:0: Power-on or device reset occurred > [383286.129411] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383286.284397] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383286.438396] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383286.593487] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383286.676863] sr 3:0:0:0: [sr0] scsi-1 drive > [383286.676871] cdrom: Uniform CD-ROM driver Revision: 3.20 > [383286.678558] sr 3:0:0:0: Attached scsi CD-ROM sr0 > [383286.679426] sr 3:0:0:0: Attached scsi generic sg2 type 5 > [383286.746343] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383286.901458] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.056423] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.211445] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.360422] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.516295] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.671464] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.827423] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > [383287.912048] sr 3:0:0:0: Power-on or device reset occurred > [383288.013376] usb 1-1.1: reset high-speed USB device number 85 using > xhci_hcd > > The guest just show config selection messages. I'll dig a bit next week > in case there's an issue with my UDC driver there. Output from usbmon could help. > As for ... > > > It's worth pointing out that all those messages are at DEBUG level. > > Although they fill up the kernel's log buffer, they won't be noticeable > > to most users. > > > > In any case, g-mass-storage was never intended be a complete emulation > > of a CD or DVD drive. Its support for those modes is minimal; it was > > originally intended just to emulate a hard disk drive. > > Then it will be worthwhile me or somebody else spending a bit of time > beefing it up a little bit. I'll see if I can spare time in the next > couple of weeks. Maybe... Even after cdrom support was added to the gadget, the scope was limited. It was intended to emulate _only_ a CD drive, not a DVD drive. Also, if I'm not mistaken, the commands that the emulation doesn't handle are all optional. Alan Stern > The Aspeed chip is a BMC chip, ie server management processor, and is > connected via the USB gadget to the actual server (the host). One of > the usage scenario here is to use USB gadget to present distro ISOs as > USB CD/DVDs to the host for remote provisioning (sourced over the > network via something like nbd). > > Note that due to the limitation of having to use
Re: USB regression for Android phone and sound card in 4.14
With kernel 4.16-rc5 it is still happening to USB sound card, Android phone issue was probably related to something else and is already fixed. Very annoying to unplug sound card after each reboot, any ideas why this might happen? Sincerely, Nazar Mokrynskyi github.com/nazar-pc 13.02.18 01:26, Nazar Mokrynskyi пише: > Starting from 4.14 and continuing in 4.15 I observe 2 bugs that I think are > related and didn't exist in 4.13. > > The first would be more difficult to reproduce: USB sound card Creative SB > Omni Surround 5.1 after system boot only shows 2.0 stereo output option, > while it also supports 5.1 and PulseAudio configured accordingly. If unplug > and plug it back in, 5.1 mode appears and I can select between 2.0 and 5.1. > You can boot with stock Ubuntu 17.10 and 18.04 as of right now and the first > one will work properly and second one will have mentioned bug. > > Second bug is easier to reproduce: when connecting Nexus 6P via USB cable, it > appears in file manager devices list (Nemo, Nautilus, etc.), but when it is > unplugged it doesn't disappear when running kernels 4.14 and 4.15. I have 7 > Nexus 6P entries already, unplugging and plugging back looks like this: > > [200038.821988] usb 3-1: new high-speed USB device number 4 using xhci_hcd > [200039.043611] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [200039.043612] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [200039.043614] usb 3-1: Product: Nexus 6P > [200039.043614] usb 3-1: Manufacturer: Huawei > [200039.043615] usb 3-1: SerialNumber: 8XV7N1612893 > [202243.949672] usb 3-1: USB disconnect, device number 4 > [205549.671959] usb 3-1: new high-speed USB device number 5 using xhci_hcd > [205549.893327] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [205549.893328] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [205549.893329] usb 3-1: Product: Nexus 6P > [205549.893329] usb 3-1: Manufacturer: Huawei > [205549.893330] usb 3-1: SerialNumber: 8XV7N1612893 > [205550.602646] usb 3-1: USB disconnect, device number 5 > [205553.456007] usb 3-1: new high-speed USB device number 6 using xhci_hcd > [205553.680392] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [205553.680394] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [205553.680394] usb 3-1: Product: Nexus 6P > [205553.680395] usb 3-1: Manufacturer: Huawei > [205553.680396] usb 3-1: SerialNumber: 8XV7N1612893 > [206021.635511] usb 3-1: USB disconnect, device number 6 > [206024.169853] usb 3-1: new high-speed USB device number 7 using xhci_hcd > [206024.392921] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [206024.392923] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [206024.392924] usb 3-1: Product: Nexus 6P > [206024.392925] usb 3-1: Manufacturer: Huawei > [206024.392925] usb 3-1: SerialNumber: 8XV7N1612893 > [206034.058208] usb 3-1: USB disconnect, device number 7 > [206036.914005] usb 3-1: new high-speed USB device number 8 using xhci_hcd > [206037.136891] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [206037.136893] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [206037.136894] usb 3-1: Product: Nexus 6P > [206037.136895] usb 3-1: Manufacturer: Huawei > [206037.136895] usb 3-1: SerialNumber: 8XV7N1612893 > [206080.923547] usb 3-1: USB disconnect, device number 8 > [206083.526585] usb 3-1: new high-speed USB device number 9 using xhci_hcd > [206083.752601] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1 > [206083.752602] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [206083.752603] usb 3-1: Product: Nexus 6P > [206083.752604] usb 3-1: Manufacturer: Huawei > [206083.752605] usb 3-1: SerialNumber: 8XV7N1612893 > > These 2 issues appeared at the same time, so I think they are related. > Let me know if you can't reproduce them and need any additional information > and CC me on answers as I'm not subscribed to this mailing list. > -- 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
