Guennadi Liakhovetski wrote: > On Mon, 27 Jun 2011, Guennadi Liakhovetski wrote: > > [snip] > >>> If the structures are expected to be generic I somehow feel that a field of >>> flags isn't the best way to describe the configuration of CSI-2 or other >>> busses. Why not to just use a structure with bus type and an union for >>> bus-specific configuration parameters? It'd be easier to access and also to >>> change as needed than flags in an unsigned long field. >> >> Well, yes, a union can be a good idea, thanks. > > ...on a second thought, we currently only have one field: flags, and it is > common for all 3 bus types: parallel, reduced parallel (bt.656, etc.), and > CSI-2. In the future, when we need more parameters for any of these busses > we'll just add such a union, shouldn't be a problem. What I meant above was that I would prefer to describe the capabilities in a structure which would contain appropriate data type for the field, not as flags or sets of flags in a bit field. This would allow e.g. just testing for v4l2_mbus_config.u.parallel.hsync_active_low instead of v4l2_mbus_config.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW. This way the flags used for the bus also express the bus explicitly rather than implicitly. Do you see downsides with this compared to using an integer field as flags? The other benefits of this are described in my earlier comment. Regards, -- Sakari Ailus sakari.ailus@xxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
