On Thu, Jul 26, 2012 at 1:23 AM, Linus Torvalds
wrote:
>
> So *if* the only problem wrt the USB hub code comes from this area,
IMO, USB hub code may not be the only one because both device_add and
device_del can just be run in process context, so any hotplug bus
may have this kind of problem
On Wednesday, July 25, 2012, Linus Torvalds wrote:
> On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei wrote:
> >
> > The below patch should fix the problem above.
>
> Actually, I think we could make this even simpler.
>
> There's nothing wrong with saying "user mode is enabled" *just* before
> we
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei wrote:
>
> The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying "user mode is enabled" *just* before
we unthaw things, if we also simply guarantee that there is no
sleeping
On Wed, Jul 25, 2012 at 8:50 PM, Ming Lei wrote:
> - no harm to thaw all user space tasks before thawing all kernel threads
> (there isn't any dependency about the thawing order)
Sorry, I mean there isn't any constraint about the order, but the 'dependency'
may be just what the patch
On Wed, Jul 25, 2012 at 8:43 PM, Oliver Neukum wrote:
> This is likely unwise. You'd better introduce a special flag for kernel
> threads
> that should be thawed only after user space will have been thawed.
IMO, it is not necessary to introduce one extra flag for the purpose since
-
On Wednesday 25 July 2012 20:35:28 Ming Lei wrote:
> CC usb guys and list
>
> On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
> wrote:
> >
> > I really think the isight thing is a totally different thing entirely.
> >
> > And quite frankly, that's just a BUG in the USB implementation. If the
> >
CC usb guys and list
On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
wrote:
>
> I really think the isight thing is a totally different thing entirely.
>
> And quite frankly, that's just a BUG in the USB implementation. If the
> USB ID changes, it shouldn't be considered a "resume" thing at all,
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei ming@canonical.com wrote:
The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying user mode is enabled *just* before
we unthaw things, if we also simply guarantee that there
On Wednesday, July 25, 2012, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei ming@canonical.com wrote:
The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying user mode is enabled *just*
On Thu, Jul 26, 2012 at 1:23 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
So *if* the only problem wrt the USB hub code comes from this area,
IMO, USB hub code may not be the only one because both device_add and
device_del can just be run in process context, so any hotplug bus
may
CC usb guys and list
On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I really think the isight thing is a totally different thing entirely.
And quite frankly, that's just a BUG in the USB implementation. If the
USB ID changes, it shouldn't be considered a
On Wednesday 25 July 2012 20:35:28 Ming Lei wrote:
CC usb guys and list
On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I really think the isight thing is a totally different thing entirely.
And quite frankly, that's just a BUG in the USB
On Wed, Jul 25, 2012 at 8:43 PM, Oliver Neukum oneu...@suse.de wrote:
This is likely unwise. You'd better introduce a special flag for kernel
threads
that should be thawed only after user space will have been thawed.
IMO, it is not necessary to introduce one extra flag for the purpose since
On Wed, Jul 25, 2012 at 8:50 PM, Ming Lei ming@canonical.com wrote:
- no harm to thaw all user space tasks before thawing all kernel threads
(there isn't any dependency about the thawing order)
Sorry, I mean there isn't any constraint about the order, but the 'dependency'
may be
On Tue, Jul 24, 2012 at 10:53 AM, Linus Torvalds
wrote:
>
> The fact that USB confuses resuming existing devices and probing new
> ones is just an implementation issue, and is a bug.
Btw, I understand *why* it confuses the two. That doesn't make is less
of a bug, though.
Linus
On Tue, Jul 24, 2012 at 10:47 AM, Ming Lei wrote:
>
> I remembered that Matthew objected caching firmware because he thought
> it can't solve the isight camera problem after warm reset. But now,
> this specific
> problem can be solved easily by letting its driver defer probe.
I really think the
Cc Matthew
On Wed, Jul 25, 2012 at 1:16 AM, Linus Torvalds
wrote:
> Nothing in this patchset made me go "Eww", and several of them looked
> like good cleanups, but maybe somebody else hates this approach.
I remembered that Matthew objected caching firmware because he thought
it can't solve the
On Tue, Jul 24, 2012 at 10:00 AM, Ming Lei wrote:
>
> This patchset implements cache/uncache firmware mechanism,
Nothing in this patchset made me go "Eww", and several of them looked
like good cleanups, but maybe somebody else hates this approach.
Linus
--
To unsubscribe from this
On Wed, Jul 25, 2012 at 1:00 AM, Ming Lei wrote:
> Hi,
>
> In [1][2], the problem below has been discussed for some time:
>
> device's firmware may be lost during suspend/resume
> cycle because device is unplugged and plugged again
> or device experiences system power loss
Hi,
In [1][2], the problem below has been discussed for some time:
device's firmware may be lost during suspend/resume
cycle because device is unplugged and plugged again
or device experiences system power loss in the period.
but during resume path, system is
Hi,
In [1][2], the problem below has been discussed for some time:
device's firmware may be lost during suspend/resume
cycle because device is unplugged and plugged again
or device experiences system power loss in the period.
but during resume path, system is
On Wed, Jul 25, 2012 at 1:00 AM, Ming Lei ming@canonical.com wrote:
Hi,
In [1][2], the problem below has been discussed for some time:
device's firmware may be lost during suspend/resume
cycle because device is unplugged and plugged again
or device experiences
On Tue, Jul 24, 2012 at 10:00 AM, Ming Lei ming@canonical.com wrote:
This patchset implements cache/uncache firmware mechanism,
Nothing in this patchset made me go Eww, and several of them looked
like good cleanups, but maybe somebody else hates this approach.
Linus
--
To
Cc Matthew
On Wed, Jul 25, 2012 at 1:16 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Nothing in this patchset made me go Eww, and several of them looked
like good cleanups, but maybe somebody else hates this approach.
I remembered that Matthew objected caching firmware because he
On Tue, Jul 24, 2012 at 10:47 AM, Ming Lei ming@canonical.com wrote:
I remembered that Matthew objected caching firmware because he thought
it can't solve the isight camera problem after warm reset. But now,
this specific
problem can be solved easily by letting its driver defer probe.
I
On Tue, Jul 24, 2012 at 10:53 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
The fact that USB confuses resuming existing devices and probing new
ones is just an implementation issue, and is a bug.
Btw, I understand *why* it confuses the two. That doesn't make is less
of a bug,
26 matches
Mail list logo
