Re: [LEDE-DEV] [PATCH] ag71xx: Reorder ring structs for lower cache trashing.
On Thu, Feb 1, 2018 at 9:23 AM, Lucian Cristian wrote:
> On 30.01.2018 18:14, Rosen Penev wrote:
>>
>> Based on Qualcomm's upstream code. Reordered a bit different.
>>
>> iperf3 speed goes from ~279mbps to ~320mbps.
>>
>> Signed-off-by: Rosen Penev
>> ---
>> .../files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h | 13
>> -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git
>> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
>> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
>> index a712812..d181240 100644
>> ---
>> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
>> +++
>> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
>> @@ -106,13 +106,16 @@ struct ag71xx_buf {
>> };
>> struct ag71xx_ring {
>> - struct ag71xx_buf *buf;
>> - u8 *descs_cpu;
>> - dma_addr_t descs_dma;
>> - u16 desc_split;
>> - u16 order;
>> + /* "Hot" fields in the data path. */
>> unsigned intcurr;
>> unsigned intdirty;
>> +
>> + /* "Cold" fields - not used in the data path. */
>> + struct ag71xx_buf *buf;
>> + u16 order;
>> + u16 desc_split;
>> + dma_addr_t descs_dma;
>> + u8 *descs_cpu;
>> };
>> struct ag71xx_mdio {
>
Seems this patch got dropped from patchwork for some reason.
>
> I can confirm that this one gives a nice performance boost !
>
>
> Regards
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On 09.02.2018 23:48, Hauke Mehrtens wrote:
On 02/09/2018 12:27 AM, Lucian Cristian wrote:
On 21.01.2018 19:53, Hauke Mehrtens wrote:
This add support for kernel 4.14 to the mvebu target. My main reason to
add kernel 4.14 support is to make it easier to also add support for the
Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board.
I do not have any of the currently supported boards so I can not runtime
test this myself, Lucian Cristian already tested an older version of
these patches on one of his boards.
My current working tree for this target can be found here:
https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14
This tree also contains the code needed for the ESPRESSObin, but we
still have some problems with the image creation, the bootloader boots
by default the kernel + dtb from a ext4 file system on a SD card and
also uses this partition as root file system.
Tomasz Maciej Nowak is working on the image generation for the
ESPRESSObin board.
I am waiting for positive and negative feedback on these patches, if you
run into a problem which you do not have with kernel 4.9 please report
this.
changes in:
v2:
* refresh on current generic kernel 4.14 integration
* create ubifs fs format version 4 also with kernel 4.14, this should
fix sysupgrade (downgrade) from kernel 4.14 to 4.9
* rename the wireless driver path when upgrading
Hauke Mehrtens (5):
kernel: ubifs: create use file system format 4 by default
mvebu: move files to files-4.9 and files-4.4 folder
mvebu: copy config and patches from 4.9 to 4.14
mvebu: Make kernel 4.14 patches apply
mvebu: migrate uci config to new PCIe path
target/linux/generic/config-4.14 | 1 +
...ption-to-create-UBI-FS-version-4-on-empty.patch | 63 ++
.../base-files/etc/uci-defaults/05-migrate-wifi | 23 +
target/linux/mvebu/config-4.14 | 486 ++
.../arch/arm/boot/dts/armada-385-linksys-rango.dts | 0
.../arm/boot/dts/armada-385-linksys-shelby.dts | 0
.../arch/arm/boot/dts/armada-385-linksys-rango.dts | 0
.../arm/boot/dts/armada-385-linksys-shelby.dts | 0
.../mvebu/patches-4.14/002-add_powertables.patch | 770
.../mvebu/patches-4.14/003-add_switch_nodes.patch | 40 +
.../004-add_sata_disk_activity_trigger.patch | 39 +
.../mvebu/patches-4.14/100-find_active_root.patch | 60 ++
.../mvebu/patches-4.14/102-revert_i2c_delay.patch | 15 +
.../103-remove-nand-driver-bug.patch | 0
.../104-linksys_mamba_disable_keep_config.patch | 10 +
.../110-pxa3xxx_revert_irq_thread.patch | 69 ++
.../205-armada-385-rd-mtd-partitions.patch | 0
.../206-ARM-mvebu-385-ap-Add-partitions.patch | 0
.../patches-4.14/210-clearfog_switch_node.patch | 21 +
.../300-mvneta-tx-queue-workaround.patch | 35 +
...bu-indicate-failure-to-enter-deeper-sleep.patch | 40 +
.../401-pci-mvebu-time-out-reset-on-link-up.patch | 60 ++
.../402-sfp-display-SFP-module-information.patch | 290 ++
.../403-net-mvneta-convert-to-phylink.patch | 979
+
.../404-net-mvneta-hack-fix-phy_interface.patch | 28 +
...disable-MVNETA_CAUSE_PSC_SYNC_CHANGE-inte.patch | 56 ++
...-mvneta-add-module-EEPROM-reading-support.patch | 44 +
...y-fixed-phy-remove-fixed_phy_update_state.patch | 80 ++
...dule-eeprom-ethtool-access-into-netdev-co.patch | 181
...409-sfp-use-netdev-sfp_bus-for-start-stop.patch | 34 +
...-allow-marvell-10G-phy-support-to-use-SFP.patch | 130 +++
.../patches-4.14/411-sfp-add-sfp-compatible.patch | 24 +
...-armada388-clearfog-emmc-on-clearfog-base.patch | 87 ++
...ada388-clearfog-increase-speed-of-i2c0-to.patch | 42 +
...armada388-clearfog-add-SFP-module-support.patch | 81 ++
...dts-armada388-clearfog-document-MPP-usage.patch | 124 +++
36 files changed, 3912 insertions(+)
create mode 100644
target/linux/generic/pending-4.14/553-ubifs-Add-option-to-create-UBI-FS-version-4-on-empty.patch
create mode 100644
target/linux/mvebu/base-files/etc/uci-defaults/05-migrate-wifi
create mode 100644 target/linux/mvebu/config-4.14
copy target/linux/mvebu/{files =>
files-4.4}/arch/arm/boot/dts/armada-385-linksys-rango.dts (100%)
copy target/linux/mvebu/{files =>
files-4.4}/arch/arm/boot/dts/armada-385-linksys-shelby.dts (100%)
rename target/linux/mvebu/{files =>
files-4.9}/arch/arm/boot/dts/armada-385-linksys-rango.dts (100%)
rename target/linux/mvebu/{files =>
files-4.9}/arch/arm/boot/dts/armada-385-linksys-shelby.dts (100%)
create mode 100644
target/linux/mvebu/patches-4.14/002-add_powertables.patch
create mode 100644
target/linux/mvebu/patches-4.14/003-add_switch_nodes.patch
create mode 100644
target/linux/mvebu/patches-4.14/004-add_sata_disk_activity_trigger.patch
create mode 100644
target/linux/mvebu/patches-
[LEDE-DEV] [PATCH] mediatek: activate fpu feature flag
The arm CPUs uses in the supported Mediatket SoCs have a FPU accordingly to the datasheet, activate it also. The CPU subtype "neon-vfpv4" is selected, but the toolcahin generated for this SoC will still be compiled with soft float and not with the hard float ABI as we haven't the fpu feature flag set. If this toolchain is reused by other targets this will even affect other targets. Signed-off-by: Hauke Mehrtens --- target/linux/mediatek/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/Makefile b/target/linux/mediatek/Makefile index 4ebac09a6e..6824111d85 100644 --- a/target/linux/mediatek/Makefile +++ b/target/linux/mediatek/Makefile @@ -6,7 +6,7 @@ ARCH:=arm BOARD:=mediatek BOARDNAME:=MediaTek Ralink ARM SUBTARGETS:=32 -FEATURES:=squashfs nand ubifs +FEATURES:=squashfs nand ubifs fpu MAINTAINER:=John Crispin KERNEL_PATCHVER:=4.9 -- 2.11.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: rename CONFIG_TRACE_ENUM_MAP_FILE to CONFIG_TRACE_EVAL_MAP_FILE
On Fri, Feb 9, 2018 at 3:44 PM, Hauke Mehrtens wrote:
> This config option was renamed in upstream Linux commit 681bec0367
> ("tracing: Rename update the enum_map file")
>
> Reported-by: Rosen Penev
> Signed-off-by: Hauke Mehrtens
> ---
> target/linux/generic/config-4.14 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/generic/config-4.14
> b/target/linux/generic/config-4.14
> index 39c37744c9..3b7985a9ed 100644
> --- a/target/linux/generic/config-4.14
> +++ b/target/linux/generic/config-4.14
> @@ -4943,7 +4943,7 @@ CONFIG_TMPFS_XATTR=y
> # CONFIG_TRACER_SNAPSHOT is not set
> # CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
> # CONFIG_TRACE_BRANCH_PROFILING is not set
> -# CONFIG_TRACE_ENUM_MAP_FILE is not set
> +# CONFIG_TRACE_EVAL_MAP_FILE is not set
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> # CONFIG_TRACE_SINK is not set
> # CONFIG_TRACING_EVENTS_GPIO is not set
ACK
> --
> 2.11.0
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] kernel: rename CONFIG_TRACE_ENUM_MAP_FILE to CONFIG_TRACE_EVAL_MAP_FILE
This config option was renamed in upstream Linux commit 681bec0367
("tracing: Rename update the enum_map file")
Reported-by: Rosen Penev
Signed-off-by: Hauke Mehrtens
---
target/linux/generic/config-4.14 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/generic/config-4.14 b/target/linux/generic/config-4.14
index 39c37744c9..3b7985a9ed 100644
--- a/target/linux/generic/config-4.14
+++ b/target/linux/generic/config-4.14
@@ -4943,7 +4943,7 @@ CONFIG_TMPFS_XATTR=y
# CONFIG_TRACER_SNAPSHOT is not set
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
# CONFIG_TRACE_BRANCH_PROFILING is not set
-# CONFIG_TRACE_ENUM_MAP_FILE is not set
+# CONFIG_TRACE_EVAL_MAP_FILE is not set
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_TRACE_SINK is not set
# CONFIG_TRACING_EVENTS_GPIO is not set
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On 02/09/2018 11:57 PM, Rosen Penev wrote: > On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote: >> On 01/21/2018 06:53 PM, Hauke Mehrtens wrote: >>> This add support for kernel 4.14 to the mvebu target. My main reason to >>> add kernel 4.14 support is to make it easier to also add support for the >>> Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board. >>> >>> I do not have any of the currently supported boards so I can not runtime >>> test this myself, Lucian Cristian already tested an older version of >>> these patches on one of his boards. >>> >>> My current working tree for this target can be found here: >>> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 >>> This tree also contains the code needed for the ESPRESSObin, but we >>> still have some problems with the image creation, the bootloader boots >>> by default the kernel + dtb from a ext4 file system on a SD card and >>> also uses this partition as root file system. >>> Tomasz Maciej Nowak is working on the image generation for the >>> ESPRESSObin board. >>> >>> I am waiting for positive and negative feedback on these patches, if you >>> run into a problem which you do not have with kernel 4.9 please report >>> this. >>> >>> changes in: >>> v2: >>> * refresh on current generic kernel 4.14 integration >>> * create ubifs fs format version 4 also with kernel 4.14, this should >>>fix sysupgrade (downgrade) from kernel 4.14 to 4.9 >>> * rename the wireless driver path when upgrading >>> >>> >>> Hauke Mehrtens (5): >>> kernel: ubifs: create use file system format 4 by default >>> mvebu: move files to files-4.9 and files-4.4 folder >>> mvebu: copy config and patches from 4.9 to 4.14 >>> mvebu: Make kernel 4.14 patches apply >>> mvebu: migrate uci config to new PCIe path >>> >> >> I haven't heard of any problems, expected that one patch does not apply >> any more with kernel 4.14.18, which is fixed now. >> >> I will merge this on Sunday if I do not get any negative feedback. >> >> You can find my tree here: >> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 > i just pulled your staging tree and decided to compile firmware for my > Turris Omnia. > > CONFIG_TRACE_EVAL_MAP_FILE makes the kernel fail. It needs to be > defined somewhere. Can you please send me the output of ./scripts/diffconfig.sh please. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On Fri, Feb 9, 2018 at 2:57 PM, Rosen Penev wrote: > On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote: >> On 01/21/2018 06:53 PM, Hauke Mehrtens wrote: >>> This add support for kernel 4.14 to the mvebu target. My main reason to >>> add kernel 4.14 support is to make it easier to also add support for the >>> Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board. >>> >>> I do not have any of the currently supported boards so I can not runtime >>> test this myself, Lucian Cristian already tested an older version of >>> these patches on one of his boards. >>> >>> My current working tree for this target can be found here: >>> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 >>> This tree also contains the code needed for the ESPRESSObin, but we >>> still have some problems with the image creation, the bootloader boots >>> by default the kernel + dtb from a ext4 file system on a SD card and >>> also uses this partition as root file system. >>> Tomasz Maciej Nowak is working on the image generation for the >>> ESPRESSObin board. >>> >>> I am waiting for positive and negative feedback on these patches, if you >>> run into a problem which you do not have with kernel 4.9 please report >>> this. >>> >>> changes in: >>> v2: >>> * refresh on current generic kernel 4.14 integration >>> * create ubifs fs format version 4 also with kernel 4.14, this should >>>fix sysupgrade (downgrade) from kernel 4.14 to 4.9 >>> * rename the wireless driver path when upgrading >>> >>> >>> Hauke Mehrtens (5): >>> kernel: ubifs: create use file system format 4 by default >>> mvebu: move files to files-4.9 and files-4.4 folder >>> mvebu: copy config and patches from 4.9 to 4.14 >>> mvebu: Make kernel 4.14 patches apply >>> mvebu: migrate uci config to new PCIe path >>> >> >> I haven't heard of any problems, expected that one patch does not apply >> any more with kernel 4.14.18, which is fixed now. >> >> I will merge this on Sunday if I do not get any negative feedback. >> >> You can find my tree here: >> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 > i just pulled your staging tree and decided to compile firmware for my > Turris Omnia. > > CONFIG_TRACE_EVAL_MAP_FILE makes the kernel fail. It needs to be > defined somewhere. Sorry it makes the compile fail. I have not tested it running yet. > >> >> Hauke >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote: > On 01/21/2018 06:53 PM, Hauke Mehrtens wrote: >> This add support for kernel 4.14 to the mvebu target. My main reason to >> add kernel 4.14 support is to make it easier to also add support for the >> Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board. >> >> I do not have any of the currently supported boards so I can not runtime >> test this myself, Lucian Cristian already tested an older version of >> these patches on one of his boards. >> >> My current working tree for this target can be found here: >> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 >> This tree also contains the code needed for the ESPRESSObin, but we >> still have some problems with the image creation, the bootloader boots >> by default the kernel + dtb from a ext4 file system on a SD card and >> also uses this partition as root file system. >> Tomasz Maciej Nowak is working on the image generation for the >> ESPRESSObin board. >> >> I am waiting for positive and negative feedback on these patches, if you >> run into a problem which you do not have with kernel 4.9 please report >> this. >> >> changes in: >> v2: >> * refresh on current generic kernel 4.14 integration >> * create ubifs fs format version 4 also with kernel 4.14, this should >>fix sysupgrade (downgrade) from kernel 4.14 to 4.9 >> * rename the wireless driver path when upgrading >> >> >> Hauke Mehrtens (5): >> kernel: ubifs: create use file system format 4 by default >> mvebu: move files to files-4.9 and files-4.4 folder >> mvebu: copy config and patches from 4.9 to 4.14 >> mvebu: Make kernel 4.14 patches apply >> mvebu: migrate uci config to new PCIe path >> > > I haven't heard of any problems, expected that one patch does not apply > any more with kernel 4.14.18, which is fixed now. > > I will merge this on Sunday if I do not get any negative feedback. > > You can find my tree here: > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 i just pulled your staging tree and decided to compile firmware for my Turris Omnia. CONFIG_TRACE_EVAL_MAP_FILE makes the kernel fail. It needs to be defined somewhere. > > Hauke > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update
On 02/09/2018 09:46 PM, Philip Prindeville wrote: > > >> On Jan 18, 2018, at 2:15 PM, Hauke Mehrtens wrote: >> >> On 01/18/2018 01:51 PM, Nick Lowe wrote: >>> Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to >>> properly address this? There are fixes to mitigate Spectre. >> >> We even need a patch for GCC which will be in GCC 8 and 7.3. >> For master we should backport it to GCC 5.5, but what do we want to do >> with 17.01 and 15.05 ? >> >> The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76, >> 4.4.111 which we already have. >> >> Hauke > > > For those of us following this from the sidelines (but not too closely), > what’s the relationship of GCC to microcode updating? > > -Philip GCC 7.3 supports retpoline which helps to mitigate one of the Spectre variants. Some of the mitigations are already done by some ASM code in the kernel, but not everything. The microcode update will provides some extra registers or instructions to also mitigate Spectre or help the software to mitigate it. Intel released here a plan which CPUs will get an updated microcode and in which state it is: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On 01/21/2018 06:53 PM, Hauke Mehrtens wrote: > This add support for kernel 4.14 to the mvebu target. My main reason to > add kernel 4.14 support is to make it easier to also add support for the > Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board. > > I do not have any of the currently supported boards so I can not runtime > test this myself, Lucian Cristian already tested an older version of > these patches on one of his boards. > > My current working tree for this target can be found here: > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 > This tree also contains the code needed for the ESPRESSObin, but we > still have some problems with the image creation, the bootloader boots > by default the kernel + dtb from a ext4 file system on a SD card and > also uses this partition as root file system. > Tomasz Maciej Nowak is working on the image generation for the > ESPRESSObin board. > > I am waiting for positive and negative feedback on these patches, if you > run into a problem which you do not have with kernel 4.9 please report > this. > > changes in: > v2: > * refresh on current generic kernel 4.14 integration > * create ubifs fs format version 4 also with kernel 4.14, this should >fix sysupgrade (downgrade) from kernel 4.14 to 4.9 > * rename the wireless driver path when upgrading > > > Hauke Mehrtens (5): > kernel: ubifs: create use file system format 4 by default > mvebu: move files to files-4.9 and files-4.4 folder > mvebu: copy config and patches from 4.9 to 4.14 > mvebu: Make kernel 4.14 patches apply > mvebu: migrate uci config to new PCIe path > I haven't heard of any problems, expected that one patch does not apply any more with kernel 4.14.18, which is fixed now. I will merge this on Sunday if I do not get any negative feedback. You can find my tree here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14 Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 0/5] mvebu: add kernel 4.14 support
On 02/09/2018 12:27 AM, Lucian Cristian wrote:
> On 21.01.2018 19:53, Hauke Mehrtens wrote:
>> This add support for kernel 4.14 to the mvebu target. My main reason to
>> add kernel 4.14 support is to make it easier to also add support for the
>> Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board.
>>
>> I do not have any of the currently supported boards so I can not runtime
>> test this myself, Lucian Cristian already tested an older version of
>> these patches on one of his boards.
>>
>> My current working tree for this target can be found here:
>> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mvebu-4.14
>>
>> This tree also contains the code needed for the ESPRESSObin, but we
>> still have some problems with the image creation, the bootloader boots
>> by default the kernel + dtb from a ext4 file system on a SD card and
>> also uses this partition as root file system.
>> Tomasz Maciej Nowak is working on the image generation for the
>> ESPRESSObin board.
>>
>> I am waiting for positive and negative feedback on these patches, if you
>> run into a problem which you do not have with kernel 4.9 please report
>> this.
>>
>> changes in:
>> v2:
>> * refresh on current generic kernel 4.14 integration
>> * create ubifs fs format version 4 also with kernel 4.14, this should
>> fix sysupgrade (downgrade) from kernel 4.14 to 4.9
>> * rename the wireless driver path when upgrading
>>
>>
>> Hauke Mehrtens (5):
>> kernel: ubifs: create use file system format 4 by default
>> mvebu: move files to files-4.9 and files-4.4 folder
>> mvebu: copy config and patches from 4.9 to 4.14
>> mvebu: Make kernel 4.14 patches apply
>> mvebu: migrate uci config to new PCIe path
>>
>> target/linux/generic/config-4.14 | 1 +
>> ...ption-to-create-UBI-FS-version-4-on-empty.patch | 63 ++
>> .../base-files/etc/uci-defaults/05-migrate-wifi | 23 +
>> target/linux/mvebu/config-4.14 | 486 ++
>> .../arch/arm/boot/dts/armada-385-linksys-rango.dts | 0
>> .../arm/boot/dts/armada-385-linksys-shelby.dts | 0
>> .../arch/arm/boot/dts/armada-385-linksys-rango.dts | 0
>> .../arm/boot/dts/armada-385-linksys-shelby.dts | 0
>> .../mvebu/patches-4.14/002-add_powertables.patch | 770
>>
>> .../mvebu/patches-4.14/003-add_switch_nodes.patch | 40 +
>> .../004-add_sata_disk_activity_trigger.patch | 39 +
>> .../mvebu/patches-4.14/100-find_active_root.patch | 60 ++
>> .../mvebu/patches-4.14/102-revert_i2c_delay.patch | 15 +
>> .../103-remove-nand-driver-bug.patch | 0
>> .../104-linksys_mamba_disable_keep_config.patch | 10 +
>> .../110-pxa3xxx_revert_irq_thread.patch | 69 ++
>> .../205-armada-385-rd-mtd-partitions.patch | 0
>> .../206-ARM-mvebu-385-ap-Add-partitions.patch | 0
>> .../patches-4.14/210-clearfog_switch_node.patch | 21 +
>> .../300-mvneta-tx-queue-workaround.patch | 35 +
>> ...bu-indicate-failure-to-enter-deeper-sleep.patch | 40 +
>> .../401-pci-mvebu-time-out-reset-on-link-up.patch | 60 ++
>> .../402-sfp-display-SFP-module-information.patch | 290 ++
>> .../403-net-mvneta-convert-to-phylink.patch | 979
>> +
>> .../404-net-mvneta-hack-fix-phy_interface.patch | 28 +
>> ...disable-MVNETA_CAUSE_PSC_SYNC_CHANGE-inte.patch | 56 ++
>> ...-mvneta-add-module-EEPROM-reading-support.patch | 44 +
>> ...y-fixed-phy-remove-fixed_phy_update_state.patch | 80 ++
>> ...dule-eeprom-ethtool-access-into-netdev-co.patch | 181
>> ...409-sfp-use-netdev-sfp_bus-for-start-stop.patch | 34 +
>> ...-allow-marvell-10G-phy-support-to-use-SFP.patch | 130 +++
>> .../patches-4.14/411-sfp-add-sfp-compatible.patch | 24 +
>> ...-armada388-clearfog-emmc-on-clearfog-base.patch | 87 ++
>> ...ada388-clearfog-increase-speed-of-i2c0-to.patch | 42 +
>> ...armada388-clearfog-add-SFP-module-support.patch | 81 ++
>> ...dts-armada388-clearfog-document-MPP-usage.patch | 124 +++
>> 36 files changed, 3912 insertions(+)
>> create mode 100644
>> target/linux/generic/pending-4.14/553-ubifs-Add-option-to-create-UBI-FS-version-4-on-empty.patch
>>
>> create mode 100644
>> target/linux/mvebu/base-files/etc/uci-defaults/05-migrate-wifi
>> create mode 100644 target/linux/mvebu/config-4.14
>> copy target/linux/mvebu/{files =>
>> files-4.4}/arch/arm/boot/dts/armada-385-linksys-rango.dts (100%)
>> copy target/linux/mvebu/{files =>
>> files-4.4}/arch/arm/boot/dts/armada-385-linksys-shelby.dts (100%)
>> rename target/linux/mvebu/{files =>
>> files-4.9}/arch/arm/boot/dts/armada-385-linksys-rango.dts (100%)
>> rename target/linux/mvebu/{files =>
>> files-4.9}/arch/arm/boot/dts/armada-385-linksys-shelby.dts (100%)
>> create mode 100644
>> target/linux/mvebu/patches-4.14/002-add_powertables.patch
>> create mode 100644
>> target/linux/mvebu/patches-4.1
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update
> On Jan 18, 2018, at 2:15 PM, Hauke Mehrtens wrote: > > On 01/18/2018 01:51 PM, Nick Lowe wrote: >> Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to >> properly address this? There are fixes to mitigate Spectre. > > We even need a patch for GCC which will be in GCC 8 and 7.3. > For master we should backport it to GCC 5.5, but what do we want to do > with 17.01 and 15.05 ? > > The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76, > 4.4.111 which we already have. > > Hauke For those of us following this from the sidelines (but not too closely), what’s the relationship of GCC to microcode updating? -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: quote values when evaluating uevent
LGTM
Been using it here for a few days.
> On Feb 1, 2018, at 5:57 PM, Daniel Golle wrote:
>
> When sourcing /sys/class/block/*/uevent values have to be quoted as
> they may contain spaces (e.g. in PARTNAME).
> Fix this by pre-processing with sed before sourcing.
>
> Signed-off-by: Daniel Golle
> ---
> package/base-files/files/lib/upgrade/common.sh | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh
> index 71cffc8587..616131c89c 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -134,8 +134,7 @@ export_bootdevice() {
> esac
>
> if [ -e "$uevent" ]; then
> - . "$uevent"
> -
> + eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
> export BOOTDEV_MAJOR=$MAJOR
> export BOOTDEV_MINOR=$MINOR
> return 0
> @@ -150,7 +149,7 @@ export_partdevice() {
> local uevent MAJOR MINOR DEVNAME DEVTYPE
>
> for uevent in /sys/class/block/*/uevent; do
> - . "$uevent"
> + eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
> if [ $BOOTDEV_MAJOR = $MAJOR -a $(($BOOTDEV_MINOR + $offset)) =
> $MINOR -a -b "/dev/$DEVNAME" ]; then
> export "$var=$DEVNAME"
> return 0
> --
> 2.16.1
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH mountd 1/2] mount: struct mount: replace "mounted" and "ignore" fileds with a "status"
From: Rafał Miłecki
There is no need to store status using these 2 separated fields.
Obviously ignored mount should never get mounted. This change will also
allow adding more statuses easily in the future if needed.
Signed-off-by: Rafał Miłecki
---
mount.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/mount.c b/mount.c
index 646cc30..2d34a91 100644
--- a/mount.c
+++ b/mount.c
@@ -33,6 +33,19 @@ int mount_new(char *path, char *dev);
static struct list_head mounts;
+/**
+ * enum status - status of mount entry
+ *
+ * @STATUS_UNMOUNTED: currently not mounted
+ * @STATUS_MOUNTED: mounted & ready for usage
+ * @STATUS_IGNORE: entry should be ignored and never mounted
+ */
+enum status {
+ STATUS_UNMOUNTED = 0,
+ STATUS_MOUNTED,
+ STATUS_IGNORE,
+};
+
struct mount {
struct list_head list;
char name[64];
@@ -41,8 +54,7 @@ struct mount {
char vendor[64];
char model[64];
char rev[64];
- int mounted;
- int ignore;
+ enum status status;
char size[64];
char sector_size[64];
int fs;
@@ -95,7 +107,7 @@ static void mount_dump_uci_state(void)
ucix_add_option(ctx, mountd, q->serial, "disc", t);
ucix_add_option(ctx, mountd, q->serial, "sector_size",
q->sector_size);
snprintf(t, 64, "part%dmounted", atoi(&q->dev[3]));
- ucix_add_option(ctx, mountd, q->serial, t,
(q->mounted)?("1"):("0"));
+ ucix_add_option(ctx, mountd, q->serial, t, q->status ==
STATUS_MOUNTED ? "1" : "0");
ucix_add_option(ctx, mountd, q->serial, "vendor", q->vendor);
ucix_add_option(ctx, mountd, q->serial, "model", q->model);
ucix_add_option(ctx, mountd, q->serial, "rev", q->rev);
@@ -106,9 +118,9 @@ static void mount_dump_uci_state(void)
snprintf(t, 64, "fs%d", atoi(&q->dev[3]));
ucix_add_option(ctx, mountd, q->serial, t,
fs_names[q->fs]);
}
- if(q->mounted)
+ if (q->status == STATUS_MOUNTED)
mounted++;
- if((!q->ignore) && q->size && q->sector_size)
+ if ((q->status != STATUS_IGNORE) && q->size && q->sector_size)
size = size + (((unsigned long long int)atoi(q->size))
* ((unsigned long long int)atoi(q->sector_size)));
}
ucix_add_option_int(ctx, mountd, mountd, "mounted", mounted);
@@ -150,12 +162,13 @@ static void mount_add_list(char *name, char *dev, char
*serial,
strncpy(mount->serial, serial, 64);
strncpy(mount->size, size, 64);
strncpy(mount->sector_size, sector_size, 64);
- mount->ignore = ignore;
- mount->mounted = 0;
+ mount->status = STATUS_UNMOUNTED;
mount->fs = fs;
list_add(&mount->list, &mounts);
- if (!mount->ignore)
- {
+
+ if (ignore) {
+ mount->status = STATUS_IGNORE;
+ } else {
log_printf("new mount : %s -> %s (%s)\n", name, dev,
fs_names[mount->fs]);
snprintf(tmp, 64, "%s%s", uci_path, name);
snprintf(tmp2, 64, "/tmp/run/mountd/%s", dev);
@@ -219,7 +232,7 @@ int mount_new(char *path, char *dev)
log_printf("request for invalid path %s%s\n", path, dev);
return -1;
}
- if(mount->ignore || mount->mounted || mount->fs == EXTENDED)
+ if (mount->status == STATUS_IGNORE || mount->status == STATUS_MOUNTED
|| mount->fs == EXTENDED)
return -1;
snprintf(tmp, 256, "%s%s", path, mount->dev);
log_printf("mounting %s\n", tmp);
@@ -298,7 +311,7 @@ int mount_new(char *path, char *dev)
}
if(mount_wait_for_disc(mount->dev) == 0)
{
- mount->mounted = 1;
+ mount->status = STATUS_MOUNTED;
mount_dump_uci_state();
} else return -1;
return 0;
@@ -317,7 +330,7 @@ int mount_remove(char *path, char *dev)
rmdir(tmp);
mount = mount_find(0, dev);
if(mount)
- mount->mounted = 0;
+ mount->status = STATUS_UNMOUNTED;
log_printf("finished unmounting\n");
mount_dump_uci_state();
return 0;
@@ -571,7 +584,7 @@ static void mount_dev_del(struct mount *mount)
{
char tmp[256];
- if (mount->mounted) {
+ if (mount->status == STATUS_MOUNTED) {
snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/", mount->name);
log_printf("%s has dissappeared ... unmounting\n", tmp);
snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/", mount->dev);
@@ -589,7 +602,7 @@ void mount_dump_list(void)
list_for_each(p, &mounts)
{
struct mount *q = container_of(p, struct mount, list);
- log_printf("* %s %s %d\n", q->name, q->dev, q->mounted
[LEDE-DEV] [PATCH mountd 2/2] mount: fix removing mount point if it's expired
From: Rafał Miłecki
Kernel can report mount point as expired and when that happens mountd
unmounts it. It's still important to:
1) Cleanup directories
2) Call hotplug scripts
when device for such a mount disappears. Fix this by adding a new
EXPIRED status and checking it when block device disappears.
Signed-off-by: Rafał Miłecki
---
mount.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mount.c b/mount.c
index 2d34a91..cb3e03c 100644
--- a/mount.c
+++ b/mount.c
@@ -38,11 +38,13 @@ static struct list_head mounts;
*
* @STATUS_UNMOUNTED: currently not mounted
* @STATUS_MOUNTED: mounted & ready for usage
+ * @STATUS_EXPIRED: mount expired & *temporary* unmounted
* @STATUS_IGNORE: entry should be ignored and never mounted
*/
enum status {
STATUS_UNMOUNTED = 0,
STATUS_MOUNTED,
+ STATUS_EXPIRED,
STATUS_IGNORE,
};
@@ -330,7 +332,7 @@ int mount_remove(char *path, char *dev)
rmdir(tmp);
mount = mount_find(0, dev);
if(mount)
- mount->status = STATUS_UNMOUNTED;
+ mount->status = STATUS_EXPIRED;
log_printf("finished unmounting\n");
mount_dump_uci_state();
return 0;
@@ -762,7 +764,7 @@ static void mount_enum_drives(void)
p->next->prev = p->prev;
p = p->next;
log_printf("removing %s\n", q->dev);
- if (q->status == STATUS_MOUNTED) {
+ if (q->status == STATUS_MOUNTED || q->status ==
STATUS_EXPIRED) {
snprintf(tmp, 64, "%s%s", "/tmp/run/mountd/",
q->dev);
rmdir(tmp);
snprintf(tmp, 64, "%s%s", uci_path, q->name);
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH mountd] mount: change mount_dev_del() argument to struct mount *
From: Rafał Miłecki
Caller of mount_dev_del() already has struct mount * so there is no
point in passing matchin device and then looking for struct mount *
again.
Signed-off-by: Rafał Miłecki
---
mount.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/mount.c b/mount.c
index f995745..646cc30 100644
--- a/mount.c
+++ b/mount.c
@@ -567,23 +567,19 @@ static void mount_dev_add(char *dev)
}
}
-static void mount_dev_del(char *dev)
+static void mount_dev_del(struct mount *mount)
{
- struct mount *mount = mount_find(0, dev);
char tmp[256];
- if(mount)
- {
- if(mount->mounted)
- {
- snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/",
mount->name);
- log_printf("%s has dissappeared ... unmounting\n", tmp);
- snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/",
mount->dev);
- system_printf("/bin/umount %s", tmp);
- rmdir(tmp);
- snprintf(tmp, 64, "%s%s", uci_path, mount->name);
- unlink(tmp);
- mount_dump_uci_state();
- }
+
+ if (mount->mounted) {
+ snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/", mount->name);
+ log_printf("%s has dissappeared ... unmounting\n", tmp);
+ snprintf(tmp, 256, "%s%s", "/tmp/run/mountd/", mount->dev);
+ system_printf("/bin/umount %s", tmp);
+ rmdir(tmp);
+ snprintf(tmp, 64, "%s%s", uci_path, mount->name);
+ unlink(tmp);
+ mount_dump_uci_state();
}
}
@@ -748,7 +744,7 @@ static void mount_enum_drives(void)
}
if(!check_block(q->dev)||del)
{
- mount_dev_del(q->dev);
+ mount_dev_del(q);
p->prev->next = p->next;
p->next->prev = p->prev;
p = p->next;
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH mountd] mount: don't mount device that is already mounted
On 8 February 2018 at 18:34, Rafał Miłecki wrote: > From: Rafał Miłecki > > It may happen that on mountd start some devices are already mounted. > This could due to killing previous mountd instance or just a crash. In > such case device shouldn't get remounted but added to the list with a > mounted flag set. That will make mountd monitor it and take needed steps > when it disappears. Uh, this may not exactly work as expected. Even if device is mounted, e.g. to /var/run/mountd/sda1 mountd on start does: /bin/mount -t autofs -o (...) /tmp/run/mountd/ which causes /var/run/mountd/sda1 to /disappear/. I've to think about it for a bit more. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT
On Freitag, 9. Februar 2018 09:05:02 CET Sven Eckelmann wrote: [...] > > In OpenWRT 15.01 we are building 7.3MB large images and have just > > enought space for configs. > > In LEDE 17.01 is max size ~6.5MB and we are not able to build our > > images, because we cannot strip more packages, now we are on 6.8MB. > > Why do you think that you are now using only 6.8MB? The fw_max_len for 8Mlzma > devices is 8126464 bytes in mktplinkfw.c. So your final image would be > 8376020 > bytes large and thus it is rejected by mktplinkfw. [...] Btw. the image sizes in mktplinkfw also include the reserved space of 262144 bytes. See the option -X in Build/mktplinkfw [1]. My use of the term "final image" might therefore be a little bit misleading - it is just the size which mktplinkfw calculates including the reserved space. But this hasn't changed since Chaos Calmer [2]. And I just saw that Matthias Schiffer also integrated his ar71xx target in OpenWrt. So you might want to check his patch [3] to get a little bit inspired. Kind regards, Sven [1] https://github.com/openwrt/openwrt/blob/9a08c104e2f2418f580f4ef218d890ea768f7a23/target/linux/ar71xx/image/common-tp-link.mk#L32 [2] https://github.com/openwrt/chaos_calmer/blob/2adad7714eebf89db7471bfd8d014b36c1e56b22/target/linux/ar71xx/image/Makefile#L59 [3] https://github.com/openwrt/openwrt/commit/0cd5e85e7ad621223b0787e66d8ad20fb2694135 signature.asc Description: This is a digitally signed message part. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT
On Freitag, 9. Februar 2018 01:36:49 CET Jakub Jančo wrote: > Hello, > > is there any reason why LEDE needs more empty space in firmware for > TP-link tl-wr1043nd v3 ? OpenWrt master should show you the exact same error message. OpenWrt 15.05 is quite outdated. > In OpenWRT 15.01 we are building 7.3MB large images and have just > enought space for configs. > In LEDE 17.01 is max size ~6.5MB and we are not able to build our > images, because we cannot strip more packages, now we are on 6.8MB. Why do you think that you are now using only 6.8MB? The fw_max_len for 8Mlzma devices is 8126464 bytes in mktplinkfw.c. So your final image would be 8376020 bytes large and thus it is rejected by mktplinkfw. The dd before that is from something else (the append-rootfs when I am not mistaken). You might now need to start to remove more things (stuff which cannot be configured but has to be patched) - for example remove unused mach files from the kernel build, remove unused drivers from the kernel, remove unused symbols from large libraries (+ elf sections per function/data + elf section garbage collection during the link), get rid of things which you don't actually use (opkg?), ... ar71xx-tiny from from gluon [1] could maybe also give you some inspiration. Kind regards, Sven [1] https://github.com/freifunk-gluon/gluon (for example grep for no_opkg) signature.asc Description: This is a digitally signed message part. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
