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  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]
Date:	Mon, 08 Sep 2008 02:26:55 +0400
From:	Sergei Shtylyov <>
To:	Bartlomiej Zolnierkiewicz <>
Subject: Re: [PATCH 01/18] ide: add ->read_sff_dma_status method


Bartlomiej Zolnierkiewicz wrote:

>>>>> static void ide_tf_load(ide_drive_t *drive, ide_task_t *task)
>>>>> {
>>>>> 	ide_hwif_t *hwif = drive->hwif;
>>>>> @@ -323,6 +331,8 @@ static void ata_output_data(ide_drive_t 
>>>>> void default_hwif_transport(ide_hwif_t *hwif)
>>>>> {
>>>>> +	hwif->read_sff_dma_status = ide_read_sff_dma_status;
>>>>> +
>>>>> 	hwif->tf_load	  = ide_tf_load;
>>>>> 	hwif->tf_read	  = ide_tf_read;
>>>>    I also didn't understand the motivation behind putting this method 
>>>> together with the transport operations... IMO, DMA programming interface 
>>>> hardly has anything to do with transporting the data over IDE bus.
>>> The motivation was that hwif->dma_ops is not available yet when
>>> ->read_sff_dma_status is used in ide_pci_check_simplex().
>>> However I agree that it should somehow find its way into ->dma_ops
>>> (as usual patches are stongly preffered :).
>>     Unless I'm missing something changing the place where hwif->dma_ops is 
>> initialized to sff_dma_ops (along the lines it was changed for hwif->dma_base) 
>> seems pretty trivial, so I wonder why you didn't do it in the same patch...

   Ah, I forgot for a moment that there were two patches and it would 
have make no sense to do that in the patch that factored out 
ide_pci_check_simplex()... And then tre was a patch introducing 'struct 
ide_tp_ops' which incorporated the read_sff_dma_status() method.

> Indeed, it should be trivial now, one just needs to be careful to:
> * move 'if (d->dma_ops) ...' from ide_init_port() into
>   ->init_dma/ide_hwif_setup_dma()
> * unset ->dma_ops on ->init_dma/ide_hwif_setup_dma() failures


> I guess I overlooked it ATM of making the patch (or the code evolved
> greatly in the meantime)...

   I think I understand now: it's sticking read_sff_dma_status() method 
into 'struct ide_tp_ops' that was a wrong move that's worth undoing (by 
putting it where it really belongs).

> [ It is really time consuming and difficult to recall the every small
>   detail of every patch after few months (the patch was posted 10 weeks

   Heh, as if it wasn't time consuming to untange that after a few 
months (when I'm suposed to spend time elsewhere :-)...

>   ago and merged 6 weeks ago)...  The most efficient way of handling
>   such issues upon discovery is with sending patches... ]

    Sigh, I'll see what I can do in my currently very limieted time...

> Thanks,
> Bart

MBR, Sergei

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists