>> << The Xilinx approach of overwriting the source tree just feels wrong,
>> and
>> no one seems to want to do it that way.>>
>>
>> I am in the group that has control over how this is done. What would you
>> propose be done different? Keep in mind that we are trying to support a
>> process where someone builds a hardware design and the later changes it
>> with new peripherals or perhaps makes minor tweaks. We want to make the
>> updating of the Linux kernel to reflect these hardware changes easy for
>> people.
>
> A noble goal, and clearly the right thing to do from a user-success point
> of view, but do the hardware peripherals (i.e. the IP cores) change that
> much?
Driver-per-version (i.e. separate drivers for 'xilinx_emac_1_00_b', 1_00_c,
etc.) is the most obvious but unlikely to be accepted, and it would lead to
lots of duplicated code. How about having a single driver that supports
all versions of xilinx_emac, and adding the specific IP version info in the
kernel config? So we would have, for example, CONFIG_XILINX_ENET_1_00_C,
or whatever, in addition to or in place of CONFIG_XILINX_ENET. The neces-
sary adjustments would generally be made via conditionally compiled code in
the driver source, or in the driver's Makefile when the version differences
are larger in scope.
>From what I've seen this is pretty consistent with The Kernel Way... And
it'd force the kernel builder to be aware of what IP version(s) are in
their hardware.
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
