linux-kernel - Re: [PATCH] mfd: viperboard driver added

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:	Mon, 24 Sep 2012 18:46:19 +0200
From:	Lars Poeschel <larsi@....tu-dresden.de>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	<linux-kernel@...r.kernel.org>,
	Lars Poeschel <poeschel@...onage.de>
Subject: Re: [PATCH] mfd: viperboard driver added

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@....tu-dresden.de 
> wrote:
>> From: Lars Poeschel <poeschel@...onage.de>
>>
>> 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@...onage.de>
>> ---
>>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/