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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100924182327.GC10777@lucy>
Date:	Fri, 24 Sep 2010 11:23:27 -0700
From:	Vernon Mauery <vernux@...ibm.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Keith Mannthey <kmannth@...ibm.com>
Subject: Re: [RFC][Patch] IBM Real-Time "SMI Free" mode driver -v4

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/