Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+
On Tue, Jan 30, 2018 at 07:32:04AM +0100, Greg KH wrote: > On Mon, Jan 29, 2018 at 07:21:09PM +0100, Markus Demleitner wrote: > > A while ago I opened bug #197863 in the kernel bugzilla: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=197863 > > > > Essentially, xhci_hcd on a resume from RAM takes several seconds on a > > Thinkpad X240 that is equipped with a Sierra LTE modem after an > > upgrade to 4.13: [...] > > Now, interestingly, there are quick resumes in 4.15.0, too, now and > > then. In that case, things look pretty much like on 4.12.2. Here's > > a 4.15.0 fast resume example: > > > > [ 873.127570] usb 1-4: device firmware changed > > [ 873.277351] usb 1-8: reset high-speed USB device number 4 using xhci_hcd > > [ 873.515141] restoring control ----0101/0/2 > > [ 873.583238] OOM killer enabled. > > [ 873.583240] Restarting tasks ... > > [ 873.583339] usb 1-4: USB disconnect, device number 10 > > [ 873.586356] done. > > [ 873.604420] PM: suspend exit > > [ 873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd > > [ 880.867398] usb 1-4: device descriptor read/64, error -110 > > [ 881.175558] usb 1-4: New USB device found, idVendor=1199, idProduct=a001 > > [ 881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, > > SerialNumber=3 > > [ 881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE > > [ 881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc. > > [ 881.175570] usb 1-4: SerialNumber: 013937002544516 > > > > Any guess what might be behind this? > > Any chance you can run 'git bisect' to find the offending commit for > this issue? It's 662591461c4b9a1e3b9b159dbf37648a585ebaae. To my eyes, it even looks plausible that it's causing the problematic behaviour, but since I can't say I understand what I'd be doing if I dabbled with the change, I've refrained from guessing how to fix it. I'm happy to try patches, though. Thanks, Markus -- 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
Bug: WD My Passport Drive sometimes crashes when connected on left USB port [Dell Latitude 3340]
Was told to report this here from https://bugzilla.kernel.org/show_bug.cgi?id=198655 Dell Latitude 3340, A14 BIOS 4.15.0-1-default #1 SMP PREEMPT Wed Jan 31 07:03:28 UTC 2018 (ac01747) x86_64 x86_64 x86_64 GNU/Linux Sometimes when WD My Passport is connected to the left side USB port, the drive starts to power up, then crashes while spinning up disk. After the drive crashing and powering off quickly, it powers back on successfully and is readable as normal. Expected: drive connects and stays powered on the first time as usual. I don't think this is a hardware issue since I haven't observed it on the right side port, and the fact that it is able to read the drive after disconnecting and reconnecting. 4.15 dmesg output (also attached): [ 522.124227] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [ 522.144960] usb 2-1: New USB device found, idVendor=1058, idProduct=0748 [ 522.144967] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 522.144971] usb 2-1: Product: My Passport 0748 [ 522.144975] usb 2-1: Manufacturer: Western Digital [ 522.144978] usb 2-1: SerialNumber: [ 522.145887] usb-storage 2-1:1.0: USB Mass Storage device detected [ 522.150584] scsi host3: usb-storage 2-1:1.0 [ 523.164907] scsi 3:0:0:0: Direct-Access WD My Passport 0748 1025 PQ: 0 ANSI: 6 [ 523.165142] sd 3:0:0:0: Attached scsi generic sg2 type 0 [ 523.165492] scsi 3:0:0:1: Enclosure WD SES Device 1025 PQ: 0 ANSI: 6 [ 523.166247] sd 3:0:0:0: [sdc] Spinning up disk... [ 523.166988] ses 3:0:0:1: Attached Enclosure device [ 523.167071] ses 3:0:0:1: Attached scsi generic sg3 type 13 [ 524.188157] . [ 524.212261] xhci_hcd :00:14.0: Cannot set link state. [ 524.212276] usb usb2-port1: cannot disable (err = -32) [ 524.212290] usb 2-1: USB disconnect, device number 4 [ 524.212591] ready [ 524.212835] sd 3:0:0:0: [sdc] Read Capacity(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 524.212842] sd 3:0:0:0: [sdc] Sense not available. [ 524.212851] sd 3:0:0:0: [sdc] 0 512-byte logical blocks: (0 B/0 B) [ 524.212855] sd 3:0:0:0: [sdc] 0-byte physical blocks [ 524.212935] sd 3:0:0:0: [sdc] Write Protect is off [ 524.212941] sd 3:0:0:0: [sdc] Mode Sense: 00 00 00 00 [ 524.213022] sd 3:0:0:0: [sdc] Asking for cache data failed [ 524.213034] sd 3:0:0:0: [sdc] Assuming drive cache: write through [ 524.213632] sd 3:0:0:0: [sdc] Read Capacity(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 524.213640] sd 3:0:0:0: [sdc] Sense not available. [ 524.213732] sd 3:0:0:0: [sdc] Attached SCSI disk [ 524.228085] ses 3:0:0:1: Failed to get diagnostic page 0x1 [ 524.228095] ses 3:0:0:1: Failed to bind enclosure -19 [ 525.724129] usb 2-1: new SuperSpeed USB device number 5 using xhci_hcd [ 525.744845] usb 2-1: New USB device found, idVendor=1058, idProduct=0748 [ 525.744851] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 525.744853] usb 2-1: Product: My Passport 0748 [ 525.744855] usb 2-1: Manufacturer: Western Digital [ 525.744857] usb 2-1: SerialNumber: [ 525.745653] usb-storage 2-1:1.0: USB Mass Storage device detected [ 525.749809] scsi host3: usb-storage 2-1:1.0 [ 526.780883] scsi 3:0:0:0: Direct-Access WD My Passport 0748 1025 PQ: 0 ANSI: 6 [ 526.781159] sd 3:0:0:0: Attached scsi generic sg2 type 0 [ 526.781489] scsi 3:0:0:1: Enclosure WD SES Device 1025 PQ: 0 ANSI: 6 [ 526.782267] sd 3:0:0:0: [sdc] Spinning up disk... [ 526.783052] ses 3:0:0:1: Attached Enclosure device [ 526.783161] ses 3:0:0:1: Attached scsi generic sg3 type 13 [ 527.804065] . [ 528.475093] ses 3:0:0:1: Wrong diagnostic page; asked for 1 got 8 [ 528.475102] ses 3:0:0:1: Failed to get diagnostic page 0x1 [ 528.475108] ses 3:0:0:1: Failed to bind enclosure -19 [ 528.475992] ready [ 528.477383] sd 3:0:0:0: [sdc] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) [ 528.477630] sd 3:0:0:0: [sdc] Write Protect is off [ 528.477634] sd 3:0:0:0: [sdc] Mode Sense: 47 00 10 08 [ 528.477871] sd 3:0:0:0: [sdc] No Caching mode page found [ 528.477878] sd 3:0:0:0: [sdc] Assuming drive cache: write through [ 528.489654] sd 3:0:0:0: [sdc] Attached SCSI disk [ 522.124227] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [ 522.144960] usb 2-1: New USB device found, idVendor=1058, idProduct=0748 [ 522.144967] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 522.144971] usb 2-1: Product: My Passport 0748 [ 522.144975] usb 2-1: Manufacturer: Western Digital [ 522.144978] usb 2-1: SerialNumber: [ 522.145887] usb-storage 2-1:1.0: USB Mass Storage device detected [ 522.150584] scsi host3: usb-storage 2-1:1.0 [ 523.164907] scsi 3:0:0:0: Direct-Access WD My Passport 0748 1025 PQ: 0 ANSI: 6 [ 523.165142] sd 3:0:0:0: Attached scsi generic sg2 type 0 [ 523.165492] scsi 3:0:0:1: Enclosure WD SES Device 1025 PQ: 0 ANSI: 6 [ 5
Re: [PATCH 2/3] usb: dwc3: of-simple: add support for shared and pulsed reset lines
Hi Felipe,
On Mon, Jan 29, 2018 at 9:18 AM, Felipe Balbi wrote:
>
> Hi,
>
> Martin Blumenstingl writes:
>> Some SoCs (such as Amlogic Meson GXL for example) share the reset line
>> with other components (in case of the Meson GXL example there's a shared
>> reset line between the USB2 PHYs, USB3 PHYs and the dwc3 controller).
>> Additionally SoC implementations may prefer a reset pulse over level
>> resets.
>>
>> Add an internal per-of_device_id struct which can be used to configure
>> whether the reset lines are shared and whether they use level or pulse
>> resets.
>>
>> For now this falls back to the old defaults, which are:
>> - reset lines are exclusive
>> - level resets are being used
>>
>> Signed-off-by: Martin Blumenstingl
>> ---
>> drivers/usb/dwc3/dwc3-of-simple.c | 65
>> ---
>> 1 file changed, 54 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
>> b/drivers/usb/dwc3/dwc3-of-simple.c
>> index 7ae0eefc7cc7..ceb9f0cd822a 100644
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -22,11 +22,22 @@
>> #include
>> #include
>>
>> +/**
>> + * struct dwc3_of_simple_params - hardware specific parameters
>> + * @shared_resets: indicates that the resets are shared or exclusive
>> + * @pulse_resets: use a reset pulse instead of level based resets
>> + */
>> +struct dwc3_of_simple_params {
>> + boolshared_resets;
>> + boolpulse_resets;
>> +};
>> +
>> struct dwc3_of_simple {
>> struct device *dev;
>> struct clk **clks;
>> int num_clocks;
>> struct reset_control*resets;
>> + const struct dwc3_of_simple_params *params;
>
> instead, you can add these two fields here:
>
> bool shared_resets;
> bool pulse_resets;
>
> and ...
>
>> @@ -90,17 +101,26 @@ static int dwc3_of_simple_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, simple);
>> simple->dev = dev;
>> + simple->params = of_device_get_match_data(dev);
>>
>> - simple->resets = of_reset_control_array_get_optional_exclusive(np);
>> + simple->resets = of_reset_control_array_get(np,
>> + simple->params->shared_resets,
>> + true);
>
> wrap this with a of_device_is_compatible() check:
>
> if (of_device_is_compatible(dev->of_node, "foobar")) {
> simple->shared_resets = true;
> simple->pulse_resets = true;
> }
>
> or something like that. Then we don't need to add a new
> dwc3_of_simple_params for everybody.
sure, I can do this if that fits the coding style in the dwc3 driver better
in that case, do you still want me to keep patches #2 and #3 separate?
> Also, the why isn't the reset type (pulse vs level) handled by reset
> framework itself? Why does dwc3-of-simple need to know about it?
the Amlogic reset driver supports both, level resets and reset pulses
unfortunately the reset line is de-asserted by default, so to reset it
we would have to:
- assert it first
- then de-assert it again
however, the reset framework does not allow this for shared resets
(see reset_control_assert: it triggers a WARN_ON if we try to assert a
shared reset which has not been de-asserted yet)
together with the fact that there are reset controller hardware
implementations out there which don't support level resets I decided
to implement it as reset pulse
Regards
Martin
--
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
power management problems in ehci-omap
Hi, I booted a 4.15 kernel without udev and loaded modules piece by piece to analyze pm problems. modprobe ehci-omap increases current by around 35mA and also rmmod ehci-omap does not let it go down at all. I expect that removing hardware does the same thing Also suspend current increases by around 15mA if that module is loaded. I tested with having everything disabled which is attached to that usb bus. System was GTA04A5 (with dm3730 processor and usb3322 phy) I know it has worked once, but I do not remember the version. The kernel config used can be found here: http://misc.andi.de1.cc/config-4.15.gz Regards Andreas BTW: I am at the FOSDEM, will probably spend a lot of time in the hw enablement devroom. So maybe ideas could be discussed directly. -- 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: power management problems in ehci-omap
Hi On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade wrote: > Hi, > > I booted a 4.15 kernel without udev and loaded modules piece by piece to > analyze > pm problems. modprobe ehci-omap increases current by around 35mA and > also rmmod ehci-omap does not let it go down at all. > > I expect that removing hardware does the same thing > > Also suspend current increases by around 15mA if that module is loaded. > I tested with having everything disabled which is attached to that usb bus. > Do you have an LTE connected to the usb? Michael > System was > GTA04A5 (with dm3730 processor and usb3322 phy) > > I know it has worked once, but I do not remember the version. > > The kernel config used can be found here: > http://misc.andi.de1.cc/config-4.15.gz > > Regards > Andreas > BTW: I am at the FOSDEM, will probably spend a lot of time in the > hw enablement devroom. So maybe ideas could be discussed directly. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- 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] option: Add support for Quectel EP06
On Wed, Jan 31, 2018 at 04:35:34PM -0600, Dan Williams wrote: > On Wed, 2018-01-31 at 16:32 -0600, Dan Williams wrote: > > On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote: > > > On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote: > > > > Hi Johan, > > > > > > > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold > > > > wrote: > > > > > This will probably have to do for now, but we already have > > > > > another > > > > > blacklist struct with the same content which we could rename > > > > > and > > > > > reuse. > > > > > > > > I noticed the same, but wasn't quite sure about the policy on > > > > renaming/recycling and added a new blacklist entry. I can rename > > > > the > > > > entry and update references as part of this commit. What would be > > > > an > > > > appropriate name, something straight-forward like > > > > "net_intf4_intf5_blacklist"? > > > > > > Yeah, the policy isn't entirely clear to me either. ;) The > > > net_blacklist > > > are used to blacklist a single network interface, but here the > > > other > > > interface was used for ADB and for the other driver it was for an > > > audio > > > interface I think. > > > > When I added/consolidated this feature a long time back I didn't > > think > > we'd end up with as many common entries as we have. I think it's > > fine > > to re-use use a common entry, but if you do and the common entry is > > named after a vendor/model, then make it generic. IIRC we have already started reusing entries, but the names have not always been made generic in the process. I think Bjørn may have proposed a generic naming scheme at some point, but that essentially just meant we encoded the two masks in the name. Then we may just move over to encoding the masks directly in driver_data instead, at least if 16 bits is enough. > IIRC I considered just dumping the BIT(x) into the .driver_info but > then we'd only have 16 bits for each of send_setup and reserved on 32- > bit arches and I wasn't sure that was enough. I've seen some devices > with lots of interfaces. But doing it this way might have been clearer > than a sidecar struct like option_blacklist_info. Yeah, we should probably consider moving over to something like that. 16 bits would at least be enough for the devices we currently have blacklists for. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] USB: serial: f81232: enable remote wakeup via RX/RI pin
On Thu, Feb 01, 2018 at 11:13:01AM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2018/1/30 上午 11:57 寫道: > > On Mon, Jan 22, 2018 at 03:58:45PM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> The F81232 can do remote wakeup via RX/RI pin with pulse. > >> This patch will use device_set_wakeup_enable to enable this > >> feature. > > > > This is a policy decision that should be made by user space by setting > > the power/wakeup attribute, and not something that something that > > drivers should enable directly themselves. > > > > Perhaps you really wanted to use device_set_wakeup_capable()? But then > > you also need to honour the current setting in suspend() as well. > > > > How have you tested this feature? > > > > Our USB-To-Serial support RI/ RX remote wakeup by Modem, Fax or > other peripherals and we had tested it by following procedure with > device_set_wakeup_enable() enabled: > 1. Using pm-suspend to S3 > 2. Trigger a pulse to RI/RX to wake up system. > > In our test, we can do remote wakeup only with > device_set_wakeup_enable() enabled. Yeah, but you need to enable it though sysfs. Not every device should be able to wake the system up. That's a decision left for user space. > Should we add device_set_wakeup_capable() & device_set_wakeup_enable() > like following link?? > https://elixir.free-electrons.com/linux/latest/source/drivers/media/rc/mceusb.c#L1476 No, your driver should not call device_set_wakeup_enable() itself. Just set the wakeup capable flag in probe. And if you can disable the wake up feature, this needs to be done at suspend depending on what user space has requested. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] USB: serial: f81232: fix bulk_in/out size
On Thu, Feb 01, 2018 at 01:50:55PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Johan,
>
> Johan Hovold 於 2018/1/30 下午 12:11 寫道:
> > On Mon, Jan 22, 2018 at 03:58:47PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> >> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> >> index a054f69446fd..f3ee537d643c 100644
> >> --- a/drivers/usb/serial/f81232.c
> >> +++ b/drivers/usb/serial/f81232.c
> >> @@ -769,8 +769,7 @@ static struct usb_serial_driver f81232_device = {
> >>},
> >>.id_table = id_table,
> >>.num_ports =1,
> >> - .bulk_in_size = 256,
> >> - .bulk_out_size =256,
> >> + .bulk_out_size =16,
> >
> > So it seems you should really be setting bulk_in_size to 64 here (and
> > possibly leave bulk_out_size unset) as that would appear to match your
> > device buffer sizes.
>
> Yes, we want to set the bulk_in_size as 64. The public datasheet has
> some error with bulk in/out, the correct size is 64.
>
> We had test the bulk_out_size set the same with internal TX FIFO will
> make the best performance in tests, but it's ok to set 64. In my opinion
> , I'll prefer to set 16.
Having larger URB buffers than the endpoint size is typically more
efficient, but sometimes there are hardware issues that needs to be
worked around.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: serial: option: Add support for Quectel EP06
On Thu, Feb 01, 2018 at 10:32:32AM +0100, Kristian Evensen wrote: > The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as > follows: > > 0: Diag > 1: NMEA > 2: AT > 3: Modem > > Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. > > This patch should also be considered for -stable. The QMI-patch for this > modem is already in the -stable-queue. > > v1->v2: > * Updated commit prefix (thanks Johan Hovold) > * Updated commit message slightly. The changelog typically goes below the cut-off line (---). > Signed-off-by: Kristian Evensen No need to block this pending the discussion on how to deal with duplicate blacklist entries. So for my own reference, or if Greg wants to pick this up sooner: Acked-by: Johan Hovold Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: serial: option: Add support for Quectel EP06
On Sun, Feb 04, 2018 at 12:55:46PM +1100, Johan Hovold wrote: > On Thu, Feb 01, 2018 at 10:32:32AM +0100, Kristian Evensen wrote: > > The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as > > follows: > > > > 0: Diag > > 1: NMEA > > 2: AT > > 3: Modem > > > > Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. > > > > This patch should also be considered for -stable. The QMI-patch for this > > modem is already in the -stable-queue. > > > > v1->v2: > > * Updated commit prefix (thanks Johan Hovold) > > * Updated commit message slightly. > > The changelog typically goes below the cut-off line (---). > > > Signed-off-by: Kristian Evensen > > No need to block this pending the discussion on how to deal with > duplicate blacklist entries. So for my own reference, or if Greg wants > to pick this up sooner: > > Acked-by: Johan Hovold Thanks, I'll pick this up once 4.16-rc1 come out. 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: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+
On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote: > On Tue, Jan 30, 2018 at 07:32:04AM +0100, Greg KH wrote: > > On Mon, Jan 29, 2018 at 07:21:09PM +0100, Markus Demleitner wrote: > > > A while ago I opened bug #197863 in the kernel bugzilla: > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=197863 > > > > > > Essentially, xhci_hcd on a resume from RAM takes several seconds on a > > > Thinkpad X240 that is equipped with a Sierra LTE modem after an > > > upgrade to 4.13: > [...] > > > Now, interestingly, there are quick resumes in 4.15.0, too, now and > > > then. In that case, things look pretty much like on 4.12.2. Here's > > > a 4.15.0 fast resume example: > > > > > > [ 873.127570] usb 1-4: device firmware changed > > > [ 873.277351] usb 1-8: reset high-speed USB device number 4 using > > > xhci_hcd > > > [ 873.515141] restoring control ----0101/0/2 > > > [ 873.583238] OOM killer enabled. > > > [ 873.583240] Restarting tasks ... > > > [ 873.583339] usb 1-4: USB disconnect, device number 10 > > > [ 873.586356] done. > > > [ 873.604420] PM: suspend exit > > > [ 873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd > > > [ 880.867398] usb 1-4: device descriptor read/64, error -110 > > > [ 881.175558] usb 1-4: New USB device found, idVendor=1199, > > > idProduct=a001 > > > [ 881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, > > > SerialNumber=3 > > > [ 881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE > > > [ 881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc. > > > [ 881.175570] usb 1-4: SerialNumber: 013937002544516 > > > > > > Any guess what might be behind this? > > > > Any chance you can run 'git bisect' to find the offending commit for > > this issue? > > It's 662591461c4b9a1e3b9b159dbf37648a585ebaae. To my eyes, it even > looks plausible that it's causing the problematic behaviour, but > since I can't say I understand what I'd be doing if I dabbled with > the change, I've refrained from guessing how to fix it. > > I'm happy to try patches, though. Ok, thanks. I've added the authors of this patch to the email here, perhaps they have an idea of what is going on? 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
[no subject]
This is in regards to an inheritance on your surname, reply back using your email address, stating your full name for more details. Reply to email for info. Email me here ( ger...@dr.com ) -- 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
