| Message ID | 1375482479-15732-1-git-send-email-csd@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/02/2013 04:27 PM, Christian Daudt wrote: > [ this is a follow-up to this discussion: > http://archive.arm.linux.org.uk/lurker/message/20130730.230827.a1ceb12a.en.html ] > This patchset renames all uses of "bcm," name bindings to > "brcm," as they were done prior to knowing that brcm had > already been standardized as Broadcom vendor prefix > (in Documentation/devicetree/bindings/vendor-prefixes.txt). > This will not cause any churn on devices because none of > these bindings have made it into production yet. > Also rename the the following dt binding docs that had "bcm," > in their name for consistency: > - bcm,kona-sdhci.txt -> kona-sdhci.txt > - bcm,kona-timer.txt -> kona-timer.txt > Changes since v1: > - added driver match table entries for deprecated names That should usually go below the --- line so it doesn't make it into the final patch description. > diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt > index fb7b5cd..cf1b206 100644 > --- a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt > +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt I wonder if this patch should rename bindings/arm/bcm/ to bindings/arm/brcm/ too? > Required root node property: > > -compatible = "bcm,bcm11351"; > +compatible = "brcm,bcm11351"; In a patch of mine that deprecated a property, Mark wondered if it would make sense to mention the old deprecated DT content simply to document that it existed, so that old DTs would still make sense when checking the documentation. I wonder if the same argument applies to this patch?
On 13-08-05 09:01 AM, Stephen Warren wrote: > On 08/02/2013 04:27 PM, Christian Daudt wrote: >> [ this is a follow-up to this discussion: >> http://archive.arm.linux.org.uk/lurker/message/20130730.230827.a1ceb12a.en.html ] >> This patchset renames all uses of "bcm," name bindings to >> "brcm," as they were done prior to knowing that brcm had >> already been standardized as Broadcom vendor prefix >> (in Documentation/devicetree/bindings/vendor-prefixes.txt). >> This will not cause any churn on devices because none of >> these bindings have made it into production yet. >> Also rename the the following dt binding docs that had "bcm," >> in their name for consistency: >> - bcm,kona-sdhci.txt -> kona-sdhci.txt >> - bcm,kona-timer.txt -> kona-timer.txt >> Changes since v1: >> - added driver match table entries for deprecated names > That should usually go below the --- line so it doesn't make it into the > final patch description. Heh - I always thought that the intent was the contrary. I just looked through git history and most of my previous patches have made it into git with the changelog, and I see I'm not alone in having changelog history as part of git commit message. But if it is the more common way I'll be glad to change going forward. >> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >> index fb7b5cd..cf1b206 100644 >> --- a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >> +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt > I wonder if this patch should rename bindings/arm/bcm/ to > bindings/arm/brcm/ too? I'd rather keep it as-is - to me the vendor prefix is a DT concept only, and I'd rather not extend its tentacles into other parts of the kernel (and the other arm/ subtrees in there all show no attempt at dirname==vendor-prefix), but I'm ok with changing it to broadcom if you prefer. > >> Required root node property: >> >> -compatible = "bcm,bcm11351"; >> +compatible = "brcm,bcm11351"; > In a patch of mine that deprecated a property, Mark wondered if it would > make sense to mention the old deprecated DT content simply to document > that it existed, so that old DTs would still make sense when checking > the documentation. I wonder if the same argument applies to this patch? > > I would think the opposite. Deprecated items should be dropped from documentation. They are in the code (for a holdover period) but clearly marked as deprecated. No one should be extending the life of these, and adding documentation on it is a step in the wrong direction of making it easier for it to linger beyond what it should. thanks, csd
On 08/05/2013 06:16 PM, Christian Daudt wrote: > On 13-08-05 09:01 AM, Stephen Warren wrote: >> On 08/02/2013 04:27 PM, Christian Daudt wrote: >>> [ this is a follow-up to this discussion: >>> http://archive.arm.linux.org.uk/lurker/message/20130730.230827.a1ceb12a.en.html >>> ] >>> This patchset renames all uses of "bcm," name bindings to >>> "brcm," as they were done prior to knowing that brcm had >>> already been standardized as Broadcom vendor prefix >>> (in Documentation/devicetree/bindings/vendor-prefixes.txt). >>> This will not cause any churn on devices because none of >>> these bindings have made it into production yet. >>> Also rename the the following dt binding docs that had "bcm," >>> in their name for consistency: >>> - bcm,kona-sdhci.txt -> kona-sdhci.txt >>> - bcm,kona-timer.txt -> kona-timer.txt >>> Changes since v1: >>> - added driver match table entries for deprecated names >>> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >>> b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >>> index fb7b5cd..cf1b206 100644 >>> --- a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >>> +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt >> I wonder if this patch should rename bindings/arm/bcm/ to >> bindings/arm/brcm/ too? > > I'd rather keep it as-is - to me the vendor prefix is a DT concept only, > and I'd rather not extend its tentacles into other parts of the kernel > (and the other arm/ subtrees in there all show no attempt at > dirname==vendor-prefix), but I'm ok with changing it to broadcom if you > prefer. Well, except that Documentation/devicetree/bindings is more part of DT than the kernel, and there are active moves afoot to separate it out. But, I suppose it's not a big deal; we can fix it when that happens I suppose. >>> Required root node property: >>> -compatible = "bcm,bcm11351"; >>> +compatible = "brcm,bcm11351"; >> In a patch of mine that deprecated a property, Mark wondered if it would >> make sense to mention the old deprecated DT content simply to document >> that it existed, so that old DTs would still make sense when checking >> the documentation. I wonder if the same argument applies to this patch? > > I would think the opposite. Deprecated items should be dropped from > documentation. They are in the code (for a holdover period) but clearly > marked as deprecated. No one should be extending the life of these, and > adding documentation on it is a step in the wrong direction of making it > easier for it to linger beyond what it should. The deprecated stuff will have to be fully documented once the DT schema validation is in place...
On 13-08-05 09:21 PM, Stephen Warren wrote: >>>> Required root node property: >>>> -compatible = "bcm,bcm11351"; >>>> +compatible = "brcm,bcm11351"; >>> In a patch of mine that deprecated a property, Mark wondered if it would >>> make sense to mention the old deprecated DT content simply to document >>> that it existed, so that old DTs would still make sense when checking >>> the documentation. I wonder if the same argument applies to this patch? >> I would think the opposite. Deprecated items should be dropped from >> documentation. They are in the code (for a holdover period) but clearly >> marked as deprecated. No one should be extending the life of these, and >> adding documentation on it is a step in the wrong direction of making it >> easier for it to linger beyond what it should. > The deprecated stuff will have to be fully documented once the DT schema > validation is in place... > This deprecated code should be short lived, given that in actual fact it is actually quite unnecessary since no boards exist that rely on it. thanks, csd
On Fri, Aug 2, 2013 at 3:27 PM, Christian Daudt <csd@broadcom.com> wrote: > [ this is a follow-up to this discussion: > http://archive.arm.linux.org.uk/lurker/message/20130730.230827.a1ceb12a.en.html ] > This patchset renames all uses of "bcm," name bindings to > "brcm," as they were done prior to knowing that brcm had > already been standardized as Broadcom vendor prefix > (in Documentation/devicetree/bindings/vendor-prefixes.txt). > This will not cause any churn on devices because none of > these bindings have made it into production yet. > Also rename the the following dt binding docs that had "bcm," > in their name for consistency: > - bcm,kona-sdhci.txt -> kona-sdhci.txt > - bcm,kona-timer.txt -> kona-timer.txt > > Changes since v1: > - added driver match table entries for deprecated names > > Signed-off-by: Christian Daudt <csd@broadcom.com> > Hi, Any ACKs for this patch ? Alternatively, I can instead just patch vendor-prefix to add "bcm" as an additional Broadcom prefix and just stick to using bcm. I have told people internally to switch over to brcm and there are patches for 3.12 that will be migrating to brcm but I'd rather not have half bcm and half brcm and that will make things quite confusing. Thanks, csd
On 08/06/2013 03:40 PM, Christian Daudt wrote: > On 13-08-05 09:21 PM, Stephen Warren wrote: >>>>> Required root node property: >>>>> -compatible = "bcm,bcm11351"; >>>>> +compatible = "brcm,bcm11351"; >>>> In a patch of mine that deprecated a property, Mark wondered if it >>>> would >>>> make sense to mention the old deprecated DT content simply to document >>>> that it existed, so that old DTs would still make sense when checking >>>> the documentation. I wonder if the same argument applies to this patch? >>> I would think the opposite. Deprecated items should be dropped from >>> documentation. They are in the code (for a holdover period) but clearly >>> marked as deprecated. No one should be extending the life of these, and >>> adding documentation on it is a step in the wrong direction of making it >>> easier for it to linger beyond what it should. >> The deprecated stuff will have to be fully documented once the DT schema >> validation is in place... >> > This deprecated code should be short lived, given that in actual fact it > is actually quite unnecessary since no boards exist that rely on it. Is this patch for v3.11-rc* or v3.12? If it's for v3.12, then I see that v3.11 will be released with a variety of users of the old compatible values, hence the old compatible value is an ABI, and hence we should continue to support and document it (as deprecated). From v3.11-rc4: > arch/arm/boot/dts/bcm11351-brt.dts:20: compatible = "bcm,bcm11351-brt", "bcm,bcm11351"; > arch/arm/boot/dts/bcm11351.dtsi:21: compatible = "bcm,bcm11351"; > arch/arm/boot/dts/bcm11351.dtsi:38: compatible = "bcm,bcm11351-smc", "bcm,kona-smc"; > arch/arm/boot/dts/bcm11351.dtsi:43: compatible = "bcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; > arch/arm/boot/dts/bcm11351.dtsi:53: compatible = "bcm,bcm11351-a2-pl310-cache"; While I admit that some bindings perhaps should be considered unstable/experimental, I don't think that would apply here, since it's simply a rename of an existing sane property value. Other DT maintainers feel free to chime in if you disagree though. If the patch is applied for v3.11-rc*, I think it'd be fine since the old binding would never have been in a released kernel. But, I think it's far too late in the rc cycle to apply this kind of change.
[resend in plain-text] On 2013-08-09 9:11 AM, "Stephen Warren" <swarren@wwwdotorg.org> wrote: > > On 08/06/2013 03:40 PM, Christian Daudt wrote: > > On 13-08-05 09:21 PM, Stephen Warren wrote: > >>>>> Required root node property: > >>>>> -compatible = "bcm,bcm11351"; > >>>>> +compatible = "brcm,bcm11351"; > >>>> In a patch of mine that deprecated a property, Mark wondered if it > >>>> would > >>>> make sense to mention the old deprecated DT content simply to document > >>>> that it existed, so that old DTs would still make sense when checking > >>>> the documentation. I wonder if the same argument applies to this patch? > >>> I would think the opposite. Deprecated items should be dropped from > >>> documentation. They are in the code (for a holdover period) but clearly > >>> marked as deprecated. No one should be extending the life of these, and > >>> adding documentation on it is a step in the wrong direction of making it > >>> easier for it to linger beyond what it should. > >> The deprecated stuff will have to be fully documented once the DT schema > >> validation is in place... > >> > > This deprecated code should be short lived, given that in actual fact it > > is actually quite unnecessary since no boards exist that rely on it. > > Is this patch for v3.11-rc* or v3.12? > I'm guessing it's too late for 3.11 at this point. > If it's for v3.12, then I see that v3.11 will be released with a variety > of users of the old compatible values, hence the old compatible value is > an ABI, and hence we should continue to support and document it (as > deprecated). > I think whether bindings automatically become ABI at kernel release is still an open topic. And as I mentioned in this case we are the only ones affected and we don't have a problem with the change. But if that's the case then there's no point to this patch. I'll just add bcm to vendor-prefixes and be done with it. I'm okay either way. Just need to know what direction to take asap so I can stop telling devs to keep changing back and forth... Thanks, csd
On 08/09/2013 12:49 PM, Christian Daudt wrote: > [resend in plain-text] > > > On 2013-08-09 9:11 AM, "Stephen Warren" <swarren@wwwdotorg.org> wrote: >> >> On 08/06/2013 03:40 PM, Christian Daudt wrote: >>> On 13-08-05 09:21 PM, Stephen Warren wrote: >>>>>>> Required root node property: >>>>>>> -compatible = "bcm,bcm11351"; >>>>>>> +compatible = "brcm,bcm11351"; >>>>>> In a patch of mine that deprecated a property, Mark wondered if it >>>>>> would >>>>>> make sense to mention the old deprecated DT content simply to document >>>>>> that it existed, so that old DTs would still make sense when checking >>>>>> the documentation. I wonder if the same argument applies to this patch? >>>>> I would think the opposite. Deprecated items should be dropped from >>>>> documentation. They are in the code (for a holdover period) but clearly >>>>> marked as deprecated. No one should be extending the life of these, and >>>>> adding documentation on it is a step in the wrong direction of making it >>>>> easier for it to linger beyond what it should. >>>> The deprecated stuff will have to be fully documented once the DT schema >>>> validation is in place... >>>> >>> This deprecated code should be short lived, given that in actual fact it >>> is actually quite unnecessary since no boards exist that rely on it. >> >> Is this patch for v3.11-rc* or v3.12? >> > I'm guessing it's too late for 3.11 at this point. > >> If it's for v3.12, then I see that v3.11 will be released with a variety >> of users of the old compatible values, hence the old compatible value is >> an ABI, and hence we should continue to support and document it (as >> deprecated). >> > I think whether bindings automatically become ABI at kernel release is > still an open topic. And as I mentioned in this case we are the only > ones affected and we don't have a problem with the change. > But if that's the case then there's no point to this patch. I'll just > add bcm to vendor-prefixes and be done with it. > I'm okay either way. Just need to know what direction to take asap so > I can stop telling devs to keep changing back and forth... I think it's fine to fix the issue; we should just do so in the trivial way that maintains backwards-compatibility, and allows people who compare the binding document to old DTs to understand how the correlate to each-other.
On 13-08-09 12:14 PM, Stephen Warren wrote: > On 08/09/2013 12:49 PM, Christian Daudt wrote: >> [resend in plain-text] >> >> >> On 2013-08-09 9:11 AM, "Stephen Warren" <swarren@wwwdotorg.org> wrote: >>> On 08/06/2013 03:40 PM, Christian Daudt wrote: >>>> On 13-08-05 09:21 PM, Stephen Warren wrote: >>>>>>>> Required root node property: >>>>>>>> -compatible = "bcm,bcm11351"; >>>>>>>> +compatible = "brcm,bcm11351"; >>>>>>> In a patch of mine that deprecated a property, Mark wondered if it >>>>>>> would >>>>>>> make sense to mention the old deprecated DT content simply to document >>>>>>> that it existed, so that old DTs would still make sense when checking >>>>>>> the documentation. I wonder if the same argument applies to this patch? >>>>>> I would think the opposite. Deprecated items should be dropped from >>>>>> documentation. They are in the code (for a holdover period) but clearly >>>>>> marked as deprecated. No one should be extending the life of these, and >>>>>> adding documentation on it is a step in the wrong direction of making it >>>>>> easier for it to linger beyond what it should. >>>>> The deprecated stuff will have to be fully documented once the DT schema >>>>> validation is in place... >>>>> >>>> This deprecated code should be short lived, given that in actual fact it >>>> is actually quite unnecessary since no boards exist that rely on it. >>> Is this patch for v3.11-rc* or v3.12? >>> >> I'm guessing it's too late for 3.11 at this point. >> >>> If it's for v3.12, then I see that v3.11 will be released with a variety >>> of users of the old compatible values, hence the old compatible value is >>> an ABI, and hence we should continue to support and document it (as >>> deprecated). >>> >> I think whether bindings automatically become ABI at kernel release is >> still an open topic. And as I mentioned in this case we are the only >> ones affected and we don't have a problem with the change. >> But if that's the case then there's no point to this patch. I'll just >> add bcm to vendor-prefixes and be done with it. >> I'm okay either way. Just need to know what direction to take asap so >> I can stop telling devs to keep changing back and forth... > I think it's fine to fix the issue; we should just do so in the trivial > way that maintains backwards-compatibility, and allows people who > compare the binding document to old DTs to understand how the correlate > to each-other. > > Ok, I've added indication that bcm, existed and is deprecated to the bindings documentation and resent the patch. Thanks, csd PS: I will be mostly away from internet for next 8 days so responses will likely only happen after then.
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt index fb7b5cd..cf1b206 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt @@ -6,4 +6,4 @@ bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties: Required root node property: -compatible = "bcm,bcm11351"; +compatible = "brcm,bcm11351"; diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt similarity index 87% rename from Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt rename to Documentation/devicetree/bindings/arm/bcm/kona-timer.txt index 59fa6e6..a716952 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt +++ b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt @@ -4,14 +4,14 @@ This timer is used in the following Broadcom SoCs: BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 Required properties: -- compatible : "bcm,kona-timer" +- compatible : "brcm,kona-timer" - reg : Register range for the timer - interrupts : interrupt for the timer - clock-frequency: frequency that the clock operates Example: timer@35006000 { - compatible = "bcm,kona-timer"; + compatible = "brcm,kona-timer"; reg = <0x35006000 0x1000>; interrupts = <0x0 7 0x4>; clock-frequency = <32768>; diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index 69ddf9f..f4aa37e 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -16,7 +16,7 @@ Required properties: performs the same operation). "marvell,"aurora-outer-cache: Marvell Controller designed to be compatible with the ARM one with outer cache mode. - "bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an + "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an offset needs to be added to the address before passing down to the L2 cache controller - cache-unified : Specifies the cache is a unified cache. diff --git a/Documentation/devicetree/bindings/misc/smc.txt b/Documentation/devicetree/bindings/misc/smc.txt index 02b4281..8126821 100644 --- a/Documentation/devicetree/bindings/misc/smc.txt +++ b/Documentation/devicetree/bindings/misc/smc.txt @@ -4,11 +4,11 @@ This binding defines the location of the bounce buffer used for non-secure to secure communications. Required properties: -- compatible : "bcm,kona-smc" +- compatible : "brcm,kona-smc" - reg : Location and size of bounce buffer Example: smc@0x3404c000 { - compatible = "bcm,bcm11351-smc", "bcm,kona-smc"; + compatible = "brcm,bcm11351-smc", "brcm,kona-smc"; reg = <0x3404c000 0x400>; //1 KiB in SRAM }; diff --git a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt similarity index 77% rename from Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt rename to Documentation/devicetree/bindings/mmc/kona-sdhci.txt index 094ae01..199d97a 100644 --- a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt @@ -4,12 +4,12 @@ This file documents differences between the core properties in mmc.txt and the properties present in the bcm281xx SDHCI Required properties: -- compatible : Should be "bcm,kona-sdhci" +- compatible : Should be "brcm,kona-sdhci" Example: sdio2: sdio@0x3f1a0000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f1a0000 0x10000>; interrupts = <0x0 74 0x4>; }; diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts index 67ec524..ed60a49 100644 --- a/arch/arm/boot/dts/bcm11351-brt.dts +++ b/arch/arm/boot/dts/bcm11351-brt.dts @@ -17,7 +17,7 @@ / { model = "BCM11351 BRT board"; - compatible = "bcm,bcm11351-brt", "bcm,bcm11351"; + compatible = "brcm,bcm11351-brt", "brcm,bcm11351"; memory { reg = <0x80000000 0x40000000>; /* 1 GB */ diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi index 6bac38f..60168ff 100644 --- a/arch/arm/boot/dts/bcm11351.dtsi +++ b/arch/arm/boot/dts/bcm11351.dtsi @@ -18,7 +18,7 @@ / { model = "BCM11351 SoC"; - compatible = "bcm,bcm11351"; + compatible = "brcm,bcm11351"; interrupt-parent = <&gic>; chosen { @@ -35,12 +35,12 @@ }; smc@0x3404c000 { - compatible = "bcm,bcm11351-smc", "bcm,kona-smc"; + compatible = "brcm,bcm11351-smc", "brcm,kona-smc"; reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */ }; uart@3e000000 { - compatible = "bcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; + compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; status = "disabled"; reg = <0x3e000000 0x1000>; clock-frequency = <13000000>; @@ -50,42 +50,42 @@ }; L2: l2-cache { - compatible = "bcm,bcm11351-a2-pl310-cache"; + compatible = "brcm,bcm11351-a2-pl310-cache"; reg = <0x3ff20000 0x1000>; cache-unified; cache-level = <2>; }; timer@35006000 { - compatible = "bcm,kona-timer"; + compatible = "brcm,kona-timer"; reg = <0x35006000 0x1000>; interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; clock-frequency = <32768>; }; sdio0: sdio@0x3f180000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f180000 0x10000>; interrupts = <0x0 77 0x4>; status = "disabled"; }; sdio1: sdio@0x3f190000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f190000 0x10000>; interrupts = <0x0 76 0x4>; status = "disabled"; }; sdio2: sdio@0x3f1a0000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f1a0000 0x10000>; interrupts = <0x0 74 0x4>; status = "disabled"; }; sdio3: sdio@0x3f1b0000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f1b0000 0x10000>; interrupts = <0x0 73 0x4>; status = "disabled"; diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c index 56d9d19..bcc1c59 100644 --- a/arch/arm/mach-bcm/bcm_kona_smc.c +++ b/arch/arm/mach-bcm/bcm_kona_smc.c @@ -36,7 +36,8 @@ struct bcm_kona_smc_data { }; static const struct of_device_id bcm_kona_smc_ids[] __initconst = { - {.compatible = "bcm,kona-smc"}, + {.compatible = "brcm,kona-smc"}, + {.compatible = "bcm,kona-smc"}, /* deprecated name */ {}, }; diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c index 2859932..6296fdf 100644 --- a/arch/arm/mach-bcm/board_bcm.c +++ b/arch/arm/mach-bcm/board_bcm.c @@ -50,7 +50,7 @@ static void __init board_init(void) kona_l2_cache_init(); } -static const char * const bcm11351_dt_compat[] = { "bcm,bcm11351", NULL, }; +static const char * const bcm11351_dt_compat[] = { "brcm,bcm11351", NULL, }; DT_MACHINE_START(BCM11351_DT, "Broadcom Application Processor") .init_time = clocksource_of_init, diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index d70e0ab..0c19af6 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -929,7 +929,9 @@ static const struct of_device_id l2x0_ids[] __initconst = { .data = (void *)&aurora_no_outer_data}, { .compatible = "marvell,aurora-outer-cache", .data = (void *)&aurora_with_outer_data}, - { .compatible = "bcm,bcm11351-a2-pl310-cache", + { .compatible = "brcm,bcm11351-a2-pl310-cache", + .data = (void *)&bcm_l2x0_data}, + { .compatible = "bcm,bcm11351-a2-pl310-cache", /* deprecated name */ .data = (void *)&bcm_l2x0_data}, {} }; diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c index ba3d859..0d7d8c3 100644 --- a/drivers/clocksource/bcm_kona_timer.c +++ b/drivers/clocksource/bcm_kona_timer.c @@ -99,7 +99,8 @@ kona_timer_get_counter(void *timer_base, uint32_t *msw, uint32_t *lsw) } static const struct of_device_id bcm_timer_ids[] __initconst = { - {.compatible = "bcm,kona-timer"}, + {.compatible = "brcm,kona-timer"}, + {.compatible = "bcm,kona-timer"}, /* deprecated name */ {}, }; @@ -201,4 +202,9 @@ static void __init kona_timer_init(struct device_node *node) kona_timer_set_next_event((arch_timer_rate / HZ), NULL); } +CLOCKSOURCE_OF_DECLARE(brcm_kona, "brcm,kona-timer", kona_timer_init); +/* + * bcm,kona-timer is deprecated by brcm,kona-timer + * being kept here for driver compatibility + */ CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init); diff --git a/drivers/mmc/host/sdhci-bcm-kona.c b/drivers/mmc/host/sdhci-bcm-kona.c index 87175f9..887482a 100644 --- a/drivers/mmc/host/sdhci-bcm-kona.c +++ b/drivers/mmc/host/sdhci-bcm-kona.c @@ -222,7 +222,8 @@ static struct sdhci_pltfm_data sdhci_pltfm_data_kona = { }; static const struct of_device_id sdhci_bcm_kona_of_match[] __initdata = { - { .compatible = "bcm,kona-sdhci"}, + { .compatible = "brcm,kona-sdhci"}, + { .compatible = "bcm,kona-sdhci"}, /* deprecated name */ {} }; MODULE_DEVICE_TABLE(of, sdhci_bcm_kona_of_match);
[ this is a follow-up to this discussion: http://archive.arm.linux.org.uk/lurker/message/20130730.230827.a1ceb12a.en.html ] This patchset renames all uses of "bcm," name bindings to "brcm," as they were done prior to knowing that brcm had already been standardized as Broadcom vendor prefix (in Documentation/devicetree/bindings/vendor-prefixes.txt). This will not cause any churn on devices because none of these bindings have made it into production yet. Also rename the the following dt binding docs that had "bcm," in their name for consistency: - bcm,kona-sdhci.txt -> kona-sdhci.txt - bcm,kona-timer.txt -> kona-timer.txt Changes since v1: - added driver match table entries for deprecated names Signed-off-by: Christian Daudt <csd@broadcom.com>