Messages in this thread | | | Subject | Re: [PATCH v1 4/6] x86/boot: Assume MMIO if serial base address supplied via earlyprintk | From | Andy Shevchenko <> | Date | Thu, 03 May 2018 13:45:58 +0300 |
| |
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
| |