ssb: sprom: add dev_id field for value overriding standard ID
Rafał Miłecki
maintainerPATCH 1/1 ssb: sprom: add dev_id field for value overriding standard ID
Some devices may have different features despite sharing the same ID (e.g. PCI ID). For example 14e4:4331 is usually a dual band, but this can be "limited". Device with "pci/x/y/devid=0x4332" supports 2.4 GHz only. Similarly 0x4333 will mean support for 5 GHz only.
Add entry in SPROM so info described above can be extracted and stored.
---
I managed to find "devid" on every common SPROM rev:
pci/1/1/sromrev=2
pci/1/1/devid=0x4318
pci/1/1/sromrev=4
pci/1/1/devid=0x4329
pci/1/1/sromrev=8
pci/1/1/devid=0x432d
pci/1/1/sromrev=9
pci/1/1/devid=0x4332
pci/1/1/sromrev=11
pci/1/1/devid=0x43a1
So it makes the most sense to always try to extract it.
--- arch/mips/bcm47xx/sprom.c | 1 + include/linux/ssb/ssb.h | 1 + 2 files changed, 2 insertions(+)
arch/mips/bcm47xx/sprom.c +1 -0
@@ -168,6 +168,7 @@ static void nvram_read_alpha2(const char *prefix, const char *name,static void bcm47xx_fill_sprom_r1234589 (struct ssb_sprom *sprom,const char *prefix,bool fallback) { +nvram_read_u16 (prefix,NULL ,"devid" , &sprom->dev_id,0 , fallback);nvram_read_u8 (prefix,NULL ,"ledbh0" , &sprom->gpio0,0xff , fallback);nvram_read_u8 (prefix,NULL ,"ledbh1" , &sprom->gpio1,0xff , fallback);nvram_read_u8 (prefix,NULL ,"ledbh2" , &sprom->gpio2,0xff , fallback);
include/linux/ssb/ssb.h +1 -0
@@ -33,6 +33,7 @@ struct ssb_sprom {u8 et1phyaddr;/* MII address for enet1 */ u8 et0mdcport;/* MDIO for enet0 */ u8 et1mdcport;/* MDIO for enet1 */ +u16 dev_id;/* Device ID overriding e.g. PCI ID */ u16 board_rev;/* Board revision number from SPROM. */ u16 board_num;/* Board number from SPROM. */ u16 board_type;/* Board type from SPROM. */
Signature · 1 line
1.8.4.5
Hauke Mehrtens
maintainerPATCH 1/1 ssb: sprom: add dev_id field for value overriding standard ID
Quoted 7 lines · Rafa? Mi?ecki
Some devices may have different features despite sharing the same ID (e.g. PCI ID). For example 14e4:4331 is usually a dual band, but this can be "limited". Device with "pci/x/y/devid=0x4332" supports 2.4 GHz only. Similarly
0x4333will mean support for 5 GHz only.
Add entry in SPROM so info described above can be extracted and stored.Signed-off-by Rafa? Mi?ecki <[email protected]>
This patch is ok, I missed that when adding BCM4716 support to brcmsmac. There is also a vendid var which should be used. See this code from brcmsmac:
http://lxr.free-electrons.com/source/drivers/staging/brcm80211/brcmsmac/wlc_bmac.c?v=3.0#L660
Hauke
Quoted 48 lines
---
I managed to find "devid" on every common SPROM rev:
pci/1/1/sromrev=2
pci/1/1/devid=0x4318pci/1/1/sromrev=4
pci/1/1/devid=0x4329pci/1/1/sromrev=8
pci/1/1/devid=0x432dpci/1/1/sromrev=9
pci/1/1/devid=0x4332pci/1/1/sromrev=11
pci/1/1/devid=0x43a1So it makes the most sense to always try to extract it.
--- arch/mips/bcm47xx/sprom.c | 1 + include/linux/ssb/ssb.h | 1 + 2 files changed, 2 insertions(+)arch/mips/bcm47xx/sprom.c +1
-0@@ -168,6 +168,7 @@ static void nvram_read_alpha2(const char *prefix, const char *name,static void bcm47xx_fill_sprom_r1234589 (struct ssb_sprom *sprom,const char *prefix,bool fallback) { +nvram_read_u16 (prefix,NULL ,"devid" , &sprom->dev_id,0 , fallback);nvram_read_u8 (prefix,NULL ,"ledbh0" , &sprom->gpio0,0xff , fallback);nvram_read_u8 (prefix,NULL ,"ledbh1" , &sprom->gpio1,0xff , fallback);nvram_read_u8 (prefix,NULL ,"ledbh2" , &sprom->gpio2,0xff , fallback);include/linux/ssb/ssb.h +1
-0@@ -33,6 +33,7 @@ struct ssb_sprom {u8 et1phyaddr;/* MII address for enet1 */ u8 et0mdcport;/* MDIO for enet0 */ u8 et1mdcport;/* MDIO for enet1 */ +u16 dev_id;/* Device ID overriding e.g. PCI ID */ u16 board_rev;/* Board revision number from SPROM. */ u16 board_num;/* Board number from SPROM. */ u16 board_type;/* Board type from SPROM. */
Rafał Miłecki
maintainerPATCH 1/1 ssb: sprom: add dev_id field for value overriding standard ID
Quoted 3 lines · Hauke Mehrtens
There is also a vendid var which should be used. See this code from brcmsmac:
http://lxr.free-electrons.com/source/drivers/staging/brcm80211/brcmsmac/wlc_bmac.c?v=3.0#L660
You're right, but is this used anywhere?
I can't reliably follow brcmsmac code, it copies the same data over and over. Simple grepping for "vendorid" shows copying from "vendorid" to "vendorid" of various structs, no real usage.
The one exception is "sha_params.vid = wlc_hw->vendorid;. However grepping with:
grep -R "\.vid" ./*
grep -R "\->vid" ./*
doesn't reveal any usage neither.
Seems like a dead code.