Hi Julian, Am Mittwoch, den 18.11.2015, 23:32 +1100 schrieb Julian Calaby: [...] > Assuming board designers are sufficiently ... stupid, won't most > drivers eventually need to use the _shared variants? Wouldn't it be > (horrifically more complicated and) better to just build this into the > generic code and switch on the shared reset line handling if multiple > devices take references to the same reset line? (Can we run through > the device tree and mark them in advance? What happens with overlays?) Either way, I think we need some way to differentiate between two different meanings of reset_control_assert - reset_control_may_assert (the clock-like case) and reset_control_must_assert (the fix broken hardware state case). > That said, I suspect that to deal sensibly with shared reset lines > we're also going to need some way to init devices in lockstep with > others, i.e. we can't deassert device A until it's clocks are running, > however the reset line is shared with device B who also can't be > deasserted until it's clocks are running. This seems like it'll get > rather complicated quickly, to say the least. > > It almost seems that, unless some other board has a similarly broken > design, that it might almost be easier to just make variants of > generic-ehci and generic-ohci to handle this one particular case. On i.MX6Q the 2D rasterizer and 2D vector graphics cores share a reset line, but there we have the luxury of a single driver handling both (and furthermore the cores have their own soft reset bits). regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
