Re: [GIT PULL] fbdev fixes for 3.19

[Rob Herring]

On Thu, Dec 11, 2014 at 4:58 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> On Thursday, December 11, 2014 12:55:28 PM Linus Torvalds wrote:
>> On Thu, Dec 11, 2014 at 5:41 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> >
>> > Please pull fbdev changes for 3.19.
>>
>> Ugh. I've pulled it, but I'm not a huge fan of commit 6d09dc6b74ca
>> ("of.h: Keep extern declaration of of_* variables when !CONFIG_OF").
>>
>> I guess it works, but it ends up delaying any failures from compile
>> time to link time, and the linker error messages likely won't be
>> great.
>>
>> So I'm cc'ing the OF people and Rafael (who worked on OF/ACPI
>> unification) to see if they have comments, preferences, or other ways
>> to solve this.
>>
>> Quite frankly, to me it smells like non-OF builds should just have an
>> empty "for_each_child_of_node ()" define instead of playing games with
>> externs that then end up not existing, and depending on the compiler
>> DTRT.
>>
>> Comments?
>
> "for_each_child_of_node ()" is not a problem here AFAICS, because in the
> example from the commit changelog the compiler would complain on the
> of_chosen instance in the "if ()" statement already anyway if I'm not mistaken.

Really, the "if" should be completely removed here.
for_each_child_of_node should do the right thing for !OF or if
of_chosen is NULL already. Since for_each_child_of_node relies on it's
helper function to get optimized away we need of_chosen defined to
something.

I believe Linus' suggestion was we could have an empty
for_each_child_of_node() define, but we've moved away from that to
simplify the of.h header and avoid multiple definitions. Doing that
has it's own issues. Fixing up !OF problems has been somewhat painful
as we've converted ARM and people failed to test that.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/