[PATCH v5] USB: serial: add Moxa UPORT 11x0 driver

Add a driver which supports : - UPort 1110 : 1 port RS-232 USB to Serial Hub. - UPort 1130 : 1 port RS-422/485 USB to Serial Hub. - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation. - UPort 1150 : 1 port RS-232/422/485 USB to Serial Hub. - UPort 1150I : 1 port RS-232/422/485 USB

[PATCH] usb: host: iounmap before return

This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not unmapping correctly. Coccinelle: scripts/coccinelle/free/iounmap.cocci Signed-off-by: Geyslan G. Bem --- drivers/usb/host/pci-quirks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host

Re: [RFC] usb: coccinelle and checkpatch cleanup

2015-12-04 18:55 GMT-03:00 Geyslan G. Bem : > While applying the "scripts/coccinelle/misc/compare_const_fl.cocci" in > usb/host/ tree I found files that deserve almost a full cleanup (very > wrong coding style). Eg. drivers/usb/host/ohci-dbg.c By wrong coding style I meant checkpatch warnings. I a

Re: [PATCH] USB: serial: cp210x: Cleaned up USB access functions.

On Mon, Nov 30, 2015 at 04:50:38PM -0600, Konstantin Shkolnyy wrote: > cp210x_get_config and cp210x_set_config were hard to use. They required > the buffer as an array of 32-bit values even for smaller values, and did > endian conversions on per-32-bit value basis, which is wrong for some > cp210x

Re: Infrastructure for zerocopy I/O

On Sun, 6 Dec 2015, Steinar H. Gunderson wrote: > >>> You don't really need to do it earlier. An unnecessary calculation of > >>> num_sgs won't hurt. > >> Is it unnecessary? I thought the test was really to force num_sgs==0 for > >> the > >> DMA case, not to save a little arithmetic. > > Well, i

[PATCH net-next] net: qmi_wwan: should hold RTNL while changing netdev type

The notifier calls were thrown in as a last-minute fix for an imagined "this device could be part of a bridge" problem. That revealed a certain lack of locking. Not to mention testing... Avoid this splat: RTNL: assertion failed at net/core/dev.c (1639) CPU: 0 PID: 4293 Comm: bash Not tainted 4.4

[PATCH net-next] net: cdc_ncm: add "ndp_to_end" sysfs attribute

Adding a writable sysfs attribute for the "NDP to end" quirk flag. This makes it easier for end users to test new devices for this firmware bug. We've been lucky so far, but we should not depend on reporters capable of rebuilding the driver. Cc: Enrico Mioso Signed-off-by: Bjørn Mork --- Docu

Re: Infrastructure for zerocopy I/O

On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote: > I'll try to update your patch with the other suggestions tomorrow. Thanks! Here we are. Lightly tested, I believe all comments should be addressed. /* Steinar */ >From 73833276a4f359c35edffc2a741dba57f2e82a12 Mon Sep 17 00:0

Power off, restart, lid close and "rmmod ehci_pci" result in system hang

On two different laptops (HP 250 G3 Intel N2830 - Lenovo B50-30 Intel N2840) the system hangs while powering down, restart, closing lid and doing "rmmod ehci_pci" if the modules xhci_pci/xhci_hcd are loaded before ehci_pci/ehci_hcd. The problem seems related to Intel processor/chipset: a similar l

Re: [PATCHv2 1/2] extcon: add driver for Intel USB mux

Hi, On 2015년 12월 04일 17:51, Heikki Krogerus wrote: > Hi, > >> I do never want to add some specific funtcion for only this driver. >> I think is not appropriate way. >> - intel_usb_mux_unregister >> - intel_usb_mux_register >> >> The client driver using extcon driver should use the standard extcon

Re: [PATCH net-next] net: qmi_wwan: should hold RTNL while changing netdev type

From: Bjørn Mork Date: Sun, 6 Dec 2015 21:25:50 +0100 > The notifier calls were thrown in as a last-minute fix for an > imagined "this device could be part of a bridge" problem. That > revealed a certain lack of locking. Not to mention testing... > > Avoid this splat: ... > Fixes: 32f7adf633b

Re: [PATCH net-next] net: cdc_ncm: add "ndp_to_end" sysfs attribute

From: Bjørn Mork Date: Sun, 6 Dec 2015 22:47:15 +0100 > Adding a writable sysfs attribute for the "NDP to end" > quirk flag. > > This makes it easier for end users to test new devices for > this firmware bug. We've been lucky so far, but we should > not depend on reporters capable of rebuildin

Re: [PATCH v6 1/4] gadget: Introduce the usb charger framework

On 6 December 2015 at 00:27, Sebastian Reichel wrote: > Hi, > > On Mon, Nov 16, 2015 at 02:33:31PM +0800, Baolin Wang wrote: >> +static ssize_t cur_limit_show(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> +

Re: [PATCH] usb: phy: Remove unused Renesas R-Car (Gen1) USB PHY driveer

On Fri, Dec 04, 2015 at 05:04:25PM +0100, Geert Uytterhoeven wrote: > As of commit 3d7608e4c169af03 ("ARM: shmobile: bockw: remove legacy > board file and config"), the Renesas R-Car (Gen1) USB PHY driver is no > longer used. > In theory it could still be used on R-Car Gen1 SoCs, but that would > r

Re: [PATCH 1/2] usb: musb: core: Fix handling of the phy notifications

On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote: > We currently can't unload omap2430 MUSB platform glue driver module and > this cause issues for fixing the MUSB code further. The reason we can't > remove omap2430 is because it uses the PHY functions and also exports the > omap_musb_mail

Re: [PATCH 2/2] usb: musb: Fix unbalanced pm_runtime_enable

On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote: > When reloading omap2430 kernel module we get a warning about > unbalanced pm_runtime_enable. Let's fix this. Note that we > need to do this after the child musb-core platform_device is > removed because of pm_runtime_irq_safe being set