Message-ID: <CAG-2HqWtbpKjkNTLAksGZSqskJRfjVOhGkJJFcJUNBFfajLhCg@mail.gmail.com>
Date:	Thu, 5 Jun 2014 17:15:06 +0200
From:	Tom Gundersen <teg@...m.no>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Takashi Iwai <tiwai@...e.de>, LKML <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Stefan Roese <sr@...x.de>, Arnd Bergmann <arnd@...db.de>,
	Abhay Salunke <Abhay_Salunke@...l.com>,
	Kay Sievers <kay@...y.org>
Subject: Re: [PATCH v2] firmware loader: allow disabling of udev as firmware loader

On Thu, Jun 5, 2014 at 4:54 PM, Ming Lei <ming.lei@...onical.com> wrote:
>> Ubuntu currently enables the firmware loader in both the kernel and in
>> udev, so would not yet have a problem here at the moment. However, I
>> spoke with Martin Pitt and he told me that both Debian and Ubuntu
>> would like to switch this off in udev once it is possible (i.e., once
>> this patch has been merged I guess). Fedora already did, and speaking
>> for Arch we definitely would like to do the same. I did not check with
>> other distros, but I'm pretty sure "everyone" will disable this in
>> udev by the next cycle. At which point having it enabled in the kernel
>> will cause real problems and bug reports.
>
> That won't cover the case of old distributions with new kernel,

Again: disabling this option will not give problems (unless you have a
custom setup), even on old userspace, only keeping it enabled on
future userspace may.

> do
> you want to break/confuse these users?

Not really, no :)

>> For distro kernels that's not a problem, as they know what to do, but
>> I guess for random kernel users we should give them the correct
>> recommendation.
>
> Also I remember that android users put firmware under their
> special path.

That may be, but I don't think this text is primarily aimed at the
people who put together Android systems... Surely their non-standard
userspace means that a lot of the advice (and it is nothing else than
advice!) in the help text does not necessarily apply?

>>>>> It only falls back if the request fw is _not_ found from direct loading,
>>>>> so it is reasonable to try to continue to look for it from user space.
>>>
>>>> Some drivers fall back to different firmware (e.g. different revision
>>>> suffix) if the requested file isn't found.  So, this happens in
>>>> reality.
>>>
>>> So do you think the fallback is better or worse? For CPU microcode
>>> case, maybe it is fine, but for other devices, maybe it is better to
>>> get a firmware for working at least.
>>
>> What usecase do you have in mind here? For people using stock udev,
>> enabling the fallback will not give any benefit, but it will soon
>
> Again, we have old distributions, also it should make sense to fall back
> to userspace for non-exist firmwares under default path.

Even on old distributions, falling back to stock udev will not give
any benefits. It will look in the same paths as the kernel and fail in
the same way.

>> start giving real problems...
>
> If there isn't firmwares at default path for devices, the device may
> not work, and that is the real problem.

These devices will never have worked with stock udev, as it looks in
the same path as the kernel (the paths the kernel looks in was taken
from udev to make sure they work the sam). So this must be a
special/custom setup by someone who knows what they are doing, and
hopefully knows how to answer the Kconfig.

Cheers,

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

Powered by blists - more mailing lists