On 05/21/2015 08:13 PM, Marcel Holtmann wrote:
Hi Laura,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during
On Thu, 2015-05-21 at 22:46 +0200, Arend van Spriel wrote:
> On 05/21/15 19:32, Takashi Iwai wrote:
> > Well, if the probe requires the access to a user-space file, it can't
> > be done during resume. That's the very problem we're seeing now.
> > The firmware loader can't help much a
On 05/22/15 09:37, Arend van Spriel wrote:
On 05/22/15 02:21, Laura Abbott wrote:
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during
On 05/22/15 02:21, Laura Abbott wrote:
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What'
Hi Laura,
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under certa
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
Th
On 05/21/15 19:32, Takashi Iwai wrote:
At Thu, 21 May 2015 19:27:41 +0200,
Arend van Spriel wrote:
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Ster
On 05/21/2015 11:11 AM, Takashi Iwai wrote:
At Thu, 21 May 2015 13:37:56 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
A
At Thu, 21 May 2015 13:37:56 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> > Alan Stern wrote:
> > >
> > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > >
> > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > > > Ala
On Thu, 21 May 2015, Takashi Iwai wrote:
> At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> Alan Stern wrote:
> >
> > On Thu, 21 May 2015, Takashi Iwai wrote:
> >
> > > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > > Alan Stern wrote:
> > > >
> > > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > > >
At Thu, 21 May 2015 19:27:41 +0200,
Arend van Spriel wrote:
>
> On 05/21/15 17:35, Takashi Iwai wrote:
> > At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> > Alan Stern wrote:
> >>
> >> On Thu, 21 May 2015, Takashi Iwai wrote:
> >>
> >>> At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> >>> Alan Stern wrote:
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
Then avoiding the failed firmware is no solution
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > Alan Stern wrote:
> > >
> > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > >
> > > > Then avoiding the failed firmware is no solution, ind
On Thu, 21 May 2015, Marcel Holtmann wrote:
> Hi Alan,
>
> >> Then avoiding the failed firmware is no solution, indeed.
> >> If it's a new probe, it should be never executed during resume.
> >
> > Can you expand this comment? What's wrong with probing during resume?
> >
> > The USB stack does
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > Then avoiding the failed firmware is no solution, indeed.
> > If it's a new probe, it should be never executed during resume.
>
> Can you expand this comment? What's wrong with probing
Hi Alan,
>> Then avoiding the failed firmware is no solution, indeed.
>> If it's a new probe, it should be never executed during resume.
>
> Can you expand this comment? What's wrong with probing during resume?
>
> The USB stack does carry out probes during resume under certain
> circumstances.
On Thu, 21 May 2015, Takashi Iwai wrote:
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under ce
At Thu, 21 May 2015 14:07:11 +0200,
Marcel Holtmann wrote:
>
> Hi Takashi,
>
> >> The data is cached in RAM. More specifically, the former loaded
> >> firmware files are reloaded and saved at suspend for each device
> >> object. See fw_pm_notify() in firmware_class.c.
> >
> >>>
Hi Takashi,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was succ
At Wed, 20 May 2015 16:42:44 -0700,
Laura Abbott wrote:
>
> On 05/20/2015 05:44 AM, Takashi Iwai wrote:
> > At Wed, 20 May 2015 11:46:31 +0200,
> > Marcel Holtmann wrote:
> >>
> >> Hi Oliver,
> >>
> The data is cached in RAM. More specifically, the former loaded
> firmware files are rel
On 05/20/2015 05:44 AM, Takashi Iwai wrote:
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
Hi Oliver,
The data is cached in RAM. More specifically, the former loaded
firmware files are reloaded and saved at suspend for each device
object. See fw_pm_notify() in firmware_class.c.
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
>
> Hi Oliver,
>
> >> The data is cached in RAM. More specifically, the former loaded
> >> firmware files are reloaded and saved at suspend for each device
> >> object. See fw_pm_notify() in firmware_class.c.
> >
> > OK, this may be a
Hi Oliver,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was successfully loaded in the fi
At Tue, 19 May 2015 19:42:55 +0200,
Oliver Neukum wrote:
>
> On Tue, 2015-05-19 at 19:13 +0200, Takashi Iwai wrote:
> > At Tue, 19 May 2015 10:26:46 -0400 (EDT),
> > Alan Stern wrote:
> > >
> > > > > > Of just have request_firmware()
> > > > > > actually sleep until userspace is ready. Seriously
Hi Alan,
I am not convinced. Now we are hacking the Bluetooth core layer
(which has nothing to do with the drivers suspend/resume or
probe) to do something different so that we do not see this
warning.
I can not do anything about the platform in question choosing a
>
25 matches
Mail list logo
