On Tue, 5 Aug 2008 20:22:55 -0600
Matthew Wilcox <matthew@xxxxxx> wrote:
> On Tue, Aug 05, 2008 at 09:46:51PM +0100, Alan Cox wrote:
> > > + * Some commands are specified to transfer (a multiple of) 512 bytes of data
> > > + * while others transfer a multiple of the number of bytes in a sector. This
> > > + * function knows which commands transfer how much data.
> >
> > static u32 ata_sector_or_block[]={...};
> >
> > if (test_bit(tf->cmd, &ata_sector_or_block))
> >
> > looks so much more elegant than a giant switch statement and I suspect
> > produces far better code
>
> Probably ... I did consider it, but I think I was too influenced by the
> existing READ/WRITE LONG code.
>
> > > + * ATA supports sector sizes up to 2^33 - 1. The reported sector size may
> > > + * not be a power of two. The extra bytes are used for user-visible data
> > > + * integrity calculations. Note this is not the same as the ECC which is
> > > + * accessed through the SCT Command Transport or READ / WRITE LONG.
> > > + */
> > > +static u64 ata_id_sect_size(const u16 *id)
> >
> > word 106 is not defined in early ATA standards so it would be wise to
> > check that ATA8 is reported by the drive - and trust the relevant bits
> > for ATA7/8 as appropriate.
>
> I'm not sure that's necessary. The spec says to check whether words are
> valid by doing the & 0xc000 == 0x4000 test.
What early spec says what state word 106 is in ? Healthy paranoia is a
good idea in the IDE world because its all a bit murky in the early days
and you get some quite strange ident data from early devices - one reason
for 0xC000 = 0x4000 is that some early drives use 0xFFFF for unknown words
for example!
> good migration path? We could have the driver set a flag, or call into
> the driver from the midlayer to check whether it can cope with a
> particular sector size.
On the driver side I need to know so I can control the FIFO so I guess
knowing when you start/end planning to use large sector sizes. The driver
could do it per command but the cost is almost certainly not worth it as
I'd expect us to stick to a size. A driver method would do the trick
nicely if it could return -EOPNOTSUPP or similar.
Alan
--
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
