enabled fiq debug & fix wifi/bt issue & fix gmac issue & enabled CONFIG_CPU_RK3308#578
Draft
chenxmqqqq wants to merge 11 commits into
Draft
enabled fiq debug & fix wifi/bt issue & fix gmac issue & enabled CONFIG_CPU_RK3308#578chenxmqqqq wants to merge 11 commits into
chenxmqqqq wants to merge 11 commits into
Conversation
| GPIOD_OUT_HIGH); | ||
| if (IS_ERR(reset_gpio)) | ||
| return PTR_ERR(reset_gpio); | ||
| if (IS_ERR_OR_NULL(reset_gpio)) |
Author
There was a problem hiding this comment.
@RadxaYuntian 天哥，明天重新整理下所有提交，stephen 说让我找找linux-6.1-stan-rkr7的提交，最好 cherry-pick
Member
There was a problem hiding this comment.
如果没有定义snps,reset的话devm_gpiod_get_optional会返回NULL，IS_ERR不会认定为错误。这是符合语义的
现在的修改会导致这个GPIO必须被定义，这是不符合预期的
Author
There was a problem hiding this comment.
撤回了关于 gmac reset-gpio 的提交，编译测试后未见报错。
Signed-off-by: Xinming Chen <chenxinming@radxa.com>
Remove chosen node, disable uart0, and enable fiq_debugger on serial0 to use it as the debug console. Signed-off-by: Xinming Chen <chenxinming@radxa.com>
Signed-off-by: Xinming Chen <chenxinming@radxa.com>
Signed-off-by: Xinming Chen <chenxinming@radxa.com>
RadxaStephen
marked this pull request as draft
July 14, 2026 10:00
Add a regulator-fixed for bt_reg_on to keep the RTL8723DS BT chip powered before the 8250 UART driver probes, preventing UART RX line floating which floods the log with break/frame errors. Remove the now-unused bt_reg_on pinctrl and drop enable-gpios from the bluetooth node to avoid GPIO conflict with the regulator. Signed-off-by: Xinming Chen <chenxinming@radxa.com>
[ Upstream commit 66600fa ] In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a Reported-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Fixes: f748be5 ("stmmac: support new GMAC4") Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Hariprasad Kelam <hkelam@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241021061023.2162701-1-0x1207@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 25d7070 ] Commit a23aa04 ("net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls") introduced checks to prevent unbalanced enable and disable IRQ wake calls. However it only initialized the auxiliary variable on one of the paths, stmmac_request_irq_multi_msi(), missing the other, stmmac_request_irq_single(). Add the same initialization on stmmac_request_irq_single() to prevent "Unbalanced IRQ <x> wake disable" warnings from being printed the first time disable_irq_wake() is called on platforms that run on that code path. Fixes: a23aa04 ("net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241101-stmmac-unbalanced-wake-single-fix-v1-1-5952524c97f0@collabora.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d740654 ] Provide a devres variant of stmmac_probe_config_dt() that allows users to skip calling stmmac_remove_config_dt() at driver detach. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230623100417.93592-9-brgl@bgdev.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 2b6ffcd ("net: stmmac: restructure the error path of stmmac_probe_config_dt()") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f3c2caa ] Currently a MDIO bus is created if the devicetree description is either: 1. Not fixed-link 2. fixed-link but contains a MDIO bus as well The "1" case above isn't always accurate. If there's a phy-handle, it could be referencing a phy on another MDIO controller's bus[1]. In this case, where the MDIO bus is not described at all, currently stmmac will make a MDIO bus and scan its address space to discover phys (of which there are none). This process takes time scanning a bus that is known to be empty, delaying time to complete probe. There are also a lot of upstream devicetrees[2] that expect a MDIO bus to be created, scanned for phys, and the first one found connected to the MAC. This case can be inferred from the platform description by not having a phy-handle && not being fixed-link. This hits case "1" in the current driver's logic, and must be handled in any logic change here since it is a valid legacy dt-binding. Let's improve the logic to create a MDIO bus if either: - Devicetree contains a MDIO bus - !fixed-link && !phy-handle (legacy handling) This way the case where no MDIO bus should be made is handled, as well as retaining backwards compatibility with the valid cases. Below devicetree snippets can be found that explain some of the cases above more concretely. Here's[0] a devicetree example where the MAC is both fixed-link and driving a switch on MDIO (case "2" above). This needs a MDIO bus to be created: &fec1 { phy-mode = "rmii"; fixed-link { speed = <100>; full-duplex; }; mdio1: mdio { switch0: switch0@0 { compatible = "marvell,mv88e6190"; pinctrl-0 = <&pinctrl_gpio_switch0>; }; }; }; Here's[1] an example where there is no MDIO bus or fixed-link for the ethernet1 MAC, so no MDIO bus should be created since ethernet0 is the MDIO master for ethernet1's phy: ðernet0 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy0>; mdio { compatible = "snps,dwmac-mdio"; sgmii_phy0: phy@8 { compatible = "ethernet-phy-id0141.0dd4"; reg = <0x8>; device_type = "ethernet-phy"; }; sgmii_phy1: phy@a { compatible = "ethernet-phy-id0141.0dd4"; reg = <0xa>; device_type = "ethernet-phy"; }; }; }; ðernet1 { phy-mode = "sgmii"; phy-handle = <&sgmii_phy1>; }; Finally there's descriptions like this[2] which don't describe the MDIO bus but expect it to be created and the whole address space scanned for a phy since there's no phy-handle or fixed-link described: &gmac { phy-supply = <&vcc_lan>; phy-mode = "rmii"; snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>; snps,reset-active-low; snps,reset-delays-us = <0 10000 1000000>; }; [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164 Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Stable-dep-of: 2b6ffcd ("net: stmmac: restructure the error path of stmmac_probe_config_dt()") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2b6ffcd ] Current implementation of stmmac_probe_config_dt() does not release the OF node reference obtained by of_parse_phandle() in some error paths. The problem is that some error paths call stmmac_remove_config_dt() to clean up but others use and unwind ladder. These two types of error handling have not kept in sync and have been a recurring source of bugs. Re-write the error handling in stmmac_probe_config_dt() to use an unwind ladder. Consequently, stmmac_remove_config_dt() is not needed anymore, thus remove it. This bug was found by an experimental verification tool that I am developing. Fixes: 4838a54 ("net: stmmac: Fix wrapper drivers not detecting PHY") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://patch.msgid.link/20241219024119.2017012-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
chenxmqqqq
force-pushed
the
linux-6.1-stan-rkr5.1
branch
from
July 15, 2026 10:22
839b79b to
6dfbcf8
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
chenxmqqqq
force-pushed
the
linux-6.1-stan-rkr5.1
branch
from
July 16, 2026 09:48
6dfbcf8 to
2f5b143
Compare
The RTL8211F fixups use a broad PHY UID mask to support parts sold as RTL8211F that report different PHY IDs. This mask also matches the RTL8201F (0x001cc816), causing RTL8211F-specific LED and EEE register writes, including a software reset, to be applied to the wrong PHY. This results in periodic link renegotiation on the ROCK Pi S. Keep the broad RTL8211F match for compatibility, but skip both RTL8211F fixups when the detected PHY is an RTL8201F. Add a dedicated RTL8201F fixup that configures LED0 (yellow) for 100M link and LED1 (green) for activity. Use phy_modify_paged() in rtl8201_config_intr() so updating interrupt bits [13:11] preserves the customized-LED enable bit in page 7 register 19. Tested on RK3308 ROCK Pi S with RTL8201F at 100 Mbps. Signed-off-by: Xinming Chen <chenxinming@radxa.com>
chenxmqqqq
force-pushed
the
linux-6.1-stan-rkr5.1
branch
from
July 16, 2026 11:30
2f5b143 to
da11183
Compare
Author
|
由于 RTL8211F IC 至少有2种 PHY ID，遂改动了判断条件，当 PHYID 是 RTL8201F 不再执行phy_rtl8211f_led_fixup 和 phy_rtl8211f_eee_fixup。 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.