linux-kernel - Re: Use of drivers/platform and matching include?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Oct 2013 11:38:44 -0500
From:	Kumar Gala <galak@...eaurora.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: Use of drivers/platform and matching include?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/