randconfig failures - MMC + trusted foundations

randconfig failures - MMC + trusted foundations

[Russell King - ARM Linux]

Last night's omap4430-sdp randconfig build:

In file included from arch/arm/mach-tegra/tegra.c:43:0:
arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)


Last night's versatile randconfig build:

drivers/mmc/core/core.c: In function 'mmc_card_power_up':
drivers/mmc/core/core.c:1517:4: error: implicit declaration of function 'gpiod_set_value'

This one appears to be a regular feature of failure, and is as I'm
carrying Olof's "mmc: add support for power-on sequencing through DT"
patch for CuBox wireless - see the 222 patch set.  It probably points
at something not being right with GPIO stuff.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH] ARM: trusted_foundations: only set setup_max_cpus if SMP set

[Alexandre Courbot]

The setup_max_cpu variable is only defined if CONFIG_SMP is set. Add
a preprocessor condition to avoid the following compilation error if
CONFIG_SMP is not set:

    arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
    arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)

Reported-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Hi Russell,

This should take care of the trusted foundations issue. Thanks for reporting this.

 arch/arm/include/asm/trusted_foundations.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/trusted_foundations.h b/arch/arm/include/asm/trusted_foundations.h
index b5f7705..624e1d4 100644
--- a/arch/arm/include/asm/trusted_foundations.h
+++ b/arch/arm/include/asm/trusted_foundations.h
@@ -54,7 +54,9 @@ static inline void register_trusted_foundations(
 	 */
 	pr_err("No support for Trusted Foundations, continuing in degraded mode.\n");
 	pr_err("Secondary processors as well as CPU PM will be disabled.\n");
+#if IS_ENABLED(CONFIG_SMP)
 	setup_max_cpus = 0;
+#endif
 	cpu_idle_poll_ctrl(true);
 }
 
-- 
1.9.2

[PATCH] ARM: trusted_foundations: only set setup_max_cpus if SMP set

[Alexandre Courbot]

On Sun, Apr 27, 2014 at 7:01 PM, Alexandre Courbot <acourbot@nvidia.com> wrote:
> The setup_max_cpu variable is only defined if CONFIG_SMP is set. Add
> a preprocessor condition to avoid the following compilation error if
> CONFIG_SMP is not set:
>
>     arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
>     arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)
>
> Reported-by: Russell King <rmk@arm.linux.org.uk>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> Hi Russell,
>
> This should take care of the trusted foundations issue. Thanks for reporting this.

Russell,

Do you mind taking this into your tree? Or do you prefer if the Tegra
folks do it?

>
>  arch/arm/include/asm/trusted_foundations.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/trusted_foundations.h b/arch/arm/include/asm/trusted_foundations.h
> index b5f7705..624e1d4 100644
> --- a/arch/arm/include/asm/trusted_foundations.h
> +++ b/arch/arm/include/asm/trusted_foundations.h
> @@ -54,7 +54,9 @@ static inline void register_trusted_foundations(
>          */
>         pr_err("No support for Trusted Foundations, continuing in degraded mode.\n");
>         pr_err("Secondary processors as well as CPU PM will be disabled.\n");
> +#if IS_ENABLED(CONFIG_SMP)
>         setup_max_cpus = 0;
> +#endif
>         cpu_idle_poll_ctrl(true);
>  }
>
> --
> 1.9.2
>

[PATCH] ARM: trusted_foundations: only set setup_max_cpus if SMP set

[Stephen Warren]

On 05/01/2014 01:22 AM, Alexandre Courbot wrote:
> On Sun, Apr 27, 2014 at 7:01 PM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> The setup_max_cpu variable is only defined if CONFIG_SMP is set. Add
>> a preprocessor condition to avoid the following compilation error if
>> CONFIG_SMP is not set:
>>
>>     arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
>>     arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)
>>
>> Reported-by: Russell King <rmk@arm.linux.org.uk>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> Hi Russell,
>>
>> This should take care of the trusted foundations issue. Thanks for reporting this.
> 
> Russell,
> 
> Do you mind taking this into your tree? Or do you prefer if the Tegra
> folks do it?

I /think/ that Russell prefers to pick patches up from his patch tracker:

http://www.arm.linux.org.uk/developer/patches/

and instructions:
http://www.arm.linux.org.uk/developer/patches/info.php

If you add it there and he objects, I expect he'll let you know:-)

[PATCH] ARM: trusted_foundations: only set setup_max_cpus if SMP set

[Alexandre Courbot]

On 05/02/2014 01:50 AM, Stephen Warren wrote:
> On 05/01/2014 01:22 AM, Alexandre Courbot wrote:
>> On Sun, Apr 27, 2014 at 7:01 PM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>>> The setup_max_cpu variable is only defined if CONFIG_SMP is set. Add
>>> a preprocessor condition to avoid the following compilation error if
>>> CONFIG_SMP is not set:
>>>
>>>      arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
>>>      arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)
>>>
>>> Reported-by: Russell King <rmk@arm.linux.org.uk>
>>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>>> ---
>>> Hi Russell,
>>>
>>> This should take care of the trusted foundations issue. Thanks for reporting this.
>>
>> Russell,
>>
>> Do you mind taking this into your tree? Or do you prefer if the Tegra
>> folks do it?
>
> I /think/ that Russell prefers to pick patches up from his patch tracker:
>
> http://www.arm.linux.org.uk/developer/patches/
>
> and instructions:
> http://www.arm.linux.org.uk/developer/patches/info.php
>
> If you add it there and he objects, I expect he'll let you know:-)

Oh, thanks. Submitting this to the right place then.

randconfig failures - MMC + trusted foundations

[Alexandre Courbot]

Hi Russell,

On Sun, Apr 27, 2014 at 6:32 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Last night's omap4430-sdp randconfig build:
>
> In file included from arch/arm/mach-tegra/tegra.c:43:0:
> arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations':
> arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function)

Just sent you a patch to fix this. Thanks for reporting.

> Last night's versatile randconfig build:
>
> drivers/mmc/core/core.c: In function 'mmc_card_power_up':
> drivers/mmc/core/core.c:1517:4: error: implicit declaration of function 'gpiod_set_value'
>
> This one appears to be a regular feature of failure, and is as I'm
> carrying Olof's "mmc: add support for power-on sequencing through DT"
> patch for CuBox wireless - see the 222 patch set.  It probably points
> at something not being right with GPIO stuff.

I had a quick look at the patch and I would say this is happening
because drivers/mmc/core/core.c does not include
<linux/gpio/consumer.h> despite using the gpiod_* functions. The error
will only happen if CONFIG_GPIOLIB is not defined. Olof, if it is not
too late can you fix this in your patch series?

Cheers,
Alex.

randconfig failures - MMC + trusted foundations

[Russell King - ARM Linux]

On Sun, Apr 27, 2014 at 07:09:31PM +0900, Alexandre Courbot wrote:
> Hi Russell,
> 
> On Sun, Apr 27, 2014 at 6:32 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Last night's versatile randconfig build:
> >
> > drivers/mmc/core/core.c: In function 'mmc_card_power_up':
> > drivers/mmc/core/core.c:1517:4: error: implicit declaration of function 'gpiod_set_value'
> >
> > This one appears to be a regular feature of failure, and is as I'm
> > carrying Olof's "mmc: add support for power-on sequencing through DT"
> > patch for CuBox wireless - see the 222 patch set.  It probably points
> > at something not being right with GPIO stuff.
> 
> I had a quick look at the patch and I would say this is happening
> because drivers/mmc/core/core.c does not include
> <linux/gpio/consumer.h> despite using the gpiod_* functions. The error
> will only happen if CONFIG_GPIOLIB is not defined. Olof, if it is not
> too late can you fix this in your patch series?

I received a report from someone else last week (in the mmc patch series
I posted) that Chris has already merged this into his mmc tree, so I
think it would need to be a follow on patch.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

randconfig failures - MMC + trusted foundations

[Olof Johansson]

On Sun, Apr 27, 2014 at 3:33 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Apr 27, 2014 at 07:09:31PM +0900, Alexandre Courbot wrote:
>> Hi Russell,
>>
>> On Sun, Apr 27, 2014 at 6:32 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > Last night's versatile randconfig build:
>> >
>> > drivers/mmc/core/core.c: In function 'mmc_card_power_up':
>> > drivers/mmc/core/core.c:1517:4: error: implicit declaration of function 'gpiod_set_value'
>> >
>> > This one appears to be a regular feature of failure, and is as I'm
>> > carrying Olof's "mmc: add support for power-on sequencing through DT"
>> > patch for CuBox wireless - see the 222 patch set.  It probably points
>> > at something not being right with GPIO stuff.
>>
>> I had a quick look at the patch and I would say this is happening
>> because drivers/mmc/core/core.c does not include
>> <linux/gpio/consumer.h> despite using the gpiod_* functions. The error
>> will only happen if CONFIG_GPIOLIB is not defined. Olof, if it is not
>> too late can you fix this in your patch series?
>
> I received a report from someone else last week (in the mmc patch series
> I posted) that Chris has already merged this into his mmc tree, so I
> think it would need to be a follow on patch.

Huh, I don't see the patches in mmc-next. Did they get applied
somewhere else? They're not in linux-next either.

Timing is good though; I was hoping to revisit that patch set this week.


-Olof

randconfig failures - MMC + trusted foundations

[Russell King - ARM Linux]

On Sun, Apr 27, 2014 at 12:46:06PM -0700, Olof Johansson wrote:
> On Sun, Apr 27, 2014 at 3:33 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I received a report from someone else last week (in the mmc patch series
> > I posted) that Chris has already merged this into his mmc tree, so I
> > think it would need to be a follow on patch.
> 
> Huh, I don't see the patches in mmc-next. Did they get applied
> somewhere else? They're not in linux-next either.
> 
> Timing is good though; I was hoping to revisit that patch set this week.

Ah, it wasn't the main patch, it was the one adding mmc_of_parse to dw_mmc.c:

| I didn't know which version you have checked.
| But I have known that mmc_of_parse() have already included at mmc-next
| repository.
| 
| commit 6ca5c60605dde3420ce7fee6f93ec4a7c7924848
| Author: Jaehoon Chung <jh80.chung@gmail.com>
| Date:   Mon Mar 3 11:36:41 2014 +0900
| 
|     mmc: dw_mmc: use the mmc_of_parse() instead of local parser

as part of the big 70-odd sdhci/cubox-i mmc patch series I posted last
week.

So I'll continue carrying your versions privately for the time being.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.