linux-kernel - Re: [PATCH] Generic platform device IDE driver

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: <20061013122824.GA26705@linux-sh.org>
Date:	Fri, 13 Oct 2006 21:28:24 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Matthias Fuchs <matthias.fuchs@...-electronics.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [PATCH] Generic platform device IDE driver

On Fri, Oct 13, 2006 at 08:52:19AM +0100, Russell King wrote:
> On Thu, Oct 12, 2006 at 03:13:48PM +0900, Paul Mundt wrote:
> > Yes, that's one thing I was thinking of as well.. Here's a patch that
> > makes an attempt at that, can you give it a try and see if it works for
> > you? This applies on top of the earlier patch. None of the ARM, SH, or
> > H8300 cases need to do the remapping at least.
> 
> It's likely that ARM will switch over to using the MMIO resources if
> this patch makes it in.  There's certain ARM platforms which would
> benefit from this change (since inb() and friends are more complex
> than they necessarily need to be.)
> 
> However, one issue needs to be solved before we could do that - how do
> we handle the case where the IDE registers are on a 4 byte spacing
> interval instead of the usual 1 byte?
> 
We could solve this in the driver, but it sounds like this is something
that libata should have some visibility of directly.

> I notice that this driver is calling ata_std_ports() which handles
> the standard setup.  Maybe that needs to become a little more inteligent?
> 
If we go this route, I suppose the easiest option will be simply to have
a private structure with a few function pointers for these sorts of
things, or we can simply have an element for the spacing interval if you
don't forsee needing to change the ioaddrs in any fashion beyond the
register spacing.. Which approach would you be more comfortable with?
Are there any other items that you're concerned with in the current
driver?

Thanks for the feedback!
-
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/