Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On 06/22/2015 02:51 AM, Ian Kent wrote: > On Sun, 2015-06-21 at 19:19 +0200, Rafał Miłecki wrote: >> On 10 March 2015 at 04:30, Ian Kent wrote: >>> The Netgear R8000 has a PEX8603 connected to the BCM53012 and if >>> it isn't configured during the bus scan the PCI layer goes crazy >>> trying to configure phantom devices. >> >> This is kind of magic for me. >> Hauke: are you able to review this? > > Yeah, it's a bridge so it needs upstream and downstream bus ids set but > the main issue is that it doesn't respond with appropriate return values > for non-existent devices. > > I modelled the code on the corresponding source from the Broadcom SDK > file that this source was originally developed from (at least it > appeared to match). > > I confirmed that PEX860X devices don't return proper return code from > another PEX driver, from the WRT1900 source I think, its been a while > now. > > Ian Hi, I completely missed these patches, thanks for pointing me to them again. I will try to review them in the net days. I already saw this code in the vendor driver but did not add it because my devices did not use it. We will change to a different PCIe driver with the next kernel in OpenWrt, because Broadcom added a kernel for this PCIe core into the mainline kernel. We should get it into this new driver. Then also some people from Broadcom can review this. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On 22 June 2015 at 10:10, Hauke Mehrtens wrote: > On 06/22/2015 02:51 AM, Ian Kent wrote: >> On Sun, 2015-06-21 at 19:19 +0200, Rafał Miłecki wrote: >>> On 10 March 2015 at 04:30, Ian Kent wrote: The Netgear R8000 has a PEX8603 connected to the BCM53012 and if it isn't configured during the bus scan the PCI layer goes crazy trying to configure phantom devices. >>> >>> This is kind of magic for me. >>> Hauke: are you able to review this? >> >> Yeah, it's a bridge so it needs upstream and downstream bus ids set but >> the main issue is that it doesn't respond with appropriate return values >> for non-existent devices. >> >> I modelled the code on the corresponding source from the Broadcom SDK >> file that this source was originally developed from (at least it >> appeared to match). >> >> I confirmed that PEX860X devices don't return proper return code from >> another PEX driver, from the WRT1900 source I think, its been a while >> now. >> >> Ian > > Hi, > > I completely missed these patches, thanks for pointing me to them again. > I will try to review them in the net days. I already saw this code in > the vendor driver but did not add it because my devices did not use it. > We will change to a different PCIe driver with the next kernel in > OpenWrt, because Broadcom added a kernel for this PCIe core into the > mainline kernel. We should get it into this new driver. Then also some > people from Broadcom can review this. This would be nice to patch the old driver in CC branch. To get R8000 supported by CC. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] linux-3.18: prevent redefinition of struct ethhdr
Alejandro Mery wrote: > when using musl packages include netinet/ether.h break because > struct ethhdr gets redefined. > > this patch comes includes a patch originally from sabotage linux > and it has been submitted upstream https://lkml.org/lkml/2014/3/14/266 > If this gets merged, could we then drop the large and growing pile of musl ether.h patches in each of the packages? Is this going to get _merged_ upstream, or was it just posted to LKML? I didn't see any discussion of it there. Cheers, Karl P___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Fix WAN port location on EnGenius ESR1750 and EPG5000.
The designated blue WAN port has index 5, not 1, on both devices. Christian Beier (1): ar71xx: Fix WAN port location on EnGenius ESR1750 and EPG5000. target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Fix WAN port location on EnGenius ESR1750 and EPG5000.
The designated blue WAN port on both devices has index 5, not 1. Signed-off-by: Christian Beier --- target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index 2fab4c2..fe4733a 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -34,8 +34,8 @@ esr1750 |\ epg5000) ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" ucidef_add_switch "switch0" "1" "1" - ucidef_add_switch_vlan "switch0" "1" "0t 2 3 4 5" - ucidef_add_switch_vlan "switch0" "2" "0t 1" + ucidef_add_switch_vlan "switch0" "1" "0t 1 2 3 4" + ucidef_add_switch_vlan "switch0" "2" "0t 5" ;; ap136-010) -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] musl breaks python
Hi,
I have discovered that python is broken using musl. When a thread
created
using the threading library exists, python segfaults.
This is a simple example application showing the issue:
import time
import threading
def test():
print("Hello")
time.sleep(2)
print("world")
t = threading.Thread(target=test)
t.start()
After printing "world" python segfaults.
root@OpenWrt:~# python test.py
Hello
world
Segmentation fault
This has only been tested/verified by me on the ar71xx platform using
AR9331. Built using r46106.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] musl breaks python
Thanks for reporting this.
Will move this to the Github issues, since it belongs there.
https://github.com/openwrt/packages/issues/1450
Thanks
On Mon, Jun 22, 2015 at 1:37 PM, wrote:
> Hi,
>
> I have discovered that python is broken using musl. When a thread created
> using the threading library exists, python segfaults.
>
> This is a simple example application showing the issue:
>
> import time
> import threading
>
> def test():
> print("Hello")
> time.sleep(2)
> print("world")
>
> t = threading.Thread(target=test)
> t.start()
>
> After printing "world" python segfaults.
>
> root@OpenWrt:~# python test.py
> Hello
> world
> Segmentation fault
>
> This has only been tested/verified by me on the ar71xx platform using
> AR9331. Built using r46106.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: add LED defaults for the EnGenius EPG5000
NB that wlan5g is phy0tpt and wlan2g phy1tpt. Signed-off-by: Christian Beier --- target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 5 + 1 file changed, 5 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 19814f4..7c10f42 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -165,6 +165,11 @@ esr1750) ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "esr1750:blue:wlan-5g" "phy1tpt" ;; +epg5000) + ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "epg5000:blue:wlan-2g" "phy1tpt" + ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "epg5000:blue:wlan-5g" "phy0tpt" + ;; + hiwifi-hc6361) ucidef_set_led_netdev "inet" "INET" "hiwifi:blue:internet" "eth1" ucidef_set_led_wlan "wlan" "WLAN" "hiwifi:blue:wlan-2p4" "phy0tpt" -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [brcm47xx] Belkin F7DXXXX (BCM47XX based) support for Linux 3.18
From: Joseph East
Patchset based on previous work by Cody Schafer and Luc Forcier to allow
TRX images with Belkin IDs to be compiled as part of the BRCM47XX platform
for Linux 3.18.
The patchset has been tested with a Belkin F7D4401 (PlayMax N600), other
devices part of the previous patch are untested but have been included,
however the Belkin QA TRX signature has been removed.
The otrx tool has been modified to accept a -m argument which allows
comparison against a user defined TRX signature, this works in tandem with
the changes in platform.sh to verify the different Belkin TRXs for
supported models.
Signed-off-by: Joseph East
---
package/system/mtd/src/trx.c | 28 --
package/utils/otrx/src/otrx.c | 31 +++-
.../brcm47xx/base-files/lib/upgrade/platform.sh| 39
target/linux/brcm47xx/image/Makefile | 19 ++
.../brcm47xx/image/lzma-loader/src/decompress.c| 25 -
...nclude-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch | 43
++
6 files changed, 177 insertions(+), 8 deletions(-)
create mode 100644
target/linux/brcm47xx/patches-3.18/032-11-MIPS-BCM47XX-Include-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch
diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c
index 245ee76..8e4980c 100644
--- a/package/system/mtd/src/trx.c
+++ b/package/system/mtd/src/trx.c
@@ -35,7 +35,12 @@
#include "mtd.h"
#include "crc32.h"
-#define TRX_MAGIC 0x30524448 /* "HDR0" */
+#define TRX_MAGIC 0x30524448 /* "HDR0" */
+#define BELKIN_F7D3301_MAGIC0x20100322
+#define BELKIN_F7D3302_MAGIC0x20090928
+#define BELKIN_F7D4302_MAGIC0x20101006
+#define BELKIN_F7D4401_MAGIC0x00018517
+
struct trx_header {
uint32_t magic; /* "HDR0" */
uint32_t len; /* Length of file including header */
@@ -55,6 +60,21 @@ struct trx_header {
ssize_t pread(int fd, void *buf, size_t count, off_t offset);
ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset);
+static bool is_trx_magic(uint32_t magic)
+{
+magic = STORE32_LE(magic);
+switch (magic) {
+case TRX_MAGIC:
+case BELKIN_F7D3301_MAGIC:
+case BELKIN_F7D3302_MAGIC:
+case BELKIN_F7D4302_MAGIC:
+case BELKIN_F7D4401_MAGIC:
+return true;
+default:
+return false;
+}
+}
+
int
trx_fixup(int fd, const char *name)
{
@@ -83,7 +103,7 @@ trx_fixup(int fd, const char *name)
}
trx = ptr;
- if (trx->magic != TRX_MAGIC) {
+ if (!is_trx_magic(trx->magic)) {
fprintf(stderr, "TRX header not found\n");
goto err;
}
@@ -118,7 +138,7 @@ trx_check(int imagefd, const char *mtd, char *buf, int
*len)
return 0;
}
- if (trx->magic != TRX_MAGIC || trx->len < sizeof(struct trx_header)) {
+ if (!is_trx_magic(trx->magic) || trx->len < sizeof(struct trx_header)) {
if (quiet < 2) {
fprintf(stderr, "Bad trx header\n");
fprintf(stderr, "This is not the correct file format; refusing to
flash.\n"
@@ -184,7 +204,7 @@ mtd_fixtrx(const char *mtd, size_t offset)
}
trx = (struct trx_header *) (buf + offset);
- if (trx->magic != STORE32_LE(0x30524448)) {
+ if (!is_trx_magic(trx->magic)) {
fprintf(stderr, "No trx magic found\n");
exit(1);
}
diff --git a/package/utils/otrx/src/otrx.c b/package/utils/otrx/src/otrx.c
index 101a310..36ebe62 100644
--- a/package/utils/otrx/src/otrx.c
+++ b/package/utils/otrx/src/otrx.c
@@ -47,6 +47,8 @@ struct trx_header {
char *trx_path;
size_t trx_offset = 0;
+uint8_t use_trx_override = 0;
+uint32_t trx_override = 0;
char *partition[TRX_MAX_PARTS] = {};
static inline size_t otrx_min(size_t x, size_t y) {
@@ -143,11 +145,35 @@ uint32_t otrx_crc32(uint8_t *buf, size_t len) {
static void otrx_check_parse_options(int argc, char **argv) {
int c;
- while ((c = getopt(argc, argv, "o:")) != -1) {
+ while ((c = getopt(argc, argv, "m:o:")) != -1) {
switch (c) {
case 'o':
trx_offset = atoi(optarg);
break;
+ case 'm':
+ trx_override = strtol(optarg, NULL, 16);
+ use_trx_override = 1;
+ break;
+ }
+ }
+}
+
+static int is_trx_magic(uint32_t magic) {
+magic = cpu_to_le32(magic);
+ if(use_trx_override) {
+ if(magic == trx_override) {
+ return 1;
+ }
+ else {
+ return 0;
+ }
+ }
+ else {
+ if(magic == TRX_MAGIC) {
+ return 1;
+ }
+ else {
+ return 0;
}
}
}
@@ -186,7 +212,7 @@ static int otrx_check(int argc, char **argv) {
goto err_close;
}
- if (le32_to_cpu(hdr.magic) != TRX_MAGIC) {
+ if (!is_trx_magic(le32_to_cpu(hdr.magic))) {
fprintf(stderr, "Invalid TRX magic: 0x%08x\n", le32_to_cpu(hdr.magic));
err = -EINVAL;
goto err_close;
@@ -548,6 +574,7 @@ static void usage() {
printf("Checking TRX file:\n");
printf("\totrx check [options]\tcheck if file is a valid TRX\n");
printf("\t-o offset\t\t\toffset of TRX data in file (default: 0)\n");
+ printf("\t-m signature\t\t\tCompa
Re: [OpenWrt-Devel] [PATCH] [brcm47xx] Belkin F7DXXXX (BCM47XX based) support for Linux 3.18
Patch didn't seem to mail properly, trying again.
From: Joseph East
Patchset based on previous work by Cody Schafer and Luc Forcier to allow
TRX images with Belkin IDs to be compiled as part of the BRCM47XX
platform for Linux 3.18.
The patchset has been tested with a Belkin F7D4401 (PlayMax N600), other
devices part of the previous patch are untested but have been included,
however the Belkin QA TRX signature has been removed.
The otrx tool has been modified to accept a -m argument which allows
comparison against a user defined TRX signature, this works in tandem
with the changes in platform.sh to verify the different Belkin TRXs for
supported models.
Signed-off-by: Joseph East
---
package/system/mtd/src/trx.c | 28 --
package/utils/otrx/src/otrx.c | 31 +++-
.../brcm47xx/base-files/lib/upgrade/platform.sh| 39
target/linux/brcm47xx/image/Makefile | 19 ++
.../brcm47xx/image/lzma-loader/src/decompress.c| 25 -
...nclude-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch | 43
++
6 files changed, 177 insertions(+), 8 deletions(-)
create mode 100644
target/linux/brcm47xx/patches-3.18/032-11-MIPS-BCM47XX-Include-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch
diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c
index 245ee76..8e4980c 100644
--- a/package/system/mtd/src/trx.c
+++ b/package/system/mtd/src/trx.c
@@ -35,7 +35,12 @@
#include "mtd.h"
#include "crc32.h"
-#define TRX_MAGIC 0x30524448 /* "HDR0" */
+#define TRX_MAGIC 0x30524448 /* "HDR0" */
+#define BELKIN_F7D3301_MAGIC0x20100322
+#define BELKIN_F7D3302_MAGIC0x20090928
+#define BELKIN_F7D4302_MAGIC0x20101006
+#define BELKIN_F7D4401_MAGIC0x00018517
+
struct trx_header {
uint32_t magic;/* "HDR0" */
uint32_t len;/* Length of file including header */
@@ -55,6 +60,21 @@ struct trx_header {
ssize_t pread(int fd, void *buf, size_t count, off_t offset);
ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset);
+static bool is_trx_magic(uint32_t magic)
+{
+magic = STORE32_LE(magic);
+switch (magic) {
+case TRX_MAGIC:
+case BELKIN_F7D3301_MAGIC:
+case BELKIN_F7D3302_MAGIC:
+case BELKIN_F7D4302_MAGIC:
+case BELKIN_F7D4401_MAGIC:
+return true;
+default:
+return false;
+}
+}
+
int
trx_fixup(int fd, const char *name)
{
@@ -83,7 +103,7 @@ trx_fixup(int fd, const char *name)
}
trx = ptr;
-if (trx->magic != TRX_MAGIC) {
+if (!is_trx_magic(trx->magic)) {
fprintf(stderr, "TRX header not found\n");
goto err;
}
@@ -118,7 +138,7 @@ trx_check(int imagefd, const char *mtd, char *buf,
int *len)
return 0;
}
-if (trx->magic != TRX_MAGIC || trx->len < sizeof(struct trx_header)) {
+if (!is_trx_magic(trx->magic) || trx->len < sizeof(struct
trx_header)) {
if (quiet < 2) {
fprintf(stderr, "Bad trx header\n");
fprintf(stderr, "This is not the correct file format;
refusing to flash.\n"
@@ -184,7 +204,7 @@ mtd_fixtrx(const char *mtd, size_t offset)
}
trx = (struct trx_header *) (buf + offset);
-if (trx->magic != STORE32_LE(0x30524448)) {
+if (!is_trx_magic(trx->magic)) {
fprintf(stderr, "No trx magic found\n");
exit(1);
}
diff --git a/package/utils/otrx/src/otrx.c b/package/utils/otrx/src/otrx.c
index 101a310..36ebe62 100644
--- a/package/utils/otrx/src/otrx.c
+++ b/package/utils/otrx/src/otrx.c
@@ -47,6 +47,8 @@ struct trx_header {
char *trx_path;
size_t trx_offset = 0;
+uint8_t use_trx_override = 0;
+uint32_t trx_override = 0;
char *partition[TRX_MAX_PARTS] = {};
static inline size_t otrx_min(size_t x, size_t y) {
@@ -143,11 +145,35 @@ uint32_t otrx_crc32(uint8_t *buf, size_t len) {
static void otrx_check_parse_options(int argc, char **argv) {
int c;
-while ((c = getopt(argc, argv, "o:")) != -1) {
+while ((c = getopt(argc, argv, "m:o:")) != -1) {
switch (c) {
case 'o':
trx_offset = atoi(optarg);
break;
+case 'm':
+trx_override = strtol(optarg, NULL, 16);
+use_trx_override = 1;
+break;
+}
+}
+}
+
+static int is_trx_magic(uint32_t magic) {
+magic = cpu_to_le32(magic);
+if(use_trx_override) {
+if(magic == trx_override) {
+return 1;
+}
+else {
+return 0;
+}
+}
+else {
+if(magic == TRX_MAGIC) {
+return 1;
+}
+else {
+return 0;
}
}
}
@@ -186,7 +212,7 @@ static int otrx_check(int argc, char **argv) {
goto err_close;
}
-if (le32_to_cpu(hdr.magic) != TRX_MAGIC) {
+if (!is_trx_magic(le32_to_cpu(hdr.magic))) {
fpr
Re: [OpenWrt-Devel] [PATCH] [brcm47xx] Belkin F7DXXXX (BCM47XX based) support for Linux 3.18
On 06/22/2015 02:25 PM, Joseph East wrote:
> Patch didn't seem to mail properly, trying again.
>
> From: Joseph East
>
> Patchset based on previous work by Cody Schafer and Luc Forcier to allow
> TRX images with Belkin IDs to be compiled as part of the BRCM47XX
> platform for Linux 3.18.
>
> The patchset has been tested with a Belkin F7D4401 (PlayMax N600), other
> devices part of the previous patch are untested but have been included,
> however the Belkin QA TRX signature has been removed.
>
> The otrx tool has been modified to accept a -m argument which allows
> comparison against a user defined TRX signature, this works in tandem
> with the changes in platform.sh to verify the different Belkin TRXs for
> supported models.
>
> Signed-off-by: Joseph East
> ---
> package/system/mtd/src/trx.c | 28 --
> package/utils/otrx/src/otrx.c | 31 +++-
> .../brcm47xx/base-files/lib/upgrade/platform.sh| 39
>
> target/linux/brcm47xx/image/Makefile | 19 ++
> .../brcm47xx/image/lzma-loader/src/decompress.c| 25 -
> ...nclude-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch | 43
> ++
> 6 files changed, 177 insertions(+), 8 deletions(-)
> create mode 100644
> target/linux/brcm47xx/patches-3.18/032-11-MIPS-BCM47XX-Include-Belkin-F7D4XXX-F7D3XXX-TRX-for-mtd.patch
>
>
> diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c
> index 245ee76..8e4980c 100644
> --- a/package/system/mtd/src/trx.c
> +++ b/package/system/mtd/src/trx.c
> @@ -35,7 +35,12 @@
> #include "mtd.h"
> #include "crc32.h"
>
> -#define TRX_MAGIC 0x30524448 /* "HDR0" */
> +#define TRX_MAGIC 0x30524448 /* "HDR0" */
> +#define BELKIN_F7D3301_MAGIC0x20100322
> +#define BELKIN_F7D3302_MAGIC0x20090928
> +#define BELKIN_F7D4302_MAGIC0x20101006
> +#define BELKIN_F7D4401_MAGIC0x00018517
> +
> struct trx_header {
> uint32_t magic;/* "HDR0" */
> uint32_t len;/* Length of file including header */
> @@ -55,6 +60,21 @@ struct trx_header {
> ssize_t pread(int fd, void *buf, size_t count, off_t offset);
> ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset);
>
> +static bool is_trx_magic(uint32_t magic)
> +{
> +magic = STORE32_LE(magic);
> +switch (magic) {
> +case TRX_MAGIC:
> +case BELKIN_F7D3301_MAGIC:
> +case BELKIN_F7D3302_MAGIC:
> +case BELKIN_F7D4302_MAGIC:
> +case BELKIN_F7D4401_MAGIC:
> +return true;
> +default:
> +return false;
> +}
> +}
> +
> int
> trx_fixup(int fd, const char *name)
> {
> @@ -83,7 +103,7 @@ trx_fixup(int fd, const char *name)
> }
>
> trx = ptr;
> -if (trx->magic != TRX_MAGIC) {
> +if (!is_trx_magic(trx->magic)) {
> fprintf(stderr, "TRX header not found\n");
> goto err;
> }
> @@ -118,7 +138,7 @@ trx_check(int imagefd, const char *mtd, char *buf,
> int *len)
> return 0;
> }
>
> -if (trx->magic != TRX_MAGIC || trx->len < sizeof(struct trx_header)) {
> +if (!is_trx_magic(trx->magic) || trx->len < sizeof(struct
> trx_header)) {
This is probably an unwanted line break.
Please use "git format-patch" to create the patch and "git send-email"
to send them. these two tools make sure it does not get corrupted.
> if (quiet < 2) {
> fprintf(stderr, "Bad trx header\n");
> fprintf(stderr, "This is not the correct file format;
> refusing to flash.\n"
> @@ -184,7 +204,7 @@ mtd_fixtrx(const char *mtd, size_t offset)
> }
>
> trx = (struct trx_header *) (buf + offset);
> -if (trx->magic != STORE32_LE(0x30524448)) {
> +if (!is_trx_magic(trx->magic)) {
> fprintf(stderr, "No trx magic found\n");
> exit(1);
> }
> diff --git a/package/utils/otrx/src/otrx.c b/package/utils/otrx/src/otrx.c
> index 101a310..36ebe62 100644
> --- a/package/utils/otrx/src/otrx.c
> +++ b/package/utils/otrx/src/otrx.c
> @@ -47,6 +47,8 @@ struct trx_header {
>
> char *trx_path;
> size_t trx_offset = 0;
> +uint8_t use_trx_override = 0;
> +uint32_t trx_override = 0;
> char *partition[TRX_MAX_PARTS] = {};
>
> static inline size_t otrx_min(size_t x, size_t y) {
> @@ -143,11 +145,35 @@ uint32_t otrx_crc32(uint8_t *buf, size_t len) {
> static void otrx_check_parse_options(int argc, char **argv) {
> int c;
>
> -while ((c = getopt(argc, argv, "o:")) != -1) {
> +while ((c = getopt(argc, argv, "m:o:")) != -1) {
> switch (c) {
> case 'o':
> trx_offset = atoi(optarg);
> break;
> +case 'm':
> +trx_override = strtol(optarg, NULL, 16);
> +use_trx_override = 1;
> +break;
> +}
> +}
> +}
> +
> +static int is_trx_magic(uint32_t magic) {
> +magic = cpu_to_le32(magic);
> +if(use_trx_override) {
> +if(magic == trx_ov
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On 03/10/2015 04:30 AM, Ian Kent wrote:
> The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
> it isn't configured during the bus scan the PCI layer goes crazy
> trying to configure phantom devices.
Could you provide some diagram how this is connected?
My current assumption is that on one of the 3 PCIe ports is this switch,
so the scan will find this switch as a PCIe device, bu how does it go
from there?
>From the vendor driver I would assume that that the two devices behind
the switch are device function 0x08 and 0x10 on the switch device.
Can you also post the output of lspci on your device?
>
> Signed-off-by: Ian Kent
> ---
> .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
>
> .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
>
> 2 files changed, 450 insertions(+)
> create mode 100644
> target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> create mode 100644
> target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
>
..
> diff --git
> a/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
>
> b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> new file mode 100644
> index 000..fc606b4
> --- /dev/null
> +++
> b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> @@ -0,0 +1,225 @@
> +bcm53xx: R8000 handle PEX8603 switch
> +
> +The Netgear R8000 has a PEX8603 which, if not configured at
> +bus probe results in quite a few phantom devices as it doesn't
> +respond properly to configuration requests. The device needs
> +to be configured when seen.
> +
> +Signed-off-by: Ian Kent
> +
> +--- a/drivers/pci/host/pci-host-bcm5301x.c
> b/drivers/pci/host/pci-host-bcm5301x.c
> +@@ -29,6 +29,21 @@
> + #define PCI_TARGET_LINK_SPEED_GEN20x2
> + #define PCI_TARGET_LINK_SPEED_GEN10x1
> +
> ++#define PCI_MAX_BUS 4
> ++#define PLX_PRIM_SEC_BUS_NUM(0x0201 | (PCI_MAX_BUS <<
> 16))
> ++
> ++#ifndef SZ_48M
> ++#define SZ_48M (SZ_32M + SZ_16M)
> ++#endif
Please remove the ifndef, it should fail if this gets added.
> ++
> ++struct pex86xx_info {
> ++u8 busno; /* Upstream bus PEX is on */
> ++u8 slot;/* Upstream slot PEX is at */
> ++u16 active; /* Active port count */
> ++u16 ports; /* Active port bit map */
> ++};
> ++struct pex86xx_info pex8603;
> ++
> + static int bcma_pcie2_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
> + {
> + struct pci_sys_data *sys = pdev->sysdata;
> +@@ -115,6 +130,39 @@ static int bcma_pcie2_read_config_pci(st
> + struct pci_sys_data *sys = bus->sysdata;
> + struct bcma_device *bdev = sys->private_data;
> +
> ++/* The PEX8603 won't return sensible values to the PCI layer so
> ++ * we have to do that ourselves.
> ++ */
> ++if (pex8603.busno) {
> ++u16 slot = PCI_SLOT(devfn);
> ++
> ++/* Not the PEX upstream slot */
> ++if (pex8603.busno == bus->number && pex8603.slot != slot)
> ++goto done;
> ++
> ++/* Not the PEX downstream bus? */
> ++if (bus->number < pex8603.busno ||
> ++bus->number > pex8603.busno + 1)
> ++goto done;
> ++
> ++switch (bus->number - pex8603.busno) {
> ++case 0:
> ++/* Upstream port */
> ++break;
> ++
> ++case 1:
> ++/* PEX8603, not present for slots other than 1 or 2 */
> ++if (!(slot == 1 || slot == 2)) {
> ++*val = 0x;
> ++return PCIBIOS_SUCCESSFUL;
> ++}
> ++break;
> ++
> ++default:
> ++break;
> ++}
> ++}
> ++done:
> + *val = bcma_pcie2_read_config(bdev, bus->number, devfn, where, size);
> +
> + return PCIBIOS_SUCCESSFUL;
> +@@ -126,6 +174,37 @@ static int bcma_pcie2_write_config_pci(s
> + struct pci_sys_data *sys = bus->sysdata;
> + struct bcma_device *bdev = sys->private_data;
> +
> ++/* Don't try and set anything on the PEX8603 if it isn't
> ++ * valid.
> ++ */
> ++if (pex8603.busno) {
> ++u16 slot = PCI_SLOT(devfn);
> ++
> ++/* Not the PEX upstream slot */
> ++if (pex8603.busno == bus->number && pex8603.slot != slot)
> ++goto done;
> ++
> ++/* Not the PEX downstream bus? */
> ++if (bus->number < pex8603.busno ||
> ++bus->number > pex8603.busno + 1)
> ++goto done;
> ++
> ++switch (bus->number - pex8603.busno) {
> ++case 0:
> ++/* Upstream port */
> ++break;
> ++
> ++case 1:
> ++
[OpenWrt-Devel] [PATCH 0/2] mac80211: Update QCA9880 firmware (ath10k)
Current firmware version for QCA9880 is known to stall for some time when a station in power saving mode (e.g. mobile phone) leaves the AP range. This stall causes ath10k timeouts during station removal and subsequently firmware thinks station is still connected, causing "Spurios quick kickout for STA" -messages in kernel log. A fix is to use a newer firmware where this problem has been worked around by sending management frames via normal packet transport channel instead of the problematic management interface. These patches backport the new FW API v5 to ath10k (upstream commits 8348db2, 53513c3, and dc3632a) and change mac80211 to use the new firmware. Fixes https://dev.openwrt.org/ticket/18794 (even though it is already marked as fixed). Matti Laakso (2): mac80211: Backport ath10k firmware API v5 support mac80211: Update QCA9880 firmware to 10.2.4.70-2 package/kernel/mac80211/Makefile | 6 +- ...31-ath10k_add_ath10k_fw_ie_htt_op_version.patch | 385 + .../patches/932-ath10k_bump_up_fw_api_to_5.patch | 43 +++ ...tt_op_backwards_compatibility_for_qca6174.patch | 47 +++ 4 files changed, 478 insertions(+), 3 deletions(-) create mode 100644 package/kernel/mac80211/patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch create mode 100644 package/kernel/mac80211/patches/932-ath10k_bump_up_fw_api_to_5.patch create mode 100644 package/kernel/mac80211/patches/933-ath10k_fix_htt_op_backwards_compatibility_for_qca6174.patch -- 2.1.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mac80211: Backport ath10k firmware API v5 support
These patches add support for the new version 5 firmware API.
Signed-off-by: Matti Laakso
---
...31-ath10k_add_ath10k_fw_ie_htt_op_version.patch | 385 +
.../patches/932-ath10k_bump_up_fw_api_to_5.patch | 43 +++
...tt_op_backwards_compatibility_for_qca6174.patch | 47 +++
3 files changed, 475 insertions(+)
create mode 100644
package/kernel/mac80211/patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch
create mode 100644
package/kernel/mac80211/patches/932-ath10k_bump_up_fw_api_to_5.patch
create mode 100644
package/kernel/mac80211/patches/933-ath10k_fix_htt_op_backwards_compatibility_for_qca6174.patch
diff --git
a/package/kernel/mac80211/patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch
b/package/kernel/mac80211/patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch
new file mode 100644
index 000..45384ed
--- /dev/null
+++
b/package/kernel/mac80211/patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch
@@ -0,0 +1,385 @@
+diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
+index 02da72e..f3788e2 100644
+--- a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
+@@ -675,6 +675,17 @@ static int ath10k_core_fetch_firmware_api_n(struct ath10k
*ar, const char *name)
+ ath10k_dbg(ar, ATH10K_DBG_BOOT, "found fw ie wmi op
version %d\n",
+ ar->wmi.op_version);
+ break;
++ case ATH10K_FW_IE_HTT_OP_VERSION:
++ if (ie_len != sizeof(u32))
++ break;
++
++ version = (__le32 *)data;
++
++ ar->htt.op_version = le32_to_cpup(version);
++
++ ath10k_dbg(ar, ATH10K_DBG_BOOT, "found fw ie htt op
version %d\n",
++ ar->htt.op_version);
++ break;
+ default:
+ ath10k_warn(ar, "Unknown FW IE: %u\n",
+ le32_to_cpu(hdr->id));
+diff --git a/drivers/net/wireless/ath/ath10k/htt.c
b/drivers/net/wireless/ath/ath10k/htt.c
+index 4f59ab9..f782d76 100644
+--- a/drivers/net/wireless/ath/ath10k/htt.c
b/drivers/net/wireless/ath/ath10k/htt.c
+@@ -22,6 +22,86 @@
+ #include "core.h"
+ #include "debug.h"
+
++static const enum htt_t2h_msg_type htt_main_t2h_msg_types[] = {
++ [HTT_MAIN_T2H_MSG_TYPE_VERSION_CONF] = HTT_T2H_MSG_TYPE_VERSION_CONF,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_IND] = HTT_T2H_MSG_TYPE_RX_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_FLUSH] = HTT_T2H_MSG_TYPE_RX_FLUSH,
++ [HTT_MAIN_T2H_MSG_TYPE_PEER_MAP] = HTT_T2H_MSG_TYPE_PEER_MAP,
++ [HTT_MAIN_T2H_MSG_TYPE_PEER_UNMAP] = HTT_T2H_MSG_TYPE_PEER_UNMAP,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_ADDBA] = HTT_T2H_MSG_TYPE_RX_ADDBA,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_DELBA] = HTT_T2H_MSG_TYPE_RX_DELBA,
++ [HTT_MAIN_T2H_MSG_TYPE_TX_COMPL_IND] = HTT_T2H_MSG_TYPE_TX_COMPL_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_PKTLOG] = HTT_T2H_MSG_TYPE_PKTLOG,
++ [HTT_MAIN_T2H_MSG_TYPE_STATS_CONF] = HTT_T2H_MSG_TYPE_STATS_CONF,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_FRAG_IND] = HTT_T2H_MSG_TYPE_RX_FRAG_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_SEC_IND] = HTT_T2H_MSG_TYPE_SEC_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_TX_INSPECT_IND] =
++ HTT_T2H_MSG_TYPE_TX_INSPECT_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_MGMT_TX_COMPL_IND] =
++ HTT_T2H_MSG_TYPE_MGMT_TX_COMPLETION,
++ [HTT_MAIN_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND] =
++ HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_PN_IND] = HTT_T2H_MSG_TYPE_RX_PN_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_RX_OFFLOAD_DELIVER_IND] =
++ HTT_T2H_MSG_TYPE_RX_OFFLOAD_DELIVER_IND,
++ [HTT_MAIN_T2H_MSG_TYPE_TEST] = HTT_T2H_MSG_TYPE_TEST,
++};
++
++static const enum htt_t2h_msg_type htt_10x_t2h_msg_types[] = {
++ [HTT_10X_T2H_MSG_TYPE_VERSION_CONF] = HTT_T2H_MSG_TYPE_VERSION_CONF,
++ [HTT_10X_T2H_MSG_TYPE_RX_IND] = HTT_T2H_MSG_TYPE_RX_IND,
++ [HTT_10X_T2H_MSG_TYPE_RX_FLUSH] = HTT_T2H_MSG_TYPE_RX_FLUSH,
++ [HTT_10X_T2H_MSG_TYPE_PEER_MAP] = HTT_T2H_MSG_TYPE_PEER_MAP,
++ [HTT_10X_T2H_MSG_TYPE_PEER_UNMAP] = HTT_T2H_MSG_TYPE_PEER_UNMAP,
++ [HTT_10X_T2H_MSG_TYPE_RX_ADDBA] = HTT_T2H_MSG_TYPE_RX_ADDBA,
++ [HTT_10X_T2H_MSG_TYPE_RX_DELBA] = HTT_T2H_MSG_TYPE_RX_DELBA,
++ [HTT_10X_T2H_MSG_TYPE_TX_COMPL_IND] = HTT_T2H_MSG_TYPE_TX_COMPL_IND,
++ [HTT_10X_T2H_MSG_TYPE_PKTLOG] = HTT_T2H_MSG_TYPE_PKTLOG,
++ [HTT_10X_T2H_MSG_TYPE_STATS_CONF] = HTT_T2H_MSG_TYPE_STATS_CONF,
++ [HTT_10X_T2H_MSG_TYPE_RX_FRAG_IND] = HTT_T2H_MSG_TYPE_RX_FRAG_IND,
++ [HTT_10X_T2H_MSG_TYPE_SEC_IND] = HTT_T2H_MSG_TYPE_SEC_IND,
++ [HTT_10X_T2H_MSG_TYPE_RC_UPDATE_IND] = HTT_T2H_MSG_TYPE_RC_UPDATE_IND,
++ [HTT_10X_T2H_MSG_TYPE_TX_INSPECT_IND] = HTT_T2H_MSG_TYPE_TX_INSPECT_IND,
++ [HTT_10X_T2H_MSG_TYPE_TEST] = HTT_T2H_MSG_TYPE_TEST,
++
[OpenWrt-Devel] [PATCH 2/2] mac80211: Update QCA9880 firmware to 10.2.4.70-2
This firmware adds support for management frames over normal packet transport interface instead of over the WMI management interface. Signed-off-by: Matti Laakso --- package/kernel/mac80211/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index 2af5d39..0872a9c 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -128,7 +128,7 @@ endef $(eval $(call Download,linux-firmware)) PKG_ATH10K_LINUX_FIRMWARE_NAME:=ath10k-firmware -PKG_ATH10K_LINUX_FIRMWARE_VERSION:=da0f85d924226ee30c46e037120621c9e192b39e +PKG_ATH10K_LINUX_FIRMWARE_VERSION:=b46f3e01a6c1f9150fb4612ef53611d714565842 PKG_ATH10K_LINUX_FIRMWARE_SOURCE:=$(PKG_ATH10K_LINUX_FIRMWARE_NAME)-$(PKG_ATH10K_LINUX_FIRMWARE_VERSION).tar.bz2 PKG_ATH10K_LINUX_FIRMWARE_PROTO:=git PKG_ATH10K_LINUX_FIRMWARE_SOURCE_URL:=https://github.com/kvalo/ath10k-firmware.git @@ -1864,8 +1864,8 @@ ifeq ($(CONFIG_ATH10K_STA_FW),y) $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-2.bin else $(INSTALL_DATA) \ - $(PKG_BUILD_DIR)/$(PKG_ATH10K_LINUX_FIRMWARE_SUBDIR)/10.2.4/firmware-4.bin_10.2.4.45 \ - $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-4.bin + $(PKG_BUILD_DIR)/$(PKG_ATH10K_LINUX_FIRMWARE_SUBDIR)/10.2.4/untested/firmware-5.bin_10.2.4.70-2 \ + $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin endif endef -- 2.1.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Issue when creating rootfs images with parallel jobs
Hi, when I try to create a rootfs for my Duckbill device, I used to run "make -j4 ...". The default configuration enables CONFIG_TARGET_ROOTFS_INCLUDE_KERNEL because the bootloader expects the kernel image in the rootfs below /boot. However, my problem is, that when running make with -j2 or more, then the ext4 rootfs image does not contain the /boot directory and thus the kernel/dt binaries. But this is not limited to ext4 images, the tar.gz variant of the rootfs suffers from the same problem. But everthing works as expected, when using "make -j1..." Then all images include the /boot directory. So I guess, this is a problem with the parallel jobs. Is there any chance to get this fixed? Regards, mhei ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] linux-3.18: prevent redefinition of struct ethhdr
Hi, On 22/06/15 11:32, Karl Palsson wrote: Alejandro Mery wrote: when using musl packages include netinet/ether.h break because struct ethhdr gets redefined. this patch comes includes a patch originally from sabotage linux and it has been submitted upstream https://lkml.org/lkml/2014/3/14/266 If this gets merged, could we then drop the large and growing pile of musl ether.h patches in each of the packages? Is this going to get _merged_ upstream, or was it just posted to LKML? I didn't see any discussion of it there. not sure if *all* related patches can be removed because some packages do very nasty stuff, but this at least fixes those not doing define/include witchcraft. also, here I'm only patching 3.18 and will 4.0 need similar love. this patch is happily used by openembedded and sabotage linux, but it might take a while upstream decides to take it into consideration... it's not that they enjoy becoming part of libc wars. but they did at least replace the #ifdef __GLIBC__ with a #ifndef __KERNEL__ in libc-compat.h, and that's something :) cheers, Alejandro Mery ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] linux-3.18: prevent redefinition of struct ethhdr
On 22/06/15 21:08, Alejandro Mery wrote: Hi, On 22/06/15 11:32, Karl Palsson wrote: Alejandro Mery wrote: when using musl packages include netinet/ether.h break because struct ethhdr gets redefined. this patch comes includes a patch originally from sabotage linux and it has been submitted upstream https://lkml.org/lkml/2014/3/14/266 If this gets merged, could we then drop the large and growing pile of musl ether.h patches in each of the packages? Is this going to get _merged_ upstream, or was it just posted to LKML? I didn't see any discussion of it there. not sure if *all* related patches can be removed because some packages do very nasty stuff, but this at least fixes those not doing define/include witchcraft. also, here I'm only patching 3.18 and will 4.0 need similar love. this patch is happily used by openembedded and sabotage linux, but it might take a while upstream decides to take it into consideration... it's not that they enjoy becoming part of libc wars. but they did at least replace the #ifdef __GLIBC__ with a #ifndef __KERNEL__ in libc-compat.h, and that's something :) An example of weakness of this patch is etherwake which breaks because it includes the kernel headers before libc's. so I suppose it's hard (impossible?) to find an almighty patch that fixes every case. From d25df0f20a5fd690a502a169c56a4cc0458bb6b1 Mon Sep 17 00:00:00 2001 From: Alejandro Mery Date: Mon, 22 Jun 2015 23:44:27 +0200 Subject: [PATCH] etherwake: prevent the redefinition of struct ethhdr by including the libc headers first Signed-off-by: Alejandro Mery --- net/etherwake/patches/200-netinit-if_ether_h.patch | 24 ++ 1 file changed, 24 insertions(+) create mode 100644 net/etherwake/patches/200-netinit-if_ether_h.patch diff --git a/net/etherwake/patches/200-netinit-if_ether_h.patch b/net/etherwake/patches/200-netinit-if_ether_h.patch new file mode 100644 index 000..a29ea27 --- /dev/null +++ b/net/etherwake/patches/200-netinit-if_ether_h.patch @@ -0,0 +1,24 @@ +avoid redefinition of struct struct ethhdr by including +the libc headers first. + +--- ./ether-wake.c.orig2015-06-22 23:39:23.271788072 +0200 ./ether-wake.c 2015-06-22 23:39:52.771788072 +0200 +@@ -82,6 +82,9 @@ + #include + + #include ++#include ++#include ++ + #if __GLIBC__ >= 2 && __GLIBC_MINOR >= 1 + #include + #include +@@ -90,8 +93,6 @@ + #include + #include + #endif +-#include +-#include + + /* Grrr, no consistency between include versions. +Enable this if setsockopt() isn't declared with your library. */ -- 2.4.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
Hi! Come to the Battlemesh event in Slovenia this year, almost as close to Hungary as you can get. :-) https://wlan-si.net/en/blog/2015/03/29/announcing-battlemesh-v8-in-maribor-slovenia/ Mitar On Thu, Mar 26, 2015 at 4:02 AM, bkil wrote: > If anyone wants to organize a BattleMesh event in Hungary, I would > vote for that and have a near industrial amount of various compatible > hardware standing by! > > On Wed, Mar 25, 2015 at 9:36 PM, Gergely Kiss wrote: >> On 03/21/2015 08:51 PM, valent.turko...@gmail.com wrote: >>> On 10 March 2015 at 21:26, Gergely Kiss wrote: Hi Valent, first of all, I strongly disagree with people claiming that OpenWrt sucks because it doesn't. For me it rather looks like a well-maintained, rapidly improving project with a great number of actively supported hardware and quite a few people contributing to >>> >>> >>> Do you think OpenWrt sucks? Then stop complaining and do something to make it better. It's that simple. Cheers, Gergely >>> >>> Hi Gergely, >>> thanks for your reply and for your contribution to OpenWrt. But I have >>> to ask - have you read my message apart from headline? If you have >>> read it you will see that I'm defending OpenWrt and I definitely don't >>> think it sucks! >> >> Hi Valent, >> >> I'm sorry, that paragraph wasn't addressed to you but to "people claiming >> that OpenWrt sucks". >> >> Of course, I have read your message, I never reply to a message I haven't >> read in its entirety. >> >>> >>> I contribute to it everyday, but not (yet) as a developer but as >>> advanced user, forum and wiki contributor and have organized multiple >>> workshops all accross Croatia, Serbia and Macedonia to get people to >>> use OpenWrt. >>> >> >> That's great! Any plans to come to Hungary someday? :) >> >>> Cheers, >>> Valent. >>> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Controlling POE passthrough via GPIO
Hi, within our wireless community we are using a couple of devices with the following features: * powered via POE through their first ethernet plug * another device can be powered via the second ethernet plug (POE passthrough switchable via GPIO) The POE passthrough feature can be controlled via GPIO pins. For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO pins #2, #8 or #20 (depending on the model). Currently we are using a custom script (see attached) for these models. I have the feeling that this kind of hardware capabilities should be available within openwrt (similar to the LED setup). Is there anything related already implemented within openwrt? If not: where would you recommend to put it? Cheers, Lars poe-passthrough.sh Description: application/shellscript ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Mon, 2015-06-22 at 18:42 +0200, Hauke Mehrtens wrote:
>
> On 03/10/2015 04:30 AM, Ian Kent wrote:
> > The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
> > it isn't configured during the bus scan the PCI layer goes crazy
> > trying to configure phantom devices.
>
> Could you provide some diagram how this is connected?
I could try, when I get a chance, ascii art isn't my strong suit.
>
> My current assumption is that on one of the 3 PCIe ports is this switch,
> so the scan will find this switch as a PCIe device, bu how does it go
> from there?
I can only infer from looking at sysfs, which is what I have done.
Perhaps I'm not correct but it looks to me that there are is a BCM53012
connected with two legs, one has one wireless device, and the other has
a PEX8603 bridge which has two legs, each with a wireless device.
> From the vendor driver I would assume that that the two devices behind
> the switch are device function 0x08 and 0x10 on the switch device.
I'll have to reacquaint myself with the code before I respond to the
comments below, its been a while.
>
> Can you also post the output of lspci on your device?
Don't think I have lspci in the build I was using, I'll need to add it
and rebuild. That probably won't be until the weekend.
>
> >
> > Signed-off-by: Ian Kent
> > ---
> > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> >
> > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> >
> > 2 files changed, 450 insertions(+)
> > create mode 100644
> > target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > create mode 100644
> > target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> >
>
>
> ..
>
>
> > diff --git
> > a/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> >
> > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > new file mode 100644
> > index 000..fc606b4
> > --- /dev/null
> > +++
> > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > @@ -0,0 +1,225 @@
> > +bcm53xx: R8000 handle PEX8603 switch
> > +
> > +The Netgear R8000 has a PEX8603 which, if not configured at
> > +bus probe results in quite a few phantom devices as it doesn't
> > +respond properly to configuration requests. The device needs
> > +to be configured when seen.
> > +
> > +Signed-off-by: Ian Kent
> > +
> > +--- a/drivers/pci/host/pci-host-bcm5301x.c
> > b/drivers/pci/host/pci-host-bcm5301x.c
> > +@@ -29,6 +29,21 @@
> > + #define PCI_TARGET_LINK_SPEED_GEN20x2
> > + #define PCI_TARGET_LINK_SPEED_GEN10x1
> > +
> > ++#define PCI_MAX_BUS 4
> > ++#define PLX_PRIM_SEC_BUS_NUM (0x0201 | (PCI_MAX_BUS <<
> > 16))
> > ++
> > ++#ifndef SZ_48M
> > ++#define SZ_48M(SZ_32M + SZ_16M)
> > ++#endif
>
> Please remove the ifndef, it should fail if this gets added.
>
>
> > ++
> > ++struct pex86xx_info {
> > ++ u8 busno; /* Upstream bus PEX is on */
> > ++ u8 slot;/* Upstream slot PEX is at */
> > ++ u16 active; /* Active port count */
> > ++ u16 ports; /* Active port bit map */
> > ++};
> > ++struct pex86xx_info pex8603;
> > ++
> > + static int bcma_pcie2_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
> > + {
> > + struct pci_sys_data *sys = pdev->sysdata;
> > +@@ -115,6 +130,39 @@ static int bcma_pcie2_read_config_pci(st
> > + struct pci_sys_data *sys = bus->sysdata;
> > + struct bcma_device *bdev = sys->private_data;
> > +
> > ++ /* The PEX8603 won't return sensible values to the PCI layer so
> > ++ * we have to do that ourselves.
> > ++ */
> > ++ if (pex8603.busno) {
> > ++ u16 slot = PCI_SLOT(devfn);
> > ++
> > ++ /* Not the PEX upstream slot */
> > ++ if (pex8603.busno == bus->number && pex8603.slot != slot)
> > ++ goto done;
> > ++
> > ++ /* Not the PEX downstream bus? */
> > ++ if (bus->number < pex8603.busno ||
> > ++ bus->number > pex8603.busno + 1)
> > ++ goto done;
> > ++
> > ++ switch (bus->number - pex8603.busno) {
> > ++ case 0:
> > ++ /* Upstream port */
> > ++ break;
> > ++
> > ++ case 1:
> > ++ /* PEX8603, not present for slots other than 1 or 2 */
> > ++ if (!(slot == 1 || slot == 2)) {
> > ++ *val = 0x;
> > ++ return PCIBIOS_SUCCESSFUL;
> > ++ }
> > ++ break;
> > ++
> > ++ default:
> > ++ break;
> > ++ }
> > ++ }
> > ++done:
> > + *val = bcma_pcie2_read_config(bdev, bus->number, devfn, where, size);
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +@@ -126,6 +174,37 @@ static int bcma_pcie2_write_config_pci(s
> > + struct pci_sys_data *sy
Re: [OpenWrt-Devel] Controlling POE passthrough via GPIO
On 22/06/15 16:48, Lars Kruse wrote: > Hi, > > within our wireless community we are using a couple of devices with the > following features: > * powered via POE through their first ethernet plug > * another device can be powered via the second ethernet plug (POE passthrough > switchable via GPIO) > > The POE passthrough feature can be controlled via GPIO pins. > For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO > pins #2, #8 or #20 (depending on the model). > > Currently we are using a custom script (see attached) for these models. > > I have the feeling that this kind of hardware capabilities should be available > within openwrt (similar to the LED setup). > > Is there anything related already implemented within openwrt? > If not: where would you recommend to put it? You could eventually utilize the regulator framework to implement such GPIO toggling to provide/remove power to a given device. I have not looked at whether this is something controllable from user-space, but there is an in-kernel API to be a "consumer" of the regulator API. Of course this information should be made conditional to the device model. My 2 cents. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Controlling POE passthrough via GPIO
On 23/06/2015 01:48, Lars Kruse wrote: > Hi, > > within our wireless community we are using a couple of devices with the > following features: > * powered via POE through their first ethernet plug > * another device can be powered via the second ethernet plug (POE passthrough > switchable via GPIO) > > The POE passthrough feature can be controlled via GPIO pins. > For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO > pins #2, #8 or #20 (depending on the model). > > Currently we are using a custom script (see attached) for these models. > > I have the feeling that this kind of hardware capabilities should be available > within openwrt (similar to the LED setup). > > Is there anything related already implemented within openwrt? > If not: where would you recommend to put it? > add some generic uci-sefault functions to add poe sections to uci. then create a /etc/init.d/poe script that will set the gpios based on what is written in uci. finally call the new uci-defaults functions from /etc/uci-default/$my_arch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
