Re: [OpenWrt-Devel] [PATCH 4/4] ARM: dts: add PCI to the Gemini DTSI

2017-02-06 Thread Hans Ulli Kroll
Hi Linus,

On Sun, 5 Feb 2017, Linus Walleij wrote:

> On Sun, Feb 5, 2017 at 11:03 AM, Hans Ulli Kroll
>  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@4800!
> (...)
> > -   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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

2017-02-06 Thread Karl Palsson

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  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@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Nanostation m5 XW ethernet patch gone

2017-02-06 Thread Tiziano Bacocco
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: 
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel