From: dylan cristiani <d.cristiani@idem-tech.it>
To: b43-dev@lists.infradead.org
Subject: Trouble using bcm4318 compact flash with b43 driver
Date: Wed, 2 Feb 2011 12:55:29 +0100 [thread overview]
Message-ID: <20110202125529.00002e75@unknown> (raw)
In-Reply-To: <20110202101151.00007105@unknown>
On Wed, 2 Feb 2011 10:11:51 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
> On Tue, 01 Feb 2011 14:40:32 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> > On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > > i have some news: i went back to kernel version 2.6.26 and it
> > > worked so i moved forward kernel by kernel and it works till
> > > kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> > > and, at module loading time i can see for the first time, after
> > > loading firmware, the following debug info (don't know if it's
> > > helpful but same message happears in every non-working kernel
> > > from 2.6.33 to 2.6.37):
> > >
> > > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> >
> > Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> > SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> > (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> > logging of a core scan. The two remaining are 391ae22 that fixed an
> > SDIO typo and 8b45499 that put host pointers in a union should be
> > the only ones that needed testing.
> >
> > Those patches are attached. Try each of them in turn to 2.6.33 with
> > a 'patch -p1 -R < patch_name' If it doesn't help, use the same
> > command without the "-R" to reapply. I'm guessing that 8b45499 is
> > more likely to be the problem, and I would try it first.
> >
> > Larry
> Hi Larry i tryied to reverte two patches you sent me but nothing
> happens; but i discovered interesting behaviour: the mac address of
> the module is:
> 00:0B:B6....
> but starting from 2.6.33 the chip is read as:
> 14:0B:B6....
> (maybe the '0x14' value could be '20dBm' related to the max-TX-power
> value.....); so it seems that the driver is faulty reading the chip
> properties from sprom (in fact till the 2.6.32 the mac address was
> correct and the max-TX-power warning wasn't issued); i noticed that
> into drivers/ssb/pcmcia.c tha way to read properties from the chip is
> changed also; hope this helps
Hi larry i located the problem: at ssb level the info (MAC,
max-TX-power and friends) are ok, while when at b43 driver level there
are some data corruption; here comes the log of some debug i put into
drivers followed by the code slices where i put the debug; i'm sure
i'll find the trouble:
boot log
...
MMMMAC0 = 0
MMMMAC1 = b
MMMMAC1 = 6b
MMMMAC1 = 1e
MMMMAC1 = 3e
MMMMAC1 = 86
sprom->maxpwr_bg = 76
ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
IEEEMMMMAC0 = 14
IEEEMMMMAC1 = b
IEEEMMMMAC1 = 6b
IEEEMMMMAC1 = 1e
IEEEMMMMAC1 = 3e
IEEEMMMMAC1 = 86
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
Reconfiguring network interfaces...
ip: RTNETLINK answers: File exists
b43 ssb0:0: firmware: requesting b43/ucode5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/pcm5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
phy_g max_pwr_bg = 65535
b43-phy0 warning: Invalid max-TX-power value in SPROM.
udhcpc (v1.17.4) started
Sending discover...
phy_g max_pwr_bg = 80
Sending discover...
Sending discover...
No lease, failing
.....
and here the sources:
drivers/ssb/pcmcia.c
static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
tuple_t *tuple,
void *priv)
{
struct ssb_sprom *sprom = priv;
if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
return -EINVAL;
if (tuple->TupleDataLen != ETH_ALEN + 2)
return -EINVAL;
if (tuple->TupleData[1] != ETH_ALEN)
return -EINVAL;
memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
//ssb_log
printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
//ssb_log
return 0;
};
.....
static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
tuple_t *tuple,
void *priv)
{
.....
sprom->maxpwr_bg = tuple->TupleData[8];
//ssb_log
printk(KERN_INFO "sprom->maxpwr_bg = %d",
sprom->maxpwr_bg);
//ssb_log
......
drivers/net/wireless/b43/main.c
static int b43_wireless_init(struct ssb_device *dev)
{
....
if (is_valid_ether_addr(sprom->et1mac))
SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
else
SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
//b43_main_log
printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
//b43_main_log
....
drivers/net/wireless/b43/phy_g.c
/* Estimate the TX power emission based on the TSSI */
estimated_pwr = b43_gphy_estimate_power_out(dev, average_tssi);
B43_WARN_ON(phy->type != B43_PHYTYPE_G);
max_pwr = dev->dev->bus->sprom.maxpwr_bg;
//b43_phyg_log
printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
//b43_phyg_log
if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
max_pwr -= 3; /* minus 0.75 */
if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
b43warn(dev->wl,
"Invalid max-TX-power value in SPROM.\n");
max_pwr = INT_TO_Q52(20); /* fake it */
dev->dev->bus->sprom.maxpwr_bg = max_pwr;
}
....
next prev parent reply other threads:[~2011-02-02 11:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 17:21 Trouble using bcm4318 compact flash with b43 driver dylan cristiani
2011-01-14 18:52 ` Larry Finger
2011-01-15 7:05 ` Dylan Cristiani
2011-01-15 16:38 ` Larry Finger
2011-01-17 10:06 ` dylan cristiani
2011-01-17 13:51 ` dylan cristiani
2011-01-18 10:58 ` dylan cristiani
2011-01-18 14:34 ` Larry Finger
2011-01-19 13:03 ` dylan cristiani
2011-01-21 15:51 ` Dylan Cristiani
2011-01-21 17:22 ` Larry Finger
2011-01-21 21:54 ` Dylan Cristiani
2011-01-21 22:13 ` Larry Finger
2011-01-22 10:48 ` Dylan Cristiani
2011-02-01 14:41 ` dylan cristiani
2011-02-01 20:40 ` Larry Finger
2011-02-02 9:11 ` dylan cristiani
2011-02-02 11:55 ` dylan cristiani [this message]
2011-02-02 15:30 ` dylan cristiani
2011-02-02 21:58 ` Larry Finger
2011-02-03 8:28 ` dylan cristiani
2011-02-02 22:40 ` Michael Büsch
2011-02-03 8:45 ` dylan cristiani
2011-02-03 10:29 ` Michael Büsch
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=20110202125529.00002e75@unknown \
--to=d.cristiani@idem-tech.it \
--cc=b43-dev@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).