From: Alessio Ferri <alessio.ferri.3012@gmail.com>
To: "zajec5@gmail.com" <zajec5@gmail.com>
Cc: linux-wireless@vger.kernel.org, linux-mips@vger.kernel.org
Subject: bcma: endianness problem chipcommon access soc bcm6362
Date: Tue, 12 May 2026 11:41:08 +0200 [thread overview]
Message-ID: <CAHDv23WJLBEp3ETscVT4Z6E5PQfzTDcofxbZ6jAezZNYde7C0w@mail.gmail.com> (raw)
Hi Rafał,
Sorry for the multiple emails, having trouble sending plain text with gmail.
I am working on an OpenWrt port for the D-Link DSL-3580L (BCM6362 SoC,
big-endian MIPS host, 4352 variant mini pcie for ac).
project here https://github.com/aleferri/openwrt-dsl3580l
While testing I ran into an endianness assumption inside bcma.
It uses readl()/writel() everywhere, which uses "device little-endian"
convention
they go through le32_to_cpu(), so on a BE host they swap bytes.
But on this SoC the AXI bus is big-endian, so readl() swaps them and
bus scanning sees garbage.
Evidence from a small diagnostic ko module that i asked claude to
create, dumps the SHIM at 0x10007000 and the AXI chipcommon at
0x10004000 side by side:
axi @0x10004000 +0x00 CC_ID readl=0x62630122 ioread32be=0x22016362
shim @0x10007000 +0x18 (CIA) readl=0x0100f84b ioread32be=0x4bf80001
shim @0x10007000 +0x20 (ADDR) readl=0x05400010 ioread32be=0x10004005
shim @0x10007000 +0x2c (ADDR) readl=0x05500010 ioread32be=0x10005005
shim @0x10007000 +0x38 (ADDR) readl=0x05700010 ioread32be=0x10007005
shim @0x10007000 +0x3c (EOT) readl=0x0f000000 ioread32be=0x0000000f
The BE column seems correct:
- chip id 0x6362 in CC_ID
- CIA entries with Broadcom vendor 0x4bf
- ADDR descriptors pointing back at the expected core bases
The readl() column is just the same words byte-swapped, which matches
what I observe at runtime: bcma_bus_scan() fail to scan with -88
The relevant call sites are:
- drivers/bcma/scan.c
bcma_erom_get_ent() -- readl() directly; this is the function
where bus scanning breaks immediately
bcma_scan_read32() -- readl() directly
- drivers/bcma/host_soc.c
all read*/write* ops use readb/readw/readl / writeb/writew/writel
I don't know how to disambinguate at runtime as scan.c reads the data
before the chip id is known, so a runtime quirk based on the chip id
is not workable.
Maybe if the endianness is known at bind time with a standard property
in the DT the bug can be fixed while leaving the default as is
Happy to test patches on the device, or i'll send an RFC myself if
you'd rather review some code.
Thanks,
Alessio Ferri
reply other threads:[~2026-05-12 9:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAHDv23WJLBEp3ETscVT4Z6E5PQfzTDcofxbZ6jAezZNYde7C0w@mail.gmail.com \
--to=alessio.ferri.3012@gmail.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).