Hi Doug, On 5/7/19 3:19 PM, Doug Anderson wrote: > Hi, > > On Tue, May 7, 2019 at 3:17 PM Frank Rowand <frowand.list@xxxxxxxxx> wrote: >> >> On 5/6/19 4:58 PM, Doug Anderson wrote: >>> Hi, >>> >>> On Mon, May 6, 2019 at 2:10 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>>> >>>> From: Douglas Anderson <dianders@xxxxxxxxxxxx> >>>> Date: Fri, May 3, 2019 at 10:48 AM >>>> To: Kees Cook, Anton Vorontsov >>>> Cc: <linux-rockchip@xxxxxxxxxxxxxxxxxxx>, <jwerner@xxxxxxxxxxxx>, >>>> <groeck@xxxxxxxxxxxx>, <mka@xxxxxxxxxxxx>, <briannorris@xxxxxxxxxxxx>, >>>> Douglas Anderson, Colin Cross, Tony Luck, >>>> <linux-kernel@xxxxxxxxxxxxxxx> >>>> >>>>> When you try to run an upstream kernel on an old ARM-based Chromebook >>>>> you'll find that console-ramoops doesn't work. >>>>> >>>>> Old ARM-based Chromebooks, before <https://crrev.com/c/439792> >>>>> ("ramoops: support upstream {console,pmsg,ftrace}-size properties") >>>>> used to create a "ramoops" node at the top level that looked like: >>>>> >>>>> / { >>>>> ramoops { >>>>> compatible = "ramoops"; >>>>> reg = <...>; >>>>> record-size = <...>; >>>>> dump-oops; >>>>> }; >>>>> }; >>>>> >>>>> ...and these Chromebooks assumed that the downstream kernel would make >>>>> console_size / pmsg_size match the record size. The above ramoops >>>>> node was added by the firmware so it's not easy to make any changes. >>>>> >>>>> Let's match the expected behavior, but only for those using the old >>>>> backward-compatible way of working where ramoops is right under the >>>>> root node. >>>>> >>>>> NOTE: if there are some out-of-tree devices that had ramoops at the >>>>> top level, left everything but the record size as 0, and somehow >>>>> doesn't want this behavior, we can try to add more conditions here. >>>>> >>>>> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> >>>> >>>> I like this; thanks! Rob is this okay by you? I just want to >>>> double-check since it's part of the DT parsing logic. >>>> >>>> I'll pick it up and add a Cc: stable. >>> >>> Hold off a second--I may need to send out a v2 but out of time for the >>> day. I think I need a #include file to fix errors on x86: >>> >>>> implicit declaration of function 'of_node_is_root' [-Werror,-Wimplicit-function-declaration >> >> Instead of checking "of_node_is_root(parent_node)" the patch could check >> for parent_node not "/reserved-memory". Then the x86 error would not >> occur. >> >> The check I am suggesting is not as precise, but it should be good enough >> for this case, correct? > > Sure, there are a million different ways to slice it. If you prefer > that instead of adding a dummy of_node_is_root() I'm happy to do that. Yes, I would prefer to avoid adding a dummy of_node_is_root() if the alternative is reasonable (and if I understand, you are saying the alternative is reasonable). Thanks, Frank _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
