On Tue, 07 Jun 2016, Lee Jones wrote: > On Tue, 07 Jun 2016, Peter Griffin wrote: > > > Hi, > > > > On Mon, 06 Jun 2016, Lee Jones wrote: > > > > > Phasing out generic reset line requests enables us to make some better > > > decisions on when and how to (de)assert said lines. If an 'exclusive' > > > line is requested, we know a device *requires* a reset and that it's > > > preferable to act upon a request right away. However, if a 'shared' > > > reset line is requested, we can reasonably assume sure that placing a > > > device into reset isn't a hard requirement, but probably a measure to > > > save power and is thus able to cope with not being asserted if another > > > device is still in use. > > > > > > In order allow gentle adoption and not to forcing all consumers to > > > move to the API immediately, causing administration headache between > > > subsystems, this patch adds some temporary stand-in shim-calls. This > > > will ease the burden at merge time and allow subsystems to migrate over > > > to the new API in a more realistic time-frame. > > > > Is the intention that this series will be taken into the next -rc? > > > > As the introduction of shared resets in reset subsystem has caused regressions > > on STi platforms. > > Yes, which is why it has a Fixes: tag. Ah wait. I thought this was the shared-memory patch. More haste, less speed and all that. I guess it should really go into the -rcs, yes. Since Hans' patch actually breaks a lot of devices. I'm pretty surprised a patch capable of this much damage was actually accepted to be honest. A better approach would have been to issue a warning, but keep the semantics the same for at least a couple of releases. However, I guess the damage has been done now, so let's do what we can do fix it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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