Re: Question to recent Qualcomm CVEs

On Thursday, 2 May 2024 09:25:03 CEST Sven Eckelmann wrote: > On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote: > > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > > It's quite strange that they updated 2.5.0.1 branch first but my > > > un

Re: Question to recent Qualcomm CVEs

On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote: > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > It's quite strange that they updated 2.5.0.1 branch first but my > > understanding that there should be updates for the newer 2.7.0.1 branch > >

Re: Question to recent Qualcomm CVEs

On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > It's quite strange that they updated 2.5.0.1 branch first but my > understanding that there should be updates for the newer 2.7.0.1 branch > as well (2.7.0.1 branch is also in linux-firmware). Yes, I also told them in the support ticket th

Re: Question to recent Qualcomm CVEs

On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote: [...] >> The Qualcomm bulletin[1] says "Patches are being actively > > shared with OEMs". > > > > Were these bugfixes made available for OpenWRT? Is there an established > > procedure for such cases, where closed-source firmware gets bu

[PATCH v2] dnsmasq: mark global ubus context as closed after fork

change the daemon->ubus pointer because various functions are already checking it for NULL. It is also the behavior which ubus_destroy() implements. Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns lookup results via ubus") Signed-off-by: Sven Eckelmann ---

[PATCH] dnsmasq: mark global ubus context as closed after fork

daemon->ubus pointer to NULL because various functions are already it for NULL. It is also the behavior which ubus_destroy() implements. Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns lookup results via ubus") Signed-off-by: Sven Eckelmann --- package/net

uboot-envtools: Don't preserve configs after sysupgrade

tc/fw_env.config is not preserved and instead autogenerated after each firmware installation. There might still be a good reason to restore the values from uci in case there is no code to auto-generate the settings. Fixes: 7f00e5ffc671 ("uboot-envtools: update to 2012.04.01") Signed-off-by:

[PATCH] uboot-envtools: Fix format of autogenerated sectors

ot;) Fixes: 54b275c8ed3a ("ipq40xx: add target") Signed-off-by: Sven Eckelmann --- package/boot/uboot-envtools/files/ipq40xx | 1 + package/boot/uboot-envtools/files/ipq806x | 1 + 2 files changed, 2 insertions(+) diff --git a/package/boot/uboot-envtools/files/ipq40xx b/package/boot/

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote: > On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote: > > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote: > > [...] > > > A node name change is required for the new patch to work

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote: [...] > A node name change is required for the new patch to work. Since we are > not aware of device that use cmdline as partition parser, I converted > each device that use nvmem-cells to the new format. I am not 100% if you refere

Re: nvmem: Defining cells on mtd created by mtdparts

On Tuesday, 12 October 2021 20:24:46 CEST Pratyush Yadav wrote: [...] > I have been wanting to fix this problem for a while but just never got > around to it. I was thinking about either extending the mtdparts syntax > to maybe add nvmem cell information in there or adding a separate > cmdline a

Re: nvmem: Defining cells on mtd created by mtdparts

On Sunday, 10 October 2021 14:53:13 CEST Sven Eckelmann wrote: [...] > Since there are most likely more devices out there which use mtdparts, I > would > guess that there might already be a strategy out there which can be used to > define the nvmem-provider for mtdparts defined pa

nvmem: Defining cells on mtd created by mtdparts

Hi, OpenWrt switched [1] their MAC address (from flash) retrieval code from their mtd-mac-address based solution [2] to nvmem-cells. The mtd-mac-address based solution had the benefit that it could find the correct partition by using get_mtd_device_nm - which was label based. So a lookup for a

Re: ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

On Friday, 17 September 2021 18:25:35 CEST Sven Eckelmann wrote: [...] > Interestingly, the crash disappeared when I've changed > baseEepHeader.nonLinearTxFir (offset 0xc2 in the BDF) from 1 to 0. > > The device itself was using firmware 10.4-3.6-00140 (the version currently in

ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

Hi, I've just wanted to test openwrt-21.02 (with ath10k-firmware-qca4019 + kmod- ath10k) on an Plasma Cloud PA1200 router. While this device worked fine in the past, with this upgrade (to the newest firmware from linux-firmware), the 5GHz radio firmware seems to crash whenever I set it up via `i

Re: ath79: sysupgrade format policy for ar71xx migrations

On Saturday, 2 January 2021 15:22:38 CET David Bauer wrote: > sorry for the late reply. > > Firs to fall, there is no real policy on that one, as OpenWrt itself does not > advertise support for cross-target upgrades. It might work, or it might not. Thanks for the reply. But the option 3 was alrea

[PATCH] images: Revert "fix boot failures on NAND with small sub pages"

d7638e94083329d5d2781 Data validation failed! Cc: Russell Senior Cc: Jonas Gorski Signed-off-by: Sven Eckelmann --- I've originally submitted another hack on top of the original hack to avoid this additional padding when the JFFS2 post-padding mark was detected. https://github.com/open

Re: ath79: sysupgrade format policy for ar71xx migrations

On Tuesday, 24 November 2020 08:58:04 CET Sven Eckelmann wrote: [...] > Now to the actual question: I will just add some extra info to the options shown below. Maybe it makes then more sense why I've added two gluon developers to the Cc. > What should the OpenMesh devices use as

ath79: sysupgrade format policy for ar71xx migrations

Hi, I am currently a little bit unsure about the preferred sysupgrade format when an ar71xx device is re-added as ath79 device. I know that there is a migration guide for users [1] but I didn't see one for developers. First a little bit of background: The OpenMesh devices used the combined ext

Re: ath79 subtarget with cmdline from bootloader

On Monday, 3 August 2020 00:49:40 CET SAn via openwrt-devel wrote: > The LibreRouter uses a dual-boot scheme that relies on the bootloader > configuring the kernel cmdline. At ar71xx 18.06 it was possible to select per > device if the cmdline from the bootloader has to be honored (using > patch-

[PATCH] mac80211: Fix wpa_supplicant config removal ubus call

t;. Fixes: b5516603dd90 ("mac80211: more wifi reconf related fixes") Signed-off-by: Sven Eckelmann --- package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.

Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

On Monday, 17 August 2020 10:39:00 CEST Bjørn Mork wrote: > Linus Lüssing writes: [...] > This is not a bug. They are deliberately breaking IPv6 because they > consider this a feature. You should not try to work around such issues. > It is a fight you cannot win. Any workaround will only encour

[OpenWrt-Devel] [PATCH v2] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

a short while, the whole MAC will stop to react. No traffic can be transported anymore from the CPU port from/to the AR40xx PHY/switch and the MAC has to be resetted. Signed-off-by: Sven Eckelmann --- v2: * move the changes directly to target/linux/ipq40xx/files-5.4/drivers/net/ethernet

Re: [OpenWrt-Devel] [PATCH] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

On Tuesday, 9 June 2020 15:23:04 CEST Sven Eckelmann wrote: [...] > The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would > be good that this patch (or maybe even a better one) is copied to these > versions (and then refreshed). > > Thanks > > .

[OpenWrt-Devel] [PATCH] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

a short while, the whole MAC will stop to react. No traffic can be transported anymore from the CPU port from/to the AR40xx PHY/switch and the MAC has to be resetted. Signed-off-by: Sven Eckelmann --- The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would be good that this

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote: [...] > And it still can with this OpenWrt version. But it doesn't seem to happen > with > the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000 > commits inbetween. So no idea what changed (just

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote: [...] > could somone clarify the state here and why it was dropped? > the original patch i wrote does exclude the soc chipsets, but the patch > was later reorganized and some part have been rewritten > so i'm not sure if it covers

[OpenWrt-Devel] [PATCH v2] uci: fix options list of section after type change

lean up uci_set") Signed-off-by: Sven Eckelmann --- v2: - drop unnecessary include of stdbool.h in cli.c list.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/list.c b/list.c index 25aec56..78efbaf 100644 --- a/list.c +++ b/list.c @@ -182,6 +1

Re: [OpenWrt-Devel] [PATCH] uci: test: use valgrind to detect memory corruptions

On Friday, 17 May 2019 11:44:25 CEST Charlemagne Lasse wrote: > uci is currently a highly problematic software and its library & lua > bindings cannot be used without corrupting or leaking memory heap-use-after-free - yes. But I cannot find the memory leak report/test. This is what I am currently

[OpenWrt-Devel] [PATCH] uci: fix options list of section after type change

lean up uci_set") Signed-off-by: Sven Eckelmann --- cli.c | 1 + list.c | 31 +++ 2 files changed, 32 insertions(+) diff --git a/cli.c b/cli.c index f8b45db..9ffd45c 100644 --- a/cli.c +++ b/cli.c @@ -15,6 +15,7 @@ #include #include #include +#include

Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock

On Tuesday, 14 May 2019 15:42:18 CEST Pavel Kubelun wrote: > +--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi > b/arch/arm/boot/dts/qcom-ipq4019.dtsi > +@@ -141,9 +141,9 @@ > + }; > + > + clocks { > +- sleep_clk: sleep_clk { > ++ sleep_clk: gcc_sleep_clk_src {

Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock

On Wednesday, 15 May 2019 19:16:51 CEST Павел wrote: [...] > > Is there any particular reason why > > this > > shouldn't be sent upstream and then backported to OpenWrt? > > > > There are no reasons why it shouldn't be sent upstream along with other > patches. I hope to find someone with datasheet

Re: [OpenWrt-Devel] ath10k TPC reg. domain incorrect?

On Monday, 13 May 2019 22:58:00 CEST Sam Samy wrote: > I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri > band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios > (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working > fine except one problem in 5Ghz

Re: [OpenWrt-Devel] [PATCH] ath79: Add missing read-only properties

On Thursday, 9 May 2019 13:50:39 CEST Adrian Schmutzler wrote: > diff --git a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts b/ target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts > index 1e3cf40f71..fa74cf2344 100644 > --- a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts > +++ b

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

On Saturday, 16 March 2019 13:18:48 CET Xuebing Wang wrote: [...] > 1) Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based > routers. > 2) Firmware from kvalo/linux-firmware > > Are these "2 lines" of firmware essentially the same? They should at least be quite similar. Maybe Kall

Re: [OpenWrt-Devel] WPJ428HV board - OpenWRT

On Thursday, 14 March 2019 22:39:54 CET Lloyed Emmanuel wrote: [...] > I have loaded the following OpenWRT firmware to WPJ428HV boards. > > http://downloads.openwrt.org/releases/18.06.2/targets/ipq40xx/generic/openwrt-18.06.2-ipq40xx-compex_wpj428-squashfs-sysupgrade.bin > > and I followed your

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

On Sunday, 10 March 2019 18:03:51 CET Ben Greear wrote: [...] > > [2] > > https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5 > > So, both of the patches above need to be applied to ath10k-ct 4.19 driver? > > > [3] h

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote: [...] > Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2 > or branch openwrt-18.06? Most(?) companies and community projects just throw the 802.11s forwarding/ routing part away and are running their preferred Layer2

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote: > From: Sebastian Gottschall > > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based > chipsets with on chipset connected led's using WMI Firmware API. The LED > device will get available named as "ath10k-phyX" at sysfs

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

On Monday, 25 February 2019 20:25:25 CET Sven Eckelmann wrote: > On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote: > > >> Mesh is broken using ath10k-ct? > > >> https://bugs.openwrt.org/index.php?do=details&task_id=2123 [...] > Can you check if follow

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote: > >> Mesh is broken using ath10k-ct? > >> https://bugs.openwrt.org/index.php?do=details&task_id=2123 [...] > * The "classic" drivers/firmware fail on or after the indicated commit > > CONFIG_PACKAGE_ath10k-firmware-qca9887=y >

Re: [OpenWrt-Devel] [B.A.T.M.A.N.] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

On Monday, 25 February 2019 09:03:52 CET Кирилл Луконин wrote: > But what about ELP interval parameter? > As I think, it should be covered by UCI config too. Please first provide a batctl patch to support this setting. Then we can discuss the uci integration. Kind regards, Sven signatur

Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

On Monday, 25 February 2019 02:24:56 CET Gui Iribarren wrote: > have you considered, to simplify backwards compatibility, to keep proto > "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? It was one of the goals to *not* name the batadv hardif interface proto "batadv".

[OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

fig interface 'bat0_hardif_eth0' option proto 'batadv_hardif' option master 'bat0' option ifname 'eth0' option mtu '1536' # configure IP on bat0 config interface 'bat0_lan' option ifname '

Re: [OpenWrt-Devel] 5GHz wifi is broken

On Saturday, 16 February 2019 22:36:18 CET Christian Lamparter wrote: > @Ben can you please take a peek into your wave-1 firmware and check if the > mgmt_rate WMI (WMI_10X_VDEV_PARAM_MGMT_RATE) is supported, or if there is > a bad interaction somewhere else? I am using the same driver and ath10k-

Re: [OpenWrt-Devel] OM2P ImageBuilder

On Thursday, 14 February 2019 13:07:42 CET Conca Ten wrote: [...] > regarding your exchange at > [OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used > > I've tried to use https://chef.aparcar.org to > generate a flashable firmware with added package

Re: [OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used

sed by the way SingleProfile is defined and how it interacts with LegacyDevice (include/image-legacy.mk) vs. Device (include/image.mk). If you look carefully, you will notice that legacy devices spawn a new sub-make - non-legacy devices don't do that. You can try the attached mini-patch [1] to ch

Re: [OpenWrt-Devel] ath9k: Max 3 dBi gain for FCC (365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch)

On Dienstag, 31. Juli 2018 10:57:03 CET Sven Eckelmann wrote: > Hi, > > I've just checked the FCC "antenna reduction workaround" patch [1] in ath9k. > The code uses twicepower (.5 dB unit used by QCA) and uses 6 (3dBi) as > allowed > gain for FCC. The commen

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

On Dienstag, 28. August 2018 17:26:36 CEST Wang guilin wrote: > Hi,Sven > I am using the QCA9886 chip for the first time. I saw the example you > gave. > I think the following code should be deleted. > ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin > /lib/firmware/

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

On Dienstag, 28. August 2018 09:38:39 CEST John Crispin wrote: > > +gl-x1200) > > + ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" > > "phy1tpt" > > + ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" > > "phy0tpt" > > + ;; > > this section aswell as seve

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

On Montag, 27. August 2018 19:12:58 CEST wellnw wrote: > + },/* { > +.desc = "right", > +.type = EV_KEY, > +.code = BTN_0, > +.debounce_interval = GL_AR750S_KEYS_DEBOUNCE_INTERVAL, > +.gpio

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

On Montag, 27. August 2018 19:12:58 CEST wellnw wrote: > @@ -282,6 +283,8 @@ CONFIG_ATH79=y > # CONFIG_ATH79_PCI_ATH9K_FIXUP is not set > # CONFIG_ATH79_ROUTERBOOT is not set > CONFIG_ATH79_WDT=y > +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y > +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > CONFIG_CEVT_R

[OpenWrt-Devel] ath9k: Max 3 dBi gain for FCC (365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch)

Hi, I've just checked the FCC "antenna reduction workaround" patch [1] in ath9k. The code uses twicepower (.5 dB unit used by QCA) and uses 6 (3dBi) as allowed gain for FCC. The comment also states "FCC allows maximum antenna gain of 3 dBi". Where does the 3dBi come from? 15.247(b)(4) talks ab

Re: [OpenWrt-Devel] [PATCH 3/4] ipq40xx: fix OpenMesh A62 dtc warnings

iled prerequisite 'pci_bridge' > Warning (pci_device_reg): Failed prerequisite 'pci_bridge' > Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge' > > Cc: Sven Eckelmann > Signed-off-by: Christian Lamparter > --- Tested-by:

Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to mesh-mode supplicant

On Montag, 4. Juni 2018 13:17:10 CEST Daniel Hernandez wrote: > Hello > > Any clue if these fixes are going to make it into Openwrt / LEDE 18.06 . So > I can begin testing. They are part of openwrt-18.06-snapshot. Kind regards, Sven signature.asc Description: This is a digitally sig

Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to mesh-mode supplicant

On Freitag, 13. April 2018 01:41:31 CEST Daniel Golle wrote: > Unlike when operating in Ad-Hoc mode, we apparently need to pass the > hostapd control socket interface to wpa_supplicant when using 802.11s > mesh mode. > > There also seems to still be something wrong with the logic setting > channel

[OpenWrt-Devel] (V)HT mode selection for meshpoint (was "ath10k + ap + encryption")

On Mittwoch, 6. Dezember 2017 22:26:09 CEST Sven Eckelmann wrote: > On Mittwoch, 6. Dezember 2017 18:52:01 CET Daniel Hernandez wrote: > > So been running this mesh patch on 4 routers in my home for over a > > month and it works great ! > > Reporting my feedbac

[OpenWrt-Devel] [PATCH ipq 2/2] ipq40xx: Fix A42 eth port aliases/mac addresses

doesn't only affect the names of the virtual interface names but also swaps the mac addresses of the ports. The first ethernet port will then no longer use the mac address which is printed on the device. [1] https://patchwork.kernel.org/patch/9133903/ Signed-off-by: Sven Eckelmann --- I was

[OpenWrt-Devel] [PATCH ipq 1/2] ipq40xx: Use exact SoC name in A42 DTS name

The naming scheme of ipq40xx DTS files was adjusted with the switch to the new IPQ40xx target. This was not done correctly for the OpenMesh A42 which is actually an IPQ4018 and not an IPQ4019. Signed-off-by: Sven Eckelmann --- .../arch/arm/boot/dts/{qcom-ipq4019-a42.dts => qcom-ipq4018-a42.

[OpenWrt-Devel] [PATCH ipq 0/2] ipq40xx: OpenMesh A42 adjustments

-split. They were also uploaded to github. Kind regards, Sven [1] https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=shortlog;h=refs/heads/ipq [2] https://github.com/ecsv/openwrt/tree/ipq-rebuttal Sven Eckelmann (2): ipq40xx: Use exact SoC name in A42 DTS name ipq40xx: Fix A42

Re: [OpenWrt-Devel] Reducing the root file system in openwrt

On Mittwoch, 7. März 2018 17:30:31 CET Arjav Parikh wrote: [...] > I tried to remove those files by removing its entry from > root-ipq806x/usr/lib/opkg/info/wigig-firmware.list assuming that on > next build these files wont appear but still the files are there in > /lib/firmware directory. Is this

Re: [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT

On Freitag, 9. Februar 2018 09:05:02 CET Sven Eckelmann wrote: [...] > > In OpenWRT 15.01 we are building 7.3MB large images and have just > > enought space for configs. > > In LEDE 17.01 is max size ~6.5MB and we are not able to build our > > images, because we cannot str

Re: [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT

On Freitag, 9. Februar 2018 01:36:49 CET Jakub Jančo wrote: > Hello, > > is there any reason why LEDE needs more empty space in firmware for > TP-link tl-wr1043nd v3 ? OpenWrt master should show you the exact same error message. OpenWrt 15.05 is quite outdated. > In OpenWRT 15.01 we are buildin

Re: [OpenWrt-Devel] IPQ8064: Remove GMAC/Ethernet Support

On Dienstag, 30. Januar 2018 14:08:28 CET Arjav Parikh wrote: > Hi Team, > > I am working on Qualcomm IPQ8064 SOC for one of my project and I want > to remove the Ethernet and GMAC support from Linux as I am not using > Ethernet PHY in my project. > > The purpose for removing the support from ker

Re: [OpenWrt-Devel] [PATCH 4/8] caldata-utils: new package to manipulate ath10k

On Donnerstag, 31. März 2016 19:48:20 CET Adrian Panella wrote: > >From df9a676bb3ba225f0fd6621dbaeec945baf3153d Mon Sep 17 00:00:00 2001 > From: Adrian Panella > Date: Wed, 30 Mar 2016 23:31:06 -0600 > Subject: [PATCH 12/15] caldata-utils: new package to manipulate ath10k > calibration data >

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

On Montag, 19. September 2016 11:34:00 CET Sven Eckelmann wrote: > On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote: > [...] > > > We're testing encrypted AP + Mesh quite successfully right now with > > > this firmware: https://github.com/kvalo/at

[OpenWrt-Devel] [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices

/status LEDs] Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 27 ++ 1 file changed, 27 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds index d11369c

[OpenWrt-Devel] LED uci policy for not actively used LEDs

Hi, how should non-actively used LEDs be handled in regards of entries in uci system.*. I saw some entries in target/linux/ar71xx/base-files/etc/board.d/ 01_leds with calls to ucidef_set_led_default with the default parameter set to 0. But not all LEDs have an entry in either 01_leds or diag.sh

[OpenWrt-Devel] [PATCH] base-files: Prefer busybox arp over /proc/net/arp alias

From: Marek Lindner A firmware compiled with BUSYBOX_CONFIG_ARP should also use by default the arp binary from busybox. Otherwise the extra functionality the user requested can only be used when running arp with the path to the binary. Signed-off-by: Marek Lindner --- package/base-files/files/

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote: [...] > > We're testing encrypted AP + Mesh quite successfully right now with > > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b > > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip. >

Re: [OpenWrt-Devel] [RFC v2 6/6] ar71xx: Reset QCA955x SGMII link on speed change

On Tuesday 05 April 2016 15:32:13 Sven Eckelmann wrote: > From: Sven Eckelmann > > The SGMII link of the QCA955x seems to be unstable when the PHY changes the > link speed. Reseting the SGMII and the PHY management control seems to > resolve this problem. > > This was observ

[OpenWrt-Devel] [PATCH CC 13/13] ar71xx: add MR1750v2 to the MR1750 profile

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 11/13] package/uboot-envtools: add OpenMesh MR1750v2 support

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 12/13] ar71xx: extract ath10k wifi board.bin for the OpenMesh MR1750v2 board

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 10/13] package/om-watchdog: add OpenMesh MR1750v2 support

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 09/13] ar71xx: enable sysupgrade for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 08/13] ar71xx: add user-space support for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 07/13] ar71xx: add kernel support for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 06/13] ar71xx: add OM2P-HSv3 to the OM2P profile

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 05/13] package/uboot-envtools: add OpenMesh OM2P-HSv3 support

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 02/13] ar71xx: add user-space support for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 03/13] ar71xx: enable sysupgrade for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 04/13] package/om-watchdog: add OpenMesh OM2P-HSv3 support

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH CC 01/13] ar71xx: add kernel support for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- Based on following CC backports from 2016-05-19: * https://patchwork.ozlabs.org/patch/624172/ * https://patchwork.ozlabs.org/patch/624173/ * https://patchwork.ozlabs.org/patch/624174/ * https://patchwork.ozlabs.org/patch/624175/ * https

[OpenWrt-Devel] [PATCH 04/13] package/om-watchdog: add OpenMesh OM2P-HSv3 support

Signed-off-by: Sven Eckelmann --- package/kernel/om-watchdog/files/om-watchdog.init | 1 + 1 file changed, 1 insertion(+) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 79819ad..4c6ac45 100644 --- a/package/kernel/om

[OpenWrt-Devel] [PATCH 13/13] ar71xx: add MR1750v2 to the MR1750 profile

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index eb972ee..15b974a 100644 --- a

[OpenWrt-Devel] [PATCH 12/13] ar71xx: extract ath10k wifi board.bin for the OpenMesh MR1750v2 board

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11

[OpenWrt-Devel] [PATCH 11/13] package/uboot-envtools: add OpenMesh MR1750v2 support

Signed-off-by: Sven Eckelmann --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index dc7583f..986fdef 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b

[OpenWrt-Devel] [PATCH 10/13] package/om-watchdog: add OpenMesh MR1750v2 support

Signed-off-by: Sven Eckelmann --- package/kernel/om-watchdog/files/om-watchdog.init | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 4c6ac45..4ed178d 100644 --- a

[OpenWrt-Devel] [PATCH 09/13] ar71xx: enable sysupgrade for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index 2e01419..2ce5331 100755 --- a

[OpenWrt-Devel] [PATCH 08/13] ar71xx: add user-space support for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 3 ++- target/linux/ar71xx/base-files/etc/board.d/02_network | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 3 ++- target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ target

[OpenWrt-Devel] [PATCH 07/13] ar71xx: add kernel support for the OpenMesh MR1750v2

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c | 1 + target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c b/target/linux/ar71xx/files/arch

[OpenWrt-Devel] [PATCH 06/13] ar71xx: add OM2P-HSv3 to the OM2P profile

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 6817c59..eb972ee 100644 --- a

[OpenWrt-Devel] [PATCH 05/13] package/uboot-envtools: add OpenMesh OM2P-HSv3 support

Signed-off-by: Sven Eckelmann --- package/boot/uboot-envtools/files/ar71xx | 1 + 1 file changed, 1 insertion(+) diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index 32e7269..dc7583f 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b

[OpenWrt-Devel] [PATCH 03/13] ar71xx: enable sysupgrade for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 + target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++ 2 files changed, 3 insertions(+) diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh b/target/linux/ar71xx/base-files

[OpenWrt-Devel] [PATCH 02/13] ar71xx: add user-space support for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 1 + target/linux/ar71xx/base-files/etc/diag.sh | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++ 3 files changed, 5 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc

[OpenWrt-Devel] [PATCH 01/13] ar71xx: add kernel support for the OpenMesh OM2P-HSv3

Signed-off-by: Sven Eckelmann --- target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c | 1 + target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c b/target/linux/ar71xx/files/arch/mips

[OpenWrt-Devel] [PATCH CC 34/34] ar71xx: add OM5P-ACv2 to the OM5P-AC profile

Signed-off-by: Sven Eckelmann Backport of r49155 --- target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk b/target/linux/ar71xx/generic/profiles/openmesh.mk index 64aaa24

[OpenWrt-Devel] [PATCH CC 33/34] ar71xx: extract ath10k wifi board.bin for the OpenMesh OM5P-ACv2 board

Signed-off-by: Sven Eckelmann Backport of r49154 --- .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base

[OpenWrt-Devel] [PATCH CC 31/34] om-watchdog: add OpenMesh OM5P-ACv2 support

Signed-off-by: Sven Eckelmann Backport of r49152 --- package/kernel/om-watchdog/files/om-watchdog.init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/om-watchdog/files/om-watchdog.init b/package/kernel/om-watchdog/files/om-watchdog.init index 8cec13b

  1   2   3   4   >