Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/23/2012 02:44 PM, Rafał Miłecki wrote:
2012/8/17 Arend van Spriel <arend@xxxxxxxxxxxx>:
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@xxxxxxxxx>
Cc: John W. Linville <linville@xxxxxxxxxxxxx>
Signed-off-by: Saul St. John <saul.stjohn@xxxxxxxxx>


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.

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux