Re: [RFC][Patch] IBM Real-Time "SMI Free" mode driver -v4

From: Vernon Mauery
Date: Fri Sep 24 2010 - 14:26:16 EST


On 24-Sep-2010 07:40 PM, Arnd Bergmann wrote:
On Friday 24 September 2010 19:09:43 Vernon Mauery wrote:
I looked into this and tested it on some hardware, but it doesn't work.
After more digging and poking, it looks like the reason is that the port
IO address is not within the x86 standard port IO range.

I tried something like this:

addr = ioread32(&rtl_table->cmd_port_address);
plen = rtl_cmd_width/8;
if (rtl_cmd_type == RTL_ADDR_TYPE_MMIO)
rtl_cmd_addr = ioremap(addr, plen);
else
rtl_cmd_addr = ioport_map(addr, plen);
RTL_DEBUG("rtl_cmd_addr = %#llx\n", (u64)rtl_cmd_addr);

It printed out that rtl_cmd_addr was 0, meaning the ioport_map failed.
After more digging, it turns out that on at least one of the machines
this code is targeted for, the port IO address (from the first line
above) is 0x40000. Even if this did get mapped, the IO_COND macro would
target it for MMIO access instead of PIO access. So I don't think I can
use this method (even though it did make my code a lot nicer to read).

Any suggestions?

That seems really strange. I thought the inb/outb instructions could not
actually operate on addresses above 0x10000 at all, since they take a 16
bit address operand (DX register). Passing 0x40000 into inb should have the
same effect as zero AFAICT, which means that your existing code should not
work either.

No, inb/outb have address as as unsigned long, which would explain why 0x40000 works with PIO. When doing inb/outb via the ioread/iowrite macros, the port value is the address (minus the offset) masked off to PIO_MASK, which is 16 bits on x86.

So it looks like this really not going to work and I will have to go back to how it was before. Would it be tacky to write my own little macro?

For non-x86 architectures, I would recommend defining HAVE_ARCH_PIO_SIZE
and setting PIO_RESERVED to a higher value.

Unfortunately, this is targeted only for x86 platforms.

--Vernon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/