From: Larry Finger <Larry.Finger@lwfinger.net>
To: Michael Buesch <mb@bu3sch.de>
Cc: b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: [RFC/RFT] ssb: resolve alternate SPROM offset for 14e4:4315
Date: Thu, 06 May 2010 08:11:37 -0500 [thread overview]
Message-ID: <4BE2C009.8020002@lwfinger.net> (raw)
In-Reply-To: <201005061201.18469.mb@bu3sch.de>
On 05/06/2010 05:01 AM, Michael Buesch wrote:
> On Thursday 06 May 2010 11:53:01 Michael Buesch wrote:
>> On Thursday 06 May 2010 07:00:13 Larry Finger wrote:
>>> This patch and the patch by Gabor entitled "[PATCH] ssb: Implement
>>> fast powerup delay calculation" are enough to allow the netbook from
>>> John to work with ssb/b43. As this patch tampers with the SPROM offset for
>>> 14e4:4315 devices, it should be tested by anyone with an LP PHY that works
>>> to ensure that it is not killed.
>>>
>>> The essential elements of this patch will also be tested as part of kernel Bug
>>> #15825.
>>>
>>> Larry
>>>
>>> Index: wireless-testing/drivers/ssb/pci.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/pci.c
>>> +++ wireless-testing/drivers/ssb/pci.c
>>> @@ -631,8 +631,17 @@ static int ssb_pci_sprom_get(struct ssb_
>>> return -ENODEV;
>>> }
>>>
>>> - bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
>>> - SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
>>> + /* get SPROM offset: SSB_SPROM_BASE1 except for chipcommon rev >= 31
>>> + * or chip ID is 0x4312 and bit 0x2 is set in chipcommon status
>>> + */
>>> + if (bus->chipco.dev->id.revision >= 31)
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else if (bus->chip_id == 0x4312 && (bus->chipco.status & 0x02))
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else
>>> + bus->sprom_offset = SSB_SPROM_BASE1;
>>> +
>>> + ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);
>>>
>>> buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
>>> if (!buf)
>>> Index: wireless-testing/drivers/ssb/scan.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/scan.c
>>> +++ wireless-testing/drivers/ssb/scan.c
>>> @@ -306,6 +306,11 @@ int ssb_bus_scan(struct ssb_bus *bus,
>>> }
>>> tmp = scan_read32(bus, 0, SSB_CHIPCO_CAP);
>>> bus->chipco.capabilities = tmp;
>>> + if (bus->chip_rev >= 11)
>>
>> This still is wrong. the chip_rev is not the chipcommon core revision.
>
> Although technically in most (all?) cases it might be the same number.
> I'm not sure on that one.
> But it is read from an entirely different register and I think it's plain
> wrong to assume that chip_rev equals the chipcommon core rev.
Is it OK to read the chipcommon capabilities here?
>> We already went through this and we decided to read the chipstat later.
>> Read it in chipcommon init. The bus scan is _way_ too early to read this.
I missed that, but found it now.
Larry
WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Michael Buesch <mb@bu3sch.de>
Cc: b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [RFC/RFT] ssb: resolve alternate SPROM offset for 14e4:4315
Date: Thu, 06 May 2010 08:11:37 -0500 [thread overview]
Message-ID: <4BE2C009.8020002@lwfinger.net> (raw)
In-Reply-To: <201005061201.18469.mb@bu3sch.de>
On 05/06/2010 05:01 AM, Michael Buesch wrote:
> On Thursday 06 May 2010 11:53:01 Michael Buesch wrote:
>> On Thursday 06 May 2010 07:00:13 Larry Finger wrote:
>>> This patch and the patch by Gabor entitled "[PATCH] ssb: Implement
>>> fast powerup delay calculation" are enough to allow the netbook from
>>> John to work with ssb/b43. As this patch tampers with the SPROM offset for
>>> 14e4:4315 devices, it should be tested by anyone with an LP PHY that works
>>> to ensure that it is not killed.
>>>
>>> The essential elements of this patch will also be tested as part of kernel Bug
>>> #15825.
>>>
>>> Larry
>>>
>>> Index: wireless-testing/drivers/ssb/pci.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/pci.c
>>> +++ wireless-testing/drivers/ssb/pci.c
>>> @@ -631,8 +631,17 @@ static int ssb_pci_sprom_get(struct ssb_
>>> return -ENODEV;
>>> }
>>>
>>> - bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
>>> - SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
>>> + /* get SPROM offset: SSB_SPROM_BASE1 except for chipcommon rev >= 31
>>> + * or chip ID is 0x4312 and bit 0x2 is set in chipcommon status
>>> + */
>>> + if (bus->chipco.dev->id.revision >= 31)
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else if (bus->chip_id == 0x4312 && (bus->chipco.status & 0x02))
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else
>>> + bus->sprom_offset = SSB_SPROM_BASE1;
>>> +
>>> + ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);
>>>
>>> buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
>>> if (!buf)
>>> Index: wireless-testing/drivers/ssb/scan.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/scan.c
>>> +++ wireless-testing/drivers/ssb/scan.c
>>> @@ -306,6 +306,11 @@ int ssb_bus_scan(struct ssb_bus *bus,
>>> }
>>> tmp = scan_read32(bus, 0, SSB_CHIPCO_CAP);
>>> bus->chipco.capabilities = tmp;
>>> + if (bus->chip_rev >= 11)
>>
>> This still is wrong. the chip_rev is not the chipcommon core revision.
>
> Although technically in most (all?) cases it might be the same number.
> I'm not sure on that one.
> But it is read from an entirely different register and I think it's plain
> wrong to assume that chip_rev equals the chipcommon core rev.
Is it OK to read the chipcommon capabilities here?
>> We already went through this and we decided to read the chipstat later.
>> Read it in chipcommon init. The bus scan is _way_ too early to read this.
I missed that, but found it now.
Larry
next prev parent reply other threads:[~2010-05-06 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 5:00 [RFC/RFT] ssb: resolve alternate SPROM offset for 14e4:4315 Larry Finger
2010-05-06 8:45 ` Mark Huijgen
2010-05-06 9:53 ` Michael Buesch
2010-05-06 9:53 ` Michael Buesch
2010-05-06 10:01 ` Michael Buesch
2010-05-06 10:01 ` Michael Buesch
2010-05-06 13:11 ` Larry Finger [this message]
2010-05-06 13:11 ` Larry Finger
2010-05-06 22:44 ` Michael Buesch
2010-05-06 22:44 ` Michael Buesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE2C009.8020002@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=b43-dev@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mb@bu3sch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.