On Thu, 2011-08-11 at 20:53 -0700, Dmitry Torokhov wrote: > On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote: > > at least wakeup, irq_flags in the structure should be something > > related with driver implementation not hardware. Suppose all others > > are hardware properties, it looks terrible to list and get so many > > properties in dts and drivers. It doesn't seem like this should be a blocker for moving the things we can move, the conversion is going to need doing anyway so we may as well get on with it. We always keep the platform data option around anyway as not all platforms have converted to the device tree and it means that systems that don't need to use any of the things that are difficult to convert are able to convert. In the case of wakeup there's already an API for controlling things at runtime (device_may_wakeup() and so on) which the driver should probably be converted to use, though I've not looked at what the actual platform data does. In the case of the IRQ flags we've got a generic problem that needs solving at the IRQ level - the device is responsible for specifying the flags but many devices are flexible about how they signal interrupts in order to improve interoperability with controllers. > Maybe should not add DT bindings for devices that can't be adequately > expressed via DT properties [yet]? Because I do not see what benefits we > get since platform code still needs to provide missing data and now we'd > have issue of data not being there when device is registered and driver > is being bound to it. You tend to find that in a lot of systems only need a subset of the platform data - some of it can get pretty esoteric - or perhaps none at all so they'll be able to run happily even if not everything can be configured via the device tree. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
