Re: [PATCH 2/2] of/fdt: add kernel command line option for dtb_compat string

[Dirk Brandewie <dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 11/16/2010 04:12 PM, Grant Likely wrote:
> On Tue, Nov 16, 2010 at 6:50 AM, Dirk Brandewie
> <dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>> On 11/15/2010 10:32 PM, Grant Likely wrote:
>>>
>>> On Mon, Nov 15, 2010 at 08:01:21PM -0800, dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>>>> +{
>>>> +       void *rc = NULL;
>>>> +       unsigned long root, size;
>>>> +       struct boot_param_header  *orig_initial_boot_params;
>>>> +       uint8_t *blob;
>>>
>>> blob should be a void* here.  It is never used as a uint8.
>>>
>>
>> I used uint8_t prevent compiler warning when blob is compared to __dtb_end
>>
>
> okay
>
>>>> +{
>>>> +       strncpy(dtb_compat_name, line, MAX_DTB_COMPAT_STR);
>>>> +       return 1;
>>>> +}
>>>
>>> I don't remember getting a response about whether or not
>>> of_find_compatible_dtb can be called directly from dtb_compat_setup.
>>> Doing so would eliminate the arbitrary MAX_DTB_COMPAT_STR because
>>> there would be no need to keep around a copy of dtb_compat_name.  It
>>> also means that of_find_compatible_dtb() can be restricted to the file
>>> scope.
>>>
>>> Is there a use-case for calling of_find_compatible_dtb() anywhere
>>> other than in dtb_compat_setup?
>>>
>>
>> The use case for having these functions exposed is allowing the platfrom
>> code decide the policy for which dtb will be used in the case where a dtb
>> might have been passed in by the boot loader. These functions can be used as
>> a fallback if a dtb was not passed in or to override of the passed in dtb by
>> the platform code.
>
> Still this all looks very generic, even across architectures.  I say
> don't export the functions for now, and change it later if a use case
> shows up that requires it.  I'd really rather not let platform code
> muck about with it directly if there isn't a use case for it.

I have the use case for it in my platform.  There will two ways that the kernel 
can get the DTB.
1. The blob is linked in and I go find the one for my platform. This is the path 
that uses the two new functions.

2. The a pointer blob passed in (physical address) from the bootloader. The blob 
is relocated/copied to keep the bootloader from having to know the kernel memory 
layout.

One method will be able to override the other.  I am not sure what the 
precedence between the methods will be ATM.

>
> However, thinking about it further.  You also need to make sure this
> code is excluded for the powerpc and microblaze architectures because
> the kernel command line is passed via the device tree blob in those
> cases.  By that time it gets called, it is too late to switch the
> device tree pointer.
>
if a "wrapped" kernel is booted doesn't it know exactly which dtb it should be 
using?  These platforms would never go looking for the command line value even 
it it was passed in.

> g.