Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network
> According to https://wiki.openwrt.org/toh/linksys/wrt_ac_series, they > have different switch layouts, especially mamba(WRT1900ac v1). No, they do not - all three switches (=all five devices) have this layout: Switch Port | Function / External Port 0 | LAN 4 1 | LAN 3 2 | LAN 2 3 | LAN 1 4 | WAN 5 | eth0 6 | eth1 The assignment of the ports to a specific VLAN is done arbitraryly. And what you found on the wiki is this artificial complication of things, which I want to address with my patch. Do you agree? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network
According to https://wiki.openwrt.org/toh/linksys/wrt_ac_series, they have different switch layouts, especially mamba(WRT1900ac v1). Best Regards, Syrone Wong On Sat, Oct 29, 2016 at 2:22 AM, wrote: > From: Paul Wassi > > Unify switch configuration on Linksys WRTxx00AC series. > LAN = eth0, WAN = eth1 > > Signed-off-by: Paul Wassi > --- > In the OpenWrt wiki, it can be seen that the Linksys WRTxx00AC series > has a device dependent switch configuration: > https://wiki.openwrt.org/toh/linksys/wrt_ac_series#switch_layout > All devices have eth0 and eth1, however some devices set eth0 as LAN, eth1 as > WAN, > while others do it the other way 'round: eth0 = WAN, eth1 = LAN. > As I don't see a technical requirement to have these differences, couldn't we > make life (and code) easier by unifying switch configuration among these > devices. > I.e. the WRTxx00AC series would then have eth0 = LAN, eth1 = WAN and > therefore share > the same lines of code (for network configuration). > > linux/mvebu/base-files/etc/board.d/02_network |6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network > b/target/linux/mvebu/base-files/etc/board.d/02_network > --- a/target/linux/mvebu/base-files/etc/board.d/02_network > +++ b/target/linux/mvebu/base-files/etc/board.d/02_network > @@ -15,11 +15,7 @@ case "$board" in > armada-385-linksys-caiman|\ > armada-385-linksys-cobra|\ > armada-385-linksys-rango|\ > -armada-385-linksys-shelby) > - ucidef_set_interfaces_lan_wan "eth1" "eth0" > - ucidef_add_switch "switch0" \ > - "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "6@eth1" "4:wan" > "5@eth0" > - ;; > +armada-385-linksys-shelby|\ > armada-xp-linksys-mamba) > ucidef_set_interfaces_lan_wan "eth0" "eth1" > ucidef_add_switch "switch0" \ > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Stability & release plans -- CVE-2016-5195
On 10/28/2016 11:39 AM, yanosz wrote: 1. I'm unhappy with the state of OpenWRT at the moment. I see some trouble in building and releasing. The current code base has some bugs. I'ven't seen a fix for "mad cow" yet. For me it is hard to estimate whether OpenWRT is able to include, build and release critical patches over the next months in a timely fashion. My impression is that CVE-2016-5195 (also known by it's marketing name for low-intellect individuals as "dirty COW") is mostly a non-issue on OpenWRT/LEDE. This is why you have not heard much about a response for it. The exploit is a privilege escalation. However, almost everything on a standard LEDE/OpenWRT system already runs as root anyway, since these kinds of systems are not designed for multi-user scenarios. Conversely, this exploit is a huge deal on Android for the very same reason it's a non-issue on LEDE/OpenWRT. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube
On Fri, 2016-10-28 at 19:14 +0300, Antti Seppälä wrote:
> On 28 October 2016 at 17:30, Ben Mulvihill wrote:
> > Add device tree binding for dwc2 usb driver on lantiq danube
> >
> > Signed-off-by: Ben Mulvihill
> > ---
> > diff -uprN a/target/linux/lantiq/dts/danube.dtsi
> > b/target/linux/lantiq/dts/danube.dtsi
> > --- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27
> > 19:56:07.090392399 +0200
> > +++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27
> > 20:47:34.387511522 +0200
> > @@ -140,7 +140,7 @@
> > };
> >
> > ifxhcd@E101000 {
> > - compatible = "lantiq,ifxhcd-danube";
> > + compatible = "lantiq,ifxhcd-danube",
> > "lantiq,ifxhcd-danube-dwc2";
> > reg = <0xE101000 0x1000
> > 0xE12 0x3f000>;
> > interrupt-parent = <&icu0>;
> >
> >
>
> Hi.
>
> Have you tried if danube can simply be compatible with vanilla "snps,dwc2"?
>
> The main reason we created our own definition for lantiq is that arx
> and xrx have fifo sizes smaller than what the dwc2 autodetection
> mechanism expects.
> I remember finding some references in ifxhcd code which would suggest
> that danube had bigger fifo and thus would maybe work without any
> special treatment.
>
> Br,
I'm pretty sure I tried it, but must have been a couple of years
ago and I can't remember why it didn't work. I'll have another go.
Thanks for the suggestion,
Ben
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] o2 box 6431 / VGV7510KW22 - SIP with FXS/TAE Ports | owsip or alternative ?
Give a look at https://github.com/pgid69/bcm63xx-phone/tree/master/bcm63xx-ast-chan they have the same source for both 1.8 1.11 and 1.13, it seems that it does change just the makefile... maybe it can be applied to lantiq asterisk-tapi Regards On Mon, Oct 3, 2016 at 1:56 AM, Hauke Mehrtens wrote: > On 09/23/2016 09:02 PM, Daniel Golle wrote: >> On Fri, Sep 23, 2016 at 08:14:24PM +0200, Dennis Schneck wrote: >>> >>> >>> >>> Hello, >>> i use the o2 box 6431 / VGV7510KW22 with LEDE r1640. >>> Like to use my SIP Accout with the 3x FXS Ports (Analog Phone / TAE Ports) >>> >>> I read about owsip but can not find a package. >>> Is there a simular package for lede ? >> >> No. owsip disappeared a while ago, asterisk-chan-lantiq was dropped >> with asterisk-1.8.x being moved to packages-abandoned, but it may >> possible to still build it. If you want to give asterisk-1.8.x with >> chan-lantiq a shot, I'd be happy to assist and maybe even forward- >> port things to asterisk-13.x -- on this box having plenty of RAM >> and flash, this might actually be a quite nice option. > > Hi Daniel, > > I looked into it and was unable to find any documentation on how to > write a asterisk channel driver. Do you know some documentation or > should I look into the code of the other channel drivers? My plan was to > port the lantiq channel driver to asterisk 1.13.x. > > Hauke > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube
On Fri, 2016-10-28 at 18:28 +0200, Christian Lamparter wrote:
> Hello,
>
> On Friday, October 28, 2016 4:30:56 PM CEST Ben Mulvihill wrote:
> > Add device tree binding for dwc2 usb driver on lantiq danube
> >
> > Signed-off-by: Ben Mulvihill
> > ---
> > diff -uprN a/target/linux/lantiq/dts/danube.dtsi
> > b/target/linux/lantiq/dts/danube.dtsi
> > --- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27 19:56:07.090392399
> > +0200
> > +++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27 20:47:34.387511522
> > +0200
> > @@ -140,7 +140,7 @@
> > };
> >
> > ifxhcd@E101000 {
> > - compatible = "lantiq,ifxhcd-danube";
> > + compatible = "lantiq,ifxhcd-danube",
> > "lantiq,ifxhcd-danube-dwc2";
> Usually for device tree, the first compatible string is reserved for the
> "exact device" that the node represents [0]. So wouldn't switching around
> the strings (i.e.: "lantiq,ifxhcd-danube-dwc2", "lantiq,ifxhcd-danube")
> make more sense? After all, the dwc2 is the "more exact device" in this case?
>
Thanks for reviewing.
Are they not equally "exact"? They are two alternative, and completely
separate, drivers. (The names chosen for the bindings are perhaps a
little misleading in that regard.) I Left "lantiq,ifxhcd-danube" in
first position simply because it has been the default driver until
now, and I didn't want to change the default at this stage. Not that
it will make any difference to which driver is actually used unless
for some strange reason someone decides to include both drivers in
the same build.
Once we're sure that dwc2 works properly on danube, the old
ifxhcd-danube driver can be ditched from the source tree completely.
But I thought it was better to get an ack from John on
these first.
> > reg = <0xE101000 0x1000
> > 0xE12 0x3f000>;
> > interrupt-parent = <&icu0>;
> >
>
> [0]
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] package net/cifs-utils: missing dependency?
From: Paul Wassi Add dependency to kmod-fs-cifs Signed-off-by: Paul Wassi --- 'cifsmount' alone is not able to mount a SMB share, after having installed kmod-fs-cifs this was possible. So I guess adding kmod-fs-cifs as a dependency to cifsmount is ok. diff --git a/net/cifs-utils/Makefile b/net/cifs-utils/Makefile --- a/net/cifs-utils/Makefile +++ b/net/cifs-utils/Makefile @@ -24,6 +24,7 @@ include $(INCLUDE_DIR)/package.mk define Package/cifsmount SECTION:=net CATEGORY:=Network + DEPENDS:=+kmod-fs-cifs TITLE:=CIFS mount utilities URL:=http://wiki.samba.org/index.php/LinuxCIFS_utils endef ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Stability & release plans
Hello, Am 10/24/2016 um 06:50 PM schrieb Jo-Philipp Wich: > Hi yanosz, > > Alberto kindly pointed out that your inquiry didn't receive any response > so far, so please excuse the lack of communication. Thanks for your time and effort here - I really appreciate your feedback. I'd like to provide a few thoughts on this. May it helps, maybe it doesn't. 1. I'm unhappy with the state of OpenWRT at the moment. I see some trouble in building and releasing. The current code base has some bugs. I'ven't seen a fix for "mad cow" yet. For me it is hard to estimate whether OpenWRT is able to include, build and release critical patches over the next months in a timely fashion. 2. When looking at lede I'm somewhat missing the release engineering part. This has nothing to do with infrastructure or build setups or even coding. When looking at Debian they have a release team taking care of freezing, planning and releases. - or take Theo de Raadt's job in OpenBSD for instance. IMHO From a release engineering point of view it's good to do release if a software is reasonable better then the one released before. >From a developer's point of view, it's good to release, if he or she feels confident with his or her work and all annoying bugs are fixed. IMHO planning a lede release is worth the effort if it's reasonable better then the last OpenWRT-Release, no matter what bugs, refactorings or infrastructure issue are outstanding, still. Having a fixed schedule (every 6/8/12 months) or so will ease discussion on when to release and what features to include, since freeze-dates, commit-handling etc. are more or less fixed. IMHO it is an interesting idea to announce a release in six months or so (one year after its founding :-) ), make a plan on freezing / branching / etc. and stick to fixed schedule (every n months) I offered help on this to nbd on 2012's (2013 .. maybe) Wireless Community Week and my offer is still stands. Not being a OpenWRT / lede veteran I'm not interesting in taking the lead here. I'm not interested in bossing somebody around of becoming a ego-manic project lead ..,. Back in 2012, there was hardly any interest in this kind of help, but I'm not sure, if the lede split has changed anything here. 3. I think, gluon is doing an good job here. They're taking the OpenWRT / lede codebase and release it in a concise way. Unfortunately - due to releasing no binary artifacts - they address power-users instead of novices. And gluon - in its current form - can hardly be used to just flash and use a SOHO router for whatever is interesting. I don't know much about tcatm's plans for gluon. I don't know, if binary releases are on its map or if synchronizing gluon and lede releases is a good idea. But ... IMHO it's worth thinking about this. That's it. I'll be at the 33c3 by the end of the year, so if you're interested discussing this in person, I'm available ;-). Greetz, yanosz -- For those of you without hope, we have rooms with color TV, cable and air conditioning ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Arcadyan vrv9510kwac23
On Fri, Oct 28, 2016 at 10:43 AM, Juan Rios wrote: > anyone can help? its already working. > > Just need guidance about best place to put the configuration for it > and register the callback... maybe it would be best to place it inside the .dts? if I had to implement it I'd see if I can adjust the wifi driver (b43 in your case I guess) to allow passing the MAC-address via devicetree see my ath9k patches (which are waiting to be accepted upstream): [0] for the documentation and [1] for the ath9k driver changes [1] (on a side-note: Mathias Kresin and me are planning to use this in LEDE as soon as it's accepted upstream) Martin [0] https://patchwork.kernel.org/patch/9378317/ [1] https://patchwork.kernel.org/patch/9378321/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network
From: Paul Wassi Unify switch configuration on Linksys WRTxx00AC series. LAN = eth0, WAN = eth1 Signed-off-by: Paul Wassi --- In the OpenWrt wiki, it can be seen that the Linksys WRTxx00AC series has a device dependent switch configuration: https://wiki.openwrt.org/toh/linksys/wrt_ac_series#switch_layout All devices have eth0 and eth1, however some devices set eth0 as LAN, eth1 as WAN, while others do it the other way 'round: eth0 = WAN, eth1 = LAN. As I don't see a technical requirement to have these differences, couldn't we make life (and code) easier by unifying switch configuration among these devices. I.e. the WRTxx00AC series would then have eth0 = LAN, eth1 = WAN and therefore share the same lines of code (for network configuration). linux/mvebu/base-files/etc/board.d/02_network |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network b/target/linux/mvebu/base-files/etc/board.d/02_network --- a/target/linux/mvebu/base-files/etc/board.d/02_network +++ b/target/linux/mvebu/base-files/etc/board.d/02_network @@ -15,11 +15,7 @@ case "$board" in armada-385-linksys-caiman|\ armada-385-linksys-cobra|\ armada-385-linksys-rango|\ -armada-385-linksys-shelby) - ucidef_set_interfaces_lan_wan "eth1" "eth0" - ucidef_add_switch "switch0" \ - "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "6@eth1" "4:wan" "5@eth0" - ;; +armada-385-linksys-shelby|\ armada-xp-linksys-mamba) ucidef_set_interfaces_lan_wan "eth0" "eth1" ucidef_add_switch "switch0" \ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube
Hello,
On Friday, October 28, 2016 4:30:56 PM CEST Ben Mulvihill wrote:
> Add device tree binding for dwc2 usb driver on lantiq danube
>
> Signed-off-by: Ben Mulvihill
> ---
> diff -uprN a/target/linux/lantiq/dts/danube.dtsi
> b/target/linux/lantiq/dts/danube.dtsi
> --- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27 19:56:07.090392399
> +0200
> +++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27 20:47:34.387511522
> +0200
> @@ -140,7 +140,7 @@
> };
>
> ifxhcd@E101000 {
> - compatible = "lantiq,ifxhcd-danube";
> + compatible = "lantiq,ifxhcd-danube",
> "lantiq,ifxhcd-danube-dwc2";
Usually for device tree, the first compatible string is reserved for the
"exact device" that the node represents [0]. So wouldn't switching around
the strings (i.e.: "lantiq,ifxhcd-danube-dwc2", "lantiq,ifxhcd-danube")
make more sense? After all, the dwc2 is the "more exact device" in this case?
> reg = <0xE101000 0x1000
> 0xE12 0x3f000>;
> interrupt-parent = <&icu0>;
>
[0]
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube
On 28 October 2016 at 17:30, Ben Mulvihill wrote:
> Add device tree binding for dwc2 usb driver on lantiq danube
>
> Signed-off-by: Ben Mulvihill
> ---
> diff -uprN a/target/linux/lantiq/dts/danube.dtsi
> b/target/linux/lantiq/dts/danube.dtsi
> --- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27 19:56:07.090392399
> +0200
> +++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27 20:47:34.387511522
> +0200
> @@ -140,7 +140,7 @@
> };
>
> ifxhcd@E101000 {
> - compatible = "lantiq,ifxhcd-danube";
> + compatible = "lantiq,ifxhcd-danube",
> "lantiq,ifxhcd-danube-dwc2";
> reg = <0xE101000 0x1000
> 0xE12 0x3f000>;
> interrupt-parent = <&icu0>;
>
>
Hi.
Have you tried if danube can simply be compatible with vanilla "snps,dwc2"?
The main reason we created our own definition for lantiq is that arx
and xrx have fifo sizes smaller than what the dwc2 autodetection
mechanism expects.
I remember finding some references in ifxhcd code which would suggest
that danube had bigger fifo and thus would maybe work without any
special treatment.
Br,
--
Antti
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/28/2016 05:21 PM, Jo-Philipp Wich wrote: > Hi Zefir, > > what do you mean with overlay patches exactly? > > ~ Jo > I mean adding some private patches on top of those already contained in the package's patches directory without touching the package itself. I thought the same overlay mechanism available for overwriting installation files would be easy to implement, but seems a bit tricky. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
Hi Zefir, what do you mean with overlay patches exactly? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] replacing files in base system from a package?
On 10/17/2016 11:38 AM, Zefir Kurtisi wrote: > On 10/16/2016 01:04 AM, Jo-Philipp Wich wrote: >> Hi Karl, >> >> let me introduce a not strictly new way but another heavily under >> documented buildroot feature which you can use to implement custom >> modifications to packages which do not require source code edits. >> > Wow! - this really deserves an easier to find documentation - I was looking > for > that feature several times but never got to it. > > We used to have copies of packages for only minor modifications in init or > config > files. If it works as described, this will reduce a lot of overhead. > > > Thank you, very helpful. > > Hello Jo, indeed, it works as described, thanks. Is there some similar mechanism in place for adding overlay patches? >From what I understand one would need to expand Build/Prepare, but it is not obvious (to me at least) how to extend the list of patches. Cheers ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/3] lantiq: enable dwc2 in danube dtsi
define device tree binding for dwc2 usb driver on danube boards
as well as arx and xrx.
Signed-off-by: Ben Mulvihill
---
diff -uprN a/target/linux/lantiq/patches-4.4/0041-USB-DWC2-add-ltq-params.patch
b/target/linux/lantiq/patches-4.4/0041-USB-DWC2-add-ltq-params.patch
--- a/target/linux/lantiq/patches-4.4/0041-USB-DWC2-add-ltq-params.patch
2016-01-26 18:50:04.584650092 +0100
+++ b/target/linux/lantiq/patches-4.4/0041-USB-DWC2-add-ltq-params.patch
2016-01-30 09:45:30.415980545 +0100
@@ -35,10 +35,11 @@
/**
* dwc2_lowlevel_hw_enable - enable platform lowlevel hw resources
* @hsotg: The driver state
-@@ -310,6 +338,8 @@ static int dwc2_driver_remove(struct pla
+@@ -310,6 +338,9 @@ static int dwc2_driver_remove(struct pla
static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
{ .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
++ { .compatible = "lantiq,ifxhcd-danube-dwc2", .data = ¶ms_ltq },
+ { .compatible = "lantiq,ifxhcd-arx100-dwc2", .data = ¶ms_ltq },
+ { .compatible = "lantiq,ifxhcd-xrx200-dwc2", .data = ¶ms_ltq },
{ .compatible = "snps,dwc2", .data = NULL },
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/3] lantiq: add device tree binding for dwc2 on danube
Add device tree binding for dwc2 usb driver on lantiq danube
Signed-off-by: Ben Mulvihill
---
diff -uprN a/target/linux/lantiq/dts/danube.dtsi
b/target/linux/lantiq/dts/danube.dtsi
--- a/target/linux/lantiq/dts/danube.dtsi 2016-10-27 19:56:07.090392399
+0200
+++ b/target/linux/lantiq/dts/danube.dtsi 2016-10-27 20:47:34.387511522
+0200
@@ -140,7 +140,7 @@
};
ifxhcd@E101000 {
- compatible = "lantiq,ifxhcd-danube";
+ compatible = "lantiq,ifxhcd-danube",
"lantiq,ifxhcd-danube-dwc2";
reg = <0xE101000 0x1000
0xE12 0x3f000>;
interrupt-parent = <&icu0>;
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/3] lantiq: initialise dwc2 on danube
Initialise the dwc2 usb driver on danube boards as well as ar9 and vr9.
Signed-off-by: Ben Mulvihill
---
diff -uprN
a/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
b/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
---
a/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
1970-01-01 01:00:00.0 +0100
+++
b/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
2016-01-20 09:43:35.522128608 +0100
@@ -0,0 +1,10 @@
+--- a/arch/mips/lantiq/xway/reset.c2016-01-20 08:45:18.382597595 +0100
b/arch/mips/lantiq/xway/reset.c2016-01-20 08:45:31.927107016 +0100
+@@ -370,6 +370,7 @@ static int __init mips_reboot_setup(void
+ panic("Failed to remap core memory");
+
+ if (of_machine_is_compatible("lantiq,ar9") ||
++ of_machine_is_compatible("lantiq,danube") ||
+ of_machine_is_compatible("lantiq,vr9"))
+ ltq_usb_init();
+
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/3] lantiq: enable dwc2 usb driver for danube
The following 3 patches enable lantiq danube targets to be compiled with the dwc2 usb driver instead of ifxhcd. I have tested usb storage and a usb sound card on a home hub 2B and both seem to work fine. The only problem I have identified is that a couple of mode mismatch interrupts are logged whenever a new device is inserted. This does not happen with the ifxhcd driver or with the dwc2 driver on ar9, and does not seem to affect the subsequent functioning of the device. For the moment, I have not included patches to switch danube profiles over to dwc2 by default. Ben Mulvihill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH V2] apm821xx: fix USB LED trigger for WNDR4700
On 28 October 2016 at 12:46, Christian Lamparter
wrote:
> On Friday, October 28, 2016 12:40:01 PM CEST Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> The old usbdev trigger never supported assigning more than 1 USB port.
>> This code we got was never working as expected and it was missing 2 more
>> ports. Switch to usbport to have LED working with all ports.
>>
> Tested-by: Christian Lamparter
>> Signed-off-by: Rafał Miłecki
>
> Thanks!
>
> here's a explanation what's going on with the multiple port and usb
> definitions:
>
> The WNDR4700 has two different USB solutions. A DesignWare DWC2 IP-Core
> in the APM82181-SoC ("usb1") which is wired to the SD-Card reader and needs
> to be ignored (as it's always connected). And a dedicated Renesas uPD720202
> usb 3.0 chip which powers both physical USB 3.0 ports (port1 and port2).
> The uPD720202 has two root hubs. In case of the WNDR4700 these are enumerated
> as "usb2" (for USB 1.x/2.0 devices) and "usb3" (soley for USB 3.0+ devices).
> Hence in order to fully detect any usb 1.x/2.0 or usb 3.0 device being
> plugged in to any of the two ports, the usbport trigger needs to check both
> ports on the "usb2" and "usb3" root hubs.
Thank you! Pushed.
--
Rafał
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH V2] apm821xx: fix USB LED trigger for WNDR4700
On Friday, October 28, 2016 12:40:01 PM CEST Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> The old usbdev trigger never supported assigning more than 1 USB port.
> This code we got was never working as expected and it was missing 2 more
> ports. Switch to usbport to have LED working with all ports.
>
Tested-by: Christian Lamparter
> Signed-off-by: Rafał Miłecki
Thanks!
here's a explanation what's going on with the multiple port and usb definitions:
The WNDR4700 has two different USB solutions. A DesignWare DWC2 IP-Core
in the APM82181-SoC ("usb1") which is wired to the SD-Card reader and needs
to be ignored (as it's always connected). And a dedicated Renesas uPD720202
usb 3.0 chip which powers both physical USB 3.0 ports (port1 and port2).
The uPD720202 has two root hubs. In case of the WNDR4700 these are enumerated
as "usb2" (for USB 1.x/2.0 devices) and "usb3" (soley for USB 3.0+ devices).
Hence in order to fully detect any usb 1.x/2.0 or usb 3.0 device being
plugged in to any of the two ports, the usbport trigger needs to check both
ports on the "usb2" and "usb3" root hubs.
> V2: Add 2 extra ports that were missing
> ---
> target/linux/apm821xx/base-files/etc/board.d/01_leds | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds
> b/target/linux/apm821xx/base-files/etc/board.d/01_leds
> index a1eeb8f..80a22b8 100755
> --- a/target/linux/apm821xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds
> @@ -23,8 +23,7 @@ mbl)
> wndr4700)
> ucidef_set_led_ide "sata" "SATA" "wndr4700:green:hd"
> ucidef_set_led_netdev "wan" "WAN (green)" "wndr4700:green:wan" "eth0.2"
> - ucidef_set_led_usbdev "usb3-1" "USB3-1" "wndr4700:blue:usb" "2-1"
> - ucidef_set_led_usbdev "usb3-2" "USB3-2" "wndr4700:blue:usb" "3-1"
> + ucidef_set_led_usbport "usb3" "USB3" "wndr4700:blue:usb" "usb2-port1"
> "usb2-port2" "usb3-port1" "usb3-port2"
> ucidef_set_led_wlan "wlan2g" "WLAN2G" "wndr4700:blue:wlan" "phy0tpt"
> ucidef_set_led_wlan "wlan5g" "WLAN5G" "wndr4700:blue:wlan" "phy1tpt"
> ;;
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH V2] apm821xx: fix USB LED trigger for WNDR4700
From: Rafał Miłecki The old usbdev trigger never supported assigning more than 1 USB port. This code we got was never working as expected and it was missing 2 more ports. Switch to usbport to have LED working with all ports. Signed-off-by: Rafał Miłecki --- V2: Add 2 extra ports that were missing --- target/linux/apm821xx/base-files/etc/board.d/01_leds | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds b/target/linux/apm821xx/base-files/etc/board.d/01_leds index a1eeb8f..80a22b8 100755 --- a/target/linux/apm821xx/base-files/etc/board.d/01_leds +++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds @@ -23,8 +23,7 @@ mbl) wndr4700) ucidef_set_led_ide "sata" "SATA" "wndr4700:green:hd" ucidef_set_led_netdev "wan" "WAN (green)" "wndr4700:green:wan" "eth0.2" - ucidef_set_led_usbdev "usb3-1" "USB3-1" "wndr4700:blue:usb" "2-1" - ucidef_set_led_usbdev "usb3-2" "USB3-2" "wndr4700:blue:usb" "3-1" + ucidef_set_led_usbport "usb3" "USB3" "wndr4700:blue:usb" "usb2-port1" "usb2-port2" "usb3-port1" "usb3-port2" ucidef_set_led_wlan "wlan2g" "WLAN2G" "wndr4700:blue:wlan" "phy0tpt" ucidef_set_led_wlan "wlan5g" "WLAN5G" "wndr4700:blue:wlan" "phy1tpt" ;; -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700
On 22 October 2016 at 18:10, Christian Lamparter wrote: > On Saturday, October 22, 2016 11:22:35 AM CEST Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> The old usbdev trigger never supported assigning more than 1 USB port. >> This code we got was never working as expected. Switch to usbport to >> have LED working with both ports. >> >> Signed-off-by: Rafał Miłecki > > I was testing this on the wndr4700. > > # cat /etc/config/system > config led 'led_usb3' > option name 'USB3' > option sysfs 'wndr4700:blue:usb' > option trigger 'usbport' > list port 'usb2-port1' > list port 'usb3-port1' > --- > > However the LED only lights up if a device (in my case two > usb-sticks one 3.0 and one 2.0) is connected on port > usb3-port1. No LED activity for usb2-port1 at first. > > The next step was to look into the port triggers > # ls -al /sys/class/leds/wndr4700\:blue\:usb/ports/ > usb1-port1 usb2-port1 usb2-port2 usb3-port1 usb3-port2 > > # cat /sys/class/leds/wndr4700\:blue\:usb/ports/* > 0 > 1 > 0 > 1 > 0 > --- > The triggers are set for usb2-port1 and usb3-port1 but not for any of > the port2. I had to enable the usb2-port2 and usb3-port2 to get it > working. Is there a way to specify sth like "usb2-port[2-Adresslimit]" > and the same for usb3-port? Thanks for the research, I incorrectly assumed info in 01_leds is correct and complete. There isn't a way to specify range of ports. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Arcadyan vrv9510kwac23
anyone can help? its already working. Just need guidance about best place to put the configuration for it and register the callback... Thanks On Tue, Oct 25, 2016 at 9:13 PM, Juan Rios wrote: > Hello again, > I have been working on adding support for this router with the > help of SCApi and we got it to the point that Ethernet ports works, > leds and buttons works and wifi card 0xa8d6 43222 works. > > The wifi card don't have sprom and I had to write a patch to add > fallback sprom support for this card. > > The sprom is not located in flash or at least I could not find it. I > used the logs from original firmware and information from broadcom > architecture to make it and put the interesting values and it works. > > To supply sprom buffer I need the mac address of the interface. I want > to use the Ethernet mac address + 2. The Ethernet mac address is > stored in mtd at certain offset. > > Where should be the registration of the sprom fallback function?. > Right now I did it in the b43_pci_ssb_bridge_init function from the > drivers/ssb/pci_b43_bridge.c file. > > Also It is needed a way to specify the mtd partition where the mac > address is stored, the offset and the increment needed to the mac > address. Where and how should this be put? > > Right now there is only three lantiq routers with broadcom wifi card > that I know of and may be in the same situation. > > Regards > Juan Rios ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 3/6 v2] x86: Add sp5100_tco as a kernel module
On Sun, Oct 23, 2016 at 7:19 AM, Felix Fietkau wrote: > On 2016-10-22 19:39, Chris Blake wrote: >> This patch enables the kernel sp5100_tco watchdog driver to be built as >> a kernel module. >> >> Signed-off-by: Chris Blake >> --- >> target/linux/x86/modules.mk | 15 +++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk >> index 1fc5ce5..f6a87ee 100644 >> --- a/target/linux/x86/modules.mk >> +++ b/target/linux/x86/modules.mk >> @@ -19,3 +19,18 @@ define KernelPackage/gpio-nct5104d/description >> endef >> >> $(eval $(call KernelPackage,gpio-nct5104d)) >> + >> +define KernelPackage/sp5100_tco >> + SUBMENU:=$(OTHER_MENU) >> + TITLE:=SP5100 Watchdog Support >> + DEPENDS:=@TARGET_x86 >> + KCONFIG:=CONFIG_SP5100_TCO >> + FILES:=$(LINUX_DIR)/drivers/watchdog/sp5100_tco.ko >> + AUTOLOAD:=$(call AutoLoad,50,sp5100_tco,1) >> +endef >> + >> +define KernelPackage/sp5100_tco/description >> + Kernel module for the SP5100_TCO hardware watchdog. >> +endef > Please enable this in the x86/64 kernel config instead of packaging it. > > - Felix > Felix, If possible, can sp5100_tco be kept as a kmod? The justifiable reason is that if a user wants to use the I2c interface on the board, this driver needs to be unloaded as it can't be used along side the i2c interface. Keeping this a kmod will allow users to do this without needing to modify the build. More info is at https://github.com/riptidewave93/LEDE-APU2/issues/9 and https://github.com/riptidewave93/LEDE-APU2/pull/5#issuecomment-255667736 Regards, Chris Blake ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/1] package/utils: Add beep package
John, Sounds good. My only question is around the current RFC for the PC Engines APU2 which has this application defined in the profile for the board. Would that be enough justification to allow this into the LEDE branch, or would it be OK to keep "beep" defined in the profile and just merge this into the packages feed? Regards, Chris Blake On Thu, Oct 27, 2016 at 5:08 AM, John Crispin wrote: > Hi, > > after some time considering i am against merging this into trunk. there > are no direct users and no hardware that wont function without. please > submit the package as a PR to the packages feed. > > John > > On 19/10/2016 16:59, Chris Blake wrote: >> This adds the "beep" binary as a package to LEDE. Note that busybox does >> have a beep option that can be built in, but it is disabled by default >> on all LEDE targets. This package gives users the option to manually >> install beep at a later time, or include it as a default for a device >> profile. >> >> This was based on the older PR at https://lists.openwrt.org/pipermail >> /openwrt-devel/2009-November/005226.html >> >> Signed-off-by: Chris Blake >> --- >> package/utils/beep/Makefile | 50 >> + >> 1 file changed, 50 insertions(+) >> create mode 100644 package/utils/beep/Makefile >> >> diff --git a/package/utils/beep/Makefile b/package/utils/beep/Makefile >> new file mode 100644 >> index 000..b9bb4d80 >> --- /dev/null >> +++ b/package/utils/beep/Makefile >> @@ -0,0 +1,50 @@ >> +# >> +# Copyright (C) 2016 OpenWrt.org >> +# >> +# This is free software, licensed under the GNU General Public License v2. >> +# See /LICENSE for more information. >> +# >> + >> +include $(TOPDIR)/rules.mk >> + >> +PKG_NAME:=beep >> +PKG_REV:=0d790fa45777896749a885c3b93b2c1476d59f20 >> +PKG_VERSION:=1.3 >> +PKG_RELEASE:=1 >> + >> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz >> +PKG_SOURCE_URL:=https://github.com/johnath/beep.git >> +PKG_SOURCE_PROTO:=git >> +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) >> +PKG_SOURCE_VERSION:=$(PKG_REV) >> + >> +PKG_LICENSE:=GPL >> +PKG_LICENSE_FILES:= >> + >> +include $(INCLUDE_DIR)/package.mk >> + >> +define Package/beep >> + SECTION:=sound >> + CATEGORY:=Sound >> + DEPENDS:=+kmod-pcspkr >> + TITLE:=Play beep sounds through a PC speaker >> + URL:=http://johnath.com/beep/README >> +endef >> + >> +define Package/beep/description >> + This program plays beeps through the PC speaker >> +endef >> + >> +CONFIGURE_ARGS += \ >> + --enable-static \ >> + --enable-shared >> + >> +MAKE_FLAGS += \ >> + CFLAGS="$(TARGET_CFLAGS)" >> + >> +define Package/beep/install >> + $(INSTALL_DIR) $(1)/usr/bin >> + $(INSTALL_BIN) $(PKG_BUILD_DIR)/beep $(1)/usr/bin >> +endef >> + >> +$(eval $(call BuildPackage,beep)) >> -- >> 2.7.4 >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev >> ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
