Re: [PATCH] mfd: viperboard driver added
From: Lars Poeschel
Date: Mon Sep 24 2012 - 12:46:14 EST
Hi Samuel,
Thanks for your review.
Am 19.09.2012 17:29, schrieb Samuel Ortiz:
Hi Lars,
On Mon, Aug 27, 2012 at 03:08:38PM +0200, larsi@xxxxxxxxxxxxxxxxx
wrote:
From: Lars Poeschel <poeschel@xxxxxxxxxxx>
First version of the driver for Nano River Tech's
viperboard added.
It supports i2c, adc, gpio a and gpio b. spi and pwm on
the first gpio a pins is not supported yet.
Signed-off-by: Lars Poeschel <poeschel@xxxxxxxxxxx>
---
drivers/mfd/Kconfig | 17 +
drivers/mfd/Makefile | 1 +
drivers/mfd/viperboard.c | 1084
++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 1102 insertions(+)
create mode 100644 drivers/mfd/viperboard.c
So the MFD driver contains a GPIO one, and an i2c bus driver.
You should really split this code into at least 3 pieces: 1 for the
GPIO
(drivers/gpio), another one for your i2c bus algorithm
(drivers/i2c/busses)
and a last one for the actual MFD driver. Your Kconfig entries will
define the
dependencies between them.
Then you can define your SoC subdevices as MFD cells and use the MFD
APIs to
add them as platform devices.
I am not really sure, but maybe you got mislead by the term
"viperboard". It is NOT an embedded evaluation board or starterkit. It
is an USB to SPI, I2C, GPIO and ADC interface. You can get a quick
overview here: http://nanorivertech.com/viperboard.html
The I2C, GPIO or ADC parts of this driver will never be part of a
"platform device" in terms of the linux kernel definining the
configuration of different embedded evaluation boards (a platform).
Do you still think I should split up the different parts into their
respective subsystems in the kernel and have one "core" combining those
parts in MFD ?
If so, I will do this. As there would be multiple different maintainers
involved, against which branch has my patch to be ?
Should I simply CC the patch to all involved maintainers ?
Regards,
Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/