Hi All, On Wed, Nov 18, 2015 at 9:18 PM, Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, Nov 18, 2015 at 10:46:52AM +0100, Philipp Zabel wrote: >> Hi Hans, >> >> Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede: >> > On 16-11-15 18:01, Philipp Zabel wrote: >> > > If there are two devices sharing the same reset line that is initially >> > > held asserted, do the two drivers somehow have to synchronize before >> > > releasing the reset together? >> > >> > Not to my knowledge, I suggest that we simply treat this same as >> > regulators / clocks where the first one to enable it actually gets >> > it enabled (de-asserted in case of a reset), and the last one >> > to disable (assert) it (so dropping the usage counter back to 0) leads >> > to it being asserted again. >> > >> > This seems to work well enough for clocks / regulators and phys, and >> > at least for my use-case it should work fine for the shared reset too >> > (I will test to make sure of course). >> > >> > So from my pov a simple counter should suffice, does that work for you ? >> >> I don't quite understand what counting will help with, then. The first >> driver to call reset_control_deassert will deassert the reset, whether >> you count or not. >> But if the two drivers have deasserted an initially asserted reset, a >> reset_control_assert for one of them will silently fail. > > Then maybe we can just make it return an error when someone calls > _assert or _reset on a reset line that has more than one user? Just to set another cat amongst the pigeons: What if a driver needs to toggle the shared reset line of some IP block to get it out of some broken state? Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- 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
