From: Tero Kristo <t-kristo@ti.com>
To: Tony Lindgren <tony@atomide.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Pavel Machek <pavel@ucw.cz>, <pali.rohar@gmail.com>,
<sre@kernel.org>, kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
<linux-omap@vger.kernel.org>, <khilman@kernel.org>,
<aaro.koskinen@iki.fi>, <ivo.g.dimitrov.75@gmail.com>,
<patrikbachan@gmail.com>, <serge@hallyn.com>,
<abcloriens@gmail.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Russell King <linux@armlinux.org.uk>
Subject: Re: n900 in next-20170901
Date: Tue, 14 Nov 2017 21:31:21 +0200 [thread overview]
Message-ID: <5c885f60-bc8c-5f8e-dc81-57eacc57abc8@ti.com> (raw)
In-Reply-To: <20171114173719.GA28152@atomide.com>
On 14/11/17 19:37, Tony Lindgren wrote:
> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171114 06:34]:
>> On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote:
>>> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171110 06:34]:
>>>> On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote:
>>>>> +#define OMAP34XX_SRAM_PHYS 0x40200000
>>>>> +#define OMAP34XX_SRAM_VIRT 0xd0010000
>>>>> +#define OMAP34XX_SRAM_SIZE 0x10000
>>>>
>>>> For my testing environment, vmalloc address space is started at
>>>> roughly 0xe0000000 so 0xd0010000 would not be valid.
>>>
>>> Well we can map it anywhere we want, got any preferences?
>>
>> My testing environment is a beagle-(xm?) for QEMU. It is configured by
>> CONFIG_VMSPLIT_3G=y so kernel address space is started at 0xc0000000.
>> And, it has 512 MB memory so 0xc0000000 ~ 0xdff00000 is used for
>> direct mapping. See below.
>>
>> [ 0.000000] Memory: 429504K/522240K available (11264K kernel code,
>> 1562K rwdata, 4288K rodata, 2048K init, 405K bss, 27200K reserved,
>> 65536K cma-reserved, 0K highmem)
>> [ 0.000000] Virtual kernel memory layout:
>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
>> [ 0.000000] vmalloc : 0xe0000000 - 0xff800000 ( 504 MB)
>> [ 0.000000] lowmem : 0xc0000000 - 0xdff00000 ( 511 MB)
>> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
>> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
>> [ 0.000000] .text : 0xc0208000 - 0xc0e00000 (12256 kB)
>> [ 0.000000] .init : 0xc1300000 - 0xc1500000 (2048 kB)
>> [ 0.000000] .data : 0xc1500000 - 0xc1686810 (1563 kB)
>> [ 0.000000] .bss : 0xc168fc68 - 0xc16f512c ( 406 kB)
>>
>> Therefore, if OMAP34XX_SRAM_VIRT is 0xd0010000, direct mapping is
>> broken and the system doesn't work. I guess that we should use more
>> stable address like as 0xf0000000.
>
> OK. Let's forget about adding static mappings and my earlier
> patches to attempt to fix this. Below is what I now think we should
> merge as a fix before merging Joonsoo's patches. Please all review
> and test, adding Tero to Cc also.
>
> Regards,
>
> Tony
>
> 8< -----------------------
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 13 Nov 2017 13:23:33 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix SRAM virt to phys translation for
> save_secure_ram_context
>
> With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it
> was noticed that n900 stopped booting. After investigating it turned
> out that n900 save_secure_ram_context does some whacky virtual to
> physical address translation for the SRAM data address.
>
> As we now only have minimal parts of omap3 idle code copied to SRAM,
> running save_secure_ram_context() in SRAM is not needed. It only gets
> called on PM init. And it seems there's no need to ever call this from
> SRAM idle code.
>
> So let's just keep save_secure_ram_context() in DDR, and pass it the
> physical address of the parameters. We can do everything else in
> omap-secure.c like we already do for other secure code.
>
> And since we don't have any documentation, I still have no clue what
> the values for 0, 1 and 1 for the parameters might be. If somebody has
> figured it out, please do send a patch to add some comments.
>
> Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++
> arch/arm/mach-omap2/omap-secure.h | 4 ++++
> arch/arm/mach-omap2/pm.h | 4 ----
> arch/arm/mach-omap2/pm34xx.c | 13 ++++---------
> arch/arm/mach-omap2/sleep34xx.S | 26 ++++----------------------
> 5 files changed, 31 insertions(+), 35 deletions(-)
I guess you could just use rx51_secure_dispatcher and ditch the
save_secure_ram_context call completely (and most of the other related
code)? That one would handle the cache also in a clean manner.
Something like:
rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4,
__pa(omap3_secure_ram_storage), 0, 1, 1);
Can't test it myself as I don't have omap3 secure HW.
-Tero
>
> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> --- a/arch/arm/mach-omap2/omap-secure.c
> +++ b/arch/arm/mach-omap2/omap-secure.c
> @@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base(void)
> return omap_secure_memblock_base;
> }
>
> +u32 omap3_save_secure_ram(void __iomem *addr, int size)
> +{
> + u32 ret;
> + u32 param[5];
> +
> + if (size != OMAP3_SAVE_SECURE_RAM_SZ)
> + return OMAP3_SAVE_SECURE_RAM_SZ;
> +
> + param[0] = 4; /* Number of arguments */
> + param[1] = __pa(addr); /* Physical address for saving */
> + param[2] = 0;
> + param[3] = 1;
> + param[4] = 1;
> +
> + ret = save_secure_ram_context(__pa(param));
> +
> + return ret;
> +}
> +
> /**
> * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
> * @idx: The PPA API index
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -31,6 +31,8 @@
> /* Maximum Secure memory storage size */
> #define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K)
>
> +#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F
> +
> /* Secure low power HAL API index */
> #define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
> #define OMAP4_HAL_SAVEHW_INDEX 0x1b
> @@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
> extern phys_addr_t omap_secure_ram_mempool_base(void);
> extern int omap_secure_ram_reserve_memblock(void);
> +extern u32 save_secure_ram_context(u32 args_pa);
> +extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
>
> extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
> u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
> /* ... and its pointer from SRAM after copy */
> extern void (*omap3_do_wfi_sram)(void);
>
> -/* save_secure_ram_context function pointer and size, for copy to SRAM */
> -extern int save_secure_ram_context(u32 *addr);
> -extern unsigned int save_secure_ram_context_sz;
> -
> extern void omap3_save_scratchpad_contents(void);
>
> #define PM_RTA_ERRATUM_i608 (1 << 0)
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -48,6 +48,7 @@
> #include "prm3xxx.h"
> #include "pm.h"
> #include "sdrc.h"
> +#include "omap-secure.h"
> #include "sram.h"
> #include "control.h"
> #include "vc.h"
> @@ -66,7 +67,6 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static int (*_omap_save_secure_sram)(u32 *addr);
> void (*omap3_do_wfi_sram)(void);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> @@ -121,8 +121,8 @@ static void omap3_save_secure_ram_context(void)
> * will hang the system.
> */
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> - ret = _omap_save_secure_sram((u32 *)(unsigned long)
> - __pa(omap3_secure_ram_storage));
> + ret = omap3_save_secure_ram(omap3_secure_ram_storage,
> + OMAP3_SAVE_SECURE_RAM_SZ);
> pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> /* Following is for error tracking, it should not happen */
> if (ret) {
> @@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> *
> * The minimum set of functions is pushed to SRAM for execution:
> * - omap3_do_wfi for erratum i581 WA,
> - * - save_secure_ram_context for security extensions.
> */
> void omap_push_sram_idle(void)
> {
> omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
> -
> - if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> - _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
> - save_secure_ram_context_sz);
> }
>
> static void __init pm_errata_configure(void)
> @@ -553,7 +548,7 @@ int __init omap3_pm_init(void)
> clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> omap3_secure_ram_storage =
> - kmalloc(0x803F, GFP_KERNEL);
> + kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL);
> if (!omap3_secure_ram_storage)
> pr_err("Memory allocation failed when allocating for secure sram context\n");
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
> ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
> /*
> - * Function to call rom code to save secure ram context. This gets
> - * relocated to SRAM, so it can be all in .data section. Otherwise
> - * we need to initialize api_params separately.
> + * Function to call rom code to save secure ram context.
> + *
> + * r0 = physical address of the parameters
> */
> - .data
> - .align 3
> ENTRY(save_secure_ram_context)
> stmfd sp!, {r4 - r11, lr} @ save registers on stack
> - adr r3, api_params @ r3 points to parameters
> - str r0, [r3,#0x4] @ r0 has sdram address
> - ldr r12, high_mask
> - and r3, r3, r12
> - ldr r12, sram_phy_addr_mask
> - orr r3, r3, r12
> + mov r3, r0 @ physical address of parameters
> mov r0, #25 @ set service ID for PPA
> mov r12, r0 @ copy secure service ID in r12
> mov r1, #0 @ set task id for ROM code in r1
> @@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context)
> nop
> nop
> ldmfd sp!, {r4 - r11, pc}
> - .align
> -sram_phy_addr_mask:
> - .word SRAM_BASE_P
> -high_mask:
> - .word 0xffff
> -api_params:
> - .word 0x4, 0x0, 0x0, 0x1, 0x1
> ENDPROC(save_secure_ram_context)
> -ENTRY(save_secure_ram_context_sz)
> - .word . - save_secure_ram_context
> -
> - .text
>
> /*
> * ======================
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
WARNING: multiple messages have this Message-ID (diff)
From: Tero Kristo <t-kristo@ti.com>
To: Tony Lindgren <tony@atomide.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
ivo.g.dimitrov.75@gmail.com, khilman@kernel.org,
Vlastimil Babka <vbabka@suse.cz>,
aaro.koskinen@iki.fi, kernel list <linux-kernel@vger.kernel.org>,
sre@kernel.org, abcloriens@gmail.com,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Pavel Machek <pavel@ucw.cz>,
pali.rohar@gmail.com, Russell King <linux@armlinux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
linux-omap@vger.kernel.org, patrikbachan@gmail.com,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
serge@hallyn.com
Subject: Re: n900 in next-20170901
Date: Tue, 14 Nov 2017 21:31:21 +0200 [thread overview]
Message-ID: <5c885f60-bc8c-5f8e-dc81-57eacc57abc8@ti.com> (raw)
In-Reply-To: <20171114173719.GA28152@atomide.com>
On 14/11/17 19:37, Tony Lindgren wrote:
> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171114 06:34]:
>> On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote:
>>> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171110 06:34]:
>>>> On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote:
>>>>> +#define OMAP34XX_SRAM_PHYS 0x40200000
>>>>> +#define OMAP34XX_SRAM_VIRT 0xd0010000
>>>>> +#define OMAP34XX_SRAM_SIZE 0x10000
>>>>
>>>> For my testing environment, vmalloc address space is started at
>>>> roughly 0xe0000000 so 0xd0010000 would not be valid.
>>>
>>> Well we can map it anywhere we want, got any preferences?
>>
>> My testing environment is a beagle-(xm?) for QEMU. It is configured by
>> CONFIG_VMSPLIT_3G=y so kernel address space is started at 0xc0000000.
>> And, it has 512 MB memory so 0xc0000000 ~ 0xdff00000 is used for
>> direct mapping. See below.
>>
>> [ 0.000000] Memory: 429504K/522240K available (11264K kernel code,
>> 1562K rwdata, 4288K rodata, 2048K init, 405K bss, 27200K reserved,
>> 65536K cma-reserved, 0K highmem)
>> [ 0.000000] Virtual kernel memory layout:
>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
>> [ 0.000000] vmalloc : 0xe0000000 - 0xff800000 ( 504 MB)
>> [ 0.000000] lowmem : 0xc0000000 - 0xdff00000 ( 511 MB)
>> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
>> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
>> [ 0.000000] .text : 0xc0208000 - 0xc0e00000 (12256 kB)
>> [ 0.000000] .init : 0xc1300000 - 0xc1500000 (2048 kB)
>> [ 0.000000] .data : 0xc1500000 - 0xc1686810 (1563 kB)
>> [ 0.000000] .bss : 0xc168fc68 - 0xc16f512c ( 406 kB)
>>
>> Therefore, if OMAP34XX_SRAM_VIRT is 0xd0010000, direct mapping is
>> broken and the system doesn't work. I guess that we should use more
>> stable address like as 0xf0000000.
>
> OK. Let's forget about adding static mappings and my earlier
> patches to attempt to fix this. Below is what I now think we should
> merge as a fix before merging Joonsoo's patches. Please all review
> and test, adding Tero to Cc also.
>
> Regards,
>
> Tony
>
> 8< -----------------------
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 13 Nov 2017 13:23:33 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix SRAM virt to phys translation for
> save_secure_ram_context
>
> With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it
> was noticed that n900 stopped booting. After investigating it turned
> out that n900 save_secure_ram_context does some whacky virtual to
> physical address translation for the SRAM data address.
>
> As we now only have minimal parts of omap3 idle code copied to SRAM,
> running save_secure_ram_context() in SRAM is not needed. It only gets
> called on PM init. And it seems there's no need to ever call this from
> SRAM idle code.
>
> So let's just keep save_secure_ram_context() in DDR, and pass it the
> physical address of the parameters. We can do everything else in
> omap-secure.c like we already do for other secure code.
>
> And since we don't have any documentation, I still have no clue what
> the values for 0, 1 and 1 for the parameters might be. If somebody has
> figured it out, please do send a patch to add some comments.
>
> Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++
> arch/arm/mach-omap2/omap-secure.h | 4 ++++
> arch/arm/mach-omap2/pm.h | 4 ----
> arch/arm/mach-omap2/pm34xx.c | 13 ++++---------
> arch/arm/mach-omap2/sleep34xx.S | 26 ++++----------------------
> 5 files changed, 31 insertions(+), 35 deletions(-)
I guess you could just use rx51_secure_dispatcher and ditch the
save_secure_ram_context call completely (and most of the other related
code)? That one would handle the cache also in a clean manner.
Something like:
rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4,
__pa(omap3_secure_ram_storage), 0, 1, 1);
Can't test it myself as I don't have omap3 secure HW.
-Tero
>
> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> --- a/arch/arm/mach-omap2/omap-secure.c
> +++ b/arch/arm/mach-omap2/omap-secure.c
> @@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base(void)
> return omap_secure_memblock_base;
> }
>
> +u32 omap3_save_secure_ram(void __iomem *addr, int size)
> +{
> + u32 ret;
> + u32 param[5];
> +
> + if (size != OMAP3_SAVE_SECURE_RAM_SZ)
> + return OMAP3_SAVE_SECURE_RAM_SZ;
> +
> + param[0] = 4; /* Number of arguments */
> + param[1] = __pa(addr); /* Physical address for saving */
> + param[2] = 0;
> + param[3] = 1;
> + param[4] = 1;
> +
> + ret = save_secure_ram_context(__pa(param));
> +
> + return ret;
> +}
> +
> /**
> * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
> * @idx: The PPA API index
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -31,6 +31,8 @@
> /* Maximum Secure memory storage size */
> #define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K)
>
> +#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F
> +
> /* Secure low power HAL API index */
> #define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
> #define OMAP4_HAL_SAVEHW_INDEX 0x1b
> @@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
> extern phys_addr_t omap_secure_ram_mempool_base(void);
> extern int omap_secure_ram_reserve_memblock(void);
> +extern u32 save_secure_ram_context(u32 args_pa);
> +extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
>
> extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
> u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
> /* ... and its pointer from SRAM after copy */
> extern void (*omap3_do_wfi_sram)(void);
>
> -/* save_secure_ram_context function pointer and size, for copy to SRAM */
> -extern int save_secure_ram_context(u32 *addr);
> -extern unsigned int save_secure_ram_context_sz;
> -
> extern void omap3_save_scratchpad_contents(void);
>
> #define PM_RTA_ERRATUM_i608 (1 << 0)
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -48,6 +48,7 @@
> #include "prm3xxx.h"
> #include "pm.h"
> #include "sdrc.h"
> +#include "omap-secure.h"
> #include "sram.h"
> #include "control.h"
> #include "vc.h"
> @@ -66,7 +67,6 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static int (*_omap_save_secure_sram)(u32 *addr);
> void (*omap3_do_wfi_sram)(void);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> @@ -121,8 +121,8 @@ static void omap3_save_secure_ram_context(void)
> * will hang the system.
> */
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> - ret = _omap_save_secure_sram((u32 *)(unsigned long)
> - __pa(omap3_secure_ram_storage));
> + ret = omap3_save_secure_ram(omap3_secure_ram_storage,
> + OMAP3_SAVE_SECURE_RAM_SZ);
> pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> /* Following is for error tracking, it should not happen */
> if (ret) {
> @@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> *
> * The minimum set of functions is pushed to SRAM for execution:
> * - omap3_do_wfi for erratum i581 WA,
> - * - save_secure_ram_context for security extensions.
> */
> void omap_push_sram_idle(void)
> {
> omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
> -
> - if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> - _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
> - save_secure_ram_context_sz);
> }
>
> static void __init pm_errata_configure(void)
> @@ -553,7 +548,7 @@ int __init omap3_pm_init(void)
> clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> omap3_secure_ram_storage =
> - kmalloc(0x803F, GFP_KERNEL);
> + kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL);
> if (!omap3_secure_ram_storage)
> pr_err("Memory allocation failed when allocating for secure sram context\n");
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
> ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
> /*
> - * Function to call rom code to save secure ram context. This gets
> - * relocated to SRAM, so it can be all in .data section. Otherwise
> - * we need to initialize api_params separately.
> + * Function to call rom code to save secure ram context.
> + *
> + * r0 = physical address of the parameters
> */
> - .data
> - .align 3
> ENTRY(save_secure_ram_context)
> stmfd sp!, {r4 - r11, lr} @ save registers on stack
> - adr r3, api_params @ r3 points to parameters
> - str r0, [r3,#0x4] @ r0 has sdram address
> - ldr r12, high_mask
> - and r3, r3, r12
> - ldr r12, sram_phy_addr_mask
> - orr r3, r3, r12
> + mov r3, r0 @ physical address of parameters
> mov r0, #25 @ set service ID for PPA
> mov r12, r0 @ copy secure service ID in r12
> mov r1, #0 @ set task id for ROM code in r1
> @@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context)
> nop
> nop
> ldmfd sp!, {r4 - r11, pc}
> - .align
> -sram_phy_addr_mask:
> - .word SRAM_BASE_P
> -high_mask:
> - .word 0xffff
> -api_params:
> - .word 0x4, 0x0, 0x0, 0x1, 0x1
> ENDPROC(save_secure_ram_context)
> -ENTRY(save_secure_ram_context_sz)
> - .word . - save_secure_ram_context
> -
> - .text
>
> /*
> * ======================
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
WARNING: multiple messages have this Message-ID (diff)
From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: n900 in next-20170901
Date: Tue, 14 Nov 2017 21:31:21 +0200 [thread overview]
Message-ID: <5c885f60-bc8c-5f8e-dc81-57eacc57abc8@ti.com> (raw)
In-Reply-To: <20171114173719.GA28152@atomide.com>
On 14/11/17 19:37, Tony Lindgren wrote:
> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171114 06:34]:
>> On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote:
>>> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171110 06:34]:
>>>> On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote:
>>>>> +#define OMAP34XX_SRAM_PHYS 0x40200000
>>>>> +#define OMAP34XX_SRAM_VIRT 0xd0010000
>>>>> +#define OMAP34XX_SRAM_SIZE 0x10000
>>>>
>>>> For my testing environment, vmalloc address space is started at
>>>> roughly 0xe0000000 so 0xd0010000 would not be valid.
>>>
>>> Well we can map it anywhere we want, got any preferences?
>>
>> My testing environment is a beagle-(xm?) for QEMU. It is configured by
>> CONFIG_VMSPLIT_3G=y so kernel address space is started at 0xc0000000.
>> And, it has 512 MB memory so 0xc0000000 ~ 0xdff00000 is used for
>> direct mapping. See below.
>>
>> [ 0.000000] Memory: 429504K/522240K available (11264K kernel code,
>> 1562K rwdata, 4288K rodata, 2048K init, 405K bss, 27200K reserved,
>> 65536K cma-reserved, 0K highmem)
>> [ 0.000000] Virtual kernel memory layout:
>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
>> [ 0.000000] vmalloc : 0xe0000000 - 0xff800000 ( 504 MB)
>> [ 0.000000] lowmem : 0xc0000000 - 0xdff00000 ( 511 MB)
>> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
>> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
>> [ 0.000000] .text : 0xc0208000 - 0xc0e00000 (12256 kB)
>> [ 0.000000] .init : 0xc1300000 - 0xc1500000 (2048 kB)
>> [ 0.000000] .data : 0xc1500000 - 0xc1686810 (1563 kB)
>> [ 0.000000] .bss : 0xc168fc68 - 0xc16f512c ( 406 kB)
>>
>> Therefore, if OMAP34XX_SRAM_VIRT is 0xd0010000, direct mapping is
>> broken and the system doesn't work. I guess that we should use more
>> stable address like as 0xf0000000.
>
> OK. Let's forget about adding static mappings and my earlier
> patches to attempt to fix this. Below is what I now think we should
> merge as a fix before merging Joonsoo's patches. Please all review
> and test, adding Tero to Cc also.
>
> Regards,
>
> Tony
>
> 8< -----------------------
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 13 Nov 2017 13:23:33 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix SRAM virt to phys translation for
> save_secure_ram_context
>
> With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it
> was noticed that n900 stopped booting. After investigating it turned
> out that n900 save_secure_ram_context does some whacky virtual to
> physical address translation for the SRAM data address.
>
> As we now only have minimal parts of omap3 idle code copied to SRAM,
> running save_secure_ram_context() in SRAM is not needed. It only gets
> called on PM init. And it seems there's no need to ever call this from
> SRAM idle code.
>
> So let's just keep save_secure_ram_context() in DDR, and pass it the
> physical address of the parameters. We can do everything else in
> omap-secure.c like we already do for other secure code.
>
> And since we don't have any documentation, I still have no clue what
> the values for 0, 1 and 1 for the parameters might be. If somebody has
> figured it out, please do send a patch to add some comments.
>
> Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++
> arch/arm/mach-omap2/omap-secure.h | 4 ++++
> arch/arm/mach-omap2/pm.h | 4 ----
> arch/arm/mach-omap2/pm34xx.c | 13 ++++---------
> arch/arm/mach-omap2/sleep34xx.S | 26 ++++----------------------
> 5 files changed, 31 insertions(+), 35 deletions(-)
I guess you could just use rx51_secure_dispatcher and ditch the
save_secure_ram_context call completely (and most of the other related
code)? That one would handle the cache also in a clean manner.
Something like:
rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4,
__pa(omap3_secure_ram_storage), 0, 1, 1);
Can't test it myself as I don't have omap3 secure HW.
-Tero
>
> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> --- a/arch/arm/mach-omap2/omap-secure.c
> +++ b/arch/arm/mach-omap2/omap-secure.c
> @@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base(void)
> return omap_secure_memblock_base;
> }
>
> +u32 omap3_save_secure_ram(void __iomem *addr, int size)
> +{
> + u32 ret;
> + u32 param[5];
> +
> + if (size != OMAP3_SAVE_SECURE_RAM_SZ)
> + return OMAP3_SAVE_SECURE_RAM_SZ;
> +
> + param[0] = 4; /* Number of arguments */
> + param[1] = __pa(addr); /* Physical address for saving */
> + param[2] = 0;
> + param[3] = 1;
> + param[4] = 1;
> +
> + ret = save_secure_ram_context(__pa(param));
> +
> + return ret;
> +}
> +
> /**
> * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
> * @idx: The PPA API index
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -31,6 +31,8 @@
> /* Maximum Secure memory storage size */
> #define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K)
>
> +#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F
> +
> /* Secure low power HAL API index */
> #define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
> #define OMAP4_HAL_SAVEHW_INDEX 0x1b
> @@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
> extern phys_addr_t omap_secure_ram_mempool_base(void);
> extern int omap_secure_ram_reserve_memblock(void);
> +extern u32 save_secure_ram_context(u32 args_pa);
> +extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
>
> extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
> u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
> /* ... and its pointer from SRAM after copy */
> extern void (*omap3_do_wfi_sram)(void);
>
> -/* save_secure_ram_context function pointer and size, for copy to SRAM */
> -extern int save_secure_ram_context(u32 *addr);
> -extern unsigned int save_secure_ram_context_sz;
> -
> extern void omap3_save_scratchpad_contents(void);
>
> #define PM_RTA_ERRATUM_i608 (1 << 0)
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -48,6 +48,7 @@
> #include "prm3xxx.h"
> #include "pm.h"
> #include "sdrc.h"
> +#include "omap-secure.h"
> #include "sram.h"
> #include "control.h"
> #include "vc.h"
> @@ -66,7 +67,6 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static int (*_omap_save_secure_sram)(u32 *addr);
> void (*omap3_do_wfi_sram)(void);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> @@ -121,8 +121,8 @@ static void omap3_save_secure_ram_context(void)
> * will hang the system.
> */
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> - ret = _omap_save_secure_sram((u32 *)(unsigned long)
> - __pa(omap3_secure_ram_storage));
> + ret = omap3_save_secure_ram(omap3_secure_ram_storage,
> + OMAP3_SAVE_SECURE_RAM_SZ);
> pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> /* Following is for error tracking, it should not happen */
> if (ret) {
> @@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> *
> * The minimum set of functions is pushed to SRAM for execution:
> * - omap3_do_wfi for erratum i581 WA,
> - * - save_secure_ram_context for security extensions.
> */
> void omap_push_sram_idle(void)
> {
> omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
> -
> - if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> - _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
> - save_secure_ram_context_sz);
> }
>
> static void __init pm_errata_configure(void)
> @@ -553,7 +548,7 @@ int __init omap3_pm_init(void)
> clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> omap3_secure_ram_storage =
> - kmalloc(0x803F, GFP_KERNEL);
> + kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL);
> if (!omap3_secure_ram_storage)
> pr_err("Memory allocation failed when allocating for secure sram context\n");
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
> ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
> /*
> - * Function to call rom code to save secure ram context. This gets
> - * relocated to SRAM, so it can be all in .data section. Otherwise
> - * we need to initialize api_params separately.
> + * Function to call rom code to save secure ram context.
> + *
> + * r0 = physical address of the parameters
> */
> - .data
> - .align 3
> ENTRY(save_secure_ram_context)
> stmfd sp!, {r4 - r11, lr} @ save registers on stack
> - adr r3, api_params @ r3 points to parameters
> - str r0, [r3,#0x4] @ r0 has sdram address
> - ldr r12, high_mask
> - and r3, r3, r12
> - ldr r12, sram_phy_addr_mask
> - orr r3, r3, r12
> + mov r3, r0 @ physical address of parameters
> mov r0, #25 @ set service ID for PPA
> mov r12, r0 @ copy secure service ID in r12
> mov r1, #0 @ set task id for ROM code in r1
> @@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context)
> nop
> nop
> ldmfd sp!, {r4 - r11, pc}
> - .align
> -sram_phy_addr_mask:
> - .word SRAM_BASE_P
> -high_mask:
> - .word 0xffff
> -api_params:
> - .word 0x4, 0x0, 0x0, 0x1, 0x1
> ENDPROC(save_secure_ram_context)
> -ENTRY(save_secure_ram_context_sz)
> - .word . - save_secure_ram_context
> -
> - .text
>
> /*
> * ======================
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2017-11-14 19:35 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-03 20:37 n900 in next-20170901 Pavel Machek
2017-09-03 20:37 ` Pavel Machek
2017-09-05 20:13 ` Tony Lindgren
2017-09-05 20:13 ` Tony Lindgren
2017-09-05 20:27 ` Vlastimil Babka
2017-09-05 20:27 ` Vlastimil Babka
2017-09-05 20:32 ` Tony Lindgren
2017-09-05 20:32 ` Tony Lindgren
2017-09-05 23:32 ` Joonsoo Kim
2017-09-05 23:32 ` Joonsoo Kim
2017-09-06 13:30 ` Tony Lindgren
2017-09-06 13:30 ` Tony Lindgren
2017-09-07 7:30 ` Joonsoo Kim
2017-09-07 7:30 ` Joonsoo Kim
2017-09-07 16:16 ` Tony Lindgren
2017-09-07 16:16 ` Tony Lindgren
2017-09-13 7:55 ` Joonsoo Kim
2017-09-13 7:55 ` Joonsoo Kim
2017-09-13 16:31 ` Tony Lindgren
2017-09-13 16:31 ` Tony Lindgren
2017-09-15 6:56 ` Joonsoo Kim
2017-09-15 6:56 ` Joonsoo Kim
2017-09-21 17:28 ` Tony Lindgren
2017-09-21 17:28 ` Tony Lindgren
2017-09-25 8:08 ` Joonsoo Kim
2017-09-25 8:08 ` Joonsoo Kim
2017-09-25 14:54 ` Tony Lindgren
2017-09-25 14:54 ` Tony Lindgren
2017-10-18 8:29 ` Joonsoo Kim
2017-10-18 8:29 ` Joonsoo Kim
2017-10-19 18:30 ` Tony Lindgren
2017-10-19 18:30 ` Tony Lindgren
2017-10-20 1:55 ` Joonsoo Kim
2017-10-20 1:55 ` Joonsoo Kim
2017-10-20 17:31 ` Tony Lindgren
2017-10-20 17:31 ` Tony Lindgren
2017-10-23 4:53 ` Joonsoo Kim
2017-10-23 4:53 ` Joonsoo Kim
2017-10-25 17:31 ` Tony Lindgren
2017-10-25 17:31 ` Tony Lindgren
2017-10-26 4:48 ` Joonsoo Kim
2017-10-26 4:48 ` Joonsoo Kim
2017-10-26 14:16 ` Tony Lindgren
2017-10-26 14:16 ` Tony Lindgren
2017-11-07 5:33 ` Joonsoo Kim
2017-11-07 5:33 ` Joonsoo Kim
2017-11-07 15:48 ` Tony Lindgren
2017-11-07 15:48 ` Tony Lindgren
2017-11-08 7:46 ` Joonsoo Kim
2017-11-08 7:46 ` Joonsoo Kim
2017-11-08 16:34 ` Tony Lindgren
2017-11-08 16:34 ` Tony Lindgren
2017-11-09 0:08 ` Joonsoo Kim
2017-11-09 0:08 ` Joonsoo Kim
2017-11-09 0:11 ` Tony Lindgren
2017-11-09 0:11 ` Tony Lindgren
2017-11-09 0:36 ` Joonsoo Kim
2017-11-09 0:36 ` Joonsoo Kim
2017-11-09 3:50 ` Joonsoo Kim
2017-11-09 3:50 ` Joonsoo Kim
2017-11-09 15:08 ` Tony Lindgren
2017-11-09 15:08 ` Tony Lindgren
2017-11-10 0:13 ` Joonsoo Kim
2017-11-10 0:13 ` Joonsoo Kim
2017-11-10 3:26 ` Tony Lindgren
2017-11-10 3:26 ` Tony Lindgren
2017-11-10 6:19 ` Tony Lindgren
2017-11-10 6:19 ` Tony Lindgren
2017-11-10 6:23 ` Tony Lindgren
2017-11-10 6:23 ` Tony Lindgren
2017-11-10 6:46 ` Joonsoo Kim
2017-11-10 6:46 ` Joonsoo Kim
2017-11-10 15:37 ` Tony Lindgren
2017-11-10 15:37 ` Tony Lindgren
2017-11-10 6:37 ` Joonsoo Kim
2017-11-10 6:37 ` Joonsoo Kim
2017-11-10 15:36 ` Tony Lindgren
2017-11-10 15:36 ` Tony Lindgren
2017-11-13 21:15 ` Tony Lindgren
2017-11-13 21:15 ` Tony Lindgren
2017-11-14 6:40 ` Joonsoo Kim
2017-11-14 6:40 ` Joonsoo Kim
2017-11-14 6:37 ` Joonsoo Kim
2017-11-14 6:37 ` Joonsoo Kim
2017-11-14 17:37 ` Tony Lindgren
2017-11-14 17:37 ` Tony Lindgren
2017-11-14 19:31 ` Tero Kristo [this message]
2017-11-14 19:31 ` Tero Kristo
2017-11-14 19:31 ` Tero Kristo
2017-11-14 19:44 ` Tony Lindgren
2017-11-14 19:44 ` Tony Lindgren
2017-11-14 20:01 ` Tero Kristo
2017-11-14 20:01 ` Tero Kristo
2017-11-14 20:01 ` Tero Kristo
2017-11-14 20:54 ` Tony Lindgren
2017-11-14 20:54 ` Tony Lindgren
2017-11-15 0:51 ` Joonsoo Kim
2017-11-15 0:51 ` Joonsoo Kim
2017-11-15 2:04 ` Tony Lindgren
2017-11-15 2:04 ` Tony Lindgren
2017-11-15 2:48 ` Joonsoo Kim
2017-11-15 2:48 ` Joonsoo Kim
2017-11-15 2:53 ` Tony Lindgren
2017-11-15 2:53 ` Tony Lindgren
2017-11-15 2:53 ` Tony Lindgren
2017-09-15 13:18 ` Pavel Machek
2017-09-15 13:18 ` Pavel Machek
2017-09-18 2:01 ` Joonsoo Kim
2017-09-18 2:01 ` Joonsoo Kim
2017-09-18 8:11 ` Linux-next broken for 2 weeks was " Pavel Machek
2017-09-18 8:11 ` Pavel Machek
2017-09-18 22:00 ` Stephen Rothwell
2017-09-18 22:00 ` Stephen Rothwell
2017-09-18 22:16 ` Pavel Machek
2017-09-18 22:16 ` Pavel Machek
2017-09-15 13:28 ` Pali Rohár
2017-09-15 13:28 ` Pali Rohár
2017-09-18 2:07 ` Joonsoo Kim
2017-09-18 2:07 ` Joonsoo Kim
2017-09-08 9:31 ` Pavel Machek
2017-09-08 9:31 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c885f60-bc8c-5f8e-dc81-57eacc57abc8@ti.com \
--to=t-kristo@ti.com \
--cc=aaro.koskinen@iki.fi \
--cc=abcloriens@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=pali.rohar@gmail.com \
--cc=patrikbachan@gmail.com \
--cc=pavel@ucw.cz \
--cc=serge@hallyn.com \
--cc=sfr@canb.auug.org.au \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.