Use of drivers/platform and matching include?

Kumar Gala galak at codeaurora.org
Thu Oct 3 12:38:44 EDT 2013


On Oct 3, 2013, at 11:25 AM, Greg Kroah-Hartman wrote:

> On Thu, Oct 03, 2013 at 11:21:10AM -0500, Kumar Gala wrote:
>> 
>> On Oct 3, 2013, at 10:27 AM, Greg Kroah-Hartman wrote:
>> 
>>> On Thu, Oct 03, 2013 at 09:45:38AM -0500, Kumar Gala wrote:
>>>> As we look at upstreaming more support for the Qualcomm MSM SoCs there
>>>> are a number of drivers or library like routines that are unique to
>>>> the MSM platform, we are thinking that putting them under:
>>>> 
>>>> drivers/platform/qcom/
>>> 
>>> What type of drivers are these?  Shouldn't they really go under the
>>> specific driver type directory instead?
>> 
>> If there isn't an existing driver/ dir for this I dont see how it can go there, I'm not also not really a fan of trying to artificial put something that is highly SoC specific into something generic of this nature.
> 
> Loose a line-wrap somewhere?...
> 
> Anyway, you didn't answer my question, so why do I need to answer yours?

Sorry about that.  I gave one example in the initial email about a driver that is used to get regions of memory used by processors or HW blocks on the SoC.

I'm still sorting through the mass of code to figure out what all is there and where might be the best place for it.  However, I do think we will end up with some SoC specific bits that highly unique to qualcomm SoCs that just dont fit anywhere else and thus drivers/platforms seemed the best location.

As we submit things upstream I'm more than happy to move stuff around based on feedback.

One example you can look at is arch/arm/mach-msm/smd.c, this is a mix of the memory region support (which we've since split out) and some multiproc messaging functionality.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation




More information about the linux-arm-kernel mailing list