b43-dev.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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 16:30:02 +0100	[thread overview]
Message-ID: <20110202163002.00005927@unknown> (raw)
In-Reply-To: <20110202125529.00002e75@unknown>

On Wed, 2 Feb 2011 12:55:29 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:

> 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;
> 	}
> ....
I try to send you a 'maybe regular' patch: this solves the issue; before
the patch, the MSB of the MAC address were overridden by one assignement
inside function ssb_pcmcia_get_invariants(...); here the patch


--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
	/* Fetch the vendor specific tuples. */
	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
-				ssb_pcmcia_do_get_invariants, sprom);
+				ssb_pcmcia_do_get_invariants, iv);
	if ((res == 0) || (res == -ENOSPC))
		return 0;

  reply	other threads:[~2011-02-02 15:30 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
2011-02-02 15:30                                   ` dylan cristiani [this message]
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=20110202163002.00005927@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).