On Thu, Nov 19, 2009 at 7:13 AM, Ben Dooks <ben-linux@xxxxxxxxx> wrote: > On Wed, Nov 18, 2009 at 11:14:52PM +0900, jassi brar wrote: >> On Wed, Nov 18, 2009 at 10:33 PM, Marek Szyprowski >> <m.szyprowski@xxxxxxxxxxx> wrote: >> > From: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> >> > >> > Samsung S5PC110 SoCs have UART that differs a bit from the one known >> > from the previous Samsung SoCs. This patch adds support for this new >> > driver. >> > >> > Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> >> > Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > >> Not just about this c110 patch: I think this string comparison thing >> isn't very neat. >> I think we'd better be doing it by indexing into an array of clock >> names(which can be >> defined in some platform specific code). > > I don't mind changing to using a table, but the table is probably best > off here, closest to the UART drivers in question. well as per current implementation of drivers/serial/samsung.c we can't do much about it. Ideally, each SoC(if not yet, maybe in future) can have different number/names of possible source clocks for signal generation. Let us not depend upon even defaults(fclk, pclk etc) Let each platform code(SoC specific) define names of all possible source clocks and let the board init code pass on the potential source clocks by some bit-mask(or some other mechanism) while setting the platform data. The samsung.c could then simply go thru the array of source clock names and the bit-mask, in platform_data, while selecting the best possible source for the baud rate under consideration. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |