Re: [OpenWrt-Devel] [PATCH v2 1/2] pinctrl/lantiq: split xway_mfp into dedicated tables

[Martin Schiller]

Hi,



Mit freundlichen Grüßen,
Kind regards

Martin Schiller
Dipl.-Inf. FH

Entwicklung
Development


TDT GmbH Tel.  +49 (0) 8703 929 00
Siemensstr. 18   Fax   +49 (0) 8703 929 201
84051 Essenbach  E-Mailmschil...@tdt.de
Germany  Internet  www.tdt.de

--
Die gesetzlichen Pflichtangaben finden Sie unter http://www.tdt.de/imprint
--

On Mon, Nov 16, 2015 at 2:06 PM, Jonas Gorski <j...@openwrt.org>
wrote:
> On Mon, Nov 16, 2015 at 12:01 PM, Martin Schiller <mschil...@tdt.de>
> wrote:
> > This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9"
> > settings into dedicated "pinctrl-ase", "pinctrl-danube",
> > "pinctrl-xrx100" and "pinctrl-xrx200" configuration tables.
> >
> > Based on the newest Lantiq Hardware Description it turend out, that
> > there are some differences in the GPIO alternative functions of the
> > Danube, xRX100 and xRX200 families, which makes it impossible to use
> only one xway_mfp table.
> >
> > This patch is also the first step to add support for the xRX300
> family.
> >
> > Signed-off-by: Martin Schiller <mschil...@tdt.de>
> > ---
> >  .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1059
> +++-
> >  .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059
> +++-
> >  2 files changed, 2098 insertions(+), 20 deletions(-)
> >
> > diff --git
> > a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> > b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> > index 84adbe6..3fc0432 100644
> > --- a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> > +++ b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
> > @@ -1,15 +1,1054 @@
> >  --- a/drivers/pinctrl/pinctrl-xway.c
> >  +++ b/drivers/pinctrl/pinctrl-xway.c
>
> (snip)
>
> > +@@ -769,9 +1153,10 @@ static struct pinctrl_gpio_range xway_gp  };
> > +
> > + static const struct of_device_id xway_match[] = {
> > +-  { .compatible = "lantiq,pinctrl-xway", .data = _cfg[0]},
> > +-  { .compatible = "lantiq,pinctrl-xr9", .data = _cfg[1]},
> > +-  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[2]},
> > ++  { .compatible = "lantiq,pinctrl-ase", .data = _cfg[0]},
> > ++  { .compatible = "lantiq,pinctrl-danube", .data =
> _cfg[1]},
> > ++  { .compatible = "lantiq,pinctrl-xrx100", .data =
> _cfg[2]},
> > ++  { .compatible = "lantiq,pinctrl-xrx200", .data =
> _cfg[3]},
>
> Unfortunately that ship has sailed, and "lantiq,pinctrl-xway" etc are
> the Documented bindings for it in upstream linux; you can't just drop
> support for the older bindings. At least you will never get this
> accepted upstream. Also if you update bindings, you need to update the
> documentation in Documentation/devicetree/bindings as well.

OK, you are right. We also need to patch the bindings and the Documentation.

"that ship has sailed": Do you mean, it's impossible to bring this changes 
upstream?

Or would it be a solution to let the pinctrl-xway and pinctrl-xr9 in the code 
and mark it as deprecated somehow?


>
>
> > +   {},
> > + };
> > + MODULE_DEVICE_TABLE(of, xway_match);

Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] pinctrl/lantiq: split xway_mfp into dedicated tables

[Martin Schiller]

This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9" settings
into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100" and
"pinctrl-xrx200" configuration tables.

Based on the newest Lantiq Hardware Description it turend out, that there are
some differences in the GPIO alternative functions of the Danube, xRX100 and
xRX200 families, which makes it impossible to use only one xway_mfp table.

This patch is also the first step to add support for the xRX300 family.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 target/linux/lantiq/dts/BTHOMEHUBV2B.dts   |2 +-
 target/linux/lantiq/dts/BTHOMEHUBV3A.dts   |2 +-
 target/linux/lantiq/dts/EASY50712.dts  |2 +-
 target/linux/lantiq/dts/EASY50810.dts  |2 +-
 target/linux/lantiq/dts/EASY80920.dtsi |2 +-
 target/linux/lantiq/dts/GR7000.dts |2 +-
 target/linux/lantiq/dts/P2601HNFX.dts  |2 +-
 target/linux/lantiq/dts/P2812HNUFX.dtsi|2 +-
 target/linux/lantiq/dts/VGV7519.dtsi   |2 +-
 target/linux/lantiq/dts/ar9.dtsi   |2 +-
 target/linux/lantiq/dts/danube.dtsi|2 +-
 target/linux/lantiq/dts/vr9.dtsi   |2 +-
 .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059 +++-
 13 files changed, 1061 insertions(+), 22 deletions(-)

diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
index 9b3180c..e2d713e 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
@@ -102,7 +102,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
index 1ae9840..9383498 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
@@ -79,7 +79,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50712.dts 
b/target/linux/lantiq/dts/EASY50712.dts
index e44267a..e0d5ed1 100644
--- a/target/linux/lantiq/dts/EASY50712.dts
+++ b/target/linux/lantiq/dts/EASY50712.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50810.dts 
b/target/linux/lantiq/dts/EASY50810.dts
index 5f4b733..73f31ea 100644
--- a/target/linux/lantiq/dts/EASY50810.dts
+++ b/target/linux/lantiq/dts/EASY50810.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY80920.dtsi 
b/target/linux/lantiq/dts/EASY80920.dtsi
index 4013610..0600d36 100644
--- a/target/linux/lantiq/dts/EASY80920.dtsi
+++ b/target/linux/lantiq/dts/EASY80920.dtsi
@@ -71,7 +71,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx200";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/GR7000.dts 
b/target/linux/lantiq/dts/GR7000.dts
index fcc27eb..bc95f1f 100644
--- a/target/linux/lantiq/dts/GR7000.dts
+++ b/target/linux/lantiq/dts/GR7000.dts
@@ -42,7 +42,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/P2601HNFX.dts 
b/target/linux/lantiq/dts/P2601HNFX.dts
index bb9193e..c22c547 100644
--- a/target/linux/lantiq/dts/P2601HNFX.dts
+++ b/target/linux/lantiq/dts/P2601HNFX.dts
@

Re: [OpenWrt-Devel] [PATCH] pinctrl/lantiq: split xway_mfp into dedicated tables

[Martin Schiller]

Hi,

ok, I will split this patch into 2 patches:

[1/2] pinctrl/lantiq: split xway_mfp into dedicated tables
[2/2] pinctrl/lantiq: adapt device-trees to new tables

Would that be ok?

To get the pinctrl patch upstream, we also have to send the 
0012-pinctrl-lantiq-fix-up-pinmux.patch upstream.
Should I do this in a patch series as well?

To whom should this patch be sent? (maintainer/mailing-list?)

Martin

-Ursprüngliche Nachricht-
Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im Auftrag 
von John Crispin
Gesendet: Montag, 16. November 2015 10:50
An: openwrt-devel@lists.openwrt.org
Betreff: Re: [OpenWrt-Devel] [PATCH] pinctrl/lantiq: split xway_mfp into 
dedicated tables

Hi,

the dts and kernel changes should be in separate patches.

also please send the pinctrl patch upstream.

John

On 16/11/2015 10:42, Martin Schiller wrote:
> This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9" settings
> into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100" and
> "pinctrl-xrx200" configuration tables.
>
> Based on the newest Lantiq Hardware Description it turend out, that there are
> some differences in the GPIO alternative functions of the Danube, xRX100 and
> xRX200 families, which makes it impossible to use only one xway_mfp table.
>
> This patch is also the first step to add support for the xRX300 family.
>
> Signed-off-by: Martin Schiller <mschil...@tdt.de>
> ---
>  target/linux/lantiq/dts/BTHOMEHUBV2B.dts   |2 +-
>  target/linux/lantiq/dts/BTHOMEHUBV3A.dts   |2 +-
>  target/linux/lantiq/dts/EASY50712.dts  |2 +-
>  target/linux/lantiq/dts/EASY50810.dts  |2 +-
>  target/linux/lantiq/dts/EASY80920.dtsi |2 +-
>  target/linux/lantiq/dts/GR7000.dts |2 +-
>  target/linux/lantiq/dts/P2601HNFX.dts  |2 +-
>  target/linux/lantiq/dts/P2812HNUFX.dtsi|2 +-
>  target/linux/lantiq/dts/VGV7519.dtsi   |2 +-
>  target/linux/lantiq/dts/ar9.dtsi   |2 +-
>  target/linux/lantiq/dts/danube.dtsi|2 +-
>  target/linux/lantiq/dts/vr9.dtsi   |2 +-
>  .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059 
> +++-
>  13 files changed, 1061 insertions(+), 22 deletions(-)
>
> diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 
> b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
> index 9b3180c..e2d713e 100644
> --- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
> +++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
> @@ -102,7 +102,7 @@
>  };
>
>  gpio: pinmux@E100B10 {
> -compatible = "lantiq,pinctrl-xway";
> +compatible = "lantiq,pinctrl-danube";
>  pinctrl-names = "default";
>  pinctrl-0 = <_default>;
>
> diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts 
> b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
> index 1ae9840..9383498 100644
> --- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
> +++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
> @@ -79,7 +79,7 @@
>  };
>
>  gpio: pinmux@E100B10 {
> -compatible = "lantiq,pinctrl-xr9";
> +compatible = "lantiq,pinctrl-xrx100";
>  pinctrl-names = "default";
>  pinctrl-0 = <_default>;
>
> diff --git a/target/linux/lantiq/dts/EASY50712.dts 
> b/target/linux/lantiq/dts/EASY50712.dts
> index e44267a..e0d5ed1 100644
> --- a/target/linux/lantiq/dts/EASY50712.dts
> +++ b/target/linux/lantiq/dts/EASY50712.dts
> @@ -51,7 +51,7 @@
>  };
>
>  gpio: pinmux@E100B10 {
> -compatible = "lantiq,pinctrl-xway";
> +compatible = "lantiq,pinctrl-danube";
>  pinctrl-names = "default";
>  pinctrl-0 = <_default>;
>
> diff --git a/target/linux/lantiq/dts/EASY50810.dts 
> b/target/linux/lantiq/dts/EASY50810.dts
> index 5f4b733..73f31ea 100644
> --- a/target/linux/lantiq/dts/EASY50810.dts
> +++ b/target/linux/lantiq/dts/EASY50810.dts
> @@ -51,7 +51,7 @@
>  };
>
>  gpio: pinmux@E100B10 {
> -compatible = "lantiq,pinctrl-xr9";
> +compatible = "lantiq,pinctrl-xrx100";
>  pinctrl-names = "default";
>  pinctrl-0 = <_default>;
>
> diff --git a/target/linux/lantiq/dts/EASY80920.dtsi 
> b/target/linux/lantiq/dts/EASY80920.dtsi
> index 4013610..0600d36 100644
> --- a/target/linux/lantiq/dts/EASY80920.dtsi
> +++ b/target/linux/lantiq/dts/EASY80920.dtsi
> @@ -71,7 +71,7 @@
>  };
>
>  gpio: pinmux@E100B10 {
> -compatible = "lantiq,pinctrl-xr9";
> +compatible = "lantiq,pinctrl-xrx200";
>  pinctrl-names = "default";
>  pinctrl-0 = <_default>;
>
> diff --git a/t

[OpenWrt-Devel] [PATCH v2 1/2] pinctrl/lantiq: split xway_mfp into dedicated tables

[Martin Schiller]

This patch splits the inadequate "pinctrl-xway" and "pinctrl-xr9" settings
into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100" and
"pinctrl-xrx200" configuration tables.

Based on the newest Lantiq Hardware Description it turend out, that there are
some differences in the GPIO alternative functions of the Danube, xRX100 and
xRX200 families, which makes it impossible to use only one xway_mfp table.

This patch is also the first step to add support for the xRX300 family.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1059 +++-
 .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1059 +++-
 2 files changed, 2098 insertions(+), 20 deletions(-)

diff --git a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch 
b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
index 84adbe6..3fc0432 100644
--- a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
+++ b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
@@ -1,15 +1,1054 @@
 --- a/drivers/pinctrl/pinctrl-xway.c
 +++ b/drivers/pinctrl/pinctrl-xway.c
-@@ -152,10 +152,10 @@ static const struct ltq_mfp_pin xway_mfp
-   MFP_XWAY(GPIO41, GPIO,  NONE,   NONE,   NONE),
-   MFP_XWAY(GPIO42, GPIO,  MDIO,   NONE,   NONE),
-   MFP_XWAY(GPIO43, GPIO,  MDIO,   NONE,   NONE),
+@@ -7,6 +7,7 @@
+  *  publishhed by the Free Software Foundation.
+  *
+  *  Copyright (C) 2012 John Crispin <blo...@openwrt.org>
++ *  Copyright (C) 2015 Martin Schiller <mschil...@tdt.de>
+  */
+ 
+ #include 
+@@ -80,17 +81,18 @@
+ #define FUNC_MUX(f, m)\
+   { .func = f, .mux = XWAY_MUX_##m, }
+ 
+-#define XWAY_MAX_PIN  32
+-#define XR9_MAX_PIN   56
+-
+ enum xway_mux {
+   XWAY_MUX_GPIO = 0,
+   XWAY_MUX_SPI,
+   XWAY_MUX_ASC,
++  XWAY_MUX_USIF,
+   XWAY_MUX_PCI,
++  XWAY_MUX_CBUS,
+   XWAY_MUX_CGU,
+   XWAY_MUX_EBU,
++  XWAY_MUX_EBU2,
+   XWAY_MUX_JTAG,
++  XWAY_MUX_MCD,
+   XWAY_MUX_EXIN,
+   XWAY_MUX_TDM,
+   XWAY_MUX_STP,
+@@ -103,68 +105,12 @@ enum xway_mux {
+   XWAY_MUX_DFE,
+   XWAY_MUX_SDIO,
+   XWAY_MUX_GPHY,
++  XWAY_MUX_SSI,
+   XWAY_MUX_NONE = 0x,
+ };
+ 
+-static const struct ltq_mfp_pin xway_mfp[] = {
+-  /*   pinf0  f1  f2  f3   */
+-  MFP_XWAY(GPIO0, GPIO,   EXIN,   NONE,   TDM),
+-  MFP_XWAY(GPIO1, GPIO,   EXIN,   NONE,   NONE),
+-  MFP_XWAY(GPIO2, GPIO,   CGU,EXIN,   GPHY),
+-  MFP_XWAY(GPIO3, GPIO,   CGU,NONE,   PCI),
+-  MFP_XWAY(GPIO4, GPIO,   STP,NONE,   ASC),
+-  MFP_XWAY(GPIO5, GPIO,   STP,NONE,   GPHY),
+-  MFP_XWAY(GPIO6, GPIO,   STP,GPT,ASC),
+-  MFP_XWAY(GPIO7, GPIO,   CGU,PCI,GPHY),
+-  MFP_XWAY(GPIO8, GPIO,   CGU,NMI,NONE),
+-  MFP_XWAY(GPIO9, GPIO,   ASC,SPI,EXIN),
+-  MFP_XWAY(GPIO10, GPIO,  ASC,SPI,NONE),
+-  MFP_XWAY(GPIO11, GPIO,  ASC,PCI,SPI),
+-  MFP_XWAY(GPIO12, GPIO,  ASC,NONE,   NONE),
+-  MFP_XWAY(GPIO13, GPIO,  EBU,SPI,NONE),
+-  MFP_XWAY(GPIO14, GPIO,  CGU,PCI,NONE),
+-  MFP_XWAY(GPIO15, GPIO,  SPI,JTAG,   NONE),
+-  MFP_XWAY(GPIO16, GPIO,  SPI,NONE,   JTAG),
+-  MFP_XWAY(GPIO17, GPIO,  SPI,NONE,   JTAG),
+-  MFP_XWAY(GPIO18, GPIO,  SPI,NONE,   JTAG),
+-  MFP_XWAY(GPIO19, GPIO,  PCI,NONE,   NONE),
+-  MFP_XWAY(GPIO20, GPIO,  JTAG,   NONE,   NONE),
+-  MFP_XWAY(GPIO21, GPIO,  PCI,EBU,GPT),
+-  MFP_XWAY(GPIO22, GPIO,  SPI,NONE,   NONE),
+-  MFP_XWAY(GPIO23, GPIO,  EBU,PCI,STP),
+-  MFP_XWAY(GPIO24, GPIO,  EBU,TDM,PCI),
+-  MFP_XWAY(GPIO25, GPIO,  TDM,NONE,   ASC),
+-  MFP_XWAY(GPIO26, GPIO,  EBU,NONE,   TDM),
+-  MFP_XWAY(GPIO27, GPIO,  TDM,NONE,   ASC),
+-  MFP_XWAY(GPIO28, GPIO,  GPT,NONE,   NONE),
+-  MFP_XWAY(GPIO29, GPIO,  PCI,NONE,   NONE),
+-  MFP_XWAY(GPIO30, GPIO,  PCI,NONE,   NONE),
+-  MFP_XWAY(GPIO31, GPIO,  EBU,PCI,NONE),
+-  MFP_XWAY(GPIO32, GPIO,  NONE,   NONE,   EBU),
+-  MFP_XWAY(GPIO33, GPIO,  NONE,   NONE,   EBU),
+-  MFP_XWAY(GPIO34, GPIO,  NONE,   NONE,   EBU),
+-  MFP_XWAY(GPIO35, GPIO,  NONE,   NONE,   EBU),
+-  MFP_XWAY(GPIO36, GPIO,  SIN,NONE,   EBU),
+-  MFP_XWAY(GPIO37, GPIO,  PCI,NONE,   NONE),
+-  MFP_XWAY(GPIO38, GPIO,  PCI,NONE,   NONE),
+-  MFP_XWAY(GPIO39, GPIO,  EXIN,   NONE,   NONE),
+-  MFP_XWAY(GPIO40, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO41, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO42, GPIO,  MDIO,   NONE,   NONE),
+-  MFP_XWAY(GPIO43, GPIO,  MDIO,   NONE,   NONE),
 -  MFP_XWAY(GPIO44, GPIO,  NONE,   GPHY,   SIN),
-+  MFP_XWAY(GPIO44, GPIO,  MII,SIN,GPHY),
-

[OpenWrt-Devel] [PATCH v2 2/2] pinctrl/lantiq: adapt device-trees to new tables

[Martin Schiller]

This patch adapts the "pinctrl-xway" and "pinctrl-xr9" settings in the
dts files into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100"
and "pinctrl-xrx200" settings.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 target/linux/lantiq/dts/BTHOMEHUBV2B.dts | 2 +-
 target/linux/lantiq/dts/BTHOMEHUBV3A.dts | 2 +-
 target/linux/lantiq/dts/EASY50712.dts| 2 +-
 target/linux/lantiq/dts/EASY50810.dts| 2 +-
 target/linux/lantiq/dts/EASY80920.dtsi   | 2 +-
 target/linux/lantiq/dts/GR7000.dts   | 2 +-
 target/linux/lantiq/dts/P2601HNFX.dts| 2 +-
 target/linux/lantiq/dts/P2812HNUFX.dtsi  | 2 +-
 target/linux/lantiq/dts/VGV7519.dtsi | 2 +-
 target/linux/lantiq/dts/ar9.dtsi | 2 +-
 target/linux/lantiq/dts/danube.dtsi  | 2 +-
 target/linux/lantiq/dts/vr9.dtsi | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
index 9b3180c..e2d713e 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
@@ -102,7 +102,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
index 1ae9840..9383498 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
@@ -79,7 +79,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50712.dts 
b/target/linux/lantiq/dts/EASY50712.dts
index e44267a..e0d5ed1 100644
--- a/target/linux/lantiq/dts/EASY50712.dts
+++ b/target/linux/lantiq/dts/EASY50712.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50810.dts 
b/target/linux/lantiq/dts/EASY50810.dts
index 5f4b733..73f31ea 100644
--- a/target/linux/lantiq/dts/EASY50810.dts
+++ b/target/linux/lantiq/dts/EASY50810.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY80920.dtsi 
b/target/linux/lantiq/dts/EASY80920.dtsi
index 4013610..0600d36 100644
--- a/target/linux/lantiq/dts/EASY80920.dtsi
+++ b/target/linux/lantiq/dts/EASY80920.dtsi
@@ -71,7 +71,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx200";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/GR7000.dts 
b/target/linux/lantiq/dts/GR7000.dts
index fcc27eb..bc95f1f 100644
--- a/target/linux/lantiq/dts/GR7000.dts
+++ b/target/linux/lantiq/dts/GR7000.dts
@@ -42,7 +42,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/P2601HNFX.dts 
b/target/linux/lantiq/dts/P2601HNFX.dts
index bb9193e..c22c547 100644
--- a/target/linux/lantiq/dts/P2601HNFX.dts
+++ b/target/linux/lantiq/dts/P2601HNFX.dts
@@ -50,7 +50,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/P2812HNUFX.dtsi 
b/target/linux/lantiq/dts/P2812HNUFX.dtsi
index d93e862..1dd13ac 100644
--- a/target/linux/lantiq/dts/P2812HNUFX.dtsi
+++ b/target/linux/lant

[OpenWrt-Devel] [PATCH v3 2/2] pinctrl/lantiq: adapt devicetrees to new tables

[Martin Schiller]

This patch adapts the "pinctrl-xway" and "pinctrl-xr9" settings in the
dts files into dedicated "pinctrl-ase", "pinctrl-danube", "pinctrl-xrx100"
and "pinctrl-xrx200" settings.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 target/linux/lantiq/dts/BTHOMEHUBV2B.dts | 2 +-
 target/linux/lantiq/dts/BTHOMEHUBV3A.dts | 2 +-
 target/linux/lantiq/dts/EASY50712.dts| 2 +-
 target/linux/lantiq/dts/EASY50810.dts| 2 +-
 target/linux/lantiq/dts/EASY80920.dtsi   | 2 +-
 target/linux/lantiq/dts/GR7000.dts   | 2 +-
 target/linux/lantiq/dts/P2601HNFX.dts| 2 +-
 target/linux/lantiq/dts/P2812HNUFX.dtsi  | 2 +-
 target/linux/lantiq/dts/VGV7519.dtsi | 2 +-
 target/linux/lantiq/dts/ar9.dtsi | 2 +-
 target/linux/lantiq/dts/danube.dtsi  | 2 +-
 target/linux/lantiq/dts/vr9.dtsi | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
index 9b3180c..e2d713e 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts
@@ -102,7 +102,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
index 1ae9840..9383498 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV3A.dts
@@ -79,7 +79,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50712.dts 
b/target/linux/lantiq/dts/EASY50712.dts
index e44267a..e0d5ed1 100644
--- a/target/linux/lantiq/dts/EASY50712.dts
+++ b/target/linux/lantiq/dts/EASY50712.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xway";
+   compatible = "lantiq,pinctrl-danube";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY50810.dts 
b/target/linux/lantiq/dts/EASY50810.dts
index 5f4b733..73f31ea 100644
--- a/target/linux/lantiq/dts/EASY50810.dts
+++ b/target/linux/lantiq/dts/EASY50810.dts
@@ -51,7 +51,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/EASY80920.dtsi 
b/target/linux/lantiq/dts/EASY80920.dtsi
index 4013610..0600d36 100644
--- a/target/linux/lantiq/dts/EASY80920.dtsi
+++ b/target/linux/lantiq/dts/EASY80920.dtsi
@@ -71,7 +71,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx200";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/GR7000.dts 
b/target/linux/lantiq/dts/GR7000.dts
index fcc27eb..bc95f1f 100644
--- a/target/linux/lantiq/dts/GR7000.dts
+++ b/target/linux/lantiq/dts/GR7000.dts
@@ -42,7 +42,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/P2601HNFX.dts 
b/target/linux/lantiq/dts/P2601HNFX.dts
index bb9193e..c22c547 100644
--- a/target/linux/lantiq/dts/P2601HNFX.dts
+++ b/target/linux/lantiq/dts/P2601HNFX.dts
@@ -50,7 +50,7 @@
};
 
gpio: pinmux@E100B10 {
-   compatible = "lantiq,pinctrl-xr9";
+   compatible = "lantiq,pinctrl-xrx100";
pinctrl-names = "default";
pinctrl-0 = <_default>;
 
diff --git a/target/linux/lantiq/dts/P2812HNUFX.dtsi 
b/target/linux/lantiq/dts/P2812HNUFX.dtsi
index d93e862..1dd13ac 100644
--- a/target/linux/lantiq/dts/P2812HNUFX.dtsi
+++ b/target/linux/lant

[OpenWrt-Devel] [PATCH v3 1/2] pinctrl/lantiq: introduce new dedicated tables

[Martin Schiller]

This patch introduces new dedicated "pinctrl-ase", "pinctrl-danube",
"pinctrl-xrx100" and "pinctrl-xrx200" configuration tables.

Based on the newest Lantiq Hardware Description it turend out, that there are
some differences in the GPIO alternative functions of the Danube, xRX100 and
xRX200 families, which makes it impossible to use only one xway_mfp table.

This patch is also the first step to add support for the xRX300 family.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../patches-3.18/0150-lantiq-pinctrl-xway.patch| 1118 +++-
 .../patches-4.1/0150-lantiq-pinctrl-xway.patch | 1118 +++-
 2 files changed, 2214 insertions(+), 22 deletions(-)

diff --git a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch 
b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
index 84adbe6..871cebb 100644
--- a/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
+++ b/target/linux/lantiq/patches-3.18/0150-lantiq-pinctrl-xway.patch
@@ -1,15 +1, @@
 --- a/drivers/pinctrl/pinctrl-xway.c
 +++ b/drivers/pinctrl/pinctrl-xway.c
-@@ -152,10 +152,10 @@ static const struct ltq_mfp_pin xway_mfp
-   MFP_XWAY(GPIO41, GPIO,  NONE,   NONE,   NONE),
-   MFP_XWAY(GPIO42, GPIO,  MDIO,   NONE,   NONE),
-   MFP_XWAY(GPIO43, GPIO,  MDIO,   NONE,   NONE),
--  MFP_XWAY(GPIO44, GPIO,  NONE,   GPHY,   SIN),
+@@ -7,6 +7,7 @@
+  *  publishhed by the Free Software Foundation.
+  *
+  *  Copyright (C) 2012 John Crispin <blo...@openwrt.org>
++ *  Copyright (C) 2015 Martin Schiller <mschil...@tdt.de>
+  */
+ 
+ #include 
+@@ -80,17 +81,18 @@
+ #define FUNC_MUX(f, m)\
+   { .func = f, .mux = XWAY_MUX_##m, }
+ 
+-#define XWAY_MAX_PIN  32
+-#define XR9_MAX_PIN   56
+-
+ enum xway_mux {
+   XWAY_MUX_GPIO = 0,
+   XWAY_MUX_SPI,
+   XWAY_MUX_ASC,
++  XWAY_MUX_USIF,
+   XWAY_MUX_PCI,
++  XWAY_MUX_CBUS,
+   XWAY_MUX_CGU,
+   XWAY_MUX_EBU,
++  XWAY_MUX_EBU2,
+   XWAY_MUX_JTAG,
++  XWAY_MUX_MCD,
+   XWAY_MUX_EXIN,
+   XWAY_MUX_TDM,
+   XWAY_MUX_STP,
+@@ -103,9 +105,15 @@ enum xway_mux {
+   XWAY_MUX_DFE,
+   XWAY_MUX_SDIO,
+   XWAY_MUX_GPHY,
++  XWAY_MUX_SSI,
+   XWAY_MUX_NONE = 0x,
+ };
+ 
++/* -  DEPRECATED: xway/xr9 related code - */
++/* -  use danube/xrx100/xrx200 instead  - */
++#define XWAY_MAX_PIN  32
++#define XR9_MAX_PIN   56
++
+ static const struct ltq_mfp_pin xway_mfp[] = {
+   /*   pinf0  f1  f2  f3   */
+   MFP_XWAY(GPIO0, GPIO,   EXIN,   NONE,   TDM),
+@@ -166,42 +174,6 @@ static const struct ltq_mfp_pin xway_mfp
+   MFP_XWAY(GPIO55, GPIO,  NONE,   NONE,   NONE),
+ };
+ 
+-static const struct ltq_mfp_pin ase_mfp[] = {
+-  /*   pinf0  f1  f2  f3   */
+-  MFP_XWAY(GPIO0, GPIO,   EXIN,   MII,TDM),
+-  MFP_XWAY(GPIO1, GPIO,   STP,DFE,EBU),
+-  MFP_XWAY(GPIO2, GPIO,   STP,DFE,EPHY),
+-  MFP_XWAY(GPIO3, GPIO,   STP,EPHY,   EBU),
+-  MFP_XWAY(GPIO4, GPIO,   GPT,EPHY,   MII),
+-  MFP_XWAY(GPIO5, GPIO,   MII,ASC,GPT),
+-  MFP_XWAY(GPIO6, GPIO,   MII,ASC,EXIN),
+-  MFP_XWAY(GPIO7, GPIO,   SPI,MII,JTAG),
+-  MFP_XWAY(GPIO8, GPIO,   SPI,MII,JTAG),
+-  MFP_XWAY(GPIO9, GPIO,   SPI,MII,JTAG),
+-  MFP_XWAY(GPIO10, GPIO,  SPI,MII,JTAG),
+-  MFP_XWAY(GPIO11, GPIO,  EBU,CGU,JTAG),
+-  MFP_XWAY(GPIO12, GPIO,  EBU,MII,SDIO),
+-  MFP_XWAY(GPIO13, GPIO,  EBU,MII,CGU),
+-  MFP_XWAY(GPIO14, GPIO,  EBU,SPI,CGU),
+-  MFP_XWAY(GPIO15, GPIO,  EBU,SPI,SDIO),
+-  MFP_XWAY(GPIO16, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO17, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO18, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO19, GPIO,  EBU,MII,SDIO),
+-  MFP_XWAY(GPIO20, GPIO,  EBU,MII,SDIO),
+-  MFP_XWAY(GPIO21, GPIO,  EBU,MII,SDIO),
+-  MFP_XWAY(GPIO22, GPIO,  EBU,MII,CGU),
+-  MFP_XWAY(GPIO23, GPIO,  EBU,MII,CGU),
+-  MFP_XWAY(GPIO24, GPIO,  EBU,NONE,   MII),
+-  MFP_XWAY(GPIO25, GPIO,  EBU,MII,GPT),
+-  MFP_XWAY(GPIO26, GPIO,  EBU,MII,SDIO),
+-  MFP_XWAY(GPIO27, GPIO,  EBU,NONE,   MII),
+-  MFP_XWAY(GPIO28, GPIO,  MII,EBU,SDIO),
+-  MFP_XWAY(GPIO29, GPIO,  EBU,MII,EXIN),
+-  MFP_XWAY(GPIO30, GPIO,  NONE,   NONE,   NONE),
+-  MFP_XWAY(GPIO31, GPIO,  NONE,   NONE,   NONE),
+-};
+-
+ static const unsigned pins_jtag[] = {GPIO15, GPIO16, GPIO17, GPIO19, GPIO35};
+ static const unsigned pins_asc0[] = {GPIO11, GPIO12};
+ static const unsigned pins_asc0_cts_rts[] = {GPIO9, GPIO10};
+@@ -231,6 +203,8 @@ static const unsigned pins_nand_cle[] =
+ static const unsigned pins_n

[OpenWrt-Devel] Review of 0012-pinctrl-lantiq-fix-up-pinmux.patch

[Martin Schiller]

Hi,

here follows a little review of the 0012-pinctrl-lantiq-fix-up-pinmux.patch
to get this stuff upstream:

> From 25494c55a4007a1409f53ddbafd661636e47ea34 Mon Sep 17 00:00:00 2001
> From: John Crispin 
> Date: Fri, 9 Aug 2013 20:38:15 +0200
> Subject: [PATCH 12/36] pinctrl/lantiq: fix up pinmux
>
> We found out how to set the gphy led pinmuxing.
>
> Signed-off-by: John Crispin 
> ---
>  drivers/pinctrl/pinctrl-xway.c |   28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
>
> --- a/drivers/pinctrl/pinctrl-xway.c
> +++ b/drivers/pinctrl/pinctrl-xway.c
> @@ -609,10 +609,9 @@ static struct pinctrl_desc xway_pctrl_de
>  .confops= _pinconf_ops,
>  };
>
> -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> +static int mux_apply(struct ltq_pinmux_info *info,
>  int pin, int mux)
>  {
> -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
>  int port = PORT(pin);
>  u32 alt1_reg = GPIO_ALT1(pin);
>
> @@ -632,6 +631,14 @@ static inline int xway_mux_apply(struct
>  return 0;
>  }
>
> +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> +int pin, int mux)
> +{
> +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> +
> +return mux_apply(info, pin, mux);
> +}
> +
>  static const struct ltq_cfg_param xway_cfg_params[] = {
>  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
>  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},

What are these changes for?

> @@ -676,6 +683,10 @@ static int xway_gpio_dir_out(struct gpio
>  {
>  struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
>
> +if (PORT(pin) == PORT3)
> +gpio_setbit(info->membase[0], GPIO3_OD, PORT_PIN(pin));
> +else
> +gpio_setbit(info->membase[0], GPIO_OD(pin), PORT_PIN(pin));
>  gpio_setbit(info->membase[0], GPIO_DIR(pin), PORT_PIN(pin));
>  xway_gpio_set(chip, pin, val);
>

This fixes the GPIO Setup for GPIOs >= GPIO48 (GPIO Port3), right?


> @@ -696,6 +707,18 @@ static void xway_gpio_free(struct gpio_c
>  pinctrl_free_gpio(gpio);
>  }
>
> +static int xway_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
> +{
> +struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> +int i;
> +
> +for (i = 0; i < info->num_exin; i++)
> +if (info->exin[i] == offset)
> +return ltq_eiu_get_irq(i);
> +
> +return -1;
> +}
> +
>  static struct gpio_chip xway_chip = {
>  .label = "gpio-xway",
>  .direction_input = xway_gpio_dir_in,
> @@ -704,6 +727,7 @@ static struct gpio_chip xway_chip = {
>  .set = xway_gpio_set,
>  .request = xway_gpio_req,
>  .free = xway_gpio_free,
> +.to_irq = xway_gpio_to_irq,
>  .base = -1,
>  };
>

This implements the IRQ Mapping for GPIOs.


So which of these changes is related to gphy led pinmuxing?

I think we can make 2 patches out of this one:

[1/2] pinctrl/lantiq: Fix GPIO Setup for GPIO Port3
[2/2] pinctrl/lantiq: Implement gpio_chip.to_irq

Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] pinctrl/lantiq: split xway_mfp into dedicated tables

[Martin Schiller]

Hi,

On 11/16/2015 at 9:28 PM, Hauke Mehrtens wrote:
> Hi Martin,
>
> The get_maintainer.pl helps to find the correct mailing list, it
> searches the MAINTAINERS file.
>
> ./scripts/get_maintainer.pl -f drivers/pinctrl/pinctrl-xway.c
> Linus Walleij  (maintainer:PIN CONTROL
> SUBSYSTEM)
> linux-g...@vger.kernel.org (open list:PIN CONTROL SUBSYSTEM)
> linux-ker...@vger.kernel.org (open list)

Thanks, John already told me to use the get_maintainer.pl script.

> You should probably not send it to linux-ker...@vger.kernel.org.
> In addition you should send it to blo...@openwrt.org as he is the main
> author.
>
> I assume John is ok if you also send his patch
> 0012-pinctrl-lantiq-fix-up-pinmux.patch upstream. When you use git
> send-mail it should preserve the author name.

I think we have to review this patch again, because it changes more
than that what is stated in the comment.
Maybe we have to split it up in several parts to get it upstream?

> Can you please also add me in cc as well, thanks.

Ok.

> You changed the compatible string, this is considered ABI in the Linux
> kernel and should stay compatible with older versions, so that you can
> use an older DTS file with a recent kernel. Could you only add the new
> names in of_device_id xway_match and not remove the old ones, so that
> both will work.

So I will leave the old stuff (pinctrl-xway and pinctrl-xr9), mark them
as deprecated and add the new ones (pinctrl-danube, pinctrl-xrx100 and
pinctrl-xrx200). Of course, the Documentation will also be updated.

>
> I send some patches to add basic support for the xrx300 upstream and it
> is included in Linux 4.4, it boots. ;-)

Ah, nice work! I want to use the USIF UART of the xRX200, so it was also
on my todo list to adapt the Lantiq UGW PMU Patches to the free world. ;-)

But maybe you overlooked some little details:

The PMU_ASC0 should be removed from the "generic xway clocks" section.
Instead, the PMU_ASC1 should go there because it is available on every
XWAY SoC (even on the Amazon-SE).

Also, the quotation marks should be removed from the second parameter of
the clkdev_add_pmu("1da.usif", "NULL", 1, 0, PMU_USIF) calls.

Looking forward to meet again on the next Summit,

Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lantiq, xrx200-net: add new 'id' devicetree property

[Martin Schiller]

This patch adds the new 'id' devicetree property, which makes it possible to
renumber the physical mac ports.

This change has only cosmetical reasons (e.g. appearance in swconfig,
kernel messages on link change).

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 39 --
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 48c7395..4ab09e2 100644
--- a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +};
 --- /dev/null
 +++ b/drivers/net/ethernet/lantiq_xrx200.c
-@@ -0,0 +1,1798 @@
+@@ -0,0 +1,1815 @@
 +/*
 + *   This program is free software; you can redistribute it and/or modify it
 + *   under the terms of the GNU General Public License version 2 as published
@@ -404,6 +404,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +
 +struct xrx200_port {
 +  u8 num;
++  u8 id;
 +  u8 phy_addr;
 +  u16 flags;
 +  phy_interface_t phy_if;
@@ -461,6 +462,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  struct xrx200_hw *hw;
 +};
 +
++static int id_to_mac[XRX200_MAX_PORT] = {0,1,2,3,4,5,6};
++static int mac_to_id[XRX200_MAX_PORT] = {0,1,2,3,4,5,6};
++
 +static __iomem void *xrx200_switch_membase;
 +static __iomem void *xrx200_mii_membase;
 +static __iomem void *xrx200_mdio_membase;
@@ -789,9 +793,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  {
 +  struct switch_port *p = >value.ports[i];
 +
-+  portmap |= (1 << p->id);
++  portmap |= (1 << id_to_mac[p->id]);
 +  if (p->flags & (1 << SWITCH_PORT_FLAG_TAGGED))
-+  tagmap |= (1 << p->id);
++  tagmap |= (1 << id_to_mac[p->id]);
 +  }
 +
 +  tem.table = XRX200_PCE_VLANMAP_IDX;
@@ -855,7 +859,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  continue;
 +
 +  p = >value.ports[val->len++];
-+  p->id = i;
++  p->id = mac_to_id[i];
 +  if (tags & (1 << i))
 +  p->flags = (1 << SWITCH_PORT_FLAG_TAGGED);
 +  else
@@ -898,8 +902,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +}
 +
 +// port
-+static int xrx200sw_get_port_pvid(struct switch_dev *dev, int port, int *val)
++static int xrx200sw_get_port_pvid(struct switch_dev *dev, int port_id, int 
*val)
 +{
++  int port = id_to_mac[port_id];
 +  struct xrx200_pce_table_entry tev;
 +
 +  if (port >= XRX200_MAX_PORT)
@@ -914,9 +919,11 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +}
 +
 +static int xrx200sw_get_port_link(struct switch_dev *dev,
-+int port,
++int port_id,
 +struct switch_port_link *link)
 +{
++  int port = id_to_mac[port_id];
++
 +  if (port >= XRX200_MAX_PORT)
 +  return -EINVAL;
 +
@@ -1432,7 +1439,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  xrx200_gmac_update(>port[i]);
 +  priv->port[i].link = priv->port[i].phydev->link;
 +  netdev_info(dev, "port %d %s link\n",
-+  priv->port[i].num,
++  priv->port[i].id,
 +  (priv->port[i].link)?("got"):("lost"));
 +  }
 +  }
@@ -1633,7 +1640,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  for (i = 0; i < priv->num_port; i++)
 +  if (xrx200_mdio_probe(dev, >port[i]))
 +  pr_warn("xrx200-mdio: probing phy of port %d failed\n",
-+   priv->port[i].num);
++   priv->port[i].id);
 +
 +  return 0;
 +
@@ -1787,19 +1794,25 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +
 +static void xrx200_of_port(struct xrx200_priv *priv, struct device_node *port)
 +{
-+  const __be32 *addr, *id = of_get_property(port, "reg", NULL);
++  const __be32 *addr, *id, *mac = of_get_property(port, "reg", NULL);
 +  struct xrx200_port *p = >port[priv->num_port];
 +
-+  if (!id)
++  if (!mac)
 +  return;
 +
++  id = of_get_property(port, "id", NULL);
++
++  if (!id)
++  id = mac;
++
 +  memset(p, 0, sizeof(struct xrx200_port));
 +  p->phy_node =

[OpenWrt-Devel] [PATCH v2] lantiq, xrx200-net: add devicetree aliases support for port->mac mapping

[Martin Schiller]

This patch adds devicetree aliases support, which makes it possible to
renumber the physical mac ports.

This change has only cosmetical reasons (e.g. appearance in swconfig,
kernel messages on link change).

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
Changes in v2:
- use devicetree aliases instead of 'id' property
- only map ports, which are "configured" in the devicetree

 .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 46 --
 1 file changed, 33 insertions(+), 13 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 48c7395..c76c165 100644
--- a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +};
 --- /dev/null
 +++ b/drivers/net/ethernet/lantiq_xrx200.c
-@@ -0,0 +1,1798 @@
+@@ -0,0 +1,1818 @@
 +/*
 + *   This program is free software; you can redistribute it and/or modify it
 + *   under the terms of the GNU General Public License version 2 as published
@@ -404,6 +404,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +
 +struct xrx200_port {
 +  u8 num;
++  u8 id;
 +  u8 phy_addr;
 +  u16 flags;
 +  phy_interface_t phy_if;
@@ -461,6 +462,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  struct xrx200_hw *hw;
 +};
 +
++static int id_to_mac[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
++static int mac_to_id[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
++
 +static __iomem void *xrx200_switch_membase;
 +static __iomem void *xrx200_mii_membase;
 +static __iomem void *xrx200_mdio_membase;
@@ -789,9 +793,13 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  {
 +  struct switch_port *p = >value.ports[i];
 +
-+  portmap |= (1 << p->id);
++  if (id_to_mac[p->id] < 0) {
++  continue;
++  }
++
++  portmap |= (1 << id_to_mac[p->id]);
 +  if (p->flags & (1 << SWITCH_PORT_FLAG_TAGGED))
-+  tagmap |= (1 << p->id);
++  tagmap |= (1 << id_to_mac[p->id]);
 +  }
 +
 +  tem.table = XRX200_PCE_VLANMAP_IDX;
@@ -855,7 +863,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  continue;
 +
 +  p = >value.ports[val->len++];
-+  p->id = i;
++  p->id = mac_to_id[i];
 +  if (tags & (1 << i))
 +  p->flags = (1 << SWITCH_PORT_FLAG_TAGGED);
 +  else
@@ -898,11 +906,12 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +}
 +
 +// port
-+static int xrx200sw_get_port_pvid(struct switch_dev *dev, int port, int *val)
++static int xrx200sw_get_port_pvid(struct switch_dev *dev, int port_id, int 
*val)
 +{
++  int port = id_to_mac[port_id];
 +  struct xrx200_pce_table_entry tev;
 +
-+  if (port >= XRX200_MAX_PORT)
++  if (port < 0 || port >= XRX200_MAX_PORT)
 +  return -EINVAL;
 +
 +  tev.table = XRX200_PCE_ACTVLAN_IDX;
@@ -914,10 +923,12 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +}
 +
 +static int xrx200sw_get_port_link(struct switch_dev *dev,
-+int port,
++int port_id,
 +struct switch_port_link *link)
 +{
-+  if (port >= XRX200_MAX_PORT)
++  int port = id_to_mac[port_id];
++
++  if (port < 0 || port >= XRX200_MAX_PORT)
 +  return -EINVAL;
 +
 +  link->link = xrx200sw_read_x(XRX200_MAC_PSTAT_LSTAT, port);
@@ -1432,7 +1443,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  xrx200_gmac_update(>port[i]);
 +  priv->port[i].link = priv->port[i].phydev->link;
 +  netdev_info(dev, "port %d %s link\n",
-+  priv->port[i].num,
++  priv->port[i].id,
 +  (priv->port[i].link)?("got"):("lost"));
 +  }
 +  }
@@ -1633,7 +1644,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  for (i = 0; i < priv->num_port; i++)
 +  if (xrx200_mdio_probe(dev, >port[i]))
 +  pr_warn("xrx200-mdio: probing phy of port %d failed\n",
-+   priv->port[i].num);
++   priv->port[i].id);
 +
 +  return 0;
 +
@@ -1787,19 +1798,24 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +
 +static void xrx200_of_port(struct xrx200_priv *p

Re: [OpenWrt-Devel] [PATCH v2] lantiq, xrx200-net: add devicetree aliases support for port->mac mapping

[Martin Schiller]

On 12/17/2015 at 12:13 PM, John Crispin wrote:
>
>
> On 17/12/2015 12:03, Martin Schiller wrote:
> > On 12/17/2015 at 9:20 AM, John Crispin wrote:
> >>
> >>
> >> On 14/12/2015 10:18, Martin Schiller wrote:
> >>> This patch adds devicetree aliases support, which makes it possible
> >> to
> >>> renumber the physical mac ports.
> >>>
> >>> This change has only cosmetical reasons (e.g. appearance in
> swconfig,
> >>> kernel messages on link change).
> >>>
> >>> Signed-off-by: Martin Schiller <mschil...@tdt.de>
> >>
> >> i have a problem with this patch. port 5 is port 5 *always*. i dont
> see
> >> how this fixes an issue. did you HW guys build broken HW with badly
> >> ordered mac ports ?
> >
> > Yes, you are right. This patch is intended to reorder broken/unlovely
> > placed mac ports.
> >
> > The user should see ports in the order 1,2,3,4,5 instead of
> 1,4,5,2,3.
> >
>
> ah of coruse the ports are ordered in a wonky way on the SoC
>
> > Our HW guys told us it would be much more work to solve this in
> hardware
> > by doing a lot of "wire crossings" (with unwanted hf side-effects) in
> the
> > pcb layout.
> >
>
> correct
>
> > And there are also situations, where you even can't do it in
> hardware:
> > when you use the xrx200 in Gigabit mode, you can use mac 0,1,2,4,5.
> > mac/port 3 is dead in this case.
> >
> > But you can't tell an enduser/customer that there is a port 2 and a
> port 4
> > but no port 3.
>
> sure but solving this in the driver by using a virtual port abstraction
> is imho not good.
>
> i'll see if i can think of a better solution for this issue

As this is a board specific issue, I thought solving this in the
devicetree would be a nice way.

But any better solution would be welcome.

>
>
>
>
>
> >
> >>
> >>
> >>
> >>> ---
> >>> Changes in v2:
> >>> - use devicetree aliases instead of 'id' property
> >>> - only map ports, which are "configured" in the devicetree
> >>>
> >>>  .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 46
> >> --
> >>>  1 file changed, 33 insertions(+), 13 deletions(-)
> >>>
> >>> diff --git a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-
> >> adds-xrx200-net.patch b/target/linux/lantiq/patches-4.1/0025-NET-
> MIPS-
> >> lantiq-adds-xrx200-net.patch
> >>> index 48c7395..c76c165 100644
> >>> --- a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-
> >> xrx200-net.patch
> >>> +++ b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-
> >> xrx200-net.patch
> >>> @@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> >> xrx200-net
> >>>  +};
> >>>  --- /dev/null
> >>>  +++ b/drivers/net/ethernet/lantiq_xrx200.c
> >>> -@@ -0,0 +1,1798 @@
> >>> +@@ -0,0 +1,1818 @@
> >>>  +/*
> >>>  + *   This program is free software; you can redistribute it
> and/or
> >> modify it
> >>>  + *   under the terms of the GNU General Public License version 2
> as
> >> published
> >>> @@ -404,6 +404,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> >> xrx200-net
> >>>  +
> >>>  +struct xrx200_port {
> >>>  +u8 num;
> >>> ++u8 id;
> >>>  +u8 phy_addr;
> >>>  +u16 flags;
> >>>  +phy_interface_t phy_if;
> >>> @@ -461,6 +462,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> >> xrx200-net
> >>>  +struct xrx200_hw *hw;
> >>>  +};
> >>>  +
> >>> ++static int id_to_mac[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
> >>> ++static int mac_to_id[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
> >>> ++
> >>>  +static __iomem void *xrx200_switch_membase;
> >>>  +static __iomem void *xrx200_mii_membase;
> >>>  +static __iomem void *xrx200_mdio_membase;
> >>> @@ -789,9 +793,13 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> >> xrx200-net
> >>>  +{
> >>>  +struct switch_port *p = >value.ports[i];
> >>>  +
> >>> -+portmap |= (1 << p->id);
> >>> ++if (id_to_mac[p->id] < 0) {
> >>> ++continue;
> >>> ++}
> >>> ++
> >>> ++portmap |= (1 << id_to_mac[p->id]);

Re: [OpenWrt-Devel] [PATCH v2] lantiq, xrx200-net: add devicetree aliases support for port->mac mapping

[Martin Schiller]

On 12/17/2015 at 9:20 AM, John Crispin wrote:
>
>
> On 14/12/2015 10:18, Martin Schiller wrote:
> > This patch adds devicetree aliases support, which makes it possible
> to
> > renumber the physical mac ports.
> >
> > This change has only cosmetical reasons (e.g. appearance in swconfig,
> > kernel messages on link change).
> >
> > Signed-off-by: Martin Schiller <mschil...@tdt.de>
>
> i have a problem with this patch. port 5 is port 5 *always*. i dont see
> how this fixes an issue. did you HW guys build broken HW with badly
> ordered mac ports ?

Yes, you are right. This patch is intended to reorder broken/unlovely
placed mac ports.

The user should see ports in the order 1,2,3,4,5 instead of 1,4,5,2,3.

Our HW guys told us it would be much more work to solve this in hardware
by doing a lot of "wire crossings" (with unwanted hf side-effects) in the
pcb layout.

And there are also situations, where you even can't do it in hardware:
when you use the xrx200 in Gigabit mode, you can use mac 0,1,2,4,5.
mac/port 3 is dead in this case.

But you can't tell an enduser/customer that there is a port 2 and a port 4
but no port 3.


>
>
>
> > ---
> > Changes in v2:
> > - use devicetree aliases instead of 'id' property
> > - only map ports, which are "configured" in the devicetree
> >
> >  .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 46
> --
> >  1 file changed, 33 insertions(+), 13 deletions(-)
> >
> > diff --git a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-
> adds-xrx200-net.patch b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-
> lantiq-adds-xrx200-net.patch
> > index 48c7395..c76c165 100644
> > --- a/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-
> xrx200-net.patch
> > +++ b/target/linux/lantiq/patches-4.1/0025-NET-MIPS-lantiq-adds-
> xrx200-net.patch
> > @@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +};
> >  --- /dev/null
> >  +++ b/drivers/net/ethernet/lantiq_xrx200.c
> > -@@ -0,0 +1,1798 @@
> > +@@ -0,0 +1,1818 @@
> >  +/*
> >  + *   This program is free software; you can redistribute it and/or
> modify it
> >  + *   under the terms of the GNU General Public License version 2 as
> published
> > @@ -404,6 +404,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +
> >  +struct xrx200_port {
> >  +u8 num;
> > ++u8 id;
> >  +u8 phy_addr;
> >  +u16 flags;
> >  +phy_interface_t phy_if;
> > @@ -461,6 +462,9 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +struct xrx200_hw *hw;
> >  +};
> >  +
> > ++static int id_to_mac[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
> > ++static int mac_to_id[XRX200_MAX_PORT] = {-1,-1,-1,-1,-1,-1,6};
> > ++
> >  +static __iomem void *xrx200_switch_membase;
> >  +static __iomem void *xrx200_mii_membase;
> >  +static __iomem void *xrx200_mdio_membase;
> > @@ -789,9 +793,13 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +{
> >  +struct switch_port *p = >value.ports[i];
> >  +
> > -+portmap |= (1 << p->id);
> > ++if (id_to_mac[p->id] < 0) {
> > ++continue;
> > ++}
> > ++
> > ++portmap |= (1 << id_to_mac[p->id]);
> >  +if (p->flags & (1 << SWITCH_PORT_FLAG_TAGGED))
> > -+tagmap |= (1 << p->id);
> > ++tagmap |= (1 << id_to_mac[p->id]);
> >  +}
> >  +
> >  +tem.table = XRX200_PCE_VLANMAP_IDX;
> > @@ -855,7 +863,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +continue;
> >  +
> >  +p = >value.ports[val->len++];
> > -+p->id = i;
> > ++p->id = mac_to_id[i];
> >  +if (tags & (1 << i))
> >  +p->flags = (1 << SWITCH_PORT_FLAG_TAGGED);
> >  +else
> > @@ -898,11 +906,12 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +}
> >  +
> >  +// port
> > -+static int xrx200sw_get_port_pvid(struct switch_dev *dev, int port,
> int *val)
> > ++static int xrx200sw_get_port_pvid(struct switch_dev *dev, int
> port_id, int *val)
> >  +{
> > ++int port = id_to_mac[port_id];
> >  +struct xrx200_pce_table_entry tev;
> >  +
> > -+if (port >= XRX200_MAX_PORT)
> > ++if (port < 0 || port >= XRX200_MAX_PORT)
> >  +return -EINVAL;
> >  +
> >  +tev.table = XRX200_PCE_ACTVLAN_IDX;
> > @@ -914,10 +923,12 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +}
> >  +
> >  +static int xrx200sw_get_

Re: [OpenWrt-Devel] Review of 0012-pinctrl-lantiq-fix-up-pinmux.patch

[Martin Schiller]

On 11/17/2015 at 8:50 AM, Martin Schiller wrote:
> Hi,
>
> here follows a little review of the 0012-pinctrl-lantiq-fix-up-
> pinmux.patch
> to get this stuff upstream:
>
> > From 25494c55a4007a1409f53ddbafd661636e47ea34 Mon Sep 17 00:00:00
> 2001
> > From: John Crispin <blo...@openwrt.org>
> > Date: Fri, 9 Aug 2013 20:38:15 +0200
> > Subject: [PATCH 12/36] pinctrl/lantiq: fix up pinmux
> >
> > We found out how to set the gphy led pinmuxing.
> >
> > Signed-off-by: John Crispin <blo...@openwrt.org>
> > ---
> >  drivers/pinctrl/pinctrl-xway.c |   28 ++--
> >  1 file changed, 26 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/pinctrl/pinctrl-xway.c
> > +++ b/drivers/pinctrl/pinctrl-xway.c
> > @@ -609,10 +609,9 @@ static struct pinctrl_desc xway_pctrl_de
> >  .confops= _pinconf_ops,
> >  };
> >
> > -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> > +static int mux_apply(struct ltq_pinmux_info *info,
> >  int pin, int mux)
> >  {
> > -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> >  int port = PORT(pin);
> >  u32 alt1_reg = GPIO_ALT1(pin);
> >
> > @@ -632,6 +631,14 @@ static inline int xway_mux_apply(struct
> >  return 0;
> >  }
> >
> > +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> > +int pin, int mux)
> > +{
> > +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> > +
> > +return mux_apply(info, pin, mux);
> > +}
> > +
> >  static const struct ltq_cfg_param xway_cfg_params[] = {
> >  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
> >  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},
>
> What are these changes for?
>
> > @@ -676,6 +683,10 @@ static int xway_gpio_dir_out(struct gpio
> >  {
> >  struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> >
> > +if (PORT(pin) == PORT3)
> > +gpio_setbit(info->membase[0], GPIO3_OD, PORT_PIN(pin));
> > +else
> > +gpio_setbit(info->membase[0], GPIO_OD(pin), PORT_PIN(pin));
> >  gpio_setbit(info->membase[0], GPIO_DIR(pin), PORT_PIN(pin));
> >  xway_gpio_set(chip, pin, val);
> >
>
> This fixes the GPIO Setup for GPIOs >= GPIO48 (GPIO Port3), right?
>
>
> > @@ -696,6 +707,18 @@ static void xway_gpio_free(struct gpio_c
> >  pinctrl_free_gpio(gpio);
> >  }
> >
> > +static int xway_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
> > +{
> > +struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> > +int i;
> > +
> > +for (i = 0; i < info->num_exin; i++)
> > +if (info->exin[i] == offset)
> > +return ltq_eiu_get_irq(i);
> > +
> > +return -1;
> > +}
> > +
> >  static struct gpio_chip xway_chip = {
> >  .label = "gpio-xway",
> >  .direction_input = xway_gpio_dir_in,
> > @@ -704,6 +727,7 @@ static struct gpio_chip xway_chip = {
> >  .set = xway_gpio_set,
> >  .request = xway_gpio_req,
> >  .free = xway_gpio_free,
> > +.to_irq = xway_gpio_to_irq,
> >  .base = -1,
> >  };
> >
>
> This implements the IRQ Mapping for GPIOs.
>
>
> So which of these changes is related to gphy led pinmuxing?
>
> I think we can make 2 patches out of this one:
>
> [1/2] pinctrl/lantiq: Fix GPIO Setup for GPIO Port3
> [2/2] pinctrl/lantiq: Implement gpio_chip.to_irq

Aren't there any comments / suggestions?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Review of 0012-pinctrl-lantiq-fix-up-pinmux.patch

[Martin Schiller]

On 11/19/2015 at 8:15 AM, John Crispin wrote:
>
>
> On 19/11/2015 06:39, Martin Schiller wrote:
> > On 11/17/2015 at 8:50 AM, Martin Schiller wrote:
> >> Hi,
> >>
> >> here follows a little review of the 0012-pinctrl-lantiq-fix-up-
> >> pinmux.patch
> >> to get this stuff upstream:
> >>
> >>> From 25494c55a4007a1409f53ddbafd661636e47ea34 Mon Sep 17 00:00:00
> >> 2001
> >>> From: John Crispin <blo...@openwrt.org>
> >>> Date: Fri, 9 Aug 2013 20:38:15 +0200
> >>> Subject: [PATCH 12/36] pinctrl/lantiq: fix up pinmux
> >>>
> >>> We found out how to set the gphy led pinmuxing.
> >>>
> >>> Signed-off-by: John Crispin <blo...@openwrt.org>
> >>> ---
> >>>  drivers/pinctrl/pinctrl-xway.c |   28 ++--
> >>>  1 file changed, 26 insertions(+), 2 deletions(-)
> >>>
> >>> --- a/drivers/pinctrl/pinctrl-xway.c
> >>> +++ b/drivers/pinctrl/pinctrl-xway.c
> >>> @@ -609,10 +609,9 @@ static struct pinctrl_desc xway_pctrl_de
> >>>  .confops= _pinconf_ops,
> >>>  };
> >>>
> >>> -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> >>> +static int mux_apply(struct ltq_pinmux_info *info,
> >>>  int pin, int mux)
> >>>  {
> >>> -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> >>>  int port = PORT(pin);
> >>>  u32 alt1_reg = GPIO_ALT1(pin);
> >>>
> >>> @@ -632,6 +631,14 @@ static inline int xway_mux_apply(struct
> >>>  return 0;
> >>>  }
> >>>
> >>> +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> >>> +int pin, int mux)
> >>> +{
> >>> +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> >>> +
> >>> +return mux_apply(info, pin, mux);
> >>> +}
> >>> +
> >>>  static const struct ltq_cfg_param xway_cfg_params[] = {
> >>>  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
> >>>  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},
> >>
> >> What are these changes for?
> >>
> >>> @@ -676,6 +683,10 @@ static int xway_gpio_dir_out(struct gpio
> >>>  {
> >>>  struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> >>>
> >>> +if (PORT(pin) == PORT3)
> >>> +gpio_setbit(info->membase[0], GPIO3_OD, PORT_PIN(pin));
> >>> +else
> >>> +gpio_setbit(info->membase[0], GPIO_OD(pin), PORT_PIN(pin));
> >>>  gpio_setbit(info->membase[0], GPIO_DIR(pin), PORT_PIN(pin));
> >>>  xway_gpio_set(chip, pin, val);
> >>>
> >>
> >> This fixes the GPIO Setup for GPIOs >= GPIO48 (GPIO Port3), right?
> >>
> >>
> >>> @@ -696,6 +707,18 @@ static void xway_gpio_free(struct gpio_c
> >>>  pinctrl_free_gpio(gpio);
> >>>  }
> >>>
> >>> +static int xway_gpio_to_irq(struct gpio_chip *chip, unsigned
> offset)
> >>> +{
> >>> +struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> >>> +int i;
> >>> +
> >>> +for (i = 0; i < info->num_exin; i++)
> >>> +if (info->exin[i] == offset)
> >>> +return ltq_eiu_get_irq(i);
> >>> +
> >>> +return -1;
> >>> +}
> >>> +
> >>>  static struct gpio_chip xway_chip = {
> >>>  .label = "gpio-xway",
> >>>  .direction_input = xway_gpio_dir_in,
> >>> @@ -704,6 +727,7 @@ static struct gpio_chip xway_chip = {
> >>>  .set = xway_gpio_set,
> >>>  .request = xway_gpio_req,
> >>>  .free = xway_gpio_free,
> >>> +.to_irq = xway_gpio_to_irq,
> >>>  .base = -1,
> >>>  };
> >>>
> >>
> >> This implements the IRQ Mapping for GPIOs.
> >>
> >>
> >> So which of these changes is related to gphy led pinmuxing?
> >>
> >> I think we can make 2 patches out of this one:
> >>
> >> [1/2] pinctrl/lantiq: Fix GPIO Setup for GPIO Port3
> >> [2/2] pinctrl/lantiq: Implement gpio_chip.to_irq
> >
> > Aren't there any comments / suggestions?
> >
>
> we are not a barber shop where you can walk in and demand to be
> serviced right away.

It seemed to me that this topic about the pinctrl is interesting for some 
people here.

I just thought this mail was overseen/forgotten.

But you are right, there is no obligation for a quick answer.

Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/5] lantiq/xrx200-net: fix PCE_MAPx handling

[Martin Schiller]

On 02/20/2016 at 10:59 AM, Felix Fietkau wrote:
> On 2016-02-18 14:13, Martin Schiller wrote:
> > Remove unnecessary MPMAP (PCE_MAP1) initialization and make
> DMCPMAP (PCE_MAP2)
> > and UUCMAP (PCE_MAP3) configurable from user space.
> >
> > Signed-off-by: Martin Schiller <mschil...@tdt.de>
> This looks a lot like a low level implementation detail that should not
> be exposed to the configuration. Please provide an explanation of how
> exactly these port map registers works, so we can figure out a way to
> set it dynamically from within the driver.
>
> - Felix

MPMAP is the map of ports to which incoming frames shall be sent for
monitoring.

There are a lot of other registers where you can configure which kind of
frames shall be monitored. So adding ports to the MPMAP without further
configuration doesn't make sense, and so the MPMAP initialization should
be removed.

DMCPMAP is the map of ports to which incoming unknown multicast and
broadcast frames shall be sent.

UUCMAP ist he map of ports to which incoming unknown unicast frames
shall be sent.

 I introduced this configure options, because they were helpful to figure
out the behaivor of this mappings while I was "fighting" with the LAN/WAN port
separation, but there is actually no really strong need to have access to this
registers from userspace.

So my thought was that it won't hurt or break anything else when I add the
opportunity to change this register values from userspace.

Regards,
Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] lantiq/xrx200-net: separate lan and wan ports

[Martin Schiller]

Hi!

I need to set up the xrx200 switch with one LAN switch part (phy2-phy5) and one 
WAN port (phy1).

The problem is, that I can see the LAN traffic on the WAN port and vice versa.

It doesn't also matter if SW_PORTMAP is defined or not.

I think it maybe has something to do with the PCE_PMAPx setup, but how to set 
this port mappings to get separated LAN and WAN groups?

The dts configuration is a follow:

wan: interface@0 {
compatible = "lantiq,xrx200-pdi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
mac-address = [ 00 11 22 33 44 56 ];
lantiq,wan;

ethernet@1 {
compatible = "lantiq,xrx200-pdi-port";
reg = <1>;
phy-mode = "rgmii";
phy-handle = <>;
};
};

lan: interface@1 {
compatible = "lantiq,xrx200-pdi";
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
mac-address = [ 00 11 22 33 44 55 ];
lantiq,switch;

ethernet@2 {
compatible = "lantiq,xrx200-pdi-port";
reg = <2>;
phy-mode = "mii";
phy-handle = <>;
};
ethernet@3 {
compatible = "lantiq,xrx200-pdi-port";
reg = <3>;
phy-mode = "mii";
phy-handle = <>;
};
ethernet@4 {
compatible = "lantiq,xrx200-pdi-port";
reg = <4>;
phy-mode = "mii";
phy-handle = <>;
};
ethernet@5 {
compatible = "lantiq,xrx200-pdi-port";
reg = <5>;
phy-mode = "mii";
phy-handle = <>;
};
};


Regards,
Martin


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq/xrx200-net: separate lan and wan ports

[Martin Schiller]

On 02/16/2016 at 9:46 AM, Martin Schiller wrote:
> On 02/16/2016 at 8:32 AM, Martin Blumenstingl wrote:
> > On Tue, Feb 16, 2016 at 8:06 AM, Martin Schiller <mschil...@tdt.de> wrote:
> > > Hi!
> > >
> > > I need to set up the xrx200 switch with one LAN switch part (phy2-phy5)
> > and one WAN port (phy1).
> > >
> > > The problem is, that I can see the LAN traffic on the WAN port and vice
> > versa.
> > >
> > > It doesn't also matter if SW_PORTMAP is defined or not.
> > >
> > > I think it maybe has something to do with the PCE_PMAPx setup, but
> how
> > to set this port mappings to get separated LAN and WAN groups?
> > I think you are right on this one. There's one user who investigated
> > some PPPoE/broadcast issue with the WAN port and here's what he found
> > out: [0]
> > Here's where the initialization takes place in the OpenWrt driver: [1]
> >
> > To sum up "ased's" findings, the original driver (at least in some of
> > the ifxmips_ppa_datapath_vr9_* configurations):
> > - PCE_PMAP1 is set to 0x40 (= port 7 / CPU port) instead of 0x7f (= all 
> > ports)
> > - PCE_PMAP2 and 3 are set to 0x7f & (~priv->hw->wan_map) ("all but the
> > configured WAN port(s)")
>
> I've already tried this and it will fix only half the problem:
> By removing the wan port from this port mappings, there will be no LAN
> traffic on the WAN port any more.
> But the incoming WAN traffic is still on the LAN side.
>
> I also wonder what the PMAC_EWAN register setting may have to do with
> this, or what it is good for at all.

After crawling through a lots of documents I found an Application Note from 
Lantiq which includes some kind of "best practice" for this use case.
As this document is distributed to us with NDA, I will use my own words. :-)

- enable global VLAN support
- add the WAN port(s) to the Ethernet WAN group (PMAC_EWAN)
- enable VLAN transparent mode on all ports
- for all LAN ports: PVID = , FID (Filtering Identifier) = 
- on the CPU port: PVID = , FID = 
- for all WAN ports: PVID= , FID = 
- vlan group  includes all LAN ports + CPU port, all untagged
- vlan group  includes all ports, all untagged
- vlan group  includes all WAN ports + CPU port, all untagged
- UUCMAP (unknown unicast port map) = 0x7F
- DMCPMAP (unknown multicast, broadcast port map) = 0x7F

To do this, there are some changes on the xrx200net driver neccessary 
(dedicated PVID setup; one port can be (untagged) member of multiple VLAN 
groups, FID (Filtering Identifier) support)

My first test seems ok so far.

Some patches will follow.

>
> >
> > I don't have access to the datasheets, so I cannot say what
> > "monitoring" means exactly (PCE_PMAP1).
> > Unfortunately I did not have time to play around with it yet, so I
> > can't tell you much more.
> > But maybe someone with access to the datasheets can at least confirm
> > this and explain the PCE_PMAP1 register.

The PCE_PMAP1 register isn't usefull in this context und should be left with 
the reset value 0x00 so far.
As far as I understand this register is for monitoring / redirection purposes, 
where all/some configured kind of packets are send to these mapped ports.

> >
> >
> > Regards,
> > Martin
> >
> >
> > [0] http://openwrt.ebilan.co.uk/viewtopic.php?p=893#p893
> > [1]
> >
> https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patc
> > hes-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch#L1696


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/5] lantiq/xrx200-net: Add support for eth0 as WAN interface if the SW_PORTMAP is disabled

[Martin Schiller]

Use priv->wan instead of priv->id as indicator if packets should go to the
Ethernet WAN group (DPID=1) or not (DPID=0). This way, it's independant of
interface names or indexes.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 3250a9b..8c8513b 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -1277,7 +1277,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  #ifdef SW_PORTMAP
 +  special_tag |= priv->port_map << PORT_MAP_SHIFT;
 +  #else
-+  if(priv->id)
++  if(priv->wan)
 +  special_tag |= (1 << DPID_SHIFT);
 +  #endif
 +  if(skb_headroom(skb) < 4) {
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/5] lantiq/xrx200-net: fix PCE_MAPx handling

[Martin Schiller]

Remove unnecessary MPMAP (PCE_MAP1) initialization and make DMCPMAP (PCE_MAP2)
and UUCMAP (PCE_MAP3) configurable from user space.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 42 ++
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 8c8513b..0b2dae3 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +};
 --- /dev/null
 +++ b/drivers/net/ethernet/lantiq_xrx200.c
-@@ -0,0 +1,1801 @@
+@@ -0,0 +1,1815 @@
 +/*
 + *   This program is free software; you can redistribute it and/or modify it
 + *   under the terms of the GNU General Public License version 2 as published
@@ -963,12 +963,25 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +// attributes
 +static struct switch_attr xrx200sw_globals[] = {
 +  {
++  XRX200_GLOBAL_REGATTR(XRX200_PCE_PMAP_2_DMCPMAP),
++  .name = "dmcpmap",
++  .description = "Default Multicast/Broadcast Port Map",
++  .max = 0x7F,
++  },
++  {
++  XRX200_GLOBAL_REGATTR(XRX200_PCE_PMAP_3_UUCMAP),
++  .name = "uucmap",
++  .description = "Default Unknown Unicast Port Map",
++  .max = 0x7F,
++  },
++  {
 +  .type = SWITCH_TYPE_INT,
 +  .set = xrx200_set_vlan_mode_enable,
 +  .get = xrx200_get_vlan_mode_enable,
 +  .name = "enable_vlan",
 +  .description = "Enable VLAN mode",
-+  .max = 1},
++  .max = 1,
++  },
 +};
 +
 +static struct switch_attr xrx200sw_port[] = {
@@ -1693,11 +1706,12 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +  /* load the pce microcode */
 +  xrx200_pci_microcode();
 +
-+  /* Default unknown Broadcat/Multicast/Unicast port maps */
-+  ltq_switch_w32(0x7f, PCE_PMAP1);
-+  ltq_switch_w32(0x7f, PCE_PMAP2);
-+  ltq_switch_w32(0x7f, PCE_PMAP3);
++  /* Default unknown Multicast/Broadcast port map (DMCPMAP) */
++  ltq_switch_w32(0x7F, PCE_PMAP2);
 +
++  /* Default unknown Unicast port map (UUCMAP) */
++  ltq_switch_w32(0x7F, PCE_PMAP3);
++ 
 +  /* RMON Counter Enable for all physical ports */
 +  for (i = 0; i < 7; i++)
 +  ltq_switch_w32(0x1, BM_PCFG(i));
@@ -2295,10 +2309,10 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +//XRX200_PCE_AGE_1_MANT, /* Aging Counter Mantissa Value  */
 +//XRX200_PCE_PMAP_1, /* Port Map Register 1 */
 +//XRX200_PCE_PMAP_1_MPMAP,   /* Monitoring Port Map */
-+//XRX200_PCE_PMAP_2, /* Port Map Register 2 */
-+//XRX200_PCE_PMAP_2_DMCPMAP, /* Default Multicast Port Map */
-+//XRX200_PCE_PMAP_3, /* Port Map Register 3 */
-+//XRX200_PCE_PMAP_3_UUCMAP,  /* Default Unknown Unicast Port Map */
++  XRX200_PCE_PMAP_2, /* Port Map Register 2 */
++  XRX200_PCE_PMAP_2_DMCPMAP, /* Default Multicast Port Map */
++  XRX200_PCE_PMAP_3, /* Port Map Register 3 */
++  XRX200_PCE_PMAP_3_UUCMAP,  /* Default Unknown Unicast Port Map */
 +//XRX200_PCE_GCTRL_0,/* PCE Global Control Register0 */
 +//XRX200_PCE_GCTRL_0_IGMP,   /* IGMP Mode Selection */
 +  XRX200_PCE_GCTRL_0_VLAN,   /* VLAN-aware Switching */
@@ -2951,10 +2965,10 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +//{0x1148, 0, 16, 0x00}, /* XRX200_PCE_AGE_1_MANT 
 Aging Counter Mantissa Value  */
 +//{0x114C, 0, 16, 0x00}, /* XRX200_PCE_PMAP_1 
 Port Map Register 1 */
 +//{0x114C, 0, 16, 0x00}, /* XRX200_PCE_PMAP_1_MPMAP   
 Monitoring Port Map */
-+//{0x1150, 0, 16, 0x00}, /* XRX200_PCE_PMAP_2 
 Port Map Register 2 */
-+//{0x1150, 0, 16, 0x00}, /* XRX200_PCE_PMAP_2_DMCPMAP 
 Default Multicast Port Map */
-+//{0x1154, 0, 16, 0x00}, /* XRX200_PCE_PMAP_3 
 Port Map Register 3 */
-+//{0x1154, 0, 16, 0x00}, /* XRX200_PCE_PMAP_3_UUCMAP  
 Default Unknown Unicast Port Map */
++  {0x1150, 0, 16, 0x00}, /* XRX200_PCE_PMAP_2 
 Port Map Register 2 */
++  {0x1150, 0, 16, 0x00}, /* XRX200_PCE_PMAP_2_DMCPMAP 
 Default Multicast Port Map */
++  {0x1154, 0, 16, 0x00}, /* XRX200_PCE_PMAP_3 
 Port Map Register 3 */
++  {0x1154, 0, 16, 

[OpenWrt-Devel] [PATCH 3/5] lantiq/xrx200-net: fix VID max value

[Martin Schiller]

The correct possible VID range is 0-4095.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 0b2dae3..531bbd0 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -1015,10 +1015,10 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds 
xrx200-net
 +  {
 +  .type = SWITCH_TYPE_INT,
 +  .name = "vid",
-+  .description = "VLAN ID (0-4094)",
++  .description = "VLAN ID (0-4095)",
 +  .set = xrx200sw_set_vlan_vid,
 +  .get = xrx200sw_get_vlan_vid,
-+  .max = 4094,
++  .max = 4095,
 +  },
 +  {
 +  .type = SWITCH_TYPE_INT,
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/5] lantiq/xrx200-net: add FID (filtering identifier) setting

[Martin Schiller]

By setting the FID of a VLAN group to a value other then the default (0) it
is possible to switch from Shared VLAN Learning to Independant VLAN Learning.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 531bbd0..9d598a3 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +};
 --- /dev/null
 +++ b/drivers/net/ethernet/lantiq_xrx200.c
-@@ -0,0 +1,1815 @@
+@@ -0,0 +1,1852 @@
 +/*
 + *   This program is free software; you can redistribute it and/or modify it
 + *   under the terms of the GNU General Public License version 2 as published
@@ -778,6 +778,35 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  return 0;
 +}
 +
++static int xrx200sw_set_vlan_fid(struct switch_dev *dev, const struct 
switch_attr *attr,
++   struct switch_val *val)
++{
++  int i;
++  struct xrx200_pce_table_entry tev;
++
++  tev.table = XRX200_PCE_ACTVLAN_IDX;
++
++  tev.index = val->port_vlan;
++  xrx200_pce_table_entry_read();
++  tev.val[0] = val->value.i;
++  xrx200_pce_table_entry_write();
++
++  return 0;
++}
++
++static int xrx200sw_get_vlan_fid(struct switch_dev *dev, const struct 
switch_attr *attr,
++   struct switch_val *val)
++{
++  struct xrx200_pce_table_entry te;
++
++  te.table = XRX200_PCE_ACTVLAN_IDX;
++  te.index = val->port_vlan;
++  xrx200_pce_table_entry_read();
++  val->value.i = te.val[0];
++
++  return 0;
++}
++
 +static int xrx200sw_set_vlan_ports(struct switch_dev *dev, struct switch_val 
*val)
 +{
 +  int i, portmap, tagmap, untagged;
@@ -1022,6 +1051,14 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  },
 +  {
 +  .type = SWITCH_TYPE_INT,
++  .name = "fid",
++  .description = "Filtering Identifier (0-63)",
++  .set = xrx200sw_set_vlan_fid,
++  .get = xrx200sw_get_vlan_fid,
++  .max = 63,
++  },
++  {
++  .type = SWITCH_TYPE_INT,
 +  .name = "enable",
 +  .description = "Enable VLAN",
 +  .set = xrx200sw_set_vlan_enable,
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 5/5] lantiq/xrx200-net: change VLAN untagged ports and PVID handling

[Martin Schiller]

This patch adds the xrx200sw_set_port_pvid() function and removes the
xrx200sw_fixup_pvids() function and the restriction that a switch port can only
be an untagged member of one VLAN group.

There are situations, where an switch port needs to be a member of multiple
VLAN groups without VLAN tagging enabled, so it's not possible to set the
PVID automatically like the xrx200sw_fixup_pvids() did it before and has to
be specified explicitly.

Signed-off-by: Martin Schiller <mschil...@tdt.de>
---
 .../0025-NET-MIPS-lantiq-adds-xrx200-net.patch | 76 --
 1 file changed, 26 insertions(+), 50 deletions(-)

diff --git 
a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch 
b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
index 9d598a3..b7f4965 100644
--- a/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
+++ b/target/linux/lantiq/patches-4.4/0025-NET-MIPS-lantiq-adds-xrx200-net.patch
@@ -209,7 +209,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +};
 --- /dev/null
 +++ b/drivers/net/ethernet/lantiq_xrx200.c
-@@ -0,0 +1,1852 @@
+@@ -0,0 +1,1828 @@
 +/*
 + *   This program is free software; you can redistribute it and/or modify it
 + *   under the terms of the GNU General Public License version 2 as published
@@ -639,48 +639,6 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  return 0;
 +}
 +
-+static void xrx200sw_fixup_pvids(void)
-+{
-+  int index, p, portmap, untagged;
-+  struct xrx200_pce_table_entry tem;
-+  struct xrx200_pce_table_entry tev;
-+
-+  portmap = 0;
-+  for (p = 0; p < XRX200_MAX_PORT; p++)
-+  portmap |= BIT(p);
-+
-+  tem.table = XRX200_PCE_VLANMAP_IDX;
-+  tev.table = XRX200_PCE_ACTVLAN_IDX;
-+
-+  for (index = XRX200_MAX_VLAN; index-- > 0;)
-+  {
-+  tev.index = index;
-+  xrx200_pce_table_entry_read();
-+
-+  if (tev.valid == 0)
-+  continue;
-+
-+  tem.index = index;
-+  xrx200_pce_table_entry_read();
-+
-+  if (tem.val[0] == 0)
-+  continue;
-+
-+  untagged = portmap & (tem.val[1] ^ tem.val[2]);
-+
-+  for (p = 0; p < XRX200_MAX_PORT; p++)
-+  if (untagged & BIT(p))
-+  {
-+  portmap &= ~BIT(p);
-+  xrx200sw_write_x(index, 
XRX200_PCE_DEFPVID_PVID, p);
-+  }
-+
-+  for (p = 0; p < XRX200_MAX_PORT; p++)
-+  if (portmap & BIT(p))
-+  xrx200sw_write_x(index, 
XRX200_PCE_DEFPVID_PVID, p);
-+  }
-+}
-+
 +// swconfig interface
 +static void xrx200_hw_init(struct xrx200_hw *hw);
 +
@@ -761,7 +719,6 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  tem.val[0] = val->value.i;
 +  xrx200_pce_table_entry_write();
 +
-+  xrx200sw_fixup_pvids();
 +  return 0;
 +}
 +
@@ -833,9 +790,6 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +
 +  if (tem.val[0] == 0)
 +  continue;
-+
-+  if ((untagged & (tem.val[1] ^ tem.val[2])) && (val->port_vlan 
!= i))
-+  return -EINVAL;
 +  }
 +
 +  tem.index = val->port_vlan;
@@ -859,8 +813,6 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  tem.val[2] = tagmap;
 +  xrx200_pce_table_entry_write();
 +
-+  xrx200sw_fixup_pvids();
-+
 +  return 0;
 +}
 +
@@ -909,7 +861,6 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  tev.valid = val->value.i;
 +  xrx200_pce_table_entry_write();
 +
-+  xrx200sw_fixup_pvids();
 +  return 0;
 +}
 +
@@ -942,6 +893,30 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  return 0;
 +}
 +
++static int xrx200sw_set_port_pvid(struct switch_dev *dev, int port, int val)
++{
++  int i;
++  struct xrx200_pce_table_entry tev;
++
++  if (port >= XRX200_MAX_PORT)
++  return -EINVAL;
++
++  tev.table = XRX200_PCE_ACTVLAN_IDX;
++
++  for (i = 0; i < XRX200_MAX_VLAN; i++)
++  {
++  tev.index = i;
++  xrx200_pce_table_entry_read();
++  if (tev.key[0] == val)
++  {
++  xrx200sw_write_x(i, XRX200_PCE_DEFPVID_PVID, port);
++  return 0;
++  }
++  }
++
++  return -EINVAL;
++}
++
 +static int xrx200sw_get_port_link(struct switch_dev *dev,
 +int port,
 +struct switch_port_link *link)
@@ -1083,6 +1058,7 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds xrx200-net
 +  .get_vlan_ports = xrx200sw_get_vlan_ports,
 +  .set_vlan_ports = xrx200sw_set_vlan_ports,
 +  .get_port_pvid = xrx200sw_get_port_pvid,
++

Re: [OpenWrt-Devel] [PATCH 4/5] lantiq/xrx200-net: add FID (filtering identifier) setting

[Martin Schiller]

On 02/19/2016 at 6:32 AM, John Crispin wrote:
>
>
> On 18/02/2016 14:13, Martin Schiller wrote:
> > By setting the FID of a VLAN group to a value other then the default (0) it
> > is possible to switch from Shared VLAN Learning to Independant VLAN
> Learning.
> >
>
> and what are the pro / cons of doing so ?

Independant:
On incoming VLAN traffic the source MAC address is learned but is not made
available for other VLANs (with other FIDs).

Shared:
The learned MAC address information is shared between multiple VLANs
(with the same FID).

This feature is used for example to separate the LAN and WAN interfaces.
(like I described here:
https://lists.openwrt.org/pipermail/openwrt-devel/2016-February/039758.html)

[...]

>
> [...]
>
> >  +static int xrx200sw_set_vlan_ports(struct switch_dev *dev, struct
> switch_val *val)
> >  +{
> >  +int i, portmap, tagmap, untagged;
> > @@ -1022,6 +1051,14 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq: adds
> xrx200-net
> >  +},
> >  +{
> >  +.type = SWITCH_TYPE_INT,
> > ++.name = "fid",
> > ++.description = "Filtering Identifier (0-63)",
> > ++.set = xrx200sw_set_vlan_fid,
> > ++.get = xrx200sw_get_vlan_fid,
> > ++.max = 63,
> > ++ },
>
>
> i am not sure it is a good idea to export these options to user(land).
> why do you need them ?

I'm also not happy with this additional option, but for the use case above
for example I don't think we can set the fid in an "automatic" way.

>
> > ++{
> > ++.type = SWITCH_TYPE_INT,
> >  +.name = "enable",
> >  +.description = "Enable VLAN",
> >  +.set = xrx200sw_set_vlan_enable,
> >

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] lantiq/xrx200-net: add FID (filtering identifier) setting

[Martin Schiller]

On 02/19/2016 at 11:27 AM, John Crispin wrote:
>
>
> On 19/02/2016 08:29, Martin Schiller wrote:
> > On 02/19/2016 at 6:32 AM, John Crispin wrote:
> >>
> >>
> >> On 18/02/2016 14:13, Martin Schiller wrote:
> >>> By setting the FID of a VLAN group to a value other then the default (0) 
> >>> it
> >>> is possible to switch from Shared VLAN Learning to Independant VLAN
> >> Learning.
> >>>
> >>
> >> and what are the pro / cons of doing so ?
> >
> > Independant:
> > On incoming VLAN traffic the source MAC address is learned but is not
> made
> > available for other VLANs (with other FIDs).
> >
> > Shared:
> > The learned MAC address information is shared between multiple VLANs
> > (with the same FID).
> >
> > This feature is used for example to separate the LAN and WAN interfaces.
>
> so if i am not misunderstanding this, we want one fid / vlan. can we
> just write the pvid into this field unconditionally

No, in the given "best practice", the cpu-vlan and the lan-vlan share 1 fid,
and the wan-vlan has it independant one.

But i don't know if it is really necessary, that the learned MAC address
information is shared between cpu-vlan and lan-vlan.

The datasheets says, that the shared mode is useful for complex VLAN
traffic patterns without forcing the switch to flood the unicast traffic in
each direction.

When we assume, that it will also be ok that we simply use one unique
fid /vlan group, than it would be the best to use the vlan group index as fid,
because fid has a range of 0-63 and we have vlan 0-63.

The pvid is an port option, which is not unique and can get values from 0 - 
4095.

>
>
>
>
> > (like I described here:
> > https://lists.openwrt.org/pipermail/openwrt-devel/2016-
> February/039758.html)
> >
> > [...]
> >
> >>
> >> [...]
> >>
> >>>  +static int xrx200sw_set_vlan_ports(struct switch_dev *dev, struct
> >> switch_val *val)
> >>>  +{
> >>>  +int i, portmap, tagmap, untagged;
> >>> @@ -1022,6 +1051,14 @@ Subject: [PATCH 25/36] NET: MIPS: lantiq:
> adds
> >> xrx200-net
> >>>  +},
> >>>  +{
> >>>  +.type = SWITCH_TYPE_INT,
> >>> ++.name = "fid",
> >>> ++.description = "Filtering Identifier (0-63)",
> >>> ++.set = xrx200sw_set_vlan_fid,
> >>> ++.get = xrx200sw_get_vlan_fid,
> >>> ++.max = 63,
> >>> ++ },
> >>
> >>
> >> i am not sure it is a good idea to export these options to user(land).
> >> why do you need them ?
> >
> > I'm also not happy with this additional option, but for the use case above
> > for example I don't think we can set the fid in an "automatic" way.
> >
> >>
> >>> ++{
> >>> ++.type = SWITCH_TYPE_INT,
> >>>  +.name = "enable",
> >>>  +.description = "Enable VLAN",
> >>>  +.set = xrx200sw_set_vlan_enable,
> >>>
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/5] lantiq/xrx200-net: add FID (filtering identifier) setting

[Martin Schiller]

On 02/19/2016 at 2:22 PM, John Crispin wrote:
>
>
> On 19/02/2016 14:08, Martin Schiller wrote:
> > On 02/19/2016 at 11:27 AM, John Crispin wrote:
> >>
> >>
> >> On 19/02/2016 08:29, Martin Schiller wrote:
> >>> On 02/19/2016 at 6:32 AM, John Crispin wrote:
> >>>>
> >>>>
> >>>> On 18/02/2016 14:13, Martin Schiller wrote:
> >>>>> By setting the FID of a VLAN group to a value other then the default
> (0) it
> >>>>> is possible to switch from Shared VLAN Learning to Independant VLAN
> >>>> Learning.
> >>>>>
> >>>>
> >>>> and what are the pro / cons of doing so ?
> >>>
> >>> Independant:
> >>> On incoming VLAN traffic the source MAC address is learned but is not
> >> made
> >>> available for other VLANs (with other FIDs).
> >>>
> >>> Shared:
> >>> The learned MAC address information is shared between multiple
> VLANs
> >>> (with the same FID).
> >>>
> >>> This feature is used for example to separate the LAN and WAN
> interfaces.
> >>
> >> so if i am not misunderstanding this, we want one fid / vlan. can we
> >> just write the pvid into this field unconditionally
> >
> > No, in the given "best practice", the cpu-vlan and the lan-vlan share 1 fid,
> > and the wan-vlan has it independant one.
> >
> > But i don't know if it is really necessary, that the learned MAC address
> > information is shared between cpu-vlan and lan-vlan.
> >
> > The datasheets says, that the shared mode is useful for complex VLAN
> > traffic patterns without forcing the switch to flood the unicast traffic in
> > each direction.
> >
> > When we assume, that it will also be ok that we simply use one unique
> > fid /vlan group, than it would be the best to use the vlan group index as 
> > fid,
> > because fid has a range of 0-63 and we have vlan 0-63.
> >
> > The pvid is an port option, which is not unique and can get values from 0 -
> 4095.
> >
>
>
> ok, i assume this comes from the competence center ? can you tell me the
> exact file name and release date so i can go looking for the PDF ?

The "best practice" for Ethernet WAN/LAN separation is from this document:

XWAY_VRX200_Family_PPE_Switch_AN_Rev1.0_20110907.pdf (2.6 MB) / 2013-10-30 
06:06:34

Have a look at chapter 3.6.1

And the Filtering Identifier description is from:

Common Ethernet Switch API Users Manual Programmers Guide Rev4.1 (5.26 MB) / 
2015-03-11 17:14:51

Chapter 4.1.1.3

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] kmod-gpio-mcp23s08 not working/available for linux-4.14

[Martin Schiller]

On 2018-08-23 14:10, Martin Schiller wrote:

On 2018-08-23 12:17, John Crispin wrote:

On 23/08/18 11:53, Martin Schiller wrote:
The mcp23s08 drivers was moved from gpio to pinctrl "subsystem" in 
linux-4.13.


As linux-4.9 is still used for some targets, how to proceed with this 
mcp23s08 driver?
Create a new (second) CONFIG option (kmod-pinctrl-mcp23s08) 
coexisting to the kmod-gpio-mcp23s08?


Or is it possible to get this handled by the existing CONFIG option 
and depend on the kernel version?

Any hints are welcome.


...


add an ifdef guarded sections that check the kernel version inside the
module mk files ?
    John


So I tried this, but "CompareKernelPatchVer" seems not working here:

diff --git a/package/kernel/linux/modules/other.mk
b/package/kernel/linux/modules/other.mk
index c4cf74d98b..3befc9cba8 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -224,6 +224,23 @@ endef
 $(eval $(call KernelPackage,gpio-dev))


+ifeq ($(strip $(call 
CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,4.13.0)),1)

+define KernelPackage/pinctrl-mcp23s08
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Microchip MCP23xxx I/O expander
+  DEPENDS:=@GPIO_SUPPORT +kmod-i2c-core
+  KCONFIG:=CONFIG_PINCTRL_MCP23S08
+  FILES:=$(LINUX_DIR)/drivers/pinctrl/pinctrl-mcp23s08.ko
+  AUTOLOAD:=$(call AutoLoad,40,pinctrl-mcp23s08)
+endef
+
+define KernelPackage/pinctrl-mcp23s08/description
+ Kernel module for Microchip MCP23xxx SPI/I2C I/O expander
+endef
+
+$(eval $(call KernelPackage,pinctrl-mcp23s08))
+
+else
 define KernelPackage/gpio-mcp23s08
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Microchip MCP23xxx I/O expander
@@ -238,7 +255,7 @@ define KernelPackage/gpio-mcp23s08/description
 endef

 $(eval $(call KernelPackage,gpio-mcp23s08))
-
+endif

 define KernelPackage/gpio-nxp-74hc164
   SUBMENU:=$(OTHER_MENU)



OK, so my next approach is this:

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk

index c4cf74d98b..bc97376c87 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -228,9 +228,13 @@ define KernelPackage/gpio-mcp23s08
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Microchip MCP23xxx I/O expander
   DEPENDS:=@GPIO_SUPPORT +kmod-i2c-core
-  KCONFIG:=CONFIG_GPIO_MCP23S08
-  FILES:=$(LINUX_DIR)/drivers/gpio/gpio-mcp23s08.ko
-  AUTOLOAD:=$(call AutoLoad,40,gpio-mcp23s08)
+  KCONFIG:= \
+   CONFIG_GPIO_MCP23S08 \
+   CONFIG_PINCTRL_MCP23S08
+  FILES:= \
+   $(LINUX_DIR)/drivers/gpio/gpio-mcp23s08.ko@lt4.13 \
+   $(LINUX_DIR)/drivers/pinctrl/pinctrl-mcp23s08.ko@ge4.13
+  AUTOLOAD:=$(call AutoLoad,40,gpio-mcp23s08@lt4.13 
pinctrl-mcp23s08@ge4.13)

 endef

 define KernelPackage/gpio-mcp23s08/description


I also tried to use the "@ge4.13 / @lt4.13" flags for KCONFIG, but 
doesn't work for me, although it is used elsewhere.


Advantage of this solution is, that the package name is not changed and 
anything works like before.
On the other hand, the mcp23s08 isn't a gpio driver anymore, it's a 
pinctrl driver now (>4.13).


- Martin



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

[OpenWrt-Devel] kmod-gpio-mcp23s08 not working/available for linux-4.14

[Martin Schiller]

The mcp23s08 drivers was moved from gpio to pinctrl "subsystem" in 
linux-4.13.


As linux-4.9 is still used for some targets, how to proceed with this 
mcp23s08 driver?
Create a new (second) CONFIG option (kmod-pinctrl-mcp23s08) coexisting 
to the kmod-gpio-mcp23s08?


Or is it possible to get this handled by the existing CONFIG option and 
depend on the kernel version?

Any hints are welcome.

- Martin


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

Re: [OpenWrt-Devel] kmod-gpio-mcp23s08 not working/available for linux-4.14

[Martin Schiller]

On 2018-08-23 12:17, John Crispin wrote:

On 23/08/18 11:53, Martin Schiller wrote:
The mcp23s08 drivers was moved from gpio to pinctrl "subsystem" in 
linux-4.13.


As linux-4.9 is still used for some targets, how to proceed with this 
mcp23s08 driver?
Create a new (second) CONFIG option (kmod-pinctrl-mcp23s08) coexisting 
to the kmod-gpio-mcp23s08?


Or is it possible to get this handled by the existing CONFIG option 
and depend on the kernel version?

Any hints are welcome.


...


add an ifdef guarded sections that check the kernel version inside the
module mk files ?
    John


So I tried this, but "CompareKernelPatchVer" seems not working here:

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk

index c4cf74d98b..3befc9cba8 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -224,6 +224,23 @@ endef
 $(eval $(call KernelPackage,gpio-dev))


+ifeq ($(strip $(call 
CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,4.13.0)),1)

+define KernelPackage/pinctrl-mcp23s08
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Microchip MCP23xxx I/O expander
+  DEPENDS:=@GPIO_SUPPORT +kmod-i2c-core
+  KCONFIG:=CONFIG_PINCTRL_MCP23S08
+  FILES:=$(LINUX_DIR)/drivers/pinctrl/pinctrl-mcp23s08.ko
+  AUTOLOAD:=$(call AutoLoad,40,pinctrl-mcp23s08)
+endef
+
+define KernelPackage/pinctrl-mcp23s08/description
+ Kernel module for Microchip MCP23xxx SPI/I2C I/O expander
+endef
+
+$(eval $(call KernelPackage,pinctrl-mcp23s08))
+
+else
 define KernelPackage/gpio-mcp23s08
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Microchip MCP23xxx I/O expander
@@ -238,7 +255,7 @@ define KernelPackage/gpio-mcp23s08/description
 endef

 $(eval $(call KernelPackage,gpio-mcp23s08))
-
+endif

 define KernelPackage/gpio-nxp-74hc164
   SUBMENU:=$(OTHER_MENU)


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

Re: [OpenWrt-Devel] u-boot/lantiq: gcc7 incompatibility: resets when trying to access network

[Martin Schiller]

On 2018-09-24 13:38, Martin Schiller wrote:

On 2018-09-24 13:14, Martin Schiller wrote:

Hi,

I've got some problems with the lantiq uboot in combination with the
(default) gcc 7.x compiler.

Setting "OPTFLAGS" in uboot's config.mk to "-O2" or the default "-Os"
leads to the following behaviour:

The uboot compiles well, but when you try o access the ethernet
network (ping/tftboot) the device do a RESET:

(tested on a Lantiq VRX268 v1.2)



VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device

ROM VER: 1.1.4
CFG 04
_�
ROM VER: 1.1.4
CFG 04
EEPROM Data OK
UART



doing the same with "OPTFLAGS" set to "-O1" everything works fine:


...
VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device
host 192.168.1.20 is alive
VR2020 #


When using gcc 6.x or 5.x, "OPTFLAGS=-Os" also works.

Any ideas how to get "OPTFLAGS=-Os" working again with gcc 7.x?


Ok, found out that '-fstore-merging' is responsible for the crash,
which is enabled with "-02" in gcc 7.x by default.

Adding "-fno-store-merging" to "OPTFLAGS" fixes the problem.

Here is also a "statement" to this problem:

https://patchwork.ozlabs.org/patch/792238/



I've backported this commit/fix for uboot-lantiq now:

https://github.com/openwrt/openwrt/pull/1404

Maybe this should also be done for other uboot targets?

- Martin


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

Re: [OpenWrt-Devel] u-boot/lantiq: gcc7 incompatibility: resets when trying to access network

[Martin Schiller]

On 2018-09-24 13:14, Martin Schiller wrote:

Hi,

I've got some problems with the lantiq uboot in combination with the
(default) gcc 7.x compiler.

Setting "OPTFLAGS" in uboot's config.mk to "-O2" or the default "-Os"
leads to the following behaviour:

The uboot compiles well, but when you try o access the ethernet
network (ping/tftboot) the device do a RESET:

(tested on a Lantiq VRX268 v1.2)



VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device

ROM VER: 1.1.4
CFG 04
_�
ROM VER: 1.1.4
CFG 04
EEPROM Data OK
UART



doing the same with "OPTFLAGS" set to "-O1" everything works fine:


...
VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device
host 192.168.1.20 is alive
VR2020 #


When using gcc 6.x or 5.x, "OPTFLAGS=-Os" also works.

Any ideas how to get "OPTFLAGS=-Os" working again with gcc 7.x?


Ok, found out that '-fstore-merging' is responsible for the crash, which 
is enabled with "-02" in gcc 7.x by default.


Adding "-fno-store-merging" to "OPTFLAGS" fixes the problem.

Here is also a "statement" to this problem:

https://patchwork.ozlabs.org/patch/792238/

How should we proceed now for our uboot-lantiq?

- Martin

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

[OpenWrt-Devel] u-boot/lantiq: gcc7 incompatibility: resets when trying to access network

[Martin Schiller]

Hi,

I've got some problems with the lantiq uboot in combination with the 
(default) gcc 7.x compiler.


Setting "OPTFLAGS" in uboot's config.mk to "-O2" or the default "-Os" 
leads to the following behaviour:


The uboot compiles well, but when you try o access the ethernet network 
(ping/tftboot) the device do a RESET:


(tested on a Lantiq VRX268 v1.2)



VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device

ROM VER: 1.1.4
CFG 04
_�
ROM VER: 1.1.4
CFG 04
EEPROM Data OK
UART



doing the same with "OPTFLAGS" set to "-O1" everything works fine:


...
VR2020 # ping 192.168.1.20
ltq_phy: addr 1, link 0, speed 10, duplex 0
ltq_phy: addr 17, link 0, speed 10, duplex 0
ltq_phy: addr 18, link 0, speed 10, duplex 0
ltq_phy: addr 19, link 1, speed 100, duplex 1
ltq_phy: addr 20, link 0, speed 10, duplex 0
Using ltq-eth device
host 192.168.1.20 is alive
VR2020 #


When using gcc 6.x or 5.x, "OPTFLAGS=-Os" also works.

Any ideas how to get "OPTFLAGS=-Os" working again with gcc 7.x?

- Martin

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

[OpenWrt-Devel] [PATCH/netifd] interface: fix "if-down" hotplug event handling

[Martin Schiller]

commit a97297d83e42 ("interface: set interface in TEARDOWN state when checking 
link state")
broke the if-down hotplug event handling, as the iface->state is now 
IFS_TEARDOWN when
calling the mark_interface_down() function from the IFPEV_DOWN event.

Fixes: a97297d83e42 ("interface: set interface in TEARDOWN state when checking 
link state")
Signed-off-by: Martin Schiller 
---
 interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/interface.c b/interface.c
index fd7a826..7c25839 100644
--- a/interface.c
+++ b/interface.c
@@ -268,7 +268,7 @@ mark_interface_down(struct interface *iface)
iface->link_up_event = false;
iface->state = IFS_DOWN;
switch (state) {
-   case IFS_UP:
+   case IFS_TEARDOWN:
interface_event(iface, IFEV_DOWN);
break;
case IFS_SETUP:
-- 
2.11.0


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

[OpenWrt-Devel] [PATCH v2 netifd] interface: fix "if-down" hotplug event handling

[Martin Schiller]

commit a97297d83e42 ("interface: set interface in TEARDOWN state when checking 
link state")
broke the if-down hotplug event handling, as the iface->state is now 
IFS_TEARDOWN when
calling the mark_interface_down() function from the IFPEV_DOWN event.

Fixes: a97297d83e42 ("interface: set interface in TEARDOWN state when checking 
link state")
Signed-off-by: Martin Schiller 
---
 interface.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/interface.c b/interface.c
index fd7a826..e0652cd 100644
--- a/interface.c
+++ b/interface.c
@@ -269,6 +269,7 @@ mark_interface_down(struct interface *iface)
iface->state = IFS_DOWN;
switch (state) {
case IFS_UP:
+   case IFS_TEARDOWN:
interface_event(iface, IFEV_DOWN);
break;
case IFS_SETUP:
-- 
2.11.0


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

Re: [OpenWrt-Devel] [PATCH/netifd] interface: fix "if-down" hotplug event handling

[Martin Schiller]

On 2019-04-11 15:16, Hans Dedecker wrote:

Hi,

On Thu, Apr 11, 2019 at 3:02 PM Martin Schiller  wrote:


commit a97297d83e42 ("interface: set interface in TEARDOWN state when 
checking link state")
broke the if-down hotplug event handling, as the iface->state is now 
IFS_TEARDOWN when

calling the mark_interface_down() function from the IFPEV_DOWN event.

Fixes: a97297d83e42 ("interface: set interface in TEARDOWN state when 
checking link state")

Signed-off-by: Martin Schiller 
---
 interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/interface.c b/interface.c
index fd7a826..7c25839 100644
--- a/interface.c
+++ b/interface.c
@@ -268,7 +268,7 @@ mark_interface_down(struct interface *iface)
iface->link_up_event = false;
iface->state = IFS_DOWN;
switch (state) {
-   case IFS_UP:
+   case IFS_TEARDOWN:

I don't think it's safe to remove the IFS_UP state as
mark_interface_down can be called when the interface is either in the
IFS_UP or IFS_TEARDOWN state



You are right. I will send a v2 where IFS_UP and IFS_TEARDOWN will be 
handled.



Hans

interface_event(iface, IFEV_DOWN);
break;
case IFS_SETUP:
--
2.11.0




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

[OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn

[Martin Schiller]

This command is needed in the qmi proto handler to check if the plmn
is already set to 'auto'.

The reason for this is, that setting the plmn to 'auto' will implicitly
lead to a (delayed) network re-registration, which could further lead
to some timing related issues in the qmi proto handler.

Signed-off-by: Martin Schiller 
---
 commands-nas.c | 31 +++
 commands-nas.h |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/commands-nas.c b/commands-nas.c
index 5874bfb..1f7445d 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -293,6 +293,37 @@ cmd_nas_get_serving_system_prepare(struct qmi_dev *qmi, 
struct qmi_request *req,
 }
 
 static void
+cmd_nas_get_plmn_cb(struct qmi_dev *qmi, struct qmi_request *req, struct 
qmi_msg *msg)
+{
+   struct qmi_nas_get_system_selection_preference_response res;
+   static const char *modes[] = {
+   [QMI_NAS_NETWORK_SELECTION_PREFERENCE_AUTOMATIC] = "automatic",
+   [QMI_NAS_NETWORK_SELECTION_PREFERENCE_MANUAL] = "manual",
+   };
+   void *c;
+
+   qmi_parse_nas_get_system_selection_preference_response(msg, );
+
+   c = blobmsg_open_table(, NULL);
+   if (res.set.network_selection_preference) {
+   blobmsg_add_string(, "mode", 
modes[res.data.network_selection_preference]);
+   }
+   if (res.set.manual_network_selection) {
+   blobmsg_add_u32(, "mcc", 
res.data.manual_network_selection.mcc);
+   blobmsg_add_u32(, "mnc", 
res.data.manual_network_selection.mnc);
+   }
+
+   blobmsg_close_table(, c);
+}
+
+static enum qmi_cmd_result
+cmd_nas_get_plmn_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct 
qmi_msg *msg, char *arg)
+{
+   qmi_set_nas_get_system_selection_preference_request(msg);
+   return QMI_CMD_REQUEST;
+}
+
+static void
 cmd_nas_network_scan_cb(struct qmi_dev *qmi, struct qmi_request *req, struct 
qmi_msg *msg)
 {
static struct qmi_nas_network_scan_response res;
diff --git a/commands-nas.h b/commands-nas.h
index 9ebfa00..4b175f9 100644
--- a/commands-nas.h
+++ b/commands-nas.h
@@ -24,6 +24,7 @@
__uqmi_command(nas_set_network_modes, set-network-modes, required, 
CMD_TYPE_OPTION), \
__uqmi_command(nas_initiate_network_register, network-register, no, 
QMI_SERVICE_NAS), \
__uqmi_command(nas_set_plmn, set-plmn, no, QMI_SERVICE_NAS), \
+   __uqmi_command(nas_get_plmn, get-plmn, no, QMI_SERVICE_NAS), \
__uqmi_command(nas_set_mcc, mcc, required, CMD_TYPE_OPTION), \
__uqmi_command(nas_set_mnc, mnc, required, CMD_TYPE_OPTION), \
__uqmi_command(nas_network_scan, network-scan, no, QMI_SERVICE_NAS), \
@@ -44,6 +45,7 @@
"  --set-plmn:   Register at specified 
network\n" \
"--mcc :Mobile Country Code (0 - 
auto)\n" \
"--mnc :Mobile Network Code\n" \
+   "  --get-plmn:   Get preferred network 
selection info\n" \
"  --get-signal-info:Get signal strength 
info\n" \
"  --get-serving-system: Get serving system info\n" 
\
 
-- 
2.11.0


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

Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn

[Martin Schiller]

On 2019-08-26 21:12, Sami Olmari wrote:

I think the ideology behind proto handler there is to "do whatever
told" despite of what the state is currently,
maybe there is a reason for such behaviour (searches some stuff from
network etc).


There exist 2 problems in the qmi proto handler:

1. Setting the plmn to 'auto' will implicitly lead to a (delayed)
network re-registration, which could further lead to some timing
related issues in the qmi proto handler.
Let me explain this in more detail:
After successfully calling the uqmi --set-plmn (auto) command it takes
up to 5 (or maybe even more) seconds until the modem detaches from 
network

and start searching for new registration.

In the meantime the proto handler goes through the next steps ("Waiting 
for

network registration", "Start network $interface" etc.).

I hope you can see were this leads to.

This is really a problem in Roaming scenarios, where to provider maybe 
is

switched after the re-registration.


2. The plmn setting is permanently saved in the wwan modem:
This leads to the problem, that if you switch back from manual plmn 
selection

to auto mode you have to set it explicitly to 'auto'.

- Martin

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

Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn

[Martin Schiller]

Can somebody please take a look at this patch.

It's really necessary to fix the problem in the qmi proto handler.

Thanks,
Martin

On 2019-07-04 13:35, Martin Schiller wrote:

This command is needed in the qmi proto handler to check if the plmn
is already set to 'auto'.

The reason for this is, that setting the plmn to 'auto' will implicitly
lead to a (delayed) network re-registration, which could further lead
to some timing related issues in the qmi proto handler.

Signed-off-by: Martin Schiller 
---
 commands-nas.c | 31 +++
 commands-nas.h |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/commands-nas.c b/commands-nas.c
index 5874bfb..1f7445d 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -293,6 +293,37 @@ cmd_nas_get_serving_system_prepare(struct qmi_dev
*qmi, struct qmi_request *req,
 }

 static void
+cmd_nas_get_plmn_cb(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg)
+{
+   struct qmi_nas_get_system_selection_preference_response res;
+   static const char *modes[] = {
+   [QMI_NAS_NETWORK_SELECTION_PREFERENCE_AUTOMATIC] = "automatic",
+   [QMI_NAS_NETWORK_SELECTION_PREFERENCE_MANUAL] = "manual",
+   };
+   void *c;
+
+   qmi_parse_nas_get_system_selection_preference_response(msg, );
+
+   c = blobmsg_open_table(, NULL);
+   if (res.set.network_selection_preference) {
+   blobmsg_add_string(, "mode",
modes[res.data.network_selection_preference]);
+   }
+   if (res.set.manual_network_selection) {
+		blobmsg_add_u32(, "mcc", 
res.data.manual_network_selection.mcc);
+		blobmsg_add_u32(, "mnc", 
res.data.manual_network_selection.mnc);

+   }
+
+   blobmsg_close_table(, c);
+}
+
+static enum qmi_cmd_result
+cmd_nas_get_plmn_prepare(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg, char *arg)
+{
+   qmi_set_nas_get_system_selection_preference_request(msg);
+   return QMI_CMD_REQUEST;
+}
+
+static void
 cmd_nas_network_scan_cb(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg)
 {
static struct qmi_nas_network_scan_response res;
diff --git a/commands-nas.h b/commands-nas.h
index 9ebfa00..4b175f9 100644
--- a/commands-nas.h
+++ b/commands-nas.h
@@ -24,6 +24,7 @@
__uqmi_command(nas_set_network_modes, set-network-modes, required,
CMD_TYPE_OPTION), \
__uqmi_command(nas_initiate_network_register, network-register, no,
QMI_SERVICE_NAS), \
__uqmi_command(nas_set_plmn, set-plmn, no, QMI_SERVICE_NAS), \
+   __uqmi_command(nas_get_plmn, get-plmn, no, QMI_SERVICE_NAS), \
__uqmi_command(nas_set_mcc, mcc, required, CMD_TYPE_OPTION), \
__uqmi_command(nas_set_mnc, mnc, required, CMD_TYPE_OPTION), \
 	__uqmi_command(nas_network_scan, network-scan, no, QMI_SERVICE_NAS), 
\

@@ -44,6 +45,7 @@
 		"  --set-plmn:   Register at specified 
network\n" \
 		"--mcc :Mobile Country Code (0 - 
auto)\n" \

"--mnc :Mobile Network Code\n" \
+   "  --get-plmn:   Get preferred network
selection info\n" \
"  --get-signal-info:Get signal strength 
info\n" \
"  --get-serving-system: Get serving system info\n" 
\



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

Re: [OpenWrt-Devel] Lantiq xrx200: Access to ethernet phy registers (MDIO) from userspace

[Martin Schiller]

On 2019-09-16 22:43, Hauke Mehrtens wrote:

On 9/16/19 7:09 PM, Martin Blumenstingl wrote:

Hi Martin,

On Mon, Sep 16, 2019 at 12:54 PM Martin Schiller  
wrote:


Hi!

I am searching for a possibility to disable Auto Negotiation of an
PEF7072 which is attached to MAC1 of the Lantiq xrx200 switch.

The xrx200-net driver does not seem to have support for that.

I don't know about xrx200-net, but ...

Accessing the STD_CRTL register on the mdio bus from uboot with the 
mdio

command works like expected.

Any suggestions how to do that from linux userspace?
... my (limited) understanding is that this is one of the benefits of 
DSA:

you get one interface per port - with that you can use for example
ethtool to disable auto negotiation for one port
kernel source reference: [0]


I also do not know if xrx200-net supports that or if it is possible 
with

swconfig at all. There is also a DSA driver for this switch in the
mainline kernel:
https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/lantiq_gswip.c

This driver should support everything the xrx200-net driver supports
plus some extras.
I would prefer to use the DSA driver also in OpenWrt, but we need a way
to migrate the existing configurations which are based on swconfig to 
DSA.


You could try the fixed-link attribute in device tree to model this 
with

DSA.


Thanks for your answers.

Switching to DSA would be nice, but it's too much work I can't afford 
right now.


Disabling ANEG in the DTS is not enough, because I also need a way to 
turn

ANEG on and off at runtime.

Meanwhile I found out that there is a mechanism with swconfig to 
configure

the link attributes:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6219b3deae1c8dfbf405f5a701d3f3b00ebacce1

I will try to integrate this into the "old" xrx200-net driver.

Martin

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

Re: [OpenWrt-Devel] Lantiq xrx200: Access to ethernet phy registers (MDIO) from userspace

[Martin Schiller]

On 2019-09-17 08:51, Martin Schiller wrote:
Meanwhile I found out that there is a mechanism with swconfig to 
configure

the link attributes:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6219b3deae1c8dfbf405f5a701d3f3b00ebacce1

I will try to integrate this into the "old" xrx200-net driver.


I've sent a PR where I have added the set_port_link feature to the 
xrx200-net driver:


https://github.com/openwrt/openwrt/pull/2421

Martin

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

[OpenWrt-Devel] Lantiq xrx200: Access to ethernet phy registers (MDIO) from userspace

[Martin Schiller]

Hi!

I am searching for a possibility to disable Auto Negotiation of an 
PEF7072 which is attached to MAC1 of the Lantiq xrx200 switch.


The xrx200-net driver does not seem to have support for that.

Accessing the STD_CRTL register on the mdio bus from uboot with the mdio 
command works like expected.


Any suggestions how to do that from linux userspace?

Thanks,
Martin

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

Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn

[Martin Schiller]

Ping.

I still want to fix the existing problems in the qmi protohandler.

Therefore, this feature needs to be integrated into uqmi.

Martin

On 2019-08-29 10:35, Bjørn Mork wrote:

Martin Schiller  writes:


On 2019-08-26 21:12, Sami Olmari wrote:

I think the ideology behind proto handler there is to "do whatever
told" despite of what the state is currently,
maybe there is a reason for such behaviour (searches some stuff from
network etc).


There exist 2 problems in the qmi proto handler:

1. Setting the plmn to 'auto' will implicitly lead to a (delayed)
network re-registration, which could further lead to some timing
related issues in the qmi proto handler.
Let me explain this in more detail:
After successfully calling the uqmi --set-plmn (auto) command it takes
up to 5 (or maybe even more) seconds until the modem detaches from
network
and start searching for new registration.

In the meantime the proto handler goes through the next steps
("Waiting for
network registration", "Start network $interface" etc.).

I hope you can see were this leads to.

This is really a problem in Roaming scenarios, where to provider maybe
is
switched after the re-registration.



FWIW, I also believe this is a real problem.

The modem firmware isn't always smart.  It will "do whatever told", 
even

if it is a completely unnecessary de-registration, network scan and
re-registration.

We can be smarter than that.  We should avoid changing any persistent
(in modem nvram) setting related to network registration, unless
absolutely necessary.


2. The plmn setting is permanently saved in the wwan modem:
This leads to the problem, that if you switch back from manual plmn
selection
to auto mode you have to set it explicitly to 'auto'.


Yes, the current handler will use whatever is stored in the modem 
unless

'plmn' is explictly set.  This is very confusing if you set 'plmn'
temporarily, whether it is for roaming or just experimenting. Users 
will

rightfully assume that adding and then removing 'plmn' means 'no
change'.

Everything in the qmi proto handler should take into account that
settings might be stored in the modem nvram.  Optional settings need an
explicit default, and should always be verified against the value 
stored

in the modem.

I believe the 'plmn' default should be 'auto'. But we can only do that
if we first add the logic to verify the current setting and avoid any
unnecessary 'uqmi --set-plmn' commands.



Bjørn



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

Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

[Martin Schiller]

On 2019-10-12 03:28, Gordon Shawn wrote:

What about skipping 19.07 and focusing on 20.03 instead? Based on the
resource I think one release per year is not bad. By then Luci will be
in a better shape and a newer kernel can also be used instead.


Well, there are always some great changes in the master that you would 
like to have in the stable as well.


But you will never get a release if you don't stop transferring things 
from the master to the stable.


Since 19.07 is already quite a bit late anyway (I remember the 19.01 
plans) and some of us are already betting on this branch as their next 
release base, it would be extremely annoying and inconsistent to start 
all over again.


So my opinion:
Only add bugfixes and security patches into 19.07, no feature changes.

- Martin

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

Re: [OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Ok, I think I've got it:

The "sk_wmem_alloc" is decremented in sock_wfree() which is called
by kfree_skb.

But in ptm_hard_start_xmit() of the ifxmips_ptm_vdsl.c, the skb
only gets freed immediately, if the skb_headroom is to small or
the skb is cloned. In this case the skb is copied to a new one and
the original skb gets freed.

Otherwise the skb only gets freed after a complete round through
the TX descriptor table.

My suggestion would be, to always copy the skb.

- Martin

On 2020-01-20 13:45, Martin Schiller wrote:

Update:

I've found out now that the ENOBUFS is set by __ip_append_data,
because sk_wmem_alloc "overflows".

Martin


On 2020-01-20 07:09, Martin Schiller wrote:

Hi!

I have discovered the following problem:

If you have established a PPPoE session via VDSL / PTM connection 
incl.

VLAN tagging and send data with a relatively small send buffer
(SO_SNDBUF), then an ENOBUFS always comes back.

We first noticed this with stagnating data transfers over an OpenVPN
connection.

Also with iputils-ping, since by default the send buffer is relatively
small.

You can also force this with busybox ping by using

echo "5000"> / proc / sys / net / core / wmem_default

minimizes the system default value.

Then you send pings with a packet size of e.g. 4000 bytes and the
second package is already in the pants:


root @ OpenWrt: ~ # ping -s4000 10.200.1.142
PING 10.200.1.142 (10.200.1.142): 4000 data bytes
4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
ping: sendto: No buffer space available
root @ OpenWrt: ~ #


So it should be easily reproducible for everyone.

Traffic that is only routed through the router is not affected.

The manpage of sendto says:
---
ENOBUFS
The output queue for a network interface was full. This generally
indicates that the interface has stopped sending, but may be 
caused

by transient congestion. (Normally, this does not occur in Linux.
Packets are just silently dropped when a device queue overflows.)
---

But all former packets have already been transmitted.

This issue seems to be in there since lede-17.01.

I can't reproduce it with owrt-15.05.

Does anyone have any idea how to solve the problem?

Martin

___
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



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

Re: [OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Just for reference:
I've opened a pull request with a fix here:
https://github.com/openwrt/openwrt/pull/2707

- Martin

On 2020-01-21 06:28, Martin Schiller wrote:

Ok, I think I've got it:

The "sk_wmem_alloc" is decremented in sock_wfree() which is called
by kfree_skb.

But in ptm_hard_start_xmit() of the ifxmips_ptm_vdsl.c, the skb
only gets freed immediately, if the skb_headroom is to small or
the skb is cloned. In this case the skb is copied to a new one and
the original skb gets freed.

Otherwise the skb only gets freed after a complete round through
the TX descriptor table.

My suggestion would be, to always copy the skb.

- Martin

On 2020-01-20 13:45, Martin Schiller wrote:

Update:

I've found out now that the ENOBUFS is set by __ip_append_data,
because sk_wmem_alloc "overflows".

Martin


On 2020-01-20 07:09, Martin Schiller wrote:

Hi!

I have discovered the following problem:

If you have established a PPPoE session via VDSL / PTM connection 
incl.

VLAN tagging and send data with a relatively small send buffer
(SO_SNDBUF), then an ENOBUFS always comes back.

We first noticed this with stagnating data transfers over an OpenVPN
connection.

Also with iputils-ping, since by default the send buffer is 
relatively

small.

You can also force this with busybox ping by using

echo "5000"> / proc / sys / net / core / wmem_default

minimizes the system default value.

Then you send pings with a packet size of e.g. 4000 bytes and the
second package is already in the pants:


root @ OpenWrt: ~ # ping -s4000 10.200.1.142
PING 10.200.1.142 (10.200.1.142): 4000 data bytes
4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
ping: sendto: No buffer space available
root @ OpenWrt: ~ #


So it should be easily reproducible for everyone.

Traffic that is only routed through the router is not affected.

The manpage of sendto says:
---
ENOBUFS
The output queue for a network interface was full. This generally
indicates that the interface has stopped sending, but may be 
caused

by transient congestion. (Normally, this does not occur in Linux.
Packets are just silently dropped when a device queue overflows.)
---

But all former packets have already been transmitted.

This issue seems to be in there since lede-17.01.

I can't reproduce it with owrt-15.05.

Does anyone have any idea how to solve the problem?

Martin

___
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



___
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

[OpenWrt-Devel] [WIP] vrx518 support for AVM Fritzbox 7530

[Martin Schiller]

I've done some work to get the vrx518 running on the AVM Fritzbox 7530:
https://github.com/3headeddevs/openwrt/commits/vrx518_support

The current status is as follows:
- The VRX518 TC driver is running in software datapath mode, which 
required some codefixes for the driver to compile at all.

- The line is synchronized in both ATM and PTM mode
- Outgoing data packets via PTM go out (I can see them behind the 
DSLAM), but no packets are received.

- ATM is not really tested so far and maybe needs some further hacks.

Therefore, I took some driver/software from the Intel UGW-8.3.2.30 which 
partially were published on prpl gitlab.


Alternatively I extracted the binary firmwares (ACA, PPE, DSL) from the 
original AVM firmware images. But the result was the same. (except that 
it contains the ADSL ANNEX-B firmware which is currently not available 
on prpl gitlab)


So the implementation is not really functional yet, but I would like to 
share this progress here now, so that other interested people can help 
to get the whole thing running.


Regards,
Martin


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

[OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Hi!

I have discovered the following problem:

If you have established a PPPoE session via VDSL / PTM connection incl.
VLAN tagging and send data with a relatively small send buffer
(SO_SNDBUF), then an ENOBUFS always comes back.

We first noticed this with stagnating data transfers over an OpenVPN
connection.

Also with iputils-ping, since by default the send buffer is relatively
small.

You can also force this with busybox ping by using

echo "5000"> / proc / sys / net / core / wmem_default

minimizes the system default value.

Then you send pings with a packet size of e.g. 4000 bytes and the
second package is already in the pants:


root @ OpenWrt: ~ # ping -s4000 10.200.1.142
PING 10.200.1.142 (10.200.1.142): 4000 data bytes
4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
ping: sendto: No buffer space available
root @ OpenWrt: ~ #


So it should be easily reproducible for everyone.

Traffic that is only routed through the router is not affected.

The manpage of sendto says:
---
ENOBUFS
The output queue for a network interface was full. This generally
indicates that the interface has stopped sending, but may be caused
by transient congestion. (Normally, this does not occur in Linux.
Packets are just silently dropped when a device queue overflows.)
---

But all former packets have already been transmitted.

This issue seems to be in there since lede-17.01.

I can't reproduce it with owrt-15.05.

Does anyone have any idea how to solve the problem?

Martin

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

Re: [OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Update:

I've found out now that the ENOBUFS is set by __ip_append_data,
because sk_wmem_alloc "overflows".

Martin


On 2020-01-20 07:09, Martin Schiller wrote:

Hi!

I have discovered the following problem:

If you have established a PPPoE session via VDSL / PTM connection incl.
VLAN tagging and send data with a relatively small send buffer
(SO_SNDBUF), then an ENOBUFS always comes back.

We first noticed this with stagnating data transfers over an OpenVPN
connection.

Also with iputils-ping, since by default the send buffer is relatively
small.

You can also force this with busybox ping by using

echo "5000"> / proc / sys / net / core / wmem_default

minimizes the system default value.

Then you send pings with a packet size of e.g. 4000 bytes and the
second package is already in the pants:


root @ OpenWrt: ~ # ping -s4000 10.200.1.142
PING 10.200.1.142 (10.200.1.142): 4000 data bytes
4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
ping: sendto: No buffer space available
root @ OpenWrt: ~ #


So it should be easily reproducible for everyone.

Traffic that is only routed through the router is not affected.

The manpage of sendto says:
---
ENOBUFS
The output queue for a network interface was full. This generally
indicates that the interface has stopped sending, but may be caused
by transient congestion. (Normally, this does not occur in Linux.
Packets are just silently dropped when a device queue overflows.)
---

But all former packets have already been transmitted.

This issue seems to be in there since lede-17.01.

I can't reproduce it with owrt-15.05.

Does anyone have any idea how to solve the problem?

Martin

___
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

[OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

[Martin Schiller]

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit 
64bb88841fbc
("uqmi: inherit firewall zone membership to virtual sub interfaces") 
which was

introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to 
another
without a reconnect of that interface, because the related zone is 
stored during
interface setup and fw3 will use this value even if the parent interface 
is

already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface is 
decided
by an iface-hotplug script on an if-up event and i don't want / can't 
reconnect

the interface right after it's coming up.

Is there a possibility to get this working again?

Regards,
Martin

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

Re: [OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

[Martin Schiller]

On 2020-05-07 06:47, Martin Schiller wrote:

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit
64bb88841fbc ("uqmi: inherit firewall zone membership to virtual sub
interfaces") which was introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to
another without a reconnect of that interface, because the related
zone is stored during interface setup and fw3 will use this value
even if the parent interface is already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface
is decided by an iface-hotplug script on an if-up event and i don't
want / can't reconnect the interface right after it's coming up.

Is there a possibility to get this working again?


What about storing the information (name) of the parent interface
instead of the zone and let fw3 dynamically take the zone of the
parent interface?



Regards,
Martin



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

Re: [OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

[Martin Schiller]

On 2020-05-07 07:39, Martin Schiller wrote:

On 2020-05-07 06:47, Martin Schiller wrote:

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit
64bb88841fbc ("uqmi: inherit firewall zone membership to virtual sub
interfaces") which was introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to
another without a reconnect of that interface, because the related
zone is stored during interface setup and fw3 will use this value
even if the parent interface is already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface
is decided by an iface-hotplug script on an if-up event and i don't
want / can't reconnect the interface right after it's coming up.

Is there a possibility to get this working again?


What about storing the information (name) of the parent interface
instead of the zone and let fw3 dynamically take the zone of the
parent interface?



OK, so please have a look at the patch below. It works as expected
for me.

If there is a "parent" information (name of the parent interface)
in the data section of an interface, then let's check if this
parent interface is a member the current zone.

Of course, the proto handler(s) also need to be patched to save the
parent information instead of the zone.

---
 ubus.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ubus.c b/ubus.c
index cf5c8b1..d77807c 100644
--- a/ubus.c
+++ b/ubus.c
@@ -228,6 +228,7 @@ void
 fw3_ubus_zone_devices(struct fw3_zone *zone)
 {
struct blob_attr *c, *cur, *dcur;
+   struct fw3_device *net;
unsigned r, rem, drem;
const char *name;
bool matches;
@@ -239,10 +240,20 @@ fw3_ubus_zone_devices(struct fw3_zone *zone)
blobmsg_for_each_attr(cur, c, rem) {
if (!strcmp(blobmsg_name(cur), "interface"))
name = blobmsg_get_string(cur);
-   else if (!strcmp(blobmsg_name(cur), "data"))
-   blobmsg_for_each_attr(dcur, cur, drem)
+   else if (!strcmp(blobmsg_name(cur), "data")) {
+   blobmsg_for_each_attr(dcur, cur, drem) {
if (!strcmp(blobmsg_name(dcur), "zone"))
matches = 
!strcmp(blobmsg_get_string(dcur), zone->name);
+   /* check, if the parent interface is in 
this zone */
+   else if (!strcmp(blobmsg_name(dcur), 
"parent")) {
+   list_for_each_entry(net, 
>networks, list)
+   {
+   if 
(!strcmp(blobmsg_get_string(dcur), net->name))
+   matches = true;
+   }
+   }
+   }
+   }
}

if (name && matches)
--



Regards,
Martin



___
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: [OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

[Martin Schiller]

On 2020-05-07 07:39, Martin Schiller wrote:

On 2020-05-07 06:47, Martin Schiller wrote:

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit
64bb88841fbc ("uqmi: inherit firewall zone membership to virtual sub
interfaces") which was introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to
another without a reconnect of that interface, because the related
zone is stored during interface setup and fw3 will use this value
even if the parent interface is already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface
is decided by an iface-hotplug script on an if-up event and i don't
want / can't reconnect the interface right after it's coming up.

Is there a possibility to get this working again?


What about storing the information (name) of the parent interface
instead of the zone and let fw3 dynamically take the zone of the
parent interface?



OK, so please have a look at the patch below. It works as expected
for me.

If there is a "parent" information (name of the parent interface)
in the data section of an interface, then let's check if this
parent interface is a member the current zone.

Of course, the proto handler(s) also need to be patched to save the
parent information instead of the zone.

---
 ubus.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ubus.c b/ubus.c
index cf5c8b1..d77807c 100644
--- a/ubus.c
+++ b/ubus.c
@@ -228,6 +228,7 @@ void
 fw3_ubus_zone_devices(struct fw3_zone *zone)
 {
struct blob_attr *c, *cur, *dcur;
+   struct fw3_device *net;
unsigned r, rem, drem;
const char *name;
bool matches;
@@ -239,10 +240,20 @@ fw3_ubus_zone_devices(struct fw3_zone *zone)
blobmsg_for_each_attr(cur, c, rem) {
if (!strcmp(blobmsg_name(cur), "interface"))
name = blobmsg_get_string(cur);
-   else if (!strcmp(blobmsg_name(cur), "data"))
-   blobmsg_for_each_attr(dcur, cur, drem)
+   else if (!strcmp(blobmsg_name(cur), "data")) {
+   blobmsg_for_each_attr(dcur, cur, drem) {
if (!strcmp(blobmsg_name(dcur), "zone"))
matches = 
!strcmp(blobmsg_get_string(dcur), zone->name);
+   /* check, if the parent interface is in 
this zone */
+   else if (!strcmp(blobmsg_name(dcur), 
"parent")) {
+   list_for_each_entry(net, 
>networks, list)
+   {
+   if 
(!strcmp(blobmsg_get_string(dcur), net->name))
+   matches = true;
+   }
+   }
+   }
+   }
}

if (name && matches)
--


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

Re: [OpenWrt-Devel] [PATCH] lantiq: add dsl line_state mapping

[Martin Schiller]

On 2020-06-17 12:21, Florian Eckert wrote:

Hi Adrian,


The line_state of the DSL connection is described in the system via a
hexadecimal variable. With this change the hexadecimal is mapped to a
decimal value. With this change it is now possible to store this 
value in a

database, so that it can be easily evaluated.


Interesting file this lantiq_dsl.sh ...



That´s probably right!


I'm wondering whether all of this really need to be in this file, or
whether stuff can be moved to the package actually dealing with it?
This might also make it easier to change it when necessary.



This file is sourced twice:
- dsl_control of package ltq-adsl-app [1]
- dsl_control of package ltq-vdsl-app [2]

If we take this from the target folder then we have to make our own
packet ltq-dsl-common for example.
And the packages ltq-adsl-app and ltq-vdsl-app could depend on this.

When we create a new package, we may also want to move other files
from the target directory to the new package?

- lantiq.sh [3] This is sourced in 02_network files on the lantiq 
targets.

- led_dsl.sh [4]
- pppoa.sh [5]
- uci-defaults [6]
- dsl_notify.sh [7]

These are candidates that could also moved to the new package


That's what I've already done in my working tree for VRX518 support on
FB7530, to get this scripts also available on other targets than lantiq:

https://github.com/3headeddevs/openwrt/commit/9f45c750f91eea230dc638c0936fb6e761214abb



Best regards

Florian

[1]
https://github.com/openwrt/openwrt/blob/master/package/network/config/ltq-adsl-app/files/dsl_control#L11
[2]
https://github.com/openwrt/openwrt/blob/master/package/network/config/ltq-vdsl-app/files/dsl_control#L11
[3]
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/base-files/lib/functions/lantiq.sh
[4]
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/base-files/etc/hotplug.d/dsl/led_dsl.sh
[5]
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/base-files/etc/hotplug.d/dsl/pppoa.sh
[6]
https://github.com/openwrt/openwrt/tree/master/target/linux/lantiq/base-files/etc/uci-defaults
[7]
https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/base-files/sbin/dsl_notify.sh

___
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: [PATCH] base-files: sysupgrade: store status of system-services

[Martin Schiller]

On 2021-01-11 14:38, Stijn Segers wrote:

Hi Alberto,

Alberto Bursi  schreef op 11 januari 2021
03:56:23 CET:



On 10/01/21 22:50, Stijn Segers wrote:

Hi Sven,

Op zondag 10 januari 2021 om 22u28 schreef Sven Roederer
:

Am Samstag, 9. Januar 2021, 12:28:31 CET schrieb Stijn Segers:

 > @@ -228,6 +229,7 @@ do_save_conffiles() {
 >
 > if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
 > echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
 > +   echo "${SERVICE_STATUS}" >> "$CONFFILES"
 > mkdir -p "$ETCBACKUP_DIR"

 Am I reading this correctly and is this only keeping track of 
service
 status if you tell sysupgrade to save packages? What's the 
rationale

 behind that?

 I have a personal build with all packages preinstalled, so I don't 
need
 that. Would like to keep track of service status though. Can those 
two

 things be entangled?



Stijn,

my intention was to not change the current behavior by default, so 
an

extra
switch or extending an existing switch looked like the way. I've
choosen the
lazy one, based on "when the user is storing the packages-list, he 
is

for sure
interested in the services".
But I'm happy to add a separate switch to sysupgrade. Any preference
of the
letter? What about using "-s"?

Sven


Yes, that's still free and the most intuitive I think.

Thanks!

Stijn



Since we (me, Andre Heider and Paul Spooren) are discussing/asking 
about

enabling this by default, do you have any opinion on that?

-Alberto


That would be great, as Adrian pointed out it's something you'd expect
would be saved when you tell sysupgrade to keep settings.

So +1 from me on making it default. All my AP/testing devices now have
scripting to disable e.g. DHCP and DNS again after an upgrade.

Stijn


I am also in favor of saving the service status by default.
This is the expected behavior as long as you don't use the '-n' switch.

Currently we use our own patchset for this, but I would prefer to get
an upstream solution.

Martin

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

Re: [PATCH v2] base-files: restore status of system-services after sysupgrade

[Martin Schiller]

On 2021-01-11 23:07, Sven Roederer wrote:

Restore the status of the system-services after sysupgrade.
Create a file with the status of all known services and keep it during
upgrade. After upgrade run a uci-default script to restore every
single service.


Doing the restore in an uci-default script is to late, because then you
are already in the procd rcS helper "loop" and new added init links
won't get called.

Also, have you thought about a backup/restore of the configuration?
The whole thing should/must work there as well.

I would do the restore at the end of the pre-init stage.

Martin

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

netifd: segfault on teardown when using proto static on dynamically added interface

[Martin Schiller]

Hi!

In my work on https://github.com/openwrt/openwrt/pull/2759 (umbim /
wwan: bugfixes + support for non-dhcp devices), I ran into a problem
ith netifd.

If you use the "static" protocol for a dynamically created interface,
the netifd throws a segfault on "ifdown" of the parent interface.

This is how I create the dynamic interface:

https://github.com/openwrt/openwrt/pull/2759/files#diff-3721d970f207cbcaaa5251bf32caa91ab96818fae68cf0e9f15ea572a0d2dc22R161

It seems to be related to the flag "PROTO_FLAG_IMMEDIATE" of proto
static, whereby in __interface_set_down() the iface gets already freed
before the last interface_flush_state(iface) call.

Regards,
Martin

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

Re: [PATCH v2 0/12] add ubus support to ltq-[v|a]dsl-app

[Martin Schiller]

On 2021-01-14 12:55, Mathias Kresin wrote:

1/13/21 3:00 PM, Martin Schiller:

On 2021-01-09 09:40, Andre Heider wrote:

Hi,

(cc'ed some recent commiters for lantiq)

On 15/12/2020 10:35, Andre Heider wrote:

v2:
- drop 0002-ltq-vdsl-app-fix-Wundef-warnings.patch
- use "/dev/dsl_cpe_api" without the "0" suffix for the adsl daemon:
   package/kernel/lantiq/ltq-adsl/patches/100-dsl_compat.patch:+ 
device_create(dsl_class, NULL, MKDEV(DRV_DSL_CPE_API_DEV_MAJOR, 0), 
NULL, "dsl_cpe_api");
   package/kernel/lantiq/ltq-vdsl/patches/100-compat.patch:+ 
device_create(dsl_class, NULL, dsl_devt, NULL, "dsl_cpe_api0");

- use callDSLMetrics() for luci, per jo
- add Tested-by tags

This is to significantly speed up the generation of the metrics.

The motivation comes from the fact that ~2.6s is just way too
ineffcient for interval based metric collectors like prometheus or
collectd.

The luci status page also loads/refreshes alot faster.

$ time /etc/init.d/dsl_control dslstat
real    0m 2.66s
user    0m 0.90s
sys    0m 1.76s

$ time ubus call dsl metrics
real    0m 0.02s
user    0m 0.00s
sys    0m 0.01s

The ltq-adsl-app changes are only compile time tested.


who do I need to convince to review this? ;)


I would also like this great work to be merged.

Martin


Sending a reviewed-by and/or tested-by (with devices it was tested on)
might help to push this forward.


OK.

I've successfully tested the following parts of this patchset (v2) on
our (TDT) xrx200 based systems:

[01/13] ltq-vdsl-app: shutdown upon sigterm
[02/12] ltq-vdsl-app: add ubus support to get metrics
[04/12] luci-mod-status: use the new ubus dsl metrics
[05/12] rpcd-mod-luci: get rid of now unused getDSLStatus ubus rpc
[07/12] ltq-vdsl-app: use ubus to provide metrics
[09/12] ltq-dsl-base: remove usused lantiq_dsl.sh
[10/12] ltq-dsl-base: bump PKG_RELEASE
[11/12] ltq-vdsl-app: bump PKG_RELEASE

I am not able to test the ltq-adsl (Danube etc.) stuff.

Tested-by: Martin Schiller 

It is also important to note that the output of dslstat has changed
completely and lucistat no longer exists. If someone has processed the
output directly, it must be reworked.

Regards,
Martin

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

Re: [PATCH v2] base-files: restore status of system-services after sysupgrade

[Martin Schiller]

On 2021-01-12 23:03, Sven Roederer wrote:

Am Dienstag, 12. Januar 2021, 19:56:54 CET schrieb Hannu Nyman:

Martin Schiller kirjoitti 12.1.2021 klo 9.25:
> On 2021-01-11 23:07, Sven Roederer wrote:
>> Restore the status of the system-services after sysupgrade.
>> Create a file with the status of all known services and keep it during
>> upgrade. After upgrade run a uci-default script to restore every
>> single service.
>
> Doing the restore in an uci-default script is to late, because then you
> are already in the procd rcS helper "loop" and new added init links
> won't get called.
>
> Also, have you thought about a backup/restore of the configuration?
> The whole thing should/must work there as well.
>
> I would do the restore at the end of the pre-init stage.
>
> Martin

My two cents to the discussion:

* I assume that a small minority of users actually disable services, 
or at
least disable several services, so defaulting to "lets by default 
always

store status of all services" sounds like overkill.

* Backuping always info that the dozens of standard services are 
enabled
sounds unncessary. As services are installed by default as "enabled" 
to the
image, it might make sense to store only info about "disabled" 
services and
disable those when restoring the backup in sysupgrade.  (Re-enabling 
the
already enabled services is unnecessary.)  That would also help to 
keep the

amount of new backup info small.

* make clear in sysupgrade script help texts and documentation that
saving/restoring service status depends on "keep settings". If 
settings are
not kept, the service status can not be copied in sysupugrade as there 
is no
sysupgrade.tar.gz to be passed. (And naturally it would not even make 
sense

to e.g. revert network settings to defaults but keep selected network
services disabled. Easy to cause soft-bricks that way.)



Hannu,

as long as no service was disabled with the "DISABLED_SERVICES" option 
of the

imagebuilder the explicit "enable" is not required.
Indeed enabling a service that have been disabled during image creation 
is a
bit edge-case, but I prefer here the "full featured" way. Not enabling 
such a

service also breaks the user experience like the disable case.


I totally agree. If you do this, you should cover all cases.


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

Re: [PATCH v2 0/12] add ubus support to ltq-[v|a]dsl-app

[Martin Schiller]

On 2021-01-09 09:40, Andre Heider wrote:

Hi,

(cc'ed some recent commiters for lantiq)

On 15/12/2020 10:35, Andre Heider wrote:

v2:
- drop 0002-ltq-vdsl-app-fix-Wundef-warnings.patch
- use "/dev/dsl_cpe_api" without the "0" suffix for the adsl daemon:
   package/kernel/lantiq/ltq-adsl/patches/100-dsl_compat.patch:+   
device_create(dsl_class, NULL, MKDEV(DRV_DSL_CPE_API_DEV_MAJOR, 0), 
NULL, "dsl_cpe_api");
   package/kernel/lantiq/ltq-vdsl/patches/100-compat.patch:+   
device_create(dsl_class, NULL, dsl_devt, NULL, "dsl_cpe_api0");

- use callDSLMetrics() for luci, per jo
- add Tested-by tags

This is to significantly speed up the generation of the metrics.

The motivation comes from the fact that ~2.6s is just way too
ineffcient for interval based metric collectors like prometheus or
collectd.

The luci status page also loads/refreshes alot faster.

$ time /etc/init.d/dsl_control dslstat
real0m 2.66s
user0m 0.90s
sys 0m 1.76s

$ time ubus call dsl metrics
real0m 0.02s
user0m 0.00s
sys 0m 0.01s

The ltq-adsl-app changes are only compile time tested.


who do I need to convince to review this? ;)


I would also like this great work to be merged.

Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-04-28 14:39, Martin Schiller wrote:

On 2021-03-26 10:30, Martin Schiller wrote:

On 2021-03-26 09:55, Martin Schiller wrote:

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this 
approach

generally
makes sense.

However for the vlan I wonder if we should simply use "option vid 
10"

since
setting anything besides an egress untagged pvid does not make 
sense

for wifi.
I think more complex VLAN settings make sense for WDS if you want 
to

carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we 
are

always
going to default to 1?
It would inherit 456 to keep it in sync with the VLAN based 
network.




Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline 
driver and
a wifi interface and have the problem that the wlan0 interface is 
added
to the bridge switch0 but the bridge vlan configuration for the 
wlan0

interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) 
and
use 'option network lan' in the wifi-iface. It will detect that the 
lan
ifname is a vlan on top of a vlan-filtering bridge and will add 
wlan0 to

switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?



`ubus call network.device status` shows:


...
"switch0": {
"external": false,
"present": true,
"type": "bridge",
"up": true,
"carrier": true,
"bridge-members": [
"lan1",
"lan2",
"lan3",
"lan4",
"wlan0"
],
"bridge-vlans": [
{
"id": 1,
"local": true,
"ports": [
"lan1",
"lan2",
"lan3",
"lan4"
]
}
],
...



As you can see here, "wlan0" is added to the "bridge-members", but not
to the "ports" of the "bridge-vlans"/"id":1. Maybe this is the problem?



With netifd commit 61a71e5e49c3 ("bridge: dynamically create vlans for
hotplug members) the behavior has changed in that now the wlan0
interface is added to the "ports" of the "bridge-vlans"

layerscape: problems with image builder

[Martin Schiller]

When trying to build an image for the Layerscape "NXP LS1046A-RDB SD
Card Boot" target using Image Builder, you get the following error
messages:


...
Package list missing or not up-to-date, generating it.

Building package index...
Downloading file:packages/Packages
Updated list of available packages in 
Downloading file:packages/Packages.sig
Signature check passed.
Collected errors:
 * opkg_install_cmd: Cannot install package fmc.
 * opkg_install_cmd: Cannot install package fmc-eth-config.
 * opkg_install_cmd: Cannot install package layerscape-fman.
 * opkg_install_cmd: Cannot install package tfa-ls1046a-rdb-sdboot.
make[3]: *** [Makefile:167: package_install] Error 255
make[2]: *** [Makefile:132: _call_manifest] Error 2
make[1]: *** [Makefile:251: manifest] Error 2
...


The following is noticeable:
1. All these packages are listed in the "DEVICES_PACKAGES" of this
   target.
2. the packages "fmc" and "fmc-eth-config" do not exist at all.
3. the packages "layerscape-fman" and "tfa-ls1046a-rdb-sdboot" do not
   have a "package/install" routine and therefore do not create an ipk
   file. Only binary blobs are installed via "Build/InstallDev", which
   are then used during image assembly.

Since "fmc" and "fmc-eth-config" do not exist, we should remove these
entries from the "DEVICE_PACKAGES".

For the other two it is a bit more difficult. For this, a mechanism
similar to PKG_BUILD_DEPENDS on image level would be useful or
necessary.

Any suggestions?

- Martin

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

OpenWrt 21.02: backport lantiq xrx200 DSA switch

[Martin Schiller]

Hello all!

Now that the Lantiq xrx200 DSA switch has finally made it into the
master, I would like to ask whether we also want to pack this switch
into the 21.02 release.

The topic "DSA Support" is one of the key points of the 21.02 release
and therefore this would fit very well.

Any opinions?

Thanks, Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 10:49, Martin Schiller wrote:

On 2021-03-26 10:44, Felix Fietkau wrote:

On 2021-03-26 09:55, Martin Schiller wrote:

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this 
approach

generally
makes sense.

However for the vlan I wonder if we should simply use "option vid
10"
since
setting anything besides an egress untagged pvid does not make 
sense

for wifi.
I think more complex VLAN settings make sense for WDS if you want 
to

carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we 
are

always
going to default to 1?
It would inherit 456 to keep it in sync with the VLAN based 
network.




Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline 
driver

and
a wifi interface and have the problem that the wlan0 interface is
added
to the bridge switch0 but the bridge vlan configuration for the 
wlan0

interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) 
and
use 'option network lan' in the wifi-iface. It will detect that the 
lan
ifname is a vlan on top of a vlan-filtering bridge and will add 
wlan0

to
switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?

Looks right to me. I'll see if I can find the time to reproduce this.
You're using a recent version of OpenWrt, right?


Yes, I'm using
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=07c49462ad2ac3f6386bb4463546509f3bf35e39



Hello Felix! Have you already found time to look at this problem? I
think this affects quite a few users when DSA is used "productively".

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 10:30, Martin Schiller wrote:

On 2021-03-26 09:55, Martin Schiller wrote:

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this approach
generally
makes sense.

However for the vlan I wonder if we should simply use "option vid 
10"

since
setting anything besides an egress untagged pvid does not make 
sense

for wifi.
I think more complex VLAN settings make sense for WDS if you want 
to

carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we are
always
going to default to 1?
It would inherit 456 to keep it in sync with the VLAN based 
network.




Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline driver 
and
a wifi interface and have the problem that the wlan0 interface is 
added
to the bridge switch0 but the bridge vlan configuration for the 
wlan0

interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) 
and
use 'option network lan' in the wifi-iface. It will detect that the 
lan
ifname is a vlan on top of a vlan-filtering bridge and will add wlan0 
to

switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?



`ubus call network.device status` shows:


...
"switch0": {
"external": false,
"present": true,
"type": "bridge",
"up": true,
"carrier": true,
"bridge-members": [
"lan1",
"lan2",
"lan3",
"lan4",
"wlan0"
],
"bridge-vlans": [
{
"id": 1,
"local": true,
"ports": [
"lan1",
"lan2",
"lan3",
"lan4"
]
}
],
...



As you can see here, "wlan0" is added to the "bridge-members", but not
to the "ports" of the "bridge-vlans"/"id":1. Maybe this is the problem?

- Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 10:44, Felix Fietkau wrote:

On 2021-03-26 09:55, Martin Schiller wrote:

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this approach
generally
makes sense.

However for the vlan I wonder if we should simply use "option vid
10"
since
setting anything besides an egress untagged pvid does not make 
sense

for wifi.
I think more complex VLAN settings make sense for WDS if you want 
to

carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we are
always
going to default to 1?
It would inherit 456 to keep it in sync with the VLAN based 
network.




Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline driver
and
a wifi interface and have the problem that the wlan0 interface is
added
to the bridge switch0 but the bridge vlan configuration for the 
wlan0

interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) 
and
use 'option network lan' in the wifi-iface. It will detect that the 
lan

ifname is a vlan on top of a vlan-filtering bridge and will add wlan0
to
switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?

Looks right to me. I'll see if I can find the time to reproduce this.
You're using a recent version of OpenWrt, right?


Yes, I'm using 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=07c49462ad2ac3f6386bb4463546509f3bf35e39


- Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1 
untagged

by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI 
implementation and
the special role of wifi and I am convinced now that this approach 
generally

makes sense.

However for the vlan I wonder if we should simply use "option vid 10" 
since
setting anything besides an egress untagged pvid does not make sense 
for wifi.

I think more complex VLAN settings make sense for WDS if you want to
carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we are 
always

going to default to 1?

It would inherit 456 to keep it in sync with the VLAN based network.



Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline driver and
a wifi interface and have the problem that the wlan0 interface is added
to the bridge switch0 but the bridge vlan configuration for the wlan0
interface is not set.

- Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this approach
generally
makes sense.

However for the vlan I wonder if we should simply use "option vid 
10"

since
setting anything besides an egress untagged pvid does not make sense
for wifi.

I think more complex VLAN settings make sense for WDS if you want to
carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we are
always
going to default to 1?

It would inherit 456 to keep it in sync with the VLAN based network.



Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline driver 
and
a wifi interface and have the problem that the wlan0 interface is 
added

to the bridge switch0 but the bridge vlan configuration for the wlan0
interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) and
use 'option network lan' in the wifi-iface. It will detect that the lan
ifname is a vlan on top of a vlan-filtering bridge and will add wlan0 
to

switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?

- Martin

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Martin Schiller]

On 2021-03-26 09:55, Martin Schiller wrote:

On 2021-03-26 09:42, Felix Fietkau wrote:

On 2021-03-26 09:34, Martin Schiller wrote:

On 2020-07-24 19:13, Felix Fietkau wrote:

On 2020-07-24 18:44, Jo-Philipp Wich wrote:

Hi Felix,


[...]

For a simple default config, you could have this:

# network
config device

option type bridge  # I assume this is needed as well

option name switch0

Correct.


config bridge-vlan
option vlan 1
option ports "lan1 lan2 lan3 lan4"

config interface lan
option ifname switch0.1


# wireless

config wifi-iface
option network lan


In this case, wlan0 would be added to switch0 and set to VLAN 1
untagged
by default.

If you want it on VLAN 10 tagged/PVID instead, you could do:
option network-vlan "10:t*"


What do you think?


I did think about it some more, also in context of a LuCI
implementation and
the special role of wifi and I am convinced now that this approach
generally
makes sense.

However for the vlan I wonder if we should simply use "option vid 
10"

since
setting anything besides an egress untagged pvid does not make 
sense

for wifi.

I think more complex VLAN settings make sense for WDS if you want to
carry multiple networks over the link.


So your second example above would become:

  config wifi-iface
option network lan
option vid 10  # instead of inheriting vid 1, use 10 as pvid


Also, just to clarify... assuming a:

  config interface foo
option ifname somevlanbridge0.456

and an wifi iface without an explicit vid override:

  config wifi-iface
option network foo

... we would inherit vid 456 and set as pvid, right? Or are we are
always
going to default to 1?

It would inherit 456 to keep it in sync with the VLAN based network.



Is this functionality already integrated?
I am testing with a xrx200 based system with the DSA mainline driver 
and
a wifi interface and have the problem that the wlan0 interface is 
added

to the bridge switch0 but the bridge vlan configuration for the wlan0
interface is not set.

It's handled differently now.

You can set lan's ifname to switch0.1 (without option type bridge) and
use 'option network lan' in the wifi-iface. It will detect that the 
lan
ifname is a vlan on top of a vlan-filtering bridge and will add wlan0 
to

switch0 and make it a member of lan's vlan.



Hmmm... I think that's what I've alread done. Here is my config:

network:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.X.Y'
option netmask '255.255.255.0'
option ifname 'switch0.1'

config device
option type 'bridge'
option name 'switch0'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'

config bridge-vlan
option device 'switch0'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'

wireless:
--
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option ssid 'TETS-AP'
option network 'lan'
option key 'xxx'
option wpa_disable_eapol_key_retries '1'


Did I forget anything?



`ubus call network.device status` shows:


...
"switch0": {
"external": false,
"present": true,
"type": "bridge",
"up": true,
"carrier": true,
"bridge-members": [
"lan1",
"lan2",
"lan3",
"lan4",
"wlan0"
],
"bridge-vlans": [
{
"id": 1,
"local": true,
"ports": [
"lan1",
"lan2",
"lan3",
"lan4"
]
}
],
...

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

Re: lantiq: upstream Linux efforts

[Martin Schiller]

On 2021-04-12 00:24, Hauke Mehrtens wrote:

Hi,

On 4/11/21 7:51 PM, Martin Blumenstingl wrote:

Hello everyone,

you are included in this email because you have previously worked on
patches for the Lantiq SoCs upstream.

In the past updating the kernel version for the lantiq target in
OpenWrt was an unpleasant task.
There are many out-of-tree patches and some of them are breaking with
newer kernel versions.

To improve the situation I suggest using Rafał Miłecki's approach also
for the lantiq target:
He is submitting patches upstream, then backporting them to OpenWrt.
That way backports to the -stable tree are for free.
Other patches can simply be dropped during the next major kernel
version update (instead of having to rework them every time...).


I like this approach.


I also like this approach.

This approach however only works when there are active contributors 
upstream.

It brings the benefit of upstream code-reviews though - which in my
experience improves the quality of the resulting code.


I think there's quite a bit of work involved.

If you take for example the patch with the configurability of the LEDs
on the phys:
Hauke had already started one or more attempts to bring this upstream
[1], but this was "rejected" with the reason that this belongs in the
LED subsystem.

Now I found an interesting solution on the mailing list, which
implements this function as hw offloading of the netdev trigger. [2]

@Hauke: what do you think about this?

Furthermore there are some patches for the target lantiq, which
unfortunately don't contain any description and so we have to work out
the deeper sense or necessity of this patch again.

[1] https://www.spinics.net/lists/netdev/msg380196.html
[2] https://www.spinics.net/lists/linux-leds/msg17241.html


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

Re: OpenWrt 21.02-rc1

[Martin Schiller]

On 2021-04-07 12:01, Hannu Nyman wrote:

Hauke Mehrtens kirjoitti 7.4.2021 klo 1.29:

Hi,

How do we want to go forward with OpenWrt 21.02-rc1?

* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged 
into master some time ago as far as I understood.


...

In would like to get 21.02-rc1 soon, so more users start testing it 
and we get more bug reports.


How should we continue?
1. Tag 21.02-rc1 and do the release in the next days with the current
  state.

2. Merge the LuCI DSA changes from master to 21.02 branch now and do
  21.02-rc1 ~3 days to see if some big problems come up.



Option 2 of merging the LuCI DSA changes and then making the first
21.02-rc sounds good to me.



I would also prefer option 2, as I would like to switch to DSA with 
21.02.




Also the option 1 of doing the rc now would likely be ok, as the only
a few targets actually use DSA, so the absence of LuCI support for DSA
does not concern that many users.


I would prefer if we merge the LuCI DSA changes from master to 21.02 
branch now and do 21.02-rc1 soon. We should list the problems as known 
problems.


It would be nice if someone else could also look into these problems 
and propose fixes.



Like with previous releases, the developers interest mainly stays on
the master, and not much happens in the new release branch...

It is now 50 days since the 21.02 was branched in February, so a high
time to get the rc out.




___
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: Release goals for 22.XX

[Martin Schiller]

On 2021-10-20 04:47, Paul Spooren wrote:

For now layerscape is still on 5.4 without Kernel 5.10 support. Is
anyone planing to add support? Please reach out.


As I had already written on 08 October, I am already working on it.
Thereby I try to bring all relevant components to the state of
LSDK-21.08.

Currently I'm a bit stuck with the kernel. It is a mammoth task to
extract all the patches from the patched kernel [1], filter out the
relevant ones and port them to the already patched openwrt v5.10.72.

My first tests with it are unfortunately still without success:
When booting, the system hangs after the last uboot message "Starting
kernel ...".

I am currently trying to find out what this could be.

At [2] you can find a state with the updated packages like bootloader
and firmwares.

There is also a small inconsistency here. I have 2 boards for runtime
tests. At the ls1046ardb the pcie bus is not enumerated by the uboot
anymore, so the pcie bus is also not recognized in the Linux system.
With ls1046afrwy, however, everything works as before.

[1] 
https://source.codeaurora.org/external/qoriq/qoriq-components/linux/log/?h=LSDK-21.08
[2] 
https://github.com/TDT-AG/openwrt/commits/pr/20211011-layerscape-LSDK-21.08



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

Re: Release goals for 22.XX

[Martin Schiller]

On 2021-10-08 11:13, Paul Spooren wrote:

Hi,

--- %< ---


based on my overview[1] things are moving forward and being 
tested,

great! What about the targets that did not see any 5.10 ambitions
yet?
Specifically:

- arc770
- archs38


I just got an email from synopsys and they'll contribute Kernel 5.10
patches for both targets.


- ath25


Could this be dropped?


- bcm47xx
- bcm4908


Will these two targets be replaced by bmips?


- layerscape
- pistachio
- uml


Might be dropped if nobody takes care?



Is anyone aware of people working on those targets? Please let me
know.


I'm working on a Layerscape target since a couple of weeks and have
started updating the components to NXP LSDK-21.08. [1]

This uses an external kernel based on v5.10.35, with countless patches
incorporated. I'm trying to break it down a bit right now. [2]

Martin

[1] https://source.codeaurora.org/external/qoriq/qoriq-components

[2] 
https://source.codeaurora.org/external/qoriq/qoriq-components/linux/log/?h=LSDK-21.08


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

RFC: layerscape: update to kernel 5.10

[Martin Schiller]

I have now found the cause of my boot problems with linux 5.10.
(see [1] for reference)

By changing the TEXT_OFFSET to 0x0 (instead of 0x8 before) in the 
upstream
commit [2] and deactivated kernel option CONFIG_RELOCATABLE the system 
could not

boot.

Thus, we now need to set the KERNEL_LOADADDR to 0x8000 in the 
layerscape
target for kernel >= 5.8. (ATTENTION: but then kernel 5.4 can no longer 
boot).


In addition, we should think about enabling CONFIG_RELOCATABLE in 
general to
avoid being completely in the dark in case of similar problems in the 
future.


Also, I am currently very unhappy with how the kernel patches are 
handled in the
layerscape target. So far they seem to be taken "1 to 1" from the NXP 
LSDK. This
pile of patches is totally unmanageable and it is impossible to 
understand what

is really needed and what is not.
There was already a small discussion about this [3].

I would like to make a clear CUT here and work as far as possible with 
the linux

upstream state.

What is your opinion about this?
(maybe any performance drawbacks, missing features etc.)

[1] 
http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036785.html

[2] https://www.spinics.net/lists/arm-kernel/msg798878.html
[3] 
http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033732.html


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

[PATCH ustream-ssl v2] ustream-openssl: Disable renegotiation in TLSv1.2 and earlier

[Martin Schiller]

This fixes CVE-2011-1473 and CVE-2011-5094 by disabling renegotiation in
TLSv1.2 and earlier for server context.

Signed-off-by: Martin Schiller 
---
v2:
 - also handle wolfssl implementation.

---
 ustream-openssl.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ustream-openssl.c b/ustream-openssl.c
index 6dae4ae..7a991e9 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -157,6 +157,12 @@ __ustream_ssl_context_new(bool server)
SSL_CTX_set_options(c, SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 |
   SSL_OP_NO_TLSv1_1);
 #endif
+#if defined(HAVE_WOLFSSL)
+   SSL_CTX_set_options(c, SSL_AD_NO_RENEGOTIATION);
+#else
+   SSL_CTX_set_options(c, SSL_OP_NO_RENEGOTIATION);
+#endif
+
SSL_CTX_set_cipher_list(c, server_cipher_list);
} else {
SSL_CTX_set_cipher_list(c, client_cipher_list);
-- 
2.20.1


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

[PATCH ustream-ssl] ustream-openssl: Disable renegotiation in TLSv1.2 and earlier

[Martin Schiller]

This fixes CVE-2011-1473 and CVE-2011-5094 by disabling renegotiation in
TLSv1.2 and earlier for server context.

Signed-off-by: Martin Schiller 
---
 ustream-openssl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ustream-openssl.c b/ustream-openssl.c
index 6dae4ae..9d8d1bc 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -157,6 +157,8 @@ __ustream_ssl_context_new(bool server)
SSL_CTX_set_options(c, SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 |
   SSL_OP_NO_TLSv1_1);
 #endif
+   SSL_CTX_set_options(c, SSL_OP_NO_RENEGOTIATION);
+
SSL_CTX_set_cipher_list(c, server_cipher_list);
} else {
SSL_CTX_set_cipher_list(c, client_cipher_list);
-- 
2.20.1


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

kernel-headers: platform/target patches are not applied

[Martin Schiller]

When preparing the kernel sources to build the kernel headers, currently 
only the patches from the generic folder are applied, but not from the 
actual selected target.


This is basically understandable if one assumes that one wants to use a 
toolchain for different targets with the same architecture.


But if a target has a kernel patch which also changes the uapi, then 
this is not considered in the toolchain/kernel-headers and thus when 
compiling Userspace applications at the moment.


This is currently already the case for the following targets:
* ath79
* bcm27xx
* bcm63xx
* ipq40xx
* lantiq
* realtek

I am currently working on a new target, have now stumbled across this 
problem and would now like to start a discussion here on how best to 
solve this now.


I am looking forward to your ideas.


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

Re: kernel-headers: platform/target patches are not applied

[Martin Schiller]

Hi Felix,

On 2023-07-27 22:26, Felix Fietkau wrote:

Hi Martin,

On 27.07.23 13:23, Martin Schiller wrote:
When preparing the kernel sources to build the kernel headers, 
currently

only the patches from the generic folder are applied, but not from the
actual selected target.

This is basically understandable if one assumes that one wants to use 
a

toolchain for different targets with the same architecture.

But if a target has a kernel patch which also changes the uapi, then
this is not considered in the toolchain/kernel-headers and thus when
compiling Userspace applications at the moment.

This is currently already the case for the following targets:
* ath79
* bcm27xx
* bcm63xx
* ipq40xx
* lantiq
* realtek

I am currently working on a new target, have now stumbled across this
problem and would now like to start a discussion here on how best to
solve this now.

I am looking forward to your ideas.


Packages that depend on target specific UAPI changes can always
include kernel.mk in the package Makefile, make themselves non-shared
and pull include files from $(LINUX_DIR)/user_headers

The default for all other packages should be to not rely on target
specific UAPI changes.

- Felix


Yes, that is a viable way.

Thanks Felix for the quick answer!

- Martin

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

Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"

[Martin Schiller]

On 2023-12-13 02:45, Elliott Mitchell wrote:

On Tue, Dec 12, 2023 at 04:54:05PM +0100, Jonas Gorski wrote:


On Sun, 10 Dec 2023 at 18:51, Elliott Mitchell  
wrote:

>
> Date: Fri, 3 Nov 2023 22:57:43 -0700
>
> Enabling an Intel chipset feature on a platform originally made by
> National Semiconductor and later bought by AMD.  Could we cut the Intel
> enthusiasm?
>
> This reverts commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f.

commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f says "This makes it
possible to use the MCP23S08 i/o expander on geode platforms with
linux 4.14."


Problem is this is nonsensical.  A Geode processor CANNOT be paired 
with

an Intel chipset (the original Geode GX1 came out of National
Semiconductor/Cyrix and was later bought by AMD).

So we don't need to enable PINCTRL (via other symbols) anymore for 
this?


No idea, I wasn't able to find very much information when I looked at
this.

I did find:
https://lists.openwrt.org/pipermail/openwrt-devel/2018-August/019479.html

This doesn't tell me what platform Martin Schiller was trying for.
17f30bfcf7 makes me suspect Martin Schiller was simply trying to do 
this

to all x86 platforms and didn't realize geode was a specialized target.

Alternatively Martin Schiller may have been trying to use a MCP23S08 on 
a
Geode processor.  Unfortunately using CONFIG_X86_INTEL_LPSS is a 
bizzare

choice since CONFIG_X86_AMD_PLATFORM_DEVICE has fewer side-effects and
then current Geodes were AMD processors.

With sparse information the former is my present belief.  Is anyone
reading this list using a Geode processor with a MCP23S08?  Otherwise 
my
present belief is only people with Intel x86 processors are interested 
in

the MCP23S08.


Hi.

The problem was and is that the PINCTRL subsystem can only be used on 
x86
platforms if either X86_INTEL_LPSS or X86_AMD_PLATFORM_DEVICE is 
activated.

I no longer know why I chose the former at the time.

X86_AMD_PLATFORM_DEVICE is now activated for x86/generic and x86/64.

From my point of view, we can deactivate X86_INTEL_LPSS if no one else
need it.

Regards,
Martin

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