[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5182BFC6.3070709@gmail.com>
Date: Thu, 02 May 2013 21:34:30 +0200
From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Andrew Lunn <andrew@...n.ch>,
Russell King <linux@....linux.org.uk>,
Jason Cooper <jason@...edaemon.net>,
Jean-Francois Moine <moinejf@...e.fr>,
devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Rob Herring <rob.herring@...xeda.com>,
Grant Likely <grant.likely@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] irqchip: add support for Marvell Orion SoCs
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
> On Thursday 02 May 2013, Jason Gunthorpe wrote:
>>> +static struct of_device_id orion_irq_dt_ids[] __initconst = {
>>> + { .compatible = "marvell,orion-mpic", .data = orion_of_init },
>>> + { }
>>
>> Is there a strong reason to change the compatible string? Looks to me
>> like either the new driver or the old driver will bind depending on
>> what is in the machine description. No need for a new string?
>>
>
> The compatible string should change if the binding changes in an
> incomptible way, and we should try not to change it unless it's
> fundamentally flawed.
Well, there is no _fundamental_ change in the binding syntax as it
is only reg, interrupts, and clocks. But there is a semantic change
in reg properties, as current orion irq controller wants the mask
registers (0x04,0x08) only while this also needs cause register
(0x00).
Nothing that couldn't be handled while moving Orion arch to irqchip
but if there are no further objections, I'd like to stick with the new
compatible string - also having orion-spic in mind.
Sebastian
--
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