On Fri, Apr 04, 2014 at 10:12:40PM +0400, Antony Pavlov wrote:
> On Fri, 4 Apr 2014 18:52:46 +0200
> Michel Stam wrote:
>
> > Hello Antony,
> >
> > Sorry to hear that- the patch was not meant to add new functionality,
> > merely preserve the status quo in master.
>
> Quite the contrary!
>
>
Hello Antony,
I was not aware of this. No matter, I've resubmitted the patches,
they're rebased on top of next now.
Michel
On 04/04/2014 08:12 PM, Antony Pavlov wrote:
On Fri, 4 Apr 2014 18:52:46 +0200
Michel Stam wrote:
Hello Antony,
Sorry to hear that- the patch was not meant to add new
On Fri, 4 Apr 2014 18:52:46 +0200
Michel Stam wrote:
> Hello Antony,
>
> Sorry to hear that- the patch was not meant to add new functionality, merely
> preserve the status quo in master.
Quite the contrary!
Your patchseries introduces new functionality, it adds additional io space.
In bareb
Hello Antony,
Sorry to hear that- the patch was not meant to add new functionality, merely
preserve the status quo in master.
To explain; add_ns16550_device() assumes that all ns16550 chips are mapped into
memory. This is not so on the x86 platform. Previously, because no io-mapped
resources
On Fri, 4 Apr 2014 15:41:39 +0200
mic...@reverze.net wrote:
> From: Michel Stam
>
> The current implementation fakes a memory-mapped I/O device
> at 0x3f8 and 0x2f8, then uses platform read/write functions
> to do the actual reading and writing. These platform functions
> only exist for the x86
From: Michel Stam
The current implementation fakes a memory-mapped I/O device
at 0x3f8 and 0x2f8, then uses platform read/write functions
to do the actual reading and writing. These platform functions
only exist for the x86 platform; better to move the I/O
routines into the driver and have the dr
