> We could have done it for interrupts too. A "struct irqnum" that has a bit
> that specifies "valid". That would work. But it tends to be painful, so it
> really has to give you something more than "zero is disabled".
>
> It's just not worth it.
>
> And it's why I decreed, that the ONLY SANE
> However, in all honesty, we have triggered bugs in that area too, simply
> because some driver code "knew" that PIO addresses could fit in 16 bits,
> and used u16 or "unsigned short" to remember the PIO address. Both ARM and
> Sparc was bitten by this, although usually the issue is trivial to
> On sparc64, for example, after I pointed this out to DaveM, he was able
> to implement the new iomap interface without the 'if (pio-mem-area)'
> branch present on x86.
Yup, we did that from day 1 on powerpc :-) However, I don't totally
agree with adding some other remapping layer here, I
> Indeed. Zero means "not in use". It really is that simple.
I tried to avoid stepping into that specific flamewar as I don't have
strong opinions either way, but I've been asked to so ... and there are
a few things in your statement that I do like to argue about a bit :-)
> And I'm sorry,
Indeed. Zero means not in use. It really is that simple.
I tried to avoid stepping into that specific flamewar as I don't have
strong opinions either way, but I've been asked to so ... and there are
a few things in your statement that I do like to argue about a bit :-)
And I'm sorry, David,
On sparc64, for example, after I pointed this out to DaveM, he was able
to implement the new iomap interface without the 'if (pio-mem-area)'
branch present on x86.
Yup, we did that from day 1 on powerpc :-) However, I don't totally
agree with adding some other remapping layer here, I think
However, in all honesty, we have triggered bugs in that area too, simply
because some driver code knew that PIO addresses could fit in 16 bits,
and used u16 or unsigned short to remember the PIO address. Both ARM and
Sparc was bitten by this, although usually the issue is trivial to fix
We could have done it for interrupts too. A struct irqnum that has a bit
that specifies valid. That would work. But it tends to be painful, so it
really has to give you something more than zero is disabled.
It's just not worth it.
And it's why I decreed, that the ONLY SANE THING is to
It's not as if people should be pulling 'raw' IRQ numbers out
of a hat or even module parameters these days, except for ISA drivers..
Err.. in the embedded space, this is exceptionally common today,
on the most modern of chips, too. Lots of magic hard(ware)-coded IRQ numbers.
Cheers
-
To
(Yeah, mmap() has taught some people about MAP_FAIL, but that's pretty
unusual too.
It's so unusual, that I regularly find buggy code checking for NULL
instead of MAP_FAILED. Just about every program I look at has it wrong
in at least one place.
Ditto for the result value from wait() -- lots
> Also, many ISA-only drivers actually have hardcoded PIO numbers (eg
> "0x1f0").
Bad example - 0x1F0 is one of those that leaked into the PCI world as
well 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Fri, 26 Jan 2007 13:09:40 +0800
> My question was about _how_ you think this should be achieved in this
> particular case. You didn't like the suggestion that we should put your
> new special-case hack into the resource code... where/how _do_ you
>
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 22:18:21 -0800 (PST)
> So on sparc64, "ioport_resource" really is just a container for the actual
> per-domain resource buckets that the hardware (within that domain) will
> then do the resource allocation from. Afaik.
>
> But you
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 22:18:21 -0800 (PST)
So on sparc64, ioport_resource really is just a container for the actual
per-domain resource buckets that the hardware (within that domain) will
then do the resource allocation from. Afaik.
But you should
From: David Woodhouse [EMAIL PROTECTED]
Date: Fri, 26 Jan 2007 13:09:40 +0800
My question was about _how_ you think this should be achieved in this
particular case. You didn't like the suggestion that we should put your
new special-case hack into the resource code... where/how _do_ you
Also, many ISA-only drivers actually have hardcoded PIO numbers (eg
0x1f0).
Bad example - 0x1F0 is one of those that leaked into the PCI world as
well 8)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
(Yeah, mmap() has taught some people about MAP_FAIL, but that's pretty
unusual too.
It's so unusual, that I regularly find buggy code checking for NULL
instead of MAP_FAILED. Just about every program I look at has it wrong
in at least one place.
Ditto for the result value from wait() -- lots
It's not as if people should be pulling 'raw' IRQ numbers out
of a hat or even module parameters these days, except for ISA drivers..
Err.. in the embedded space, this is exceptionally common today,
on the most modern of chips, too. Lots of magic hard(ware)-coded IRQ numbers.
Cheers
-
To
On Thu, 25 Jan 2007, Linus Torvalds wrote:
>
> Have you noticed that the resource-allocation code _already_ never returns
> zero on sparc64?
Btw, that was a rhetorical question, and I'm not actually sure what the
heck sparc64 will _really_ do ;)
I picked sparc64 as an example, because I
On Fri, 26 Jan 2007, David Woodhouse wrote:
>
> My question was about _how_ you think this should be achieved in this
> particular case.
I already told you.
Have you noticed that the resource-allocation code _already_ never returns
zero on a PC?
Have you noticed that the resource-allocation
On Thu, 2007-01-25 at 20:48 -0800, Linus Torvalds wrote:
> Irq0 may _exist_. IO Port 0 may _exist_. Virtual address 0 may
> _exist_.
>
> Got it?
>
> But they ARE NOT VALID THINGS FOR DRIVERS TO WORRY ABOUT.
I do understand what you're saying; there's no need to shout. I think
it's very
David Woodhouse wrote:
When I eventually get to go home, which will hopefully still be some
time this month, I'll give some more coherent thought to the idea of
just using a (struct irq_desc *) directly instead of an integer. Then
Tejun beat you to it with devres. devres makes all sorts of
On Fri, 26 Jan 2007, David Woodhouse wrote:
>
> Of course it could, but then again why shouldn't we special-case zero in
> _all_ of those use cases, just to make life easier for those poor driver
> authors who presumably can't manage to write userspace code using stdin
> or open() either.
On Thu, 2007-01-25 at 20:00 -0800, Linus Torvalds wrote:
> The resource code really is totally agnostic, and you're barking up the
> wrong tree there. In many ways, the resource code isn't even about "IO
> resources", it could do other things too.
Of course it could, but then again why
On Fri, 26 Jan 2007, David Woodhouse wrote:
>
> It's not just "my laptop", I believe. It's the generic resource code,
> which is happy to assign address zero since it's never been taught that
> zero is now a special case. If we're not going to ask for the bug I
> observed to be fixed -- if
On Thu, 2007-01-25 at 18:58 -0800, Linus Torvalds wrote:
> And it's why I decreed, that the ONLY SANE THING is to just let people do
> the obvious thing:
>
> if (!dev->irq)
> return -ENODEV;
>
> you don't have to know ANYTHING, and that code just works, and just looks
>
On Fri, 26 Jan 2007, David Woodhouse wrote:
>
> The quality of our drivers is low; I'm fully aware that trying to
> improve driver quality is a quixotic task.
This is an important point. I actually hold things like the kernel VM
layer to _much_ higher standards than I would ever hold a driver
On Thu, 2007-01-25 at 17:28 -0800, Linus Torvalds wrote:
>
> On Fri, 26 Jan 2007, David Woodhouse wrote:
> >
> > You're thinking of MMIO, while the case we were discussing was PIO. My
> > laptop is perfectly happy to assign PIO resources from zero.
>
> I was indeed thinking MMIO, but I really
Linus Torvalds wrote:
So *if* you use the new "iomap" interfaces, and the new "pci_iomap()"
things, that should actually not just allow drivers (like the ATA layer)
to share much more code between the PIO and MMIO cases, but it hopefully
actually makes it easier for strange architectures to do
On Thu, 25 Jan 2007, Jeff Garzik wrote:
>
> On sparc64, for example, after I pointed this out to DaveM, he was able to
> implement the new iomap interface without the 'if (pio-mem-area)' branch
> present on x86.
However, in all honesty, we have triggered bugs in that area too, simply
because
Linus Torvalds wrote:
On Fri, 26 Jan 2007, David Woodhouse wrote:
You're thinking of MMIO, while the case we were discussing was PIO. My
laptop is perfectly happy to assign PIO resources from zero.
I was indeed thinking MMIO, but I really think it should extend to PIO
also. It certainly is
On Fri, 26 Jan 2007, David Woodhouse wrote:
>
> You're thinking of MMIO, while the case we were discussing was PIO. My
> laptop is perfectly happy to assign PIO resources from zero.
I was indeed thinking MMIO, but I really think it should extend to PIO
also. It certainly is (again) true on
On Thu, 2007-01-25 at 09:56 -0800, Linus Torvalds wrote:
> Broken architectures that put PCI things at some "PCI physical address
> zero" need to map their PCI addresses to something else. It's part of why
> we have the whole infrastructure for doing things like
>
>
Alan wrote:
Fixes bogus accesses to ports 0-15 with a non DMA capable controller.
This I think should go in for 2.6.20
applied to #upstream-fixes, but it's a hack based on a misunderstanding.
See comments below for further work needed.
Arguably it shouldn't be called for PIO commands at
On Thu, 25 Jan 2007, Alan wrote:
>
> If you want to put your bmdma address at zero then libata-sff won't help
> you at the moment, and assumes zero is a safe "not in use" value because
> the PCI layer also takes a similar view in places.
Indeed. Zero means "not in use". It really is that
> > void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
> > {
> > - ata_bmdma_stop(qc);
> > + if (qc->ap->ioaddr.bmdma_addr)
> > + ata_bmdma_stop(qc);
> > }
>
> But what if the bmdma_addr _is_ zero? Please, let's not allow the "zero
> is not a valid number"
On Thu, 2007-01-25 at 16:22 +, Russell King wrote:
> The zero DMA address is absolutely and totally valid. It might not
> correspond with physical address zero on platforms.
>
> Also, DMA address zero is not the same as NULL.
This isn't actually "DMA address" in that context -- it's the
On Thu, Jan 25, 2007 at 11:17:20AM -0500, Jeff Garzik wrote:
> David Woodhouse wrote:
> >On Thu, 2007-01-25 at 15:09 +, Alan wrote:
> >>diff -u --new-file --recursive --exclude-from /usr/src/exclude
> >>linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
>
On Thu, 2007-01-25 at 11:17 -0500, Jeff Garzik wrote:
> Read the code... This test is already widely in use in libata.
That doesn't make it correct; it just means it's your fault not Alan's,
right? :)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
David Woodhouse wrote:
On Thu, 2007-01-25 at 15:09 +, Alan wrote:
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
On Thu, 2007-01-25 at 15:09 +, Alan wrote:
>
> diff -u --new-file --recursive --exclude-from /usr/src/exclude
> linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
> linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
> --- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 2007-01-22
Fixes bogus accesses to ports 0-15 with a non DMA capable controller.
This I think should go in for 2.6.20
Arguably it shouldn't be called for PIO commands at all but thats a
matter for Jeff to decide
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from
Fixes bogus accesses to ports 0-15 with a non DMA capable controller.
This I think should go in for 2.6.20
Arguably it shouldn't be called for PIO commands at all but thats a
matter for Jeff to decide
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from
On Thu, 2007-01-25 at 15:09 +, Alan wrote:
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 2007-01-22
David Woodhouse wrote:
On Thu, 2007-01-25 at 15:09 +, Alan wrote:
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
On Thu, 2007-01-25 at 11:17 -0500, Jeff Garzik wrote:
Read the code... This test is already widely in use in libata.
That doesn't make it correct; it just means it's your fault not Alan's,
right? :)
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, Jan 25, 2007 at 11:17:20AM -0500, Jeff Garzik wrote:
David Woodhouse wrote:
On Thu, 2007-01-25 at 15:09 +, Alan wrote:
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
On Thu, 2007-01-25 at 16:22 +, Russell King wrote:
The zero DMA address is absolutely and totally valid. It might not
correspond with physical address zero on platforms.
Also, DMA address zero is not the same as NULL.
This isn't actually DMA address in that context -- it's the I/O port
void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
{
- ata_bmdma_stop(qc);
+ if (qc-ap-ioaddr.bmdma_addr)
+ ata_bmdma_stop(qc);
}
But what if the bmdma_addr _is_ zero? Please, let's not allow the zero
is not a valid number braindamage to spread
On Thu, 25 Jan 2007, Alan wrote:
If you want to put your bmdma address at zero then libata-sff won't help
you at the moment, and assumes zero is a safe not in use value because
the PCI layer also takes a similar view in places.
Indeed. Zero means not in use. It really is that simple.
And
On Thu, 2007-01-25 at 09:56 -0800, Linus Torvalds wrote:
Broken architectures that put PCI things at some PCI physical address
zero need to map their PCI addresses to something else. It's part of why
we have the whole infrastructure for doing things like
pcibios_bus_to_resource()
On Fri, 26 Jan 2007, David Woodhouse wrote:
You're thinking of MMIO, while the case we were discussing was PIO. My
laptop is perfectly happy to assign PIO resources from zero.
I was indeed thinking MMIO, but I really think it should extend to PIO
also. It certainly is (again) true on PC's,
Linus Torvalds wrote:
On Fri, 26 Jan 2007, David Woodhouse wrote:
You're thinking of MMIO, while the case we were discussing was PIO. My
laptop is perfectly happy to assign PIO resources from zero.
I was indeed thinking MMIO, but I really think it should extend to PIO
also. It certainly is
On Thu, 25 Jan 2007, Jeff Garzik wrote:
On sparc64, for example, after I pointed this out to DaveM, he was able to
implement the new iomap interface without the 'if (pio-mem-area)' branch
present on x86.
However, in all honesty, we have triggered bugs in that area too, simply
because some
Linus Torvalds wrote:
So *if* you use the new iomap interfaces, and the new pci_iomap()
things, that should actually not just allow drivers (like the ATA layer)
to share much more code between the PIO and MMIO cases, but it hopefully
actually makes it easier for strange architectures to do it
On Thu, 2007-01-25 at 17:28 -0800, Linus Torvalds wrote:
On Fri, 26 Jan 2007, David Woodhouse wrote:
You're thinking of MMIO, while the case we were discussing was PIO. My
laptop is perfectly happy to assign PIO resources from zero.
I was indeed thinking MMIO, but I really think it
On Fri, 26 Jan 2007, David Woodhouse wrote:
The quality of our drivers is low; I'm fully aware that trying to
improve driver quality is a quixotic task.
This is an important point. I actually hold things like the kernel VM
layer to _much_ higher standards than I would ever hold a driver
On Thu, 2007-01-25 at 18:58 -0800, Linus Torvalds wrote:
And it's why I decreed, that the ONLY SANE THING is to just let people do
the obvious thing:
if (!dev-irq)
return -ENODEV;
you don't have to know ANYTHING, and that code just works, and just looks
obvious.
On Fri, 26 Jan 2007, David Woodhouse wrote:
It's not just my laptop, I believe. It's the generic resource code,
which is happy to assign address zero since it's never been taught that
zero is now a special case. If we're not going to ask for the bug I
observed to be fixed -- if we're going
Alan wrote:
Fixes bogus accesses to ports 0-15 with a non DMA capable controller.
This I think should go in for 2.6.20
applied to #upstream-fixes, but it's a hack based on a misunderstanding.
See comments below for further work needed.
Arguably it shouldn't be called for PIO commands at
On Thu, 2007-01-25 at 20:00 -0800, Linus Torvalds wrote:
The resource code really is totally agnostic, and you're barking up the
wrong tree there. In many ways, the resource code isn't even about IO
resources, it could do other things too.
Of course it could, but then again why shouldn't we
On Fri, 26 Jan 2007, David Woodhouse wrote:
Of course it could, but then again why shouldn't we special-case zero in
_all_ of those use cases, just to make life easier for those poor driver
authors who presumably can't manage to write userspace code using stdin
or open() either.
You're not
David Woodhouse wrote:
When I eventually get to go home, which will hopefully still be some
time this month, I'll give some more coherent thought to the idea of
just using a (struct irq_desc *) directly instead of an integer. Then
Tejun beat you to it with devres. devres makes all sorts of
On Thu, 2007-01-25 at 20:48 -0800, Linus Torvalds wrote:
Irq0 may _exist_. IO Port 0 may _exist_. Virtual address 0 may
_exist_.
Got it?
But they ARE NOT VALID THINGS FOR DRIVERS TO WORRY ABOUT.
I do understand what you're saying; there's no need to shout. I think
it's very misguided and
On Fri, 26 Jan 2007, David Woodhouse wrote:
My question was about _how_ you think this should be achieved in this
particular case.
I already told you.
Have you noticed that the resource-allocation code _already_ never returns
zero on a PC?
Have you noticed that the resource-allocation
On Thu, 25 Jan 2007, Linus Torvalds wrote:
Have you noticed that the resource-allocation code _already_ never returns
zero on sparc64?
Btw, that was a rhetorical question, and I'm not actually sure what the
heck sparc64 will _really_ do ;)
I picked sparc64 as an example, because I
66 matches
Mail list logo
