From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 4/4] dt-uart: support /chosen/stdout-path property. Date: Mon, 12 Jan 2015 15:24:51 +0000 Message-ID: <54B3E743.3030605@linaro.org> References: <1420718009.19787.44.camel@citrix.com> <1420718036-29651-4-git-send-email-ian.campbell@citrix.com> <54AE82EA.1090703@linaro.org> <1420723344.19787.76.camel@citrix.com> <54AE867D.5030903@linaro.org> <1421076157.26317.97.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1421076157.26317.97.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Hi Ian, On 12/01/15 15:22, Ian Campbell wrote: > On Thu, 2015-01-08 at 13:30 +0000, Julien Grall wrote: >> On 08/01/15 13:22, Ian Campbell wrote: >>> On Thu, 2015-01-08 at 13:15 +0000, Julien Grall wrote: >>>> Hi Ian, >>>> >>>> On 08/01/15 11:53, Ian Campbell wrote: >>>>> + ret = dt_property_read_string(chosen, "stdout-path", &stdout); >>>>> + if ( ret >= 0 ) >>>>> + { >>>>> + printk("Taking dtuart configuration from /chosen/stdout-path\n"); >>>>> + if ( strlcpy(opt_dtuart, stdout, sizeof(opt_dtuart)) >>>>> + >= sizeof(opt_dtuart) ) >>>>> + printk("WARNING: /chosen/stdout-path too long, truncated\n"); >>>> >>>> I would add XENLOG_WARNING here and ... >>>> >>>>> + } >>>>> + else if ( ret != -EINVAL /* Not present */ ) >>>>> + printk("Failed to read /chosen/stdout-path (%d)\n", ret); >>>> >>>> XENLOG_ERROR here. >>> >>> In practice these only go via the earlyprintk mechanism, since the >>> console can't be setup yet. I'm not sure it's worthwhile tagging such >>> messages. >> >> earlyprintk is transparent for the console code. Tagging may help if we >> decide to implement other kind of console later (VGA, PCI UART...). >> >> Anyway, I doesn't change much things here as the message is tagged as >> WARNING by default. So it will be always printing. > > It turns out that none of the existing prints in this function use the > tags, and I think its of marginal use in this context so I don't think > it is necessary to go changing them all, or to only use the tags for > these two messages. Ok. I'm fine with it. Regards, -- Julien Grall