Due to some recent optimization done in the way the mac address
bytes are written into the OTP memory, some AR9485 chipsets were
forced to use the first byte from the eeprom template and as AR9485
happens to use generic eeprom template which has 0x1 as the first
byte causes issues in bringing up the card.
So fixed the eeprom template accordingly to address the issue.
Cc: Paul Stewart <[email protected]>
Signed-off-by: Senthil Balasubramanian <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 184abb6..b527ea1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -69,7 +69,7 @@ static int ar9003_hw_power_interpolate(int32_t x,
static const struct ar9300_eeprom ar9300_default = {
.eepromVersion = 2,
.templateVersion = 2,
- .macAddr = {1, 2, 3, 4, 5, 6},
+ .macAddr = {0, 2, 3, 4, 5, 6},
.custData = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
.baseEepHeader = {
--
1.7.0.4
On Fri, Aug 12, 2011 at 01:17:34PM -0400, John W. Linville wrote:
> On Wed, Aug 10, 2011 at 12:14:16AM +0530, Senthil Balasubramanian wrote:
> > On Tue, Aug 09, 2011 at 11:32:17AM -0700, Luis R. Rodriguez wrote:
> > > On Tue, Aug 9, 2011 at 11:31 AM, Luis R. Rodriguez <[email protected]> wrote:
> > > > On Tue, Aug 9, 2011 at 11:22 AM, Senthil Balasubramanian
> > > > <[email protected]> wrote:
> > > >> Due to some recent optimization done in the way the mac address
> > > >> bytes are written into the OTP memory, some AR9485 chipsets were
> > > >> forced to use the first byte from the eeprom template and as AR9485
> > > >> happens to use generic eeprom template which has 0x1 as the first
> > > >> byte causes issues in bringing up the card.
> > > >>
> > > >> So fixed the eeprom template accordingly to address the issue.
> > > >>
> > > >> Cc: Paul Stewart <[email protected]>
> > > >> Signed-off-by: Senthil Balasubramanian <[email protected]>
> > > >
> > > > I don't follow the description too well, all I can tell from it is
> > > > that there is an issue if the template has 0x01 set instead of 0x0 but
> > > > it doesn't tell me why.
> > The leading byte is 1 which is obviously incorrect for mac address.
> > The reason why 1 is chosen by the driver for mac address is due to
> > the way the OTP write was optimized and so the driver has taken the
> > first byte alone from the template and the remaining from OTP.
> >
> > >
> > > Is this not a stable fix?
> > Oops.. Yes it is. Let me cc to stable. thanks for the stable reminder :-(
>
> Are you goint to resubmit a patch w/ a better changelog and
> Cc: [email protected]?
Yes.. John. Sorry! for the long silence from my side.
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> [email protected] might be all we have. Be ready.
On Tue, Aug 09, 2011 at 11:32:17AM -0700, Luis R. Rodriguez wrote:
> On Tue, Aug 9, 2011 at 11:31 AM, Luis R. Rodriguez <[email protected]> wrote:
> > On Tue, Aug 9, 2011 at 11:22 AM, Senthil Balasubramanian
> > <[email protected]> wrote:
> >> Due to some recent optimization done in the way the mac address
> >> bytes are written into the OTP memory, some AR9485 chipsets were
> >> forced to use the first byte from the eeprom template and as AR9485
> >> happens to use generic eeprom template which has 0x1 as the first
> >> byte causes issues in bringing up the card.
> >>
> >> So fixed the eeprom template accordingly to address the issue.
> >>
> >> Cc: Paul Stewart <[email protected]>
> >> Signed-off-by: Senthil Balasubramanian <[email protected]>
> >
> > I don't follow the description too well, all I can tell from it is
> > that there is an issue if the template has 0x01 set instead of 0x0 but
> > it doesn't tell me why.
The leading byte is 1 which is obviously incorrect for mac address.
The reason why 1 is chosen by the driver for mac address is due to
the way the OTP write was optimized and so the driver has taken the
first byte alone from the template and the remaining from OTP.
>
> Is this not a stable fix?
Oops.. Yes it is. Let me cc to stable. thanks for the stable reminder :-(
>
> Luis
On Tue, Aug 9, 2011 at 11:22 AM, Senthil Balasubramanian
<[email protected]> wrote:
> Due to some recent optimization done in the way the mac address
> bytes are written into the OTP memory, some AR9485 chipsets were
> forced to use the first byte from the eeprom template and as AR9485
> happens to use generic eeprom template which has 0x1 as the first
> byte causes issues in bringing up the card.
>
> So fixed the eeprom template accordingly to address the issue.
>
> Cc: Paul Stewart <[email protected]>
> Signed-off-by: Senthil Balasubramanian <[email protected]>
I don't follow the description too well, all I can tell from it is
that there is an issue if the template has 0x01 set instead of 0x0 but
it doesn't tell me why.
Luis
On Tue, Aug 9, 2011 at 11:31 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Tue, Aug 9, 2011 at 11:22 AM, Senthil Balasubramanian
> <[email protected]> wrote:
>> Due to some recent optimization done in the way the mac address
>> bytes are written into the OTP memory, some AR9485 chipsets were
>> forced to use the first byte from the eeprom template and as AR9485
>> happens to use generic eeprom template which has 0x1 as the first
>> byte causes issues in bringing up the card.
>>
>> So fixed the eeprom template accordingly to address the issue.
>>
>> Cc: Paul Stewart <[email protected]>
>> Signed-off-by: Senthil Balasubramanian <[email protected]>
>
> I don't follow the description too well, all I can tell from it is
> that there is an issue if the template has 0x01 set instead of 0x0 but
> it doesn't tell me why.
Is this not a stable fix?
Luis
On Wed, Aug 10, 2011 at 12:14:16AM +0530, Senthil Balasubramanian wrote:
> On Tue, Aug 09, 2011 at 11:32:17AM -0700, Luis R. Rodriguez wrote:
> > On Tue, Aug 9, 2011 at 11:31 AM, Luis R. Rodriguez <[email protected]> wrote:
> > > On Tue, Aug 9, 2011 at 11:22 AM, Senthil Balasubramanian
> > > <[email protected]> wrote:
> > >> Due to some recent optimization done in the way the mac address
> > >> bytes are written into the OTP memory, some AR9485 chipsets were
> > >> forced to use the first byte from the eeprom template and as AR9485
> > >> happens to use generic eeprom template which has 0x1 as the first
> > >> byte causes issues in bringing up the card.
> > >>
> > >> So fixed the eeprom template accordingly to address the issue.
> > >>
> > >> Cc: Paul Stewart <[email protected]>
> > >> Signed-off-by: Senthil Balasubramanian <[email protected]>
> > >
> > > I don't follow the description too well, all I can tell from it is
> > > that there is an issue if the template has 0x01 set instead of 0x0 but
> > > it doesn't tell me why.
> The leading byte is 1 which is obviously incorrect for mac address.
> The reason why 1 is chosen by the driver for mac address is due to
> the way the OTP write was optimized and so the driver has taken the
> first byte alone from the template and the remaining from OTP.
>
> >
> > Is this not a stable fix?
> Oops.. Yes it is. Let me cc to stable. thanks for the stable reminder :-(
Are you goint to resubmit a patch w/ a better changelog and
Cc: [email protected]?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.