On 2017-06-01 04:19, jmondi wrote: >> But why do you need to identify them? What problem are you trying to solve? >> > I want to be able to walk all children devices of an i2c-adapter, > not including the mux channel i2c-adapters. I'm sure I can work around it. > While doing that I stumbled upon this and thought it was wrong. Hey, I'm not saying that the current (ab?)use of dev->parent for the i2c hierarchy is "right". But fixing things is simply just more involved than what you proposed. Some random thoughts on this topic: - I'm not sure it is sane to rearrange the device hierarchy the way the i2c mux code does, and the i2c hierarchy is available by other means as parent in struct i2c_mux_core. The trouble is getting to that struct from outside the owner driver. Maybe make i2c_mux_alloc create a separate device? Then all i2c muxes could store their copy of struct i2c_mux_core in a way that could be easily found by generic code. - Is it ok to add children to unsuspecting(?) devices? (I.e. the parent adapter of an i2c mux gets extra children.) - I think the current scheme prevents the parent adapter from going away before the mux child adapter during tare-down, which is a good thing, but I think that can be solved with these new device links that I read about? - The i2c hierarchy also needs to be visible in sysfs, which it is with the current scheme (but not with your patch) so some kind of new i2c-parent attribute is needed for i2c mux child adapters. - Changes in this area feel subtle, and needs testing... Cheers, peda -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
