* [PATCH v15 05/11] pwm: pwm-imx-tpm: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Fabio Estevam, Arnd Bergmann, David Collins, Stephen Boyd,
Shawn Guo, Sascha Hauer, linux-kernel, Geert Uytterhoeven,
Dan Carpenter, Pengutronix Kernel Team, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck,
NXP Linux Team
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/pwm/pwm-imx-tpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 5f3d7f7..fcdf6be 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -124,7 +124,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
real_state->duty_cycle = state->duty_cycle;
tmp = (u64)p->mod * real_state->duty_cycle;
- p->val = DIV_ROUND_CLOSEST_ULL(tmp, real_state->period);
+ p->val = DIV64_U64_ROUND_CLOSEST(tmp, real_state->period);
real_state->polarity = state->polarity;
real_state->enabled = state->enabled;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 07/11] pwm: sifive: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-26 17:35 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Uwe Kleine-König
Cc: linux-arm-kernel, Guru Das Srinagesh, Daniel Thompson,
Arnd Bergmann, David Collins, Stephen Boyd, linux-kernel,
Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <cover.1590514331.git.gurus@codeaurora.org>
Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
drivers/pwm/pwm-sifive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index cc63f9b..62de0bb 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
* consecutively
*/
num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
- frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
+ frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
/* The hardware cannot generate a 100% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-26 17:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Naohiro Aota, Stephen Boyd, Masahiro Yamada, Nick Desaulniers,
linux-kernel, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, linux-arm-kernel
Custom toolchains that modify the default target to -mthumb cannot
compile the arm64 compat vdso32, as
arch/arm64/include/asm/vdso/compat_gettimeofday.h
contains assembly that's invalid in -mthumb. Force the use of -marm,
always.
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084372
Cc: Stephen Boyd <swboyd@google.com>
Reported-by: Luis Lozano <llozano@google.com>
Tested-by: Manoj Gupta <manojgupta@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Surgeon General's Warning: changing the compiler defaults is not
recommended and can lead to spooky bugs that are hard to reproduce
upstream.
arch/arm64/kernel/vdso32/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 3964738ebbde..c449a293d81e 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -104,6 +104,8 @@ VDSO_CFLAGS += -D__uint128_t='void*'
# (on GCC 4.8 or older, there is unfortunately no way to silence this warning)
VDSO_CFLAGS += $(call cc32-disable-warning,shift-count-overflow)
VDSO_CFLAGS += -Wno-int-to-pointer-cast
+# Force vdso to be compiled in ARM mode, not THUMB.
+VDSO_CFLAGS += -marm
VDSO_AFLAGS := $(VDSO_CAFLAGS)
VDSO_AFLAGS += -D__ASSEMBLY__
--
2.27.0.rc0.183.gde8f92d652-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 0/4] scsi: ufs: Fix WriteBooster and cleanup UFS driver
From: Asutosh Das (asd) @ 2020-05-26 17:25 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, martin.petersen, avri.altman,
alim.akhtar, jejb
Cc: Virtual_Global_UFS_Upstream, bvanassche, linux-kernel, cang,
linux-mediatek, matthias.bgg, linux-arm-kernel, beanhuo
In-Reply-To: <20200522083212.4008-1-stanley.chu@mediatek.com>
On 5/22/2020 1:32 AM, Stanley Chu wrote:
> Hi,
>
> This patch set fixes some WriteBooster issues and do small cleanup in UFS driver
>
> v3 -> v4
> - Squash patch [4] and [5] (Asutosh)
> - Fix commit message in patch [4]
>
> v2 -> v3
> - Introduce patch [5] to fix possible VCC power drain during runtime suspend (Asutosh)
>
> v1 -> v2
> - Remove dummy new line in patch [4] (Asutosh)
> - Add more limitation to allow WriteBooster flush during Hibern8 in runtime-suspend. Now the device power mode is kept as Active power mode only if link is put in Hibern8 or Auto-Hibern8 is enabled during runtime-suspend (Asutosh)
>
> Stanley Chu (4):
> scsi: ufs: Remove unnecessary memset for dev_info
> scsi: ufs: Allow WriteBooster on UFS 2.2 devices
> scsi: ufs: Fix index of attributes query for WriteBooster feature
> scsi: ufs: Fix WriteBooster flush during runtime suspend
>
> drivers/scsi/ufs/ufs-sysfs.c | 13 ++++-
> drivers/scsi/ufs/ufs.h | 2 +-
> drivers/scsi/ufs/ufshcd.c | 99 +++++++++++++++++++++++++-----------
> drivers/scsi/ufs/ufshcd.h | 3 +-
> 4 files changed, 82 insertions(+), 35 deletions(-)
>
This set looks good to me.
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: imx8mm-beacon: Fix voltages on LDO1 and LDO2
From: Adam Ford @ 2020-05-26 17:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Fabio Estevam, Adam Ford, Sascha Hauer, aford,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo
LDO1 and LDO2 settings are wrong and case the voltage to go above the
maximum level of 2.15V permitted by the SoC to 3.0V.
This patch is based on work done on the i.MX8M Mini-EVK which utilizes
the same fix.
Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index fb0137a8611c..94911b1707ef 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -136,7 +136,7 @@
ldo1_reg: LDO1 {
regulator-name = "LDO1";
- regulator-min-microvolt = <3000000>;
+ regulator-min-microvolt = <1600000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
@@ -144,7 +144,7 @@
ldo2_reg: LDO2 {
regulator-name = "LDO2";
- regulator-min-microvolt = <900000>;
+ regulator-min-microvolt = <800000>;
regulator-max-microvolt = <900000>;
regulator-boot-on;
regulator-always-on;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4] Makefile: support compressed debug info
From: Nick Desaulniers @ 2020-05-26 17:06 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Naohiro Aota, Stephen Rothwell, Michal Marek, Nick Clifton,
Fangrui Song, Anshuman Khandual, Mauro Carvalho Chehab,
Catalin Marinas, Randy Dunlap, LKML, Krzysztof Kozlowski,
Changbin Du, Linux ARM, clang-built-linux, Sedat Dilek,
David Blaikie, Thomas Gleixner, Vincenzo Frascino, Will Deacon,
Andrew Morton, Linux Kbuild mailing list
In-Reply-To: <20200526170321.137238-1-ndesaulniers@google.com>
On Tue, May 26, 2020 at 10:03 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> As debug information gets larger and larger, it helps significantly save
> the size of vmlinux images to compress the information in the debug
> information sections. Note: this debug info is typically split off from
> the final compressed kernel image, which is why vmlinux is what's used
> in conjunction with GDB. Minimizing the debug info size should have no
> impact on boot times, or final compressed kernel image size.
>
> All of the debug sections will have a `C` flag set.
> $ readelf -S <object file>
>
> $ bloaty vmlinux.gcc75.compressed.dwarf4 -- \
> vmlinux.gcc75.uncompressed.dwarf4
>
> FILE SIZE VM SIZE
> -------------- --------------
> +0.0% +18 [ = ] 0 [Unmapped]
> -73.3% -114Ki [ = ] 0 .debug_aranges
> -76.2% -2.01Mi [ = ] 0 .debug_frame
> -73.6% -2.89Mi [ = ] 0 .debug_str
> -80.7% -4.66Mi [ = ] 0 .debug_abbrev
> -82.9% -4.88Mi [ = ] 0 .debug_ranges
> -70.5% -9.04Mi [ = ] 0 .debug_line
> -79.3% -10.9Mi [ = ] 0 .debug_loc
> -39.5% -88.6Mi [ = ] 0 .debug_info
> -18.2% -123Mi [ = ] 0 TOTAL
>
> $ bloaty vmlinux.clang11.compressed.dwarf4 -- \
> vmlinux.clang11.uncompressed.dwarf4
>
> FILE SIZE VM SIZE
> -------------- --------------
> +0.0% +23 [ = ] 0 [Unmapped]
> -65.6% -871 [ = ] 0 .debug_aranges
> -77.4% -1.84Mi [ = ] 0 .debug_frame
> -82.9% -2.33Mi [ = ] 0 .debug_abbrev
> -73.1% -2.43Mi [ = ] 0 .debug_str
> -84.8% -3.07Mi [ = ] 0 .debug_ranges
> -65.9% -8.62Mi [ = ] 0 .debug_line
> -86.2% -40.0Mi [ = ] 0 .debug_loc
> -42.0% -64.1Mi [ = ] 0 .debug_info
> -22.1% -122Mi [ = ] 0 TOTAL
>
> For x86_64 defconfig + LLVM=1 (before):
> Elapsed (wall clock) time (h:mm:ss or m:ss): 3:22.03
> Maximum resident set size (kbytes): 43856
>
> For x86_64 defconfig + LLVM=1 (after):
> Elapsed (wall clock) time (h:mm:ss or m:ss): 3:32.52
> Maximum resident set size (kbytes): 1566776
>
> Thanks to:
> Nick Clifton helped us to provide the minimal binutils version.
> Sedat Dilet found an increase in size of debug .deb package.
>
> Cc: Nick Clifton <nickc@redhat.com>
> Cc: Sedat Dilek <sedat.dilek@gmail.com>
> Suggested-by: David Blaikie <blaikie@google.com>
> Reviewed-by: Fangrui Song <maskray@google.com>
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> Changes V3 -> V4:
> * Add thanks line to commit message as per Masahiro.
> * Swap Sugguested-by to Cc for two lines in commit message, as per
> Masahiro.
>
> Changes V2 -> V3:
> * Fix blaikie@'s email addr.
> * Fix Fangrui's Reviewed-by tag as per Masahiro.
> * Fix help text as per Masahiro.
> * Fix -Wa$(comma)foo as per Masahiro.
>
> Changes V1 -> V2:
> * rebase on linux-next.
> * Add assembler flags as per Fangrui.
> * Add note about KDEB_COMPRESS+scripts/package/builddeb
> as per Sedat and Masahiro.
> * Add note about bintutils version requirements as per Nick C.
> * Add note about measured increased build time and max RSS.
>
> Makefile | 6 ++++++
> arch/arm64/kernel/vdso32/Makefile | 2 +-
Sorry, I was wondering why Will and TGLX got cc'ed. My tree was dirty
when I amended ... was carrying another patch to send, please
disregard v4, and sorry for the noise.
> lib/Kconfig.debug | 17 +++++++++++++++++
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 71687bfe1cd9..be8835296754 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -822,6 +822,12 @@ DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
> $(call cc-option,-fno-var-tracking)
> endif
>
> +ifdef CONFIG_DEBUG_INFO_COMPRESSED
> +DEBUG_CFLAGS += -gz=zlib
> +KBUILD_AFLAGS += -Wa,--compress-debug-sections=zlib
> +KBUILD_LDFLAGS += --compress-debug-sections=zlib
> +endif
> +
> KBUILD_CFLAGS += $(DEBUG_CFLAGS)
> export DEBUG_CFLAGS
>
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 3964738ebbde..5fd7792d03fc 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -135,7 +135,7 @@ c-obj-vdso-gettimeofday := vgettimeofday.o
> asm-obj-vdso := sigreturn.o
>
> ifneq ($(c-gettimeofday-y),)
> -VDSO_CFLAGS_gettimeofday_o += -include $(c-gettimeofday-y)
> +VDSO_CFLAGS_gettimeofday_o += -include $(c-gettimeofday-y) -marm
> endif
>
> VDSO_CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b8f023e054b9..7fc82dcf814b 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -225,6 +225,23 @@ config DEBUG_INFO_REDUCED
> DEBUG_INFO build and compile times are reduced too.
> Only works with newer gcc versions.
>
> +config DEBUG_INFO_COMPRESSED
> + bool "Compressed debugging information"
> + depends on DEBUG_INFO
> + depends on $(cc-option,-gz=zlib)
> + depends on $(as-option,-Wa$(comma)--compress-debug-sections=zlib)
> + depends on $(ld-option,--compress-debug-sections=zlib)
> + help
> + Compress the debug information using zlib. Requires GCC 5.0+ or Clang
> + 5.0+, binutils 2.26+, and zlib.
> +
> + Users of dpkg-deb via scripts/package/builddeb may find an increase in
> + size of their debug .deb packages with this config set, due to the
> + debug info being compressed with zlib, then the object files being
> + recompressed with a different compression scheme. But this is still
> + preferable to setting $KDEB_COMPRESS to "none" which would be even
> + larger.
> +
> config DEBUG_INFO_SPLIT
> bool "Produce split debuginfo in .dwo files"
> depends on DEBUG_INFO
> --
> 2.27.0.rc0.183.gde8f92d652-goog
>
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] Makefile: support compressed debug info
From: Nick Desaulniers @ 2020-05-26 17:03 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Nick Clifton, Catalin Marinas, Vincenzo Frascino, Will Deacon,
Naohiro Aota, Stephen Rothwell, Fangrui Song,
Mauro Carvalho Chehab, linux-kbuild, Krzysztof Kozlowski,
clang-built-linux, Anshuman Khandual, Sedat Dilek, David Blaikie,
Thomas Gleixner, linux-arm-kernel, Michal Marek, Randy Dunlap,
Nick Desaulniers, linux-kernel, Changbin Du, Andrew Morton
In-Reply-To: <CAK7LNASkcLx-K+W1va9WxfxZ=7H-w65QbyBt=88dzK1NrrM_PQ@mail.gmail.com>
As debug information gets larger and larger, it helps significantly save
the size of vmlinux images to compress the information in the debug
information sections. Note: this debug info is typically split off from
the final compressed kernel image, which is why vmlinux is what's used
in conjunction with GDB. Minimizing the debug info size should have no
impact on boot times, or final compressed kernel image size.
All of the debug sections will have a `C` flag set.
$ readelf -S <object file>
$ bloaty vmlinux.gcc75.compressed.dwarf4 -- \
vmlinux.gcc75.uncompressed.dwarf4
FILE SIZE VM SIZE
-------------- --------------
+0.0% +18 [ = ] 0 [Unmapped]
-73.3% -114Ki [ = ] 0 .debug_aranges
-76.2% -2.01Mi [ = ] 0 .debug_frame
-73.6% -2.89Mi [ = ] 0 .debug_str
-80.7% -4.66Mi [ = ] 0 .debug_abbrev
-82.9% -4.88Mi [ = ] 0 .debug_ranges
-70.5% -9.04Mi [ = ] 0 .debug_line
-79.3% -10.9Mi [ = ] 0 .debug_loc
-39.5% -88.6Mi [ = ] 0 .debug_info
-18.2% -123Mi [ = ] 0 TOTAL
$ bloaty vmlinux.clang11.compressed.dwarf4 -- \
vmlinux.clang11.uncompressed.dwarf4
FILE SIZE VM SIZE
-------------- --------------
+0.0% +23 [ = ] 0 [Unmapped]
-65.6% -871 [ = ] 0 .debug_aranges
-77.4% -1.84Mi [ = ] 0 .debug_frame
-82.9% -2.33Mi [ = ] 0 .debug_abbrev
-73.1% -2.43Mi [ = ] 0 .debug_str
-84.8% -3.07Mi [ = ] 0 .debug_ranges
-65.9% -8.62Mi [ = ] 0 .debug_line
-86.2% -40.0Mi [ = ] 0 .debug_loc
-42.0% -64.1Mi [ = ] 0 .debug_info
-22.1% -122Mi [ = ] 0 TOTAL
For x86_64 defconfig + LLVM=1 (before):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:22.03
Maximum resident set size (kbytes): 43856
For x86_64 defconfig + LLVM=1 (after):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:32.52
Maximum resident set size (kbytes): 1566776
Thanks to:
Nick Clifton helped us to provide the minimal binutils version.
Sedat Dilet found an increase in size of debug .deb package.
Cc: Nick Clifton <nickc@redhat.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: David Blaikie <blaikie@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Changes V3 -> V4:
* Add thanks line to commit message as per Masahiro.
* Swap Sugguested-by to Cc for two lines in commit message, as per
Masahiro.
Changes V2 -> V3:
* Fix blaikie@'s email addr.
* Fix Fangrui's Reviewed-by tag as per Masahiro.
* Fix help text as per Masahiro.
* Fix -Wa$(comma)foo as per Masahiro.
Changes V1 -> V2:
* rebase on linux-next.
* Add assembler flags as per Fangrui.
* Add note about KDEB_COMPRESS+scripts/package/builddeb
as per Sedat and Masahiro.
* Add note about bintutils version requirements as per Nick C.
* Add note about measured increased build time and max RSS.
Makefile | 6 ++++++
arch/arm64/kernel/vdso32/Makefile | 2 +-
lib/Kconfig.debug | 17 +++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 71687bfe1cd9..be8835296754 100644
--- a/Makefile
+++ b/Makefile
@@ -822,6 +822,12 @@ DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
$(call cc-option,-fno-var-tracking)
endif
+ifdef CONFIG_DEBUG_INFO_COMPRESSED
+DEBUG_CFLAGS += -gz=zlib
+KBUILD_AFLAGS += -Wa,--compress-debug-sections=zlib
+KBUILD_LDFLAGS += --compress-debug-sections=zlib
+endif
+
KBUILD_CFLAGS += $(DEBUG_CFLAGS)
export DEBUG_CFLAGS
diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 3964738ebbde..5fd7792d03fc 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -135,7 +135,7 @@ c-obj-vdso-gettimeofday := vgettimeofday.o
asm-obj-vdso := sigreturn.o
ifneq ($(c-gettimeofday-y),)
-VDSO_CFLAGS_gettimeofday_o += -include $(c-gettimeofday-y)
+VDSO_CFLAGS_gettimeofday_o += -include $(c-gettimeofday-y) -marm
endif
VDSO_CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b8f023e054b9..7fc82dcf814b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -225,6 +225,23 @@ config DEBUG_INFO_REDUCED
DEBUG_INFO build and compile times are reduced too.
Only works with newer gcc versions.
+config DEBUG_INFO_COMPRESSED
+ bool "Compressed debugging information"
+ depends on DEBUG_INFO
+ depends on $(cc-option,-gz=zlib)
+ depends on $(as-option,-Wa$(comma)--compress-debug-sections=zlib)
+ depends on $(ld-option,--compress-debug-sections=zlib)
+ help
+ Compress the debug information using zlib. Requires GCC 5.0+ or Clang
+ 5.0+, binutils 2.26+, and zlib.
+
+ Users of dpkg-deb via scripts/package/builddeb may find an increase in
+ size of their debug .deb packages with this config set, due to the
+ debug info being compressed with zlib, then the object files being
+ recompressed with a different compression scheme. But this is still
+ preferable to setting $KDEB_COMPRESS to "none" which would be even
+ larger.
+
config DEBUG_INFO_SPLIT
bool "Produce split debuginfo in .dwo files"
depends on DEBUG_INFO
--
2.27.0.rc0.183.gde8f92d652-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 3/3] serial: 8250_dw: Fix common clocks usage race condition
From: Andy Shevchenko @ 2020-05-26 16:57 UTC (permalink / raw)
To: Serge Semin
Cc: Thomas Bogendoerfer, linux-kernel, Arnd Bergmann,
Greg Kroah-Hartman, Russell King, Serge Semin, Alexey Malahov,
Maxime Ripard, linux-serial, Jiri Slaby, linux-mips, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200526160316.26136-4-Sergey.Semin@baikalelectronics.ru>
On Tue, May 26, 2020 at 07:03:16PM +0300, Serge Semin wrote:
> The race condition may happen if the UART reference clock is shared with
> some other device (on Baikal-T1 SoC it's another DW UART port). In this
> case if that device changes the clock rate while serial console is using
> it the DW 8250 UART port might not only end up with an invalid uartclk
> value saved, but may also experience a distorted output data since
> baud-clock could have been changed. In order to fix this lets at least
> try to adjust the 8250 port setting like UART clock rate in case if the
> reference clock rate change is discovered. The driver will call the new
> method to update 8250 UART port clock rate settings. It's done by means of
> the clock event notifier registered at the port startup and unregistered
> in the shutdown callback method.
>
> Note 1. In order to avoid deadlocks we had to execute the UART port update
> method in a dedicated deferred work. This is due to (in my opinion
> redundant) the clock update implemented in the dw8250_set_termios()
> method.
> Note 2. Before the ref clock is manually changed by the custom
> set_termios() function we swap the port uartclk value with new rate
> adjusted to be suitable for the requested baud. It is necessary in
> order to effectively disable a functionality of the ref clock events
> handler for the current UART port, since uartclk update will be done
> a bit further in the generic serial8250_do_set_termios() function.
...
> +static void dw8250_clk_work_cb(struct work_struct *work)
> +{
> + struct dw8250_data *d = work_to_dw8250_data(work);
> + struct uart_8250_port *up;
> + unsigned long rate;
> +
> + rate = clk_get_rate(d->clk);
> + if (rate) {
if (rate <= 0)
return;
?
> + up = serial8250_get_port(d->data.line);
> +
> + serial8250_update_uartclk(&up->port, rate);
> + }
> +}
...
> +static int dw8250_startup(struct uart_port *p)
> +{
> + struct dw8250_data *d = to_dw8250_data(p->private_data);
> + int ret;
> +
> + /*
> + * Some platforms may provide a reference clock shared between several
> + * devices. In this case before using the serial port first we have to
> + * make sure that any clock state change is known to the UART port at
> + * least post factum.
> + */
> + if (d->clk) {
Do you need this?
> + ret = clk_notifier_register(d->clk, &d->clk_notifier);
Okay, seems clk_notifier_register() and its counterpart should be fixed for
optional clocks.
> + if (ret)
> + dev_warn(p->dev, "Failed to set the clock notifier\n");
So, what does this warning mean on the platforms which does not need notifier
at all (i.o.w. all but baikal)?
> + /*
> + * Get current reference clock rate to make sure the UART port
> + * is equipped with an up-to-date value before it's started up.
> + */
Why? We call ->set_termios() for it, no?
> + p->uartclk = clk_get_rate(d->clk);
> + if (!p->uartclk) {
> + dev_err(p->dev, "Clock rate not defined\n");
> + return -EINVAL;
> + }
> + }
> +
> + return serial8250_do_startup(p);
> +}
> +
> +static void dw8250_shutdown(struct uart_port *p)
> +{
> + struct dw8250_data *d = to_dw8250_data(p->private_data);
> +
> + serial8250_do_shutdown(p);
> +
> + if (d->clk) {
Ditto.
> + clk_notifier_unregister(d->clk, &d->clk_notifier);
> +
> + flush_work(&d->clk_work);
> + }
> +}
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v3 1/2] thermal: core: Let thermal zone device's mode be stored in its struct
From: Andrzej Pietrasiewicz @ 2020-05-26 16:56 UTC (permalink / raw)
To: Daniel Lezcano, linux-pm
Cc: Rafael J . Wysocki, platform-driver-x86, Shawn Guo, kernel,
Fabio Estevam, Amit Kucheria, linux-acpi, NXP Linux Team,
Darren Hart, Zhang Rui, Gayatri Kammela, Len Brown,
Barlomiej Zolnierkiewicz, Sascha Hauer, Ido Schimmel, Jiri Pirko,
Thomas Gleixner, Allison Randal, linux-arm-kernel,
Support Opensource, netdev, Peter Kaestle,
Pengutronix Kernel Team, Enrico Weigelt, David S . Miller,
Andy Shevchenko
In-Reply-To: <b8b69bf3-07bf-8747-dce6-65a73c02fb88@linaro.org>
Hi Daniel,
W dniu 26.05.2020 o 00:08, Daniel Lezcano pisze:
> On 25/05/2020 21:35, Andrzej Pietrasiewicz wrote:
>> Hi Daniel,
>>
>> W dniu 23.05.2020 o 23:24, Daniel Lezcano pisze:
>>> Hi Andrzej,
>>>
>>> On 17/04/2020 18:20, Andrzej Pietrasiewicz wrote:
>>>> Thermal zone devices' mode is stored in individual drivers. This patch
>>>> changes it so that mode is stored in struct thermal_zone_device instead.
>>>>
>>>> As a result all driver-specific variables storing the mode are not
>>>> needed
>>>> and are removed. Consequently, the get_mode() implementations have
>>>> nothing
>>>> to operate on and need to be removed, too.
>>>>
>>>> Some thermal framework specific functions are introduced:
>>>>
>>>> thermal_zone_device_get_mode()
>>>> thermal_zone_device_set_mode()
>>>> thermal_zone_device_enable()
>>>> thermal_zone_device_disable()
>>>>
>>>> thermal_zone_device_get_mode() and its "set" counterpart take tzd's lock
>>>> and the "set" calls driver's set_mode() if provided, so the latter must
>>>> not take this lock again. At the end of the "set"
>>>> thermal_zone_device_update() is called so drivers don't need to
>>>> repeat this
>>>> invocation in their specific set_mode() implementations.
>>>>
>>>> The scope of the above 4 functions is purposedly limited to the thermal
>>>> framework and drivers are not supposed to call them. This encapsulation
>>>> does not fully work at the moment for some drivers, though:
>>>>
>>>> - platform/x86/acerhdf.c
>>>> - drivers/thermal/imx_thermal.c
>>>> - drivers/thermal/intel/intel_quark_dts_thermal.c
>>>> - drivers/thermal/of-thermal.c
>>>>
>>>> and they manipulate struct thermal_zone_device's members directly.
>>>>
>>>> struct thermal_zone_params gains a new member called initial_mode, which
>>>> is used to set tzd's mode at registration time.
>>>>
>>>> The sysfs "mode" attribute is always exposed from now on, because all
>>>> thermal zone devices now have their get_mode() implemented at the
>>>> generic
>>>> level and it is always available. Exposing "mode" doesn't hurt the
>>>> drivers
>>>> which don't provide their own set_mode(), because writing to "mode" will
>>>> result in -EPERM, as expected.
>>>
>>> The result is great, that is a nice cleanup of the thermal framework.
>>>
>>> After review it appears there are still problems IMO, especially with
>>> the suspend / resume path. The patch is big, it is a bit complex to
>>> comment. I suggest to re-org the changes as following:
>>>
>>> - patch 1 : Add the four functions:
>>>
>>> * thermal_zone_device_set_mode()
>>> * thermal_zone_device_enable()
>>> * thermal_zone_device_disable()
>>> * thermal_zone_device_is_enabled()
>>>
>>> *but* do not export thermal_zone_device_set_mode(), it must stay private
>>> to the thermal framework ATM.
>>
>> Not exporting thermal_zone_device_set_mode() implies not exporting
>> thermal_zone_device_enable()/thermal_zone_device_disable() because they
>> are implemented in terms of the former. Or do you have a different idea?
>
> I meant no inline for them but as below:
>
> in .h
>
> extern int thermal_zone_device_enable();
> extern int thermal_zone_device_disable();
> extern int thermal_zone_device_is_enabled();
>
> in .c
>
> static int thermal_zone_device_set_mode()
> {
> ...
> }
>
> int thermal_zone_device_enable()
> {
> thermal_zone_device_set_mode();
> }
> EXPORT_SYMBOL_GPL(thermal_zone_device_enable);
>
Hmm. I'm trying to proceed according to what you outline, but it
doesn't feel the right approach. Let me show you patch 1:
drivers/thermal/thermal_core.c:
+int thermal_zone_device_set_mode(struct thermal_zone_device *tz,
+ enum thermal_device_mode mode)
+{
+ int ret = 0;
+
+ mutex_lock(&tz->lock);
+
+ if (tz->ops->set_mode)
+ ret = tz->ops->set_mode(tz, mode);
+
+ mutex_unlock(&tz->lock);
+
+ thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
+
+ return ret;
+}
+
+int thermal_zone_device_enable(struct thermal_zone_device *tz)
+{
+ return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_ENABLED);
+}
+EXPORT_SYMBOL(thermal_zone_device_enable);
+
+int thermal_zone_device_disable(struct thermal_zone_device *tz)
+{
+ return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_DISABLED);
+}
+EXPORT_SYMBOL(thermal_zone_device_disable);
+
+int thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
+{
+ enum thermal_device_mode mode = THERMAL_DEVICE_ENABLED;
+ int ret;
+
+ mutex_lock(&tz->lock);
+
+ if (tz->ops->get_mode)
+ ret = tz->ops->get_mode(tz, &mode);
+
+ mutex_unlock(&tz->lock);
+
+ return mode == THERMAL_DEVICE_ENABLED;
+}
+EXPORT_SYMBOL(thermal_zone_device_is_enabled);
+
plus prototypes of all except set_mode in include/linux/thermal.h
I can see 2 problems:
1) we add unused code to the kernel (perhaps this is ok if patches in this
series will start using it)
2) tzd *does not* store mode. These are drivers that provide mode access
with get_mode()/set_mode() - if they implement them. What if they don't?
If thermal_zone_device_set_mode() is introduced now its effect depends on
whether a driver implements set_mode() or not. If it doesn't then despite
thermal_zone_device_set_mode() being invoked the mode is not changed.
Then what does thermal_zone_device_is_enabled() mean? We don't know, because
we don't know what the effect of thermal_zone_device_set_mode() is in the
first place. And if the driver does not provide get_mode() then
thermal_zone_device_is_enabled() always returns "enabled".
Adding these functions now without mode being stored in tzd seems awkward
to me. Consequently, IMO the first thing to do is make tzd store device's
mode and this way be independent from whether drivers implement or not
implement get_mode()/set_mode().
>
>>> - patch 2 : Add the mode THERMAL_DEVICE_SUSPENDED
>>>
>>> In the thermal_pm_notify() in the:
>>>
>>> - PM_SUSPEND_PREPARE case, set the mode to THERMAL_DEVICE_SUSPENDED if
>>> the mode is THERMAL_DEVICE_ENABLED
>>>
>>> - PM_POST_SUSPEND case, set the mode to THERMAL_DEVICE_ENABLED, if the
>>> mode is THERMAL_DEVICE_SUSPENDED
>>>
drivers/thermal/thermal_core.c:
case PM_HIBERNATION_PREPARE:
case PM_RESTORE_PREPARE:
case PM_SUSPEND_PREPARE:
+ list_for_each_entry(tz, &thermal_tz_list, node) {
+ tz_mode = THERMAL_DEVICE_ENABLED;
+ if (tz->ops->get_mode)
+ tz->ops->get_mode(tz, &tz_mode);
+ if (tz_mode == THERMAL_DEVICE_ENABLED)
+ thermal_zone_device_set_mode(tz,
+ THERMAL_DEVICE_SUSPENDED);
+ }
atomic_set(&in_suspend, 1);
break;
case PM_POST_HIBERNATION:
@@ -1530,6 +1538,9 @@ static int thermal_pm_notify(struct notifier_block *nb,
tz_mode = THERMAL_DEVICE_ENABLED;
if (tz->ops->get_mode)
tz->ops->get_mode(tz, &tz_mode);
if (tz_mode == THERMAL_DEVICE_DISABLED)
continue;
+ if (tz_mode == THERMAL_DEVICE_SUSPENDED)
+ thermal_zone_device_set_mode(tz,
+ THERMAL_DEVICE_ENABLED);
include/linux/thermal.h:
enum thermal_device_mode {
THERMAL_DEVICE_DISABLED = 0,
THERMAL_DEVICE_ENABLED,
+ THERMAL_DEVICE_SUSPENDED,
We don't know if set_mode() was effective in PM_SUSPEND_PREPARE_PATH.
If it wasn't then instead of being SUSPENDED the device is still ENABLED.
If still enabled it doesn't need enabling so the last "if" does the
right thing, but does not feel right.
>>> - patch 3 : Change the monitor function
>>>
>>> Change monitor_thermal_zone() function to set the polling to zero if the
>>> mode is THERMAL_DEVICE_DISABLED
>>
>> So we assume this: if a driver creates a tz which is initially ENABLED,
>> it will be polled. If a driver creates a tz which is initially DISABLED
>> (which is what you suggest the drivers should be doing, but not all of them
>> do), it won't be polled unless the driver explicitly enables its tz.
>
> Yes.
>
>> Am I concluding right that a suspended device will remain polled? Is it ok?
>
> Actually it is not ok but AFAICT, it is the current behavior. The
> polling do not stop but the 'in_suspend' prevent an update. I thought we
> can post-pone the suspend case later when the ENABLED/DISABLED changes
> are consolidated, so SUSPENDED will act as DISABLED.
>
drivers/thermal/thermal_core.c:
static void monitor_thermal_zone(struct thermal_zone_device *tz)
{
+ enum thermal_device_mode tz_mode = THERMAL_DEVICE_ENABLED;
+
mutex_lock(&tz->lock);
- if (tz->passive)
+ if (tz->ops->get_mode)
+ tz->ops->get_mode(tz, &tz_mode);
+
+ if (tz->passive && mode != THERMAL_DEVICE_DISABLED)
thermal_zone_device_set_polling(tz, tz->passive_delay);
- else if (tz->polling_delay)
+ else if (tz->polling_delay && mode != THERMAL_DEVICE_DISABLED)
thermal_zone_device_set_polling(tz, tz->polling_delay);
else
thermal_zone_device_set_polling(tz, 0);
If the driver does not implement get_mode() then we assume ENABLED.
What if it is actually DISABLED?
How does this depend on patch 1 or patch 2?
>>> - patch 4 : Do the changes to remove get_mode() ops
>>>
>>> Make sure there is no access to tz->mode from the drivers anymore but
>>> use of the functions of patch 1. IMO, this is the tricky part because a
>>> part of the drivers are not calling the update after setting the mode
>>> while the function thermal_zone_device_enable()/disable() call update
>>> via the thermal_zone_device_set_mode(), so we must be sure to not break
>>> anything.
>>
I haven't started this yet, but again it seems to me that drivers need
to start storing their mode in tzd->mode in the first place
So what I envision is this:
1) Make all drivers store their state still locally, but using the enum
(not all of them do)
2) Once all drivers store their state in the enum, store the enum in
struct tzd instead of locally in drivers. This makes get_mode() driver
op redundant, but if you prefer more granularity removing it might be
done in a separate patch (at the expense of modifying it now to use
tzd's member instead of driver-local variable). This also impacts set_mode()
ops, because they need to actually change tzd's member instead of some
driver-level variable. Changing set_mode() IMO needs to be done in one go.
3) Remove get_mode() driver op altogether, as the mode is stored in
struct tzd.
4) patch 1 you outlined - set_mode() and is_enabled() will now operate
on tzd's members, so their effect does not depend on drivers implementing
or not implementing set_mode(). These effects don't depend on get_mode()
any more because of 3). set_mode() would still be calling the set_mode()
op in drivers before modifying tzd->mode.
5) patch 2 you outlined - but it can't use thermal_zone_device_set_mode(),
because if it gets and then changes tzd's mode, it must do so under
tzd->lock. This is ok as this is the very implementation of thermal_core,
so accessing "private" members of tzd is a valid approach here.
6) patch 3 you outlined - now it makes much more sense to query tzd's member
for mode instead of relying on drivers implementing get_mode().
7) patch 4 you outlined but under a different name, because get_mode()
is already gone. The guts of the patch should be doing what you wrote,
though, which is use the helpers instead of directly modifying tzd's
members in drivers.
8) patch 5 you outlined - perhaps under a different name, but still
doing the same thing: removing portions of code which set polling time to
zero in drivers, as that is already being done at tzd's level. This would
hopefully make at least some set_mode() implementations no-ops and,
consequently, redundant. I can see these drivers: mellanox, part of
acerhdf (this driver wants to know when it is becoming enabled/disabled,
but the part setting polling can be removed), part of imx (similar
situation to that of acerhdf) and of-thermal.
After 8) there would be 5 non-empty set_mode() implementations:
acpi - but apparently only to print some debug, maybe can be removed
acerhdf - no idea if it can live without knowing when the mode changes
imx - ditto
int3400 - ditto
quark - ditto
Perhaps after 8) instead of removing set_mode() maybe we should change
its name to better reflect its purpose: mode_changing() ? Or maybe
even such a change should be a part of 4)?
Regards,
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 23/26] KVM: arm64: Move SPSR_EL1 to the system register array
From: James Morse @ 2020-05-26 16:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-24-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> SPSR_EL1 being a VNCR-capable register with ARMv8.4-NV, move it to
> the sysregs array and update the accessors.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 22/26] KVM: arm64: Disintegrate SPSR array
From: James Morse @ 2020-05-26 16:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-23-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> As we're about to move SPSR_EL1 into the VNCR page, we need to
> disassociate it from the rest of the 32bit cruft. Let's break
> the array into individual fields.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 21/26] KVM: arm64: Move SP_EL1 to the system register array
From: James Morse @ 2020-05-26 16:29 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Mark Rutland, Will Deacon, Suzuki K Poulose, Andre Przywara,
Christoffer Dall, Dave Martin, George Cherian, Zengtao (B),
Catalin Marinas, Alexandru Elisei, Jintack Lim, Julien Thierry
In-Reply-To: <20200422120050.3693593-22-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> SP_EL1 being a VNCR-capable register with ARMv8.4-NV, move it to the
> system register array and update the accessors.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 20/26] KVM: arm64: Move ELR_EL1 to the system register array
From: James Morse @ 2020-05-26 16:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-21-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> As ELR-EL1 is a VNCR-capable register with ARMv8.4-NV, let's move it to
> the sys_regs array and repaint the accessors. While we're at it, let's
> kill the now useless accessors used only on the fault injection path.
Reviewed-by: James Morse <james.morse@arm.com>
A curiosity:
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 95977b80265ce..46949fce3e813 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -184,6 +184,8 @@ enum vcpu_sysreg {
Comment above the enum has some claims about the order, but its already out of order with
__vcpu_read_sys_reg_from_cpu()... (PAR_EL1 being the culprit)
(I think it only matters for searching by encoding, which is checked at boot.)
> APGAKEYLO_EL1,
> APGAKEYHI_EL1,
>
> + ELR_EL1,
> +
> /* 32bit specific registers. Keep them at the end of the range */
> DACR32_EL2, /* Domain Access Control Register */
> IFSR32_EL2, /* Instruction Fault Status Register */
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 5bda4af36a0e7..7c2fffb20c217 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -95,6 +95,7 @@ static bool __vcpu_read_sys_reg_from_cpu(int reg, u64 *val)
> case TPIDR_EL1: *val = read_sysreg_s(SYS_TPIDR_EL1); break;
> case AMAIR_EL1: *val = read_sysreg_s(SYS_AMAIR_EL12); break;
> case CNTKCTL_EL1: *val = read_sysreg_s(SYS_CNTKCTL_EL12); break;
> + case ELR_EL1: *val = read_sysreg_s(SYS_ELR_EL12); break;
> case PAR_EL1: *val = read_sysreg_s(SYS_PAR_EL1); break;
> case DACR32_EL2: *val = read_sysreg_s(SYS_DACR32_EL2); break;
> case IFSR32_EL2: *val = read_sysreg_s(SYS_IFSR32_EL2); break;
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 19/26] KVM: arm64: Make struct kvm_regs userspace-only
From: James Morse @ 2020-05-26 16:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-20-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> struct kvm_regs is used by userspace to indicate which register gets
> accessed by the {GET,SET}_ONE_REG API. But as we're about to refactor
> the layout of the in-kernel register structures, we need the kernel to
> move away from it.
>
> Let's make kvm_regs userspace only, and let the kernel map it to its own
> internal representation.
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 23ebe51410f06..9fec9231b63e2 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -102,6 +102,55 @@ static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
> return size;
> }
>
> +static void *core_reg_addr(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> +{
> + u64 off = core_reg_offset_from_id(reg->id);
> +
> + switch (off) {
> + default:
> + return NULL;
Doesn't this switch statement catch an out of range offset, and a misaligned offset?
... We still test for those explicitly in the caller. Better safe than implicit?
> + }
> +}
With the reset thing reported by Zenghui and Zengtao on the previous patch fixed:
Reviewed-by: James Morse <james.morse@arm.com>
(otherwise struct kvm_regs isn't userspace-only!)
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 11/26] KVM: arm64: Add missing reset handlers for PMU emulation
From: James Morse @ 2020-05-26 16:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-12-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> As we're about to become a bit more harsh when it comes to the lack of
> reset callbacks, let's add the missing PMU reset handlers. Note that
> these only cover *CLR registers that were always covered by their *SET
> counterpart, so there is no semantic change here.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/26] KVM: arm64: Refactor vcpu_{read,write}_sys_reg
From: James Morse @ 2020-05-26 16:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, kvmarm, Will Deacon, George Cherian,
Julien Thierry, Zengtao (B), Catalin Marinas, Alexandru Elisei,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200422120050.3693593-11-maz@kernel.org>
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
> Extract the direct HW accessors for later reuse.
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 51db934702b64..46f218982df8c 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> +u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
> +{
> + u64 val = 0x8badf00d8badf00d;
> +
> + if (!vcpu->arch.sysregs_loaded_on_cpu) {
> + goto memory_read;
> }
>
> -immediate_write:
> + if (__vcpu_read_sys_reg_from_cpu(reg, &val))
> + return val;
> +
> +memory_read:
> + return __vcpu_sys_reg(vcpu, reg);
> +}
The goto here is a bit odd, is it just an artefact of how we got here?
Is this easier on the eye?:
| u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
| {
| u64 val = 0x8badf00d8badf00d;
|
| if (vcpu->arch.sysregs_loaded_on_cpu &&
| __vcpu_read_sys_reg_from_cpu(reg, &val))
| return val;
|
| return __vcpu_sys_reg(vcpu, reg);
| }
> +void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
> +{
> + if (!vcpu->arch.sysregs_loaded_on_cpu)
> + goto memory_write;
> +
> + if (__vcpu_write_sys_reg_to_cpu(val, reg))
> + return;
> +
> +memory_write:
> __vcpu_sys_reg(vcpu, reg) = val;
> }
Again I think its clearer without the goto....
Regardless:
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] KVM: arm64: Add emulation for 32bit guests accessing ACTLR2
From: James Morse @ 2020-05-26 16:18 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <20200526161834.29165-1-james.morse@arm.com>
ACTLR_EL1 is a 64bit register while the 32bit ACTLR is obviously 32bit.
For 32bit software, the extra bits are accessible via ACTLR2... which
KVM doesn't emulate.
Signed-off-by: James Morse <james.morse@arm.com>
---
I'm not convinced this is endian safe, but it does match what
kvm_inject_undef32() do.
The alternative would be to always read the 64bit value, and generate
the 32bit offets like access_vm_reg() does.
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/sys_regs_generic_v8.c | 16 +++++++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 32c8a675e5a4..5b7538663a8e 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -185,6 +185,7 @@ enum vcpu_sysreg {
#define c0_CSSELR (CSSELR_EL1 * 2)/* Cache Size Selection Register */
#define c1_SCTLR (SCTLR_EL1 * 2) /* System Control Register */
#define c1_ACTLR (ACTLR_EL1 * 2) /* Auxiliary Control Register */
+#define c1_ACTLR2 (c1_ACTLR + 1) /* ACTLR top 32 bits */
#define c1_CPACR (CPACR_EL1 * 2) /* Coprocessor Access Control */
#define c2_TTBR0 (TTBR0_EL1 * 2) /* Translation Table Base Register 0 */
#define c2_TTBR0_high (c2_TTBR0 + 1) /* TTBR0 top 32 bits */
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index 9cb6b4c8355a..ed77bbb48e64 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -30,6 +30,18 @@ static bool access_actlr(struct kvm_vcpu *vcpu,
return true;
}
+static bool access_cp15_actlr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ if (p->is_write)
+ return ignore_write(vcpu, p);
+
+ p->regval = vcpu_cp15(vcpu, r->reg);
+ return true;
+
+}
+
static void reset_actlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
{
__vcpu_sys_reg(vcpu, ACTLR_EL1) = read_sysreg(actlr_el1);
@@ -46,7 +58,9 @@ static const struct sys_reg_desc genericv8_sys_regs[] = {
static const struct sys_reg_desc genericv8_cp15_regs[] = {
/* ACTLR */
{ Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b001),
- access_actlr },
+ access_cp15_actlr, NULL, c1_ACTLR },
+ { Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b011),
+ access_cp15_actlr, NULL, c1_ACTLR2 },
};
static struct kvm_sys_reg_target_table genericv8_target_table = {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: Stop save/restoring ACTLR_EL1
From: James Morse @ 2020-05-26 16:18 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <20200526161834.29165-1-james.morse@arm.com>
KVM sets HCR_EL2.TACR (which it calls HCR_TAC) via HCR_GUEST_FLAGS.
This means ACTLR* accesses from the guest are always trapped, and
always return the value in the sys_regs array.
The guest can't change the value of these registers, so we are
save restoring the reset value, which came from the host.
Stop save/restoring this register.
This also stops this register being affected by sysregs_loaded_on_cpu,
so we can provide 32 bit accessors that always use the in-memory copy.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/kvm/hyp/sysreg-sr.c | 2 --
arch/arm64/kvm/sys_regs.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 75b1925763f1..57116cf3a1a5 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -44,7 +44,6 @@ static void __hyp_text __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
{
ctxt->sys_regs[CSSELR_EL1] = read_sysreg(csselr_el1);
ctxt->sys_regs[SCTLR_EL1] = read_sysreg_el1(SYS_SCTLR);
- ctxt->sys_regs[ACTLR_EL1] = read_sysreg(actlr_el1);
ctxt->sys_regs[CPACR_EL1] = read_sysreg_el1(SYS_CPACR);
ctxt->sys_regs[TTBR0_EL1] = read_sysreg_el1(SYS_TTBR0);
ctxt->sys_regs[TTBR1_EL1] = read_sysreg_el1(SYS_TTBR1);
@@ -133,7 +132,6 @@ static void __hyp_text __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
isb();
}
- write_sysreg(ctxt->sys_regs[ACTLR_EL1], actlr_el1);
write_sysreg_el1(ctxt->sys_regs[CPACR_EL1], SYS_CPACR);
write_sysreg_el1(ctxt->sys_regs[TTBR0_EL1], SYS_TTBR0);
write_sysreg_el1(ctxt->sys_regs[TTBR1_EL1], SYS_TTBR1);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2eda539f3281..aae58513025c 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -81,7 +81,6 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg)
switch (reg) {
case CSSELR_EL1: return read_sysreg_s(SYS_CSSELR_EL1);
case SCTLR_EL1: return read_sysreg_s(SYS_SCTLR_EL12);
- case ACTLR_EL1: return read_sysreg_s(SYS_ACTLR_EL1);
case CPACR_EL1: return read_sysreg_s(SYS_CPACR_EL12);
case TTBR0_EL1: return read_sysreg_s(SYS_TTBR0_EL12);
case TTBR1_EL1: return read_sysreg_s(SYS_TTBR1_EL12);
@@ -124,7 +123,6 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
switch (reg) {
case CSSELR_EL1: write_sysreg_s(val, SYS_CSSELR_EL1); return;
case SCTLR_EL1: write_sysreg_s(val, SYS_SCTLR_EL12); return;
- case ACTLR_EL1: write_sysreg_s(val, SYS_ACTLR_EL1); return;
case CPACR_EL1: write_sysreg_s(val, SYS_CPACR_EL12); return;
case TTBR0_EL1: write_sysreg_s(val, SYS_TTBR0_EL12); return;
case TTBR1_EL1: write_sysreg_s(val, SYS_TTBR1_EL12); return;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] KVM: arm64: Stop writing aarch32's CSSELR into ACTLR
From: James Morse @ 2020-05-26 16:18 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Marc Zyngier, James Morse, stable, Julien Thierry,
Suzuki K Poulose
In-Reply-To: <20200526161834.29165-1-james.morse@arm.com>
aarch32 has pairs of registers to access the high and low parts of 64bit
registers. KVM has a union of 64bit sys_regs[] and 32bit copro[]. The
32bit accessors read the high or low part of the 64bit sys_reg[] value
through the union.
Both sys_reg_descs[] and cp15_regs[] list access_csselr() as the accessor
for CSSELR{,_EL1}. access_csselr() is only aware of the 64bit sys_regs[],
and expects r->reg to be 'CSSELR_EL1' in the enum, index 2 of the 64bit
array.
cp15_regs[] uses the 32bit copro[] alias of sys_regs[]. Here CSSELR is
c0_CSSELR which is the same location in sys_reg[]. r->reg is 'c0_CSSELR',
index 4 in the 32bit array.
access_csselr() uses the 32bit r->reg value to access the 64bit array,
so reads and write the wrong value. sys_regs[4], is ACTLR_EL1, which
is subsequently save/restored when we enter the guest.
ACTLR_EL1 is supposed to be read-only for the guest. This register
only affects execution at EL1, and the host's value is restored before
we return to host EL1.
Rename access_csselr() to access_csselr_el1(), to indicate it expects
the 64bit register index, and pass it CSSELR_EL1 from cp15_regs[].
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
----
Providing access_csselr_cp15() wouldn't work as with VHE CSSELR_EL1 is
loaded on the CPU while this code runs. access_csselr_cp15() would have
to map it back the 64bit resgister to use vcpu_write_sys_reg(). We may
as well do it in the table.
arch/arm64/kvm/sys_regs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 51db934702b6..2eda539f3281 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1302,7 +1302,7 @@ static bool access_clidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
-static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+static bool access_csselr_el1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
if (p->is_write)
@@ -1566,7 +1566,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_CCSIDR_EL1), access_ccsidr },
{ SYS_DESC(SYS_CLIDR_EL1), access_clidr },
- { SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
+ { SYS_DESC(SYS_CSSELR_EL1), access_csselr_el1, reset_unknown, CSSELR_EL1 },
{ SYS_DESC(SYS_CTR_EL0), access_ctr },
{ SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, PMCR_EL0 },
@@ -2060,7 +2060,7 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1(1), CRn( 0), CRm( 0), Op2(0), access_ccsidr },
{ Op1(1), CRn( 0), CRm( 0), Op2(1), access_clidr },
- { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr, NULL, c0_CSSELR },
+ { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr_el1, NULL, CSSELR_EL1 },
};
static const struct sys_reg_desc cp15_64_regs[] = {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] KVM: arm64: aarch32 ACTLR accesses
From: James Morse @ 2020-05-26 16:18 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose
Hello!
Patch 1 fixes an issue where the 32bit and 64bit indexes into copro[]
and sys_regs[] are muddled.
Patch 3 adds support for aarch32 accessing the top 32bits of ACTLR_EL1
via ACTLR2. Support for this register is advertised in ID_MMFR4.AC2, which
doesn't get removed by cpufeature. The register is mandatory from v8.2, but
imp-def before then.
Patch 2 stops the sys_regs[] value we use for emulation being save/restored.
This simplifies patch 3 as the aarch32 helper can rely on the in-memory copy.
I think Patch 1 is stable material, I'm not sure about 2&3.
Bonus cans of worms!:
1. How does this copro[] thing work with a big-endian host?
The cp15_regs emulation look fine as nothing uses vcpu_cp15() to read the
register, but wouldn't prepare_fault32() read the wrong end of the register
when using vcpu_cp15()?
2. How does the 32bit fault injection code work with VHE?
vcpu_cp15() modifies the in-memory copy, surely a vcpu_put() will clobber
everything it did, or fail to restore it when entering the guest.
Thanks,
James Morse (3):
KVM: arm64: Stop writing aarch32's CSSELR into ACTLR
KVM: arm64: Stop save/restoring ACTLR_EL1
KVM: arm64: Add emulation for 32bit guests accessing ACTLR2
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/hyp/sysreg-sr.c | 2 --
arch/arm64/kvm/sys_regs.c | 8 +++-----
arch/arm64/kvm/sys_regs_generic_v8.c | 16 +++++++++++++++-
4 files changed, 19 insertions(+), 8 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MIPS: BCM63xx: fix 6328 boot selection bit
From: Florian Fainelli @ 2020-05-26 16:15 UTC (permalink / raw)
To: Álvaro Fernández Rojas, tsbogend, jonas.gorski,
bcm-kernel-feedback-list, linux-mips, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200526110324.1324754-1-noltari@gmail.com>
On 5/26/2020 4:03 AM, Álvaro Fernández Rojas wrote:
> MISC_STRAP_BUS_BOOT_SEL_SHIFT is 18 according to Broadcom's GPL source code.
>
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This is correct:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes: e5766aea5b9b ("MIPS: BCM63XX: Add basic BCM6328 support")
> ---
> arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
> index bc3444cd4ef2..9ceb5e72889f 100644
> --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
> +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
> @@ -1367,8 +1367,8 @@
> #define MISC_STRAPBUS_6328_REG 0x240
> #define STRAPBUS_6328_FCVO_SHIFT 7
> #define STRAPBUS_6328_FCVO_MASK (0x1f << STRAPBUS_6328_FCVO_SHIFT)
> -#define STRAPBUS_6328_BOOT_SEL_SERIAL (1 << 28)
> -#define STRAPBUS_6328_BOOT_SEL_NAND (0 << 28)
> +#define STRAPBUS_6328_BOOT_SEL_SERIAL (1 << 18)
> +#define STRAPBUS_6328_BOOT_SEL_NAND (0 << 18)
>
> /*************************************************************************
> * _REG relative to RSET_PCIE
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] KVM: arm64: Allow in-atomic injection of SPIs
From: Marc Zyngier @ 2020-05-26 16:11 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Eric Auger, kernel-team, James Morse, Julien Thierry,
Suzuki K Poulose
On a system that uses SPIs to implement MSIs (as it would be
the case on a GICv2 system exposing a GICv2m to its guests),
we deny the possibility of injecting SPIs on the in-atomic
fast-path.
This results in a very large amount of context-switches
(roughly equivalent to twice the interrupt rate) on the host,
and suboptimal performance for the guest (as measured with
a test workload involving a virtio interface backed by vhost-net).
Given that GICv2 systems are usually on the low-end of the spectrum
performance wise, they could do without the aggravation.
We solved this for GICv3+ITS by having a translation cache. But
SPIs do not need any extra infrastructure, and can be immediately
injected in the virtual distributor as the locking is already
heavy enough that we don't need to worry about anything.
This halves the number of context switches for the same workload.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic-irqfd.c | 20 ++++++++++++++++----
arch/arm64/kvm/vgic/vgic-its.c | 3 +--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c b/arch/arm64/kvm/vgic/vgic-irqfd.c
index d8cdfea5cc96..11a9f81115ab 100644
--- a/arch/arm64/kvm/vgic/vgic-irqfd.c
+++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
@@ -107,15 +107,27 @@ int kvm_arch_set_irq_inatomic(struct kvm_kernel_irq_routing_entry *e,
struct kvm *kvm, int irq_source_id, int level,
bool line_status)
{
- if (e->type == KVM_IRQ_ROUTING_MSI && vgic_has_its(kvm) && level) {
+ if (!level)
+ return -EWOULDBLOCK;
+
+ switch (e->type) {
+ case KVM_IRQ_ROUTING_MSI: {
struct kvm_msi msi;
+ if (!vgic_has_its(kvm))
+ return -EINVAL;
+
kvm_populate_msi(e, &msi);
- if (!vgic_its_inject_cached_translation(kvm, &msi))
- return 0;
+ return vgic_its_inject_cached_translation(kvm, &msi);
}
- return -EWOULDBLOCK;
+ case KVM_IRQ_ROUTING_IRQCHIP:
+ /* Injecting SPIs is always possible in atomic context */
+ return vgic_irqfd_set_irq(e, kvm, irq_source_id, 1, line_status);
+
+ default:
+ return -EWOULDBLOCK;
+ }
}
int kvm_vgic_setup_default_irq_routing(struct kvm *kvm)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index c012a52b19f5..40cbaca81333 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -757,9 +757,8 @@ int vgic_its_inject_cached_translation(struct kvm *kvm, struct kvm_msi *msi)
db = (u64)msi->address_hi << 32 | msi->address_lo;
irq = vgic_its_check_cache(kvm, db, msi->devid, msi->data);
-
if (!irq)
- return -1;
+ return -EWOULDBLOCK;
raw_spin_lock_irqsave(&irq->irq_lock, flags);
irq->pending_latch = true;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 07/10] media: i2c: imx290: Add RAW12 mode support
From: Dave Stevenson @ 2020-05-26 16:05 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, LKML, a.brela, Peter Griffin, Sakari Ailus,
manivannan.sadhasivam, Mauro Carvalho Chehab, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <20200524192505.20682-8-andrey.konovalov@linaro.org>
Hi Andrey
Thanks for the patch.
On Sun, 24 May 2020 at 20:26, Andrey Konovalov
<andrey.konovalov@linaro.org> wrote:
>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and
> 12 bit formats. Since the driver already supports RAW10 mode, let's add
> the missing RAW12 mode as well.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 36 +++++++++++++++++++++++++++++++++---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 162c345fffac..6e70ff22bc5f 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -71,6 +71,7 @@ struct imx290 {
> struct clk *xclk;
> struct regmap *regmap;
> u8 nlanes;
> + u8 bpp;
>
> struct v4l2_subdev sd;
> struct v4l2_fwnode_endpoint ep;
> @@ -90,10 +91,12 @@ struct imx290 {
>
> struct imx290_pixfmt {
> u32 code;
> + u8 bpp;
> };
>
> static const struct imx290_pixfmt imx290_formats[] = {
> - { MEDIA_BUS_FMT_SRGGB10_1X10 },
> + { MEDIA_BUS_FMT_SRGGB10_1X10, 10 },
> + { MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
> };
>
> static const struct regmap_config imx290_regmap_config = {
> @@ -261,6 +264,18 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> { 0x300b, 0x00},
> };
>
> +static const struct imx290_regval imx290_12bit_settings[] = {
> + { 0x3005, 0x01 },
> + { 0x3046, 0x01 },
> + { 0x3129, 0x00 },
> + { 0x317c, 0x00 },
> + { 0x31ec, 0x0e },
> + { 0x3441, 0x0c },
> + { 0x3442, 0x0c },
> + { 0x300a, 0xf0 },
> + { 0x300b, 0x00 },
> +};
> +
> /* supported link frequencies */
> static const s64 imx290_link_freq_2lanes[] = {
> 891000000, /* 1920x1080 - 2 lane */
> @@ -421,7 +436,12 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> } else {
> imx290_write_reg(imx290, IMX290_PGCTRL, 0x00);
> msleep(10);
> - imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x3c);
> + if (imx290->bpp == 10)
> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
> + 0x3c);
> + else /* 12 bits per pixel */
> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
> + 0xf0);
> imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
> }
> break;
> @@ -496,7 +516,7 @@ static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> u8 nlanes = imx290->nlanes;
>
> /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> - return (link_freq * 2 * nlanes / 10);
> + return (link_freq * 2 * nlanes / imx290->bpp);
This doesn't link on a 32bit system as it's a 64bit divide:
ERROR: "__aeabi_ldivmod" [drivers/media/i2c/imx290.ko] undefined!
It ought to be using do_div().
Admittedly it didn't compile before as you still had a s64 divide by
10, but I hadn't tried that :-)
Dave
> }
>
> static int imx290_set_fmt(struct v4l2_subdev *sd,
> @@ -533,6 +553,7 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> } else {
> format = &imx290->current_format;
> imx290->current_mode = mode;
> + imx290->bpp = imx290_formats[i].bpp;
>
> if (imx290->link_freq)
> __v4l2_ctrl_s_ctrl(imx290->link_freq,
> @@ -577,6 +598,15 @@ static int imx290_write_current_format(struct imx290 *imx290)
> return ret;
> }
> break;
> + case MEDIA_BUS_FMT_SRGGB12_1X12:
> + ret = imx290_set_register_array(imx290, imx290_12bit_settings,
> + ARRAY_SIZE(
> + imx290_12bit_settings));
> + if (ret < 0) {
> + dev_err(imx290->dev, "Could not set format registers\n");
> + return ret;
> + }
> + break;
> default:
> dev_err(imx290->dev, "Unknown pixel format\n");
> return -EINVAL;
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 3/3] serial: 8250_dw: Fix common clocks usage race condition
From: Serge Semin @ 2020-05-26 16:03 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko
Cc: Arnd Bergmann, linux-kernel, Russell King, Maxime Ripard,
Alexey Malahov, Serge Semin, Serge Semin, linux-serial,
linux-mips, Will Deacon, linux-arm-kernel
In-Reply-To: <20200526160316.26136-1-Sergey.Semin@baikalelectronics.ru>
The race condition may happen if the UART reference clock is shared with
some other device (on Baikal-T1 SoC it's another DW UART port). In this
case if that device changes the clock rate while serial console is using
it the DW 8250 UART port might not only end up with an invalid uartclk
value saved, but may also experience a distorted output data since
baud-clock could have been changed. In order to fix this lets at least
try to adjust the 8250 port setting like UART clock rate in case if the
reference clock rate change is discovered. The driver will call the new
method to update 8250 UART port clock rate settings. It's done by means of
the clock event notifier registered at the port startup and unregistered
in the shutdown callback method.
Note 1. In order to avoid deadlocks we had to execute the UART port update
method in a dedicated deferred work. This is due to (in my opinion
redundant) the clock update implemented in the dw8250_set_termios()
method.
Note 2. Before the ref clock is manually changed by the custom
set_termios() function we swap the port uartclk value with new rate
adjusted to be suitable for the requested baud. It is necessary in
order to effectively disable a functionality of the ref clock events
handler for the current UART port, since uartclk update will be done
a bit further in the generic serial8250_do_set_termios() function.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
Changelog v2:
- Move exclusive ref clock lock/unlock precudures to the 8250 port
startup/shutdown methods.
- The changelog message has also been slightly modified due to the
alteration.
- Remove Alexey' SoB tag.
- Cc someone from ARM who might be concerned regarding this change.
- Cc someone from Clocks Framework to get their comments on this patch.
Changelog v3:
- Refactor the original patch to adjust the UART port divisor instead of
requesting an exclusive ref clock utilization.
---
drivers/tty/serial/8250/8250_dw.c | 114 +++++++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 12866083731d..cf4de510ab1b 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -19,6 +19,8 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/workqueue.h>
+#include <linux/notifier.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/clk.h>
@@ -43,6 +45,8 @@ struct dw8250_data {
int msr_mask_off;
struct clk *clk;
struct clk *pclk;
+ struct notifier_block clk_notifier;
+ struct work_struct clk_work;
struct reset_control *rst;
unsigned int skip_autocfg:1;
@@ -54,6 +58,16 @@ static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
return container_of(data, struct dw8250_data, data);
}
+static inline struct dw8250_data *clk_to_dw8250_data(struct notifier_block *nb)
+{
+ return container_of(nb, struct dw8250_data, clk_notifier);
+}
+
+static inline struct dw8250_data *work_to_dw8250_data(struct work_struct *work)
+{
+ return container_of(work, struct dw8250_data, clk_work);
+}
+
static inline int dw8250_modify_msr(struct uart_port *p, int offset, int value)
{
struct dw8250_data *d = to_dw8250_data(p->private_data);
@@ -260,6 +274,45 @@ static int dw8250_handle_irq(struct uart_port *p)
return 0;
}
+static void dw8250_clk_work_cb(struct work_struct *work)
+{
+ struct dw8250_data *d = work_to_dw8250_data(work);
+ struct uart_8250_port *up;
+ unsigned long rate;
+
+ rate = clk_get_rate(d->clk);
+ if (rate) {
+ up = serial8250_get_port(d->data.line);
+
+ serial8250_update_uartclk(&up->port, rate);
+ }
+}
+
+static int dw8250_clk_notifier_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct dw8250_data *d = clk_to_dw8250_data(nb);
+
+ /*
+ * We have no choice but to defer the uartclk update due to two
+ * deadlocks. First one is caused by a recursive mutex lock which
+ * happens when clk_set_rate() is called from dw8250_set_termios().
+ * Second deadlock is more tricky and is caused by an inverted order of
+ * the clk and tty-port mutexes lock. It happens if clock rate change
+ * is requested asynchronously while set_termios() is executed between
+ * tty-port mutex lock and clk_set_rate() function invocation and
+ * vise-versa. Anyway if we didn't have the reference clock alteration
+ * in the dw8250_set_termios() method we wouldn't have needed this
+ * deferred event handling complication.
+ */
+ if (event == POST_RATE_CHANGE) {
+ queue_work(system_unbound_wq, &d->clk_work);
+ return NOTIFY_OK;
+ }
+
+ return NOTIFY_DONE;
+}
+
static void
dw8250_do_pm(struct uart_port *port, unsigned int state, unsigned int old)
{
@@ -283,9 +336,16 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
clk_disable_unprepare(d->clk);
rate = clk_round_rate(d->clk, baud * 16);
if (rate > 0) {
- ret = clk_set_rate(d->clk, rate);
- if (!ret)
- p->uartclk = rate;
+ /*
+ * Premilinary set the uartclk to the new clock rate so the
+ * clock update event handler caused by the clk_set_rate()
+ * calling wouldn't actually update the UART divisor since
+ * we about to do this anyway.
+ */
+ swap(p->uartclk, rate);
+ ret = clk_set_rate(d->clk, p->uartclk);
+ if (ret)
+ swap(p->uartclk, rate);
}
clk_prepare_enable(d->clk);
@@ -312,6 +372,49 @@ static void dw8250_set_ldisc(struct uart_port *p, struct ktermios *termios)
serial8250_do_set_ldisc(p, termios);
}
+static int dw8250_startup(struct uart_port *p)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+ int ret;
+
+ /*
+ * Some platforms may provide a reference clock shared between several
+ * devices. In this case before using the serial port first we have to
+ * make sure that any clock state change is known to the UART port at
+ * least post factum.
+ */
+ if (d->clk) {
+ ret = clk_notifier_register(d->clk, &d->clk_notifier);
+ if (ret)
+ dev_warn(p->dev, "Failed to set the clock notifier\n");
+
+ /*
+ * Get current reference clock rate to make sure the UART port
+ * is equipped with an up-to-date value before it's started up.
+ */
+ p->uartclk = clk_get_rate(d->clk);
+ if (!p->uartclk) {
+ dev_err(p->dev, "Clock rate not defined\n");
+ return -EINVAL;
+ }
+ }
+
+ return serial8250_do_startup(p);
+}
+
+static void dw8250_shutdown(struct uart_port *p)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+
+ serial8250_do_shutdown(p);
+
+ if (d->clk) {
+ clk_notifier_unregister(d->clk, &d->clk_notifier);
+
+ flush_work(&d->clk_work);
+ }
+}
+
/*
* dw8250_fallback_dma_filter will prevent the UART from getting just any free
* channel on platforms that have DMA engines, but don't have any channels
@@ -407,6 +510,8 @@ static int dw8250_probe(struct platform_device *pdev)
p->serial_out = dw8250_serial_out;
p->set_ldisc = dw8250_set_ldisc;
p->set_termios = dw8250_set_termios;
+ p->startup = dw8250_startup;
+ p->shutdown = dw8250_shutdown;
p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
if (!p->membase)
@@ -468,6 +573,9 @@ static int dw8250_probe(struct platform_device *pdev)
if (IS_ERR(data->clk))
return PTR_ERR(data->clk);
+ INIT_WORK(&data->clk_work, dw8250_clk_work_cb);
+ data->clk_notifier.notifier_call = dw8250_clk_notifier_cb;
+
err = clk_prepare_enable(data->clk);
if (err)
dev_warn(dev, "could not enable optional baudclk: %d\n", err);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/3] serial: 8250_dw: Fix ref clock usage
From: Serge Semin @ 2020-05-26 16:03 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: Maxime Ripard, Alexey Kolotnikov, Vadim Vlasov, Maxim Kaurkin,
Ramil Zaripov, linux-mips, linux-kernel, Russell King,
Serge Semin, Alexey Malahov, Serge Semin, Arnd Bergmann,
Pavel Parkhomenko, Ekaterina Skachko, linux-serial,
Andy Shevchenko, Will Deacon, linux-arm-kernel
Greg, Jiri, the merge window is upon us, please review/merge in/whatever
the rest of the patches.
It might be dangerous if an UART port reference clock rate is suddenly
changed. In particular the 8250 port drivers (and AFAICS most of the tty
drivers using common clock framework clocks) rely either on the
exclusive reference clock utilization or on the ref clock rate being
always constant. Needless to say that it turns out not true and if some
other service suddenly changes the clock rate behind an UART port driver
back it's no good. So the port might not only end up with an invalid
uartclk value saved, but may also experience a distorted output/input
data since such action will effectively update the programmed baud-clock.
We discovered such problem on Baikal-T1 SoC where two DW 8250 ports have
got a shared reference clock. Allwinner SoC is equipped with an UART,
which clock is derived from the CPU PLL clock source, so the CPU frequency
change might be propagated down up to the serial port reference clock.
This patchset provides a way to fix the problem to the 8250 serial port
controllers and mostly fixes it for the DW 8250-compatible UART. I say
mostly because due to not having a facility to pause/stop and resume/
restart on-going transfers we implemented the UART clock rate update
procedure executed post factum of the actual reference clock rate change.
In addition the patchset includes a few fixes we discovered when were
working the issue. First one concerns the maximum baud rate setting used
to determine a serial port baud based on the current UART port clock rate.
Another one simplifies the ref clock rate setting procedure a bit.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v3:
- Refactor the original patch to adjust the UART port divisor instead of
requesting an exclusive ref clock utilization.
Changelog v4:
- Discard commit b426bf0fb085 ("serial: 8250: Fix max baud limit in generic
8250 port") since Greg has already merged it into the tty-next branch.
- Use EXPORT_SYMBOL_GPL() for the serial8250_update_uartclk() method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (3):
serial: 8250: Add 8250 port clock update method
serial: 8250_dw: Simplify the ref clock rate setting procedure
serial: 8250_dw: Fix common clocks usage race condition
drivers/tty/serial/8250/8250_dw.c | 125 +++++++++++++++++++++++++---
drivers/tty/serial/8250/8250_port.c | 38 +++++++++
include/linux/serial_8250.h | 2 +
3 files changed, 153 insertions(+), 12 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox