Hi Rafael, On Fri, May 19, 2023 at 08:34:34PM +0200, Rafael J. Wysocki wrote: > On Wed, Mar 29, 2023 at 12:10 PM Sakari Ailus > <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > > > MIPI DisCo for Imaging defines properties for sensor-adjacent devices such > > as EEPROM, LED flash or lens VCM as either device or sub-node references. > > This is compliant with existing DT definitions apart from property names. > > > > Rename parsed MIPI-defined properties so drivers will have a unified view > > of them as defined in DT and already parsed by drivers. > > I don't particularly like this idea. > > One of the drawbacks is that if somebody doesn't care about DT > bindings (for instance, because they will always run on platforms > without DT), they won't be able to use the MIPI-defined property names > in their code. > > I would very much prefer to add a set of DT-defined properties with > the same values. The, whoever wants to use the property names from > the DT bindings, they will be able to do that, but it will be also > possible to use the MIPI-defined ones. > > The previous patch adds the "rotation" property to the swnodes set, so > I don't see any problems with doing that for the properties in > question. I don't think this would be a problem really, no, but I question the need to ever access the MIPI specification names in Linux outside this piece of code. Drivers for cameras, lens controllers and LED flashes generally try to avoid being specific to a given firmware interface and the established de facto naming of these properties in the kernel is aligned with Devicetree. I'd like to see differences only when the functionality differs, otherwise they should be the same. Creating a copy when you can modify it is waste of a bit of memory. On the upside, the object memory could remain const that way. -- Kind regards, Sakari Ailus
