linux-kernel - Re: [PATCH 0/4] Voltage and current regulator framework

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, 15 Feb 2008 16:24:51 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH 0/4] Voltage and current regulator framework

On Fri, Feb 15, 2008 at 02:10:41PM +0000, Liam Girdwood wrote:
> This patch series provides a generic framework to allow device drivers
> to control voltage and current regulators on SoC based devices (e.g.
> phones, gps, media players).
> 
> The intention is to allow systems to dynamically control regulator
> output in order to save power and prolong battery life. This applies to
> both voltage regulators (where voltage output is controllable) and
> current sinks (where current output is controllable).
> 
> The framework is designed around SoC based devices but may also be
> relevant to non SoC devices. It's also been designed against two Power
> Management ICs (PMICs) currently on the market - namely the Freescale
> MC13783 and the Wolfson WM8350. However it is quite generic and should
> apply to all PMICs. 

General comments related to your patch submission - not to the code.

- Each patch should have a descriptive subject for the said patch.
  The headlines you use below looks fine for this.
- Tag each subject with name of the framework so it is obvious
  they belong to the same area.
  Note that the numbers will be lost when the patches are applied to git.
- Each patch should contain a description of what it contains
  and why it is needed.
  You seem to have it written but it is 'hidden' in the 0/4
  mail that will not go into git - so the info is hard to find when
  the patches goes in.
- Each patch should contain a diffstat before the actual patch so
  it is obvious what is touched by the patch.
- The patches should not break the build.
  As your patches did not include any Makefile / Kconfig fragments
  I gues you have no issues here.
  It is typical to split up patches like you have done and apply
  the MAkefile/Kconfig bits as the final patch to make sure the kernel
  continue to build.

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