Hi Pawel,
On Tue, Jun 18, 2013 at 10:29:42AM +0100, Pawel Moll wrote:
On Tue, 2013-06-18 at 10:09 +0100, Samuel Ortiz wrote:
Hi Pawell,
Double l in the wrong place ;-)
Apologies...
If you feel strongly about it, I'm ready to split it into mfd_cells and
move the gpio and leds code
On Wednesday 19 June 2013, Samuel Ortiz wrote:
2. Move the vexpress-sysreg platform management functions into misc
(unless we get any better place for it)
This is for Arnd and Greg to decide I suppose.
I think when vexpress-sysreg was created, we didn't have the syscon driver
yet, otherwise
On Wed, 2013-06-19 at 13:37 +0100, Arnd Bergmann wrote:
I think when vexpress-sysreg was created, we didn't have the syscon driver
yet, otherwise I think we should have used that, and put separate
drivers on top.
Not sure if it's too late for changing it to that now, given that
we already
On Wednesday 19 June 2013, Pawel Moll wrote:
That would end up eliminating the sysreg driver, aside from maybe
a one-line change to the syscon driver to allow it to probe the
right device.
... but sysreg does more than just that. In particular it provides a
pseudo-gpio controller (I
On Wed, 2013-06-19 at 16:03 +0100, Arnd Bergmann wrote:
On Wednesday 19 June 2013, Pawel Moll wrote:
... but sysreg does more than just that. In particular it provides a
pseudo-gpio controller (I don't think you want to hide this behind the
syscon) and it can act as a bridge to the
Hi Pawell,
On Thu, Jun 13, 2013 at 10:45:57AM +0100, Pawel Moll wrote:
On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote:
Now, about the driver itself, besides the really odd code design, the
static variables all over the place, the nasty init hacks and the
unneeded long function
Morning, Samuel,
On Tue, 2013-06-18 at 10:09 +0100, Samuel Ortiz wrote:
Hi Pawell,
Double l in the wrong place ;-)
If you feel strongly about it, I'm ready to split it into mfd_cells and
move the gpio and leds code into separate drivers, however I'm not
convinced that it's worth the
On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote:
Now, about the driver itself, besides the really odd code design, the
static variables all over the place, the nasty init hacks and the
unneeded long function names, someone should refresh my memory and explain
to me why is this guy under
Hi Lorenzo,
On Tue, Jun 11, 2013 at 10:05:45AM +0100, Lorenzo Pieralisi wrote:
Hi Samuel,
if nobody has objections I think this set is ready to get merged. As
Nico mentioned in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173541.html
since we would like to get it
Hi Samuel,
if nobody has objections I think this set is ready to get merged. As
Nico mentioned in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173541.html
since we would like to get it merged through the ARM SoC tree owing to
dependencies between this code and ARM power
10 matches
Mail list logo
