On 05/07/11 00:52, Luca Olivetti wrote:
> Al 02/07/11 20:49, En/na Luca Olivetti ha escrit:
>> Al 02/07/11 20:34, En/na John Crispin ha escrit:
>>> On 02/07/11 20:15, Luca Olivetti wrote:
>>>> Al 02/07/11 19:58, En/na Florian Fainelli ha escrit:
>>>>
>>>>   
>>>>>> 0) @@ -0,0 +1,11 @@
>>>>>> +--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c       2011-02-08
>>>>>> 17:33:42.000000000 +0100 ++++
>>>>>> b/drivers/net/wireless/ath/ath9k/eeprom_def.c    2011-02-20
>>>>>> 17:51:47.000000000 +0100 +@@ -147,7 +152,7 @@
>>>>>> +                return false;
>>>>>> +        }
>>>>>> +
>>>>>> +-       if (!ath9k_hw_use_flash(ah)) {
>>>>>> ++       if (1) {
>>>>>>       
>>>>> This looks wrong.
>>>>>     
>>>> Why?
>>>>
>>>> See http://patchwork.openwrt.org/patch/849/ for the previous discussion.
>>>>
>>>> Bye
>>>>   
>>> because it will break devices which dont have the eeprom inside the flash
>>
>> Are you sure?
>> Mind me, I could be wrong, but looking at eeprom.c:
>>
>> int ath9k_hw_eeprom_init(struct ath_hw *ah)
>> {
>>         int status;
>>
>>         if (AR_SREV_9300_20_OR_LATER(ah))
>>                 ah->eep_ops = &eep_ar9300_ops;
>>         else if (AR_SREV_9287(ah)) {
>>                 ah->eep_ops = &eep_ar9287_ops;
>>         } else if (AR_SREV_9285(ah) || AR_SREV_9271(ah)) {
>>                 ah->eep_ops = &eep_4k_ops;
>>         } else {
>>                 ah->eep_ops = &eep_def_ops;
>>         }
>>
>>         if (!ah->eep_ops->fill_eeprom(ah))
>>                 return -EIO;
>>
>>         status = ah->eep_ops->check_eeprom(ah);
>>
>>         return status;
>> }
>>
>> So when it reaches check_eeprom (where the endianness check is done),
>> it has already called fill_eeprom, which copies the data in ram,
>> so it shouldn't matter if the device has an onboard eeprom or uses the flash 
>> to
>> emulate it.
>> Felix said that the endianness check should be done unconditionally, maybe
>> he knows better.
> 
> So, what's the final decision?
> Should I forget about ath9k support on this board?
> 
> Bye

why always so huffy ?

has the open question of the patch possibly breaking ath9k on other
targets been answered ? no it has not...

so until that is resolved we cant add the patch.

as you may have noticed i have been pushing lots of patches the last few
days and am still in the middle of it ...

so, if you have more insight into the
>>>>>> +-       if (!ath9k_hw_use_flash(ah)) {
>>>>>> ++       if (1) {
issue let me know.
otherwise you need to wait until i verified it


_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to