Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1613632 > unrolled thread

[PATCH RFC] remove custom Michael MIC implementation

Back to article view | Back to linux.kernel

Contents

  [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-03-31 06:50 +0200
    Re: [PATCH RFC] remove custom Michael MIC implementation Wolfram Sang <wsa@the-dreams.de> - 2017-03-31 10:00 +0200
      Re: [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-03-31 12:30 +0200
        Re: [PATCH RFC] remove custom Michael MIC implementation Wolfram Sang <wsa@the-dreams.de> - 2017-03-31 12:50 +0200
          Re: [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-04-01 12:50 +0200
        Re: [PATCH RFC] remove custom Michael MIC implementation Kalle Valo <kvalo@codeaurora.org> - 2017-04-03 07:30 +0200
          Re: [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-04-03 11:10 +0200
            Re: [PATCH RFC] remove custom Michael MIC implementation Kalle Valo <kvalo@codeaurora.org> - 2017-04-03 12:00 +0200
            Re: [PATCH RFC] remove custom Michael MIC implementation Toke Høiland-Jørgensen <toke@toke.dk> - 2017-04-03 12:10 +0200
              Re: [PATCH RFC] remove custom Michael MIC implementation Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-04-03 12:20 +0200
                Re: [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-04-03 23:40 +0200
                  Re: [PATCH RFC] remove custom Michael MIC implementation Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-04-04 23:40 +0200
                    Re: [PATCH RFC] remove custom Michael MIC implementation "Tobin C. Harding" <me@tobin.cc> - 2017-04-05 03:20 +0200
            Re: [PATCH RFC] remove custom Michael MIC implementation Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-03 14:20 +0200

#1613632 — [PATCH RFC] remove custom Michael MIC implementation

This RFC can be applied on op on Linus' tree 89970a0

Configuration options needed to build are

CONFIG_STAGING=y
CONFIG_KS7010=m

The ks7010 driver currently uses a custom implementation of the
Michael MIC algorithm. The kernel has an implementation of this
algorithm already. This patch is an attempt to replace the custom
implementation with the in-tree implementation via the kernel
cryptography API.

I am not an expert on the Michael Message Integrity Check or on
cryptography in general. Actually, I'm not even an expert on kernel
development.

I believe I have mirrored the behavior of the custom implementation. I
do not know if I have done this completely correctly or, for that
matter, if I have gone about it correctly. The only in-tree driver I
could find that does the MIC check in software was the Orinoco driver
(net/wireless/intersil/orinoco). I based this code off of the Orinoco
code and the current implementation.

The whole thing is in one patch since there was no way to keep the
driver in a sane state during the implementation replacement.

The steps I took were as follows;

1. Remove the custom implementation, michael_mic.[ch]

2. Implement helper functions that call the kernel crypto API, this is
   the code that is based of Orinoco, mic.[ch]

3. Replace driver calls to the custom implementation with calls to the
   newly defined helper functions.


The code is untested, I have hardware in the mail.

If any one is interested and has any comments I would really like to
hear them. I am open to all suggestions (even down to trivial coding
style issues).

Thank you for taking the time to read this and for any tips you may be
able to give me.

thanks,
Tobin.

Tobin C. Harding (1):
  staging: ks7010: remove custom Michael MIC implementation

 drivers/staging/ks7010/Makefile      |   2 +-
 drivers/staging/ks7010/ks_hostif.c   |  48 +++++++-----
 drivers/staging/ks7010/ks_wlan.h     |   3 +
 drivers/staging/ks7010/mic.c         | 131 +++++++++++++++++++++++++++++++
 drivers/staging/ks7010/mic.h         |  22 ++++++
 drivers/staging/ks7010/michael_mic.c | 148 -----------------------------------
 drivers/staging/ks7010/michael_mic.h |  25 ------
 7 files changed, 186 insertions(+), 193 deletions(-)
 create mode 100644 drivers/staging/ks7010/mic.c
 create mode 100644 drivers/staging/ks7010/mic.h
 delete mode 100644 drivers/staging/ks7010/michael_mic.c
 delete mode 100644 drivers/staging/ks7010/michael_mic.h

-- 
2.7.4

[toc] | [next] | [standalone]

#1613716

[Multipart message — attachments visible in raw view] — view raw

> The code is untested, I have hardware in the mail.

Cool!

> If any one is interested and has any comments I would really like to
> hear them. I am open to all suggestions (even down to trivial coding
> style issues).

I'll just repeat that the key move to get this driver out of staging is
to get away from the WEXT interface to CFG80211. Otherwise no chance
that wireless maintainers will even look at it. This is a huge change
but once it is done, features like Michael MIC come with it for free
(from what I recall, I am not a wireless expert myself).

Without the CFG80211 conversion, replacing the Michael custom
implementation with the in-kernel one makes the driver a tad better and
is good exercise. However, it will sadly not help to get the driver out
of staging.

But if you want a clean WEXT driver first, this is a step in the right
direction.

[toc] | [prev] | [next] | [standalone]

#1613850

[Multipart message — attachments visible in raw view] — view raw

On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
> 
> > The code is untested, I have hardware in the mail.
> 
> Cool!

The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
a SDW-823 and should use the ks7010 driver. I am going to attempt to
get it running on a Raspberry Pi B+. I ordered the wrong size break
out board originally so waiting on the new one now.

> 
> > If any one is interested and has any comments I would really like to
> > hear them. I am open to all suggestions (even down to trivial coding
> > style issues).
> 
> I'll just repeat that the key move to get this driver out of staging is
> to get away from the WEXT interface to CFG80211. Otherwise no chance
> that wireless maintainers will even look at it. This is a huge change
> but once it is done, features like Michael MIC come with it for free
> (from what I recall, I am not a wireless expert myself).

That would explain why I could not find more than the Orinoco driver
using the Michael MIC module directly.

> Without the CFG80211 conversion, replacing the Michael custom
> implementation with the in-kernel one makes the driver a tad better and
> is good exercise. However, it will sadly not help to get the driver out
> of staging.

I'll drop it then. Could you please tell me, is there any thing else
more I need to do to let LKML know that this RFC is dropped? Or is
this reply enough. I don't want to use any ones time unnecessarily.

> 
> But if you want a clean WEXT driver first, this is a step in the right
> direction.
> 

Let's go for a CFG80211 driver and get out of staging :) So next step
is I guess study the ath6kl driver, learn how CFG80211 is done and
implement that interface in ks7010? Oh, and test that it works.

thanks,
Tobin.

[toc] | [prev] | [next] | [standalone]

#1613858

[Multipart message — attachments visible in raw view] — view raw

Hi,

> The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> a SDW-823 and should use the ks7010 driver.

Sorry, likely not. It is an early SDW-821 and has a MediaTek chipset for
which no driver is known:
https://wikidevi.com/wiki/Spectec_SDW-821_%28MediaTek%29

For SDW-821 (SD size) and KS7010, you'd need a "S2Y-WLAN-11G-K" (but I
have never seen one yet):
https://wikidevi.com/wiki/Spectec_SDW-821_%28KeyStream%29

One can find an SDW-823 (microSD) "S2Y-MWLAN-11B-G" once in a while:
https://wikidevi.com/wiki/Spectec_SDW-823

> > Without the CFG80211 conversion, replacing the Michael custom
> > implementation with the in-kernel one makes the driver a tad better and
> > is good exercise. However, it will sadly not help to get the driver out
> > of staging.
> 
> I'll drop it then. Could you please tell me, is there any thing else
> more I need to do to let LKML know that this RFC is dropped? Or is
> this reply enough. I don't want to use any ones time unnecessarily.

That should do.

> Let's go for a CFG80211 driver and get out of staging :) So next step
> is I guess study the ath6kl driver, learn how CFG80211 is done and
> implement that interface in ks7010? Oh, and test that it works.

Yes, have a look around and check if you like that task. I might have a
spare SDW-823 lying around if you are up to it. But check first, it is
not a trivial task. On the pro side, there are tons of interesting
things about WiFI and kernel development to learn on the way :)

Regards,

   Wolfram

[toc] | [prev] | [next] | [standalone]

#1614452

[Multipart message — attachments visible in raw view] — view raw

On Fri, Mar 31, 2017 at 12:42:22PM +0200, Wolfram Sang wrote:
> Hi,
> 
> > The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> > a SDW-823 and should use the ks7010 driver.
> 
> Sorry, likely not. It is an early SDW-821 and has a MediaTek chipset for
> which no driver is known:
> https://wikidevi.com/wiki/Spectec_SDW-821_%28MediaTek%29

Oh damn.

> 
> For SDW-821 (SD size) and KS7010, you'd need a "S2Y-WLAN-11G-K" (but I
> have never seen one yet):
> https://wikidevi.com/wiki/Spectec_SDW-821_%28KeyStream%29
> 
> One can find an SDW-823 (microSD) "S2Y-MWLAN-11B-G" once in a while:
> https://wikidevi.com/wiki/Spectec_SDW-823

That's actually the page I was reading, I didn't notice the 'M' in there.

> > > Without the CFG80211 conversion, replacing the Michael custom
> > > implementation with the in-kernel one makes the driver a tad better and
> > > is good exercise. However, it will sadly not help to get the driver out
> > > of staging.
> > 
> > I'll drop it then. Could you please tell me, is there any thing else
> > more I need to do to let LKML know that this RFC is dropped? Or is
> > this reply enough. I don't want to use any ones time unnecessarily.
> 
> That should do.
> 
> > Let's go for a CFG80211 driver and get out of staging :) So next step
> > is I guess study the ath6kl driver, learn how CFG80211 is done and
> > implement that interface in ks7010? Oh, and test that it works.
> 
> Yes, have a look around and check if you like that task. I might have a
> spare SDW-823 lying around if you are up to it. But check first, it is
> not a trivial task. On the pro side, there are tons of interesting
> things about WiFI and kernel development to learn on the way :)

I like the task. You had me at 'this is a huge change...' in your
first email. Whether I have the ability is yet to be seen. Thanks for
the offer of the card, let's wait first to see if I can make any
progress that warrants testing. The new breakout board turned up in
the mail today, super glad to read your email before I spent the day
tomorrow trying to get it working :)

> 
> Regards,
> 
>    Wolfram
> 

Cheers Wolfram,
Tobin.

[toc] | [prev] | [next] | [standalone]

#1614893

+ linux-wireless

"Tobin C. Harding" <me@tobin.cc> writes:

> On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
>> 
>> > The code is untested, I have hardware in the mail.
>> 
>> Cool!
>
> The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> a SDW-823 and should use the ks7010 driver. I am going to attempt to
> get it running on a Raspberry Pi B+. I ordered the wrong size break
> out board originally so waiting on the new one now.
>
>> 
>> > If any one is interested and has any comments I would really like to
>> > hear them. I am open to all suggestions (even down to trivial coding
>> > style issues).
>> 
>> I'll just repeat that the key move to get this driver out of staging is
>> to get away from the WEXT interface to CFG80211. Otherwise no chance
>> that wireless maintainers will even look at it. This is a huge change
>> but once it is done, features like Michael MIC come with it for free
>> (from what I recall, I am not a wireless expert myself).
>
> That would explain why I could not find more than the Orinoco driver
> using the Michael MIC module directly.

I think cfg80211 and mac80211 got mixed up. mac80211 (the full IEEE
802.11 stack for "softmac" devices) provides Michael MIC implementation,
but cfg80211 (for "hardmac" devices) does not.

>> Without the CFG80211 conversion, replacing the Michael custom
>> implementation with the in-kernel one makes the driver a tad better and
>> is good exercise. However, it will sadly not help to get the driver out
>> of staging.
>
> I'll drop it then. Could you please tell me, is there any thing else
> more I need to do to let LKML know that this RFC is dropped? Or is
> this reply enough. I don't want to use any ones time unnecessarily.
>
>> 
>> But if you want a clean WEXT driver first, this is a step in the right
>> direction.
>
> Let's go for a CFG80211 driver and get out of staging :) So next step
> is I guess study the ath6kl driver, learn how CFG80211 is done and
> implement that interface in ks7010? Oh, and test that it works.

Please keep linux-wireless list in loop so that people on that list can
help.

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1614992

On Mon, Apr 03, 2017 at 08:19:40AM +0300, Kalle Valo wrote:
> + linux-wireless
> 
> "Tobin C. Harding" <me@tobin.cc> writes:
> 
> > On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
> >> 
> >> > The code is untested, I have hardware in the mail.
> >> 
> >> Cool!
> >
> > The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> > a SDW-823 and should use the ks7010 driver. I am going to attempt to
> > get it running on a Raspberry Pi B+. I ordered the wrong size break
> > out board originally so waiting on the new one now.
> >
> >> 
> >> > If any one is interested and has any comments I would really like to
> >> > hear them. I am open to all suggestions (even down to trivial coding
> >> > style issues).
> >> 
> >> I'll just repeat that the key move to get this driver out of staging is
> >> to get away from the WEXT interface to CFG80211. Otherwise no chance
> >> that wireless maintainers will even look at it. This is a huge change
> >> but once it is done, features like Michael MIC come with it for free
> >> (from what I recall, I am not a wireless expert myself).
> >
> > That would explain why I could not find more than the Orinoco driver
> > using the Michael MIC module directly.
> 
> I think cfg80211 and mac80211 got mixed up. mac80211 (the full IEEE
> 802.11 stack for "softmac" devices) provides Michael MIC implementation,
> but cfg80211 (for "hardmac" devices) does not.

Cool, thanks for clarifying. Hilariously I was just sitting down
trying to figure out what was up after a day spent trying to merge
ideas from ath6kl (fullmac) and ks7010. I finally spent some time
reading the cw1200 driver (softmac) for further inspiration.

> >> Without the CFG80211 conversion, replacing the Michael custom
> >> implementation with the in-kernel one makes the driver a tad better and
> >> is good exercise. However, it will sadly not help to get the driver out
> >> of staging.
> >
> > I'll drop it then. Could you please tell me, is there any thing else
> > more I need to do to let LKML know that this RFC is dropped? Or is
> > this reply enough. I don't want to use any ones time unnecessarily.
> >
> >> 
> >> But if you want a clean WEXT driver first, this is a step in the right
> >> direction.
> >
> > Let's go for a CFG80211 driver and get out of staging :) So next step
> > is I guess study the ath6kl driver, learn how CFG80211 is done and
> > implement that interface in ks7010? Oh, and test that it works.
> 
> Please keep linux-wireless list in loop so that people on that list can
> help.

How newbie friendly is the linux-wireless list please? I am having
trouble separating the data path code from the control path. I think I
will spend a few more days on it though before asking any questions.

Except one: do you know off the top of your head of a canonical
implementation of a softmac wi-fi driver.

thanks,
Tobin.

[toc] | [prev] | [next] | [standalone]

#1615049

"Tobin C. Harding" <me@tobin.cc> writes:

>> >> But if you want a clean WEXT driver first, this is a step in the right
>> >> direction.
>> >
>> > Let's go for a CFG80211 driver and get out of staging :) So next step
>> > is I guess study the ath6kl driver, learn how CFG80211 is done and
>> > implement that interface in ks7010? Oh, and test that it works.
>> 
>> Please keep linux-wireless list in loop so that people on that list can
>> help.
>
> How newbie friendly is the linux-wireless list please?

I would claim quite friendly, but I'm finnish and our definition of
"friendly" seems to be very different from rest of the world ;)

> I am having trouble separating the data path code from the control
> path. I think I will spend a few more days on it though before asking
> any questions.

People do send questions to the list and most of the time they get
answered. So go for it.

There's also an irc channel which usually is helpful:

https://wireless.wiki.kernel.org/en/users/support#linux_wireless_user_irc_channel

> Except one: do you know off the top of your head of a canonical
> implementation of a softmac wi-fi driver.

You mean a mac80211 driver? mac80211_hwsim is the simplest one, but
that's not a real driver as it's a simulator. Just grep
ieee80211_register() to find all the drivers. Smaller drivers like
rtl8xxxu or wl1251 might be good starting points to get familiar with
the stack.

And I guess you already saw the documentation:

https://wireless.wiki.kernel.org/en/developers/documentation/mac80211

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1615050

"Tobin C. Harding" <me@tobin.cc> writes:

> Except one: do you know off the top of your head of a canonical
> implementation of a softmac wi-fi driver.

I'll suggest taking a look at the ath9k driver :)

-Toke

[toc] | [prev] | [next] | [standalone]

#1615061

seems we are missing out again?

On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
> "Tobin C. Harding" <me@tobin.cc> writes:
> 
>> Except one: do you know off the top of your head of a canonical
>> implementation of a softmac wi-fi driver.
> 
> I'll suggest taking a look at the ath9k driver :)

Looking at ks7010 driver it looks like it has 802.11 stack in firmware
and not sure if Renesas is actively supporting this effort to come up
with mac80211-friendly firmware or provide detailed chip info.

Regards,
Arend

[toc] | [prev] | [next] | [standalone]

#1615573

On Mon, Apr 03, 2017 at 12:15:15PM +0200, Arend Van Spriel wrote:
> seems we are missing out again?

Sorry, I don't understand what this comment means?

> On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
> > "Tobin C. Harding" <me@tobin.cc> writes:
> > 
> >> Except one: do you know off the top of your head of a canonical
> >> implementation of a softmac wi-fi driver.
> > 
> > I'll suggest taking a look at the ath9k driver :)
> 
> Looking at ks7010 driver it looks like it has 802.11 stack in firmware
> and not sure if Renesas is actively supporting this effort to come up
> with mac80211-friendly firmware or provide detailed chip info.

Thanks for taking a look. If the ks7010 driver has 802.11 stack in
firmware does that mean it is not compatible with using the kernel
mac80211 stack with the current firmware? I do not have my hopes up
about getting any chip information out of Renesas, all I think we have
to go in is the current WEXT driver.

This is an exercise in learning for me, but I do not want to take any
ones time up with a project that is not that useful. Is getting the
ks7010 driver out of staging something that is of use to the kernel
community or are there other wi-fi tasks that our time is better spent
on?

thanks,
Tobin.

[toc] | [prev] | [next] | [standalone]

#1616386

On 3-4-2017 23:39, Tobin C. Harding wrote:
> On Mon, Apr 03, 2017 at 12:15:15PM +0200, Arend Van Spriel wrote:
>> seems we are missing out again?
> 
> Sorry, I don't understand what this comment means?

My bad. I had to reset my email account in thunderbird and now it needs
to learn anew what is spam and what is not. So I missed out on the
conversation as some messages (a lot actually) ended up in my spam folder.

>> On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
>>> "Tobin C. Harding" <me@tobin.cc> writes:
>>>
>>>> Except one: do you know off the top of your head of a canonical
>>>> implementation of a softmac wi-fi driver.
>>>
>>> I'll suggest taking a look at the ath9k driver :)
>>
>> Looking at ks7010 driver it looks like it has 802.11 stack in firmware
>> and not sure if Renesas is actively supporting this effort to come up
>> with mac80211-friendly firmware or provide detailed chip info.
> 
> Thanks for taking a look. If the ks7010 driver has 802.11 stack in
> firmware does that mean it is not compatible with using the kernel
> mac80211 stack with the current firmware? I do not have my hopes up
> about getting any chip information out of Renesas, all I think we have
> to go in is the current WEXT driver.

Indeed. That is my gut feeling as well and if that is truly the case
your best option would be a cfg80211-based driver like ath6kl, mwifiex,
and brcmfmac.

> This is an exercise in learning for me, but I do not want to take any
> ones time up with a project that is not that useful. Is getting the
> ks7010 driver out of staging something that is of use to the kernel
> community or are there other wi-fi tasks that our time is better spent
> on?

If there are linux users with this hardware than sure. Especially if it
revised to interface with the latest wireless subsystem so tools like iw
can operate on it.

Also I suppose it is preferred if a driver is maintained. I do not see
the ks7010 listed in the MAINTAINERS file yet.

> thanks,
> Tobin.
> 

[toc] | [prev] | [next] | [standalone]

#1616486

On Tue, Apr 04, 2017 at 11:31:14PM +0200, Arend Van Spriel wrote:
> >> On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote:
> >>> "Tobin C. Harding" <me@tobin.cc> writes:
> >>>
> >>>> Except one: do you know off the top of your head of a canonical
> >>>> implementation of a softmac wi-fi driver.
> >>>
> >>> I'll suggest taking a look at the ath9k driver :)
> >>
> >> Looking at ks7010 driver it looks like it has 802.11 stack in firmware
> >> and not sure if Renesas is actively supporting this effort to come up
> >> with mac80211-friendly firmware or provide detailed chip info.
> > 
> > Thanks for taking a look. If the ks7010 driver has 802.11 stack in
> > firmware does that mean it is not compatible with using the kernel
> > mac80211 stack with the current firmware? I do not have my hopes up
> > about getting any chip information out of Renesas, all I think we have
> > to go in is the current WEXT driver.
> 
> Indeed. That is my gut feeling as well and if that is truly the case
> your best option would be a cfg80211-based driver like ath6kl, mwifiex,
> and brcmfmac.

Ok. So that would mean that we still have to do the Michael MIC in software
(using kernel crypto API) right?

I think the best course of action is to totally clean up the WEXT
interface, including getting Michael MIC working with kernel
crypto, test it all, and then attempt the migration to cfg80211
interface.

If no one thinks that's a bad idea I'll keep working on the WEXT
interface for now.

> > This is an exercise in learning for me, but I do not want to take any
> > ones time up with a project that is not that useful. Is getting the
> > ks7010 driver out of staging something that is of use to the kernel
> > community or are there other wi-fi tasks that our time is better spent
> > on?
> 
> If there are linux users with this hardware than sure. Especially if it
> revised to interface with the latest wireless subsystem so tools like iw
> can operate on it.
> 
> Also I suppose it is preferred if a driver is maintained. I do not see
> the ks7010 listed in the MAINTAINERS file yet.

How's this for a MAINTAINERS entry?

KS7010 KEYSTREAM DRIVER
M:      Wolfram Sang <wsa@the-dreams.de>
M:      Tobin Harding <me@tobin.cc>
L:      driverdev-devel@linuxdriverproject.org
S:      Maintained
F:      drivers/staging/ks7010/

Wolfram, is this ok by you;
(a) To put your name
(b) To put my name

Is the status correct, I'm happy to help maintain it if that is acceptable
for someone of my experience level to do so. Is this driver part of
your job?

thanks,
Tobin.

[toc] | [prev] | [next] | [standalone]

#1615149

On Mon, Apr 03, 2017 at 07:03:59PM +1000, Tobin C. Harding wrote:
> On Mon, Apr 03, 2017 at 08:19:40AM +0300, Kalle Valo wrote:
> > + linux-wireless
> > 
> > "Tobin C. Harding" <me@tobin.cc> writes:
> > 
> > > On Fri, Mar 31, 2017 at 09:58:51AM +0200, Wolfram Sang wrote:
> > >> 
> > >> > The code is untested, I have hardware in the mail.
> > >> 
> > >> Cool!
> > >
> > > The card I have is a Spectec FCC ID: S2Y-WLAN-11B-G which I believe is
> > > a SDW-823 and should use the ks7010 driver. I am going to attempt to
> > > get it running on a Raspberry Pi B+. I ordered the wrong size break
> > > out board originally so waiting on the new one now.
> > >
> > >> 
> > >> > If any one is interested and has any comments I would really like to
> > >> > hear them. I am open to all suggestions (even down to trivial coding
> > >> > style issues).
> > >> 
> > >> I'll just repeat that the key move to get this driver out of staging is
> > >> to get away from the WEXT interface to CFG80211. Otherwise no chance
> > >> that wireless maintainers will even look at it. This is a huge change
> > >> but once it is done, features like Michael MIC come with it for free
> > >> (from what I recall, I am not a wireless expert myself).
> > >
> > > That would explain why I could not find more than the Orinoco driver
> > > using the Michael MIC module directly.
> > 
> > I think cfg80211 and mac80211 got mixed up. mac80211 (the full IEEE
> > 802.11 stack for "softmac" devices) provides Michael MIC implementation,
> > but cfg80211 (for "hardmac" devices) does not.
> 
> Cool, thanks for clarifying. Hilariously I was just sitting down
> trying to figure out what was up after a day spent trying to merge
> ideas from ath6kl (fullmac) and ks7010. I finally spent some time
> reading the cw1200 driver (softmac) for further inspiration.

As an example of a driver that has been moved from an internal wireless
stack to using the kernel stack is the vt6655 driver.  I think it's the
only driver that has done this type of transition, so look at the patch
history of it for an example of what to do.

good luck!

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web