From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:56743 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753520Ab0LAXId (ORCPT ); Wed, 1 Dec 2010 18:08:33 -0500 Received: by eye27 with SMTP id 27so3934865eye.19 for ; Wed, 01 Dec 2010 15:08:32 -0800 (PST) Message-ID: <4CF6D566.4050301@lwfinger.net> Date: Wed, 01 Dec 2010 17:08:22 -0600 From: Larry Finger MIME-Version: 1.0 To: Florian Fainelli CC: =?UTF-8?B?TWljaGFlbCBCw7xzY2g=?= , John Linville , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , =?UTF-8?B?R8OhYm9yIA==?= =?UTF-8?B?U3RlZmFuaWs=?= , b43-dev , wireless Subject: Re: RFC - removal of SPROM fallback References: <4CF69ED1.1070406@lwfinger.net> (sfid-20101201_201546_954964_FFFFFFFFC298F049) <1291240619.1960.3.camel@maggie> <4CF6CA2F.5050704@openwrt.org> In-Reply-To: <4CF6CA2F.5050704@openwrt.org> Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 12/01/2010 04:20 PM, Florian Fainelli wrote: > Hello, > > Le 01/12/2010 22:56, Michael Büsch a écrit : >> On Wed, 2010-12-01 at 13:15 -0600, Larry Finger wrote: >>> At one time, we thought that we had found BCM43xx devices with no >>> SPROM. In the >>> one case that I remember, it was because the SPROM had been relocated. >>> >>> I now have the data from John's device that needs the revision fixup >>> and I know >>> what is wrong - it is rev 2 with corrupted CRC. The defaulting to rev >>> 1 is >>> getting almost everything wrong, including MAC address and vendor. My >>> plan is to >>> write a better fixup routine. >>> >>> At the moment, we have some SPROM fallback code that has not been fully >>> implemented, and is probably not needed. Are there any objections to >>> stripping >>> this code out of drivers/ssb/pci.c and drivers/ssb/sprom.c? >> >> Yes. The code is needed for bcm63xx embedded devices. The code that uses >> it currently is not in mainline, though. It can be found in the OpenWRT >> repositories. > > It actually is mainline and used. > >> >> But I still think that the SPROM fallback mechanism should be replaced >> by a "platform data" based mechanism, or similar. Just removing it >> without replacement is not an option, because bcm63xx embedded really >> does not have an SPROM. > > Correct. The rationale behind this is that if you have a big flash for > your system, you do not want to afford the cost for another flash chip > storing the SPROM. Whichever mechanism works for your, I will do the > required changes in the bcm63xx architecture code. There is no need for that. I'll start my changes after the check for a fallback SPROM returns NULL. My only reason for removing anything is that I thought it was not used. Larry