All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Kyle Moffett <kyle@moffetthome.net>
Cc: "Alex Deucher" <alexdeucher@gmail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Pavel Ivanov" <paivanof@gmail.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	dri-devel@lists.freedesktop.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
Date: Mon, 29 Aug 2011 19:21:46 +0200	[thread overview]
Message-ID: <20110829172146.GE2025@gere.osrc.amd.com> (raw)
In-Reply-To: <CAGZ=bqKHvauaW8jdPR98d-X5dry_pADYHWH-OsJE_CXT9hdwVw@mail.gmail.com>

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:
> 
> config DRM_RADEON_FIRMWARE
>         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.

Thanks.

-- 
Regards/Gruss,
Boris.


  reply	other threads:[~2011-08-29 17:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-27  4:20 Kernel almost hangs when CONFIG_DRM_RADEON=y Pavel Ivanov
2011-08-27  9:00 ` Michel Dänzer
2011-08-27 22:50   ` Pavel Ivanov
2011-08-28  5:36     ` Borislav Petkov
2011-08-28 21:47       ` Pavel Ivanov
2011-08-28 21:47         ` Pavel Ivanov
2011-08-29  5:49         ` Borislav Petkov
2011-08-29  6:04           ` Michel Dänzer
2011-08-29  6:04             ` Michel Dänzer
2011-08-29 13:20       ` Peter Zijlstra
2011-08-29 13:38         ` Borislav Petkov
2011-08-29 13:43           ` Dave Airlie
2011-08-29 13:48           ` Alex Deucher
2011-08-29 14:16             ` Borislav Petkov
2011-08-29 15:47               ` David Airlie
2011-08-29 15:55                 ` Borislav Petkov
2011-08-29 16:10                   ` Arnaud Lacombe
2011-08-29 16:10                     ` Arnaud Lacombe
2011-08-29 17:17                     ` Borislav Petkov
2011-08-29 17:38                       ` Michel Dänzer
2011-08-29 17:38                         ` Michel Dänzer
2011-08-29 17:50                       ` Peter Zijlstra
2011-08-29 18:09                       ` Peter Zijlstra
2011-08-29 18:16                       ` Peter Zijlstra
2011-08-29 21:14                         ` Borislav Petkov
2011-08-30  2:08                           ` Henrique de Moraes Holschuh
2011-08-30  2:08                           ` Henrique de Moraes Holschuh
2011-08-30  7:17                             ` Borislav Petkov
2011-08-30  7:17                               ` Borislav Petkov
2011-08-30 14:44                               ` Henrique de Moraes Holschuh
2011-08-30 14:44                               ` Henrique de Moraes Holschuh
2011-08-30  8:37                             ` Peter Zijlstra
2011-08-30 14:55                               ` Henrique de Moraes Holschuh
2011-08-29 16:28             ` Kyle Moffett
2011-08-29 17:21               ` Borislav Petkov [this message]
2011-08-29 17:51                 ` Peter Zijlstra
2011-08-27 23:03   ` Kyle Moffett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110829172146.GE2025@gere.osrc.amd.com \
    --to=bp@alien8.de \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kyle@moffetthome.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --cc=paivanof@gmail.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.