On 25/05/15 14:50, Jacek Anaszewski wrote: >> On 23/05/15 14:03, Sakari Ailus wrote: >>> >> On Thu, May 21, 2015 at 03:28:40PM +0200, Sylwester Nawrocki wrote: >>>> >>> flash-leds = <&flash_xx &image_sensor_x>, <...>; >>> >> >>> >> One more matter to consider: xenon flash devices. >>> >> >>> >> How about samsung,camera-flashes (and ti,camera-flashes)? After pondering >>> >> this awhile, I'm ok with removing the vendor prefix as well. >>> >> >>> >> Let me know what you think. >> > >> > I thought about it a bit more and I have some doubts about semantics >> > as above. I'm fine with 'camera-flashes' as far as name is concerned. >> > >> > Perhaps we should put only phandles to leds or xenon flash devices >> > in the 'camera-flashes' property. I think it would be more future >> > proof in case there is more nodes needed to describe the camera flash >> > (or a camera module) than the above two. And phandles to corresponding >> > image sensor device nodes would be put in a separate property. > > Could you give examples of the cases you are thinking of? I don't have any examples in mind ATM, I just wanted to point out the above convention might not be flexible enough. Especially since we already know there is more sub-devices within the camera module than just flashes and image sensors. >> > camera-flashes = <&flash_xx>, ... >> > camera-flash-masters = <&image_sensor_x>, ... >> > >> > Then pairs at same index would describe a single flash, 0 would indicate >> > a null entry if needed. > > When it should be needed? Not sure if there is a real use case for null entries, it was just to note we can skip any entry if needed - probably an irrelevant comment. I could imagine 2 LEDs of which one is only triggered in software, so it wouldn't have a 'camera-flash-masters' entry. >> > Similarly we could create properties for other sub-devices of a camera >> > module, like lenses, etc. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
