[PATCH] Use resource_size_t for serial port IO addresses

Russell King rmk at arm.linux.org.uk
Sun Jul 15 21:06:06 EST 2007


On Fri, Jul 13, 2007 at 12:02:26PM -0700, Andrew Morton wrote:
> On Fri, 13 Jul 2007 09:02:16 -0500
> Josh Boyer <jwboyer at linux.vnet.ibm.com> wrote:
> 
> > This is a resend of a patch David sent out on May 7.  Without it, the
> > PowerPC 44x port in 2.6.22 and on is broken.  I've rebased it off of
> > Linus' current tree.  Please consider pushing this soon.
> > 
> > josh
> > 
> > 
> > At present, various parts of the serial code use unsigned long to
> > define resource addresses.  This is a problem, because some 32-bit
> > platforms have physical addresses larger than 32-bits, and have mmio
> > serial uarts located above the 4GB point.
> > 
> > This patch changes the type of mapbase in both struct uart_port and
> > struct plat_serial8250_port to resource_size_t, which can be
> > configured to be 64 bits on such platforms.  The mapbase in
> > serial_struct can't safely be changed, because that structure is user
> > visible.
> 
> This is something we should do, but I have recollections of Russell
> identifying problems with this patch, or at least an earlier version of it?

Basically, there's two patches.  This one (let's call this patch A)
and another to prevent users being surprised (let's call that patch B).

I didn't have any real objections to patch A, provided something like
patch B was merged.  I did have objections against patch B, and I was
intermittently working on a revised solution.

However, for whatever reason [*], during the last merge window patch B
got merged and patch A got dropped, and as a result I've now given up
with my revised solution, and TBH, I no longer care.


* - probably a result of the patches having been worked on several
months prior to the merge window, then me forgetting the discussions
that were had, and then objecting to the wrong patch with wrong
reasoning.  I really hate this "work on patches, wait months, forget
all about them, then try to work out what the hell happened" approach.
It causes mistakes like this.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:



More information about the Linuxppc-dev mailing list