linux-mips
[Top] [All Lists]

Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interfac

To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface.
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 21 Nov 2008 18:07:21 +0000
Cc: David Daney <ddaney@caviumnetworks.com>, linux-ide@vger.kernel.org, linux-mips <linux-mips@linux-mips.org>
In-reply-to: <4926EF55.7080004@ru.mvista.com>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <49261BE5.2010406@caviumnetworks.com> <20081121102137.634616c5@lxorguk.ukuu.org.uk> <4926EA6A.7040704@caviumnetworks.com> <4926EF55.7080004@ru.mvista.com>
Sender: linux-mips-bounce@linux-mips.org
> >> If you get a request for an odd length you should write an extra word
> >> containing the last byte and one other. See how the standard methods
> >> handle this.
> 
> > OK.
> 
>     I don't think you need to bother doing that with CF.

Look at it the other way around is the best thing to do given an odd
sized I/O (eg if a CF format ATAPI drive comes along) to crash the
machine.

> > Perhaps it would be better to fix the problem at the source.
> 
>     I don't think there's a problem there. The string versions of the 
> functions treat memory as a string of bytes.

Double checking the docs you are right. How dumb, but dumb or not that is
what it is specified to do.

> > Probably nothing.  I will try to sort it out.
> 
>     It's the need for the tasklet that seems doubtful to me...

I was wondering but assumed it was some kind of hardware feature where
the end of IRQ occurs too early to do some of the cleanup.

<Prev in Thread] Current Thread [Next in Thread>