Re: USB gadgets with configfs hang reboot

[Felipe Balbi]

Hi,

Alan Stern  writes:
> On Thu, 31 Mar 2016, Ivaylo Dimitrov wrote:
>
>> > This isn't supposed to cause any problems.  The two instances should
>> > never run at the same time, because they belong to different configs.
>> >
>> 
>> The problem seems to be that fsg driver creates a thread for every 
>> fsg_bind() call, which overwrites common->thread_task without first 
>> checking if a thread is already created. I don't know the idea behind - 
>> should it have only one thread for all instances, or there should be a 
>> thread per instance, but anyway the current implementation looks wrong.
>
> You've put your finger on the problem.
>
> Michal, I'm not sure how you intended to handle this.  We only need to
> have one thread per interface (even if there's more than one LUN), but
> if there are multiple mass-storage interfaces in one configuration then
> you might want to have multiple threads.  Of course, then you would
> have to handle cases where one config has one mass-storage interface
> and another config has two...
>
> It's your decision, but clearly the driver needs to be fixed.

I agree, this is now very clear what the problem is.

-- 
balbi


signature.asc
Description: PGP signature

Re: USB gadgets with configfs hang reboot

[Felipe Balbi]

Hi,

Ivaylo Dimitrov  writes:
>>> Looks like there's some issue with the USB gadgets and configfs.
>>>
>>> I'm seeing rmmod of the UDC driver cause a warning and then reboot
>>> hangs the system. This happens at least with v4.4, and I've 
>>> reproduced
>>> it with dwc3 and musb so it seems to be generic.
>>>
>>
>> Having configfs is not needed, disabling usb gadgets (#
>> CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff
>> hang issue on N900. Also, g_nokia is not a module in the config I 
>> use,
>> so I guess the problem is not related whether gadgets are modular or
>> not. Unfortunately I was not able to test reboot, as rootfs became
>> corrupted after the first poweroff :( . So it looks like my theory 
>> that
>> onenand corruption on N900 is because poweroff/reboot hangs is wrong.
>>
>> Ivo
>
>
> Is there any progress on the issue?

>>>
>>> Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo
>>> musb-hdrc.0.auto > unbind results in:
>>>
>>> <1>[ 1418.511260] Unable to handle kernel paging request at virtual
>>> address 6c6c757a
>>> <7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
>>> <1>[ 1418.683349] pgd = c0004000
>>> <1>[ 1418.739959] [6c6c757a] *pgd=
>>> <0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
>>> <4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng
>>> ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm
>>> ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech
>>> hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger
>>> gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005
>>> tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523
>>> leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820
>>> v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c
>>> lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem
>>> ssi_protocol omap_ssi hsi rx51_battery
>>> <4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
>>> 4.5.0-rc5+ #59
>>> <4>[ 1418.846130] Hardware name: Nokia RX-51 board
>>> <4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
>>> <4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
>>> <4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
>>> <4>[ 1418.879241] pc : []lr : []psr: 
>>> 8013
>>> <4>[ 1418.879241] sp : ce009ea0  ip :   fp : 
>>> <4>[ 1418.898284] r10:   r9 :   r8 : 
>>> <4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 :   r4 : 
>>> cebe1600
>>> <4>[ 1418.917663] r3 : 6f642820  r2 :   r1 :   r0 : 
>>> 
>>> <4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>>> Segment none
>>> <4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 0051
>>> <0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 
>>> 0xce008210)
>>> <0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
>>> <0>[ 1418.966735] 9ea0: 000f   0b07 
>>> 0001 03ff 0001
>>> <0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300  c004841c 
>>> 0002 ce888000 c0451a50
>>> <0>[ 1418.991180] 9ee0:    0008 cebe1600
>>> 0001 c0717dd0 0001
>>> <0>[ 1419.003387] 9f00:   ce009f14 c044ddf4 
>>> c031c020 0042 ce009f30
>>> <0>[ 1419.015686] 9f20: ce009f30  cebe1600 c031d958 
>>> c044d864 a013 
>>> <0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 
>>> cebe1600 c031d8d0 
>>> <0>[ 1419.040130] 9f60:    c00474e4 dc4d900d
>>>  31bc92e7 cebe1600
>>> <0>[ 1419.052429] 9f80:  ce009f84 ce009f84  ce009f90
>>> ce009f90 ce009fac cebfa100
>>> <0>[ 1419.064697] 9fa0: c0047418   c000f218 
>>>   
>>> <0>[ 1419.076934] 9fc0:     
>>>   
>>> <0>[ 1419.089050] 9fe0:     0013
>>>  2000 3891
>>> <4>[ 1419.101043] [] (handle_exception) from []
>>> (fsg_main_thread+0x88/0x13dc)
>>> <4>[ 1419.113189] [] (fsg_main_thread) from []
>>> (kthread+0xcc/0xe0)
>>> <4>[ 1419.124267] [] (kthread) from []
>>> (ret_from_fork+0x14/0x3c)
>>> <0>[ 1419.135101] Code: 1a15 ea40 e5946038 e0866285 (e5963014)
>>> <4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---

[RFC] Create an audit record of USB specific details

[wmealing]

From: Wade Mealing 

Gday,

I'm looking to create an audit trail for when devices are added or removed
from the system.

The audit subsystem is a logging subsystem in kernel space that can be
used to create advanced filters on generated events.  It has partnered userspace
utilities ausearch, auditd, aureport, auditctl which work exclusively on audit
records.

These tools are able to set filters to "trigger" on specific in-kernel events
specified by privileged users.  While the userspace tools can create audit 
events these are not able to be handled intelligently (decoded,filtered or 
ignored) as kernel generated audit events are.

I have this working at the moment with the USB subsystem (as an example).
Its been suggested that I use systemd-udev however this means that the audit
tools (ausearch) will not be able to index these records.

Here is an example of picking out the AUDIT_DEVICE record type for example.

> # ausearch -l -i -ts today -m AUDIT_DEVICE
> 
> type=AUDIT_DEVICE msg=audit(31/03/16 16:37:15.642:2) : action=add
> manufacturer=Linux 4.4.0-ktest ehci_hcd product=EHCI Host Controller
> serial=:00:06.7 major=189 minor=0 bus="usb"

Admittedly this is only the USB device type at the moment, but I'd like to break
this
out into other bus types at some time in the future, gotta start somewhere.

Thanks,

Wade Mealing

---
 include/uapi/linux/audit.h |  1 +
 init/Kconfig   | 10 ++
 kernel/Makefile|  1 +
 kernel/audit_device.c  | 90 ++
 4 files changed, 102 insertions(+)
 create mode 100644 kernel/audit_device.c

diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 843540c..344c97b 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -110,6 +110,7 @@
 #define AUDIT_SECCOMP  1326/* Secure Computing event */
 #define AUDIT_PROCTITLE1327/* Proctitle emit event */
 #define AUDIT_FEATURE_CHANGE   1328/* audit log listing feature changes */
+#define AUDIT_DEVICE_CHANGE 1330/* Device added/removed to the system 
*/
 
 #define AUDIT_AVC  1400/* SE Linux avc denial or grant */
 #define AUDIT_SELINUX_ERR  1401/* Internal SE Linux Errors */
diff --git a/init/Kconfig b/init/Kconfig
index 2232080..e171f74 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -309,6 +309,16 @@ config AUDITSYSCALL
def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
 
+config DEVICE_AUDIT
+bool "Create audit records for devices added to the systems"
+depends on AUDIT && USB
+   default y
+   help
+ Generate audit events in the system for USB devices that
+ are added or removed from the system from boot time onwards.
+ Records the manufacturer, product serial number, device major
+ and minor number and bus which the device was added to.
+
 config AUDIT_WATCH
def_bool y
depends on AUDITSYSCALL
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..909c869 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
 obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
 obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
 obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
+obj-$(CONFIG_DEVICE_AUDIT) += audit_device.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
 obj-$(CONFIG_KPROBES) += kprobes.o
 obj-$(CONFIG_KGDB) += debug/
diff --git a/kernel/audit_device.c b/kernel/audit_device.c
new file mode 100644
index 000..8dfdf04
--- /dev/null
+++ b/kernel/audit_device.c
@@ -0,0 +1,90 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void log_string(struct audit_buffer *ab, char *key, char *val)
+{
+   if (val) {
+   audit_log_format(ab, " %s=", key);
+   audit_log_untrustedstring(ab, val);
+   }
+   else {
+  audit_log_format(ab, " %s=%s", key, "?");
+   } 
+
+}
+
+static void log_major_minor(struct audit_buffer *ab, struct device *dev)
+{
+   if (dev && dev->devt) {
+   audit_log_format(ab, " major=%d", MAJOR(dev->devt));
+   audit_log_format(ab, " minor=%d", MINOR(dev->devt));
+   }
+}
+
+/* Blocking call when device has reference and will keep reference until
+ * all notifiers are done, no usb_dev_get/ usb_dev_put required.
+ */
+static int audit_notify(struct notifier_block *self,
+   unsigned long action, void *d)
+{
+   struct usb_device *usbdev = (struct usb_device *)d;
+   char *op;
+   struct audit_buffer *ab;
+
+   switch (action) {
+   case USB_DEVICE_ADD:
+   op = "add";
+   break;
+   case USB_DEVICE_REMOVE:
+   op =  "remove";
+   break;
+   default: /* ignore any other USB events */ 
+  return NOTIFY_DONE;
+   }
+
+   ab = 

Re: function ehci_hub_control in ehci-hub.c

[Alan Stern]

On Sun, 3 Apr 2016, Navin P.S wrote:

> On Sat, Apr 2, 2016 at 8:00 PM, Alan Stern  wrote:
> > On Sat, 2 Apr 2016, Navin P.S wrote:
> >>regs->hostpc[(wIndex & 0xff) - 1];
> >
> > You're asking the question backwards.  wIndex is allowed to be 0
> > because the USB spec says so.  You can't argue with that.
> >
> > You should be asking why we initialize status_reg and hostpc_reg as
> > above.
> >.
> 
> Can i initialize them to NULL and only use them if wIndex is not zero
> and wIndex <= ports.

You can't use a NULL pointer!  You have to set it to a non-NULL value
before you can dereference it.

> I assign them goto error case statement.

I don't understand that sentence.

>  That would be a cleaner solution.

It would not be cleaner than leaving the code the way it is.

> >> This is only valid when we have regs->port_status and regs->hostpc and
> >> 1 more into the actual array but gcc catches this.
> >
> > No, it's always valid.  The C spec might not agree with me, but the
> > kernel doesn't use standard C.  It uses gcc, which is different from
> > the standard in quite a few ways.
> >
> 
> 
> If you had told me the size of port_status and hostpc is 65536
> atleast i wouldn't have a problem

I don't see why you have a problem anyway.  There's nothing wrong with
assigning a nonsense value to a pointer, as long as you don't try to
use it.  For example, your compiler might not like this program, but
the program won't cause an error when you run it:

int a[5];

int main()
{
int *x = [-1];

return 0;
}

>  because wIndex &0xff -1
> when casted to a unit16_t would be 65535 when wIndex is 0. The 1 is
> treated as a signed integer constant and wIndex is an unsigned
> uint16_t. So the value of expression is -1 in this case.
> 
> Please note i'm not talking about 0 sized arrays or 1 sized arrays
> inside struct.
> 
> 
> Can you please explain where gcc mentions this as valid ?
> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions

It's probably not mentioned in there.

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: GDM7240 - NULL pointer dereference

[Alex]

Thanks, looks like exactly the same issue, I'll check if it works on 4.5.

/--Regards, Alex/

On 03/04/16 15:26, poma wrote:

On 03.04.2016 12:15, Alex wrote:

Hello,
[1.] System hang when connecting USB modem (LU150)
[2.] I'm running 4.4.5 kernel (Arch Linux). When this modem is connected
I'm getting below trace in journal and system becomes unusable - lsusb,
logout and some other operations lead to a complete hang, the only way
out is hardware power off. This modem works perfectly on 4.1.20 kernel -
attaching all outputs for both kernels.

...

See if it is related to
http://thread.gmane.org/gmane.linux.usb.general/135626

if so, kernel >= 4.5
i.e.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/usb/cdc_ether.c?h=linux-4.5.y=29c6dd5



--
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 14/14] USB: ch341: implement tx_empty callback

[Karl Palsson]

Grigori Goronzy  wrote:
> The status bit was found with USB captures of the Windows
> driver and some luck. Tested on CH340G and CH341A.

By my reversing, bit 0x4, is "multiple status changes since last
interrupt"

> 
> Signed-off-by: Grigori Goronzy 
> ---
>  drivers/usb/serial/ch341.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/ch341.c
> b/drivers/usb/serial/ch341.c index 6981e2ad..adf7d79 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -82,6 +82,8 @@
>  #define CH341_LCR_CS6  0x01
>  #define CH341_LCR_CS5  0x00
>  
> +#define CH341_STATUS_TXBUSY0x01
> +
>  static const struct usb_device_id id_table[] = {
>   { USB_DEVICE(0x4348, 0x5523) },
>   { USB_DEVICE(0x1a86, 0x7523) },
> @@ -95,6 +97,7 @@ struct ch341_private {
>   unsigned baud_rate; /* set baud rate */
>   u8 line_control; /* set line control value RTS/DTR */
>   u8 line_status; /* active status of modem control inputs */
> + u8 uart_status; /* generic UART status bits */
>  };
>  
>  static void ch341_set_termios(struct tty_struct *tty,
> @@ -187,7 +190,8 @@ static int ch341_get_status(struct usb_device *dev, 
> struct ch341_private *priv)
>   if (r == 2) {
>   r = 0;
>   spin_lock_irqsave(>lock, flags);
> - priv->line_status = (~(*buffer)) & CH341_BITS_MODEM_STAT;
> + priv->line_status = (~buffer[0]) & CH341_BITS_MODEM_STAT;
> + priv->uart_status = buffer[1];
>   spin_unlock_irqrestore(>lock, flags);
>   } else {
>   r = -EPROTO;
> @@ -198,6 +202,18 @@ out:
>   return r;
>  }
>  
> +static bool ch341_tx_empty(struct usb_serial_port *port)
> +{
> + int r;
> + struct ch341_private *priv = usb_get_serial_port_data(port);
> +
> + r = ch341_get_status(port->serial->dev, priv);
> + if (r < 0)
> + return true;
> +
> + return !(priv->uart_status & CH341_STATUS_TXBUSY);
> +}
> +
>  /* 
> -- */
>  
>  static int ch341_configure(struct usb_device *dev, struct ch341_private 
> *priv)
> @@ -606,6 +622,7 @@ static struct usb_serial_driver ch341_device = {
>   .carrier_raised= ch341_carrier_raised,
>   .close = ch341_close,
>   .set_termios   = ch341_set_termios,
> + .tx_empty  = ch341_tx_empty,
>   .break_ctl = ch341_break_ctl,
>   .tiocmget  = ch341_tiocmget,
>   .tiocmset  = ch341_tiocmset,
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-usb" in the body of a message to
> majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 07/14] USB: ch341: add support for parity, frame length, stop bits

[Karl Palsson]

Grigori Goronzy  wrote:
> With the new reinitialization method, configuring parity,
> different frame lengths and different stop bit settings work as
> expected on both CH340G and CH341A. This has been extensively
> tested with a logic analyzer.
> 
> Tested-by: Ryan Barber 
> Signed-off-by: Grigori Goronzy 
> ---
>  drivers/usb/serial/ch341.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/serial/ch341.c
> b/drivers/usb/serial/ch341.c index c001773..4d66f0f 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -346,6 +346,7 @@ static void ch341_set_termios(struct tty_struct *tty,
>   unsigned baud_rate;
>   unsigned long flags;
>   unsigned char ctrl;
> + unsigned cflag = tty->termios.c_cflag;
>   int r;
>  
>   /* redundant changes may cause the chip to lose bytes */
> @@ -356,7 +357,35 @@ static void ch341_set_termios(struct tty_struct *tty,
>  
>   priv->baud_rate = baud_rate;
>  
> - ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX | CH341_LCR_CS8;
> + ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX;
> +
> + switch (cflag & CSIZE) {
> + case CS5:
> + ctrl |= CH341_LCR_CS5;
> + break;
> + case CS6:
> + ctrl |= CH341_LCR_CS6;
> + break;
> + case CS7:
> + ctrl |= CH341_LCR_CS7;
> + break;
> + case CS8:
> + default:
> + ctrl |= CH341_LCR_CS8;
> + break;
> + }
> +
> + if (cflag & PARENB) {
> + ctrl |= CH341_LCR_ENABLE_PAR;
> + if ((cflag & PARODD) == 0)
> + ctrl |= CH341_LCR_PAR_EVEN;
> + }
> +
> + if (cflag & CMSPAR)
> + ctrl |= CH341_LCR_MARK_SPACE;
> +
> + if (cflag & CSTOPB)
> + ctrl |= CH341_LCR_STOP_BITS_2;
>  

I think this should be moved up to the PARENB check, at least,
when I was working on this. Also there's macros for some of the
flag checks: (From some code I was working on, but you can see
the mark/space is differently handled, this matched the windows
driver I was reversing usb captures from.)

if (C_PARENB(tty)) {
*lcr |= CH341_LCR_PARITY;
if (C_CMSPAR(tty)) {
*lcr |= CH341_LCR_SPAR;
if (C_PARODD(tty)) {
dev_dbg(>dev, "parity = mark\n");
*lcr &= ~CH341_LCR_EPAR;
} else {
dev_dbg(>dev, "parity = space\n");
*lcr |= CH341_LCR_EPAR;
}
} else {
*lcr &= ~CH341_LCR_SPAR;
if (C_PARODD(tty)) {
dev_dbg(>dev, "parity = odd\n");
*lcr &= ~CH341_LCR_EPAR;
} else {
dev_dbg(>dev, "parity = even\n");
*lcr |= CH341_LCR_EPAR;
}
}
} else {
*lcr &= ~(CH341_LCR_PARITY | CH341_LCR_SPAR | CH341_LCR_EPAR);
dev_dbg(>dev, "parity = none\n");
}



>   if (baud_rate) {
>   spin_lock_irqsave(>lock, flags);
> @@ -373,11 +402,6 @@ static void ch341_set_termios(struct tty_struct *tty,
>  
>   ch341_set_handshake(port->serial->dev, priv->line_control);
>  
> - /* Unimplemented:
> -  * (cflag & CSIZE) : data bits [5, 8]
> -  * (cflag & PARENB) : parity {NONE, EVEN, ODD}
> -  * (cflag & CSTOPB) : stop bits [1, 2]
> -  */
>  }
>  
>  static void ch341_break_ctl(struct tty_struct *tty, int break_state)
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-usb" in the body of a message to
> majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: System hang when connecting USB modem (GCT/Yota LU150)

[Bjørn Mork]

Alex  writes:

> Apr 01 11:33:24 arch kernel: BUG: unable to handle kernel NULL pointer 
> dereference at 0003
> Apr 01 11:33:24 arch kernel: IP: [] 
> usbnet_generic_cdc_bind+0x171/0x710 [cdc_ether]
..
> Apr 01 11:33:24 arch kernel: Call Trace:
> Apr 01 11:33:24 arch kernel:  [] 
> generic_rndis_bind+0x62/0x520 [rndis_host]
> Apr 01 11:33:24 arch kernel:  [] ? 
> alloc_netdev_mqs+0x302/0x440
> Apr 01 11:33:24 arch kernel:  [] rndis_bind+0x13/0x20 
> [rndis_host]

This is most likely fixed by commit 29c6dd591bbd ("cdc-acm: fix NULL
pointer reference").  Which should defintely go into the 4.4 stable
series.  Could you please add it to your v4.4 queue, David?

Ignore the "cdc-acm" prefix. The patch fixes a NULL pointer dereference
in the cdc_ether/rndis_host drivers introduced by commit 823bd3433424
("cdc-ether: switch to common CDC parser")


Bjørn
--
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: GDM7240 - NULL pointer dereference

[poma]

On 03.04.2016 12:15, Alex wrote:
> Hello,
> [1.] System hang when connecting USB modem (LU150)
> [2.] I'm running 4.4.5 kernel (Arch Linux). When this modem is connected 
> I'm getting below trace in journal and system becomes unusable - lsusb, 
> logout and some other operations lead to a complete hang, the only way 
> out is hardware power off. This modem works perfectly on 4.1.20 kernel - 
> attaching all outputs for both kernels.
...

See if it is related to
http://thread.gmane.org/gmane.linux.usb.general/135626

if so, kernel >= 4.5
i.e.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/usb/cdc_ether.c?h=linux-4.5.y=29c6dd5

--
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/2] phy: Group vendor specific phy drivers

[Krzysztof Kozlowski]

On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote:
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
> With growing number of phy drivers, it makes sense to
> group these drivers under their respective vendor/platform
> umbrella directory.
> 
> Build-tested 'multi_v7_defconfig'.

Please update also the MAINTAINERS file. For many entires the path won't
match anymore.

Best regards,
Krzysztof

--
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