On Tue, 2016-11-29 at 22:37 +0100, Luis R. Rodriguez wrote:
> On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote:
> >
> > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg
> > wrote:
> > >
> > > My argument basically goes like this:
> > >
> > > First, given good drivers (i.e. using req
On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote:
> On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
> wrote:
> > [CC: added Harald]
> >
> > As Harald pointed out over a beer yesterday evening, there is at least
> > one more reason why UMH isn't obsolete. The ordering of the firmware l
On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote:
> On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg
> wrote:
> > My argument basically goes like this:
> >
> > First, given good drivers (i.e. using request_firmware_nowait())
> > putting firmware even for a built-in driver into initramf
On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg
wrote:
> My argument basically goes like this:
>
> First, given good drivers (i.e. using request_firmware_nowait())
> putting firmware even for a built-in driver into initramfs or not
> should be a system integrator decision. If they don't need the d
On Tue, 2016-11-08 at 23:47 +0100, Luis R. Rodriguez wrote:
> This issue still stands. At Plumbers Johannes Berg did indicate to me
> he had a simple elegant solution in mind. He suggested that since the
> usermode helper was available, he had added support to be able to
> differentiate async firm
On Wed, Nov 9, 2016 at 3:21 AM, Andy Lutomirski wrote:
> On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
> wrote:
>> [CC: added Harald]
>>
>> As Harald pointed out over a beer yesterday evening, there is at least
>> one more reason why UMH isn't obsolete. The ordering of the firmware loading
>> mig
On Tue, Nov 8, 2016 at 2:47 PM, Luis R. Rodriguez wrote:
> Whatever the outcome of this discussion is -- Johannes seemed to *want*
> to further use the UMH by default on *all* async alls... even if the
> driver did not explicitly requested it -- I'm concerned about this given
> all the above and t
On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
wrote:
> [CC: added Harald]
>
> As Harald pointed out over a beer yesterday evening, there is at least
> one more reason why UMH isn't obsolete. The ordering of the firmware loading
> might be of important. Say you want to greet the user with a splash
[CC: added Harald]
On 11/08/2016 11:47 PM, Luis R. Rodriguez wrote:
On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote:
On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote:
On Tue, Sep 13, 2016 at 09:38:17PM
On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote:
> On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
> > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez
> > wrote:
> > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
> > >
> > >> I did some shuffli
On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote:
> On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote:
> > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
> >
> >> I did some shuffling around of those code to make initmpfs work, does
> >> anybody know why initramf
On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote:
> On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
>
>> I did some shuffling around of those code to make initmpfs work, does
>> anybody know why initramfs extraction _before_ we initialize drivers
>> would be a bad thing?
>
> N
On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote:
> On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote:
> > kernel_read_file_from_path() can try to read a file from
> > the system's filesystem. This is typically done for firmware
> > for instance, which lives in /lib/firmware. One issue wit
On Tue, Oct 04, 2016 at 05:32:22PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez wrote:
> >
> > Note that the races are beyond firmware, so all
> > kernel_read_file_from_path() users, as such re-using such old /sys/
> > interafeces for firmware will not suffice t
On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett wrote:
>
>I definitely don't think it
> should be a system-wide "mount event"; it should be a per-device "go
> direct-load your firmware" poke from userspace.
I don't disagree with that kind of interface. We already have things
like "rescan" for P
On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote:
> > I am not sure how/why a firmware loading daemon would be a better
> > idea now. What Marc describes that Josh proposed with signals for
> > userspcae seems more aligned wi
On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez wrote:
>
> Note that the races are beyond firmware, so all
> kernel_read_file_from_path() users, as such re-using such old /sys/
> interafeces for firmware will not suffice to cover all ground now for
> the same race for other possible users.
Blah
On Tue, Oct 4, 2016 at 5:12 PM, Linus Torvalds
wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote:
>>
>> I am not sure how/why a firmware loading daemon would be a better
>> idea now. What Marc describes that Josh proposed with signals for
>> userspcae seems more aligned with what w
On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote:
>
> I am not sure how/why a firmware loading daemon would be a better
> idea now. What Marc describes that Josh proposed with signals for
> userspcae seems more aligned with what we likely need
Quite frankly, I doubt you want a signal.
You
On Sat, Sep 24, 2016 at 10:41:46AM -0700, Dmitry Torokhov wrote:
> On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote:
> > On 03/09/2016 11:10, Dmitry Torokhov wrote:
> >> I was thinking if we kernel could post
> >> "conditions" (maybe simple stings) that it waits for, and userspace
> >> could u
On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote:
> On 03/09/2016 11:10, Dmitry Torokhov wrote:
>> I was thinking if we kernel could post
>> "conditions" (maybe simple stings) that it waits for, and userspace
>> could unlock these "conditions". One of them might be "firmware
>> available".
>
>
On 03/09/2016 11:10, Dmitry Torokhov wrote:
> I was thinking if we kernel could post
> "conditions" (maybe simple stings) that it waits for, and userspace
> could unlock these "conditions". One of them might be "firmware
> available".
On idea offered by Josh Triplett that seems to overlap with thi
On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote:
> kernel_read_file_from_path() can try to read a file from
> the system's filesystem. This is typically done for firmware
> for instance, which lives in /lib/firmware. One issue with
> this is that the kernel cannot know for sure when the real
> fina
On Tue, Sep 06, 2016 at 03:28:47PM -0700, Bjorn Andersson wrote:
> On Tue 06 Sep 14:52 PDT 2016, Luis R. Rodriguez wrote:
>
> > We already have MODULE_FIRMWARE(), we could have MODULE_FIRMWARE_REQ() or
> > something like it to help annotate the the driver was only functional with
> > the
> > firm
On Tue, Sep 06, 2016 at 02:50:51PM -0700, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson
> wrote:
> > On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote:
> >
> >> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> >> Nobody has actually answered the "why don't we just tie
On Tue, Sep 06, 2016 at 11:32:05AM -0700, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> wrote:
> >
> > Linus, I reversed the order of your questions/answers to fit my answer
> > better.
>
> Nobody has actually answered the "why don't we just tie the firmware
This is
On Tue 06 Sep 14:52 PDT 2016, Luis R. Rodriguez wrote:
> We already have MODULE_FIRMWARE(), we could have MODULE_FIRMWARE_REQ() or
> something like it to help annotate the the driver was only functional with the
> firmware, punt things to kmod to deal with the requirements.
That implies that a si
On Sat, Sep 03, 2016 at 11:10:02AM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 3, 2016 at 11:01 AM, Linus Torvalds
> wrote:
> > On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov
> > wrote:
> >>
> >> Unfortunately module loading and availability of firmware is very
> >> loosely coupled.
> >
> > The
On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson
wrote:
> On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote:
>
>> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
>> Nobody has actually answered the "why don't we just tie the firmware
>> and module together" question.
>
> The answer to this depend
On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> wrote:
> >
> > Linus, I reversed the order of your questions/answers to fit my answer
> > better.
>
> Nobody has actually answered the "why don't we just tie the firmware
> and module togethe
On Fri 02 Sep 21:11 PDT 2016, Linus Torvalds wrote:
Linus, I reversed the order of your questions/answers to fit my answer
better.
> On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote:
> >
> > Thoughts ?
> What are the drivers that need this, and why can't those drivers just
> be fixed to n
On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
wrote:
>
> Linus, I reversed the order of your questions/answers to fit my answer
> better.
Nobody has actually answered the "why don't we just tie the firmware
and module together" question.
Really. If the driver doesn't work without the firmware
On Sat, Sep 3, 2016 at 11:01 AM, Linus Torvalds
wrote:
> On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov
> wrote:
>>
>> Unfortunately module loading and availability of firmware is very
>> loosely coupled.
>
> The whole "let's add a new magical proc entry to say that all
> filesystems are mounte
On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov
wrote:
>
> Unfortunately module loading and availability of firmware is very
> loosely coupled.
The whole "let's add a new magical proc entry to say that all
filesystems are mounted" is all about the user space coupling them.
I'm just saying that
On Fri, Sep 02, 2016 at 09:41:18PM -0700, Linus Torvalds wrote:
> On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote:
> >
> > Like what? Some devices do need to have firmware loaded so we know
> > their capabilities, so we really can't push the firmware loading into
> > "open".
>
> So you
> (a) docu
On Sep 2, 2016 9:20 PM, "Dmitry Torokhov" wrote:
>
> Like what? Some devices do need to have firmware loaded so we know
> their capabilities, so we really can't push the firmware loading into
> "open".
So you
(a) document that
(b) make the driver only build as a module
(c) make sure the module an
On Fri, Sep 2, 2016 at 9:11 PM, Linus Torvalds
wrote:
> On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote:
>>
>> Thoughts ?
>
> I really think this is a horrible hack.
>
> It's basically the kernel giving up, and relying on user space to give
> a single flag, and it's broken nasty crap. Wo
On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote:
>
> Thoughts ?
I really think this is a horrible hack.
It's basically the kernel giving up, and relying on user space to give
a single flag, and it's broken nasty crap. Worse, it's broken nasty
crap with a user interface, so we'll be stuc
kernel_read_file_from_path() can try to read a file from
the system's filesystem. This is typically done for firmware
for instance, which lives in /lib/firmware. One issue with
this is that the kernel cannot know for sure when the real
final /lib/firmare/ is ready, and even if you use initramfs
dri
39 matches
Mail list logo
