On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto <ppannuto@xxxxxxxxxxxxxx> wrote: > Inspiration for this comes from: > http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg31161.html > > RFC: http://lkml.org/lkml/2010/8/3/496 > Patch is unchanged from the RFC. Reviews seemed generally positive > and it seemed this was desired functionality. Thanks for your patch, it's really nice to see work done in this area! I'd like to see something like this merged in the not so distant future. At this point I'm not so concerned about the details, so I'll restrict myself to this: > /drivers/my_driver.c > static struct platform_driver my_driver = { > .driver = { > .name = "my-driver", > .owner = THIS_MODULE, > .bus = &my_bus_type, > }, > }; I would really prefer not to have the bus type in the here. I understand it's needed at this point, but I wonder if it's possible to adjust the device<->driver matching for platform devices to allow any type of pseudo-platform bus_type. The reason why I'd like to avoid having the bus type in the driver is that I'd like to reuse the platform driver across multiple architectures and buses. For instance, on the SH architecture and SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the sh-sci.c serial driver. The sh-sci.c platform driver supports a wide range of different SCI(F)(A)(B) hardware blocks, and on any given SoC there is a mix of SCIF blocks spread out on different buses. At this point our SH platform drivers are unaware where their driver instanced are located on the SoC. The I/O address and IRQs are assigned via struct resource and clocks are managed through clkdev. I believe that adding the bus type in the driver will violate this abstraction and make it more difficult to just instantiate a driver somewhere on the SoC. > /somewhere/my_device.c > static struct platform_device my_device = { > .name = "my-device", > .id = -1, > .dev.bus = &my_bus_type, > .dev.parent = &sub_bus_1.dev, > }; This I don't mind at all. Actually, this is the place where the topology should be defined IMO. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
