Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751535AbbKIMcQ (ORCPT ); Mon, 9 Nov 2015 07:32:16 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:12557 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751163AbbKIMcO (ORCPT ); Mon, 9 Nov 2015 07:32:14 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Mon, 09 Nov 2015 04:30:02 -0800 Date: Mon, 9 Nov 2015 13:32:04 +0100 From: Thierry Reding To: "Rafael J. Wysocki" CC: Linux PM list , Greg Kroah-Hartman , Linux Kernel Mailing List , Alan Stern , "Grant Likely" , Mark Brown , Rob Herring , Tomeu Vizoso , Dmitry Torokhov , Geert Uytterhoeven , "Michael Turquette" Subject: Re: [RFD] Functional dependencies between devices Message-ID: <20151109123202.GC23941@ulmo.nvidia.com> References: <1623682.7KVblAB3KQ@vostro.rjw.lan> MIME-Version: 1.0 In-Reply-To: <1623682.7KVblAB3KQ@vostro.rjw.lan> X-NVConfidentiality: public User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) X-Originating-IP: [10.2.69.248] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3627 Lines: 75 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: [...] > There's a question about what if the supplier device is being unbound before > the consumer one (for example, as a result of a hotplug event). My current > view on that is that the consumer needs to be force-unbound in that case too, > but I guess I may be persuaded otherwise given sufficiently convincing > arguments. I think this would be a huge step towards making the kernel more robust with little driver or subsystem code having to be duplicated. Currently most provider/consumer subsystems are fragile in that there isn't proper reference counting. Many subsystems will happily allow you to remove any of the provider, regardless of whether or not it has consumers. Most of the subsystems will make sure that modules can't be unloaded, but beyond that won't be able to prevent drivers from being unbound (either when a device is unplugged or unbound via sysfs). Even with proper reference counting there is no easy way to deal with devices going away (you'd need some sort of revoke semantics implemented for all providers, and consumers must be able to handle that situation gracefully). Implementing a force-unbind policy would make this a whole lot easier. Dangling resources will automatically become a thing of the past. The downside of course is that force-unbinding consumers may not always be the most user-friendly course of action. Consider an SD/MMC slot that uses a GPIO as card-detect pin. Unbinding the provider of the GPIO would cause the SD/ MMC controller to be unbound, hence unmounting the filesystem that it provided. That filesystem might have been the root filesystem. We discussed similar use-cases a while back and you proposed making the force-unbind policy be two-staged: reject unbind (-EBUSY) if there are any consumers, and force-unbind consumers if the provider was forcibly unbound (or caused by hot-unplug of the backing device). That sounds like a good compromise to me. That said I can also imagine subsystems where a reliable mechanism is in place to properly hotplug and -unplug providers. The good thing about the functional dependencies mechanism you propose here is that it's an optional mechanism that drivers use from ->probe(). Subsystems where a better mechanism exists can simply choose to do without functional dependencies. Thierry --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWQJI4AAoJEN0jrNd/PrOhBswP/iBrNEri0doqa2JHW0LQuQ8j JvDUgL8PcamaS0UX9vzrGHd1+6+Zy+p/gbpjTlbk2kNVU3oKRJArCS7SJTjRWiAS ykTbYjMkewBrtBNpIpw2uVj+4Gqgt4jA0oar03Np2xKMWTiuOxWMZ/9qVxwAy4oa dbEclL0fJ7Op8bEY2NKW+sLE6HJ75Hf0ci7qHUYPrbK1Z1P4FMQlewXj2U75ED54 9pTLK7PKBHHwNAQ+f80p4tNjZq3qzwGWZfmaIY0IZL0Ca5H0dpHlr90Y2u0zn/D9 sGhHE7Pfl282o5M4hb6E8H/fc1XFnttJ4MtnjBLqEsPaQwn+jC+34a0s5vNQ3D0O q+gcPhV6OXca/65rvqcJen9MGyavyNvcZmXRnhnied1EwAlAdjdT7XEwJZqBwVhE QxxUNMTxsuRX428L8cLnsZfGGtmbSwyIP6Yunc6kB3qimSv1vl5FZTUPfs2Jl9Nj 9gbIZZbeR1ZsYSLyWTmA7PDzWO6K3bzT3gn1PX1XoBafQIY54qRCfs/wjzimBl/T xZT63/OP/G7WtbGQPgJc3tgII+IZGnTuxl+YbmN95MNlOKwXEmf6LBqeMPpKkak/ 3nuBUFdCmLotsMpvdBa5p0ScYcoC4uAVjapeKl8mqIGaxK7JIZaKc0DGu8/0+evS HGa4dk9MHErl9ifLcuCf =GNRM -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/