[OpenWrt-Devel] [PATCH 3/4 RFCv2] net: dsa: realtek-smi: Add Realtek SMI driver

[Linus Walleij]

This adds a driver core for the Realtek SMI chips and a subdriver
for the RTL8366RB. I just added this chip simply because it is
all I can test.

The code is a massaged variant of the code that has been sitting
out-of-tree in OpenWRT for years in the absence of a proper switch
subsystem. I have tried to credit the original authors wherever
possible.

The main changes I've done from the OpenWRT code:
- Added a callback to set the MAC address.
- Added an IRQ chip inside the RTL8366RB switch to demux and
  handle the line state IRQs.
- Distributed the phy handling out to the PHY driver.
- Added some RTL8366RB code that was missing in the driver at
  the time, such as setting up "green ethernet" with a funny
  jam table and forcing MAC5 (the CPU port) into 1 GBit.
- Select jam table and add the default jam table from the
  vendor driver, also for ASIC "version 0" if need be.
- Do not store jam tables in the device tree, store them
  in the driver.
- Pick in the "initvals" jam tables from OpenWRT's driver
  and make those get selected per compatible for the
  whole system. It's apparently about electrical settings
  for this system and whatnot, not really configuration
  from device tree.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv1->RFCv2:
- Create the internal MDIO bus from the new MDIO node in
  the device tree
- Support disabling all LEDs and LED setup
- Run the per-device "jam tables" to set up registers to
  initial predictable states.
- Fix a bunch of warnings from the static checkers that
  picked up the RFC patch for test immediately
---
 drivers/net/dsa/Kconfig   |   12 +
 drivers/net/dsa/Makefile  |2 +
 drivers/net/dsa/realtek-smi.c |  488 
 drivers/net/dsa/realtek-smi.h |  146 
 drivers/net/dsa/rtl8366.c |  524 
 drivers/net/dsa/rtl8366rb.c   | 1411 +
 drivers/net/phy/realtek.c |1 +
 7 files changed, 2584 insertions(+)
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 2b81b97e994f..a8a10a288939 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -52,6 +52,18 @@ config NET_DSA_QCA8K
  This enables support for the Qualcomm Atheros QCA8K Ethernet
  switch chips.
 
+config NET_DSA_RTK_SMI
+   tristate "Realtek SMI Ethernet switch family support"
+   depends on NET_DSA
+   # FIXME: select NET_DSA_TAG_RTK
+   select FIXED_PHY
+   select IRQ_DOMAIN
+   select REALTEK_PHY
+   select NET_DSA_TAG_TRAILER
+   ---help---
+ This enables support for the Realtek SMI-based switch
+ chips, currently only RTL8366RB.
+
 config NET_DSA_SMSC_LAN9303
tristate
select NET_DSA_TAG_LAN9303
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 15c2a831edf1..0582a57e1545 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -8,6 +8,8 @@ endif
 obj-$(CONFIG_NET_DSA_MT7530)   += mt7530.o
 obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
 obj-$(CONFIG_NET_DSA_QCA8K)+= qca8k.o
+obj-$(CONFIG_NET_DSA_RTK_SMI)  += realtek.o
+realtek-objs   := realtek-smi.o rtl8366.o rtl8366rb.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
diff --git a/drivers/net/dsa/realtek-smi.c b/drivers/net/dsa/realtek-smi.c
new file mode 100644
index ..2c9d23cf7423
--- /dev/null
+++ b/drivers/net/dsa/realtek-smi.c
@@ -0,0 +1,488 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Realtek Simple Management Interface (SMI) driver
+ * It can be discussed how "simple" this interface is.
+ *
+ * The SMI protocol piggy-backs the MDIO MDC and MDIO signals levels
+ * but the protocol is not MDIO at all. Instead it is a Realtek
+ * pecularity that need to bit-bang the lines in a special way to
+ * communicate with the switch.
+ *
+ * ASICs we intend to support with this driver:
+ *
+ * RTL8366   - The original version, apparently
+ * RTL8369   - Similar enough to have the same datsheet as RTL8366
+ * RTL8366RB - Probably reads out "RTL8366 revision B", has a quite
+ * different register layout from the other two
+ * RTL8366S  - Is this "RTL8366 super"?
+ * RTL8367   - Has an OpenWRT driver as well
+ * RTL8368S  - Seems to be an alternative name for RTL8366RB
+ * RTL8370   - Also uses SMI
+ *
+ * Copyright (C) 2017 Linus Walleij 
+ * Copyright (C) 2010 Antti Seppälä 
+ * Copyright (C) 2010 Roman Yeryomin 
+ * Copyright (C) 2011 Colin Leitner 
+ * Copyright (C) 2009-2010 Gabor Juhos 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[OpenWrt-Devel] [PATCH 2/4 RFCv2] net: dsa: Add bindings for Realtek SMI DSAs

[Linus Walleij]

The Realtek SMI family is a set of DSA chips that provide
switching in routers. This binding just follows the pattern
set by other switches but with the introduction of an embedded
irqchip to demux and handle the interrupts fired by the single
line from the chip.

This interrupt construction is similar to how we handle
interrupt controllers inside PCI bridges etc.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv1->RFCv2:
- Switch to Andrew's suggestion to have a local MDIO bus
  definition inside of the DSA device node
- Add realtek,disabled-leds
- Correct WAN IRQ to 12 in the example
---
 .../bindings/net/dsa/realtek-smi.txt  | 153 ++
 1 file changed, 153 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt

diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt 
b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
new file mode 100644
index ..b6ae8541bd55
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
@@ -0,0 +1,153 @@
+Realtek SMI-based Switches
+==
+
+The SMI "Simple Management Interface" is a two-wire protocol using
+bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
+not use the MDIO protocol. This binding defines how to specify the
+SMI-based Realtek devices.
+
+Required properties:
+
+- compatible: must be exactly one of:
+  "realtek,rtl8366"
+  "realtek,rtl8366rb" (4+1 ports)
+  "realtek,rtl8366s"  (4+1 ports)
+  "realtek,rtl8367"
+  "realtek,rtl8367b"
+  "realtek,rtl8368s"  (8 port)
+  "realtek,rtl8369"
+  "realtek,rtl8370"   (8 port)
+
+Required properties:
+- mdc-gpios: GPIO line for the MDC clock line.
+- mdio-gpios: GPIO line for the MDIO data line.
+- reset-gpios: GPIO line for the reset signal.
+
+Optional properties:
+- realtek,disable-leds: if the LED drivers are not used in the
+  hardware design this will disable them so they are not turned on
+  and wasting power.
+
+Required subnodes:
+
+- interrupt-controller
+
+  This defines an interrupt controller with an IRQ line (typically
+  a GPIO) that will demultiplex and handle the interrupt from the single
+  interrupt line coming out of one of the SMI-based chips. It most
+  importantly provides link up/down interrupts to the PHY blocks inside
+  the ASIC.
+
+Required properties of interrupt-controller:
+
+- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
+- interrupt-controller: see interrupt-controller/interrupts.txt
+- #address-cells: should be <0>
+- #interrupt-cells: should be <1>
+
+- mdio
+
+  This defines the internal MDIO bus of the SMI device, mostly for the
+  purpose of being able to hook the interrupts to the right PHY and
+  the right PHY to the corresponding port.
+
+Required properties of mdio:
+
+- compatible: should be set to "realtek,smi-mdio" for all SMI devices
+
+See net/mdio.txt for additional MDIO bus properties.
+
+See net/dsa/dsa.txt for a list of additional required and optional properties
+and subnodes of DSA switches.
+
+Examples:
+
+switch {
+   compatible = "realtek,rtl8366rb";
+   /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+   mdc-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   mdio-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+
+   switch_intc: interrupt-controller {
+   /* GPIO 15 provides the interrupt */
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   port@0 {
+   reg = <0>;
+   label = "lan0";
+   phy-handle = <>;
+   };
+   port@1 {
+   reg = <1>;
+   label = "lan1";
+   phy-handle = <>;
+   };
+   port@2 {
+   reg = <2>;
+   label = "lan2";
+   phy-handle = <>;
+   };
+   port@3 {
+   reg = <3>;
+   label = "lan3";
+   phy-handle = <>;
+   };
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   phy-handle = <>;
+   };
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <>;
+   phy-mode = "rgmii";
+   fixed-link {
+   speed = <1000>;
+ 

[OpenWrt-Devel] [PATCH 1/4 RFCv2] net: phy: realtek: Support RTL8366RB variant

[Linus Walleij]

The RTL8366RB is an ASIC with five internal PHYs for
LAN0..LAN3 and WAN. The PHYs are spawn off the main
device so they can be handled in a distributed manner
by the Realtek PHY driver. All that is really needed
is the power save feature enablement and letting the
PHY driver core pick up the IRQ from the switch chip.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv1->RFCv2:
- No real changes.
---
 drivers/net/phy/realtek.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 9f48ecf9c627..21624d1c9d38 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -37,6 +37,9 @@
 #define RTL8201F_ISR   0x1e
 #define RTL8201F_IER   0x13
 
+#define RTL8366RB_POWER_SAVE   0x21
+#define RTL8366RB_POWER_SAVE_ON 0x1000
+
 MODULE_DESCRIPTION("Realtek PHY driver");
 MODULE_AUTHOR("Johnson Leung");
 MODULE_LICENSE("GPL");
@@ -145,6 +148,22 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return phy_modify_paged(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, val);
 }
 
+static int rtl8366rb_config_init(struct phy_device *phydev)
+{
+   int ret;
+   u16 reg;
+
+   ret = genphy_config_init(phydev);
+   if (ret < 0)
+   return ret;
+
+   reg = phy_read(phydev, RTL8366RB_POWER_SAVE);
+   reg |= RTL8366RB_POWER_SAVE_ON;
+   phy_write(phydev, RTL8366RB_POWER_SAVE, reg);
+
+   return 0;
+}
+
 static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x8201,
@@ -207,6 +226,18 @@ static struct phy_driver realtek_drvs[] = {
.resume = genphy_resume,
.read_page  = rtl821x_read_page,
.write_page = rtl821x_write_page,
+   }, {
+   /* The main part of this DSA is in drivers/net/dsa */
+   .phy_id = 0x001cc961,
+   .name   = "RTL8366RB Gigabit Ethernet",
+   .phy_id_mask= 0x001f,
+   .features   = PHY_GBIT_FEATURES,
+   .flags  = PHY_HAS_INTERRUPT,
+   .config_aneg= _config_aneg,
+   .config_init= _config_init,
+   .read_status= _read_status,
+   .suspend= genphy_suspend,
+   .resume = genphy_resume,
},
 };
 
@@ -218,6 +249,7 @@ static struct mdio_device_id __maybe_unused realtek_tbl[] = 
{
{ 0x001cc914, 0x001f },
{ 0x001cc915, 0x001f },
{ 0x001cc916, 0x001f },
+   { 0x001cc961, 0x001f },
{ }
 };
 
-- 
2.17.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Daniel Golle]

Hi!

On Mon, May 28, 2018 at 02:50:40PM +0200, Stanislaw Gruszka wrote:
> I have some updates here.
> 
> ...
> Another issue is that sometimes we do not sent rate probe frames,
> I posted fix for that (revert of my older change):
> https://marc.info/?l=linux-wireless=152750671715369=2 
> This patch improve performance when mt7620 is connected with Intel iwl7265
> device. With the patch I have 70 Mbits/sec compared to about 17 Mbits/sec
> before. Perhaps it also fix stability issues.

Oh goodness, I didn't expect anything like that to still happen at
this stage. Thanks a lot for investigating the issue!
I've imported the patch to OpenWrt git:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f4a639a3d7d40b4f63c431c2d554c479fbcc6b74

Once we got some feedback from users (please test!) we can push that
also to still be part of the openwrt-18.06 release.

Cheers

Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LEDE 17.01.5 release planning -> WNR2000v3 broken

[Aaron Z]

On Sun, May 27, 2018 at 12:19 PM, Hauke Mehrtens  wrote:
> On 05/25/2018 12:27 PM, Stijn Segers wrote:
>> Hi Hauke,
>> WNR2000v3 images are still being built but sysupgrading them from old 
>> versions seems broken, maybe someone could look into this? With 18.06 around 
>> the corner as well, might be handy to have this fixed.
>> https://bugs.openwrt.org/index.php?do=details_id=672=WNR2000
> Thank you for the information. Does someone want to fix this device,
> otherwise I would remove it from the lede-17.01 branch in the next days.
> I do not have a WNR2000v3.
If someone wants to fix it, I have a one that has been sitting my
shelf for a while and a serial adapter. Point me to an image and I
load it and test it.

Aaron Z

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] curl: Use ca-bundle for all TLS libraries.

[Kevin Darbyshire-Bryant via openwrt-devel]

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 ---


> On 27 May 2018, at 23:13, Rosen Penev  wrote:
> 
> It simplifies the Makefile a bit. In addition, using ca-bundle
> saves some space as well.
> 
> It also fixes an issue with at least transmission, which has a dependency
> on ca-bundle, but currently libcurl with OpenSSL or GnuTLS cause it not
> to work.
> 
> This has been tested on mt7621 with OpenSSL and GnuTLS just by running
> 'curl https://www.google.com' and seeing if there's a verify error.
> The rest are already using ca-bundle and therefore work fine.
> 
> Signed-off-by: Rosen Penev 
> ---
> package/network/utils/curl/Makefile | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/package/network/utils/curl/Makefile 
> b/package/network/utils/curl/Makefile
> index 92b3cab7dd..ae8cc31edc 100644
> --- a/package/network/utils/curl/Makefile
> +++ b/package/network/utils/curl/Makefile
> @@ -112,13 +112,15 @@ CONFIGURE_ARGS += \
>   --without-libmetalink \
>   --without-librtmp \
>   --without-libidn \
> + --without-ca-path \
> + --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \
>   \
>   $(call autoconf_bool,CONFIG_IPV6,ipv6) \
>   \
> - $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr" 
> --without-ca-path 
> --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-cyassl) \
> - $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr" 
> --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-gnutls) \
> - $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr" 
> --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-ssl) \
> - $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr" 
> --without-ca-path 
> --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-mbedtls) \
> + $(if 
> $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr",--without-cyassl)
>  \
> + $(if 
> $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) 
> \
> + $(if 
> $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr",--without-ssl) \
> + $(if 
> $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr",--without-mbedtls)
>  \
>   \
>   $(if 
> $(CONFIG_LIBCURL_LIBIDN2),--with-libidn2="$(STAGING_DIR)/usr",--without-libidn2)
>  \
>   $(if 
> $(CONFIG_LIBCURL_SSH2),--with-libssh2="$(STAGING_DIR)/usr",--without-libssh2) 
> \
> --
> 2.17.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel


Works for me and has solved a long annoying issue of needing both ca-bundle & 
ca-certs installed (ddns-scripts v znc), hence taking twice the space in rom.

Tested-by: Kevin Darbyshire-Bryant 


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver

[Linus Walleij]

This is a second RFC version of the DSA driver for Realtek
RTL8366x especially RTL8366RB.

I've been beating my head against this one and I'm not really
clear on why my ethernet frames are not coming through to the
CPU port on the chip.

It appears when using ethtool -S on the ports that packets
are passing fine into the router fabric and through to the
CPU port but the ethernet driver where the fixed link is
connected refuse to accept the packages.

Of course packages needs VLAN tagging/untagging, this is not
the problem as it seems. The OpenWRT userspace even kicks
the interface in promiscuous mode so all packages should be
accepted, I also tried tcpdump on the interface to no avail:
the ethernet frames are so broken that they do not even make
it through the fixed link.

The do cause error statistics on the ethernet port on the
system side.

It might very well be that the problem is on the ethernet
driver side, and this driver "just works" with other
routers, so reposting it along with the DTS example so others
can try it while I keep banging my head against it. Maybe
I should just try to obtain another router with this chip
so as to establish that it is not the DSA router driver that
is wrong.

I did try this hardware with the present OpenWRT driver
(not DSA) and that failed too.

Anyways check out the new DT bindings etc.

Linus Walleij (4):
  net: phy: realtek: Support RTL8366RB variant
  net: dsa: Add bindings for Realtek SMI DSAs
  net: dsa: realtek-smi: Add Realtek SMI driver
  ARM: dts: Add ethernet and switch to D-Link DIR-685

 .../bindings/net/dsa/realtek-smi.txt  |  153 ++
 arch/arm/boot/dts/gemini-dlink-dir-685.dts|  153 +-
 drivers/net/dsa/Kconfig   |   12 +
 drivers/net/dsa/Makefile  |2 +
 drivers/net/dsa/realtek-smi.c |  488 ++
 drivers/net/dsa/realtek-smi.h |  146 ++
 drivers/net/dsa/rtl8366.c |  524 ++
 drivers/net/dsa/rtl8366rb.c   | 1411 +
 drivers/net/phy/realtek.c |   33 +
 9 files changed, 2921 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

-- 
2.17.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver

[Andrew Lunn]

On Mon, May 28, 2018 at 07:47:48PM +0200, Linus Walleij wrote:
> This is a second RFC version of the DSA driver for Realtek
> RTL8366x especially RTL8366RB.
> 
> I've been beating my head against this one and I'm not really
> clear on why my ethernet frames are not coming through to the
> CPU port on the chip.
> 
> It appears when using ethtool -S on the ports that packets
> are passing fine into the router fabric and through to the
> CPU port but the ethernet driver where the fixed link is
> connected refuse to accept the packages.

Hi Linus

Have you played with RGMII delays?

   Andrew

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4 RFCv2] ARM: dts: Add ethernet and switch to D-Link DIR-685

[Linus Walleij]

This adds the Ethernet and Realtek switch device to the
D-Link DIR-685 Gemini-based device.

Signed-off-by: Linus Walleij 
---
ChangeLog RFCv1->RFCv2
- Rebased, use the new DT bindings
---
 arch/arm/boot/dts/gemini-dlink-dir-685.dts | 153 -
 1 file changed, 152 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts 
b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
index fb5c954ab95a..ccbe03c05c2a 100644
--- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -156,6 +156,100 @@
};
};
 
+   /* This is a RealTek RTL8366RB switch and PHY using SMI over GPIO */
+   switch {
+   compatible = "realtek,rtl8366rb";
+   /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+   mdc-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   mdio-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+   realtek,disable-leds;
+
+   switch_intc: interrupt-controller {
+   /* GPIO 15 provides the interrupt */
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   label = "lan0";
+   phy-handle = <>;
+   };
+   port@1 {
+   reg = <1>;
+   label = "lan1";
+   phy-handle = <>;
+   };
+   port@2 {
+   reg = <2>;
+   label = "lan2";
+   phy-handle = <>;
+   };
+   port@3 {
+   reg = <3>;
+   label = "lan3";
+   phy-handle = <>;
+   };
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   phy-handle = <>;
+   };
+   rtl8366rb_cpu_port: port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <>;
+   phy-mode = "rgmii";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   pause;
+   };
+   };
+
+   };
+
+   mdio {
+   compatible = "realtek,smi-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy0: phy@0 {
+   reg = <0>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
+   };
+   phy1: phy@1 {
+   reg = <1>;
+   interrupt-parent = <_intc>;
+   interrupts = <1>;
+   };
+   phy2: phy@2 {
+   reg = <2>;
+   interrupt-parent = <_intc>;
+   interrupts = <2>;
+   };
+   phy3: phy@3 {
+   reg = <3>;
+   interrupt-parent = <_intc>;
+   interrupts = <3>;
+   };
+   phy4: phy@4 {
+   reg = <4>;
+   interrupt-parent = <_intc>;
+   interrupts = <12>;
+   };
+   };
+   };
+
soc {
flash@3000 {
/*
@@ -223,10 +317,12 @@
 * gpio0bgrp cover line 7 used by WPS LED
 * gpio0cgrp cover line 8, 13 used by keys
 *   and 11, 12 used by the HD LEDs
+*   and line 14, 15 used by RTL8366
+*   RESET and phy ready
 * gpio0egrp cover line 16 used by VDISP
 * gpio0fgrp cover line 17 used by TK IRQ
 * 

Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver

[Lucian Cristian]

On 28.05.2018 20:47, Linus Walleij wrote:

This is a second RFC version of the DSA driver for Realtek
RTL8366x especially RTL8366RB.

I've been beating my head against this one and I'm not really
clear on why my ethernet frames are not coming through to the
CPU port on the chip.

It appears when using ethtool -S on the ports that packets
are passing fine into the router fabric and through to the
CPU port but the ethernet driver where the fixed link is
connected refuse to accept the packages.

Of course packages needs VLAN tagging/untagging, this is not
the problem as it seems. The OpenWRT userspace even kicks
the interface in promiscuous mode so all packages should be
accepted, I also tried tcpdump on the interface to no avail:
the ethernet frames are so broken that they do not even make
it through the fixed link.

The do cause error statistics on the ethernet port on the
system side.

It might very well be that the problem is on the ethernet
driver side, and this driver "just works" with other
routers, so reposting it along with the DTS example so others
can try it while I keep banging my head against it. Maybe
I should just try to obtain another router with this chip
so as to establish that it is not the DSA router driver that
is wrong.

I did try this hardware with the present OpenWRT driver
(not DSA) and that failed too.

Anyways check out the new DT bindings etc.

Linus Walleij (4):
   net: phy: realtek: Support RTL8366RB variant
   net: dsa: Add bindings for Realtek SMI DSAs
   net: dsa: realtek-smi: Add Realtek SMI driver
   ARM: dts: Add ethernet and switch to D-Link DIR-685

  .../bindings/net/dsa/realtek-smi.txt  |  153 ++
  arch/arm/boot/dts/gemini-dlink-dir-685.dts|  153 +-
  drivers/net/dsa/Kconfig   |   12 +
  drivers/net/dsa/Makefile  |2 +
  drivers/net/dsa/realtek-smi.c |  488 ++
  drivers/net/dsa/realtek-smi.h |  146 ++
  drivers/net/dsa/rtl8366.c |  524 ++
  drivers/net/dsa/rtl8366rb.c   | 1411 +
  drivers/net/phy/realtek.c |   33 +
  9 files changed, 2921 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
  create mode 100644 drivers/net/dsa/realtek-smi.c
  create mode 100644 drivers/net/dsa/realtek-smi.h
  create mode 100644 drivers/net/dsa/rtl8366.c
  create mode 100644 drivers/net/dsa/rtl8366rb.c

I have a very strange problem with this switch too, porting the 
1043nd-v1 ar71xx target to ath79 dts using the *standard* drivers (John 
validated that they work in that config), I can see the packets on the 
interface but no actual traffic routed or accepted, from time to time, 
after a power off, the exact image is working, then after 2-3 reboots is 
not working anymore.


I'll try the dsa drivers on the new ath79 target and come back at you

Regards


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath10k-firmware: Fix typo in last commit

[Mathias Kresin]

2018-05-27 19:21 GMT+03:00 Rosen Penev :
> Signed-off-by: Rosen Penev 
> ---
>  package/firmware/ath10k-firmware/Makefile | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/package/firmware/ath10k-firmware/Makefile 
> b/package/firmware/ath10k-firmware/Makefile
> index 2c024905bb..35f6013947 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -452,8 +452,6 @@ define Package/ath10k-firmware-qca6174/install
> $(INSTALL_DATA)

Shouldn't it be "$(INSTALL_DATA) \", similar to all the other install defines?

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dont drop support of working devices, fix the build system

[John Crispin]

On 28/05/18 17:40, wnr200...@memeware.net wrote:
I reported here an issue with the build system creating too big 
images: 
https://forum.lede-project.org/t/help-required-to-fix-bug-porting-from-legacy-to-generic-build-form-wnr2000v3-4-32-device/14693


Borromini then reported this here: 
https://lists.infradead.org/pipermail/openwrt-devel/2018-May/012514.html


And now you want to thank me for reporting this by dropping support 
for my device here? 
https://lists.infradead.org/pipermail/openwrt-devel/2018-May/012554.html


The device is working perfectly fine with all the snapshot builds. Its 
the build-system that have to be fixed to not create images that are 
too big. An advanced user told me that the device should be just 
ported from openwrt/target/linux/ar71xx/image/legacy.mk to 
openwrt/target/linux/ar71xx/image/generic.mk . He told that the modern 
build system have this check for the size.


All i write here is already been written once in the forum post i 
linked above.





Let me rephrase that for you ...

Hi All,

thanks for spending your free time to respond to my report. I think that 
dropping the board is not the best option. I am not a developer myself 
but I am happy to help test patches/image. I hope that the board can be 
kept on the list of supported devices as it is working perfectly well.


Kind regards
    wnr2000v3 user

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Dont drop support of working devices, fix the build system

[wnr2000v3]

I reported here an issue with the build system creating too big images: 
https://forum.lede-project.org/t/help-required-to-fix-bug-porting-from-legacy-to-generic-build-form-wnr2000v3-4-32-device/14693


Borromini then reported this here: 
https://lists.infradead.org/pipermail/openwrt-devel/2018-May/012514.html


And now you want to thank me for reporting this by dropping support for 
my device here? 
https://lists.infradead.org/pipermail/openwrt-devel/2018-May/012554.html


The device is working perfectly fine with all the snapshot builds. Its 
the build-system that have to be fixed to not create images that are too 
big. An advanced user told me that the device should be just ported from 
openwrt/target/linux/ar71xx/image/legacy.mk to 
openwrt/target/linux/ar71xx/image/generic.mk . He told that the modern 
build system have this check for the size.


All i write here is already been written once in the forum post i linked 
above.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iwinfo: Check DFS support before enabling DFS channels

[Krishna Chaitanya]

On Mon, Jan 16, 2017 at 1:10 AM, Krishna Chaitanya
 wrote:
>
> On Sun, Jan 15, 2017 at 6:35 PM, Chaitanya Tata
>  wrote:
> >
> > Before enabling the DFS channels looks for support of DFS
> > in interface combinations, NO_IR and DFS flags.
> >
> > Currently BW level checks are not supported.
> >
> > Tested-by: Tushar Jobanputra 
> > Signed-off-by: Chaitanya Tata 
> > ---
> > Fix signed tag.
> > ---
> >  iwinfo_nl80211.c | 65 
> > ++--
> >  1 file changed, 59 insertions(+), 6 deletions(-)
> >
> > diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> > index 63b70d5..d8d2670 100644
> > --- a/iwinfo_nl80211.c
> > +++ b/iwinfo_nl80211.c
> > @@ -2404,20 +2404,71 @@ static int nl80211_get_scanlist(const char *ifname, 
> > char *buf, int *len)
> > return -1;
> >  }
> >
> > +char *channel_width_name(enum nl80211_chan_width width)
> > +{
> > +   switch (width) {
> > +   case NL80211_CHAN_WIDTH_20_NOHT:
> > +   return "20 MHz (no HT)";
> > +   case NL80211_CHAN_WIDTH_20:
> > +   return "20 MHz";
> > +   case NL80211_CHAN_WIDTH_40:
> > +   return "40 MHz";
> > +   case NL80211_CHAN_WIDTH_80:
> > +   return "80 MHz";
> > +   case NL80211_CHAN_WIDTH_80P80:
> > +   return "80+80 MHz";
> > +   case NL80211_CHAN_WIDTH_160:
> > +   return "160 MHz";
> > +   default:
> > +   return "unknown";
> > +   }
> > +}
> > +
>
> I just realized that i am not using this function, it was left over
> from debug prints.
>
> >
> > nla_for_each_nested(band, attr[NL80211_ATTR_WIPHY_BANDS], 
> > bands_remain)
> > {
> > +   struct nlattr *is_ir,*is_dfs;
> Technically this should be is_no_ir?
>
> Will await further comments and then submit a V2.



the patch says "changed requested" but no review comments received,
should I submit v2?

https://patchwork.ozlabs.org/project/openwrt/list/?series==23866=*===

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] brcm2708: add squashfs rootfs image

[Daniel Golle]

Hi!

On Tue, Apr 24, 2018 at 04:59:34PM +0200, Christian Lamparter wrote:
> ...
> this patch is therefore no longer necessary since it the existing ext4
> images work as well. :) ... Plus the ext4 images don't confuse tools and
> brains as much.

While this assumption might hold true for some people (apparently all
of them Rasbpi users), it is currently an exception from OpenWrt's
point of view (probably because most users flash their devices by
removing the microSD and writing it via another device rather than
on-target system upgrades, no even speaking about remote and/or
over-the-air upgrades...).

Imho it would still be very nice to at least have the option for
overlayfs-based images on all targets because otherwise we kill some
of the features OpenWrt-users have learned to rely on, such as
the robustness of preinit, availability of recovery in case of
misconfiguration, factory-reset/firstboot, snapshots, ...
While this might not be so much of an issue for people using the
rasbpi as a devboard, it does make things more difficult for people
building end-user-ready devices based on that hardware.


Cheers


Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Kevin Darbyshire-Bryant via openwrt-devel]

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 ---


> On 28 May 2018, at 14:52, Mauro Mozzarelli  wrote:
> 
> Neither it is to post an arrogant reply which is the only type of reply I get 
> usually from Jo-Philipp as this isn't the first time. You reap what you seed 
> guys.

Oh dear.

This is somewhat frustrating for me as I have a HH5a but no ADSL line to test 
it on.  The mention of VCI/VPI 0.38 suggests this is UK, where I also am.  The 
VDSL line (SKY isp) I have won’t do ADSL and hence PPPoA for testing.

I have a local-ish ‘tame’ ISP (AAISP) who might let me visit the office and try 
a test line there… but I’d have to book & arrange it.

Or I could get a second line installed at home for £130+ for a month.   H.  
Would be good to have a UK based tester of ADSL/BT/Openwrt compatibility.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Alberto Bursi]

On 28/05/2018 15:52, Mauro Mozzarelli wrote:
Neither it is to post an arrogant reply which is the only type of 
reply I get usually from Jo-Philipp as this isn't the first time. You 
reap what you seed guys.





Where you see arrogance in Jo-Philipp's mail? He is just stating facts, 
it's not enough info, he has no hardware to test, and you have no right 
to ask for someone to do it for free in their own free time.


-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Mauro Mozzarelli]

Neither it is to post an arrogant reply which is the only type of reply 
I get usually from Jo-Philipp as this isn't the first time. You reap 
what you seed guys.



On 28/05/18 14:34, John Crispin wrote:



On 28/05/18 15:29, Jo-Philipp Wich wrote:

Hi,


This does not make sense, is the alternative to write off openwrt?
Because if ADSL + PPPoA do not work, then it is useless.

Indeed, if OpenWrt does not work for your device then you should look
for alternatives or try to dig into the issue yourself.


As a minimum I would expect a developer to look at the commits
between r6080 and r7050 to see what has changed and roll-back.

Lets see... that is a range of 970 commits, with an estimated average of
2 minutes to review each commit that'd be 1940 minutes worth of work.

Given roughly 3 hours daily spare time (weekends excluded) one can
devote to OpenWrt it'd about 2 weeks worth of development time to track
down this sole bug.

That is quite a lot you expect as a minimum. It also not even clear if
any of these commits can be clearly attributed to your problem at hand.

Regards,
Jo


Dear Mauro,

may I also add that top posting a ranty mail is certainly not the best 
way to get people to help you. That is like walking into the shop 
spitting on the floor, demanding immediate service and slamming the 
door on the way out. Funnily I am 100% sure you would not do so in a 
shop, so why do it on the interwebs ?


    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Moving the mailing lists

[John Crispin]

On 28/05/18 14:35, Bjørn Mork wrote:

I just tried to follow a link I had referred to in another dicussion
  ( http://lists.infradead.org/pipermail/lede-dev/2018-April/011701.html )
and got "403 Forbidden".  I note that the article now is available as
http://lists.infradead.org/pipermail/openwrt-devel/2018-April/011701.html
but that doesn't help much when the original reference is in another
immutable document.  Would it be possible to restore the old lede-dev
URLs for the part of the archive which used to be lede-dev?  Or is that
too hard to be worth the effort?
  
All the stale forum.openwrt.org links are bad enough.  Didn't need

another set of stale openwrt doc links...

Thanks,
Bjørn




We'll ask David to add a rewrite rule, thanks for pointing this out !

    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[John Crispin]

On 28/05/18 15:29, Jo-Philipp Wich wrote:

Hi,


This does not make sense, is the alternative to write off openwrt?
Because if ADSL + PPPoA do not work, then it is useless.

Indeed, if OpenWrt does not work for your device then you should look
for alternatives or try to dig into the issue yourself.


As a minimum I would expect a developer to look at the commits
between r6080 and r7050 to see what has changed and roll-back.

Lets see... that is a range of 970 commits, with an estimated average of
2 minutes to review each commit that'd be 1940 minutes worth of work.

Given roughly 3 hours daily spare time (weekends excluded) one can
devote to OpenWrt it'd about 2 weeks worth of development time to track
down this sole bug.

That is quite a lot you expect as a minimum. It also not even clear if
any of these commits can be clearly attributed to your problem at hand.

Regards,
Jo


Dear Mauro,

may I also add that top posting a ranty mail is certainly not the best 
way to get people to help you. That is like walking into the shop 
spitting on the floor, demanding immediate service and slamming the door 
on the way out. Funnily I am 100% sure you would not do so in a shop, so 
why do it on the interwebs ?


    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Jaap Buurman]

On Mon, May 28, 2018 at 3:27 PM, Mauro Mozzarelli  wrote:
> I will be happy to help. How do I do it?
>
> I mean, I have a backup of the master folder for r6080, since I keep a full
> copy of every successful build that I then run on my routers. How do I pull
> just one release at a time, like r6081, r6082, etc.? That is the best I
> could do, build the releases one by one until I find the one that fails.
>
>
> Mauro
>
>
>
> On 28/05/18 14:17, Jaap Buurman wrote:
>>
>> On Mon, May 28, 2018 at 3:12 PM, Mauro Mozzarelli 
>> wrote:
>>>
>>> This does not make sense, is the alternative to write off openwrt?
>>> Because
>>> if ADSL + PPPoA do not work, then it is useless.
>>>
>>> As a minimum I would expect a developer to look at the commits between
>>> r6080
>>> and r7050 to see what has changed and roll-back.
>>>
>>> Also if you need any further information, just ask and provide guidance
>>> on
>>> how to get it.
>>> If you would like the hardware I can arrange for it to be shipped to you.
>>>
>>> Mauro
>>>
>>>
>>>
>>> On 28/05/18 14:02, Jo-Philipp Wich wrote:

 Hi,

> Is anyone looking into it?

 I doubt it, unfortunately the info in the ticket is too vague to work
 with. Personally I don't have any hardware to debug this.

 ~ Jo

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 http://lists.infradead.org/mailman/listinfo/openwrt-devel
>>>
>>>
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> http://lists.infradead.org/mailman/listinfo/openwrt-devel
>>
>> Dear Mauro,
>>
>> Going through nearly 1000 commits without knowing what to look for is
>> very difficult and not very time efficient. The easiest way for you to
>> help track down this issue would be to do a Git bisect from r6080 to
>> r7050 until you find the specific commit that breaks PPPoA. It would
>> be much easier to debug/fix if a developer knows which particular
>> commit breaks stuff :)
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>
>

I don't know the commands by heart, so you will have to look up the
specific commands. But basically:

1) use git to clone the repository
2) mark the last known good commit
3) mark the first known bad commit
4) git will then pick one commit in the middle, so in this case
r6500ish. You compile that image:
https://openwrt.org/docs/guide-developer/quickstart-build-images
5) you test the image and mark it as good/bad. Git will then pick a
new commit r6250ish or 6750ish depending on whether the previous one
was bad/good.

Since you halve the search space each attempt, it shouldn't take that
many attempts to track down the specific commit that broke it within
1000 commits.

Good luck :)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Jo-Philipp Wich]

Hi,

> This does not make sense, is the alternative to write off openwrt? 
> Because if ADSL + PPPoA do not work, then it is useless.

Indeed, if OpenWrt does not work for your device then you should look
for alternatives or try to dig into the issue yourself.

> As a minimum I would expect a developer to look at the commits
> between r6080 and r7050 to see what has changed and roll-back.

Lets see... that is a range of 970 commits, with an estimated average of
2 minutes to review each commit that'd be 1940 minutes worth of work.

Given roughly 3 hours daily spare time (weekends excluded) one can
devote to OpenWrt it'd about 2 weeks worth of development time to track
down this sole bug.

That is quite a lot you expect as a minimum. It also not even clear if
any of these commits can be clearly attributed to your problem at hand.

Regards,
Jo

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Jaap Buurman]

On Mon, May 28, 2018 at 3:12 PM, Mauro Mozzarelli  wrote:
> This does not make sense, is the alternative to write off openwrt? Because
> if ADSL + PPPoA do not work, then it is useless.
>
> As a minimum I would expect a developer to look at the commits between r6080
> and r7050 to see what has changed and roll-back.
>
> Also if you need any further information, just ask and provide guidance on
> how to get it.
> If you would like the hardware I can arrange for it to be shipped to you.
>
> Mauro
>
>
>
> On 28/05/18 14:02, Jo-Philipp Wich wrote:
>>
>> Hi,
>>
>>> Is anyone looking into it?
>>
>> I doubt it, unfortunately the info in the ticket is too vague to work
>> with. Personally I don't have any hardware to debug this.
>>
>> ~ Jo
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.infradead.org/mailman/listinfo/openwrt-devel
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel

Dear Mauro,

Going through nearly 1000 commits without knowing what to look for is
very difficult and not very time efficient. The easiest way for you to
help track down this issue would be to do a Git bisect from r6080 to
r7050 until you find the specific commit that breaks PPPoA. It would
be much easier to debug/fix if a developer knows which particular
commit breaks stuff :)

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Mauro Mozzarelli]

This does not make sense, is the alternative to write off openwrt? 
Because if ADSL + PPPoA do not work, then it is useless.


As a minimum I would expect a developer to look at the commits between 
r6080 and r7050 to see what has changed and roll-back.


Also if you need any further information, just ask and provide guidance 
on how to get it.

If you would like the hardware I can arrange for it to be shipped to you.

Mauro


On 28/05/18 14:02, Jo-Philipp Wich wrote:

Hi,


Is anyone looking into it?

I doubt it, unfortunately the info in the ticket is too vague to work
with. Personally I don't have any hardware to debug this.

~ Jo

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Jo-Philipp Wich]

Hi,

> Is anyone looking into it?

I doubt it, unfortunately the info in the ticket is too vague to work
with. Personally I don't have any hardware to debug this.

~ Jo

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050

[Mauro Mozzarelli]

Hello,


I reported https://bugs.openwrt.org/index.php?do=details_id=1567

Which is a blocking issue for BT Home Hub 5 as pppoa no longer connects. 
Is anyone looking into it?


Thanks.

Mauro


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Moving the mailing lists

[Bjørn Mork]

I just tried to follow a link I had referred to in another dicussion
 ( http://lists.infradead.org/pipermail/lede-dev/2018-April/011701.html )
and got "403 Forbidden".  I note that the article now is available as
http://lists.infradead.org/pipermail/openwrt-devel/2018-April/011701.html
but that doesn't help much when the original reference is in another
immutable document.  Would it be possible to restore the old lede-dev
URLs for the part of the archive which used to be lede-dev?  Or is that
too hard to be worth the effort?
 
All the stale forum.openwrt.org links are bad enough.  Didn't need
another set of stale openwrt doc links...

Thanks,
Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

Dear Mathias,

I can confirm your patch is working fine. I am able to set a mtu of
1508 on the switch, giving me a mtu of 1500 on the pppoe-wan
connection. I am now able to ping 1472 bytes with the DF flag set. The
patch in question:
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

Thank you very much for your work :)

@the rest

I was able to flash simply by disabling all my WiFi interfaces. It's a
dirty workaround and should be fixed before a 18.06 release IMO, but
at least we managed to track down what's causing the issue :)

Yours sincerely,

Jaap Buurman

On Sat, May 26, 2018 at 9:16 AM, Kristian Evensen
 wrote:
> Hi,
>
> (Accidentally hit send)
>
> On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
>  wrote:
>>> I know how to fix the issue by recovery, however, from the responses
>>> in the topic on the Lede forum it seems more people are running into
>>> this issue. This definitely needs to be fixed before a 18.06 release.
>>> Is there someone with a mt7621 device that can reproduce the problem,
>>> and that has serial access? We might be able to figure out what is
>>> going wrong.
>
> I kept looking into this and instrumented /lib/upgrade/stage2. I added
> some output showing which processes were left for each iteration of
> the loop, as well as when "Failed to kill ..." hits. It seems that
> hostapd, for some reason, takes unexpectedly long to die:
>
> Sending TERM to remaining processes ... loop limit 10
> logd
> rpcd
> netifd
> odhcpd
> crond
> ntpd
> nginx
> nginx
> ubusd
> dnsmasq
> sh
> sh
> sh
> sshd
> sleep
> sh
> hostapd
> hostapd
> rsync
> ssh
> sleep
>
> [  115.583843] device wlan0 left promiscuous mode
> [  115.588436] br-lan: port 3(wlan0) entered disabled state
> [  115.594261] device wlan1 left promiscuous mode
> [  115.598798] br-lan: port 2(wlan1) entered disabled state
> Sending KILL to remaining processes ... loop limit 10
> hostapd
> loop limit 9
> hostapd
> loop limit 8
> hostapd
> loop limit 7
> hostapd
> loop limit 6
> hostapd
> loop limit 5
> hostapd
> loop limit 4
> hostapd
> loop limit 3
> hostapd
> loop limit 2
> hostapd
> loop limit 1
>
> Failed to kill all processes.
>   PID USER   VSZ STAT COMMAND
> 1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
> 2 root 0 SW   [kthreadd]
> 3 root 0 IW   [kworker/0:0]
> 4 root 0 IW<  [kworker/0:0H]
> 5 root 0 IW   [kworker/u8:0]
> 6 root 0 IW<  [mm_percpu_wq]
> 7 root 0 SW   [ksoftirqd/0]
> 8 root 0 IW   [rcu_sched]
> 9 root 0 IW   [rcu_bh]
>10 root 0 SW   [migration/0]
>11 root 0 SW   [cpuhp/0]
>12 root 0 SW   [cpuhp/1]
>13 root 0 SW   [migration/1]
>14 root 0 SW   [ksoftirqd/1]
>15 root 0 IW   [kworker/1:0]
>16 root 0 IW<  [kworker/1:0H]
>17 root 0 SW   [cpuhp/2]
>18 root 0 SW   [migration/2]
>19 root 0 SW   [ksoftirqd/2]
>20 root 0 IW   [kworker/2:0]
>21 root 0 IW<  [kworker/2:0H]
>22 root 0 SW   [cpuhp/3]
>23 root 0 SW   [migration/3]
>24 root 0 SW   [ksoftirqd/3]
>25 root 0 IW   [kworker/3:0]
>26 root 0 IW<  [kworker/3:0H]
>27 root 0 IW   [kworker/u8:1]
>34 root 0 IW   [kworker/u8:2]
>65 root 0 IW   [kworker/0:1]
>66 root 0 IW   [kworker/3:1]
>67 root 0 IW   [kworker/2:1]
>   136 root 0 IW   [kworker/1:1]
>   137 root 0 SW   [oom_reaper]
>   138 root 0 IW<  [writeback]
>   140 root 0 IW<  [crypto]
>   142 root 0 IW<  [kblockd]
>   157 root 0 IW   [kworker/u8:3]
>   177 root 0 IW<  [watchdogd]
>   201 root 0 SW   [kswapd0]
>   233 root 0 IW<  [pencrypt]
>   262 root 0 IW<  [pdecrypt]
>   295 root 0 SW   [spi0]
>   353 root 0 IW<  [ipv6_addrconf]
>   362 root 0 IW<  [kworker/1:1H]
>   363 root 0 IW<  [kworker/0:1H]
>   365 root 0 IW<  [kworker/3:1H]
>   366 root 0 IW<  [kworker/2:1H]
>   416 root 0 IW   [kworker/1:2]
>   417 root 0 IW   [kworker/0:2]
>   457 root 0 SWN  [jffs2_gcd_mtd6]
>   575 root 0 IW   [kworker/2:2]
>   869 root 0 IW<  [cfg80211]
>  1842 root 0 IW   [kworker/3:2]
>  7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
>  7547 root  1184 R/bin/ps
> sysupgrade abort[  124.152193] reboot: Restarting system
> ed with return code: 256
>
> With a working update, KILL usually looks like this:
> Sending KILL to remaining processes ... loop limit 10
> hostapd
> hostapd
> celerway_wd
> loop limit 9
> hostapd
> hostapd
> loop limit 8
> hostapd
> hostapd
> loop limit 7
> hostapd
> hostapd
> loop limit 6
> hostapd