Re: [PATCH v1 4/6] x86/boot: Assume MMIO if serial base address supplied via earlyprintk

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, 2018-01-16 at 16:55 +0100, Ingo Molnar wrote:
> * Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > On Tue, 2018-01-16 at 04:13 +0100, Ingo Molnar wrote:
> > > * Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > 
> > > > If user supplied serial base address via kernel command line and
> > > > value
> > > > is higher than IO space limit (64k boundary), assume for now
> > > > that
> > > > MMIO
> > > > byte access is required.
> > > > 
> > > > Later we might expand or modify this if needed.
> > > 
> > > Is this a standard pattern for serial code configuration values?
> > 
> > I didn't get what you meant under "standard" here.
> > 
> > IO space limit comes from generic io.h header and AFAIU is a
> > hardware
> > limitation (outN (%dx), ...; inX (%dx); dx is 16 bit register).
> > 
> > Using mmio8 out of the IO space is dictated by the (modern) x86
> > platforms with non-standard (okay, high speed) UART location in
> > address
> > space.
> 
> So I was wondering whether we should just make mmio configuration an
> explicit 
> parameter instead of a 'range hack'.

I _think_ it can be done later without breaking any existed
configurations.

> Since we are introducing something entirely new the choice is ours.
> 
> Doing it that way would technically be cleaner, as, at least
> theoretically,
> there could be platforms with mmio addresses below 64k physical,
> right?

Correct, though we are talking about x86 world where I have no example
like this. Either we have LPC ports (I/O 0x3f8 and alike) or HS UARTS on
higher MMIO addresses. Note, that PCI code guarantees that range bump as
well when resources would be allocated for unassigned, by firmware, PCI
UART controllers.

> It's also more self-documenting if the new configuration/parameter
> says 'mmio' 
> explicitly.

I would look at it, though it might make things much more complicated to
implement. And yes, it wouldn't reduce fragility of the parser anyway.

Perhaps we can unify earlycon parser with earlyprintk one (not sure if
it's possible since this nice trick with sharing same code between
compressed and boot code).

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy