Hi, On Mon, May 6, 2019 at 2:40 PM Brian Norris <briannorris@xxxxxxxxxxxx> wrote: > > On Fri, May 3, 2019 at 10:48 AM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote: > > When you try to run an upstream kernel on an old ARM-based Chromebook > > you'll find that console-ramoops doesn't work. > > Ooh, nice! I still get annoyed by old depthcharge firmware. It's > almost as if we should have gotten an upstream binding approved before > baking it into firmware... > > > --- a/fs/pstore/ram.c > > +++ b/fs/pstore/ram.c > > > @@ -703,6 +704,23 @@ static int ramoops_parse_dt(struct platform_device *pdev, > > > > #undef parse_size > > > > + /* > > + * Some old Chromebooks relied on the kernel setting the console_size > > + * and pmsg_size to the record size since that's what the downstream > > + * kernel did. These same Chromebooks had "ramoops" straight under > > + * the root node which isn't according to the upstream bindings. > > The last part of the sentence technically isn't true -- the original > bindings (notably, with no DT maintainer Reviewed-by) didn't specify > where such a node should be found: > > 35da60941e44 pstore/ram: add Device Tree bindings > > so child-of-root used to be a valid location. But anyway, this code is > just part of a heuristic for "old DT" (where later bindings clarified > this), so it still seems valid. I agree that it was unclear in the past, but it is true that being under the root node is not according to the _current_ upstream bindings, right? ;-) > > Let's > > + * make those old Chromebooks work by detecting this and mimicing the > > s/mimicing/mimicking/ Kees: if you want me to spin with this typo fix then please let me know. Otherwise I'll assume it's less work for you to just fix it yourself when applying. -Doug _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
