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 ---
I’m interested in adding support f
Hi,
> -Original Message-
> From: Sandeep Sheriker M [mailto:sandeep.sheri...@microchip.com]
> Sent: Samstag, 22. August 2020 21:56
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-devel][ at91 patches 1/4] target/linux/at91: bump linux
> version to 5.4
Can you push this patchset
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 ---
Signed-off-by: Sandeep Sheriker M
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 ---
changing dtb file path since the d
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 ---
bump version to linux4sam-2020.04
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 ---
Signed-off-by: Sandeep Sheriker M
For many target we have added CONFIG_WATCHDOG_CORE=y to the target
config due to the following error:
Package kmod-hwmon-sch5627 is missing dependencies for the following
libraries:
watchdog.ko
However, actually the proper way appears to be setting the
dependency for the kmod-hwmon-sch5627 pac
Removed patches have been applied upstream.
Signed-off-by: Adrian Schmutzler
---
.../rb532/patches-5.4/001-cmdline_hack.patch | 4 +-
.../004-rb532-fix-partition-info.patch| 2 +-
...overflow-and-tx-underflow-interrupts.patch | 156 --
...actor-rx-descriptor-flags-pr
** I do not own this device, please test! **
This updates rb532 from kernel 4.14 to 5.4. Based on the code this
was actually quite easy, let's see whether it works on the devices.
Adrian Schmutzler (6):
rb532: copy files from 4.14 to 5.4
rb532: refresh patches for kernel 5.4
rb532: refresh
Just copy, do not change anything yet.
Signed-off-by: Adrian Schmutzler
---
target/linux/rb532/config-5.4 | 181 ++
.../rb532/patches-5.4/001-cmdline_hack.patch | 20 ++
.../004-rb532-fix-partition-info.patch| 17 ++
...overflow-and-tx-underflow-interru
There is only one device, so using a testing kernel does not make
much sense.
Signed-off-by: Adrian Schmutzler
---
target/linux/rb532/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile
index 43ec4cc491..390f1baac
Use "make kernel_oldconfig" and add back the renamed NAND symbols.
Add CONFIG_WATCHDOG_CORE=y to prevent the following error:
Package kmod-hwmon-sch5627 is missing dependencies for the following libraries:
watchdog.ko
Signed-off-by: Adrian Schmutzler
---
target/linux/rb532/config-5.4 | 107 +++
This applies the vendor_model scheme used in most targets to rb532.
Also update the board name based on how a matching compatible would
look like.
Signed-off-by: Adrian Schmutzler
---
target/linux/rb532/base-files/lib/preinit/01_sysinfo | 2 +-
target/linux/rb532/image/Makefile
So far, the sysupgrade-* folder used during upgrade in rb532 was
hardcoded to contain the board name. Therefore, changing board name
or BOARD_NAME variable in image/Makefile might have broken upgrade.
Improve this by adding a step to determine the folder name via
a wildcard, as it is done for gene
On 8/22/20 1:45 AM, Paul Spooren wrote:
>
> On 21.08.20 06:47, Matthias Schiffer wrote:
>> Did you have a look at the zstd patches I sent a while ago? zstd is
>> superior to xz in most cases - the only reason I didn't merge the patches
>> yet was that all of our phase2 buildbots would need to have
15 matches
Mail list logo