On Sun, Jul 22, 2012 at 12:46:13PM -0700, Linus Torvalds wrote:
> On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov wrote:
> >
> > Question: is there any other reason
> >
> > [besides maybe embedded people who care about each single Kb of memory
> >on the system]
> >
> > why we don't make thi
On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov wrote:
>
> Question: is there any other reason
>
> [besides maybe embedded people who care about each single Kb of memory
>on the system]
>
> why we don't make this cache/uncache firmware thing *implicit*? That is,
> load it once at driver ope
On Sat, Jul 21, 2012 at 01:38:52PM -0700, Linus Torvalds wrote:
> > Looks it is not difficult to cache firmware data by kernel, for example,
> > just
> > call the
> >
> >cache_firmware(fw_name)
> >
> > for each device which need firmware before suspending,
> > then call the below to un
On Sun, Jul 22, 2012 at 4:38 AM, Linus Torvalds
wrote:
>
> I agree that this is a problem. At the same time, early boot has some
> of the exact same problems as resume has, and I do wish that people
> would ask themselves: "why do I try to load the firmware at early boot
> time"?
>
> There is real
Ming Lei :
> On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds
> wrote:
> > On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> >> The RFC patch is just for discussing if the idea of deferring
> >> request_firmware is doable for addressing the issue of
> >> request_firmware in resume path, which is
On Saturday, July 21, 2012, Ming Lei wrote:
> On Sun, Jul 22, 2012 at 1:49 AM, Rafael J. Wysocki wrote:
> > On Friday, July 20, 2012, Ming Lei wrote:
>
> >> + if (system_state != SYSTEM_RUNNING)
> >> + return -EPROBE_DEFER;
> >
> > You can't just return here, _request_firmware_cle
On Sat, 21 Jul 2012, Linus Torvalds wrote:
In my opinion, we should cache firmware data for all hotplug
devices or devices which may experience power loss automatically
in kernel during suspend-resume cycle because all such devices may be
disconnected and connected again during suspend-resume c
On Sat, Jul 21, 2012 at 12:55 PM, Ming Lei wrote:
>
> Suppose it is not good for resume case, I think it still makes sense
> for early boot situation, at least the patch will support to request
> firmware inside init call, and allow drivers to be built in kernel i
> case of requesting firmware fro
On Sun, Jul 22, 2012 at 1:49 AM, Rafael J. Wysocki wrote:
> On Friday, July 20, 2012, Ming Lei wrote:
>> + if (system_state != SYSTEM_RUNNING)
>> + return -EPROBE_DEFER;
>
> You can't just return here, _request_firmware_cleanup() has to be done still.
Good catch, thanks.
>
>> +
Thanks for your so detailed comments.
On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds
wrote:
> On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
>> The RFC patch is just for discussing if the idea of deferring
>> request_firmware is doable for addressing the issue of
>> request_firmware in resume
On Saturday, July 21, 2012, Linus Torvalds wrote:
> On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> > The RFC patch is just for discussing if the idea of deferring
> > request_firmware is doable for addressing the issue of
> > request_firmware in resume path, which is caused by driver
> > unbin
On Friday, July 20, 2012, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in such th
On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
NAK.
It really *has* to be handled
On Saturday, July 21, 2012, Ming Lei wrote:
> On Sat, Jul 21, 2012 at 5:56 PM, Rafael J. Wysocki wrote:
> > On Saturday, July 21, 2012, Ming Lei wrote:
> >> CC guys who discussed the problem in the below link in Jan. :
> >>
> >> http://marc.info/?t=13252895602&r=10&w=2
> >>
> >> On Fri,
On Sat, Jul 21, 2012 at 5:56 PM, Rafael J. Wysocki wrote:
> On Saturday, July 21, 2012, Ming Lei wrote:
>> CC guys who discussed the problem in the below link in Jan. :
>>
>> http://marc.info/?t=13252895602&r=10&w=2
>>
>> On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
>> > The RFC pat
On Saturday, July 21, 2012, Ming Lei wrote:
> CC guys who discussed the problem in the below link in Jan. :
>
> http://marc.info/?t=13252895602&r=10&w=2
>
> On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
> > The RFC patch is just for discussing if the idea of deferring
> > request_fi
CC guys who discussed the problem in the below link in Jan. :
http://marc.info/?t=13252895602&r=10&w=2
On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_fir
On Fri, Jul 20, 2012 at 9:54 PM, Oliver Neukum wrote:
>
> The approach seems to me to be less comprehensive than
> it ought to be. If you defer, why not the whole probe()?
Because for other failures, we don't know when the conditions
for them can be satisfied. For example, we don't know when the
On Friday 20 July 2012 20:33:32 Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in s
On Fri, Jul 20, 2012 at 09:09:10PM +0800, Ming Lei wrote:
> On Fri, Jul 20, 2012 at 9:03 PM, Borislav Petkov wrote:
> > This still doesn't change the fact that SYSTEM_SUSPEND or
> > SYSTEM_SUSPEND_DISK is unused. IOW, both states are unused. So why
> > introduce a new state instead of simply test
On Fri, Jul 20, 2012 at 9:03 PM, Borislav Petkov wrote:
> This still doesn't change the fact that SYSTEM_SUSPEND or
> SYSTEM_SUSPEND_DISK is unused. IOW, both states are unused. So why
> introduce a new state instead of simply test != SYSTEM_RUNNING?
Because system_state is still SYSTEM_RUNNING d
On Fri, Jul 20, 2012 at 08:57:05PM +0800, Ming Lei wrote:
> On Fri, Jul 20, 2012 at 8:52 PM, Borislav Petkov wrote:
>
> > This new SYSTEM_SUSPEND state is declared above and only assigned here
> > to system_state without being tested anywhere. AFAICT, the only test
> > you're doing is system_stat
On Fri, Jul 20, 2012 at 8:52 PM, Borislav Petkov wrote:
> This new SYSTEM_SUSPEND state is declared above and only assigned here
> to system_state without being tested anywhere. AFAICT, the only test
> you're doing is system_state != SYSTEM_RUNNING and that works without
> defining a new SYSTEM_S
On Fri, Jul 20, 2012 at 08:33:32PM +0800, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is inv
The RFC patch is just for discussing if the idea of deferring
request_firmware is doable for addressing the issue of
request_firmware in resume path, which is caused by driver
unbind/rebind during resume.
At least usb bus is involved in such things, one driver may be
unbound and rebound in resume
25 matches
Mail list logo
