Hello everyone,
I have made the bug reproducible by adding sleep(2) between the calls to
nl80211_create_iface and linux_br_add_if in src/drivers/driver_nl80211.c
of hostapd.
In that way, I was able to observe (without the confusing random
effects) that commit 4d0c2ad3fd268388b97af0582baa8a89
Most boards supported by this target have a dedicated GPIO line
connected to SoC's /RESET to allow full clean reliable reboot.
Use regular kernel notifier methods for default restart routines to
allow higher-priority handlers (such as gpio-restart) to override it.
Signed-off-by: Paul Fertser
---
Roughly
Write this up into an FAQ/howto on openwrt.org (this is, after all, the
OWRT way)
Link to it in a
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks
which looks f
On 10/2/21 2:41 PM, Paul D wrote:
Overwrite or override? Seems like override - distinction here is
important...
Hi,
I can change this to override, I am not a native speaker.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
htt
Hi Tim,
On 04.10.2021 00:22, Tim Harvey wrote:
Piotr,
How is your progress regarding submitting patches to OpenWrt to split
the imx target into multiple arch related subtargets (like cortexa7,
cortexa9)?
I'm planning to clean it up and send patches this week.
I finally got final revision of t
On Tue, Oct 5, 2021 at 8:42 AM Piotr Dymacz wrote:
>
> Hi Tim,
>
> On 04.10.2021 00:22, Tim Harvey wrote:
> > Piotr,
> >
> > How is your progress regarding submitting patches to OpenWrt to split
> > the imx target into multiple arch related subtargets (like cortexa7,
> > cortexa9)?
>
> I'm plannin
Hi Tim-san, Piotr-san
I have an on OpenWrt based buildroot with an i.MX8M mini board.
Since I used linux-imx, uboot-imx. it is not a code that can be merged into the
original master.
It running for Japanese communication robot.
start porting to i.MX8M on openwrt master?
I want to help as much a
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 ---
Use the GNUInstallDirs include to
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul D
> Sent: Dienstag, 5. Oktober 2021 16:24
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: Suggestion: Explicitly warn to not use GitHub web UI for
patches
>
> Roughly
>
> W
> On Oct 5, 2021, at 10:24 AM, Paul D wrote:
>
> Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT
> way)
Yes, it's always more powerful (and useful) to tell people what TO do, instead
of what NOT to do.
I contribute very occasionally, and by trial and error, I *
MikroTik released a 3rd revision of that board, virtually identical
to the previous one as far as software is concerned.
Signed-off-by: Thibaut VARÈNE
---
In case anyone still cares about ar71xx on 19.07, this one-liner keeps
it working with MikroTik's latest minor revision of an otherwise
alread
In preparations to add support for more similar boards the common part
is split into a DTSI.
The model that's currently supported is known to be revision F1 so mark
it accordingly and provide appropriate compatible string for sysupgrade
to work.
Signed-off-by: Paul Fertser
---
...0p.dts => rtl8
I only have D-Link DGS-1210-10P R1 for testing but other devices should be very
similar judging by the photos. Would be nice to share support for all the
features available rather than get just R1 fully working.
Paul Fertser (5):
realtek: split DGS-1210-10P DTS
realtek: add all LEDs, buttons a
These GPIO numbers were obtained by physically inspecting a DGS-1210-10P
R1 board but should be common for other devices based on same PCB
layout.
Signed-off-by: Paul Fertser
---
.../dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi | 88 +--
1 file changed, 83 insertions(+), 5 deletions
Signed-off-by: Paul Fertser
---
.../rtl8380_d-link_dgs-1210-10-f1.dts | 8 +++
.../rtl8380_d-link_dgs-1210-10-f1.dtsi| 61 +++
.../rtl8380_d-link_dgs-1210-10p-f1.dts| 60 +-
target/linux/realtek/image/Makefile | 10 ++-
4 files ch
According to photos and specs for Trendnet TPE-082WS V1.2R it should be
the same as D-Link DGS-1210-10P R1 but with more powerful PSU (90 W) so
the PoE budget is specified as 75 W.
Signed-off-by: Paul Fertser
---
.../realtek/base-files/etc/board.d/02_network | 3 +
.../rtl8380_trendnet_tpe-082w
This is an 8 port 1000BASE-T + 2 1000BASE-X SFP gigabit switch with PoE+
support, 65 W budget (using 54 V * 1.574 A = 85 W power supply).
In order to manipulate the PoE+ one needs the realtek-poe package [0].
Specifications
--
* SoC: Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash:
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Luis Araneda
> Sent: Sonntag, 3. Oktober 2021 17:35
> To: openwrt-devel@lists.openwrt.org
> Cc: Luis Araneda
> Subject: [PATCH 4/4] zynq: switch to kernel 5.10
>
> Use kernel 5.
Hi Paul,
On Tue, 2021-10-05 at 16:35 +0300, Paul Fertser wrote:
> Most boards supported by this target have a dedicated GPIO line
> connected to SoC's /RESET to allow full clean reliable reboot.
>
> Use regular kernel notifier methods for default restart routines to
> allow higher-priority handle
Hi,
On 05/10/2021 22:59, Sander Vanheule wrote:
One alternative could be to create some extra driver(s) in OpenWrt already, to
get rid of
setup.c (and prom.c at some later point) and work towards the upstream base for
RTL838x/RTL839x. Anyone else with an opinion on this?
That's a good idea. Bu
Hi all,
based on my overview[1] things are moving forward and being tested,
great! What about the targets that did not see any 5.10 ambitions yet?
Specifically:
- arc770
- archs38
- ath25
- bcm47xx
- bcm4908
- ipq807x
- layerscape
- pistachio
- uml
Is anyone aware of people working on those
On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote:
>
> Hi all,
>
> based on my overview[1] things are moving forward and being tested,
> great! What about the targets that did not see any 5.10 ambitions yet?
> Specifically:
>
> - arc770
> - archs38
> - ath25
> - bcm47xx
> - bcm4908
> - ipq807x
I ca
> On 5. Oct 2021, at 12:33, Robert Marko wrote:
>
> On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote:
>>
>> Hi all,
>>
>> based on my overview[1] things are moving forward and being tested,
>> great! What about the targets that did not see any 5.10 ambitions yet?
>> Specifically:
>>
>> - ar
On 30.09.2021 03:34, Rich Brown wrote:
My desire would be to name our next release "22.03", with a target release date in March
2022. And we should name the following release "22.09" with a release date in
September. And so on - every six months (or whatever interval we believe we can susta
24 matches
Mail list logo