[PATCH] Revert "swconfig: fix Broadcom b53 support"
From: Rafał Miłecki
This reverts commit 8f9cd1af0f9c325a902dbd0e79e12015372e6bb0.
That commit was meant to add a single EXPORT_SYMBOL_GPL() but it
actually also added few .of_match_table-s. One commit should handle one
thing and should not introduce unrelated changes.
Regarding actual changes:
1. EXPORT_SYMBOL_GPL is not required as we don't build swconfig drivers
as modules.
2. PHY drivers must not have .of_match_table. That is allowed for MDIO
drivers. This could work for some time (although is didn't for me on
bcm53xx) but does not with kernel 5.10. It causes a soft lockup and
upstream developers confirmed it's an unsupported design.
Link:
https://lore.kernel.org/netdev/2b1dc053-8c9a-e3e4-b450-eecdfca3f...@gmail.com/t/#mf80e472f35ee23f7a75cbf5b1e101a17ab3a64a3
Cc: Tobias Schramm
Signed-off-by: Rafał Miłecki
---
.../files/drivers/net/phy/b53/b53_mdio.c | 32 ---
.../generic/files/drivers/net/phy/swconfig.c | 1 -
2 files changed, 33 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
index 98cdbffe73..6ec23a49a3 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c
@@ -361,26 +361,6 @@ static int b53_phy_read_status(struct phy_device *phydev)
return 0;
}
-static const struct of_device_id b53_of_match_1[] = {
- { .compatible = "brcm,bcm5325" },
- { .compatible = "brcm,bcm5395" },
- { .compatible = "brcm,bcm5397" },
- { .compatible = "brcm,bcm5398" },
- { /* sentinel */ },
-};
-
-static const struct of_device_id b53_of_match_2[] = {
- { .compatible = "brcm,bcm53115" },
- { .compatible = "brcm,bcm53125" },
- { .compatible = "brcm,bcm53128" },
- { /* sentinel */ },
-};
-
-static const struct of_device_id b53_of_match_3[] = {
- { .compatible = "brcm,bcm5365" },
- { /* sentinel */ },
-};
-
/* BCM5325, BCM539x */
static struct phy_driver b53_phy_driver_id1 = {
.phy_id = 0x0143bc00,
@@ -392,10 +372,6 @@ static struct phy_driver b53_phy_driver_id1 = {
.config_aneg= b53_phy_config_aneg,
.config_init= b53_phy_config_init,
.read_status= b53_phy_read_status,
- .mdiodrv.driver = {
- .name = "bcm539x",
- .of_match_table = b53_of_match_1,
- },
};
/* BCM53125, BCM53128 */
@@ -409,10 +385,6 @@ static struct phy_driver b53_phy_driver_id2 = {
.config_aneg= b53_phy_config_aneg,
.config_init= b53_phy_config_init,
.read_status= b53_phy_read_status,
- .mdiodrv.driver = {
- .name = "bcm531xx",
- .of_match_table = b53_of_match_2,
- },
};
/* BCM5365 */
@@ -426,10 +398,6 @@ static struct phy_driver b53_phy_driver_id3 = {
.config_aneg= b53_phy_config_aneg,
.config_init= b53_phy_config_init,
.read_status= b53_phy_read_status,
- .mdiodrv.driver = {
- .name = "bcm5365",
- .of_match_table = b53_of_match_3,
- },
};
int __init b53_phy_driver_register(void)
diff --git a/target/linux/generic/files/drivers/net/phy/swconfig.c
b/target/linux/generic/files/drivers/net/phy/swconfig.c
index a734e57608..f506daaf91 100644
--- a/target/linux/generic/files/drivers/net/phy/swconfig.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig.c
@@ -1222,7 +1222,6 @@ switch_generic_set_link(struct switch_dev *dev, int port,
return 0;
}
-EXPORT_SYMBOL_GPL(switch_generic_set_link);
static int __init
swconfig_init(void)
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: switch to kernel 5.10
Hi Adrian, On Wed, Sep 29, 2021 at 1:34 PM Stijn Segers wrote: > > Hi Ilya, > > Op maandag 27 september 2021 om 19u11 schreef Ilya Lipnitskiy > : > > Hi Stijn, > > > >> >> >all mt7620 JBOOT devices will be broken. > > ... > >> $ grep \ KERNEL_SIZE image/mt7620.mk|wc -l > >> 1 > > That one is under "define Device/amit_jboot", searching for that > > yields: > > $ git grep "\$(Device/amit_jboot)" | wc -l > > 8 > > > > So all JBOOT devices look covered. > > > > Which mt76x8 device(s) is missing a KERNEL_SIZE or fails to boot with > > 5.10? > > The single mt76x8 device I have works, my reasoning was that maybe > those needed further checks because most (all?) of them are small flash > devices. That worry was triggered by the odd report of people bricking > their device by flashing images with too big a kernel. That being said, > that even seems to happen to beefy modern hardware like the mvebu > platform, so... I may have been overly cautious (and worried). > > By now it's clear I am not wholly familiar with the finer points, so > I'm happy with the answers I got (and what I learned) and I'll leave it > at that. I think this patch can now be merged in. We can fix broken or devices with small flash incrementally, right? > > Thank you! > > Stijn > > > > > Ilya > > Thanks! Ilya ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 2/6] at91: enable specific sam9x kernel config flags
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Enable specific sam9x kernel config flags. Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 168 +++-- 1 file changed, 159 insertions(+), 9 deletions(-) diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index d8b5c31dc7e5..a9f66766b1f2 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -1,7 +1,6 @@ . CONFIG_INITRAMFS_SOURCE="" +CONFIG_INPUT=y +CONFIG_INPUT_KEYBOARD=y Do you really need keyboard support in OpenWrt? OpenWrt uses some patches to hanlde buttons like a wifi on / off switch. CONFIG_IRQCHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_IRQ_WORK=y +CONFIG_JBD2=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGER_CPU=y +CONFIG_LEDS_TRIGGER_GPIO=y . +CONFIG_USB=y +CONFIG_USB_ACM=y +CONFIG_USB_AT91=y +CONFIG_USB_ATMEL_USBA=y +CONFIG_USB_COMMON=y +CONFIG_USB_CONFIGFS=y I would prefer if you put the USB gadget stuff into a optional openwrt kmod kernel package instead of compiling this into the kernel. +CONFIG_USB_CONFIGFS_ACM=y +# CONFIG_USB_CONFIGFS_ECM is not set +# CONFIG_USB_CONFIGFS_ECM_SUBSET is not set +# CONFIG_USB_CONFIGFS_EEM is not set +# CONFIG_USB_CONFIGFS_F_FS is not set +# CONFIG_USB_CONFIGFS_F_HID is not set +# CONFIG_USB_CONFIGFS_F_LB_SS is not set +# CONFIG_USB_CONFIGFS_F_PRINTER is not set +CONFIG_USB_CONFIGFS_MASS_STORAGE=y +# CONFIG_USB_CONFIGFS_NCM is not set +# CONFIG_USB_CONFIGFS_OBEX is not set +# CONFIG_USB_CONFIGFS_RNDIS is not set +# CONFIG_USB_CONFIGFS_SERIAL is not set +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_HCD_AT91=y +# CONFIG_USB_EHCI_HCD_PLATFORM is not set +CONFIG_USB_ETH=y +# CONFIG_USB_ETH_EEM is not set +CONFIG_USB_ETH_RNDIS=y +CONFIG_USB_F_ACM=y +CONFIG_USB_F_ECM=y +CONFIG_USB_F_MASS_STORAGE=y +CONFIG_USB_F_RNDIS=y +CONFIG_USB_F_SUBSET=y +CONFIG_USB_GADGET=y +CONFIG_USB_LIBCOMPOSITE=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_AT91=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_SERIAL=y +# CONFIG_USB_SERIAL_CONSOLE is not set +CONFIG_USB_SERIAL_FTDI_SIO=y . ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 1/6] at91: kernel: bump to 5.10
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with: - this the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save); - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9, SAM9X60) has been enabled such that sam9x SoCs to be able to boot. Signed-off-by: Claudiu Beznea --- target/linux/at91/Makefile| 2 +- .../at91/files/arch/arm/boot/dts/wb45n.dts| 220 -- .../at91/files/arch/arm/boot/dts/wb50n.dts| 113 - .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205 target/linux/at91/image/sam9x.mk | 1 + target/linux/at91/image/sama5.mk | 1 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 - .../102-ARM-at91-build-dtb-for-wb45n.patch| 12 - ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 -- .../103-ARM-at91-build-dtb-for-wb50n.patch| 12 - ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39 target/linux/at91/sam9x/config-default| 105 - The target/linux/at91/sama5/config-default probably also needs some updates. When I compile the sama5 subtaregt the kernel find the folowing new symbols: Enable firmware caching during suspend (FW_CACHE) [Y/n/?] (NEW) ATMEL Image Sensor Controller (ISC) support (VIDEO_ATMEL_ISC) [N/m/y/?] (NEW) Microchip ASoC driver for boards using S/PDIF TX (SND_MCHP_SOC_SPDIFTX) [N/m/y/?] (NEW) Microchip ASoC driver for boards using S/PDIF RX (SND_MCHP_SOC_SPDIFRX) [N/m/y/?] (NEW) Special Function Registers support (AT91_SOC_SFR) [N/m/y/?] (NEW) Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 0/6] at91: add support for sama5d2 icp, sama5d27 wlsom1 ek and sam9x60ek
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Hi, This series adds support for SAMA5D2 ICP, SAMA5D27-WLSOM1-EK and SAM9X60EK boards. Since SAM9X60's kernel support is included in 5.10 but not on 5.4 1st (patch 1/6) switches to kernel 5.10. Patches 2/6, 5/6 updates the kernel config for sam9x SoCs and sam9x60. Patch 3/6, 4/6, 6/6 adds the boards support. Thank you, Claudiu Beznea Hi, I am getting this error: - touch /home/hauke/openwrt/openwrt/staging_dir/target-arm_arm926ej-s_musl_eabi/root-at91/stamp/.kernel_installed ERROR: module '/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/linux-5.10.70/drivers/usb/gadget/at91_udc.ko' is missing. make[3]: *** [/home/hauke/openwrt/openwrt/target/linux/at91/modules.mk:67: /home/hauke/openwrt/openwrt/bin/targets/at91/sam9x/packages/kmod-at91-udc_5.10.70-1_arm_arm926ej-s.ipk] Error 1 make[3]: Leaving directory '/home/hauke/openwrt/openwrt/package/kernel/linux' time: package/kernel/linux/compile#1.54#0.07#1.61 ERROR: package/kernel/linux failed to build. When building with this configuration: CONFIG_TARGET_at91=y CONFIG_TARGET_at91_sam9x=y CONFIG_TARGET_at91_sam9x_DEVICE_atmel_at91sam9263ek=y CONFIG_DISPLAY_SUPPORT=y CONFIG_PACKAGE_kmod-usb-ehci=y CONFIG_PACKAGE_kmod-usb2=y The at91_udc driver is compiled into the kernel image with CONFIG_USB_AT91=y, but still selected as a default package Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt imx split status?
Piotr, How is your progress regarding submitting patches to OpenWrt to split the imx target into multiple arch related subtargets (like cortexa7, cortexa9)? Is anyone working on i.MX8 support that you know of? I have seen people ask for it in the past but nobody has been persistent about it. Best regards, Tim ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Suggestion: Explicitly warn to not use GitHub web UI for patches
Hi, I've repeatedly made the observation that people who submit PRs with edits from GitHub's web interface cannot do history edits there when we request them. This leads to a lot of frustration both for the reviewers and the submitters. Eventually, it's mostly one of the following three undesirable options: 1. The submitter has to clone the repository anyway (as he would have done in the first place otherwise), and do the edits locally. This typically leads to additional problems with force-pushing to the existing PR, and in most cases simply means duplicate work for the submitter. 2. The reviewer (committer) has to do the edits for the submitter. 3. The submitter closes the PR because he does not want to do the same thing twice. I have dealt with any of these options multiple times. Consequently, I think the overall disadvantages of direct GitHub edits outweigh the advantage of this option for easy submissions. It's also really frustrating for myself when I have to decide whether I should invest precious time in doing a git 101 with somebody or have to leave him behind otherwise. Thus, I'd like actively discourage this option in submitting-patches, and edit the current references to this option there accordingly. This essentially implies something like "Please, do not use GitHub Web UI for creating commits because ...". Of course, not everybody will read it, but if it helps for a few of them, it's already better than now. Are there any (other) opinions out there? Do we require a vote for that or is it enough if there are no objections after a certain waiting time? Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Removing 5.4 support for bcm27xx and bcm53xx
Hi Adrian, No objections from me for bcm27xx. Best regards, Álvaro. > El 2 oct 2021, a las 18:43, Adrian Schmutzler > escribió: > > Hi, > > both bcm27xx and bcm53xx have kernel 5.10 by default for more than one > month. > > I'd like to remove 5.4 patches etc. there, so we don't have to bother with > 5.4 for new patches (like stintel had to when adding config symbols > recently). > > Any objections? > > Best > > Adrian > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: toolchain for building eBPF modules within the OpenWrt build system
On Sun, Oct 3, 2021 at 5:47 AM Felix Fietkau wrote: > > > Hi, > > I recently spent some time digging into what's needed for proper eBPF > build support in OpenWrt. Here's what I found so far: > > Most out-of-tree eBPF based projects fork some of the BPF related kernel > headers from various different kernel versions and manually maintain > those forks. These header files are usually very incomplete and tailored > specifically for the project that uses them. To make things even worse, > they typically explicitly rely on including headers from the local x86 > host toolchain header files when building for the BPF target. > > The in-kernel build of BPF modules is weird in a different way. It > explicitly includes all the header files from the arch that the kernel > is being built for. And because a lot of assembly stuff in there is > completely incompatible with building for the BPF target, the build > system actually targets clang to the same arch that the kernel is being > built for and only emits un-optimized LLVM bitcode without running any > of the LLVM passes. It then passes that bitcode to the optimizer and > target code generator with bpf specified as target arch. > It's a weird hack, but it seems to work properly even when > cross-compiling to non-x86 targets. > > When writing ebpf modules myself, I definitely don't want to rely on the > crappy header fork mess that most out-of-tree projects use. In my tests > it was simply too fragile, and I couldn't get it to work on my macOS > build host either. Even if we could make it work for more use cases, it > would still be a maintenance hell when comes to supporting more features > and newer kernel versions. > > I think staying close to the way that in-tree BPF module builds work is > the way to go. Unfortunately, this means that we will not be able to use > GCC for BPF (which Daniel has been working on), because targeting the > frontend and the rest of the compiler to different architectures is only > supported by clang/LLVM. > > I just did a test build of LLVM with reduced features and targetting > only BPF, and it takes around 42 minutes to build on my 2018 macbook. > That's more than the time needed to build a typical basic OpenWrt build > from scratch. > > The way I see it, these are our options for eBPF support: > > 1. Add a host dependency on a recent enough LLVM version for eBPF. > 1a) disable it by default > 1b) hide eBPF packages unless host support is available > 2. Add llvm to tools/ to ensure that it is only built once, even when > switching between targets > 3. Add llvm as a host package and use build-dependencies in eBPF > 4. Ship precompiled big and little endian eBPF binaries + scripts to > recompile in packages, and rely on CO-RE (compile once, run everywhere) > > What do you think? I've been thinking of adding a toolchain/llvm section before. I don't know how realistic it would be or if it solves the eBPF issue. > > - Felix > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out
On Sun, Oct 3, 2021 at 5:18 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of daxiong
> > Sent: Sonntag, 3. Oktober 2021 13:35
> > To: openwrt-devel@lists.openwrt.org
> > Subject: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit
> > queue 0 timed out
> >
> > Use flow control or BQL maybe lead to bug.
> > Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur.
> > example:
> >Server: iperf3 -s
> >Client: iperf3 -c 172.16.10.20
> >
> > Signed-off-by: daxiong
>
> Is this your (full) real name?
daxiong = big bear. So probably not.
>
> Best
>
> Adrian
>
> > ---
> > ...iatek-ethernet-transmit-queue-timeout-bug.patch | 109
> > +
> > 1 file changed, 109 insertions(+)
> > create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> > ethernet-transmit-queue-timeout-bug.patch
> >
> > diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> > transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> > mediatek-ethernet-transmit-queue-timeout-bug.patch
> > new file mode 100644
> > index 000..d5da9e4
> > --- /dev/null
> > +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> > que
> > +++ ue-timeout-bug.patch
> > @@ -0,0 +1,109 @@
> > +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> > 18:46:25.065801660 +0800
> > b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> > 19:13:24.931017393 +0800
> > +@@ -26,6 +26,11 @@
> > +
> > + #include "mtk_eth_soc.h"
> > +
> > ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> > ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> > ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> > ++DISABLE_MTK_FC //disable Flow Control
> > ++
> > + static int mtk_msg_level = -1;
> > + module_param_named(msg_level, mtk_msg_level, int, 0);
> > +MODULE_PARM_DESC(msg_level, "Message level
> > +(-1=defaults,0=none,...,16=all)");
> > +@@ -380,6 +385,10 @@ static void mtk_mac_config(struct phylin
> > + mcr_new |= MAC_MCR_FORCE_RX_FC;
> > + }
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> > MAC_MCR_FORCE_TX_FC);
> > ++#endif
> > ++
> > + /* Only update control register when needed! */
> > + if (mcr_new != mcr_cur)
> > + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> > @@ -535,8 +544,10
> > +@@ static void mtk_validate(struct phylink_
> > + }
> > + }
> > +
> > ++#ifndef DISABLE_MTK_FC
> > + phylink_set(mask, Pause);
> > + phylink_set(mask, Asym_Pause);
> > ++#endif
> > +
> > + linkmode_and(supported, supported, mask);
> > + linkmode_and(state->advertising, state->advertising, mask); @@
> > +-1071,8 +1082,10 @@ static int mtk_tx_map(struct sk_buff *sk
> > + txd_pdma->txd2 |= TX_DMA_LS1;
> > + }
> > +
> > ++#ifndef DISABLE_MTK_BQL
> > + netdev_sent_queue(dev, skb->len);
> > + skb_tx_timestamp(skb);
> > ++#endif
> > +
> > + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> > + atomic_sub(n_desc, >free_count); @@ -1496,7 +1509,9 @@
> > static
> > +int mtk_poll_tx(struct mtk_eth *e
> > + for (i = 0; i < MTK_MAC_COUNT; i++) {
> > + if (!eth->netdev[i] || !done[i])
> > + continue;
> > ++#ifndef DISABLE_MTK_BQL
> > + netdev_completed_queue(eth->netdev[i], done[i],
> > bytes[i]);
> > ++#endif
> > + total += done[i];
> > + eth->tx_packets += done[i];
> > + eth->tx_bytes += bytes[i];
> > +--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
> > b/drivers/net/dsa/mt7530.c 2021-10-03 19:13:37.807016826 +0800
> > +@@ -22,6 +22,8 @@
> > +
> > + #include "mt7530.h"
> > +
> > ++#define DISABLE_MTK_FC //disable Flow Control
> > ++
> > + /* String, offset, and register size in bytes if different from 4
> > +bytes */ static const struct mt7530_mib_desc mt7530_mib[] = {
> > + MIB_DESC(1, 0x00, "TxDrop"),
> > +@@ -1281,6 +1283,18 @@ mt7530_setup(struct dsa_switch *ds)
> > + val |= MHWTRAP_MANUAL;
> > + mt7530_write(priv, MT7530_MHWTRAP, val);
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++usleep_range(10, 20);
> > ++
> > ++val = mt7530_read(priv, 0x1FE0);
> > ++val &= ~BIT(31);
> > ++mt7530_write(priv, 0x1FE0, val);
> > ++
> > ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> > ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> > ++usleep_range(10, 20);
> > ++#endif
> > ++
> > + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> > +
> > + /* Enable and reset MIB counters */
> > +@@ -1427,6 +1441,10 @@ static void mt7530_phylink_mac_config(st
> > + mcr_new |= PMCR_RX_FC_EN;
> > + }
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++mcr_new &=
[sdwalker/sdwalker.github.io] 25b5e5: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 25b5e578934ba7efc97829245b21df5f9ae1e20a https://github.com/sdwalker/sdwalker.github.io/commit/25b5e578934ba7efc97829245b21df5f9ae1e20a Author: Stephen Walker Date: 2021-10-03 (Sun, 03 Oct 2021) Changed paths: M uscan/index-19.07.html M uscan/index-21.02.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] zynq: switch to kernel 5.10
Use kernel 5.10 by default compile-tested: all devices from target run-tested: Digilent Zybo Z7-20 Signed-off-by: Luis Araneda --- target/linux/zynq/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/zynq/Makefile b/target/linux/zynq/Makefile index b5988c9e05..83807913e4 100644 --- a/target/linux/zynq/Makefile +++ b/target/linux/zynq/Makefile @@ -17,7 +17,7 @@ define Target/Description Build firmware image for Zynq 7000 SoC devices. endef -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 include $(INCLUDE_DIR)/target.mk -- 2.33.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/4] zynq: kernel: update config for 5.10
Update config with make kernel_oldconfig Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.10 | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/target/linux/zynq/config-5.10 b/target/linux/zynq/config-5.10 index 98b2bd0f93..aad769d319 100644 --- a/target/linux/zynq/config-5.10 +++ b/target/linux/zynq/config-5.10 @@ -2,7 +2,6 @@ CONFIG_ALIGNMENT_TRAP=y # CONFIG_ALTERA_FREEZE_BRIDGE is not set # CONFIG_ALTERA_PR_IP_CORE is not set CONFIG_ARCH_32BIT_OFF_T=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_KEEP_MEMBLOCK=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y @@ -12,6 +11,8 @@ CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_NR_GPIO=1024 CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y +CONFIG_ARCH_SELECT_MEMORY_MODEL=y +CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y @@ -75,7 +76,6 @@ CONFIG_CMA_SIZE_SEL_MBYTES=y CONFIG_COMMON_CLK=y # CONFIG_COMMON_CLK_AXI_CLKGEN is not set CONFIG_COMMON_CLK_SI570=y -CONFIG_COMMON_CLK_VERSATILE=y CONFIG_COMPAT_32BIT_TIME=y CONFIG_CONNECTOR=y CONFIG_CONSOLE_TRANSLATIONS=y @@ -117,15 +117,10 @@ CONFIG_CRC16=y # CONFIG_CRC32_SARWATE is not set CONFIG_CRC32_SLICEBY8=y CONFIG_CROSS_MEMORY_ATTACH=y -CONFIG_CRYPTO_AEAD=y -CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_CRC32=y CONFIG_CRYPTO_CRC32C=y -CONFIG_CRYPTO_HASH=y -CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_HW=y -CONFIG_CRYPTO_MANAGER=y -CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_RNG2=y CONFIG_DCACHE_WORD_ACCESS=y @@ -134,6 +129,7 @@ CONFIG_DMADEVICES=y CONFIG_DMA_CMA=y CONFIG_DMA_ENGINE=y CONFIG_DMA_OF=y +CONFIG_DMA_OPS=y CONFIG_DMA_REMAP=y CONFIG_DMA_SHARED_BUFFER=y CONFIG_DRM=y @@ -188,6 +184,7 @@ CONFIG_FPGA_REGION=y CONFIG_FREEZER=y CONFIG_FS_IOMAP=y CONFIG_FS_MBCACHE=y +CONFIG_FW_CACHE=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ARCH_TOPOLOGY=y @@ -196,6 +193,7 @@ CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_GENERIC_EARLY_IOREMAP=y +CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_IRQ_MIGRATION=y @@ -211,6 +209,7 @@ CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_VDSO_32=y CONFIG_GLOB=y CONFIG_GPIOLIB=y CONFIG_GPIOLIB_IRQCHIP=y @@ -280,6 +279,7 @@ CONFIG_IRQ_WORK=y CONFIG_JBD2=y # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y +CONFIG_KCMP=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_XZ is not set CONFIG_KEYBOARD_ATKBD=y @@ -293,6 +293,7 @@ CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LEDS_TRIGGER_ONESHOT=y CONFIG_LEDS_TRIGGER_TRANSIENT=y CONFIG_LIBFDT=y +CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_MACB=y @@ -302,6 +303,7 @@ CONFIG_MARVELL_PHY=y CONFIG_MDIO_BITBANG=y CONFIG_MDIO_BUS=y CONFIG_MDIO_DEVICE=y +CONFIG_MDIO_DEVRES=y # CONFIG_MDIO_GPIO is not set CONFIG_MEMFD_CREATE=y CONFIG_MEMORY=y @@ -394,10 +396,12 @@ CONFIG_PCIE_XILINX=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_DOMAINS_GENERIC=y CONFIG_PCI_MSI=y +CONFIG_PCI_MSI_ARCH_FALLBACKS=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PERF_USE_VMALLOC=y CONFIG_PGTABLE_LEVELS=2 CONFIG_PHYLIB=y +CONFIG_PHYLINK=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_SINGLE is not set CONFIG_PINCTRL_ZYNQ=y @@ -423,7 +427,6 @@ CONFIG_R8169=y CONFIG_RAS=y CONFIG_RATIONAL=y CONFIG_REALTEK_PHY=y -CONFIG_REFCOUNT_FULL=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_REGMAP_MMIO=y @@ -499,12 +502,12 @@ CONFIG_UNWINDER_ARM=y CONFIG_USB=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_HOST=y -CONFIG_USB_CHIPIDEA_OF=y CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_COMMON=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set +# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_GADGET_XILINX=y CONFIG_USB_HID=y @@ -519,7 +522,6 @@ CONFIG_USB_ULPI_BUS=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USE_OF=y CONFIG_VEXPRESS_CONFIG=y -CONFIG_VEXPRESS_SYSCFG=y CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_VGA_ARB=y -- 2.33.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/4] zynq: kernel: copy config from 5.4 to 5.10
Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.10 | 553 ++ 1 file changed, 553 insertions(+) create mode 100644 target/linux/zynq/config-5.10 diff --git a/target/linux/zynq/config-5.10 b/target/linux/zynq/config-5.10 new file mode 100644 index 00..98b2bd0f93 --- /dev/null +++ b/target/linux/zynq/config-5.10 @@ -0,0 +1,553 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_ALTERA_FREEZE_BRIDGE is not set +# CONFIG_ALTERA_PR_IP_CORE is not set +CONFIG_ARCH_32BIT_OFF_T=y +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_KEEP_MEMBLOCK=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MULTIPLATFORM=y +CONFIG_ARCH_MULTI_V6_V7=y +CONFIG_ARCH_MULTI_V7=y +CONFIG_ARCH_NR_GPIO=1024 +CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y +CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_VEXPRESS=y +CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y +# CONFIG_ARCH_VEXPRESS_SPC is not set +CONFIG_ARCH_ZYNQ=y +CONFIG_ARM=y +CONFIG_ARM_AMBA=y +CONFIG_ARM_CPU_SUSPEND=y +CONFIG_ARM_ERRATA_643719=y +CONFIG_ARM_ERRATA_720789=y +CONFIG_ARM_ERRATA_754322=y +CONFIG_ARM_ERRATA_754327=y +CONFIG_ARM_ERRATA_764369=y +CONFIG_ARM_ERRATA_775420=y +CONFIG_ARM_GIC=y +CONFIG_ARM_GLOBAL_TIMER=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_ARM_HEAVY_MB=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +CONFIG_ARM_PATCH_IDIV=y +CONFIG_ARM_PATCH_PHYS_VIRT=y +# CONFIG_ARM_PL172_MPMC is not set +# CONFIG_ARM_SMMU is not set +CONFIG_ARM_THUMB=y +CONFIG_ARM_TIMER_SP804=y +CONFIG_ARM_UNWIND=y +CONFIG_ARM_VIRT_EXT=y +CONFIG_ARM_ZYNQ_CPUIDLE=y +CONFIG_ATAGS=y +CONFIG_AUTO_ZRELADDR=y +# CONFIG_AXI_DMAC is not set +CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=16384 +CONFIG_BLK_MQ_PCI=y +CONFIG_BLK_PM=y +CONFIG_BOUNCE=y +CONFIG_CACHE_L2X0=y +CONFIG_CADENCE_TTC_TIMER=y +CONFIG_CADENCE_WATCHDOG=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK=y +CONFIG_CLKSRC_MMIO=y +CONFIG_CLKSRC_VERSATILE=y +CONFIG_CLK_SP810=y +CONFIG_CLK_VEXPRESS_OSC=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CMA=y +CONFIG_CMA_ALIGNMENT=8 +CONFIG_CMA_AREAS=7 +# CONFIG_CMA_DEBUG is not set +# CONFIG_CMA_DEBUGFS is not set +CONFIG_CMA_SIZE_MBYTES=16 +# CONFIG_CMA_SIZE_SEL_MAX is not set +CONFIG_CMA_SIZE_SEL_MBYTES=y +# CONFIG_CMA_SIZE_SEL_MIN is not set +# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set +CONFIG_COMMON_CLK=y +# CONFIG_COMMON_CLK_AXI_CLKGEN is not set +CONFIG_COMMON_CLK_SI570=y +CONFIG_COMMON_CLK_VERSATILE=y +CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CONNECTOR=y +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_CONTIG_ALLOC=y +CONFIG_COREDUMP=y +# CONFIG_CPUFREQ_DT is not set +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_FREQ=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ATTR_SET=y +CONFIG_CPU_FREQ_GOV_COMMON=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_STAT=y +CONFIG_CPU_HAS_ASID=y +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_IDLE_GOV_MENU=y +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_PM=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_SPECTRE=y +CONFIG_CPU_THERMAL=y +CONFIG_CPU_THUMB_CAPABLE=y +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +# CONFIG_CRC32_SARWATE is not set +CONFIG_CRC32_SLICEBY8=y +CONFIG_CROSS_MEMORY_ATTACH=y +CONFIG_CRYPTO_AEAD=y +CONFIG_CRYPTO_AEAD2=y +CONFIG_CRYPTO_CRC32=y +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_MANAGER2=y +CONFIG_CRYPTO_NULL2=y +CONFIG_CRYPTO_RNG2=y +CONFIG_DCACHE_WORD_ACCESS=y +CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" +CONFIG_DMADEVICES=y +CONFIG_DMA_CMA=y +CONFIG_DMA_ENGINE=y +CONFIG_DMA_OF=y +CONFIG_DMA_REMAP=y +CONFIG_DMA_SHARED_BUFFER=y +CONFIG_DRM=y +CONFIG_DRM_BRIDGE=y +CONFIG_DRM_FBDEV_EMULATION=y +CONFIG_DRM_FBDEV_OVERALLOC=100 +CONFIG_DRM_KMS_FB_HELPER=y +CONFIG_DRM_KMS_HELPER=y +CONFIG_DRM_PANEL=y +CONFIG_DRM_PANEL_BRIDGE=y +CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y +CONFIG_DTC=y +CONFIG_DUMMY_CONSOLE=y +CONFIG_E1000E=y +CONFIG_EDAC=y +CONFIG_EDAC_ATOMIC_SCRUB=y +# CONFIG_EDAC_DEBUG is not set +CONFIG_EDAC_LEGACY_SYSFS=y +CONFIG_EDAC_SUPPORT=y +# CONFIG_EDAC_SYNOPSYS is not set +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_AT25=y +CONFIG_ELF_CORE=y +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_EXT4_FS=y +CONFIG_EXTCON=y +CONFIG_F2FS_FS=y +CONFIG_FB=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_IMAGEBLIT=y +CONFIG_FB_CMDLINE=y +CONFIG_FB_DEFERRED_IO=y +CONFIG_FB_SYS_COPYAREA=y +CONFIG_FB_SYS_FILLRECT=y +CONFIG_FB_SYS_FOPS=y +CONFIG_FB_SYS_IMAGEBLIT=y +# CONFIG_FB_XILINX is not set +CONFIG_FHANDLE=y
[PATCH 0/4] zynq: add support for kernel 5.10 and switch to it by default
This series adds support for kernel 5.10 and then switches to it by default. As the series is introducing and switching to 5.10, I didn't want to remove 5.4 files to give some time in case regressions appear. compile-tested: all devices from target run-tested: Digilent Zybo Z7-20 Signed-off-by: Luis Araneda Luis Araneda (4): zynq: kernel: refresh config zynq: kernel: copy config from 5.4 to 5.10 zynq: kernel: update config for 5.10 zynq: switch to kernel 5.10 target/linux/zynq/Makefile| 2 +- target/linux/zynq/config-5.10 | 555 ++ target/linux/zynq/config-5.4 | 96 +- 3 files changed, 558 insertions(+), 95 deletions(-) create mode 100644 target/linux/zynq/config-5.10 -- 2.33.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/4] zynq: kernel: refresh config
using "make kernel_oldconfig" Several configs are now part of generic Signed-off-by: Luis Araneda --- target/linux/zynq/config-5.4 | 96 +--- 1 file changed, 2 insertions(+), 94 deletions(-) diff --git a/target/linux/zynq/config-5.4 b/target/linux/zynq/config-5.4 index 498d057e3a..98b2bd0f93 100644 --- a/target/linux/zynq/config-5.4 +++ b/target/linux/zynq/config-5.4 @@ -3,23 +3,6 @@ CONFIG_ALIGNMENT_TRAP=y # CONFIG_ALTERA_PR_IP_CORE is not set CONFIG_ARCH_32BIT_OFF_T=y CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_BINFMT_FLAT=y -CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_FORTIFY_SOURCE=y -CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y -CONFIG_ARCH_HAS_KCOV=y -CONFIG_ARCH_HAS_KEEPINITRD=y -CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y -CONFIG_ARCH_HAS_PHYS_TO_DMA=y -CONFIG_ARCH_HAS_RESET_CONTROLLER=y -CONFIG_ARCH_HAS_SETUP_DMA_OPS=y -CONFIG_ARCH_HAS_SET_MEMORY=y -CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y -CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y -CONFIG_ARCH_HAS_TEARDOWN_DMA_OPS=y -CONFIG_ARCH_HAS_TICK_BROADCAST=y -CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_KEEP_MEMBLOCK=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y @@ -29,25 +12,13 @@ CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_NR_GPIO=1024 CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT=y -CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y -CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y # CONFIG_ARCH_VEXPRESS_SPC is not set -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_GENERAL_HUGETLB=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARCH_ZYNQ=y CONFIG_ARM=y CONFIG_ARM_AMBA=y -CONFIG_ARM_CCI=y -CONFIG_ARM_CCI400_COMMON=y -CONFIG_ARM_CCI400_PMU=y -CONFIG_ARM_CCI_PMU=y CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_ERRATA_643719=y CONFIG_ARM_ERRATA_720789=y @@ -61,15 +32,11 @@ CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_ARM_HEAVY_MB=y CONFIG_ARM_L1_CACHE_SHIFT=6 CONFIG_ARM_L1_CACHE_SHIFT_6=y -# CONFIG_ARM_LPAE is not set CONFIG_ARM_PATCH_IDIV=y CONFIG_ARM_PATCH_PHYS_VIRT=y # CONFIG_ARM_PL172_MPMC is not set -CONFIG_ARM_PMU=y # CONFIG_ARM_SMMU is not set -# CONFIG_ARM_SP805_WATCHDOG is not set CONFIG_ARM_THUMB=y -# CONFIG_ARM_THUMBEE is not set CONFIG_ARM_TIMER_SP804=y CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y @@ -88,7 +55,6 @@ CONFIG_BOUNCE=y CONFIG_CACHE_L2X0=y CONFIG_CADENCE_TTC_TIMER=y CONFIG_CADENCE_WATCHDOG=y -CONFIG_CC_HAS_KASAN_GENERIC=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK=y CONFIG_CLKSRC_MMIO=y @@ -119,8 +85,6 @@ CONFIG_COREDUMP=y CONFIG_CPU_32v6K=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y -# CONFIG_CPU_BIG_ENDIAN is not set -# CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_CPU_CACHE_V7=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y @@ -138,13 +102,9 @@ CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_HAS_ASID=y -# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set -# CONFIG_CPU_ICACHE_DISABLE is not set -# CONFIG_CPU_ICACHE_MISMATCH_WORKAROUND is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y -# CONFIG_CPU_IDLE_GOV_TEO is not set CONFIG_CPU_PABRT_V7=y CONFIG_CPU_PM=y CONFIG_CPU_RMAP=y @@ -170,7 +130,6 @@ CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_RNG2=y CONFIG_DCACHE_WORD_ACCESS=y CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" -# CONFIG_DEBUG_USER is not set CONFIG_DMADEVICES=y CONFIG_DMA_CMA=y CONFIG_DMA_ENGINE=y @@ -183,7 +142,6 @@ CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100 CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_KMS_HELPER=y -# CONFIG_DRM_MCDE is not set CONFIG_DRM_PANEL=y CONFIG_DRM_PANEL_BRIDGE=y CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y @@ -231,8 +189,6 @@ CONFIG_FREEZER=y CONFIG_FS_IOMAP=y CONFIG_FS_MBCACHE=y CONFIG_FW_LOADER_PAGED_BUF=y -# CONFIG_FXOS8700_I2C is not set -# CONFIG_FXOS8700_SPI is not set CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ARCH_TOPOLOGY=y CONFIG_GENERIC_BUG=y @@ -254,6 +210,7 @@ CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y +CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GLOB=y CONFIG_GPIOLIB=y CONFIG_GPIOLIB_IRQCHIP=y @@ -265,51 +222,7 @@ CONFIG_HARDEN_BRANCH_PREDICTOR=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y -CONFIG_HAVE_ARCH_AUDITSYSCALL=y -CONFIG_HAVE_ARCH_BITREVERSE=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_PFN_VALID=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_ARM_SCU=y -CONFIG_HAVE_ARM_SMCCC=y -CONFIG_HAVE_ARM_TWD=y -CONFIG_HAVE_CLK=y -CONFIG_HAVE_CLK_PREPARE=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y
RFC: toolchain for building eBPF modules within the OpenWrt build system
Hi, I recently spent some time digging into what's needed for proper eBPF build support in OpenWrt. Here's what I found so far: Most out-of-tree eBPF based projects fork some of the BPF related kernel headers from various different kernel versions and manually maintain those forks. These header files are usually very incomplete and tailored specifically for the project that uses them. To make things even worse, they typically explicitly rely on including headers from the local x86 host toolchain header files when building for the BPF target. The in-kernel build of BPF modules is weird in a different way. It explicitly includes all the header files from the arch that the kernel is being built for. And because a lot of assembly stuff in there is completely incompatible with building for the BPF target, the build system actually targets clang to the same arch that the kernel is being built for and only emits un-optimized LLVM bitcode without running any of the LLVM passes. It then passes that bitcode to the optimizer and target code generator with bpf specified as target arch. It's a weird hack, but it seems to work properly even when cross-compiling to non-x86 targets. When writing ebpf modules myself, I definitely don't want to rely on the crappy header fork mess that most out-of-tree projects use. In my tests it was simply too fragile, and I couldn't get it to work on my macOS build host either. Even if we could make it work for more use cases, it would still be a maintenance hell when comes to supporting more features and newer kernel versions. I think staying close to the way that in-tree BPF module builds work is the way to go. Unfortunately, this means that we will not be able to use GCC for BPF (which Daniel has been working on), because targeting the frontend and the rest of the compiler to different architectures is only supported by clang/LLVM. I just did a test build of LLVM with reduced features and targetting only BPF, and it takes around 42 minutes to build on my 2018 macbook. That's more than the time needed to build a typical basic OpenWrt build from scratch. The way I see it, these are our options for eBPF support: 1. Add a host dependency on a recent enough LLVM version for eBPF. 1a) disable it by default 1b) hide eBPF packages unless host support is available 2. Add llvm to tools/ to ensure that it is only built once, even when switching between targets 3. Add llvm as a host package and use build-dependencies in eBPF 4. Ship precompiled big and little endian eBPF binaries + scripts to recompile in packages, and rely on CO-RE (compile once, run everywhere) What do you think? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of daxiong
> Sent: Sonntag, 3. Oktober 2021 13:35
> To: openwrt-devel@lists.openwrt.org
> Subject: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit
> queue 0 timed out
>
> Use flow control or BQL maybe lead to bug.
> Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur.
> example:
>Server: iperf3 -s
>Client: iperf3 -c 172.16.10.20
>
> Signed-off-by: daxiong
Is this your (full) real name?
Best
Adrian
> ---
> ...iatek-ethernet-transmit-queue-timeout-bug.patch | 109
> +
> 1 file changed, 109 insertions(+)
> create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> ethernet-transmit-queue-timeout-bug.patch
>
> diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> mediatek-ethernet-transmit-queue-timeout-bug.patch
> new file mode 100644
> index 000..d5da9e4
> --- /dev/null
> +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> que
> +++ ue-timeout-bug.patch
> @@ -0,0 +1,109 @@
> +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:46:25.065801660 +0800
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 19:13:24.931017393 +0800
> +@@ -26,6 +26,11 @@
> +
> + #include "mtk_eth_soc.h"
> +
> ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> ++DISABLE_MTK_FC //disable Flow Control
> ++
> + static int mtk_msg_level = -1;
> + module_param_named(msg_level, mtk_msg_level, int, 0);
> +MODULE_PARM_DESC(msg_level, "Message level
> +(-1=defaults,0=none,...,16=all)");
> +@@ -380,6 +385,10 @@ static void mtk_mac_config(struct phylin
> + mcr_new |= MAC_MCR_FORCE_RX_FC;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> MAC_MCR_FORCE_TX_FC);
> ++#endif
> ++
> + /* Only update control register when needed! */
> + if (mcr_new != mcr_cur)
> + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> @@ -535,8 +544,10
> +@@ static void mtk_validate(struct phylink_
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask); @@
> +-1071,8 +1082,10 @@ static int mtk_tx_map(struct sk_buff *sk
> + txd_pdma->txd2 |= TX_DMA_LS1;
> + }
> +
> ++#ifndef DISABLE_MTK_BQL
> + netdev_sent_queue(dev, skb->len);
> + skb_tx_timestamp(skb);
> ++#endif
> +
> + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> + atomic_sub(n_desc, >free_count); @@ -1496,7 +1509,9 @@
> static
> +int mtk_poll_tx(struct mtk_eth *e
> + for (i = 0; i < MTK_MAC_COUNT; i++) {
> + if (!eth->netdev[i] || !done[i])
> + continue;
> ++#ifndef DISABLE_MTK_BQL
> + netdev_completed_queue(eth->netdev[i], done[i],
> bytes[i]);
> ++#endif
> + total += done[i];
> + eth->tx_packets += done[i];
> + eth->tx_bytes += bytes[i];
> +--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
> b/drivers/net/dsa/mt7530.c 2021-10-03 19:13:37.807016826 +0800
> +@@ -22,6 +22,8 @@
> +
> + #include "mt7530.h"
> +
> ++#define DISABLE_MTK_FC //disable Flow Control
> ++
> + /* String, offset, and register size in bytes if different from 4
> +bytes */ static const struct mt7530_mib_desc mt7530_mib[] = {
> + MIB_DESC(1, 0x00, "TxDrop"),
> +@@ -1281,6 +1283,18 @@ mt7530_setup(struct dsa_switch *ds)
> + val |= MHWTRAP_MANUAL;
> + mt7530_write(priv, MT7530_MHWTRAP, val);
> +
> ++#ifdef DISABLE_MTK_FC
> ++usleep_range(10, 20);
> ++
> ++val = mt7530_read(priv, 0x1FE0);
> ++val &= ~BIT(31);
> ++mt7530_write(priv, 0x1FE0, val);
> ++
> ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> ++usleep_range(10, 20);
> ++#endif
> ++
> + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> +
> + /* Enable and reset MIB counters */
> +@@ -1427,6 +1441,10 @@ static void mt7530_phylink_mac_config(st
> + mcr_new |= PMCR_RX_FC_EN;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
> ++#endif
> ++
> + if (mcr_new != mcr_cur)
> + mt7530_write(priv, MT7530_PMCR_P(port), mcr_new); }
> @@ -1505,8
> ++1523,10 @@ unsupported:
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> +
mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out
Use flow control or BQL maybe lead to bug.
Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur.
example:
Server: iperf3 -s
Client: iperf3 -c 172.16.10.20
Signed-off-by: daxiong
---
...iatek-ethernet-transmit-queue-timeout-bug.patch | 109 +
1 file changed, 109 insertions(+)
create mode 100644
target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
diff --git
a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
new file mode 100644
index 000..d5da9e4
--- /dev/null
+++
b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
@@ -0,0 +1,109 @@
+--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 2021-10-03
18:46:25.065801660 +0800
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c 2021-10-03
19:13:24.931017393 +0800
+@@ -26,6 +26,11 @@
+
+ #include "mtk_eth_soc.h"
+
++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
++//Bug fixed: BQL and FC maybe QUEUE to be stopped forever
++#define DISABLE_MTK_BQL //disable Byte Queue Limit
++#define DISABLE_MTK_FC //disable Flow Control
++
+ static int mtk_msg_level = -1;
+ module_param_named(msg_level, mtk_msg_level, int, 0);
+ MODULE_PARM_DESC(msg_level, "Message level (-1=defaults,0=none,...,16=all)");
+@@ -380,6 +385,10 @@ static void mtk_mac_config(struct phylin
+ mcr_new |= MAC_MCR_FORCE_RX_FC;
+ }
+
++ #ifdef DISABLE_MTK_FC
++ mcr_new &= ~(MAC_MCR_FORCE_RX_FC | MAC_MCR_FORCE_TX_FC);
++ #endif
++
+ /* Only update control register when needed! */
+ if (mcr_new != mcr_cur)
+ mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
+@@ -535,8 +544,10 @@ static void mtk_validate(struct phylink_
+ }
+ }
+
++ #ifndef DISABLE_MTK_FC
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
++ #endif
+
+ linkmode_and(supported, supported, mask);
+ linkmode_and(state->advertising, state->advertising, mask);
+@@ -1071,8 +1082,10 @@ static int mtk_tx_map(struct sk_buff *sk
+ txd_pdma->txd2 |= TX_DMA_LS1;
+ }
+
++ #ifndef DISABLE_MTK_BQL
+ netdev_sent_queue(dev, skb->len);
+ skb_tx_timestamp(skb);
++ #endif
+
+ ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
+ atomic_sub(n_desc, >free_count);
+@@ -1496,7 +1509,9 @@ static int mtk_poll_tx(struct mtk_eth *e
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!eth->netdev[i] || !done[i])
+ continue;
++ #ifndef DISABLE_MTK_BQL
+ netdev_completed_queue(eth->netdev[i], done[i], bytes[i]);
++ #endif
+ total += done[i];
+ eth->tx_packets += done[i];
+ eth->tx_bytes += bytes[i];
+--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
b/drivers/net/dsa/mt7530.c 2021-10-03 19:13:37.807016826 +0800
+@@ -22,6 +22,8 @@
+
+ #include "mt7530.h"
+
++#define DISABLE_MTK_FC //disable Flow Control
++
+ /* String, offset, and register size in bytes if different from 4 bytes */
+ static const struct mt7530_mib_desc mt7530_mib[] = {
+ MIB_DESC(1, 0x00, "TxDrop"),
+@@ -1281,6 +1283,18 @@ mt7530_setup(struct dsa_switch *ds)
+ val |= MHWTRAP_MANUAL;
+ mt7530_write(priv, MT7530_MHWTRAP, val);
+
++#ifdef DISABLE_MTK_FC
++ usleep_range(10, 20);
++
++ val = mt7530_read(priv, 0x1FE0);
++ val &= ~BIT(31);
++ mt7530_write(priv, 0x1FE0, val);
++
++ mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
++ mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
++ usleep_range(10, 20);
++#endif
++
+ priv->p6_interface = PHY_INTERFACE_MODE_NA;
+
+ /* Enable and reset MIB counters */
+@@ -1427,6 +1441,10 @@ static void mt7530_phylink_mac_config(st
+ mcr_new |= PMCR_RX_FC_EN;
+ }
+
++ #ifdef DISABLE_MTK_FC
++ mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
++ #endif
++
+ if (mcr_new != mcr_cur)
+ mt7530_write(priv, MT7530_PMCR_P(port), mcr_new);
+ }
+@@ -1505,8 +1523,10 @@ unsupported:
+ }
+ }
+
++ #ifndef DISABLE_MTK_FC
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
++ #endif
+
+ linkmode_and(supported, supported, mask);
+ linkmode_and(state->advertising, state->advertising, mask);
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug. Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of daxiong
> Sent: Sonntag, 3. Oktober 2021 13:03
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth):
> Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug.
> Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur.
> example: Server: iperf3 -s Client: iperf3 -c 172.16.10.20
This has formal issues. Please clean up your commit title/message, use proper
title, and use your real name for Signed-off-by.
https://openwrt.org/submitting-patches
Apart from that, note that changes should be submitted to master first.
Best
Adrian
>
> Signed-off-by: daxiong
> ---
> ...iatek-ethernet-transmit-queue-timeout-bug.patch | 113
> +
> 1 file changed, 113 insertions(+)
> create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> ethernet-transmit-queue-timeout-bug.patch
>
> diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> mediatek-ethernet-transmit-queue-timeout-bug.patch
> new file mode 100644
> index 000..cec27c6
> --- /dev/null
> +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> que
> +++ ue-timeout-bug.patch
> @@ -0,0 +1,113 @@
> +--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
> b/drivers/net/dsa/mt7530.c 2021-10-03 18:47:33.353798655 +0800
> +@@ -22,6 +22,10 @@
> +
> + #include "mt7530.h"
> +
> ++#ifdef CONFIG_SUPPORT_IKUAI_CODE
> ++#define DISABLE_MTK_FC //disable Flow Control #endif
> ++
> + /* String, offset, and register size in bytes if different from 4
> +bytes */ static const struct mt7530_mib_desc mt7530_mib[] = {
> + MIB_DESC(1, 0x00, "TxDrop"),
> +@@ -1281,6 +1285,18 @@ mt7530_setup(struct dsa_switch *ds)
> + val |= MHWTRAP_MANUAL;
> + mt7530_write(priv, MT7530_MHWTRAP, val);
> +
> ++#ifdef DISABLE_MTK_FC
> ++usleep_range(10, 20);
> ++
> ++val = mt7530_read(priv, 0x1FE0);
> ++val &= ~BIT(31);
> ++mt7530_write(priv, 0x1FE0, val);
> ++
> ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> ++usleep_range(10, 20);
> ++#endif
> ++
> + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> +
> + /* Enable and reset MIB counters */
> +@@ -1427,6 +1443,10 @@ static void mt7530_phylink_mac_config(st
> + mcr_new |= PMCR_RX_FC_EN;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
> ++#endif
> ++
> + if (mcr_new != mcr_cur)
> + mt7530_write(priv, MT7530_PMCR_P(port), mcr_new); }
> @@ -1505,8
> ++1525,10 @@ unsupported:
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask);
> +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:46:25.065801660 +0800
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:47:33.353798655 +0800
> +@@ -26,6 +26,13 @@
> +
> + #include "mtk_eth_soc.h"
> +
> ++#ifdef CONFIG_SUPPORT_IKUAI_CODE
> ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> ++DISABLE_MTK_FC //disable Flow Control #endif
> ++
> + static int mtk_msg_level = -1;
> + module_param_named(msg_level, mtk_msg_level, int, 0);
> +MODULE_PARM_DESC(msg_level, "Message level
> +(-1=defaults,0=none,...,16=all)");
> +@@ -380,6 +387,10 @@ static void mtk_mac_config(struct phylin
> + mcr_new |= MAC_MCR_FORCE_RX_FC;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> MAC_MCR_FORCE_TX_FC);
> ++#endif
> ++
> + /* Only update control register when needed! */
> + if (mcr_new != mcr_cur)
> + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> @@ -535,8 +546,10
> +@@ static void mtk_validate(struct phylink_
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask); @@
> +-1071,8 +1084,10 @@ static int mtk_tx_map(struct sk_buff *sk
> + txd_pdma->txd2 |= TX_DMA_LS1;
> + }
> +
> ++#ifndef DISABLE_MTK_BQL
> + netdev_sent_queue(dev, skb->len);
> + skb_tx_timestamp(skb);
> ++#endif
> +
> + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> + atomic_sub(n_desc, >free_count); @@ -1496,7 +1511,9 @@
> static
> +int mtk_poll_tx(struct mtk_eth *e
> +
[PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug. Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur. ex
Signed-off-by: daxiong
---
...iatek-ethernet-transmit-queue-timeout-bug.patch | 113 +
1 file changed, 113 insertions(+)
create mode 100644
target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
diff --git
a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
new file mode 100644
index 000..cec27c6
--- /dev/null
+++
b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-queue-timeout-bug.patch
@@ -0,0 +1,113 @@
+--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
b/drivers/net/dsa/mt7530.c 2021-10-03 18:47:33.353798655 +0800
+@@ -22,6 +22,10 @@
+
+ #include "mt7530.h"
+
++#ifdef CONFIG_SUPPORT_IKUAI_CODE
++#define DISABLE_MTK_FC //disable Flow Control
++#endif
++
+ /* String, offset, and register size in bytes if different from 4 bytes */
+ static const struct mt7530_mib_desc mt7530_mib[] = {
+ MIB_DESC(1, 0x00, "TxDrop"),
+@@ -1281,6 +1285,18 @@ mt7530_setup(struct dsa_switch *ds)
+ val |= MHWTRAP_MANUAL;
+ mt7530_write(priv, MT7530_MHWTRAP, val);
+
++#ifdef DISABLE_MTK_FC
++ usleep_range(10, 20);
++
++ val = mt7530_read(priv, 0x1FE0);
++ val &= ~BIT(31);
++ mt7530_write(priv, 0x1FE0, val);
++
++ mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
++ mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
++ usleep_range(10, 20);
++#endif
++
+ priv->p6_interface = PHY_INTERFACE_MODE_NA;
+
+ /* Enable and reset MIB counters */
+@@ -1427,6 +1443,10 @@ static void mt7530_phylink_mac_config(st
+ mcr_new |= PMCR_RX_FC_EN;
+ }
+
++ #ifdef DISABLE_MTK_FC
++ mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
++ #endif
++
+ if (mcr_new != mcr_cur)
+ mt7530_write(priv, MT7530_PMCR_P(port), mcr_new);
+ }
+@@ -1505,8 +1525,10 @@ unsupported:
+ }
+ }
+
++ #ifndef DISABLE_MTK_FC
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
++ #endif
+
+ linkmode_and(supported, supported, mask);
+ linkmode_and(state->advertising, state->advertising, mask);
+--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 2021-10-03
18:46:25.065801660 +0800
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c 2021-10-03
18:47:33.353798655 +0800
+@@ -26,6 +26,13 @@
+
+ #include "mtk_eth_soc.h"
+
++#ifdef CONFIG_SUPPORT_IKUAI_CODE
++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
++//Bug fixed: BQL and FC maybe QUEUE to be stopped forever
++#define DISABLE_MTK_BQL //disable Byte Queue Limit
++#define DISABLE_MTK_FC //disable Flow Control
++#endif
++
+ static int mtk_msg_level = -1;
+ module_param_named(msg_level, mtk_msg_level, int, 0);
+ MODULE_PARM_DESC(msg_level, "Message level (-1=defaults,0=none,...,16=all)");
+@@ -380,6 +387,10 @@ static void mtk_mac_config(struct phylin
+ mcr_new |= MAC_MCR_FORCE_RX_FC;
+ }
+
++ #ifdef DISABLE_MTK_FC
++ mcr_new &= ~(MAC_MCR_FORCE_RX_FC | MAC_MCR_FORCE_TX_FC);
++ #endif
++
+ /* Only update control register when needed! */
+ if (mcr_new != mcr_cur)
+ mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
+@@ -535,8 +546,10 @@ static void mtk_validate(struct phylink_
+ }
+ }
+
++ #ifndef DISABLE_MTK_FC
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
++ #endif
+
+ linkmode_and(supported, supported, mask);
+ linkmode_and(state->advertising, state->advertising, mask);
+@@ -1071,8 +1084,10 @@ static int mtk_tx_map(struct sk_buff *sk
+ txd_pdma->txd2 |= TX_DMA_LS1;
+ }
+
++ #ifndef DISABLE_MTK_BQL
+ netdev_sent_queue(dev, skb->len);
+ skb_tx_timestamp(skb);
++ #endif
+
+ ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
+ atomic_sub(n_desc, >free_count);
+@@ -1496,7 +1511,9 @@ static int mtk_poll_tx(struct mtk_eth *e
+ for (i = 0; i < MTK_MAC_COUNT; i++) {
+ if (!eth->netdev[i] || !done[i])
+ continue;
++ #ifndef DISABLE_MTK_BQL
+ netdev_completed_queue(eth->netdev[i], done[i], bytes[i]);
++ #endif
+ total += done[i];
+ eth->tx_packets += done[i];
+ eth->tx_bytes += bytes[i];
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] realtek: enable pca953x driver for target
The system status LED on Panasonic Switch-M8eG PN28080K is connected to a PCA9539PW. To use the LED as a status LED of OpenWrt while booting, enable the pca953x driver and built-in to the kernel. Signed-off-by: INAGAKI Hiroshi --- target/linux/realtek/config-5.10 | 3 +++ target/linux/realtek/config-5.4 | 3 +++ 2 files changed, 6 insertions(+) diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10 index 1b050fc081..810bacbefa 100644 --- a/target/linux/realtek/config-5.10 +++ b/target/linux/realtek/config-5.10 @@ -69,6 +69,8 @@ CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GPIOLIB=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_GENERIC=y +CONFIG_GPIO_PCA953X=y +# CONFIG_GPIO_PCA953X_IRQ is not set CONFIG_GPIO_REALTEK_OTTO=y CONFIG_GPIO_RTL8231=y CONFIG_GRO_CELLS=y @@ -161,6 +163,7 @@ CONFIG_RATIONAL=y CONFIG_REALTEK_PHY=y CONFIG_REALTEK_SOC_PHY=y CONFIG_REGMAP=y +CONFIG_REGMAP_I2C=y CONFIG_REGMAP_MMIO=y CONFIG_RESET_CONTROLLER=y CONFIG_RTL838X=y diff --git a/target/linux/realtek/config-5.4 b/target/linux/realtek/config-5.4 index 5e29879798..8a353dfc32 100644 --- a/target/linux/realtek/config-5.4 +++ b/target/linux/realtek/config-5.4 @@ -72,6 +72,8 @@ CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GPIOLIB=y +CONFIG_GPIO_PCA953X=y +# CONFIG_GPIO_PCA953X_IRQ is not set CONFIG_GPIO_RTL8231=y CONFIG_GPIO_RTL838X=y CONFIG_REALTEK_SOC_PHY=y @@ -161,6 +163,7 @@ CONFIG_POWER_RESET_SYSCON=y CONFIG_PSB6970_PHY=y CONFIG_REALTEK_PHY=y CONFIG_REGMAP=y +CONFIG_REGMAP_I2C=y CONFIG_REGMAP_MMIO=y CONFIG_RESET_CONTROLLER=y CONFIG_RTL838X=y -- 2.33.0.windows.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] realtek: enable gpio-restart driver in target
On Panasonic Switch-M8eG PN28080K, a GPIO pin on PCA9539 chip is used for for hard-reset of the system. To use this, enable gpio-restart driver and built-in to the kernel. Signed-off-by: INAGAKI Hiroshi --- target/linux/realtek/config-5.10 | 1 + target/linux/realtek/config-5.4 | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10 index 810bacbefa..5a847a2bb1 100644 --- a/target/linux/realtek/config-5.10 +++ b/target/linux/realtek/config-5.10 @@ -158,6 +158,7 @@ CONFIG_PHYLIB=y CONFIG_PHYLINK=y CONFIG_PINCTRL=y CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO_RESTART=y CONFIG_POWER_RESET_SYSCON=y CONFIG_RATIONAL=y CONFIG_REALTEK_PHY=y diff --git a/target/linux/realtek/config-5.4 b/target/linux/realtek/config-5.4 index 8a353dfc32..34e4b9028b 100644 --- a/target/linux/realtek/config-5.4 +++ b/target/linux/realtek/config-5.4 @@ -159,6 +159,7 @@ CONFIG_PHYLIB=y CONFIG_PHYLINK=y CONFIG_PINCTRL=y CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_GPIO_RESTART=y CONFIG_POWER_RESET_SYSCON=y CONFIG_PSB6970_PHY=y CONFIG_REALTEK_PHY=y -- 2.33.0.windows.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] realtek: add support for Panasonic Switch-M8eG PN28080K
This is a continuation of the PR in GitHub[1]. This patch series adds support for Panasonic Switch-M8eG PN28080K. Panasonic Switch-M*eG PN28xx0K series has the following models: - Switch-M8eG PN28080K (RTL8380M, 8 + 1 SFP) - 1-9 : RTL8380M (SoC) - Switch-M16eG PN28160K (RTL8382M?, 14 + 2 combo) - ? - Switch-M24eG PN28240K (RTL8382M, 22 + 2 combo) - 1-8 : RTL8218B - 9-16: RTL8382M (SoC) - 17-24: RTL8218FB - Switch-M48eG PN28480K (RTL8393M, 44 + 4 combo) - 1-40: RTL8218B - 41-48: RTL8218FB (Note: I don't have a Switch-M16eG PN28160K and the hardware specification is unknown) These models have the many common parts, so 3rd commit creates a dtsi for This series. Note: - "Switch-M*eG" is a model name and "PN28xx0K" is a model number. Each model has two model number, "PN28xx0" and "PN28xx0K". But the first one (PN28xx0) is a Broadcom SoC based hardware. - This series uses the VxWorks-based kernel in stock firmware. [1]: https://github.com/openwrt/openwrt/pull/4209 INAGAKI Hiroshi (3): realtek: enable pca953x driver for target realtek: enable gpio-restart driver in target realtek: add support for Panasonic Switch-M8eG PN28080K target/linux/realtek/config-5.10 | 4 + target/linux/realtek/config-5.4 | 4 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 103 .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 + .../rtl8380_panasonic_m8eg-pn28080k.dts | 107 + .../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++ target/linux/realtek/image/Makefile | 10 + 7 files changed, 664 insertions(+) create mode 100644 target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi create mode 100644 target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts create mode 100644 target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi -- 2.33.0.windows.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K
Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on
RTL8380M.
Specification:
- SoC : Realtek RTL8380M
- RAM : DDR3 128 MiB (Winbond W631GG8KB-15)
- Flash : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
- Ethernet : 10/100/1000 Mbps x8 + 1
- port 1-8: TP, RTL8218B (SoC)
- port 9 : SFP, RTL8380M (SoC)
- LEDs/Keys : 7x / 1x
- UART : RS-232 port on the front panel (connector: RJ-45)
- 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
- 9600n8
- Power : 100-240 VAC, 50/60 Hz, 0.5 A
- Plug: IEC 60320-C13
- Stock OS : VxWorks based
Flash instruction using initramfs image:
1. Prepare the TFTP server with the IP address 192.168.1.111
2. Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
the TFTP directory
3. Download the official upgrading firmware (ex: pn28080k_v3.rom)
and place it to the TFTP directory
4. Boot M8eG and interrupt the U-Boot with Ctrl + C keys
5. Execute the following commands and boot with the OpenWrt initramfs
image
rtk network on
tftpboot 0x8100
bootm
6. Backup mtdblock files to the computer by scp or anything and reboot
7. Interrupt the U-Boot and execute the following commands to re-create
filesystem in the flash
ffsmount c:/
ffsfmt c:/
this step takes a long time, about ~ 4 mins
8. Execute the following commands to put the official images to the
filesystem
updatert
example:
updatert pn28080k_v3.rom
this step takes about ~ 40 secs
9. Set the environment variables of the U-Boot by the following commands
setenv loadaddr 0xb4e0
setenv bootcmd bootm
saveenv
10: Download the OpenWrt initramfs image and boot with it
tftpboot 0x8100 0101A8C0.img
bootm
11: On the initramfs image, download the sysupgrade image and perform
sysupgrade with it
sysupgrade
12: Wait ~ 120 seconds to complete flashing
Note:
- "Switch-M8eG" is a model name, and "PN28080K" is a model number.
Switch-M8eG has an another (old) model number ("PN28080"), it's not a
Realtek based hardware.
- Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
GPIO pin.
- The U-Boot checks the runtime images in the flash when booting and
fails to execute anything in "bootcmd" variable if the images are not
exsisting.
- A filesystem is formed in the flash (0x10-0x1DF) on the stock
firmware and it includes the stock images, configuration files and
checksum files. It's unknown format, can't be managed on the OpenWrt.
To get the enough space for OpenWrt, move the filesystem to the head
of "fs_reserved" partition by execution of "ffsfmt" and "updatert".
Back to the stock firmware:
1. Delete "loadaddr" variable and set "bootcmd" to the original value
on U-Boot:
setenv loadaddr
setenv bootcmd 'bootm 0x8100'
on OpenWrt:
fw_setenv loadaddr
fw_setenv bootcmd 'bootm 0x8100'
2. Perform reset or reboot
on U-Boot:
reset
on OpenWrt:
reboot
Signed-off-by: INAGAKI Hiroshi
---
.../rtl8380_panasonic_m8eg-pn28080k.dts | 103
.../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 216 +
.../rtl8380_panasonic_m8eg-pn28080k.dts | 107 +
.../rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi | 220 ++
target/linux/realtek/image/Makefile | 10 +
5 files changed, 656 insertions(+)
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
create mode 100644
target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
create mode 100644
target/linux/realtek/dts-5.4/rtl8380_panasonic_m8eg-pn28080k.dts
create mode 100644
target/linux/realtek/dts-5.4/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
diff --git a/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
new file mode 100644
index 00..df470c377e
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_panasonic_m8eg-pn28080k.dts
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+#include "rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi"
+
+/ {
+ compatible = "panasonic,m8eg-pn28080k", "realtek,rtl838x-soc";
+ model = "Panasonic Switch-M8eG PN28080K";
+
+ aliases {
+ led-boot = _status_eco_green;
+ led-failsafe = _status_eco_amber;
+ led-running = _status_eco_green;
+ led-upgrade = _status_eco_green;
+ };
+
+ sfp0: sfp-p9 {
+ compatible = "sff,sfp";
+ i2c-bus = <>;
+ tx-fault-gpio = < 0 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpio = < 1 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpio = < 2 GPIO_ACTIVE_LOW>;
+ los-gpio = < 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ led_status_eco_amber: status_eco_amber {
