From: Frank Rowand <[email protected]>
x86_flattree_get_config() is incorrectly protected by
ifdef CONFIG_OF_FLATTREE. It uses of_get_flat_dt_size(), which
only exists if CONFIG_OF_EARLY_FLATTREE. This issue has not
been exposed previously because OF_FLATTREE did not occur unless
it was selected by OF_EARLY_FLATTREE. A devicetree overlay change
is selecting OF_FLATTREE directly instead of indirectly enabling
it by selecting OF_EARLY_FLATTREE.
This problem was exposed by a randconfig generated by the kbuild
test robot, where Platform OLPC was enabled. OLPC selects
OF_PROMTREE instead of OF_EARLY_FLATREE. The only other x86
platform that selects OF is X86_INTEL_CE, which does select
OF_EARLY_FLATTREE.
Signed-off-by: Frank Rowand <[email protected]>
---
The devicetree overlay change is in patch 1/4 of the series:
https://lkml.org/lkml/2018/3/2/979
The pull request for the patch series that triggered the kbuild
test robot is:
https://lkml.org/lkml/2018/3/2/1065
arch/x86/kernel/devicetree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 25de5f6ca997..45416826f6ee 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -259,7 +259,7 @@ static void __init dtb_apic_setup(void)
dtb_ioapic_setup();
}
-#ifdef CONFIG_OF_FLATTREE
+#ifdef CONFIG_OF_EARLY_FLATTREE
static void __init x86_flattree_get_config(void)
{
u32 size, map_len;
--
Frank Rowand <[email protected]>
Hi Frank,
Thank you for the patch.
On Saturday, 3 March 2018 06:12:26 EET [email protected] wrote:
> From: Frank Rowand <[email protected]>
>
> x86_flattree_get_config() is incorrectly protected by
> ifdef CONFIG_OF_FLATTREE. It uses of_get_flat_dt_size(), which
> only exists if CONFIG_OF_EARLY_FLATTREE. This issue has not
> been exposed previously because OF_FLATTREE did not occur unless
> it was selected by OF_EARLY_FLATTREE. A devicetree overlay change
> is selecting OF_FLATTREE directly instead of indirectly enabling
> it by selecting OF_EARLY_FLATTREE.
>
> This problem was exposed by a randconfig generated by the kbuild
> test robot, where Platform OLPC was enabled. OLPC selects
> OF_PROMTREE instead of OF_EARLY_FLATREE. The only other x86
> platform that selects OF is X86_INTEL_CE, which does select
> OF_EARLY_FLATTREE.
>
> Signed-off-by: Frank Rowand <[email protected]>
> ---
>
> The devicetree overlay change is in patch 1/4 of the series:
> https://lkml.org/lkml/2018/3/2/979
>
> The pull request for the patch series that triggered the kbuild
> test robot is:
> https://lkml.org/lkml/2018/3/2/1065
>
> arch/x86/kernel/devicetree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index 25de5f6ca997..45416826f6ee 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -259,7 +259,7 @@ static void __init dtb_apic_setup(void)
> dtb_ioapic_setup();
> }
>
> -#ifdef CONFIG_OF_FLATTREE
> +#ifdef CONFIG_OF_EARLY_FLATTREE
> static void __init x86_flattree_get_config(void)
> {
> u32 size, map_len;
This looks good to me. Could you respin the pull request with this patch
included ? I need to send a pull request for a patch series based on your
overlay changes, and I'd rather avoid breaking the build :-)
--
Regards,
Laurent Pinchart
Hi x86 Maintainers,
On 03/03/18 01:17, Laurent Pinchart wrote:
> Hi Frank,
>
> Thank you for the patch.
>
> On Saturday, 3 March 2018 06:12:26 EET [email protected] wrote:
>> From: Frank Rowand <[email protected]>
>>
>> x86_flattree_get_config() is incorrectly protected by
>> ifdef CONFIG_OF_FLATTREE. It uses of_get_flat_dt_size(), which
>> only exists if CONFIG_OF_EARLY_FLATTREE. This issue has not
>> been exposed previously because OF_FLATTREE did not occur unless
>> it was selected by OF_EARLY_FLATTREE. A devicetree overlay change
>> is selecting OF_FLATTREE directly instead of indirectly enabling
>> it by selecting OF_EARLY_FLATTREE.
>>
>> This problem was exposed by a randconfig generated by the kbuild
>> test robot, where Platform OLPC was enabled. OLPC selects
>> OF_PROMTREE instead of OF_EARLY_FLATREE. The only other x86
>> platform that selects OF is X86_INTEL_CE, which does select
>> OF_EARLY_FLATTREE.
>>
>> Signed-off-by: Frank Rowand <[email protected]>
>> ---
>>
>> The devicetree overlay change is in patch 1/4 of the series:
>> https://lkml.org/lkml/2018/3/2/979
>>
>> The pull request for the patch series that triggered the kbuild
>> test robot is:
>> https://lkml.org/lkml/2018/3/2/1065
>>
>> arch/x86/kernel/devicetree.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
>> index 25de5f6ca997..45416826f6ee 100644
>> --- a/arch/x86/kernel/devicetree.c
>> +++ b/arch/x86/kernel/devicetree.c
>> @@ -259,7 +259,7 @@ static void __init dtb_apic_setup(void)
>> dtb_ioapic_setup();
>> }
>>
>> -#ifdef CONFIG_OF_FLATTREE
>> +#ifdef CONFIG_OF_EARLY_FLATTREE
>> static void __init x86_flattree_get_config(void)
>> {
>> u32 size, map_len;
>
> This looks good to me. Could you respin the pull request with this patch
> included ? I need to send a pull request for a patch series based on your
> overlay changes, and I'd rather avoid breaking the build :-)
>
I sent this patch to the x86 maintainers and to Rob because of a patch
series that is modifying arch/x86/kernel/devicetree.c, in
x86_flattree_get_config() [1]. It does not look like my patch will
conflict with that patch at the moment, but it is possible that a conflict
could develop as that patch is developed.
I will add this patch to my devictree pull request, and ask the x86
maintainers to ack it and watch for possible conflicts as patch [1]
is further developed.
[1] https://lkml.org/lkml/2018/3/1/1005
[PATCH v3 1/3] x86: devicetree: call early_init_dt_verify()
On Sat, 3 Mar 2018, Frank Rowand wrote:
> I sent this patch to the x86 maintainers and to Rob because of a patch
> series that is modifying arch/x86/kernel/devicetree.c, in
> x86_flattree_get_config() [1]. It does not look like my patch will
> conflict with that patch at the moment, but it is possible that a conflict
> could develop as that patch is developed.
Even if it conflicts, its trivial enough ....