Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Wed, Oct 3, 2012 at 12:50 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> >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 been getting more testing in Linux-next or >something, but I suspect that what I'll do is to commit this patch >asap, and then commit another patch that turns off udev firmware >loading entirely for the synchronous firmware loading case. > >Why? Just to get more testing, and seeing if there are reports of >breakage. Maybe some udev out there has a different search path (or >because udev runs in a different filesystem namespace or whatever), in >which case running udev as a fallback would otherwise hide the fact >that he direct kernel firmware loading isn't working. > >We can (and will) revert things if that turns out to break things, but >I'd like to make any failures of the firmware direct-load path be fast >and hard, so that we can see when/what it breaks. > >Ok? Comments? > > Linus >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" >in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html 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 Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
