* Re: [PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Bjorn Andersson @ 2019-08-27 16:10 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, kernel, Geert Uytterhoeven, Tony Lindgren,
Catalin Marinas, Linus Walleij, Thierry Reding, Miquel Raynal,
groeck, Leonard Crestez, lee.jones, Marek Szyprowski,
Maxime Ripard, linux-samsung-soc, Anson Huang, Will Deacon,
Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Arnd Bergmann, Robert Jarzmik, soc,
linux-tegra, Simon Horman, Fabrice Gasnier, bleung,
linux-arm-kernel, linux-kernel, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <20190827154851.10486-1-enric.balletbo@collabora.com>
On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
> Recently we refactored the CrOS EC drivers moving part of the code from
> the MFD subsystem to the platform chrome subsystem. During this change
> we needed to rename some config options, so, update the defconfigs
> accordingly.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
> Tested-by: Gwendal Grignou <gwendal@chromium.org>
Can we make the entries in the generic arm64 defconfig modules?
Regards,
Bjorn
> ---
> Dear all,
>
> This is basically a resend of [1] in order to get patch into the arm-soc
> patchwork and can be merged independently of the series. The patch was
> originally sent as part of the these series [2] but as defconfig changes
> often cause merge conflicts the maintainers prefer to have this merged
> through the arm-soc tree. My bad was not including the soc ML from the
> begining, so sorry about that.
>
> Thanks,
> Enric
>
> [1] https://lkml.org/lkml/2019/8/23/518
> [2] https://lkml.org/lkml/2019/8/23/475
>
> arch/arm/configs/exynos_defconfig | 6 +++++-
> arch/arm/configs/multi_v7_defconfig | 6 ++++--
> arch/arm/configs/pxa_defconfig | 4 +++-
> arch/arm/configs/tegra_defconfig | 2 +-
> arch/arm64/configs/defconfig | 6 ++++--
> 5 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 2e6a863d25aa..d29029f534ec 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -154,7 +154,11 @@ CONFIG_CPU_THERMAL=y
> CONFIG_THERMAL_EMULATION=y
> CONFIG_WATCHDOG=y
> CONFIG_S3C2410_WATCHDOG=y
> -CONFIG_MFD_CROS_EC=y
> +CONFIG_MFD_CROS_EC_DEV=y
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=y
> +CONFIG_CROS_EC_I2C=y
> +CONFIG_CROS_EC_SPI=y
> CONFIG_MFD_MAX14577=y
> CONFIG_MFD_MAX77686=y
> CONFIG_MFD_MAX77693=y
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 6a40bc2ef271..0e9e70badf88 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -511,10 +511,12 @@ CONFIG_MFD_BCM590XX=y
> CONFIG_MFD_AC100=y
> CONFIG_MFD_AXP20X_I2C=y
> CONFIG_MFD_AXP20X_RSB=y
> -CONFIG_MFD_CROS_EC=m
> +CONFIG_MFD_CROS_EC_DEV=m
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=m
> CONFIG_CROS_EC_I2C=m
> CONFIG_CROS_EC_SPI=m
> -CONFIG_MFD_CROS_EC_CHARDEV=m
> +CONFIG_CROS_EC_CHARDEV=m
> CONFIG_MFD_DA9063=m
> CONFIG_MFD_MAX14577=y
> CONFIG_MFD_MAX77686=y
> diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
> index 787c3f9be414..635bf7dec53c 100644
> --- a/arch/arm/configs/pxa_defconfig
> +++ b/arch/arm/configs/pxa_defconfig
> @@ -393,7 +393,9 @@ CONFIG_SA1100_WATCHDOG=m
> CONFIG_MFD_AS3711=y
> CONFIG_MFD_BCM590XX=m
> CONFIG_MFD_AXP20X=y
> -CONFIG_MFD_CROS_EC=m
> +CONFIG_MFD_CROS_EC_DEV=m
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=m
> CONFIG_CROS_EC_I2C=m
> CONFIG_CROS_EC_SPI=m
> CONFIG_MFD_ASIC3=y
> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
> index 8f5c6a5b444c..061037012335 100644
> --- a/arch/arm/configs/tegra_defconfig
> +++ b/arch/arm/configs/tegra_defconfig
> @@ -147,7 +147,7 @@ CONFIG_SENSORS_LM95245=y
> CONFIG_WATCHDOG=y
> CONFIG_TEGRA_WATCHDOG=y
> CONFIG_MFD_AS3722=y
> -CONFIG_MFD_CROS_EC=y
> +CONFIG_MFD_CROS_EC_DEV=y
> CONFIG_MFD_MAX8907=y
> CONFIG_MFD_STMPE=y
> CONFIG_MFD_PALMAS=y
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0e58ef02880c..c4df1999fe0d 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -457,8 +457,7 @@ CONFIG_MFD_ALTERA_SYSMGR=y
> CONFIG_MFD_BD9571MWV=y
> CONFIG_MFD_AXP20X_I2C=y
> CONFIG_MFD_AXP20X_RSB=y
> -CONFIG_MFD_CROS_EC=y
> -CONFIG_MFD_CROS_EC_CHARDEV=m
> +CONFIG_MFD_CROS_EC_DEV=y
> CONFIG_MFD_EXYNOS_LPASS=m
> CONFIG_MFD_HI6421_PMIC=y
> CONFIG_MFD_HI655X_PMIC=y
> @@ -668,8 +667,11 @@ CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_MMIO=y
> CONFIG_XEN_GNTDEV=y
> CONFIG_XEN_GRANT_DEV_ALLOC=y
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=y
> CONFIG_CROS_EC_I2C=y
> CONFIG_CROS_EC_SPI=y
> +CONFIG_CROS_EC_CHARDEV=m
> CONFIG_COMMON_CLK_RK808=y
> CONFIG_COMMON_CLK_SCPI=y
> CONFIG_COMMON_CLK_CS2000_CP=y
> --
> 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 1/3] arm64: smp: Increase secondary CPU boot timeout value
From: Mark Rutland @ 2019-08-27 16:05 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190827151815.2160-2-will@kernel.org>
On Tue, Aug 27, 2019 at 04:18:13PM +0100, Will Deacon wrote:
> When many debug options are enabled simultaneously (e.g. PROVE_LOCKING,
> KMEMLEAK, DEBUG_PAGE_ALLOC, KASAN etc), it is possible for us to timeout
> when attempting to boot a secondary CPU and give up. Unfortunately, the
> CPU will /eventually/ appear, and sit in the background happily stuck
> in a recursive exception due to a NULL stack pointer.
>
> Increase the timeout to 5s, which will of course be enough for anybody.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 018a33e01b0e..63c7a7682e93 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -123,7 +123,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * time out.
> */
> wait_for_completion_timeout(&cpu_running,
> - msecs_to_jiffies(1000));
> + msecs_to_jiffies(5000));
>
> if (!cpu_online(cpu)) {
> pr_crit("CPU%u: failed to come online\n", cpu);
> --
> 2.11.0
>
_______________________________________________
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] arm64: fix fixmap copy for 16K pages and 48-bit VA
From: Marc Zyngier @ 2019-08-27 16:04 UTC (permalink / raw)
To: Mark Rutland
Cc: Anshuman Khandual, Ard Biesheuvel, Catalin Marinas, Steve Capper,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190827155708.34699-1-mark.rutland@arm.com>
On 2019-08-27 16:57, Mark Rutland wrote:
> With 16K pages and 48-bit VAs, the PGD level of table has two
> entries,
> and so the fixmap shares a PGD with the kernel image. Since commit:
>
> f9040773b7bbbd9e ("arm64: move kernel image to base of vmalloc
> area")
>
> ... we copy the existing fixmap to the new fine-grained page tables
> at
> the PUD level in this case. When walking to the new PUD, we forgot to
> offset the PGD entry and always used the PGD entry at index 0, but
> this
> worked as the kernel image and fixmap were in the low half of the
> TTBR1
> address space.
>
> As of commit:
>
> 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
>
> ... the kernel image and fixmap are in the high half of the TTBR1
> address space, and hence use the PGD at index 1, but we didn't update
> the fixmap copying code to account for this.
>
> Thus, we'll erroneously try to copy the fixmap slots into a PUD under
> the PGD entry at index 0. At the point we do so this PGD entry has
> not
> been initialised, and thus we'll try to write a value to a small
> offset
> from physical address 0, causing a number of potential problems.
>
> Fix this be correctly offsetting the PGD. This is split over a few
> steps
> for legibility.
>
> Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
> Reported-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Steve Capper <Steve.Capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> arch/arm64/mm/mmu.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 1d4247f9a496..4197f27f86e5 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -646,6 +646,8 @@ static void __init map_kernel(pgd_t *pgdp)
> set_pgd(pgd_offset_raw(pgdp, FIXADDR_START),
> READ_ONCE(*pgd_offset_k(FIXADDR_START)));
> } else if (CONFIG_PGTABLE_LEVELS > 3) {
> + pgd_t *bm_pgdp;
> + pud_t *bm_pudp;
> /*
> * The fixmap shares its top level pgd entry with the kernel
> * mapping. This can really only occur when we are running
> @@ -653,9 +655,9 @@ static void __init map_kernel(pgd_t *pgdp)
> * entry instead.
> */
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> - pud_populate(&init_mm,
> - pud_set_fixmap_offset(pgdp, FIXADDR_START),
> - lm_alias(bm_pmd));
> + bm_pgdp = pgd_offset_raw(pgdp, FIXADDR_START);
> + bm_pudp = pud_set_fixmap_offset(bm_pgdp, FIXADDR_START);
> + pud_populate(&init_mm, bm_pudp, lm_alias(bm_pmd));
> pud_clear_fixmap();
> } else {
> BUG();
I've thrown this at a guest running on a TX1 box, and the guest
booted flawlessly, which is a major improvement.
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 2/3] arm64: smp: Don't enter kernel with NULL stack pointer or task struct
From: Mark Rutland @ 2019-08-27 16:04 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190827151815.2160-3-will@kernel.org>
On Tue, Aug 27, 2019 at 04:18:14PM +0100, Will Deacon wrote:
> Although SMP bringup is inherently racy, we can significantly reduce
> the window during which secondary CPUs can unexpectedly enter the
> kernel by sanity checking the 'stack' and 'task' fields of the
> 'secondary_data' structure. If the booting CPU gave up waiting for us,
> then they will have been cleared to NULL and we should spin in a WFE; WFI
> loop instead.
>
> Signed-off-by: Will Deacon <will@kernel.org>
In future I think that we can handle this better using the MPIDR hash
and atomics to flip the values and cater for races, but this is better
than what we have, so FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/head.S | 8 ++++++++
> arch/arm64/kernel/smp.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 2cdacd1c141b..0baadf335172 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -724,14 +724,22 @@ __secondary_switched:
>
> adr_l x0, secondary_data
> ldr x1, [x0, #CPU_BOOT_STACK] // get secondary_data.stack
> + cbz x1, __secondary_too_slow
> mov sp, x1
> ldr x2, [x0, #CPU_BOOT_TASK]
> + cbz x2, __secondary_too_slow
> msr sp_el0, x2
> mov x29, #0
> mov x30, #0
> b secondary_start_kernel
> ENDPROC(__secondary_switched)
>
> +__secondary_too_slow:
> + wfe
> + wfi
> + b __secondary_too_slow
> +ENDPROC(__secondary_too_slow)
> +
> /*
> * The booting CPU updates the failed status @__early_cpu_boot_status,
> * with MMU turned off.
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 63c7a7682e93..1f8aeb77cba5 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -136,6 +136,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>
> secondary_data.task = NULL;
> secondary_data.stack = NULL;
> + __flush_dcache_area(&secondary_data, sizeof(secondary_data));
> status = READ_ONCE(secondary_data.status);
> if (ret && status) {
>
> --
> 2.11.0
>
_______________________________________________
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 V2 07/13] dt-bindings: i2c: bcm2835: Add brcm,bcm2711 compatible
From: Rob Herring @ 2019-08-27 16:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: devicetree, Florian Fainelli, Scott Branden, Wolfram Sang,
Ray Jui, Stefan Wahren, Eric Anholt, bcm-kernel-feedback-list,
linux-i2c, linux-clk, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565713248-4906-8-git-send-email-wahrenst@gmx.net>
On Tue, 13 Aug 2019 18:20:42 +0200, Stefan Wahren wrote:
> Add a new compatible for the BCM2711, which hasn't the clock stretch bug.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 V2 03/13] dt-bindings: bcm2835-cprman: Add bcm2711 support
From: Rob Herring @ 2019-08-27 16:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: devicetree, Florian Fainelli, Scott Branden, Wolfram Sang,
Ray Jui, Stefan Wahren, Eric Anholt, bcm-kernel-feedback-list,
linux-i2c, linux-clk, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565713248-4906-4-git-send-email-wahrenst@gmx.net>
On Tue, 13 Aug 2019 18:20:38 +0200, Stefan Wahren wrote:
> The new BCM2711 supports an additional clock for the emmc2 block.
> So we need an additional compatible.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Acked-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt | 4 +++-
> include/dt-bindings/clock/bcm2835.h | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 3/3] arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
From: Mark Rutland @ 2019-08-27 15:59 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190827151815.2160-4-will@kernel.org>
On Tue, Aug 27, 2019 at 04:18:15PM +0100, Will Deacon wrote:
> When we fail to bring a secondary CPU online and it fails in an unknown
> state, we should assume the worst and increment 'cpus_stuck_in_kernel'
> so that things like kexec() are disabled.
Definitely! I has assumed we already did this, but I see that we don't.
> Signed-off-by: Will Deacon <will@kernel.org>
I don't see a nicer way of doing this, so:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/smp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 1f8aeb77cba5..dc9fe879c279 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -147,6 +147,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> default:
> pr_err("CPU%u: failed in unknown state : 0x%lx\n",
> cpu, status);
> + cpus_stuck_in_kernel++;
> break;
> case CPU_KILL_ME:
> if (!op_cpu_kill(cpu)) {
> --
> 2.11.0
>
_______________________________________________
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: fix fixmap copy for 16K pages and 48-bit VA
From: Mark Rutland @ 2019-08-27 15:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Anshuman Khandual, Ard Biesheuvel, Catalin Marinas,
Steve Capper, Marc Zyngier, Will Deacon
With 16K pages and 48-bit VAs, the PGD level of table has two entries,
and so the fixmap shares a PGD with the kernel image. Since commit:
f9040773b7bbbd9e ("arm64: move kernel image to base of vmalloc area")
... we copy the existing fixmap to the new fine-grained page tables at
the PUD level in this case. When walking to the new PUD, we forgot to
offset the PGD entry and always used the PGD entry at index 0, but this
worked as the kernel image and fixmap were in the low half of the TTBR1
address space.
As of commit:
14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
... the kernel image and fixmap are in the high half of the TTBR1
address space, and hence use the PGD at index 1, but we didn't update
the fixmap copying code to account for this.
Thus, we'll erroneously try to copy the fixmap slots into a PUD under
the PGD entry at index 0. At the point we do so this PGD entry has not
been initialised, and thus we'll try to write a value to a small offset
from physical address 0, causing a number of potential problems.
Fix this be correctly offsetting the PGD. This is split over a few steps
for legibility.
Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
Reported-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Steve Capper <Steve.Capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/mm/mmu.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 1d4247f9a496..4197f27f86e5 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -646,6 +646,8 @@ static void __init map_kernel(pgd_t *pgdp)
set_pgd(pgd_offset_raw(pgdp, FIXADDR_START),
READ_ONCE(*pgd_offset_k(FIXADDR_START)));
} else if (CONFIG_PGTABLE_LEVELS > 3) {
+ pgd_t *bm_pgdp;
+ pud_t *bm_pudp;
/*
* The fixmap shares its top level pgd entry with the kernel
* mapping. This can really only occur when we are running
@@ -653,9 +655,9 @@ static void __init map_kernel(pgd_t *pgdp)
* entry instead.
*/
BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
- pud_populate(&init_mm,
- pud_set_fixmap_offset(pgdp, FIXADDR_START),
- lm_alias(bm_pmd));
+ bm_pgdp = pgd_offset_raw(pgdp, FIXADDR_START);
+ bm_pudp = pud_set_fixmap_offset(bm_pgdp, FIXADDR_START);
+ pud_populate(&init_mm, bm_pudp, lm_alias(bm_pmd));
pud_clear_fixmap();
} else {
BUG();
--
2.11.0
_______________________________________________
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 2/2] dt-bindings: imx6q-pcie: add "fsl,pcie-phy-refclk-internal" for i.MX7D
From: Rob Herring @ 2019-08-27 15:56 UTC (permalink / raw)
To: André Draszik
Cc: Mark Rutland, devicetree, Richard Zhu, Fabio Estevam,
Sascha Hauer, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, linux-pci, Bjorn Helgaas, Shawn Guo,
linux-arm-kernel, Lucas Stach
In-Reply-To: <20190813103759.38358-2-git@andred.net>
On Tue, Aug 13, 2019 at 11:37:59AM +0100, André Draszik wrote:
> The i.MX7D variant of the IP can use either an external
> crystal oscillator input or an internal clock input as
> a reference clock input for the PCIe PHY.
>
> Document the optional property 'fsl,pcie-phy-refclk-internal'
>
> Signed-off-by: André Draszik <git@andred.net>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> 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>
> Cc: linux-pci@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index a7f5f5afa0e6..985d7083df9f 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -56,6 +56,11 @@ Additional required properties for imx7d-pcie and imx8mq-pcie:
> - "turnoff"
> - fsl,imx7d-pcie-phy: A phandle to an fsl,imx7d-pcie-phy node.
Not sure how this got in, but why is the phy binding not used here?
>
> +Additional optional properties for imx7d-pcie:
> +- fsl,pcie-phy-refclk-internal: If present then an internal PLL input is used
> + as PCIe PHY reference clock source. By default an external ocsillator input
> + is used.
Can't the clock binding and maybe 'assigned-clocks' be used here?
Also, this is a property of the PHY, so it belongs in the PHY's node.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Enric Balletbo i Serra @ 2019-08-27 15:48 UTC (permalink / raw)
To: soc
Cc: gwendal, kernel, Geert Uytterhoeven, Tony Lindgren,
Catalin Marinas, Linus Walleij, Bjorn Andersson, Thierry Reding,
Miquel Raynal, groeck, Leonard Crestez, Will Deacon,
Marek Szyprowski, Maxime Ripard, linux-samsung-soc, Anson Huang,
lee.jones, Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Arnd Bergmann, Robert Jarzmik,
linux-tegra, Simon Horman, Fabrice Gasnier, bleung,
linux-arm-kernel, linux-kernel, Yannick Fertré, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
Recently we refactored the CrOS EC drivers moving part of the code from
the MFD subsystem to the platform chrome subsystem. During this change
we needed to rename some config options, so, update the defconfigs
accordingly.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
---
Dear all,
This is basically a resend of [1] in order to get patch into the arm-soc
patchwork and can be merged independently of the series. The patch was
originally sent as part of the these series [2] but as defconfig changes
often cause merge conflicts the maintainers prefer to have this merged
through the arm-soc tree. My bad was not including the soc ML from the
begining, so sorry about that.
Thanks,
Enric
[1] https://lkml.org/lkml/2019/8/23/518
[2] https://lkml.org/lkml/2019/8/23/475
arch/arm/configs/exynos_defconfig | 6 +++++-
arch/arm/configs/multi_v7_defconfig | 6 ++++--
arch/arm/configs/pxa_defconfig | 4 +++-
arch/arm/configs/tegra_defconfig | 2 +-
arch/arm64/configs/defconfig | 6 ++++--
5 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 2e6a863d25aa..d29029f534ec 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -154,7 +154,11 @@ CONFIG_CPU_THERMAL=y
CONFIG_THERMAL_EMULATION=y
CONFIG_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
-CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_DEV=y
+CONFIG_CHROME_PLATFORMS=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_I2C=y
+CONFIG_CROS_EC_SPI=y
CONFIG_MFD_MAX14577=y
CONFIG_MFD_MAX77686=y
CONFIG_MFD_MAX77693=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6a40bc2ef271..0e9e70badf88 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -511,10 +511,12 @@ CONFIG_MFD_BCM590XX=y
CONFIG_MFD_AC100=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_MFD_AXP20X_RSB=y
-CONFIG_MFD_CROS_EC=m
+CONFIG_MFD_CROS_EC_DEV=m
+CONFIG_CHROME_PLATFORMS=y
+CONFIG_CROS_EC=m
CONFIG_CROS_EC_I2C=m
CONFIG_CROS_EC_SPI=m
-CONFIG_MFD_CROS_EC_CHARDEV=m
+CONFIG_CROS_EC_CHARDEV=m
CONFIG_MFD_DA9063=m
CONFIG_MFD_MAX14577=y
CONFIG_MFD_MAX77686=y
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index 787c3f9be414..635bf7dec53c 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -393,7 +393,9 @@ CONFIG_SA1100_WATCHDOG=m
CONFIG_MFD_AS3711=y
CONFIG_MFD_BCM590XX=m
CONFIG_MFD_AXP20X=y
-CONFIG_MFD_CROS_EC=m
+CONFIG_MFD_CROS_EC_DEV=m
+CONFIG_CHROME_PLATFORMS=y
+CONFIG_CROS_EC=m
CONFIG_CROS_EC_I2C=m
CONFIG_CROS_EC_SPI=m
CONFIG_MFD_ASIC3=y
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 8f5c6a5b444c..061037012335 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -147,7 +147,7 @@ CONFIG_SENSORS_LM95245=y
CONFIG_WATCHDOG=y
CONFIG_TEGRA_WATCHDOG=y
CONFIG_MFD_AS3722=y
-CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_DEV=y
CONFIG_MFD_MAX8907=y
CONFIG_MFD_STMPE=y
CONFIG_MFD_PALMAS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..c4df1999fe0d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -457,8 +457,7 @@ CONFIG_MFD_ALTERA_SYSMGR=y
CONFIG_MFD_BD9571MWV=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_MFD_AXP20X_RSB=y
-CONFIG_MFD_CROS_EC=y
-CONFIG_MFD_CROS_EC_CHARDEV=m
+CONFIG_MFD_CROS_EC_DEV=y
CONFIG_MFD_EXYNOS_LPASS=m
CONFIG_MFD_HI6421_PMIC=y
CONFIG_MFD_HI655X_PMIC=y
@@ -668,8 +667,11 @@ CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
+CONFIG_CHROME_PLATFORMS=y
+CONFIG_CROS_EC=y
CONFIG_CROS_EC_I2C=y
CONFIG_CROS_EC_SPI=y
+CONFIG_CROS_EC_CHARDEV=m
CONFIG_COMMON_CLK_RK808=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
--
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
* Re: [PATCH 6/6] PCI: tegra: Add support to enable slot regulators
From: Andrew Murray @ 2019-08-27 15:47 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190826073143.4582-7-vidyas@nvidia.com>
On Mon, Aug 26, 2019 at 01:01:43PM +0530, Vidya Sagar wrote:
> Add support to get regulator information of 3.3V and 12V supplies of a PCIe
> slot from the respective controller's device-tree node and enable those
> supplies. This is required in platforms like p2972-0000 where the supplies
> to x16 slot owned by C5 controller need to be enabled before attempting to
> enumerate the devices.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> drivers/pci/controller/dwc/pcie-tegra194.c | 65 ++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 8a27b25893c9..97de2151a738 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
> u32 aspm_l0s_enter_lat;
>
> struct regulator *pex_ctl_supply;
> + struct regulator *slot_ctl_3v3;
> + struct regulator *slot_ctl_12v;
>
> unsigned int phy_count;
> struct phy **phys;
> @@ -1047,6 +1049,59 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
> }
> }
>
> +static void tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> + if (IS_ERR(pcie->slot_ctl_3v3))
> + pcie->slot_ctl_3v3 = NULL;
> +
> + pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
> + if (IS_ERR(pcie->slot_ctl_12v))
> + pcie->slot_ctl_12v = NULL;
Do these need to take into consideration -EPROBE_DEFER?
Thanks,
Andrew Murray
> +}
> +
> +static int tegra_pcie_enable_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + int ret;
> +
> + if (pcie->slot_ctl_3v3) {
> + ret = regulator_enable(pcie->slot_ctl_3v3);
> + if (ret < 0) {
> + dev_err(pcie->dev,
> + "Failed to enable 3V3 slot supply: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + if (pcie->slot_ctl_12v) {
> + ret = regulator_enable(pcie->slot_ctl_12v);
> + if (ret < 0) {
> + dev_err(pcie->dev,
> + "Failed to enable 12V slot supply: %d\n", ret);
> + if (pcie->slot_ctl_3v3)
> + regulator_disable(pcie->slot_ctl_3v3);
> + return ret;
> + }
> + }
> +
> + /*
> + * According to PCI Express Card Electromechanical Specification
> + * Revision 1.1, Table-2.4, T_PVPERL (Power stable to PERST# inactive)
> + * should be a minimum of 100ms.
> + */
> + msleep(100);
> +
> + return 0;
> +}
> +
> +static void tegra_pcie_disable_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + if (pcie->slot_ctl_12v)
> + regulator_disable(pcie->slot_ctl_12v);
> + if (pcie->slot_ctl_3v3)
> + regulator_disable(pcie->slot_ctl_3v3);
> +}
> +
> static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> bool en_hw_hot_rst)
> {
> @@ -1060,6 +1115,10 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> return ret;
> }
>
> + ret = tegra_pcie_enable_slot_regulators(pcie);
> + if (ret < 0)
> + goto fail_slot_reg_en;
> +
> ret = regulator_enable(pcie->pex_ctl_supply);
> if (ret < 0) {
> dev_err(pcie->dev, "Failed to enable regulator: %d\n", ret);
> @@ -1142,6 +1201,8 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> fail_core_clk:
> regulator_disable(pcie->pex_ctl_supply);
> fail_reg_en:
> + tegra_pcie_disable_slot_regulators(pcie);
> +fail_slot_reg_en:
> tegra_pcie_bpmp_set_ctrl_state(pcie, false);
>
> return ret;
> @@ -1174,6 +1235,8 @@ static int __deinit_controller(struct tegra_pcie_dw *pcie)
> return ret;
> }
>
> + tegra_pcie_disable_slot_regulators(pcie);
> +
> ret = tegra_pcie_bpmp_set_ctrl_state(pcie, false);
> if (ret) {
> dev_err(pcie->dev, "Failed to disable controller %d: %d\n",
> @@ -1372,6 +1435,8 @@ static int tegra_pcie_dw_probe(struct platform_device *pdev)
> return ret;
> }
>
> + tegra_pcie_get_slot_regulators(pcie);
> +
> pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
> if (IS_ERR(pcie->pex_ctl_supply)) {
> dev_err(dev, "Failed to get regulator: %ld\n",
> --
> 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
* Re: [PATCH 3/6] PCI: tegra: Add support to configure sideband pins
From: Vidya Sagar @ 2019-08-27 15:40 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190827153029.GO14582@e119886-lin.cambridge.arm.com>
On 8/27/2019 9:00 PM, Andrew Murray wrote:
> On Mon, Aug 26, 2019 at 01:01:40PM +0530, Vidya Sagar wrote:
>> Add support to configure sideband signal pins when information is present
>> in respective controller's device-tree node.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> ---
>> drivers/pci/controller/dwc/pcie-tegra194.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>> index fc0dbeb31d78..8a27b25893c9 100644
>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>> @@ -1308,6 +1308,12 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
>> return ret;
>> }
>>
>> + ret = pinctrl_pm_select_default_state(pcie->dev);
>> + if (ret < 0) {
>> + dev_err(pcie->dev, "Failed to configure sideband pins\n");
>
> I think you can just use dev instead of pcie->dev here.
Yup. I can use just 'dev' here.
>
>> + return ret;
>
> Don't you need to pm_runtime_put_sync and pm_runtime_disable here?
Yup. Thanks for catching it. I'll address it in next patch series.
>
> Thanks,
>
> Andrew Murray
>
>> + }
>> +
>> tegra_pcie_init_controller(pcie);
>>
>> pcie->link_state = tegra_pcie_dw_link_up(&pcie->pci);
>> --
>> 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
* Re: [PATCH 3/6] PCI: tegra: Add support to configure sideband pins
From: Andrew Murray @ 2019-08-27 15:30 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190826073143.4582-4-vidyas@nvidia.com>
On Mon, Aug 26, 2019 at 01:01:40PM +0530, Vidya Sagar wrote:
> Add support to configure sideband signal pins when information is present
> in respective controller's device-tree node.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> drivers/pci/controller/dwc/pcie-tegra194.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index fc0dbeb31d78..8a27b25893c9 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -1308,6 +1308,12 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
> return ret;
> }
>
> + ret = pinctrl_pm_select_default_state(pcie->dev);
> + if (ret < 0) {
> + dev_err(pcie->dev, "Failed to configure sideband pins\n");
I think you can just use dev instead of pcie->dev here.
> + return ret;
Don't you need to pm_runtime_put_sync and pm_runtime_disable here?
Thanks,
Andrew Murray
> + }
> +
> tegra_pcie_init_controller(pcie);
>
> pcie->link_state = tegra_pcie_dw_link_up(&pcie->pci);
> --
> 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
* Re: [PATCH v5 17/18] dt-bindings: thermal: add binding document for r40 thermal controller
From: Rob Herring @ 2019-08-27 15:27 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-18-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:28 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner r40 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] fdt: Update CRC check for rng-seed
From: Will Deacon @ 2019-08-27 15:27 UTC (permalink / raw)
To: Hsin-Yi Wang; +Cc: Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190827103353.109218-1-hsinyi@chromium.org>
On Tue, Aug 27, 2019 at 06:33:53PM +0800, Hsin-Yi Wang wrote:
> Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
> from early_init_dt_verify() to early_init_dt_scan() since
> early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
>
> However, arm and some other arch won't call early_init_dt_scan(), they
> call early_init_dt_verify() then early_init_dt_scan_nodes().
>
> Restore of_fdt_crc32 to early_init_dt_verify() then update it in
> early_init_dt_scan_chosen() if fdt if updated.
>
> Fixes: 428826f5358c ("fdt: add support for rng-seed")
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
> drivers/of/fdt.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, I'll queue this up with the tags from Geert.
Will
_______________________________________________
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 v5 14/18] dt-bindings: thermal: add binding document for h5 thermal controller
From: Rob Herring @ 2019-08-27 15:27 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-15-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:25 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner h5 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v5 12/18] dt-bindings: thermal: add binding document for a64 thermal controller
From: Rob Herring @ 2019-08-27 15:26 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-13-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:23 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner a64 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v5 10/18] dt-bindings: thermal: add binding document for h3 thermal controller
From: Rob Herring @ 2019-08-27 15:26 UTC (permalink / raw)
To: Yangtao Li
Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
daniel.lezcano, linux-kernel, edubezval, Yangtao Li, wens,
robh+dt, Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
linux-arm-kernel
In-Reply-To: <20190810052829.6032-11-tiny.windzz@gmail.com>
On Sat, 10 Aug 2019 05:28:21 +0000, Yangtao Li wrote:
> This patch adds binding document for allwinner h3 thermal controller.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> .../bindings/thermal/sun8i-thermal.yaml | 81 ++++++++++++++++++-
> 1 file changed, 78 insertions(+), 3 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] Documentation: add link to stm32mp157 docs
From: Alexandre Torgue @ 2019-08-27 15:23 UTC (permalink / raw)
To: Jonathan Corbet, Gerald BAEZA
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, linux-doc@vger.kernel.org
In-Reply-To: <20190827074825.64a28e88@lwn.net>
Hi Jonathan,
On 8/27/19 3:48 PM, Jonathan Corbet wrote:
> On Tue, 27 Aug 2019 12:19:32 +0000
> Gerald BAEZA <gerald.baeza@st.com> wrote:
>
>> Link to the online stm32mp157 documentation added
>> in the overview.
>>
>> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
>> ---
>> Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
>> index f62fdc8..8d5a476 100644
>> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
>> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
>> @@ -14,6 +14,12 @@ It features:
>> - Standard connectivity, widely inherited from the STM32 MCU family
>> - Comprehensive security support
>>
>> +Resources
>> +---------
>> +
>> +Datasheet and reference manual are publicly available on ST website:
>> +.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
>> +
>
> Adding the URL is a fine idea. But you don't need the extra syntax to
> create a link if you're not going to actually make a link out of it. So
> I'd take the ".. _STM32MP157:" part out and life will be good.
>
We also did it for older stm32 product. Idea was to not have the "full"
address but just a shortcut of the link when html file is read. It maybe
makes no sens ? (if yes we will have to update older stm32 overview :))
thanks
Alex
> Thanks,
>
> jon
>
_______________________________________________
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 05/20] arm64: dts: marvell: Prepare the introduction of AP807 based SoCs
From: Gregory CLEMENT @ 2019-08-27 15:20 UTC (permalink / raw)
To: Miquel Raynal, Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Maxime Chevallier, Nadav Haklai, Thomas Petazzoni, Miquel Raynal,
Konstantin Porotchkin, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel
In-Reply-To: <20190806145500.24109-6-miquel.raynal@bootlin.com>
Hi Miquel,
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> Prepare the support for Marvell AP807 die. This die is very similar to
> AP806 but uses different DDR PHY. AP807 is a major component of CN9130
> SoC series.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 448 +----------------
> arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 456 ++++++++++++++++++
> 2 files changed, 458 insertions(+), 446 deletions(-)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index a23ddd46efc5..cdadb28f287e 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -5,454 +5,10 @@
> * Device Tree file for Marvell Armada AP806.
> */
>
> -#include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/thermal/thermal.h>
> -
> -/dts-v1/;
> +#define AP_NAME ap806
I didn't find where AP_NAME is used.
> +#include "armada-ap80x.dtsi"
[...]
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> new file mode 100644
> index 000000000000..c44cd7c64bf6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
[...]
> + ap806 {
This file will be used for ap806 and for ap807 but the ap name will be
the same for both varirant?
Shouldn't you use the AP_NAME here?
Gregory
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
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] arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
When we fail to bring a secondary CPU online and it fails in an unknown
state, we should assume the worst and increment 'cpus_stuck_in_kernel'
so that things like kexec() are disabled.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1f8aeb77cba5..dc9fe879c279 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -147,6 +147,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
default:
pr_err("CPU%u: failed in unknown state : 0x%lx\n",
cpu, status);
+ cpus_stuck_in_kernel++;
break;
case CPU_KILL_ME:
if (!op_cpu_kill(cpu)) {
--
2.11.0
_______________________________________________
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] arm64: smp: Don't enter kernel with NULL stack pointer or task struct
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
Although SMP bringup is inherently racy, we can significantly reduce
the window during which secondary CPUs can unexpectedly enter the
kernel by sanity checking the 'stack' and 'task' fields of the
'secondary_data' structure. If the booting CPU gave up waiting for us,
then they will have been cleared to NULL and we should spin in a WFE; WFI
loop instead.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/head.S | 8 ++++++++
arch/arm64/kernel/smp.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 2cdacd1c141b..0baadf335172 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -724,14 +724,22 @@ __secondary_switched:
adr_l x0, secondary_data
ldr x1, [x0, #CPU_BOOT_STACK] // get secondary_data.stack
+ cbz x1, __secondary_too_slow
mov sp, x1
ldr x2, [x0, #CPU_BOOT_TASK]
+ cbz x2, __secondary_too_slow
msr sp_el0, x2
mov x29, #0
mov x30, #0
b secondary_start_kernel
ENDPROC(__secondary_switched)
+__secondary_too_slow:
+ wfe
+ wfi
+ b __secondary_too_slow
+ENDPROC(__secondary_too_slow)
+
/*
* The booting CPU updates the failed status @__early_cpu_boot_status,
* with MMU turned off.
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 63c7a7682e93..1f8aeb77cba5 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -136,6 +136,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
secondary_data.task = NULL;
secondary_data.stack = NULL;
+ __flush_dcache_area(&secondary_data, sizeof(secondary_data));
status = READ_ONCE(secondary_data.status);
if (ret && status) {
--
2.11.0
_______________________________________________
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] arm64: smp: Increase secondary CPU boot timeout value
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
In-Reply-To: <20190827151815.2160-1-will@kernel.org>
When many debug options are enabled simultaneously (e.g. PROVE_LOCKING,
KMEMLEAK, DEBUG_PAGE_ALLOC, KASAN etc), it is possible for us to timeout
when attempting to boot a secondary CPU and give up. Unfortunately, the
CPU will /eventually/ appear, and sit in the background happily stuck
in a recursive exception due to a NULL stack pointer.
Increase the timeout to 5s, which will of course be enough for anybody.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 018a33e01b0e..63c7a7682e93 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -123,7 +123,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
* time out.
*/
wait_for_completion_timeout(&cpu_running,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(5000));
if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
--
2.11.0
_______________________________________________
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] Try to make SMP booting slightly less fragile
From: Will Deacon @ 2019-08-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, Will Deacon
Hi everyone,
After spending some time investigating SMP boot issues when using
(random?) configs from Qian Cai with lots of debug options enabled, I
hacked together these two patches which make SMP booting a little more
robust.
The whole thing is still a racy mess, but I'm not sure we can do much
about that without reworking it to use per-cpu data structures which
we can update atomically.
Will
--->8
Will Deacon (3):
arm64: smp: Increase secondary CPU boot timeout value
arm64: smp: Don't enter kernel with NULL stack pointer or task struct
arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
arch/arm64/kernel/head.S | 8 ++++++++
arch/arm64/kernel/smp.c | 4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/5] stm32-ddr-pmu driver creation
From: Gerald BAEZA @ 2019-08-27 15:08 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Gerald BAEZA
The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
This series adds support for the DDRPERFM via a new stm32-ddr-pmu driver,
registered into the perf framework.
This driver is inspired from arch/arm/mm/cache-l2x0-pmu.c
---
Changes from v1:
- add 'resets' description (bindings) and using (driver). Thanks Rob.
- rebase on 5.2-rc1 (that includes the ddrperfm clock control patch).
Changes from v2:
- rebase on 5.3-rc6 that has to be completed with
'perf tools: fix alignment trap in perf stat': mandatory.
'Documentation: add link to stm32mp157 docs': referenced from this series.
- take into account all remarks from Mark Rutland: thanks for your time!
https://lkml.org/lkml/2019/6/26/388
- fix for event type filtering in stm32_ddr_pmu_event_init()
Gerald Baeza (5):
Documentation: perf: stm32: ddrperfm support
dt-bindings: perf: stm32: ddrperfm support
perf: stm32: ddrperfm driver creation
ARM: configs: enable STM32_DDR_PMU
ARM: dts: stm32: add ddrperfm on stm32mp157c
.../devicetree/bindings/perf/stm32-ddr-pmu.txt | 16 +
Documentation/perf/stm32-ddr-pmu.txt | 37 ++
arch/arm/boot/dts/stm32mp157c.dtsi | 8 +
arch/arm/configs/multi_v7_defconfig | 1 +
drivers/perf/Kconfig | 6 +
drivers/perf/Makefile | 1 +
drivers/perf/stm32_ddr_pmu.c | 426 +++++++++++++++++++++
7 files changed, 495 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
create mode 100644 Documentation/perf/stm32-ddr-pmu.txt
create mode 100644 drivers/perf/stm32_ddr_pmu.c
--
2.7.4
_______________________________________________
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