On Wed, May 21, 2008 at 11:51 AM, Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote: > On Wed, 21 May 2008, Grant Likely wrote: > >> I concede that sometimes platform code just has to pass data to the >> driver that cannot be described in the device tree. callback pointers >> being the most significant example and we do need a sane way to do so. > > Sorry, I just cannot understand. So far my understanding was, that OF > bindings were there to _completely_ describe hardware, that cannot be > autoconfigured or probed.
Correct, they describe the hardware... to a level sufficient to identify it usefully and uniquely to an operating system. > So a _generic_ driver gets all information it > needs from the device tree and needs no additional information to handle > the hardware. Also correct. > > Now if a driver needs additional information from "platform code" what's > the purpose of partial data in the device tree at all? Just use board > information as usual. (Note; it must be said that I think the situation is *rare* and should be avoided) If some behaviour is entirely board specific and doesn't have any possibility of being duplicated on other boards, then it makes sense for the code implementing that behaviour to live with the platform code. For example; consider the example of the ads7846 device driver. It needs a pointer to a function that will tell it whether or not the pen is down. This is entirely a board specific kind of thing; it might happen via a GPIO or a key press or a phase of the moon. The device doesn't care; but the driver needs a way to test the state. The driver needs some method to obtain the pointer to the function. It cannot be encoded in the device tree because it is a function pointer, not raw 'data'. The device tree may have some data that tells the platform code how it is wired up; but the pointer itself cannot be encoded into the device tree. I see two obvious ways to do this. (note: platform code cannot simply export the function because it might be a multiplatform kernel with multiple platforms defining the same function). 1) Pass it in a data structure passed with the device structure 2) Make the device driver call out to a lookup function that returns the function pointer. Option 1) is basically some form of pdata scheme. Option 2 requires the driver to use some API to go looking for the relevant function. I'm not convinced yet on which method is the best; but I cannot say that platform code must never pass data to drivers that is not directly encoded into the device tree. Besides, we must always account for the situation where the provided device tree has a bug or the hardware has a quirk and platform code needs to do something to fix it up. Or if you prefer: 99% of the time everything is handled with common code reading the device tree directly; but in the 1% of the time where that does not work (due to bugs or quirks) we have options to insert workaround code. > > What good is an OF-binding if it doesn't provide complete information? It still increases the amount of common code even if there are rare corner cases that require board specific code. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
