linux-kernel - Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power

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, 19 Apr 2012 18:02:44 +0200
From:	Jean Pihet <jean.pihet@...oldbits.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Trilok Soni <tsoni@...eaurora.org>,
	Kevin Hilman <khilman@...com>,
	"Cousson, Benoit" <b-cousson@...com>, gregkh@...uxfoundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-omap@...r.kernel.org,
	Jean Pihet <j-pihet@...com>
Subject: Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific
 macros in include/linux/power

Hi Arnd,

On Thu, Apr 19, 2012 at 3:54 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thursday 05 April 2012, Trilok Soni wrote:
>> >> Couple of suggestions:
>> >>
>> >> drivers/platform/omap/avs?
>> >> drivers/misc/omap/avs?
>> >>
>
> I would definitely prefer something under drivers/power,
> drivers/regulators or a new top-level directory under
> drivers.
Can I take this as an OK for drivers/power/avs as suggested?

>
>> >>> IIRC, David Brownell was referring to the rule of three for such case.
>> >>> Meaning that it worth having a generic fmwk when at least three
>> >>> different drivers are doing the same kind of things.
>> >
>> > Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-)
>> > More seriously, the OMAP code for SmartReflex is far from complete in
>> > mainline. There is a plan to provide the following features:
>> > - OMAP v1 IP,
>> > - OMAP v2 IP,
>> > - class 1.5,
>> > - class 3,
>> > - class 3.5,
>> > - and more support for the upcoming chipsets.
>>
>> I don't understand much of these versions right now, but hopefully after
>> going through all these docs. My only contention point is to not create
>> any directory into the drivers/power, unless it is generic fwk and then
>> build up "client" drivers on top of it. Meanwhile we could move this
>> driver into above options as I have suggested.
>
> I think creating the directory in the place where we want the files
> to stay in the long run is ok, if the plan is to add more drivers and
> make the base code more generic. We don't have to wait until it's too
> late and we absolutely need a framework ;-)
Agree! That is the intention to provide a fwk.

> The part I don't understand is how this relates to the regulator framework.
> Is there any overlap between the functionality provided by the
> smartreflex framework and the regulator framework? If so, would it be
> better to extend the existing framework so it can do smartreflex as well?
The link with regulator has indeed an impact on the target dir, this
is still unknown and discussed internally.

>
>        Arnd

Thanks,
Jean
--
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/