Re: [PATCH 01/18] ide: add ->read_sff_dma_status method

From: Sergei Shtylyov
Date: Sun Sep 07 2008 - 18:27:22 EST


Hello.

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

Sure.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/