Il Wed, Jun 14, 2006 at 08:30:27PM -0400, Dennis Munsie ha scritto: 

well, the hacks don't seem specific to the driver -- more that they  
are there to deal with quirks in the monitors -- which is something  
that shouldn't be in the driver.  It could also be that these hacks  
are completely unnecessary -- but that is something that I'm not  
qualified to determine.

Those hacks are needed to wake up the EEPROMs on some weird monitors.
When I did the initial coding of the I2C stuff I asked ATI and they
confirmed that that black magic was not stricly needed but a "nice to
have" to make sure that EDID could be read also from older monitors.

But, the problem is that to make it robust and generic, i need access  
to some internal data in the i2c bit algo.  I can call the  
appropriate functions that tie back into the drivers, but I can't be  
100% sure that the I2C adapter passed to me is a bit algo and not  
something else. There is no ID field in the adapter struct (or any  
of the structs inside of that one) that allows me to verify that I  
have good data.

Now, playing devil's advocate, we could just say that since this  
routine should only be called by drivers in the fb subsystem, they  
should know what i2c algorithm they are using, and it can be up to  
the caller to insure that everything is OK... but, I really don't  
feel comfortable using that method.  I'll leave that one up for  
debate...

Well, this stuff will be used only from kernel drivers. So I'd say that
if a driver is passing down something which is not a bit banging adaptor
then that driver is buggy, it violating the API.
I mean, right now I can pass crap to tons of kernel functions and then
watch the kernel explode; it's not a library which will be used by
userspace applications :P

Luca
-- 
Home: http://kronoz.cjb.net
"Ci sono le balle, le megaballe e le statistiche".
 Mark Twain