Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753833Ab0HSWXF (ORCPT ); Thu, 19 Aug 2010 18:23:05 -0400 Received: from mail-gw0-f46.google.com ([74.125.83.46]:56565 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753502Ab0HSWXD convert rfc822-to-8bit (ORCPT ); Thu, 19 Aug 2010 18:23:03 -0400 MIME-Version: 1.0 In-Reply-To: <87hbiql89d.fsf@deeprootsystems.com> References: <1281484174-32174-1-git-send-email-ppannuto@codeaurora.org> <1281484174-32174-3-git-send-email-ppannuto@codeaurora.org> <3F978429-F916-42E5-8B36-6AC02DAC8CA2@boeing.com> <87hbiql89d.fsf@deeprootsystems.com> From: Grant Likely Date: Thu, 19 Aug 2010 16:22:41 -0600 X-Google-Sender-Auth: RZSi9QEpm7xwhJiRTAFpONt5r5k Message-ID: Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses To: Kevin Hilman Cc: "Moffett, Kyle D" , Patrick Pannuto , "linux-kernel@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , "magnus.damm@gmail.com" , "gregkh@suse.de" , Paul Mundt , Magnus Damm , "Rafael J. Wysocki" , Eric Miao , Dmitry Torokhov , "netdev@vger.kernel.org" , Kyle D Moffett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5390 Lines: 116 On Thu, Aug 19, 2010 at 1:20 PM, Kevin Hilman wrote: >> There is no mechanism to allow drivers from one bus type to also be >> made available to another bus type. Certainly it would be possible to >> invent a mechanism, but the more I think about it, them more I think >> it will be a bad idea. ?The runtime-PM use-case that kicked this >> discussion off makes the assumption that a driver will behave >> identically when attached to either the platform_bus_type or the >> soc_bus_type. ?However, I think that in the general case that >> assumption will prove to be false. ?I strongly suspect that the new >> bus type will turn out to be not as similar to the platform_bus_type >> as originally assumed and that there will still be bus-type-specific >> impact on device drivers > > What makes you suspect that? ?Maybe Patrick has other use-cases in mind, > but from a PM perspective, I have not seen any impact. Call it a gut reaction if you like, but here's my line of thinking. In your use case, sure, there is zero impact on drivers, but will that continue to be the case for other bus architectures as they use this interface? Or, in other words, will this solution end up being short sighted and we'll be having this discussion all over again in a year? The big concern for me is the idea of partial divergence from the platform_bus_type (specifically having different bus_type, but same pool of drivers). For starts, how is it represented in the device model? Where do the device drivers live in /sys/bus/*/drivers? What happens when one bus type is unregistered but has drivers used by another bus type? Does it scale to the (granted, currently speculative) use-case where the device driver does need knowledge about which bus_type it is registered against? I'm also concerned about the complexity required to implement driver sharing and ensuring that correct locking and consistency is maintained between bus_types. Note: I consider partial divergence to be different from platform_bus_type inheritance which Patrick has been implementing. I don't have a technical issue with inheritance (drivers aren't shared), I'm just not convinced it is the best solution yet. :-) My other thought is this: If from both the device perspective and the driver perspective the interface is exactly the same as the platform_bus_type, then platform_bus_type really is the correct interface. That says to me that putting the runtime PM behaviour into a new bus_type is abstracting at the wrong level, and a different method should be used to modify PM behaviour, either based on device model topology (ie, the parent implement's the child's runtime PM behaviour), or maybe a "struct dev_pm_ops *bus_pm" in the struct device. However, the number of device drivers affected is still very small, and I don't have concerns if each driver registers itself on multiple bus types explicitly. For example: static struct platform_driver omap2_mcspi_platform_driver = { .driver = { .name = "omap2_mcspi", .owner = THIS_MODULE, }, .probe = omap2_mcspi_probe, .remove = __exit_p(omap2_mcspi_remove), }; static struct platform_driver omap2_mcspi_omap_driver = { .driver = { .name = "omap2_mcspi", .owner = THIS_MODULE, }, .probe = omap2_mcspi_probe, .remove = __exit_p(omap2_mcspi_remove), }; static int __init omap2_mcspi_init(void) { platform_driver_register(&omap2_mcspi_platform_driver); omap_driver_register(&omap2_mcspi_omap_driver); } module_init(omap2_mcspi_init); I'd even be okay with a helper function that kmemdups() a platform_driver and registers it onto multiple busses. Then if the driver ever really does need to be differentiated, then the driver can stop using the helper function and provide a different probe hook for each registration. > One of the primary goals of this (at least for me and it seems Magnus also) > is to keep drivers ignorant of their bus type, and any bus-type-specific > code should be done in the bus_type implementation. Heh; which just screams to me that bus_type is the wrong level to be abstracting the behaviour (but I also understand your need for the "omap_device" wrapper around platform_device which also requires some method to sort out when a platform_device really is an omap_device without an unsafe dereference). > Both for SH and OMAP, we've been using the (admiteddly broken) > weak-symbol-override approach to getting a custom bus-type based on the > platform_bus. ?We've been using that in OMAP for a while now and have > not seen any need to for the drivers to know if they are on the vanilla > platform_bus or the customized one. > > I'm very curious to hear what type of impact you expect to the drivers. My fears on this point may very well be unfounded. This isn't the hill I'm going to die on either. Show me an implementation of driver sharing that is clean and prove me wrong! :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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/