All of lore.kernel.org
 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 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.