On 10/09/2012 04:16 PM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?
Rather than repeating things over and over in reviews, we should
document at least rules we can easily agree on and then add to it when
people get "creative." Also, I can't keep up with every single binding
review as is, and this could just add another level of complexity to the
review. A few off the top of my head and from the thread discussion:
- Headers must be self contained with no outside (i.e. libc, kernel,
etc.) header dependencies.
- No kernel kconfig option usage
- No gcc built-in define usage
- No unused items (i.e. externs, structs, etc.)
- No macro concatenation
- No macros for strings or property names
Do we further restrict things to say defines are only numbers? One could
start to define complex macros to build the nodes themselves. If each
platform does this slightly differently, it will become difficult to
review and maintain. Then we will be doing dts consolidation. The fact
that we have some fixed structure and each SOC is not free to do things
their own way makes things easier to maintain. You don't have that in
the kernel across platforms. For example, look how register defines and
static mappings or platform device creation are done. They are all
similar, but yet slightly different. That makes doing changes across
platforms more difficult.
> I imagine the most common usage will simply be a bunch of:
>
> #define TEGRA_GPIO_PB0 32
> #define TEGRA_GPIO_INT_LEVEL_LOW 8
>
> / {
> xxx {
> interrupts = <TEGRA_GPIO_PB0 TEGRA_GPIO_INT_LEVEL_LOW>;
>
> and similarly, simple math:
>
> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
>
These are all perfectly fine and sane use, but if we don't restrict
things then the next step is this:
#define PROP_SOMETHING(v) (something = <(v)>)
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
