On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net wrote:
I don't know if you can remove the /sys/.../firmware ABI altogether, because
there is at least one, somewhat popular udev replacement
On Thu, Oct 04, 2012 at 09:39:41AM -0400, Josh Boyer wrote:
That said, there's clearly enough variation here that I think that for
now I won't take the step to disable the udev part. I'll do the patch
to support direct filesystem firmware loading using the udev default
paths, and that
On Tue, 2 Oct 2012, Linus Torvalds wrote:
Now, at the same time, I do agree that network devices should generally
try to delay it until ifup time
Slightly tangential to the ongoing discussion, but still ... I think that
even all network drivers should delay firmware loading to ifup time
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH gre...@linuxfoundation.org wrote:
Mauro, what version of udev are you using that is still showing this
issue?
Kay, didn't you resolve this already? If not, what was the reason why?
It's the same in the current release, we still haven't wrapped our
On Wed, Oct 3, 2012 at 7:36 AM, Kay Sievers k...@vrfy.org wrote:
If that unfortunate module_init() lockup can't be solved properly in
the kernel
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
As even you admit, it is *udev* that has the whole serialization
issue, and
Em 02-10-2012 19:47, Linus Torvalds escreveu:
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH gre...@linuxfoundation.org wrote:
which went into udev release 187 which I think corresponds to the place
when people started having problems, right Mauro?
According to what I've seen, people started
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Yes. The issue was noticed with media drivers when people started using the
drivers on Fedora 17, witch came with udev-182. There's an open
bugzilla there:
On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote:
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH gre...@linuxfoundation.org wrote:
Mauro, what version of udev are you using that is still showing this
issue?
Kay, didn't you resolve this already? If not, what was the reason why?
On Wed, Oct 3, 2012 at 9:38 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Anyway. Attached is a really stupid patch that tries to do the direct
firmware load as suggested by Ivan. It has not been tested very
extensively at all (but I did test that it loaded the brcmsmac
firmware
On Wed, Oct 03, 2012 at 09:38:52AM -0700, Linus Torvalds wrote:
Yeah, that bugzilla shows the problem with Kay as a maintainer too,
not willing to own up to problems he caused.
Can you actually see the problem? I did add the attached patch as an
attachment to the bugzilla, so the reporter
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH gre...@linuxfoundation.org wrote:
It's the same in the current release, we still haven't wrapped our
head around how to fix it/work around it.
Ick, as this is breaking people's previously-working machines, shouldn't
this be resolved quickly?
Nothing
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check mode and size in kstat; if
it's sufficiently hot for that to hurt, we
On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers k...@vrfy.org wrote:
Nothing really breaks, It's slow and it will surely be fixed when
we know what's the right fix, which we haven't sorted out at this
moment.
A thirty-second pause at bootup is easily long enough that some people
might think the
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check
Em 03-10-2012 13:57, Greg KH escreveu:
On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote:
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH gre...@linuxfoundation.org wrote:
Mauro, what version of udev are you using that is still showing this
issue?
Kay, didn't you resolve this already?
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org wrote:
Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it to
the driver model may have not been such a good idea so many years ago.
Doing it this way makes more sense.
Ok, I wish this had
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org wrote:
Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it to
the driver model may have not been such a
On Wed, Oct 03, 2012 at 01:39:23PM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org wrote:
Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it to
the driver model may have not been such a good idea so many
Greg KH gre...@linuxfoundation.org wrote:
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk
wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH gre...@linuxfoundation.org wrote:
As for the firmware path, maybe we should
change that to be modified by userspace (much like /sbin/hotplug was) in
a proc file so that distros can override the location if they need to.
If that's needed, a
On Wed, 3 Oct 2012 23:18:06 +0200
Kay Sievers k...@vrfy.org wrote:
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH gre...@linuxfoundation.org wrote:
As for the firmware path, maybe we should
change that to be modified by userspace (much like /sbin/hotplug was) in
a proc file so that distros can
On Wed, Oct 3, 2012 at 5:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org wrote:
Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it to
the driver model may have not been such a
On Tue, Oct 2, 2012 at 7:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev ikalvac...@gmail.com wrote:
I'm not kernel developer and probably my opinion would be a little
naive, but here it is.
Please, make the kernel load firmware from
On Wed, Oct 3, 2012 at 2:58 PM, Lucas De Marchi
lucas.de.mar...@gmail.com wrote:
So maintaining the fallback or adding a configurable entry to set the
firmware paths might be good.
Yeah, I do think we need to make it configurable. Probably both at
kernel compile time and dynamically.
The aim
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org
wrote:
Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it
to
the driver model may have not been such a good idea so many years
ago.
Doing
Hi Linus,
On Wed, 3 Oct 2012 13:39:23 -0700 Linus Torvalds
torva...@linux-foundation.org wrote:
Ok, I wish this had been getting more testing in Linux-next or
something
If you ever want a patch tested for a few days, just send it to me and I
will put it in my fixes tree which is merged into
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net wrote:
I don't know if you can remove the /sys/.../firmware ABI altogether, because
there is at least one, somewhat popular udev replacement that also uses it:
mdev
http://git.busybox.net/busybox/plain/docs/mdev.txt
Heh.
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei ming@canonical.com wrote:
Yes, the patch will make firmware cache not working, I would like to fix
that when I return from one trip next week.
BTW, firmware cache is still needed even direct loading is taken.
I agree 100%, I'd have liked to do the
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, there's clearly enough variation here that I think that for
now I won't take the step to disable the udev part. I'll do the patch
to support direct filesystem firmware loading using the udev default
Hi Greg,
Em Mon, 25 Jun 2012 22:55:41 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Em 25-06-2012 19:33, Greg KH escreveu:
On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
I basically tried a few different approaches, including deferred probe(),
as you suggested, and request_firmware_async(), as Kay suggested.
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days?
On 10/2/12, Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
I basically tried a few different approaches, including deferred probe(),
as you suggested, and request_firmware_async(), as Kay suggested.
Stop
On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote:
I don't know where the problem started in udev, but the report I saw
was that udev175 was fine, and udev182 was broken, and would deadlock
if module_init() did a request_firmware(). That kind of nested
behavior is absolutely
On Tue, Oct 02, 2012 at 03:12:39PM -0700, Greg KH wrote:
On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote:
I don't know where the problem started in udev, but the report I saw
was that udev175 was fine, and udev182 was broken, and would deadlock
if module_init() did a
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev ikalvac...@gmail.com wrote:
I'm not kernel developer and probably my opinion would be a little
naive, but here it is.
Please, make the kernel load firmware from the filesystem on its own.
We probably should do that, not just for firmware, but
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH gre...@linuxfoundation.org wrote:
which went into udev release 187 which I think corresponds to the place
when people started having problems, right Mauro?
According to what I've seen, people started complaining in 182, not 187.
See for example
On Tue, 2 Oct 2012, Linus Torvalds wrote:
And see this email from Kay Sievers that shows that it was all known
about and intentional in the udev camp:
http://www.spinics.net/lists/netdev/msg185742.html
This seems confusing indeed.
That e-mail referenced above is talking about loading
On Tue, Oct 2, 2012 at 5:01 PM, Jiri Kosina jkos...@suse.cz wrote:
On Tue, 2 Oct 2012, Linus Torvalds wrote:
And see this email from Kay Sievers that shows that it was all known
about and intentional in the udev camp:
http://www.spinics.net/lists/netdev/msg185742.html
This seems
Hi Mauro,
On Mon, 25 Jun 2012 17:06:28 -0300, Mauro Carvalho Chehab wrote:
That's said, IMO, the best approach is to do:
1) add support for asynchronous probe at device core, for devices that
requires firmware
at probe(). The async_probe() will only be active if !usermodehelper_disabled.
On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote:
Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad
Em 25-06-2012 16:15, Antti Palosaari escreveu:
On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote:
Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
What change was that? How did it break anything?
Driver's documentation at
Em 25-06-2012 19:33, Greg KH escreveu:
On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
What change was that? How did it break
Hi Mauro
I think that your __i2c_transfer() solution is elegant for DVB-C frontend tuner
reprogramming sleep cases:
TDA6650 programming manual, page 9 states:
Main divider data are valid only if no new I2C-bus transmission
is started (START condition) during the computation
period of 50 μs.
On Thu, Jun 21, 2012 at 9:36 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as
Em 21-06-2012 11:21, Devin Heitmueller escreveu:
On Thu, Jun 21, 2012 at 9:36 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as they all seem to have an
50 matches
Mail list logo
