Message-ID: <20081013172852.393584be@hskinnemo-gx745.norway.atmel.com>
Date:	Mon, 13 Oct 2008 17:28:52 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Anders Blomdell <anders.blomdell@...trol.lth.se>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Make ATNGW100 serial ports configurable

Anders Blomdell <anders.blomdell@...trol.lth.se> wrote:
> Haavard Skinnemoen wrote:
> > Really? I personally think out-of-tree modules is a real hassle causing
> > extra work each time I need to update the kernel, whether it's on my
> > embedded target or my PC.
> Depends on if it's you or somebody else (who doesn't care about your code) that
> rebuilds the kernel. Since I plan to use some tens of atngw100's eventually,
> with at least 3 different expansions boards, a solution that doesn't need 3
> different kernels (i.e. loadable modules) is much preferred to a Kconfig (I know
> I started out with this, but one does change opinion :-) occasionally) or
> in-tree init code.

So what you really need is device tree support.

I suppose modules would do the trick in your case, but it sounds like a
very specialized setup, and I don't feel too good about bloating the
kernel for everyone else just to support this kind of thing.

Device tree support would probably make the kernel bigger too, but I
think that would be mostly __init code, so it doesn't matter as much.

> > Have a look at the EVKLCD10x code that was just applied for an example
> > of how to add support for an expansion board:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/hskinnemoen/avr32-2.6.git;a=commitdiff;h=a3bee42f058c2f9fe281df942eff397924630a12
> > 
> > Most of it is LCD-related, so if you only need to add a USART, you'll
> > only need a fraction of the code.
> I see a distinct clutter in setup.c (#ifndef CONFIG_BOARD_ATNGW100_EVKLCD10X)
> :-) (it clearly shows the need for conflict resolution, though)

Yes, but it's hard to avoid that, it's confined to the support code
for that particular expansion board, and the clutter is there to
support actual variations of the board. It could have been moved into
separate files, but that would have led to more duplication.

It's all about finding the right balance, really.

I didn't quite understand what you mean by "conflict resolution".

> > Also note that it shows a huge problem with the Kconfig approach: Most
> > devices need additional board-specific data. And even though the USART
> > doesn't currently need any of that, it may in the future when we add
> > support for RS485, hardware flow control, etc. How will you deal with
> > that through Kconfig?
> Honestly, I don't know :-(, but it would be nice to be able to select all these
> options wihout having to write the code myself :-)

But is wading through several dozen config options really that much
easier than writing ten lines of code?

> Question is if there is any way to come up with a solution that makes it
> possible to select software modules for what is present on a specific expansion
> board, my naive thought was that it should be selected by Kconfig (and in that
> vein, my 5 cents is that video for ngw100/stk100x should be selected as
> TCG057QVLAD/PH320240T/LTV350QV, and not as a by-product of selecting a specific
> expansion board, this way it would be easier to add video to a custom expansion
> board withou dragging in unrelated functions like USARTs). Perhaps it is
> possible to solve my problems as well as the stk100x clutter if it is done right?

Possibly. But adding options for the USARTs is only solving a tiny part
of the problem, and I'm worried that solving the rest in the same
manner is going to end up as a spectacular mess. If you can prove me
wrong, I'm all for it.

Haavard
--
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/

Powered by blists - more mailing lists