From linus.walleij at linaro.org  Wed Feb  1 14:46:32 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed,  1 Feb 2017 20:46:32 +0100
Subject: [OpenWrt-Devel] [PATCH 12/22 v2] ARM: dts: add top-level DT
	bindings for Cortina Gemini
Message-ID: <20170201194632.18455-1-linus.walleij@linaro.org>

This adds the top level SoC bindings for Cortina systems Gemini
platforms.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Rename required property "intcon" to "interrupt-controller"
- Elaborate a bit on the SoC origins
- Put the example DTS SoC nodes in a soc {} node
---
 Documentation/devicetree/bindings/arm/gemini.txt | 81 ++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/gemini.txt

diff --git a/Documentation/devicetree/bindings/arm/gemini.txt b/Documentation/devicetree/bindings/arm/gemini.txt
new file mode 100644
index 000000000000..eb788302d3e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gemini.txt
@@ -0,0 +1,81 @@
+Cortina systems Gemini platforms
+
+The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally
+produced by Storlink Semiconductor around 2005. The company was renamed
+later renamed Storm Semiconductor. The chip product name is Storlink SL3516.
+It was derived from earlier products from Storm named SL3316 (Centroid) and
+SL3512.
+
+Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was
+produced and used for NAS and similar usecases. In 2014 Cortina Systems was
+in turn acquired by Inphi, who seem to have discontinued this product family.
+
+Required properties (in root node):
+	compatible = "cortina,gemini";
+
+Required nodes:
+
+- syscon: the root node must have a system controller node pointing to the
+  global control registers, with the compatible string
+  "cortina,gemini-syscon", "syscon";
+
+- timer: the root node must have a timer node pointing to the SoC timer
+  block, with the compatible string "cortina,gemini-timer"
+  See: clocksource/cortina,gemini-timer.txt
+
+- interrup-controller: the root node must have an interrupt controller
+  node pointing to the SoC interrupt controller block, with the compatible
+  string "cortina,gemini-interrupt-controller"
+  See interrupt-controller/cortina,gemini-interrupt-controller.txt
+
+Example:
+
+/ {
+	model = "Foo Gemini Machine";
+	compatible = "cortina,gemini";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x8000000>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		compatible = "simple-bus";
+		interrupt-parent = <&intcon>;
+
+		syscon: syscon at 40000000 {
+			compatible = "cortina,gemini-syscon", "syscon";
+			reg = <0x40000000 0x1000>;
+		};
+
+		uart0: serial at 42000000 {
+			compatible = "ns16550a";
+			reg = <0x42000000 0x100>;
+			clock-frequency = <48000000>;
+			interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+		};
+
+		timer at 43000000 {
+			compatible = "cortina,gemini-timer";
+			reg = <0x43000000 0x1000>;
+			interrupt-parent = <&intcon>;
+			interrupts = <14 IRQ_TYPE_EDGE_RISING>, /* Timer 1 */
+				     <15 IRQ_TYPE_EDGE_RISING>, /* Timer 2 */
+				     <16 IRQ_TYPE_EDGE_RISING>; /* Timer 3 */
+			syscon = <&syscon>;
+		};
+
+		intcon: interrupt-controller at 48000000 {
+			compatible = "cortina,gemini-interrupt-controller";
+			reg = <0x48000000 0x1000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Wed Feb  1 15:00:14 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 1 Feb 2017 21:00:14 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Cortina
	Gemini PCI Host Bridge
In-Reply-To: <20170131003137.GE20550@bhelgaas-glaptop.roam.corp.google.com>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170131003137.GE20550@bhelgaas-glaptop.roam.corp.google.com>
Message-ID: <CACRpkdZFHBufh1ZunKnY018_TN-s80drQ_f-KTtPoR6O5OGHrg@mail.gmail.com>

On Tue, Jan 31, 2017 at 1:31 AM, Bjorn Helgaas <helgaas at kernel.org> wrote:

>> +- bus-range: set to <0x00 0x00> (only root bus)
>
> Why is this limited to bus 0?  Is everything completely soldered down
> with no possibility of adding or replacing PCI devices? The interrupt-map
> below suggests slots, though.  If there's a slot, we could plug in a card
> with a bridge, which would mean more than just bus 0.

I thought so because it's a NAS box (the typical usecase) but when I
dismantled it and turned it over, wow, there is indeed a MiniPCI
slot!

OK I will augment this to 0x00 0xff.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Wed Feb  1 15:04:44 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 1 Feb 2017 21:04:44 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Cortina
	Gemini PCI Host Bridge
In-Reply-To: <20170201160224.jg6tuls2xcuul3m4@rob-hp-laptop>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170201160224.jg6tuls2xcuul3m4@rob-hp-laptop>
Message-ID: <CACRpkdat3rcNL9=FHXBD7zT5LoZy3BGCV1ZT74AoeR4JytSoaQ@mail.gmail.com>

On Wed, Feb 1, 2017 at 5:02 PM, Rob Herring <robh at kernel.org> wrote:
> On Sat, Jan 28, 2017 at 09:48:36PM +0100, Linus Walleij wrote:

>> +Example:
>> +
>> +pci at 50000000 {
>> +     compatible = "cortina,gemini-pci";
>> +     reg = <0x50000000 0x100>;
>
> Config space is indirectly accessed?

Yes it is a really annoying construction. The first device, the Faraday
roob hub is at that address, the init code uses that to set up the bus.

As soon as the bus is up, we use bus accessors to talk to the root
hub on slot 0 (this manages interrupts etc).

I guess I could even unmap this reg range at that point ...

I guess I could also get the address directly from the IO range
and start poking around. I don't know if that is any better.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From jamie at onebillion.org  Wed Feb  1 15:29:43 2017
From: jamie at onebillion.org (Jamie Stuart)
Date: Wed, 1 Feb 2017 20:29:43 +0000
Subject: [OpenWrt-Devel]   [LEDE-DEV] MT7620A WiFi issue - with a twist!
Message-ID: <0B19E733-9A13-4471-917E-1358CA9B7ACF@onebillion.org>

Hello LEDE / OpenWRT devs,

I am requesting your help. First a little background?

I am co-founder of an education technology charity, onebillion ( https://onebillion.org/ <https://onebillion.org/> ). We build apps that enable children to learn to read and become basically numerate in their own language. We are working with partners in Malawi and other sub-saharan African countries to scale tablet-based learning initiatives to marginalised children through the Unlocking Talent Initiative ( https://unlockingtalent.org <https://unlockingtalent.org/> ). Working through government schools in Malawi, groups of 30 children at a time are learning through our apps using solar-powered tablets. There are 120 schools (and rising) across the country taking part in the initiative. As of today, 20,000 children are getting numeracy and reading lesson in their own language every week.


In each school, the children?s tablets are connected via wifi to a small server to store their progress. It has a 3G connection to allow remote monitoring and MDM commands to be sent to the children?s tablets. The server ( http://www.zbtlink.com/products/router/WE1026.html <http://www.zbtlink.com/products/router/WE1026.html> ) currently runs OpenWRT (DD, from source, with a number of packages including MySQL, nginx, php7, OpenVPN,).

However?

We have a persistent problem. The tablets frequently have trouble communicating with the server over WiFi. We have replicated this issue in our London office using 30 iPad Minis connected to a test server. After running for a while (and especially during periods of high network activity, which are sparse), these errors appear in the logs:

rt2800mmio_txstatus_is_spurious: Warning - 4 spurious TX_FIFO_STATUS interrupt(s)
rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
rt2800mmio_txdone: Warning - Got TX status for an empty queue 2, dropping


After that, data transfer between client and server either slows to a crawl or stops entirely and the client decides to disassociate. This is not good for the children as we lose the ability to monitor their progress, and for them to log in.


This a known issue with the chipset and seems to have been round for years.
We are currently building on LEDE trunk and still the issue persists.

We are not driver developers, so my question is whether anyone with knowledge can help and provide a proper fix for this issue?

Jamie, onebillion







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170201/4f59eadb/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Thu Feb  2 19:43:43 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Fri, 3 Feb 2017 01:43:43 +0100
Subject: [OpenWrt-Devel] NETSHe mac80211 GPL sources
Message-ID: <20170203004342.GA1759@makrotopia.org>

Hi!

NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which
offers support for TDMA, see:
http://netshe.ru/files/doc/en/TDMA_brief_en.pdf

Where to download the sourcecode of mac80211 and the modified drivers?


Cheers


Daniel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.luessing at c0d3.blue  Fri Feb  3 02:53:03 2017
From: linus.luessing at c0d3.blue (Linus =?utf-8?Q?L=C3=BCssing?=)
Date: Fri, 3 Feb 2017 08:53:03 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] NETSHe mac80211 GPL sources
In-Reply-To: <fabd39a0-40e7-dccd-b125-46ca108998b7@netshe-lab.ru>
References: <20170203004342.GA1759@makrotopia.org>
 <fabd39a0-40e7-dccd-b125-46ca108998b7@netshe-lab.ru>
Message-ID: <20170203075303.GA19051@otheros>

On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
> Please check this article http://netshe.ru/wirelessstack to understand
> layering of our modifications in Linux wireless stack. 

"this module is a proprietary module broker"

Wow, that's a fancy name for it :D.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Fri Feb  3 03:29:33 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Fri, 3 Feb 2017 09:29:33 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
Message-ID: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>

Hi Felix,

SIGTERM & SIGINT signals received during ubus_complete_request()
waiting for ubus_poll_data() to return are ignored due to
uloop_cancelled being restored to its previous value it had before
uloop_poll_data() was called.

The reproduction scenario is this:
  1) cancelled local variable is set to false, current value of uloop_cancelled
  2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
received, so uloop_cancelled is set to true
  3) after ubus_poll_data() returns, uloop_cancelled value gets
overwritten with false and SIGTERM signal ends up being ignored in the
uloop_run()

The whole uloop_cancelled related logic in the ubus_complete_request()
seems to be focused on getting out from the current recursion of
uloop_run(), but from what I see uloop_run() capability to be called
recursively is no longer used in ubus, so I wonder if it is still
necessary.

If the answer is no, the entire logic referring to uloop_cancelled and
uloop_end() should be removed from libubus-req.c. Otherwise an
additional uloop_cancelled_recursions bit mask would be needed that
will allow to control uloop_run() exit condition for each individual
recursion.

Please share your pov so I could prepare the necessary patches.

Thanks,
Alin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Fri Feb  3 05:40:21 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Fri, 3 Feb 2017 11:40:21 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] NETSHe mac80211 GPL sources
In-Reply-To: <fabd39a0-40e7-dccd-b125-46ca108998b7@netshe-lab.ru>
References: <20170203004342.GA1759@makrotopia.org>
 <fabd39a0-40e7-dccd-b125-46ca108998b7@netshe-lab.ru>
Message-ID: <20170203104021.GA3861@makrotopia.org>

Hi Stas,

thanks for the quick reply!

I'm looking for a good way to replace ubiquiti's proprietary TDMA
implementation with something which could be vendor-independent and
interoperable -- and ideally Free Open Source Software.
As TDMA has been implemented for ath9k in FreeBSD, I was wondering if
a similar extension to mac80211 has been made -- and found NETSHe's
wireless stack. As ath9k, mac80211 and the Linux kernel are under the
GPL license, I was assuming that NETSHe's modifications to support
TDMA thus must be available under the GPL licensed as well.

So from what I understand you are using your own proprietary driver
instead of ath9k? Yet, cfg80211 and mac80211 seem to be involved
according to what I found in TDMA_brief_en.pdf, as TDMA interfaces
are added obviously added through nl80211. Earlier today I also
realised that this has previously been discussed on this mailing
list, see
https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034374.html

As you are offering a binary version of the firmware for download,
according to the GPL you are oblidged to also share the portion of
the source code which is under GPL (ie. at least the Linux kernel,
GPL'ed wireless drivers like ath9k, libnl, the 'iw' userspace, ...)
as well as all modifications you've made to that GPL licensed code.

Obviously you could easily avoid that legal requirement by just not
offering a free download of the binaries, so don't get me wrong, I
do appreciate your openness! Yet, it'd be great if we had a shared
codebase for TDMA instead of a growing number of competing
implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each
being developed behind closed doors. As your implementation is built
upon GPL'ed code and you offer binaries for download, please also
share the patches for iw, libnl, cfg80211, mac80211 and ath*k.
By the end of the day, you are using 99% code which other people have
written and published under the assumption that everyone is granted
the freedom to run, study, share and modify the software.
"The GPL is a copyleft license, which means that derivative work can
only be distributed under the same license terms." [1]
However, I'm not a lawyer and I have simply no idea if the GPL can
actually be enforced in the judicative domain NETSHe is located in or
whether we are talking about a purely idealistic/moralic issue here.

Anywa, my interest is to use and improve that code! Friends of mine
have started a non-profit collaborative ISP project [2] and we are
having a heated debate whether to use OpenWrt/LEDE from source or
ubnt's proprietary firmware on ubnt and other ath9k-based hardware.
Even though Wifi performance on ath9k recently improved a lot, a TDMA
implementation under a free license (ie. GPL) would be great thing to
have, also for use in Wireless Community Mesh Networks.

A good compromise could be to publish the code without the userspace
tools allowing AES crypto -- in that way, free community networks
can use that implementation and commercial entities would need to
license the crypto bits if they want link-level crypto.



Cheers


Daniel

[1]: https://en.wikipedia.org/wiki/GNU_General_Public_License
[2]: https://www.reudnetz.org/


On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
> Hi Daniel,
> 
> Please check this article http://netshe.ru/wirelessstack to understand
> layering of our modifications in Linux wireless stack. You can see that
> we add proprietary licensed and dual licensed drivers in wireless stack.
> We provide our GPLed and dual licensed source codes to our customer only.
> Not our source code is available at http://gw.stasoft.net/dl/
> 
> Can you tell me what is your real interest?
> 
> Regards, Stas
> 
> 
> On 03.02.2017 03:43, Daniel Golle wrote:
> > Hi!
> >
> > NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which
> > offers support for TDMA, see:
> > http://netshe.ru/files/doc/en/TDMA_brief_en.pdf
> >
> > Where to download the sourcecode of mac80211 and the modified drivers?
> >
> >
> > Cheers
> >
> >
> > Daniel
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Fri Feb  3 08:47:50 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 3 Feb 2017 14:47:50 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
In-Reply-To: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
References: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
Message-ID: <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>

Hi Alin,

On 2017-02-03 09:29, Alin N?stac wrote:
> Hi Felix,
> 
> SIGTERM & SIGINT signals received during ubus_complete_request()
> waiting for ubus_poll_data() to return are ignored due to
> uloop_cancelled being restored to its previous value it had before
> uloop_poll_data() was called.
> 
> The reproduction scenario is this:
>   1) cancelled local variable is set to false, current value of uloop_cancelled
>   2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
> received, so uloop_cancelled is set to true
>   3) after ubus_poll_data() returns, uloop_cancelled value gets
> overwritten with false and SIGTERM signal ends up being ignored in the
> uloop_run()
> 
> The whole uloop_cancelled related logic in the ubus_complete_request()
> seems to be focused on getting out from the current recursion of
> uloop_run(), but from what I see uloop_run() capability to be called
> recursively is no longer used in ubus, so I wonder if it is still
> necessary.
I left in uloop_cancelled primarily to deal with cleaning up recursive
requests after Ctrl+c or SIGTERM when uloop is in use.

> If the answer is no, the entire logic referring to uloop_cancelled and
> uloop_end() should be removed from libubus-req.c. Otherwise an
> additional uloop_cancelled_recursions bit mask would be needed that
> will allow to control uloop_run() exit condition for each individual
> recursion.
I think the main problem was the fact that uloop_cancelled was used
both for internal request termination and also for external use.
Here's a patch that should resolve this issue, please test:

---
diff --git a/libubus-io.c b/libubus-io.c
index 1075c65..1343bb2 100644
--- a/libubus-io.c
+++ b/libubus-io.c
@@ -154,9 +154,10 @@ int __hidden ubus_send_msg(struct ubus_context *ctx, uint32_t seq,
 	return ret;
 }
 
-static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
+static int recv_retry(struct ubus_context *ctx, struct iovec *iov, bool wait, int *recv_fd)
 {
 	int bytes, total = 0;
+	int fd = ctx->sock.fd;
 	static struct {
 		struct cmsghdr h;
 		int fd;
@@ -191,7 +192,7 @@ static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
 
 		if (bytes < 0) {
 			bytes = 0;
-			if (uloop_cancelled)
+			if (uloop_cancelled || ctx->cancel_poll)
 				return 0;
 			if (errno == EINTR)
 				continue;
@@ -274,7 +275,7 @@ static bool get_next_msg(struct ubus_context *ctx, int *recv_fd)
 	int r;
 
 	/* receive header + start attribute */
-	r = recv_retry(ctx->sock.fd, &iov, false, recv_fd);
+	r = recv_retry(ctx, &iov, false, recv_fd);
 	if (r <= 0) {
 		if (r < 0)
 			ctx->sock.eof = true;
@@ -298,7 +299,7 @@ static bool get_next_msg(struct ubus_context *ctx, int *recv_fd)
 	iov.iov_base = (char *)ctx->msgbuf.data + sizeof(hdrbuf.data);
 	iov.iov_len = blob_len(ctx->msgbuf.data);
 	if (iov.iov_len > 0 &&
-	    recv_retry(ctx->sock.fd, &iov, true, NULL) <= 0)
+	    recv_retry(ctx, &iov, true, NULL) <= 0)
 		return false;
 
 	return true;
@@ -311,7 +312,7 @@ void __hidden ubus_handle_data(struct uloop_fd *u, unsigned int events)
 
 	while (get_next_msg(ctx, &recv_fd)) {
 		ubus_process_msg(ctx, &ctx->msgbuf, recv_fd);
-		if (uloop_cancelled)
+		if (uloop_cancelled || ctx->cancel_poll)
 			break;
 	}
 
@@ -326,6 +327,7 @@ void __hidden ubus_poll_data(struct ubus_context *ctx, int timeout)
 		.events = POLLIN | POLLERR,
 	};
 
+	ctx->cancel_poll = false;
 	poll(&pfd, 1, timeout ? timeout : -1);
 	ubus_handle_data(&ctx->sock, ULOOP_READ);
 }
diff --git a/libubus-req.c b/libubus-req.c
index db5061c..305e813 100644
--- a/libubus-req.c
+++ b/libubus-req.c
@@ -122,7 +122,7 @@ static void ubus_sync_req_cb(struct ubus_request *req, int ret)
 {
 	req->status_msg = true;
 	req->status_code = ret;
-	uloop_end();
+	req->ctx->cancel_poll = true;
 }
 
 static int64_t get_time_msec(void)
@@ -142,6 +142,7 @@ int ubus_complete_request(struct ubus_context *ctx, struct ubus_request *req,
 	ubus_complete_handler_t complete_cb = req->complete_cb;
 	int status = UBUS_STATUS_NO_DATA;
 	int64_t timeout = 0, time_end = 0;
+	bool prev_uloop_cancelled = uloop_cancelled;
 
 	if (req_timeout)
 		time_end = get_time_msec() + req_timeout;
@@ -149,29 +150,32 @@ int ubus_complete_request(struct ubus_context *ctx, struct ubus_request *req,
 	ubus_complete_request_async(ctx, req);
 	req->complete_cb = ubus_sync_req_cb;
 
+	if (!ctx->stack_depth)
+		uloop_cancelled = false;
+
 	ctx->stack_depth++;
 	while (!req->status_msg) {
-		bool cancelled = uloop_cancelled;
-
-		uloop_cancelled = false;
 		if (req_timeout) {
 			timeout = time_end - get_time_msec();
 			if (timeout <= 0) {
 				ubus_set_req_status(req, UBUS_STATUS_TIMEOUT);
-				uloop_cancelled = cancelled;
 				break;
 			}
 		}
+
 		ubus_poll_data(ctx, (unsigned int) timeout);
 
-		uloop_cancelled = cancelled;
 		if (ctx->sock.eof) {
 			ubus_set_req_status(req, UBUS_STATUS_CONNECTION_FAILED);
+			ctx->cancel_poll = true;
 			break;
 		}
 	}
+
 	ctx->stack_depth--;
 	if (ctx->stack_depth)
+		ctx->cancel_poll = true;
+	else if (prev_uloop_cancelled)
 		uloop_cancelled = true;
 
 	if (req->status_msg)
diff --git a/libubus.h b/libubus.h
index ea53272..4e45cb6 100644
--- a/libubus.h
+++ b/libubus.h
@@ -155,6 +155,7 @@ struct ubus_context {
 
 	uint32_t local_id;
 	uint16_t request_seq;
+	bool cancel_poll;
 	int stack_depth;
 
 	void (*connection_lost)(struct ubus_context *ctx);
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Fri Feb  3 09:57:12 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Fri, 3 Feb 2017 15:57:12 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
In-Reply-To: <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>
References: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
 <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>
Message-ID: <CAF1oqRAtZ64iWZ3j8jTkKTP6TnaOt-ApaKX3p2sXyTp=tPvN5A@mail.gmail.com>

Hi Felix,

The SIGTERM ignore issue I was experiencing before is no longer
reproducible after I apply your patch.

However, I'm concerned about a possible ignore of SIGTERM signal
received during a ubus_complete_request() call. If ctx->stack_depth is
0, any such signal received between prev_uloop_initialization and the
reset of ulopp_cancelling to false will be ignored. Is this
"uloop_cancelling = false" really necessary?

BTW, I think the reset of uloop_status and uloop_cancelled should be
executed before uloop_setup_signals() like so:
        if (!recursive_calls++) {
               uloop_status = 0;
               uloop_cancelled = false;
               uloop_setup_signals(true);
        }

Cheers,
Alin

On Fri, Feb 3, 2017 at 2:47 PM, Felix Fietkau <nbd at nbd.name> wrote:
> Hi Alin,
>
> On 2017-02-03 09:29, Alin N?stac wrote:
>> Hi Felix,
>>
>> SIGTERM & SIGINT signals received during ubus_complete_request()
>> waiting for ubus_poll_data() to return are ignored due to
>> uloop_cancelled being restored to its previous value it had before
>> uloop_poll_data() was called.
>>
>> The reproduction scenario is this:
>>   1) cancelled local variable is set to false, current value of uloop_cancelled
>>   2) while ubus_poll_data() is waiting for a read event, a SIGTERM is
>> received, so uloop_cancelled is set to true
>>   3) after ubus_poll_data() returns, uloop_cancelled value gets
>> overwritten with false and SIGTERM signal ends up being ignored in the
>> uloop_run()
>>
>> The whole uloop_cancelled related logic in the ubus_complete_request()
>> seems to be focused on getting out from the current recursion of
>> uloop_run(), but from what I see uloop_run() capability to be called
>> recursively is no longer used in ubus, so I wonder if it is still
>> necessary.
> I left in uloop_cancelled primarily to deal with cleaning up recursive
> requests after Ctrl+c or SIGTERM when uloop is in use.
>
>> If the answer is no, the entire logic referring to uloop_cancelled and
>> uloop_end() should be removed from libubus-req.c. Otherwise an
>> additional uloop_cancelled_recursions bit mask would be needed that
>> will allow to control uloop_run() exit condition for each individual
>> recursion.
> I think the main problem was the fact that uloop_cancelled was used
> both for internal request termination and also for external use.
> Here's a patch that should resolve this issue, please test:
>
> ---
> diff --git a/libubus-io.c b/libubus-io.c
> index 1075c65..1343bb2 100644
> --- a/libubus-io.c
> +++ b/libubus-io.c
> @@ -154,9 +154,10 @@ int __hidden ubus_send_msg(struct ubus_context *ctx, uint32_t seq,
>         return ret;
>  }
>
> -static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
> +static int recv_retry(struct ubus_context *ctx, struct iovec *iov, bool wait, int *recv_fd)
>  {
>         int bytes, total = 0;
> +       int fd = ctx->sock.fd;
>         static struct {
>                 struct cmsghdr h;
>                 int fd;
> @@ -191,7 +192,7 @@ static int recv_retry(int fd, struct iovec *iov, bool wait, int *recv_fd)
>
>                 if (bytes < 0) {
>                         bytes = 0;
> -                       if (uloop_cancelled)
> +                       if (uloop_cancelled || ctx->cancel_poll)
>                                 return 0;
>                         if (errno == EINTR)
>                                 continue;
> @@ -274,7 +275,7 @@ static bool get_next_msg(struct ubus_context *ctx, int *recv_fd)
>         int r;
>
>         /* receive header + start attribute */
> -       r = recv_retry(ctx->sock.fd, &iov, false, recv_fd);
> +       r = recv_retry(ctx, &iov, false, recv_fd);
>         if (r <= 0) {
>                 if (r < 0)
>                         ctx->sock.eof = true;
> @@ -298,7 +299,7 @@ static bool get_next_msg(struct ubus_context *ctx, int *recv_fd)
>         iov.iov_base = (char *)ctx->msgbuf.data + sizeof(hdrbuf.data);
>         iov.iov_len = blob_len(ctx->msgbuf.data);
>         if (iov.iov_len > 0 &&
> -           recv_retry(ctx->sock.fd, &iov, true, NULL) <= 0)
> +           recv_retry(ctx, &iov, true, NULL) <= 0)
>                 return false;
>
>         return true;
> @@ -311,7 +312,7 @@ void __hidden ubus_handle_data(struct uloop_fd *u, unsigned int events)
>
>         while (get_next_msg(ctx, &recv_fd)) {
>                 ubus_process_msg(ctx, &ctx->msgbuf, recv_fd);
> -               if (uloop_cancelled)
> +               if (uloop_cancelled || ctx->cancel_poll)
>                         break;
>         }
>
> @@ -326,6 +327,7 @@ void __hidden ubus_poll_data(struct ubus_context *ctx, int timeout)
>                 .events = POLLIN | POLLERR,
>         };
>
> +       ctx->cancel_poll = false;
>         poll(&pfd, 1, timeout ? timeout : -1);
>         ubus_handle_data(&ctx->sock, ULOOP_READ);
>  }
> diff --git a/libubus-req.c b/libubus-req.c
> index db5061c..305e813 100644
> --- a/libubus-req.c
> +++ b/libubus-req.c
> @@ -122,7 +122,7 @@ static void ubus_sync_req_cb(struct ubus_request *req, int ret)
>  {
>         req->status_msg = true;
>         req->status_code = ret;
> -       uloop_end();
> +       req->ctx->cancel_poll = true;
>  }
>
>  static int64_t get_time_msec(void)
> @@ -142,6 +142,7 @@ int ubus_complete_request(struct ubus_context *ctx, struct ubus_request *req,
>         ubus_complete_handler_t complete_cb = req->complete_cb;
>         int status = UBUS_STATUS_NO_DATA;
>         int64_t timeout = 0, time_end = 0;
> +       bool prev_uloop_cancelled = uloop_cancelled;
>
>         if (req_timeout)
>                 time_end = get_time_msec() + req_timeout;
> @@ -149,29 +150,32 @@ int ubus_complete_request(struct ubus_context *ctx, struct ubus_request *req,
>         ubus_complete_request_async(ctx, req);
>         req->complete_cb = ubus_sync_req_cb;
>
> +       if (!ctx->stack_depth)
> +               uloop_cancelled = false;
> +
>         ctx->stack_depth++;
>         while (!req->status_msg) {
> -               bool cancelled = uloop_cancelled;
> -
> -               uloop_cancelled = false;
>                 if (req_timeout) {
>                         timeout = time_end - get_time_msec();
>                         if (timeout <= 0) {
>                                 ubus_set_req_status(req, UBUS_STATUS_TIMEOUT);
> -                               uloop_cancelled = cancelled;
>                                 break;
>                         }
>                 }
> +
>                 ubus_poll_data(ctx, (unsigned int) timeout);
>
> -               uloop_cancelled = cancelled;
>                 if (ctx->sock.eof) {
>                         ubus_set_req_status(req, UBUS_STATUS_CONNECTION_FAILED);
> +                       ctx->cancel_poll = true;
>                         break;
>                 }
>         }
> +
>         ctx->stack_depth--;
>         if (ctx->stack_depth)
> +               ctx->cancel_poll = true;
> +       else if (prev_uloop_cancelled)
>                 uloop_cancelled = true;
>
>         if (req->status_msg)
> diff --git a/libubus.h b/libubus.h
> index ea53272..4e45cb6 100644
> --- a/libubus.h
> +++ b/libubus.h
> @@ -155,6 +155,7 @@ struct ubus_context {
>
>         uint32_t local_id;
>         uint16_t request_seq;
> +       bool cancel_poll;
>         int stack_depth;
>
>         void (*connection_lost)(struct ubus_context *ctx);
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Fri Feb  3 10:19:21 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 3 Feb 2017 16:19:21 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
In-Reply-To: <CAF1oqRAtZ64iWZ3j8jTkKTP6TnaOt-ApaKX3p2sXyTp=tPvN5A@mail.gmail.com>
References: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
 <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>
 <CAF1oqRAtZ64iWZ3j8jTkKTP6TnaOt-ApaKX3p2sXyTp=tPvN5A@mail.gmail.com>
Message-ID: <63779bea-79ca-3e34-ef11-f6d10461357f@nbd.name>

On 2017-02-03 15:57, Alin N?stac wrote:
> Hi Felix,
> 
> The SIGTERM ignore issue I was experiencing before is no longer
> reproducible after I apply your patch.
> 
> However, I'm concerned about a possible ignore of SIGTERM signal
> received during a ubus_complete_request() call. If ctx->stack_depth is
> 0, any such signal received between prev_uloop_initialization and the
> reset of ulopp_cancelling to false will be ignored. Is this
> "uloop_cancelling = false" really necessary?
> 
> BTW, I think the reset of uloop_status and uloop_cancelled should be
> executed before uloop_setup_signals() like so:
>         if (!recursive_calls++) {
>                uloop_status = 0;
>                uloop_cancelled = false;
>                uloop_setup_signals(true);
>         }
I was worried about the corner case of performing a ubus request after
uloop_run has already completed.
I guess one way this could be addressed is by setting uloop_cancelled =
false at the end of uloop_run().

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

From alin.nastac at gmail.com  Fri Feb  3 10:41:15 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Fri, 3 Feb 2017 16:41:15 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
In-Reply-To: <63779bea-79ca-3e34-ef11-f6d10461357f@nbd.name>
References: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
 <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>
 <CAF1oqRAtZ64iWZ3j8jTkKTP6TnaOt-ApaKX3p2sXyTp=tPvN5A@mail.gmail.com>
 <63779bea-79ca-3e34-ef11-f6d10461357f@nbd.name>
Message-ID: <CAF1oqRAajdL4ERFTozHtRWvFVPz1RwzgV8N9Y4aHfYpCyEkmeQ@mail.gmail.com>

On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau <nbd at nbd.name> wrote:
> On 2017-02-03 15:57, Alin N?stac wrote:
>> Hi Felix,
>>
>> The SIGTERM ignore issue I was experiencing before is no longer
>> reproducible after I apply your patch.
>>
>> However, I'm concerned about a possible ignore of SIGTERM signal
>> received during a ubus_complete_request() call. If ctx->stack_depth is
>> 0, any such signal received between prev_uloop_initialization and the
>> reset of ulopp_cancelling to false will be ignored. Is this
>> "uloop_cancelling = false" really necessary?
>>
>> BTW, I think the reset of uloop_status and uloop_cancelled should be
>> executed before uloop_setup_signals() like so:
>>         if (!recursive_calls++) {
>>                uloop_status = 0;
>>                uloop_cancelled = false;
>>                uloop_setup_signals(true);
>>         }
> I was worried about the corner case of performing a ubus request after
> uloop_run has already completed.
> I guess one way this could be addressed is by setting uloop_cancelled =
> false at the end of uloop_run().

How about adding this uloop function:
static int recursive_calls = 0; /* moved from uloop_run() context */
int uloop_cancelling()
{
    return recursive_calls > 0 && uloop_cancelled;
}

This function will return true only when uloop_run() is still running,
so you will no longer need to touch uloop_cancelled state at all. This
way you could reduce the scope of uloop_cancelled to uloop.c too.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Fri Feb  3 12:58:19 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 3 Feb 2017 18:58:19 +0100
Subject: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received
 during ubus_complete_request() calls are ignored
In-Reply-To: <CAF1oqRAajdL4ERFTozHtRWvFVPz1RwzgV8N9Y4aHfYpCyEkmeQ@mail.gmail.com>
References: <CAF1oqRBAB=doAtW+6-jjmEMUnQcPcHnH1s0ak2ZJnoBP=6xZdg@mail.gmail.com>
 <a2381f11-cba1-b64d-f34e-72858f9169c6@nbd.name>
 <CAF1oqRAtZ64iWZ3j8jTkKTP6TnaOt-ApaKX3p2sXyTp=tPvN5A@mail.gmail.com>
 <63779bea-79ca-3e34-ef11-f6d10461357f@nbd.name>
 <CAF1oqRAajdL4ERFTozHtRWvFVPz1RwzgV8N9Y4aHfYpCyEkmeQ@mail.gmail.com>
Message-ID: <7f8de7e0-57bc-2ea8-3bfd-5aa98051e276@nbd.name>

On 2017-02-03 16:41, Alin N?stac wrote:
> On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau <nbd at nbd.name> wrote:
>> On 2017-02-03 15:57, Alin N?stac wrote:
>>> Hi Felix,
>>>
>>> The SIGTERM ignore issue I was experiencing before is no longer
>>> reproducible after I apply your patch.
>>>
>>> However, I'm concerned about a possible ignore of SIGTERM signal
>>> received during a ubus_complete_request() call. If ctx->stack_depth is
>>> 0, any such signal received between prev_uloop_initialization and the
>>> reset of ulopp_cancelling to false will be ignored. Is this
>>> "uloop_cancelling = false" really necessary?
>>>
>>> BTW, I think the reset of uloop_status and uloop_cancelled should be
>>> executed before uloop_setup_signals() like so:
>>>         if (!recursive_calls++) {
>>>                uloop_status = 0;
>>>                uloop_cancelled = false;
>>>                uloop_setup_signals(true);
>>>         }
>> I was worried about the corner case of performing a ubus request after
>> uloop_run has already completed.
>> I guess one way this could be addressed is by setting uloop_cancelled =
>> false at the end of uloop_run().
> 
> How about adding this uloop function:
> static int recursive_calls = 0; /* moved from uloop_run() context */
> int uloop_cancelling()
> {
>     return recursive_calls > 0 && uloop_cancelled;
> }
> 
> This function will return true only when uloop_run() is still running,
> so you will no longer need to touch uloop_cancelled state at all. This
> way you could reduce the scope of uloop_cancelled to uloop.c too.
Implemented that in libubox.git and ubus.git. Will push to LEDE master soon.

Thanks,

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

From linus.walleij at linaro.org  Fri Feb  3 14:55:51 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri,  3 Feb 2017 20:55:51 +0100
Subject: [OpenWrt-Devel] [PATCH 2/3 v3] watchdog: add DT bindings for
	Cortina Gemini
Message-ID: <20170203195551.4825-1-linus.walleij@linaro.org>

This adds DT bindings for the Cortina systems Gemini SoC
watchdog timer.

Cc: devicetree at vger.kernel.org
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Fixed spelling error in filename "gemin" to "gemini"
- Collected ACKs
ChangeLog v1->v2:
- Make the timeout an optional property
- Do not mention any Linux defaults if the property is not there
---
 .../bindings/watchdog/cortina,gemini-watchdog.txt       | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt

diff --git a/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt b/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt
new file mode 100644
index 000000000000..bc4b865d178b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cortina,gemini-watchdog.txt
@@ -0,0 +1,17 @@
+Cortina Systems Gemini SoC Watchdog
+
+Required properties:
+- compatible : must be "cortina,gemini-watchdog"
+- reg : shall contain base register location and length
+- interrupts : shall contain the interrupt for the watchdog
+
+Optional properties:
+- timeout-sec : the default watchdog timeout in seconds.
+
+Example:
+
+watchdog at 41000000 {
+	compatible = "cortina,gemini-watchdog";
+	reg = <0x41000000 0x1000>;
+	interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nick at fishun.co.uk  Fri Feb  3 19:17:58 2017
From: nick at fishun.co.uk (Nick Malyon)
Date: Fri, 3 Feb 2017 18:17:58 -0600
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
	upstream network goes down
Message-ID: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>

Hi all,

I tried to open the following bug report but Trac's spam filter wouldn't let me, so I thought I'd raise it on the mailing list to see what you think...

I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it to provide a WiFi access point to my phone/tablet while I travel, and it's acting as a WiFi client for the various hostels I visit.

If you configure it as a wifi client with a wwan interface using the LuCI scan/join wizard, and then you configure a wifi access point on the same radio, the router works as expected and when you connect to the router's AP, you get Internet via the client connection.

However, if you move out of range of the network the router is a client of, or if it goes down, when you power off the OpenWrt router and power back on, the access point won't come up.

The AP will only come up if the client network you configured is also working; so you have no way to connect to the router over wifi, and no way to reconfigure the router, if that client network is down or out of range.

This is a particular problem for a travel router because it will often move it out of range of the original upstream network, and you may only have a wifi-capable device with which to reconfigure it.

The Ethernet port on the router does remain active, so I can tell it does actually boot. It's just the radio that doesn't come up. I managed to get back in range of a network once, and the router worked as expected.

It doesn't matter whether the AP or client connection are configured first or second on the radio interface, and, unticking "bring up on boot" for the wwan interface has no effect on the behaviour.

Steps to reproduce: Connect the router to a wifi network as a client using the Join wizard. Add a wifi master-mode access point on the same radio interface. Verify you can access the Internet by joining the router's new master AP. Reboot the router with the original network it was a client of turned off. Notice the router's AP you configured never comes up.

Expected behaviour: The master access point of the router should always come up, regardless of the availability of the client network.

If anyone has a workaround that would be great ? currently I managed to get back in range of a network to make it accessible again, and now I run from batteries and delete the wifi client configuration every night before the jungle power goes out.

If this is indeed a bug, if you could please raise it in Trac for me ? sorry, I get a "rejected due to possible spam" error, maybe because of my location.

Many thanks!
- Nick
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From luizluca at gmail.com  Fri Feb  3 19:25:42 2017
From: luizluca at gmail.com (Luiz Angelo Daros de Luca)
Date: Sat, 04 Feb 2017 00:25:42 +0000
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
Message-ID: <CAJq09z7FZX-_gDiwChXWmP3iUBtOmfDrNrPOiQL9g+Ew+zv6VA@mail.gmail.com>

Nick, you can try lede-project bug tracker. I recently released rc1.

Em sex, 3 de fev de 2017 22:18, Nick Malyon <nick at fishun.co.uk> escreveu:

> Hi all,
>
> I tried to open the following bug report but Trac's spam filter wouldn't
> let me, so I thought I'd raise it on the mailing list to see what you
> think...
>
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it
> to provide a WiFi access point to my phone/tablet while I travel, and it's
> acting as a WiFi client for the various hostels I visit.
>
> If you configure it as a wifi client with a wwan interface using the LuCI
> scan/join wizard, and then you configure a wifi access point on the same
> radio, the router works as expected and when you connect to the router's
> AP, you get Internet via the client connection.
>
> However, if you move out of range of the network the router is a client
> of, or if it goes down, when you power off the OpenWrt router and power
> back on, the access point won't come up.
>
> The AP will only come up if the client network you configured is also
> working; so you have no way to connect to the router over wifi, and no way
> to reconfigure the router, if that client network is down or out of range.
>
> This is a particular problem for a travel router because it will often
> move it out of range of the original upstream network, and you may only
> have a wifi-capable device with which to reconfigure it.
>
> The Ethernet port on the router does remain active, so I can tell it does
> actually boot. It's just the radio that doesn't come up. I managed to get
> back in range of a network once, and the router worked as expected.
>
> It doesn't matter whether the AP or client connection are configured first
> or second on the radio interface, and, unticking "bring up on boot" for the
> wwan interface has no effect on the behaviour.
>
> Steps to reproduce: Connect the router to a wifi network as a client using
> the Join wizard. Add a wifi master-mode access point on the same radio
> interface. Verify you can access the Internet by joining the router's new
> master AP. Reboot the router with the original network it was a client of
> turned off. Notice the router's AP you configured never comes up.
>
> Expected behaviour: The master access point of the router should always
> come up, regardless of the availability of the client network.
>
> If anyone has a workaround that would be great ? currently I managed to
> get back in range of a network to make it accessible again, and now I run
> from batteries and delete the wifi client configuration every night before
> the jungle power goes out.
>
> If this is indeed a bug, if you could please raise it in Trac for me ?
> sorry, I get a "rejected due to possible spam" error, maybe because of my
> location.
>
> Many thanks!
> - Nick
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizluca at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170204/04466578/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From weedy2887 at gmail.com  Fri Feb  3 19:49:22 2017
From: weedy2887 at gmail.com (Weedy)
Date: Fri, 3 Feb 2017 19:49:22 -0500
Subject: [OpenWrt-Devel] [LEDE-DEV] MT7620A WiFi issue - with a twist!
In-Reply-To: <0B19E733-9A13-4471-917E-1358CA9B7ACF@onebillion.org>
References: <0B19E733-9A13-4471-917E-1358CA9B7ACF@onebillion.org>
Message-ID: <CAFE24U1_aFw=CRC6WBN_9Z6yyGnT4VG6xDFWv5L5EGYhbUPREA@mail.gmail.com>

On 1 February 2017 at 15:29, Jamie Stuart <jamie at onebillion.org> wrote:
> Hello LEDE / OpenWRT devs,
>
> I am requesting your help. First a little background?
...
> This a known issue with the chipset and seems to have been round for years.
> We are currently building on LEDE trunk and still the issue persists.
>
> We are not driver developers, so my question is whether anyone with
> knowledge can help and provide a proper fix for this issue?


You will probably have the most luck posting a bounty on the linux
wifi mailing list.

Your root problem is picking a platform that basically uses a client
mode tested driver in AP mode and then hanging a million clients off
of it. I'm honestly surprised it didn't fall over sooner.

May I suggest when it comes time to refresh the hardware you guys pick
something with NGFF or mini-pcie slots for ALL radios.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From weedy2887 at gmail.com  Fri Feb  3 21:31:51 2017
From: weedy2887 at gmail.com (Weedy)
Date: Fri, 3 Feb 2017 21:31:51 -0500
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
Message-ID: <CAFE24U18fNXUYLQ1_faWYUTbO-ODJ0b5QSCcJJ=nJCoRz7OoEg@mail.gmail.com>

On 3 February 2017 at 19:17, Nick Malyon <nick at fishun.co.uk> wrote:
> If anyone has a workaround that would be great ? currently I managed to get back in range of a network to make it accessible again, and now I run from batteries and delete the wifi client configuration every night before the jungle power goes out.


Do you have access to a PC? I would be interested in seeing the
wireless config file. specifically if the AP or STA section is listed
first.

I have a script I use to keep my repeated online in case of bullshit.
I can probably modify it to help you out if I get your config. Are you
using the template off the wiki with relayd and interface wwan etc?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nick at fishun.co.uk  Fri Feb  3 23:59:50 2017
From: nick at fishun.co.uk (Nick Malyon)
Date: Fri, 3 Feb 2017 22:59:50 -0600
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
	upstream network goes down
In-Reply-To: <CAFE24U18fNXUYLQ1_faWYUTbO-ODJ0b5QSCcJJ=nJCoRz7OoEg@mail.gmail.com>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
 <CAFE24U18fNXUYLQ1_faWYUTbO-ODJ0b5QSCcJJ=nJCoRz7OoEg@mail.gmail.com>
Message-ID: <39CD7A1C-A014-4AB9-B5D2-0AAE59FF0D70@fishun.co.uk>

Hey,

I only have my phone, but I have a Terminal app ?. Here's the config; I used the LuCI web interface to manage it. It doesn't seem to make a difference whether I join the client network then create the AP, or create the AP then join the network.

In this instance, I joined the network after creating the AP...

root at OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'platform/ar933x_wmac'
        option htmode 'HT40'
        option txpower '15'
        option country 'CR'
        option disabled '0'
        option channel '1'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'Treehouse'
        option encryption 'psk2+ccmp'
        option key '*****'

config wifi-iface
        option network 'wwan'
        option ssid 'LA PAZ'
        option encryption 'psk2'
        option device 'radio0'
        option mode 'sta'
        option bssid '00:21:6C:DA:56:85'
        option key '*****'

Thanks!
- Nick

> On 3 Feb 2017, at 8:31 pm, Weedy <weedy2887 at gmail.com> wrote:
> 
>> On 3 February 2017 at 19:17, Nick Malyon <nick at fishun.co.uk> wrote:
>> If anyone has a workaround that would be great ? currently I managed to get back in range of a network to make it accessible again, and now I run from batteries and delete the wifi client configuration every night before the jungle power goes out.
> 
> 
> Do you have access to a PC? I would be interested in seeing the
> wireless config file. specifically if the AP or STA section is listed
> first.
> 
> I have a script I use to keep my repeated online in case of bullshit.
> I can probably modify it to help you out if I get your config. Are you
> using the template off the wiki with relayd and interface wwan etc?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Sat Feb  4 13:11:53 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 4 Feb 2017 19:11:53 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] MT7620A WiFi issue - with a twist!
In-Reply-To: <CAFE24U1_aFw=CRC6WBN_9Z6yyGnT4VG6xDFWv5L5EGYhbUPREA@mail.gmail.com>
References: <0B19E733-9A13-4471-917E-1358CA9B7ACF@onebillion.org>
 <CAFE24U1_aFw=CRC6WBN_9Z6yyGnT4VG6xDFWv5L5EGYhbUPREA@mail.gmail.com>
Message-ID: <20170204181152.GC1690@makrotopia.org>

Hi Weedy,

On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote:
> On 1 February 2017 at 15:29, Jamie Stuart <jamie at onebillion.org> wrote:
> > Hello LEDE / OpenWRT devs,
> >
> > I am requesting your help. First a little background?
> ...
> > This a known issue with the chipset and seems to have been round for years.
> > We are currently building on LEDE trunk and still the issue persists.
> >
> > We are not driver developers, so my question is whether anyone with
> > knowledge can help and provide a proper fix for this issue?
> 
> 
> You will probably have the most luck posting a bounty on the linux
> wifi mailing list.

As a response to the many issues and obvious code quality problems in
the patch adding support for MT7620 to rt2x00 I started a kickstarter
project to fund an afternoon or two (depending on the amount people
throw into my hat) of focussing on rt2x00 running on MT7620:

https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede


> 
> Your root problem is picking a platform that basically uses a client
> mode tested driver in AP mode and then hanging a million clients off
> of it. I'm honestly surprised it didn't fall over sooner.

Well, rt2x00 is used for both AP and Client mode, and afaik there
wasn't a lot of testing for either mode of operation. And AP mode has
recently seen quite a bunch of improvements.
Having seperate drivers for AP and STA is a common strategy of chip
makers to devide-and-conquer QA and also add product differentiation,
ie. sell the same hardware for more if it is used for specific tasks.
Thus Ralink used to give away the station-mode driver for free and used
to charge people for the AP-mode driver (they do share a common
codebase). The bigger issue here is that Ralink's WiFi chip design is
flawed when using the chips in multi-STA modes (AP, Adhoc, Mesh)
because instead of having a way to set parameters for each associated
station it only allows it to be set globally, see [1] for an example of
how rt2x00 thus needs to limit the hardware to use the parameters of
the weakest associated station (the vendor driver does the same).

> 
> May I suggest when it comes time to refresh the hardware you guys pick
> something with NGFF or mini-pcie slots for ALL radios.

+1
Though I personally don't believe it's ever going to get as chaotic
and complex as for the final generation of Ralink's WiFi chips (ie.
which later became MT76x0). Ralink/Mediatek's newer chips are much
cleaner and don't share the same issues.


Cheers


Daniel

[1] https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/drivers/net/wireless/ralink/rt2x00/rt2800lib.c?id=8f03a7c6e7f959edd22e35158fbb9a4087962fae
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb  4 13:43:15 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 4 Feb 2017 19:43:15 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Cortina Gemini
	Host Bridge
In-Reply-To: <2695922.yyinjvNuJK@wuerfel>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-2-linus.walleij@linaro.org> <2695922.yyinjvNuJK@wuerfel>
Message-ID: <CACRpkdb=BqihykWo3egtNW1VKE2-FV+nJQQVYOc2GdCvh1fMng@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:11 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday, January 28, 2017 9:48:37 PM CET Linus Walleij wrote:

>> +     /* No clue what these do */
>> +     pcibios_min_io = 0x100;
>> +     pcibios_min_mem = 0;
>
> Don't touch these

OK I have a clue why this is there now, atleast the first one.

The first 0x100 in the IOspace is actually configuration registers
for the bridge. That is why we have this:

reg = <0x50000000 0x100>;
(...)
/* PCI ranges mappings */
                        ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
                         <0x01000000 0 0          0x50000000 0 0x00100000>,

This is in all the vendor code I have located too.

So the pcibios_min_io is manipulated to avoid touching that
sensitive area. But I also see that arch/arm/mm/iomap.c
sets it to 0x1000, according to the commit because you said
it's the only valid value :D

I tried setting the IO range to <0x50000100 0x000FFF00>
instead of <0x50000000 0x00100000>
but predictably that doesn't work. Maybe it should, I don't
know really.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Sat Feb  4 14:35:27 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 4 Feb 2017 20:35:27 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] NETSHe mac80211 GPL sources
In-Reply-To: <00f47f8f-05f3-5205-08a1-2a7a3c5b6e88@netshe-lab.ru>
References: <20170203004342.GA1759@makrotopia.org>
 <fabd39a0-40e7-dccd-b125-46ca108998b7@netshe-lab.ru>
 <20170203104021.GA3861@makrotopia.org>
 <00f47f8f-05f3-5205-08a1-2a7a3c5b6e88@netshe-lab.ru>
Message-ID: <20170204193527.GG1690@makrotopia.org>

Hi Stas,

On Fri, Feb 03, 2017 at 03:58:15PM +0300, Stanislav V. Korsakov wrote:
> Hi Daniel,
> 
> Why do you think that all our TDMA-related modifications must be under
> GPL license?

As you are using cfg80211 and mac80211 I just guessed that chances are
high that you'd also use ath9k and modified it.

> 
> We use cfg80211, mac80211, ath5k and ath9k with very small modifications
> to support new type of interface and to handle some new netlink commands.
> We call own dual licensed module from mac80211 to handle new type of
> interface. Some code to provide new functionality is placed in our
> proprietary licensed driver. This driver does not use any GPL exported
> calls/symbols from the kernel and other drivers. Code from this module
> is used from our dual licensed module only. This module taints kernel.
> 
> In our mind, we do not breach GPL v2 with this architecture.
> Thus, we have two parts of source code:
> 1. GPLed and dual-licensed. We provide this source code to our
> customers. Any customer can open GPLed part if he wish to do it. Why
> should we provide it for everyone (not customers)? Please point me to
> GPL v2 license term which has this requirements. Not your interpretation.
> 2. Closed source for our proprietary module.

Ok, thanks a lot for the clarifications. That's indeed a clean solution
as far as I can judge.


> 
> We do not share our binaries for everyone since v3.2. All GPLed code
> (including patches) is available in a free access for v3.2.

Is that the code on sourceforge.net?

> 
> At least, we try to keep copyrights and software licenses and I do not
> see license breaches now. You can find what we build our firmware, what
> we used and how. E.g. how we use OpenWRT and what is the difference. We
> do not hide it.
> If you found breaches - inform me to cancel.

That's not the road I'm going for ;) I'm just interested in code, I am
not an expert on legal/license things.

> 
> About idealistic...
> I did not see long time and effective working just for fun only...
> Programmers want to eat...

Of course, same here. From a labour perspective FOSS can also be seen
as quite a nightmare -- not long ago, companies needed to hire people
and then educate them while paying them. Today, you're expected to be
self-educated and nobody cares how people are feeding themselves while
studying free software code...

> Open source is very good and helpful thing. Let discuss how we can help
> but keep in mind that we need to earn money too.

Imho this conversation can already be seen as a contribution.
To avoid confusion in future, it'd be great if you made sure that the
GPL'ed part of the sources can be found right next to the binaries as
well as on webpages linking to those binaries.

Another good concept could be to make sure stuff goes public once you
longer have commercial interest in it. That will allow e.g. securiy
audits of outdated gear in the field and also help future generations
to understand history and evolution of software. CodeWeavers and the
wine folks get's that right, imho, but it's a rare thing. Most of the
time, stuff just disappears and future researchers are left in the
dark when the try to figure out what happened 10 years ago.

> 
> Excuse me my bad English. Hope, I explained our point of view...

No worries, your English is good and I didn't have any problems
understanding what you were writing.
Thank you for your time and for explaining things!

> 
> Now about implementation details if it still interesting...
> 
> Our implementation is completely different from Ubiquiti or FreeBSD's.
> In my mind, first uses PCF mode variation. Second is original but i do
> not impress how it works in noisy environment.
> For our implementation, closest mode is AdHoc with own scheduler.
> Scheduler is implemented in software completely.
> Our implementation is well for narrow channels and not big mesh networks
> (and we do own mesh implementation above TDMA) but lost efficiency with
> wide channels. We can not utilize HT/VHT  and have bigger delay by design.

That's indeed quite different from what I expected. But surely makes
sense for long-distance links where QoS and reliability is a most, I
imagine that VoIP should work very well using your solution.
However, for the purpose I had in mind (wireless community ISP in urban
areas) I'd rather have MiMo and more throughput as links are rather
short compared to what you are doing. Nevertheless, I'm impressed by
your report of 30km+ stable links!


Cheers


Daniel



> 
> Regards, Stas
> 
> 
> On 03.02.2017 13:40, Daniel Golle wrote:
> > Hi Stas,
> >
> > thanks for the quick reply!
> >
> > I'm looking for a good way to replace ubiquiti's proprietary TDMA
> > implementation with something which could be vendor-independent and
> > interoperable -- and ideally Free Open Source Software.
> > As TDMA has been implemented for ath9k in FreeBSD, I was wondering if
> > a similar extension to mac80211 has been made -- and found NETSHe's
> > wireless stack. As ath9k, mac80211 and the Linux kernel are under the
> > GPL license, I was assuming that NETSHe's modifications to support
> > TDMA thus must be available under the GPL licensed as well.
> >
> > So from what I understand you are using your own proprietary driver
> > instead of ath9k? Yet, cfg80211 and mac80211 seem to be involved
> > according to what I found in TDMA_brief_en.pdf, as TDMA interfaces
> > are added obviously added through nl80211. Earlier today I also
> > realised that this has previously been discussed on this mailing
> > list, see
> > https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034374.html
> >
> > As you are offering a binary version of the firmware for download,
> > according to the GPL you are oblidged to also share the portion of
> > the source code which is under GPL (ie. at least the Linux kernel,
> > GPL'ed wireless drivers like ath9k, libnl, the 'iw' userspace, ...)
> > as well as all modifications you've made to that GPL licensed code.
> >
> > Obviously you could easily avoid that legal requirement by just not
> > offering a free download of the binaries, so don't get me wrong, I
> > do appreciate your openness! Yet, it'd be great if we had a shared
> > codebase for TDMA instead of a growing number of competing
> > implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each
> > being developed behind closed doors. As your implementation is built
> > upon GPL'ed code and you offer binaries for download, please also
> > share the patches for iw, libnl, cfg80211, mac80211 and ath*k.
> > By the end of the day, you are using 99% code which other people have
> > written and published under the assumption that everyone is granted
> > the freedom to run, study, share and modify the software.
> > "The GPL is a copyleft license, which means that derivative work can
> > only be distributed under the same license terms." [1]
> > However, I'm not a lawyer and I have simply no idea if the GPL can
> > actually be enforced in the judicative domain NETSHe is located in or
> > whether we are talking about a purely idealistic/moralic issue here.
> >
> > Anywa, my interest is to use and improve that code! Friends of mine
> > have started a non-profit collaborative ISP project [2] and we are
> > having a heated debate whether to use OpenWrt/LEDE from source or
> > ubnt's proprietary firmware on ubnt and other ath9k-based hardware.
> > Even though Wifi performance on ath9k recently improved a lot, a TDMA
> > implementation under a free license (ie. GPL) would be great thing to
> > have, also for use in Wireless Community Mesh Networks.
> >
> > A good compromise could be to publish the code without the userspace
> > tools allowing AES crypto -- in that way, free community networks
> > can use that implementation and commercial entities would need to
> > license the crypto bits if they want link-level crypto.
> >
> >
> >
> > Cheers
> >
> >
> > Daniel
> >
> > [1]: https://en.wikipedia.org/wiki/GNU_General_Public_License
> > [2]: https://www.reudnetz.org/
> >
> >
> > On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
> >> Hi Daniel,
> >>
> >> Please check this article http://netshe.ru/wirelessstack to understand
> >> layering of our modifications in Linux wireless stack. You can see that
> >> we add proprietary licensed and dual licensed drivers in wireless stack.
> >> We provide our GPLed and dual licensed source codes to our customer only.
> >> Not our source code is available at http://gw.stasoft.net/dl/
> >>
> >> Can you tell me what is your real interest?
> >>
> >> Regards, Stas
> >>
> >>
> >> On 03.02.2017 03:43, Daniel Golle wrote:
> >>> Hi!
> >>>
> >>> NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which
> >>> offers support for TDMA, see:
> >>> http://netshe.ru/files/doc/en/TDMA_brief_en.pdf
> >>>
> >>> Where to download the sourcecode of mac80211 and the modified drivers?
> >>>
> >>>
> >>> Cheers
> >>>
> >>>
> >>> Daniel
> >>
> >> _______________________________________________
> >> Lede-dev mailing list
> >> Lede-dev at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From luke at lukeross.name  Sat Feb  4 16:13:00 2017
From: luke at lukeross.name (Luke Ross)
Date: Sat, 4 Feb 2017 21:13:00 +0000
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
Message-ID: <20170204211259.5e5yw3hf2vrovhat@lukeross.name>

Hi,

On Fri, Feb 03, 2017 at 06:17:58PM -0600, Nick Malyon wrote:
> 
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it to 
> provide a WiFi access point to my phone/tablet while I travel, and it's 
> acting as a WiFi client for the various hostels I visit.
> 
> If you configure it as a wifi client with a wwan interface using the LuCI 
> scan/join wizard, and then you configure a wifi access point on the same 
> radio, the router works as expected and when you connect to the router's AP, 
> you get Internet via the client connection.
> 
> However, if you move out of range of the network the router is a client of, 
> or if it goes down, when you power off the OpenWrt router and power back on, 
> the access point won't come up.

I've hit exactly the same issue with an MR3040 - it appears the router is all 
good apart from the AP which won't come up. I've not got to the bottom of why, 
but I've set the slide switch to enable/disable the wifi client so at least I 
can recover easily (and it also allows me to reconfigure the ethernet from lan 
to wan depending on position).

https://github.com/jefferyto/openwrt-slide-switch makes using the slide switch 
super-easy. The button script I've hooked up to the wifi position is at 
https://github.com/lukeross/OpenWRT-Config/blob/master/MR3040/etc/rc.button/mode-wisp

With regards,

Luke
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Sun Feb  5 04:53:02 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Sun, 5 Feb 2017 10:53:02 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 14/22] ARM: dts: add a devicetree for
 Raidsonic NAS IB-4220-B
In-Reply-To: <20170122122254.10764-1-linus.walleij@linaro.org>
References: <20170122122254.10764-1-linus.walleij@linaro.org>
Message-ID: <alpine.LNX.2.00.1702051051090.26313@T420s>

Hi Linus,

please add right baudrate and partition scheme for NAS 4220

Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>

---
 arch/arm/boot/dts/gemini-nas4220b.dts | 36 +++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index 0b30cdeb2354..7668ba52158e 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -19,7 +19,7 @@
 	};
 
 	chosen {
-		bootargs = "console=ttyS0,115200n8";
+		bootargs = "console=ttyS0,19200n8";
 		stdout-path = &uart0;
 	};
 
@@ -64,7 +64,39 @@
 			status = "okay";
 			/* 16MB of flash */
 			reg = <0x30000000 0x01000000>;
-			/* TODO: add flash partitions here */
+
+			partition at 0 {
+				label = "RedBoot";
+				reg = <0x00000000 0x00020000>;
+				read-only;
+			};
+			partition at 20000 {
+				label = "Kernel";
+				reg = <0x00020000 0x00300000>;
+			};
+			partition at 320000 {
+				label = "Ramdisk";
+				reg = <0x00320000 0x00600000>;
+			};
+			partition at 920000 {
+				label = "Application";
+				reg = <0x00920000 0x00600000>;
+			};
+			partition at f20000 {
+				label = "VCTL";
+				reg = <0x00f20000 0x00020000>;
+				read-only;
+			};
+			partition at f40000 {
+				label = "CurConf";
+				reg = <0x00f40000 0x000a0000>;
+				read-only;
+			};
+			partition at fe0000 {
+				label = "FIS directory";
+				reg = <0x00fe0000 0x00020000>;
+				read-only;
+			};
 		};
 	};
 };
-- 
2.11.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Sun Feb  5 05:00:41 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Sun, 5 Feb 2017 11:00:41 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Cortina Gemini
	Host Bridge
In-Reply-To: <20170128204839.18330-2-linus.walleij@linaro.org>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-2-linus.walleij@linaro.org>
Message-ID: <alpine.LNX.2.00.1702051054240.26313@T420s>

Hi Linus

while debugging my boot issues on my NAS 4220, I saw this warning

irq: type mismatch, failed to map hwirq-26 for /soc/interrupt-controller at 48000000!

We need to use the use the use the PCI IRQ from gemini as root for the irq 
domain, not the next one in DT.

diff --git a/drivers/pci/host/pci-gemini.c b/drivers/pci/host/pci-gemini.c
index 7051dd992114..bb564a8e6379 100644
--- a/drivers/pci/host/pci-gemini.c
+++ b/drivers/pci/host/pci-gemini.c
@@ -217,7 +217,6 @@ static const struct irq_domain_ops gemini_pci_irqdomain_ops = {
 
 static int gemini_pci_setup_irq(struct gemini_pci *p, int irq)
 {
-	struct device_node *intc = of_get_next_child(p->dev->of_node, NULL);
 	int i;
 
 	if (!intc) {
@@ -225,7 +224,7 @@ static int gemini_pci_setup_irq(struct gemini_pci *p, int irq)
 		return -EINVAL;
 	}
 
-	p->irqdomain = irq_domain_add_linear(intc, 4,
+	p->irqdomain = irq_domain_add_linear(p->dev->of_node, 4,
 					     &gemini_pci_irqdomain_ops,
 					     p);
 	if (!p->irqdomain) {
-- 
2.11.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Sun Feb  5 05:03:14 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Sun, 5 Feb 2017 11:03:14 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini DTSI
In-Reply-To: <20170128204839.18330-4-linus.walleij@linaro.org>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-4-linus.walleij@linaro.org>
Message-ID: <alpine.LNX.2.00.1702051101110.26313@T420s>

Hi Linus

We need to the remove hwirq 26-28 from DT.
First one will print this warning while boot.

irq: type mismatch, failed to map hwirq-26 for /soc/interrupt-controller at 48000000!

 arch/arm/boot/dts/gemini.dtsi | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 11441e577058..0e2c021cd8c5 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -114,10 +114,7 @@
 		pci at 50000000 {
 			compatible = "cortina,gemini-pci";
 			reg = <0x50000000 0x100>;
-			interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
-				   	<26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
-					<27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
-					<28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
+			interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; /* chained irq PCI A-D */
 			#address-cells = <3>;
 			#size-cells = <2>;
 			#interrupt-cells = <1>;
-- 
2.11.0
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb  5 09:36:41 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 5 Feb 2017 15:36:41 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Cortina Gemini
	Host Bridge
In-Reply-To: <alpine.LNX.2.00.1702051054240.26313@T420s>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-2-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051054240.26313@T420s>
Message-ID: <CACRpkdY=gc4R5RwgPrFnjyfLVqgN0=ChVe6D7ibvAA+8Q1sqNA@mail.gmail.com>

On Sun, Feb 5, 2017 at 11:00 AM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:

> irq: type mismatch, failed to map hwirq-26 for /soc/interrupt-controller at 48000000!
>
> We need to use the use the use the PCI IRQ from gemini as root for the irq
> domain, not the next one in DT.

Hm I wonder if that is because I need to set the parent for the intcon
in the device tree as Arnd pointed out in the bindings patch?

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb  5 09:44:42 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 5 Feb 2017 15:44:42 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Cortina
	Gemini PCI Host Bridge
In-Reply-To: <7079928.XO1j93ERJc@wuerfel>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <7079928.XO1j93ERJc@wuerfel>
Message-ID: <CACRpkdZtuqF-ekNzVTNY4BBCt2bG6NcTAFs-ARYGw7q5E=jBTw@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:09 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday, January 28, 2017 9:48:36 PM CET Linus Walleij wrote:
>> +       pci_intc: interrupt-controller {
>> +               interrupt-controller;
>> +               #address-cells = <0>;
>> +               #interrupt-cells = <1>;
>> +       };
>
> I think this one needs at least an interrupt-parent property, otherwise
> you would recursively translate the numbers back through the interrupt-map
> property of its parent.

OK I added this, I think it was the cause of the error Hand Uli Kroll
was seeing. I guess I didn't run into it because I was only testing the
device in slot 9 so everything was defaulting to zero.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb  5 09:56:43 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 5 Feb 2017 15:56:43 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Cortina
	Gemini PCI Host Bridge
In-Reply-To: <17693846.Edk12xXofc@wuerfel>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <17693846.Edk12xXofc@wuerfel>
Message-ID: <CACRpkdYpBYaeTo2SJ55=cwKcZ5Y7A1k-wy1N3UuR6u3L3RdNoA@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:19 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday, January 28, 2017 9:48:36 PM CET Linus Walleij wrote:
>> +       interrupt-map-mask = <0xff00 0 0 7>;
>> +       interrupt-map = <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
>> +                       <0x4900 0 0 2 &pci_intc 1>,
>> +                       <0x4a00 0 0 3 &pci_intc 2>,
>> +                       <0x4b00 0 0 4 &pci_intc 3>,
>> +                       <0x5000 0 0 1 &pci_intc 0>, /* Slot 10 */
>> +                       <0x5100 0 0 2 &pci_intc 1>,
>> +                       <0x5200 0 0 3 &pci_intc 2>,
>> +                       <0x5300 0 0 4 &pci_intc 3>,
>> +                       <0x5800 0 0 1 &pci_intc 0>, /* Slot 11 */
>> +                       <0x5900 0 0 2 &pci_intc 1>,
>> +                       <0x5a00 0 0 3 &pci_intc 2>,
>> +                       <0x5b00 0 0 4 &pci_intc 3>,
>> +                       <0x6000 0 0 1 &pci_intc 0>, /* Slot 12 */
>> +                       <0x6100 0 0 2 &pci_intc 1>,
>> +                       <0x6200 0 0 3 &pci_intc 2>,
>> +                       <0x6300 0 0 4 &pci_intc 3>;
>>
>
> The mapping looks wrong here, we normally don't list interrupts per function
> so the mask should be 0xf800.

Yup it works that way too, and indeed the USB hub on function
2 was requesting the right pin and everything.

> Note that the interrupt map is board specific, so this should probably
> go in the board.dts file rather than platform.dtsi.

OK moving it down there.

> For this particular board, the interrupt lines appear to have been badly
> configured so all slots use the same interrupt 0 for IntA. IIRC This also
> means you can probably use <0 0 0 7> as the mask and just specify each of
> the four interrupts once. A properly wired board would swizzle the
> interrupts so that each slot has a different IRQ for its IntA line.

They are swizzled, I just have very bad hardware docs. (Only
code.) It turns out when I'm browsing through old board support
code that there is a comment followed by a piece of code like this:

/*
 *      No swizzle on SL2312
 */
static u8 __init sl2312_pci_swizzle(struct pci_dev *dev, u8 *pinp)
{
        return PCI_SLOT(dev->devfn);
}

/*
 * map the specified device/slot/pin to an IRQ.  This works out such
 * that slot 9 pin 1 is INT0, pin 2 is INT1, and slot 10 pin 1 is INT1.
 */
static int __init sl2312_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
{
        int intnr = ((slot  + (pin - 1)) & 3) + 4;  /* the IRQ number
of PCI bridge */

        printk("%s : slot = %d  pin = %d \n",__func__,slot,pin);
    switch (slot)
    {
        case 12:
                if (pin==1)
                {
                        intnr = 3;
                    }
                    else
                    {
                        intnr = 0;
                    }
#ifdef CONFIG_DUAL_PCI
                    return IRQ_PCI_INTD;
#endif
            break;
        case 11:
                    intnr = (2 + (pin - 1)) & 3;
#ifdef CONFIG_DUAL_PCI
                    return IRQ_PCI_INTC;
#endif
            break;
        case 10:
                    intnr = (1 + (pin - 1)) & 3;
#ifdef CONFIG_DUAL_PCI
                    return IRQ_PCI_INTB;
#endif
            break;
        case  9:
                    intnr = (pin - 1) & 3;
            break;
    }
//      if (slot == 10)
//              intnr = (1 + (pin - 1)) & 3;
//      else if (slot == 9)
//              intnr = (pin - 1) & 3;
        return (IRQ_PCI_INTA + intnr);
}

If I understand correctly they say that the IRQs are not swizzled
on the PCI bridge side but on the IRQ handler side.

So if I put it in the device tree like so:

+                         interrupt-map =
+                               <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+                               <0x4800 0 0 2 &pci_intc 1>,
+                               <0x4800 0 0 3 &pci_intc 2>,
+                               <0x4800 0 0 4 &pci_intc 3>,
+                               <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+                               <0x5000 0 0 2 &pci_intc 2>,
+                               <0x5000 0 0 3 &pci_intc 3>,
+                               <0x5000 0 0 4 &pci_intc 0>,
+                               <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+                               <0x5800 0 0 2 &pci_intc 3>,
+                               <0x5800 0 0 3 &pci_intc 0>,
+                               <0x5800 0 0 4 &pci_intc 1>,
+                               <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+                               <0x6000 0 0 2 &pci_intc 0>,
+                               <0x6000 0 0 3 &pci_intc 1>,
+                               <0x6000 0 0 4 &pci_intc 2>;

So the IRQs on the right side are swizzled instead
of the pins being swizzled.

...but that looks a bit insane.

Isn't that exactly the same thing just exposed in some
inverse way?

I'll try to get the RALink MiniPCI I have ?n the slot going and
see if it works the same with just good old vanilla
swizzling.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb  5 10:00:13 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 5 Feb 2017 16:00:13 +0100
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini DTSI
In-Reply-To: <alpine.LNX.2.00.1702051101110.26313@T420s>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-4-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051101110.26313@T420s>
Message-ID: <CACRpkdbrys49Yv5fJ_te2H1mEUqquc1jn2dP-uvkdLixFbtYFA@mail.gmail.com>

On Sun, Feb 5, 2017 at 11:03 AM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:

> We need to the remove hwirq 26-28 from DT.
> First one will print this warning while boot.
>
> irq: type mismatch, failed to map hwirq-26 for /soc/interrupt-controller at 48000000!
(...)
> -                       interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
> -                                       <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
> -                                       <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
> -                                       <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
> +                       interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; /* chained irq PCI A-D */

Sure I can remove them ... just found them in the irqs.h file and thought it
made sense to add them. I'll just cut them.

Since there is actually an internal IRQ controller in the host controller
cascading the four PCI child IRQs that we model as an irqchip, I don't
really see why they have these "PCI B-D" IRQs... anyone has a guess?

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From scharania11 at gmail.com  Sun Feb  5 10:07:02 2017
From: scharania11 at gmail.com (Sam Charania)
Date: Sun, 5 Feb 2017 15:07:02 +0000
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
	signal E1700 (MT7620A)
Message-ID: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>

Hi,

Did this ever get resolved?

I would like to help resolve it so please advise ASAP.

Thanks,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170205/015368ad/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Sun Feb  5 10:24:13 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 5 Feb 2017 16:24:13 +0100
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
Message-ID: <20170205152412.GB2018@makrotopia.org>

Hi Sam,

If this didn't get any better with on recent LEDE builds after commit
https://git.lede-project.org/?p=source.git;a=commit;h=b367eef21dccbc5115778001955847ac3af47db8
it's most likely the issue is due to missing external PA init in the
rt2x00 driver. I'm currently fixing the most of the obvious problems
with rt2x00 on MT7620, but there are too many to get this done within
a weekend and a kickstarter bounty of EUR 200. External PA currently
isn't on the list of things I give priority to because none of the
boards I've seen are using this feature. Please retry with the current
LEDE build, if that doesn't fix the issue, let me know.

I'll fix external PA if you are willing to help testing on the device
you own and obviously I'd appreciate if you throw something into my
hat for that tedious work on a not-very-well designed wifi chip and
a driver which has grown beyond reasonable size...

https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede/


Cheers


Daniel

On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
> Hi,
> 
> Did this ever get resolved?
> 
> I would like to help resolve it so please advise ASAP.
> 
> Thanks,
> Sam

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From tpham3783 at gmail.com  Sun Feb  5 14:19:10 2017
From: tpham3783 at gmail.com (Toan Pham)
Date: Sun, 5 Feb 2017 14:19:10 -0500
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <20170205152412.GB2018@makrotopia.org>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
 <20170205152412.GB2018@makrotopia.org>
Message-ID: <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>

Hi,

I tested OpenWrt trunk version on the E1700 five months ago.  At that time,
openwrt (or the vendor) claimed that all of all ethernet ports are gibabit
ports (ref.  https://wiki.openwrt.org/toh/hwdata/linksys/linksys_e1700)
However, All four ports showed up as 100Mb, not Gbps ports, on Chaos Calmer
build.  Please let me know if you're experiencing the same thing, if so,
should we update Openwrt product spec webpage to reflect the actual link
speed?

I also found wifi on the e1700 hardware unbearable.  That's why I had to
revert back to OEM firmware.



TP

On Sun, Feb 5, 2017 at 10:24 AM, Daniel Golle <daniel at makrotopia.org> wrote:

> Hi Sam,
>
> If this didn't get any better with on recent LEDE builds after commit
> https://git.lede-project.org/?p=source.git;a=commit;h=
> b367eef21dccbc5115778001955847ac3af47db8
> it's most likely the issue is due to missing external PA init in the
> rt2x00 driver. I'm currently fixing the most of the obvious problems
> with rt2x00 on MT7620, but there are too many to get this done within
> a weekend and a kickstarter bounty of EUR 200. External PA currently
> isn't on the list of things I give priority to because none of the
> boards I've seen are using this feature. Please retry with the current
> LEDE build, if that doesn't fix the issue, let me know.
>
> I'll fix external PA if you are willing to help testing on the device
> you own and obviously I'd appreciate if you throw something into my
> hat for that tedious work on a not-very-well designed wifi chip and
> a driver which has grown beyond reasonable size...
>
> https://www.kickstarter.com/projects/1327597961/better-
> support-for-mt7620a-n-in-openwrt-lede/
>
>
> Cheers
>
>
> Daniel
>
> On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
> > Hi,
> >
> > Did this ever get resolved?
> >
> > I would like to help resolve it so please advise ASAP.
> >
> > Thanks,
> > Sam
>
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170205/f9ad107b/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Mon Feb  6 04:55:03 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Mon, 6 Feb 2017 10:55:03 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini DTSI
In-Reply-To: <CACRpkdbrys49Yv5fJ_te2H1mEUqquc1jn2dP-uvkdLixFbtYFA@mail.gmail.com>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-4-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051101110.26313@T420s>
 <CACRpkdbrys49Yv5fJ_te2H1mEUqquc1jn2dP-uvkdLixFbtYFA@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1702061038590.7077@T420s>

Hi Linus,

On Sun, 5 Feb 2017, Linus Walleij wrote:

> On Sun, Feb 5, 2017 at 11:03 AM, Hans Ulli Kroll
> <ulli.kroll at googlemail.com> wrote:
> 
> > We need to the remove hwirq 26-28 from DT.
> > First one will print this warning while boot.
> >
> > irq: type mismatch, failed to map hwirq-26 for /soc/interrupt-controller at 48000000!
> (...)
> > -                       interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
> > -                                       <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
> > -                                       <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
> > -                                       <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
> > +                       interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; /* chained irq PCI A-D */
> 
> Sure I can remove them ... just found them in the irqs.h file and thought it
> made sense to add them. I'll just cut them.
> 
> Since there is actually an internal IRQ controller in the host controller
> cascading the four PCI child IRQs that we model as an irqchip, I don't
> really see why they have these "PCI B-D" IRQs... anyone has a guess?

I think they used some other IP vendor.

from my IB 4220 sources.

#define IRQ_PCI_INTA				       PCI_IRQ_OFFSET + 0
#ifndef CONFIG_DUAL_PCI
#define IRQ_PCI_INTB				       PCI_IRQ_OFFSET + 1
#define IRQ_PCI_INTC				       PCI_IRQ_OFFSET + 2
#define IRQ_PCI_INTD				       PCI_IRQ_OFFSET + 3
#else
#define IRQ_PCI_INTB				       27
#define IRQ_PCI_INTC				       28
#define IRQ_PCI_INTD				       29
#endif

CONFIG_DUAL_PCI is never used
IRQ_PCIB - IRQ_PCID or IRQ_PCI_INTB - IRQ_PCI_INTD are also never used.

You can download my original NAS 4220 here
http://ulli-kroll.de/gemini/kernel.tgz

Greetings
Hans Ulli Kroll
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From karlp at tweak.net.au  Mon Feb  6 06:40:37 2017
From: karlp at tweak.net.au (Karl Palsson)
Date: Mon, 06 Feb 2017 11:40:37 -0000
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
Message-ID: <YfNksWiYa7exrroFmpEhzbqRnjhapd74ZjQrwRG22199@mailpile>


I've been advised this is "expected" though I find it
disappointing, as you do.

It's agreed that this behaviour is "non optimal" for various use
cases, and it was suggested that it could be possible to provider
better fallback behaviour by modifying hostapd. It's currently
prioritizing the STA mode, and keeps rescanning and trying to
associate, which blocks the AP from coming up.

You can see the same behaviour if you enter the wrong password
for the network you're trying to attach to. It will continually
retry the bad password and never bring up the AP.

As far as getting worked on, the general response was, "use two
radios if you want two networks dummy" which was, accurate
perhaps, but... unhelpful :)

Sincerely,
Karl Palsson


Nick Malyon <nick at fishun.co.uk> wrote:
> Hi all,
> 
> I tried to open the following bug report but Trac's spam filter
> wouldn't let me, so I thought I'd raise it on the mailing list
> to see what you think...
> 
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm
> using it to provide a WiFi access point to my phone/tablet
> while I travel, and it's acting as a WiFi client for the
> various hostels I visit.
> 
> If you configure it as a wifi client with a wwan interface
> using the LuCI scan/join wizard, and then you configure a wifi
> access point on the same radio, the router works as expected
> and when you connect to the router's AP, you get Internet via
> the client connection.
> 
> However, if you move out of range of the network the router is
> a client of, or if it goes down, when you power off the OpenWrt
> router and power back on, the access point won't come up.
> 
> The AP will only come up if the client network you configured
> is also working; so you have no way to connect to the router
> over wifi, and no way to reconfigure the router, if that client
> network is down or out of range.
> 
> This is a particular problem for a travel router because it
> will often move it out of range of the original upstream
> network, and you may only have a wifi-capable device with which
> to reconfigure it.
> 
> The Ethernet port on the router does remain active, so I can
> tell it does actually boot. It's just the radio that doesn't
> come up. I managed to get back in range of a network once, and
> the router worked as expected.
> 
> It doesn't matter whether the AP or client connection are
> configured first or second on the radio interface, and,
> unticking "bring up on boot" for the wwan interface has no
> effect on the behaviour.
> 
> Steps to reproduce: Connect the router to a wifi network as a
> client using the Join wizard. Add a wifi master-mode access
> point on the same radio interface. Verify you can access the
> Internet by joining the router's new master AP. Reboot the
> router with the original network it was a client of turned off.
> Notice the router's AP you configured never comes up.
> 
> Expected behaviour: The master access point of the router
> should always come up, regardless of the availability of the
> client network.
> 
> If anyone has a workaround that would be great ? currently I
> managed to get back in range of a network to make it accessible
> again, and now I run from batteries and delete the wifi client
> configuration every night before the jungle power goes out.
> 
> If this is indeed a bug, if you could please raise it in Trac
> for me ? sorry, I get a "rejected due to possible spam" error,
> maybe because of my location.
> 
> Many thanks!
> - Nick
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.html
Type: application/pgp-signature
Size: 1161 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170206/c9b56f5d/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From tizbac2 at gmail.com  Mon Feb  6 10:34:24 2017
From: tizbac2 at gmail.com (Tiziano Bacocco)
Date: Mon, 6 Feb 2017 16:34:24 +0100
Subject: [OpenWrt-Devel] Nanostation m5 XW ethernet patch gone
Message-ID: <CAMLJ59z1h=xpMUqEY6xOnPhne1aii_51vuZdThYTfRk==wmT-A@mail.gmail.com>

Hello everyone
Could this patch http://gerrit.aredn.org/#/c/57 be merged in trunk?
I've just tested it with trunk and it works properly on my nanostation loco
m5 xw , the PHY chip is correctly reset every like 8 hours or so and no
connectivity loss since then

Bug report:
https://dev.openwrt.org/ticket/19085

System log after applying patch
Sun Feb  5 23:40:02 2017 kern.info kernel: [716206.656361] br-lan: port
1(eth0) entered forwarding state
Sun Feb  5 23:40:02 2017 daemon.notice netifd: Network device 'eth0' link
is up
Sun Feb  5 23:40:04 2017 kern.info kernel: [716208.654021] br-lan: port
1(eth0) entered forwarding state
Mon Feb  6 05:05:21 2017 kern.info kernel: [735725.556613]
ag71xx_check_reset: expected: 004d, got: 0000
Mon Feb  6 05:05:21 2017 kern.info kernel: [735725.562190]
ag71xx_gpio_reset triggered
Mon Feb  6 05:05:21 2017 kern.info kernel: [735725.571328] eth0: link down
Mon Feb  6 05:05:21 2017 daemon.notice netifd: Network device 'eth0' link
is down
Mon Feb  6 05:05:21 2017 kern.info kernel: [735725.574702] br-lan: port
1(eth0) entered disabled state
Mon Feb  6 05:05:23 2017 kern.info kernel: [735727.567752] eth0: link up
(100Mbps/Full duplex)
Mon Feb  6 05:05:23 2017 kern.info kernel: [735727.572533] br-lan: port
1(eth0) entered forwarding state
Mon Feb  6 05:05:23 2017 kern.info kernel: [735727.578224] br-lan: port
1(eth0) entered forwarding state
Mon Feb  6 05:05:23 2017 daemon.notice netifd: Network device 'eth0' link
is up


I'm not commenting to the bug report because i' both unable to register and
to comment because trac complains that i'm spamming, my ip address range
is 89.202.181.128 - 89.202.181.143
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170206/cbe017cb/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Tue Feb  7 04:14:31 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Tue, 7 Feb 2017 14:44:31 +0530
Subject: [OpenWrt-Devel] Wshaper package dependencies fail with snapshot
	image-builder
Message-ID: <CAKhqrsBMPyqmLC4jmSLRBAWZ8+ZVqvuzmUWLrn_CJzzWgT3FhQ@mail.gmail.com>

Hello OpenWRT team,

I am trying to build ramips/7620 router firmware with wshaper
and luci-app-wshaper package.  Build fails due to dependency error.

----------
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for
luci-app-wshaper:
 * wshaper *
 * opkg_install_cmd: Cannot install package wshaper.
Makefile:146: recipe for target 'package_install' failed
-------------

Please provide a fix.


Regards,
Mangesh Bhamre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/2d6c051b/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From dave.taht at gmail.com  Tue Feb  7 05:01:08 2017
From: dave.taht at gmail.com (Dave Taht)
Date: Tue, 7 Feb 2017 02:01:08 -0800
Subject: [OpenWrt-Devel] Wshaper package dependencies fail with snapshot
	image-builder
In-Reply-To: <CAKhqrsBMPyqmLC4jmSLRBAWZ8+ZVqvuzmUWLrn_CJzzWgT3FhQ@mail.gmail.com>
References: <CAKhqrsBMPyqmLC4jmSLRBAWZ8+ZVqvuzmUWLrn_CJzzWgT3FhQ@mail.gmail.com>
Message-ID: <CAA93jw6dpNx5CA1b3YFX0iC1VKhwwTmykjpGE62AFkP3dr8x4Q@mail.gmail.com>

wshaper was just retired in favor of sqm-scripts and qos-scripts.

See

https://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die/

for why.


On Tue, Feb 7, 2017 at 1:14 AM, Mangesh Bhamre <mangesh at opennetware.com> wrote:
> Hello OpenWRT team,
>
> I am trying to build ramips/7620 router firmware with wshaper and
> luci-app-wshaper package.  Build fails due to dependency error.
>
> ----------
>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for
> luci-app-wshaper:
>  * wshaper *
>  * opkg_install_cmd: Cannot install package wshaper.
> Makefile:146: recipe for target 'package_install' failed
> -------------
>
> Please provide a fix.
>
>
> Regards,
> Mangesh Bhamre
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From daniel at makrotopia.org  Tue Feb  7 06:23:01 2017
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 7 Feb 2017 12:23:01 +0100
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
 <20170205152412.GB2018@makrotopia.org>
 <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>
Message-ID: <20170207112300.GC1704@makrotopia.org>

Hi Toan,

I received some more funding on the kickstarter campaign which will
allow me to add support for the external PA and external LNA stuff
which will bring our GPL'ed driver to the same level of hardware
support of the vendor's driver.
In order to do that it'd be great if you can provide some help:
Please flash your router to OpenWrt or LEDE and enter a console via
SSH. Then see which flash partition holds the wifi eeprom:
cat /proc/mtd
There is supposed to be a 'factory' partition, e.g. /dev/mtd2 or
something like that. Dump that partition to /tmp
dd if=/dev/mtd2 of=/tmp/factory.bin
Then logout and copy that file to your workstation:
scp root at 192.168.1.1:/tmp/factory.bin .
(assuming the router has the IP 192.168.1.1)
Then send that file (factory.bin) to me via email, so I can analyze
it and see how we can auto-detect those features present on your
device.

I know this is some effort (flashing OpenWrt/LEDE and then reverting
to the factory firmware, loosing your configuration on the way and all
that) but I would be a great help and most likely improve the bad wifi
signal situation on OpenWrt/LEDE within the next days.


Cheers


Daniel


On Sun, Feb 05, 2017 at 02:19:10PM -0500, Toan Pham wrote:
> Hi,
> 
> I tested OpenWrt trunk version on the E1700 five months ago.  At that time,
> openwrt (or the vendor) claimed that all of all ethernet ports are gibabit
> ports (ref.  https://wiki.openwrt.org/toh/hwdata/linksys/linksys_e1700)
> However, All four ports showed up as 100Mb, not Gbps ports, on Chaos Calmer
> build.  Please let me know if you're experiencing the same thing, if so,
> should we update Openwrt product spec webpage to reflect the actual link
> speed?
> 
> I also found wifi on the e1700 hardware unbearable.  That's why I had to
> revert back to OEM firmware.
> 
> 
> 
> TP
> 
> On Sun, Feb 5, 2017 at 10:24 AM, Daniel Golle <daniel at makrotopia.org> wrote:
> 
> > Hi Sam,
> >
> > If this didn't get any better with on recent LEDE builds after commit
> > https://git.lede-project.org/?p=source.git;a=commit;h=
> > b367eef21dccbc5115778001955847ac3af47db8
> > it's most likely the issue is due to missing external PA init in the
> > rt2x00 driver. I'm currently fixing the most of the obvious problems
> > with rt2x00 on MT7620, but there are too many to get this done within
> > a weekend and a kickstarter bounty of EUR 200. External PA currently
> > isn't on the list of things I give priority to because none of the
> > boards I've seen are using this feature. Please retry with the current
> > LEDE build, if that doesn't fix the issue, let me know.
> >
> > I'll fix external PA if you are willing to help testing on the device
> > you own and obviously I'd appreciate if you throw something into my
> > hat for that tedious work on a not-very-well designed wifi chip and
> > a driver which has grown beyond reasonable size...
> >
> > https://www.kickstarter.com/projects/1327597961/better-
> > support-for-mt7620a-n-in-openwrt-lede/
> >
> >
> > Cheers
> >
> >
> > Daniel
> >
> > On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
> > > Hi,
> > >
> > > Did this ever get resolved?
> > >
> > > I would like to help resolve it so please advise ASAP.
> > >
> > > Thanks,
> > > Sam
> >
> > > _______________________________________________
> > > openwrt-devel mailing list
> > > openwrt-devel at lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From scharania11 at gmail.com  Tue Feb  7 07:37:56 2017
From: scharania11 at gmail.com (Sam Charania)
Date: Tue, 7 Feb 2017 12:37:56 +0000
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <20170207112300.GC1704@makrotopia.org>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
 <20170205152412.GB2018@makrotopia.org>
 <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>
 <20170207112300.GC1704@makrotopia.org>
Message-ID: <CAMqDNcco42+=iDK0Rw3bABon=Yt1UzO5K7ZK3NUsP=92TA3KPQ@mail.gmail.com>

E1700 using
https://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/mt7620/lede-17.01.0-rc1-r3042-ec095b5-ramips-mt7620-e1700-squashfs-factory.bin

root at lede:~# cat /proc/cpuinfo
system type : MediaTek MT7620A ver:2 eco:6
machine : Linksys E1700
processor : 0
cpu model : MIPS 24KEc V5.0
BogoMIPS : 385.84
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available




root at lede:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00001000 "u-boot"
mtd1: 00010000 00001000 "config"
mtd2: 00010000 00001000 "factory"
mtd3: 007b0000 00001000 "firmware"
mtd4: 001281bd 00001000 "kernel"
mtd5: 00687e43 00001000 "rootfs"
mtd6: 00451000 00001000 "rootfs_data"

root at lede:~# free -m
             total       used       free     shared    buffers     cached
Mem:         61112      21536      39576        712       2200       7616
-/+ buffers/cache:      11720      49392
Swap:            0          0          0
root at lede:~#

Also note:

[image: Inline image 1]


On Tue, Feb 7, 2017 at 11:23 AM, Daniel Golle <daniel at makrotopia.org> wrote:

> Hi Toan,
>
> I received some more funding on the kickstarter campaign which will
> allow me to add support for the external PA and external LNA stuff
> which will bring our GPL'ed driver to the same level of hardware
> support of the vendor's driver.
> In order to do that it'd be great if you can provide some help:
> Please flash your router to OpenWrt or LEDE and enter a console via
> SSH. Then see which flash partition holds the wifi eeprom:
> cat /proc/mtd
> There is supposed to be a 'factory' partition, e.g. /dev/mtd2 or
> something like that. Dump that partition to /tmp
> dd if=/dev/mtd2 of=/tmp/factory.bin
> Then logout and copy that file to your workstation:
> scp root at 192.168.1.1:/tmp/factory.bin .
> (assuming the router has the IP 192.168.1.1)
> Then send that file (factory.bin) to me via email, so I can analyze
> it and see how we can auto-detect those features present on your
> device.
>
> I know this is some effort (flashing OpenWrt/LEDE and then reverting
> to the factory firmware, loosing your configuration on the way and all
> that) but I would be a great help and most likely improve the bad wifi
> signal situation on OpenWrt/LEDE within the next days.
>
>
> Cheers
>
>
> Daniel
>
>
> On Sun, Feb 05, 2017 at 02:19:10PM -0500, Toan Pham wrote:
> > Hi,
> >
> > I tested OpenWrt trunk version on the E1700 five months ago.  At that
> time,
> > openwrt (or the vendor) claimed that all of all ethernet ports are
> gibabit
> > ports (ref.  https://wiki.openwrt.org/toh/hwdata/linksys/linksys_e1700)
> > However, All four ports showed up as 100Mb, not Gbps ports, on Chaos
> Calmer
> > build.  Please let me know if you're experiencing the same thing, if so,
> > should we update Openwrt product spec webpage to reflect the actual link
> > speed?
> >
> > I also found wifi on the e1700 hardware unbearable.  That's why I had to
> > revert back to OEM firmware.
> >
> >
> >
> > TP
> >
> > On Sun, Feb 5, 2017 at 10:24 AM, Daniel Golle <daniel at makrotopia.org>
> wrote:
> >
> > > Hi Sam,
> > >
> > > If this didn't get any better with on recent LEDE builds after commit
> > > https://git.lede-project.org/?p=source.git;a=commit;h=
> > > b367eef21dccbc5115778001955847ac3af47db8
> > > it's most likely the issue is due to missing external PA init in the
> > > rt2x00 driver. I'm currently fixing the most of the obvious problems
> > > with rt2x00 on MT7620, but there are too many to get this done within
> > > a weekend and a kickstarter bounty of EUR 200. External PA currently
> > > isn't on the list of things I give priority to because none of the
> > > boards I've seen are using this feature. Please retry with the current
> > > LEDE build, if that doesn't fix the issue, let me know.
> > >
> > > I'll fix external PA if you are willing to help testing on the device
> > > you own and obviously I'd appreciate if you throw something into my
> > > hat for that tedious work on a not-very-well designed wifi chip and
> > > a driver which has grown beyond reasonable size...
> > >
> > > https://www.kickstarter.com/projects/1327597961/better-
> > > support-for-mt7620a-n-in-openwrt-lede/
> > >
> > >
> > > Cheers
> > >
> > >
> > > Daniel
> > >
> > > On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
> > > > Hi,
> > > >
> > > > Did this ever get resolved?
> > > >
> > > > I would like to help resolve it so please advise ASAP.
> > > >
> > > > Thanks,
> > > > Sam
> > >
> > > > _______________________________________________
> > > > openwrt-devel mailing list
> > > > openwrt-devel at lists.openwrt.org
> > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > > _______________________________________________
> > > openwrt-devel mailing list
> > > openwrt-devel at lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/a0d07e21/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 72875 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/a0d07e21/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: factory.bin
Type: application/octet-stream
Size: 65536 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/a0d07e21/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From lvqier at gmail.com  Tue Feb  7 08:22:57 2017
From: lvqier at gmail.com (Qier LU)
Date: Tue, 7 Feb 2017 21:22:57 +0800
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <CAMqDNcco42+=iDK0Rw3bABon=Yt1UzO5K7ZK3NUsP=92TA3KPQ@mail.gmail.com>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
 <20170205152412.GB2018@makrotopia.org>
 <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>
 <20170207112300.GC1704@makrotopia.org>
 <CAMqDNcco42+=iDK0Rw3bABon=Yt1UzO5K7ZK3NUsP=92TA3KPQ@mail.gmail.com>
Message-ID: <CAGocYBOh9xeSfE=Q8BgCrz+V9K1E0i9B3E4Z1z_SdK9ntdfttg@mail.gmail.com>

Hi Daniel,

Thank you for your support!

Here is Xiaomi mini using LEDE r2244

root at lede:~# cat /proc/cpuinfo
system type        : MediaTek MT7620A ver:2 eco:6
machine            : Xiaomi MiWiFi Mini
processor        : 0
cpu model        : MIPS 24KEc V5.0
BogoMIPS        : 385.84
wait instruction    : yes
microsecond timers    : yes
tlb_entries        : 32
extra interrupt vector    : yes
hardware watchpoint    : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
0x0ffb, 0x0ffb]
isa            : mips1 mips2 mips32r1 mips32r2
ASEs implemented    : mips16 dsp
shadow register sets    : 1
kscratch registers    : 0
package            : 0
core            : 0
VCED exceptions        : not available
VCEI exceptions        : not available

root at lede:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot-env"
mtd2: 00010000 00001000 "factory"
mtd3: 00f80000 00001000 "firmware"
mtd4: 0013f660 00001000 "kernel"
mtd5: 00e409a0 00001000 "rootfs"
mtd6: 00c46000 00001000 "rootfs_data"
mtd7: 00010000 00001000 "crash"
mtd8: 00010000 00001000 "reserved"
mtd9: 00010000 00001000 "Bdata"
root at lede:~# free
             total       used       free     shared    buffers     cached
Mem:        125744      34240      91504        680       1900      11196
-/+ buffers/cache:      21144     104600
Swap:            0          0          0

On Tue, Feb 7, 2017 at 8:37 PM, Sam Charania <scharania11 at gmail.com> wrote:

> E1700 using https://downloads.lede-project.org/releases/17.01.0-
> rc1/targets/ramips/mt7620/lede-17.01.0-rc1-r3042-
> ec095b5-ramips-mt7620-e1700-squashfs-factory.bin
>
> root at lede:~# cat /proc/cpuinfo
> system type : MediaTek MT7620A ver:2 eco:6
> machine : Linksys E1700
> processor : 0
> cpu model : MIPS 24KEc V5.0
> BogoMIPS : 385.84
> wait instruction : yes
> microsecond timers : yes
> tlb_entries : 32
> extra interrupt vector : yes
> hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
> 0x0ffb, 0x0ffb]
> isa : mips1 mips2 mips32r1 mips32r2
> ASEs implemented : mips16 dsp
> shadow register sets : 1
> kscratch registers : 0
> package : 0
> core : 0
> VCED exceptions : not available
> VCEI exceptions : not available
>
>
>
>
> root at lede:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00030000 00001000 "u-boot"
> mtd1: 00010000 00001000 "config"
> mtd2: 00010000 00001000 "factory"
> mtd3: 007b0000 00001000 "firmware"
> mtd4: 001281bd 00001000 "kernel"
> mtd5: 00687e43 00001000 "rootfs"
> mtd6: 00451000 00001000 "rootfs_data"
>
> root at lede:~# free -m
>              total       used       free     shared    buffers     cached
> Mem:         61112      21536      39576        712       2200       7616
> -/+ buffers/cache:      11720      49392
> Swap:            0          0          0
> root at lede:~#
>
> Also note:
>
> [image: Inline image 1]
>
>
> On Tue, Feb 7, 2017 at 11:23 AM, Daniel Golle <daniel at makrotopia.org>
> wrote:
>
>> Hi Toan,
>>
>> I received some more funding on the kickstarter campaign which will
>> allow me to add support for the external PA and external LNA stuff
>> which will bring our GPL'ed driver to the same level of hardware
>> support of the vendor's driver.
>> In order to do that it'd be great if you can provide some help:
>> Please flash your router to OpenWrt or LEDE and enter a console via
>> SSH. Then see which flash partition holds the wifi eeprom:
>> cat /proc/mtd
>> There is supposed to be a 'factory' partition, e.g. /dev/mtd2 or
>> something like that. Dump that partition to /tmp
>> dd if=/dev/mtd2 of=/tmp/factory.bin
>> Then logout and copy that file to your workstation:
>> scp root at 192.168.1.1:/tmp/factory.bin .
>> (assuming the router has the IP 192.168.1.1)
>> Then send that file (factory.bin) to me via email, so I can analyze
>> it and see how we can auto-detect those features present on your
>> device.
>>
>> I know this is some effort (flashing OpenWrt/LEDE and then reverting
>> to the factory firmware, loosing your configuration on the way and all
>> that) but I would be a great help and most likely improve the bad wifi
>> signal situation on OpenWrt/LEDE within the next days.
>>
>>
>> Cheers
>>
>>
>> Daniel
>>
>>
>> On Sun, Feb 05, 2017 at 02:19:10PM -0500, Toan Pham wrote:
>> > Hi,
>> >
>> > I tested OpenWrt trunk version on the E1700 five months ago.  At that
>> time,
>> > openwrt (or the vendor) claimed that all of all ethernet ports are
>> gibabit
>> > ports (ref.  https://wiki.openwrt.org/toh/hwdata/linksys/linksys_e1700)
>> > However, All four ports showed up as 100Mb, not Gbps ports, on Chaos
>> Calmer
>> > build.  Please let me know if you're experiencing the same thing, if so,
>> > should we update Openwrt product spec webpage to reflect the actual link
>> > speed?
>> >
>> > I also found wifi on the e1700 hardware unbearable.  That's why I had to
>> > revert back to OEM firmware.
>> >
>> >
>> >
>> > TP
>> >
>> > On Sun, Feb 5, 2017 at 10:24 AM, Daniel Golle <daniel at makrotopia.org>
>> wrote:
>> >
>> > > Hi Sam,
>> > >
>> > > If this didn't get any better with on recent LEDE builds after commit
>> > > https://git.lede-project.org/?p=source.git;a=commit;h=
>> > > b367eef21dccbc5115778001955847ac3af47db8
>> > > it's most likely the issue is due to missing external PA init in the
>> > > rt2x00 driver. I'm currently fixing the most of the obvious problems
>> > > with rt2x00 on MT7620, but there are too many to get this done within
>> > > a weekend and a kickstarter bounty of EUR 200. External PA currently
>> > > isn't on the list of things I give priority to because none of the
>> > > boards I've seen are using this feature. Please retry with the current
>> > > LEDE build, if that doesn't fix the issue, let me know.
>> > >
>> > > I'll fix external PA if you are willing to help testing on the device
>> > > you own and obviously I'd appreciate if you throw something into my
>> > > hat for that tedious work on a not-very-well designed wifi chip and
>> > > a driver which has grown beyond reasonable size...
>> > >
>> > > https://www.kickstarter.com/projects/1327597961/better-
>> > > support-for-mt7620a-n-in-openwrt-lede/
>> > >
>> > >
>> > > Cheers
>> > >
>> > >
>> > > Daniel
>> > >
>> > > On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
>> > > > Hi,
>> > > >
>> > > > Did this ever get resolved?
>> > > >
>> > > > I would like to help resolve it so please advise ASAP.
>> > > >
>> > > > Thanks,
>> > > > Sam
>> > >
>> > > > _______________________________________________
>> > > > openwrt-devel mailing list
>> > > > openwrt-devel at lists.openwrt.org
>> > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> > > _______________________________________________
>> > > openwrt-devel mailing list
>> > > openwrt-devel at lists.openwrt.org
>> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> > >
>>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>


-- 
????????????
?????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/03532953/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 72875 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/03532953/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: factory.bin
Type: application/octet-stream
Size: 65536 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/03532953/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Tue Feb  7 08:56:09 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Tue, 7 Feb 2017 14:56:09 +0100
Subject: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi
 signal E1700 (MT7620A)
In-Reply-To: <CAGocYBOh9xeSfE=Q8BgCrz+V9K1E0i9B3E4Z1z_SdK9ntdfttg@mail.gmail.com>
References: <CAMqDNceCSVyei5BWRDu6VWu31Sf8QwgoY2SUgVwOFQwtScdHxA@mail.gmail.com>
 <20170205152412.GB2018@makrotopia.org>
 <CAGNmLEMnKOG5AjxZKs6PWFCKewqGfRSfNWYJDmng5UCWZ6bSSw@mail.gmail.com>
 <20170207112300.GC1704@makrotopia.org>
 <CAMqDNcco42+=iDK0Rw3bABon=Yt1UzO5K7ZK3NUsP=92TA3KPQ@mail.gmail.com>
 <CAGocYBOh9xeSfE=Q8BgCrz+V9K1E0i9B3E4Z1z_SdK9ntdfttg@mail.gmail.com>
Message-ID: <CAKR_QVL_PBhkSs0+C1hJ01FACGOaHexB-3efY+ApANd0Yoh6-w@mail.gmail.com>

Hi

Can anyone get a reference driver for MT7612E ?

On 7 February 2017 at 14:22, Qier LU <lvqier at gmail.com> wrote:

> Hi Daniel,
>
> Thank you for your support!
>
> Here is Xiaomi mini using LEDE r2244
>
> root at lede:~# cat /proc/cpuinfo
> system type        : MediaTek MT7620A ver:2 eco:6
> machine            : Xiaomi MiWiFi Mini
> processor        : 0
> cpu model        : MIPS 24KEc V5.0
> BogoMIPS        : 385.84
> wait instruction    : yes
> microsecond timers    : yes
> tlb_entries        : 32
> extra interrupt vector    : yes
> hardware watchpoint    : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
> 0x0ffb, 0x0ffb]
> isa            : mips1 mips2 mips32r1 mips32r2
> ASEs implemented    : mips16 dsp
> shadow register sets    : 1
> kscratch registers    : 0
> package            : 0
> core            : 0
> VCED exceptions        : not available
> VCEI exceptions        : not available
>
> root at lede:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00030000 00001000 "u-boot"
> mtd1: 00010000 00001000 "u-boot-env"
> mtd2: 00010000 00001000 "factory"
> mtd3: 00f80000 00001000 "firmware"
> mtd4: 0013f660 00001000 "kernel"
> mtd5: 00e409a0 00001000 "rootfs"
> mtd6: 00c46000 00001000 "rootfs_data"
> mtd7: 00010000 00001000 "crash"
> mtd8: 00010000 00001000 "reserved"
> mtd9: 00010000 00001000 "Bdata"
> root at lede:~# free
>              total       used       free     shared    buffers     cached
> Mem:        125744      34240      91504        680       1900      11196
> -/+ buffers/cache:      21144     104600
> Swap:            0          0          0
>
> On Tue, Feb 7, 2017 at 8:37 PM, Sam Charania <scharania11 at gmail.com>
> wrote:
>
>> E1700 using https://downloads.lede-project.org/releases/17.01.0-rc1/
>> targets/ramips/mt7620/lede-17.01.0-rc1-r3042-ec095b5-ramips-
>> mt7620-e1700-squashfs-factory.bin
>>
>> root at lede:~# cat /proc/cpuinfo
>> system type : MediaTek MT7620A ver:2 eco:6
>> machine : Linksys E1700
>> processor : 0
>> cpu model : MIPS 24KEc V5.0
>> BogoMIPS : 385.84
>> wait instruction : yes
>> microsecond timers : yes
>> tlb_entries : 32
>> extra interrupt vector : yes
>> hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
>> 0x0ffb, 0x0ffb]
>> isa : mips1 mips2 mips32r1 mips32r2
>> ASEs implemented : mips16 dsp
>> shadow register sets : 1
>> kscratch registers : 0
>> package : 0
>> core : 0
>> VCED exceptions : not available
>> VCEI exceptions : not available
>>
>>
>>
>>
>> root at lede:~# cat /proc/mtd
>> dev:    size   erasesize  name
>> mtd0: 00030000 00001000 "u-boot"
>> mtd1: 00010000 00001000 "config"
>> mtd2: 00010000 00001000 "factory"
>> mtd3: 007b0000 00001000 "firmware"
>> mtd4: 001281bd 00001000 "kernel"
>> mtd5: 00687e43 00001000 "rootfs"
>> mtd6: 00451000 00001000 "rootfs_data"
>>
>> root at lede:~# free -m
>>              total       used       free     shared    buffers     cached
>> Mem:         61112      21536      39576        712       2200       7616
>> -/+ buffers/cache:      11720      49392
>> Swap:            0          0          0
>> root at lede:~#
>>
>> Also note:
>>
>> [image: Inline image 1]
>>
>>
>> On Tue, Feb 7, 2017 at 11:23 AM, Daniel Golle <daniel at makrotopia.org>
>> wrote:
>>
>>> Hi Toan,
>>>
>>> I received some more funding on the kickstarter campaign which will
>>> allow me to add support for the external PA and external LNA stuff
>>> which will bring our GPL'ed driver to the same level of hardware
>>> support of the vendor's driver.
>>> In order to do that it'd be great if you can provide some help:
>>> Please flash your router to OpenWrt or LEDE and enter a console via
>>> SSH. Then see which flash partition holds the wifi eeprom:
>>> cat /proc/mtd
>>> There is supposed to be a 'factory' partition, e.g. /dev/mtd2 or
>>> something like that. Dump that partition to /tmp
>>> dd if=/dev/mtd2 of=/tmp/factory.bin
>>> Then logout and copy that file to your workstation:
>>> scp root at 192.168.1.1:/tmp/factory.bin .
>>> (assuming the router has the IP 192.168.1.1)
>>> Then send that file (factory.bin) to me via email, so I can analyze
>>> it and see how we can auto-detect those features present on your
>>> device.
>>>
>>> I know this is some effort (flashing OpenWrt/LEDE and then reverting
>>> to the factory firmware, loosing your configuration on the way and all
>>> that) but I would be a great help and most likely improve the bad wifi
>>> signal situation on OpenWrt/LEDE within the next days.
>>>
>>>
>>> Cheers
>>>
>>>
>>> Daniel
>>>
>>>
>>> On Sun, Feb 05, 2017 at 02:19:10PM -0500, Toan Pham wrote:
>>> > Hi,
>>> >
>>> > I tested OpenWrt trunk version on the E1700 five months ago.  At that
>>> time,
>>> > openwrt (or the vendor) claimed that all of all ethernet ports are
>>> gibabit
>>> > ports (ref.  https://wiki.openwrt.org/toh/hwdata/linksys/linksys_e1700
>>> )
>>> > However, All four ports showed up as 100Mb, not Gbps ports, on Chaos
>>> Calmer
>>> > build.  Please let me know if you're experiencing the same thing, if
>>> so,
>>> > should we update Openwrt product spec webpage to reflect the actual
>>> link
>>> > speed?
>>> >
>>> > I also found wifi on the e1700 hardware unbearable.  That's why I had
>>> to
>>> > revert back to OEM firmware.
>>> >
>>> >
>>> >
>>> > TP
>>> >
>>> > On Sun, Feb 5, 2017 at 10:24 AM, Daniel Golle <daniel at makrotopia.org>
>>> wrote:
>>> >
>>> > > Hi Sam,
>>> > >
>>> > > If this didn't get any better with on recent LEDE builds after commit
>>> > > https://git.lede-project.org/?p=source.git;a=commit;h=
>>> > > b367eef21dccbc5115778001955847ac3af47db8
>>> > > it's most likely the issue is due to missing external PA init in the
>>> > > rt2x00 driver. I'm currently fixing the most of the obvious problems
>>> > > with rt2x00 on MT7620, but there are too many to get this done within
>>> > > a weekend and a kickstarter bounty of EUR 200. External PA currently
>>> > > isn't on the list of things I give priority to because none of the
>>> > > boards I've seen are using this feature. Please retry with the
>>> current
>>> > > LEDE build, if that doesn't fix the issue, let me know.
>>> > >
>>> > > I'll fix external PA if you are willing to help testing on the device
>>> > > you own and obviously I'd appreciate if you throw something into my
>>> > > hat for that tedious work on a not-very-well designed wifi chip and
>>> > > a driver which has grown beyond reasonable size...
>>> > >
>>> > > https://www.kickstarter.com/projects/1327597961/better-
>>> > > support-for-mt7620a-n-in-openwrt-lede/
>>> > >
>>> > >
>>> > > Cheers
>>> > >
>>> > >
>>> > > Daniel
>>> > >
>>> > > On Sun, Feb 05, 2017 at 03:07:02PM +0000, Sam Charania wrote:
>>> > > > Hi,
>>> > > >
>>> > > > Did this ever get resolved?
>>> > > >
>>> > > > I would like to help resolve it so please advise ASAP.
>>> > > >
>>> > > > Thanks,
>>> > > > Sam
>>> > >
>>> > > > _______________________________________________
>>> > > > openwrt-devel mailing list
>>> > > > openwrt-devel at lists.openwrt.org
>>> > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> > > _______________________________________________
>>> > > openwrt-devel mailing list
>>> > > openwrt-devel at lists.openwrt.org
>>> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> > >
>>>
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
>
>
> --
> ????????????
> ?????????????????
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/88cff59a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 72875 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/88cff59a/attachment.png>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Tue Feb  7 11:21:22 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Tue, 7 Feb 2017 21:51:22 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
Message-ID: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>

Hello OpenWRT team,

I wish to bundle dnscrypt-proxy package using latest snapshot
Image-builder. I get below errors. Please recommend a fix or address it in
snapshot.

Collected errors:
 * opkg_install_cmd: Cannot install package dnscrypt-proxy.
Makefile:146: recipe for target 'package_install' failed

Regards,
Mangesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/47f91eae/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Tue Feb  7 11:53:18 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Tue, 07 Feb 2017 16:53:18 +0000
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
Message-ID: <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>

Do you have a Package/dnscrypt-proxy/install rule ?
Are you calling the BuildPackage rule ?

Do you have Package/dnscrypt-proxy/description rule ?

And check for typos if above stuff is checked.

Thanks
Alex


On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com> wrote:

> Hello OpenWRT team,
>
> I wish to bundle dnscrypt-proxy package using latest snapshot
> Image-builder. I get below errors. Please recommend a fix or address it in
> snapshot.
>
> Collected errors:
>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
> Makefile:146: recipe for target 'package_install' failed
>
> Regards,
> Mangesh
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/bc88b233/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Tue Feb  7 12:02:07 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Tue, 7 Feb 2017 22:32:07 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
Message-ID: <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>

Hi Alex,

Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported in
CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
include while building with CC Image-builder.

I scanned through all snapshot image-builder and no reference there. I run
following command to build - same works fine for CC 15.05.1

make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files

Surely no typo there.

Regards,
Mangesh


On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean <ardeleanalex at gmail.com>
wrote:

> Do you have a Package/dnscrypt-proxy/install rule ?
> Are you calling the BuildPackage rule ?
>
> Do you have Package/dnscrypt-proxy/description rule ?
>
> And check for typos if above stuff is checked.
>
> Thanks
> Alex
>
>
> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
> wrote:
>
>> Hello OpenWRT team,
>>
>> I wish to bundle dnscrypt-proxy package using latest snapshot
>> Image-builder. I get below errors. Please recommend a fix or address it in
>> snapshot.
>>
>> Collected errors:
>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
>> Makefile:146: recipe for target 'package_install' failed
>>
>> Regards,
>> Mangesh
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170207/d6fe6268/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Tue Feb  7 16:48:12 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue,  7 Feb 2017 22:48:12 +0100
Subject: [OpenWrt-Devel] [PATCH 12/22 v3] ARM: dts: add top-level DT
	bindings for Cortina Gemini
Message-ID: <20170207214812.27365-1-linus.walleij@linaro.org>

This adds the top level SoC bindings for Cortina systems Gemini
platforms.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Fix soc bus node and references.
- Fix spelling of interrupt-controller
ChangeLog v1->v2:
- Rename required property "intcon" to "interrupt-controller"
- Elaborate a bit on the SoC origins
- Put the example DTS SoC nodes in a soc {} node
---
 Documentation/devicetree/bindings/arm/gemini.txt | 84 ++++++++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/gemini.txt

diff --git a/Documentation/devicetree/bindings/arm/gemini.txt b/Documentation/devicetree/bindings/arm/gemini.txt
new file mode 100644
index 000000000000..c3e8430202ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gemini.txt
@@ -0,0 +1,84 @@
+Cortina systems Gemini platforms
+
+The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally
+produced by Storlink Semiconductor around 2005. The company was renamed
+later renamed Storm Semiconductor. The chip product name is Storlink SL3516.
+It was derived from earlier products from Storm named SL3316 (Centroid) and
+SL3512.
+
+Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was
+produced and used for NAS and similar usecases. In 2014 Cortina Systems was
+in turn acquired by Inphi, who seem to have discontinued this product family.
+
+Required properties (in root node):
+	compatible = "cortina,gemini";
+
+Required nodes:
+
+- soc: the SoC should be represented by a simple bus encompassing all the
+  onchip devices, this is referred to as the soc bus node.
+
+- syscon: the soc bus node must have a system controller node pointing to the
+  global control registers, with the compatible string
+  "cortina,gemini-syscon", "syscon";
+
+- timer: the soc bus node must have a timer node pointing to the SoC timer
+  block, with the compatible string "cortina,gemini-timer"
+  See: clocksource/cortina,gemini-timer.txt
+
+- interrupt-controller: the sob bus node must have an interrupt controller
+  node pointing to the SoC interrupt controller block, with the compatible
+  string "cortina,gemini-interrupt-controller"
+  See interrupt-controller/cortina,gemini-interrupt-controller.txt
+
+Example:
+
+/ {
+	model = "Foo Gemini Machine";
+	compatible = "cortina,gemini";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x8000000>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		compatible = "simple-bus";
+		interrupt-parent = <&intcon>;
+
+		syscon: syscon at 40000000 {
+			compatible = "cortina,gemini-syscon", "syscon";
+			reg = <0x40000000 0x1000>;
+		};
+
+		uart0: serial at 42000000 {
+			compatible = "ns16550a";
+			reg = <0x42000000 0x100>;
+			clock-frequency = <48000000>;
+			interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+		};
+
+		timer at 43000000 {
+			compatible = "cortina,gemini-timer";
+			reg = <0x43000000 0x1000>;
+			interrupt-parent = <&intcon>;
+			interrupts = <14 IRQ_TYPE_EDGE_RISING>, /* Timer 1 */
+				     <15 IRQ_TYPE_EDGE_RISING>, /* Timer 2 */
+				     <16 IRQ_TYPE_EDGE_RISING>; /* Timer 3 */
+			syscon = <&syscon>;
+		};
+
+		intcon: interrupt-controller at 48000000 {
+			compatible = "cortina,gemini-interrupt-controller";
+			reg = <0x48000000 0x1000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Tue Feb  7 16:52:05 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 7 Feb 2017 22:52:05 +0100
Subject: [OpenWrt-Devel] [PATCH 14/22] ARM: dts: add a devicetree for
	Raidsonic NAS IB-4220-B
In-Reply-To: <alpine.LNX.2.00.1702051051090.26313@T420s>
References: <20170122122254.10764-1-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051051090.26313@T420s>
Message-ID: <CACRpkdb2YUSAD1eR8c11BsCb3yBmMJ7C_bEKkpgkiqX9B4GNwQ@mail.gmail.com>

On Sun, Feb 5, 2017 at 10:53 AM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:

> Hi Linus,
>
> please add right baudrate and partition scheme for NAS 4220
>
> Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>

Thanks Hans! I folded this into the NAS 4220 device tree
and added your Signed-off-by to the patch.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Wed Feb  8 07:55:17 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Wed, 8 Feb 2017 13:55:17 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 14/22] ARM: dts: add a devicetree for
 Raidsonic NAS IB-4220-B
In-Reply-To: <CACRpkdb2YUSAD1eR8c11BsCb3yBmMJ7C_bEKkpgkiqX9B4GNwQ@mail.gmail.com>
References: <20170122122254.10764-1-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051051090.26313@T420s>
 <CACRpkdb2YUSAD1eR8c11BsCb3yBmMJ7C_bEKkpgkiqX9B4GNwQ@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1702081353480.8463@T420s>

HI Linus

On Tue, 7 Feb 2017, Linus Walleij wrote:

> On Sun, Feb 5, 2017 at 10:53 AM, Hans Ulli Kroll
> <ulli.kroll at googlemail.com> wrote:
> 
> > Hi Linus,
> >
> > please add right baudrate and partition scheme for NAS 4220
> >
> > Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>
> 
> Thanks Hans! I folded this into the NAS 4220 device tree
> and added your Signed-off-by to the patch.
> 

You can remove the PCI entries I've seen on your git tree.
NAS 4220 has no PCI interface

Greetings
Hans Ulli Kroll
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Wed Feb  8 08:13:22 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Wed, 8 Feb 2017 14:13:22 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT
 and multiplatform
In-Reply-To: <20170122121506.9995-1-linus.walleij@linaro.org>
References: <20170122121506.9995-1-linus.walleij@linaro.org>
Message-ID: <alpine.LNX.2.00.1702081401080.8463@T420s>

Hi Linus

On Sun, 22 Jan 2017, Linus Walleij wrote:

> I got a Gemini platform from Florian Fainelli over at OpenWRT
> some time back. I finally got around to "future-proofing" the
> platform, which was the idea when he paintakingly sent the box
> over to me.
> 

now I've got my toolchain cleaned up and working ...
Tested on may nas 4220
  
here my
Acked-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>

> - FOT2G USB EHCI host

The fotg2 driver is already upstream.
I've added DT support and this driver works.
The only problem here is dis/reconnect of usb devices, but I think this 
is some driver problem here.

I must clean up my DT support patches to send them of.

Greetings
Hans Ulli Kroll
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Wed Feb  8 09:44:00 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Wed, 8 Feb 2017 15:44:00 +0100
Subject: [OpenWrt-Devel] procd: service instance restart does not wait for
 old process to be closed before lanching the new one
Message-ID: <CAF1oqRBUuYj4V-MOimcKpXOa=fbyn-21-dqEtWVimrEzUiXFcQ@mail.gmail.com>

Hi John,

One of the daemons I use takes sometime a couple of seconds to close
after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
restart" there will be 2 instances of that service running in parallel
until the initial instance will finally manage to handle the SIGTERM
signal. This daemon registers its own ubus object, but new instance
will fail to register its object due to name conflict with an object
that is already existing.

The root cause of this defect is the way procd restarts a service by
issuing a service_stop followed immediately by a service_start:
  1) service_stop call translates to
    - instance_stop() ->  send SIGTERM signal to the old instance
    - instance_free() -> call uloop_process_delete(), which means
in->proc.pending will be set to 0
  2) sevice_start will launch the new instance becaise previous
process has been already deleted

Shouldn't uloop_process_delete() be called only when process was
closed, as it is the case in uloop.c? If so, instance_start() should
at least set restart to 1 when (in->proc.pending && in->halt).

And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM?

BR,
Alin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Wed Feb  8 09:55:29 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Wed, 8 Feb 2017 15:55:29 +0100
Subject: [OpenWrt-Devel] procd: service instance restart does not wait
 for old process to be closed before lanching the new one
In-Reply-To: <CAF1oqRBUuYj4V-MOimcKpXOa=fbyn-21-dqEtWVimrEzUiXFcQ@mail.gmail.com>
References: <CAF1oqRBUuYj4V-MOimcKpXOa=fbyn-21-dqEtWVimrEzUiXFcQ@mail.gmail.com>
Message-ID: <CAF1oqRDgPzOvijLsVcp3fWV5aNBX0GsQ_xb1LL0j_Grdw30RuQ@mail.gmail.com>

Hi John,

One of the daemons I use takes sometime a couple of seconds to close
after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
restart" there will be 2 instances of that service running in parallel
until the initial instance will finally manage to handle the SIGTERM
signal. This daemon registers its own ubus object, but new instance
will fail to register its object due to name conflict with an object
that is already existing.

The root cause of this defect is the way procd restarts a service by
issuing a service_stop followed immediately by a service_start:
  1) service_stop call translates to
    - instance_stop() ->  send SIGTERM signal to the old instance
    - instance_free() -> call uloop_process_delete(), which means
in->proc.pending will be set to 0
  2) sevice_start will launch the new instance becaise previous
process has been already deleted

Shouldn't uloop_process_delete() be called only when process was
closed, as it is the case in uloop.c? If so, instance_start() should
at least set restart to 1 when (in->proc.pending && in->halt).

And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM?

BR,
Alin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From codemarauder at gmail.com  Wed Feb  8 10:03:37 2017
From: codemarauder at gmail.com (Nishant Sharma)
Date: Wed, 08 Feb 2017 20:33:37 +0530
Subject: [OpenWrt-Devel] procd: service instance restart does not wait
	for old process to be closed before lanching the new one
In-Reply-To: <CAF1oqRDgPzOvijLsVcp3fWV5aNBX0GsQ_xb1LL0j_Grdw30RuQ@mail.gmail.com>
References: <CAF1oqRBUuYj4V-MOimcKpXOa=fbyn-21-dqEtWVimrEzUiXFcQ@mail.gmail.com>
 <CAF1oqRDgPzOvijLsVcp3fWV5aNBX0GsQ_xb1LL0j_Grdw30RuQ@mail.gmail.com>
Message-ID: <3E5504C0-2D51-4044-B940-D5159930D7D7@gmail.com>



On 8 February 2017 8:25:29 PM IST, "Alin N?stac" <
>And isn't a bit too optimistic to assume all daemons will be stopped by
>SIGTERM?

Case in point a squid running on PCEngines APU. Even if I configure it to force close connections within 2-3 seconds, it still at times takes more time.

Regards,
Nishant
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Wed Feb  8 10:21:55 2017
From: john at phrozen.org (John Crispin)
Date: Wed, 8 Feb 2017 16:21:55 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] procd: service instance restart does
 not wait for old process to be closed before lanching the new one
In-Reply-To: <CAF1oqRDgPzOvijLsVcp3fWV5aNBX0GsQ_xb1LL0j_Grdw30RuQ@mail.gmail.com>
References: <CAF1oqRBUuYj4V-MOimcKpXOa=fbyn-21-dqEtWVimrEzUiXFcQ@mail.gmail.com>
 <CAF1oqRDgPzOvijLsVcp3fWV5aNBX0GsQ_xb1LL0j_Grdw30RuQ@mail.gmail.com>
Message-ID: <5ce59a01-f87f-3ffa-1cad-7813e94d9bdc@phrozen.org>



On 08/02/2017 15:55, Alin N?stac wrote:
> Hi John,
> 
> One of the daemons I use takes sometime a couple of seconds to close
> after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon
> restart" there will be 2 instances of that service running in parallel
> until the initial instance will finally manage to handle the SIGTERM
> signal. This daemon registers its own ubus object, but new instance
> will fail to register its object due to name conflict with an object
> that is already existing.
> 
> The root cause of this defect is the way procd restarts a service by
> issuing a service_stop followed immediately by a service_start:
>   1) service_stop call translates to
>     - instance_stop() ->  send SIGTERM signal to the old instance
>     - instance_free() -> call uloop_process_delete(), which means
> in->proc.pending will be set to 0
>   2) sevice_start will launch the new instance becaise previous
> process has been already deleted
> 
> Shouldn't uloop_process_delete() be called only when process was
> closed, as it is the case in uloop.c? If so, instance_start() should
> at least set restart to 1 when (in->proc.pending && in->halt).
> 
> And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM?

Hi,

probably, feel free to send a patch to fix the issue. we can help test it.

	John


> BR,
> Alin
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From vincent.wiemann at ironai.com  Wed Feb  8 16:29:08 2017
From: vincent.wiemann at ironai.com (Vincent Wiemann)
Date: Wed, 8 Feb 2017 22:29:08 +0100
Subject: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units
In-Reply-To: <96e88182-911e-7f38-2b34-6abae133d150@gmx.de>
References: <12eddfe1-af22-f2f4-3f6b-cdf5f48dc170@openwrt.org>
 <9f9b5319-8be6-cf74-1904-bd358e3bd9fd@gmx.de>
 <96e88182-911e-7f38-2b34-6abae133d150@gmx.de>
Message-ID: <284a80e2-3535-ba54-3e2c-645dc91761fd@ironai.com>

Hi everyone,

has anyone received one of the units, yet?
I wonder how long it takes as my experience with TP-Link (who don't
really care about free software :D) is that they send their units with
UPS Express and it never took more than a week...

On 17.01.2017 20:06, Hartmut Knaack wrote:
> 
> OK, to answer my question: today we received an email from Belkin/Linksys,
> asking for a shipping address.
> 

Kind regards,
CodeFetch
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From knaack.h at gmx.de  Wed Feb  8 18:04:56 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Thu, 9 Feb 2017 00:04:56 +0100
Subject: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units
In-Reply-To: <284a80e2-3535-ba54-3e2c-645dc91761fd@ironai.com>
References: <12eddfe1-af22-f2f4-3f6b-cdf5f48dc170@openwrt.org>
 <9f9b5319-8be6-cf74-1904-bd358e3bd9fd@gmx.de>
 <96e88182-911e-7f38-2b34-6abae133d150@gmx.de>
 <284a80e2-3535-ba54-3e2c-645dc91761fd@ironai.com>
Message-ID: <46aa89ce-408a-30bc-ab2d-680e8c1d95f1@gmx.de>

Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> Hi everyone,
> 
> has anyone received one of the units, yet?

According to the forum, two guys from Canada, one guy from Australia and
one guy from the UK already got their devices (all 5-eyes countries ;-).

> I wonder how long it takes as my experience with TP-Link (who don't
> really care about free software :D) is that they send their units with
> UPS Express and it never took more than a week...
> 
> On 17.01.2017 20:06, Hartmut Knaack wrote:
>>
>> OK, to answer my question: today we received an email from Belkin/Linksys,
>> asking for a shipping address.
>>
> 
> Kind regards,
> CodeFetch
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From joel at aenertia.net  Wed Feb  8 18:26:05 2017
From: joel at aenertia.net (=?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?=)
Date: Thu, 9 Feb 2017 12:26:05 +1300
Subject: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units
In-Reply-To: <46aa89ce-408a-30bc-ab2d-680e8c1d95f1@gmx.de>
References: <12eddfe1-af22-f2f4-3f6b-cdf5f48dc170@openwrt.org>
 <9f9b5319-8be6-cf74-1904-bd358e3bd9fd@gmx.de>
 <96e88182-911e-7f38-2b34-6abae133d150@gmx.de>
 <284a80e2-3535-ba54-3e2c-645dc91761fd@ironai.com>
 <46aa89ce-408a-30bc-ab2d-680e8c1d95f1@gmx.de>
Message-ID: <CAKiAkGQy-zpWjzjvVAsT7Ea=QcA8TV6EwA_DgpYga8t-iMBLeg@mail.gmail.com>

I am in New Zealand, (also 5 eyes ;) and have not received one.

On 9 February 2017 at 12:04, Hartmut Knaack <knaack.h at gmx.de> wrote:

> Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> > Hi everyone,
> >
> > has anyone received one of the units, yet?
>
> According to the forum, two guys from Canada, one guy from Australia and
> one guy from the UK already got their devices (all 5-eyes countries ;-).
>
> > I wonder how long it takes as my experience with TP-Link (who don't
> > really care about free software :D) is that they send their units with
> > UPS Express and it never took more than a week...
> >
> > On 17.01.2017 20:06, Hartmut Knaack wrote:
> >>
> >> OK, to answer my question: today we received an email from
> Belkin/Linksys,
> >> asking for a shipping address.
> >>
> >
> > Kind regards,
> > CodeFetch
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170209/728dc779/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Thu Feb  9 05:02:53 2017
From: alin.nastac at gmail.com (Alin Nastac)
Date: Thu,  9 Feb 2017 11:02:53 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: stop service using SIGKILL if
	SIGTERM failed to do so
Message-ID: <1486634573-12258-1-git-send-email-alin.nastac@gmail.com>

SIGKILL is sent if instance process is still running after
<term_timeout> seconds after SIGTERM has been sent. To prevent
another daemon process being launched before old process dies,
the instance is kept until SIGCHLD confirms that service has
been stopped.

Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
---
 service/instance.c | 44 +++++++++++++++++++++++++++++++++++++-------
 service/instance.h |  1 +
 service/service.c  | 26 ++++++++++++++++----------
 service/service.h  |  3 +++
 4 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/service/instance.c b/service/instance.c
index 018db3c..4d340fd 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -55,6 +55,7 @@ enum {
 	INSTANCE_ATTR_SECCOMP,
 	INSTANCE_ATTR_PIDFILE,
 	INSTANCE_ATTR_RELOADSIG,
+	INSTANCE_ATTR_TERMTIMEOUT,
 	__INSTANCE_ATTR_MAX
 };
 
@@ -79,6 +80,7 @@ static const struct blobmsg_policy instance_attr[__INSTANCE_ATTR_MAX] = {
 	[INSTANCE_ATTR_SECCOMP] = { "seccomp", BLOBMSG_TYPE_STRING },
 	[INSTANCE_ATTR_PIDFILE] = { "pidfile", BLOBMSG_TYPE_STRING },
 	[INSTANCE_ATTR_RELOADSIG] = { "reload_signal", BLOBMSG_TYPE_INT32 },
+	[INSTANCE_ATTR_TERMTIMEOUT] = { "term_timeout", BLOBMSG_TYPE_INT32 },
 };
 
 enum {
@@ -389,8 +391,16 @@ instance_start(struct service_instance *in)
 		return;
 	}
 
-	if (in->proc.pending || !in->command)
+	if (!in->command) {
+		LOG("Not starting instance %s::%s, command not set\n", in->srv->name, in->name);
 		return;
+	}
+
+	if (in->proc.pending) {
+		if (in->halt)
+			in->restart = true;
+		return;
+	}
 
 	instance_free_stdio(in);
 	if (in->_stdout.fd.fd > -2) {
@@ -408,7 +418,7 @@ instance_start(struct service_instance *in)
 	}
 
 	in->restart = false;
-	in->halt = !in->respawn;
+	in->halt = false;
 
 	if (!in->valid)
 		return;
@@ -494,7 +504,11 @@ instance_timeout(struct uloop_timeout *t)
 
 	in = container_of(t, struct service_instance, timeout);
 
-	if (!in->halt && (in->restart || in->respawn))
+	if (in->halt) {
+		LOG("Instance %s::%s pid %d not stopped on SIGTERM, sending SIGKILL instead\n",
+				in->srv->name, in->name, in->proc.pid);
+		kill(in->proc.pid, SIGKILL);
+	} else if (in->restart || in->respawn)
 		instance_start(in);
 }
 
@@ -515,8 +529,19 @@ instance_exit(struct uloop_process *p, int ret)
 		return;
 
 	uloop_timeout_cancel(&in->timeout);
+	service_event("instance.stop", in->srv->name, in->name);
+
 	if (in->halt) {
 		instance_removepid(in);
+		if (in->restart)
+			instance_start(in);
+		else {
+			struct service *s = in->srv;
+
+			avl_delete(&s->instances.avl, &in->node.avl);
+			instance_free(in);
+			service_stopped(s);
+		}
 	} else if (in->restart) {
 		instance_start(in);
 	} else if (in->respawn) {
@@ -535,7 +560,6 @@ instance_exit(struct uloop_process *p, int ret)
 			uloop_timeout_set(&in->timeout, in->respawn_timeout * 1000);
 		}
 	}
-	service_event("instance.stop", in->srv->name, in->name);
 }
 
 void
@@ -546,6 +570,7 @@ instance_stop(struct service_instance *in)
 	in->halt = true;
 	in->restart = in->respawn = false;
 	kill(in->proc.pid, SIGTERM);
+	uloop_timeout_set(&in->timeout, in->term_timeout * 1000);
 }
 
 static void
@@ -559,10 +584,10 @@ instance_restart(struct service_instance *in)
 		return;
 	}
 
-	in->halt = false;
+	in->halt = true;
 	in->restart = true;
 	kill(in->proc.pid, SIGTERM);
-	instance_removepid(in);
+	uloop_timeout_set(&in->timeout, in->term_timeout * 1000);
 }
 
 static bool
@@ -796,6 +821,8 @@ instance_config_parse(struct service_instance *in)
 	if (!instance_config_parse_command(in, tb))
 		return false;
 
+	if (tb[INSTANCE_ATTR_TERMTIMEOUT])
+		in->term_timeout = blobmsg_get_u32(tb[INSTANCE_ATTR_TERMTIMEOUT]);
 	if (tb[INSTANCE_ATTR_RESPAWN]) {
 		int i = 0;
 		uint32_t vals[3] = { 3600, 5, 5};
@@ -933,8 +960,9 @@ instance_update(struct service_instance *in, struct service_instance *in_new)
 {
 	bool changed = instance_config_changed(in, in_new);
 	bool running = in->proc.pending;
+	bool stopping = in->halt;
 
-	if (!running) {
+	if (!running || stopping) {
 		instance_config_move(in, in_new);
 		instance_start(in);
 	} else {
@@ -967,6 +995,7 @@ instance_init(struct service_instance *in, struct service *s, struct blob_attr *
 	in->config = config;
 	in->timeout.cb = instance_timeout;
 	in->proc.cb = instance_exit;
+	in->term_timeout = 5;
 
 	in->_stdout.fd.fd = -2;
 	in->_stdout.stream.string_data = true;
@@ -999,6 +1028,7 @@ void instance_dump(struct blob_buf *b, struct service_instance *in, int verbose)
 		blobmsg_add_u32(b, "pid", in->proc.pid);
 	if (in->command)
 		blobmsg_add_blob(b, in->command);
+	blobmsg_add_u32(b, "term_timeout", in->term_timeout);
 
 	if (!avl_is_empty(&in->errors.avl)) {
 		struct blobmsg_list_node *var;
diff --git a/service/instance.h b/service/instance.h
index 3cc2009..78999c8 100644
--- a/service/instance.h
+++ b/service/instance.h
@@ -59,6 +59,7 @@ struct service_instance {
 	char *seccomp;
 	char *pidfile;
 
+	uint32_t term_timeout;
 	uint32_t respawn_timeout;
 	uint32_t respawn_threshold;
 	uint32_t respawn_retry;
diff --git a/service/service.c b/service/service.c
index 2c73901..0584ee0 100644
--- a/service/service.c
+++ b/service/service.c
@@ -59,11 +59,10 @@ service_instance_update(struct vlist_tree *tree, struct vlist_node *node_new,
 		instance_update(in_o, in_n);
 		instance_free(in_n);
 	} else if (in_o) {
-		DEBUG(2, "Free instance %s::%s\n", in_o->srv->name, in_o->name);
+		DEBUG(2, "Stop instance %s::%s\n", in_o->srv->name, in_o->name);
 		instance_stop(in_o);
-		instance_free(in_o);
 	} else if (in_n) {
-		DEBUG(2, "Create instance %s::%s\n", in_n->srv->name, in_n->name);
+		DEBUG(2, "Start instance %s::%s\n", in_n->srv->name, in_n->name);
 		instance_start(in_n);
 	}
 	blob_buf_init(&b, 0);
@@ -80,7 +79,7 @@ service_alloc(const char *name)
 	strcpy(new_name, name);
 
 	vlist_init(&s->instances, avl_strcmp, service_instance_update);
-	s->instances.keep_old = true;
+	s->instances.no_delete = true;
 	s->name = new_name;
 	s->avl.key = s->name;
 	INIT_LIST_HEAD(&s->validators);
@@ -149,13 +148,8 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
 static void
 service_delete(struct service *s)
 {
-	service_event("service.stop", s->name, NULL);
 	vlist_flush_all(&s->instances);
-	avl_delete(&services, &s->avl);
-	trigger_del(s);
-	free(s->trigger);
-	free(s);
-	service_validate_del(s);
+	service_stopped(s);
 }
 
 enum {
@@ -606,6 +600,18 @@ service_start_early(char *name, char *cmdline)
 	return service_handle_set(NULL, NULL, NULL, "add", b.head);
 }
 
+void service_stopped(struct service *s)
+{
+	if (avl_is_empty(&s->instances.avl)) {
+		service_event("service.stop", s->name, NULL);
+		avl_delete(&services, &s->avl);
+		trigger_del(s);
+		free(s->trigger);
+		free(s);
+		service_validate_del(s);
+	}
+}
+
 void service_event(const char *type, const char *service, const char *instance)
 {
 	if (!ctx)
diff --git a/service/service.h b/service/service.h
index c3f2964..d4f0a83 100644
--- a/service/service.h
+++ b/service/service.h
@@ -50,7 +50,10 @@ void service_validate_add(struct service *s, struct blob_attr *attr);
 void service_validate_dump(struct blob_buf *b, struct service *s);
 void service_validate_dump_all(struct blob_buf *b, char *p, char *s);
 int service_start_early(char *name, char *cmdline);
+void service_stopped(struct service *s);
 void service_validate_del(struct service *s);
 void service_event(const char *type, const char *service, const char *instance);
 
+
+
 #endif
-- 
1.7.12.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Thu Feb  9 05:54:08 2017
From: john at phrozen.org (John Crispin)
Date: Thu, 9 Feb 2017 11:54:08 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] procd: stop service using
 SIGKILL if SIGTERM failed to do so
In-Reply-To: <1486634573-12258-1-git-send-email-alin.nastac@gmail.com>
References: <1486634573-12258-1-git-send-email-alin.nastac@gmail.com>
Message-ID: <0a70d9cc-b0aa-be39-70cc-57331c746fb1@phrozen.org>

Hi,

i know that someone else is about to send a fix for the same issue but
with a different approach of fixing it. i'd like to wait for this 2nd
patch to arrive before we decide which to merge

	John

On 09/02/2017 11:02, Alin Nastac wrote:
> SIGKILL is sent if instance process is still running after
> <term_timeout> seconds after SIGTERM has been sent. To prevent
> another daemon process being launched before old process dies,
> the instance is kept until SIGCHLD confirms that service has
> been stopped.
> 
> Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
> ---
>  service/instance.c | 44 +++++++++++++++++++++++++++++++++++++-------
>  service/instance.h |  1 +
>  service/service.c  | 26 ++++++++++++++++----------
>  service/service.h  |  3 +++
>  4 files changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/service/instance.c b/service/instance.c
> index 018db3c..4d340fd 100644
> --- a/service/instance.c
> +++ b/service/instance.c
> @@ -55,6 +55,7 @@ enum {
>  	INSTANCE_ATTR_SECCOMP,
>  	INSTANCE_ATTR_PIDFILE,
>  	INSTANCE_ATTR_RELOADSIG,
> +	INSTANCE_ATTR_TERMTIMEOUT,
>  	__INSTANCE_ATTR_MAX
>  };
>  
> @@ -79,6 +80,7 @@ static const struct blobmsg_policy instance_attr[__INSTANCE_ATTR_MAX] = {
>  	[INSTANCE_ATTR_SECCOMP] = { "seccomp", BLOBMSG_TYPE_STRING },
>  	[INSTANCE_ATTR_PIDFILE] = { "pidfile", BLOBMSG_TYPE_STRING },
>  	[INSTANCE_ATTR_RELOADSIG] = { "reload_signal", BLOBMSG_TYPE_INT32 },
> +	[INSTANCE_ATTR_TERMTIMEOUT] = { "term_timeout", BLOBMSG_TYPE_INT32 },
>  };
>  
>  enum {
> @@ -389,8 +391,16 @@ instance_start(struct service_instance *in)
>  		return;
>  	}
>  
> -	if (in->proc.pending || !in->command)
> +	if (!in->command) {
> +		LOG("Not starting instance %s::%s, command not set\n", in->srv->name, in->name);
>  		return;
> +	}
> +
> +	if (in->proc.pending) {
> +		if (in->halt)
> +			in->restart = true;
> +		return;
> +	}
>  
>  	instance_free_stdio(in);
>  	if (in->_stdout.fd.fd > -2) {
> @@ -408,7 +418,7 @@ instance_start(struct service_instance *in)
>  	}
>  
>  	in->restart = false;
> -	in->halt = !in->respawn;
> +	in->halt = false;
>  
>  	if (!in->valid)
>  		return;
> @@ -494,7 +504,11 @@ instance_timeout(struct uloop_timeout *t)
>  
>  	in = container_of(t, struct service_instance, timeout);
>  
> -	if (!in->halt && (in->restart || in->respawn))
> +	if (in->halt) {
> +		LOG("Instance %s::%s pid %d not stopped on SIGTERM, sending SIGKILL instead\n",
> +				in->srv->name, in->name, in->proc.pid);
> +		kill(in->proc.pid, SIGKILL);
> +	} else if (in->restart || in->respawn)
>  		instance_start(in);
>  }
>  
> @@ -515,8 +529,19 @@ instance_exit(struct uloop_process *p, int ret)
>  		return;
>  
>  	uloop_timeout_cancel(&in->timeout);
> +	service_event("instance.stop", in->srv->name, in->name);
> +
>  	if (in->halt) {
>  		instance_removepid(in);
> +		if (in->restart)
> +			instance_start(in);
> +		else {
> +			struct service *s = in->srv;
> +
> +			avl_delete(&s->instances.avl, &in->node.avl);
> +			instance_free(in);
> +			service_stopped(s);
> +		}
>  	} else if (in->restart) {
>  		instance_start(in);
>  	} else if (in->respawn) {
> @@ -535,7 +560,6 @@ instance_exit(struct uloop_process *p, int ret)
>  			uloop_timeout_set(&in->timeout, in->respawn_timeout * 1000);
>  		}
>  	}
> -	service_event("instance.stop", in->srv->name, in->name);
>  }
>  
>  void
> @@ -546,6 +570,7 @@ instance_stop(struct service_instance *in)
>  	in->halt = true;
>  	in->restart = in->respawn = false;
>  	kill(in->proc.pid, SIGTERM);
> +	uloop_timeout_set(&in->timeout, in->term_timeout * 1000);
>  }
>  
>  static void
> @@ -559,10 +584,10 @@ instance_restart(struct service_instance *in)
>  		return;
>  	}
>  
> -	in->halt = false;
> +	in->halt = true;
>  	in->restart = true;
>  	kill(in->proc.pid, SIGTERM);
> -	instance_removepid(in);
> +	uloop_timeout_set(&in->timeout, in->term_timeout * 1000);
>  }
>  
>  static bool
> @@ -796,6 +821,8 @@ instance_config_parse(struct service_instance *in)
>  	if (!instance_config_parse_command(in, tb))
>  		return false;
>  
> +	if (tb[INSTANCE_ATTR_TERMTIMEOUT])
> +		in->term_timeout = blobmsg_get_u32(tb[INSTANCE_ATTR_TERMTIMEOUT]);
>  	if (tb[INSTANCE_ATTR_RESPAWN]) {
>  		int i = 0;
>  		uint32_t vals[3] = { 3600, 5, 5};
> @@ -933,8 +960,9 @@ instance_update(struct service_instance *in, struct service_instance *in_new)
>  {
>  	bool changed = instance_config_changed(in, in_new);
>  	bool running = in->proc.pending;
> +	bool stopping = in->halt;
>  
> -	if (!running) {
> +	if (!running || stopping) {
>  		instance_config_move(in, in_new);
>  		instance_start(in);
>  	} else {
> @@ -967,6 +995,7 @@ instance_init(struct service_instance *in, struct service *s, struct blob_attr *
>  	in->config = config;
>  	in->timeout.cb = instance_timeout;
>  	in->proc.cb = instance_exit;
> +	in->term_timeout = 5;
>  
>  	in->_stdout.fd.fd = -2;
>  	in->_stdout.stream.string_data = true;
> @@ -999,6 +1028,7 @@ void instance_dump(struct blob_buf *b, struct service_instance *in, int verbose)
>  		blobmsg_add_u32(b, "pid", in->proc.pid);
>  	if (in->command)
>  		blobmsg_add_blob(b, in->command);
> +	blobmsg_add_u32(b, "term_timeout", in->term_timeout);
>  
>  	if (!avl_is_empty(&in->errors.avl)) {
>  		struct blobmsg_list_node *var;
> diff --git a/service/instance.h b/service/instance.h
> index 3cc2009..78999c8 100644
> --- a/service/instance.h
> +++ b/service/instance.h
> @@ -59,6 +59,7 @@ struct service_instance {
>  	char *seccomp;
>  	char *pidfile;
>  
> +	uint32_t term_timeout;
>  	uint32_t respawn_timeout;
>  	uint32_t respawn_threshold;
>  	uint32_t respawn_retry;
> diff --git a/service/service.c b/service/service.c
> index 2c73901..0584ee0 100644
> --- a/service/service.c
> +++ b/service/service.c
> @@ -59,11 +59,10 @@ service_instance_update(struct vlist_tree *tree, struct vlist_node *node_new,
>  		instance_update(in_o, in_n);
>  		instance_free(in_n);
>  	} else if (in_o) {
> -		DEBUG(2, "Free instance %s::%s\n", in_o->srv->name, in_o->name);
> +		DEBUG(2, "Stop instance %s::%s\n", in_o->srv->name, in_o->name);
>  		instance_stop(in_o);
> -		instance_free(in_o);
>  	} else if (in_n) {
> -		DEBUG(2, "Create instance %s::%s\n", in_n->srv->name, in_n->name);
> +		DEBUG(2, "Start instance %s::%s\n", in_n->srv->name, in_n->name);
>  		instance_start(in_n);
>  	}
>  	blob_buf_init(&b, 0);
> @@ -80,7 +79,7 @@ service_alloc(const char *name)
>  	strcpy(new_name, name);
>  
>  	vlist_init(&s->instances, avl_strcmp, service_instance_update);
> -	s->instances.keep_old = true;
> +	s->instances.no_delete = true;
>  	s->name = new_name;
>  	s->avl.key = s->name;
>  	INIT_LIST_HEAD(&s->validators);
> @@ -149,13 +148,8 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
>  static void
>  service_delete(struct service *s)
>  {
> -	service_event("service.stop", s->name, NULL);
>  	vlist_flush_all(&s->instances);
> -	avl_delete(&services, &s->avl);
> -	trigger_del(s);
> -	free(s->trigger);
> -	free(s);
> -	service_validate_del(s);
> +	service_stopped(s);
>  }
>  
>  enum {
> @@ -606,6 +600,18 @@ service_start_early(char *name, char *cmdline)
>  	return service_handle_set(NULL, NULL, NULL, "add", b.head);
>  }
>  
> +void service_stopped(struct service *s)
> +{
> +	if (avl_is_empty(&s->instances.avl)) {
> +		service_event("service.stop", s->name, NULL);
> +		avl_delete(&services, &s->avl);
> +		trigger_del(s);
> +		free(s->trigger);
> +		free(s);
> +		service_validate_del(s);
> +	}
> +}
> +
>  void service_event(const char *type, const char *service, const char *instance)
>  {
>  	if (!ctx)
> diff --git a/service/service.h b/service/service.h
> index c3f2964..d4f0a83 100644
> --- a/service/service.h
> +++ b/service/service.h
> @@ -50,7 +50,10 @@ void service_validate_add(struct service *s, struct blob_attr *attr);
>  void service_validate_dump(struct blob_buf *b, struct service *s);
>  void service_validate_dump_all(struct blob_buf *b, char *p, char *s);
>  int service_start_early(char *name, char *cmdline);
> +void service_stopped(struct service *s);
>  void service_validate_del(struct service *s);
>  void service_event(const char *type, const char *service, const char *instance);
>  
> +
> +
>  #endif
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Thu Feb  9 06:43:07 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Thu, 9 Feb 2017 12:43:07 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] procd: stop service using
 SIGKILL if SIGTERM failed to do so
In-Reply-To: <0a70d9cc-b0aa-be39-70cc-57331c746fb1@phrozen.org>
References: <1486634573-12258-1-git-send-email-alin.nastac@gmail.com>
 <0a70d9cc-b0aa-be39-70cc-57331c746fb1@phrozen.org>
Message-ID: <CAF1oqRDgyfibPb0DJsXui02BEucEOKBFAygpUZuKBLVYGWX9sA@mail.gmail.com>

On Thu, Feb 9, 2017 at 11:54 AM, John Crispin <john at phrozen.org> wrote:
> Hi,
>
> i know that someone else is about to send a fix for the same issue but
> with a different approach of fixing it. i'd like to wait for this 2nd
> patch to arrive before we decide which to merge
Are you sure it wasn't me? :)
You said yesterday that I should send you a patch for it.

The only other approach I could think of would involve a
instance_stop() that waits for the service instance to exit.
I thought initially to do it like this, but decided that waiting
asynchronously for stop event would be a fer better technical solution
to the given issue, don't you agree?

>
>         John
>

Alin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Fri Feb 10 07:26:16 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 10 Feb 2017 13:26:16 +0100
Subject: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT
	and multiplatform
In-Reply-To: <alpine.LNX.2.00.1702081401080.8463@T420s>
References: <20170122121506.9995-1-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702081401080.8463@T420s>
Message-ID: <CACRpkdYsFDxk_mmWtWi6qtpmuiNr9nzNvt0auMEmbWapR=K+Ew@mail.gmail.com>

On Wed, Feb 8, 2017 at 2:13 PM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:

> now I've got my toolchain cleaned up and working ...
> Tested on may nas 4220
>
> here my
> Acked-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>

Thanks! I'll add it throughout.

>> - FOT2G USB EHCI host
>
> The fotg2 driver is already upstream.
> I've added DT support and this driver works.

I saw some patches flying, awesome. I'll probably stack them up in
my git tree. I can't test them: the SQ201 I'm using has a separate
VIA USB on PCI for some reason, I guess they just didn't trust the
built-in USB and just threw money at the problem.

With the patches in transit the upstream TODO (not started) is just
down to:
- SATA
- Ethernet
- Crypto

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Fri Feb 10 07:55:53 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 10 Feb 2017 13:55:53 +0100
Subject: [OpenWrt-Devel] [PATCH 14/22] ARM: dts: add a devicetree for
	Raidsonic NAS IB-4220-B
In-Reply-To: <alpine.LNX.2.00.1702081353480.8463@T420s>
References: <20170122122254.10764-1-linus.walleij@linaro.org>
 <alpine.LNX.2.00.1702051051090.26313@T420s>
 <CACRpkdb2YUSAD1eR8c11BsCb3yBmMJ7C_bEKkpgkiqX9B4GNwQ@mail.gmail.com>
 <alpine.LNX.2.00.1702081353480.8463@T420s>
Message-ID: <CACRpkdb6vfTsv=rBd_A7igSRQNYayXw=P8LJdY4-gVX5nnoCpw@mail.gmail.com>

On Wed, Feb 8, 2017 at 1:55 PM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:
> On Tue, 7 Feb 2017, Linus Walleij wrote:
>
>> On Sun, Feb 5, 2017 at 10:53 AM, Hans Ulli Kroll
>> <ulli.kroll at googlemail.com> wrote:
>>
>> > Hi Linus,
>> >
>> > please add right baudrate and partition scheme for NAS 4220
>> >
>> > Signed-off-by: Hans Ulli Kroll <ulli.kroll at googlemail.com>
>>
>> Thanks Hans! I folded this into the NAS 4220 device tree
>> and added your Signed-off-by to the patch.
>>
>
> You can remove the PCI entries I've seen on your git tree.
> NAS 4220 has no PCI interface

OK! I just assumed it was on that machine since you were
commenting on the driver, I cut it now.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Sat Feb 11 00:35:54 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Sat, 11 Feb 2017 11:05:54 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
Message-ID: <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>

Hi Alex and OpenWRT Team,

Any help on getting  dnscrypt-proxy package into snapshot will be helpful.
It is working fine with 15.05.1 - but not snapshot ImageBuilder.

Regards,
Mangesh Bhamre

On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <mangesh at opennetware.com>
wrote:

> Hi Alex,
>
> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported in
> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
> include while building with CC Image-builder.
>
> I scanned through all snapshot image-builder and no reference there. I run
> following command to build - same works fine for CC 15.05.1
>
> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
>
> Surely no typo there.
>
> Regards,
> Mangesh
>
>
> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean <
> ardeleanalex at gmail.com> wrote:
>
>> Do you have a Package/dnscrypt-proxy/install rule ?
>> Are you calling the BuildPackage rule ?
>>
>> Do you have Package/dnscrypt-proxy/description rule ?
>>
>> And check for typos if above stuff is checked.
>>
>> Thanks
>> Alex
>>
>>
>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
>> wrote:
>>
>>> Hello OpenWRT team,
>>>
>>> I wish to bundle dnscrypt-proxy package using latest snapshot
>>> Image-builder. I get below errors. Please recommend a fix or address it in
>>> snapshot.
>>>
>>> Collected errors:
>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
>>> Makefile:146: recipe for target 'package_install' failed
>>>
>>> Regards,
>>> Mangesh
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170211/4eeb7822/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 06:17:17 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 12:17:17 +0100
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini DTSI
In-Reply-To: <3236035.PSA6VtheyS@wuerfel>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <CACRpkdbrys49Yv5fJ_te2H1mEUqquc1jn2dP-uvkdLixFbtYFA@mail.gmail.com>
 <alpine.LNX.2.00.1702061038590.7077@T420s> <3236035.PSA6VtheyS@wuerfel>
Message-ID: <CACRpkdah04ZaRU52Gr6L=qmW57N6XOgZeHYNDzB2GcSH+B3DXA@mail.gmail.com>

On Fri, Feb 10, 2017 at 4:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday, February 6, 2017 10:55:03 AM CET Hans Ulli Kroll wrote:
>>
>> from my IB 4220 sources.
>>
>> #define IRQ_PCI_INTA                                   PCI_IRQ_OFFSET + 0
>> #ifndef CONFIG_DUAL_PCI
>> #define IRQ_PCI_INTB                                   PCI_IRQ_OFFSET + 1
>> #define IRQ_PCI_INTC                                   PCI_IRQ_OFFSET + 2
>> #define IRQ_PCI_INTD                                   PCI_IRQ_OFFSET + 3
>> #else
>> #define IRQ_PCI_INTB                                   27
>> #define IRQ_PCI_INTC                                   28
>> #define IRQ_PCI_INTD                                   29
>> #endif
>>
>> CONFIG_DUAL_PCI is never used
>> IRQ_PCIB - IRQ_PCID or IRQ_PCI_INTB - IRQ_PCI_INTD are also never used.
>
> The source code that Linus quoted earlier had references to
> 'IRQ_PCI_INTA +n' though, which is basically the same thing.

There is essentially two versions of the IP block, one which has
a cascaded interrupt controller in the PCI host bridge, and one
named "dual PCI" that has dedicated IRQs for PCIA, B, C, D on
the primary interrupt controller.

I'll try to codify it into the driver so it's clear how this works on the
two variants.

I'm also pretty sure this is a faraday IP block and not something
from Storlink/Storm/Cortina, so I will rename the compatible strings
etc reflecting that.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Sat Feb 11 06:26:35 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Sat, 11 Feb 2017 13:26:35 +0200
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
Message-ID: <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>

Hey Mangesh,

So, I don't use much ImageBuilder.
I don't even know how that works.

I usually just do

< get OpenWrt repo >
./scripts/feeds update packages
./scripts/feeds install -a
make menuconfig
< select packages I need, configure arch, etc >
make V=99 -j8
< extract image from the bin directory >

Looking through
https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy
It looks like dnscrypt-proxy should be there.
But that's just the Makefile that builds the package.

Does ImageBuilder install pre-built packages from an OpenWrt mirror ?
Because on some architectures, dnscrypt-proxy looks broken.

Example:
http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/
http://buildbot.openwrt.org:8010/broken_packages/kirkwood/
http://buildbot.openwrt.org:8010/broken_packages/bcm53xx/
http://buildbot.openwrt.org:8010/broken_packages/ar71xx.mikrotik/
http://buildbot.openwrt.org:8010/broken_packages/adm8668/

On which architecture are you trying to build ?
I understand you're trying to build on CC 15.05.1

So, a bit more info about your setup could help.


On Sat, Feb 11, 2017 at 7:35 AM, Mangesh Bhamre <mangesh at opennetware.com> wrote:
> Hi Alex and OpenWRT Team,
>
> Any help on getting  dnscrypt-proxy package into snapshot will be helpful.
> It is working fine with 15.05.1 - but not snapshot ImageBuilder.
>
> Regards,
> Mangesh Bhamre
>
> On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <mangesh at opennetware.com>
> wrote:
>>
>> Hi Alex,
>>
>> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported in
>> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
>> include while building with CC Image-builder.
>>
>> I scanned through all snapshot image-builder and no reference there. I run
>> following command to build - same works fine for CC 15.05.1
>>
>> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
>> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
>>
>> Surely no typo there.
>>
>> Regards,
>> Mangesh
>>
>>
>> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean
>> <ardeleanalex at gmail.com> wrote:
>>>
>>> Do you have a Package/dnscrypt-proxy/install rule ?
>>> Are you calling the BuildPackage rule ?
>>>
>>> Do you have Package/dnscrypt-proxy/description rule ?
>>>
>>> And check for typos if above stuff is checked.
>>>
>>> Thanks
>>> Alex
>>>
>>>
>>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
>>> wrote:
>>>>
>>>> Hello OpenWRT team,
>>>>
>>>> I wish to bundle dnscrypt-proxy package using latest snapshot
>>>> Image-builder. I get below errors. Please recommend a fix or address it in
>>>> snapshot.
>>>>
>>>> Collected errors:
>>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
>>>> Makefile:146: recipe for target 'package_install' failed
>>>>
>>>> Regards,
>>>> Mangesh
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel at lists.openwrt.org
>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Sat Feb 11 07:14:35 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Sat, 11 Feb 2017 17:44:35 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
Message-ID: <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>

Hi Alex,

ramips architecture. Mt7620 make file.

Regards
Mangesh

On 11-Feb-2017 4:56 PM, "Alexandru Ardelean" <ardeleanalex at gmail.com> wrote:

> Hey Mangesh,
>
> So, I don't use much ImageBuilder.
> I don't even know how that works.
>
> I usually just do
>
> < get OpenWrt repo >
> ./scripts/feeds update packages
> ./scripts/feeds install -a
> make menuconfig
> < select packages I need, configure arch, etc >
> make V=99 -j8
> < extract image from the bin directory >
>
> Looking through
> https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy
> It looks like dnscrypt-proxy should be there.
> But that's just the Makefile that builds the package.
>
> Does ImageBuilder install pre-built packages from an OpenWrt mirror ?
> Because on some architectures, dnscrypt-proxy looks broken.
>
> Example:
> http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/
> http://buildbot.openwrt.org:8010/broken_packages/kirkwood/
> http://buildbot.openwrt.org:8010/broken_packages/bcm53xx/
> http://buildbot.openwrt.org:8010/broken_packages/ar71xx.mikrotik/
> http://buildbot.openwrt.org:8010/broken_packages/adm8668/
>
> On which architecture are you trying to build ?
> I understand you're trying to build on CC 15.05.1
>
> So, a bit more info about your setup could help.
>
>
> On Sat, Feb 11, 2017 at 7:35 AM, Mangesh Bhamre <mangesh at opennetware.com>
> wrote:
> > Hi Alex and OpenWRT Team,
> >
> > Any help on getting  dnscrypt-proxy package into snapshot will be
> helpful.
> > It is working fine with 15.05.1 - but not snapshot ImageBuilder.
> >
> > Regards,
> > Mangesh Bhamre
> >
> > On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <mangesh at opennetware.com
> >
> > wrote:
> >>
> >> Hi Alex,
> >>
> >> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported
> in
> >> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
> >> include while building with CC Image-builder.
> >>
> >> I scanned through all snapshot image-builder and no reference there. I
> run
> >> following command to build - same works fine for CC 15.05.1
> >>
> >> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
> >> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
> >>
> >> Surely no typo there.
> >>
> >> Regards,
> >> Mangesh
> >>
> >>
> >> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean
> >> <ardeleanalex at gmail.com> wrote:
> >>>
> >>> Do you have a Package/dnscrypt-proxy/install rule ?
> >>> Are you calling the BuildPackage rule ?
> >>>
> >>> Do you have Package/dnscrypt-proxy/description rule ?
> >>>
> >>> And check for typos if above stuff is checked.
> >>>
> >>> Thanks
> >>> Alex
> >>>
> >>>
> >>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
> >>> wrote:
> >>>>
> >>>> Hello OpenWRT team,
> >>>>
> >>>> I wish to bundle dnscrypt-proxy package using latest snapshot
> >>>> Image-builder. I get below errors. Please recommend a fix or address
> it in
> >>>> snapshot.
> >>>>
> >>>> Collected errors:
> >>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
> >>>> Makefile:146: recipe for target 'package_install' failed
> >>>>
> >>>> Regards,
> >>>> Mangesh
> >>>> _______________________________________________
> >>>> openwrt-devel mailing list
> >>>> openwrt-devel at lists.openwrt.org
> >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170211/f6071ae1/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Sat Feb 11 07:50:29 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Sat, 11 Feb 2017 12:50:29 +0000
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
 <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
Message-ID: <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>

If I got this correctly it's broken for that target as well

http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/

It looks like an issue with the source tar ball not being present in any
OpenWrt mirror.

Well, that was the error when it tried to build.
Looks like dnscrypt-proxy was updated on the 7th of Feb 2017.

No idea how the artifact caching works on OpenWrt buildbot.

But, it could be that the issue may resolve itself, after triggering a
rebuild.
It doesn't look like it failed on all targets.


On Sat, 11 Feb 2017 at 14:14, Mangesh Bhamre <mangesh at opennetware.com>
wrote:

> Hi Alex,
>
> ramips architecture. Mt7620 make file.
>
> Regards
> Mangesh
>
> On 11-Feb-2017 4:56 PM, "Alexandru Ardelean" <ardeleanalex at gmail.com>
> wrote:
>
> Hey Mangesh,
>
> So, I don't use much ImageBuilder.
> I don't even know how that works.
>
> I usually just do
>
> < get OpenWrt repo >
> ./scripts/feeds update packages
> ./scripts/feeds install -a
> make menuconfig
> < select packages I need, configure arch, etc >
> make V=99 -j8
> < extract image from the bin directory >
>
> Looking through
> https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy
> It looks like dnscrypt-proxy should be there.
> But that's just the Makefile that builds the package.
>
> Does ImageBuilder install pre-built packages from an OpenWrt mirror ?
> Because on some architectures, dnscrypt-proxy looks broken.
>
> Example:
> http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/
> http://buildbot.openwrt.org:8010/broken_packages/kirkwood/
> http://buildbot.openwrt.org:8010/broken_packages/bcm53xx/
> http://buildbot.openwrt.org:8010/broken_packages/ar71xx.mikrotik/
> http://buildbot.openwrt.org:8010/broken_packages/adm8668/
>
> On which architecture are you trying to build ?
> I understand you're trying to build on CC 15.05.1
>
> So, a bit more info about your setup could help.
>
>
> On Sat, Feb 11, 2017 at 7:35 AM, Mangesh Bhamre <mangesh at opennetware.com>
> wrote:
> > Hi Alex and OpenWRT Team,
> >
> > Any help on getting  dnscrypt-proxy package into snapshot will be
> helpful.
> > It is working fine with 15.05.1 - but not snapshot ImageBuilder.
> >
> > Regards,
> > Mangesh Bhamre
> >
> > On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <mangesh at opennetware.com
> >
> > wrote:
> >>
> >> Hi Alex,
> >>
> >> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported
> in
> >> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
> >> include while building with CC Image-builder.
> >>
> >> I scanned through all snapshot image-builder and no reference there. I
> run
> >> following command to build - same works fine for CC 15.05.1
> >>
> >> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
> >> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
> >>
> >> Surely no typo there.
> >>
> >> Regards,
> >> Mangesh
> >>
> >>
> >> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean
> >> <ardeleanalex at gmail.com> wrote:
> >>>
> >>> Do you have a Package/dnscrypt-proxy/install rule ?
> >>> Are you calling the BuildPackage rule ?
> >>>
> >>> Do you have Package/dnscrypt-proxy/description rule ?
> >>>
> >>> And check for typos if above stuff is checked.
> >>>
> >>> Thanks
> >>> Alex
> >>>
> >>>
> >>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
> >>> wrote:
> >>>>
> >>>> Hello OpenWRT team,
> >>>>
> >>>> I wish to bundle dnscrypt-proxy package using latest snapshot
> >>>> Image-builder. I get below errors. Please recommend a fix or address
> it in
> >>>> snapshot.
> >>>>
> >>>> Collected errors:
> >>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
> >>>> Makefile:146: recipe for target 'package_install' failed
> >>>>
> >>>> Regards,
> >>>> Mangesh
> >>>> _______________________________________________
> >>>> openwrt-devel mailing list
> >>>> openwrt-devel at lists.openwrt.org
> >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170211/4bf9c3fa/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 07:52:17 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 13:52:17 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Faraday
	Technology PCI Host Bridge
Message-ID: <20170211125220.10273-1-linus.walleij@linaro.org>

This adds device tree bindings for the Faraday technology PCI
Host Bridge. This IP is found in the Storlink/Storm/Cortina
Gemini SoC platform.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: devicetree at vger.kernel.org
Cc: Gavin Guo <gavinguo at andestech.com>
Cc: Macpaul Lin <macpaul at andestech.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Rename from Cortina prefixes to Faraday. This is clearly
  a Faraday IP block.
- Support both the version with cascaded interrupts and the
  "dual" version with 1-to-1 mapped interrupts.
- Change bus-range to <0x00 0xff>
- Fix spelling mistake
- Write a bit about swizzling interrupts on the interrupt
  controller side
- Reasonable swizzling in the interrupt mapping example

This can be merged to the PCI tree whenever it is considered
fine for inclusion.
---
 .../devicetree/bindings/pci/faraday-pci.txt        | 113 +++++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/faraday-pci.txt

diff --git a/Documentation/devicetree/bindings/pci/faraday-pci.txt b/Documentation/devicetree/bindings/pci/faraday-pci.txt
new file mode 100644
index 000000000000..5fbb0fc6b758
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/faraday-pci.txt
@@ -0,0 +1,113 @@
+Faraday Technology PCI Host Bridge
+
+This PCI bridge is found inside that Cortina Systems Gemini SoC platform and
+is a generic IP block from Faraday Technology. It exists in two variants:
+plain and dual PCI. The plain version embeds a cascading interrupt controller
+into the host bridge. The dual version routes the interrupts to the host
+chips interrupt controller.
+
+The host controller appear on the PCI bus with vendor ID 0x159b (Faraday
+Technology) and product ID 0x4321.
+
+Mandatory properties:
+
+- compatible: should be one of
+  "faraday,pci"
+  "faraday,dual-pci"
+- reg: memory base and size for the host bridge
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells: set to <1>
+- bus-range: set to <0x00 0xff>
+- device_type, set to "pci"
+- ranges: see pci.txt
+- interrupt-map-mask: see pci.txt
+- interrupt-map: see pci.txt
+
+Mandatory subnodes:
+- For "faraday,pci" a node representing the interrupt-controller inside the
+  host bridge is mandatory. It has the following mandatory properties:
+  - interrupt: see interrupt-controller/interrupts.txt
+  - interrupt-parent: see interrupt-controller/interrupts.txt
+  - interrupt-controller: see interrupt-controller/interrupts.txt
+  - #address-cells: set to <0>
+  - #interrupt-cells: set to <1>
+
+I/O space considerations:
+
+The plain variant has 128MiB of non-prefetchable memory space, whereas the
+"dual" variant has 64MiB. Take this into account when describing the ranges.
+
+Interrupt map considerations:
+
+The "dual" variant will get INT A, B, C, D from the system interrupt controller
+and should point to respective interrupt in that controller in its
+interrupt-map.
+
+The code which is the only documentation of how the Faraday PCI (the non-dual
+variant) interrupts assigns the default interrupt mapping/swizzling has
+typically been like this, doing the swizzling on the interrupt controller side
+rather than in the interconnect:
+
+interrupt-map-mask = <0xf800 0 0 7>;
+interrupt-map =
+	<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+	<0x4800 0 0 2 &pci_intc 1>,
+	<0x4800 0 0 3 &pci_intc 2>,
+	<0x4800 0 0 4 &pci_intc 3>,
+	<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+	<0x5000 0 0 2 &pci_intc 2>,
+	<0x5000 0 0 3 &pci_intc 3>,
+	<0x5000 0 0 4 &pci_intc 0>,
+	<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+	<0x5800 0 0 2 &pci_intc 3>,
+	<0x5800 0 0 3 &pci_intc 0>,
+	<0x5800 0 0 4 &pci_intc 1>,
+	<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+	<0x6000 0 0 2 &pci_intc 0>,
+	<0x6000 0 0 3 &pci_intc 1>,
+	<0x6000 0 0 4 &pci_intc 2>;
+
+Example:
+
+pci at 50000000 {
+	compatible = "faraday,pci";
+	reg = <0x50000000 0x100>;
+	interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
+			<26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
+			<27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
+			<28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
+	#address-cells = <3>;
+	#size-cells = <2>;
+	#interrupt-cells = <1>;
+
+	bus-range = <0x00 0xff>;
+	ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
+		 <0x01000000 0 0          0x50000000 0 0x00100000>,
+		 /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
+		 <0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
+	interrupt-map-mask = <0xf800 0 0 7>;
+	interrupt-map =
+		<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+		<0x4800 0 0 2 &pci_intc 1>,
+		<0x4800 0 0 3 &pci_intc 2>,
+		<0x4800 0 0 4 &pci_intc 3>,
+		<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+		<0x5000 0 0 2 &pci_intc 2>,
+		<0x5000 0 0 3 &pci_intc 3>,
+		<0x5000 0 0 4 &pci_intc 0>,
+		<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+		<0x5800 0 0 2 &pci_intc 3>,
+		<0x5800 0 0 3 &pci_intc 0>,
+		<0x5800 0 0 4 &pci_intc 1>,
+		<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+		<0x6000 0 0 2 &pci_intc 0>,
+		<0x6000 0 0 3 &pci_intc 0>,
+		<0x6000 0 0 4 &pci_intc 0>;
+	pci_intc: interrupt-controller {
+		interrupt-parent = <&intcon>;
+		interrupt-controller;
+		#address-cells = <0>;
+		#interrupt-cells = <1>;
+	};
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 07:52:18 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 13:52:18 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Faraday Technology
	Host Bridge
In-Reply-To: <20170211125220.10273-1-linus.walleij@linaro.org>
References: <20170211125220.10273-1-linus.walleij@linaro.org>
Message-ID: <20170211125220.10273-2-linus.walleij@linaro.org>

This adds a host bridge driver for the Faraday Technology
PCI host bridge, used for Cortina Systems Gemini SoC (SL3516)
PCI Host Bridge.

This code is inspired by the out-of-tree OpenWRT patch and
then extensively rewritten for device tree and using the modern
helpers to cut down and modernize the code to all new PCI
frameworks.

Tested on the ITian Square One SQ201 NAS with the following
result in the boot log (trimmed to relevant parts):

OF: PCI: host bridge /soc/pci at 50000000 ranges:
OF: PCI:    IO 0x50000000..0x500fffff -> 0x00000000
OF: PCI:   MEM 0x58000000..0x5fffffff -> 0x58000000
gemini-pci 50000000.pci: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0x58000000-0x5fffffff]
pci 0000:00:00.0: [159b:4321] type 00 class 0x060000
pci 0000:00:09.0: [1106:3038] type 00 class 0x0c0300
pci 0000:00:09.0: reg 0x20: [io  0xfce0-0xfcff]
pci 0000:00:09.0: supports D1 D2
pci 0000:00:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:09.1: [1106:3038] type 00 class 0x0c0300
pci 0000:00:09.1: reg 0x20: [io  0xfce0-0xfcff]
pci 0000:00:09.1: supports D1 D2
pci 0000:00:09.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:09.2: [1106:3104] type 00 class 0x0c0320
pci 0000:00:09.2: reg 0x10: [mem 0x00000000-0x000000ff]
pci 0000:00:09.2: supports D1 D2
pci 0000:00:09.2: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0c.0: [1814:0301] type 00 class 0x028000
pci 0000:00:0c.0: reg 0x10: [mem 0xffff8000-0xffffffff]
PCI: bus0: Fast back to back transfers disabled
gemini-pci 50000000.pci: clear all IRQs
gemini-pci 50000000.pci: setting up PCI DMA
pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0000:00:0c.0: BAR 0: assigned [mem 0x58000000-0x58007fff]
pci 0000:00:09.2: BAR 0: assigned [mem 0x58008000-0x580080ff]
pci 0000:00:09.0: BAR 4: assigned [io  0x1000-0x101f]
pci 0000:00:09.1: BAR 4: assigned [io  0x1020-0x103f]
pci 0000:00:09.0: enabling device (0140 -> 0141)
pci 0000:00:09.0: HCRESET not completed yet!
pci 0000:00:09.1: enabling device (0140 -> 0141)
pci 0000:00:09.1: HCRESET not completed yet!
pci 0000:00:09.2: enabling device (0140 -> 0142)
rt61pci 0000:00:0c.0: enabling device (0140 -> 0142)
ieee80211 phy0: rt2x00_set_chip: Info - Chipset detected -
  rt: 2561, rf: 0003, rev: 000c
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci 0000:00:09.2: EHCI Host Controller
ehci-pci 0000:00:09.2: new USB bus registered, assigned bus number 1
ehci-pci 0000:00:09.2: irq 125, io mem 0x58008000
ehci-pci 0000:00:09.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:09.0: UHCI Host Controller
uhci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:09.0: HCRESET not completed yet!
uhci_hcd 0000:00:09.0: irq 123, io base 0x00001000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
uhci_hcd 0000:00:09.1: UHCI Host Controller
uhci_hcd 0000:00:09.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:09.1: HCRESET not completed yet!
uhci_hcd 0000:00:09.1: irq 124, io base 0x00001020
hub 3-0:1.0: USB hub found
hub 3-0:1.0: config failed, hub doesn't have any ports! (err -19)
usb 1-2: new high-speed USB device number 2 using ehci-pci
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-2:1.0
scsi 0:0:0:0: Direct-Access     USB      Flash Disk       1.00 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 7900336 512-byte logical blocks: (4.04 GB/3.77 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI removable disk
ieee80211 phy0: rt2x00lib_request_firmware: Info -
  Loading firmware file 'rt2561s.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info -
  Firmware detected - version: 0.8
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

$ lspci
00:00.0 Class 0600: 159b:4321
00:09.2 Class 0c03: 1106:3104
00:09.0 Class 0c03: 1106:3038
00:09.1 Class 0c03: 1106:3038
00:0c.0 Class 0280: 1814:0301

cat /proc/interrupts
          CPU0
 16:       3402    GEMINI  14 Edge      Gemini Timer Tick
 17:          0    GEMINI   3 Level     watchdog bark
 18:       1305    GEMINI  18 Level     serial
 21:          0    GEMINI  17 Level     45000000.rtc
 22:          1    GEMINI  26 Edge      poweroff
 44:          0      GPIO  18 Edge      factory reset
123:          0       PCI   0 Edge      uhci_hcd:usb2
124:          0       PCI   1 Edge      uhci_hcd:usb3
125:        160       PCI   2 Edge      ehci_hcd:usb1
126:       1148       PCI   3 Edge      rt61pci

cat /proc/iomem
00000000-07ffffff : System RAM
  00008000-006fffff : Kernel code
  00900000-0095f007 : Kernel data
30000000-30ffffff : 30000000.flash
41000000-41000fff : /soc/watchdog at 41000000
42000000-420000ff : serial
4b000000-4b0000ff : /soc/power-controller at 4b000000
4d000000-4d0000ff : /soc/gpio at 4d000000
4e000000-4e0000ff : /soc/gpio at 4e000000
4f000000-4f0000ff : /soc/gpio at 4f000000
50000000-500000ff : /soc/pci at 50000000
58000000-5fffffff : Gemini PCI MEM
  58000000-58007fff : 0000:00:0c.0
    58000000-58007fff : 0000:00:0c.0
  58008000-580080ff : 0000:00:09.2
    58008000-580080ff : ehci_hcd

Well the EHCI USB hub works fine, I can mount and manage
files and the IRQs just keep ticking up. I can issue
iwlist wlan0 scanning and see all the WLANs here, I don't have
wpa_supplicant so have not tried connecting to them.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Gavin Guo <gavinguo at andestech.com>
Cc: Macpaul Lin <macpaul at andestech.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Rename the bridge and symbols to reflect Faraday technology
  as this IP block is clearly a Faraday block and not from
  Storlink/Storm/Cortina at all.
- Support both the regular and "dual" versions of the bridge,
  where the regular has a cascaded IRQ controller and the dual
  does not.
- Encode per-variant characteristics in a variant struct in
  the .data field of the OF match.
- Drop the pointless spinlock in the config space accessors.
- Drop manipulation of pcibios_min_io and pcibios_min_mem
- Get the IO range size from the device tree, and set up the
  bridge properly according to this. Currently we only support
  a 1MiB size IO range, but hey, it's at least dynamic and
  logical.

This can be merged to the PCI tree whenever it is considered
fine for inclusion.

Andestech and Faraday guys: you are more likely than me to
actually have documentation for this bridge. Please share with
me if you can, especially the register defintions, because I
want to set up IO and MEM windows properly from the device tree,
not just rely on defaults. There are defines for these registers
but no use or documentation.
---
 drivers/pci/host/Kconfig       |   5 +
 drivers/pci/host/Makefile      |   1 +
 drivers/pci/host/pci-faraday.c | 399 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 405 insertions(+)
 create mode 100644 drivers/pci/host/pci-faraday.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 898d2c48239c..ab5536101ffb 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -60,6 +60,11 @@ config PCI_EXYNOS
 	select PCIEPORTBUS
 	select PCIE_DW
 
+config PCI_FARADAY
+	bool "Faraday Technology PCI controller"
+	depends on OF
+	default ARCH_GEMINI
+
 config PCI_IMX6
 	bool "Freescale i.MX6 PCIe controller"
 	depends on SOC_IMX6Q
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index bfe3179ae74c..71bd839127a4 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
+obj-$(CONFIG_PCI_FARADAY) += pci-faraday.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_HYPERV) += pci-hyperv.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pci-faraday.c b/drivers/pci/host/pci-faraday.c
new file mode 100644
index 000000000000..29e893381c89
--- /dev/null
+++ b/drivers/pci/host/pci-faraday.c
@@ -0,0 +1,399 @@
+/*
+ * Support for Faraday Technologt PCI Controller
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij at linaro.org>
+ *
+ * Based on the out-of-tree OpenWRT patch for Cortina Gemini:
+ * Copyright (C) 2009 Janos Laube <janos.dev at gmail.com>
+ * Copyright (C) 2009 Paulius Zaleckas <paulius.zaleckas at teltonika.lt>
+ * Based on SL2312 PCI controller code
+ * Storlink (C) 2003
+ */
+
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/bitops.h>
+#include <linux/irq.h>
+
+#define FARADAY_PCI_IOSIZE_1M		0x0000
+
+#define FARADAY_PCI_PMC			0x40
+#define FARADAY_PCI_PMCSR		0x44
+#define FARADAY_PCI_CTRL1		0x48
+#define FARADAY_PCI_CTRL2		0x4C
+#define FARADAY_PCI_MEM1_BASE_SIZE	0x50
+#define FARADAY_PCI_MEM2_BASE_SIZE	0x54
+#define FARADAY_PCI_MEM3_BASE_SIZE	0x58
+
+#define PCI_CTRL2_INTSTS_SHIFT		28
+#define PCI_CTRL2_INTMASK_SHIFT		22
+
+#define FARADAY_PCI_DMA_MASK		0xFFF00000
+#define FARADAY_PCI_DMA_MEM1_BASE	0x00000000
+#define FARADAY_PCI_DMA_MEM2_BASE	0x00000000
+#define FARADAY_PCI_DMA_MEM3_BASE	0x00000000
+#define FARADAY_PCI_DMA_MEM1_SIZE	7
+#define FARADAY_PCI_DMA_MEM2_SIZE	6
+#define FARADAY_PCI_DMA_MEM3_SIZE	6
+
+#define PCI_CONF_ENABLE		BIT(31)
+#define PCI_CONF_WHERE(r)	((r) & 0xFC)
+#define PCI_CONF_BUS(b)		(((b) & 0xFF) << 16)
+#define PCI_CONF_DEVICE(d)	(((d) & 0x1F) << 11)
+#define PCI_CONF_FUNCTION(f)	(((f) & 0x07) << 8)
+
+/*
+ * Special configuration registers directly in the first few words
+ * in he I/O space.
+ */
+#define PCI_IOSIZE	0x00
+#define PCI_PROT	0x04
+#define PCI_CTRL	0x08
+#define PCI_SOFTRST	0x10
+#define PCI_CONFIG	0x28
+#define PCI_DATA	0x2C
+
+/**
+ * struct faraday_pci_variant - encodes IP block differences
+ * @cascaded_irq: this host has cascaded IRQs from an interrupt controller
+ *	embedded in the host bridge.
+ */
+struct faraday_pci_variant {
+	bool cascaded_irq;
+};
+
+struct faraday_pci {
+	struct device *dev;
+	void __iomem *base;
+	struct irq_domain *irqdomain;
+	struct pci_bus *bus;
+};
+
+static int faraday_pci_read_config(struct pci_bus *bus, unsigned int fn,
+				  int config, int size, u32 *value)
+{
+	struct faraday_pci *p = bus->sysdata;
+
+	writel(PCI_CONF_BUS(bus->number) |
+			PCI_CONF_DEVICE(PCI_SLOT(fn)) |
+			PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
+			PCI_CONF_WHERE(config) |
+			PCI_CONF_ENABLE,
+			p->base + PCI_CONFIG);
+
+	*value = readl(p->base + PCI_DATA);
+
+	if (size == 1)
+		*value = (*value >> (8 * (config & 3))) & 0xFF;
+	else if (size == 2)
+		*value = (*value >> (8 * (config & 3))) & 0xFFFF;
+
+	dev_dbg(&bus->dev,
+		"[read]  slt: %.2d, fnc: %d, cnf: 0x%.2X, val (%d bytes): 0x%.8X\n",
+		PCI_SLOT(fn), PCI_FUNC(fn), config, size, *value);
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int faraday_pci_write_config(struct pci_bus *bus, unsigned int fn,
+				   int config, int size, u32 value)
+{
+	struct faraday_pci *p = bus->sysdata;
+	int ret = PCIBIOS_SUCCESSFUL;
+
+	dev_dbg(&bus->dev,
+		"[write] slt: %.2d, fnc: %d, cnf: 0x%.2X, val (%d bytes): 0x%.8X\n",
+		PCI_SLOT(fn), PCI_FUNC(fn), config, size, value);
+
+	writel(PCI_CONF_BUS(bus->number) |
+			PCI_CONF_DEVICE(PCI_SLOT(fn)) |
+			PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
+			PCI_CONF_WHERE(config) |
+			PCI_CONF_ENABLE,
+			p->base + PCI_CONFIG);
+
+	switch (size) {
+	case 4:
+		writel(value, p->base + PCI_DATA);
+		break;
+	case 2:
+		writew(value, p->base + PCI_DATA + (config & 3));
+		break;
+	case 1:
+		writeb(value, p->base + PCI_DATA + (config & 3));
+		break;
+	default:
+		ret = PCIBIOS_BAD_REGISTER_NUMBER;
+	}
+
+	return ret;
+}
+
+static struct pci_ops faraday_pci_ops = {
+	.read	= faraday_pci_read_config,
+	.write	= faraday_pci_write_config,
+};
+
+static void faraday_pci_ack_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~(0xF << PCI_CTRL2_INTSTS_SHIFT);
+	reg |= BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTSTS_SHIFT);
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_mask_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~((0xF << PCI_CTRL2_INTSTS_SHIFT)
+		 | BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTMASK_SHIFT));
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_unmask_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~(0xF << PCI_CTRL2_INTSTS_SHIFT);
+	reg |= BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTMASK_SHIFT);
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_irq_handler(struct irq_desc *desc)
+{
+	struct faraday_pci *p = irq_desc_get_handler_data(desc);
+	struct irq_chip *irqchip = irq_desc_get_chip(desc);
+	unsigned int irq_stat, reg, i;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	irq_stat = reg >> PCI_CTRL2_INTSTS_SHIFT;
+
+	chained_irq_enter(irqchip, desc);
+
+	for (i = 0; i < 4; i++) {
+		if ((irq_stat & BIT(i)) == 0)
+			continue;
+		generic_handle_irq(irq_find_mapping(p->irqdomain, i));
+	}
+
+	chained_irq_exit(irqchip, desc);
+}
+
+static struct irq_chip faraday_pci_irq_chip = {
+	.name = "PCI",
+	.irq_ack = faraday_pci_ack_irq,
+	.irq_mask = faraday_pci_mask_irq,
+	.irq_unmask = faraday_pci_unmask_irq,
+};
+
+static int faraday_pci_irq_map(struct irq_domain *domain, unsigned int irq,
+			      irq_hw_number_t hwirq)
+{
+	irq_set_chip_and_handler(irq, &faraday_pci_irq_chip, handle_level_irq);
+	irq_set_chip_data(irq, domain->host_data);
+
+	return 0;
+}
+
+static const struct irq_domain_ops faraday_pci_irqdomain_ops = {
+	.map = faraday_pci_irq_map,
+};
+
+static int faraday_pci_setup_cascaded_irq(struct faraday_pci *p)
+{
+	struct device_node *intc = of_get_next_child(p->dev->of_node, NULL);
+	int irq;
+	int i;
+
+	if (!intc) {
+		dev_err(p->dev, "missing child interrupt-controller node\n");
+		return -EINVAL;
+	}
+
+	/* All PCI IRQs cascade off this one */
+	irq = of_irq_get(intc, 0);
+	if (!irq) {
+		dev_err(p->dev, "failed to get parent IRQ\n");
+		return -EINVAL;
+	}
+
+	p->irqdomain = irq_domain_add_linear(intc, 4,
+					     &faraday_pci_irqdomain_ops,
+					     p);
+	if (!p->irqdomain) {
+		dev_err(p->dev, "failed to create Gemini PCI IRQ domain\n");
+		return -EINVAL;
+	}
+
+	irq_set_chained_handler_and_data(irq, faraday_pci_irq_handler, p);
+
+	for (i = 0; i < 4; i++)
+		irq_create_mapping(p->irqdomain, i);
+
+	return 0;
+}
+
+static int faraday_pci_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct faraday_pci_variant *variant =
+		of_device_get_match_data(dev);
+	struct resource *regs;
+	resource_size_t io_base;
+	struct resource_entry *win;
+	struct faraday_pci *p;
+	struct resource *mem;
+	struct resource *io;
+	struct pci_bus *bus;
+	int ret;
+	u32 val;
+	LIST_HEAD(res);
+
+	p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL);
+	if (!p)
+		return -ENOMEM;
+
+	p->dev = dev;
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	p->base = devm_ioremap_resource(dev, regs);
+	if (IS_ERR(p->base))
+		return PTR_ERR(p->base);
+
+	ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
+					       &res, &io_base);
+	if (ret)
+		return ret;
+
+	ret = devm_request_pci_bus_resources(dev, &res);
+	if (ret)
+		return ret;
+
+	/* Get the I/O and memory ranges from DT */
+	resource_list_for_each_entry(win, &res) {
+		switch (resource_type(win->res)) {
+		case IORESOURCE_IO:
+			io = win->res;
+			io->name = "Gemini PCI I/O";
+			if (resource_size(io) == SZ_1M) {
+				/* setup I/O space to 1MB size */
+				writel(FARADAY_PCI_IOSIZE_1M,
+				       p->base + PCI_IOSIZE);
+			} else {
+				dev_err(dev,
+					"illegal IO mem size, must be 1 MiB\n");
+			}
+			ret = pci_remap_iospace(io, io_base);
+			if (ret) {
+				dev_warn(dev, "error %d: failed to map resource %pR\n",
+					 ret, io);
+				continue;
+			}
+			break;
+		case IORESOURCE_MEM:
+			mem = win->res;
+			mem->name = "Gemini PCI MEM";
+			break;
+		case IORESOURCE_BUS:
+			break;
+		default:
+			break;
+		}
+	}
+
+	/* Setup hostbridge */
+	val = readl(p->base + PCI_CTRL);
+	val |= PCI_COMMAND_IO;
+	val |= PCI_COMMAND_MEMORY;
+	val |= PCI_COMMAND_MASTER;
+	writel(val, p->base + PCI_CTRL);
+
+	bus = pci_scan_root_bus(&pdev->dev, 0, &faraday_pci_ops, p, &res);
+	if (!bus)
+		return -ENOMEM;
+	p->bus = bus;
+
+	dev_info(dev, "clear all IRQs\n");
+
+	/* Mask and clear all interrupts */
+	faraday_pci_write_config(bus, 0, FARADAY_PCI_CTRL2 + 2, 2, 0xF000);
+
+	if (variant->cascaded_irq) {
+		ret = faraday_pci_setup_cascaded_irq(p);
+		if (ret) {
+			dev_err(dev, "failed to setup cascaded IRQ\n");
+			return ret;
+		}
+	}
+
+	dev_info(dev, "setting up PCI DMA\n");
+	val = (FARADAY_PCI_DMA_MEM1_BASE & FARADAY_PCI_DMA_MASK)
+		| (FARADAY_PCI_DMA_MEM1_SIZE << 16);
+	faraday_pci_write_config(bus, 0, FARADAY_PCI_MEM1_BASE_SIZE, 4, val);
+	val = (FARADAY_PCI_DMA_MEM2_BASE & FARADAY_PCI_DMA_MASK)
+		| (FARADAY_PCI_DMA_MEM2_SIZE << 16);
+	faraday_pci_write_config(bus, 0, FARADAY_PCI_MEM2_BASE_SIZE, 4, val);
+	val = (FARADAY_PCI_DMA_MEM3_BASE & FARADAY_PCI_DMA_MASK)
+		| (FARADAY_PCI_DMA_MEM3_SIZE << 16);
+	faraday_pci_write_config(bus, 0, FARADAY_PCI_MEM3_BASE_SIZE, 4, val);
+
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+	pci_bus_assign_resources(bus);
+	pci_assign_unassigned_bus_resources(bus);
+	pci_bus_add_devices(bus);
+	pci_free_resource_list(&res);
+
+	return 0;
+}
+
+/*
+ * We encode bridge variants here, we have at least two so it doesn't
+ * hurt to have infrastructure to encompass future variants as well.
+ */
+const struct faraday_pci_variant faraday_regular = {
+	.cascaded_irq = true,
+};
+
+const struct faraday_pci_variant faraday_dual = {
+	.cascaded_irq = false,
+};
+
+static const struct of_device_id faraday_pci_of_match[] = {
+	{
+		.compatible = "faraday,pci",
+		.data = &faraday_regular,
+	},
+	{
+		.compatible = "faraday,pci-dual",
+		.data = &faraday_dual,
+	},
+	{},
+};
+
+static struct platform_driver faraday_pci_driver = {
+	.driver = {
+		.name = "gemini-pci",
+		.of_match_table = of_match_ptr(faraday_pci_of_match),
+	},
+	.probe  = faraday_pci_probe,
+};
+builtin_platform_driver(faraday_pci_driver);
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 07:52:19 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 13:52:19 +0100
Subject: [OpenWrt-Devel] [PATCH 3/4] ARM: gemini: select MIGHT_HAVE_PCI
In-Reply-To: <20170211125220.10273-1-linus.walleij@linaro.org>
References: <20170211125220.10273-1-linus.walleij@linaro.org>
Message-ID: <20170211125220.10273-3-linus.walleij@linaro.org>

As we have a PCI driver for the Gemini, we should select
MIGHT_HAVE_PCI.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Gavin Guo <gavinguo at andestech.com>
Cc: Macpaul Lin <macpaul at andestech.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/mach-gemini/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-gemini/Kconfig b/arch/arm/mach-gemini/Kconfig
index 798abb16bb88..91ea52ccf13c 100644
--- a/arch/arm/mach-gemini/Kconfig
+++ b/arch/arm/mach-gemini/Kconfig
@@ -5,6 +5,7 @@ menuconfig ARCH_GEMINI
 	select GEMINI_TIMER
 	select GPIO_GEMINI
 	select GPIOLIB
+	select MIGHT_HAVE_PCI
 	select POWER_RESET
 	select POWER_RESET_SYSCON
 	select SERIAL_OF_PLATFORM
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 07:52:20 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 13:52:20 +0100
Subject: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini device
	trees
In-Reply-To: <20170211125220.10273-1-linus.walleij@linaro.org>
References: <20170211125220.10273-1-linus.walleij@linaro.org>
Message-ID: <20170211125220.10273-4-linus.walleij@linaro.org>

The Cortina Gemini has an internal PCI root bus, add this to
the device tree, and add interrupt mapping (swizzling) to the
relevant systems device trees.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Gavin Guo <gavinguo at andestech.com>
Cc: Macpaul Lin <macpaul at andestech.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Change bus-range to <0x00 0xff>
- Drop the three extra IRQs that are unused
- Implement the right interrupt mapping/swizzling
- Push the interrupt mapping down to each affected system, only
  SQ201 for now.

PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/boot/dts/gemini-sq201.dts | 22 ++++++++++++++++++++++
 arch/arm/boot/dts/gemini.dtsi      | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
index dae2a70d8fbc..46309e79cc7b 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -92,5 +92,27 @@
 				read-only;
 			};
 		};
+
+		pci at 50000000 {
+			status = "okay";
+			interrupt-map-mask = <0xf800 0 0 7>;
+			interrupt-map =
+				<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+				<0x4800 0 0 2 &pci_intc 1>,
+				<0x4800 0 0 3 &pci_intc 2>,
+				<0x4800 0 0 4 &pci_intc 3>,
+				<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+				<0x5000 0 0 2 &pci_intc 2>,
+				<0x5000 0 0 3 &pci_intc 3>,
+				<0x5000 0 0 4 &pci_intc 0>,
+				<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+				<0x5800 0 0 2 &pci_intc 3>,
+				<0x5800 0 0 3 &pci_intc 0>,
+				<0x5800 0 0 4 &pci_intc 1>,
+				<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+				<0x6000 0 0 2 &pci_intc 0>,
+				<0x6000 0 0 3 &pci_intc 1>,
+				<0x6000 0 0 4 &pci_intc 2>;
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index ed2314a3a804..2eddc698795e 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -104,5 +104,37 @@
 			interrupt-controller;
 			#interrupt-cells = <2>;
 		};
+
+		pci at 50000000 {
+			compatible = "faraday,pci";
+			/*
+			 * The first 256 bytes in the IO range is actually used
+			 * to configure the host bridge.
+			 */
+			reg = <0x50000000 0x100>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			status = "disabled";
+
+			bus-range = <0x00 0xff>;
+			/* PCI ranges mappings */
+			ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
+			<0x01000000 0 0          0x50000000 0 0x00100000>,
+			/* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
+			<0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
+
+			/*
+			 * This PCI host bridge variant has a cascaded interrupt
+			 * controller embedded in the host bridge.
+			 */
+			pci_intc: interrupt-controller {
+				interrupt-parent = <&intcon>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#address-cells = <0>;
+				#interrupt-cells = <1>;
+			};
+		};
 	};
 };
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 11 08:20:25 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 11 Feb 2017 14:20:25 +0100
Subject: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT
	and multiplatform
In-Reply-To: <alpine.LNX.2.00.1701301702420.14503@T420s>
References: <20170122121506.9995-1-linus.walleij@linaro.org>
 <8e705d3a-ff99-23b2-c4c9-2edccf134cac@gmail.com>
 <CACRpkdbdsNU6pOcewyZw_jpXzXvm_aj0FURY7Ty5FkT227iZ=Q@mail.gmail.com>
 <alpine.LNX.2.00.1701241734140.2736@T420s>
 <CACRpkdY1A8QbKVV0-ZFeH-n0zYpmJkoGj5vA0Ov-DDhBTJf5_w@mail.gmail.com>
 <6a6f3b79-18d7-3243-6a5c-2dc9a3755aa9@gmail.com>
 <alpine.LNX.2.00.1701301702420.14503@T420s>
Message-ID: <CACRpkdbUOR76fjb_UvuiQHq22oAji8zwMAxmJV1dRA5V9DEQQw@mail.gmail.com>

On Mon, Jan 30, 2017 at 5:35 PM, Hans Ulli Kroll
<ulli.kroll at googlemail.com> wrote:
> On Tue, 24 Jan 2017, Florian Fainelli wrote:
>> On 01/24/2017 12:47 PM, Linus Walleij wrote:

>> >> This is a dual GMAC !
>> >>
>> >> They are two different base address for each GMAC and one shared
>> >> base address for both of them.
>> >> This is all in one address space which remaps the driver.
>> >>
>> >> And to make it worse two interrupt lines, one of them is also shared.
>> >>
>> >> Any ideas to "convert" this into DT ??
>> >> Because I think it's impossible to split both GMAC interfaces ??
>> >
>> > Sounds odd.  Yeah hardware.h lists this:
>> >
>> > #define GEMINI_TOE_BASE         0x60000000
>> > #define GEMINI_GMAC0_BASE       0x6000A000
>> > #define GEMINI_GMAC1_BASE       0x6000E000
>> >
>> > I guess one approach is to make a driver handling all of it in one,
>> > let it ioremap all regions and support one or two GMACs on the same
>> > TOE. More complex solutions is to share the TOE using
>> > syscons regmap mechanism but it looks cumbersome.
>> >
>> > {
>> >    compatible = "cortina,genesis-gmac-ethernet";
>> >    reg = <0x60000000 0xa000>, <0x6000a000 0x4000>, <0x6000e000 0x4000>;
>> >    interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <2 IRQ_TYPE_LEVEL_HIGH>;
>> > }
>> >
>> > Or something like that?
>
> For addresses, base is here, for both interfaces
> #define GEMINI_TOE_BASE                 0x60000000
> and now for each interface, offset to the above
> code is from the headerfile of the openwrt driver.
> #define TOE_GMAC_DMA_BASE(x)            (0x8000 + 0x4000 * (x))
> #define TOE_GMAC_BASE(x)                (0xA000 + 0x4000 * (x))
>
> maybe some other registers to
> #define TOE_NONTOE_QUE_HDR_BASE         0x2000
> #define TOE_TOE_QUE_HDR_BASE            0x3000
> #define TOE_V_BIT_BASE                  0x4000
> #define TOE_A_BIT_BASE                  0x6000
>
> AFAICR
> The TOE part was "invented" for the gigabit interface.
> They need to speed up the NIC because without TCP offloading you will get
> only fast ethernet speed on a gigabit NIC.

I was suspecting that this ethernet is related to the Faraday ethernet driver
that was merged in drivers/net/ethernet/faraday since so many other
Gemini parts seems to be coming essentially directly from Faraday.

I looked through the header files etc there but the registers seem quite
different ... :/

Still it is using the same "GMAC" naming and I strongly suspect this is
an older Faraday IP that should go into the same driver folder.

Cc:ing some Faraday and Andestech emails to see if we can get some
clarity in this. It would be nice if someone could atleast say "oh it's this
IP FTxxx from Faraday" so we know what to name it.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Sat Feb 11 12:57:26 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Sat, 11 Feb 2017 18:57:26 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT
 and multiplatform
In-Reply-To: <CACRpkdbUOR76fjb_UvuiQHq22oAji8zwMAxmJV1dRA5V9DEQQw@mail.gmail.com>
References: <20170122121506.9995-1-linus.walleij@linaro.org>
 <8e705d3a-ff99-23b2-c4c9-2edccf134cac@gmail.com>
 <CACRpkdbdsNU6pOcewyZw_jpXzXvm_aj0FURY7Ty5FkT227iZ=Q@mail.gmail.com>
 <alpine.LNX.2.00.1701241734140.2736@T420s>
 <CACRpkdY1A8QbKVV0-ZFeH-n0zYpmJkoGj5vA0Ov-DDhBTJf5_w@mail.gmail.com>
 <6a6f3b79-18d7-3243-6a5c-2dc9a3755aa9@gmail.com>
 <alpine.LNX.2.00.1701301702420.14503@T420s>
 <CACRpkdbUOR76fjb_UvuiQHq22oAji8zwMAxmJV1dRA5V9DEQQw@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1702111853460.32439@T420s>

HI Linus,

On Sat, 11 Feb 2017, Linus Walleij wrote:

> On Mon, Jan 30, 2017 at 5:35 PM, Hans Ulli Kroll
> <ulli.kroll at googlemail.com> wrote:
> > On Tue, 24 Jan 2017, Florian Fainelli wrote:
> >> On 01/24/2017 12:47 PM, Linus Walleij wrote:
> 
> >> >> This is a dual GMAC !
> >> >>
> >> >> They are two different base address for each GMAC and one shared
> >> >> base address for both of them.
> >> >> This is all in one address space which remaps the driver.
> >> >>
> >> >> And to make it worse two interrupt lines, one of them is also shared.
> >> >>
> >> >> Any ideas to "convert" this into DT ??
> >> >> Because I think it's impossible to split both GMAC interfaces ??
> >> >
> >> > Sounds odd.  Yeah hardware.h lists this:
> >> >
> >> > #define GEMINI_TOE_BASE         0x60000000
> >> > #define GEMINI_GMAC0_BASE       0x6000A000
> >> > #define GEMINI_GMAC1_BASE       0x6000E000
> >> >
> >> > I guess one approach is to make a driver handling all of it in one,
> >> > let it ioremap all regions and support one or two GMACs on the same
> >> > TOE. More complex solutions is to share the TOE using
> >> > syscons regmap mechanism but it looks cumbersome.
> >> >
> >> > {
> >> >    compatible = "cortina,genesis-gmac-ethernet";
> >> >    reg = <0x60000000 0xa000>, <0x6000a000 0x4000>, <0x6000e000 0x4000>;
> >> >    interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <2 IRQ_TYPE_LEVEL_HIGH>;
> >> > }
> >> >
> >> > Or something like that?
> >
> > For addresses, base is here, for both interfaces
> > #define GEMINI_TOE_BASE                 0x60000000
> > and now for each interface, offset to the above
> > code is from the headerfile of the openwrt driver.
> > #define TOE_GMAC_DMA_BASE(x)            (0x8000 + 0x4000 * (x))
> > #define TOE_GMAC_BASE(x)                (0xA000 + 0x4000 * (x))
> >
> > maybe some other registers to
> > #define TOE_NONTOE_QUE_HDR_BASE         0x2000
> > #define TOE_TOE_QUE_HDR_BASE            0x3000
> > #define TOE_V_BIT_BASE                  0x4000
> > #define TOE_A_BIT_BASE                  0x6000
> >
> > AFAICR
> > The TOE part was "invented" for the gigabit interface.
> > They need to speed up the NIC because without TCP offloading you will get
> > only fast ethernet speed on a gigabit NIC.
> 
> I was suspecting that this ethernet is related to the Faraday ethernet driver
> that was merged in drivers/net/ethernet/faraday since so many other
> Gemini parts seems to be coming essentially directly from Faraday.
> 
> I looked through the header files etc there but the registers seem quite
> different ... :/
> 
> Still it is using the same "GMAC" naming and I strongly suspect this is
> an older Faraday IP that should go into the same driver folder.
> 
> Cc:ing some Faraday and Andestech emails to see if we can get some
> clarity in this. It would be nice if someone could atleast say "oh it's this
> IP FTxxx from Faraday" so we know what to name it.
> 

I must look/seach for the nas2000 SDK, maybe this brings some light.

Greetings Hans Ulli Kroll
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nick at fishun.co.uk  Sat Feb 11 13:49:51 2017
From: nick at fishun.co.uk (Nick Malyon)
Date: Sat, 11 Feb 2017 18:49:51 +0000
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <CAJq09z7FZX-_gDiwChXWmP3iUBtOmfDrNrPOiQL9g+Ew+zv6VA@mail.gmail.com>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
 <CAJq09z7FZX-_gDiwChXWmP3iUBtOmfDrNrPOiQL9g+Ew+zv6VA@mail.gmail.com>
Message-ID: <CEFE1413-B648-477C-ACF3-967AEBC8AB59@fishun.co.uk>

Many thanks, I have reported this on the LEDE Project bug tracker as FS#499: https://bugs.lede-project.org/index.php?do=details&task_id=499 <https://bugs.lede-project.org/index.php?do=details&task_id=499>

> On 4 Feb 2017, at 00:25, Luiz Angelo Daros de Luca <luizluca at gmail.com> wrote:
> Nick, you can try lede-project bug tracker. I recently released rc1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170211/aa7ae521/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nick at fishun.co.uk  Sat Feb 11 13:55:20 2017
From: nick at fishun.co.uk (Nick Malyon)
Date: Sat, 11 Feb 2017 18:55:20 +0000
Subject: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if
 upstream network goes down
In-Reply-To: <YfNksWiYa7exrroFmpEhzbqRnjhapd74ZjQrwRG22199@mailpile>
References: <D3755E24-BD1F-4ED9-8B29-99BC01651D11@fishun.co.uk>
 <YfNksWiYa7exrroFmpEhzbqRnjhapd74ZjQrwRG22199@mailpile>
Message-ID: <67722779-32B4-4EEC-BC39-C5436FE5EA99@fishun.co.uk>

Luke, Karl,

Thanks for the slide switch workaround and explanation, I finally have a computer again so can try writing a button script.

Indeed very frustrating it won?t be fixed. I do think most users would expect their wifi access point not to suddenly disappear on them.

Two radios would indeed be a better option, just a shame you have to have this bad experience first to realise you should have packed one of several on your desk at home ;-)

Thanks all!
- Nick
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Sun Feb 12 14:57:19 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Sun, 12 Feb 2017 12:57:19 -0700
Subject: [OpenWrt-Devel] Observing procd progress
Message-ID: <19D3842A-D040-4848-BB53-CA7150B19D13@redfish-solutions.com>

One thing I was wondering about was, on a headless system, but that does have an LCD display, is maybe capturing the progress of procd as it runs and displaying it on that LCD.

Looking at /var/log/messages, I see:

2017-02-12T05:49:52+00:00 Powercode kernel:    4.660666] procd: - early -
2017-02-12T05:49:52+00:00 Powercode kernel:    5.253264] procd: - watchdog -
2017-02-12T05:49:52+00:00 Powercode kernel:    5.256546] procd: - ubus -
2017-02-12T05:49:52+00:00 Powercode kernel:    5.323323] procd: - init -
2017-02-12T05:50:28+00:00 Powercode procd: - init complete -

and I see where those are generated in the procd source.

I don?t see where procd communicates (logs) it?s progress that we could attach an observer.

Maybe in q_initd_run() where the DEBUG(2, ?start %s %s \n??) happens, and in q_initd_complete() where the DEBUG(2, ?stop %s %s \n?, ?) happens?

Hmm? for that matter, I also don?t know where procd does a wait() or wait3() or waitpid() on the rc.d/ scripts...

I?m not sufficiently versed in procd to guess at how to go about this.

Anyone else know?

Thanks,

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From arend.vanspriel at broadcom.com  Mon Feb 13 04:00:36 2017
From: arend.vanspriel at broadcom.com (Arend Van Spriel)
Date: Mon, 13 Feb 2017 10:00:36 +0100
Subject: [OpenWrt-Devel] luci issue with bleeding edge
Message-ID: <ce24a45e-005a-fb59-cb87-cf3b4a38a3ec@broadcom.com>

Hi,

I am trying to setup a openwrt environment for bleeding edge following
instruction here [1]. However, the build process gets stuck on luci-base:

make[3]: Entering directory
`/opt/arend/openwrt/feeds/luci/modules/luci-base'
install -d -m0755 /bin
install -m0755 src/po2lmo /bin/po2lmo
install: cannot create regular file '/bin/po2lmo': Permission denied
make[3]: ***
[/opt/arend/openwrt/staging_dir/target-arm_cortex-a9_musl-1.1.14_eabi/host/stamp/.luci-base_installed]
Error 1
make[3]: Leaving directory `/opt/arend/openwrt/feeds/luci/modules/luci-base'

Looking in the Makefile there I see:

define Host/Install
        $(INSTALL_DIR) $(1)/bin
        $(INSTALL_BIN) src/po2lmo $(1)/bin/po2lmo
        $(INSTALL_BIN) $(HOST_BUILD_DIR)/bin/LuaSrcDiet.lua
$(1)/bin/LuaSrcDiet
endef

So apparently $(1) is empty, but no clue why. Anyone observed this
before and more importantly do you have a fix for it?

Regards,
Arend

[1] wiki.openwrt.org/doc/howto/buildroot.exigence
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ulli.kroll at googlemail.com  Mon Feb 13 04:20:32 2017
From: ulli.kroll at googlemail.com (Hans Ulli Kroll)
Date: Mon, 13 Feb 2017 10:20:32 +0100 (CET)
Subject: [OpenWrt-Devel] [PATCH 00/22] Conversion of ARMv4 Gemini to DT
 and multiplatform
In-Reply-To: <FC5B4F97116B48439B455474D032A2F1087BAD65@FTCPCS74.faraday.com.tw>
References: <20170122121506.9995-1-linus.walleij@linaro.org>
 <8e705d3a-ff99-23b2-c4c9-2edccf134cac@gmail.com>
 <CACRpkdbdsNU6pOcewyZw_jpXzXvm_aj0FURY7Ty5FkT227iZ=Q@mail.gmail.com>
 <alpine.LNX.2.00.1701241734140.2736@T420s>
 <CACRpkdY1A8QbKVV0-ZFeH-n0zYpmJkoGj5vA0Ov-DDhBTJf5_w@mail.gmail.com>
 <6a6f3b79-18d7-3243-6a5c-2dc9a3755aa9@gmail.com>
 <alpine.LNX.2.00.1701301702420.14503@T420s>
 <CACRpkdbUOR76fjb_UvuiQHq22oAji8zwMAxmJV1dRA5V9DEQQw@mail.gmail.com>
 <alpine.LNX.2.00.1702111853460.32439@T420s>
 <FC5B4F97116B48439B455474D032A2F1087BAD65@FTCPCS74.faraday.com.tw>
Message-ID: <alpine.LNX.2.00.1702131013210.25980@T420s>

Hi John,

On Mon, 13 Feb 2017, John Feng-Hsin Chiang(???) wrote:

> Hi Hans,
> 
> > HI Linus,
> > 
> > On Sat, 11 Feb 2017, Linus Walleij wrote:
> > 
> > > On Mon, Jan 30, 2017 at 5:35 PM, Hans Ulli Kroll
> > > <ulli.kroll at googlemail.com> wrote:
> > > > On Tue, 24 Jan 2017, Florian Fainelli wrote:
> > > >> On 01/24/2017 12:47 PM, Linus Walleij wrote:
> > >
> > > >> >> This is a dual GMAC !
> > > >> >>
> > > >> >> They are two different base address for each GMAC and one shared
> > > >> >> base address for both of them.
> > > >> >> This is all in one address space which remaps the driver.
> > > >> >>
> > > >> >> And to make it worse two interrupt lines, one of them is also shared.
> > > >> >>
> > > >> >> Any ideas to "convert" this into DT ??
> > > >> >> Because I think it's impossible to split both GMAC interfaces ??
> > > >> >
> > > >> > Sounds odd.  Yeah hardware.h lists this:
> > > >> >
> > > >> > #define GEMINI_TOE_BASE         0x60000000
> > > >> > #define GEMINI_GMAC0_BASE       0x6000A000
> > > >> > #define GEMINI_GMAC1_BASE       0x6000E000
> > > >> >
> > > >> > I guess one approach is to make a driver handling all of it in
> > > >> > one, let it ioremap all regions and support one or two GMACs on
> > > >> > the same TOE. More complex solutions is to share the TOE using
> > > >> > syscons regmap mechanism but it looks cumbersome.
> > > >> >
> > > >> > {
> > > >> >    compatible = "cortina,genesis-gmac-ethernet";
> > > >> >    reg = <0x60000000 0xa000>, <0x6000a000 0x4000>,> <0x6000e000 0x4000>;
> > > >> >    interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <2> IRQ_TYPE_LEVEL_HIGH>;
> > > >> > }
> > > >> >
> > > >> > Or something like that?
> > > >
> > > > For addresses, base is here, for both interfaces
> > > > #define GEMINI_TOE_BASE                 0x60000000
> > > > and now for each interface, offset to the above code is from the
> > > > headerfile of the openwrt driver.
> > > > #define TOE_GMAC_DMA_BASE(x)            (0x8000 + 0x4000 * (x))
> > > > #define TOE_GMAC_BASE(x)                (0xA000 + 0x4000 * (x))
> > > >
> > > > maybe some other registers to
> > > > #define TOE_NONTOE_QUE_HDR_BASE         0x2000
> > > > #define TOE_TOE_QUE_HDR_BASE            0x3000
> > > > #define TOE_V_BIT_BASE                  0x4000
> > > > #define TOE_A_BIT_BASE                  0x6000
> > > >
> > > > AFAICR
> > > > The TOE part was "invented" for the gigabit interface.
> > > > They need to speed up the NIC because without TCP offloading you
> > > > will get only fast ethernet speed on a gigabit NIC.
> > >
> > > I was suspecting that this ethernet is related to the Faraday ethernet
> > > driver that was merged in drivers/net/ethernet/faraday since so many
> > > other Gemini parts seems to be coming essentially directly from Faraday.
> 
> 1. Faraday have no TOE design in GMAC, and the GMAC in Gemini is very old one (licensed to Storlink about 13 years ago)
> 2. Storlink may modify the GMC design and add TOE function in it to fit their SoC.
> 

Yeah, this was also my idea.
Storlink need to speed up their GMAC NIC, so they do some tricks here.

> > >
> > > I looked through the header files etc there but the registers seem
> > > quite different ... :/
> > >
> > > Still it is using the same "GMAC" naming and I strongly suspect this
> > > is an older Faraday IP that should go into the same driver folder.
> 
> Yes, This is not the same one as Faraday's.
> 
> > >
> > > Cc:ing some Faraday and Andestech emails to see if we can get some
> > > clarity in this. It would be nice if someone could atleast say "oh
> > > it's this IP FTxxx from Faraday" so we know what to name it.
> > >
> 
> You should think this IP is from Storlink
> 

I'll do. Thanks for the hint here, John.

Greetings
Hans Ulli Kroll
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From hannu.nyman at iki.fi  Mon Feb 13 05:21:51 2017
From: hannu.nyman at iki.fi (Hannu Nyman)
Date: Mon, 13 Feb 2017 12:21:51 +0200
Subject: [OpenWrt-Devel] luci issue with bleeding edge
In-Reply-To: <ce24a45e-005a-fb59-cb87-cf3b4a38a3ec@broadcom.com>
References: <ce24a45e-005a-fb59-cb87-cf3b4a38a3ec@broadcom.com>
Message-ID: <14a1677f-dbe1-35ea-c691-ff3325c82adb@iki.fi>

Arend Van Spriel wrote on Mon Feb 13 10:00:36 CET 2017:
 > install: cannot create regular file '/bin/po2lmo': Permission denied
 > ...
 > target-arm_cortex-a9_musl-1.1.14_eabi

Based on those lines you are using the stale source repo at git.openwrt.org 
that has not been updated for 7 months.

The instructions at your linked wiki page
wiki.openwrt.org/doc/howto/buildroot.exigence
point you to the current sources at Github:
https://github.com/openwrt/openwrt.git
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From mangesh at opennetware.com  Mon Feb 13 10:33:07 2017
From: mangesh at opennetware.com (Mangesh Bhamre)
Date: Mon, 13 Feb 2017 21:03:07 +0530
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
 <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
 <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>
Message-ID: <CAKhqrsA=h=1pm9U4fpKGD2og59O8+tJrJjJHZ_PQNPK+vajbTg@mail.gmail.com>

Hi Alex,

Looking at build log -
http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/dnscrypt-proxy/compile.txt

Tar ball is available on download.dnscrypt.org . Build download fails for
some SSL issue.

Also, tar ball is missing on mirror2.openwrt.org and
downloads.openwrt.org/sources

Not sure, how mirror2 or download.openwrt.org gets updated.  Any help in
getting is appreciated.

Regards,
Mangesh


On Sat, Feb 11, 2017 at 6:20 PM, Alexandru Ardelean <ardeleanalex at gmail.com>
wrote:

> If I got this correctly it's broken for that target as well
>
> http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/
>
> It looks like an issue with the source tar ball not being present in any
> OpenWrt mirror.
>
> Well, that was the error when it tried to build.
> Looks like dnscrypt-proxy was updated on the 7th of Feb 2017.
>
> No idea how the artifact caching works on OpenWrt buildbot.
>
> But, it could be that the issue may resolve itself, after triggering a
> rebuild.
> It doesn't look like it failed on all targets.
>
>
> On Sat, 11 Feb 2017 at 14:14, Mangesh Bhamre <mangesh at opennetware.com>
> wrote:
>
>> Hi Alex,
>>
>> ramips architecture. Mt7620 make file.
>>
>> Regards
>> Mangesh
>>
>> On 11-Feb-2017 4:56 PM, "Alexandru Ardelean" <ardeleanalex at gmail.com>
>> wrote:
>>
>> Hey Mangesh,
>>
>> So, I don't use much ImageBuilder.
>> I don't even know how that works.
>>
>> I usually just do
>>
>> < get OpenWrt repo >
>> ./scripts/feeds update packages
>> ./scripts/feeds install -a
>> make menuconfig
>> < select packages I need, configure arch, etc >
>> make V=99 -j8
>> < extract image from the bin directory >
>>
>> Looking through
>> https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy
>> It looks like dnscrypt-proxy should be there.
>> But that's just the Makefile that builds the package.
>>
>> Does ImageBuilder install pre-built packages from an OpenWrt mirror ?
>> Because on some architectures, dnscrypt-proxy looks broken.
>>
>> Example:
>> http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/
>> http://buildbot.openwrt.org:8010/broken_packages/kirkwood/
>> http://buildbot.openwrt.org:8010/broken_packages/bcm53xx/
>> http://buildbot.openwrt.org:8010/broken_packages/ar71xx.mikrotik/
>> http://buildbot.openwrt.org:8010/broken_packages/adm8668/
>>
>> On which architecture are you trying to build ?
>> I understand you're trying to build on CC 15.05.1
>>
>> So, a bit more info about your setup could help.
>>
>>
>> On Sat, Feb 11, 2017 at 7:35 AM, Mangesh Bhamre <mangesh at opennetware.com>
>> wrote:
>> > Hi Alex and OpenWRT Team,
>> >
>> > Any help on getting  dnscrypt-proxy package into snapshot will be
>> helpful.
>> > It is working fine with 15.05.1 - but not snapshot ImageBuilder.
>> >
>> > Regards,
>> > Mangesh Bhamre
>> >
>> > On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <
>> mangesh at opennetware.com>
>> > wrote:
>> >>
>> >> Hi Alex,
>> >>
>> >> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported
>> in
>> >> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
>> >> include while building with CC Image-builder.
>> >>
>> >> I scanned through all snapshot image-builder and no reference there. I
>> run
>> >> following command to build - same works fine for CC 15.05.1
>> >>
>> >> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
>> >> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
>> >>
>> >> Surely no typo there.
>> >>
>> >> Regards,
>> >> Mangesh
>> >>
>> >>
>> >> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean
>> >> <ardeleanalex at gmail.com> wrote:
>> >>>
>> >>> Do you have a Package/dnscrypt-proxy/install rule ?
>> >>> Are you calling the BuildPackage rule ?
>> >>>
>> >>> Do you have Package/dnscrypt-proxy/description rule ?
>> >>>
>> >>> And check for typos if above stuff is checked.
>> >>>
>> >>> Thanks
>> >>> Alex
>> >>>
>> >>>
>> >>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mangesh at opennetware.com>
>> >>> wrote:
>> >>>>
>> >>>> Hello OpenWRT team,
>> >>>>
>> >>>> I wish to bundle dnscrypt-proxy package using latest snapshot
>> >>>> Image-builder. I get below errors. Please recommend a fix or address
>> it in
>> >>>> snapshot.
>> >>>>
>> >>>> Collected errors:
>> >>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
>> >>>> Makefile:146: recipe for target 'package_install' failed
>> >>>>
>> >>>> Regards,
>> >>>> Mangesh
>> >>>> _______________________________________________
>> >>>> openwrt-devel mailing list
>> >>>> openwrt-devel at lists.openwrt.org
>> >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> >>
>> >>
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170213/1cb28b84/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ralph.sennhauser at gmail.com  Mon Feb 13 11:03:50 2017
From: ralph.sennhauser at gmail.com (Ralph Sennhauser)
Date: Mon, 13 Feb 2017 17:03:50 +0100
Subject: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot
In-Reply-To: <CAKhqrsA=h=1pm9U4fpKGD2og59O8+tJrJjJHZ_PQNPK+vajbTg@mail.gmail.com>
References: <CAKhqrsDqea0r_V1FCdOKk6to-1HFNJTxUq-wJ5OQbj_1ADqsFQ@mail.gmail.com>
 <CA+U=DspY0p3wn7Wdq4osEjpyWr2N6OT-aDBpC8nbOBnML9VLYQ@mail.gmail.com>
 <CAKhqrsBFK7T-sFDiiDT2Qs95_NtP_K0K5xVfcjTXCuGL+bo-nQ@mail.gmail.com>
 <CAKhqrsC_299aCHYnegi9+3Cxq+B9k5LNf5WDytmVM1OZKuRwEw@mail.gmail.com>
 <CA+U=DsqMe783cXjtRj=SGQHvE0OpVejFApm6W-hQGi=9OrNF_A@mail.gmail.com>
 <CAKhqrsB2EF2GUe7irexW_Lg3-v0PiqwVhKfeRCmaH_=7+fZk+Q@mail.gmail.com>
 <CA+U=DsoR17k5VBePDi9tvWUc07rqhWYRQxWFvSnanaUej=ZVRA@mail.gmail.com>
 <CAKhqrsA=h=1pm9U4fpKGD2og59O8+tJrJjJHZ_PQNPK+vajbTg@mail.gmail.com>
Message-ID: <20170213170350.572659eb@gmail.com>

On Mon, 13 Feb 2017 21:03:07 +0530
Mangesh Bhamre <mangesh at opennetware.com> wrote:

> Hi Alex,
> 
> Looking at build log -
> http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/dnscrypt-proxy/compile.txt
> 
> Tar ball is available on download.dnscrypt.org . Build download fails
> for some SSL issue.

The site has HSTS enabled. Might that be the issue?

Maybe just updating PKG_SOURCE_URL to use https might be all that
is needed. There was another user having issues with a redirect and
samba. I think he was using Ubuntu.

Ralph

> 
> Also, tar ball is missing on mirror2.openwrt.org and
> downloads.openwrt.org/sources
> 
> Not sure, how mirror2 or download.openwrt.org gets updated.  Any help
> in getting is appreciated.
> 
> Regards,
> Mangesh
> 
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Mon Feb 13 21:51:18 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Mon, 13 Feb 2017 19:51:18 -0700
Subject: [OpenWrt-Devel] [LEDE-DEV] Makefile question
In-Reply-To: <CAECwjAh8p24fCQmnN3qcFtW0WqpOjFTgKNi2T_YDTSJhJek4oQ@mail.gmail.com>
References: <E228D798-5CA0-4A9C-A9CA-7850C8A690FC@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702102129420.6590@qynat-yncgbc>
 <982A90C1-87F8-45ED-A701-468FB27A31B0@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702111928300.6590@qynat-yncgbc>
 <BA25CD41-ADA4-4988-BA90-718FB66D3C0A@redfish-solutions.com>
 <CAECwjAh8p24fCQmnN3qcFtW0WqpOjFTgKNi2T_YDTSJhJek4oQ@mail.gmail.com>
Message-ID: <F965135F-EFAE-46F3-BC8B-1EB0AE3F1FE0@redfish-solutions.com>


> On Feb 12, 2017, at 10:04 PM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> 
> On 13 February 2017 at 11:23, Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> 
>>> On Feb 11, 2017, at 8:29 PM, David Lang <david at lang.hm> wrote:
>>> 
>>> On Sat, 11 Feb 2017, Philip Prindeville wrote:
>>> 
>>>>> This can't eliminate the /etc/rc.d/S* files as it only adds files, and it's not as flexibile as adding a user or changing a password (as it would just let you replace the /etc/passwd, /etc/shadow files, not modify them).
>>>>> 
>>>>> If you look for where the /files/* are copied into the filesystem, that is probably the place you would want to add your scripting hooks.
>>>> 
>>>> Good idea.  I?ll look there.
>>> 
>>> Once you find this, may I suggest that you create /scripts/* and contribute the infrastructure to support it back upstream?
>>> 
>>> I have seen a lot of people wanting to do similar things.
>> 
>> 
>> Surprisingly, I?m still trying to find in the Makefiles where $(topdir)/files/ gets copied over?
>> 
>> -Philip
> 
> It's prepare_rootfs doing this job at the moment.
> 
>                yousong


Hi Yousong,

I?ve been working on both OpenWRT and LEDE and needed to get some hooks working in OpenWRT so I focused on that first.

These are the changes I made, but I couldn?t get it to work.

Was wondering if anyone can run with this.

Part of the problem is making package/Makefile recurse with additional arguments and a different working directory?  When I try to do this, the submake of package/Makefile gets run without inherited variables like $(INCLUDE_DIR), etc.

Also odd is even though the top of package/Makefile says:

curdir:=package

when it recurses $(curdir) retains some other value like ?target? or ?toolchain?.  Not sure why.

Any guidance appreciated.

-Philip


-------------- next part --------------
A non-text attachment was scrubbed...
Name: install-hooks.patch
Type: application/octet-stream
Size: 2346 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170213/b497f303/attachment.obj>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From yszhou4tech at gmail.com  Tue Feb 14 01:25:28 2017
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Tue, 14 Feb 2017 14:25:28 +0800
Subject: [OpenWrt-Devel] [LEDE-DEV] Makefile question
In-Reply-To: <F965135F-EFAE-46F3-BC8B-1EB0AE3F1FE0@redfish-solutions.com>
References: <E228D798-5CA0-4A9C-A9CA-7850C8A690FC@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702102129420.6590@qynat-yncgbc>
 <982A90C1-87F8-45ED-A701-468FB27A31B0@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702111928300.6590@qynat-yncgbc>
 <BA25CD41-ADA4-4988-BA90-718FB66D3C0A@redfish-solutions.com>
 <CAECwjAh8p24fCQmnN3qcFtW0WqpOjFTgKNi2T_YDTSJhJek4oQ@mail.gmail.com>
 <F965135F-EFAE-46F3-BC8B-1EB0AE3F1FE0@redfish-solutions.com>
Message-ID: <CAECwjAhAa7H5TJbEj0dRLH-eUVwnXJdUS37D520P2gTSji22sA@mail.gmail.com>

On 14 February 2017 at 10:51, Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:
>
>> On Feb 12, 2017, at 10:04 PM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>>
>> On 13 February 2017 at 11:23, Philip Prindeville
>> <philipp_subx at redfish-solutions.com> wrote:
>>>
>>>> On Feb 11, 2017, at 8:29 PM, David Lang <david at lang.hm> wrote:
>>>>
>>>> On Sat, 11 Feb 2017, Philip Prindeville wrote:
>>>>
>>>>>> This can't eliminate the /etc/rc.d/S* files as it only adds files, and it's not as flexibile as adding a user or changing a password (as it would just let you replace the /etc/passwd, /etc/shadow files, not modify them).
>>>>>>
>>>>>> If you look for where the /files/* are copied into the filesystem, that is probably the place you would want to add your scripting hooks.
>>>>>
>>>>> Good idea.  I?ll look there.
>>>>
>>>> Once you find this, may I suggest that you create /scripts/* and contribute the infrastructure to support it back upstream?
>>>>
>>>> I have seen a lot of people wanting to do similar things.
>>>
>>>
>>> Surprisingly, I?m still trying to find in the Makefiles where $(topdir)/files/ gets copied over?
>>>
>>> -Philip
>>
>> It's prepare_rootfs doing this job at the moment.
>>
>>                yousong
>
>
> Hi Yousong,
>
> I?ve been working on both OpenWRT and LEDE and needed to get some hooks working in OpenWRT so I focused on that first.
>
> These are the changes I made, but I couldn?t get it to work.
>
> Was wondering if anyone can run with this.
>
> Part of the problem is making package/Makefile recurse with additional arguments and a different working directory?  When I try to do this, the submake of package/Makefile gets run without inherited variables like $(INCLUDE_DIR), etc.

package/Makefile was included by $(TOPDIR)/Makefile which included
$(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but
not exported.

>
> Also odd is even though the top of package/Makefile says:
>
> curdir:=package
>
> when it recurses $(curdir) retains some other value like ?target? or ?toolchain?.  Not sure why.
>

No idea how this happened as I do not yet have time to check the patch
in details.  Does it take these values in a random way?

The other thing is if it's just about pre/post hooks, then I guess the
Build/IncludeOverlay mechanism should already fulfil most (if not all)
of your needs.

                yousong
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ynezz at true.cz  Tue Feb 14 04:45:55 2017
From: ynezz at true.cz (Petr =?iso-8859-2?Q?=A9tetiar?=)
Date: Tue, 14 Feb 2017 10:45:55 +0100
Subject: [OpenWrt-Devel] [LEDE-DEV] Observing procd progress
In-Reply-To: <19D3842A-D040-4848-BB53-CA7150B19D13@redfish-solutions.com>
References: <19D3842A-D040-4848-BB53-CA7150B19D13@redfish-solutions.com>
Message-ID: <20170214094555.GA21521@ibawizard.net>

Philip Prindeville <philipp_subx at redfish-solutions.com> [2017-02-12 12:57:19]:

Hi,

> One thing I was wondering about was, on a headless system, but that does
> have an LCD display, is maybe capturing the progress of procd as it runs and
> displaying it on that LCD.

BTW, what kind of platform and LCD is that?

I would probably get the total number of scripts planned to be run, the total
count, 100% on progress bar from glob() as it's used in rcS.c/_rc(). Then I
would probably update the position of the progress bar, the current % position
in q_initd_complete() callback.

> Maybe in q_initd_run() where the DEBUG(2, ?start %s %s \n??) happens, and in

Look at libubox/runqueue.c, search for '->run(' callback.

> q_initd_complete() where the DEBUG(2, ?stop %s %s \n?, ?) happens?

Look at libubox/runqueue.c, search for '->complete(' callback.

> Hmm? for that matter, I also don?t know where procd does a wait() or wait3()
> or waitpid() on the rc.d/ scripts...

procd is using runqueue task helper, which in turn uses uloop_process_*
functions, so look at libubox at runqueue.c and uloop.c for details.

-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Tue Feb 14 15:10:54 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Tue, 14 Feb 2017 13:10:54 -0700
Subject: [OpenWrt-Devel] [LEDE-DEV] Observing procd progress
In-Reply-To: <20170214094555.GA21521@ibawizard.net>
References: <19D3842A-D040-4848-BB53-CA7150B19D13@redfish-solutions.com>
 <20170214094555.GA21521@ibawizard.net>
Message-ID: <6654CE44-8579-4A2C-9B4F-908BE68AC1B6@redfish-solutions.com>


> On Feb 14, 2017, at 2:45 AM, Petr ?tetiar <ynezz at true.cz> wrote:
> 
> Philip Prindeville <philipp_subx at redfish-solutions.com> [2017-02-12 12:57:19]:
> 
> Hi,
> 
>> One thing I was wondering about was, on a headless system, but that does
>> have an LCD display, is maybe capturing the progress of procd as it runs and
>> displaying it on that LCD.
> 
> BTW, what kind of platform and LCD is that?


It?s a Lanner network appliance FW-8771 with an ST-7066U LCD module.

The module is hd44780 compatible, but with LCM-162-like wiring (at least that?s the interface type I select in lcdproc).


> I would probably get the total number of scripts planned to be run, the total
> count, 100% on progress bar from glob() as it's used in rcS.c/_rc(). Then I
> would probably update the position of the progress bar, the current % position
> in q_initd_complete() callback.


I?m more interested in knowing the name of a particular script should it cause the boot process to hang?  but maybe both could be done.


> 
>> Maybe in q_initd_run() where the DEBUG(2, ?start %s %s \n??) happens, and in
> 
> Look at libubox/runqueue.c, search for '->run(' callback.
> 
>> q_initd_complete() where the DEBUG(2, ?stop %s %s \n?, ?) happens?
> 
> Look at libubox/runqueue.c, search for '->complete(' callback.


Thanks.


> 
>> Hmm? for that matter, I also don?t know where procd does a wait() or wait3()
>> or waitpid() on the rc.d/ scripts...
> 
> procd is using runqueue task helper, which in turn uses uloop_process_*
> functions, so look at libubox at runqueue.c and uloop.c for details.
> 
> ? ynezz


Will do!

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Tue Feb 14 17:33:30 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Tue, 14 Feb 2017 15:33:30 -0700
Subject: [OpenWrt-Devel] [LEDE-DEV] Makefile question
In-Reply-To: <CAECwjAhAa7H5TJbEj0dRLH-eUVwnXJdUS37D520P2gTSji22sA@mail.gmail.com>
References: <E228D798-5CA0-4A9C-A9CA-7850C8A690FC@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702102129420.6590@qynat-yncgbc>
 <982A90C1-87F8-45ED-A701-468FB27A31B0@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702111928300.6590@qynat-yncgbc>
 <BA25CD41-ADA4-4988-BA90-718FB66D3C0A@redfish-solutions.com>
 <CAECwjAh8p24fCQmnN3qcFtW0WqpOjFTgKNi2T_YDTSJhJek4oQ@mail.gmail.com>
 <F965135F-EFAE-46F3-BC8B-1EB0AE3F1FE0@redfish-solutions.com>
 <CAECwjAhAa7H5TJbEj0dRLH-eUVwnXJdUS37D520P2gTSji22sA@mail.gmail.com>
Message-ID: <791B17DF-D1DE-42E7-AEEF-B7E195C6F383@redfish-solutions.com>


> On Feb 13, 2017, at 11:25 PM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> 
> On 14 February 2017 at 10:51, Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> 
>> Hi Yousong,
>> 
>> I?ve been working on both OpenWRT and LEDE and needed to get some hooks working in OpenWRT so I focused on that first.
>> 
>> These are the changes I made, but I couldn?t get it to work.
>> 
>> Was wondering if anyone can run with this.
>> 
>> Part of the problem is making package/Makefile recurse with additional arguments and a different working directory?  When I try to do this, the submake of package/Makefile gets run without inherited variables like $(INCLUDE_DIR), etc.
> 
> package/Makefile was included by $(TOPDIR)/Makefile which included
> $(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but
> not exported.


Okay, so just add ?export INCLUDE_DIR? and I?m done?


> 
>> 
>> Also odd is even though the top of package/Makefile says:
>> 
>> curdir:=package
>> 
>> when it recurses $(curdir) retains some other value like ?target? or ?toolchain?.  Not sure why.
>> 
> 
> No idea how this happened as I do not yet have time to check the patch
> in details.  Does it take these values in a random way?

On two different runs, I seem to remember them being either value.  And that was with -j1 so it?s not a parallelism indeterminism.


> 
> The other thing is if it's just about pre/post hooks, then I guess the
> Build/IncludeOverlay mechanism should already fulfil most (if not all)
> of your needs.
> 
>                yousong


Well, I need to get things working with OpenWRT and then move the entire product over to LEDE.

Are you on IRC?

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From yszhou4tech at gmail.com  Tue Feb 14 21:09:31 2017
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Wed, 15 Feb 2017 10:09:31 +0800
Subject: [OpenWrt-Devel] [LEDE-DEV] Makefile question
In-Reply-To: <791B17DF-D1DE-42E7-AEEF-B7E195C6F383@redfish-solutions.com>
References: <E228D798-5CA0-4A9C-A9CA-7850C8A690FC@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702102129420.6590@qynat-yncgbc>
 <982A90C1-87F8-45ED-A701-468FB27A31B0@redfish-solutions.com>
 <nycvar.QRO.7.75.62.1702111928300.6590@qynat-yncgbc>
 <BA25CD41-ADA4-4988-BA90-718FB66D3C0A@redfish-solutions.com>
 <CAECwjAh8p24fCQmnN3qcFtW0WqpOjFTgKNi2T_YDTSJhJek4oQ@mail.gmail.com>
 <F965135F-EFAE-46F3-BC8B-1EB0AE3F1FE0@redfish-solutions.com>
 <CAECwjAhAa7H5TJbEj0dRLH-eUVwnXJdUS37D520P2gTSji22sA@mail.gmail.com>
 <791B17DF-D1DE-42E7-AEEF-B7E195C6F383@redfish-solutions.com>
Message-ID: <CAECwjAg7fNS+G1+OSxkLJ9vjSf2z1cTqfUf+-MbXECVY9N4mTA@mail.gmail.com>

On 15 February 2017 at 06:33, Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:

[...]

>>>
>>> Part of the problem is making package/Makefile recurse with additional arguments and a different working directory?  When I try to do this, the submake of package/Makefile gets run without inherited variables like $(INCLUDE_DIR), etc.
>>
>> package/Makefile was included by $(TOPDIR)/Makefile which included
>> $(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but
>> not exported.
>
>
> Okay, so just add ?export INCLUDE_DIR? and I?m done?
>

It should work, but if there are other ways around, imho, minimal
usage of global export is preferred to avoid cluttering the
environment.

[...]

>>
>> The other thing is if it's just about pre/post hooks, then I guess the
>> Build/IncludeOverlay mechanism should already fulfil most (if not all)
>> of your needs.
>>
>>                yousong
>
>
> Well, I need to get things working with OpenWRT and then move the entire product over to LEDE.

That Build/IncludeOverlay is also available in OpenWrt as it was there
since 2009-08-31

>
> Are you on IRC?
>

most of the time, no.  I got the impression that I needed to check it
fairly frequently to not miss a call...  It's a distraction I'd like
to avoid ;)

                yousong
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From Alexey.Brodkin at synopsys.com  Wed Feb 15 05:11:45 2017
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 15 Feb 2017 13:11:45 +0300
Subject: [OpenWrt-Devel] [PATCH] packages: Use https instead of git
Message-ID: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>

From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>

On some [especially corporate] networks non-standard ports are blocked
and git is one of them. So switch to more convenient https transport.

Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
---
 libs/dmx_usb_module/Makefile  | 2 +-
 libs/libhttp-parser/Makefile  | 2 +-
 libs/libsoxr/Makefile         | 2 +-
 libs/protobuf-c/Makefile      | 2 +-
 libs/yajl/Makefile            | 2 +-
 net/acme/Makefile             | 2 +-
 net/coova-chilli/Makefile     | 2 +-
 net/horst/Makefile            | 2 +-
 net/linuxptp/Makefile         | 2 +-
 net/lispmob/Makefile          | 2 +-
 net/mii-tool/Makefile         | 2 +-
 net/opentracker/Makefile      | 2 +-
 net/port-mirroring/Makefile   | 2 +-
 net/wifidog/Makefile          | 2 +-
 sound/forked-daapd/Makefile   | 2 +-
 sound/shairplay/Makefile      | 2 +-
 sound/shairport-sync/Makefile | 2 +-
 sound/shairport/Makefile      | 2 +-
 utils/acl/Makefile            | 2 +-
 utils/ap51-flash/Makefile     | 2 +-
 utils/ecdsautils/Makefile     | 2 +-
 utils/evtest/Makefile         | 2 +-
 utils/mbtools/Makefile        | 2 +-
 utils/openocd/Makefile        | 2 +-
 utils/pps-tools/Makefile      | 2 +-
 utils/rtklib/Makefile         | 2 +-
 utils/rtl-sdr/Makefile        | 2 +-
 utils/sispmctl/Makefile       | 2 +-
 utils/triggerhappy/Makefile   | 2 +-
 29 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/libs/dmx_usb_module/Makefile b/libs/dmx_usb_module/Makefile
index d9e458fbe7eb..4487437d3f88 100644
--- a/libs/dmx_usb_module/Makefile
+++ b/libs/dmx_usb_module/Makefile
@@ -14,7 +14,7 @@ PKG_RELEASE:=0.1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/lowlander/dmx_usb_module.git
+PKG_SOURCE_URL:=https://github.com/lowlander/dmx_usb_module.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=ee99ca7edbd9e093480ad63341ac007394047bde
 PKG_MAINTAINER:=Martijn Zilverschoon <martijn at friedzombie.com>
diff --git a/libs/libhttp-parser/Makefile b/libs/libhttp-parser/Makefile
index fe28b4cab263..db0a201f4867 100644
--- a/libs/libhttp-parser/Makefile
+++ b/libs/libhttp-parser/Makefile
@@ -16,7 +16,7 @@ PKG_LICENSE_FILES:=LICENSE-MIT
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/joyent/http-parser.git
+PKG_SOURCE_URL:=https://github.com/nodejs/http-parser.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=56f7ad0e2e5a80f79d214015c91e1f17d11d109f
 
diff --git a/libs/libsoxr/Makefile b/libs/libsoxr/Makefile
index 9881fbb9d871..52cbf4779baf 100644
--- a/libs/libsoxr/Makefile
+++ b/libs/libsoxr/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=0.1.1
 PKG_RELEASE:=3
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.code.sf.net/p/soxr/code
+PKG_SOURCE_URL:=https://git.code.sf.net/p/soxr/code
 PKG_SOURCE_VERSION:=$(PKG_VERSION)
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/libs/protobuf-c/Makefile b/libs/protobuf-c/Makefile
index 16b2f2be326e..e2d17c06ee16 100644
--- a/libs/protobuf-c/Makefile
+++ b/libs/protobuf-c/Makefile
@@ -13,7 +13,7 @@ PKG_RELEASE:=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/protobuf-c/protobuf-c.git
+PKG_SOURCE_URL:=https://github.com/protobuf-c/protobuf-c.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=$(PKG_VERSION)
 
diff --git a/libs/yajl/Makefile b/libs/yajl/Makefile
index f9a2877a034e..79bf9b6bc01b 100644
--- a/libs/yajl/Makefile
+++ b/libs/yajl/Makefile
@@ -18,7 +18,7 @@ PKG_REV:=66cb08ca2ad8581080b626a75dfca266a890afb2
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
-PKG_SOURCE_URL:=git://github.com/lloyd/yajl.git
+PKG_SOURCE_URL:=https://github.com/lloyd/yajl.git
 PKG_SOURCE_PROTO:=git
 
 include $(INCLUDE_DIR)/package.mk
diff --git a/net/acme/Makefile b/net/acme/Makefile
index 9d35f8005fcd..a75b5b5bafc4 100644
--- a/net/acme/Makefile
+++ b/net/acme/Makefile
@@ -14,7 +14,7 @@ PKG_RELEASE:=1
 PKG_LICENSE:=GPLv3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_RELEASE).tar.xz
-PKG_SOURCE_URL:=git://github.com/Neilpang/acme.sh.git
+PKG_SOURCE_URL:=https://github.com/Neilpang/acme.sh.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_RELEASE)
 PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)-$(PKG_RELEASE)
diff --git a/net/coova-chilli/Makefile b/net/coova-chilli/Makefile
index b926a1d0843d..ed54eb010ed2 100644
--- a/net/coova-chilli/Makefile
+++ b/net/coova-chilli/Makefile
@@ -15,7 +15,7 @@ PKG_LICENSE_FILES:=COPYING
 PKG_RELEASE:=4
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/coova/coova-chilli
+PKG_SOURCE_URL:=https://github.com/coova/coova-chilli
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=b93de20a288c01c2ba28e96e31ad6da01627f45f
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/net/horst/Makefile b/net/horst/Makefile
index 1eb7409c0a7b..0f6988dbdbda 100644
--- a/net/horst/Makefile
+++ b/net/horst/Makefile
@@ -13,7 +13,7 @@ PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-git.tar.gz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/br101/horst.git
+PKG_SOURCE_URL:=https://github.com/br101/horst.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=version-$(PKG_VERSION)
 
diff --git a/net/linuxptp/Makefile b/net/linuxptp/Makefile
index 6128521881e1..a5e654e1482d 100644
--- a/net/linuxptp/Makefile
+++ b/net/linuxptp/Makefile
@@ -14,7 +14,7 @@ PKG_REV:=891d56e4292653c5c19ac8345159a1f1f5b2df26
 
 PKG_MAINTAINER:=Wojciech Dubowik <Wojciech.Dubowik at neratec.com>
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=git://git.code.sf.net/p/linuxptp/code
+PKG_SOURCE_URL:=https://git.code.sf.net/p/linuxptp/code
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
 PKG_SOURCE_PROTO:=git
diff --git a/net/lispmob/Makefile b/net/lispmob/Makefile
index b1776641ac82..acb348f73234 100644
--- a/net/lispmob/Makefile
+++ b/net/lispmob/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=0.4
 PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=git://github.com/LISPmob/lispmob.git
+PKG_SOURCE_URL:=https://github.com/LISPmob/lispmob.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
diff --git a/net/mii-tool/Makefile b/net/mii-tool/Makefile
index e9c793dbd60f..6634748d7d65 100644
--- a/net/mii-tool/Makefile
+++ b/net/mii-tool/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION=2016-10-06-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.code.sf.net/p/net-tools/code
+PKG_SOURCE_URL:=https://git.code.sf.net/p/net-tools/code
 PKG_SOURCE_VERSION:=115f1af2494ded1fcd21c8419d5e289bc4df380f
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/net/opentracker/Makefile b/net/opentracker/Makefile
index e47633211904..389b419ed30e 100644
--- a/net/opentracker/Makefile
+++ b/net/opentracker/Makefile
@@ -15,7 +15,7 @@ PKG_MAINTAINER:=Daniel Golle <daniel at makrotopia.org>
 PKG_LICENSE:=Beerware
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=git://erdgeist.org/opentracker
+PKG_SOURCE_URL:=https://erdgeist.org/gitweb/opentracker
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
 PKG_SOURCE_PROTO:=git
diff --git a/net/port-mirroring/Makefile b/net/port-mirroring/Makefile
index fdc4b39d8369..b65cf895a38f 100644
--- a/net/port-mirroring/Makefile
+++ b/net/port-mirroring/Makefile
@@ -14,7 +14,7 @@ PKG_LICENSE:=BSD-2-Clause
 PKG_LICENSE_FILES:=LICENSE
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/mmaraya/port-mirroring.git
+PKG_SOURCE_URL:=https://github.com/mmaraya/port-mirroring.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=f6ead68b7760fa86e8da73ac1e062349f243ac93
 PKG_FIXUP:=autoreconf
diff --git a/net/wifidog/Makefile b/net/wifidog/Makefile
index 591f29107b29..d35eeadd521f 100644
--- a/net/wifidog/Makefile
+++ b/net/wifidog/Makefile
@@ -20,7 +20,7 @@ PKG_LICENSE_FILES:=COPYING
 
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/wifidog/wifidog-gateway.git
+PKG_SOURCE_URL:=https://github.com/wifidog/wifidog-gateway.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=1.3.0
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/sound/forked-daapd/Makefile b/sound/forked-daapd/Makefile
index b33bb44fbf40..a5775f3b58d4 100644
--- a/sound/forked-daapd/Makefile
+++ b/sound/forked-daapd/Makefile
@@ -15,7 +15,7 @@ PKG_REV:=1b6283752ed0b790a6658bed1f05946e1af193da
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/ejurgensen/forked-daapd.git
+PKG_SOURCE_URL:=https://github.com/ejurgensen/forked-daapd.git
 PKG_SOURCE_VERSION:=$(PKG_REV)
 
 PKG_BUILD_DEPENDS:=gperf/host
diff --git a/sound/shairplay/Makefile b/sound/shairplay/Makefile
index 191647c51e17..a0a1e1e91cb8 100644
--- a/sound/shairplay/Makefile
+++ b/sound/shairplay/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2016-01-01
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/juhovh/shairplay.git
+PKG_SOURCE_URL:=https://github.com/juhovh/shairplay.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=ce80e005908f41d0e6fde1c4a21e9cb8ee54007b
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/sound/shairport-sync/Makefile b/sound/shairport-sync/Makefile
index abec42156dcb..60f78d81a36c 100644
--- a/sound/shairport-sync/Makefile
+++ b/sound/shairport-sync/Makefile
@@ -11,7 +11,7 @@ PKG_VERSION:=2.8.6
 PKG_RELEASE:=2
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/mikebrady/shairport-sync.git
+PKG_SOURCE_URL:=https://github.com/mikebrady/shairport-sync.git
 PKG_SOURCE_VERSION:=$(PKG_VERSION)
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_VERSION).tar.gz
diff --git a/sound/shairport/Makefile b/sound/shairport/Makefile
index aeb63f793909..ea57b418a9f5 100644
--- a/sound/shairport/Makefile
+++ b/sound/shairport/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2014-10-28
 PKG_RELEASE:=2
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/abrasive/shairport.git
+PKG_SOURCE_URL:=https://github.com/abrasive/shairport.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=d679d19a4bd66cc220dabfd23ad748c34e95995c
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/utils/acl/Makefile b/utils/acl/Makefile
index 943958247efb..0c01b9e53d46 100644
--- a/utils/acl/Makefile
+++ b/utils/acl/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=20160519
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=git://git.sv.gnu.org/acl.git
+PKG_SOURCE_URL:=https://git0.savannah.gnu.org/r/acl.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
diff --git a/utils/ap51-flash/Makefile b/utils/ap51-flash/Makefile
index a30fa5d52683..0496c0420100 100644
--- a/utils/ap51-flash/Makefile
+++ b/utils/ap51-flash/Makefile
@@ -11,7 +11,7 @@ PKG_VERSION:=2016-10-16
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://dev.cloudtrax.com/ap51-flash.git
+PKG_SOURCE_URL:=https://dev.cloudtrax.com/git/ap51-flash.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=48b3fbac1c30c5968b2608eb09b53ea37c310a24
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
diff --git a/utils/ecdsautils/Makefile b/utils/ecdsautils/Makefile
index e5f3567a80d2..6f740b6ef4fd 100644
--- a/utils/ecdsautils/Makefile
+++ b/utils/ecdsautils/Makefile
@@ -13,7 +13,7 @@ PKG_RELEASE:=1
 PKG_REV:=07538893fb6c2a9539678c45f9dbbf1e4f222b46
 PKG_MAINTAINER:=Matthias Schiffer <mschiffer at universe-factory.net>
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_SOURCE_URL:=git://github.com/tcatm/$(PKG_NAME).git
+PKG_SOURCE_URL:=https://github.com/tcatm/$(PKG_NAME).git
 PKG_SOURCE_VERSION:=$(PKG_REV)
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_PROTO:=git
diff --git a/utils/evtest/Makefile b/utils/evtest/Makefile
index e85deeb4b4c5..9c6548a0b795 100644
--- a/utils/evtest/Makefile
+++ b/utils/evtest/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=1.33
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=git://anongit.freedesktop.org/evtest
+PKG_SOURCE_URL:=https://anongit.freedesktop.org/git/evtest.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
diff --git a/utils/mbtools/Makefile b/utils/mbtools/Makefile
index 109adc6f7101..643152b7b98c 100644
--- a/utils/mbtools/Makefile
+++ b/utils/mbtools/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=2014-10-29
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/webstack/mbtools
+PKG_SOURCE_URL:=https://github.com/webstack/mbtools
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=149e9c69cec180f18cf8781cf5285b97352bf719
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git a/utils/openocd/Makefile b/utils/openocd/Makefile
index 45901c531ece..2f3c2e5d7d34 100644
--- a/utils/openocd/Makefile
+++ b/utils/openocd/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=v0.10.0
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.code.sf.net/p/openocd/code
+PKG_SOURCE_URL:=https://git.code.sf.net/p/openocd/code
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/utils/pps-tools/Makefile b/utils/pps-tools/Makefile
index 578004d7b84d..fd6fdb0bff86 100644
--- a/utils/pps-tools/Makefile
+++ b/utils/pps-tools/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2014-08-01
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/ago/pps-tools
+PKG_SOURCE_URL:=https://github.com/ago/pps-tools
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=0deb9c7e135e9380a6d09e9d2e938a146bb698c8
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git a/utils/rtklib/Makefile b/utils/rtklib/Makefile
index 9d7ed6db8726..91fd7d6b7eab 100644
--- a/utils/rtklib/Makefile
+++ b/utils/rtklib/Makefile
@@ -11,7 +11,7 @@ PKG_VERSION:=2.4.3_b24
 PKG_RELEASE:=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/tomojitakasu/RTKLIB.git
+PKG_SOURCE_URL:=https://github.com/tomojitakasu/RTKLIB.git
 PKG_SOURCE_VERSION:=1cec90a9ffa424908ad1a4ca3d52f33f9b94d1f7
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
diff --git a/utils/rtl-sdr/Makefile b/utils/rtl-sdr/Makefile
index 37e7f848a738..edb129f3692d 100644
--- a/utils/rtl-sdr/Makefile
+++ b/utils/rtl-sdr/Makefile
@@ -11,7 +11,7 @@ PKG_VERSION:=0.5.3-20150608-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=2
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.osmocom.org/rtl-sdr.git
+PKG_SOURCE_URL:=https://git.osmocom.org/rtl-sdr
 PKG_SOURCE_VERSION:=e3c03f738f5aef4dc51e2b741fbdb542b9cc1bb1
 
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
diff --git a/utils/sispmctl/Makefile b/utils/sispmctl/Makefile
index ad6c1e3523f3..9455645c662e 100644
--- a/utils/sispmctl/Makefile
+++ b/utils/sispmctl/Makefile
@@ -15,7 +15,7 @@ PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=5ff4a05a5bcb6a64a9d6f77fed47014512f66b11
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://git.code.sf.net/p/sispmctl/git
+PKG_SOURCE_URL:=https://git.code.sf.net/p/sispmctl/git
 PKG_MAINTAINER:=Richard Kunze <richard.kunze at web.de>
 PKG_LICENSE:=GPL-2.0+
 
diff --git a/utils/triggerhappy/Makefile b/utils/triggerhappy/Makefile
index 97c6e90315d8..7e81dd088f35 100644
--- a/utils/triggerhappy/Makefile
+++ b/utils/triggerhappy/Makefile
@@ -13,7 +13,7 @@ PKG_REV:=7e5abc69f215678e93a6b999524981c8b40bdcd9
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=git://github.com/wertarbyte/triggerhappy
+PKG_SOURCE_URL:=https://github.com/wertarbyte/triggerhappy
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
-- 
2.7.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From Alexey.Brodkin at synopsys.com  Wed Feb 15 05:12:46 2017
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 15 Feb 2017 13:12:46 +0300
Subject: [OpenWrt-Devel] [PATCH] routing: Use https instead of git
Message-ID: <1487153566-7209-1-git-send-email-abrodkin@synopsys.com>

From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>

On some [especially corporate] networks non-standard ports are blocked
and git is one of them. So switch to more convenient https transport.

Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
---
 batmand/Makefile            | 2 +-
 bmx6/Makefile               | 2 +-
 bmx7/Makefile               | 2 +-
 mcproxy/Makefile            | 2 +-
 minimalist-pcproxy/Makefile | 2 +-
 mrd6/Makefile               | 2 +-
 nodogsplash/Makefile        | 2 +-
 ohybridproxy/Makefile       | 2 +-
 vis/Makefile                | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/batmand/Makefile b/batmand/Makefile
index b4ed30171041..425d35594303 100644
--- a/batmand/Makefile
+++ b/batmand/Makefile
@@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
 PKG_NAME:=batmand
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.open-mesh.org/batmand.git
+PKG_SOURCE_URL:=https://git.open-mesh.org/batmand.git
 PKG_REV:=b67a7087b51d7a5e90d27ac39116d1f57257c86e
 PKG_VERSION:=1440
 PKG_RELEASE:=0
diff --git a/bmx6/Makefile b/bmx6/Makefile
index 425c298cde13..52a83addafcc 100644
--- a/bmx6/Makefile
+++ b/bmx6/Makefile
@@ -29,7 +29,7 @@ PKG_NAME:=bmx6
 PKG_SOURCE_PROTO:=git
 
 #PKG_SOURCE_URL:=git://bmx6.net/bmx6.git
-PKG_SOURCE_URL:=git://github.com/axn/bmx6.git
+PKG_SOURCE_URL:=https://github.com/axn/bmx6.git
 
 PKG_REV:=2a87b770d3f9c254e3927dc159e2f425f2e0e83a
 PKG_VERSION:=r2015080701
diff --git a/bmx7/Makefile b/bmx7/Makefile
index 215ec727562c..ef3a0a1c7472 100644
--- a/bmx7/Makefile
+++ b/bmx7/Makefile
@@ -28,7 +28,7 @@ PKG_NAME:=bmx7
 PKG_SOURCE_PROTO:=git
 
 #PKG_SOURCE_URL:=git://bmx6.net/bmx6.git
-PKG_SOURCE_URL:=git://github.com/axn/bmx6.git
+PKG_SOURCE_URL:=https://github.com/axn/bmx6.git
 #PKG_SOURCE_URL:=file:///usr/src/bmx6/bmx6.git
 
 PKG_REV:=589ee21b49d370056a24d8931d663626608f3c12
diff --git a/mcproxy/Makefile b/mcproxy/Makefile
index c155055a0269..d709097d2e9a 100644
--- a/mcproxy/Makefile
+++ b/mcproxy/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=2014-12-31-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=3
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/mcproxy/mcproxy.git
+PKG_SOURCE_URL:=https://github.com/mcproxy/mcproxy.git
 PKG_MAINTAINER:=Steven Barth <cyrus at openwrt.org>
 PKG_LICENSE:=GPL-2.0+
 
diff --git a/minimalist-pcproxy/Makefile b/minimalist-pcproxy/Makefile
index 36faa8d802e4..8b8cf24c7bd4 100644
--- a/minimalist-pcproxy/Makefile
+++ b/minimalist-pcproxy/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2015-01-12-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/fingon/minimalist-pcproxy.git
+PKG_SOURCE_URL:=https://github.com/fingon/minimalist-pcproxy.git
 PKG_MAINTAINER:=Markus Stenberg <fingon at iki.fi>
 PKG_LICENSE:=GPL-2.0
 
diff --git a/mrd6/Makefile b/mrd6/Makefile
index a20ea26ab2a1..a617e5e90d0f 100644
--- a/mrd6/Makefile
+++ b/mrd6/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=2013-11-30-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/hugosantos/mrd6.git
+PKG_SOURCE_URL:=https://github.com/hugosantos/mrd6.git
 PKG_MAINTAINER:=Steven Barth <cyrus at openwrt.org>
 PKG_LICENSE:=GPL-2.0+
 
diff --git a/nodogsplash/Makefile b/nodogsplash/Makefile
index 971fbac8fe78..edadb8731608 100644
--- a/nodogsplash/Makefile
+++ b/nodogsplash/Makefile
@@ -14,7 +14,7 @@ PKG_RELEASE:=2
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)/
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=git://github.com/nodogsplash/nodogsplash.git
+PKG_SOURCE_URL:=https://github.com/nodogsplash/nodogsplash.git
 PKG_SOURCE_VERSION:=485d6dba05cce7a4ed87c28beaaf1199c0f832cf
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_BUILD_PARALLEL:=1
diff --git a/ohybridproxy/Makefile b/ohybridproxy/Makefile
index 7d88f5d862ec..ea23137f3111 100644
--- a/ohybridproxy/Makefile
+++ b/ohybridproxy/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2016-06-28-$(PKG_SOURCE_VERSION)
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/sbyx/ohybridproxy.git
+PKG_SOURCE_URL:=https://github.com/sbyx/ohybridproxy.git
 PKG_MAINTAINER:=Steven Barth <cyrus at openwrt.org>
 PKG_LICENSE:=GPL-2.0
 
diff --git a/vis/Makefile b/vis/Makefile
index 316224a39f27..af58f5e00390 100644
--- a/vis/Makefile
+++ b/vis/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
 PKG_NAME:=vis
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.open-mesh.org/vis.git
+PKG_SOURCE_URL:=https://git.open-mesh.org/vis.git
 PKG_REV:=e141311c6a4fc824efbad536c137ed279905d825
 PKG_VERSION:=1440
 PKG_RELEASE:=0
-- 
2.7.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From Alexey.Brodkin at synopsys.com  Wed Feb 15 05:13:29 2017
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 15 Feb 2017 13:13:29 +0300
Subject: [OpenWrt-Devel] [PATCH] telephony: Use https instead of git
Message-ID: <1487153609-7402-1-git-send-email-abrodkin@synopsys.com>

From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>

On some [especially corporate] networks non-standard ports are blocked
and git is one of them. So switch to more convenient https transport.

Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
---
 net/rtpproxy/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rtpproxy/Makefile b/net/rtpproxy/Makefile
index 7b4fe90e9dc5..6f1e796b0502 100644
--- a/net/rtpproxy/Makefile
+++ b/net/rtpproxy/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2.0.0
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/sippy/rtpproxy.git
+PKG_SOURCE_URL:=https://github.com/sippy/rtpproxy.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=d5926892630139bcbe55d1f3fa36764c881648bc
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
-- 
2.7.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kaloz at openwrt.org  Wed Feb 15 07:20:04 2017
From: kaloz at openwrt.org (Imre Kaloz)
Date: Wed, 15 Feb 2017 13:20:04 +0100
Subject: [OpenWrt-Devel] [PATCH] packages: Use https instead of git
In-Reply-To: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
References: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
Message-ID: <a24f8e26-a975-bcec-a58b-dcf66a53f778@openwrt.org>

Hi Alexey,

On 2017-02-15 11:11, Alexey Brodkin wrote:
> From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
>
> On some [especially corporate] networks non-standard ports are blocked
> and git is one of them. So switch to more convenient https transport.
>
> Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>

Please make this a configuration option instead.


Thanks,

Imre
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From dwmw2 at infradead.org  Wed Feb 15 07:27:22 2017
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 Feb 2017 12:27:22 +0000
Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] packages: Use https instead
	of git
In-Reply-To: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
References: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
Message-ID: <1487161642.21974.50.camel@infradead.org>

On Wed, 2017-02-15 at 13:11 +0300, Alexey Brodkin wrote:
> 
> On some [especially corporate] networks non-standard ports are blocked
> and git is one of them. So switch to more convenient https transport.

Here's a nickel, kid. Get yourself a proper Internet connection.

Seriously, better to advocate that users take a cluebat to stupid
network admins, than to pander to this.

Make it git-only, and IPv6-only :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170215/43355824/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From dwmw2 at infradead.org  Wed Feb 15 07:29:04 2017
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 Feb 2017 12:29:04 +0000
Subject: [OpenWrt-Devel] [LEDE-DEV] [PATCH] packages: Use https instead
	of git
In-Reply-To: <1487161642.21974.50.camel@infradead.org>
References: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
 <1487161642.21974.50.camel@infradead.org>
Message-ID: <1487161744.21974.52.camel@infradead.org>

On Wed, 2017-02-15 at 12:27 +0000, David Woodhouse wrote:
> On Wed, 2017-02-15 at 13:11 +0300, Alexey Brodkin wrote:
> > 
> > 
> > On some [especially corporate] networks non-standard ports are blocked
> > and git is one of them. So switch to more convenient https transport.
> Here's a nickel, kid. Get yourself a proper Internet connection.
> 
> Seriously, better to advocate that users take a cluebat to stupid
> network admins, than to pander to this.
> 
> Make it git-only, and IPv6-only :)

Slightly more seriously, a configuration option for a proxy tool to use
for git might be worthwhile, to save users from having to set it up for
themselves. But then again, users in such broken networks will probably
already have done so, won't they?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170215/77172c92/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From Alexey.Brodkin at synopsys.com  Wed Feb 15 07:30:32 2017
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 15 Feb 2017 12:30:32 +0000
Subject: [OpenWrt-Devel] [PATCH] packages: Use https instead of git
In-Reply-To: <a24f8e26-a975-bcec-a58b-dcf66a53f778@openwrt.org>
References: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
 <a24f8e26-a975-bcec-a58b-dcf66a53f778@openwrt.org>
Message-ID: <1487161832.20939.17.camel@synopsys.com>

Hi Imre,

On Wed, 2017-02-15 at 13:20 +0100, Imre Kaloz wrote:
> Hi Alexey,
> 
> On 2017-02-15 11:11, Alexey Brodkin wrote:
> > 
> > From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
> > 
> > On some [especially corporate] networks non-standard ports are blocked
> > and git is one of them. So switch to more convenient https transport.
> > 
> > Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
> 
> Please make this a configuration option instead.

Why add another option?
What is a difference between https vs git for getting stuff from git repos?
As long as you don't need to push your commits https is fine.
But given we just pack tarballs from git repos there's no sense in pure git
protocol, no?

-Alexey
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From nbd at nbd.name  Wed Feb 15 07:32:55 2017
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 15 Feb 2017 13:32:55 +0100
Subject: [OpenWrt-Devel] [PATCH] packages: Use https instead of git
In-Reply-To: <a24f8e26-a975-bcec-a58b-dcf66a53f778@openwrt.org>
References: <1487153505-6985-1-git-send-email-abrodkin@synopsys.com>
 <a24f8e26-a975-bcec-a58b-dcf66a53f778@openwrt.org>
Message-ID: <c0c2380a-d890-8a80-817d-1657e593a308@nbd.name>

On 2017-02-15 13:20, Imre Kaloz wrote:
> Hi Alexey,
> 
> On 2017-02-15 11:11, Alexey Brodkin wrote:
>> From: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
>>
>> On some [especially corporate] networks non-standard ports are blocked
>> and git is one of them. So switch to more convenient https transport.
>>
>> Signed-off-by: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
> 
> Please make this a configuration option instead.
Please don't. Adding a configuration option for this is a waste of time
and only makes makefiles more convoluted.

This stuff is pretty much a non-issue for all packages that have
PKG_MIRROR_HASH (or the legacy PKG_MIRROR_MD5SUM) option set.
The LEDE buildbot automatically uploads mirrored tarballs to a place
that's referenced by download.pl.

This means that only in the rare case of the package update being too
new (or a broken makefile) it will actually attempt to download from
git. In all other cases it will pull the mirrored tarball from the LEDE
server, which should work properly with garbage firewalls.

Now if these packages don't have PKG_MIRROR_HASH set properly, that's
something actually worth fixing :)

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

From arend.vanspriel at broadcom.com  Wed Feb 15 16:52:30 2017
From: arend.vanspriel at broadcom.com (Arend Van Spriel)
Date: Wed, 15 Feb 2017 22:52:30 +0100
Subject: [OpenWrt-Devel] luci issue with bleeding edge
In-Reply-To: <14a1677f-dbe1-35ea-c691-ff3325c82adb@iki.fi>
References: <ce24a45e-005a-fb59-cb87-cf3b4a38a3ec@broadcom.com>
 <14a1677f-dbe1-35ea-c691-ff3325c82adb@iki.fi>
Message-ID: <fddbaf98-1dc4-8e1e-7032-57a11a9df576@broadcom.com>



On 13-2-2017 11:21, Hannu Nyman wrote:
> Arend Van Spriel wrote on Mon Feb 13 10:00:36 CET 2017:
>> install: cannot create regular file '/bin/po2lmo': Permission denied
>> ...
>> target-arm_cortex-a9_musl-1.1.14_eabi
> 
> Based on those lines you are using the stale source repo at
> git.openwrt.org that has not been updated for 7 months.
> 
> The instructions at your linked wiki page
> wiki.openwrt.org/doc/howto/buildroot.exigence
> point you to the current sources at Github:
> https://github.com/openwrt/openwrt.git

I overlooked that. Thanks. Will give it a try.

Regards,
Arend
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From xbing6 at gmail.com  Fri Feb 17 01:40:37 2017
From: xbing6 at gmail.com (Xuebing Wang)
Date: Fri, 17 Feb 2017 14:40:37 +0800
Subject: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files
 into sysupgrade image?
Message-ID: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>

Hi Community and Alexandru:

I am using OpenWrt chaos_calmer for an Atheros based platform, we have a 
complicated Python application which takes time to run.
- On the target board, I can "python -m compileall ." for Python 
standard libraries in directories "/usr/lib/python2.7", and boot time 
can improve significantly.

Would you please advise how can I change in files 
feeds/packages/lang/python to byte-compile Python libraries and include 
.pyc files in the sysupgrade image?

I am using below packages:
CONFIG_PACKAGE_python-base=y
CONFIG_PACKAGE_python-light=y
CONFIG_PACKAGE_python-codecs=y
CONFIG_PACKAGE_python-openssl=y
CONFIG_PACKAGE_python-sqlite3=y
CONFIG_PACKAGE_python-logging=y

Thanks.
xuebing wang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Fri Feb 17 02:31:28 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Fri, 17 Feb 2017 09:31:28 +0200
Subject: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files
	into sysupgrade image?
In-Reply-To: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>
References: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>
Message-ID: <CA+U=DspxNsQrKjKN2bS-qfQJXTuh6ecQEF68h_pLhnWfpFhUbg@mail.gmail.com>

Oh.

This is an old topic.
Let me think about it, for a bit.

Quick q: which Python version are you using and from which repo/branch ?
I usually test against trunk.

Thanks
Alex

On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
> Hi Community and Alexandru:
>
> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
> complicated Python application which takes time to run.
> - On the target board, I can "python -m compileall ." for Python standard
> libraries in directories "/usr/lib/python2.7", and boot time can improve
> significantly.
>
> Would you please advise how can I change in files feeds/packages/lang/python
> to byte-compile Python libraries and include .pyc files in the sysupgrade
> image?
>
> I am using below packages:
> CONFIG_PACKAGE_python-base=y
> CONFIG_PACKAGE_python-light=y
> CONFIG_PACKAGE_python-codecs=y
> CONFIG_PACKAGE_python-openssl=y
> CONFIG_PACKAGE_python-sqlite3=y
> CONFIG_PACKAGE_python-logging=y
>
> Thanks.
> xuebing wang
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From xbing6 at gmail.com  Fri Feb 17 02:42:42 2017
From: xbing6 at gmail.com (Xuebing Wang)
Date: Fri, 17 Feb 2017 15:42:42 +0800
Subject: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files
 into sysupgrade image?
In-Reply-To: <CA+U=DspxNsQrKjKN2bS-qfQJXTuh6ecQEF68h_pLhnWfpFhUbg@mail.gmail.com>
References: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>
 <CA+U=DspxNsQrKjKN2bS-qfQJXTuh6ecQEF68h_pLhnWfpFhUbg@mail.gmail.com>
Message-ID: <c5b5d949-211a-16a2-6b13-a2360c8227e3@gmail.com>

Hi Alex,

Thanks a lot for your help.  I am using Python 2.7.12, branch 
chaos_calmer from (git://github.com/openwrt/openwrt.git), feeds branch 
is for-15.05.

Also, I am using Atheros platform based on MIPS architecture.

Thanks again.

xuebing wang

On 2017?02?17? 15:31, Alexandru Ardelean wrote:
> Oh.
>
> This is an old topic.
> Let me think about it, for a bit.
>
> Quick q: which Python version are you using and from which repo/branch ?
> I usually test against trunk.
>
> Thanks
> Alex
>
> On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
>> Hi Community and Alexandru:
>>
>> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
>> complicated Python application which takes time to run.
>> - On the target board, I can "python -m compileall ." for Python standard
>> libraries in directories "/usr/lib/python2.7", and boot time can improve
>> significantly.
>>
>> Would you please advise how can I change in files feeds/packages/lang/python
>> to byte-compile Python libraries and include .pyc files in the sysupgrade
>> image?
>>
>> I am using below packages:
>> CONFIG_PACKAGE_python-base=y
>> CONFIG_PACKAGE_python-light=y
>> CONFIG_PACKAGE_python-codecs=y
>> CONFIG_PACKAGE_python-openssl=y
>> CONFIG_PACKAGE_python-sqlite3=y
>> CONFIG_PACKAGE_python-logging=y
>>
>> Thanks.
>> xuebing wang
>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ardeleanalex at gmail.com  Fri Feb 17 10:37:58 2017
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Fri, 17 Feb 2017 17:37:58 +0200
Subject: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files
	into sysupgrade image?
In-Reply-To: <c5b5d949-211a-16a2-6b13-a2360c8227e3@gmail.com>
References: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>
 <CA+U=DspxNsQrKjKN2bS-qfQJXTuh6ecQEF68h_pLhnWfpFhUbg@mail.gmail.com>
 <c5b5d949-211a-16a2-6b13-a2360c8227e3@gmail.com>
Message-ID: <CA+U=DsrnYa5qZjPiP4fAmbxW1tbvv2ZtDwOu-zs_ntyrWMUXUw@mail.gmail.com>

@Xuebing: so, there doesn't seem to be a very easy way to do this at build time.
I mean, at first, it can seem easy, because all that is needed, is to
add script that compiles here:
https://github.com/openwrt/packages/blob/for-15.05/lang/python/files/python-package.mk#L94

That script needs to recursively compile all .py files and
[optionally]  remove them.
So, feel free to try/hack something for your case.

Maybe a shell script that uses this: http://effbot.org/zone/python-compile.htm

> compile.py
import os
import sys
import py_compile
for file in sys.argv:
    py_compile.compile(file)
    os.remove(file)

find . -name "\.py" | xargs compile.py


For the general case [in trunk], I think I have to start considering
splitting the Python source files and Python byte-compiled files into
2 package types.
There was a older discussion about this ; the idea is to package the
byte coded files, and offer the sources and python source packages.
Example: Have `python` package and `python-sources`  package.
`python` == byte-compiled .pyc files, `python-sources` .py files

Will try to make an effort in the next couple of days to implement the
general solution for this.
But, it's Friday now here, and I usually don't do much in the weekend.
So, hopefully next week I could allocate some time for this.

Thanks
Alex

On Fri, Feb 17, 2017 at 9:42 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
> Hi Alex,
>
> Thanks a lot for your help.  I am using Python 2.7.12, branch chaos_calmer
> from (git://github.com/openwrt/openwrt.git), feeds branch is for-15.05.
>
> Also, I am using Atheros platform based on MIPS architecture.
>
> Thanks again.
>
> xuebing wang
>
>
> On 2017?02?17? 15:31, Alexandru Ardelean wrote:
>>
>> Oh.
>>
>> This is an old topic.
>> Let me think about it, for a bit.
>>
>> Quick q: which Python version are you using and from which repo/branch ?
>> I usually test against trunk.
>>
>> Thanks
>> Alex
>>
>> On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
>>>
>>> Hi Community and Alexandru:
>>>
>>> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
>>> complicated Python application which takes time to run.
>>> - On the target board, I can "python -m compileall ." for Python standard
>>> libraries in directories "/usr/lib/python2.7", and boot time can improve
>>> significantly.
>>>
>>> Would you please advise how can I change in files
>>> feeds/packages/lang/python
>>> to byte-compile Python libraries and include .pyc files in the sysupgrade
>>> image?
>>>
>>> I am using below packages:
>>> CONFIG_PACKAGE_python-base=y
>>> CONFIG_PACKAGE_python-light=y
>>> CONFIG_PACKAGE_python-codecs=y
>>> CONFIG_PACKAGE_python-openssl=y
>>> CONFIG_PACKAGE_python-sqlite3=y
>>> CONFIG_PACKAGE_python-logging=y
>>>
>>> Thanks.
>>> xuebing wang
>>>
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From xbing6 at gmail.com  Fri Feb 17 18:26:09 2017
From: xbing6 at gmail.com (Xuebing Wang)
Date: Sat, 18 Feb 2017 07:26:09 +0800
Subject: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files
 into sysupgrade image?
In-Reply-To: <CA+U=DsrnYa5qZjPiP4fAmbxW1tbvv2ZtDwOu-zs_ntyrWMUXUw@mail.gmail.com>
References: <eef2636e-86fa-178c-aaca-3a0ef12a5127@gmail.com>
 <CA+U=DspxNsQrKjKN2bS-qfQJXTuh6ecQEF68h_pLhnWfpFhUbg@mail.gmail.com>
 <c5b5d949-211a-16a2-6b13-a2360c8227e3@gmail.com>
 <CA+U=DsrnYa5qZjPiP4fAmbxW1tbvv2ZtDwOu-zs_ntyrWMUXUw@mail.gmail.com>
Message-ID: <d08220bd-89e6-fb6a-af82-6f6fb49210c5@gmail.com>

Hi Alex,

Thank you so much for your help.

xuebing wang


On 2017?02?17? 23:37, Alexandru Ardelean wrote:
> @Xuebing: so, there doesn't seem to be a very easy way to do this at build time.
> I mean, at first, it can seem easy, because all that is needed, is to
> add script that compiles here:
> https://github.com/openwrt/packages/blob/for-15.05/lang/python/files/python-package.mk#L94
>
> That script needs to recursively compile all .py files and
> [optionally]  remove them.
> So, feel free to try/hack something for your case.
>
> Maybe a shell script that uses this: http://effbot.org/zone/python-compile.htm
>
>> compile.py
> import os
> import sys
> import py_compile
> for file in sys.argv:
>      py_compile.compile(file)
>      os.remove(file)
>
> find . -name "\.py" | xargs compile.py
>
>
> For the general case [in trunk], I think I have to start considering
> splitting the Python source files and Python byte-compiled files into
> 2 package types.
> There was a older discussion about this ; the idea is to package the
> byte coded files, and offer the sources and python source packages.
> Example: Have `python` package and `python-sources`  package.
> `python` == byte-compiled .pyc files, `python-sources` .py files
>
> Will try to make an effort in the next couple of days to implement the
> general solution for this.
> But, it's Friday now here, and I usually don't do much in the weekend.
> So, hopefully next week I could allocate some time for this.
>
> Thanks
> Alex
>
> On Fri, Feb 17, 2017 at 9:42 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
>> Hi Alex,
>>
>> Thanks a lot for your help.  I am using Python 2.7.12, branch chaos_calmer
>> from (git://github.com/openwrt/openwrt.git), feeds branch is for-15.05.
>>
>> Also, I am using Atheros platform based on MIPS architecture.
>>
>> Thanks again.
>>
>> xuebing wang
>>
>>
>> On 2017?02?17? 15:31, Alexandru Ardelean wrote:
>>> Oh.
>>>
>>> This is an old topic.
>>> Let me think about it, for a bit.
>>>
>>> Quick q: which Python version are you using and from which repo/branch ?
>>> I usually test against trunk.
>>>
>>> Thanks
>>> Alex
>>>
>>> On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbing6 at gmail.com> wrote:
>>>> Hi Community and Alexandru:
>>>>
>>>> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
>>>> complicated Python application which takes time to run.
>>>> - On the target board, I can "python -m compileall ." for Python standard
>>>> libraries in directories "/usr/lib/python2.7", and boot time can improve
>>>> significantly.
>>>>
>>>> Would you please advise how can I change in files
>>>> feeds/packages/lang/python
>>>> to byte-compile Python libraries and include .pyc files in the sysupgrade
>>>> image?
>>>>
>>>> I am using below packages:
>>>> CONFIG_PACKAGE_python-base=y
>>>> CONFIG_PACKAGE_python-light=y
>>>> CONFIG_PACKAGE_python-codecs=y
>>>> CONFIG_PACKAGE_python-openssl=y
>>>> CONFIG_PACKAGE_python-sqlite3=y
>>>> CONFIG_PACKAGE_python-logging=y
>>>>
>>>> Thanks.
>>>> xuebing wang
>>>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sat Feb 18 09:05:18 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 18 Feb 2017 15:05:18 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Cortina Gemini
	Host Bridge
In-Reply-To: <3658176.ffWihUmtIa@wuerfel>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <2695922.yyinjvNuJK@wuerfel>
 <CACRpkdb=BqihykWo3egtNW1VKE2-FV+nJQQVYOc2GdCvh1fMng@mail.gmail.com>
 <3658176.ffWihUmtIa@wuerfel>
Message-ID: <CACRpkdZ4OKCifVogYN3MCnyZ6y9U_Pg2tNsjy5f02wxGOykAhg@mail.gmail.com>

On Thu, Feb 16, 2017 at 3:08 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Saturday, February 4, 2017 7:43:15 PM CET Linus Walleij wrote:

> Did you notice my other comment below (quoting from my own
> message)?
>
>> > +
>> > +     bus = pci_scan_root_bus(&pdev->dev, 0, &gemini_pci_ops, p, &res);
>>
>> Can you try using the new pci_register_host_bridge() API?

Yes. It crashes badly when I try it so I'm still trying to figure this out...
If I do I will send an iteration.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From xbing6 at gmail.com  Tue Feb 21 01:55:37 2017
From: xbing6 at gmail.com (Xuebing Wang)
Date: Tue, 21 Feb 2017 14:55:37 +0800
Subject: [OpenWrt-Devel] [openwrt-devel] [linux-wireless] 802.11s mesh
 network can not recover after connectivity goes low and back up
Message-ID: <5272d739-1ac2-a892-9b52-889fde2861c4@gmail.com>

Hi Community,

I am using several routers (Atheros AR9331 + OpenWRT) to build a 802.11s 
mesh network. I am having an issue.
-  Linux kernel: 3.18.29
-  OpenWRT version / branch: chaos_calmer
-  Hardware platform: AR9331 with ath9k driver.

Description of the issue:
-  When connectivity of a mesh node is low and connection to other nodes 
is lost. After connectivity is back up again, ping other nodes won't get 
this node to recover to connect to its peers.
-  Test setup: most routers are in one room, with one specific router in 
another room to simulate low connectivity.
-  I use 'iw wlan0 set txpower limit 0' to simulate low connectivity.
-  It's not easy to reproduce, occurrence rate is low.
-  I sometimes put a laptop to the isolated router and "ssh into this 
laptop" to generate some WiFi traffic (possible collisions).

Does anyone see the similar issue? Thanks.

xuebing wang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From kvalo at qca.qualcomm.com  Tue Feb 21 08:19:17 2017
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 21 Feb 2017 13:19:17 +0000
Subject: [OpenWrt-Devel] ATH10K VLAN firmware issue
In-Reply-To: <027001d28c42$5042c910$f0c85b30$@acksys.fr> (voncken's message of
 "Tue, 21 Feb 2017 13:59:18 +0100")
References: <773DB8A82AB6A046AE0195C68612A31901C5B293@sbs2003.acksys.local>
 <566849DB.9040901@candelatech.com>
 <079401d132a6$7e7e2050$7b7a60f0$@acksys.fr>
 <CABUTiXWg3t5qK6O5ooDE+4=Xk3Msybs5mu9+tQm_Bb0wdSrfWQ@mail.gmail.com>
 <87twbnueqv.fsf@kamboji.qca.qualcomm.com>
 <CABUTiXW5QSh2KkD+sQ-6QOD5zTce0dun+nyfAMnvL580U=OVNw@mail.gmail.com>
 <871syn5fnb.fsf@qca.qualcomm.com>
 <CABUTiXV8eFsW4MJET4spvjVQvFgi66NV7hLLxFC6Ttqs1znxjA@mail.gmail.com>
 <87polwq2nq.fsf@kamboji.qca.qualcomm.com>
 <027001d28c42$5042c910$f0c85b30$@acksys.fr>
Message-ID: <87efyrd6lv.fsf@kamboji.qca.qualcomm.com>

voncken <cedric.voncken at acksys.fr> writes:

> Do you know if the firmware team planned to fix the VLAN issue on ath10k
> firmware?

I reported it forward only this week.

-- 
Kalle Valo
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pozega.tomislav at gmail.com  Tue Feb 21 08:42:56 2017
From: pozega.tomislav at gmail.com (Tom Psyborg)
Date: Tue, 21 Feb 2017 14:42:56 +0100
Subject: [OpenWrt-Devel] ATH10K VLAN firmware issue
In-Reply-To: <87efyrd6lv.fsf@kamboji.qca.qualcomm.com>
References: <773DB8A82AB6A046AE0195C68612A31901C5B293@sbs2003.acksys.local>
 <566849DB.9040901@candelatech.com> <079401d132a6$7e7e2050$7b7a60f0$@acksys.fr>
 <CABUTiXWg3t5qK6O5ooDE+4=Xk3Msybs5mu9+tQm_Bb0wdSrfWQ@mail.gmail.com>
 <87twbnueqv.fsf@kamboji.qca.qualcomm.com>
 <CABUTiXW5QSh2KkD+sQ-6QOD5zTce0dun+nyfAMnvL580U=OVNw@mail.gmail.com>
 <871syn5fnb.fsf@qca.qualcomm.com>
 <CABUTiXV8eFsW4MJET4spvjVQvFgi66NV7hLLxFC6Ttqs1znxjA@mail.gmail.com>
 <87polwq2nq.fsf@kamboji.qca.qualcomm.com>
 <027001d28c42$5042c910$f0c85b30$@acksys.fr>
 <87efyrd6lv.fsf@kamboji.qca.qualcomm.com>
Message-ID: <CAKR_QVLpSWab-kF-f8=xqw+oWAfA966GDm7CtXrWfzmJz8gP-w@mail.gmail.com>

have you tried this one
https://forum.lede-project.org/t/new-qca988x-firmware-with-mesh-support/1587

On 21 February 2017 at 14:19, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:

> voncken <cedric.voncken at acksys.fr> writes:
>
> > Do you know if the firmware team planned to fix the VLAN issue on ath10k
> > firmware?
>
> I reported it forward only this week.
>
> --
> Kalle Valo
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170221/37c2f26f/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From baantunes at gmail.com  Tue Feb 21 11:47:13 2017
From: baantunes at gmail.com (Bruno Antunes)
Date: Tue, 21 Feb 2017 16:47:13 +0000
Subject: [OpenWrt-Devel] ATH10K VLAN firmware issue
In-Reply-To: <CAKR_QVLpSWab-kF-f8=xqw+oWAfA966GDm7CtXrWfzmJz8gP-w@mail.gmail.com>
References: <773DB8A82AB6A046AE0195C68612A31901C5B293@sbs2003.acksys.local>
 <566849DB.9040901@candelatech.com> <079401d132a6$7e7e2050$7b7a60f0$@acksys.fr>
 <CABUTiXWg3t5qK6O5ooDE+4=Xk3Msybs5mu9+tQm_Bb0wdSrfWQ@mail.gmail.com>
 <87twbnueqv.fsf@kamboji.qca.qualcomm.com>
 <CABUTiXW5QSh2KkD+sQ-6QOD5zTce0dun+nyfAMnvL580U=OVNw@mail.gmail.com>
 <871syn5fnb.fsf@qca.qualcomm.com>
 <CABUTiXV8eFsW4MJET4spvjVQvFgi66NV7hLLxFC6Ttqs1znxjA@mail.gmail.com>
 <87polwq2nq.fsf@kamboji.qca.qualcomm.com>
 <027001d28c42$5042c910$f0c85b30$@acksys.fr>
 <87efyrd6lv.fsf@kamboji.qca.qualcomm.com>
 <CAKR_QVLpSWab-kF-f8=xqw+oWAfA966GDm7CtXrWfzmJz8gP-w@mail.gmail.com>
Message-ID: <CABUTiXUjnBcTUhw6t3Pf+y8xAXmZ-t9OJ06pfhBx71EMqB_k9Q@mail.gmail.com>

On 21 February 2017 at 13:42, Tom Psyborg <pozega.tomislav at gmail.com> wrote:
> have you tried this one
> https://forum.lede-project.org/t/new-qca988x-firmware-with-mesh-support/1587

From my testing it does not work.

>
> On 21 February 2017 at 14:19, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>>
>> voncken <cedric.voncken at acksys.fr> writes:
>>
>> > Do you know if the firmware team planned to fix the VLAN issue on ath10k
>> > firmware?
>>
>> I reported it forward only this week.
>>
>> --
>> Kalle Valo
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bmcintosh at paceprofessional.co.uk  Wed Feb 22 06:28:23 2017
From: bmcintosh at paceprofessional.co.uk (Bernie McIntosh)
Date: Wed, 22 Feb 2017 11:28:23 +0000
Subject: [OpenWrt-Devel] BT Home Hub 5A again
Message-ID: <0102015a659452d8-68fa347f-1449-41c4-a1f3-a15baa942fed-000000@eu-west-1.amazonses.com>

Hi,

 

I built the latest Openwrt trunk but don't find menuconfig options for
BTHOMEHUBV5A.   The earlier patches providing support are mostly there but
John Crispin's  commit of 24 Jun 2016
83f7442dccbe6773c62371a62da7fe1ca3104fd2 entitled "lantiq: convert remaining
legacy targets to the new image generation"  has removed the bt.mk file in
the target/lantiq/xrx200/profiles directory.

 

Now I know that there must be a good reason for that because it relates to
the title of the patch so unlikely to be an error.  It seems that  the only
way I can build a sysupgrade tar for my BT router is to  use the last
revision before John's commit.  

 

Or do I ?  What exactly was the point of John's  patch ?

 

I have read that the BT Homehub support is working well in LEDE so that is
always an option, but when you want to know the answer to something, well
you want to know  : - )

 

 

Cheers

 

Bernie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/b575f4be/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From k6jq at comcast.net  Wed Feb 22 15:30:40 2017
From: k6jq at comcast.net (Dana Myers)
Date: Wed, 22 Feb 2017 12:30:40 -0800
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
	platform?
Message-ID: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>


I'm working with the Onion Omega2, which is based on an MT7688 SoC.
The MT7688 SoC is a variant of the MT76xx family; in particular, it
shares the same SPI peripheral. Support for SPI is in ..../drivers/spi/mt7621.c

However, there's  bugs with the SPI in the MT7688 which require a patch
to spi-mt7621.c - and I don't know if the same bugs are present in the
other MT76xx family members. It is possible the other MT76xx SoCs have
the same hardware issue (I'd be surprised if not) but I can only test
the MT7688 I have.

I think I want to patch the source file only when building only the MT7688
target, but I'm not sure how to do that or if it's supported.

So I'm looking for advice on how I might incorporate this patch so
that it is only applied when building ramips/mt7688.

Thanks,
Dana K6JQ
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ldpinney at gmail.com  Wed Feb 22 19:27:17 2017
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 22 Feb 2017 18:27:17 -0600
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
	platform?
In-Reply-To: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
Message-ID: <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>

Are you using https://github.com/OnionIoT/source onion-omega2 branch ?

On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net> wrote:

>
> I'm working with the Onion Omega2, which is based on an MT7688 SoC.
> The MT7688 SoC is a variant of the MT76xx family; in particular, it
> shares the same SPI peripheral. Support for SPI is in
> ..../drivers/spi/mt7621.c
>
> However, there's  bugs with the SPI in the MT7688 which require a patch
> to spi-mt7621.c - and I don't know if the same bugs are present in the
> other MT76xx family members. It is possible the other MT76xx SoCs have
> the same hardware issue (I'd be surprised if not) but I can only test
> the MT7688 I have.
>
> I think I want to patch the source file only when building only the MT7688
> target, but I'm not sure how to do that or if it's supported.
>
> So I'm looking for advice on how I might incorporate this patch so
> that it is only applied when building ramips/mt7688.
>
> Thanks,
> Dana K6JQ
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/acd86d86/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From k6jq at comcast.net  Wed Feb 22 20:00:26 2017
From: k6jq at comcast.net (Dana Myers)
Date: Wed, 22 Feb 2017 17:00:26 -0800
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
 platform?
In-Reply-To: <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
Message-ID: <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>

On 2/22/2017 4:27 PM, L. D. Pinney wrote:
> Are you using https://github.com/OnionIoT/source onion-omega2 branch ?
>

I am not; I'm using https://github.com/lede-project/source (master branch)

However, I don't believe it makes any difference - spi-mt7621.c appears
to be identical in both and the same patch applies; and this isn't an
Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
Labs patched their LinkIt repo for this. A fix really belongs upstream.

Thanks -
Dana


> On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net <mailto:k6jq at comcast.net>> wrote:
>
>
>     I'm working with the Onion Omega2, which is based on an MT7688 SoC.
>     The MT7688 SoC is a variant of the MT76xx family; in particular, it
>     shares the same SPI peripheral. Support for SPI is in ..../drivers/spi/mt7621.c
>
>     However, there's  bugs with the SPI in the MT7688 which require a patch
>     to spi-mt7621.c - and I don't know if the same bugs are present in the
>     other MT76xx family members. It is possible the other MT76xx SoCs have
>     the same hardware issue (I'd be surprised if not) but I can only test
>     the MT7688 I have.
>
>     I think I want to patch the source file only when building only the MT7688
>     target, but I'm not sure how to do that or if it's supported.
>
>     So I'm looking for advice on how I might incorporate this patch so
>     that it is only applied when building ramips/mt7688.
>
>     Thanks,
>     Dana K6JQ
>     _______________________________________________
>     openwrt-devel mailing list
>     openwrt-devel at lists.openwrt.org <mailto:openwrt-devel at lists.openwrt.org>
>     https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>     <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/9e3f731d/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Wed Feb 22 21:05:39 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Wed, 22 Feb 2017 19:05:39 -0700
Subject: [OpenWrt-Devel] Using kdump... persistent logs, etc.
Message-ID: <E68D1D86-68BB-4623-AB3F-23033C5B7266@redfish-solutions.com>

Hi,

Has anyone managed to use kdump with OpenWRT/LEDE?

I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs.  Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab?

And how would I modify the build process if I wanted to add additional partitions?

Thanks,

-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ldpinney at gmail.com  Wed Feb 22 21:18:43 2017
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 22 Feb 2017 20:18:43 -0600
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
	platform?
In-Reply-To: <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
 <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
Message-ID: <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>

spi-mt7621.c has bugs ... isn't very helpful.
Please describe the problem?

Can I reproduce the same problem on one of my many MT76x8 devices?
If so how?

The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.





On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net> wrote:

> On 2/22/2017 4:27 PM, L. D. Pinney wrote:
>
> Are you using https://github.com/OnionIoT/source onion-omega2 branch ?
>
>
> I am not; I'm using https://github.com/lede-project/source (master branch)
>
> However, I don't believe it makes any difference - spi-mt7621.c appears
> to be identical in both and the same patch applies; and this isn't an
> Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
> Labs patched their LinkIt repo for this. A fix really belongs upstream.
>
> Thanks -
> Dana
>
>
> On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net> wrote:
>
>>
>> I'm working with the Onion Omega2, which is based on an MT7688 SoC.
>> The MT7688 SoC is a variant of the MT76xx family; in particular, it
>> shares the same SPI peripheral. Support for SPI is in
>> ..../drivers/spi/mt7621.c
>>
>> However, there's  bugs with the SPI in the MT7688 which require a patch
>> to spi-mt7621.c - and I don't know if the same bugs are present in the
>> other MT76xx family members. It is possible the other MT76xx SoCs have
>> the same hardware issue (I'd be surprised if not) but I can only test
>> the MT7688 I have.
>>
>> I think I want to patch the source file only when building only the MT7688
>> target, but I'm not sure how to do that or if it's supported.
>>
>> So I'm looking for advice on how I might incorporate this patch so
>> that it is only applied when building ramips/mt7688.
>>
>> Thanks,
>> Dana K6JQ
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/5bbcc28c/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From k6jq at comcast.net  Wed Feb 22 21:57:45 2017
From: k6jq at comcast.net (Dana Myers)
Date: Wed, 22 Feb 2017 18:57:45 -0800
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
 platform?
In-Reply-To: <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
 <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
 <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
Message-ID: <888149eb-b69a-8a23-2b81-1aab84ac8867@comcast.net>

On 2/22/2017 6:18 PM, L. D. Pinney wrote:
>
> spi-mt7621.c has bugs ... isn't very helpful.

I am a bit surprised you're not already aware of the SPI issues.

You can start here:

     https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20

which links to another forum thread which contains this *very* informative
posting:

     http://52.76.69.244/jforum/posts/list/30/3683.page#12266

and suggested patch:

     http://52.76.69.244/jforum/posts/list/30/3683.page#12299

which is the basis of the patch I'm using.

> Please describe the problem?
>
berniwa does a much better job than me in the above-linked posting.


> Can I reproduce the same problem on one of my many MT76x8 devices?
> If so how?

I've only seen reports of  the issue on MT7688-based devices (LinkIt 7688, Omega2)
and I personally have observed it on the Omega2.

The easiest way to reproduce it is to attempt to send an SPI sequence
starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll find
the leading '1' bit is sent as a '0'.

I'd be somewhat surprised if the same issue wasn't present on all devices which
incorporate the MT7621 SPI peripheral given the likelihood that MediaTek
reproduces the same logic on every chip that includes the peripheral.

The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's
patch addresses by breaking up a transfer as needed (keeping chip select
asserted).
>
> The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
> The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.

Understood; I didn't say that MediaTek was using the *same* patch, but that
this issue is present on all MT7688 devices and that MediaTek has incorporated
a patch for it. The patch I'm using is for 4.4, of course.

If you could confirm the presence of  the issue on other MT7621-based SPI
peripherals, that would address my initial inquiry indirectly if we could just
patch all instances of the MT7621 SPI build :-)

Cheers,
Dana  K6JQ

>
>
>
>
> On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net <mailto:k6jq at comcast.net>> wrote:
>
>     On 2/22/2017 4:27 PM, L. D. Pinney wrote:
>>     Are you using https://github.com/OnionIoT/source <https://github.com/OnionIoT/source> onion-omega2 branch ?
>>
>
>     I am not; I'm using https://github.com/lede-project/source <https://github.com/lede-project/source> (master branch)
>
>     However, I don't believe it makes any difference - spi-mt7621.c appears
>     to be identical in both and the same patch applies; and this isn't an
>     Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
>     Labs patched their LinkIt repo for this. A fix really belongs upstream.
>
>     Thanks -
>     Dana
>
>
>>     On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net <mailto:k6jq at comcast.net>> wrote:
>>
>>
>>         I'm working with the Onion Omega2, which is based on an MT7688 SoC.
>>         The MT7688 SoC is a variant of the MT76xx family; in particular, it
>>         shares the same SPI peripheral. Support for SPI is in ..../drivers/spi/mt7621.c
>>
>>         However, there's  bugs with the SPI in the MT7688 which require a patch
>>         to spi-mt7621.c - and I don't know if the same bugs are present in the
>>         other MT76xx family members. It is possible the other MT76xx SoCs have
>>         the same hardware issue (I'd be surprised if not) but I can only test
>>         the MT7688 I have.
>>
>>         I think I want to patch the source file only when building only the MT7688
>>         target, but I'm not sure how to do that or if it's supported.
>>
>>         So I'm looking for advice on how I might incorporate this patch so
>>         that it is only applied when building ramips/mt7688.
>>
>>         Thanks,
>>         Dana K6JQ
>>         _______________________________________________
>>         openwrt-devel mailing list
>>         openwrt-devel at lists.openwrt.org <mailto:openwrt-devel at lists.openwrt.org>
>>         https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>         <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/1de94b55/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ldpinney at gmail.com  Wed Feb 22 23:09:06 2017
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 22 Feb 2017 22:09:06 -0600
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
	platform?
In-Reply-To: <888149eb-b69a-8a23-2b81-1aab84ac8867@comcast.net>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
 <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
 <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
 <888149eb-b69a-8a23-2b81-1aab84ac8867@comcast.net>
Message-ID: <CAJOqq5SWUWHqKujpMaCTCNZy-QRYFDRpq7kfjfs4G3FxwaFmnw@mail.gmail.com>

On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <k6jq at comcast.net> wrote:

> On 2/22/2017 6:18 PM, L. D. Pinney wrote:
>
>
> spi-mt7621.c has bugs ... isn't very helpful.
>
>
> I am a bit surprised you're not already aware of the SPI issues.
>
>
I am not surprised at all ... ALL of my MT76x8 devices have only a single
SPI-NOR Chip connected to the SPI.
On every device it works as intended ... load the OS.

Whenever you (or anyone) adds functionality to a device you can expect
problems.
In this case some device foreign to the actual device in question.
More specifically a device such as a RFID module or STM32.

If you have a working patch...You can start here :

https://lede-project.org/docs/guide-developer/the-source-code



You can start here:
>
>     https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20
>
> which links to another forum thread which contains this *very* informative
> posting:
>
>     http://52.76.69.244/jforum/posts/list/30/3683.page#12266
>
> and suggested patch:
>
>     http://52.76.69.244/jforum/posts/list/30/3683.page#12299
>
> which is the basis of the patch I'm using.
>
> Please describe the problem?
>
> berniwa does a much better job than me in the above-linked posting.
>
>
> Can I reproduce the same problem on one of my many MT76x8 devices?
> If so how?
>
>
> I've only seen reports of  the issue on MT7688-based devices (LinkIt 7688,
> Omega2)
> and I personally have observed it on the Omega2.
>
> The easiest way to reproduce it is to attempt to send an SPI sequence
> starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll
> find
> the leading '1' bit is sent as a '0'.
>
> I'd be somewhat surprised if the same issue wasn't present on all devices
> which
> incorporate the MT7621 SPI peripheral given the likelihood that MediaTek
> reproduces the same logic on every chip that includes the peripheral.
>
> The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's
> patch addresses by breaking up a transfer as needed (keeping chip select
> asserted).
>
>
> The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
> The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.
>
>
> Understood; I didn't say that MediaTek was using the *same* patch, but that
> this issue is present on all MT7688 devices and that MediaTek has
> incorporated
> a patch for it. The patch I'm using is for 4.4, of course.
>
> If you could confirm the presence of  the issue on other MT7621-based SPI
> peripherals, that would address my initial inquiry indirectly if we could
> just
> patch all instances of the MT7621 SPI build :-)
>
> Cheers,
> Dana  K6JQ
>
>
>
>
>
>
> On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net> wrote:
>
>> On 2/22/2017 4:27 PM, L. D. Pinney wrote:
>>
>> Are you using https://github.com/OnionIoT/source onion-omega2 branch ?
>>
>>
>> I am not; I'm using https://github.com/lede-project/source (master
>> branch)
>>
>> However, I don't believe it makes any difference - spi-mt7621.c appears
>> to be identical in both and the same patch applies; and this isn't an
>> Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
>> Labs patched their LinkIt repo for this. A fix really belongs upstream.
>>
>> Thanks -
>> Dana
>>
>>
>> On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net> wrote:
>>
>>>
>>> I'm working with the Onion Omega2, which is based on an MT7688 SoC.
>>> The MT7688 SoC is a variant of the MT76xx family; in particular, it
>>> shares the same SPI peripheral. Support for SPI is in
>>> ..../drivers/spi/mt7621.c
>>>
>>> However, there's  bugs with the SPI in the MT7688 which require a patch
>>> to spi-mt7621.c - and I don't know if the same bugs are present in the
>>> other MT76xx family members. It is possible the other MT76xx SoCs have
>>> the same hardware issue (I'd be surprised if not) but I can only test
>>> the MT7688 I have.
>>>
>>> I think I want to patch the source file only when building only the
>>> MT7688
>>> target, but I'm not sure how to do that or if it's supported.
>>>
>>> So I'm looking for advice on how I might incorporate this patch so
>>> that it is only applied when building ramips/mt7688.
>>>
>>> Thanks,
>>> Dana K6JQ
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/c38a0726/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From wong.syrone at gmail.com  Thu Feb 23 01:44:35 2017
From: wong.syrone at gmail.com (Syrone Wong)
Date: Thu, 23 Feb 2017 14:44:35 +0800
Subject: [OpenWrt-Devel] Using kdump... persistent logs, etc.
In-Reply-To: <E68D1D86-68BB-4623-AB3F-23033C5B7266@redfish-solutions.com>
References: <E68D1D86-68BB-4623-AB3F-23033C5B7266@redfish-solutions.com>
Message-ID: <CAEaqfobCx-OOtFVdpp07ONMK2f2hYJnsXTZ-1=poQoOAnunNOg@mail.gmail.com>

According to LEDE's source code:

config KERNEL_CRASHLOG
  bool "Crash logging"
  depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64)
  default y

https://github.com/lede-project/source/blob/master/config/Config-kernel.in

It is enabled by default on some targets and will be available at
`/sys/kernel/debug/crashlog` on next boot after crash.

The implementation detail can be found here:
https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch


Best Regards,
Syrone Wong


On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:
> Hi,
>
> Has anyone managed to use kdump with OpenWRT/LEDE?
>
> I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs.  Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab?
>
> And how would I modify the build process if I wanted to add additional partitions?
>
> Thanks,
>
> -Philip
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From christoph.kottke at gmx.de  Thu Feb 23 04:59:14 2017
From: christoph.kottke at gmx.de (Christoph Kottke)
Date: Thu, 23 Feb 2017 10:59:14 +0100
Subject: [OpenWrt-Devel] SVN server
In-Reply-To: <56EC03B9.9010308@openwrt.org>
References: <56EC03B9.9010308@openwrt.org>
Message-ID: <2623919d-895d-a0b9-0dc4-da24feb4a566@gmx.de>

Hi,

is there also a mirror from the luci svn server?

Ch,...

Am 18.03.2016 um 14:33 schrieb John Crispin:
> --> svn://svn.mein.io/openwrt
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From bmcintosh at paceprofessional.co.uk  Thu Feb 23 06:13:52 2017
From: bmcintosh at paceprofessional.co.uk (Bernie McIntosh)
Date: Thu, 23 Feb 2017 11:13:52 +0000
Subject: [OpenWrt-Devel] Using kdump... persistent logs,
	etc. (Syrone Wong)
Message-ID: <0102015a6aad6334-5429fd8b-9d05-41d2-a3d1-0b3384d54ef4-000000@eu-west-1.amazonses.com>

> Hi,
>
> Has anyone managed to use kdump with OpenWRT/LEDE?
>
> I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs.  Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab?
>
> And how would I modify the build process if I wanted to add additional partitions?
>
> Thanks,
>
> -Philip
> 

An alternative might be helpful.

I use rsyslog to send log to a  host on my LAN. 

How to enable it on Openwrt:   https://wiki.openwrt.org/doc/uci/system

How to set up rsyslog server (depends on Linux flavour) : http://www.thegeekstuff.com/2012/01/rsyslog-remote-logging

Regards

Bernie



_______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From david at lang.hm  Thu Feb 23 10:22:54 2017
From: david at lang.hm (David Lang)
Date: Thu, 23 Feb 2017 07:22:54 -0800 (PST)
Subject: [OpenWrt-Devel] Using kdump... persistent logs,
 etc. (Syrone Wong)
In-Reply-To: <0102015a6aad6334-5429fd8b-9d05-41d2-a3d1-0b3384d54ef4-000000@eu-west-1.amazonses.com>
References: <0102015a6aad6334-5429fd8b-9d05-41d2-a3d1-0b3384d54ef4-000000@eu-west-1.amazonses.com>
Message-ID: <nycvar.QRO.7.75.62.1702230721420.6590@qynat-yncgbc>

If you run into problems configuring rsyslog, we have a fairly active mailing 
list at rsyslog-users <rsyslog at lists.adiscon.com>, or ask questions here and 
I'll be happy to answer them.

David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From martin.tippmann at gmail.com  Thu Feb 23 10:35:11 2017
From: martin.tippmann at gmail.com (Martin Tippmann)
Date: Thu, 23 Feb 2017 16:35:11 +0100
Subject: [OpenWrt-Devel] Using kdump... persistent logs,
	etc. (Syrone Wong)
In-Reply-To: <0102015a6aad6334-5429fd8b-9d05-41d2-a3d1-0b3384d54ef4-000000@eu-west-1.amazonses.com>
References: <0102015a6aad6334-5429fd8b-9d05-41d2-a3d1-0b3384d54ef4-000000@eu-west-1.amazonses.com>
Message-ID: <CABL_Pd9R2n2FYjkpfgqf8atgMOgPwttpm4WFUuriCs=G9uVjfg@mail.gmail.com>

On Thu, Feb 23, 2017 at 12:13 PM, Bernie McIntosh
<bmcintosh at paceprofessional.co.uk> wrote:
>> Hi,
>>
>> Has anyone managed to use kdump with OpenWRT/LEDE?
>>
>> I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs.  Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab?
>>
>> And how would I modify the build process if I wanted to add additional partitions?
>>
>> Thanks,
>>
>> -Philip
>>
>
> An alternative might be helpful.

Another alternative is Kernel crashlogging - I think it's on by
default and you can get the backtrace from the last panic in
/sys/kernel/debug/crashlog after reboot.

regards
Martin
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From philipp_subx at redfish-solutions.com  Thu Feb 23 12:27:10 2017
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Thu, 23 Feb 2017 10:27:10 -0700
Subject: [OpenWrt-Devel] Using kdump... persistent logs, etc.
In-Reply-To: <CAEaqfobCx-OOtFVdpp07ONMK2f2hYJnsXTZ-1=poQoOAnunNOg@mail.gmail.com>
References: <E68D1D86-68BB-4623-AB3F-23033C5B7266@redfish-solutions.com>
 <CAEaqfobCx-OOtFVdpp07ONMK2f2hYJnsXTZ-1=poQoOAnunNOg@mail.gmail.com>
Message-ID: <D279822F-4D31-4C93-96EC-CAA141BB6AB7@redfish-solutions.com>

Thanks for that.


> On Feb 22, 2017, at 11:44 PM, Syrone Wong <wong.syrone at gmail.com> wrote:
> 
> According to LEDE's source code:
> 
> config KERNEL_CRASHLOG
>  bool "Crash logging"
>  depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64)
>  default y
> 
> https://github.com/lede-project/source/blob/master/config/Config-kernel.in
> 
> It is enabled by default on some targets and will be available at
> `/sys/kernel/debug/crashlog` on next boot after crash.
> 
> The implementation detail can be found here:
> https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch
> 
> 
> Best Regards,
> Syrone Wong
> 
> 
> On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> Hi,
>> 
>> Has anyone managed to use kdump with OpenWRT/LEDE?
>> 
>> I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs.  Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab?
>> 
>> And how would I modify the build process if I wanted to add additional partitions?
>> 
>> Thanks,
>> 
>> -Philip
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Fri Feb 24 04:26:05 2017
From: alin.nastac at gmail.com (Alin Nastac)
Date: Fri, 24 Feb 2017 10:26:05 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its last
	instance is freed
Message-ID: <1487928365-10371-1-git-send-email-alin.nastac@gmail.com>

Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
---
 service/service.c | 5 ++++-
 service/service.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/service/service.c b/service/service.c
index 0584ee0..9675ba2 100644
--- a/service/service.c
+++ b/service/service.c
@@ -140,6 +140,8 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
 			vlist_flush(&s->instances);
 	}
 
+	s->deleted = false;
+
 	rc(s->name, "running");
 
 	return 0;
@@ -149,6 +151,7 @@ static void
 service_delete(struct service *s)
 {
 	vlist_flush_all(&s->instances);
+	s->deleted = true;
 	service_stopped(s);
 }
 
@@ -602,7 +605,7 @@ service_start_early(char *name, char *cmdline)
 
 void service_stopped(struct service *s)
 {
-	if (avl_is_empty(&s->instances.avl)) {
+	if (s->deleted && avl_is_empty(&s->instances.avl)) {
 		service_event("service.stop", s->name, NULL);
 		avl_delete(&services, &s->avl);
 		trigger_del(s);
diff --git a/service/service.h b/service/service.h
index d4f0a83..cc629b1 100644
--- a/service/service.h
+++ b/service/service.h
@@ -40,6 +40,7 @@ struct validate {
 struct service {
 	struct avl_node avl;
 	const char *name;
+	bool deleted;
 
 	struct blob_attr *trigger;
 	struct vlist_tree instances;
-- 
1.7.12.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Fri Feb 24 04:53:59 2017
From: john at phrozen.org (John Crispin)
Date: Fri, 24 Feb 2017 10:53:59 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its
 last instance is freed
In-Reply-To: <1487928365-10371-1-git-send-email-alin.nastac@gmail.com>
References: <1487928365-10371-1-git-send-email-alin.nastac@gmail.com>
Message-ID: <3f6348c6-da82-a831-0519-f26752b39fb6@phrozen.org>



On 24/02/2017 10:26, Alin Nastac wrote:
> Signed-off-by: Alin Nastac <alin.nastac at gmail.com>

Hi,

can you write a little more info as to why this is needed and what
scenario this fixes/changes ?

	John

> ---
>  service/service.c | 5 ++++-
>  service/service.h | 1 +
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/service/service.c b/service/service.c
> index 0584ee0..9675ba2 100644
> --- a/service/service.c
> +++ b/service/service.c
> @@ -140,6 +140,8 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
>  			vlist_flush(&s->instances);
>  	}
>  
> +	s->deleted = false;
> +
>  	rc(s->name, "running");
>  
>  	return 0;
> @@ -149,6 +151,7 @@ static void
>  service_delete(struct service *s)
>  {
>  	vlist_flush_all(&s->instances);
> +	s->deleted = true;
>  	service_stopped(s);
>  }
>  
> @@ -602,7 +605,7 @@ service_start_early(char *name, char *cmdline)
>  
>  void service_stopped(struct service *s)
>  {
> -	if (avl_is_empty(&s->instances.avl)) {
> +	if (s->deleted && avl_is_empty(&s->instances.avl)) {
>  		service_event("service.stop", s->name, NULL);
>  		avl_delete(&services, &s->avl);
>  		trigger_del(s);
> diff --git a/service/service.h b/service/service.h
> index d4f0a83..cc629b1 100644
> --- a/service/service.h
> +++ b/service/service.h
> @@ -40,6 +40,7 @@ struct validate {
>  struct service {
>  	struct avl_node avl;
>  	const char *name;
> +	bool deleted;
>  
>  	struct blob_attr *trigger;
>  	struct vlist_tree instances;
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Fri Feb 24 05:21:12 2017
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Fri, 24 Feb 2017 11:21:12 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its
	last instance is freed
In-Reply-To: <3f6348c6-da82-a831-0519-f26752b39fb6@phrozen.org>
References: <1487928365-10371-1-git-send-email-alin.nastac@gmail.com>
 <3f6348c6-da82-a831-0519-f26752b39fb6@phrozen.org>
Message-ID: <CAF1oqRA6u37fZ0cq46guw-c5m_3vxWGe3sX3gD-ygGW7uXneXg@mail.gmail.com>

Hi John,

On Fri, Feb 24, 2017 at 10:53 AM, John Crispin <john at phrozen.org> wrote:
> can you write a little more info as to why this is needed and what
> scenario this fixes/changes ?

1) root at OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enable_server='0'
system.ntp.use_dhcp='1'
system.ntp.dhcp_interface='wan'
2) root at OpenWrt:~# uci show network.wan
network.wan=interface
network.wan.proto='dhcp'
network.wan.ifname='eth4'
network.wan.reqopts='1 3 6 15 33 42 51 121 249'
3) restart wan interface using ifup command
4) sysntpd service will be down afterwards although dhcp lease has an option 42

Because service is deleted when last instance gets freed, its triggers
will also released. Without these triggers in place, sysntpd will not
be reloaded when a new dhcp lease containing option 42 will be
received.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From john at phrozen.org  Sun Feb 26 04:43:36 2017
From: john at phrozen.org (John Crispin)
Date: Sun, 26 Feb 2017 10:43:36 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its
 last instance is freed
In-Reply-To: <CAF1oqRA6u37fZ0cq46guw-c5m_3vxWGe3sX3gD-ygGW7uXneXg@mail.gmail.com>
References: <1487928365-10371-1-git-send-email-alin.nastac@gmail.com>
 <3f6348c6-da82-a831-0519-f26752b39fb6@phrozen.org>
 <CAF1oqRA6u37fZ0cq46guw-c5m_3vxWGe3sX3gD-ygGW7uXneXg@mail.gmail.com>
Message-ID: <9106ee04-5301-7bb2-2436-24502b8f0f80@phrozen.org>



On 24/02/2017 11:21, Alin N?stac wrote:
> Hi John,
> 
> On Fri, Feb 24, 2017 at 10:53 AM, John Crispin <john at phrozen.org> wrote:
>> can you write a little more info as to why this is needed and what
>> scenario this fixes/changes ?
> 
> 1) root at OpenWrt:~# uci show system.ntp
> system.ntp=timeserver
> system.ntp.enable_server='0'
> system.ntp.use_dhcp='1'
> system.ntp.dhcp_interface='wan'
> 2) root at OpenWrt:~# uci show network.wan
> network.wan=interface
> network.wan.proto='dhcp'
> network.wan.ifname='eth4'
> network.wan.reqopts='1 3 6 15 33 42 51 121 249'
> 3) restart wan interface using ifup command
> 4) sysntpd service will be down afterwards although dhcp lease has an option 42
> 
> Because service is deleted when last instance gets freed, its triggers
> will also released. Without these triggers in place, sysntpd will not
> be reloaded when a new dhcp lease containing option 42 will be
> received.
> 


Hi Alin,

can resend this as a patch with that info added please ?

	John
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb 26 14:42:51 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 26 Feb 2017 20:42:51 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4] PCI: add driver for Cortina Gemini
	Host Bridge
In-Reply-To: <20170131003751.GF20550@bhelgaas-glaptop.roam.corp.google.com>
References: <20170128204839.18330-1-linus.walleij@linaro.org>
 <20170128204839.18330-2-linus.walleij@linaro.org>
 <20170131003751.GF20550@bhelgaas-glaptop.roam.corp.google.com>
Message-ID: <CACRpkdZ1ONM-sODoYi4isk65Eq5GUqPtfqnL9=is5s0=zObm_w@mail.gmail.com>

On Tue, Jan 31, 2017 at 1:37 AM, Bjorn Helgaas <helgaas at kernel.org> wrote:

> Looks nice; a couple unused definitions below.

Just so I do things right:  what is your policy on unused defines?
I'm asking because the defines in this case is pretty much the
documentation... there is no datasheet for this IP core. I usually
like to keep the defines around so people can have them as a
hint if they want to tinker and hack the driver.

Would you be OK with keeping them if I comment them out?

I'll repost the driver soon, including all things asked to be
fixed up by you & Arnd.

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Sun Feb 26 15:17:46 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 26 Feb 2017 21:17:46 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4] PCI: add DT bindings for Faraday
	Technology PCI Host Bridge
In-Reply-To: <20170222002640.y2uhumje5csioure@rob-hp-laptop>
References: <20170211125220.10273-1-linus.walleij@linaro.org>
 <20170222002640.y2uhumje5csioure@rob-hp-laptop>
Message-ID: <CACRpkdZsFfnh8vA_-RQqXyrJOh-emZQytj2bxHXRDkTs9ga+eg@mail.gmail.com>

On Wed, Feb 22, 2017 at 1:26 AM, Rob Herring <robh at kernel.org> wrote:
> On Sat, Feb 11, 2017 at 01:52:17PM +0100, Linus Walleij wrote:

>> +- compatible: should be one of
>> +  "faraday,pci"
>> +  "faraday,dual-pci"
>
> Probably should still have a Cortina specific compatible.

OK I rewrote it using the specific-to-generic compatible pattern.

>> +pci at 50000000 {
>> +     compatible = "faraday,pci";
>> +     reg = <0x50000000 0x100>;
>> +     interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
>> +                     <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
>> +                     <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
>> +                     <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
>> +     #address-cells = <3>;
>> +     #size-cells = <2>;
>> +     #interrupt-cells = <1>;
>
> This doesn't belong here (I think).

This needs to be here because the interrupts for
PCI are 1 cell. The PCI host acts as interrupt parent for all
the cards you plug in, and they always have one cell, you
can see this in the example for open-pic in Device Tree
Specification release 0.1, page 19 for example.

It gets a bit confusing maybe in cases like this (as with
open-pic) where there is a cascades interrupt controller
that in this case also has 1 cell of interrupt specifier.

Or did you mean something else?

Yours,
Linus Walleij
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From alin.nastac at gmail.com  Mon Feb 27 04:08:34 2017
From: alin.nastac at gmail.com (Alin Nastac)
Date: Mon, 27 Feb 2017 10:08:34 +0100
Subject: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its last
	instance is freed
Message-ID: <1488186514-5988-1-git-send-email-alin.nastac@gmail.com>

This fixes the following regression introduced in commit
961dc692aff7457f874bce61f8e766514edcf794:
 1) reboot using the following configuration
root at OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enable_server='0'
system.ntp.use_dhcp='1'
system.ntp.dhcp_interface='wan'
root at OpenWrt:~# uci show network.wan
network.wan=interface
network.wan.proto='dhcp'
network.wan.ifname='eth4'
network.wan.reqopts='1 3 6 15 33 42 51 121 249'
 2) if obtained DHCP lease has an option 42 sysntpd service will have an
 instance
 3) run "ifup wan"
 4) although the same DHCP lease was obtained, sysntpd would be stopped

Because sysntpd service is deleted when last instance is freed, its triggers
will also be released. Without these triggers in place, sysntpd will not be
reloaded when a new DHCP lease containing option 42 will be received.

Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
---
 service/service.c | 5 ++++-
 service/service.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/service/service.c b/service/service.c
index 0584ee0..9675ba2 100644
--- a/service/service.c
+++ b/service/service.c
@@ -140,6 +140,8 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
 			vlist_flush(&s->instances);
 	}
 
+	s->deleted = false;
+
 	rc(s->name, "running");
 
 	return 0;
@@ -149,6 +151,7 @@ static void
 service_delete(struct service *s)
 {
 	vlist_flush_all(&s->instances);
+	s->deleted = true;
 	service_stopped(s);
 }
 
@@ -602,7 +605,7 @@ service_start_early(char *name, char *cmdline)
 
 void service_stopped(struct service *s)
 {
-	if (avl_is_empty(&s->instances.avl)) {
+	if (s->deleted && avl_is_empty(&s->instances.avl)) {
 		service_event("service.stop", s->name, NULL);
 		avl_delete(&services, &s->avl);
 		trigger_del(s);
diff --git a/service/service.h b/service/service.h
index d4f0a83..cc629b1 100644
--- a/service/service.h
+++ b/service/service.h
@@ -40,6 +40,7 @@ struct validate {
 struct service {
 	struct avl_node avl;
 	const char *name;
+	bool deleted;
 
 	struct blob_attr *trigger;
 	struct vlist_tree instances;
-- 
1.7.12.4
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From k6jq at comcast.net  Mon Feb 27 12:32:29 2017
From: k6jq at comcast.net (Dana Myers)
Date: Mon, 27 Feb 2017 09:32:29 -0800
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
 platform?
In-Reply-To: <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
 <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
 <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
Message-ID: <d04aa40f-7e5f-b020-75fb-1a53856cc4b2@comcast.net>

> On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <k6jq at comcast.net <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:
>
> >/On 2/22/2017 6:18 PM, L. D. Pinney wrote: />//>//>/spi-mt7621.c has bugs ... isn't very helpful. />//>//>/I am a bit surprised you're not already aware of the SPI issues. />//>//I am not surprised at all ... ALL of my MT76x8 devices have only a single
> SPI-NOR Chip connected to the SPI.
> On every device it works as intended ... load the OS.

Of course - that's surely why this hardware bug in the MediaTek SPI peripheral
escaped from the factory; they implement and document functionality (full-duplex
operation), and either didn't test it or didn't regard the bug as critical. The
critical use-case of the SPI port is to read the flash device, which is half-duplex,
but that's not the only documented use of the SPI port.

MediaTek documents the SPI port as a general peripheral (and provides
an additional select line), and there's a bug in the hardware.
> Whenever you (or anyone) adds functionality to a device you can expect
> problems.
Thanks, though this isn't relevant at all. I'm not *adding* functionality to the device.
There's a bug in the SPI controller that's exposed when you try to use it as documented.

> In this case some device foreign to the actual device in question.
> More specifically a device such as a RFID module or STM32.
This isn't the case at all. There's a bug in the MediaTek SPI controller completely
independent of what (if anything) is attached to it. Simply attempting to *send*
a byte in full-duplex mode results in corrupted bits coming out of the MediaTek
SPI Master-Out line. It has absolutely nothing to do with external devices. It's a
bug in the MediaTek controller.

This has been interesting bit of bikeshedding, but back to my original question.
>
> If you have a working patch...You can start here :

> https://lede-project.org/docs/guide-developer/the-source-code

I have a working patch. I know how to do a PR. I know how to RTFM :-)
Which brings us full-circle to my initial query...

My concern (as alluded to in the subject line) is that I have a patch that
I know for certain is required for the MT7688 and I've tested on the MT7688.
I don't have other MT76xx variants to  to verify the presence of the hardware
bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
question is how to apply this patch for only the mt7688 target.

However, the more I think about it, I strongly suspect this bug is present
on all variants of the MT76xx, so the patch should be generically applied;
I need to find confirmation; I'll try contacting MediaTek.

Thanks,
Dana  K6JQ


>
>
>
> You can start here:
> >//>/https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 />//>/which links to another forum thread which contains this *very* informative />/posting: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12266 />//>/and suggested patch: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12299 />//>/which is the basis of the patch I'm using. />//>/Please describe the problem? />//>/berniwa does a much better job than me in the above-linked posting. />//>//>/Can I reproduce the same problem on one of my many MT76x8 devices? />/If so how? />//>//>/I've only seen reports of the issue on MT7688-based devices (LinkIt 7688, />/Omega2) />/and I personally have observed it on the Omega2. />//>/The easiest way to reproduce it is to attempt to send an SPI sequence />/starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll />/find />/the leading '1' bit is sent as a '0'. />//>/I'd be somewhat surprised if the same issue wasn't present on all devices />/which />/incorporate the MT7621 SPI peripheral given the likelihood that MediaTek />/reproduces the same logic on every chip that includes the peripheral. />//>/The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's />/patch addresses by breaking up a transfer as needed (keeping chip select />/asserted). />//>//>/The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel. />/The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different. />//>//>/Understood; I didn't say that MediaTek was using the *same* patch, but that />/this issue is present on all MT7688 devices and that MediaTek has />/incorporated />/a patch for it. The patch I'm using is for 4.4, of course. />//>/If you could confirm the presence of the issue on other MT7621-based SPI />/peripherals, that would address my initial inquiry indirectly if we could />/just />/patch all instances of the MT7621 SPI build :-) />//>/Cheers, />/Dana K6JQ />//>//>//>//>//>//>/On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net 
> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: />//>>/On 2/22/2017 4:27 PM, L. D. Pinney wrote: />>//>>/Are you using https://github.com/OnionIoT/source onion-omega2 branch ? />>//>>//>>/I am not; I'm using https://github.com/lede-project/source (master />>/branch) />>//>>/However, I don't believe it makes any difference - spi-mt7621.c appears />>/to be identical in both and the same patch applies; and this isn't an />>/Omega2-specific issue. All MT7688-based systems have this issue; MediaTek />>/Labs patched their LinkIt repo for this. A fix really belongs upstream. />>//>>/Thanks - />>/Dana />>//>>//>>/On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net 
> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: />>//>>>//>>>/I'm working with the Onion Omega2, which is based on an MT7688 SoC. />>>/The MT7688 SoC is a variant of the MT76xx family; in particular, it />>>/shares the same SPI peripheral. Support for SPI is in />>>/..../drivers/spi/mt7621.c />>>//>>>/However, there's bugs with the SPI in the MT7688 which require a patch />>>/to spi-mt7621.c - and I don't know if the same bugs are present in the />>>/other MT76xx family members. It is possible the other MT76xx SoCs have />>>/the same hardware issue (I'd be surprised if not) but I can only test />>>/the MT7688 I have. />>>//>>>/I think I want to patch the source file only when building only the />>>/MT7688 />>>/target, but I'm not sure how to do that or if it's supported. />>>//>>>/So I'm looking for advice on how I might incorporate this patch so />>>/that it is only applied when building ramips/mt7688. />>>//>>>/Thanks, />>>/Dana K6JQ />>>/_______________________________________________ />>>/openwrt-devel mailing list />>>/openwrt-devel at lists.openwrt.org <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel> />>>/https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel />>>//>>//>>//>>//>//>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170227/23fe9bb2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon Feb 27 14:07:17 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 27 Feb 2017 20:07:17 +0100
Subject: [OpenWrt-Devel] [PATCH 1/4 v3] PCI: add DT bindings for Faraday
	Technology PCI Host Bridge
Message-ID: <20170227190720.31409-1-linus.walleij@linaro.org>

This adds device tree bindings for the Faraday technology PCI
Host Bridge. This IP is found in the Storlink/Storm/Cortina
Gemini SoC platform.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: devicetree at vger.kernel.org
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Reinstate the specific-to-generic bindings also specifying the
  "cortina,gemini-pci" fixture for the Faraday block.
- Set compatible to "faraday,ftpci100" and "faraday,ftpci100-dual"
  this is clearly closer to or equal to what the IP blocks from
  Faraday are actually named.
- Add "dma-ranges" property, after deciphering that some hardcoded
  constants in the driver is really about this.
ChangeLog v1->v2:
- Rename from Cortina prefixes to Faraday. This is clearly
  a Faraday IP block.
- Support both the version with cascaded interrupts and the
  "dual" version with 1-to-1 mapped interrupts.
- Change bus-range to <0x00 0xff>
- Fix spelling mistake
- Write a bit about swizzling interrupts on the interrupt
  controller side
- Reasonable swizzling in the interrupt mapping example

This can be merged to the PCI tree whenever it is considered
fine for inclusion.
---
 .../devicetree/bindings/pci/faraday,ftpci100.txt   | 129 +++++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/faraday,ftpci100.txt

diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
new file mode 100644
index 000000000000..35d4a979bb7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
@@ -0,0 +1,129 @@
+Faraday Technology FTPCI100 PCI Host Bridge
+
+This PCI bridge is found inside that Cortina Systems Gemini SoC platform and
+is a generic IP block from Faraday Technology. It exists in two variants:
+plain and dual PCI. The plain version embeds a cascading interrupt controller
+into the host bridge. The dual version routes the interrupts to the host
+chips interrupt controller.
+
+The host controller appear on the PCI bus with vendor ID 0x159b (Faraday
+Technology) and product ID 0x4321.
+
+Mandatory properties:
+
+- compatible: ranging from specific to generic, should be one of
+  "cortina,gemini-pci", "faraday,ftpci100"
+  "cortina,gemini-pci-dual", "faraday,ftpci100-dual"
+  "faraday,ftpci100"
+  "faraday,ftpci100-dual"
+- reg: memory base and size for the host bridge
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells: set to <1>
+- bus-range: set to <0x00 0xff>
+- device_type, set to "pci"
+- ranges: see pci.txt
+- interrupt-map-mask: see pci.txt
+- interrupt-map: see pci.txt
+- dma-ranges: three ranges for the inbound memory region. The ranges must
+  be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB,
+  128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as
+  pre-fetchable.
+
+Mandatory subnodes:
+- For "faraday,ftpci100" a node representing the interrupt-controller inside the
+  host bridge is mandatory. It has the following mandatory properties:
+  - interrupt: see interrupt-controller/interrupts.txt
+  - interrupt-parent: see interrupt-controller/interrupts.txt
+  - interrupt-controller: see interrupt-controller/interrupts.txt
+  - #address-cells: set to <0>
+  - #interrupt-cells: set to <1>
+
+I/O space considerations:
+
+The plain variant has 128MiB of non-prefetchable memory space, whereas the
+"dual" variant has 64MiB. Take this into account when describing the ranges.
+
+Interrupt map considerations:
+
+The "dual" variant will get INT A, B, C, D from the system interrupt controller
+and should point to respective interrupt in that controller in its
+interrupt-map.
+
+The code which is the only documentation of how the Faraday PCI (the non-dual
+variant) interrupts assigns the default interrupt mapping/swizzling has
+typically been like this, doing the swizzling on the interrupt controller side
+rather than in the interconnect:
+
+interrupt-map-mask = <0xf800 0 0 7>;
+interrupt-map =
+	<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+	<0x4800 0 0 2 &pci_intc 1>,
+	<0x4800 0 0 3 &pci_intc 2>,
+	<0x4800 0 0 4 &pci_intc 3>,
+	<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+	<0x5000 0 0 2 &pci_intc 2>,
+	<0x5000 0 0 3 &pci_intc 3>,
+	<0x5000 0 0 4 &pci_intc 0>,
+	<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+	<0x5800 0 0 2 &pci_intc 3>,
+	<0x5800 0 0 3 &pci_intc 0>,
+	<0x5800 0 0 4 &pci_intc 1>,
+	<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+	<0x6000 0 0 2 &pci_intc 0>,
+	<0x6000 0 0 3 &pci_intc 1>,
+	<0x6000 0 0 4 &pci_intc 2>;
+
+Example:
+
+pci at 50000000 {
+	compatible = "cortina,gemini-pci", "faraday,ftpci100";
+	reg = <0x50000000 0x100>;
+	interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
+			<26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
+			<27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
+			<28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
+	#address-cells = <3>;
+	#size-cells = <2>;
+	#interrupt-cells = <1>;
+
+	bus-range = <0x00 0xff>;
+	ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
+		 <0x01000000 0 0          0x50000000 0 0x00100000>,
+		 /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
+		 <0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
+
+	/* DMA ranges */
+	dma-ranges =
+	/* 128MiB at 0x00000000-0x07ffffff */
+	<0x02000000 0 0x00000000 0x00000000 0 0x08000000>,
+	/* 64MiB at 0x00000000-0x03ffffff */
+	<0x02000000 0 0x00000000 0x00000000 0 0x04000000>,
+	/* 64MiB at 0x00000000-0x03ffffff */
+	<0x02000000 0 0x00000000 0x00000000 0 0x04000000>;
+
+	interrupt-map-mask = <0xf800 0 0 7>;
+	interrupt-map =
+		<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+		<0x4800 0 0 2 &pci_intc 1>,
+		<0x4800 0 0 3 &pci_intc 2>,
+		<0x4800 0 0 4 &pci_intc 3>,
+		<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+		<0x5000 0 0 2 &pci_intc 2>,
+		<0x5000 0 0 3 &pci_intc 3>,
+		<0x5000 0 0 4 &pci_intc 0>,
+		<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+		<0x5800 0 0 2 &pci_intc 3>,
+		<0x5800 0 0 3 &pci_intc 0>,
+		<0x5800 0 0 4 &pci_intc 1>,
+		<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+		<0x6000 0 0 2 &pci_intc 0>,
+		<0x6000 0 0 3 &pci_intc 0>,
+		<0x6000 0 0 4 &pci_intc 0>;
+	pci_intc: interrupt-controller {
+		interrupt-parent = <&intcon>;
+		interrupt-controller;
+		#address-cells = <0>;
+		#interrupt-cells = <1>;
+	};
+};
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon Feb 27 14:07:18 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 27 Feb 2017 20:07:18 +0100
Subject: [OpenWrt-Devel] [PATCH 2/4 v3] PCI: add driver for Faraday
	Technology Host Bridge
In-Reply-To: <20170227190720.31409-1-linus.walleij@linaro.org>
References: <20170227190720.31409-1-linus.walleij@linaro.org>
Message-ID: <20170227190720.31409-2-linus.walleij@linaro.org>

This adds a host bridge driver for the Faraday Technology
FPPCI100 host bridge, used for Cortina Systems Gemini SoC
(SL3516) PCI Host Bridge.

This code is inspired by the out-of-tree OpenWRT patch and
then extensively rewritten for device tree and using the modern
helpers to cut down and modernize the code to all new PCI
frameworks. A driver exists in U-Boot as well.

Tested on the ITian Square One SQ201 NAS with the following
result in the boot log (trimmed to relevant parts):

OF: PCI: host bridge /soc/pci at 50000000 ranges:
OF: PCI:    IO 0x50000000..0x500fffff -> 0x00000000
OF: PCI:   MEM 0x58000000..0x5fffffff -> 0x58000000
ftpci100 50000000.pci: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0x58000000-0x5fffffff]
ftpci100 50000000.pci:
  DMA MEM1 BASE: 0x0000000000000000 -> 0x0000000007ffffff config 00070000
ftpci100 50000000.pci:
  DMA MEM2 BASE: 0x0000000000000000 -> 0x0000000003ffffff config 00060000
ftpci100 50000000.pci:
  DMA MEM3 BASE: 0x0000000000000000 -> 0x0000000003ffffff config 00060000
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0000:00:0c.0: BAR 0: assigned [mem 0x58000000-0x58007fff]
pci 0000:00:09.2: BAR 0: assigned [mem 0x58008000-0x580080ff]
pci 0000:00:09.0: BAR 4: assigned [io  0x1000-0x101f]
pci 0000:00:09.1: BAR 4: assigned [io  0x1020-0x103f]
pci 0000:00:09.0: enabling device (0140 -> 0141)
pci 0000:00:09.0: HCRESET not completed yet!
pci 0000:00:09.1: enabling device (0140 -> 0141)
pci 0000:00:09.1: HCRESET not completed yet!
pci 0000:00:09.2: enabling device (0140 -> 0142)
rt61pci 0000:00:0c.0: enabling device (0140 -> 0142)
ieee80211 phy0: rt2x00_set_chip: Info - Chipset detected -
   rt: 2561, rf: 0003, rev: 000c
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci 0000:00:09.2: EHCI Host Controller
ehci-pci 0000:00:09.2: new USB bus registered, assigned bus number 1
ehci-pci 0000:00:09.2: irq 125, io mem 0x58008000
ehci-pci 0000:00:09.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:09.0: UHCI Host Controller
uhci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:09.0: HCRESET not completed yet!
uhci_hcd 0000:00:09.0: irq 123, io base 0x00001000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
uhci_hcd 0000:00:09.1: UHCI Host Controller
uhci_hcd 0000:00:09.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:09.1: HCRESET not completed yet!
uhci_hcd 0000:00:09.1: irq 124, io base 0x00001020
hub 3-0:1.0: USB hub found
hub 3-0:1.0: config failed, hub doesn't have any ports! (err -19)
scsi 0:0:0:0: Direct-Access     USB      Flash Disk       1.00 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 7900336 512-byte logical blocks: (4.04 GB/3.77 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI removable disk
ieee80211 phy0: rt2x00lib_request_firmware: Info -
   Loading firmware file 'rt2561s.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info -
   Firmware detected - version: 0.8
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

$ lspci
00:00.0 Class 0600: 159b:4321
00:09.2 Class 0c03: 1106:3104
00:09.0 Class 0c03: 1106:3038
00:09.1 Class 0c03: 1106:3038
00:0c.0 Class 0280: 1814:0301

cat /proc/interrupts
           CPU0
123:          0       PCI   0 Edge      uhci_hcd:usb2
124:          0       PCI   1 Edge      uhci_hcd:usb3
125:        159       PCI   2 Edge      ehci_hcd:usb1
126:       1082       PCI   3 Edge      rt61pci

cat /proc/iomem
50000000-500000ff : /soc/pci at 50000000
58000000-5fffffff : Gemini PCI MEM
  58000000-58007fff : 0000:00:0c.0
    58000000-58007fff : 0000:00:0c.0
  58008000-580080ff : 0000:00:09.2
    58008000-580080ff : ehci_hcd

The EHCI USB hub works fine, I can mount and manage
files and the IRQs just keep ticking up. I can issue
iwlist wlan0 scanning and see all the WLANs here, I don't have
wpa_supplicant so have not tried connecting to them.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Rewrite to use pci_alloc_host_bridge() and
  pci_register_host_bridge()
- Change compatible strings to "faraday,ftpci100" and
  "faraday,ftpci100-dual"
- Rename driver file to pci-ftpci100.c to reflect the name
  of the actual Faraday IP core.
- Make the driver depend on ARM again as not all archs use
  setup-irq.c which contains pci_fixup_irqs() that the driver
  is using.
- Add "dma-ranges" property, after deciphering that some hardcoded
  constants in the driver is really about this.
ChangeLog v1->v2:
- Rename the bridge and symbols to reflect Faraday technology
  as this IP block is clearly a Faraday block and not from
  Storlink/Storm/Cortina at all.
- Support both the regular and "dual" versions of the bridge,
  where the regular has a cascaded IRQ controller and the dual
  does not.
- Encode per-variant characteristics in a variant struct in
  the .data field of the OF match.
- Drop the pointless spinlock in the config space accessors.
- Drop manipulation of pcibios_min_io and pcibios_min_mem
- Get the IO range size from the device tree, and set up the
  bridge properly according to this. Currently we only support
  a 1MiB size IO range, but hey, it's at least dynamic and
  logical.

This can be merged to the PCI tree whenever it is considered
fine for inclusion.

Andestech and Faraday guys: you are more likely than me to
actually have documentation for this bridge. Please share with
me if you can, especially the register defintions, because I
want to set up IO and MEM windows properly from the device tree,
not just rely on defaults. There are defines for these registers
but no use or documentation.
---
 drivers/pci/host/Kconfig        |   6 +
 drivers/pci/host/Makefile       |   1 +
 drivers/pci/host/pci-ftpci100.c | 566 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 573 insertions(+)
 create mode 100644 drivers/pci/host/pci-ftpci100.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 898d2c48239c..a2555e35a393 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -60,6 +60,12 @@ config PCI_EXYNOS
 	select PCIEPORTBUS
 	select PCIE_DW
 
+config PCI_FTPCI100
+	bool "Faraday Technology FTPCI100 PCI controller"
+	depends on OF
+	depends on ARM
+	default ARCH_GEMINI
+
 config PCI_IMX6
 	bool "Freescale i.MX6 PCIe controller"
 	depends on SOC_IMX6Q
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index bfe3179ae74c..39f20b43414d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
+obj-$(CONFIG_PCI_FTPCI100) += pci-ftpci100.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_HYPERV) += pci-hyperv.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
new file mode 100644
index 000000000000..df9257dd57b0
--- /dev/null
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -0,0 +1,566 @@
+/*
+ * Support for Faraday Technology FTPC100 PCI Controller
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij at linaro.org>
+ *
+ * Based on the out-of-tree OpenWRT patch for Cortina Gemini:
+ * Copyright (C) 2009 Janos Laube <janos.dev at gmail.com>
+ * Copyright (C) 2009 Paulius Zaleckas <paulius.zaleckas at teltonika.lt>
+ * Based on SL2312 PCI controller code
+ * Storlink (C) 2003
+ */
+
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/bitops.h>
+#include <linux/irq.h>
+
+/*
+ * Special configuration registers directly in the first few words
+ * in he I/O space.
+ */
+#define PCI_IOSIZE	0x00
+#define PCI_PROT	0x04 /* AHB protection */
+#define PCI_CTRL	0x08 /* PCI control signal */
+#define PCI_SOFTRST	0x10 /* Soft reset counter and response error enable */
+#define PCI_CONFIG	0x28 /* PCI configuration command register */
+#define PCI_DATA	0x2C
+
+#define FARADAY_PCI_PMC			0x40 /* Power management control */
+#define FARADAY_PCI_PMCSR		0x44 /* Power management status */
+#define FARADAY_PCI_CTRL1		0x48 /* Control register 1 */
+#define FARADAY_PCI_CTRL2		0x4C /* Control register 2 */
+#define FARADAY_PCI_MEM1_BASE_SIZE	0x50 /* Memory base and size #1 */
+#define FARADAY_PCI_MEM2_BASE_SIZE	0x54 /* Memory base and size #2 */
+#define FARADAY_PCI_MEM3_BASE_SIZE	0x58 /* Memory base and size #3 */
+
+/* Bits 31..28 gives INTD..INTA status */
+#define PCI_CTRL2_INTSTS_SHIFT		28
+#define PCI_CTRL2_INTMASK_CMDERR	BIT(27)
+#define PCI_CTRL2_INTMASK_PARERR	BIT(26)
+/* Bits 25..22 masks INTD..INTA */
+#define PCI_CTRL2_INTMASK_SHIFT		22
+#define PCI_CTRL2_INTMASK_MABRT_RX	BIT(21)
+#define PCI_CTRL2_INTMASK_TABRT_RX	BIT(20)
+#define PCI_CTRL2_INTMASK_TABRT_TX	BIT(19)
+#define PCI_CTRL2_INTMASK_RETRY4	BIT(18)
+#define PCI_CTRL2_INTMASK_SERR_RX	BIT(17)
+#define PCI_CTRL2_INTMASK_PERR_RX	BIT(16)
+/* Bit 15 reserved */
+#define PCI_CTRL2_MSTPRI_REQ6		BIT(14)
+#define PCI_CTRL2_MSTPRI_REQ5		BIT(13)
+#define PCI_CTRL2_MSTPRI_REQ4		BIT(12)
+#define PCI_CTRL2_MSTPRI_REQ3		BIT(11)
+#define PCI_CTRL2_MSTPRI_REQ2		BIT(10)
+#define PCI_CTRL2_MSTPRI_REQ1		BIT(9)
+#define PCI_CTRL2_MSTPRI_REQ0		BIT(8)
+/* Bits 7..4 reserved */
+/* Bits 3..0 TRDYW */
+
+/*
+ * Memory configs:
+ * Bit 31..20 defines the PCI side memory base
+ * Bit 19..16 (4 bits) defines the size per below
+ */
+#define FARADAY_PCI_MEMBASE_MASK	0xfff00000
+#define FARADAY_PCI_MEMSIZE_1MB		0x0
+#define FARADAY_PCI_MEMSIZE_2MB		0x1
+#define FARADAY_PCI_MEMSIZE_4MB		0x2
+#define FARADAY_PCI_MEMSIZE_8MB		0x3
+#define FARADAY_PCI_MEMSIZE_16MB	0x4
+#define FARADAY_PCI_MEMSIZE_32MB	0x5
+#define FARADAY_PCI_MEMSIZE_64MB	0x6
+#define FARADAY_PCI_MEMSIZE_128MB	0x7
+#define FARADAY_PCI_MEMSIZE_256MB	0x8
+#define FARADAY_PCI_MEMSIZE_512MB	0x9
+#define FARADAY_PCI_MEMSIZE_1GB		0xa
+#define FARADAY_PCI_MEMSIZE_2GB		0xb
+#define FARADAY_PCI_MEMSIZE_SHIFT	16
+
+/*
+ * The DMA base is set to 0x0 for all memory segments, it reflects the
+ * fact that the memory of the host system starts at 0x0.
+ */
+#define FARADAY_PCI_DMA_MEM1_BASE	0x00000000
+#define FARADAY_PCI_DMA_MEM2_BASE	0x00000000
+#define FARADAY_PCI_DMA_MEM3_BASE	0x00000000
+
+/* Defines for PCI configuration command register */
+#define PCI_CONF_ENABLE		BIT(31)
+#define PCI_CONF_WHERE(r)	((r) & 0xFC)
+#define PCI_CONF_BUS(b)		(((b) & 0xFF) << 16)
+#define PCI_CONF_DEVICE(d)	(((d) & 0x1F) << 11)
+#define PCI_CONF_FUNCTION(f)	(((f) & 0x07) << 8)
+
+/**
+ * struct faraday_pci_variant - encodes IP block differences
+ * @cascaded_irq: this host has cascaded IRQs from an interrupt controller
+ *	embedded in the host bridge.
+ */
+struct faraday_pci_variant {
+	bool cascaded_irq;
+};
+
+struct faraday_pci {
+	struct device *dev;
+	void __iomem *base;
+	struct irq_domain *irqdomain;
+	struct pci_bus *bus;
+};
+
+static int faraday_res_to_memcfg(resource_size_t mem_base,
+				 resource_size_t mem_size,
+				 u32 *val)
+{
+	u32 outval;
+
+	switch (mem_size) {
+	case SZ_1M:
+		outval = FARADAY_PCI_MEMSIZE_1MB;
+		break;
+	case SZ_2M:
+		outval = FARADAY_PCI_MEMSIZE_2MB;
+		break;
+	case SZ_4M:
+		outval = FARADAY_PCI_MEMSIZE_4MB;
+		break;
+	case SZ_8M:
+		outval = FARADAY_PCI_MEMSIZE_8MB;
+		break;
+	case SZ_16M:
+		outval = FARADAY_PCI_MEMSIZE_16MB;
+		break;
+	case SZ_32M:
+		outval = FARADAY_PCI_MEMSIZE_32MB;
+		break;
+	case SZ_64M:
+		outval = FARADAY_PCI_MEMSIZE_64MB;
+		break;
+	case SZ_128M:
+		outval = FARADAY_PCI_MEMSIZE_128MB;
+		break;
+	case SZ_256M:
+		outval = FARADAY_PCI_MEMSIZE_256MB;
+		break;
+	case SZ_512M:
+		outval = FARADAY_PCI_MEMSIZE_512MB;
+		break;
+	case SZ_1G:
+		outval = FARADAY_PCI_MEMSIZE_1GB;
+		break;
+	case SZ_2G:
+		outval = FARADAY_PCI_MEMSIZE_2GB;
+		break;
+	default:
+		return -EINVAL;
+	}
+	outval <<= FARADAY_PCI_MEMSIZE_SHIFT;
+
+	/* This is probably not good */
+	if (mem_base & ~(FARADAY_PCI_MEMBASE_MASK))
+		pr_warn("truncated PCI memory base\n");
+	/* Translate to bridge side address space */
+	outval |= (mem_base & FARADAY_PCI_MEMBASE_MASK);
+	pr_dbg("Translated pci base @%08x, size %08x to config %08x\n",
+	       mem_base, mem_size, outval);
+
+	*val = outval;
+	return 0;
+}
+
+static int faraday_pci_read_config(struct pci_bus *bus, unsigned int fn,
+				  int config, int size, u32 *value)
+{
+	struct faraday_pci *p = bus->sysdata;
+
+	writel(PCI_CONF_BUS(bus->number) |
+			PCI_CONF_DEVICE(PCI_SLOT(fn)) |
+			PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
+			PCI_CONF_WHERE(config) |
+			PCI_CONF_ENABLE,
+			p->base + PCI_CONFIG);
+
+	*value = readl(p->base + PCI_DATA);
+
+	if (size == 1)
+		*value = (*value >> (8 * (config & 3))) & 0xFF;
+	else if (size == 2)
+		*value = (*value >> (8 * (config & 3))) & 0xFFFF;
+
+	dev_dbg(&bus->dev,
+		"[read]  slt: %.2d, fnc: %d, cnf: 0x%.2X, val (%d bytes): 0x%.8X\n",
+		PCI_SLOT(fn), PCI_FUNC(fn), config, size, *value);
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int faraday_pci_write_config(struct pci_bus *bus, unsigned int fn,
+				   int config, int size, u32 value)
+{
+	struct faraday_pci *p = bus->sysdata;
+	int ret = PCIBIOS_SUCCESSFUL;
+
+	dev_dbg(&bus->dev,
+		"[write] slt: %.2d, fnc: %d, cnf: 0x%.2X, val (%d bytes): 0x%.8X\n",
+		PCI_SLOT(fn), PCI_FUNC(fn), config, size, value);
+
+	writel(PCI_CONF_BUS(bus->number) |
+			PCI_CONF_DEVICE(PCI_SLOT(fn)) |
+			PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
+			PCI_CONF_WHERE(config) |
+			PCI_CONF_ENABLE,
+			p->base + PCI_CONFIG);
+
+	switch (size) {
+	case 4:
+		writel(value, p->base + PCI_DATA);
+		break;
+	case 2:
+		writew(value, p->base + PCI_DATA + (config & 3));
+		break;
+	case 1:
+		writeb(value, p->base + PCI_DATA + (config & 3));
+		break;
+	default:
+		ret = PCIBIOS_BAD_REGISTER_NUMBER;
+	}
+
+	return ret;
+}
+
+static struct pci_ops faraday_pci_ops = {
+	.read	= faraday_pci_read_config,
+	.write	= faraday_pci_write_config,
+};
+
+static void faraday_pci_ack_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~(0xF << PCI_CTRL2_INTSTS_SHIFT);
+	reg |= BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTSTS_SHIFT);
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_mask_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~((0xF << PCI_CTRL2_INTSTS_SHIFT)
+		 | BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTMASK_SHIFT));
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_unmask_irq(struct irq_data *d)
+{
+	struct faraday_pci *p = irq_data_get_irq_chip_data(d);
+	unsigned int reg;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	reg &= ~(0xF << PCI_CTRL2_INTSTS_SHIFT);
+	reg |= BIT(irqd_to_hwirq(d) + PCI_CTRL2_INTMASK_SHIFT);
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, reg);
+}
+
+static void faraday_pci_irq_handler(struct irq_desc *desc)
+{
+	struct faraday_pci *p = irq_desc_get_handler_data(desc);
+	struct irq_chip *irqchip = irq_desc_get_chip(desc);
+	unsigned int irq_stat, reg, i;
+
+	faraday_pci_read_config(p->bus, 0, FARADAY_PCI_CTRL2, 4, &reg);
+	irq_stat = reg >> PCI_CTRL2_INTSTS_SHIFT;
+
+	chained_irq_enter(irqchip, desc);
+
+	for (i = 0; i < 4; i++) {
+		if ((irq_stat & BIT(i)) == 0)
+			continue;
+		generic_handle_irq(irq_find_mapping(p->irqdomain, i));
+	}
+
+	chained_irq_exit(irqchip, desc);
+}
+
+static struct irq_chip faraday_pci_irq_chip = {
+	.name = "PCI",
+	.irq_ack = faraday_pci_ack_irq,
+	.irq_mask = faraday_pci_mask_irq,
+	.irq_unmask = faraday_pci_unmask_irq,
+};
+
+static int faraday_pci_irq_map(struct irq_domain *domain, unsigned int irq,
+			      irq_hw_number_t hwirq)
+{
+	irq_set_chip_and_handler(irq, &faraday_pci_irq_chip, handle_level_irq);
+	irq_set_chip_data(irq, domain->host_data);
+
+	return 0;
+}
+
+static const struct irq_domain_ops faraday_pci_irqdomain_ops = {
+	.map = faraday_pci_irq_map,
+};
+
+static int faraday_pci_setup_cascaded_irq(struct faraday_pci *p)
+{
+	struct device_node *intc = of_get_next_child(p->dev->of_node, NULL);
+	int irq;
+	int i;
+
+	if (!intc) {
+		dev_err(p->dev, "missing child interrupt-controller node\n");
+		return -EINVAL;
+	}
+
+	/* All PCI IRQs cascade off this one */
+	irq = of_irq_get(intc, 0);
+	if (!irq) {
+		dev_err(p->dev, "failed to get parent IRQ\n");
+		return -EINVAL;
+	}
+
+	p->irqdomain = irq_domain_add_linear(intc, 4,
+					     &faraday_pci_irqdomain_ops,
+					     p);
+	if (!p->irqdomain) {
+		dev_err(p->dev, "failed to create Gemini PCI IRQ domain\n");
+		return -EINVAL;
+	}
+
+	irq_set_chained_handler_and_data(irq, faraday_pci_irq_handler, p);
+
+	for (i = 0; i < 4; i++)
+		irq_create_mapping(p->irqdomain, i);
+
+	return 0;
+}
+
+static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+				     struct device_node *node)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+
+	parser->range = of_get_property(node, "dma-ranges", &rlen);
+	if (!parser->range)
+		return -ENOENT;
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+static int faraday_pci_parse_map_dma_ranges(struct faraday_pci *p,
+					    struct device_node *np)
+{
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	struct device *dev = p->dev;
+	u32 confreg[3] = {
+		FARADAY_PCI_MEM1_BASE_SIZE,
+		FARADAY_PCI_MEM2_BASE_SIZE,
+		FARADAY_PCI_MEM3_BASE_SIZE,
+	};
+	int i = 0;
+	u32 val;
+
+	if (pci_dma_range_parser_init(&parser, np)) {
+		dev_err(dev, "missing dma-ranges property\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Get the dma-ranges from the device tree
+	 */
+	for_each_of_pci_range(&parser, &range) {
+		u64 end = range.pci_addr + range.size - 1;
+		int ret;
+
+		ret = faraday_res_to_memcfg(range.pci_addr, range.size, &val);
+		if (ret) {
+			dev_err(dev,
+				"DMA range %d: illegal MEM resource size\n", i);
+			return -EINVAL;
+		}
+
+		dev_info(dev, "DMA MEM%d BASE: 0x%016llx -> 0x%016llx config %08x\n",
+			 i + 1, range.pci_addr, end, val);
+		if (i <= 2) {
+			faraday_pci_write_config(p->bus, 0, confreg[i],
+						 4, val);
+		} else {
+			dev_err(dev, "ignore extraneous dma-range %d\n", i);
+			break;
+		}
+
+		i++;
+	}
+
+	return 0;
+}
+
+static int faraday_pci_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct faraday_pci_variant *variant =
+		of_device_get_match_data(dev);
+	struct resource *regs;
+	resource_size_t io_base;
+	struct resource_entry *win;
+	struct faraday_pci *p;
+	struct resource *mem;
+	struct resource *io;
+	struct pci_host_bridge *host;
+	int ret;
+	u32 val;
+	LIST_HEAD(res);
+
+	host = pci_alloc_host_bridge(sizeof(*p));
+	if (!host)
+		return -ENOMEM;
+
+	host->dev.parent = dev;
+	host->ops = &faraday_pci_ops;
+	host->busnr = 0;
+	host->msi = NULL;
+	p = pci_host_bridge_priv(host);
+	host->sysdata = p;
+	p->dev = dev;
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	p->base = devm_ioremap_resource(dev, regs);
+	if (IS_ERR(p->base))
+		return PTR_ERR(p->base);
+
+	ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
+					       &res, &io_base);
+	if (ret)
+		return ret;
+
+	ret = devm_request_pci_bus_resources(dev, &res);
+	if (ret)
+		return ret;
+
+	/* Get the I/O and memory ranges from DT */
+	resource_list_for_each_entry(win, &res) {
+		switch (resource_type(win->res)) {
+		case IORESOURCE_IO:
+			io = win->res;
+			io->name = "Gemini PCI I/O";
+			if (!faraday_res_to_memcfg(io->start - win->offset,
+						   resource_size(io),
+						   &val)) {
+				/* setup I/O space size */
+				writel(val, p->base + PCI_IOSIZE);
+			} else {
+				dev_err(dev,
+					"illegal IO mem size\n");
+				return -EINVAL;
+			}
+			ret = pci_remap_iospace(io, io_base);
+			if (ret) {
+				dev_warn(dev, "error %d: failed to map resource %pR\n",
+					 ret, io);
+				continue;
+			}
+			break;
+		case IORESOURCE_MEM:
+			mem = win->res;
+			mem->name = "Gemini PCI MEM";
+			break;
+		case IORESOURCE_BUS:
+			break;
+		default:
+			break;
+		}
+	}
+
+	/* Setup hostbridge */
+	val = readl(p->base + PCI_CTRL);
+	val |= PCI_COMMAND_IO;
+	val |= PCI_COMMAND_MEMORY;
+	val |= PCI_COMMAND_MASTER;
+	writel(val, p->base + PCI_CTRL);
+
+	list_splice_init(&res, &host->windows);
+	ret = pci_register_host_bridge(host);
+	if (ret) {
+		dev_err(dev, "failed to register host: %d\n", ret);
+		return ret;
+	}
+	p->bus = host->bus;
+
+	/* Mask and clear all interrupts */
+	faraday_pci_write_config(p->bus, 0, FARADAY_PCI_CTRL2 + 2, 2, 0xF000);
+	if (variant->cascaded_irq) {
+		ret = faraday_pci_setup_cascaded_irq(p);
+		if (ret) {
+			dev_err(dev, "failed to setup cascaded IRQ\n");
+			return ret;
+		}
+	}
+
+	ret = faraday_pci_parse_map_dma_ranges(p, dev->of_node);
+	if (ret)
+		return ret;
+
+	pci_scan_child_bus(p->bus);
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+	pci_bus_assign_resources(p->bus);
+	pci_bus_add_devices(p->bus);
+	pci_free_resource_list(&res);
+
+	return 0;
+}
+
+/*
+ * We encode bridge variants here, we have at least two so it doesn't
+ * hurt to have infrastructure to encompass future variants as well.
+ */
+const struct faraday_pci_variant faraday_regular = {
+	.cascaded_irq = true,
+};
+
+const struct faraday_pci_variant faraday_dual = {
+	.cascaded_irq = false,
+};
+
+static const struct of_device_id faraday_pci_of_match[] = {
+	{
+		.compatible = "faraday,ftpci100",
+		.data = &faraday_regular,
+	},
+	{
+		.compatible = "faraday,ftpci100-dual",
+		.data = &faraday_dual,
+	},
+	{},
+};
+
+static struct platform_driver faraday_pci_driver = {
+	.driver = {
+		.name = "ftpci100",
+		.of_match_table = of_match_ptr(faraday_pci_of_match),
+	},
+	.probe  = faraday_pci_probe,
+};
+builtin_platform_driver(faraday_pci_driver);
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon Feb 27 14:07:19 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 27 Feb 2017 20:07:19 +0100
Subject: [OpenWrt-Devel] [PATCH 3/4 v3] ARM: gemini: select MIGHT_HAVE_PCI
In-Reply-To: <20170227190720.31409-1-linus.walleij@linaro.org>
References: <20170227190720.31409-1-linus.walleij@linaro.org>
Message-ID: <20170227190720.31409-3-linus.walleij@linaro.org>

As we have a PCI driver for the Gemini, we should select
MIGHT_HAVE_PCI.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2->v3:
- No changes

PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/mach-gemini/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-gemini/Kconfig b/arch/arm/mach-gemini/Kconfig
index a5ee5fbab796..21f89a4c16fe 100644
--- a/arch/arm/mach-gemini/Kconfig
+++ b/arch/arm/mach-gemini/Kconfig
@@ -6,6 +6,7 @@ menuconfig ARCH_GEMINI
 	select FTTMR010_TIMER
 	select GPIO_GEMINI
 	select GPIOLIB
+	select MIGHT_HAVE_PCI
 	select POWER_RESET
 	select POWER_RESET_SYSCON
 	select SERIAL_OF_PLATFORM
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From linus.walleij at linaro.org  Mon Feb 27 14:07:20 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 27 Feb 2017 20:07:20 +0100
Subject: [OpenWrt-Devel] [PATCH 4/4 v3] ARM: dts: add PCI to the Gemini
	device trees
In-Reply-To: <20170227190720.31409-1-linus.walleij@linaro.org>
References: <20170227190720.31409-1-linus.walleij@linaro.org>
Message-ID: <20170227190720.31409-4-linus.walleij@linaro.org>

The Cortina Gemini has an internal PCI root bus, add this to
the device tree, and add interrupt mapping (swizzling) to the
relevant systems device trees.

Cc: Janos Laube <janos.dev at gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas at gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Feng-Hsin Chiang <john453 at faraday-tech.com>
Cc: Greentime Hu <green.hu at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Change compatible string to "cortina,gemini-pci", "faraday,ftpci100";
- Add "dma-ranges" property, after deciphering that some hardcoded
  constants in the driver is really about this.
ChangeLog v1->v2:
- Change bus-range to <0x00 0xff>
- Drop the three extra IRQs that are unused
- Implement the right interrupt mapping/swizzling
- Push the interrupt mapping down to each affected system, only
  SQ201 for now.

PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/boot/dts/gemini-sq201.dts | 22 ++++++++++++++++++++
 arch/arm/boot/dts/gemini.dtsi      | 42 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
index dae2a70d8fbc..46309e79cc7b 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -92,5 +92,27 @@
 				read-only;
 			};
 		};
+
+		pci at 50000000 {
+			status = "okay";
+			interrupt-map-mask = <0xf800 0 0 7>;
+			interrupt-map =
+				<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
+				<0x4800 0 0 2 &pci_intc 1>,
+				<0x4800 0 0 3 &pci_intc 2>,
+				<0x4800 0 0 4 &pci_intc 3>,
+				<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
+				<0x5000 0 0 2 &pci_intc 2>,
+				<0x5000 0 0 3 &pci_intc 3>,
+				<0x5000 0 0 4 &pci_intc 0>,
+				<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
+				<0x5800 0 0 2 &pci_intc 3>,
+				<0x5800 0 0 3 &pci_intc 0>,
+				<0x5800 0 0 4 &pci_intc 1>,
+				<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
+				<0x6000 0 0 2 &pci_intc 0>,
+				<0x6000 0 0 3 &pci_intc 1>,
+				<0x6000 0 0 4 &pci_intc 2>;
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 3876feefc9d9..918e46546823 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -104,5 +104,47 @@
 			interrupt-controller;
 			#interrupt-cells = <2>;
 		};
+
+		pci at 50000000 {
+			compatible = "cortina,gemini-pci", "faraday,ftpci100";
+			/*
+			 * The first 256 bytes in the IO range is actually used
+			 * to configure the host bridge.
+			 */
+			reg = <0x50000000 0x100>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			#interrupt-cells = <1>;
+			status = "disabled";
+
+			bus-range = <0x00 0xff>;
+			/* PCI ranges mappings */
+			ranges =
+			/* 1MiB I/O space 0x50000000-0x500fffff */
+			<0x01000000 0 0          0x50000000 0 0x00100000>,
+			/* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
+			<0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
+
+			/* DMA ranges */
+			dma-ranges =
+			/* 128MiB at 0x00000000-0x07ffffff */
+			<0x02000000 0 0x00000000 0x00000000 0 0x08000000>,
+			/* 64MiB at 0x00000000-0x03ffffff */
+			<0x02000000 0 0x00000000 0x00000000 0 0x04000000>,
+			/* 64MiB at 0x00000000-0x03ffffff */
+			<0x02000000 0 0x00000000 0x00000000 0 0x04000000>;
+
+			/*
+			 * This PCI host bridge variant has a cascaded interrupt
+			 * controller embedded in the host bridge.
+			 */
+			pci_intc: interrupt-controller {
+				interrupt-parent = <&intcon>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#address-cells = <0>;
+				#interrupt-cells = <1>;
+			};
+		};
 	};
 };
-- 
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From ab at andi95.de  Mon Feb 27 16:33:57 2017
From: ab at andi95.de (=?UTF-8?Q?Andreas_Br=c3=a4u?=)
Date: Mon, 27 Feb 2017 22:33:57 +0100
Subject: [OpenWrt-Devel] GSoC 2017 - Freifunk accepted!
Message-ID: <e713fc88-ffc2-8d8b-739c-3ad26080c9a2@andi95.de>

Hi there,

today Google announced the organizations they choosed for GSoC 2017. I?m
happy to tell you: Freifunk is again accepted as mentoring organization
for Google Summer of Code together with 200 other OpenSource
organizations! Our friends from OpenWISP.org got accepted, too! Thanks
to all who helped making this application successful: those who
collected all the ideas (this year we have really a lot of ideas!),
those who talked to possible mentors and those who wrote the application
texts.

From ldpinney at gmail.com  Mon Feb 27 21:19:56 2017
From: ldpinney at gmail.com (L. D. Pinney)
Date: Mon, 27 Feb 2017 20:19:56 -0600
Subject: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware
	platform?
In-Reply-To: <d04aa40f-7e5f-b020-75fb-1a53856cc4b2@comcast.net>
References: <3ae13120-5ee9-fab9-19ea-41e7b14fb0b5@comcast.net>
 <CAJOqq5RJmA6XTPD-RzJuBQVsd8gtp1vSJv38D8VL5VxQDmeKRQ@mail.gmail.com>
 <530f93c6-8334-8538-1566-ea9cbdf2dc81@comcast.net>
 <CAJOqq5R-Mm=BnunaZbWiXVeqDL2BQghcSo=gwQ=wtQyHQbMetg@mail.gmail.com>
 <d04aa40f-7e5f-b020-75fb-1a53856cc4b2@comcast.net>
Message-ID: <CAJOqq5TyW9W9DS1OMCxRip-HnM0qGjuAaph=a-YE+=sUevT0wg@mail.gmail.com>

On Mon, Feb 27, 2017 at 11:32 AM, Dana Myers <k6jq at comcast.net> wrote:

> On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <k6jq at comcast.net <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:
>
> >* On 2/22/2017 6:18 PM, L. D. Pinney wrote:
> *>>>* spi-mt7621.c has bugs ... isn't very helpful.
> *>>>* I am a bit surprised you're not already aware of the SPI issues.
> *>>I am not surprised at all ... ALL of my MT76x8 devices have only a single
> SPI-NOR Chip connected to the SPI.
> On every device it works as intended ... load the OS.
>
>
> Of course - that's surely why this hardware bug in the MediaTek SPI
> peripheral
> escaped from the factory; they implement and document functionality
> (full-duplex
> operation), and either didn't test it or didn't regard the bug as
> critical. The
> critical use-case of the SPI port is to read the flash device, which is
> half-duplex,
> but that's not the only documented use of the SPI port.
>
> MediaTek documents the SPI port as a general peripheral (and provides
> an additional select line), and there's a bug in the hardware.
>
> Whenever you (or anyone) adds functionality to a device you can expect
> problems.
>
> Thanks, though this isn't relevant at all. I'm not *adding* functionality
> to the device.
> There's a bug in the SPI controller that's exposed when you try to use it
> as documented.
>
> In this case some device foreign to the actual device in question.
> More specifically a device such as a RFID module or STM32.
>
> Disagree this IS relevant.
The device in your case is the Onion Omega2.
There is only ONE thing connected to the SPI ... the NOR chip.
Is your second or third SPI peripheral soldered to the board?
Basically OpenWrt is working OK until you add something.
The problem is only present when something ELSE is connected to SPI.

> This isn't the case at all. There's a bug in the MediaTek SPI controller
> completely
> independent of what (if anything) is attached to it. Simply attempting to
> *send*
> a byte in full-duplex mode results in corrupted bits coming out of the
> MediaTek
> SPI Master-Out line. It has absolutely nothing to do with external
> devices. It's a
> bug in the MediaTek controller.
>
> This has been interesting bit of bikeshedding, but back to my original
> question.
>
If you have a working patch...You can start here :
>

> https://lede-project.org/docs/guide-developer/the-source-code
>
>
> I have a working patch. I know how to do a PR. I know how to RTFM :-)
> Which brings us full-circle to my initial query...
>

Why don't you post the [PATCH] here or even better to the LEDE-DEV list
where it is more likely to find 'action'


>
> My concern (as alluded to in the subject line) is that I have a patch that
> I know for certain is required for the MT7688 and I've tested on the
> MT7688.
> I don't have other MT76xx variants to  to verify the presence of  the
> hardware
> bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
> question is how to apply this patch for only the mt7688 target.
>

My question is :

If you have a patch...why don't YOU know where to apply it?
If you expect someone help post the patch....even if YOU don't know what to
do with it.

You will find it difficult to apply your patch specifically to mt7688.
It would more properly apply in target/linux/ramips/patches-4.? and thus be
applied to mt76?? as needed.


>
> However, the more I think about it, I strongly suspect this bug is present
> on all variants of the MT76xx, so the patch should be generically applied;
> I need to find confirmation; I'll try contacting MediaTek.
>

I hope you can speak ZH-TW :)
You seem to be using LEDE.
Which brings up the question of why are you posting to the OpenWrt-dev list?
When you aren't using OpenWrt and seem to know full well from this thread
that the patch should be applied upstream?


> Thanks,
> Dana  K6JQ
>
>
> You can start here:
> >>*     https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 <https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20>
> *>>* which links to another forum thread which contains this *very* informative
> *>* posting:
> *>>*     http://52.76.69.244/jforum/posts/list/30/3683.page#12266 <http://52.76.69.244/jforum/posts/list/30/3683.page#12266>
> *>>* and suggested patch:
> *>>*     http://52.76.69.244/jforum/posts/list/30/3683.page#12299 <http://52.76.69.244/jforum/posts/list/30/3683.page#12299>
> *>>* which is the basis of the patch I'm using.
> *>>* Please describe the problem?
> *>>* berniwa does a much better job than me in the above-linked posting.
> *>>>* Can I reproduce the same problem on one of my many MT76x8 devices?
> *>* If so how?
> *>>>* I've only seen reports of  the issue on MT7688-based devices (LinkIt 7688,
> *>* Omega2)
> *>* and I personally have observed it on the Omega2.
> *>>* The easiest way to reproduce it is to attempt to send an SPI sequence
> *>* starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll
> *>* find
> *>* the leading '1' bit is sent as a '0'.
> *>>* I'd be somewhat surprised if the same issue wasn't present on all devices
> *>* which
> *>* incorporate the MT7621 SPI peripheral given the likelihood that MediaTek
> *>* reproduces the same logic on every chip that includes the peripheral.
> *>>* The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's
> *>* patch addresses by breaking up a transfer as needed (keeping chip select
> *>* asserted).
> *>>>* The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
> *>* The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.
> *>>>* Understood; I didn't say that MediaTek was using the *same* patch, but that
> *>* this issue is present on all MT7688 devices and that MediaTek has
> *>* incorporated
> *>* a patch for it. The patch I'm using is for 4.4, of course.
> *>>* If you could confirm the presence of  the issue on other MT7621-based SPI
> *>* peripherals, that would address my initial inquiry indirectly if we could
> *>* just
> *>* patch all instances of the MT7621 SPI build :-)
> *>>* Cheers,
> *>* Dana  K6JQ
> *>>>>>>>* On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:
> *>>>* On 2/22/2017 4:27 PM, L. D. Pinney wrote:
> *>>>>* Are you using https://github.com/OnionIoT/source <https://github.com/OnionIoT/source> onion-omega2 branch ?
> *>>>>>>* I am not; I'm using https://github.com/lede-project/source <https://github.com/lede-project/source> (master
> *>>* branch)
> *>>>>* However, I don't believe it makes any difference - spi-mt7621.c appears
> *>>* to be identical in both and the same patch applies; and this isn't an
> *>>* Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
> *>>* Labs patched their LinkIt repo for this. A fix really belongs upstream.
> *>>>>* Thanks -
> *>>* Dana
> *>>>>>>* On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:
> *>>>>>>>>* I'm working with the Onion Omega2, which is based on an MT7688 SoC.
> *>>>* The MT7688 SoC is a variant of the MT76xx family; in particular, it
> *>>>* shares the same SPI peripheral. Support for SPI is in
> *>>>* ..../drivers/spi/mt7621.c
> *>>>>>>* However, there's  bugs with the SPI in the MT7688 which require a patch
> *>>>* to spi-mt7621.c - and I don't know if the same bugs are present in the
> *>>>* other MT76xx family members. It is possible the other MT76xx SoCs have
> *>>>* the same hardware issue (I'd be surprised if not) but I can only test
> *>>>* the MT7688 I have.
> *>>>>>>* I think I want to patch the source file only when building only the
> *>>>* MT7688
> *>>>* target, but I'm not sure how to do that or if it's supported.
> *>>>>>>* So I'm looking for advice on how I might incorporate this patch so
> *>>>* that it is only applied when building ramips/mt7688.
> *>>>>>>* Thanks,
> *>>>* Dana K6JQ
> *>>>* _______________________________________________
> *>>>* openwrt-devel mailing list
> *>>>* openwrt-devel at lists.openwrt.org <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
> *>>>* https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
> *>>>>>>>>>>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170227/86f1518d/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From thewerthfam at gmail.com  Mon Feb 27 21:22:47 2017
From: thewerthfam at gmail.com (TheWerthFam)
Date: Mon, 27 Feb 2017 21:22:47 -0500
Subject: [OpenWrt-Devel] trunk for the sunxi platform has a few
	inconsistencies
Message-ID: <a43b3045-a9fb-3476-5d88-754aa71188af@gmail.com>

I'm running the latest LEDE snapshop on the sunxi platform.  The 4.4 
kernel is a nice upgrade.
While using the image I've noticed a few inconsistencies.
The WAN LED is missing on this platform, could be since this uses a USB 
wifi adapter.  I see from the wiki page the WAN leds seem to be created 
by default on other platofms and not an extra package.
ls -l  /sys/class/leds/
lrwxrwxrwx    1 root     root             0 Jan  1  1970 
lamobo_r1:green:usr -> ../../devices/platform/leds/leds/lamobo_r1:green:usr
lrwxrwxrwx    1 root     root             0 Feb 28 02:03 
rt2800usb-phy0::assoc -> 
../../devices/platform/soc at 01c00000/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::assoc
lrwxrwxrwx    1 root     root             0 Feb 28 02:03 
rt2800usb-phy0::quality -> 
../../devices/platform/soc at 01c00000/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::quality
lrwxrwxrwx    1 root     root             0 Feb 28 02:03 
rt2800usb-phy0::radio -> 
../../devices/platform/soc at 01c00000/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::radio

Secondly I know that procd has had lots more development for this 
release.  I'm finding that the Procd  triggers for config file changes 
don't seem to work consistently.  These triggers worked on CC 15.05.1.  
Are the procd rc.buttons working consistently?
Sample relevant code section.
#!/bin/sh /etc/rc.common
#
START=95
USE_PROCD=1
...
...
My customapp has service_triggers()
Service_triggers()
{
     procd_open_trigger
     procd_add_reload_trigger "mycustomapp"
     procd_close_trigger
}

Changing /etc/config/mycustomapp doesn't trigger a reload or restart of 
the /etc/init.d/mycustomapp
Any advice much appreciated.

     Cheers
         Derek
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

From pieter.smith at philips.com  Tue Feb 28 04:42:05 2017
From: pieter.smith at philips.com (Smith, Pieter)
Date: Tue, 28 Feb 2017 09:42:05 +0000
Subject: [OpenWrt-Devel] opkg: installation order of dependencies seems
	broken
In-Reply-To: <83abf280b4014e9a8b0074e38b391369@VI1PR9003MB0253.MGDPHG.emi.philips.com>
References: <83abf280b4014e9a8b0074e38b391369@VI1PR9003MB0253.MGDPHG.emi.philips.com>
Message-ID: <8d6c8410e4e747e69629d8cbe2aa6f02@VI1PR9003MB0253.MGDPHG.emi.philips.com>

Hi,

I am having trouble with the OpenWRT build not respecting package dependencies
in determining the installation order. This typically messes up script or
config overwriting by adding a dependent package.

I opened an issue (https://github.com/openwrt/openwrt/issues/401) for this, but
would appreciate one of the maintainers confirming that the issue is indeed
undesired behavior.

I traced the cause back to what I consider a flaw in opkg, and opened a pull
request (https://github.com/openwrt/openwrt/pull/402).

Can someone please have a look at this and confirm if this indeed is undesired
behavior?

Thanks,
Pieter Smith


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

