Hi! > > > > > DT: leds: Add Qualcomm Light Pulse Generator binding > > > > > > > > This one should be first. > > > > > > > > > > Okay, no problems. > > > > > > > And I guess I'd prefer the driver to go in first, before the generic > > > > pattern interface. > > > > > > > > > > The driver won't compile without the additions to the header file. Would > > > you like the rest of the driver to go in first, then the generic > > > interface and finally the pattern part of the driver? > > > > > > Large portions of the driver doesn't make sense without the pattern > > > part, so I think I would prefer it to go in as one patch. > > > > Can we get minimum driver without the pattern parts? > > It's possible to do, but I must admit I find it slightly contrived. > > The overall design of different parts of the driver does relate to how I > decided to structure and implement the pattern support, so this would > mean that the driver we merge has a conceptual dependency on a > out-of-tree part. Ok... but I guess that's something we can live with? > May I ask about the reasoning for your request? Is it just to not leave > the driver hanging while we conclude the discussion on the pattern > interface? Yes; it would be good to have driver in the tree. OTOH new userland interface is a "big" decission, and we'll have to support the interface "forever" once it is merged. Actually even complete driver (but w/o the userland interface) would be acceptable. Drivers we can fix. Userland interfaces... not so. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature