mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sander Eikelenboom <linux@eikelenboom.it>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Julian Calaby <julian.calaby@gmail.com>,
	Arend van Spriel <arend@broadcom.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Berg, Johannes" <johannes.berg@intel.com>,
	"Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ilw@linux.intel.com" <ilw@linux.intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	Avinash Patil <avinashapatil@gmail.com>
Subject: Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work.
Date: Tue, 17 Dec 2013 22:49:14 +0100	[thread overview]
Message-ID: <1254825772.20131217224914@eikelenboom.it> (raw)
In-Reply-To: <20131217212709.GB5624@decadent.org.uk>


Tuesday, December 17, 2013, 10:27:09 PM, you wrote:

> On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote:
> [...]
>> > It's the official Debian package.
> [...]
>> > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd.
>> 
>> With all the wireless stuff switched to loadable modules it *does* work.
>> 
>> So the problem is that:
>> The current code blocks all future regulatory domain setting attempts forever (till the next reboot)
>> when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd.
>> 
>> So from the question department:
>> 
>> A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ?
>> B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ?
> [...]

> It doesn't make any logical sense to put a userland program in
> /lib/firmware, and it wouldn't have any effect on the initramfs
> builders I'm familiar with (which look at module metadata to work
> out which files to include from /lib/firmware).

Ah yes of course stupid, it's not just a blob of the regdb but
a userland program.

> Debian official kernels use modular drivers, and neither
> initramfs-tools nor dracut includes wireless drivers in the initramfs.
> If you build a custom kernel with built-in drivers then you most
> likely don't need an initramfs at all.

> As maintainer of crda in Debian, I could add an initramfs hook that
> would include it in an initramfs.  But I don't understand why it would
> be worth doing so.  Why is it so useful to have wireless drivers
> built-in *and* an initramfs?  If you think I should do this then open
> a bug (reportbug crda).

Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea
for the moment.

So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in.
It needs a access to a userland program at module load time, or it will block forever.

> Ben.



  reply	other threads:[~2013-12-17 21:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1507831110.20131018194349@eikelenboom.it>
2013-10-23 12:28 ` Sander Eikelenboom
2013-12-11 15:17   ` Sander Eikelenboom
2013-12-11 15:38     ` Luis R. Rodriguez
2013-12-11 16:53       ` Sander Eikelenboom
2013-12-11 17:14         ` Luis R. Rodriguez
2013-12-11 17:28           ` Sander Eikelenboom
2013-12-11 17:53             ` Luis R. Rodriguez
2013-12-11 18:02               ` Luis R. Rodriguez
2013-12-11 18:11               ` Sander Eikelenboom
2013-12-11 18:38                 ` Luis R. Rodriguez
2013-12-11 19:06                   ` Sander Eikelenboom
2013-12-18 18:54                     ` Luis R. Rodriguez
2013-12-16 11:22                   ` Sander Eikelenboom
2013-12-16 11:37                     ` Arend van Spriel
2013-12-16 12:56                       ` Sander Eikelenboom
2013-12-17  2:17                         ` Julian Calaby
2013-12-17  9:45                           ` Sander Eikelenboom
2013-12-17 20:33                             ` Sander Eikelenboom
2013-12-17 21:27                               ` Ben Hutchings
2013-12-17 21:49                                 ` Sander Eikelenboom [this message]
2013-12-17 22:06                                   ` Linus Torvalds
2013-12-18  9:16                                     ` Arend van Spriel
2013-12-18  9:18                                       ` Grumbach, Emmanuel
2013-12-18  9:25                                       ` Sander Eikelenboom
2013-12-18  9:26                                       ` Johannes Berg
2013-12-18 10:48                                         ` Sander Eikelenboom
2013-12-18 19:43                                           ` Luis R. Rodriguez
2013-12-18 19:45                                             ` Sander Eikelenboom
2013-12-19  4:57                                               ` Luis R. Rodriguez
2013-12-17 23:35                                   ` Julian Calaby
2013-12-18  7:50                                   ` Pontus Fuchs
2013-12-18  8:58                                     ` Arend van Spriel
2013-12-18 19:27                         ` Luis R. Rodriguez
2013-12-18 18:29                     ` Luis R. Rodriguez
2013-12-18 18:54                       ` Sander Eikelenboom
2013-12-18 19:42                         ` Luis R. Rodriguez
     [not found]       ` <CAJwzM1nwFa7z5gwh42aj39M2dxVXnuecDrhQkVyL+DDFAXwwbg@mail.gmail.com>
2013-12-11 17:00         ` Sander Eikelenboom
2013-12-11 17:17           ` Luis R. Rodriguez

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=1254825772.20131217224914@eikelenboom.it \
    --to=linux@eikelenboom.it \
    --cc=arend@broadcom.com \
    --cc=avinashapatil@gmail.com \
    --cc=ben@decadent.org.uk \
    --cc=emmanuel.grumbach@intel.com \
    --cc=ilw@linux.intel.com \
    --cc=johannes.berg@intel.com \
    --cc=julian.calaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@do-not-panic.com \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®