Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1249107 > unrolled thread

Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Problems loading firmware using built-in drivers with kernels  that use initramfs. "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-10-16 21:40 +0200
    Re: Problems loading firmware using built-in drivers with kernels  that use initramfs. "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-10-16 23:10 +0200
    Re: Problems loading firmware using built-in drivers with kernels  that use initramfs. Arend van Spriel <arend@broadcom.com> - 2015-10-17 10:40 +0200

#1249107 — Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

On Thu, Sep 03, 2015 at 10:33:51AM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 3, 2015 at 10:23 AM, Arend van Spriel <arend@broadcom.com> wrote:
> > On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
> >>
> >> On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >>>
> >>> On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez <mcgrof@suse.com>
> >>> wrote:
> >>>> IMHO its just as hacky as using -EPROBE_DEFER too, but its at least
> >>>> preemptively hacky. Sadly I can't think of clear and clever way for the
> >>>> kernel
> >>>> to know when firmware will be ready either...  Would userspace know?
> >>>> Should the
> >>>> kernel learn this from userspace ?
> >>>
> >>>
> >>> Yes. Given only userspace knows when firmware is available (I could
> >>> have it on a separate device and mount it at some time). So maybe
> >>> userpsace should simply try and scan busses for unbound devices and
> >>> tell them to re-probe when it decides that firmware is finally
> >>> available.
> >>
> >>
> >> OK, the folks wanting this mechanism can implement it then. Short of
> >> that we only have hacks.
> >
> >
> > So what does "userspace knows when firmware is available" mean here. The
> > specific firmware file the driver wants or the collection of firmware files
> > which may or may not have the specific firmware file the driver wants. I
> > assume the latter and re-probe will fail as expected.
> 
> Right, the latter.

Arend, curious are you working on this? Me and Julia did some hunting and
have found quite a bit of users that could use this. I'll provide results
in another thread but figured I'd follow up to see if anyone is working
to address this. Otherwise we just have hacks for now.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1249152

On Fri, Oct 16, 2015 at 09:35:12PM +0200, Luis R. Rodriguez wrote:
> Arend, curious are you working on this? Me and Julia did some hunting and
> have found quite a bit of users that could use this. I'll provide results
> in another thread but figured I'd follow up to see if anyone is working
> to address this. Otherwise we just have hacks for now.

A lot of things are going on with firmware_class enhancements so lets
jot things down here:

http://kernelnewbies.org/KernelProjects/firmware-class-enhancements

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249285

On 10/16/2015 09:35 PM, Luis R. Rodriguez wrote:
> On Thu, Sep 03, 2015 at 10:33:51AM -0700, Dmitry Torokhov wrote:
>> On Thu, Sep 3, 2015 at 10:23 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
>>>>
>>>> On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
>>>> <dmitry.torokhov@gmail.com> wrote:
>>>>>
>>>>> On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez <mcgrof@suse.com>
>>>>> wrote:
>>>>>> IMHO its just as hacky as using -EPROBE_DEFER too, but its at least
>>>>>> preemptively hacky. Sadly I can't think of clear and clever way for the
>>>>>> kernel
>>>>>> to know when firmware will be ready either...  Would userspace know?
>>>>>> Should the
>>>>>> kernel learn this from userspace ?
>>>>>
>>>>>
>>>>> Yes. Given only userspace knows when firmware is available (I could
>>>>> have it on a separate device and mount it at some time). So maybe
>>>>> userpsace should simply try and scan busses for unbound devices and
>>>>> tell them to re-probe when it decides that firmware is finally
>>>>> available.
>>>>
>>>>
>>>> OK, the folks wanting this mechanism can implement it then. Short of
>>>> that we only have hacks.
>>>
>>>
>>> So what does "userspace knows when firmware is available" mean here. The
>>> specific firmware file the driver wants or the collection of firmware files
>>> which may or may not have the specific firmware file the driver wants. I
>>> assume the latter and re-probe will fail as expected.
>>
>> Right, the latter.
>
> Arend, curious are you working on this? Me and Julia did some hunting and
> have found quite a bit of users that could use this. I'll provide results
> in another thread but figured I'd follow up to see if anyone is working
> to address this. Otherwise we just have hacks for now.

Not doing much else than diaper changes these days. Seems to me based on 
the above that from kernel perspective we can not do much when firmware 
mounts are controlled by user-space.

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web