<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/arm64/boot/dts/broadcom/bcmbca, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>arm64: dts: broadcom: bcm4906-netgear-r8000p: Drop unnecessary "ranges" in partition node</title>
<updated>2026-01-16T21:48:58+00:00</updated>
<author>
<name>Rob Herring (Arm)</name>
<email>robh@kernel.org</email>
</author>
<published>2026-01-08T23:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a95e1d848972dd7d5cbabd62921b9b85501d891e'/>
<id>a95e1d848972dd7d5cbabd62921b9b85501d891e</id>
<content type='text'>
"ranges" is only valid for MMIO addresses as it is used for translating
addresses to CPU address. Even if a partial translation was supported,
the DT is incorrect here as the nvmem-layout node would also need
"ranges". So drop "ranges" and the associated cell size properties.

Signed-off-by: Rob Herring (Arm) &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20260108231558.1422454-2-robh@kernel.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
"ranges" is only valid for MMIO addresses as it is used for translating
addresses to CPU address. Even if a partial translation was supported,
the DT is incorrect here as the nvmem-layout node would also need
"ranges". So drop "ranges" and the associated cell size properties.

Signed-off-by: Rob Herring (Arm) &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20260108231558.1422454-2-robh@kernel.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM64: dts: bcm63158: Add BCMBCA peripherals</title>
<updated>2025-06-09T17:10:29+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2025-05-12T12:05:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=16d27d638f3bb389f243fa469db9dd2a0aa72d83'/>
<id>16d27d638f3bb389f243fa469db9dd2a0aa72d83</id>
<content type='text'>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM63158 based on the vendor files 63158_map_part.h
and 63158_intr.h from the "bcmopen-consumer" code drop.

The DTSI file has clearly been authored for the B0 revision of
the SoC: there is an earlier A0 version, but this has
the UARTs in the legacy PERF memory space, while the B0
has opened a new peripheral window at 0xff812000 for the
three UARTs. It also has a designated AHB peripheral area
at 0xff810000 where the DMA resides, the peripheral range
window fits these two peripheral groups.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-12-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM63158 based on the vendor files 63158_map_part.h
and 63158_intr.h from the "bcmopen-consumer" code drop.

The DTSI file has clearly been authored for the B0 revision of
the SoC: there is an earlier A0 version, but this has
the UARTs in the legacy PERF memory space, while the B0
has opened a new peripheral window at 0xff812000 for the
three UARTs. It also has a designated AHB peripheral area
at 0xff810000 where the DMA resides, the peripheral range
window fits these two peripheral groups.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-12-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM64: dts: bcm6858: Add BCMBCA peripherals</title>
<updated>2025-06-09T17:10:29+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2025-05-12T12:05:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d84e3949940baa3105098f74449ff3c97b2d85e1'/>
<id>d84e3949940baa3105098f74449ff3c97b2d85e1</id>
<content type='text'>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000. Extend the peripheral window range
to 0x400000 and add the DMA controller at offset 0x59000.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM6858 based on the vendor files 6858_map_part.h
and 6858_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-11-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000. Extend the peripheral window range
to 0x400000 and add the DMA controller at offset 0x59000.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM6858 based on the vendor files 6858_map_part.h
and 6858_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-11-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM64: dts: bcm6856: Add BCMBCA peripherals</title>
<updated>2025-06-09T17:10:29+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2025-05-12T12:05:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c0126c440963a5b47a5376a8a0a9f4a270cbf82f'/>
<id>c0126c440963a5b47a5376a8a0a9f4a270cbf82f</id>
<content type='text'>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000. Extend the BCM6856 the PERF window
to 0x400000 and add the DMA block at offset 0x59000.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM6856 based on the vendor files 6856_map_part.h
and 6856_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-10-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000. Extend the BCM6856 the PERF window
to 0x400000 and add the DMA block at offset 0x59000.

Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA
blocks for the BCM6856 based on the vendor files 6856_map_part.h
and 6856_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 256 possible GPIOs due to having 8
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-10-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM64: dts: bcm4908: Add BCMBCA peripherals</title>
<updated>2025-06-09T17:10:29+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2025-05-12T12:05:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bbdccf0f4e8f3ab1f9939d7d1bea18647f9a6d9b'/>
<id>bbdccf0f4e8f3ab1f9939d7d1bea18647f9a6d9b</id>
<content type='text'>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000, we extend the peripheral bus
range to 0x400000 to cover this area.

Add the watchdog, remaining GPIO blocks, RNG, and DMA blocks
for the BCM4908 based on the vendor files 4908_map_part.h
and 4908_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 320 possible GPIOs due to having 10
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-9-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the BCMBCA SoCs share a set of peripherals at 0xff800000,
albeit at slightly varying memory locations on the bus and
with varying IRQ assignments. ARM64 SoCs have additional
peripherals at 0xff858000, we extend the peripheral bus
range to 0x400000 to cover this area.

Add the watchdog, remaining GPIO blocks, RNG, and DMA blocks
for the BCM4908 based on the vendor files 4908_map_part.h
and 4908_intr.h from the "bcmopen-consumer" code drop.

This SoC has up to 320 possible GPIOs due to having 10
registers with 32 GPIOs in each available.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: William Zhang &lt;william.zhang@broadcom.com&gt;
Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-9-86f97ab4326f@linaro.org
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: dts: bcm4908: nvmem-layout conversion</title>
<updated>2024-12-17T19:39:21+00:00</updated>
<author>
<name>Rosen Penev</name>
<email>rosenp@gmail.com</email>
</author>
<published>2024-12-03T23:36:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f5ce990af7cf9ced0b3459f3d9aed0a27a74d00c'/>
<id>f5ce990af7cf9ced0b3459f3d9aed0a27a74d00c</id>
<content type='text'>
nvmem-layout is a more flexible replacement for nvmem-cells.

Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Link: https://lore.kernel.org/r/20241203233632.184861-1-rosenp@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
nvmem-layout is a more flexible replacement for nvmem-cells.

Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Link: https://lore.kernel.org/r/20241203233632.184861-1-rosenp@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: dts: broadcom: bcmbca: bcm4908: Add DT for Zyxel EX3510-B</title>
<updated>2024-12-17T19:39:21+00:00</updated>
<author>
<name>Sam Edwards</name>
<email>cfsworks@gmail.com</email>
</author>
<published>2024-10-09T21:54:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5c1ae7729e7bf3c7dc4d36cae0133f04fd232747'/>
<id>5c1ae7729e7bf3c7dc4d36cae0133f04fd232747</id>
<content type='text'>
Zyxel EX3510-B is a WiFi 6 capable home gateway (family) based on the
BCM4906 SoC, with 512MiB of RAM and 512MiB of NAND flash. WiFi support
consists of a BCM6710 and a BCM6715 attached to separate PCIe buses.

Add an initial devicetree for this system, with support for:
- Onboard UART (per base dtsi)
- USB (2.0 only; superspeed devices are treated as high-speed due to an
    unknown cause)
- Both buttons (rear reset, front WPS)
- Almost all LEDs:
  - Power (red/green)
  - Internet (red/green)
  - WAN (green)
  - LAN (green; anode is connected to GPIO 13 so currently
      nonfunctioning)
  - USB (green)
  - WPS button (red/green)
  - Absent in DT: There are 2.4GHz/5.0GHz WiFi status LEDs connected to
      the WiFi chips instead of the SoC.
- NAND flash
- Embedded Ethernet switch
- Factory-programmed Ethernet MAC address

WiFi cannot be enabled at this time due to Linux lacking drivers for
both the PCIe controllers and the PCIe WiFi peripherals.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241009215454.1449508-3-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Zyxel EX3510-B is a WiFi 6 capable home gateway (family) based on the
BCM4906 SoC, with 512MiB of RAM and 512MiB of NAND flash. WiFi support
consists of a BCM6710 and a BCM6715 attached to separate PCIe buses.

Add an initial devicetree for this system, with support for:
- Onboard UART (per base dtsi)
- USB (2.0 only; superspeed devices are treated as high-speed due to an
    unknown cause)
- Both buttons (rear reset, front WPS)
- Almost all LEDs:
  - Power (red/green)
  - Internet (red/green)
  - WAN (green)
  - LAN (green; anode is connected to GPIO 13 so currently
      nonfunctioning)
  - USB (green)
  - WPS button (red/green)
  - Absent in DT: There are 2.4GHz/5.0GHz WiFi status LEDs connected to
      the WiFi chips instead of the SoC.
- NAND flash
- Embedded Ethernet switch
- Factory-programmed Ethernet MAC address

WiFi cannot be enabled at this time due to Linux lacking drivers for
both the PCIe controllers and the PCIe WiFi peripherals.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241009215454.1449508-3-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: dts: broadcom: bcmbca: bcm4908: Protect cpu-release-addr</title>
<updated>2024-12-17T19:39:21+00:00</updated>
<author>
<name>Sam Edwards</name>
<email>cfsworks@gmail.com</email>
</author>
<published>2024-10-05T05:01:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=95d56dfaa0dd9352462c9b2636549f2faee033a0'/>
<id>95d56dfaa0dd9352462c9b2636549f2faee033a0</id>
<content type='text'>
The `cpu-release-addr` property is relevant only when the "spin-table"
enable method is used. It is the physical address where the bootloader
expects Linux to write the secondary CPU entry point's physical address.
On this platform, only the CFE bootloader uses this method: U-Boot uses
PSCI instead.

CFE actually walks the FDT to learn this address, so we're free to put
it wherever we want. We only need to make sure that it goes in a
reserved-memory block so that writing to it during early boot does not
risk conflicting with an unrelated memory allocation: this was not done.

Since the previous patch reserved the first page of memory for CFE's
secondary-CPU init stub, which is actually much smaller than a page,
just put this address at the end of that page and it shall be so
protected.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241005050155.61103-3-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The `cpu-release-addr` property is relevant only when the "spin-table"
enable method is used. It is the physical address where the bootloader
expects Linux to write the secondary CPU entry point's physical address.
On this platform, only the CFE bootloader uses this method: U-Boot uses
PSCI instead.

CFE actually walks the FDT to learn this address, so we're free to put
it wherever we want. We only need to make sure that it goes in a
reserved-memory block so that writing to it during early boot does not
risk conflicting with an unrelated memory allocation: this was not done.

Since the previous patch reserved the first page of memory for CFE's
secondary-CPU init stub, which is actually much smaller than a page,
just put this address at the end of that page and it shall be so
protected.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241005050155.61103-3-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: dts: broadcom: bcmbca: bcm4908: Reserve CFE stub area</title>
<updated>2024-12-17T19:39:20+00:00</updated>
<author>
<name>Sam Edwards</name>
<email>cfsworks@gmail.com</email>
</author>
<published>2024-10-05T05:01:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cef313931d6424982941e1cb40b89daba68663ff'/>
<id>cef313931d6424982941e1cb40b89daba68663ff</id>
<content type='text'>
The CFE bootloader places a stub program in the first page of physical
memory to hold the secondary CPUs until the boot CPU writes the release
address, but does not splice a /reserved-memory node into the FDT to
protect it. If Linux overwrites this program before execution reaches
smp_prepare_cpus(), the secondary CPUs may become inaccessible.

This is only a problem with CFE, and then only until the secondary CPUs
are brought online. Ideally, there would be some hypothetical mechanism
we could use to indicate that this area of memory is sensitive only
during boot. But as there is none, and since it is such a small amount
of memory, it is easiest to reserve it unconditionally.

Therefore, add a /reserved-memory node to bcm4908.dtsi to protect the
first 4KiB of physical memory.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241005050155.61103-2-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The CFE bootloader places a stub program in the first page of physical
memory to hold the secondary CPUs until the boot CPU writes the release
address, but does not splice a /reserved-memory node into the FDT to
protect it. If Linux overwrites this program before execution reaches
smp_prepare_cpus(), the secondary CPUs may become inaccessible.

This is only a problem with CFE, and then only until the secondary CPUs
are brought online. Ideally, there would be some hypothetical mechanism
we could use to indicate that this area of memory is sensitive only
during boot. But as there is none, and since it is such a small amount
of memory, it is easiest to reserve it unconditionally.

Therefore, add a /reserved-memory node to bcm4908.dtsi to protect the
first 4KiB of physical memory.

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Link: https://lore.kernel.org/r/20241005050155.61103-2-CFSworks@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: dts: broadcom: bcmbca: bcm4908: set brcm,wp-not-connected</title>
<updated>2024-04-02T20:41:01+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2024-03-28T09:37:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=328ad44c5290cc4575be5f0dc457c75bb71015d4'/>
<id>328ad44c5290cc4575be5f0dc457c75bb71015d4</id>
<content type='text'>
Every described BCM4908 board has WP pin not connected. This caused
problems for drivers since day 0 but there was no property to describe
that properly. Projects like OpenWrt were modifying Linux driver to deal
with it.

It's not clear if that is hardware limitation or just reference design
being copied over and over but this applies to all known / supported
BCM4908 boards. Handle it by marking WP as not connected by default.

Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files")
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Link: https://lore.kernel.org/r/20240328093710.28206-1-zajec5@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Every described BCM4908 board has WP pin not connected. This caused
problems for drivers since day 0 but there was no property to describe
that properly. Projects like OpenWrt were modifying Linux driver to deal
with it.

It's not clear if that is hardware limitation or just reference design
being copied over and over but this applies to all known / supported
BCM4908 boards. Handle it by marking WP as not connected by default.

Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files")
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Link: https://lore.kernel.org/r/20240328093710.28206-1-zajec5@gmail.com
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
