Re: [RFC PATCH 0/6] Support for QPNP PMIC's

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux