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 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
[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 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 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 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 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 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 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
32 matches
Mail list logo
