Hi all
Could someone help review the code and leave valuable comments?
This is the first time I have submit a patch to openwrt, thank you very
much.
https://patchwork.ozlabs.org/project/openwrt/patch/2f18ab52-39b5-3546-45c1-10e5357b4...@163.com/
Best Regards
Xu Junnan
__
This patch has been upstream since GCC 10.
Dragan Mladjenovic (2):
Emit .note.GNU-stack for soft-float linux targets.
Emit .note.GNU-stack for hard-float linux targets.
Link: https://gcc.gnu.org/g:a3c1e1f2ff88
Link: https://gcc.gnu.org/g:54b3d52c3cca
Add backport patch to define TARGE
This will make upgrade to v11.3.0 easier and follows upstream more
closely.
Signed-off-by: Ilya Lipnitskiy
---
...leanup-range-of-address-calculations.patch | 160 --
...ld_using_range-range_of_address-PR10.patch | 114 +
2 files changed, 114 insertions(+), 160 deleti
Run make toolchain/gcc/minimal/refresh (with glibc, with musl
toolchain/gcc/{initial,final}/refresh don't work)
Fixes: ab241e0937c9 ("toolchain/gcc: fix build on MacOS arm64")
Signed-off-by: Ilya Lipnitskiy
---
.../patches/11.2.0/970-macos_arm64-building-fix.patch | 10 +++---
1 file chang
Use upstream patches instead of custom OpenWrt ones. Refresh patches.
Ilya Lipnitskiy (3):
toolchain/gcc: remove upstreamed patch, add backport
toolchain/gcc: replace revert with upstream fix
toolchain/gcc: refresh gcc-11.2.0 patch
...leanup-range-of-address-calculations.patch | 160 --
Add decoding of lte_system_info_v2.cid, in --get-system-info, and
intrafrequency_lte_info_v2.global_cell_id, in --get-cell-location-info,
to enodeb_id and cell_id.
h´xyy -> enodeb_id = h´x, cell_id = h´yy
Add decoding of wcdma_system_info_v2.cid, in --get-system-info, to
rnc_id and cell_id
Never mind - they appear to be more sporadic, and perhaps also require a
network restart.
Time_Zone appears in Probe Response frames only.
On 2021-12-07 04:06, Paul D wrote:
I tried enabling the wifi settings for 2.4 and 5Ghz.:
== time_advertisement ==
Result: OK. Time appears in beacon
Sorry - seems like it's already there :)
On 2021-12-07 16:29, Paul D wrote:
Could this also be picked to 21.02 branch, please?
https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b
___
openwrt-devel mailing list
op
Could this also be picked to 21.02 branch, please?
https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-dev
Hi,
> I have now taken a look at your suggestion.
> Unfortunately, I found that not all network interfaces have set the DEVTYPE
> attribute set in their uevent file. I have not yet found any information
> who sets this value. Does this do the driver or the subsystem?
afair it is set by the respon
From: Rafał Miłecki
It's needed for extracting binary images.
Cc: Yousong Zhou
Signed-off-by: Rafał Miłecki
---
...t-for-printing-raw-bytes-with-fdtget.patch | 78 +++
1 file changed, 78 insertions(+)
create mode 100644
package/utils/dtc/patches/0001-Support-b-format-for-pri
From: Rafał Miłecki
fdt* utils are needed by targets that use U-Boot FIT images for
sysupgrade. It includes all recent BCM4908 SoC routers as Broadcom
switched from CFE to U-Boot.
fdtget is required for extracting images (bootfs & rootfs) from
Broadcom's ITB. Extracted images can be then flashed
Hello Jo
imho these types are not that useful in practice (e.g. tap devices etc.
are
all reported as "ethernet". Maybe expose /sys/class/net/$devname/uevent
DEVTYP= instead.
I have now taken a look at your suggestion.
Unfortunately, I found that not all network interfaces have set the
DEVTYP
13 matches
Mail list logo
