| Message ID | 1396022885-6102-2-git-send-email-grant.likely@linaro.org |
|---|---|
| State | Accepted |
| Commit | 676e1b2fcd9dbb47a59baac13d089621d22c68b8 |
| Headers | show |
On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote: > ePAPR 1.1 defines the "stdout-path" property for specifying the console > device, but Linux currently only handles the older "linux,stdout-path" > property. This patch adds parsing for the new property name. Generally a good idea I think, but of course I need time to review and test ... :-) One thing that's been annoying me lately with the existing code which you don't address is ... in a few cases my consoles are usable *VERY* early. For example PAPR hvc and OPAL hvc can be used before we even turn the MMU on on powerpc (and thus before we unflatten the device-tree). It would be nice to be able to have the console going that early, unfortunately that would imply using the flat device-tree for the parsing / matching of the stdout-path in those drivers. Right now, I have this explicit config option to hard wire "early debug" but there are a few cases of field bugs that can happen in early init code which I'd like to see logged properly on those systems, and early debug isn't suitable for field use... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 28, 2014 at 4:33 PM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote: >> ePAPR 1.1 defines the "stdout-path" property for specifying the console >> device, but Linux currently only handles the older "linux,stdout-path" >> property. This patch adds parsing for the new property name. > > Generally a good idea I think, but of course I need time to review and > test ... :-) > > One thing that's been annoying me lately with the existing code which > you don't address is ... in a few cases my consoles are usable *VERY* > early. For example PAPR hvc and OPAL hvc can be used before we even turn > the MMU on on powerpc (and thus before we unflatten the device-tree). > > It would be nice to be able to have the console going that early, > unfortunately that would imply using the flat device-tree for the > parsing / matching of the stdout-path in those drivers. I'm working on getting just that working. See my series for "generic earlycon". I'm working on cleaning up the FDT part still, but have something functional. The "hardest" part with FDT is doing the address translation for serial devices, but I just stole that from u-boot. > Right now, I have this explicit config option to hard wire "early debug" > but there are a few cases of field bugs that can happen in early init > code which I'd like to see logged properly on those systems, and early > debug isn't suitable for field use... We have the same issue with multi-platform ARM kernels. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Sat, 29 Mar 2014 08:33:16 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote: > > ePAPR 1.1 defines the "stdout-path" property for specifying the console > > device, but Linux currently only handles the older "linux,stdout-path" > > property. This patch adds parsing for the new property name. > > Generally a good idea I think, but of course I need time to review and > test ... :-) > > One thing that's been annoying me lately with the existing code which > you don't address is ... in a few cases my consoles are usable *VERY* > early. For example PAPR hvc and OPAL hvc can be used before we even turn > the MMU on on powerpc (and thus before we unflatten the device-tree). > > It would be nice to be able to have the console going that early, > unfortunately that would imply using the flat device-tree for the > parsing / matching of the stdout-path in those drivers. I think we can get that done. Rob's series goes a long way to that, and I don't think the flattree parsing will be all that complex. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 28 Mar 2014 16:56:28 -0500, Rob Herring <robherring2@gmail.com> wrote: > On Fri, Mar 28, 2014 at 4:33 PM, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote: > >> ePAPR 1.1 defines the "stdout-path" property for specifying the console > >> device, but Linux currently only handles the older "linux,stdout-path" > >> property. This patch adds parsing for the new property name. > > > > Generally a good idea I think, but of course I need time to review and > > test ... :-) > > > > One thing that's been annoying me lately with the existing code which > > you don't address is ... in a few cases my consoles are usable *VERY* > > early. For example PAPR hvc and OPAL hvc can be used before we even turn > > the MMU on on powerpc (and thus before we unflatten the device-tree). > > > > It would be nice to be able to have the console going that early, > > unfortunately that would imply using the flat device-tree for the > > parsing / matching of the stdout-path in those drivers. > > I'm working on getting just that working. See my series for "generic > earlycon". I'm working on cleaning up the FDT part still, but have > something functional. The "hardest" part with FDT is doing the address > translation for serial devices, but I just stole that from u-boot. :-) There have been several use-cases wanting to property parse reg properties from the flat tree recently. It would be good to get that as a generic helper. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-03-28 at 16:56 -0500, Rob Herring wrote: > I'm working on getting just that working. See my series for "generic > earlycon". I'm working on cleaning up the FDT part still, but have > something functional. The "hardest" part with FDT is doing the address > translation for serial devices, but I just stole that from u-boot. > > > Right now, I have this explicit config option to hard wire "early debug" > > but there are a few cases of field bugs that can happen in early init > > code which I'd like to see logged properly on those systems, and early > > debug isn't suitable for field use... > > We have the same issue with multi-platform ARM kernels. Ah excellent, I'll keep an eye on it ! Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/of/base.c b/drivers/of/base.c index 418a4ff9d97c..be2861d69b02 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1955,9 +1955,9 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align)) of_chosen = of_find_node_by_path("/chosen@0"); if (of_chosen) { - const char *name; - - name = of_get_property(of_chosen, "linux,stdout-path", NULL); + const char *name = of_get_property(of_chosen, "stdout-path", NULL); + if (!name) + name = of_get_property(of_chosen, "linux,stdout-path", NULL); if (name) of_stdout = of_find_node_by_path(name); }
ePAPR 1.1 defines the "stdout-path" property for specifying the console device, but Linux currently only handles the older "linux,stdout-path" property. This patch adds parsing for the new property name. Signed-off-by: Grant Likely <grant.likely@linaro.org> --- drivers/of/base.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)