Re: [PATCH 2/2] bcma: expose cc sprom to sysfs

["Arend van Spriel" <arend@broadcom.com>]

On 08/23/2012 10:53 PM, Larry Finger wrote:
> On 08/23/2012 02:44 PM, Rafał Miłecki wrote:
>> 2012/8/17 Arend van Spriel <arend@broadcom.com>:
>>> On 08/16/2012 09:06 PM, Saul St. John wrote:
>>>>
>>>> On BCMA devices with a ChipCommon core of revision 31 or higher, the
>>>> device
>>>> SPROM can be accessed through CC core registers. This patch exposes the
>>>> SPROM on such devices for read/write access as a sysfs attribute.
>>>>
>>>> Tested on a MacBookPro8,2 with BCM4331.
>>>>
>>>> Cc: Rafał Miłecki <zajec5@gmail.com>
>>>> Cc: John W. Linville <linville@tuxdriver.com>
>>>> Signed-off-by: Saul St. John <saul.stjohn@gmail.com>
>>>
>>>
>>> Hi Saul,
>>>
>>> I was still planning to come back to your reply on August 14. Just
>>> wanted to
>>> reply to this patch as I still feel it is a bad thing to open up the
>>> sprom
>>> as a whole. I can see the use-cases you mentioned as useful, but
>>> maybe we
>>> can get a specific solution for that.
>>
>> I agree with Arend's doubts, on the other hand it would be nice to
>> provide some workaround for that stupid HP wifi blacklisting.
>>
>> Providing a way to overwrite just a vendor is really close to allowing
>> overwriting anything. In that case we probably should just allow
>> writing whole SPROM... Which again, is sth some want to avoid.
>>
>>
>> I wonder if we could write some user-space tool for writing SPROM.
>> Accessing ChipCommon registers is quite trivial, the thing I'm not
>> familiar with is accessing PCIE Wifi card registers. I know there are
>> tools for accessing GPU card regs. They work really well, I wonder if
>> we can use the same method for Wifi cards?
>> If so, we could write user-space app and keep this out of kernel.
>> Maybe we could even extend that tool to cover ssb cards and drop SPROM
>> on SSB writing support from kernel?
>
> This idea sounds good to me. The only valid use of the ssb SPROM writing
> was when we found some G-PHY cards that had the BT compatibility setting
> wrong. Now there is a set of quirks that eliminate that need for
> rewriting the SPROM.
>
> With a separate utility, we can control what parameters can be changed.
> The vendor codes are one possibility. What else would be useful? I have
> seen changing the MAC address be mentioned, but I would argue against
> that. There are too many possibilities for misuse.

That was indeed my concern. I know people have their legitimate reasons 
for it, but it is more for convenience as it is a necessity. Given that 
MAC spoofing also allows misuse.

The same is true for the country code. When left to the user they can 
select a country code with a less restrictive regulatory parameters for 
which the device might not be certified. With the utility we could also 
control how the parameters are changed. However, the country code change 
on system level is already covered and properly restricted by the 
regulatory framework.

Gr. AvS