On 06/26/2014 12:28 AM, Courtney Cavin wrote: > On Wed, Jun 25, 2014 at 11:18:57PM +0200, Rob Herring wrote: >> On Wed, Jun 25, 2014 at 1:04 PM, Courtney Cavin >> <courtney.cavin@xxxxxxxxxxxxxx> wrote: >>> On Wed, Jun 25, 2014 at 01:07:13PM +0200, Stanimir Varbanov wrote: >>>> On 06/25/2014 01:36 AM, Courtney Cavin wrote: >>> Greg, Grant, Rob? What's the law? >> >> Generally sub-blocks of a device are handled as platform devices. If >> there is a good enough reason then creating a new device type may be >> okay, but we certainly wouldn't want every PMIC or MFD driver to go >> off and define their own bus. Probably not each vendor doing a bus >> either. > > Thanks for the clarification! OK, I tend to agree that creating a new bus only to define new device type is pointless. But using platform devices for sub-blocks attached to spmi-bus seems wrong too. Courtney, the other option could be to extend spmi.c::of_spmi_register_devices to create spmi_device for each sub-function per each slave. Currently the function creates devices only for every spmi slave. Thus every sub-function driver will be spmi_driver (something like i2c_driver for example). Sub-function resources could be embedded in spmi_device structure. I'm not sure how much code/efforts will be needed but it seems it is worth to do. Any thoughts? -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
