acceptable chip driver limitations

acceptable chip driver limitations

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Hi!

Is it allright if my chip driver read/write's only accept 32-bit
to/from/len's?

I.e. if I return with -EINVAL if somebody tries to read/write a single byte
or tries to read from a non-dword boundary, is that acceptable or should the
driver cater for word/byte read/writes as well?

If this is the case, it complicates things a lot because for instance in my
case the flash device can only handle 32-bit read/write's and smaller
accesses will have to be emulated.

-- 

Regards
 Abraham

First study the enemy.  Seek weakness.
		-- Romulan Commander, "Balance of Terror", stardate 1709.2

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: acceptable chip driver limitations

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hi David!

> >  Is it allright if my chip driver read/write's only accept 32-bit to/
> > from/len's?
> 
> > I.e. if I return with -EINVAL if somebody tries to read/write a single
> > byte or tries to read from a non-dword boundary, is that acceptable or
> > should the driver cater for word/byte read/writes as well?
> 
> Leave them NULL. You can't return an error value from them - there's no 
> possible value you can return that isn't a valid return from an actual read.
> 
> They should never get called is the buswidth doesn't match them.

No, I'm talking about mtd->read() and mtd->write. Surely they can return
errors? If not, what about physical write/read errors?

-- 

Regards
 Abraham

Visit beautiful Vergas, Minnesota.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: acceptable chip driver limitations

[David Woodhouse]

abraham@2d3d.co.za said:
>  No, I'm talking about mtd->read() and mtd->write. Surely they can
> return errors? If not, what about physical write/read errors? 

Sorry, I misunderstood. No, that is not acceptable. You must accept 
unaligned and odd-sized writes. You can just special-case the first and 
last read/write cycles, padding writes with 0xFF. See how the existing 
driver for Intel chips does it.


--
dwmw2