From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Subject: Re: [PATCH 1/9] cmd64x: implement clear_irq() method Date: Fri, 12 Jun 2009 23:13:41 +0400 Message-ID: <4A32A8E5.4070000@ru.mvista.com> References: <200702140101.26639.sshtylyov@ru.mvista.com> <200906121816.58809.bzolnier@gmail.com> <4A32A0F7.3020101@ru.mvista.com> <200906122101.14520.bzolnier@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from h155.mvista.com ([63.81.120.155]:33843 "EHLO imap.sh.mvista.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1757321AbZFLTNo (ORCPT ); Fri, 12 Jun 2009 15:13:44 -0400 In-Reply-To: <200906122101.14520.bzolnier@gmail.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Bartlomiej Zolnierkiewicz Cc: linux-ide@vger.kernel.org Hello. Bartlomiej Zolnierkiewicz wrote: >>>> Convert the driver's two dma_end() methods into clear_irq() methods -- the >>>> driver will now use the standard dma_end() method implementation, ide_dma_end(). >>>> >>>> Signed-off-by: Sergei Shtylyov >>>> >>>> --- >>>> The patch is atop of ide-2.6.git 'for-next' branch. >>>> >>>> drivers/ide/cmd64x.c | 31 +++++++++++++++++-------------- >>>> 1 files changed, 17 insertions(+), 14 deletions(-) >>>> >>>> >>> [...] >>> >>> >>>> @@ -226,11 +226,10 @@ static void cmd64x_set_dma_mode(ide_driv >>>> (void) pci_write_config_byte(dev, pciU, regU); >>>> } >>>> >>>> -static int cmd648_dma_end(ide_drive_t *drive) >>>> +static void cmd648_clear_irq(ide_drive_t *drive) >>>> { >>>> ide_hwif_t *hwif = drive->hwif; >>>> unsigned long base = hwif->dma_base - (hwif->channel * 8); >>>> >>>> >>> Don't we need to check whether hwif->dma_base is valid now? >>> >>> >> You're right, I have managed to overlook this. I'll change this to >> pci_resource_start() call instead... >> > > Currently this driver should operate fine without BAR4 set so even if > this is pci_resource_start(), the return value still needs to be checked > against 0 -- it is the reliability/maintainability issue. > Nay, the PCI device just must not be enabled in this case: all BARs must be allocated, period -- that's what the PCI specs say, IIRC. Besides, 0 doesn't generally mean "unassigned" in the PCI world. I know, I know, we consider it unallocated but that's not correct -- only PCI 2.2 (IIRC) used to have words about 0 meaning "unassigned". Note that we don't check pci_resource_start() result for 0 in the drivers that do call it, like hpt366.c... I'm seeing the checks in pdc202xx_*.c but they seem pretty useless -- this just must not happen. So, I don't agree here... >>> Also shouldn't this patch be done after fixing core code first? >>> >> Fixing what exactly, ide_timer_expiry()? >> > > Yes. Currently IRQ is cleared in ide_timer_expiry()'s code-path: > > -> hwif->handler [ ide_dma_intr() ] > -> dma_ops->dma_end [ cmd64{x,8}_dma_end() ] > > After this patch it won't be. > Ah, that's a correct spotting... MBR, Sergei