* [PATCH] ARM: multi_v7_defconfig: Enable NXP pcf85363 rtc
From: Biju Das @ 2018-12-10 14:05 UTC (permalink / raw)
To: Simon Horman
Cc: Stefan Wahren, Fabrizio Castro, Chris Paterson, Alexandre Torgue,
Arnd Bergmann, Tony Lindgren, Russell King, Stefan Agner,
Biju Das, linux-renesas-soc, Simon Horman, Olof Johansson,
Geert Uytterhoeven, linux-arm-kernel, Marek Szyprowski
The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase
hardware support enable the driver in the multi_v7_defconfig
multiplatform configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f29f49a..7762815 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -826,6 +826,7 @@ CONFIG_RTC_DRV_MAX8997=m
CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_RS5C372=m
+CONFIG_RTC_DRV_PCF85363=m
CONFIG_RTC_DRV_BQ32K=m
CONFIG_RTC_DRV_TWL4030=y
CONFIG_RTC_DRV_PALMAS=y
--
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 related
* Re: ufs_qcom_dump_dbg_regs makes the kernel panic
From: Marc Gonzalez @ 2018-12-10 14:07 UTC (permalink / raw)
To: Robin Murphy, Jeffrey Hugo, Vivek Gautam, Bjorn Andersson,
Andy Gross, David Brown
Cc: MSM, Linux ARM
In-Reply-To: <0f4cac25-3936-adc8-d8b5-c131dea4b93c@arm.com>
On 10/12/2018 14:34, Robin Murphy wrote:
> On 10/12/2018 12:37, Marc Gonzalez wrote:
>
>> When the kernel fails to init the UFSHC, it calls ufshcd_print_host_regs()
>> to help with debugging, which calls the dbg_register_dump hook.
>>
>> ufs_qcom_dump_dbg_regs makes the kernel panic:
>>
>> [ 3.715634] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
>> [ 3.722750] UFS_DBG_RD_REG_TXUC 000000b0: 00000001 00000000 00000000 00000004
>> [ 3.729943] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
>> [ 3.737000] Modules linked in:
>> [ 3.744371] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G S 4.20.0-rc4 #16
>> [ 3.747413] Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
>> [ 3.755295] pstate: 00000005 (nzcv daif -PAN -UAO)
>> [ 3.761978] pc : __memcpy_fromio+0x68/0x80
>> [ 3.766718] lr : ufshcd_dump_regs+0x50/0xb0
>> [ 3.770767] sp : ffff00000807ba00
>> [ 3.774830] x29: ffff00000807ba00 x28: 00000000fffffffb
>> [ 3.778344] x27: ffff0000089db068 x26: ffff8000f6e58000
>> [ 3.783728] x25: 000000000000000e x24: 0000000000000800
>> [ 3.789023] x23: ffff8000f6e587c8 x22: 0000000000000800
>> [ 3.794319] x21: ffff000008908368 x20: ffff8000f6e1ab80
>> [ 3.799615] x19: 000000000000006c x18: ffffffffffffffff
>> [ 3.804910] x17: 0000000000000000 x16: 0000000000000000
>> [ 3.810206] x15: ffff000009199648 x14: ffff000089244187
>> [ 3.815502] x13: ffff000009244195 x12: ffff0000091ab000
>> [ 3.820797] x11: 0000000005f5e0ff x10: ffff0000091998a0
>> [ 3.826093] x9 : 0000000000000000 x8 : ffff8000f6e1ac00
>> [ 3.831389] x7 : 0000000000000000 x6 : 0000000000000068
>> [ 3.836676] x5 : ffff8000f6e1abe8 x4 : 0000000000000000
>> [ 3.841971] x3 : ffff00000928c868 x2 : ffff8000f6e1abec
>> [ 3.847267] x1 : ffff00000928c868 x0 : ffff8000f6e1abe8
>> [ 3.852567] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
>> [ 3.857900] Call trace:
>> [ 3.864473] __memcpy_fromio+0x68/0x80
>> [ 3.866683] ufs_qcom_dump_dbg_regs+0x1c0/0x370
>> [ 3.870522] ufshcd_print_host_regs+0x168/0x190
>> [ 3.874946] ufshcd_init+0xd4c/0xde0
>> [ 3.879459] ufshcd_pltfrm_init+0x3c8/0x550
>> [ 3.883264] ufs_qcom_probe+0x24/0x60
>> [ 3.887188] platform_drv_probe+0x50/0xa0
>> [ 3.890993] really_probe+0x1f0/0x2a0
>> [ 3.894983] driver_probe_device+0x58/0x100
>> [ 3.898628] __driver_attach+0xd4/0xe0
>> [ 3.902617] bus_for_each_dev+0x74/0xd0
>> [ 3.906436] driver_attach+0x20/0x30
>> [ 3.910169] bus_add_driver+0x1ac/0x220
>> [ 3.913992] driver_register+0x60/0x110
>> [ 3.917540] __platform_driver_register+0x40/0x50
>> [ 3.921413] ufs_qcom_pltform_init+0x18/0x20
>> [ 3.926248] do_one_initcall+0x5c/0x180
>> [ 3.930593] kernel_init_freeable+0x198/0x244
>> [ 3.934156] kernel_init+0x10/0x110
>> [ 3.938629] ret_from_fork+0x10/0x20
>> [ 3.941940] Code: f2400842 54000100 8b020002 d503201f (39400023)
>> [ 3.945875] ---[ end trace 2d10f654364744f5 ]---
>> [ 3.951841] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [ 3.956528] SMP: stopping secondary CPUs
>> [ 5.005502] SMP: failed to stop secondary CPUs 2,7
>> [ 5.005648] Kernel Offset: disabled
>> [ 5.009292] CPU features: 0x2,21802008
>> [ 5.012676] Memory Limit: none
>> [ 5.016485] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>
>>
>> The problem appears to be on this line:
>>
>> reg = ufs_qcom_get_debug_reg_offset(host, UFS_DBG_RD_REG_RXUC);
>> /* reg = 0x800 */
>> print_fn(hba, reg, 27, "UFS_DBG_RD_REG_RXUC ", priv);
>>
>> I'm not sure what's going on, because the driver is supposed to map 0x2500 bytes.
>> (reg = <0x1da4000 0x2500>;)
>
> It is mapped - you're not getting an MMU fault but an external abort,
> which means the access has been translated and gone out, but the
> peripheral (or possibly the interconnect in between) didn't like it and
> sent some kind of decode error back. Given that you're faulting in
> memcpy_from_io() that's not too surprising - using that on actual device
> registers (rather than stuff like ioremap()ed SRAM) is generally a bad
> idea, since you have no control over things like access size and
> ordering that a typical device is sensitive to.
Thanks Robin, your insight is always so very helpful. I do see that __memcpy_fromio
reads in chunks of 8-bytes, using __raw_readq.
The weird thing (to me) is that the kernel does not panic when I call
the debug function a bit later (after sleeping for a second). Feels
like there is a race somewhere, and the device is not happy if it
accessed "too soon". The kernel still hangs though, which might be
worse than a clear-cut panic...
>> Commenting out the last 4 dumps of ufs_qcom_print_hw_debug_reg_all() makes
>> the panic disappear, but the kernel just hangs after printing UFS_DBG_RD_REG_TXUC
>
> I'd recommend fixing the register dump code to use specific read*()
> accesses of the appropriate sizes for each register.
I don't have documentation for that memory region, but based on the source code,
I would assume 32-bit registers. I'll try cooking up a small patch.
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Peter Zijlstra @ 2018-12-10 14:07 UTC (permalink / raw)
To: Qian Cai
Cc: mark.rutland, marc.zyngier, daniel.lezcano, linux-kernel, mingo,
longman, akpm, tglx, linux-arm-kernel
In-Reply-To: <20181210135228.49751-1-cai@lca.pw>
On Mon, Dec 10, 2018 at 08:52:28AM -0500, Qian Cai wrote:
> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
> warning.
>
> [ 0.000000] lockdep_assert_cpus_held+0x50/0x60
> [ 0.000000] static_key_enable_cpuslocked+0x30/0xe8
> [ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
> [ 0.000000] arch_timer_acpi_init+0x274/0x6ac
> [ 0.000000] acpi_table_parse+0x1ac/0x218
> [ 0.000000] __acpi_probe_device_table+0x164/0x1ec
> [ 0.000000] timer_probe+0x1bc/0x254
> [ 0.000000] time_init+0x44/0x98
> [ 0.000000] start_kernel+0x4ec/0x7d4
It seems to me we want something like:
---
kernel/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 91d5c38eb7e5..e1ee8caf28b5 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -313,6 +313,8 @@ void cpus_write_unlock(void)
void lockdep_assert_cpus_held(void)
{
+ if (system_state < SYSTEM_RUNNING)
+ return;
percpu_rwsem_assert_held(&cpu_hotplug_lock);
}
_______________________________________________
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 v2 2/4] i2c: Add Actions Semiconductor Owl family S700 I2C support
From: Manivannan Sadhasivam @ 2018-12-10 13:53 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: mark.rutland, devicetree, linux, wsa, linux-kernel, thomas.liau,
robh+dt, linux-i2c, afaerber, linux-arm-kernel
In-Reply-To: <20181126185821.2480449-3-pn@denx.de>
On Mon, Nov 26, 2018 at 07:58:19PM +0100, Parthiban Nallathambi wrote:
> Add S700 to the list of devices supported by Owl I2C driver.
>
> Add Actions Semiconductor Owl family S900 I2C driver.
S700 ;-)
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
With the change in subject,
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cheers,
Mani
> ---
> drivers/i2c/busses/i2c-owl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/busses/i2c-owl.c b/drivers/i2c/busses/i2c-owl.c
> index 96b4572e6d9c..b6b5a495118b 100644
> --- a/drivers/i2c/busses/i2c-owl.c
> +++ b/drivers/i2c/busses/i2c-owl.c
> @@ -475,6 +475,7 @@ static int owl_i2c_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id owl_i2c_of_match[] = {
> + { .compatible = "actions,s700-i2c" },
> { .compatible = "actions,s900-i2c" },
> { /* sentinel */ }
> };
> --
> 2.17.2
>
_______________________________________________
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/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Nishanth Menon @ 2018-12-10 13:52 UTC (permalink / raw)
To: Faiz Abbas
Cc: mark.rutland, devicetree, ulf.hansson, Arnd Bergmann,
Tony Lindgren, Sekhar Nori, linux-kernel, kishon, t-kristo,
robh+dt, adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <a73337c2-977c-c9a8-141e-cf91a4591cbc@ti.com>
On 19:03-20181210, Faiz Abbas wrote:
> > I think you can rely on the author to tell you when something is> actually ready to be merged (and you can tell him/her to remind you).
>
> Yes. I will ping Nishanth once the bindings are in next.
In addition, when you are ready, please also check if the patches
need rebase on top of Tero's next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux.git/log/?h=4.20-rc1-am65x-queue
--
Regards,
Nishanth Menon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning
From: Qian Cai @ 2018-12-10 13:52 UTC (permalink / raw)
To: akpm
Cc: mark.rutland, marc.zyngier, daniel.lezcano, linux-kernel, peterz,
Qian Cai, longman, tglx, mingo, linux-arm-kernel
In-Reply-To: <1543877121-4098-1-git-send-email-cai@gmx.us>
Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
warning.
[ 0.000000] lockdep_assert_cpus_held+0x50/0x60
[ 0.000000] static_key_enable_cpuslocked+0x30/0xe8
[ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
[ 0.000000] arch_timer_acpi_init+0x274/0x6ac
[ 0.000000] acpi_table_parse+0x1ac/0x218
[ 0.000000] __acpi_probe_device_table+0x164/0x1ec
[ 0.000000] timer_probe+0x1bc/0x254
[ 0.000000] time_init+0x44/0x98
[ 0.000000] start_kernel+0x4ec/0x7d4
This is due to the commit cb538267ea1e ("jump_label/lockdep: Assert we hold
the hotplug lock for _cpuslocked() operations").
Since it is applying a global workaround to all CPUs here, it did not hold
any CPU locks in this path.
arch_timer_acpi_init
arch_timer_check_ool_workaround(ate_match_acpi_oem_info, table)
arch_timer_enable_workaround(wa, local = false)
for_each_possible_cpu()
per_cpu()
There is also another path did not have any CPU lock.
time_init
clocksource_probe
arch_timer_of_init
arch_timer_check_ool_workaround(ate_match_dt, np)
arch_timer_enable_workaround(wa, local = false)
When hot-adding a CPU, it will go with a slightly different route.
arch_timer_starting_cpu
__arch_timer_setup
arch_timer_check_ool_workaround(ate_match_local_cap_id, NULL)
arch_timer_enable_workaround(wa, local = true)
__this_cpu_write()
Hence, deal with them differently.
Fixes: 450f9689f294 (clocksource/arm_arch_timer: Use
static_branch_enable_cpuslocked())
Signed-off-by: Qian Cai <cai@lca.pw>
---
v2: fix the root cause instead of a workaround.
drivers/clocksource/arm_arch_timer.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 9a7d4dc00b6e..81dca7d31d13 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -492,17 +492,20 @@ void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround *wa
if (local) {
__this_cpu_write(timer_unstable_counter_workaround, wa);
+
+ /*
+ * Use the locked version, as we're called from the CPU
+ * hotplug framework. Otherwise, we end-up in
+ * deadlock-land.
+ */
+ static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled);
} else {
for_each_possible_cpu(i)
per_cpu(timer_unstable_counter_workaround, i) = wa;
+ /* A global workaround is not on the CPU hotplug path. */
+ static_branch_enable(&arch_timer_read_ool_enabled);
}
- /*
- * Use the locked version, as we're called from the CPU
- * hotplug framework. Otherwise, we end-up in deadlock-land.
- */
- static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled);
-
/*
* Don't use the vdso fastpath if errata require using the
* out-of-line counter accessor. We may change our mind pretty
--
2.17.2 (Apple Git-113)
_______________________________________________
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 03/12] arm/arm64: Provide a wrapper for SMCCC 1.1 calls
From: Steven Price @ 2018-12-10 13:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20181210102736.2iluzzfuryfnf4rk@lakrids.cambridge.arm.com>
On 10/12/2018 10:27, Mark Rutland wrote:
> On Wed, Nov 28, 2018 at 02:45:18PM +0000, Steven Price wrote:
>> SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI
>> conduit. Rather than coding this in every call site provide a macro
>> which uses the correct instruction. The macro also handles the case
>> where no PSCI conduit is configured returning a not supported error
>> in res, along with returning the conduit used for the call.
>>
>> This allow us to remove some duplicated code and will be useful later
>> when adding paravirtualized time hypervisor calls.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> include/linux/arm-smccc.h | 44 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
>> index 18863d56273c..b047009e7a0a 100644
>> --- a/include/linux/arm-smccc.h
>> +++ b/include/linux/arm-smccc.h
>> @@ -311,5 +311,49 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>> #define SMCCC_RET_NOT_SUPPORTED -1
>> #define SMCCC_RET_NOT_REQUIRED -2
>>
>> +/* Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED.
>> + * Used when the PSCI conduit is not defined. The empty asm statement
>> + * avoids compiler warnings about unused variables.
>> + */
>> +#define __fail_smccc_1_1(...) \
>> + do { \
>> + __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
>> + asm ("" __constraints(__count_args(__VA_ARGS__))); \
>> + if (___res) \
>> + ___res->a0 = SMCCC_RET_NOT_SUPPORTED; \
>> + } while (0)
>> +
>> +/*
>> + * arm_smccc_1_1() - make an SMCCC v1.1 compliant call
>> + *
>> + * This is a variadic macro taking one to eight source arguments, and
>> + * an optional return structure.
>> + *
>> + * @a0-a7: arguments passed in registers 0 to 7
>> + * @res: result values from registers 0 to 3
>> + *
>> + * This macro will make either an HVC call or an SMC call depending on the
>> + * current PSCI conduit. If no valid conduit is available then -1
>> + * (SMCCC_RET_NOT_SUPPORTED) is returned in @res.a0 (if supplied).
>> + *
>> + * The return value also provides the conduit that was used.
>> + */
>> +#define arm_smccc_1_1(...) ({ \
>
> As a minor nit, could we please give call this something like
> arm_smccc_1_1_call() or arm_smccc_1_1_invoke(), to make it clear what
> action this performs?
Sure, arm_smccc_1_1_call() works for me.
> I had some patches [1] cleaning up the SMCCC API, it would be nice if we
> could pick up some of those as preparatory bits, before we spread some
> of the current design warts (e.g. SMCCC depending on PSCI definitions).
Looks like a similar approach, just extended to include
s/PSCI_CONDUIT/SMCCC_CONDUIT/ and making arm_smccc_1_1_* return res.
Would you like me to drop this (and the next) patch in favour of yours?
Thanks,
Steve
> Thanks,
> Mark.
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/smccc-cleanup
>
>> + int method = psci_ops.conduit; \
>> + switch (method) { \
>> + case PSCI_CONDUIT_HVC: \
>> + arm_smccc_1_1_hvc(__VA_ARGS__); \
>> + break; \
>> + case PSCI_CONDUIT_SMC: \
>> + arm_smccc_1_1_smc(__VA_ARGS__); \
>> + break; \
>> + default: \
>> + __fail_smccc_1_1(__VA_ARGS__); \
>> + method = PSCI_CONDUIT_NONE; \
>> + break; \
>> + } \
>> + method; \
>> + })
>> +
>> #endif /*__ASSEMBLY__*/
>> #endif /*__LINUX_ARM_SMCCC_H*/
>> --
>> 2.19.2
>>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>
_______________________________________________
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 4/4] arm64: dts: actions: s700-cubieboard7: Enable I2C0 and I2C1
From: Manivannan Sadhasivam @ 2018-12-10 13:50 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: mark.rutland, devicetree, linux, wsa, linux-kernel, thomas.liau,
robh+dt, linux-i2c, afaerber, linux-arm-kernel
In-Reply-To: <20181126185821.2480449-5-pn@denx.de>
Hi Parthiban,
On Mon, Nov 26, 2018 at 07:58:21PM +0100, Parthiban Nallathambi wrote:
> Add pinctrl definitions for Actions Semiconductor S700 I2C controllers.
> Pinctrl definitions are only available for I2C0, I2C1 and I2C2.
> Enable I2C0 (PMIC), I2C1 (gyro, touchscreen) in cubieboard7.
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
> ---
> .../boot/dts/actions/s700-cubieboard7.dts | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> index 28f3f4a0f7f0..6a75fdd7ab42 100644
> --- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> +++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> @@ -37,3 +37,56 @@
> &uart3 {
> status = "okay";
> };
> +
> +&i2c0 {
On the board DTS, node names should be sorted alphabetically!
Regards,
Mani
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_default>;
> +};
> +
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_default>;
> +};
> +
> +&i2c2 {
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_default>;
> +};
> +
> +&pinctrl {
> + i2c0_default: i2c0_default {
> + pinmux {
> + groups = "i2c0_mfp";
> + function = "i2c0";
> + };
> + pinconf {
> + pins = "i2c0_sclk", "i2c0_sdata";
> + bias-pull-up;
> + };
> + };
> +
> + i2c1_default: i2c1_default {
> + pinmux {
> + groups = "i2c1_dummy";
> + function = "i2c1";
> + };
> + pinconf {
> + pins = "i2c1_sclk", "i2c1_sdata";
> + bias-pull-up;
> + };
> + };
> +
> + i2c2_default: i2c2_default {
> + pinmux {
> + groups = "i2c2_dummy";
> + function = "i2c2";
> + };
> + pinconf {
> + pins = "i2c2_sclk", "i2c2_sdata";
> + bias-pull-up;
> + };
> + };
> +};
> --
> 2.17.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
From: Catalin Marinas @ 2018-12-10 13:50 UTC (permalink / raw)
To: Doug Anderson
Cc: mhocko, linux-sh, Peter Zijlstra, Benjamin Herrenschmidt,
Will Deacon, linux-mips, dalias, paulus, H. Peter Anvin,
sparclinux, Daniel Thompson, Yoshinori Sato, mpe, x86,
Russell King - ARM Linux, Ingo Molnar, ying.huang, jhogan,
linux-snps-arc, Jason Wessel, rppt, bp, Thomas Gleixner,
Linux ARM, christophe.leroy, Vineet Gupta, LKML, Ralf Baechle,
rkuo, paul.burton, linux-hexagon, kgdb-bugreport, Andrew Morton,
linuxppc-dev, David Miller
In-Reply-To: <CAD=FV=WO2xMojkEqKCMkufwihUvnow3yEH4GZPh7hh8noNZ+=A@mail.gmail.com>
Hi Doug,
On Fri, Dec 07, 2018 at 10:40:24AM -0800, Doug Anderson wrote:
> On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> > > Douglas Anderson (4):
> > > kgdb: Remove irq flags from roundup
> > > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> > > kgdb: Don't round up a CPU that failed rounding up before
> > > kdb: Don't back trace on a cpu that didn't round up
> >
> > FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y
> > on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts
> > disabled when they shouldn't and it trips over the BUG at
> > mm/vmalloc.c:1380 (called via do_fork -> copy_process).
> >
> > Now, I don't think these patches make things worse on arm64 since prior
> > to them the kgdb boot tests on arm64 were stuck in a loop (RUN
> > singlestep).
>
> Thanks for the report! ...actually, I'd never tried CONFIG_KGDB_TESTS
> before. ...so I tried them now:
>
> A) chromeos-4.19 tree on qcom-sdm845 without this series: booted up OK
> B) chromeos-4.19 tree on qcom-sdm845 with this series: booted up OK
> C) v4.20-rc5-90-g30002dd008ed on rockchip-rk3399 (kevin) with this
> series: booted up OK
>
> Example output from B) above:
>
> localhost ~ # dmesg | grep kgdbts
> [ 2.139814] KGDB: Registered I/O driver kgdbts
> [ 2.144582] kgdbts:RUN plant and detach test
> [ 2.165333] kgdbts:RUN sw breakpoint test
> [ 2.172990] kgdbts:RUN bad memory access test
> [ 2.178640] kgdbts:RUN singlestep test 1000 iterations
> [ 2.187765] kgdbts:RUN singlestep [0/1000]
> [ 2.559596] kgdbts:RUN singlestep [100/1000]
> [ 2.931419] kgdbts:RUN singlestep [200/1000]
> [ 3.303474] kgdbts:RUN singlestep [300/1000]
> [ 3.675121] kgdbts:RUN singlestep [400/1000]
> [ 4.046867] kgdbts:RUN singlestep [500/1000]
> [ 4.418920] kgdbts:RUN singlestep [600/1000]
> [ 4.790824] kgdbts:RUN singlestep [700/1000]
> [ 5.162479] kgdbts:RUN singlestep [800/1000]
> [ 5.534103] kgdbts:RUN singlestep [900/1000]
> [ 5.902299] kgdbts:RUN do_fork for 100 breakpoints
> [ 8.463900] KGDB: Unregistered I/O driver kgdbts, debugger disabled
>
> ...so I guess I'm a little confused. Either I have a different config
> than you do or something is special about your machine?
I tried it now on a Juno board both as a host and a guest and boots
fine. It must be something that only triggers ThunderX2. Ignore the
report for now, if I find anything interesting I'll let you know.
--
Catalin
_______________________________________________
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/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Nishanth Menon @ 2018-12-10 13:49 UTC (permalink / raw)
To: Sekhar Nori
Cc: mark.rutland, devicetree, ulf.hansson, Arnd Bergmann,
Tony Lindgren, linux-kernel, robh+dt, kishon, t-kristo,
Faiz Abbas, adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <66f9d53b-abec-0a28-8eae-ecb99b075db4@ti.com>
On 18:10-20181210, Sekhar Nori wrote:
>
> I think you can rely on the author to tell you when something is
> actually ready to be merged (and you can tell him/her to remind you).
>
> For the review itself, doing it by having a look at the dependencies
> mentioned in the cover letter (like available for this series) should be
> good enough (I feel).
Dependencies can be for multiple things.. anyways, Sigh..
> I am not sure if there is a need to post an "RFC version", and then
> follow it up with an actual "PATCH version" once dependencies are
> cleared though.
Heads up for the maintainers will be useful. For example:
Will be good to state in cover-letter instead of just stating
https://patchwork.kernel.org/cover/10717641/
State:
Bindings are in discussion[2], will confirm if approved and will
check if rebase is necessary.
This will indicate to the maintainer that patches are preliminary and
subject to change depending on bindings discussion and developer has
taken ownership of maintaining patch sanity.
--
Regards,
Nishanth Menon
_______________________________________________
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 3/4] arm64: dts: actions: s700: Add I2C controller nodes
From: Manivannan Sadhasivam @ 2018-12-10 13:47 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: mark.rutland, devicetree, linux, wsa, linux-kernel, thomas.liau,
robh+dt, linux-i2c, afaerber, linux-arm-kernel
In-Reply-To: <20181126185821.2480449-4-pn@denx.de>
On Mon, Nov 26, 2018 at 07:58:20PM +0100, Parthiban Nallathambi wrote:
> Add I2C controller nodes for Actions Semiconductor S700 SoC.
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
Ideally, dts patches should come before driver.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cheers,
Mani
> ---
> arch/arm64/boot/dts/actions/s700.dtsi | 40 +++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
> index 192c7b39c8c1..35fddba2af1c 100644
> --- a/arch/arm64/boot/dts/actions/s700.dtsi
> +++ b/arch/arm64/boot/dts/actions/s700.dtsi
> @@ -174,6 +174,46 @@
> #clock-cells = <1>;
> };
>
> + i2c0: i2c@e0170000 {
> + compatible = "actions,s700-i2c";
> + reg = <0 0xe0170000 0 0x1000>;
> + clocks = <&cmu CLK_I2C0>;
> + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@e0174000 {
> + compatible = "actions,s700-i2c";
> + reg = <0 0xe0174000 0 0x1000>;
> + clocks = <&cmu CLK_I2C1>;
> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@e0178000 {
> + compatible = "actions,s700-i2c";
> + reg = <0 0xe0178000 0 0x1000>;
> + clocks = <&cmu CLK_I2C2>;
> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@e017c000 {
> + compatible = "actions,s700-i2c";
> + reg = <0 0xe017c000 0 0x1000>;
> + clocks = <&cmu CLK_I2C3>;
> + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> sps: power-controller@e01b0100 {
> compatible = "actions,s700-sps";
> reg = <0x0 0xe01b0100 0x0 0x100>;
> --
> 2.17.2
>
_______________________________________________
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 1/4] dt-bindings: i2c: Add S700 support for Actions Semi Soc's
From: Manivannan Sadhasivam @ 2018-12-10 13:43 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: mark.rutland, devicetree, linux, wsa, linux-kernel, thomas.liau,
robh+dt, linux-i2c, afaerber, linux-arm-kernel
In-Reply-To: <20181126185821.2480449-2-pn@denx.de>
On Mon, Nov 26, 2018 at 07:58:18PM +0100, Parthiban Nallathambi wrote:
> Add s700 compatible string to Actions Semi SoC dt-bindings.
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
> ---
> Documentation/devicetree/bindings/i2c/i2c-owl.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> index b743fe444e9f..dfa1197e0dbf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> @@ -2,7 +2,7 @@ Actions Semiconductor Owl I2C controller
>
> Required properties:
>
> -- compatible : Should be "actions,s900-i2c".
> +- compatible : Should be "actions,s700-i2c" or "actions,s900-i2c".
Since this driver will also support S500 in future, the above could be
phrased as:
compatible: Should be one of the following:
- "actions,s700-i2c" for S700 SoC
- "actions,s900-i2c" for S900 SoC
Regards,
Mani
> - reg : Offset and length of the register set for the device.
> - #address-cells : Should be 1.
> - #size-cells : Should be 0.
> --
> 2.17.2
>
_______________________________________________
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 7/7] drm: Split out drm_probe_helper.h
From: Benjamin Gaignard @ 2018-12-10 13:40 UTC (permalink / raw)
To: Thierry Reding
Cc: moderated list:ARM/S5P EXYNOS AR..., linux-tegra, spice-devel,
Daniel Vetter, Intel Graphics Development, etnaviv, amd-gfx,
virtualization, linux-renesas-soc, linux-rockchip, linux-mediatek,
ML dri-devel, linux-arm-msm, nouveau, Daniel Vetter,
linux-amlogic, xen-devel, freedreno, linux-stm32, Linux ARM
In-Reply-To: <CA+M3ks5MgpCqMDp6DrtyB_Cj_YMryysTmbAaUjzN7sWde5dX6Q@mail.gmail.com>
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
<benjamin.gaignard@linaro.org> a écrit :
>
> Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> <thierry.reding@gmail.com> a écrit :
> >
> > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty much everyone needs) in
> > > the drm_crtc_helper.h file (which atomic drivers should never need) is
> > > confusing. Split them out.
> > >
> > > To make sure I actually achieved the goal here I went through all
> > > drivers. And indeed, all atomic drivers are now free of
> > > drm_crtc_helper.h includes.
> > >
>
> I have difficulties to apply this with git on top of drm-misc-next.
> It is because of that I got errors (encoder and connector types not
> found) while compiling adv7511_audio.c and exynos_dp.c ?
>
Nack on this patch because it break compiling at least on sti driver.
drm_probe_helper.h doesn't bring the same includes than drm_crtc_helper.h:
#include <drm/drm_crtc.h>
#include <drm/drm_modeset_helper_vtables.h>
#include <drm/drm_modeset_helper.h>
so some types, structures and functions proptotypes are missing while compiling.
> Benjamin
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Cc: virtualization@lists.linux-foundation.org
> > > Cc: etnaviv@lists.freedesktop.org
> > > Cc: linux-samsung-soc@vger.kernel.org
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: linux-mediatek@lists.infradead.org
> > > Cc: linux-amlogic@lists.infradead.org
> > > Cc: linux-arm-msm@vger.kernel.org
> > > Cc: freedreno@lists.freedesktop.org
> > > Cc: nouveau@lists.freedesktop.org
> > > Cc: spice-devel@lists.freedesktop.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > Cc: linux-renesas-soc@vger.kernel.org
> > > Cc: linux-rockchip@lists.infradead.org
> > > Cc: linux-stm32@st-md-mailman.stormreply.com
> > > Cc: linux-tegra@vger.kernel.org
> > > Cc: xen-devel@lists.xen.org
> > > ---
> > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
> > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +-
> > > .../display/amdgpu_dm/amdgpu_dm_services.c | 2 +-
> > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +-
> > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
> > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +-
> > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +-
> > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
> > > drivers/gpu/drm/arm/malidp_drv.c | 2 +-
> > > drivers/gpu/drm/arm/malidp_mw.c | 2 +-
> > > drivers/gpu/drm/armada/armada_510.c | 2 +-
> > > drivers/gpu/drm/armada/armada_crtc.c | 2 +-
> > > drivers/gpu/drm/armada/armada_drv.c | 2 +-
> > > drivers/gpu/drm/armada/armada_fb.c | 2 +-
> > > drivers/gpu/drm/ast/ast_drv.c | 1 +
> > > drivers/gpu/drm/ast/ast_mode.c | 1 +
> > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +-
> > > drivers/gpu/drm/bochs/bochs_drv.c | 1 +
> > > drivers/gpu/drm/bochs/bochs_kms.c | 1 +
> > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +-
> > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +-
> > > .../drm/bridge/analogix/analogix_dp_core.c | 2 +-
> > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
> > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
> > > .../bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
> > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> > > drivers/gpu/drm/bridge/panel.c | 2 +-
> > > drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> > > drivers/gpu/drm/bridge/sii902x.c | 2 +-
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
> > > drivers/gpu/drm/bridge/tc358764.c | 2 +-
> > > drivers/gpu/drm/bridge/tc358767.c | 2 +-
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> > > drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 +
> > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
> > > drivers/gpu/drm/drm_atomic_helper.c | 1 -
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> > > drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> > > drivers/gpu/drm/drm_probe_helper.c | 2 +-
> > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> > > drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
> > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 +-
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +-
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +-
> > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +-
> > > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 +
> > > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
> > > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
> > > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +-
> > > .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
> > > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
> > > .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
> > > .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
> > > drivers/gpu/drm/i2c/ch7006_priv.h | 2 +-
> > > drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
> > > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> > > drivers/gpu/drm/i915/i915_drv.c | 2 +-
> > > drivers/gpu/drm/i915/intel_crt.c | 2 +-
> > > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > drivers/gpu/drm/i915/intel_dp.c | 2 +-
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > > drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +-
> > > drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
> > > drivers/gpu/drm/imx/imx-ldb.c | 2 +-
> > > drivers/gpu/drm/imx/imx-tve.c | 2 +-
> > > drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
> > > drivers/gpu/drm/imx/parallel-display.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_dpi.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> > > drivers/gpu/drm/meson/meson_crtc.c | 2 +-
> > > drivers/gpu/drm/meson/meson_drv.c | 2 +-
> > > drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> > > drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
> > > drivers/gpu/drm/mgag200/mgag200_mode.c | 1 +
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> > > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 +-
> > > .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 2 +-
> > > .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 2 +-
> > > .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 2 +-
> > > .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +-
> > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
> > > drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 2 +-
> > > drivers/gpu/drm/msm/msm_drv.h | 2 +-
> > > drivers/gpu/drm/msm/msm_fb.c | 2 +-
> > > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 2 +-
> > > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
> > > drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
> > > drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 1 +
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > > drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
> > > drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> > > drivers/gpu/drm/omapdrm/omap_connector.c | 2 +-
> > > drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
> > > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> > > drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
> > > drivers/gpu/drm/omapdrm/omap_encoder.c | 2 +-
> > > drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
> > > drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
> > > drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> > > drivers/gpu/drm/qxl/qxl_drv.c | 3 +-
> > > drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
> > > drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
> > > drivers/gpu/drm/radeon/radeon_acpi.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_connectors.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_device.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_display.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_dp_mst.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_drv.c | 1 +
> > > drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 +
> > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
> > > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> > > .../gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
> > > drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
> > > drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +-
> > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> > > drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> > > drivers/gpu/drm/rockchip/rockchip_rgb.c | 2 +-
> > > drivers/gpu/drm/sti/sti_crtc.c | 2 +-
> > > drivers/gpu/drm/sti/sti_drv.c | 2 +-
> > > drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> > > drivers/gpu/drm/sti/sti_hda.c | 2 +-
> > > drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
> > > drivers/gpu/drm/sti/sti_tvout.c | 2 +-
> > > drivers/gpu/drm/stm/drv.c | 2 +-
> > > drivers/gpu/drm/stm/ltdc.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_lvds.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
> > > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
> > > drivers/gpu/drm/tegra/drm.h | 2 +-
> > > drivers/gpu/drm/tegra/hdmi.c | 2 +-
> > > drivers/gpu/drm/tegra/hub.c | 2 +-
> > > drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +-
> > > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
> > > drivers/gpu/drm/tve200/tve200_drv.c | 2 +-
> > > drivers/gpu/drm/udl/udl_connector.c | 1 +
> > > drivers/gpu/drm/udl/udl_drv.c | 1 +
> > > drivers/gpu/drm/udl/udl_main.c | 1 +
> > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_dpi.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> > > drivers/gpu/drm/vc4/vc4_vec.c | 2 +-
> > > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> > > drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 2 +-
> > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > > drivers/gpu/drm/vkms/vkms_output.c | 2 +-
> > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +-
> > > drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
> > > drivers/gpu/drm/xen/xen_drm_front_conn.c | 2 +-
> > > drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> > > drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> > > drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
> > > drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> > > drivers/gpu/drm/zte/zx_tvenc.c | 2 +-
> > > drivers/gpu/drm/zte/zx_vga.c | 2 +-
> > > drivers/gpu/drm/zte/zx_vou.c | 2 +-
> > > drivers/staging/vboxvideo/vbox_irq.c | 2 +-
> > > drivers/staging/vboxvideo/vbox_mode.c | 2 +-
> > > include/drm/drm_crtc_helper.h | 16 ------
> > > include/drm/drm_probe_helper.h | 50 +++++++++++++++++++
> > > 208 files changed, 256 insertions(+), 200 deletions(-)
> > > create mode 100644 include/drm/drm_probe_helper.h
> >
> > Looks good to me:
> >
> > Acked-by: Thierry Reding <treding@nvidia.com>
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Will Deacon @ 2018-12-10 13:36 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: ard.biesheuvel, catalin.marinas, Steve Capper, linux-mm, jcm,
linux-arm-kernel
In-Reply-To: <be06b735-c6b4-1520-73f6-02a3a8e8af45@arm.com>
On Fri, Dec 07, 2018 at 05:28:58PM +0000, Suzuki K Poulose wrote:
>
>
> On 07/12/2018 15:26, Will Deacon wrote:
> > On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
> > > On 12/06/2018 10:50 PM, Steve Capper wrote:
> > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > > index f60081be9a1b..58fcc1edd852 100644
> > > > --- a/arch/arm64/kernel/head.S
> > > > +++ b/arch/arm64/kernel/head.S
> > > > @@ -707,6 +707,7 @@ secondary_startup:
> > > > /*
> > > > * Common entry point for secondary CPUs.
> > > > */
> > > > + bl __cpu_secondary_check52bitva
> > > > bl __cpu_setup // initialise processor
> > > > adrp x1, swapper_pg_dir
> > > > bl __enable_mmu
> > > > @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
> > > > ret
> > > > ENDPROC(__enable_mmu)
> > > > +ENTRY(__cpu_secondary_check52bitva)
> > > > +#ifdef CONFIG_ARM64_52BIT_VA
> > > > + ldr_l x0, vabits_user
> > > > + cmp x0, #52
> > > > + b.ne 2f > +
> > > > + mrs_s x0, SYS_ID_AA64MMFR2_EL1
> > > > + and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> > > > + cbnz x0, 2f
> > > > +
> > > > + adr_l x0, va52mismatch
> > > > + mov w1, #1
> > > > + strb w1, [x0]
> > > > + dmb sy
> > > > + dc ivac, x0 // Invalidate potentially stale cache line
> > >
> > > You may have to clear this variable before a CPU is brought up to avoid
> > > raising a false error message when another secondary CPU doesn't boot
> > > for some other reason (say granule support) after a CPU failed with lack
> > > of 52bitva. It is really a crazy corner case.
> >
> > Can't we just follow the example set by the EL2 setup in the way that is
> > uses __boot_cpu_mode? In that case, we only need one variable and you can
> > detect a problem by comparing the two halves.
>
> The only difference here is, the support is bolted at boot CPU time and hence
> we need to verify each and every CPU, unlike the __boot_cpu_mode where we
> check for mismatch after the SMP CPUs are brought up. If we decide to make
> the choice later, something like that could work. The only caveat is the 52bit
> kernel VA will have to do something like the above.
So looking at this a bit more, I think we're better off repurposing the
upper bits of the early boot status word to contain a reason code, rather
than introducing new variables for every possible mismatch.
Does the untested diff below look remotely sane to you?
Will
--->8
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index f82b447bd34f..1895561839a9 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -17,15 +17,20 @@
#define __ASM_SMP_H
/* Values for secondary_data.status */
+#define CPU_STUCK_REASON_SHIFT (8)
+#define CPU_BOOT_STATUS_MASK ((1U << CPU_STUCK_REASON_SHIFT) - 1)
-#define CPU_MMU_OFF (-1)
-#define CPU_BOOT_SUCCESS (0)
+#define CPU_MMU_OFF (-1)
+#define CPU_BOOT_SUCCESS (0)
/* The cpu invoked ops->cpu_die, synchronise it with cpu_kill */
-#define CPU_KILL_ME (1)
+#define CPU_KILL_ME (1)
/* The cpu couldn't die gracefully and is looping in the kernel */
-#define CPU_STUCK_IN_KERNEL (2)
+#define CPU_STUCK_IN_KERNEL (2)
/* Fatal system error detected by secondary CPU, crash the system */
-#define CPU_PANIC_KERNEL (3)
+#define CPU_PANIC_KERNEL (3)
+
+#define CPU_STUCK_REASON_52_BIT_VA (1U << CPU_STUCK_REASON_SHIFT)
+#define CPU_STUCK_REASON_NO_GRAN (2U << CPU_STUCK_REASON_SHIFT)
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index c229d9cfe9bf..7377e14884e3 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -809,13 +809,8 @@ ENTRY(__cpu_secondary_check52bitva)
and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
cbnz x0, 2f
- adr_l x0, va52mismatch
- mov w1, #1
- strb w1, [x0]
- dmb sy
- dc ivac, x0 // Invalidate potentially stale cache line
-
- update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x0, x1
+ update_early_cpu_boot_status \
+ CPU_STUCK_IN_KERNEL | CPU_STUCK_REASON_52_BIT_VA, x0, x1
1: wfe
wfi
b 1b
@@ -826,7 +821,8 @@ ENDPROC(__cpu_secondary_check52bitva)
__no_granule_support:
/* Indicate that this CPU can't boot and is stuck in the kernel */
- update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
+ update_early_cpu_boot_status \
+ CPU_STUCK_IN_KERNEL | CPU_STUCK_REASON_NO_GRAN, x1, x2
1:
wfe
wfi
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index e15b0b64d4d0..4e3bfbde829a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -108,7 +108,6 @@ static int boot_secondary(unsigned int cpu, struct task_struct *idle)
}
static DECLARE_COMPLETION(cpu_running);
-bool va52mismatch __ro_after_init;
int __cpu_up(unsigned int cpu, struct task_struct *idle)
{
@@ -138,10 +137,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
-
- if (IS_ENABLED(CONFIG_ARM64_52BIT_VA) && va52mismatch)
- pr_crit("CPU%u: does not support 52-bit VAs\n", cpu);
-
ret = -EIO;
}
} else {
@@ -156,7 +151,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
if (status == CPU_MMU_OFF)
status = READ_ONCE(__early_cpu_boot_status);
- switch (status) {
+ switch (status & CPU_BOOT_STATUS_MASK) {
default:
pr_err("CPU%u: failed in unknown state : 0x%lx\n",
cpu, status);
@@ -170,6 +165,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
pr_crit("CPU%u: may not have shut down cleanly\n", cpu);
case CPU_STUCK_IN_KERNEL:
pr_crit("CPU%u: is stuck in kernel\n", cpu);
+ if (status & CPU_STUCK_REASON_52_BIT_VA)
+ pr_crit("CPU%u: does not support 52-bit VAs\n", cpu);
+ if (status & CPU_STUCK_REASON_NO_GRAN)
+ pr_crit("CPU%u: does not support %luK granule \n", cpu, PAGE_SIZE / SZ_1K);
cpus_stuck_in_kernel++;
break;
case CPU_PANIC_KERNEL:
_______________________________________________
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: ufs_qcom_dump_dbg_regs makes the kernel panic
From: Robin Murphy @ 2018-12-10 13:34 UTC (permalink / raw)
To: Marc Gonzalez, Jeffrey Hugo, Vivek Gautam, Bjorn Andersson,
Andy Gross, David Brown
Cc: MSM, Linux ARM
In-Reply-To: <78a1b262-d366-a3d3-12ce-1a813444b6a7@free.fr>
On 10/12/2018 12:37, Marc Gonzalez wrote:
> Hello,
>
> When the kernel fails to init the UFSHC, it calls ufshcd_print_host_regs()
> to help with debugging, which calls the dbg_register_dump hook.
>
> ufs_qcom_dump_dbg_regs makes the kernel panic:
>
> [ 3.715634] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
> [ 3.722750] UFS_DBG_RD_REG_TXUC 000000b0: 00000001 00000000 00000000 00000004
> [ 3.729943] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> [ 3.737000] Modules linked in:
> [ 3.744371] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G S 4.20.0-rc4 #16
> [ 3.747413] Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
> [ 3.755295] pstate: 00000005 (nzcv daif -PAN -UAO)
> [ 3.761978] pc : __memcpy_fromio+0x68/0x80
> [ 3.766718] lr : ufshcd_dump_regs+0x50/0xb0
> [ 3.770767] sp : ffff00000807ba00
> [ 3.774830] x29: ffff00000807ba00 x28: 00000000fffffffb
> [ 3.778344] x27: ffff0000089db068 x26: ffff8000f6e58000
> [ 3.783728] x25: 000000000000000e x24: 0000000000000800
> [ 3.789023] x23: ffff8000f6e587c8 x22: 0000000000000800
> [ 3.794319] x21: ffff000008908368 x20: ffff8000f6e1ab80
> [ 3.799615] x19: 000000000000006c x18: ffffffffffffffff
> [ 3.804910] x17: 0000000000000000 x16: 0000000000000000
> [ 3.810206] x15: ffff000009199648 x14: ffff000089244187
> [ 3.815502] x13: ffff000009244195 x12: ffff0000091ab000
> [ 3.820797] x11: 0000000005f5e0ff x10: ffff0000091998a0
> [ 3.826093] x9 : 0000000000000000 x8 : ffff8000f6e1ac00
> [ 3.831389] x7 : 0000000000000000 x6 : 0000000000000068
> [ 3.836676] x5 : ffff8000f6e1abe8 x4 : 0000000000000000
> [ 3.841971] x3 : ffff00000928c868 x2 : ffff8000f6e1abec
> [ 3.847267] x1 : ffff00000928c868 x0 : ffff8000f6e1abe8
> [ 3.852567] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
> [ 3.857900] Call trace:
> [ 3.864473] __memcpy_fromio+0x68/0x80
> [ 3.866683] ufs_qcom_dump_dbg_regs+0x1c0/0x370
> [ 3.870522] ufshcd_print_host_regs+0x168/0x190
> [ 3.874946] ufshcd_init+0xd4c/0xde0
> [ 3.879459] ufshcd_pltfrm_init+0x3c8/0x550
> [ 3.883264] ufs_qcom_probe+0x24/0x60
> [ 3.887188] platform_drv_probe+0x50/0xa0
> [ 3.890993] really_probe+0x1f0/0x2a0
> [ 3.894983] driver_probe_device+0x58/0x100
> [ 3.898628] __driver_attach+0xd4/0xe0
> [ 3.902617] bus_for_each_dev+0x74/0xd0
> [ 3.906436] driver_attach+0x20/0x30
> [ 3.910169] bus_add_driver+0x1ac/0x220
> [ 3.913992] driver_register+0x60/0x110
> [ 3.917540] __platform_driver_register+0x40/0x50
> [ 3.921413] ufs_qcom_pltform_init+0x18/0x20
> [ 3.926248] do_one_initcall+0x5c/0x180
> [ 3.930593] kernel_init_freeable+0x198/0x244
> [ 3.934156] kernel_init+0x10/0x110
> [ 3.938629] ret_from_fork+0x10/0x20
> [ 3.941940] Code: f2400842 54000100 8b020002 d503201f (39400023)
> [ 3.945875] ---[ end trace 2d10f654364744f5 ]---
> [ 3.951841] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 3.956528] SMP: stopping secondary CPUs
> [ 5.005502] SMP: failed to stop secondary CPUs 2,7
> [ 5.005648] Kernel Offset: disabled
> [ 5.009292] CPU features: 0x2,21802008
> [ 5.012676] Memory Limit: none
> [ 5.016485] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
>
> The problem appears to be on this line:
>
> reg = ufs_qcom_get_debug_reg_offset(host, UFS_DBG_RD_REG_RXUC);
> /* reg = 0x800 */
> print_fn(hba, reg, 27, "UFS_DBG_RD_REG_RXUC ", priv);
>
> I'm not sure what's going on, because the driver is supposed to map 0x2500 bytes.
> (reg = <0x1da4000 0x2500>;)
It is mapped - you're not getting an MMU fault but an external abort,
which means the access has been translated and gone out, but the
peripheral (or possibly the interconnect in between) didn't like it and
sent some kind of decode error back. Given that you're faulting in
memcpy_from_io() that's not too surprising - using that on actual device
registers (rather than stuff like ioremap()ed SRAM) is generally a bad
idea, since you have no control over things like access size and
ordering that a typical device is sensitive to.
> Commenting out the last 4 dumps of ufs_qcom_print_hw_debug_reg_all() makes
> the panic disappear, but the kernel just hangs after printing UFS_DBG_RD_REG_TXUC
I'd recommend fixing the register dump code to use specific read*()
accesses of the appropriate sizes for each register.
Robin.
_______________________________________________
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/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Faiz Abbas @ 2018-12-10 13:33 UTC (permalink / raw)
To: Sekhar Nori, Nishanth Menon
Cc: mark.rutland, devicetree, ulf.hansson, Arnd Bergmann,
Tony Lindgren, linux-kernel, kishon, t-kristo, robh+dt,
adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <66f9d53b-abec-0a28-8eae-ecb99b075db4@ti.com>
Hi,
On 10/12/18 6:10 PM, Sekhar Nori wrote:
> Hi Nishanth,
>
> On 10/12/18 5:36 PM, Nishanth Menon wrote:
>> On 13:33-20181210, Sekhar Nori wrote:
>>> On 08/12/18 9:24 PM, Nishanth Menon wrote:
>>>> On 14:12-20181207, Faiz Abbas wrote:
>>>>
>>>>> +
>>>>> +&sdhci0 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mmc0_pins_default>;
>>>>> + bus-width = <8>;
>>>>> + non-removable;
>>>>> + ti,driver-strength-ohm = <50>;
>>>>
>>>> ^^
>>>>
>>>>> +};
>>>>> +
>>>>> +&sdhci1 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mmc1_pins_default>;
>>>>> + ti,driver-strength-ohm = <50>;
>>>>
>>>> NAK.
>>>>
>>>> $ git checkout next-20181207
>>>> $ git grep ti,driver-strength-ohm Documentation
>>>> $
>>>>
>>>> Nada.. And.. I think "new phy binding" probably introduces this.
>>>> [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185
>>>>
>>>> If your patches are'nt really ready, please send them as RFC, I am not
>>>> really in a mood to track the status of every single driver subsystem.
>>>>
>>>> If your binding is not in linux next at the baremin, as far as I am
>>>> concerned, this is not ready, and should be RFC.
>>>
>>> No, RFC does not say "do not merge" or "this has dependencies". RFC is
>>> used to invite a stronger review when introducing a new concept. Its
>>> fair game to apply patches marked RFC if maintainer is okay with the
>>> content.
>>
>> True, fair enough.. RFC is request for comments. Anyways, that is
>> besides the point.
>>>
>>> Dependencies are either noted in cover-letter or below the patch
>>> tear-line. With what you are asking, looks like patches need to be
>>> resubmitted once dependencies are cleared, even if there is no change in
>>> the content itself. This will be additional work.
>>
>> Yes please. There would be other dts changes that are probably ready and
>> I really wont be tracking everything happening on other drivers. If the
>> binding is present at least in next, it is a good indication of things
>> clean and ready to go.
>
> Agree that bindings should be in linux-next before device-tree files are
> merged.
>
>>
>>>
>>> That said, if it makes life convenient for you, you can impose such a
>>> rule for patches you need to handle. But I think it will take some
>>> getting used for developers who send patches to you as I don't think
>>> this is a norm elsewhere.
>>>
>>> Adding Tony and Arnd as well, in case I have missed some recently
>>> accepted convention.
>>
>>
>> I have'nt looked at any conventions, The style I prefer to follow when I do
>> submissions: It is my job to get the bindings in, until then my actual
>> dts is just "request for comments". Only after the bindings are merged
>> do I formally submit dts - simply because I dont expect dts maintainer
>> to track what happened to my driver's binding and discussions there of.
>
> Ok.
>
>>
>> Seriously, is'nt it really reasonable for dts maintainer to check every
>> single driver's development status in 15 different mailing lists?
>> Because, it sounds like what you are asking. At least I wont have time
>> for it..
>>
>>
>> I really am curious how Arnd / Tony actually pull this one off.. If they
>> have continous cron job for checking if your patch is ready... I doubt
>> it..
>
> I think you can rely on the author to tell you when something is> actually ready to be merged (and you can tell him/her to remind you).
Yes. I will ping Nishanth once the bindings are in next.
Thanks,
Faiz
_______________________________________________
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/2] arm64: dts: ti: k3-am654: Add Support for MMC/SD
From: Faiz Abbas @ 2018-12-10 13:30 UTC (permalink / raw)
To: Nishanth Menon, Vignesh R
Cc: mark.rutland, devicetree, ulf.hansson, linux-kernel,
adrian.hunter, t-kristo, robh+dt, kishon, michal.simek,
linux-arm-kernel
In-Reply-To: <20181208154526.ivbvwvcx6otg7lvh@akan>
Hi Nishanth,
On 08/12/18 9:15 PM, Nishanth Menon wrote:
> On 10:56-20181208, Vignesh R wrote:
>>
>>
>> On 07/12/18 2:12 PM, Faiz Abbas wrote:
>>> There are two MMC host controller instances present on the TI's
>>> Am654 SOCs. Add device tree nodes for the same.
>>>
>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>> ---
>>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 28 ++++++++++++++++++++++++
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> index 916434839603..d07212f16a81 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> @@ -129,4 +129,32 @@
>>> clocks = <&k3_clks 113 1>;
>>> power-domains = <&k3_pds 113>;
>>> };
>>> +
>>> + sdhci0: sdhci@4f80000 {
>>> + compatible = "ti,am654-sdhci-5.1";
>>> + reg = <0x0 0x4f80000 0x0 0x260>, <0x0 0x4f90000 0x0 0x134>;
>>> + power-domains = <&k3_pds 47>;
>>> + clocks = <&k3_clks 47 0>, <&k3_clks 47 1>;
>>> + clock-names = "clk_ahb", "clk_xin";
>>> + interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
>>> + sdhci-caps-mask = <0x80000007 0x0>;
>>> + mmc-ddr-1_8v;
>>> + ti,otap-del-sel = <0x2>;
>>> + ti,trm-icp = <0x8>;
>>> + status = "disabled";
>>> + };
>>
>> Please drop "status=disabled" from dtsi. Can be disabled as required in
>> the board dts.
>
>
> yes - the standard in k3 is to disable the nodes that are'nt needed in
> board.dtsi.
>
> This is different from "disabled by default" approach in DRA7 or OMAP4
> for example.
>
Ok. Will fix in v2.
Thanks,
Faiz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: meson-gxm: Add Mali-T820 node
From: Neil Armstrong @ 2018-12-10 13:22 UTC (permalink / raw)
To: khilman
Cc: Neil Armstrong, Christian Hewitt, linux-kernel, dri-devel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181210132227.29262-1-narmstrong@baylibre.com>
From: Christian Hewitt <christianshewitt@gmail.com>
The Amlogic Meson GXM SoC embeds an ARM Mali T820 GPU.
This patch adds the node with all the needed properties to power
on the GPU.
This has been tested with the work-in-progress PanFrost project
aiming support for ARM Mali Midgard and later GPUs.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index 247888d68a3a..35e59d390903 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -91,6 +91,33 @@
reset-names = "phy";
status = "okay";
};
+
+ mali: gpu@c0000 {
+ compatible = "amlogic,meson-gxm-mali", "arm,mali-t820";
+ reg = <0x0 0xc0000 0x0 0x40000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpu", "mmu", "job";
+ clocks = <&clkc CLKID_MALI>;
+ resets = <&reset RESET_MALI_CAPB3>, <&reset RESET_MALI>;
+
+ /*
+ * Mali clocking is provided by two identical clock paths
+ * MALI_0 and MALI_1 muxed to a single clock by a glitch
+ * free mux to safely change frequency while running.
+ */
+ assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+ <&clkc CLKID_MALI_0>,
+ <&clkc CLKID_MALI>; /* Glitch free mux */
+ assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+ <0>, /* Do Nothing */
+ <&clkc CLKID_MALI_0>;
+ assigned-clock-rates = <0>, /* Do Nothing */
+ <666666666>,
+ <0>; /* Do Nothing */
+ };
};
&clkc_AO {
--
2.19.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 1/2] dt-bindings: gpu: mali-midgard: Add resets property
From: Neil Armstrong @ 2018-12-10 13:22 UTC (permalink / raw)
To: devicetree, khilman
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, dri-devel,
Neil Armstrong
In-Reply-To: <20181210132227.29262-1-narmstrong@baylibre.com>
The Amlogic ARM Mali Midgard requires reset controls to power on and
software reset the GPU, adds these as optional in the bindings.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index 18a2cde2e5f3..24d83ec952f1 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -37,6 +37,8 @@ Optional properties:
- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
for details.
+- resets : Phandle to the reset controls for the Mali Midgard device.
+
Example for a Mali-T760:
--
2.19.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 v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Simon Horman @ 2018-12-10 13:22 UTC (permalink / raw)
To: Biju Das
Cc: linux-rtc@vger.kernel.org, Fabrizio Castro, Alexandre Belloni,
Geert Uytterhoeven, Magnus Damm, Russell King,
linux-renesas-soc@vger.kernel.org, Chris Paterson,
Srinivas Kandagatla, linux-arm-kernel@lists.infradead.org
In-Reply-To: <OSBPR01MB2103861EF91EE6456EB3E03BB8A50@OSBPR01MB2103.jpnprd01.prod.outlook.com>
On Mon, Dec 10, 2018 at 12:35:35PM +0000, Biju Das wrote:
> Hi Simon,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in
> > shmobile_defconfig
> >
> > On Fri, Dec 07, 2018 at 11:27:45AM +0000, Biju Das wrote:
> > > The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
> > > support enable the driver in the shmobile_defconfig multiplatform
> > > configuration.
> > >
> > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks, applied for v4.22.
> >
> > Is a similar change for multi_v7_defconfig also appropriate?
>
> Will send a separate patch for adding it to the "multi_v7_defconfig"
>
> CONFIG_RTC_DRV_PCF85363=m
Great, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] arm64: meson-gxm: Add support for the Mali T820 GPU
From: Neil Armstrong @ 2018-12-10 13:22 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, dri-devel,
Neil Armstrong
This patchset adds :
- Optional reset properties in the midgard bindings
- Mali T820 Node in Amlogic Meson GXM DTSI
Christian Hewitt (1):
arm64: dts: meson-gxm: Add Mali-T820 node
Neil Armstrong (1):
dt-bindings: gpu: mali-midgard: Add resets property
.../bindings/gpu/arm,mali-midgard.txt | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 27 +++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.19.2
_______________________________________________
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] kvm/arm: return 0 when the number of objects is not lessthan min
From: Christoffer Dall @ 2018-12-10 13:13 UTC (permalink / raw)
To: peng.hao2; +Cc: marc.zyngier, drjones, kvmarm, linux-arm-kernel, linux-kernel
In-Reply-To: <201812060956304771332@zte.com.cn>
On Thu, Dec 06, 2018 at 09:56:30AM +0800, peng.hao2@zte.com.cn wrote:
> >On Wed, Dec 05, 2018 at 09:15:51AM +0800, Peng Hao wrote:
> >> Return 0 when there is enough kvm_mmu_memory_cache object.
> >>
> >> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
> >> ---
> >> virt/kvm/arm/mmu.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index ed162a6..fcda0ce 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -127,7 +127,7 @@ static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
> >> while (cache->nobjs < max) {
> >> page = (void *)__get_free_page(PGALLOC_GFP);
> >> if (!page)
> >> - return -ENOMEM;
> >> + return cache->nobjs >= min ? 0 : -ENOMEM;
> >
> >This condition will never be true here, as the exact same condition is
> >already checked above, and if it had been true, then we wouldn't be here.
> >
> >What problem are you attempting to solve?
> >
> if (cache->nobjs >= min) ------here cache->nobjs<min,it can continue downward
> return 0;
> while (cache->nobjs < max) {
> page = (void *)__get_free_page(PGALLOC_GFP);
> if (!page)
> return -ENOMEM; -----here it is possible that (cache->nobjs >= min) and (cache->nobjs<max)
> cache->objects[cache->nobjs++] = page; ---here cache->nobjs increasing
> }
>
> I just think the logic of this function is to return 0 as long as (cache->nobjs >= min).
> thanks.
That's not the intention, nor is it on any of the other architectures
implementing the same thing (this one goes on the list of stuff we
should be sharing between architectures).
The idea is that you fill up the cache when it goes below min, and you
are always able to fill up to max.
If you're not able to fill up to max, then your system is seriously low
on memory and continuing to run this VM is not likely to be a good idea,
so you might as well tell user space to do something now instead of
waiting until the situation is even worse.
Thanks,
Christoffer
_______________________________________________
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 v3 04/12] soc: mediatek: add new flow for mtcmos power.
From: Nicolas Boichat @ 2018-12-10 12:52 UTC (permalink / raw)
To: Weiyi Lu
Cc: Rob Herring, srv_heupstream, jamesjj.liao, sboyd, lkml, stable,
Fan Chen, linux-mediatek, Matthias Brugger, Cheng Mars, owen.chen,
linux-clk, linux-arm Mailing List
In-Reply-To: <20181210073240.32278-6-weiyi.lu@mediatek.com>
On Mon, Dec 10, 2018 at 3:33 PM Weiyi Lu <weiyi.lu@mediatek.com> wrote:
>
> From: Owen Chen <owen.chen@mediatek.com>
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following change
> 1. bus protect need not only infracfg but smi_common registers involved
> to setup. Therefore we add a set/clr APIs with more customize arguments.
>
> The second change is that we also add subsys CG control flow before/after
> the bus protect/sram control, due to bus protect need SMI bus relative CGs
> enable to feed-back its ack, and some master's sram control need CG enable
> to on/off its resource sequentially.
>
> With the following change
> 1. turn on subsys CG before sram pwron and release bus protect.
> 2. turn off subsys CG after the process of set bus protect/receive
> ack/disable sram.
>
> The last change is for some power domains like vpu_core on MT8183 whose
> sram need to do clock and internal isolation while power on/off sram.
> We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we need to
> do the extra sram isolation control or not.
>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> drivers/soc/mediatek/Makefile | 2 +-
> drivers/soc/mediatek/mtk-scpsys-ext.c | 99 ++++++
> drivers/soc/mediatek/mtk-scpsys.c | 390 ++++++++++++++++++------
> include/linux/soc/mediatek/scpsys-ext.h | 39 +++
> 4 files changed, 443 insertions(+), 87 deletions(-)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
> create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 12998b08819e..9dc6670c19cb 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c b/drivers/soc/mediatek/mtk-scpsys-ext.c
> new file mode 100644
> index 000000000000..54df42db2a8f
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen <Owen.Chen@mediatek.com>
> + */
> +#include <linux/ktime.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +#include <linux/soc/mediatek/scpsys-ext.h>
> +
> +#define MTK_POLL_DELAY_US 10
> +#define MTK_POLL_TIMEOUT (jiffies_to_usecs(HZ))
That's just USEC_PER_SEC.
> +
> +static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_set, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_set)
> + regmap_write(map, reg_set, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, mask);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, (val & ack_mask) == ack_mask,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_clr, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_clr)
> + regmap_write(map, reg_clr, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, 0);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, !(val & ack_mask),
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = set_bus_protection(map,
> + bp_table[i].mask, bp_table[i].mask,
> + bp_table[i].set_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = MAX_STEPS - 1; i >= 0; i--) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = clear_bus_protection(map,
> + bp_table[i].mask, bp_table[i].clr_ack_mask,
> + bp_table[i].clr_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index 5b24bb4bfbf6..98ccef566ce1 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -1,15 +1,8 @@
> -/*
> - * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2015 Pengutronix
> +// Author: Sascha Hauer <kernel@pengutronix.de>
I'm not super familiar with copyright rules in Germany, but I would
not change this line. I.e., I'd keep:
// Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> +
> #include <linux/clk.h>
> #include <linux/init.h>
> #include <linux/io.h>
> @@ -20,6 +13,7 @@
> #include <linux/pm_domain.h>
> #include <linux/regulator/consumer.h>
> #include <linux/soc/mediatek/infracfg.h>
> +#include <linux/soc/mediatek/scpsys-ext.h>
>
> #include <dt-bindings/power/mt2701-power.h>
> #include <dt-bindings/power/mt2712-power.h>
> @@ -64,6 +58,8 @@
> #define PWR_ON_BIT BIT(2)
> #define PWR_ON_2ND_BIT BIT(3)
> #define PWR_CLK_DIS_BIT BIT(4)
> +#define PWR_SRAM_CLKISO_BIT BIT(5)
> +#define PWR_SRAM_ISOINT_B_BIT BIT(6)
>
> #define PWR_STATUS_CONN BIT(1)
> #define PWR_STATUS_DISP BIT(3)
> @@ -115,16 +111,38 @@ static const char * const clk_names[] = {
> };
>
> #define MAX_CLKS 3
> -
> +#define MAX_SUBSYS_CLKS 10
> +
> +/**
> + * struct scp_domain_data - scp domain data for power on/off flow
> + * @name: The domain name.
> + * @sta_mask: The mask for power on/off status bit.
> + * @ctl_offs: The offset for main power control register.
Thanks for adding documentation, but @sram_iso_ctrl is missing here.
> + * @sram_pdn_bits: The mask for sram power control bits.
> + * @sram_pdn_ack_bits: The mask for sram power control acked bits.
> + * @bus_prot_mask: The mask for single step bus protection.
> + * @clk_id: The basic clock needs to be enabled before enabling certain
> + * power domains.
> + * @basic_clk_name: provide the same purpose with field "clk_id"
> + * by declaring basic clock prefix name rather than clk_id.
> + * @subsys_clk_prefix: The prefix name of the clocks need to be enabled
> + * before releasing bus protection.
> + * @caps: The flag for active wake-up action.
> + * @bp_table: The mask table for multiple step bus protection.
> + */
> struct scp_domain_data {
> const char *name;
> u32 sta_mask;
> int ctl_offs;
> + bool sram_iso_ctrl;
> u32 sram_pdn_bits;
> u32 sram_pdn_ack_bits;
> u32 bus_prot_mask;
> enum clk_id clk_id[MAX_CLKS];
> + const char *basic_clk_name[MAX_CLKS];
> + const char *subsys_clk_prefix;
> u8 caps;
> + struct bus_prot bp_table[MAX_STEPS];
> };
>
> struct scp;
> @@ -133,6 +151,7 @@ struct scp_domain {
> struct generic_pm_domain genpd;
> struct scp *scp;
> struct clk *clk[MAX_CLKS];
> + struct clk *subsys_clk[MAX_SUBSYS_CLKS];
> const struct scp_domain_data *data;
> struct regulator *supply;
> };
> @@ -148,6 +167,7 @@ struct scp {
> struct device *dev;
> void __iomem *base;
> struct regmap *infracfg;
> + struct regmap *smi_common;
> struct scp_ctrl_reg ctrl_reg;
> bool bus_prot_reg_update;
> };
> @@ -188,32 +208,166 @@ static int scpsys_domain_is_on(struct scp_domain *scpd)
> return -EINVAL;
> }
>
> +static int scpsys_regulator_enable(struct scp_domain *scpd)
> +{
> + if (!scpd->supply)
> + return 0;
> + else
nit: Else branch not strictly needed.
> + return regulator_enable(scpd->supply);
> +}
> +
> +static int scpsys_regulator_disable(struct scp_domain *scpd)
> +{
> + if (!scpd->supply)
> + return 0;
> + else
> + return regulator_disable(scpd->supply);
> +}
> +
> +static int scpsys_clk_enable(struct clk *clk[], int max_num)
> +{
> + int i, ret = 0;
> +
> + for (i = 0; i < max_num && clk[i]; i++) {
> + ret = clk_prepare_enable(clk[i]);
> + if (ret) {
> + for (--i; i >= 0; i--)
> + clk_disable_unprepare(clk[i]);
> +
> + break;
> + }
> + }
> +
> + return ret;
> +}
> +
> +static int scpsys_clk_disable(struct clk *clk[], int max_num)
> +{
> + int i;
> +
> + for (i = max_num - 1; i >= 0; i--) {
> + if (clk[i])
> + clk_disable_unprepare(clk[i]);
> + }
> +
> + return 0;
> +}
> +
> +static int scpsys_sram_enable(struct scp_domain *scpd, void __iomem *ctl_addr)
> +{
> + u32 val;
> + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> + int tmp, ret = 0;
> +
> + val = readl(ctl_addr) & ~scpd->data->sram_pdn_bits;
> + writel(val, ctl_addr);
> +
> + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> + if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> + /*
> + * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> + * MT7622_POWER_DOMAIN_WB and thus just a trivial setup
> + * is applied here.
> + */
> + usleep_range(12000, 12100);
> + } else {
> + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> + ret = readl_poll_timeout(ctl_addr, tmp,
> + (tmp & pdn_ack) == 0,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> + }
> +
> + if (scpd->data->sram_iso_ctrl) {
Are we ok with doing this even if readl_poll_timeout fails? Should we
return ret earlier?
> + val = readl(ctl_addr) | PWR_SRAM_ISOINT_B_BIT;
> + writel(val, ctl_addr);
> + udelay(1);
> + val &= ~PWR_SRAM_CLKISO_BIT;
> + writel(val, ctl_addr);
> + }
> +
> + return ret;
> +}
> +
> +static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
> +{
> + u32 val;
> + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> + int tmp, ret = 0;
No need to init ret to 0.
> +
> + if (scpd->data->sram_iso_ctrl) {
> + val = readl(ctl_addr);
> + val |= PWR_SRAM_CLKISO_BIT;
> + writel(val, ctl_addr);
> + val &= ~PWR_SRAM_ISOINT_B_BIT;
> + writel(val, ctl_addr);
> + udelay(1);
> + }
> +
> + val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
> + writel(val, ctl_addr);
> +
> + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> + ret = readl_poll_timeout(ctl_addr, tmp,
> + (tmp & pdn_ack) == pdn_ack,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +
> + return ret;
Just return readl_poll_timeout.
> +}
> +
> +static int scpsys_bus_protect_enable(struct scp_domain *scpd)
> +{
> + struct scp *scp = scpd->scp;
> + int ret = 0;
> +
> + if (scpd->data->bus_prot_mask) {
> + ret = mtk_infracfg_set_bus_protection(scp->infracfg,
> + scpd->data->bus_prot_mask,
> + scp->bus_prot_reg_update);
> + } else if (scpd->data->bp_table[0].mask) {
> + ret = mtk_scpsys_ext_set_bus_protection(scpd->data->bp_table,
> + scp->infracfg,
> + scp->smi_common);
> + }
> +
> + return ret;
More simply:
if (scpd->data->bus_prot_mask)
return mtk_infracfg_set_bus_protection(scp->infracfg,
scpd->data->bus_prot_mask,
scp->bus_prot_reg_update);
if (scpd->data->bp_table[0].mask)
return mtk_scpsys_ext_set_bus_protection(scpd->data->bp_table,
scp->infracfg,
scp->smi_common);
return 0;
(feel free to add else's, if you like that better)
> +}
> +
> +static int scpsys_bus_protect_disable(struct scp_domain *scpd)
> +{
> + struct scp *scp = scpd->scp;
> + int ret = 0;
> +
> + if (scpd->data->bus_prot_mask) {
> + ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> + scpd->data->bus_prot_mask,
> + scp->bus_prot_reg_update);
> + } else if (scpd->data->bp_table[0].mask) {
> + ret = mtk_scpsys_ext_clear_bus_protection(
> + scpd->data->bp_table,
> + scp->infracfg,
> + scp->smi_common);
> + }
> +
> + return ret;
ditto
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> struct scp *scp = scpd->scp;
> void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
> - int i;
> -
> - if (scpd->supply) {
> - ret = regulator_enable(scpd->supply);
> - if (ret)
> - return ret;
> - }
>
> - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++) {
> - ret = clk_prepare_enable(scpd->clk[i]);
> - if (ret) {
> - for (--i; i >= 0; i--)
> - clk_disable_unprepare(scpd->clk[i]);
> + ret = scpsys_regulator_enable(scpd);
> + if (ret < 0)
> + return ret;
>
> - goto err_clk;
> - }
> - }
> + ret = scpsys_clk_enable(scpd->clk, MAX_CLKS);
> + if (ret)
> + goto err_clk;
>
> + /* subsys power on */
> val = readl(ctl_addr);
> val |= PWR_ON_BIT;
> writel(val, ctl_addr);
> @@ -235,43 +389,26 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> val |= PWR_RST_B_BIT;
> writel(val, ctl_addr);
>
> - val &= ~scpd->data->sram_pdn_bits;
> - writel(val, ctl_addr);
> -
> - /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> - if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> - /*
> - * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> - * MT7622_POWER_DOMAIN_WB and thus just a trivial setup is
> - * applied here.
> - */
> - usleep_range(12000, 12100);
> + ret = scpsys_clk_enable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
> + if (ret < 0)
> + goto err_pwr_ack;
>
> - } else {
> - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> - if (ret < 0)
> - goto err_pwr_ack;
> - }
> + ret = scpsys_sram_enable(scpd, ctl_addr);
> + if (ret < 0)
> + goto err_sram;
>
> - if (scpd->data->bus_prot_mask) {
> - ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> - scpd->data->bus_prot_mask,
> - scp->bus_prot_reg_update);
> - if (ret)
> - goto err_pwr_ack;
> - }
> + ret = scpsys_bus_protect_disable(scpd);
> + if (ret < 0)
> + goto err_sram;
>
> return 0;
>
> +err_sram:
> + scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
> err_pwr_ack:
> - for (i = MAX_CLKS - 1; i >= 0; i--) {
> - if (scpd->clk[i])
> - clk_disable_unprepare(scpd->clk[i]);
> - }
> + scpsys_clk_disable(scpd->clk, MAX_CLKS);
> err_clk:
> - if (scpd->supply)
> - regulator_disable(scpd->supply);
> + scpsys_regulator_disable(scpd);
>
> dev_err(scp->dev, "Failed to power on domain %s\n", genpd->name);
>
> @@ -283,29 +420,21 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> struct scp *scp = scpd->scp;
> void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
> - int i;
>
> - if (scpd->data->bus_prot_mask) {
> - ret = mtk_infracfg_set_bus_protection(scp->infracfg,
> - scpd->data->bus_prot_mask,
> - scp->bus_prot_reg_update);
> - if (ret)
> - goto out;
> - }
> -
> - val = readl(ctl_addr);
> - val |= scpd->data->sram_pdn_bits;
> - writel(val, ctl_addr);
> + ret = scpsys_bus_protect_enable(scpd);
> + if (ret < 0)
> + goto out;
>
> - /* wait until SRAM_PDN_ACK all 1 */
> - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == pdn_ack,
> - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> + ret = scpsys_sram_disable(scpd, ctl_addr);
> if (ret < 0)
> goto out;
>
> + ret = scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
> +
> + /* subsys power off */
> + val = readl(ctl_addr);
> val |= PWR_ISO_BIT;
> writel(val, ctl_addr);
>
> @@ -327,11 +456,9 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> if (ret < 0)
> goto out;
>
> - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++)
> - clk_disable_unprepare(scpd->clk[i]);
> + scpsys_clk_disable(scpd->clk, MAX_CLKS);
>
> - if (scpd->supply)
> - regulator_disable(scpd->supply);
> + scpsys_regulator_disable(scpd);
>
> return 0;
>
> @@ -341,6 +468,65 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> return ret;
> }
>
> +static int init_subsys_clks(struct platform_device *pdev,
> + const char *prefix, struct clk **clk)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + u32 prefix_len, sub_clk_cnt = 0;
> + int str_sz, clk_idx, ret;
> +
> + if (!node) {
> + dev_err(&pdev->dev, "Cannot find scpsys node: %ld\n",
> + PTR_ERR(node));
> + return PTR_ERR(node);
> + }
> +
> + str_sz = of_property_count_strings(node, "clock-names");
> + if (str_sz < 0) {
> + dev_err(&pdev->dev, "Cannot get any subsys strings: %d\n",
> + str_sz);
> + return str_sz;
> + }
Would it be nicer to use of_property_for_each_string to iterate over
the clock-names?
> +
> + prefix_len = strlen(prefix);
> +
> + for (clk_idx = 0; clk_idx < str_sz; clk_idx++) {
> + const char *clk_name;
> +
> + ret = of_property_read_string_index(node, "clock-names",
> + clk_idx, &clk_name);
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "Cannot read subsys string[%d]: %d\n",
> + clk_idx, ret);
> + return ret;
> + }
> +
> + if (!strncmp(clk_name, prefix, prefix_len) &&
> + (clk_name[prefix_len] == '-')) {
> + if (sub_clk_cnt >= MAX_SUBSYS_CLKS) {
> + dev_err(&pdev->dev,
> + "subsys clk out of range %d\n",
> + sub_clk_cnt);
> + return -ENOMEM;
> + }
> +
> + clk[sub_clk_cnt] = devm_clk_get(&pdev->dev,
> + clk_name);
> +
> + if (IS_ERR(clk)) {
> + dev_err(&pdev->dev,
> + "Subsys clk read fail %ld\n",
> + PTR_ERR(clk));
> + return PTR_ERR(clk);
> + }
> + sub_clk_cnt++;
> + }
> + }
> +
> + return sub_clk_cnt;
> +}
> +
> static void init_clks(struct platform_device *pdev, struct clk **clk)
> {
> int i;
> @@ -396,6 +582,17 @@ static struct scp *init_scp(struct platform_device *pdev,
> return ERR_CAST(scp->infracfg);
> }
>
> + scp->smi_common = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "smi_comm");
> +
> + if (scp->smi_common == ERR_PTR(-ENODEV)) {
> + scp->smi_common = NULL;
> + } else if (IS_ERR(scp->smi_common)) {
> + dev_err(&pdev->dev, "Cannot find smi_common controller: %ld\n",
> + PTR_ERR(scp->smi_common));
> + return ERR_CAST(scp->smi_common);
> + }
> +
> for (i = 0; i < num; i++) {
> struct scp_domain *scpd = &scp->domains[i];
> const struct scp_domain_data *data = &scp_domain_data[i];
> @@ -417,22 +614,43 @@ static struct scp *init_scp(struct platform_device *pdev,
> struct scp_domain *scpd = &scp->domains[i];
> struct generic_pm_domain *genpd = &scpd->genpd;
> const struct scp_domain_data *data = &scp_domain_data[i];
> + int clk_cnt;
>
> pd_data->domains[i] = genpd;
> scpd->scp = scp;
>
> scpd->data = data;
>
> - for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> - struct clk *c = clk[data->clk_id[j]];
> + if (data->clk_id[0]) {
> + for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> + struct clk *c = clk[data->clk_id[j]];
>
> - if (IS_ERR(c)) {
> - dev_err(&pdev->dev, "%s: clk unavailable\n",
> - data->name);
> - return ERR_CAST(c);
> + if (IS_ERR(c)) {
> + dev_err(&pdev->dev,
> + "%s: clk unavailable\n",
> + data->name);
> + return ERR_CAST(c);
> + }
> +
> + scpd->clk[j] = c;
> }
> + } else if (data->basic_clk_name[0]) {
> + for (j = 0; j < MAX_CLKS &&
> + data->basic_clk_name[j]; j++)
> + scpd->clk[j] = devm_clk_get(&pdev->dev,
> + data->basic_clk_name[j]);
> + }
>
> - scpd->clk[j] = c;
> + if (data->subsys_clk_prefix) {
> + clk_cnt = init_subsys_clks(pdev,
> + data->subsys_clk_prefix,
> + scpd->subsys_clk);
> + if (clk_cnt < 0) {
> + dev_err(&pdev->dev,
> + "%s: subsys clk unavailable\n",
> + data->name);
> + return ERR_PTR(clk_cnt);
> + }
> }
>
> genpd->name = data->name;
> diff --git a/include/linux/soc/mediatek/scpsys-ext.h b/include/linux/soc/mediatek/scpsys-ext.h
> new file mode 100644
> index 000000000000..d0ed295c88a7
> --- /dev/null
> +++ b/include/linux/soc/mediatek/scpsys-ext.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __SOC_MEDIATEK_SCPSYS_EXT_H
> +#define __SOC_MEDIATEK_SCPSYS_EXT_H
> +
> +#define MAX_STEPS 4
> +
> +#define BUS_PROT(_type, _set_ofs, _clr_ofs, \
> + _en_ofs, _sta_ofs, _mask, _clr_ack_mask) { \
> + .type = _type, \
> + .set_ofs = _set_ofs, \
> + .clr_ofs = _clr_ofs, \
> + .en_ofs = _en_ofs, \
> + .sta_ofs = _sta_ofs, \
> + .mask = _mask, \
> + .clr_ack_mask = _clr_ack_mask, \
> + }
> +
> +enum regmap_type {
> + IFR_TYPE,
> + SMI_TYPE,
> + MAX_REGMAP_TYPE,
> +};
> +
> +struct bus_prot {
> + enum regmap_type type;
> + u32 set_ofs;
> + u32 clr_ofs;
> + u32 en_ofs;
> + u32 sta_ofs;
> + u32 mask;
> + u32 clr_ack_mask;
> +};
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common);
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common);
> +
> +#endif /* __SOC_MEDIATEK_SCPSYS_EXT_H */
> --
> 2.18.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 v9 6/8] fs, arm64: untag user address in copy_mount_options
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
In copy_mount_options a user address is being subtracted from TASK_SIZE.
If the address is lower than TASK_SIZE, the size is calculated to not
allow the exact_copy_from_user() call to cross TASK_SIZE boundary.
However if the address is tagged, then the size will be calculated
incorrectly.
Untag the address before subtracting.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
fs/namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index a7f91265ea67..694dcedb7e7d 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2686,7 +2686,7 @@ void *copy_mount_options(const void __user * data)
* the remainder of the page.
*/
/* copy_from_user cannot cross TASK_SIZE ! */
- size = TASK_SIZE - (unsigned long)data;
+ size = TASK_SIZE - (unsigned long)untagged_addr(data);
if (size > PAGE_SIZE)
size = PAGE_SIZE;
--
2.20.0.rc2.403.gdbc3b29805-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
* [PATCH v9 2/8] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-12-10 12:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides arm64.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
include/linux/uaccess.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1cdd47..42b7a4ac65e2 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -13,6 +13,10 @@
#include <asm/uaccess.h>
+#ifndef untagged_addr
+#define untagged_addr(addr) (addr)
+#endif
+
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
* and get rid of their private instances of copy_{to,from}_user() and
--
2.20.0.rc2.403.gdbc3b29805-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
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