Hello.

Scott Wood wrote:

quoted

quoted

+    hwif->hw.io_ports[IDE_DATA_OFFSET] = port;
+
+    port += (1 << pdata->ioport_shift);
+    for (i = IDE_ERROR_OFFSET; i <= IDE_STATUS_OFFSET;
+         i++, port += (1 << pdata->ioport_shift))

    Looks like shift doesn't buy as anything, why not just use stride?

It doesn't buy us anything in here, but it's conceivable that someone 
may want to write a driver that uses a shift in the I/O accessor rather 
than an array of port offsets,

    It wouldn't be IDE driver then, and neither it would be libata which also 
does this another way this (despite pata_platform uses shifts too -- not in 
the accessors, so no speed loss).

and it's easier to convert a shift to a stride than the other way around

 > (not all architectures have an

equivalent of the cntlzw innstruction, and shift makes it clear that the 
stride must be power-of-two).  Plus, using shift is consistent with what 
we do on ns16550.

    Why the heck should we care about the UART code taling about IDE?!
    So, let me consider your argument purely speculative and invalid. ;-)

-Scott

WBR, Sergei