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:	Fri, 4 Oct 2013 15:29:14 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Olof Johansson <olof@...om.net>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-arm-msm@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: Use of drivers/platform and matching include?

On Friday 04 October 2013 12:48 PM, Olof Johansson wrote:
> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
>> On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
>>>
>>> So, no, there will be no new drivers under arch/arm.  They must be in the
>>> drivers subtree somewhere.
>>
>> I have no objection with this, and encourage it.
> 
> Ok, so these are some of the requirements as far as I see it:
> 
> * No per-vendor driver dumping ground under drivers/* (i.e. no
> drivers/platform/<soc vendor>/)
> * No weirdly constructed single-driver directories directly under
> drivers/* (we already have a few and should look at moving those)
> because nothing else fits
> * We need some sort of convention on dependencies. Several of these
> are more libraries than drivers, i.e. we'll have cross-calls for
> things like queue management, resource allocation, etc. So having a
> single location to hold most of these makes sense instead of
> everything cross-depending on everything else.
> 
> Based on the above, how about we create something like
> drivers/resourcemgr to hold these?   I think at least parts of the
> mvebu-mbus driver that ended up under drivers/bus might be a fit to
> move there. The APM queue allocator would likely be a fit, and maybe
> some of the qualcomm stuff. Kumar, what are your thoughts on that?

Slightly different question but relevant to th thread w.r.t the Queue
allocator/manager. We are also interested for TI Keystone SOCs.

Currently we have generic drivers/hwqueue/ with core hwqueue
layer implementing the standard hardware queue descriptor push/pop
and notification mechanisms and then Keystone specific
driver using those core functionalities. I read most of the
networking SOCs has some sort of hwqueues but not sure about
the its implementations. So just thought of bringing
it into the thread discussion to see if hwqueue core layer is
of any interest to other SOCs.

Regards,
Santosh



--
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/