On Thu, Feb 20, 2014 at 10:59:04AM +0000, Jonas Gorski wrote:
> On Thu, Feb 20, 2014 at 2:29 AM, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote:
> > 2014-02-19 16:00 GMT-08:00 Jonas Gorski <jogo@xxxxxxxxxxx>:
> >> On Thu, Feb 20, 2014 at 12:22 AM, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote:
> >>> @@ -857,6 +861,12 @@ static int bcm_uart_remove(struct platform_device *pdev)
> >>> return 0;
> >>> }
> >>>
> >>> +static const struct of_device_id bcm63xx_of_match[] = {
> >>> + { .compatible = "brcm,bcm63xx-uart" },
> >>
> >> From my understanding, this should be "brcm,bcm6345-uart", because
> >> this kind of uart appeared first on bcm6345 (well, maybe bcm6335, no
> >> idea which one of these two was first, but the latter was never
> >> supported in mainline anyway).
> >
> > That's right, in fact, I think it might be desirable to handle both
> > compatible string, just as a hint that it is compatible with the
> > entire bcm63xx family. Would that work for you?
>
> I think using a "generic" compatible string is rather frowned upon
> (what do you do if there is eventually a bcm63xx chip with an
> incompatible uart?), but I'm no device tree expert.
As long as each compatible string entry describes something that has a
compatible programming model, there's no problem. The new UART wouldn't
be described with a string it's not compatible with.
I think "brcm,bcm6345-uart," is a nicer name to use for the moment than
"brcm,bcm63xx-uart" as it clearly describes a specific UART and is less
likely to be problematic in future if an incompatible UART appears.
Additionally, each compatible UART can have a more specific compatible
string entry that allows them to be more uniquely identified in case
they need to be handled specially in future. e.g:
compatible = "brcm,bcm634x-uart", "brcm,bcm6345-uart";
Then if a bcm634y comes out with a UART that's not compatible with the
bcm6345 UART, it just needs:
compatible = "brcm,bcm634y-uart";
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
