[PATCH 7/7] ARM: S5PC210: I2C{3, 4, 5, 6, 7} device support

[Jassi Brar]

On Fri, Oct 1, 2010 at 2:28 PM, Marek Szyprowski
<m.szyprowski at samsung.com> wrote:
> Hello,
>
> On Friday, October 01, 2010 1:52 AM Jassi Brar wrote:
>
>> On Thu, Sep 30, 2010 at 8:43 PM, Marek Szyprowski
>> <m.szyprowski at samsung.com> wrote:
>> >> >> We are considering another way not to make additional new i2c dev files.
>> >> >> In my opinion, this patch looks not bad but we'd better make an effort to
>> >> >> avoid having the more similar file.
>> >> >
>> >> > Actually I also it's not good approach, but as there's no comment or
>> >> > discuss about this I send the patches.
>> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/022615.html
>> >> >
>> >> > If you have good method or approaches, I'm welcome.
>> >>
>> >> First, these are device definitions and gpio set callbacks and
>> >> shouldn't take much
>> >> of space. So, perhaps these all could be built upon single I2C support
>> >> selection.
>> >>
>> >> Second, if we must build them conditionally, how about having all in
>> >> one file with
>> >> each device's definition and callback surrounded by corresponding ifdef ?
>> >> That would alteast save us file-count.
>> >
>> > I don't think this is a good idea. IMHO we should now follow the current style
>> > of defining platform devices and the convert all at once. Mixing style always
>> > causes a lot of confusion.
>>
>> You mean to keep defining every controller in in a dedicated file ?
>
> Yes, what's the problem with many files? The i2c patches are ready, they match the
> way the other Samsung devices are defined in mainline kernel. It imho really important
> to have a common style across the same chip family to make the code easier to understand
> for someone new.
Talking about common style, dev-audio.c and dev-spi.c defines all
controllers in same file.
Also, the decision was made while Ben was here. Unfortunately he
didn't mandate all devices
do that.
Now, that we don't really have a 'common style', IMHO we'd better take
the better path if not the best.

>> If yes, my second option is still better, IMO.
>> If no, please explain what do you mean by current style.
>
> Well, postponing a merge of such simple code as i2c device definition is imho the
> worst solution. Especially because the new style / framework still has not been agreed
> yet, although a few proposals have been made a long time ago.
I don't think merging 7 files in 1 and adding ifdefs should take more
than a few hours including
testing. But of course, I can't assume the speed of the developer.

Thanks.