Hello. Scott Wood wrote:
+ 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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
