[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181115172535.GA26922@roeck-us.net>
Date: Thu, 15 Nov 2018 09:25:35 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On Thu, Nov 15, 2018 at 09:19:14AM -0800, Florian Fainelli wrote:
>
>
> On 11/14/2018 9:38 PM, Guenter Roeck wrote:
> > On Wed, Nov 14, 2018 at 07:56:47PM -0800, Florian Fainelli wrote:
> >>
> >>
> >> On November 14, 2018 5:11:25 PM PST, Guenter Roeck <linux@...ck-us.net> wrote:
> >>> On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote:
> >>>> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would
> >>>> result in the inability for the kernel to have a valid console
> >>> device,
> >>>> which can be seen with:
> >>>>
> >>>> Warning: unable to open an initial console.
> >>>>
> >>>> and then:
> >>>>
> >>>> Run /init as init process
> >>>> Kernel panic - not syncing: Attempted to kill init!
> >>> exitcode=0x00000100
> >>>>
> >>>> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there
> >>>> really is no drawback to defaulting this config to the value of
> >>>> SERIAL_8250.
> >>>>
> >>>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> >>>> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >>>
> >>> This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now
> >>> defined where it was not previously. Example mpc85xx_defconfig. This in
> >>> turn results in boot failures for those configurations, with an error
> >>> message of
> >>>
> >>> of_serial: probe of e0004500.serial failed with error -22
> >>>
> >>> which wasn't seen before.
> >>
> >> Do you know which Device Tree is being used here? The most obvious thing that could be done is to add a !PPC condition but this might be missing other platforms doing their own 8250 registration yet being OF aware (sparc?).
> >>
> >>>
> >>> Not sure if replacing a potential problem with a real one is really an
> >>> improvement.`
> >>
> >> That comment is not particularly helpful though I have an appreciation for when a change breaks things in unexpected ways and how frustrating that can be.
> >
> > Actally, never mind. I dropped the test cases. Sorry for the noise.
>
> Why? The tests are useful, if I gave you an impression that I was just
> going to walk away from this issue and not look at it, then that is not
> happening. What I was objecting to is your qualification of the issue,
> this is unfortunately not a potential/latent problem, it happens more
> often than not.
>
I ended up adding a flag to my builders which remove the offending
configuration for affected platforms/configurations, so this is no longer
an issue for my build tests.
Guenter
Powered by blists - more mailing lists