ARM: DT: binding fixup to align with vendor-prefixes.txt

PATCH Superseded Christian Daudt 4 participants 10 messages Aug 2, 2013 – Aug 10, 2013 1 message not in the archive

Subsystems (8)

Device tree bindings Arm (32-bit) Arm sub-architectures MMC, SD and SDIO +4 more subsystems

lore

Share & tools

lore

Christian Daudt

author

2013-08-02 22:27 UTC #0 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

[ 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 <[email protected]>

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +1 -1

index fb7b5cd..cf1b206 100644
@@ -6,4 +6,4 @@ bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
 
 Required root node property:
 
-compatible = "bcm,bcm11351";
+compatible = "brcm,bcm11351";

Documentation/devicetree/bindings/arm/bcm/kona-timer.txt renamed from Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt +2 -2

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
@@ -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 at 35006000 {
-		compatible = "bcm,kona-timer";
+		compatible = "brcm,kona-timer";
 		reg = <0x35006000 0x1000>;
 		interrupts = <0x0 7 0x4>;
 		clock-frequency = <32768>;

Documentation/devicetree/bindings/arm/l2cc.txt +1 -1

index 69ddf9f..f4aa37e 100644
@@ -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.

Documentation/devicetree/bindings/misc/smc.txt +2 -2

index 02b4281..8126821 100644
@@ -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 at 0x3404c000 {
-		compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
+		compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
 		reg = <0x3404c000 0x400>; //1 KiB in SRAM
 	};

Documentation/devicetree/bindings/mmc/kona-sdhci.txt renamed from Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt +2 -2

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
@@ -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 at 0x3f1a0000 {
-	compatible = "bcm,kona-sdhci";
+	compatible = "brcm,kona-sdhci";
 	reg = <0x3f1a0000 0x10000>;
 	interrupts = <0x0 74 0x4>;
 };

arch/arm/boot/dts/bcm11351-brt.dts +1 -1

index 67ec524..ed60a49 100644
@@ -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 */

arch/arm/boot/dts/bcm11351.dtsi +9 -9

index 6bac38f..60168ff 100644
@@ -18,7 +18,7 @@
 
 / {
 	model = "BCM11351 SoC";
-	compatible = "bcm,bcm11351";
+	compatible = "brcm,bcm11351";
 	interrupt-parent = <&gic>;
 
 	chosen {

@@ -35,12 +35,12 @@
 	};
 
 	smc at 0x3404c000 {
-		compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
+		compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
 		reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
 	};
 
 	uart at 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 at 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 at 0x3f180000 {
-		compatible = "bcm,kona-sdhci";
+		compatible = "brcm,kona-sdhci";
 		reg = <0x3f180000 0x10000>;
 		interrupts = <0x0 77 0x4>;
 		status = "disabled";
 	};
 
 	sdio1: sdio at 0x3f190000 {
-		compatible = "bcm,kona-sdhci";
+		compatible = "brcm,kona-sdhci";
 		reg = <0x3f190000 0x10000>;
 		interrupts = <0x0 76 0x4>;
 		status = "disabled";
 	};
 
 	sdio2: sdio at 0x3f1a0000 {
-		compatible = "bcm,kona-sdhci";
+		compatible = "brcm,kona-sdhci";
 		reg = <0x3f1a0000 0x10000>;
 		interrupts = <0x0 74 0x4>;
 		status = "disabled";
 	};
 
 	sdio3: sdio at 0x3f1b0000 {
-		compatible = "bcm,kona-sdhci";
+		compatible = "brcm,kona-sdhci";
 		reg = <0x3f1b0000 0x10000>;
 		interrupts = <0x0 73 0x4>;
 		status = "disabled";

arch/arm/mach-bcm/bcm_kona_smc.c +2 -1

index 56d9d19..bcc1c59 100644
@@ -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 */
 	{},
 };

arch/arm/mach-bcm/board_bcm.c +1 -1

index 2859932..6296fdf 100644
@@ -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,

arch/arm/mm/cache-l2x0.c +3 -1

index d70e0ab..0c19af6 100644
@@ -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},
 	{}
 };

drivers/clocksource/bcm_kona_timer.c +7 -1

index ba3d859..0d7d8c3 100644
@@ -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);

drivers/mmc/host/sdhci-bcm-kona.c +2 -1

index 87175f9..887482a 100644
@@ -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);

Signature · 1 line

1.7.10.4

Stephen Warren

2013-08-05 16:01 UTC #1 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 13 lines · Christian Daudt

[ 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

Quoted 2 lines

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.

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt

Quoted 4 lines

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +0 -0
index fb7b5cd..cf1b206 100644

I wonder if this patch should rename bindings/arm/bcm/ to bindings/arm/brcm/ too?

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt

Quoted 4 lines

Required root node property:
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +1 -1
-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?

Christian Daudt

author

2013-08-06 00:16 UTC #2 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 15 lines · Stephen Warren

Quoted 6 lines · Christian Daudt
[ 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).
Quoted 8 lines
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

Quoted 2 lines

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.

Quoted 6 lines

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
Quoted 4 lines
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +0 -0
index fb7b5cd..cf1b206 100644
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.

Quoted 11 lines

Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
Quoted 5 lines
Required root node property:
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +1 -1
-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

Stephen Warren

2013-08-06 04:21 UTC #3 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 26 lines · Christian Daudt

Quoted 17 lines · Stephen Warren
Quoted 15 lines · Christian Daudt
[ 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
Quoted 7 lines
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
Quoted 5 lines
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +0 -0
index fb7b5cd..cf1b206 100644
I wonder if this patch should rename bindings/arm/bcm/ to bindings/arm/brcm/ too?

Quoted 5 lines

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.

Quoted 8 lines

Quoted 7 lines
Quoted 3 lines
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?

Quoted 5 lines

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...

Christian Daudt

author

2013-08-06 21:40 UTC #4 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 7 lines · Stephen Warren

Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?

Quoted 8 lines

Quoted 5 lines
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

Stephen Warren

2013-08-09 16:11 UTC #5 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 14 lines · Christian Daudt

Quoted 13 lines · Stephen Warren
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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.

Quoted 5 lines

Quoted 3 lines
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).

Quoted 6 lines

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.

A message that is not in the archive (sent off-list or not yet received): CAA-5wcDOv+ru+4QiDbEZr-SP90xHSh1bq+ifdVxOsOnid1komg@mail.gmail.com

Christian Daudt

2013-08-09 18:49 UTC #7 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

[resend in plain-text]

Quoted 16 lines · Stephen Warren

Quoted 14 lines · Christian Daudt
Quoted 13 lines · Stephen Warren
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
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.

Quoted 5 lines

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

Stephen Warren

2013-08-09 19:14 UTC #8 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 35 lines · Christian Daudt

[resend in plain-text]
Quoted 16 lines · Stephen Warren
Quoted 14 lines · Christian Daudt
Quoted 13 lines · Stephen Warren
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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).

Quoted 7 lines

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.

Christian Daudt

author

2013-08-10 19:56 UTC #9 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

Quoted 41 lines · Stephen Warren

Quoted 33 lines · Christian Daudt
[resend in plain-text]
Quoted 15 lines · Stephen Warren
Quoted 14 lines · Christian Daudt
Quoted 13 lines · Stephen Warren
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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).
Quoted 7 lines
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...

Quoted 6 lines

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.

Christian Daudt

2013-08-08 22:56 UTC #10 lore raw

PATCH v2 1/1 ARM: DT: binding fixup to align with vendor-prefixes.txt

In reply to Christian Daudt

Quoted 13 lines · Christian Daudt

[ 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

Quoted 5 lines

Changes since v1:
- added driver match table entries for deprecated names
Signed-off-by Christian Daudt <[email protected]>

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