lkml.org 
[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART
On Wednesday 07 November 2012 07:46 PM, Arnd Bergmann wrote:
> On Wednesday 07 November 2012, Vineet Gupta wrote:
>> +static struct platform_device arc_uart##n##_dev = { \
>> + .name = "arc-uart", \
>> + .id = n, \
>> + .num_resources = ARRAY_SIZE(arc_uart##n##_res), \
>> + .resource = arc_uart##n##_res, \
>> + .dev = { \
>> + .platform_data = &arc_uart_info, \
>> + }, \
>> +}
>> +
>> +ARC_UART_DEV(0);
>> +#if CONFIG_SERIAL_ARC_NR_PORTS > 1
>> +ARC_UART_DEV(1);
>> +#endif
>> +
>> +static struct platform_device *fpga_early_devs[] __initdata = {
>> +#if defined(CONFIG_SERIAL_ARC_CONSOLE)
>> + &arc_uart0_dev,
>> +#endif
>> +};
>
> statically defining platform devices like this is considered very
> bad style, especially since it prevents you from doing proper
> boot-time configuration. Please get the available devices from
> the boot loader. Normally this is done using a flattened device
> tree blob that gets passed, unless you can probe the hardware
> directly.
>
> Arnd
>

So my strategy for v2 series (based off 3.8-rcx) is to introduce devicetree,
multi-platform-image support (and other key fixes such as syscall restart issues)
as slap-on patches on top of old code. This is not to avoid any chop-n-dice of
fixing patches (I've done that in plenty between v1 and v2). Its just that, in
absence of revision history for ARC port (in upstream later on) - it helps capture
the evolution of some key features and also for the community it serves as a live
documentation of bad designs and how they can be fixed.

Is that a reasonable approach for new port which is non-bisectable anyways ?

Thx,
-Vineet


\
 
 \ /
  Last update: 2013-01-17 09:01    [W:0.768 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site