These bindings document the same hardware (just different minor
revisions). Remove the newer fsl,t1023-sfp.
Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")
Signed-off-by: Sean Anderson <[email protected]>
---
.../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++-
.../bindings/nvmem/fsl,t1023-sfp.yaml | 37 -------------------
2 files changed, 19 insertions(+), 39 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
index 70fb2ad25103..8a54dd1328ea 100644
--- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
@@ -19,6 +19,13 @@ allOf:
properties:
compatible:
oneOf:
+ - description: Trust architecture 2.0 SFP
+ items:
+ enum:
+ - fsl,t1023-sfp
+ - fsl,t1040-sfp
+ - fsl,t2080-sfp
+ - fsl,t4240-sfp
- description: Trust architecture 2.1 SFP
items:
- const: fsl,ls1021a-sfp
@@ -45,8 +52,18 @@ properties:
required:
- compatible
- reg
- - clock-names
- - clocks
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,ls1021a-sfp
+ - fsl,ls1028a-sfp
+then:
+ required:
+ - clocks
+ - clock-names
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
deleted file mode 100644
index df826b40d8ca..000000000000
--- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
+++ /dev/null
@@ -1,37 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: NXP QorIQ eFuse support
-
-maintainers:
- - Richard Alpe <[email protected]>
-
-description:
- Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
-
-allOf:
- - $ref: nvmem.yaml#
-
-properties:
- compatible:
- const: fsl,t1023-sfp
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
-
-unevaluatedProperties: false
-
-examples:
- - |
- efuse@e8000 {
- compatible = "fsl,t1023-sfp";
- reg = <0xe8000 0x1000>;
- };
-...
--
2.35.1.1320.gc452695387.dirty
The qoriq-efuse driver is a duplicate of layerscape-sfp.c. The T-series
uses TA 2.0, while Layerscape uses TA 2.1 or 3.0 (depending on the
chip). Add appropriate compatibles to the layerscape-sfp driver and
remove the qoriq-efuse driver. I did not add support for P-series SoCs,
since they use TA 1.0 which doesn't share a major version with either of
the existing implementations.
The qoriq-efuse driver does not properly abstract the location/offset of
the fuses properly, instead exposing the device's whole address range to
userspace. This is not appropriate, as the fuses only occupy a small
portion of this range. The layerscape-sfp module correctly constrains
the nvmem size to the fuses size. This represents a (necessary)
compatibility break. The qoriq-efuse driver has been in-tree for around
six months. Hopefully this will limit the fallout.
I would appreciate if someone with access to trust architecture 2.0 user
guide could confirm the number of fuses.
Fixes: 0861110bb421 ("nvmem: add new NXP QorIQ eFuse driver")
Signed-off-by: Sean Anderson <[email protected]>
---
drivers/nvmem/Kconfig | 14 +-----
drivers/nvmem/Makefile | 2 -
drivers/nvmem/layerscape-sfp.c | 27 +++++++++---
drivers/nvmem/qoriq-efuse.c | 78 ----------------------------------
4 files changed, 22 insertions(+), 99 deletions(-)
delete mode 100644 drivers/nvmem/qoriq-efuse.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 5bc9c4874fe3..81531ebb073d 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -122,7 +122,7 @@ config NVMEM_LAN9662_OTPC
config NVMEM_LAYERSCAPE_SFP
tristate "Layerscape SFP (Security Fuse Processor) support"
- depends on ARCH_LAYERSCAPE || COMPILE_TEST
+ depends on ARCH_LAYERSCAPE || PPC_85xx || COMPILE_TEST
depends on HAS_IOMEM
select REGMAP_MMIO
help
@@ -405,16 +405,4 @@ config NVMEM_ZYNQMP
If sure, say yes. If unsure, say no.
-config NVMEM_QORIQ_EFUSE
- tristate "NXP QorIQ eFuse support"
- depends on PPC_85xx || COMPILE_TEST
- depends on HAS_IOMEM
- help
- This driver provides read support for the eFuses (SFP) on NXP QorIQ
- series SoC's. This includes secure boot settings, the globally unique
- NXP ID 'FUIDR' and the OEM unique ID 'OUIDR'.
-
- This driver can also be built as a module. If so, the module
- will be called nvmem_qoriq_efuse.
-
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 423baf089515..a276447b8c2f 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -79,5 +79,3 @@ obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o
nvmem-vf610-ocotp-y := vf610-ocotp.o
obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
-obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
-nvmem-qoriq-efuse-y := qoriq-efuse.o
diff --git a/drivers/nvmem/layerscape-sfp.c b/drivers/nvmem/layerscape-sfp.c
index e2b424561949..7e32133e492a 100644
--- a/drivers/nvmem/layerscape-sfp.c
+++ b/drivers/nvmem/layerscape-sfp.c
@@ -22,8 +22,9 @@ struct layerscape_sfp_priv {
};
struct layerscape_sfp_data {
- int size;
+ int size, id;
enum regmap_endian endian;
+ const char *name;
};
static int layerscape_sfp_read(void *context, unsigned int offset, void *val,
@@ -37,7 +38,6 @@ static int layerscape_sfp_read(void *context, unsigned int offset, void *val,
}
static struct nvmem_config layerscape_sfp_nvmem_config = {
- .name = "fsl-sfp",
.reg_read = layerscape_sfp_read,
.word_size = 4,
.stride = 4,
@@ -69,6 +69,8 @@ static int layerscape_sfp_probe(struct platform_device *pdev)
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
+ layerscape_sfp_nvmem_config.name = data->name;
+ layerscape_sfp_nvmem_config.id = data->id;
layerscape_sfp_nvmem_config.size = data->size;
layerscape_sfp_nvmem_config.dev = &pdev->dev;
layerscape_sfp_nvmem_config.priv = priv;
@@ -78,19 +80,32 @@ static int layerscape_sfp_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(nvmem);
}
-static const struct layerscape_sfp_data ls1021a_data = {
+static const struct layerscape_sfp_data ta2_0_data = {
.size = 0x88,
.endian = REGMAP_ENDIAN_BIG,
+ .name = "qoriq_efuse_read",
+ .id = NVMEM_DEVID_AUTO,
};
-static const struct layerscape_sfp_data ls1028a_data = {
+static const struct layerscape_sfp_data ta2_1_data = {
+ .size = 0x88,
+ .endian = REGMAP_ENDIAN_BIG,
+ .name = "fsl-sfp",
+};
+
+static const struct layerscape_sfp_data ta3_0_data = {
.size = 0x88,
.endian = REGMAP_ENDIAN_LITTLE,
+ .name = "fsl-sfp",
};
static const struct of_device_id layerscape_sfp_dt_ids[] = {
- { .compatible = "fsl,ls1021a-sfp", .data = &ls1021a_data },
- { .compatible = "fsl,ls1028a-sfp", .data = &ls1028a_data },
+ { .compatible = "fsl,ls1021a-sfp", .data = &ta2_1_data },
+ { .compatible = "fsl,ls1028a-sfp", .data = &ta3_0_data },
+ { .compatible = "fsl,t1023-sfp", .data = &ta2_0_data },
+ { .compatible = "fsl,t1040-sfp", .data = &ta2_0_data },
+ { .compatible = "fsl,t2080-sfp", .data = &ta2_0_data },
+ { .compatible = "fsl,t4240-sfp", .data = &ta2_0_data },
{},
};
MODULE_DEVICE_TABLE(of, layerscape_sfp_dt_ids);
diff --git a/drivers/nvmem/qoriq-efuse.c b/drivers/nvmem/qoriq-efuse.c
deleted file mode 100644
index e7fd04d6dd94..000000000000
--- a/drivers/nvmem/qoriq-efuse.c
+++ /dev/null
@@ -1,78 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2023 Westermo Network Technologies AB
- */
-
-#include <linux/device.h>
-#include <linux/io.h>
-#include <linux/module.h>
-#include <linux/mod_devicetable.h>
-#include <linux/nvmem-provider.h>
-#include <linux/platform_device.h>
-
-struct qoriq_efuse_priv {
- void __iomem *base;
-};
-
-static int qoriq_efuse_read(void *context, unsigned int offset, void *val,
- size_t bytes)
-{
- struct qoriq_efuse_priv *priv = context;
-
- /* .stride = 4 so offset is guaranteed to be aligned */
- __ioread32_copy(val, priv->base + offset, bytes / 4);
-
- /* Ignore trailing bytes (there shouldn't be any) */
-
- return 0;
-}
-
-static int qoriq_efuse_probe(struct platform_device *pdev)
-{
- struct nvmem_config config = {
- .dev = &pdev->dev,
- .read_only = true,
- .reg_read = qoriq_efuse_read,
- .stride = sizeof(u32),
- .word_size = sizeof(u32),
- .name = "qoriq_efuse_read",
- .id = NVMEM_DEVID_AUTO,
- .root_only = true,
- };
- struct qoriq_efuse_priv *priv;
- struct nvmem_device *nvmem;
- struct resource *res;
-
- priv = devm_kzalloc(config.dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
- if (IS_ERR(priv->base))
- return PTR_ERR(priv->base);
-
- config.size = resource_size(res);
- config.priv = priv;
- nvmem = devm_nvmem_register(config.dev, &config);
-
- return PTR_ERR_OR_ZERO(nvmem);
-}
-
-static const struct of_device_id qoriq_efuse_of_match[] = {
- { .compatible = "fsl,t1023-sfp", },
- {/* sentinel */},
-};
-MODULE_DEVICE_TABLE(of, qoriq_efuse_of_match);
-
-static struct platform_driver qoriq_efuse_driver = {
- .probe = qoriq_efuse_probe,
- .driver = {
- .name = "qoriq-efuse",
- .of_match_table = qoriq_efuse_of_match,
- },
-};
-module_platform_driver(qoriq_efuse_driver);
-
-MODULE_AUTHOR("Richard Alpe <[email protected]>");
-MODULE_DESCRIPTION("NXP QorIQ Security Fuse Processor (SFP) Reader");
-MODULE_LICENSE("GPL");
--
2.35.1.1320.gc452695387.dirty
On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote:
> These bindings document the same hardware (just different minor
> revisions). Remove the newer fsl,t1023-sfp.
>
> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")
> Signed-off-by: Sean Anderson <[email protected]>
> ---
>
> .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++-
> .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 -------------------
> 2 files changed, 19 insertions(+), 39 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
>
> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
> index 70fb2ad25103..8a54dd1328ea 100644
> --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
> @@ -19,6 +19,13 @@ allOf:
> properties:
> compatible:
> oneOf:
> + - description: Trust architecture 2.0 SFP
> + items:
> + enum:
> + - fsl,t1023-sfp
> + - fsl,t1040-sfp
> + - fsl,t2080-sfp
> + - fsl,t4240-sfp
You should at least mention where these three compatibles came from,
given they were not documented in t1023-sfp.yaml. Additionally, should
they fall back to t1023-sfp? I see that there's already some dts files
with these compatibles in them but seemingly no driver support as there
is for the t1023-sfp.
Cheers,
Conor.
> - description: Trust architecture 2.1 SFP
> items:
> - const: fsl,ls1021a-sfp
> @@ -45,8 +52,18 @@ properties:
> required:
> - compatible
> - reg
> - - clock-names
> - - clocks
> +
> +if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - fsl,ls1021a-sfp
> + - fsl,ls1028a-sfp
> +then:
> + required:
> + - clocks
> + - clock-names
>
> unevaluatedProperties: false
>
> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
> deleted file mode 100644
> index df826b40d8ca..000000000000
> --- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> -%YAML 1.2
> ----
> -$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> -
> -title: NXP QorIQ eFuse support
> -
> -maintainers:
> - - Richard Alpe <[email protected]>
> -
> -description:
> - Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
> -
> -allOf:
> - - $ref: nvmem.yaml#
> -
> -properties:
> - compatible:
> - const: fsl,t1023-sfp
> -
> - reg:
> - maxItems: 1
> -
> -required:
> - - compatible
> - - reg
> -
> -unevaluatedProperties: false
> -
> -examples:
> - - |
> - efuse@e8000 {
> - compatible = "fsl,t1023-sfp";
> - reg = <0xe8000 0x1000>;
> - };
> -...
> --
> 2.35.1.1320.gc452695387.dirty
>
On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote:
> These bindings document the same hardware (just different minor
> revisions). Remove the newer fsl,t1023-sfp.
>
> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")
I don't think Fixes is appropriate here. What was broken?
> Signed-off-by: Sean Anderson <[email protected]>
> ---
>
> .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++-
> .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 -------------------
> 2 files changed, 19 insertions(+), 39 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
Otherwise,
Reviewed-by: Rob Herring <[email protected]>
On 2024-03-17 22:12, Rob Herring wrote:
> On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote:
>> These bindings document the same hardware (just different minor
>> revisions). Remove the newer fsl,t1023-sfp.
>>
>> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse
>> support")
>
> I don't think Fixes is appropriate here. What was broken?
I also don't think Fixes is appropriate. Apart from that:
Acked-by: Richard Alpe <[email protected]>
On 2024-03-16 01:20, Sean Anderson wrote:
> The qoriq-efuse driver is a duplicate of layerscape-sfp.c. The T-series
> uses TA 2.0, while Layerscape uses TA 2.1 or 3.0 (depending on the
> chip). Add appropriate compatibles to the layerscape-sfp driver and
> remove the qoriq-efuse driver. I did not add support for P-series SoCs,
> since they use TA 1.0 which doesn't share a major version with either
> of
> the existing implementations.
>
> The qoriq-efuse driver does not properly abstract the location/offset
> of
> the fuses properly, instead exposing the device's whole address range
> to
> userspace. This is not appropriate, as the fuses only occupy a small
> portion of this range. The layerscape-sfp module correctly constrains
> the nvmem size to the fuses size. This represents a (necessary)
> compatibility break. The qoriq-efuse driver has been in-tree for around
> six months. Hopefully this will limit the fallout.
>
> I would appreciate if someone with access to trust architecture 2.0
> user
> guide could confirm the number of fuses.
>
> Fixes: 0861110bb421 ("nvmem: add new NXP QorIQ eFuse driver")
> Signed-off-by: Sean Anderson <[email protected]>
I don't think Fixes is appropriate here. Apart from that:
Acked-by: Richard Alpe <[email protected]>
On 3/17/24 11:10, Conor Dooley wrote:
> On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote:
>> These bindings document the same hardware (just different minor
>> revisions). Remove the newer fsl,t1023-sfp.
>>
>> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support")
>> Signed-off-by: Sean Anderson <[email protected]>
>> ---
>>
>> .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++-
>> .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 -------------------
>> 2 files changed, 19 insertions(+), 39 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
>> index 70fb2ad25103..8a54dd1328ea 100644
>> --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
>> +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
>> @@ -19,6 +19,13 @@ allOf:
>> properties:
>> compatible:
>> oneOf:
>> + - description: Trust architecture 2.0 SFP
>> + items:
>> + enum:
>> + - fsl,t1023-sfp
>
>> + - fsl,t1040-sfp
>> + - fsl,t2080-sfp
>> + - fsl,t4240-sfp
>
> You should at least mention where these three compatibles came from,
> given they were not documented in t1023-sfp.yaml
They come from the existing DTSs for these processors. Will add this to
the commit message.
> Additionally, should
> they fall back to t1023-sfp? I see that there's already some dts files
> with these compatibles in them but seemingly no driver support as there
> is for the t1023-sfp.
I checked the reference manuals for these processors, and all of them use TA 2.0.
--Sean
>> - description: Trust architecture 2.1 SFP
>> items:
>> - const: fsl,ls1021a-sfp
>> @@ -45,8 +52,18 @@ properties:
>> required:
>> - compatible
>> - reg
>> - - clock-names
>> - - clocks
>> +
>> +if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - fsl,ls1021a-sfp
>> + - fsl,ls1028a-sfp
>> +then:
>> + required:
>> + - clocks
>> + - clock-names
>>
>> unevaluatedProperties: false
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
>> deleted file mode 100644
>> index df826b40d8ca..000000000000
>> --- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
>> +++ /dev/null
>> @@ -1,37 +0,0 @@
>> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> -%YAML 1.2
>> ----
>> -$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
>> -$schema: http://devicetree.org/meta-schemas/core.yaml#
>> -
>> -title: NXP QorIQ eFuse support
>> -
>> -maintainers:
>> - - Richard Alpe <[email protected]>
>> -
>> -description:
>> - Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
>> -
>> -allOf:
>> - - $ref: nvmem.yaml#
>> -
>> -properties:
>> - compatible:
>> - const: fsl,t1023-sfp
>> -
>> - reg:
>> - maxItems: 1
>> -
>> -required:
>> - - compatible
>> - - reg
>> -
>> -unevaluatedProperties: false
>> -
>> -examples:
>> - - |
>> - efuse@e8000 {
>> - compatible = "fsl,t1023-sfp";
>> - reg = <0xe8000 0x1000>;
>> - };
>> -...
>> --
>> 2.35.1.1320.gc452695387.dirty
>>
On 3/18/24 04:32, [email protected] wrote:
> On 2024-03-16 01:20, Sean Anderson wrote:
>> The qoriq-efuse driver is a duplicate of layerscape-sfp.c. The T-series
>> uses TA 2.0, while Layerscape uses TA 2.1 or 3.0 (depending on the
>> chip). Add appropriate compatibles to the layerscape-sfp driver and
>> remove the qoriq-efuse driver. I did not add support for P-series SoCs,
>> since they use TA 1.0 which doesn't share a major version with either of
>> the existing implementations.
>>
>> The qoriq-efuse driver does not properly abstract the location/offset of
>> the fuses properly, instead exposing the device's whole address range to
>> userspace. This is not appropriate, as the fuses only occupy a small
>> portion of this range. The layerscape-sfp module correctly constrains
>> the nvmem size to the fuses size. This represents a (necessary)
>> compatibility break. The qoriq-efuse driver has been in-tree for around
>> six months. Hopefully this will limit the fallout.
>>
>> I would appreciate if someone with access to trust architecture 2.0 user
>> guide could confirm the number of fuses.
>>
>> Fixes: 0861110bb421 ("nvmem: add new NXP QorIQ eFuse driver")
>> Signed-off-by: Sean Anderson <[email protected]>
> I don't think Fixes is appropriate here. Apart from that:
As mentioned in the second paragraph, the original driver exposes the whole
register space in the nvmem. I consider this a bug.
--Sean
> Acked-by: Richard Alpe <[email protected]>
On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
> On 3/17/24 11:10, Conor Dooley wrote:
> > Additionally, should
> > they fall back to t1023-sfp? I see that there's already some dts files
> > with these compatibles in them but seemingly no driver support as there
> > is for the t1023-sfp.
>
> I checked the reference manuals for these processors, and all of them use TA 2.0.
Sounds like a fallback is suitable then, although that will require
updating the various dts files.
On 3/18/24 11:40, Conor Dooley wrote:
> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>> On 3/17/24 11:10, Conor Dooley wrote:
>
>> > Additionally, should
>> > they fall back to t1023-sfp? I see that there's already some dts files
>> > with these compatibles in them but seemingly no driver support as there
>> > is for the t1023-sfp.
>>
>> I checked the reference manuals for these processors, and all of them use TA 2.0.
>
> Sounds like a fallback is suitable then, although that will require
> updating the various dts files.
Yes, a fallback (like what is done for the T-series) would be suitable,
but given that these devicetrees have been in-tree for eight years I
think it would be preferable to support the existing bindings for
compatibility purposes.
--Sean
On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
> On 3/18/24 11:40, Conor Dooley wrote:
> > On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
> >> On 3/17/24 11:10, Conor Dooley wrote:
> >
> >> > Additionally, should
> >> > they fall back to t1023-sfp? I see that there's already some dts files
> >> > with these compatibles in them but seemingly no driver support as there
> >> > is for the t1023-sfp.
> >>
> >> I checked the reference manuals for these processors, and all of them use TA 2.0.
> >
> > Sounds like a fallback is suitable then, although that will require
> > updating the various dts files.
>
> Yes, a fallback (like what is done for the T-series) would be suitable,
> but given that these devicetrees have been in-tree for eight years I
> think it would be preferable to support the existing bindings for
> compatibility purposes.
Just cos stuff snuck into the tree in dts files doesn't make it right
though, I'd rather the bindings were done correctly. I don't care if you
want to support all of the compatibles in the driver so that it works
with the existing devicetrees though, as long as you mention the
rationale in the commit message.
On 3/19/24 13:55, Conor Dooley wrote:
> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
>> On 3/18/24 11:40, Conor Dooley wrote:
>> > On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>> >> On 3/17/24 11:10, Conor Dooley wrote:
>> >
>> >> > Additionally, should
>> >> > they fall back to t1023-sfp? I see that there's already some dts files
>> >> > with these compatibles in them but seemingly no driver support as there
>> >> > is for the t1023-sfp.
>> >>
>> >> I checked the reference manuals for these processors, and all of them use TA 2.0.
>> >
>> > Sounds like a fallback is suitable then, although that will require
>> > updating the various dts files.
>>
>> Yes, a fallback (like what is done for the T-series) would be suitable,
>> but given that these devicetrees have been in-tree for eight years I
>> think it would be preferable to support the existing bindings for
>> compatibility purposes.
>
> Just cos stuff snuck into the tree in dts files doesn't make it right
> though, I'd rather the bindings were done correctly. I don't care if you
> want to support all of the compatibles in the driver so that it works
> with the existing devicetrees though, as long as you mention the
> rationale in the commit message.
It doesn't really matter what the schema has as long as the driver supports
existing device trees.
--Sean
On 21/03/2024 17:21, Sean Anderson wrote:
> On 3/19/24 13:55, Conor Dooley wrote:
>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
>>> On 3/18/24 11:40, Conor Dooley wrote:
>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>>>>> On 3/17/24 11:10, Conor Dooley wrote:
>>>>
>>>>>> Additionally, should
>>>>>> they fall back to t1023-sfp? I see that there's already some dts files
>>>>>> with these compatibles in them but seemingly no driver support as there
>>>>>> is for the t1023-sfp.
>>>>>
>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0.
>>>>
>>>> Sounds like a fallback is suitable then, although that will require
>>>> updating the various dts files.
>>>
>>> Yes, a fallback (like what is done for the T-series) would be suitable,
>>> but given that these devicetrees have been in-tree for eight years I
>>> think it would be preferable to support the existing bindings for
>>> compatibility purposes.
>>
>> Just cos stuff snuck into the tree in dts files doesn't make it right
>> though, I'd rather the bindings were done correctly. I don't care if you
>> want to support all of the compatibles in the driver so that it works
>> with the existing devicetrees though, as long as you mention the
>> rationale in the commit message.
>
> It doesn't really matter what the schema has as long as the driver supports
> existing device trees.
We do not talk about driver now but bindings. You add new compatibles on
a basis that they were already used. This cannot bypass regular review
comments, so if during regular review process we would require
fallbacks, then you are expected to listen to review also when
documenting existing compatibles. Otherwise everyone would prefer to
snuck in incorrect code and later document it "it was there!".
Best regards,
Krzysztof
On 3/22/24 03:01, Krzysztof Kozlowski wrote:
> On 21/03/2024 17:21, Sean Anderson wrote:
>> On 3/19/24 13:55, Conor Dooley wrote:
>>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
>>>> On 3/18/24 11:40, Conor Dooley wrote:
>>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>>>>>> On 3/17/24 11:10, Conor Dooley wrote:
>>>>>
>>>>>>> Additionally, should
>>>>>>> they fall back to t1023-sfp? I see that there's already some dts files
>>>>>>> with these compatibles in them but seemingly no driver support as there
>>>>>>> is for the t1023-sfp.
>>>>>>
>>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0.
>>>>>
>>>>> Sounds like a fallback is suitable then, although that will require
>>>>> updating the various dts files.
>>>>
>>>> Yes, a fallback (like what is done for the T-series) would be suitable,
>>>> but given that these devicetrees have been in-tree for eight years I
>>>> think it would be preferable to support the existing bindings for
>>>> compatibility purposes.
>>>
>>> Just cos stuff snuck into the tree in dts files doesn't make it right
>>> though, I'd rather the bindings were done correctly. I don't care if you
>>> want to support all of the compatibles in the driver so that it works
>>> with the existing devicetrees though, as long as you mention the
>>> rationale in the commit message.
>>
>> It doesn't really matter what the schema has as long as the driver supports
>> existing device trees.
>
> We do not talk about driver now but bindings. You add new compatibles on
> a basis that they were already used. This cannot bypass regular review
> comments, so if during regular review process we would require
> fallbacks, then you are expected to listen to review also when
> documenting existing compatibles. Otherwise everyone would prefer to
> snuck in incorrect code and later document it "it was there!".
To be clear, the existing nodes look like
sfp: sfp@e8000 {
compatible = "fsl,t1040-sfp";
reg = <0xe8000 0x1000>;
};
which is perfectly serviceable for read-only use (as the clock is only
necessary for writing). As these devices are effectively identical, the
compatible could also look like what the P-series has:
sfp: sfp@e8000 {
compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
reg = <0xe8000 0x1000>;
};
but in either case, it is desirable for the driver to match based on the
more-specific compatible (as well as the less-specific compatible) as we
already have enough information from the more-specific compatible to
select the correct implementation.
--Sean
On Fri, Mar 22, 2024 at 12:26:10PM -0400, Sean Anderson wrote:
> On 3/22/24 03:01, Krzysztof Kozlowski wrote:
> > On 21/03/2024 17:21, Sean Anderson wrote:
> >> On 3/19/24 13:55, Conor Dooley wrote:
> >>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
> >>>> On 3/18/24 11:40, Conor Dooley wrote:
> >>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
> >>>>>> On 3/17/24 11:10, Conor Dooley wrote:
> >>>>>
> >>>>>>> Additionally, should
> >>>>>>> they fall back to t1023-sfp? I see that there's already some dts files
> >>>>>>> with these compatibles in them but seemingly no driver support as there
> >>>>>>> is for the t1023-sfp.
> >>>>>>
> >>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0.
> >>>>>
> >>>>> Sounds like a fallback is suitable then, although that will require
> >>>>> updating the various dts files.
> >>>>
> >>>> Yes, a fallback (like what is done for the T-series) would be suitable,
> >>>> but given that these devicetrees have been in-tree for eight years I
> >>>> think it would be preferable to support the existing bindings for
> >>>> compatibility purposes.
> >>>
> >>> Just cos stuff snuck into the tree in dts files doesn't make it right
> >>> though, I'd rather the bindings were done correctly. I don't care if you
> >>> want to support all of the compatibles in the driver so that it works
> >>> with the existing devicetrees though, as long as you mention the
> >>> rationale in the commit message.
> >>
> >> It doesn't really matter what the schema has as long as the driver supports
> >> existing device trees.
> >
> > We do not talk about driver now but bindings. You add new compatibles on
> > a basis that they were already used. This cannot bypass regular review
> > comments, so if during regular review process we would require
> > fallbacks, then you are expected to listen to review also when
> > documenting existing compatibles. Otherwise everyone would prefer to
> > snuck in incorrect code and later document it "it was there!".
>
> To be clear, the existing nodes look like
>
> sfp: sfp@e8000 {
> compatible = "fsl,t1040-sfp";
> reg = <0xe8000 0x1000>;
> };
>
> which is perfectly serviceable for read-only use (as the clock is only
> necessary for writing). As these devices are effectively identical, the
> compatible could also look like what the P-series has:
I'd rather you just picked the oldest device and used that as the
fallback, rather than introducing an "<blah>-sfp-2.0" compatible.
The 2.1 and 3.0 ones don't have anything like that.
> sfp: sfp@e8000 {
> compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
> reg = <0xe8000 0x1000>;
> };
None of the seem to be documented either btw:
rg fsl,qoriq-sfp-1.0
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
371: compatible = "fsl,p5020-sfp", "fsl,qoriq-sfp-1.0";
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
339: compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
386: compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0";
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
366: compatible = "fsl,p3041-sfp", "fsl,qoriq-sfp-1.0";
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
331: compatible = "fsl,p5040-sfp", "fsl,qoriq-sfp-1.0";
>
> but in either case, it is desirable for the driver to match based on the
> more-specific compatible (as well as the less-specific compatible) as we
> already have enough information from the more-specific compatible to
> select the correct implementation.
>
> --Sean
On 3/22/24 14:14, Conor Dooley wrote:
> On Fri, Mar 22, 2024 at 12:26:10PM -0400, Sean Anderson wrote:
>> On 3/22/24 03:01, Krzysztof Kozlowski wrote:
>> > On 21/03/2024 17:21, Sean Anderson wrote:
>> >> On 3/19/24 13:55, Conor Dooley wrote:
>> >>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote:
>> >>>> On 3/18/24 11:40, Conor Dooley wrote:
>> >>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote:
>> >>>>>> On 3/17/24 11:10, Conor Dooley wrote:
>> >>>>>
>> >>>>>>> Additionally, should
>> >>>>>>> they fall back to t1023-sfp? I see that there's already some dts files
>> >>>>>>> with these compatibles in them but seemingly no driver support as there
>> >>>>>>> is for the t1023-sfp.
>> >>>>>>
>> >>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0.
>> >>>>>
>> >>>>> Sounds like a fallback is suitable then, although that will require
>> >>>>> updating the various dts files.
>> >>>>
>> >>>> Yes, a fallback (like what is done for the T-series) would be suitable,
>> >>>> but given that these devicetrees have been in-tree for eight years I
>> >>>> think it would be preferable to support the existing bindings for
>> >>>> compatibility purposes.
>> >>>
>> >>> Just cos stuff snuck into the tree in dts files doesn't make it right
>> >>> though, I'd rather the bindings were done correctly. I don't care if you
>> >>> want to support all of the compatibles in the driver so that it works
>> >>> with the existing devicetrees though, as long as you mention the
>> >>> rationale in the commit message.
>> >>
>> >> It doesn't really matter what the schema has as long as the driver supports
>> >> existing device trees.
>> >
>> > We do not talk about driver now but bindings. You add new compatibles on
>> > a basis that they were already used. This cannot bypass regular review
>> > comments, so if during regular review process we would require
>> > fallbacks, then you are expected to listen to review also when
>> > documenting existing compatibles. Otherwise everyone would prefer to
>> > snuck in incorrect code and later document it "it was there!".
>>
>> To be clear, the existing nodes look like
>>
>> sfp: sfp@e8000 {
>> compatible = "fsl,t1040-sfp";
>> reg = <0xe8000 0x1000>;
>> };
>>
>> which is perfectly serviceable for read-only use (as the clock is only
>> necessary for writing). As these devices are effectively identical, the
>> compatible could also look like what the P-series has:
>
> I'd rather you just picked the oldest device and used that as the
> fallback, rather than introducing an "<blah>-sfp-2.0" compatible.
> The 2.1 and 3.0 ones don't have anything like that.
Because of course no one looked around at the other SoCs and noticed
that they all have the same TA version and use the same document for
this device. I would rather use a common name based on the version,
rather than arbitrarily picking a SoC to be "compatible" with. This
doesn't make sense to me, since each SoC's reference manual just calls
out to the appropriate TA manual for all register definitions.
>> sfp: sfp@e8000 {
>> compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
>> reg = <0xe8000 0x1000>;
>> };
>
> None of the seem to be documented either btw:
> rg fsl,qoriq-sfp-1.0
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
> 371: compatible = "fsl,p5020-sfp", "fsl,qoriq-sfp-1.0";
>
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
> 339: compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0";
>
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
> 386: compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0";
>
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
> 366: compatible = "fsl,p3041-sfp", "fsl,qoriq-sfp-1.0";
>
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
> 331: compatible = "fsl,p5040-sfp", "fsl,qoriq-sfp-1.0";
Yeah. As noted in the next patch, someone with access to the TA 1.0 manual
would need to have a look.
--Sean
>>
>> but in either case, it is desirable for the driver to match based on the
>> more-specific compatible (as well as the less-specific compatible) as we
>> already have enough information from the more-specific compatible to
>> select the correct implementation.
>>
>> --Sean