On Thursday, January 12, 2017 10:16:00 AM CET Johannes Berg wrote:
> And I realized only now that this was a different place ...
Right, it was a few hundred randconfigs later after I had confirmed
that the first patch fixed all the configurations that were broken
at first.
> I've just added the c
On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote:
> On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
> >
> > Applied. Also fixed the typo in the subject :)
>
> Thanks! Unfortunately I now got another warning for the same
> function, and though I would have expected the pat
> Come to think of it, I'm thinking I should drop this patch and the
> driver should just use iwe_stream_add_event() instead? It'll be
> somewhat tricky to get the length correct though.
No, turns out that's basically impossible with all the compat etc.
stuff here.
johannes
On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote:
> On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
> >
> > Applied. Also fixed the typo in the subject :)
>
> Thanks! Unfortunately I now got another warning for the same
> function, and though I would have expected the pat
On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
>
> Applied. Also fixed the typo in the subject :)
Thanks! Unfortunately I now got another warning for the same function,
and though I would have expected the patch to fix it, that did not work:
In file included from
/git/arm-so
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> > > NULL, and the memcpy doesn't actually
On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
wrote:
> On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
>> This works fine here because iwe->u.data.length is guaranteed to be
>> NULL, and the memcpy doesn't actually have an effect.
>
> I think you mean 0, not NULL, but I can fix that when
On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> gcc-7 complains that wl3501_cs passes NULL into a function that
> then uses the argument as the input for memcpy:
>
> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
> include/net/iw_handler.h:559:3: error: argument 2 null
On Wed, 2006-10-04 at 14:45 -0700, Jouni Malinen wrote:
> SIOCSIWMLME was designed to allow additional MLME commands to be added.
> IMHO, a potential replacement in the future should not prevent us from
> extending WEXT at this point and stop all changes in something that is
> currently available.
On Wed, Oct 04, 2006 at 10:37:23AM +0200, Johannes Berg wrote:
> On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote:
> > This patch (wext-patch) is a proposal. It adds two new defines for the
> > SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl.
> > (it would be
On Wed, 2006-10-04 at 12:56 +0200, [EMAIL PROTECTED] wrote:
> no really, the problem is that "my" hardware (aka: prism54 fullmac) does all
> the mac-management, encryption/decryption, AP-Management,... in the firmware.
> And all "management" operation are wrapped into a simple unique
> 4-byte "
On Wed, 2006-10-04 at 10:37, Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote:
> > This patch (wext-patch) is a proposal. It adds two new defines for the
> > SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a
> > ioctl. (it wou
On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote:
> This patch (wext-patch) is a proposal. It adds two new defines for the
> SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl.
> (it would be nice to have them, so that I can post the hostapd code for the
> prism
13 matches
Mail list logo
