From: Russell King <rmk@arm.linux.org.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH] Use resource_size_t for serial port IO addresses
Date: Sun, 15 Jul 2007 12:06:06 +0100 [thread overview]
Message-ID: <20070715110606.GA32577@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20070713120226.797117e2.akpm@linux-foundation.org>
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@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:
next prev parent reply other threads:[~2007-07-15 11:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-13 14:02 [PATCH] Use resource_size_t for serial port IO addresses Josh Boyer
2007-07-13 19:02 ` Andrew Morton
2007-07-13 19:24 ` Josh Boyer
2007-07-15 11:06 ` Russell King [this message]
2007-07-23 14:08 ` Josh Boyer
2007-07-23 19:34 ` Andrew Morton
2007-07-24 1:57 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070715110606.GA32577@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).