linux-kernel - Re: [PATCH 2/5] ide: ->ide_dma_clear_irq() -> ->clear

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 11 Nov 2008 18:01:54 -0800
From:	Jeremy Higdon <jeremy@....com>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] ide: ->ide_dma_clear_irq() -> ->clear_irq()

On Tue, Sep 16, 2008 at 01:16:54PM +0400, Sergei Shtylyov wrote:
> >>>>Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> >>>>        
> >>>Acked-by: Sergei Shtylyov <sshtylyov@...mvista.com>
> >>>      
> >>   Not feeling sure about this patch -- ->waiting_for_dma probably 
> >>should've been left where it was...
> >>    
> >
> >Well, it doesn't change behavior and I think having ->clear_irq method
> >independent from the transfer mode is a preffered approach.
> >  
> 
>   But its implementations will have to depend on it anyway. And 
> clearing the IDE interrupt in general already depends on the transfer 
> mode -- the BMIDE interrupt which is a (delayed) reflection of INTRQ is 
> cleared implicitly by the dma_end() method -- except in at least sgiioc4 
> driver.
>   BTW, sgiioc4 seems another candidate for clear_irq() implementation 
> -- currently clearing is done implicitly by the read_status() method (I 
> don't quite understand why it clears DMA error interrupt there). 
> However, since there's no documentation, I'm not sure how the IDE 
> interrupt is latched by IOC4.

The person who originally wrote sgiioc4 has been gone for a long time.

I'm guessing that the DMA error is cleared there, because any DMA error
status has already been processed above, and it's easier to clear
unconditionally than to test and clear, and there's no ill effect to
clearing something that's already clear.

jeremy
--
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/