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

[Kyungmin Park]

On Fri, Oct 1, 2010 at 3:16 PM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> 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.

It does not mean defer until that time.
I don't like to say delay it until something is decide or made.
So first implement it as current style and then find the 'better' way
at that time.

>
>>> 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.
Right, but no need to make an effort for that since it's not much
different this patch.

So I suggest first apply current scheme and then find a better way to
all people are agree.

Thank you,
Kyungmin Park
>
> Thanks.
>