Thanks for noticing my ATA patches. Martin Petersen has actually been doing more work than I have on supporting 4k sectors in the kernel, Peter Anvin has been working on some of the boot loader issues, and I know Matt Domsch has been putting in some effort too. I just did some of the easy bits ;-)
I have some hopefully constructive criticism for this article:
LBA stands for Logical Block Address, not Large Block Access. LBA was actually a move away from CHS (Cylinder-Head-Sector) addressing. I'm not sure whether LBA coincided with the move from 28-bit commands to 48-bit commands or not. Adding 48-bit commands was a much smaller undertaking than changing the sector size; there are many more intricate dependencies on sector size than there were on maximum drive size.
I don't know if I've explained myself terribly well if an article like this contains the line "The sect_size is used instead of ATA_SECT_SIZE when the data transfer is a multiple of 512-byte sectors." Let me see if I can do better:
Not all ATA commands that transfer data do so in multiples of the sector size. DOWNLOAD MICROCODE is a great example of this. It sends data to the drive in multiples of 512 bytes, regardless of the sector size. So when we issue a command, we have to decide what transfer size to use; it could be the sector size, or it could be 512 bytes.
My patchset implements a pair of lookup tables for this; one to say "This command transfers in units of sector size" and another to say "We know what this command is". If it's in the first table, we know to use sect_size. If it's not in the second table, we don't know what size to use, so we print an error, assume 512 bytes and add it to the second table. My rationale for this design is that new commands are less likely to be read/write data commands than they are to be some kind of management command.