On Sat, Mar 28, 2015 at 12:01 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > Hi Grant, > > On 03/27/2015 09:36 PM, Grant Likely wrote: >> On Sun, 01 Mar 2015 17:23:11 -0500 >> , Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> >> wrote: [...] >> Something like the following would do it and would be future-proof. We >> can add support for 16 or 64bit big or little endian access if it ever >> became necessary. > > I was planning on adding MEM32BE support to OF earlycon on top of my > patch series 'OF earlycon cleanup', which adds full support for the > of_serial driver DT properties (among other things). > > Unfortunately, that series is waiting on two things: > 1. libfdt upstream patch, which I submitted but was referred back to me > to add test cases. That was 3 weeks ago and I simply haven't had a free > day to burn to figure out how their test matrix is organized. I don't > think that's going to change anytime soon; I might just abandon that patch > and do the string manipulation on the stack. > > ATM, earlycon is still broken if stdout-path options have been set. Given David was okay with the patch itself, I suppose we could go ahead and apply it to the kernel copy. If you're going to require testcases, it should be trivial and/or documented on how to add... > 2. Rob never got back to me on my query [1] to unify the OF_EARLYCON_DECLARE > macro with the EARLYCON_DECLARE macro so that all earlycon consoles > are named. Sorry about that. I had thought about doing the same thing. At least unifying the macros, but not necessarily the tables. If it is also extendable to other firmware interfaces like ACPI perhaps that would be good. Rob > > Regards, > Peter Hurley > > [1] https://lkml.org/lkml/2015/3/6/571 >
