From: Ming Lei
Date: Sun, 4 Nov 2012 09:29:51 +0800
> This patch applies the introduced usbnet_read_cmd_nopm() and
> usbnet_write_cmd_nopm() in the callback of resume and suspend
> to avoid deadlock if USB runtime PM is considered into
> usbnet_read_cmd() and usbnet_write_cmd().
>
> Cc: Steve G
This patche gets the runtime PM reference count before calling
usbnet_read[write]_cmd, and puts it after completion of the
usbnet_read[write]_cmd, so that the usb control message can always
be sent to one active device in the non-PM context.
Signed-off-by: Ming Lei
---
drivers/net/usb/usbnet.c |
This patch applies the introduced usbnet_read_cmd_nopm() and
usbnet_write_cmd_nopm() in the callback of resume and suspend
to avoid deadlock if USB runtime PM is considered into
usbnet_read_cmd() and usbnet_write_cmd().
Cc: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc95xx.
This patch fixes memory leak in smsc95xx_suspend.
Also, it isn't necessary to bother mm to allocate 8bytes/16byte,
and we can use stack variable safely.
Cc: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc95xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletion
This patch applies the introduced usbnet_read_cmd_nopm() and
usbnet_write_cmd_nopm() in the callback of resume and suspend
to avoid deadlock if USB runtime PM is considered into
usbnet_read_cmd() and usbnet_write_cmd().
Cc: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc75xx.
This patch introduces the below two helpers to prepare for solving
the usbnet runtime PM problem, which may cause some network utilities
(ifconfig, ethtool,...) touch a suspended device.
usbnet_read_cmd_nopm()
usbnet_write_cmd_nopm()
The above two helpers should be called by usbne
Thip patchset avoids accessing auto-suspended device in ioctl path,
which is generally triggered by some network utility(ethtool, ifconfig,
...)
Most of network devices have the problem, but as discussed in the
thread:
http://marc.info/?t=13505486063&r=1&w=2
the problem should be sol
On Sat, 3 Nov 2012, [ISO-8859-1] Sigur�ur Bj�rnsson wrote:
> Good afternoon.
>
> I'm having bandwidth problems with a ID 0d8c:0102 C-Media Electronics,
> Inc. CM106 Like Sound Device.
> (Encore Electronics ENMAB-8CM, External USB 7.1 sound card)
> When I try to start jackd in duplex mode I get th
On Sat, 3 Nov 2012, Miguel Dardenne wrote:
> On 2012-11-03 17:50, Alan Stern wrote:
> >> I get a USB disconnect of my external USB HDD about once per day.
> >> Enabling USB debug in the kernel shows the first error as 'ehci_hcd
> >> detected XactErr'. It happens only when the drive is idle. For
>
On 2012-11-03 17:50, Alan Stern wrote:
I get a USB disconnect of my external USB HDD about once per day.
Enabling USB debug in the kernel shows the first error as 'ehci_hcd
detected XactErr'. It happens only when the drive is idle. For
example,
I had a process writing on the HDD every 3 seconds
From: Ming Lei
Date: Mon, 29 Oct 2012 15:45:05 +0800
> Thip patchset avoids accessing auto-suspended device in ioctl path,
> which is generally triggered by some network utility(ethtool, ifconfig,
> ...)
>
> Most of network devices have the problem, but as discussed in the
> thread:
>
> h
On Fri, 2 Nov 2012, Miguel Dardenne wrote:
> Hello all,
>
>
> First, apologies if this message is not posted to the right mailing
> list - please point me to the most appropriate one if needed.
>
> I get a USB disconnect of my external USB HDD about once per day.
> Enabling USB debug in the k
This patch (as1629) fixes a build error in the ChipIdea host driver
when compiled for the ARM architecture. The error was introduced
by commit 99f91934a907df31ba878dfdd090002049dc476a (USB: EHCI: make
ehci-platform a separate driver).
The fix is simple; an additional header-file #include is neede
On Sat, 3 Nov 2012, Daniel Mack wrote:
> On 03.11.2012 15:10, Christof Meerwald wrote:
> > On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote:
> >> It's almost definitely either a USB driver bug or video4linux driver bug:
> >>
> >> I'm CC'ing linux-media and linux-usb mailing lists
On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote:
> It's almost definitely either a USB driver bug or video4linux driver bug:
>
> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described
> here:
> https://lkml.org/lkml/2012/10/20/35
> https://lkml.org/lkml/201
On 03.11.2012 15:10, Christof Meerwald wrote:
> On Sat, 20 Oct 2012 23:15:17 + (GMT), Artem S. Tashkinov wrote:
>> It's almost definitely either a USB driver bug or video4linux driver bug:
>>
>> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described
>> here:
>> https://lk
Good afternoon.
I'm having bandwidth problems with a ID 0d8c:0102 C-Media Electronics,
Inc. CM106 Like Sound Device.
(Encore Electronics ENMAB-8CM, External USB 7.1 sound card)
When I try to start jackd in duplex mode I get the following error in syslog:
ALSA sound/usb/endpoint.c:872 cannot submi
We are removing plat data which was used till now to init and
exit phy. We no longer need this since dwc3-core takes care of
initializing and shutting-down the phy using usb_phy_init()
and usb_phy_shutdown().
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 16
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3
Changes from v2:
- Respined for 'dwc3' branch on Felipe's usb tree.
Changes from v1:
- Removed setting-up of "dev.coherent_dma_mask", since of/platform.c
itself takes care of it.
Vivek Gautam (2):
USB: dwc3-exynos: Add support for device tree
USB: DWC3: EXYNOS: Remove platform data for d
From: Julia Lawall
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
//
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON(1);
//
Signed-off-by:
On Fri, Nov 02, 2012 at 03:13:54PM -0400, Alan Stern wrote:
> On Sat, 3 Nov 2012, Fengguang Wu wrote:
>
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> > usb-next
> > head: bc8d51ea7e8ae0abb90fa89407b55a7e0bcb0a2a
> > commit: 09f6ffde2ecef4cc4e2a5edaa303210cabd96f57 [
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime PM and block device
error handling path. Traditionly, the problem is addressed by passing
GFP_NOIO statically to mm, but that is not a effective solution, see
detailed descriptio
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable deadlock.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume() or runtime_suspend() on any one of device in
If one storage interface or usb network interface(iSCSI case)
exists in current configuration, memory allocation with
GFP_KERNEL during usb_device_reset() might trigger I/O transfer
on the storage interface itself and cause deadlock because
the 'us->dev_mutex' is held in .pre_reset() and the storag
Deadlock might be caused by allocating memory with GFP_KERNEL in
runtime_resume and runtime_suspend callback of network devices in
iSCSI situation, so mark network devices and its ancestor as
'memalloc_noio' with the introduced pm_runtime_set_memalloc_noio().
Cc: "David S. Miller"
Cc: Eric Dumaze
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume/runtime_suspend callback on device with
the flag of 'memalloc_noio' set.
Cc: Alan Stern
Cc: Oliver Neukum
Cc: Rafael J. Wysocki
Signed-off-by: Ming Lei
This patch applyes the introduced pm_runtime_set_memalloc_noio on
block device so that PM core will teach mm to not allocate memory with
GFP_IOFS when calling the runtime_resume and runtime_suspend callback
for block devices and its ancestors.
Cc: Jens Axboe
Signed-off-by: Ming Lei
---
v4:
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task
to avoid doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device,
and the problem may happen
Hi Daniel,
* Daniel Mack, November 03, 2012 1:06 AM:
> I'm testing these patches with an AM33xx board that has the first musb
> port wired to an USB type A plug, but it doesn't yet work for me.
> So there is no host interface registered. I'm unsure on how to fix this,
> and I didn't get an answe
30 matches
Mail list logo
