date:20180926

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-26 Thread Hartmut Knaack

Koen Vandeputte schrieb am 26.09.2018 um 09:38:
 
> These targets were also dropped in 18.06 branch.
> Maybe we should also consider dropping support for these targets in master?
> 
> 
> adm5120

I started working on this target last year, but had to focus on other
topics meanwhile. Still, I would not like to give up on this one.



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

2018-09-26 Thread Torsten Duwe

On Wed, 26 Sep 2018 13:08:22 +0200 Daniel Golle  wrote:

> The safe path is to use the VDSL-firmware-blob which is shipped in
> T-Com's own Speedport router firmware.

Sounds tempting...

> See
> https://xdarklight.github.io/lantiq-xdsl-firmware-info/

> Downloads for 5.6.8.4.1.7-5.6.7.2.1.2
> https://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20W%20921V/Firmware_Speedport_W921V_1.39.000.bin

As we found out off-list, this blob got updated and has moved:
https://github.com/xdarklight/lantiq-xdsl-firmware-info/issues/13

It establishes the connection here (slower than the blob below),
with interleave, and then drops it almost immediately again!

Sebastian Moeller suggested I use
"
5.8.1.5.0.7-5.8.0.9.0.1 29de7210958de4ba57464685f680dd66e6fb5b36
898856  8.1.5 8.0.9 VDSL over ISDN incl. vectoring support
"
from the list, which did the trick.

Thank you both for your quick and accurate help!
(even if the speedport FW didn't quite work out -- maybe it does elsewhere)

Thanks a lot!

Torsten

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] uhttpd: fix building without TLS and Lua support

2018-09-26 Thread Paul Willoughby

Adds ifdefs to fix building without TLS and Lua support

Signed-off-by: Paul Willoughby 
---
 client.c | 2 ++
 main.c   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/client.c b/client.c
index 3c1aa9d..5913553 100644
--- a/client.c
+++ b/client.c
@@ -557,11 +557,13 @@ void uh_client_notify_state(struct client *cl)
if (!s->eof || s->w.data_bytes)
return;
 
+#ifdef HAVE_TLS
if (cl->tls && cl->ssl.conn && cl->ssl.conn->w.data_bytes) {
cl->ssl.conn->eof = s->eof;
if (!ustream_write_pending(cl->ssl.conn))
return;
}
+#endif
}
 
return client_close(cl);
diff --git a/main.c b/main.c
index 219e37e..0b74231 100644
--- a/main.c
+++ b/main.c
@@ -219,6 +219,7 @@ static void fixup_prefix(char *str)
str[len + 1] = 0;
 }
 
+#ifdef HAVE_LUA
 static void add_lua_prefix(const char *prefix, const char *handler) {
struct lua_prefix *p;
char *pprefix, *phandler;
@@ -235,6 +236,7 @@ static void add_lua_prefix(const char *prefix, const char 
*handler) {
 
list_add_tail(>list, _prefix);
 }
+#endif
 
 int main(int argc, char **argv)
 {
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread Robert Marko

On Wed, 2018-09-26 at 17:24 +0200, John Crispin wrote:
> 
> > We will have to send patches to linux-firmware to get them to
> > update 
> > the files.
> > 
> > John
> 
> as a temp fix we need to revert
> e6bd568051c7ca77a59783fe50203f6e2a427f19 
> right ?
> 
>  John
> 

Sorry for top posting, Gmail is not making life easy.

Asking Kalle Valo to push new board binaries would be easiest.

Its not just reverting that patch as we have devices like OpenMesh A62
that was added only after upstreaming BDF-s for IPQ4019 and its
third radio that is QCA9888 based.

Can we use linux-firmware for firmware and the old ath10k-firmware for
board files as a temporary solution.

Robert

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart

2018-09-26 Thread Kristian Evensen

Hi,

On Wed, Sep 26, 2018 at 3:14 PM Kristian Evensen
 wrote:
> On Tue, Sep 25, 2018 at 11:23 AM Jo-Philipp Wich  wrote:
> > does the same happen without "bind-dynamic" ? My hunch is that dnsmasq
> > fails to "resubscribe" to the socket after the ifindex of br-lan changed
> > due to the network restart (which will destroy and recreate br-lan).
>
> bind-dynamic seems indeed to be the trigger. Disabling bind-dynamic
> makes the problem go away.

I have been testing some more and I can now trigger the problem
locally as well. However, I don't quite know how I managed to trigger
the issue. Still, I think I have discovered something. When I restart
network, there are two different outcomes for the dnsmasq process - it
is either killed (SIGTERM, trying to identify process) or nor. The
error always happens when the process is not killed. When dnsmasq dies
and is restarted, DHCP continues to work as normal.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread John Crispin

On 26/09/2018 17:14, John Crispin wrote:

On 26/09/2018 17:12, Robert Marko wrote:

I understand the issues with never firmware breaking driver features,
and I dont have anything against using linux-firmware for the firmware
but board files there are too old.
For example board-2.bin for IPQ4019 was last updated on 15.02.2018.
and it does not contain any of the BDF that were upstreamed for
various boards in ipq40xx target.
I just checked and it only has BDF-s for the OpenMesh-A42 board while
ath10k-firmware one has BDFs for eight more boards that are OpenWrt
supported.
So this switch will effectively break the radios on most of ipq40xx 
boards.

Only way around it is to again revert to using ipq-wifi for every board

Regards
Robert Marko

which part of "please dont top post" was not clear, just for future 
reference ?

On 26 September 2018 at 16:59, John Crispin  wrote:

On 26/09/2018 16:52, Robert Marko wrote:

What about all of the custom BDF-s that were upstreamed primarly for
IPQ40XX and lately various QCA99XX and QCA98XX radios?
By disabling ath10k-firmware and using the linux-firmware version 
we are

bound to have to use ipq-wifi again since firmware and board files are
really rarely updated in linux-firmware for QCA radios.

please dont top post ...

On 26 September 2018 at 11:49, Stanislaw Gruszka mailto:sgrus...@redhat.com>> wrote:

 On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
 > On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
 > > ...
 > > With that update I am fine with squashing the mac80211 
updates and

 > > pushing them to OpenWrt master.
 > >
 > > I checked the removed patches and could not find these two
 patches in
 > > the upstream kernel:
 > > *
 > >

package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch 

 >
 > Yes, this one should be dropped according to Stanislaw Gruszka,
 we've
 > discussed this earlier, but can't spot the thread right now.

 Yes, please drop this one and also apply patches from:

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01 

 which changes whay how interrupts are handled.

 The patches were tested by versious users with positive feedback,
 what is documented in:
 https://bugzilla.kernel.org/show_bug.cgi?id=82751

 Thanks
 Stanislaw

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org

https://lists.openwrt.org/mailman/listinfo/openwrt-devel

using randomly chosen firmwares from a github repo is no real 
alternative.
the linux-firmware files seem to geed enough for most mayor distros. 
the

htt/wmi abi can change between drivers/firmware and newer FW with older
drivers can cause all sorts of weird issues like the DFS false 
positive one.

the aim of this series is to get much closer to upstream in regards to
wireless allowing us to work closer with upstream.

 John

We will have to send patches to linux-firmware to get them to update 
the files.

    John

as a temp fix we need to revert e6bd568051c7ca77a59783fe50203f6e2a427f19 
right ?

    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread John Crispin

On 26/09/2018 17:12, Robert Marko wrote:

I understand the issues with never firmware breaking driver features,
and I dont have anything against using linux-firmware for the firmware
but board files there are too old.
For example board-2.bin for IPQ4019 was last updated on 15.02.2018.
and it does not contain any of the BDF that were upstreamed for
various boards in ipq40xx target.
I just checked and it only has BDF-s for the OpenMesh-A42 board while
ath10k-firmware one has BDFs for eight more boards that are OpenWrt
supported.
So this switch will effectively break the radios on most of ipq40xx boards.

Only way around it is to again revert to using ipq-wifi for every board

Regards
Robert Marko

which part of "please dont top post" was not clear, just for future 
reference ?

On 26 September 2018 at 16:59, John Crispin  wrote:

On 26/09/2018 16:52, Robert Marko wrote:

What about all of the custom BDF-s that were upstreamed primarly for
IPQ40XX and lately various QCA99XX and QCA98XX radios?
By disabling ath10k-firmware and using the linux-firmware version we are
bound to have to use ipq-wifi again since firmware and board files are
really rarely updated in linux-firmware for QCA radios.

please dont top post ...

On 26 September 2018 at 11:49, Stanislaw Gruszka mailto:sgrus...@redhat.com>> wrote:

 On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
 > On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
 > > ...
 > > With that update I am fine with squashing the mac80211 updates and
 > > pushing them to OpenWrt master.
 > >
 > > I checked the removed patches and could not find these two
 patches in
 > > the upstream kernel:
 > > *
 > >

package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
 >
 > Yes, this one should be dropped according to Stanislaw Gruszka,
 we've
 > discussed this earlier, but can't spot the thread right now.

 Yes, please drop this one and also apply patches from:

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01

 which changes whay how interrupts are handled.

 The patches were tested by versious users with positive feedback,
 what is documented in:
 https://bugzilla.kernel.org/show_bug.cgi?id=82751

 Thanks
 Stanislaw

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org

 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

using randomly chosen firmwares from a github repo is no real alternative.
the linux-firmware files seem to geed enough for most mayor distros. the
htt/wmi abi can change between drivers/firmware and newer FW with older
drivers can cause all sorts of weird issues like the DFS false positive one.
the aim of this series is to get much closer to upstream in regards to
wireless allowing us to work closer with upstream.

 John

We will have to send patches to linux-firmware to get them to update the 
files.

    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread Robert Marko

I understand the issues with never firmware breaking driver features,
and I dont have anything against using linux-firmware for the firmware
but board files there are too old.
For example board-2.bin for IPQ4019 was last updated on 15.02.2018.
and it does not contain any of the BDF that were upstreamed for
various boards in ipq40xx target.
I just checked and it only has BDF-s for the OpenMesh-A42 board while
ath10k-firmware one has BDFs for eight more boards that are OpenWrt
supported.
So this switch will effectively break the radios on most of ipq40xx boards.

Only way around it is to again revert to using ipq-wifi for every board

Regards
Robert Marko


On 26 September 2018 at 16:59, John Crispin  wrote:
>
> On 26/09/2018 16:52, Robert Marko wrote:
>>
>> What about all of the custom BDF-s that were upstreamed primarly for
>> IPQ40XX and lately various QCA99XX and QCA98XX radios?
>> By disabling ath10k-firmware and using the linux-firmware version we are
>> bound to have to use ipq-wifi again since firmware and board files are
>> really rarely updated in linux-firmware for QCA radios.
>>
> please dont top post ...
>>
>>
>> On 26 September 2018 at 11:49, Stanislaw Gruszka > > wrote:
>>
>> On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
>> > On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
>> > > ...
>> > > With that update I am fine with squashing the mac80211 updates and
>> > > pushing them to OpenWrt master.
>> > >
>> > > I checked the removed patches and could not find these two
>> patches in
>> > > the upstream kernel:
>> > > *
>> > >
>>
>> package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
>> >
>> > Yes, this one should be dropped according to Stanislaw Gruszka,
>> we've
>> > discussed this earlier, but can't spot the thread right now.
>>
>> Yes, please drop this one and also apply patches from:
>>
>> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01
>>
>> 
>> which changes whay how interrupts are handled.
>>
>> The patches were tested by versious users with positive feedback,
>> what is documented in:
>> https://bugzilla.kernel.org/show_bug.cgi?id=82751
>> 
>>
>> Thanks
>> Stanislaw
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> 
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>>
>>
> using randomly chosen firmwares from a github repo is no real alternative.
> the linux-firmware files seem to geed enough for most mayor distros. the
> htt/wmi abi can change between drivers/firmware and newer FW with older
> drivers can cause all sorts of weird issues like the DFS false positive one.
> the aim of this series is to get much closer to upstream in regards to
> wireless allowing us to work closer with upstream.
>
> John
>
>
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread John Crispin

On 26/09/2018 16:52, Robert Marko wrote:
What about all of the custom BDF-s that were upstreamed primarly for 
IPQ40XX and lately various QCA99XX and QCA98XX radios?
By disabling ath10k-firmware and using the linux-firmware version we 
are bound to have to use ipq-wifi again since firmware and board files 
are really rarely updated in linux-firmware for QCA radios.

please dont top post ...

On 26 September 2018 at 11:49, Stanislaw Gruszka > wrote:

On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
> On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
> > ...
> > With that update I am fine with squashing the mac80211 updates and
> > pushing them to OpenWrt master.
> >
> > I checked the removed patches and could not find these two
patches in
> > the upstream kernel:
> > *
> >

package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
>
> Yes, this one should be dropped according to Stanislaw Gruszka,
we've
> discussed this earlier, but can't spot the thread right now.

Yes, please drop this one and also apply patches from:

https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01

which changes whay how interrupts are handled.

The patches were tested by versious users with positive feedback,
what is documented in:
https://bugzilla.kernel.org/show_bug.cgi?id=82751

Thanks
Stanislaw

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

https://lists.openwrt.org/mailman/listinfo/openwrt-devel

using randomly chosen firmwares from a github repo is no real 
alternative. the linux-firmware files seem to geed enough for most mayor 
distros. the htt/wmi abi can change between drivers/firmware and newer 
FW with older drivers can cause all sorts of weird issues like the DFS 
false positive one. the aim of this series is to get much closer to 
upstream in regards to wireless allowing us to work closer with upstream.

    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ncurses: Add ncurses6 config

2018-09-26 Thread Jan Kardell

This is needed by gpsd. Otherwise it finds and uses the build hosts
version of ncurses header files. And that is not compatible, at least
on openSUSE.

Also use relative symlinks to the ncursesw6-config file.

This patch is needed in master and 18.06 branch.

Signed-off-by: Jan Kardell 
---
 package/libs/ncurses/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/package/libs/ncurses/Makefile b/package/libs/ncurses/Makefile
index 94c968816f..3c51b75129 100644
--- a/package/libs/ncurses/Makefile
+++ b/package/libs/ncurses/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ncurses
 PKG_VERSION:=6.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
@@ -148,13 +148,16 @@ define Build/InstallDev
for lib in ncurses panel menu form; do \
ln -s lib{lib}w.so $(1)/usr/lib/lib{lib}.so; \
done
+   ln -s . $(1)/usr/include/ncurses
ln -s . $(1)/usr/include/ncursesw
$(TARGET_CROSS)ar rc $(1)/usr/lib/libtinfo.a
$(INSTALL_DIR) $(2)/bin
$(CP) $(PKG_INSTALL_DIR)/usr/bin/ncursesw6-config $(2)/bin/
$(SED) 's,^\(prefix\|exec_prefix\)=.*,\1=$(STAGING_DIR)/usr,g' -e 
's/INCS //g' \
$(2)/bin/ncursesw6-config
-   ln -sf $(STAGING_DIR)/host/bin/ncursesw6-config 
$(1)/usr/bin/ncursesw6-config
+   ln -rsf $(2)/bin/ncursesw6-config $(1)/usr/bin/ncurses6-config
+   ln -rsf $(2)/bin/ncursesw6-config $(2)/bin/ncurses6-config
+   ln -rsf $(2)/bin/ncursesw6-config $(1)/usr/bin/ncursesw6-config
 endef
 
 define Host/Compile
-- 
2.16.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

2018-09-26 Thread Daniel Golle

On Wed, Sep 26, 2018 at 12:24:19PM +0200, Torsten Duwe wrote:
> Hi all,
> 
> I've been running both above boxes with ADSL Annex-B without problems,
> but now the Telekomedians changed the line to VDSL (Annex-J ?). I tried
> various settings with the xDSL firmware and startup, but keep getting
> at best:
> 
> DOWN [0x300: handshake]
> DOWN [0x380: full_init]
> DOWN [0x1: exception]
> 
> IOW: no "showtime". The box is marketed as "ADSL Annex-B", but the chipset
> is said to be VDSL-capable. OpenWRT lets me configure it so I can think of
> 2 possible reasons:
> 
> 1. wrong xDSL firmware blob or configuration in the official download image
> openwrt-18.06.1-lantiq-xrx200-tplink_tdw8970-squashfs-sysupgrade.bin
> (tried that so we have some common ground for comparison)

The safe path is to use the VDSL-firmware-blob which is shipped in
T-Com's own Speedport router firmware.
See
https://xdarklight.github.io/lantiq-xdsl-firmware-info/

Downloads for 5.6.8.4.1.7-5.6.7.2.1.2
https://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20W%20921V/Firmware_Speedport_W921V_1.39.000.bin

Extracting the source files:
Rename the downloaded file to Firmware_Speedport_W921V_1.21.000.bin and 
copy it to /tmp/
Download the source of the vdsl_fw_install tool from 
https://dev.openwrt.org/browser/trunk/package/kernel/lantiq/ltq-vdsl-fw/src?rev=45275
In the source directory: make && ./w921v_fw_cutter
The result can then be found in /tmp/vr9_dsl_fw_annex_b.bin

You may also use the resurrected ltq-vdsl-fw package available in
master branch / snapshot images which automatizes the process of
downloading the firmware (given that you have internet access somehow)

opkg install ltq-vdsl-vr9-vectoring-fw-installer
vdsl_fw_install.sh



> 
> 2. TP-Link boxes will happily filter anything below 100kHz or so
> http://lists.infradead.org/pipermail/openwrt-devel/2017-July/008238.html
> 
> Any pointers or definite arguments why it cannot work?
> 
>   Torsten
> 
> 
> ___
> 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

[OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

2018-09-26 Thread Torsten Duwe

Hi all,

I've been running both above boxes with ADSL Annex-B without problems,
but now the Telekomedians changed the line to VDSL (Annex-J ?). I tried
various settings with the xDSL firmware and startup, but keep getting
at best:

DOWN [0x300: handshake]
DOWN [0x380: full_init]
DOWN [0x1: exception]

IOW: no "showtime". The box is marketed as "ADSL Annex-B", but the chipset
is said to be VDSL-capable. OpenWRT lets me configure it so I can think of
2 possible reasons:

1. wrong xDSL firmware blob or configuration in the official download image
openwrt-18.06.1-lantiq-xrx200-tplink_tdw8970-squashfs-sysupgrade.bin
(tried that so we have some common ground for comparison)

2. TP-Link boxes will happily filter anything below 100kHz or so
http://lists.infradead.org/pipermail/openwrt-devel/2017-July/008238.html

Any pointers or definite arguments why it cannot work?

Torsten


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

2018-09-26 Thread Stanislaw Gruszka

On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
> On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
> > ...
> > With that update I am fine with squashing the mac80211 updates and
> > pushing them to OpenWrt master.
> > 
> > I checked the removed patches and could not find these two patches in
> > the upstream kernel:
> > *
> > package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
> 
> Yes, this one should be dropped according to Stanislaw Gruszka, we've
> discussed this earlier, but can't spot the thread right now.

Yes, please drop this one and also apply patches from:
https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01
which changes whay how interrupts are handled.

The patches were tested by versious users with positive feedback,
what is documented in:
https://bugzilla.kernel.org/show_bug.cgi?id=82751

Thanks
Stanislaw

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-26 Thread Koen Vandeputte





On 2018-09-23 00:42, Hauke Mehrtens wrote:

Hi,

We talked about plans for the next OpenWrt releases in this mail thread:
http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
This mail is more or less a summary of the conclusions, this is still
open for change especially the dates as this depends on people having
time to do the work.

The next release, lets call it OpenWrt 19.01, should happen in January
2019, we would branch off from master in December 2018. This is the
current plan, but based on past experience it could also happen later.

OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
update the targets to kernel 4.14, support for kernel 4.19 will probably
be added to OpenWrt master soon, but we will not select it as the
default kernel for any target till OpenWrt 19.01 is branched off, to get
more testing on 4.14. The release after 19.01, which should happen in
late summer 2019, should then use kernel 4.19 only.

For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
already got some upgrades after the 18.06 release and could get some
more updates.

We are currently working on updating the wireless drivers and getting
them closer to upstream. The wireless driver in OpenWrt 19.01 will be
taken from kernel 4.19 or later and we want to update them more
frequently in master.

Otherwise we will have the normal changes in all places like with every
release.

LEDE 17.01 will get security updates and occasional bug fixes till
OpenWrt 19.01 was released, but we encourage everyone to upgrade to
18.06 to get full security support already now, as especially some of
the packages are not well maintained any more.

Hauke



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi Hauke,
Hi All,

Some targets are still on (EOL) kernel 3.18 today.
This kernel also still exists by the grace of Greg K-H but could be 
dropped any moment.


I've bumped it a few times (untested) just for the sake of security updates.
But afaict, nobody attempted/requested to update these to a newer kernel 
version.


These targets were also dropped in 18.06 branch.
Maybe we should also consider dropping support for these targets in master?


adm5120
xburst
mcs814x
au1000
ppc40x
adm8668
ppc44x



The other items mentioned in the planning sound logical and sane to me.

Regards,

Koen

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

Re: [OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

[OpenWrt-Devel] [PATCH] uhttpd: fix building without TLS and Lua support

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

[OpenWrt-Devel] [PATCH] ncurses: Add ncurses6 config

Re: [OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

[OpenWrt-Devel] VDSL with TP-link tdw8970 / tdw8980

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

14 matches

Site Navigation

Mail list logo

Footer information