Bruce Simpson wrote:
Sam Leffler wrote:
...
the "ath_hal" device.
Do not modify ah_desc.h like you've done. Add this to conf/options
ATH_HAL opt_ah.h
and use that to enable AH_SUPPORT_AR5416.
To clarify the first comment: you've made it impossible to build code
w/o the extended format d
Sam Leffler wrote:
...
the "ath_hal" device.
Do not modify ah_desc.h like you've done. Add this to conf/options
ATH_HAL opt_ah.h
and use that to enable AH_SUPPORT_AR5416.
To clarify the first comment: you've made it impossible to build code
w/o the extended format descriptor; this is wha
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing
these
ath(4) changes to RELENG_7
Bruce Simpson wrote:
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing
these
ath(4) changes to RELENG_7.
I can't remember i
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing these
ath(4) changes to RELENG_7.
I can't remember if I tested the kernel c
Bruce Simpson wrote:
> Hi,
>
> Looks like I'm late to the party. I was responsible for committing these
> ath(4) changes to RELENG_7.
> I can't remember if I tested the kernel compile without the
> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>
> Dennis Melentyev wrote:
>> 200
Hi,
Looks like I'm late to the party. I was responsible for committing these
ath(4) changes to RELENG_7.
I can't remember if I tested the kernel compile without the
AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
Dennis Melentyev wrote:
2009/4/16 Maxim Sobolev :
Dennis M
Maxim Sobolev wrote:
Dennis Melentyev wrote:
Could be worth an entry in UPDATING and/or explicitly added to GENERIC.
My point is that if the option is mandatory for compiling ath(4)
driver, then there is no point in having this option in the first place.
There is an entry in UPDATING and it
2009/4/16 Maxim Sobolev :
> Dennis Melentyev wrote:
>>
>> Could be worth an entry in UPDATING and/or explicitly added to GENERIC.
>
> My point is that if the option is mandatory for compiling ath(4) driver,
> then there is no point in having this option in the first place.
Well, fair.
+1 from me :
Dennis Melentyev wrote:
Could be worth an entry in UPDATING and/or explicitly added to GENERIC.
My point is that if the option is mandatory for compiling ath(4) driver,
then there is no point in having this option in the first place.
-Maxim
___
fre
Hi Max,
Also seen that.
Fixed with careful merging on my kernel config with GENERIC one.
There are additional strings involved:
device ath
device ath_rate_sample
After adding the later one (and probably, the first one too (?)) compiled ok.
Could be worth an entry in UPDATING and/or explicitly add
Sam,
What is the reason to have this option in the kernel config if kernel
compilation fails when this option is enabled? It also affects 7-stable.
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prot
Sam,
What is the reason to have this option in the kernel config if kernel
compilation fails when this option is enabled? It also affects 7-stable.
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototyp
13 matches
Mail list logo
