> > during support of the Ubiquiti Nanostation Loco XW, we encountered the
> > following
> > blocks in ar71xx which are only present for devices not migrated to ath79
> > yet:
> >
> > static struct mdio_board_info ubnt_loco_m_xw_mdio_info[] = {
> > {
> > [...]
> >
DESCRIPTION
Possibly exploitable vulnerability exists in the libubox library of OpenWrt,
specifically in the parts related to JSON conversion of tagged binary data,
so called blobs. An attacker could possibly exploit this behavior by
providing specially crafted binary blob or JSON which would the
DESCRIPTION
A bug in the package list parse logic of OpenWrt's opkg fork caused the
package manager to ignore SHA-256 checksums embedded in the signed repository
index, effectively bypassing integrity checking of downloaded .ipk artifacts.
The bug has been introduced with commit https://git.openw
Hi,
The OpenWrt Community is proud to announce the first service release of
the stable OpenWrt 19.07 series. OpenWrt 19.07.1 incorporates important
security updates for base packages, fixes for 5GHz performance issues and flow
offloading memory leaks as well as new versions of the Linux kernel and
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 ---
Hi,
I tested snapshot build from
Hi,
The OpenWrt Community is proud to announce the seventh service release of
the stable OpenWrt 18.06 series. OpenWrt 18.06.7 incorporates important
security updates for base packages, new versions of the Linux kernel and fixes
for various devices.
Selected highlights of this service releas
> Ok, will send this as part of v2.
I will mark 3/8 as rejected.
I'd merge 1, 2 and 4 tomorrow or on Sunday, so if you want to wait for
additional input on 5-8 you can also only send the former as smaller v2
patchset.
Best
Adrian
>
> Regards
>
> >
> >>
> >>> DEVICE_DTS_DIR and DTS_DIR migh
W dniu 31.01.2020 o 19:47, Adrian Schmutzler pisze:
> Hi,
>
>> -Original Message-
>> From: Tomasz Maciej Nowak [mailto:tome...@o2.pl]
>> Sent: Freitag, 31. Januar 2020 19:39
>> To: Adrian Schmutzler ; openwrt-
>> de...@lists.openwrt.org
>> Subject: Re: [OpenWrt-Devel] [PATCH 4/8] mvebu: im
On 2020-01-29 17:22, Petr Štetiar wrote:
> Rosen Penev [2020-01-25 15:04:03]:
>
> Hi Bjørn and Rosen,
>
>> On Thu, Jan 23, 2020 at 12:25 AM Bjørn Mork wrote:
>> > >
>> > > - if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0x) == 0x0101) {
>> > > - /* (GE1, Force 1000M/FD, FC ON, MA
Hi,
> -Original Message-
> From: Tomasz Maciej Nowak [mailto:tome...@o2.pl]
> Sent: Freitag, 31. Januar 2020 19:39
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 4/8] mvebu: image: keep global DTS_DIR
> intact
>
> W dniu 31.01.2020 o 17:
W dniu 31.01.2020 o 19:33, Adrian Schmutzler pisze:
> Hi,
>
>> I saw similar behavior when variables were set but not added to DEVICE_VARS.
>> From the tests I've done before sending, the produced images looked fine, but
>> I'll re-test that to make sure.
>
> When variables are set, but are _not_
W dniu 31.01.2020 o 17:02, Adrian Schmutzler pisze:
> Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> Behalf Of Tomasz Maciej Nowak
>> Sent: Freitag, 31. Januar 2020 16:46
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [OpenWrt-
> When variables are _not_ set, but are added to DEVICE_VARS, the variables will
> have the last value set to any device before (i.e. the last device setting
it). Note
> that Device/Default counts like an include to the current device there.
Still not precise enough here:
When variables are _not_
Hi,
> I saw similar behavior when variables were set but not added to DEVICE_VARS.
> From the tests I've done before sending, the produced images looked fine, but
> I'll re-test that to make sure.
When variables are set, but are _not_ added to DEVICE_VARS, the variables will
have _one_ single va
Hi Adrian.
W dniu 31.01.2020 o 16:56, Adrian Schmutzler pisze:
> Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> Behalf Of Tomasz Maciej Nowak
>> Sent: Freitag, 31. Januar 2020 16:46
>> To: openwrt-devel@lists.openwrt.org
>> Subjec
Hi Scott.
W dniu 31.01.2020 o 17:12, ttocsr pisze:
> Kernel 4.19 doesn't have armada-3720-uDPU.dts. Won't we need to patch
> openwrt because of this?
No, that won't be a problem. Check the ininclude/image.mk line 523, this
assures that every DEVICE_DTS will be compiled to dtb. The only thing th
Hello Adrian,
On 1/31/20 5:45 PM, Adrian Schmutzler wrote:
> Hi,
>
> during support of the Ubiquiti Nanostation Loco XW, we encountered the
> following
> blocks in ar71xx which are only present for devices not migrated to ath79 yet:
>
> static struct mdio_board_info ubnt_loco_m_xw_mdio_info[] =
Hi,
during support of the Ubiquiti Nanostation Loco XW, we encountered the following
blocks in ar71xx which are only present for devices not migrated to ath79 yet:
static struct mdio_board_info ubnt_loco_m_xw_mdio_info[] = {
{
[...]
.platform_data = &ubnt_l
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Tomasz Maciej Nowak
> Sent: Freitag, 31. Januar 2020 16:46
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 1/8] mvebu: image: sort devices alphabetically
>
> S
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Tomasz Maciej Nowak
> Sent: Freitag, 31. Januar 2020 16:46
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 2/8] mvebu: image: align subtargets makefile
> names
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Tomasz Maciej Nowak
> Sent: Freitag, 31. Januar 2020 16:46
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 4/8] mvebu: image: keep global DTS_DIR intact
>
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Tomasz Maciej Nowak
> Sent: Freitag, 31. Januar 2020 16:46
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 3/8] mvebu: image: drop empty variables from
> d
Bjørn Mork [2020-01-30 10:54:17]:
> Are you sure the revision says anything about which SoC this is?
Nope :-) It's based only on source code observation.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.
Rosen Penev [2020-01-29 20:39:57]:
Hi,
> On kernel.org, the ralink_soc variable is only used in arch/mips ,
> mainly under the ralink subdirectory.
correct, but your proposed patch can't be accepted as it is. You need to
handle only 0x0101 and 0x0103 cases, thus putting content of the register
The BUILD_VARIANT might differ from UBOOT_CONFIG, so point to a file we
are actually changing. Being here let's call 'Build/Configure/U-Boot'
definition, instead of definig the same command. This'll be more future
proof, if U-Boot configuration procedure will change.
Signed-off-by: Tomasz Maciej N
If device recipe has specified DEVICE_DTS variable, the dtb is built
anyway by OpenWrt buildroot image rules. Drop the patch and adjust the
location of compiled dtb.
Cc: Scott Roberts
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/cortexa53.mk | 2 +-
.../patc
Tar has ability to change current dir, so use that instead additional
command invocation. Also being here, change tar arguments to make final
archive reproducible.
Cc: Scott Roberts
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/Makefile | 12 +---
1 file changed, 9 ins
This device receipe selects bunch of packages, which some are re-defined,
unnecessary or irrelevant. Clean them up, so only basic functionality
persist.
Cc: Scott Roberts
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/cortexa53.mk | 4 +---
1 file changed, 1 insertion(+), 3 del
Don't rewrite global DTS_DIR, instead, use proper variable for
specifying devices dts directory.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mvebu/image/Makefile
b/target/linux/mvebu/im
Most of changes are purely cosmetic, with bigger chages to uDPU. This
will be the last of this type of clen-up from me.
Tomasz Maciej Nowak (8):
mvebu: image: sort devices alphabetically
mvebu: image: align subtargets makefile names
mvebu: image: drop empty variables from default profile
m
These variables are already initialized within DEVICE_VARS. Just move
DEVICE_VARS to make sure they are set before default profile.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/target/linux/mvebu/i
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/cortex-a72.mk | 30 ++--
target/linux/mvebu/image/cortex-a9.mk | 198 -
2 files changed, 114 insertions(+), 114 deletions(-)
diff --git a/target/linux/mvebu/image/cortex-a72.mk
b/target/linux/mvebu/image/c
Align subtargets makefiles names to actual subtargets.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/Makefile| 6 +++---
target/linux/mvebu/image/{cortex-a53.mk => cortexa53.mk} | 0
target/linux/mvebu/image/{cortex-a72.mk => cortexa72.mk} | 0
target/li
For devices without a dedicated 'diag' LED, we use sometimes one of
other LEDs for indicating at least 'boot', 'failsafe' and 'upgrade'
stages. In some cases, at the same time these LEDs have defined default
triggers in DTS using 'linux,default-trigger' property. Current 'diag'
setup removes the tr
Signed-off-by: Kevin Darbyshire-Bryant
---
Base error on new 'mustjail' attribute
service/instance.c | 32 ++--
service/instance.h | 1 +
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/service/instance.c b/service/instance.c
index e872ba0..d430d6e 1
This adds support for the BSS load information element. With this patch,
the BSS load information is visible when using the CLI as well as when
accessing scan results using the LUA binding.
Signed-off-by: David Bauer
---
include/iwinfo.h | 6 ++
include/iwinfo/utils.h | 2 ++
iwinfo_
On Fri, 31 Jan 2020 at 09:06, Rui Salvaterra wrote:
>
> Like I wrote in the forum, I don't have (yet) AR5008 hardware to test.
And I just ordered an AR5BXB72* for testing purposes. I can configure it as AP
on my Turris Omnia.
* https://www.aliexpress.com/item/32356022951.html
__
Hi, Felix,
On Fri, 31 Jan 2020 at 08:12, Felix Fietkau wrote:
> For at least AR5008 and AR9002, but probably also for AR9003 I would
> like to keep the behavior of collecting entropy only once at driver
> initialization.
Well, you could have told me this before I started working on it, but
I gue
Kevin Darbyshire-Bryant [2020-01-30 17:37:23]:
Hi Kevin,
thanks for looking into that.
> Signed-off-by: Kevin Darbyshire-Bryant
> ---
> service/instance.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/service/instance.c b/service/instance.c
> index e872ba0..b78a6
On 2020-01-30 21:03, Rui Salvaterra wrote:
> The mainline ath9k driver is able to provide a hardware random number
> generator by collecting radio noise from the PHY ADC (using a kthread
> to fill up the entropy pool as needed). Nevertheless, this feature has
> only been implemented for the more re
40 matches
Mail list logo
