Date: Fri, 15 Feb 2008 16:24:51 +0100
From: Sam Ravnborg <sam@ravnborg.org>
To: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
       linux-kernel <linux-kernel@vger.kernel.org>,
       linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 0/4] Voltage and current regulator framework
Message-ID: <20080215152451.GL1178@uranus.ravnborg.org>
References: <1203084641.3466.210.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1203084641.3466.210.camel@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2080
Lines: 43

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/