kernel.git/drivers/ssb/pci.c, branch linux-3.8.y

bcma/ssb: parse new attributes from sprom

2012-05-16T16:45:22Z

These newly added attributes are used by brcmsmac. Now bcma should parse all attributes used by brcmsmac out of the sprom. Signed-off-by: Hauke Mehrtens Tested-by: Arend van Spriel Signed-off-by: John W. Linville

ssb: fill board_rev attribute from sprom

2012-05-16T16:45:21Z

This attribute is now used in b43 driver and should be filled for all sprom versions. Signed-off-by: Hauke Mehrtens Signed-off-by: John W. Linville

ssb/bcma: fill attribute alpha2 from sprom

2012-05-16T16:45:21Z

The attribute country_code and alpha2 are two different attributes in the sprom. country_code contains some code in an 8 bit coding and alpha2 contains two chars with the country code. The attributes where read out wrongly in the past and country_code is only available on sprom version 1. Signed-off-by: Hauke Mehrtens Tested-by: Arend van Spriel Signed-off-by: John W. Linville

ssb: remove rev from boardinfo

2012-05-16T16:45:20Z

Previously the rev contained the revision read from the pci config space and was used as board_rev in the wireless drivers. This is wrong the board_rev is only fetched from the sprom accordingly to the open source part of the Broadcom SDK and brcmsmac. This patch removes the rev from the boardinfo structure and uses the board_rev attribute from sprom instead. This attribute is filled by PCI, PCMCIA, SDIO and SoC code. Signed-off-by: Hauke Mehrtens Tested-by: Arend van Spriel Signed-off-by: John W. Linville

ssb: remove 5GHz antenna gain from sprom

2012-03-05T20:20:49Z

There is no 2.4 GHz or 5GHz antenna gain stored in sprom. The sprom just stores the gain values for antenna 1 and 2 or 1 to 4 for more recent sprom versions. On old devices antenna 2 was used for 5 GHz wifi. Signed-off-by: Hauke Mehrtens Signed-off-by: John W. Linville

ssb: SPROM: extract each core power info

2012-01-24T19:06:04Z

We already extract some basic info but it's incomplete, reads info about the first core only. Used data structure doesn't allow easy adding of more cores. This patch adds new struct and array for storing power info. The plan is to: switch all extractors (including the ones using NVRAM) to new struct, switch drivers, then deprecate and finally drop old SSB fields. Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville

ssb: extract FEM info from SPROM

2011-12-13T20:30:49Z

Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial

2011-07-25T20:56:39Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (43 commits) fs: Merge split strings treewide: fix potentially dangerous trailing ';' in #defined values/expressions uwb: Fix misspelling of neighbourhood in comment net, netfilter: Remove redundant goto in ebt_ulog_packet trivial: don't touch files that are removed in the staging tree lib/vsprintf: replace link to Draft by final RFC number doc: Kconfig: `to be' -> `be' doc: Kconfig: Typo: square -> squared doc: Konfig: Documentation/power/{pm => apm-acpi}.txt drivers/net: static should be at beginning of declaration drivers/media: static should be at beginning of declaration drivers/i2c: static should be at beginning of declaration XTENSA: static should be at beginning of declaration SH: static should be at beginning of declaration MIPS: static should be at beginning of declaration ARM: static should be at beginning of declaration rcu: treewide: Do not use rcu_read_lock_held when calling rcu_dereference_check Update my e-mail address PCIe ASPM: forcedly -> forcibly gma500: push through device driver tree ... Fix up trivial conflicts: - arch/arm/mach-ep93xx/dma-m2p.c (deleted) - drivers/gpio/gpio-ep93xx.c (renamed and context nearby) - drivers/net/r8169.c (just context changes)

Update my e-mail address

2011-07-07T13:18:01Z

Signed-off-by: Michael Buesch Signed-off-by: Jiri Kosina

ssb: use pci_dev->subsystem_{vendor,device}

2011-07-05T19:32:54Z

The SSB code reads PCI subsystem IDs from the PCI configuration registers while they are already stored by the PCI subsystem in the 'subsystem_{vendor|device}' fields of 'struct pci_dev'... Signed-off-by: Sergei Shtylyov Signed-off-by: John W. Linville