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 ba
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
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
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 ?!?
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 ++
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 --gi
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
i
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 unveri
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 impl
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-
> Fro
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
exp
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 s
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
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 responsibl
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
> >
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 pu
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 a
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-
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 settin
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 Q
> 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
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
22 matches
Mail list logo
