Hi folks,
Just a quick fix for the Apple mailbox compatible. Similar to [1], we
intend to use SoC-specific compatibles only for potential quirks, and
rely on a generic compatible to allow for forward-compatibility as long
as things don't break.
Since this isn't instantiated in any upstream DT yet, I think we can
afford the compatibility break now.
This also goes ahead and adds the compatible for the new t600x SoCs.
[1] https://lore.kernel.org/linux-arm-kernel/[email protected]/
Hector Martin (2):
dt-bindings: mailbox: apple,mailbox: Add generic and t6000 compatibles
mailbox: apple: Bind to generic compatibles
.../devicetree/bindings/mailbox/apple,mailbox.yaml | 12 +++++++++---
drivers/mailbox/apple-mailbox.c | 4 ++--
2 files changed, 11 insertions(+), 5 deletions(-)
--
2.33.0
Much as we've done with other blocks, let's introduce generic
compatibles so drivers can bind to those and still work with future
SoCs, as long as the hardware remains the same. Also go ahead and add
compatibles for the new t600x SoCs (we group those as t6000).
Note that no DTs instantiate devices with this binding yet.
Signed-off-by: Hector Martin <[email protected]>
---
.../devicetree/bindings/mailbox/apple,mailbox.yaml | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
index 2c1704b34e7a..58007c789671 100644
--- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
@@ -27,14 +27,20 @@ properties:
for example for the display controller, the system management
controller and the NVMe coprocessor.
items:
- - const: apple,t8103-asc-mailbox
+ - enum:
+ - apple,t8103-asc-mailbox
+ - apple,t6000-asc-mailbox
+ - const: apple,asc-mailbox
- description:
M3 mailboxes are an older variant with a slightly different MMIO
interface still found on the M1. It is used for the Thunderbolt
co-processors.
items:
- - const: apple,t8103-m3-mailbox
+ - enum:
+ - apple,t8103-m3-mailbox
+ - apple,t6000-m3-mailbox
+ - const: apple,m3-mailbox
reg:
maxItems: 1
@@ -68,7 +74,7 @@ additionalProperties: false
examples:
- |
mailbox@77408000 {
- compatible = "apple,t8103-asc-mailbox";
+ compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox";
reg = <0x77408000 0x4000>;
interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
interrupt-names = "send-empty", "send-not-empty",
--
2.33.0
As with other blocks, we intend to have drivers bind to generic
compatibles as long as there are no SoC-specific quirks. This allows
forward-compatibility with future SoCs.
No upstream DTs instantiate this yet, so it's still safe to make this
breaking change.
Signed-off-by: Hector Martin <[email protected]>
---
drivers/mailbox/apple-mailbox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/apple-mailbox.c b/drivers/mailbox/apple-mailbox.c
index 72942002a54a..f9704332cda3 100644
--- a/drivers/mailbox/apple-mailbox.c
+++ b/drivers/mailbox/apple-mailbox.c
@@ -364,8 +364,8 @@ static const struct apple_mbox_hw apple_mbox_m3_hw = {
};
static const struct of_device_id apple_mbox_of_match[] = {
- { .compatible = "apple,t8103-asc-mailbox", .data = &apple_mbox_asc_hw },
- { .compatible = "apple,t8103-m3-mailbox", .data = &apple_mbox_m3_hw },
+ { .compatible = "apple,asc-mailbox", .data = &apple_mbox_asc_hw },
+ { .compatible = "apple,m3-mailbox", .data = &apple_mbox_m3_hw },
{}
};
MODULE_DEVICE_TABLE(of, apple_mbox_of_match);
--
2.33.0
> From: Hector Martin <[email protected]>
> Date: Thu, 9 Dec 2021 14:50:48 +0900
>
> Much as we've done with other blocks, let's introduce generic
> compatibles so drivers can bind to those and still work with future
> SoCs, as long as the hardware remains the same. Also go ahead and add
> compatibles for the new t600x SoCs (we group those as t6000).
>
> Note that no DTs instantiate devices with this binding yet.
I think this makes sense. There is no OpenBSD driver for this yet and
my U-Boot driver has not been submitted upstream yet. So I think
there are no real backwards compatibility issues.
Reviewed-by: Mark Kettenis <[email protected]>
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../devicetree/bindings/mailbox/apple,mailbox.yaml | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> index 2c1704b34e7a..58007c789671 100644
> --- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
> @@ -27,14 +27,20 @@ properties:
> for example for the display controller, the system management
> controller and the NVMe coprocessor.
> items:
> - - const: apple,t8103-asc-mailbox
> + - enum:
> + - apple,t8103-asc-mailbox
> + - apple,t6000-asc-mailbox
> + - const: apple,asc-mailbox
>
> - description:
> M3 mailboxes are an older variant with a slightly different MMIO
> interface still found on the M1. It is used for the Thunderbolt
> co-processors.
> items:
> - - const: apple,t8103-m3-mailbox
> + - enum:
> + - apple,t8103-m3-mailbox
> + - apple,t6000-m3-mailbox
> + - const: apple,m3-mailbox
>
> reg:
> maxItems: 1
> @@ -68,7 +74,7 @@ additionalProperties: false
> examples:
> - |
> mailbox@77408000 {
> - compatible = "apple,t8103-asc-mailbox";
> + compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox";
> reg = <0x77408000 0x4000>;
> interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
> interrupt-names = "send-empty", "send-not-empty",
> --
> 2.33.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
On Thu, Dec 9, 2021, at 06:50, Hector Martin wrote:
> Hi folks,
>
> Just a quick fix for the Apple mailbox compatible. Similar to [1], we
> intend to use SoC-specific compatibles only for potential quirks, and
> rely on a generic compatible to allow for forward-compatibility as long
> as things don't break.
I vaguely remember a brief discussion about this and I think we thought about
using "t6000-asc", "t8103-asc" in this case since this specific mailbox hardware
was only introduced in the M1. I think Apple calls this variant ascwrap-v4
and m3wrap-v2.
Doing it like you suggested is also fine with me though.
Sven
On 10/12/2021 01.33, Sven Peter wrote:
> On Thu, Dec 9, 2021, at 06:50, Hector Martin wrote:
>> Hi folks,
>>
>> Just a quick fix for the Apple mailbox compatible. Similar to [1], we
>> intend to use SoC-specific compatibles only for potential quirks, and
>> rely on a generic compatible to allow for forward-compatibility as long
>> as things don't break.
>
> I vaguely remember a brief discussion about this and I think we thought about
> using "t6000-asc", "t8103-asc" in this case since this specific mailbox hardware
> was only introduced in the M1. I think Apple calls this variant ascwrap-v4
> and m3wrap-v2.
>
> Doing it like you suggested is also fine with me though.
I think I remember that one... seems this is ascwrap-v4 in t8101 too, so
not quite introduced with M1. But that one doesn't have m3wraps (or
doesn't use them).
Since Apple do have some kind of sane versioning for these it seems,
maybe we should follow their numbers and call them apple,asc-mailbox-v4
and apple,m3-mailbox-v2?
--
Hector Martin ([email protected])
Public Key: https://mrcn.st/pub
On Mon, Dec 13, 2021, at 04:55, Hector Martin wrote:
> On 10/12/2021 01.33, Sven Peter wrote:
>> On Thu, Dec 9, 2021, at 06:50, Hector Martin wrote:
>>> Hi folks,
>>>
>>> Just a quick fix for the Apple mailbox compatible. Similar to [1], we
>>> intend to use SoC-specific compatibles only for potential quirks, and
>>> rely on a generic compatible to allow for forward-compatibility as long
>>> as things don't break.
>>
>> I vaguely remember a brief discussion about this and I think we thought about
>> using "t6000-asc", "t8103-asc" in this case since this specific mailbox hardware
>> was only introduced in the M1. I think Apple calls this variant ascwrap-v4
>> and m3wrap-v2.
>>
>> Doing it like you suggested is also fine with me though.
>
> I think I remember that one... seems this is ascwrap-v4 in t8101 too, so
> not quite introduced with M1. But that one doesn't have m3wraps (or
> doesn't use them).
>
> Since Apple do have some kind of sane versioning for these it seems,
> maybe we should follow their numbers and call them apple,asc-mailbox-v4
> and apple,m3-mailbox-v2?
Sure, sounds good to me.
Sven
On Thu, 09 Dec 2021 14:50:48 +0900, Hector Martin wrote:
> Much as we've done with other blocks, let's introduce generic
> compatibles so drivers can bind to those and still work with future
> SoCs, as long as the hardware remains the same. Also go ahead and add
> compatibles for the new t600x SoCs (we group those as t6000).
>
> Note that no DTs instantiate devices with this binding yet.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> .../devicetree/bindings/mailbox/apple,mailbox.yaml | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, Dec 9, 2021, at 06:50, Hector Martin wrote:
> Much as we've done with other blocks, let's introduce generic
> compatibles so drivers can bind to those and still work with future
> SoCs, as long as the hardware remains the same. Also go ahead and add
> compatibles for the new t600x SoCs (we group those as t6000).
>
> Note that no DTs instantiate devices with this binding yet.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
Reviewed-by: Sven Peter <[email protected]>
On Wed, Dec 15, 2021, at 18:13, Sven Peter wrote:
> On Thu, Dec 9, 2021, at 06:50, Hector Martin wrote:
>> Much as we've done with other blocks, let's introduce generic
>> compatibles so drivers can bind to those and still work with future
>> SoCs, as long as the hardware remains the same. Also go ahead and add
>> compatibles for the new t600x SoCs (we group those as t6000).
>>
>> Note that no DTs instantiate devices with this binding yet.
>>
>> Signed-off-by: Hector Martin <[email protected]>
>> ---
> Reviewed-by: Sven Peter <[email protected]>
er... wait... that was meant for v2, sorry *sigh*.
Sven