From: Alessio Ferri <alessio.ferri@mythread.it>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: linux-wireless@vger.kernel.org, linux-mips@vger.kernel.org
Subject: [PATCH RFC 0/2] bcma: support for SHIM-attached SoC backplane (BCM6362)
Date: Mon, 18 May 2026 13:35:33 +0200 [thread overview]
Message-ID: <3e236bf0-5269-4631-8e56-1bc199c2f643@mythread.it> (raw)
This RFC introduces the minimal infrastructure in bcma to support
SoCs that publish a SHIM-style mini-EROM: a backplane on a big-
endian peripheral bus where ChipCommon, the IEEE 802.11 core and
BCMA_CORE_SHIM all report NMW=NSW=0 because clock and reset
gating happens in the SHIM's per-core Control register rather
than in per-core DMP wrappers.
The two patches:
1/2 bcma: host_soc: support big-endian SoC backplane with
wrapper-less core synthesis
2/2 bcma: scan: allow SHIM-style mini-EROM wrapper-less cores
These two are infrastructure-only and don't interfare with
existing SoC: the default brcm,bus-axi compatible
keeps the existing behaviour, and the new code paths gate on
bus->big_endian and bus->shim_attached, both populated only
when DT compatible is one of the new SHIM-quirks ones
(brcm,bcm6362-bus-axi, brcm,bcm63268-bus-axi). I didn't
include the DT bindings YAML for those new compatibles
from this RFC - the binding design depends on the feedback.
Context: this builds on an earlier design question to the list
that did not draw a response:
https://lore.kernel.org/linux-wireless/CAHDv23WJLBEp3ETscVT4Z6E5PQfzTDcofxbZ6jAezZNYde7C0w@mail.gmail.com/
The companion b43 series for the same hardware (BCM6362 single-
die N-PHY rev 8 + radio 2057 rev 8) is in review here:
https://lore.kernel.org/linux-wireless/4581a48e-a6e4-46b1-853f-16db445d6890@mythread.it/
That b43 series stands on its own (b43 dispatcher gaps for a
PHY+radio combination already partially supported in tree).
This bcma series creates the conditions for b43 to
bind to a BCM6362 d11 core, but does not change anything for any
other b43 user.
Open design questions:
1. DT bindings for the new compatible strings. I added
"brcm,bcm6362-bus-axi" and "brcm,bcm63268-bus-axi" as new
compatibles alongside the existing "brcm,bus-axi", each with
its own quirks data block. Is it ok?
2. SHIM peephole base address. The brcm-shim quirks block
hard-codes shim_base = 0x10007000, which is the address
used by both BCM6362 and BCM63268 per the OEM SoC map
headers. I left the hard-coded value in place for the
RFC since i think it is fixed, but i'm ok to move it
to DT if asked.
3. Accessor set duplication. The BE variants in patch 1/2
(read16_be / read32_be / write16_be / write32_be /
aread32_be / awrite32_be) are direct duplicates of the
existing helpers with the underlying ioread/iowrite calls
swapped.
4. The allow-list extension in patch 2/2 (CHIPCOMMON, 80211,
SHIM) is gated on bus->shim_attached at the point of the
check.
If this design is acceptable in principle, the follow-up work
that depends on it is:
- DT bindings YAML for the new compatibles;
- A SoC-side wlan-shim platform driver to take the BCM6362
SHIM out of reset before bcma scans it (currently handled by
an out-of-tree driver during my bring-up; will upstream);
- A SPROM fallback driver that registers via
bcma_arch_register_fallback_sprom(), BCM6362 is spromless
- DT nodes for BCM6362 and BCM63268-class boards under
arch/mips/boot/dts/brcm/.
Tested on a D-Link DSL-3580L (BCM6362 SoC, single-die N-PHY rev
8 + radio 2057 rev 8). With patches 1-2 applied plus the
out-of-tree wlan-shim driver and SPROM fallback, bcma scan
enumerates the three SHIM-attached cores, b43 binds to the
802.11 core, and the d11 reaches firmware load and PSM run-up.
If asked, i can provide the full dmesg to verify working status.
I also own a NetGear D4220 and some other broadcom routers
that i plan to bring up after the BCM6362, they are BCM63168
and BCM63268.
The shim_base in quirks block already covers BCM63268 per the
OEM SoC map headers, and i expect the same SHIM-attached
backplane shape for the BCM63168.
I plan to reuse this infrastructure for their bring up.
Alessio Ferri (2):
bcma: host_soc: support big-endian SoC backplane with wrapper-less
core synthesis
bcma: scan: allow SHIM-style mini-EROM wrapper-less cores
drivers/bcma/host_soc.c | 243 +++++++++++++++++++++++++++++++++++++-
drivers/bcma/scan.c | 19 ++-
include/linux/bcma/bcma.h | 10 ++
3 files changed, 269 insertions(+), 3 deletions(-)
--
2.43.0
next reply other threads:[~2026-05-18 11:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 11:35 Alessio Ferri [this message]
2026-05-18 11:39 ` [PATCH RFC 1/2] bcma: host_soc: support quirked big-endian SoC backplane Alessio Ferri
2026-05-18 11:41 ` [PATCH RFC 2/2] bcma: scan: allow SHIM-style mini-EROM wrapper-less Alessio Ferri
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=3e236bf0-5269-4631-8e56-1bc199c2f643@mythread.it \
--to=alessio.ferri@mythread.it \
--cc=linux-mips@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=zajec5@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox