On Thu, Sep 6, 2012 at 8:59 PM, Alan Cox wrote:
>> Sorry, I don't see anyone explained clearly why request_firmware()
>> can't be called inside module_init() in module case, so maybe it is
>> a bit early to say it is a fix on 'bug', :-)
>
> Because the firmware load may trigger a need to load a dr
> Sorry, I don't see anyone explained clearly why request_firmware()
> can't be called inside module_init() in module case, so maybe it is
> a bit early to say it is a fix on 'bug', :-)
Because the firmware load may trigger a need to load a driver to load the
firmware.
> > dev_discard_firmware()
On Thu, 2012-09-06 at 00:18 +0100, Alan Cox wrote:
> > But then you have cases where probe() -> register_with_my_subsystem() ->
> > open(). Network devices come to mind. IE. udev must be able to deal with
> > a synchronous firmware load from probe I'm afraid.
>
> I don't believe so. You have
>
>
On Thu, Sep 6, 2012 at 12:30 AM, Alan Cox wrote:
>> Yes, deferring the load may fix the built in case, but which also
>> introduces much work on changes of current drivers. In fact,
>> there are few guys who complained the built in case.
>
> It fixes the modular case too.
Sorry, I don't see anyon
On Wed, Sep 5, 2012 at 9:30 AM, Alan Cox wrote:
>
> It's not about a workaround but about doing it properly for the long term
> and doing it in one place. It's also not a "great change", its a small
> change.
udev needs to get fixed regardless.
Stop this "we can break stuff" crap. Who maintains
> But then you have cases where probe() -> register_with_my_subsystem() ->
> open(). Network devices come to mind. IE. udev must be able to deal with
> a synchronous firmware load from probe I'm afraid.
I don't believe so. You have
begin probe
find match .. .firmware_name
On Wed, 2012-09-05 at 17:30 +0100, Alan Cox wrote:
>
> > Linus has said that he doesn't like to load firmware in probe(), but
> in some
> > situation the drivers have to load firmware in its probe():
>
> You don't want to load firmware in probe because of the locking
> problems
> - you can trigge
At Wed, 5 Sep 2012 13:59:56 -0300,
Lucas De Marchi wrote:
>
> On Wed, Sep 5, 2012 at 10:03 AM, Alan Cox wrote:
> >> If the driver is built in kernel, the request_firmware in .probe() may
> >> prolong kernel init, and it might be a problem. But looks it is not a
> >> big deal since most of drivers
At Wed, 5 Sep 2012 13:51:27 -0300,
Lucas De Marchi wrote:
>
> On Tue, Sep 4, 2012 at 10:06 AM, Takashi Iwai wrote:
> > Hi,
> >
> > as I've got recently a few bug reports regarding the stuck with
> > request_firmware() in module_init of some sound drivers, I started
> > looking at the issue. Stra
On Wed, Sep 5, 2012 at 10:03 AM, Alan Cox wrote:
>> If the driver is built in kernel, the request_firmware in .probe() may
>> prolong kernel init, and it might be a problem. But looks it is not a
>> big deal since most of drivers are built as module.
>
> Doing it by deferring the load also fixes t
On Tue, Sep 4, 2012 at 10:06 AM, Takashi Iwai wrote:
> Hi,
>
> as I've got recently a few bug reports regarding the stuck with
> request_firmware() in module_init of some sound drivers, I started
> looking at the issue. Strangely, the problem doesn't happen on
> openSUSE 12.2 although it has the
> Yes, deferring the load may fix the built in case, but which also
> introduces much work on changes of current drivers. In fact,
> there are few guys who complained the built in case.
It fixes the modular case too.
> The current complaint is from that udev may timeout request inside probe()
> w
On Wed, Sep 5, 2012 at 9:03 PM, Alan Cox wrote:
>> If the driver is built in kernel, the request_firmware in .probe() may
>> prolong kernel init, and it might be a problem. But looks it is not a
>> big deal since most of drivers are built as module.
>
> Doing it by deferring the load also fixes th
At Wed, 5 Sep 2012 14:03:04 +0100,
Alan Cox wrote:
>
> > If the driver is built in kernel, the request_firmware in .probe() may
> > prolong kernel init, and it might be a problem. But looks it is not a
> > big deal since most of drivers are built as module.
>
> Doing it by deferring the load also
> If the driver is built in kernel, the request_firmware in .probe() may
> prolong kernel init, and it might be a problem. But looks it is not a
> big deal since most of drivers are built as module.
Doing it by deferring the load also fixes that. The built in ones will
defer their final probe unti
On Wed, Sep 5, 2012 at 1:53 PM, Takashi Iwai wrote:
> At Wed, 5 Sep 2012 09:15:34 +0800,
> Ming Lei wrote:
>>
>> On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote:
>> > At Tue, 4 Sep 2012 23:52:15 +0800,
>> > Ming Lei wrote:
>> >>
>> >> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
>> >>
At Wed, 5 Sep 2012 09:15:34 +0800,
Ming Lei wrote:
>
> On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote:
> > At Tue, 4 Sep 2012 23:52:15 +0800,
> > Ming Lei wrote:
> >>
> >> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
> >> > Hi,
> >> >
> >> > as I've got recently a few bug reports reg
On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote:
> At Tue, 4 Sep 2012 23:52:15 +0800,
> Ming Lei wrote:
>>
>> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
>> > Hi,
>> >
>> > as I've got recently a few bug reports regarding the stuck with
>> > request_firmware() in module_init of some s
At Tue, 4 Sep 2012 23:52:15 +0800,
Ming Lei wrote:
>
> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
> > Hi,
> >
> > as I've got recently a few bug reports regarding the stuck with
> > request_firmware() in module_init of some sound drivers, I started
> > looking at the issue. Strangely, t
On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote:
> Hi,
>
> as I've got recently a few bug reports regarding the stuck with
> request_firmware() in module_init of some sound drivers, I started
> looking at the issue. Strangely, the problem doesn't happen on
> openSUSE 12.2 although it has the s
20 matches
Mail list logo
