[OpenWrt-Devel] [PATCH] mac80211: Update to version 4.19.7-1
This updates the backports package used in mac80211 to version 4.19.7-1 which is based on kernel 4.19.7. This integrates all the stable fixes introduces in this kernel version. The deleted patches are not needed any more because they are either included in the upstream Linux kernel 4.19.7 or in backports 4.19.7-1. Signed-off-by: Hauke Mehrtens --- package/kernel/mac80211/Makefile | 6 +- .../patches/ath/080-ath10k_thermal_config.patch| 2 +- .../patches/ath/402-ath_regd_optional.patch| 2 +- .../patches/ath/404-regd_no_assoc_hints.patch | 4 +- .../patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch | 2 +- ...dling-of-peer_bw_rxnss_override-parameter.patch | 2 +- ...-controlling-support-for-various-chipsets.patch | 14 +-- .../brcm/100-brcmfmac-fix-roamoff-1-modparam.patch | 15 +-- ...ix-for-proper-support-of-160MHz-bandwidth.patch | 117 - ...move-recursion-from-firmware-load-error-h.patch | 17 +-- .../patches/build/005-revert-devcoredump.patch | 8 -- .../patches/build/060-no_local_ssb_bcma.patch | 4 +- .../rt2x00/602-rt2x00-introduce-rt2x00eeprom.patch | 2 +- .../patches/subsys/140-tweak-TSQ-setting.patch | 2 +- ...x-setting-IEEE80211_KEY_FLAG_RX_MGMT-for-.patch | 25 - ...-free-skb-fraglist-before-freeing-the-skb.patch | 2 +- ...-mac80211-add-hdrlen-to-ieee80211_tx_data.patch | 10 +- ...8-mac80211-add-NEED_ALIGNED4_SKBS-hw-flag.patch | 18 ++-- ...x-memory-accounting-with-A-MSDU-aggregati.patch | 6 +- ...nore-tx-status-for-PS-stations-in-ieee802.patch | 2 +- ...x-reordering-of-buffered-broadcast-packet.patch | 2 +- ...locate-TXQs-for-active-monitor-interfaces.patch | 26 - 22 files changed, 52 insertions(+), 236 deletions(-) delete mode 100644 package/kernel/mac80211/patches/brcm/304-v4.20-0001-brcmfmac-fix-for-proper-support-of-160MHz-bandwidth.patch delete mode 100644 package/kernel/mac80211/patches/build/005-revert-devcoredump.patch delete mode 100644 package/kernel/mac80211/patches/subsys/350-mac80211-fix-setting-IEEE80211_KEY_FLAG_RX_MGMT-for-.patch delete mode 100644 package/kernel/mac80211/patches/subsys/394-mac80211-allocate-TXQs-for-active-monitor-interfaces.patch diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index c322202b4a..5f79e54edf 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=mac80211 -PKG_VERSION:=4.19-rc5-1 +PKG_VERSION:=4.19.7-1 PKG_RELEASE:=1 -PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19-rc5/ -PKG_HASH:=5b61e64ea79d22bbac9e8612d5d5485974f223de00d4ec250b0faf4b7baf9957 +PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19.7/ +PKG_HASH:=86650a02f36b0d39059be343d4bad3be14adece699723713a69c94cc64d456ef PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION) diff --git a/package/kernel/mac80211/patches/ath/080-ath10k_thermal_config.patch b/package/kernel/mac80211/patches/ath/080-ath10k_thermal_config.patch index a04abb2d28..a86cbc6e54 100644 --- a/package/kernel/mac80211/patches/ath/080-ath10k_thermal_config.patch +++ b/package/kernel/mac80211/patches/ath/080-ath10k_thermal_config.patch @@ -37,7 +37,7 @@ void ath10k_thermal_event_temperature(struct ath10k *ar, int temperature); --- a/local-symbols +++ b/local-symbols -@@ -140,6 +140,7 @@ ATH10K_SNOC= +@@ -139,6 +139,7 @@ ATH10K_SNOC= ATH10K_DEBUG= ATH10K_DEBUGFS= ATH10K_SPECTRAL= diff --git a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch b/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch index 26fcd56144..03c12df1a8 100644 --- a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch +++ b/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch @@ -82,7 +82,7 @@ ---help--- --- a/local-symbols +++ b/local-symbols -@@ -84,6 +84,7 @@ ADM8211= +@@ -83,6 +83,7 @@ ADM8211= ATH_COMMON= WLAN_VENDOR_ATH= ATH_DEBUG= diff --git a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch index 6e4794a764..ec95206acb 100644 --- a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch +++ b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch @@ -1,6 +1,6 @@ --- a/net/wireless/reg.c +++ b/net/wireless/reg.c -@@ -2980,6 +2980,8 @@ void regulatory_hint_country_ie(struct w +@@ -2982,6 +2982,8 @@ void regulatory_hint_country_ie(struct w enum environment_cap env = ENVIRON_ANY; struct regulatory_request *request = NULL, *lr; @@ -9,7 +9,7 @@ /* IE len must be evenly divisible by 2 */ if (country_ie_len & 0x01) return; -@@ -3186,6 +3188,7 @@ static void restore_regulatory_settings( +@@ -3188,6 +3190,7 @@ static void restore_regulatory_settings( void
Re: [OpenWrt-Devel] [PATCH fstools] blockd: don't reparse blob msg in the vlist callbacks
On 07/12/2018 14:13, Rafał Miłecki wrote:
From: Rafał Miłecki
ubus message is parsed in the block_hotplug() which fills all the struct
device fields. Once that is done there is no need to parse original
message again - it's enough to get required data from the struct.
This also fixes handling messages with "autofs" set to 0. They were
incorrectly interpreted due to the missing blobmsg_get_u32().
Signed-off-by: Rafał Miłecki
nice catch !
Acked-by: John Crispin
---
blockd.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/blockd.c b/blockd.c
index 1379635..29d16f2 100644
--- a/blockd.c
+++ b/blockd.c
@@ -111,29 +111,19 @@ block(char *cmd, char *action, char *device)
static void
device_free(struct device *device)
{
- struct blob_attr *data[__MOUNT_MAX];
-
- blobmsg_parse(mount_policy, __MOUNT_MAX, data,
- blob_data(device->msg), blob_len(device->msg));
-
- if (data[MOUNT_AUTOFS] && device->target)
+ if (device->autofs && device->target)
unlink(device->target);
}
static void
device_add(struct device *device)
{
- struct blob_attr *data[__MOUNT_MAX];
char path[64];
- blobmsg_parse(mount_policy, __MOUNT_MAX, data,
- blob_data(device->msg), blob_len(device->msg));
-
- if (!data[MOUNT_AUTOFS])
+ if (!device->autofs)
return;
- snprintf(path, sizeof(path), "/tmp/run/blockd/%s",
-blobmsg_get_string(data[MOUNT_DEVICE]));
+ snprintf(path, sizeof(path), "/tmp/run/blockd/%s", device->name);
if (symlink(path, device->target))
ULOG_ERR("failed to symlink %s->%s\n", device->target, path);
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents
On 07/12/2018 11:11, Hattink, Tjalling wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Friday, December 7, 2018 10:51 To: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents Hi, I had a brief discussion with John on this matter and was being told that the reason for this filter was to optimize boot time. When we remove the /dev filter, boot time will increase considerably on lower end devices due to the resulting hotplug-call overhead of the huge volume of additional uevents. A better approach here would be to selectively whitelist uevents based on subsystem or similar attributes, e.g. `DEVTYPE=usb_device`. ~ Jo I can imagine that this would increase boot times on low end devices. Looking at the commit message introducing the filter it seems to cut down the amount of events by half. How about adding a compile option to procd that enables/disables this filter. So by default this filter is enabled, but using a makemenu option in the procd configuration (similar as "Mount /tmp using zram" option) you would be able to disable the filter for high-end boards that require it. This would be fairly easy to implement. Best regards, Tjaling Hattink Hi, I actually have a rather strong opinion on this one and would prefer to hardcode uevents that we want to opt-in as Jo suggested. compile time options do look nice, but we have a trizillion of them already and they per default are not enabled in binary releases making them virtually useless to anyone that was not involved in adding them to the tree. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx Vs ath79
Hi, so many mails in this thread. does anyone feel destined to summarize this in an impartial manner ? my superficial understanding is that some/few people do have understandable doubts but alot of people understand that the trade-off is quite high and it does only effect >5% of devices ?!? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools] block: validate amount of arguments for the "autofs" command
nitpickering ...
On 07/12/2018 17:26, Rafał Miłecki wrote:
From: Rafał Miłecki
Using argv[3] without checking argc value could result in undefined
behavior. It could result in a crash or accessing a NULL that separates
argv from envp on UNIX.
Signed-off-by: Rafał Miłecki
---
block.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 8972fdf..1edc9b8 100644
--- a/block.c
+++ b/block.c
@@ -1189,8 +1189,12 @@ static int main_autofs(int argc, char **argv)
blockd_notify(pr->dev, m, pr);
}
return 0;
+ } else {
+ if (argc < 4)
+ return -EINVAL;
+
+ return mount_action(argv[2], argv[3], TYPE_AUTOFS);
we can reduce one indentation here
else if (argc < 4)
return -EINVAL;
return mount_action(argv[2], argv[3], TYPE_AUTOFS);
or not ?!
regardless ...
Acked-by: John Crispin
}
- return mount_action(argv[2], argv[3], TYPE_AUTOFS);
}
static int find_block_mtd(char *name, char *part, int plen)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH fstools] block: validate amount of arguments for the "autofs" command
From: Rafał Miłecki
Using argv[3] without checking argc value could result in undefined
behavior. It could result in a crash or accessing a NULL that separates
argv from envp on UNIX.
Signed-off-by: Rafał Miłecki
---
block.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 8972fdf..1edc9b8 100644
--- a/block.c
+++ b/block.c
@@ -1189,8 +1189,12 @@ static int main_autofs(int argc, char **argv)
blockd_notify(pr->dev, m, pr);
}
return 0;
+ } else {
+ if (argc < 4)
+ return -EINVAL;
+
+ return mount_action(argv[2], argv[3], TYPE_AUTOFS);
}
- return mount_action(argv[2], argv[3], TYPE_AUTOFS);
}
static int find_block_mtd(char *name, char *part, int plen)
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH fstools] blockd: don't reparse blob msg in the vlist callbacks
From: Rafał Miłecki
ubus message is parsed in the block_hotplug() which fills all the struct
device fields. Once that is done there is no need to parse original
message again - it's enough to get required data from the struct.
This also fixes handling messages with "autofs" set to 0. They were
incorrectly interpreted due to the missing blobmsg_get_u32().
Signed-off-by: Rafał Miłecki
---
blockd.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/blockd.c b/blockd.c
index 1379635..29d16f2 100644
--- a/blockd.c
+++ b/blockd.c
@@ -111,29 +111,19 @@ block(char *cmd, char *action, char *device)
static void
device_free(struct device *device)
{
- struct blob_attr *data[__MOUNT_MAX];
-
- blobmsg_parse(mount_policy, __MOUNT_MAX, data,
- blob_data(device->msg), blob_len(device->msg));
-
- if (data[MOUNT_AUTOFS] && device->target)
+ if (device->autofs && device->target)
unlink(device->target);
}
static void
device_add(struct device *device)
{
- struct blob_attr *data[__MOUNT_MAX];
char path[64];
- blobmsg_parse(mount_policy, __MOUNT_MAX, data,
- blob_data(device->msg), blob_len(device->msg));
-
- if (!data[MOUNT_AUTOFS])
+ if (!device->autofs)
return;
- snprintf(path, sizeof(path), "/tmp/run/blockd/%s",
-blobmsg_get_string(data[MOUNT_DEVICE]));
+ snprintf(path, sizeof(path), "/tmp/run/blockd/%s", device->name);
if (symlink(path, device->target))
ULOG_ERR("failed to symlink %s->%s\n", device->target, path);
}
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
Henrique de Moraes Holschuh wrote: > Em 05/12/2018 21:20, Thomas Endt escreveu: > >> Auftrag von Henrique de Moraes Holschuh > >> Do we have a wiki table somewhere that has the device name, ar71xx info > >> and ath79 info, which could be expanded with ar71xx->ath79 status (no, > >> yes but unverified, yes verified to be complete)? > >> > >> That would be really useful to direct efforts on adding ath79 support > >> to something that is still ar71xx-only, as well as adding ar71xx->ath79 > >> support to targets of interest (i.e. those one happens to know what > >> changes are required for the migration, really). > >> > >> I suppose one would also add any remarks about ath79 support being > >> incomplete or any regressions for each target one knows about, too. > >> That would help steering the ar71xx deprecation. > > > > There is a table that documents the ath79 status in the OpenWrt forum: > > https://forum.openwrt.org/t/ath79-target-status/18614/9 > > > > The place to put this into the wiki would be: > > https://openwrt.org/docs/techref/targets/ath79 > > > > > > We can define a new target "ar71xx-ath79" for the dataentries, which would > > then give us these 3 options: > > > > 1) "ar71xx" # device is ar71xx only > > 2) "ath79" # device is ath79 only > > 3) "ar71xx-ath79"# device is migrated (and working, if nothing in > > "Unsupported Functions") > > > > ---> devices will automatically show up on the ath79 and/or ar71xx wikipage > > (slight modifications necessary). > > > > For "ath79 WIP" devices, we can set the "Unsupported Functions" datafield > > (that's where WIP usually is found) to "ath79 WIP, see forum". > > Any detailed discussion or description of incomplete support should happen > > elsewhere, i.e. either in the forum or on the respective devicepages. > > > > Please let me know if this meets your requirements. > > Yes, this would do it nicely, provided that we take care to > describe in the web pages what ar71xx-ath79 means. > > Note that my answer assumes "migrated" (i.e. ar71xx-ath79) > means the glue to migrate and convert low-level config (LEDs, > etc) when updating from ar71xx -> ath79 is in place on the > ath79 port. > > If it just does ar71xx _and_ ath79, BUT one has to manually > adjust configuration when migrating from ar71xx to ath79, it > would have to be flagged as WIP or something like that, even if > all of its functions are fully implemented and working in > ath79. One thing we want to avoid meanwhile is keeping the old stuff "just because" The whole point of moving to ath79 is to be closer to upstream. If we just go and repatch everythign to make it compatible with the past, we might as well not have bothered. We want to make sure that any migrations are migrations to new stuff _only_ not adapting things to stay in the same place. Cheers, Karl P signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 fstools] block: generate hotplug.d mount events
From: Rafał Miłecki
With this change block generates 2 "mount" hotplug.d subsystem events:
1) "add" when block device gets mounted
2) "remove" when block device gets unmounted
This allows e.g. controlling USB storage dependant software using
hotplug.d listeners.
A very similar solution was implemented in mountd which was replaced by
blockd.
Right now this is implemented using a call to the /sbin/hotplug-call.
A possible improvement is to rewrite above shell script into a C lib
function. For now let's just assume that script exists.
Signed-off-by: Rafał Miłecki
---
V2: Use hotplug_call() helper. It requires
[PATCH libubox] hotplug: add hotplug_call() helper
V3: Switch back to the local hotplug-call call as it doesn't really fit
the library.
Use setenv() which simplifies the code.
Improve error handling.
---
block.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/block.c b/block.c
index 46050b4..8972fdf 100644
--- a/block.c
+++ b/block.c
@@ -880,6 +880,35 @@ static int exec_mount(const char *source, const char
*target,
return err;
}
+static int hotplug_call_mount(const char *action, const char *device)
+{
+ pid_t pid;
+ int err;
+
+ pid = fork();
+ if (!pid) {
+ char * const argv[] = { "hotplug-call", "mount", NULL };
+
+ setenv("ACTION", action, 1);
+ setenv("DEVICE", device, 1);
+
+ execv("/sbin/hotplug-call", argv);
+ exit(-1);
+ } else if (pid > 0) {
+ int status;
+
+ pid = waitpid(pid, , 0);
+ if (pid <= 0 || !WIFEXITED(status) || WEXITSTATUS(status)) {
+ err = -ENOEXEC;
+ ULOG_ERR("hotplug-call call failed\n");
+ }
+ } else {
+ err = -errno;
+ }
+
+ return err;
+}
+
static int handle_mount(const char *source, const char *target,
const char *fstype, struct mount *m)
{
@@ -1079,6 +1108,8 @@ static int mount_device(struct probe_info *pr, int type)
handle_swapfiles(true);
+ hotplug_call_mount("add", device);
+
return 0;
}
@@ -1091,6 +1122,8 @@ static int umount_device(char *path)
if (!mp)
return -1;
+ hotplug_call_mount("remove", basename(path));
+
err = umount2(mp, MNT_DETACH);
if (err)
ULOG_ERR("unmounting %s (%s) failed (%d) - %m\n", path, mp,
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Jo-Philipp Wich > Sent: Friday, December 7, 2018 10:51 > To: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents > > Hi, > > I had a brief discussion with John on this matter and was being told that the > reason for this filter was to optimize boot time. > > When we remove the /dev filter, boot time will increase considerably on > lower end devices due to the resulting hotplug-call overhead of the huge > volume of additional uevents. > > A better approach here would be to selectively whitelist uevents based on > subsystem or similar attributes, e.g. `DEVTYPE=usb_device`. > > ~ Jo I can imagine that this would increase boot times on low end devices. Looking at the commit message introducing the filter it seems to cut down the amount of events by half. How about adding a compile option to procd that enables/disables this filter. So by default this filter is enabled, but using a makemenu option in the procd configuration (similar as "Mount /tmp using zram" option) you would be able to disable the filter for high-end boards that require it. This would be fairly easy to implement. Best regards, Tjaling Hattink --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath9k: register GPIO chip for OF targets
This partitialy reverts commit ccab68f2d399.
Registering the GPIO chip without a parent device completely breaks the
ath9k GPIOs for device tree targets.
As long as boards using the devicetree don't have the gpio-controller
property set for the ath9k node, the unloading of the driver works as
expected.
Register the GPIO chip with the ath9k device as parent only for OF
targets to find a trade-off between the needs of driver developers and
the broken LEDs and buttons seen by users.
Signed-off-by: Mathias Kresin
---
.../ath/548-ath9k_enable_gpio_chip.patch | 21 +--
.../ath/549-ath9k_enable_gpio_buttons.patch | 8 +++
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git
a/package/kernel/mac80211/patches/ath/548-ath9k_enable_gpio_chip.patch
b/package/kernel/mac80211/patches/ath/548-ath9k_enable_gpio_chip.patch
index 0b76d330c6..eb9eb26a74 100644
--- a/package/kernel/mac80211/patches/ath/548-ath9k_enable_gpio_chip.patch
+++ b/package/kernel/mac80211/patches/ath/548-ath9k_enable_gpio_chip.patch
@@ -45,7 +45,7 @@ Signed-off-by: Felix Fietkau
#ifdef CPTCFG_ATH9K_DEBUGFS
--- a/drivers/net/wireless/ath/ath9k/gpio.c
+++ b/drivers/net/wireless/ath/ath9k/gpio.c
-@@ -16,13 +16,130 @@
+@@ -16,13 +16,139 @@
#include "ath9k.h"
#include
@@ -126,7 +126,13 @@ Signed-off-by: Felix Fietkau
+ gc->sc = sc;
+ snprintf(gc->label, sizeof(gc->label), "ath9k-%s",
+ wiphy_name(sc->hw->wiphy));
-+
++#ifdef CONFIG_OF
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,5,0)
++ gc->gchip.parent = sc->dev;
++#else
++ gc->gchip.dev = sc->dev;
++#endif
++#endif
+ gc->gchip.label = gc->label;
+ gc->gchip.base = -1;/* determine base automatically */
+ gc->gchip.ngpio = ah->caps.num_gpio_pins;
@@ -141,6 +147,9 @@ Signed-off-by: Felix Fietkau
+ return;
+ }
+
++#ifdef CONFIG_OF
++ gc->gchip.owner = NULL;
++#endif
+ sc->gpiochip = gc;
+}
+
@@ -178,7 +187,7 @@ Signed-off-by: Felix Fietkau
static void ath_fill_led_pin(struct ath_softc *sc)
{
struct ath_hw *ah = sc->sc_ah;
-@@ -80,6 +197,12 @@ static int ath_add_led(struct ath_softc
+@@ -80,6 +206,12 @@ static int ath_add_led(struct ath_softc
else
ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
@@ -191,7 +200,7 @@ Signed-off-by: Felix Fietkau
return 0;
}
-@@ -136,17 +259,24 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -136,17 +268,24 @@ void ath_deinit_leds(struct ath_softc *s
while (!list_empty(>leds)) {
led = list_first_entry(>leds, struct ath_led, list);
@@ -216,7 +225,7 @@ Signed-off-by: Felix Fietkau
char led_name[32];
const char *trigger;
int i;
-@@ -156,6 +286,15 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -156,6 +295,15 @@ void ath_init_leds(struct ath_softc *sc)
if (AR_SREV_9100(sc->sc_ah))
return;
@@ -232,7 +241,7 @@ Signed-off-by: Felix Fietkau
ath_fill_led_pin(sc);
if (pdata && pdata->leds && pdata->num_leds)
-@@ -180,6 +319,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -180,6 +328,7 @@ void ath_init_leds(struct ath_softc *sc)
ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
!sc->sc_ah->config.led_active_high);
}
diff --git
a/package/kernel/mac80211/patches/ath/549-ath9k_enable_gpio_buttons.patch
b/package/kernel/mac80211/patches/ath/549-ath9k_enable_gpio_buttons.patch
index e7282ab6b1..bd71b75e76 100644
--- a/package/kernel/mac80211/patches/ath/549-ath9k_enable_gpio_buttons.patch
+++ b/package/kernel/mac80211/patches/ath/549-ath9k_enable_gpio_buttons.patch
@@ -29,7 +29,7 @@ Signed-off-by: Felix Fietkau
#ifdef CPTCFG_MAC80211_LEDS
-@@ -124,6 +126,67 @@ static void ath9k_unregister_gpio_chip(s
+@@ -133,6 +135,67 @@ static void ath9k_unregister_gpio_chip(s
sc->gpiochip = NULL;
}
@@ -97,7 +97,7 @@ Signed-off-by: Felix Fietkau
#else /* CONFIG_GPIOLIB */
static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
-@@ -134,6 +197,14 @@ static inline void ath9k_unregister_gpio
+@@ -143,6 +206,14 @@ static inline void ath9k_unregister_gpio
{
}
@@ -112,7 +112,7 @@ Signed-off-by: Felix Fietkau
#endif /* CONFIG_GPIOLIB */
//
-@@ -257,6 +328,7 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -266,6 +337,7 @@ void ath_deinit_leds(struct ath_softc *s
{
struct ath_led *led;
@@ -120,7 +120,7 @@ Signed-off-by: Felix Fietkau
while (!list_empty(>leds)) {
led = list_first_entry(>leds, struct ath_led, list);
#ifdef CONFIG_GPIOLIB
-@@ -296,6 +368,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -305,6 +377,7 @@ void ath_init_leds(struct ath_softc *sc)
}
ath_fill_led_pin(sc);
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
Em 06/12/2018 18:18, Thomas Endt escreveu: I tried to include your comments while creating these two pages: https://openwrt.org/docs/techref/targets/ar71xx-ath79 https://openwrt.org/unsupported/ath79_wip Please crosscheck. It is perfect, thank you! There is a table that documents the ath79 status in the OpenWrt forum: https://forum.openwrt.org/t/ath79-target-status/18614/9 Can I set all devices listed as "working" to "ar71xx-ath79 + no ath79 WIP"? Probably yes, but I am not the best person to answer that question since I have no idea of what level of ath79 support "working" implies. That said, as the native ath79 support and migration from ar71xx get tested (or completed) for a device, they can lose the WIP tag, so I see no problem with your suggestion... I would not tag something that fails to boot with ethernet access still working and configured after an ar71xx->ath79 migration as "ar71xx-ath79 WIP" unless one can add a "!beware!" sort of reminder to the listing, though ;-) -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents
Hi, I had a brief discussion with John on this matter and was being told that the reason for this filter was to optimize boot time. When we remove the /dev filter, boot time will increase considerably on lower end devices due to the resulting hotplug-call overhead of the huge volume of additional uevents. A better approach here would be to selectively whitelist uevents based on subsystem or similar attributes, e.g. `DEVTYPE=usb_device`. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
The udevtrigger tool is responsible for firing hotplug
events for all devices that have been enumerated by
the kernel before the hotplug daemon is running. This
happens during the 'early' (coldplug) stage of procd.
A filter is in place during the scan of devices that
requires a dev attribute file to be present in the
sysfs. The argument is that without this attribute you
are not able to create a device node under '/dev'.
But there might be other hotplug scripts that are for
example do detection of certain connected devices that
do not have a dev attribute file, for example USB
devices and their siblings. To make sure these hotplug
scripts are also called during coldplug the filter is
removed.
Signed-off-by: Tjalling Hattink
---
plug/udevtrigger.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/plug/udevtrigger.c b/plug/udevtrigger.c
index f87a95e..db0c29a 100644
--- a/plug/udevtrigger.c
+++ b/plug/udevtrigger.c
@@ -161,9 +161,8 @@ static int device_list_insert(const char *path)
dbg("add '%s'" , path);
- /* we only have a device, if we have a dev and an uevent file */
- if (!device_has_attribute(path, "/dev", S_IRUSR) ||
- !device_has_attribute(path, "/uevent", S_IWUSR))
+ /* we can only trigger a hotplug event, if we have an uevent file */
+ if (!device_has_attribute(path, "/uevent", S_IWUSR))
return -1;
strlcpy(devpath, [4], sizeof(devpath));
--
2.14.1
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support
On Fri, Dec 7, 2018 at 10:57 AM Stijn Tintel wrote: > > On 7/12/18 10:17, Alexandru Ardelean wrote: > > On Fri, Dec 7, 2018 at 5:06 AM Stijn Tintel wrote: > >> On 11/11/18 18:37, Stijn Tintel wrote: > >>> Hi, > >>> > >>> I have just pushed support for the 4.14 kernel on the brcm2708 target to > >>> my staging tree [1], and would like to get some feedback before pushing > >>> it to master. It would also be nice if people could do runtime tests on > >>> bcm2709 and bcm2710, as I don't own such hardware. > >>> > >>> Thanks, > >>> Stijn > >>> > >>> [1] > >>> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14 > >>> > >> Updated [1]: > >> - based on 4.14.86 > >> - split kmod changes in separate commits > >> - kept lan78xx patches except those that are superseded by upstream > >> changes, added another one that attempts to fix broken ethernet and > >> "kevent 4 may have been dropped" flood > >> - added missing compatible strings using upstream names for compute modules > >> - no longer removing the sense HAT patch, I might add kmod packages for > >> that later > >> > >> Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and > >> runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired > >> interface on the latter seems to be usable now. > >> > >> I'm planning to push this to master as soon as Koen pushed the 4.14.86 > >> bump. If there are any objections, please speak up ASAP. > >> > > This one booted fine on a RPi 3. > > I used the 32 bit image. > > > > root@OpenWrt:~# uname -a > > Linux OpenWrt 4.14.86 #0 SMP Fri Dec 7 03:03:39 2018 armv7l GNU/Linux > Thanks for testing, I added your "Tested-by". Ack. > > > > A few minor/ignorable errors: > > [0.769743] Error: Driver 'sdhost-bcm2835' is already registered, > > aborting... > Fixed by disabling CONFIG_MMC_BCM2835_MMC since we want to prefer > upstream when possible. > > [8.689456] brcmfmac mmc1:0001:1: Direct firmware load for > > brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with > > error -2 > > > Similar error appeared for me with 4.9. Since it's non-fatal, I'm going > to ignore this for now. I assumed as much, but I was a bit lazy to re-create or flash an SD-card with a 4.9 image. > > Thanks, > Stijn > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support
On 7/12/18 10:17, Alexandru Ardelean wrote: > On Fri, Dec 7, 2018 at 5:06 AM Stijn Tintel wrote: >> On 11/11/18 18:37, Stijn Tintel wrote: >>> Hi, >>> >>> I have just pushed support for the 4.14 kernel on the brcm2708 target to >>> my staging tree [1], and would like to get some feedback before pushing >>> it to master. It would also be nice if people could do runtime tests on >>> bcm2709 and bcm2710, as I don't own such hardware. >>> >>> Thanks, >>> Stijn >>> >>> [1] >>> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14 >>> >> Updated [1]: >> - based on 4.14.86 >> - split kmod changes in separate commits >> - kept lan78xx patches except those that are superseded by upstream >> changes, added another one that attempts to fix broken ethernet and >> "kevent 4 may have been dropped" flood >> - added missing compatible strings using upstream names for compute modules >> - no longer removing the sense HAT patch, I might add kmod packages for >> that later >> >> Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and >> runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired >> interface on the latter seems to be usable now. >> >> I'm planning to push this to master as soon as Koen pushed the 4.14.86 >> bump. If there are any objections, please speak up ASAP. >> > This one booted fine on a RPi 3. > I used the 32 bit image. > > root@OpenWrt:~# uname -a > Linux OpenWrt 4.14.86 #0 SMP Fri Dec 7 03:03:39 2018 armv7l GNU/Linux Thanks for testing, I added your "Tested-by". > > A few minor/ignorable errors: > [0.769743] Error: Driver 'sdhost-bcm2835' is already registered, > aborting... Fixed by disabling CONFIG_MMC_BCM2835_MMC since we want to prefer upstream when possible. > [8.689456] brcmfmac mmc1:0001:1: Direct firmware load for > brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with > error -2 > Similar error appeared for me with 4.9. Since it's non-fatal, I'm going to ignore this for now. Thanks, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox] hotplug: add hotplug_call() helper
On 07/12/2018 09:39, Rafał Miłecki wrote: On 2018-12-07 04:41, Yousong Zhou wrote: On Thu, 6 Dec 2018 at 20:42, Rafał Miłecki wrote: From: Rafał Miłecki This new function imlements common code needed to run /etc/hotplug.d/ listeners. It allows specifying subsystem and environment strings as commonly used in the hotplug.d. hotplug-call is currently a OpenWrt-specific shell script from base-files. A library function's dependence on exact name and path of non-standard executable does not seem fit. You're probably right, I guess the best solution would be to implement hotplug-call script behavior directly in the libubox library. Hotplug events from the kernel is already being handled by hotplug.json script. Events from non-standard subsystem like "iface" as defined by netifd are generated and handled fine just by itself [1]. As such, I cannot find enough other places needing this function to make it into libubox. We could make netifd use that hotplug_call() helper, but now I noticed that netifd simply uses setenv() after the fork(). That may be simpler than building all that envp array. I'm not sure now if it's better to work on: 1) Improved (native) hotplug_call() implementation in the libubox 2) Original idea of doing fork() in the fstools / block + setenv() Implementing hotplug_call() was originally suggested by John, let's see what's his opinion too. I was simply thinking of making the code reusable. i do understand the concens. I dont really hold a really strong position on this. if you feel that it is better to implment this inside blockd directly or any other way, feel free to do so. John [1] https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-event.c;h=a40f6dc883d3a3654d73d0592cd7eb65c2a8de85;hb=HEAD#l45 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox] hotplug: add hotplug_call() helper
On 2018-12-07 04:41, Yousong Zhou wrote: On Thu, 6 Dec 2018 at 20:42, Rafał Miłecki wrote: From: Rafał Miłecki This new function imlements common code needed to run /etc/hotplug.d/ listeners. It allows specifying subsystem and environment strings as commonly used in the hotplug.d. hotplug-call is currently a OpenWrt-specific shell script from base-files. A library function's dependence on exact name and path of non-standard executable does not seem fit. You're probably right, I guess the best solution would be to implement hotplug-call script behavior directly in the libubox library. Hotplug events from the kernel is already being handled by hotplug.json script. Events from non-standard subsystem like "iface" as defined by netifd are generated and handled fine just by itself [1]. As such, I cannot find enough other places needing this function to make it into libubox. We could make netifd use that hotplug_call() helper, but now I noticed that netifd simply uses setenv() after the fork(). That may be simpler than building all that envp array. I'm not sure now if it's better to work on: 1) Improved (native) hotplug_call() implementation in the libubox 2) Original idea of doing fork() in the fstools / block + setenv() Implementing hotplug_call() was originally suggested by John, let's see what's his opinion too. [1] https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-event.c;h=a40f6dc883d3a3654d73d0592cd7eb65c2a8de85;hb=HEAD#l45 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
On 06/12/2018 23:51, Jo-Philipp Wich wrote: But even this may be not needed: For Tp-Link recently was released a mobile app Tether to control a router https://www.tp-link.com/us/tether/ This would imply both tying OpenWrt to a proprietary app and limiting its configuration to whatever settings that happen to be exposed by it - this hardly sounds like a viable solution to me. Having an app or a client application to control things would be cool though. I've seen this tutorial to "create" an Android/iOS app with Blynk that is using a SSH console to send over commands to the Lua interpreter on the device (maybe it can be made to work with shell script) https://www.instructables.com/id/AndroidiOS-App-to-Access-Your-OpenWrt-Router-Remot/ Just in case someone wants to do that. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
Hi!
On Mon, Oct 29, 2018 at 12:40 AM Christian Lamparter wrote:
>
> Ben Greear reported in his patch:
> |Subject: netgear r7800: Fix mac address of radios.
> |
> |Reloading the driver causes the phyX to change, and that
> |caused the MAC address to change.
>
> This is because all ODM/OEMs except QCA bothered to write
> the correct MAC address for the ath10k wifi into the
> calibration data.
>
> This patch copies over the MAC patching helper functions from ipq40xx's
> target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> file and converts all the devices to patch the correct MACs into the
> extracted calibration data before it gets sent to the driver, which sets
> up the device with the correct MAC address. It also removes the
> 10_fix_wifi_mac file as it has served its purpose.
>
> Please note the C2600: There is conflicting information on what
> the offset for the second wifi is supposed to be. This patch uses
> what was specified in 10_fix_wifi_mac.
>
> Reported-by: Ben Greear
> Signed-off-by: Christian Lamparter
> ---
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 64 +--
> .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 37 ---
> 2 files changed, 57 insertions(+), 44 deletions(-)
> delete mode 100644
> target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
>
> diff --git
> a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index fa49c250f0..1d070603f2 100644
> --- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -1,5 +1,21 @@
> #!/bin/sh
>
> +# xor multiple hex values of the same length
> +xor() {
> + local val
> + local ret="0x$1"
> + local retlen=${#1}
> +
> + shift
> + while [ -n "$1" ]; do
> + val="0x$1"
> + ret=$((ret ^ val))
> + shift
> + done
> +
> + printf "%0${retlen}x" "$ret"
> +}
> +
> ath10kcal_die() {
> echo "ath10cal: " "$*"
> exit 1
> @@ -36,6 +52,29 @@ ath10kcal_patch_mac() {
> macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
> seek=6 count=6
> }
>
> +ath10kcal_patch_mac_crc() {
> + local mac=$1
> + local mac_offset=6
> + local chksum_offset=2
> + local xor_mac
> + local xor_fw_mac
> + local xor_fw_chksum
> +
> + xor_fw_mac=$(hexdump -v -n 6 -s $mac_offset -e '/1 "%02x"'
> /lib/firmware/$FIRMWARE)
> + xor_fw_mac="${xor_fw_mac:0:4} ${xor_fw_mac:4:4} ${xor_fw_mac:8:4}"
> +
> + ath10kcal_patch_mac "$mac" && {
> + xor_mac=${mac//:/}
> + xor_mac="${xor_mac:0:4} ${xor_mac:4:4} ${xor_mac:8:4}"
> +
> + xor_fw_chksum=$(hexdump -v -n 2 -s $chksum_offset -e '/1
> "%02x"' /lib/firmware/$FIRMWARE)
> + xor_fw_chksum=$(xor $xor_fw_chksum $xor_fw_mac $xor_mac)
> +
> + printf "%b" "\x${xor_fw_chksum:0:2}\x${xor_fw_chksum:2:2}" | \
> + dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
> seek=$chksum_offset count=2
> + }
> +}
> +
I think we should replace the ath10kcal_patch_mac directly instead of
introducing another function.
All ath10k calibration data have a checksum at 0x2.
ath10kcal_patch_mac works for QCA9880/QCA9882 only because the ath10k
firmware for these two chips doesn't check the checksum value. (QCA
proprietary driver checks this and refuses to use caldata with
incorrect checksum.)
> [ -e /lib/firmware/$FIRMWARE ] && exit 0
>
> . /lib/functions.sh
> @@ -43,53 +82,64 @@ ath10kcal_patch_mac() {
>
> board=$(board_name)
>
> -
> case "$FIRMWARE" in
> "ath10k/pre-cal-pci-:01:00.0.bin")
> case $board in
> linksys,ea8500)
> - hw_mac_addr=$(mtd_get_mac_ascii devinfo hw_mac_addr)
> ath10kcal_extract "art" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_ascii
> devinfo hw_mac_addr) +1)
> + ;;
> + nec,wg2600hp)
> + ath10kcal_extract "ART" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> PRODUCTDATA 12) +1)
> ;;
> netgear,d7800 |\
> netgear,r7500v2 |\
> netgear,r7800)
> ath10kcal_extract "art" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> art 6) +1)
> ;;
> tplink,c2600)
> ath10kcal_extract "radio" 4096 12064
> -# ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary
> default-mac 8) -1)
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> default-mac 8) -1)
> ;;
> - nec,wg2600hp |\
> tplink,vr2600v)
> ath10kcal_extract "ART" 4096 12064
> +
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
> On Dec 7, 2018, at 08:29, Shaleen Jain wrote: > > Hi, > > [...] > The point about these boards requiring a lot of modification to be useful is > simply not true. > I have a TP-Link tl-wr841n-v11 running the master branch with kernel 4.14 > with luci > and sqm-scripts + miniupnpd with no problem at all. > > The only change I had to do was disable IPv6 and the opkg package from the > build image > resulting in the final image size of 3.8M [...] Jettisoning IPv6 seems like a size-reduction method that is not generally applicable, how is say ds-lite going to work on such a device? This is fine for the use case of an experienced (of well coached novice) user who understands the consequences, but it does not seem like a generic way to produce smaller images sizes for all users, no? - Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support
On Fri, Dec 7, 2018 at 5:06 AM Stijn Tintel wrote: > > On 11/11/18 18:37, Stijn Tintel wrote: > > Hi, > > > > I have just pushed support for the 4.14 kernel on the brcm2708 target to > > my staging tree [1], and would like to get some feedback before pushing > > it to master. It would also be nice if people could do runtime tests on > > bcm2709 and bcm2710, as I don't own such hardware. > > > > Thanks, > > Stijn > > > > [1] > > https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14 > > > Updated [1]: > - based on 4.14.86 > - split kmod changes in separate commits > - kept lan78xx patches except those that are superseded by upstream > changes, added another one that attempts to fix broken ethernet and > "kevent 4 may have been dropped" flood > - added missing compatible strings using upstream names for compute modules > - no longer removing the sense HAT patch, I might add kmod packages for > that later > > Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and > runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired > interface on the latter seems to be usable now. > > I'm planning to push this to master as soon as Koen pushed the 4.14.86 > bump. If there are any objections, please speak up ASAP. > This one booted fine on a RPi 3. I used the 32 bit image. root@OpenWrt:~# uname -a Linux OpenWrt 4.14.86 #0 SMP Fri Dec 7 03:03:39 2018 armv7l GNU/Linux A few minor/ignorable errors: [0.769743] Error: Driver 'sdhost-bcm2835' is already registered, aborting... [8.689456] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with error -2 Full dmesg log below /START dmesg --/ [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.14.86 (sandu@saturn) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r8039+640-0317fc3658)) #0 SMP Fri Dec 7 03:03:39 2018 [0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3 [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 16 MiB at 0x3a40 [0.00] On node 0 totalpages: 242688 [0.00] free_area_init_node: node 0, pgdat 80824bc0, node_mem_map b9c88000 [0.00] Normal zone: 1896 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 242688 pages, LIFO batch:31 [0.00] random: get_random_bytes called from start_kernel+0x84/0x35c with crng_init=0 [0.00] percpu: Embedded 16 pages/cpu @b9c34000 s33932 r8192 d23412 u65536 [0.00] pcpu-alloc: s33932 r8192 d23412 u65536 alloc=16*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 240792 [0.00] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 dwc_otg.lpm_enable=0 console=ttyS0,115200 kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 rootwait [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 937852K/970752K available (4656K kernel code, 148K rwdata, 1212K rodata, 1024K init, 351K bss, 16516K reserved, 16384K cma-reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xbb80 - 0xff80 (1088 MB) [0.00] lowmem : 0x8000 - 0xbb40 ( 948 MB) [0.00] modules : 0x7f00 - 0x8000 ( 16 MB) [0.00] .text : 0x80008000 - 0x8058c324 (5649 kB) [0.00] .init : 0x8070 - 0x8080 (1024 kB) [0.00] .data : 0x8080 - 0x808253c0 ( 149 kB) [0.00].bss : 0x8082a1a8 - 0x80881e08 ( 352 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] arch_timer: cp15 timer(s) running at 19.20MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [0.07] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [0.21] Switching to timer-based delay loop, resolution 52ns [0.000222] Console: colour dummy device 80x30 [0.000675] console [tty1] enabled
