On Wed, Dec 18, 2013 at 08:45:46PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, December 18, 2013, 8:43:28 PM, you wrote:
>
> > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote:
> >>
> >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote:
> >>
> >> > Hi all,
> >>
> >> >
Wednesday, December 18, 2013, 8:43:28 PM, you wrote:
> On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote:
>>
>> Wednesday, December 18, 2013, 10:26:25 AM, you wrote:
>>
>> > Hi all,
>>
>> > We really should be asking Luis to look at this who hasn't yet chimed
>> > in, presumab
On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote:
>
> Wednesday, December 18, 2013, 10:26:25 AM, you wrote:
>
> > Hi all,
>
> > We really should be asking Luis to look at this who hasn't yet chimed
> > in, presumably because he's between jobs (and travelling IIRC)
>
> > On Wed
On Wed, Dec 18, 2013 at 07:54:46PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, December 18, 2013, 7:29:10 PM, you wrote:
>
> > On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote:
> >>
> >> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
> >>
> >> > On Wed, Dec 11, 2013
On Mon, Dec 16, 2013 at 01:56:44PM +0100, Sander Eikelenboom wrote:
>
> Let's start from scratch then ...
>
>
> a) Isn't the point of the whole regulatory domain system that i can
>select (and restrict) the channels/frequencies my devices transmits
>on, so i can abide the law ?
The poin
Wednesday, December 18, 2013, 7:29:10 PM, you wrote:
> On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote:
>>
>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>>
>> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
>> > wrote:
>> >>
>> >> Wednesday, December 11, 2013
On Wed, Dec 11, 2013 at 08:06:51PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>
> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
> > wrote:
> >>
> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
> >>
> >>> The best way to address all
On Mon, Dec 16, 2013 at 12:22:00PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>
> > On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
> > wrote:
> >>
> >> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
> >>
> >>> The best way to address all
Wednesday, December 18, 2013, 10:26:25 AM, you wrote:
> Hi all,
> We really should be asking Luis to look at this who hasn't yet chimed
> in, presumably because he's between jobs (and travelling IIRC)
> On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote:
>> On 12/17/2013 11:06 PM, Linus
Hi all,
We really should be asking Luis to look at this who hasn't yet chimed
in, presumably because he's between jobs (and travelling IIRC)
On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote:
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> > We have literally had this *exact* same issue
Wednesday, December 18, 2013, 10:16:38 AM, you wrote:
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
>> We have literally had this *exact* same issue with firmware loading.
>> Network drivers shouldn't try to load firmware at module load time.
>> Same deal.
> It is kind of a chicken and egg pro
>
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> > We have literally had this *exact* same issue with firmware loading.
> > Network drivers shouldn't try to load firmware at module load time.
> > Same deal.
>
> It is kind of a chicken and egg problem for (wireless) networking drivers. To
> get
On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> We have literally had this *exact* same issue with firmware loading.
> Network drivers shouldn't try to load firmware at module load time.
> Same deal.
It is kind of a chicken and egg problem for (wireless) networking
drivers. To get IFF_UP from the
On 12/18/2013 08:50 AM, Pontus Fuchs wrote:
> On 2013-12-17 22:49, Sander Eikelenboom wrote:
>>
>> 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
On 2013-12-17 22:49, Sander Eikelenboom wrote:
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 progr
Hi All,
On Wed, Dec 18, 2013 at 8:49 AM, Sander Eikelenboom
wrote:
>
> Tuesday, December 17, 2013, 10:27:09 PM, you wrote:
>
>> On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote:
>> Debian official kernels use modular drivers, and neither
>> initramfs-tools nor dracut includes wi
On Tue, Dec 17, 2013 at 1:49 PM, Sander Eikelenboom
wrote:
>
> 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.
No, it's a very stupid module if it does
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
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 swi
Hello Sander,
Tuesday, December 17, 2013, 10:45:48 AM, you wrote:
> Tuesday, December 17, 2013, 3:17:50 AM, you wrote:
>> Hi Sander,
>> On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom
>> wrote:
>>>
>>> Monday, December 16, 2013, 12:37:47 PM, you wrote:
>>>
On 12/16/2013 12:22 PM, Sa
Tuesday, December 17, 2013, 3:17:50 AM, you wrote:
> Hi Sander,
> On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom
> wrote:
>>
>> Monday, December 16, 2013, 12:37:47 PM, you wrote:
>>
>>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote:
Wednesday, December 11, 2013, 7:38:50 PM, y
Hi Sander,
On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom
wrote:
>
> Monday, December 16, 2013, 12:37:47 PM, you wrote:
>
>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote:
>>>
>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>>>
On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikele
Monday, December 16, 2013, 12:37:47 PM, you wrote:
> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote:
>>
>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>>
>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
>>> wrote:
Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
On 12/16/2013 12:22 PM, Sander Eikelenboom wrote:
>
> Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
>
>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
>> wrote:
>>>
>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
>>>
The best way to address all this is by automatic reg
Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
> wrote:
>>
>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
>>
>>> The best way to address all this is by automatic region awareness and
>>> doing the right thing on devices, this h
Wednesday, December 11, 2013, 7:38:50 PM, you wrote:
> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
> wrote:
>>
>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
>>
>>> The best way to address all this is by automatic region awareness and
>>> doing the right thing on devices, this h
On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom
wrote:
>
> Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
>
>> The best way to address all this is by automatic region awareness and
>> doing the right thing on devices, this however requires good
>> architecture / calibration data / etc a
Wednesday, December 11, 2013, 6:53:07 PM, you wrote:
> On Wed, Dec 11, 2013 at 6:28 PM, Sander Eikelenboom
> wrote:
>> Wednesday, December 11, 2013, 6:14:16 PM, you wrote:
>>> Yeap, that's the case for Intel Atheros, and I think nowadays new
>>> broadcom upstream drivers too. Users should not ha
Also can you try with wireless-testing ?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Dec 11, 2013 at 6:28 PM, Sander Eikelenboom
wrote:
> Wednesday, December 11, 2013, 6:14:16 PM, you wrote:
>> Yeap, that's the case for Intel Atheros, and I think nowadays new
>> broadcom upstream drivers too. Users should not have to be involved on
>> setting the regulatory domain, everyth
Wednesday, December 11, 2013, 6:14:16 PM, you wrote:
> On Wed, Dec 11, 2013 at 5:53 PM, Sander Eikelenboom
> wrote:
>>
>> Wednesday, December 11, 2013, 4:38:13 PM, you wrote:
>>
>>> On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom
>>> wrote:
Since i haven't got a response to this yet an
On Wed, Dec 11, 2013 at 6:00 PM, Sander Eikelenboom
wrote:
> Could you send me the patch (or a link to it), i can't find it on the
> linux-wireless list.
I looked for such a patch and didn't find it either, perhaps both of
your issues are the same as with CRDA and the wireless-regdb not
having a
On Wed, Dec 11, 2013 at 5:53 PM, Sander Eikelenboom
wrote:
>
> Wednesday, December 11, 2013, 4:38:13 PM, you wrote:
>
>> On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom
>> wrote:
>>> Since i haven't got a response to this yet and after having the troubled
>>> machine back:
>>> The problem is
Wednesday, December 11, 2013, 5:34:27 PM, you wrote:
> Hi Luis,
> I have seen that hint during regulatory init still has request processed set
> to false. This results into further request set to pending. I have sent a
> patch for the same last week. Please have a look- I think issue faced by
Wednesday, December 11, 2013, 4:38:13 PM, you wrote:
> On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom
> wrote:
>> Since i haven't got a response to this yet and after having the troubled
>> machine back:
>> The problem is still present in linux 3.13-rc3
> Keep in mind regulatory hints for
On Wed, Dec 11, 2013 at 4:17 PM, Sander Eikelenboom
wrote:
> Since i haven't got a response to this yet and after having the troubled
> machine back:
> The problem is still present in linux 3.13-rc3
Keep in mind regulatory hints for Intel or Atheros cards do nothing
other than help compliance fu
Since i haven't got a response to this yet and after having the troubled
machine back:
The problem is still present in linux 3.13-rc3
The problem seems to be in this piece of code:
root@creabox:/usr/src/linux-tip# git blame -L 1567,1601 net/wireless/reg.c
fe33eb39 (Luis R. Rodriguez 2009-02-21
37 matches
Mail list logo
