Re: [OpenWrt-Devel] Response to LEDE proposal/queries/mail?

2016-06-27 Thread Val Kulkov 
OpenWRT and LEDE/[OpenWRT] folks: I do not have any interest of my own in
seeing particular individuals take upon certain roles or getting
privileges. I am not friends with anyone here. In fact, this is my first
submission to this forum. With respect to individuals and their roles, I am
a disinterested person. However, I am very interested in seeing this
project succeed.

OpenWRT folks: whatever your response is, please do explain your reasons
when you respond. Silence is not your friend. When my kid avoids talking
about something or explaining something, I know that something is wrong. It
is in the human nature to look for bad things in silence or evasive
answers. Your honest, sincere and complete answers to the points raised in
this thread will go long way toward mending relationships and building an
effective team that spends more time on the development and less time
guessing who said what and who did what, or worse, politicking.

Silence or incomplete answers will probably be viewed by many people here
as signs that you may have some ulterior motives, other than the desire for
the project to succeed. Please do not allow us to think that you have some
agenda other than the desire for the project to succeed.

LEDE folks: so far you have done a better job explaining your reasons, but
what I said above applies to you 100% as well in all your future
undertakings. Please do care to explain your reasons, and please be
reasonable in your expectations. I understand that you’ve had enough of
grief and frustration and that was very likely the reason why you had
decided to create a fork. Please try to clear your mind of grief and
frustration now and please make an honest attempt to cooperate for the sake
of the OpenWRT/LEDE community at large.

None of us want to see OpenWRT/LEDE become another OpenOffice/LibreOffice
or Wayland/Mir story. These splits create huge amounts of waste and dilute
valuable resources.

On a personal note, I hope that the re-joined project continues as OpenWRT,
a name that is already well-recognized by many. I also hope that the
antiquated email patch submission mechanism finally gets retired. Github PR
mechanism is vastly superior.

Sincerely,
Val

On 27 June 2016 at 05:39, Jo-Philipp Wich  wrote:

> Hi Zoltan,
>
> we started a discussion on OpenWrt re-merge conditions over at lede-dev
> and waited for a while to solicit more feedback.
>
> Since no other people expressed further wishes and since you repeatedly
> asked for a list of things the LEDE folks would like to see in OpenWrt
> I'm going to summarize the list the items we've assembled in
> http://lists.infradead.org/pipermail/lede-adm/2016-June/000144.html
>
> In short our points are (in no particular order):
>
>  - Use the LEDE code base
>  - Adopt the LEDE governance rules
>  - Rework admin access policies
>  - Transfer the OpenWrt project domain to SPI
>  - Stop providing project email addresses
>  - Move mailing lists to an external, neutral provider
>  - Merge LEDE and OpenWrt infrastructure (wiki, forum, ...)
>  - Start a process for granting push access to package feed maintainers
>
> Plus a few other items which got mentioned or agreed upon during various
> discussions:
>
>  - Dissolve private channels
>  - Discuss project matters on public mailing lists
>
>
> Note that the points above reflect mostly the opinions of Felix, John
> and me. Other LEDE members might or might not endorse them, but at least
> did not reject those demands.
>
> Let me know if some of the things above are unclear to you.
>
> Regards,
> Jo
> ___
> 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] Response to LEDE proposal/queries/mail?

2016-06-27 Thread Hauke Mehrtens 


On 06/27/2016 11:39 AM, Jo-Philipp Wich wrote:
> Hi Zoltan,
> 
> we started a discussion on OpenWrt re-merge conditions over at lede-dev
> and waited for a while to solicit more feedback.
> 
> Since no other people expressed further wishes and since you repeatedly
> asked for a list of things the LEDE folks would like to see in OpenWrt
> I'm going to summarize the list the items we've assembled in
> http://lists.infradead.org/pipermail/lede-adm/2016-June/000144.html
> 
> In short our points are (in no particular order):
> 
>  - Use the LEDE code base
>  - Adopt the LEDE governance rules
>  - Rework admin access policies
>  - Transfer the OpenWrt project domain to SPI
>  - Stop providing project email addresses
>  - Move mailing lists to an external, neutral provider
>  - Merge LEDE and OpenWrt infrastructure (wiki, forum, ...)
>  - Start a process for granting push access to package feed maintainers
> 
> Plus a few other items which got mentioned or agreed upon during various
> discussions:
> 
>  - Dissolve private channels
>  - Discuss project matters on public mailing lists
> 
> 
> Note that the points above reflect mostly the opinions of Felix, John
> and me. Other LEDE members might or might not endorse them, but at least
> did not reject those demands.

I endorse this list.

In addition I would add:
 - Inform the project when talking in behave of the project with industry.

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

Re: [OpenWrt-Devel] [RFC v2 6/6] ar71xx: Reset QCA955x SGMII link on speed change

2016-06-27 Thread Sven Eckelmann 
On Tuesday 05 April 2016 15:32:13 Sven Eckelmann wrote:
> From: Sven Eckelmann 
>
> The SGMII link of the QCA955x seems to be unstable when the PHY changes the
> link speed. Reseting the SGMII and the PHY management control seems to
> resolve this problem.
>
> This was observed with an AR8033 and QCA9558
>
> Signed-off-by: Sven Eckelmann 
> ---
> v2:
>  - Split into multiple patches and adjust slightly to look more like an
>OpenWrt patch
>
> The code of this RFC is not meant to be an actual patch. It should show
> what the u-boot for QCA955x does and what seemed to work(tm) in my limited
> tests. It would be interesting to know whether this was also noticed by
> other people and how they fixed it (when they fixed it).

Just because asked if this is also required for the RGMII - short answer:
yes, it is.

Slightly longer answer: Yes, the link seems to desync(?) too when RGMII
changes the link speed. Unfortunately, there is also no real fix and the
workaround is even more terrible. The basic idea behind it is that the PHY has
to be changed into its digital loopback mode on each link change. And then the
SoC has to transfer some ethernet frames to the PHY and check if it receives
these packets again. If not, then it has to toggle the TX_INVERT bit of
ETH_CFG and retest. If it still doesn't work then the only solution for the
SoC is to jump out of the window (this part is not yet implemented).

I have just implemented a PoC in case somebody wants to play around with it.
Not that I would recommend that to anyone.

Kind regards,
SvenFrom: Sven Eckelmann 
Date: Tue, 26 Apr 2016 16:14:47 +0200
Subject: [RFC 7/6] ag71xx: Test link on QCA955x for PHY connectivity problems

The link between MAC and PHY on a QCA955x tends to break down after carrier
changes. This can be worked around by setting the PHY (AR803x only
supported) into digital loopback mode and then sending packets via this
link. If no data is returned then the TX_INVERT bit has to be toggled to
get the link working again.

No information was received from QCA what actually is broken.
---
 .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c   |  44 +++-
 .../ar71xx/files/arch/mips/ath79/mach-mr1750.c |   1 +
 .../ar71xx/files/arch/mips/ath79/mach-om5pac.c |   2 +
 .../ar71xx/files/arch/mips/ath79/mach-om5pacv2.c   |   2 +
 .../mips/include/asm/mach-ath79/ag71xx_platform.h  |   2 +
 .../drivers/net/ethernet/atheros/ag71xx/ag71xx.h   |  13 +
 .../net/ethernet/atheros/ag71xx/ag71xx_main.c  | 283 +
 .../net/ethernet/atheros/ag71xx/ag71xx_phy.c   |  17 +-
 .../999-dont-set-down-on-loopback.patch|  30 +++
 .../999-dont-set-down-on-loopback.patch|  30 +++
 .../999-dont-set-down-on-loopback.patch|  30 +++
 11 files changed, 451 insertions(+), 3 deletions(-)
 create mode 100644 target/linux/generic/patches-3.18/999-dont-set-down-on-loopback.patch
 create mode 100644 target/linux/generic/patches-4.1/999-dont-set-down-on-loopback.patch
 create mode 100644 target/linux/generic/patches-4.4/999-dont-set-down-on-loopback.patch

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index b43c80a..d1d3be7 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -373,10 +373,50 @@ static void ar934x_set_speed_ge0(int speed)
 	iounmap(base);
 }

+static u32 qca955x_get_eth_pll(unsigned int mac, int speed)
+{
+	struct ag71xx_platform_data *pdata;
+	struct ath79_eth_pll_data *pll_data;
+	u32 pll_val;
+	u32 tx_invert = 0;
+
+	switch (mac) {
+	case 0:
+		pll_data = _eth0_pll_data;
+		pdata = _eth0_data;
+		break;
+	case 1:
+		pll_data = _eth1_pll_data;
+		pdata = _eth1_data;
+		break;
+	default:
+		BUG();
+	}
+
+	switch (speed) {
+	case SPEED_10:
+		pll_val = pll_data->pll_10;
+		break;
+	case SPEED_100:
+		pll_val = pll_data->pll_100;
+		break;
+	case SPEED_1000:
+		pll_val = pll_data->pll_1000;
+		break;
+	default:
+		BUG();
+	}
+
+	/* toggle TX_INVERT when required by ag71xx */
+	if (pdata->tx_invert_war && pdata->tx_invert_active)
+		tx_invert =  BIT(31);
+
+	return pll_val ^ tx_invert;
+}
 static void qca955x_set_speed_xmii(int speed)
 {
 	void __iomem *base;
-	u32 val = ath79_get_eth_pll(0, speed);
+	u32 val = qca955x_get_eth_pll(0, speed);

 	base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
 	__raw_writel(val, base + QCA955X_PLL_ETH_XMII_CONTROL_REG);
@@ -386,7 +426,7 @@ static void qca955x_set_speed_xmii(int speed)
 static void qca955x_set_speed_sgmii(int speed)
 {
 	void __iomem *base;
-	u32 val = ath79_get_eth_pll(1, speed);
+	u32 val = qca955x_get_eth_pll(1, speed);

 	base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
 	__raw_writel(val, base + QCA955X_PLL_ETH_SGMII_CONTROL_REG);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c

Re: [OpenWrt-Devel] Response to LEDE proposal/queries/mail?

2016-06-27 Thread Felix Fietkau 
On 2016-06-27 11:56, mbm wrote:
> Am I correct in assuming that this is also a statement that the LEDE 
> members will assist in accomplishing the tasks mentioned?
From my side, yes - as long as we agree about the tasks in question.

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

Re: [OpenWrt-Devel] Response to LEDE proposal/queries/mail?

2016-06-27 Thread Jo-Philipp Wich 
Hi Mike,

given sufficient and reasonable agreements I am certainly willing to
help implementing our desired changes.

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

Re: [OpenWrt-Devel] Response to LEDE proposal/queries/mail?

2016-06-27 Thread mbm 
Am I correct in assuming that this is also a statement that the LEDE 
members will assist in accomplishing the tasks mentioned?



On 6/27/2016 2:39 AM, Jo-Philipp Wich wrote:

Hi Zoltan,

we started a discussion on OpenWrt re-merge conditions over at lede-dev
and waited for a while to solicit more feedback.

Since no other people expressed further wishes and since you repeatedly
asked for a list of things the LEDE folks would like to see in OpenWrt
I'm going to summarize the list the items we've assembled in
http://lists.infradead.org/pipermail/lede-adm/2016-June/000144.html

In short our points are (in no particular order):

  - Use the LEDE code base
  - Adopt the LEDE governance rules
  - Rework admin access policies
  - Transfer the OpenWrt project domain to SPI
  - Stop providing project email addresses
  - Move mailing lists to an external, neutral provider
  - Merge LEDE and OpenWrt infrastructure (wiki, forum, ...)
  - Start a process for granting push access to package feed maintainers

Plus a few other items which got mentioned or agreed upon during various
discussions:

  - Dissolve private channels
  - Discuss project matters on public mailing lists


Note that the points above reflect mostly the opinions of Felix, John
and me. Other LEDE members might or might not endorse them, but at least
did not reject those demands.

Let me know if some of the things above are unclear to you.

Regards,
Jo
___
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] Response to LEDE proposal/queries/mail?

2016-06-27 Thread Jo-Philipp Wich 
Hi Zoltan,

we started a discussion on OpenWrt re-merge conditions over at lede-dev
and waited for a while to solicit more feedback.

Since no other people expressed further wishes and since you repeatedly
asked for a list of things the LEDE folks would like to see in OpenWrt
I'm going to summarize the list the items we've assembled in
http://lists.infradead.org/pipermail/lede-adm/2016-June/000144.html

In short our points are (in no particular order):

 - Use the LEDE code base
 - Adopt the LEDE governance rules
 - Rework admin access policies
 - Transfer the OpenWrt project domain to SPI
 - Stop providing project email addresses
 - Move mailing lists to an external, neutral provider
 - Merge LEDE and OpenWrt infrastructure (wiki, forum, ...)
 - Start a process for granting push access to package feed maintainers

Plus a few other items which got mentioned or agreed upon during various
discussions:

 - Dissolve private channels
 - Discuss project matters on public mailing lists


Note that the points above reflect mostly the opinions of Felix, John
and me. Other LEDE members might or might not endorse them, but at least
did not reject those demands.

Let me know if some of the things above are unclear to you.

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

[OpenWrt-Devel] [PATCH libubox v3] blobmsg_json: add new functions blobmsg_format_json_value*

2016-06-27 Thread Matthias Schiffer 
The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).

To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.

Signed-off-by: Matthias Schiffer 
---
v3: fix rebase breakage
v2: no changes


 blobmsg_json.c | 58 --
 blobmsg_json.h | 14 ++
 2 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index 2e318b2..7fcf620 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -214,7 +214,7 @@ static void blobmsg_format_string(struct strbuf *s, const 
char *str)
 
 static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, 
int len, bool array);
 
-static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, 
bool array, bool head)
+static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, 
bool without_name, bool head)
 {
const char *data_str;
char buf[32];
@@ -224,7 +224,7 @@ static void blobmsg_format_element(struct strbuf *s, struct 
blob_attr *attr, boo
if (!blobmsg_check_attr(attr, false))
return;
 
-   if (!array && blobmsg_name(attr)[0]) {
+   if (!without_name && blobmsg_name(attr)[0]) {
blobmsg_format_string(s, blobmsg_name(attr));
blobmsg_puts(s, ": ", s->indent ? 2 : 1);
}
@@ -293,27 +293,30 @@ static void blobmsg_format_json_list(struct strbuf *s, 
struct blob_attr *attr, i
blobmsg_puts(s, (array ? "]" : "}"), 1);
 }
 
+static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, 
blobmsg_json_format_t cb, void *priv, int indent) {
+   s->len = blob_len(attr);
+   s->buf = malloc(s->len);
+   s->pos = 0;
+   s->custom_format = cb;
+   s->priv = priv;
+   s->indent = false;
+
+   if (indent >= 0) {
+   s->indent = true;
+   s->indent_level = indent;
+   }
+}
+
 char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, 
blobmsg_json_format_t cb, void *priv, int indent)
 {
struct strbuf s;
bool array;
char *ret;
 
-   s.len = blob_len(attr);
-   s.pos = 0;
-   s.custom_format = cb;
-   s.priv = priv;
-   s.indent = false;
-
-   s.buf = malloc(s.len);
+   setup_strbuf(, attr, cb, priv, indent);
if (!s.buf)
return NULL;
 
-   if (indent >= 0) {
-   s.indent = true;
-   s.indent_level = indent;
-   }
-
array = blob_is_extended(attr) &&
blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
 
@@ -337,3 +340,30 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, 
bool list, blobmsg_jso
 
return ret;
 }
+
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, 
blobmsg_json_format_t cb, void *priv, int indent)
+{
+   struct strbuf s;
+   char *ret;
+
+   setup_strbuf(, attr, cb, priv, indent);
+   if (!s.buf)
+   return NULL;
+
+   blobmsg_format_element(, attr, true, false);
+
+   if (!s.len) {
+   free(s.buf);
+   return NULL;
+   }
+
+   ret = realloc(s.buf, s.pos + 1);
+   if (!ret) {
+   free(s.buf);
+   return NULL;
+   }
+
+   ret[s.pos] = 0;
+
+   return ret;
+}
diff --git a/blobmsg_json.h b/blobmsg_json.h
index cd9ed33..9dfc02d 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct 
blob_attr *attr, bool list
return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
 }
 
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
+   blobmsg_json_format_t cb, void *priv,
+   int indent);
+
+static inline char *blobmsg_format_json_value(struct blob_attr *attr)
+{
+   return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
+}
+
+static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, 
int indent)
+{
+   return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
+}
+
 #endif
-- 
2.9.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel