All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: b43-dev@lists.infradead.org
Subject: Extracting (boardvendor and) boardtype
Date: Tue, 19 Mar 2013 10:48:21 +0100	[thread overview]
Message-ID: <CACna6rwPvUW89k81kkARbqkN4BgoTwWkmfU234b9Cj5R1-WVsg@mail.gmail.com> (raw)

It seems Broadcom does some per-card decisions
(workarounds/hacks/adjustments) using "boardtype" value. We have few
values defined:
#define SSB_BOARD_BCM94306MP	0x0418
#define SSB_BOARD_BCM4309G	0x0421
#define SSB_BOARD_BCM4306CB	0x0417
#define SSB_BOARD_BCM4309MP	0x040C
#define SSB_BOARD_MP4318	0x044A
#define SSB_BOARD_BU4306	0x0416
#define SSB_BOARD_BU4309	0x040A
but bcmdevs.h actually contains tons of them.

To see how we currently extract it, please see ssb_pci_get_boardinfo:
bi->vendor = bus->host_pci->subsystem_vendor;
bi->type = bus->host_pci->subsystem_device;

or bcma_host_pci_probe:
bus->boardinfo.vendor = bus->host_pci->subsystem_vendor;
bus->boardinfo.type = bus->host_pci->subsystem_device;

However I suspect maybe we should extract board_type from SPROM [0] offset 0x4.

I tried to understand how Broadcom handles that but can't follow that.
First of all they seem to have abstration to the abstration of
abstration. They keep boardtype in 3 or more structs copying them all
around. I suspect they extract board_type in si_nvram_process (which
is called always, not just on SOCs where we actually have NVRAM).

The easy part is that they preference about source of "boardtype" value is:
1) si_getdevpathintvar(..., "boardtype")
2) getintvar(..., "boardtype")
3) read(PCI_CFG_SVID) >> 16

I don't understand how getdevpathintvar / getintvar works. The
forwardtrace seems to be:
si_getdevpathintvar
getintvar
PHY_GETVAR
phy_getvar

The problem is that phy_getvar iterates over pi->vars. I have no idea
what is this set to. This variable is set in about 20 places in about
3 different structs. I don't know... does it have any relation to the
pci_sromvars?

Does anyone understand this? Better than me hopefully? Should we
extract board_type from SPROM and use subsystem id only as a fallback?

[0] http://bcm-v4.sipsolutions.net/SPROM

-- 
Rafa?

             reply	other threads:[~2013-03-19  9:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19  9:48 Rafał Miłecki [this message]
2013-03-19 10:19 ` Extracting (boardvendor and) boardtype Arend van Spriel
2013-03-19 10:36   ` Rafał Miłecki
2013-03-19 11:03     ` Jonas Gorski
2013-03-19 11:18       ` Rafał Miłecki
2013-03-19 11:22         ` Arend van Spriel
2013-03-19 11:37           ` Rafał Miłecki
2013-03-19 11:45             ` Arend van Spriel
2013-03-19 11:47               ` Arend van Spriel
2013-03-19 11:52               ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACna6rwPvUW89k81kkARbqkN4BgoTwWkmfU234b9Cj5R1-WVsg@mail.gmail.com \
    --to=zajec5@gmail.com \
    --cc=b43-dev@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.