From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Orion5x - Restore parts of io.h
Date: Wed, 20 Jun 2012 15:55:08 +0000 [thread overview]
Message-ID: <201206201555.09091.arnd@arndb.de> (raw)
In-Reply-To: <20120620154617.GU4799@lunn.ch>
On Wednesday 20 June 2012, Andrew Lunn wrote:
> >
> > So if you need 1 MB per bus, why do you make the limit 4GB? Also,
> > the __io function does not actually point to the IO window at all,
> > which also appears to be horribly wrong.
> >
> > My guess is that you actually want this to be
> >
> > #define IO_SPACE_LIMIT SZ_2MB
> > #define __io(a) ((void __iomem *)ORION5X_PCI_IO_VIRT_BASE + a)
> >
> > Your patch otherwise would make the kernel build again, but has
> > no chance of doing the right thing.
>
> My patch simply puts back what was removed. Please see:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4d5fc58dbe34b78157c05b319669bb3e064ba8bd#patch20
>
> It was probably broken before. It is probably broken now. It probably
> never did the right thing. However, we don't have any hardware to test
> with and we think it is probably never used in real life.
>
> Is it worth doing more than putting back the original code?
Well, the broken version has significant side-effects, e.g. you cannot
access /dev/port or load a device driver that pokes at the PCI
I/O space without crashing the kernel. I think it's better to put
something in place that has a chance of working than something that
is known to be broken.
That said, we probably should not have done the change that broke
the kernel further than it was broken already: The assumption back
then was that we'd only remove the files that are known to be
incorrect, be we did not consider the side-effects.
Now that we're broken already, we have the choice between either
putting it back to the state it was in before, or trying to fix
it for real. Right now, I'm leaning towards fixing it because
there is still some time before the 3.5 release. If you can try
the version that I suggested above and verify that it fixes the
problem that was introduced in 4d5fc58dbe3, I'd prefer merging
that.
Arnd
prev parent reply other threads:[~2012-06-20 15:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 6:06 [PATCH] ARM: Orion5x - Restore parts of io.h Andrew Lunn
2012-06-20 11:56 ` Sergei Shtylyov
2012-06-20 15:14 ` Arnd Bergmann
2012-06-20 15:46 ` Andrew Lunn
2012-06-20 15:55 ` Arnd Bergmann [this message]
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=201206201555.09091.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.