Kernel almost hangs when CONFIG_DRM_RADEON=y

Borislav Petkov bp at
Mon Aug 29 10:21:46 PDT 2011

On Mon, Aug 29, 2011 at 12:28:31PM -0400, Kyle Moffett wrote:
> No, Linus pushed back really hard last time this issue came up with
> something; a network driver if I recall correctly.

r8169 probably.

> The issue is that this happens *EVEN FOR MODULAR DRIVERS* during
> suspend/resume.  The firmware simply may not be available yet.
> If the driver fundamentally cannot work without the firmware then it should
> bind to the device and wait until the first userspace action before requesting
> firmware.
> Furthermore, the trend is generally to push the firmware OUT of the kernel
> binary to avoid any chance of license issues.  Even if the code is built-in
> it should not need built-in firmware.
> The quickest fix is probably something like this:
>         tristate
>         default m if STANDALONE
>         default y
> config DRM_RADEON
>         depends DRM_RADEON_FIRMWARE
> That should prevent somebody from building the radeon driver into the
> kernel unless they manually indicate that they have the extra firmware.
> Long-term, the driver should support modular firmware even when it's
> built-in to the kernel.

Yep, and drivers should be able to select the firmware they need without
users even needing to do anything about it except installing some
firmware-nonfree package or whatever.

Yeah, sounds much better than Kconfig actually aiding and abetting
firmware blobs in the kernel and users needing to do stuff.



More information about the dri-devel mailing list