On 1/4/23 18:39, Christian Marangi wrote:
On Sun, Jan 17, 2021 at 06:10:34PM +0100, Hauke Mehrtens wrote:
This patch allows to build most the OpenWrt user space with address and
undefined behavior sanitizer activated by default.
This only works with glibc and gcc 10 and I only tested this on
On Wed, Jan 04, 2023 at 01:50:17PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:28PM -0800, Brian Norris wrote:
> > See also:
> >
> > commit 4d8b42d8a7774070ac0439915f8de1430db9a8e3
> > Author: Tomasz Maciej Nowak
> > Date: Thu Aug 25 20:26:11 2022 +0200
> >
> >
Remove the use of global blob_buf and blob_attr variables to allow
for better thread safety with a ctx per thread on client invoke
and sends.
Add the same variables to within each calling function's scope,
encapsulating the memory usage there.
Fixes a multithreaded use case and has been verified
Hi Christian,
On Wed, Jan 04, 2023 at 01:40:57PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:27PM -0800, Brian Norris wrote:
> > --- a/package/base-files/files/lib/upgrade/common.sh
> > +++ b/package/base-files/files/lib/upgrade/common.sh
> > @@ -127,6 +127,33 @@
Hi Christian, Robert,
On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote:
> On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote:
> >
> > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote:
> > > This fixes device tree registration for 'qcom,lpass-cpu' as used by
> > >
From: Florian Maurer
The WIFI LED already worked for me with the latest openwrt 22.03 version.
Wifi LED did not with an older 22.x version (in gluon - there phy0radio did
nothing but phy0tpt did show activity
the WAN interface has the name "wan" and not "pppoe-wan" on this device
fixes #7757
On Thu, 5 Jan 2023 at 04:02, Brian Norris wrote:
>
> Hi Christian, Robert,
>
> On Wed, Jan 04, 2023 at 02:30:23PM +0100, Robert Marko wrote:
> > On Wed, 4 Jan 2023 at 14:04, Christian Marangi wrote:
> > >
> > > On Mon, Jan 02, 2023 at 03:25:31PM -0800, Brian Norris wrote:
> > > > This fixes
Hi Christian,
On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote:
> > See the patch notes about the stock firmware for TP-Link Onhub and
> > https://chromium-review.googlesource.com/243115.
> >
> > As noted there, the
From: Rafał Miłecki
1. Check for -EPROBE_DEFER
If it occurs we have to return immediately. Trying other properties
could result in another error and ignoring -EPROBE_DEFER which has a
special meaning.
2. Check for read result
Assuming property->read() success can result in NULL pointer
Hi
On 2023-01-06, Christian Marangi wrote:
> On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
> > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
[...]
> > Do I need to create some intermediate/stub package just to express the
> > dependency, or is there some better way?
> >
>
> In
On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann wrote:
> On 2023-01-06, Christian Marangi wrote:
> > On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
> > > On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
> [...]
> > > Do I need to create some intermediate/stub package just to
On Thu, 5 Jan 2023 at 19:47, Brian Norris wrote:
>
> Hi Christian,
>
> On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> > On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote:
> > > See the patch notes about the stock firmware for TP-Link Onhub and
> > >
On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
> In case you are open to giving more helpful tips to a relative
> newcomer to openwrt development:
>
> On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
> wrote:
> > I'll just need to
> > force a 'base64' utility into these images
>
>
In case you are open to giving more helpful tips to a relative
newcomer to openwrt development:
On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
wrote:
> I'll just need to
> force a 'base64' utility into these images
This is turning out to be nontrivial. The only in-tree base64 tool is
a busybox
czw., 5 sty 2023 o 16:41 Janusz Dziedzic napisał(a):
>
> Hello,
>
> Have two mt7915e cards in my banana PI R64 (latest master).
> After do ifconfig wlan1 up - dump.
> While ifconfig wlan2 up works correctly.
>
> [7.093206] mt7915e :01:00.0: assign IRQ: got 148
> [7.098405] mt7915e
Hello,
Have two mt7915e cards in my banana PI R64 (latest master).
After do ifconfig wlan1 up - dump.
While ifconfig wlan2 up works correctly.
[7.093206] mt7915e :01:00.0: assign IRQ: got 148
[7.098405] mt7915e :01:00.0: enabling device ( -> 0002)
[7.104537] mt7915e
On Thu, Jan 5, 2023 at 11:02 AM Robert Marko wrote:
> On Thu, 5 Jan 2023 at 19:47, Brian Norris wrote:
> > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> > > Also on top of that the besto solution for these special case is to
> > > parse the base64 data in userspace a
This is no longer needed now that the kernel is built with a load
address that matches the one hard-coded in the bootloader.
Signed-off-by: Jan Hoffmann
---
target/linux/realtek/image/Makefile | 14 --
target/linux/realtek/image/common.mk | 2 --
2 files changed, 16 deletions(-)
18 matches
Mail list logo
