[BPI-R4] mtk_soc_eth should selects automatically CONFIG_SRAM

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

Hi all,

I’ve notice starting with Linux Kernel 6.17 a new patch into mtk_soc_eth using SRAM. But if you complie the kernel without CONFIG_SRAM, everything is compiled but when you boot the kernel you get this error:

[    0.000000] psci: probing for conduit method from DT.
[    1.847587] mtk_soc_eth 15100000.ethernet: Could not get SRAM pool
[    1.857263] mtk_soc_eth 15100000.ethernet: probe with driver mtk_soc_eth failed with error -22

Looking into arch/arm64/boot/dts for mt7988a and in arch/arm64/configs I saw new dependency of SRAM. But when you select the driver in Kernel sources, it doesn’t automatically selects CONFIG_SRAM.

There is a reason why?

2

yes previous versions used a second reg entry for sram and upstreaming process required using dedicated sram node and driver

1 Like
3

Do you want to create a patch for Kconfig to add automatic selection of CONFIG_SRAM and submit to your kernel git repository?

4

Not all socs supported by mtk ethernet driver need this driver.

5

So if understood correctly multiple SoC are using the same driver but just some of them needs SRAM driver. But this driver affects somehow the performance or anything else on other SoC if is enabled by default? From what I saw Linux Kernel doesn’t have a specific selection of the SoC, just generic Mediatek.

6

Soc selection is done by compatible in used devicetree. Some socs have no dedicated sram (should bind on specific node and we did some changes for other socs…at least mt7986). Not sure if this is completely save to enable SRAM driver to all socs

1 Like
7

OK, than make sens. Because there is no way to know which SoC is selected, because is just a generic Mediatek SoC, then is difficult to select SRAM when mtk_soc_eth is selected. Unfortunately this can lead to some issues if somebody doesn’t know this small detail.

8

Would CONFIG_SRAM=y break something if a kernel is run with this option on a soc that does not use it?

It should not, right?

9

It should not as sram depends on MTK_SRAM capability which should be only set for filogic SoCs (mt798x). But sending patch to mainline requires intensive testing on all targets.

10

For myself I find it easier to maintain only 1 defconfig for all the bpi-mtk boards. The downside is that the kernel is a tiny bit larger then necessary for that specific board, but the difference is small. For me this outweighs the hassle if multiple defcoonfigs.

So I just have this config set to yes for all boards.