[i2c] Add ARM Versatile and Realview I2C driver

[Russell King]

On Sat, Dec 02, 2006 at 01:22:30PM +0100, Jean Delvare wrote:
> On Thu, 30 Nov 2006 20:58:35 +0000, Russell King wrote:
> > On Thu, Nov 30, 2006 at 08:44:22PM +0100, Jean Delvare wrote:
> > > Note that in theory i2c_del_adapter could fail.
> > 
> > Eww.  That would not be nice for hot-pluggable hardware.  Luckily this
> > isn't, but note that even if we did return the error to the driver
> > model via the remove method, the driver model itself ignores the
> > return code and would continue to unbind the driver.
> 
> I wonder why the remove method has to return an int, rather than void,
> then.

Someone was misguided?  This is a pet peeve of mine.

Code which thinks it can refuse a "remove" event is just plain silly IMHO.
Consider these cases:

1. a hotpluggable device.  You unplug the device physically from the
   machine.  The software tries to remove the device, but encounters
   an error, so refuses to process the remove event.  Is the hardware
   still there?  From the software point of view it is.  From reality
   it isn't.  User eventually has to reboot their system to recover.

2. gdb and it's thread tracking.  (this is something I've recently
   encountered.)  You run a program, it exits but gdb says "thread
   not found" and continues thinking it's running.  Using "kill"
   results in "thread not found".  Using "quit" results in "thread
   not found" and it not quitting.  The only way to quit gdb is to
   send it a SIGKILL.  Duh.  (if the thread isn't found, it's
   obviously already dead!)

So, I'd say it's fine to print a message if you encounter some unexpected
state, but to fail an event to do with shutting something down is just
silly.

It's just as silly as trying to close a windows program and it popping
up a modal box saying something like "Macro disabled [cancel] [ok]",
clicking either button and the program resuming.  So you try to close it
again, repeat, repeat repeat and repeat, and eventually pull the power
cord from the machine.  (I've actually encountered this situation
several times.)

(Yes, I do accept that there are _certain_ cases where you do want to
handle such errors, but such cases need to handle the errors gracefully
in some way that's appropriate to that case.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: