Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
As Arjan suggested, trying to load the default modules right after the initial rootfs mount could be an acceptable compromise and it would be really nice (for both code sanity and avoiding future problems) to be able to declare module loading nested inside async unspported. we can even try twice the first time right after we mount the initramfs the second time when the initramfs code exits, and before we exec init (the initramfs supposedly mounted the real root fs at this point) if you want your elevator to apply to your root filesystem storage, the rule will then be put the module in the initramfs... but to be honest, that's not a restriction that is unreasonable or unexpected. for doing a module loading from inside an async handler..we can then just make use of the normal load this module async way of requesting a module. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds
For now, I'm gonna implement simple I'm not gonna wait for myself self-deadlock avoidance. If this needs any more sophistication, I think we better reimplement it so that we can explicitly match up and track who's gonna wait for what instead of throwing everything into a single cookie space and then try to work back from there. async fundamentally had the concept of a monotonic increasing number, and that you could always wait for everyone before me. then people (like me) wanted exceptions to what everyone means ;-( I'm ok with going back to a single space and simplify the world. the case with (usb) module loading is fun... people expect the device to be there (since frankly, it's hard to do otherwise).. ... but it's also really hard due to the nature of USB.. USB is async in nature, even independent of the kernel async stuff. Example: Load ehci.ko ... the actual use devices don't show up for some time. the module wait case is tricky, and I wonder if there's deadlocks lurking even without async. (btw there is a similar situation at the end of the normal kernel boot versus things like asynchronous driver initializing... but we skip that in the case of an initrd is used to bypass a very similar deadlock. this is even without async in use.. typical hard case is the PS/2 mouse probing) at some point in the past we had the concept of request a module but don't wait for it, and I wonder if that is what should have been used here. Doing a range wait, with the start of the range being taken at the start of module loading is a bit of a hack, but it'll work for the userspace expected semantics of all async stuff of the *loaded module* be done, independent of all other modules/async stuff. It's not as deadlocky as one might think, but it's not going to be efficient to implement. not self-deadlocking likely solves most practical cases though -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB port power off discussion
On 9/23/2012 8:33 PM, Rafael J. Wysocki wrote: On Sunday, September 23, 2012, Peter Stuge wrote: Rafael J. Wysocki wrote: Well, we actually need to handle power domains appropriately. .. Some work in that direction has been done in the ARM space, where we have much more direct access to hardware, and I suppose it may be extended to things like ganged sets of ports (which actually are power domains). Of course. Is there already an API for power domains there? What does it look like? Yes, there is, as it turns out. :-) Please see drivers/base/power/domain.c and include/linux/pm_domain.h. Of course, this only covers a limited set of use cases at the moment, but I think it's better to extend the existing code to cover more of them than to add new code of similar functionality. yeah. well... we also have the voltage rail framework, which came from ARM, but matches the ACPI paradigm much more closely. Ideally we map ACPI to the VR framework, and then have a more generic mapping from that to power domains. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB port power off discussion
On 9/24/2012 12:13 AM, Alan Stern wrote: Therefore all we need is an API for individual devices, not for domains. Of course, userspace may want to know which devices all belong to the same power domain. agreed on both. I'd like PowerTOP to be able to report at least who keeps power alive and such.. ;-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
