[ath9k-devel] ath9k: some more yummy patches

[ath9k-devel] ath9k: some more yummy patches

[Luis R. Rodriguez]

Some more yummmy patches, specially if you are interested in IBSS.
These are committed into ath9k git as well.

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/

  Luis

ath9k: some more yummy patches

[Luis R. Rodriguez]

Some more yummmy patches, specially if you are interested in IBSS.
These are committed into ath9k git as well.

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/

  Luis

[ath9k-devel] ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:13:37AM -0700, Luis R. Rodriguez wrote:
> Some more yummmy patches, specially if you are interested in IBSS.
> These are committed into ath9k git as well.
> 
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/

Btw I had a quick look over the driver, and it's quite huge..  Why does
the driver have it's own regdomain support?  Also there seems to be
quite some useless hal style abstractions and types.  Do you plan to
kill those?

And a lot of macros that want replacing by proper C code.

Re: ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:13:37AM -0700, Luis R. Rodriguez wrote:
> Some more yummmy patches, specially if you are interested in IBSS.
> These are committed into ath9k git as well.
> 
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/

Btw I had a quick look over the driver, and it's quite huge..  Why does
the driver have it's own regdomain support?  Also there seems to be
quite some useless hal style abstractions and types.  Do you plan to
kill those?

And a lot of macros that want replacing by proper C code.

[ath9k-devel] ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 9:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:13:37AM -0700, Luis R. Rodriguez wrote:
>> Some more yummmy patches, specially if you are interested in IBSS.
>> These are committed into ath9k git as well.
>>
>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/
>
> Btw I had a quick look over the driver, and it's quite huge..

Tell me about it.

> Why does
> the driver have it's own regdomain support?

It still needs a good scrubbing, just as well as the driver in general
in many areas, but basically what will be kept in terms of regulatory
is our own internal eeprom regulatory domain to support channel
mapping. This is because we have no firmware to do magic vodoo there
like others do. This is how we can support Linux. Also although CRDA
(not yet merged even) can provide a thorough and updated database
sometimes vendors want to support regulatory settings for clients
based on SKUs. The callback for setting a regulatory domain through
CRDA will allow us to review the central regulatory information and
override it if necessary, this is useful for cases where customers we
have may want to support channels 1-11 and if the regulatory domain
allows then channel 14 we'll keep the device stuck to 1-11 as that is
what the customer certified their devices for in terms of support or
testing. This exactly why a callback is part of the design for CRDA --
the central db provides the complete regulatory solution for drivers
with none but yet it allows vendors to enhance regulatory to meet
business and legal requirements.

> Also there seems to be
> quite some useless hal style abstractions and types.  Do you plan to
> kill those?

Absolutely.

> And a lot of macros that want replacing by proper C code.

Sure thing. We figure we get users supported first with a decent first
patch post so we're following the 'release early, review early'
technique. Further cleanup and enhancements can come through as we
move along.

  Luis

Re: ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 9:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:13:37AM -0700, Luis R. Rodriguez wrote:
>> Some more yummmy patches, specially if you are interested in IBSS.
>> These are committed into ath9k git as well.
>>
>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-07-23/
>
> Btw I had a quick look over the driver, and it's quite huge..

Tell me about it.

> Why does
> the driver have it's own regdomain support?

It still needs a good scrubbing, just as well as the driver in general
in many areas, but basically what will be kept in terms of regulatory
is our own internal eeprom regulatory domain to support channel
mapping. This is because we have no firmware to do magic vodoo there
like others do. This is how we can support Linux. Also although CRDA
(not yet merged even) can provide a thorough and updated database
sometimes vendors want to support regulatory settings for clients
based on SKUs. The callback for setting a regulatory domain through
CRDA will allow us to review the central regulatory information and
override it if necessary, this is useful for cases where customers we
have may want to support channels 1-11 and if the regulatory domain
allows then channel 14 we'll keep the device stuck to 1-11 as that is
what the customer certified their devices for in terms of support or
testing. This exactly why a callback is part of the design for CRDA --
the central db provides the complete regulatory solution for drivers
with none but yet it allows vendors to enhance regulatory to meet
business and legal requirements.

> Also there seems to be
> quite some useless hal style abstractions and types.  Do you plan to
> kill those?

Absolutely.

> And a lot of macros that want replacing by proper C code.

Sure thing. We figure we get users supported first with a decent first
patch post so we're following the 'release early, review early'
technique. Further cleanup and enhancements can come through as we
move along.

  Luis

[ath9k-devel] ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:43:24AM -0700, Luis R. Rodriguez wrote:
> Sure thing. We figure we get users supported first with a decent first
> patch post so we're following the 'release early, review early'
> technique. Further cleanup and enhancements can come through as we
> move along.

Yes, absolutely.  I just wrote up the few comments I had so far.
Might be worth to add a writeup of your midterm plans to the wiki page.

Re: ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:43:24AM -0700, Luis R. Rodriguez wrote:
> Sure thing. We figure we get users supported first with a decent first
> patch post so we're following the 'release early, review early'
> technique. Further cleanup and enhancements can come through as we
> move along.

Yes, absolutely.  I just wrote up the few comments I had so far.
Might be worth to add a writeup of your midterm plans to the wiki page.

[ath9k-devel] ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 9:46 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:43:24AM -0700, Luis R. Rodriguez wrote:
>> Sure thing. We figure we get users supported first with a decent first
>> patch post so we're following the 'release early, review early'
>> technique. Further cleanup and enhancements can come through as we
>> move along.
>
> Yes, absolutely.  I just wrote up the few comments I had so far.
> Might be worth to add a writeup of your midterm plans to the wiki page.

How's this?

http://wireless.kernel.org/en/users/Drivers/ath9k#TODO

I take it we made it too late for .27?

  Luis

Re: ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 9:46 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:43:24AM -0700, Luis R. Rodriguez wrote:
>> Sure thing. We figure we get users supported first with a decent first
>> patch post so we're following the 'release early, review early'
>> technique. Further cleanup and enhancements can come through as we
>> move along.
>
> Yes, absolutely.  I just wrote up the few comments I had so far.
> Might be worth to add a writeup of your midterm plans to the wiki page.

How's this?

http://wireless.kernel.org/en/users/Drivers/ath9k#TODO

I take it we made it too late for .27?

  Luis

[ath9k-devel] ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
> I take it we made it too late for .27?

Well, we decided to put driver in anytime in the process, so if the
driver is cleaned up enough in the next month or so it should be able
to make it.

Re: ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
> I take it we made it too late for .27?

Well, we decided to put driver in anytime in the process, so if the
driver is cleaned up enough in the next month or so it should be able
to make it.

[ath9k-devel] ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
>> I take it we made it too late for .27?
>
> Well, we decided to put driver in anytime in the process, so if the
> driver is cleaned up enough in the next month or so it should be able
> to make it.

Great! We are committed so let me know if you find other critical
areas of cleanups you'd like to see.

  Luis

Re: ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
>> I take it we made it too late for .27?
>
> Well, we decided to put driver in anytime in the process, so if the
> driver is cleaned up enough in the next month or so it should be able
> to make it.

Great! We are committed so let me know if you find other critical
areas of cleanups you'd like to see.

  Luis

[ath9k-devel] ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 10:01:37AM -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
> >> I take it we made it too late for .27?
> >
> > Well, we decided to put driver in anytime in the process, so if the
> > driver is cleaned up enough in the next month or so it should be able
> > to make it.
> 
> Great! We are committed so let me know if you find other critical
> areas of cleanups you'd like to see.

Let's start with some easy ones that might not be critical by itself
but help making the driver look like a normal Linux driver:

 - replace enum hal_bool with the normal bool type
 - replace A_MAX usage with the normal max/max_t macros
 - just use ASSERT instead of assert
 - think about doing the same for KASSERT
 - kill memzero
 - kill get_dma_mem_context and copy_dma_mem_context
 - replace the various debug message print helpers with standard
   Linux infrastructure

Re: ath9k: some more yummy patches

[Christoph Hellwig]

On Wed, Jul 23, 2008 at 10:01:37AM -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
> >> I take it we made it too late for .27?
> >
> > Well, we decided to put driver in anytime in the process, so if the
> > driver is cleaned up enough in the next month or so it should be able
> > to make it.
> 
> Great! We are committed so let me know if you find other critical
> areas of cleanups you'd like to see.

Let's start with some easy ones that might not be critical by itself
but help making the driver look like a normal Linux driver:

 - replace enum hal_bool with the normal bool type
 - replace A_MAX usage with the normal max/max_t macros
 - just use ASSERT instead of assert
 - think about doing the same for KASSERT
 - kill memzero
 - kill get_dma_mem_context and copy_dma_mem_context
 - replace the various debug message print helpers with standard
   Linux infrastructure

[ath9k-devel] ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 10:15 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 10:01:37AM -0700, Luis R. Rodriguez wrote:
>> On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> > On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
>> >> I take it we made it too late for .27?
>> >
>> > Well, we decided to put driver in anytime in the process, so if the
>> > driver is cleaned up enough in the next month or so it should be able
>> > to make it.
>>
>> Great! We are committed so let me know if you find other critical
>> areas of cleanups you'd like to see.
>
> Let's start with some easy ones that might not be critical by itself
> but help making the driver look like a normal Linux driver:
>
>  - replace enum hal_bool with the normal bool type
>  - replace A_MAX usage with the normal max/max_t macros
>  - just use ASSERT instead of assert
>  - think about doing the same for KASSERT
>  - kill memzero
>  - kill get_dma_mem_context and copy_dma_mem_context
>  - replace the various debug message print helpers with standard
>   Linux infrastructure

We'll get cracking on this.

  Luis

Re: ath9k: some more yummy patches

[Luis R. Rodriguez]

On Wed, Jul 23, 2008 at 10:15 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jul 23, 2008 at 10:01:37AM -0700, Luis R. Rodriguez wrote:
>> On Wed, Jul 23, 2008 at 10:00 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> > On Wed, Jul 23, 2008 at 09:57:31AM -0700, Luis R. Rodriguez wrote:
>> >> I take it we made it too late for .27?
>> >
>> > Well, we decided to put driver in anytime in the process, so if the
>> > driver is cleaned up enough in the next month or so it should be able
>> > to make it.
>>
>> Great! We are committed so let me know if you find other critical
>> areas of cleanups you'd like to see.
>
> Let's start with some easy ones that might not be critical by itself
> but help making the driver look like a normal Linux driver:
>
>  - replace enum hal_bool with the normal bool type
>  - replace A_MAX usage with the normal max/max_t macros
>  - just use ASSERT instead of assert
>  - think about doing the same for KASSERT
>  - kill memzero
>  - kill get_dma_mem_context and copy_dma_mem_context
>  - replace the various debug message print helpers with standard
>   Linux infrastructure

We'll get cracking on this.

  Luis