Felipe Balbi wrote:
>
> Hi,
>
Hi :-)
[...]
> Sure, but I still need Kukjin's 'say-so' for the arch/arm/plat-samsung
> and arch/arm/mach-exynos part.
>
Basically, this approach looks OK to me.
BTW, I have some comments and need to update...
>From 4th patch...
> diff --git a/arch/arm/mach-s3c
On 2012年11月12日 10:41, Alan Stern wrote:
> On Mon, 12 Nov 2012, Lan Tianyu wrote:
>
I think port and device are bound. Power off port also means to power
off device. So prevent device from power off also means to prevent port
from power off. They just like a power domain. Because p
On Mon, 12 Nov 2012, Lan Tianyu wrote:
> >> This will consume more power than suspend it
> >> agian.
> >
> > No it won't, because the device will suspend itself after 3 ms.
> But the premise is "they see a constant Idle state on their upstream
> facing bus lines for more than 3.0 ms", that mean
On Mon, 12 Nov 2012, Lan Tianyu wrote:
> >> I think port and device are bound. Power off port also means to power
> >> off device. So prevent device from power off also means to prevent port
> >> from power off. They just like a power domain. Because power is on the
> >> port and so I thought w
On 2012年11月11日 23:46, Alan Stern wrote:
> On Sun, 11 Nov 2012, Lan Tianyu wrote:
>
>> Hi Alan:
>> Great thanks for your review and good suggestions.
>> I think the main problem is that when the port device resumed(you said
>> turn on/off power in the port's runtime callback ) and device
On Sat, Nov 10, 2012 at 08:37:58PM -0500, Alan Stern wrote:
> On Sat, 10 Nov 2012 starlight.201...@binnacle.cx wrote:
>
> > Hello,
> >
> > I'm wondering how long it will be before this
> > patch appears in a 3.6.x release. Any idea?
>
> Probably a week or two. It's up to Greg KH.
As it's real
On 2012年11月11日 23:55, Alan Stern wrote:
> On Sun, 11 Nov 2012, Lan Tianyu wrote:
>
>> On 2012/11/10 0:10, Alan Stern wrote:
>>> On Fri, 9 Nov 2012, Lan Tianyu wrote:
>>>
Some usb devices can't be resumed correctly after power off. This
patch is to add pm qos flags request to change NO_PO
On Fri, Nov 09, 2012 at 11:30:36PM +0200, Felipe Balbi wrote:
> Hi Greg,
>
> Here are gadget patches for v3.8, and it also conflicts with your
> usb-next branch. Below you can find my resolution (suggested
> by Kuninori):
>
> diff --cc drivers/usb/renesas_usbhs/fifo.c
> index c021b20,72ad375..953
On Fri, Nov 09, 2012 at 11:29:05PM +0200, Felipe Balbi wrote:
> Hi Greg,
>
> Here are dwc3 patches for v3.8. This will also conflict with your usb-next
> branch and below you can find my resolution:
>
> diff --cc drivers/usb/dwc3/core.c
> index c14ebc9,2bd007d..4174054
> --- a/drivers/usb/dwc3/co
On Fri, Nov 09, 2012 at 11:27:32PM +0200, Felipe Balbi wrote:
> Hi Greg,
>
> MUSB changes for v3.8 follow. This will conflict with your usb-next branch,
> below you can find the resolution I used:
>
> diff --cc drivers/usb/musb/musb_dsps.c
> index ff5f112,e770f79..cf08966a
> --- a/drivers/usb/mus
On Fri, Nov 09, 2012 at 11:25:53PM +0200, Felipe Balbi wrote:
> Hi Greg,
>
> Here are the transceiver patches for v3.8 merge window. Let me know
> if you want any changes.
>
> Have a nice weekend
>
> ps: for samsung folks, I'm sorry but I couldn't wait any longer.
>
> The following changes sinc
> It looks like your mail client attempted to line wrap it. You might
> want to use mutt, thunderbird, or maybe even the plain text gmail
> interface to resend this.
If anyone is using Outlook, see this:
https://lkml.org/lkml/2011/1/25/587
Yuhong Bao--
To un
Just started a copies of /dev/urandom
to the new drive mirror pairs (in preparation
for crypt'ing them). This will take four
days so I can't touch the system for a
week now. No hurry on a 3.6 patch if
you were contemplating one. Maybe 3.7
will be out by then anyway.
>At 08:37 PM 11/10/2012 -05
At 08:37 PM 11/10/2012 -0500, Alan Stern wrote:
>Does the patch fix the problem?
Morning and coffee motivated an attempt
to build a kernel and try the patch.
However it fails to apply for 3.6.6
--even caffine is not enough to inspire
me to consider a -rc for production.
Any chance for a 3.6 patc
On Sun, 11 Nov 2012, Lan Tianyu wrote:
> On 2012/11/10 0:10, Alan Stern wrote:
> > On Fri, 9 Nov 2012, Lan Tianyu wrote:
> >
> >> Some usb devices can't be resumed correctly after power off. This
> >> patch is to add pm qos flags request to change NO_POWER_OFF and
> >> provide usb_device_allow_pow
On Sun, 11 Nov 2012, Lan Tianyu wrote:
> > What you should do, if all the conditions are met, is call
> > pm_runtime_put(&port_dev->dev). Then the port's runtime suspend
> > routine should be responsible for turning off the power.
>
> You mean just send set/clear PORT_POWER request in the port's
On Sun, 11 Nov 2012, Lan Tianyu wrote:
> Hi Alan:
> Great thanks for your review and good suggestions.
> I think the main problem is that when the port device resumed(you said
> turn on/off power in the port's runtime callback ) and device powered on
> again, If we did't resume the d
On 2012/11/10 0:10, Alan Stern wrote:
On Fri, 9 Nov 2012, Lan Tianyu wrote:
Some usb devices can't be resumed correctly after power off. This
patch is to add pm qos flags request to change NO_POWER_OFF and
provide usb_device_allow_power_off() for device drivers to allow or
prohibit usb core to
On 2012/11/10 0:01, Alan Stern wrote:
On Fri, 9 Nov 2012, Lan Tianyu wrote:
This patch is to add usb port auto power off mechanism.
When usb device is suspending, usb core will send clear usb port's
POWER feature requst to power off port if all conditions were met.
Actually, this is the wrong
On 2012/11/10 0:07, Alan Stern wrote:
On Fri, 9 Nov 2012, Lan Tianyu wrote:
When pm qos flags is changing, the pm core will keep device not
in RPM_SUSPEND via pm_runtime_get_sync/put(dev). When the flags are
changed, this will affect usb device status. If NO_POWER_OFF flag was
set when the devi
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
On Sun, Nov 11, 2012 at 8:34 PM, Ming Lei wrote:
> +/* GFP_NOIO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
> +static inline gfp_t memalloc_noio_flags(gfp_t flags)
> +{
> + if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> + flags &= ~GFP_NOIO;
> + retu
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
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
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
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
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 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
---
v5:
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
On Nov 09 Elliott, Robert (Server Storage) wrote:
> I recommend broadening this patch. T10 is discussing making READ (10), WRITE
> (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts.
>
> The algorithm should be:
> 1. During discovery, determine if 16-byte CDBs are supporte
Richard writes:
> Bjørn:
>
> I patched keyspan.c using your below supplied diff in 3.6.6 (I'm not
> using git.) The patch WORKS for me. (I tested using minicom and the
> two programs that usually access the Keyspan serial device.)
Thanks for testing. Good to know that this really was the prob
31 matches
Mail list logo
