* [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, devicetree, Rob Herring Hello, This series adds a soc bus driver for Realtek RTD1195 and RTD1295 SoC families. The detection magic for RTD1295 family was mostly borrowed from downstream code and the bit meanings are entirely undocumented. In case of RTD1293 I had to invent my own detection logic, possibly flawed. It is expected that this driver will need to be tweaked as new models emerge. One general consideration here is that some register accesses are not well self-contained within a block so that a syscon might in theory help - but for lack of documentation we don't really have an overview of the IP blocks and their names, starts and sizes; downstream trees just hardcoded addresses. I therefore split off the DT change to add a second/third reg entry for now, so that we could move ahead with a basic driver initially. We have no RTD1294 DT, so it is included here mainly for illustration of the unpredictable register dependencies affecting this binding/driver. Using reg-names might clean this up a little but would blow up the driver code as there appears to be no handy helper function provided. Finally, I've been struggling to find an overarching name for the SoC families. Realtek.com groups them as "Digital Home Center" - not sure whether that fits? For now I use Phoenix/Kylin/etc. with DHC only as fallback, but I wonder whether those family names should rather be soc_id than family contents? Prepared but not included here is: * RTD1395 family, which we don't have a DT for yet, * RTD1619 family, which we don't have a DT for yet, Chip ID to be verified, * RTD1319 family, which we don't have a DT for yet, with TODO for its Chip ID. Latest experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Andreas Färber (11): dt-bindings: soc: Add Realtek RTD1195 chip info binding soc: Add Realtek chip info driver for RTD1195 and RTD1295 arm64: dts: realtek: rtd129x: Add chip info node ARM: dts: rtd1195: Add chip info node dt-bindings: soc: realtek: rtd1195-chip: Extend reg property soc: realtek: chip: Detect RTD1296 arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 soc: realtek: chip: Detect RTD1293 dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again soc: realtek: chip: Detect RTD1294 arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 47 +++++ MAINTAINERS | 1 + arch/arm/boot/dts/rtd1195.dtsi | 5 + arch/arm64/boot/dts/realtek/rtd129x.dtsi | 7 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/realtek/Kconfig | 13 ++ drivers/soc/realtek/Makefile | 2 + drivers/soc/realtek/chip.c | 190 +++++++++++++++++++++ 9 files changed, 267 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c -- 2.16.4 ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel, Andreas Färber Hello, This series adds a soc bus driver for Realtek RTD1195 and RTD1295 SoC families. The detection magic for RTD1295 family was mostly borrowed from downstream code and the bit meanings are entirely undocumented. In case of RTD1293 I had to invent my own detection logic, possibly flawed. It is expected that this driver will need to be tweaked as new models emerge. One general consideration here is that some register accesses are not well self-contained within a block so that a syscon might in theory help - but for lack of documentation we don't really have an overview of the IP blocks and their names, starts and sizes; downstream trees just hardcoded addresses. I therefore split off the DT change to add a second/third reg entry for now, so that we could move ahead with a basic driver initially. We have no RTD1294 DT, so it is included here mainly for illustration of the unpredictable register dependencies affecting this binding/driver. Using reg-names might clean this up a little but would blow up the driver code as there appears to be no handy helper function provided. Finally, I've been struggling to find an overarching name for the SoC families. Realtek.com groups them as "Digital Home Center" - not sure whether that fits? For now I use Phoenix/Kylin/etc. with DHC only as fallback, but I wonder whether those family names should rather be soc_id than family contents? Prepared but not included here is: * RTD1395 family, which we don't have a DT for yet, * RTD1619 family, which we don't have a DT for yet, Chip ID to be verified, * RTD1319 family, which we don't have a DT for yet, with TODO for its Chip ID. Latest experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Andreas Färber (11): dt-bindings: soc: Add Realtek RTD1195 chip info binding soc: Add Realtek chip info driver for RTD1195 and RTD1295 arm64: dts: realtek: rtd129x: Add chip info node ARM: dts: rtd1195: Add chip info node dt-bindings: soc: realtek: rtd1195-chip: Extend reg property soc: realtek: chip: Detect RTD1296 arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 soc: realtek: chip: Detect RTD1293 dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again soc: realtek: chip: Detect RTD1294 arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 47 +++++ MAINTAINERS | 1 + arch/arm/boot/dts/rtd1195.dtsi | 5 + arch/arm64/boot/dts/realtek/rtd129x.dtsi | 7 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/realtek/Kconfig | 13 ++ drivers/soc/realtek/Makefile | 2 + drivers/soc/realtek/chip.c | 190 +++++++++++++++++++++ 9 files changed, 267 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree Define a binding for RTD1195 and later SoCs' chip info registers. Add the new directory to MAINTAINERS. Signed-off-by: Andreas Färber <afaerber@suse.de> --- Note: The binding gets extended compatibly later for up to three reg entries. .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 32 ++++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml new file mode 100644 index 000000000000..565ad2419553 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -0,0 +1,32 @@ +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/realtek/realtek,rtd1195-chip.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Realtek RTD1195 chip identification + +maintainers: + - Andreas Färber <afaerber@suse.de> + +description: | + The Realtek SoCs have some registers to identify the chip and revision. + +properties: + compatible: + const: "realtek,rtd1195-chip" + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + chip-info@1801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x1801a200 0x8>; + }; +... diff --git a/MAINTAINERS b/MAINTAINERS index f33adc430230..5c61cf5a44cb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2188,6 +2188,7 @@ L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/boot/dts/realtek/ F: Documentation/devicetree/bindings/arm/realtek.yaml +F: Documentation/devicetree/bindings/soc/realtek/ ARM/RENESAS ARM64 ARCHITECTURE M: Geert Uytterhoeven <geert+renesas@glider.be> -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel Define a binding for RTD1195 and later SoCs' chip info registers. Add the new directory to MAINTAINERS. Signed-off-by: Andreas Färber <afaerber@suse.de> --- Note: The binding gets extended compatibly later for up to three reg entries. .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 32 ++++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml new file mode 100644 index 000000000000..565ad2419553 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -0,0 +1,32 @@ +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/realtek/realtek,rtd1195-chip.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Realtek RTD1195 chip identification + +maintainers: + - Andreas Färber <afaerber@suse.de> + +description: | + The Realtek SoCs have some registers to identify the chip and revision. + +properties: + compatible: + const: "realtek,rtd1195-chip" + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + chip-info@1801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x1801a200 0x8>; + }; +... diff --git a/MAINTAINERS b/MAINTAINERS index f33adc430230..5c61cf5a44cb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2188,6 +2188,7 @@ L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/boot/dts/realtek/ F: Documentation/devicetree/bindings/arm/realtek.yaml +F: Documentation/devicetree/bindings/soc/realtek/ ARM/RENESAS ARM64 ARCHITECTURE M: Geert Uytterhoeven <geert+renesas@glider.be> -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding 2019-11-03 1:36 ` Andreas Färber @ 2019-11-06 4:41 ` Rob Herring -1 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-06 4:41 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Mark Rutland, devicetree On Sun, Nov 03, 2019 at 02:36:35AM +0100, Andreas Färber wrote: > Define a binding for RTD1195 and later SoCs' chip info registers. > Add the new directory to MAINTAINERS. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > Note: The binding gets extended compatibly later for up to three reg entries. > > .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 32 ++++++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 33 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > > diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > new file mode 100644 > index 000000000000..565ad2419553 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > @@ -0,0 +1,32 @@ > +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/soc/realtek/realtek,rtd1195-chip.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Realtek RTD1195 chip identification > + > +maintainers: > + - Andreas Färber <afaerber@suse.de> > + > +description: | > + The Realtek SoCs have some registers to identify the chip and revision. > + > +properties: > + compatible: > + const: "realtek,rtd1195-chip" Don't need quotes. > + > + reg: > + maxItems: 1 > + > +required: > + - compatible > + - reg Add here: additionalProperties: false > + > +examples: > + - | > + chip-info@1801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x1801a200 0x8>; > + }; > +... > diff --git a/MAINTAINERS b/MAINTAINERS > index f33adc430230..5c61cf5a44cb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2188,6 +2188,7 @@ L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers) > S: Maintained > F: arch/arm64/boot/dts/realtek/ > F: Documentation/devicetree/bindings/arm/realtek.yaml > +F: Documentation/devicetree/bindings/soc/realtek/ > > ARM/RENESAS ARM64 ARCHITECTURE > M: Geert Uytterhoeven <geert+renesas@glider.be> > -- > 2.16.4 > ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding @ 2019-11-06 4:41 ` Rob Herring 0 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-06 4:41 UTC (permalink / raw) To: Andreas Färber Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc On Sun, Nov 03, 2019 at 02:36:35AM +0100, Andreas Färber wrote: > Define a binding for RTD1195 and later SoCs' chip info registers. > Add the new directory to MAINTAINERS. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > Note: The binding gets extended compatibly later for up to three reg entries. > > .../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 32 ++++++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 33 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > > diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > new file mode 100644 > index 000000000000..565ad2419553 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > @@ -0,0 +1,32 @@ > +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/soc/realtek/realtek,rtd1195-chip.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Realtek RTD1195 chip identification > + > +maintainers: > + - Andreas Färber <afaerber@suse.de> > + > +description: | > + The Realtek SoCs have some registers to identify the chip and revision. > + > +properties: > + compatible: > + const: "realtek,rtd1195-chip" Don't need quotes. > + > + reg: > + maxItems: 1 > + > +required: > + - compatible > + - reg Add here: additionalProperties: false > + > +examples: > + - | > + chip-info@1801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x1801a200 0x8>; > + }; > +... > diff --git a/MAINTAINERS b/MAINTAINERS > index f33adc430230..5c61cf5a44cb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2188,6 +2188,7 @@ L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers) > S: Maintained > F: arch/arm64/boot/dts/realtek/ > F: Documentation/devicetree/bindings/arm/realtek.yaml > +F: Documentation/devicetree/bindings/soc/realtek/ > > ARM/RENESAS ARM64 ARCHITECTURE > M: Geert Uytterhoeven <geert+renesas@glider.be> > -- > 2.16.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-arm-kernel, linux-kernel, Andreas Färber Add a soc bus driver to print chip model and revision details. Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. Signed-off-by: Andreas Färber <afaerber@suse.de> --- Naming: What to call the family vs. soc_id? drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/realtek/Kconfig | 13 ++++ drivers/soc/realtek/Makefile | 2 + drivers/soc/realtek/chip.c | 164 +++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 181 insertions(+) create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 833e04a7835c..06ae9d97321c 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" source "drivers/soc/ixp4xx/Kconfig" source "drivers/soc/mediatek/Kconfig" source "drivers/soc/qcom/Kconfig" +source "drivers/soc/realtek/Kconfig" source "drivers/soc/renesas/Kconfig" source "drivers/soc/rockchip/Kconfig" source "drivers/soc/samsung/Kconfig" diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 2ec355003524..1d55d838a342 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ obj-y += mediatek/ obj-y += amlogic/ obj-y += qcom/ +obj-y += realtek/ obj-y += renesas/ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ obj-$(CONFIG_SOC_SAMSUNG) += samsung/ diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file mode 100644 index 000000000000..be75c1889c61 --- /dev/null +++ b/drivers/soc/realtek/Kconfig @@ -0,0 +1,13 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +if ARCH_REALTEK || COMPILE_TEST + +config REALTEK_SOC + tristate "Realtek chip info" + default ARCH_REALTEK + select SOC_BUS + help + Say 'y' here to enable support for SoC info on Realtek RTD1195 and + RTD1295 SoC families. + If unsure, say 'n'. + +endif diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new file mode 100644 index 000000000000..49900273905b --- /dev/null +++ b/drivers/soc/realtek/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +obj-$(CONFIG_REALTEK_SOC) += chip.o diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file mode 100644 index 000000000000..9d13422e9936 --- /dev/null +++ b/drivers/soc/realtek/chip.c @@ -0,0 +1,164 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Realtek System-on-Chip info + * + * Copyright (c) 2017-2019 Andreas Färber + */ + +#include <linux/io.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +#define REG_CHIP_ID 0x0 +#define REG_CHIP_REV 0x4 + +struct rtd_soc_revision { + const char *name; + u32 chip_rev; +}; + +static const struct rtd_soc_revision rtd1195_revisions[] = { + { "A", 0x00000000 }, + { "B", 0x00010000 }, + { "C", 0x00020000 }, + { "D", 0x00030000 }, + { } +}; + +static const struct rtd_soc_revision rtd1295_revisions[] = { + { "A00", 0x00000000 }, + { "A01", 0x00010000 }, + { "B00", 0x00020000 }, + { "B01", 0x00030000 }, + { } +}; + +struct rtd_soc { + u32 chip_id; + const char *family; + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); + const struct rtd_soc_revision *revisions; + const char *codename; +}; + +static const char *default_name(struct device *dev, const struct rtd_soc *s) +{ + return s->family; +} + +static const struct rtd_soc rtd_soc_families[] = { + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, +}; + +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { + const struct rtd_soc *family = &rtd_soc_families[i]; + + if (family->chip_id == chip_id) + return family; + } + return NULL; +} + +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 chip_rev) +{ + if (family) { + const struct rtd_soc_revision *rev = family->revisions; + + while (rev && rev->name) { + if (rev->chip_rev == chip_rev) + return rev->name; + rev++; + } + } + return "unknown"; +} + +static int rtd_soc_probe(struct platform_device *pdev) +{ + const struct rtd_soc *s; + struct soc_device_attribute *soc_dev_attr; + struct soc_device *soc_dev; + struct device_node *node; + void __iomem *base; + u32 chip_id, chip_rev; + + base = of_iomap(pdev->dev.of_node, 0); + if (!base) + return -ENODEV; + + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); + if (!soc_dev_attr) + return -ENOMEM; + + chip_id = readl_relaxed(base + REG_CHIP_ID); + chip_rev = readl_relaxed(base + REG_CHIP_REV); + + node = of_find_node_by_path("/"); + of_property_read_string(node, "model", &soc_dev_attr->machine); + of_node_put(node); + + s = rtd_soc_by_chip_id(chip_id); + + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", + (s && s->codename) ? s->codename : + ((s && s->family) ? s->family : "Digital Home Center")); + + if (likely(s && s->get_name)) + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); + else + soc_dev_attr->soc_id = "unknown"; + + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); + + soc_dev = soc_device_register(soc_dev_attr); + if (IS_ERR(soc_dev)) { + kfree(soc_dev_attr->family); + kfree(soc_dev_attr); + return PTR_ERR(soc_dev); + } + + platform_set_drvdata(pdev, soc_dev); + + dev_info(soc_device_to_device(soc_dev), + "%s %s (0x%08x) rev %s (0x%08x) detected\n", + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, + soc_dev_attr->revision, chip_rev); + + return 0; +} + +static int rtd_soc_remove(struct platform_device *pdev) +{ + struct soc_device *soc_dev = platform_get_drvdata(pdev); + + soc_device_unregister(soc_dev); + + return 0; +} + +static const struct of_device_id rtd_soc_dt_ids[] = { + { .compatible = "realtek,rtd1195-chip" }, + { } +}; + +static struct platform_driver rtd_soc_driver = { + .probe = rtd_soc_probe, + .remove = rtd_soc_remove, + .driver = { + .name = "rtd1195-soc", + .of_match_table = rtd_soc_dt_ids, + }, +}; +module_platform_driver(rtd_soc_driver); + +MODULE_DESCRIPTION("Realtek SoC identification"); +MODULE_LICENSE("GPL"); -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel, Andreas Färber Add a soc bus driver to print chip model and revision details. Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. Signed-off-by: Andreas Färber <afaerber@suse.de> --- Naming: What to call the family vs. soc_id? drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/realtek/Kconfig | 13 ++++ drivers/soc/realtek/Makefile | 2 + drivers/soc/realtek/chip.c | 164 +++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 181 insertions(+) create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 833e04a7835c..06ae9d97321c 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" source "drivers/soc/ixp4xx/Kconfig" source "drivers/soc/mediatek/Kconfig" source "drivers/soc/qcom/Kconfig" +source "drivers/soc/realtek/Kconfig" source "drivers/soc/renesas/Kconfig" source "drivers/soc/rockchip/Kconfig" source "drivers/soc/samsung/Kconfig" diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 2ec355003524..1d55d838a342 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ obj-y += mediatek/ obj-y += amlogic/ obj-y += qcom/ +obj-y += realtek/ obj-y += renesas/ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ obj-$(CONFIG_SOC_SAMSUNG) += samsung/ diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file mode 100644 index 000000000000..be75c1889c61 --- /dev/null +++ b/drivers/soc/realtek/Kconfig @@ -0,0 +1,13 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +if ARCH_REALTEK || COMPILE_TEST + +config REALTEK_SOC + tristate "Realtek chip info" + default ARCH_REALTEK + select SOC_BUS + help + Say 'y' here to enable support for SoC info on Realtek RTD1195 and + RTD1295 SoC families. + If unsure, say 'n'. + +endif diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new file mode 100644 index 000000000000..49900273905b --- /dev/null +++ b/drivers/soc/realtek/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +obj-$(CONFIG_REALTEK_SOC) += chip.o diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file mode 100644 index 000000000000..9d13422e9936 --- /dev/null +++ b/drivers/soc/realtek/chip.c @@ -0,0 +1,164 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Realtek System-on-Chip info + * + * Copyright (c) 2017-2019 Andreas Färber + */ + +#include <linux/io.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +#define REG_CHIP_ID 0x0 +#define REG_CHIP_REV 0x4 + +struct rtd_soc_revision { + const char *name; + u32 chip_rev; +}; + +static const struct rtd_soc_revision rtd1195_revisions[] = { + { "A", 0x00000000 }, + { "B", 0x00010000 }, + { "C", 0x00020000 }, + { "D", 0x00030000 }, + { } +}; + +static const struct rtd_soc_revision rtd1295_revisions[] = { + { "A00", 0x00000000 }, + { "A01", 0x00010000 }, + { "B00", 0x00020000 }, + { "B01", 0x00030000 }, + { } +}; + +struct rtd_soc { + u32 chip_id; + const char *family; + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); + const struct rtd_soc_revision *revisions; + const char *codename; +}; + +static const char *default_name(struct device *dev, const struct rtd_soc *s) +{ + return s->family; +} + +static const struct rtd_soc rtd_soc_families[] = { + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, +}; + +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { + const struct rtd_soc *family = &rtd_soc_families[i]; + + if (family->chip_id == chip_id) + return family; + } + return NULL; +} + +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 chip_rev) +{ + if (family) { + const struct rtd_soc_revision *rev = family->revisions; + + while (rev && rev->name) { + if (rev->chip_rev == chip_rev) + return rev->name; + rev++; + } + } + return "unknown"; +} + +static int rtd_soc_probe(struct platform_device *pdev) +{ + const struct rtd_soc *s; + struct soc_device_attribute *soc_dev_attr; + struct soc_device *soc_dev; + struct device_node *node; + void __iomem *base; + u32 chip_id, chip_rev; + + base = of_iomap(pdev->dev.of_node, 0); + if (!base) + return -ENODEV; + + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); + if (!soc_dev_attr) + return -ENOMEM; + + chip_id = readl_relaxed(base + REG_CHIP_ID); + chip_rev = readl_relaxed(base + REG_CHIP_REV); + + node = of_find_node_by_path("/"); + of_property_read_string(node, "model", &soc_dev_attr->machine); + of_node_put(node); + + s = rtd_soc_by_chip_id(chip_id); + + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", + (s && s->codename) ? s->codename : + ((s && s->family) ? s->family : "Digital Home Center")); + + if (likely(s && s->get_name)) + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); + else + soc_dev_attr->soc_id = "unknown"; + + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); + + soc_dev = soc_device_register(soc_dev_attr); + if (IS_ERR(soc_dev)) { + kfree(soc_dev_attr->family); + kfree(soc_dev_attr); + return PTR_ERR(soc_dev); + } + + platform_set_drvdata(pdev, soc_dev); + + dev_info(soc_device_to_device(soc_dev), + "%s %s (0x%08x) rev %s (0x%08x) detected\n", + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, + soc_dev_attr->revision, chip_rev); + + return 0; +} + +static int rtd_soc_remove(struct platform_device *pdev) +{ + struct soc_device *soc_dev = platform_get_drvdata(pdev); + + soc_device_unregister(soc_dev); + + return 0; +} + +static const struct of_device_id rtd_soc_dt_ids[] = { + { .compatible = "realtek,rtd1195-chip" }, + { } +}; + +static struct platform_driver rtd_soc_driver = { + .probe = rtd_soc_probe, + .remove = rtd_soc_remove, + .driver = { + .name = "rtd1195-soc", + .of_match_table = rtd_soc_dt_ids, + }, +}; +module_platform_driver(rtd_soc_driver); + +MODULE_DESCRIPTION("Realtek SoC identification"); +MODULE_LICENSE("GPL"); -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:45 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:45 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Am 03.11.19 um 02:36 schrieb Andreas Färber: > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/realtek/Kconfig | 13 ++++ > drivers/soc/realtek/Makefile | 2 + > drivers/soc/realtek/chip.c | 164 +++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 181 insertions(+) > create mode 100644 drivers/soc/realtek/Kconfig > create mode 100644 drivers/soc/realtek/Makefile > create mode 100644 drivers/soc/realtek/chip.c This patch forgets to add drivers/soc/realtek/ to MAINTAINERS. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2019-11-03 1:45 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:45 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Am 03.11.19 um 02:36 schrieb Andreas Färber: > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/realtek/Kconfig | 13 ++++ > drivers/soc/realtek/Makefile | 2 + > drivers/soc/realtek/chip.c | 164 +++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 181 insertions(+) > create mode 100644 drivers/soc/realtek/Kconfig > create mode 100644 drivers/soc/realtek/Makefile > create mode 100644 drivers/soc/realtek/chip.c This patch forgets to add drivers/soc/realtek/ to MAINTAINERS. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-03 1:36 ` Andreas Färber @ 2019-11-11 4:56 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 4:56 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Greg Kroah-Hartman, Rafael J. Wysocki Use of soc_device_to_device() in driver modules causes a build failure. Given that the helper is nicely documented in include/linux/sys_soc.h, let's export it as GPL symbol. struct soc_device is local to soc.c, so it can't be inlined into the header or into driver code. This still handles only the case that CONFIG_SOC_BUS is enabled. Same as commit da65a1589dacc7ec44ea0557a14d70a39d991f32 ("base: soc: Provide a dummy implementation of soc_device_match()") we'd need to provide a dummy inline implementation to cope with COMPILE_TEST, too. Reported-by: kbuild test robot <lkp@intel.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/base/soc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/soc.c b/drivers/base/soc.c index 4af11a423475..72848587cd51 100644 --- a/drivers/base/soc.c +++ b/drivers/base/soc.c @@ -41,6 +41,7 @@ struct device *soc_device_to_device(struct soc_device *soc_dev) { return &soc_dev->dev; } +EXPORT_SYMBOL_GPL(soc_device_to_device); static umode_t soc_attribute_mode(struct kobject *kobj, struct attribute *attr, -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 4:56 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 4:56 UTC (permalink / raw) To: linux-realtek-soc Cc: Geert Uytterhoeven, Rafael J. Wysocki, Greg Kroah-Hartman, linux-kernel, Bjorn Andersson, Lee Jones, Andreas Färber, linux-arm-kernel Use of soc_device_to_device() in driver modules causes a build failure. Given that the helper is nicely documented in include/linux/sys_soc.h, let's export it as GPL symbol. struct soc_device is local to soc.c, so it can't be inlined into the header or into driver code. This still handles only the case that CONFIG_SOC_BUS is enabled. Same as commit da65a1589dacc7ec44ea0557a14d70a39d991f32 ("base: soc: Provide a dummy implementation of soc_device_match()") we'd need to provide a dummy inline implementation to cope with COMPILE_TEST, too. Reported-by: kbuild test robot <lkp@intel.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/base/soc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/soc.c b/drivers/base/soc.c index 4af11a423475..72848587cd51 100644 --- a/drivers/base/soc.c +++ b/drivers/base/soc.c @@ -41,6 +41,7 @@ struct device *soc_device_to_device(struct soc_device *soc_dev) { return &soc_dev->dev; } +EXPORT_SYMBOL_GPL(soc_device_to_device); static umode_t soc_attribute_mode(struct kobject *kobj, struct attribute *attr, -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 4:56 ` Andreas Färber @ 2019-11-11 5:27 ` Greg Kroah-Hartman -1 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-11 5:27 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > Use of soc_device_to_device() in driver modules causes a build failure. > Given that the helper is nicely documented in include/linux/sys_soc.h, > let's export it as GPL symbol. I thought we were fixing the soc drivers to not need this. What happened to that effort? I thought I had patches in my tree (or someone's tree) that did some of this work already, such that this symbol isn't needed anymore. thanks, greg k-h ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 5:27 ` Greg Kroah-Hartman 0 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-11 5:27 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Rafael J. Wysocki, linux-kernel, Bjorn Andersson, Lee Jones, linux-arm-kernel On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > Use of soc_device_to_device() in driver modules causes a build failure. > Given that the helper is nicely documented in include/linux/sys_soc.h, > let's export it as GPL symbol. I thought we were fixing the soc drivers to not need this. What happened to that effort? I thought I had patches in my tree (or someone's tree) that did some of this work already, such that this symbol isn't needed anymore. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 5:27 ` Greg Kroah-Hartman @ 2019-11-11 5:42 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 5:42 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki Hi Greg, Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >> Use of soc_device_to_device() in driver modules causes a build failure. >> Given that the helper is nicely documented in include/linux/sys_soc.h, >> let's export it as GPL symbol. > > I thought we were fixing the soc drivers to not need this. What > happened to that effort? I thought I had patches in my tree (or > someone's tree) that did some of this work already, such that this > symbol isn't needed anymore. I do still see this function used in next-20191108 in drivers/soc/. I'll be happy to adjust my RFC driver if someone points me to how! Given the current struct layout, a type cast might work (but ugly). Or if we stay with my current RFC driver design, we could use the platform_device instead of the soc_device (which would clutter the screen more than "soc soc0:") or resort to pr_info() w/o device. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 5:42 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 5:42 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Rafael J. Wysocki, linux-kernel, Bjorn Andersson, Lee Jones, linux-arm-kernel Hi Greg, Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >> Use of soc_device_to_device() in driver modules causes a build failure. >> Given that the helper is nicely documented in include/linux/sys_soc.h, >> let's export it as GPL symbol. > > I thought we were fixing the soc drivers to not need this. What > happened to that effort? I thought I had patches in my tree (or > someone's tree) that did some of this work already, such that this > symbol isn't needed anymore. I do still see this function used in next-20191108 in drivers/soc/. I'll be happy to adjust my RFC driver if someone points me to how! Given the current struct layout, a type cast might work (but ugly). Or if we stay with my current RFC driver design, we could use the platform_device instead of the soc_device (which would clutter the screen more than "soc soc0:") or resort to pr_info() w/o device. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 5:42 ` Andreas Färber @ 2019-11-11 6:40 ` Greg Kroah-Hartman -1 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-11 6:40 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > Hi Greg, > > Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >> Use of soc_device_to_device() in driver modules causes a build failure. > >> Given that the helper is nicely documented in include/linux/sys_soc.h, > >> let's export it as GPL symbol. > > > > I thought we were fixing the soc drivers to not need this. What > > happened to that effort? I thought I had patches in my tree (or > > someone's tree) that did some of this work already, such that this > > symbol isn't needed anymore. > > I do still see this function used in next-20191108 in drivers/soc/. > > I'll be happy to adjust my RFC driver if someone points me to how! Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs entries") for how you can just use the default attributes for the soc to create the needed sysfs files, instead of having to do it "by hand" which is racy and incorrect. > Given the current struct layout, a type cast might work (but ugly). > Or if we stay with my current RFC driver design, we could use the > platform_device instead of the soc_device (which would clutter the > screen more than "soc soc0:") or resort to pr_info() w/o device. Ick, no, don't cast blindly. What do you need the pointer for? Is this for in-tree code? thanks, greg k-h ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 6:40 ` Greg Kroah-Hartman 0 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-11 6:40 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Rafael J. Wysocki, linux-kernel, Bjorn Andersson, Lee Jones, linux-arm-kernel On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > Hi Greg, > > Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >> Use of soc_device_to_device() in driver modules causes a build failure. > >> Given that the helper is nicely documented in include/linux/sys_soc.h, > >> let's export it as GPL symbol. > > > > I thought we were fixing the soc drivers to not need this. What > > happened to that effort? I thought I had patches in my tree (or > > someone's tree) that did some of this work already, such that this > > symbol isn't needed anymore. > > I do still see this function used in next-20191108 in drivers/soc/. > > I'll be happy to adjust my RFC driver if someone points me to how! Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs entries") for how you can just use the default attributes for the soc to create the needed sysfs files, instead of having to do it "by hand" which is racy and incorrect. > Given the current struct layout, a type cast might work (but ugly). > Or if we stay with my current RFC driver design, we could use the > platform_device instead of the soc_device (which would clutter the > screen more than "soc soc0:") or resort to pr_info() w/o device. Ick, no, don't cast blindly. What do you need the pointer for? Is this for in-tree code? thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 6:40 ` Greg Kroah-Hartman (?) (?) @ 2019-11-11 20:10 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Hartley Sweeten, Alexander Sverdlin, Tony Lindgren, linux-omap, Michal Simek, Kevin Hilman, linux-amlogic, Thierry Reding Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >> Hi Greg, >> >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>> let's export it as GPL symbol. >>> >>> I thought we were fixing the soc drivers to not need this. What >>> happened to that effort? I thought I had patches in my tree (or >>> someone's tree) that did some of this work already, such that this >>> symbol isn't needed anymore. >> >> I do still see this function used in next-20191108 in drivers/soc/. >> >> I'll be happy to adjust my RFC driver if someone points me to how! > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > entries") for how you can just use the default attributes for the soc to > create the needed sysfs files, instead of having to do it "by hand" > which is racy and incorrect. Unrelated. >> Given the current struct layout, a type cast might work (but ugly). >> Or if we stay with my current RFC driver design, we could use the >> platform_device instead of the soc_device (which would clutter the >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > for in-tree code? No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ As I indicated above, I used it for a dev_info(), which I can easily avoid by using pr_info() instead: diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index e5078c6731fd..f9380e831659 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, soc_dev); - dev_info(soc_device_to_device(soc_dev), - "%s %s (0x%08x) rev %s (0x%08x) detected\n", + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, soc_dev_attr->revision, chip_rev); But as I said, there is still in-tree code using this helper: arch/arm/mach-ep93xx/core.c: return soc_device_to_device(soc_dev); Returned from ep93xx_init_soc(), which is passed through by ep93xx_init_devices(): arch/arm/mach-ep93xx/adssphere.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/edb93xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/gesbc9312.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/micro9.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/simone.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/snappercl15.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/vision_ep9307.c: ep93xx_init_devices(); Return value unused everywhere. arch/arm/mach-imx/cpu.c: return soc_device_to_device(soc_dev); Used as return value of imx_soc_device_init(): arch/arm/mach-imx/mach-imx6q.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sl.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sx.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6ul.c: parent = imx_soc_device_init(); These do a NULL check and pass it to of_platform_default_populate(). arch/arm/mach-imx/mach-imx7d.c: parent = imx_soc_device_init(); This one only does a NULL check. arch/arm/mach-imx/mach-imx7ulp.c: of_platform_default_populate(NULL, NULL, imx_soc_device_init()); Speaks for itself. arch/arm/mach-mxs/mach-mxs.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). arch/arm/mach-omap2/id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). arch/arm/mach-zynq/common.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). drivers/soc/amlogic/meson-gx-socinfo.c: dev = soc_device_to_device(soc_dev); Used for dev_info(). CONFIG_MESON_GX_SOCINFO is bool, thus not affected. drivers/soc/amlogic/meson-mx-socinfo.c: dev_info(soc_device_to_device(soc_dev), "Amlogic %s %s detected\n", Speaks for itself. CONFIG_MESON_MX_SOCINFO is bool, thus not affected. drivers/soc/tegra/fuse/fuse-tegra.c: return soc_device_to_device(dev); Returned from tegra_soc_device_register(). For arm64 NULL-checked only, but also used for arm in arch/arm/mach-tegra/tegra.c:tegra_dt_init(), which passes it to of_platform_default_populate(). drivers/soc/ux500/ux500-soc-id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-integrator.c: dev = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_board_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_build_attr); Speaks for itself. So, not counting my unmerged Realtek driver, * we have two cases of struct device being used for dev_info(), which could be cleaned up with device-less pr_info(), I could post a patch, * frequent usage in arm/mach-* for of_platform_default_populate(), this seems most difficult to replace if we neither want to cast nor expose the struct, * some simply unused, which could be refactored to return void, and * some for device_create_file(), which could probably be avoided with custom_attr_group. It also raises the question of whether new arm platforms such as RTD1195 (mach-realtek) should attempt to use of_platform_default_populate() with the soc_device somehow, or if not, whether those platforms should be refactored to consistently no longer do so? I believe in the Broken Window Theory, i.e. fixing what we can before mistakes get copied and propagate further in code; but here I don't see a perspective for getting rid of soc_device_to_device() completely to prevent new usages, nor can I test all of those platforms myself. Has a cleanup based on custom_attr_group been attempted already and is waiting on patches to get reviewed and merged through maintainer trees, or do we need to prepare new cleanup patches here? A search for "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 20:10 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >> Hi Greg, >> >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>> let's export it as GPL symbol. >>> >>> I thought we were fixing the soc drivers to not need this. What >>> happened to that effort? I thought I had patches in my tree (or >>> someone's tree) that did some of this work already, such that this >>> symbol isn't needed anymore. >> >> I do still see this function used in next-20191108 in drivers/soc/. >> >> I'll be happy to adjust my RFC driver if someone points me to how! > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > entries") for how you can just use the default attributes for the soc to > create the needed sysfs files, instead of having to do it "by hand" > which is racy and incorrect. Unrelated. >> Given the current struct layout, a type cast might work (but ugly). >> Or if we stay with my current RFC driver design, we could use the >> platform_device instead of the soc_device (which would clutter the >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > for in-tree code? No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ As I indicated above, I used it for a dev_info(), which I can easily avoid by using pr_info() instead: diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index e5078c6731fd..f9380e831659 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, soc_dev); - dev_info(soc_device_to_device(soc_dev), - "%s %s (0x%08x) rev %s (0x%08x) detected\n", + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, soc_dev_attr->revision, chip_rev); But as I said, there is still in-tree code using this helper: arch/arm/mach-ep93xx/core.c: return soc_device_to_device(soc_dev); Returned from ep93xx_init_soc(), which is passed through by ep93xx_init_devices(): arch/arm/mach-ep93xx/adssphere.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/edb93xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/gesbc9312.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/micro9.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/simone.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/snappercl15.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/vision_ep9307.c: ep93xx_init_devices(); Return value unused everywhere. arch/arm/mach-imx/cpu.c: return soc_device_to_device(soc_dev); Used as return value of imx_soc_device_init(): arch/arm/mach-imx/mach-imx6q.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sl.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sx.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6ul.c: parent = imx_soc_device_init(); These do a NULL check and pass it to of_platform_default_populate(). arch/arm/mach-imx/mach-imx7d.c: parent = imx_soc_device_init(); This one only does a NULL check. arch/arm/mach-imx/mach-imx7ulp.c: of_platform_default_populate(NULL, NULL, imx_soc_device_init()); Speaks for itself. arch/arm/mach-mxs/mach-mxs.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). arch/arm/mach-omap2/id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). arch/arm/mach-zynq/common.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). drivers/soc/amlogic/meson-gx-socinfo.c: dev = soc_device_to_device(soc_dev); Used for dev_info(). CONFIG_MESON_GX_SOCINFO is bool, thus not affected. drivers/soc/amlogic/meson-mx-socinfo.c: dev_info(soc_device_to_device(soc_dev), "Amlogic %s %s detected\n", Speaks for itself. CONFIG_MESON_MX_SOCINFO is bool, thus not affected. drivers/soc/tegra/fuse/fuse-tegra.c: return soc_device_to_device(dev); Returned from tegra_soc_device_register(). For arm64 NULL-checked only, but also used for arm in arch/arm/mach-tegra/tegra.c:tegra_dt_init(), which passes it to of_platform_default_populate(). drivers/soc/ux500/ux500-soc-id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-integrator.c: dev = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_board_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_build_attr); Speaks for itself. So, not counting my unmerged Realtek driver, * we have two cases of struct device being used for dev_info(), which could be cleaned up with device-less pr_info(), I could post a patch, * frequent usage in arm/mach-* for of_platform_default_populate(), this seems most difficult to replace if we neither want to cast nor expose the struct, * some simply unused, which could be refactored to return void, and * some for device_create_file(), which could probably be avoided with custom_attr_group. It also raises the question of whether new arm platforms such as RTD1195 (mach-realtek) should attempt to use of_platform_default_populate() with the soc_device somehow, or if not, whether those platforms should be refactored to consistently no longer do so? I believe in the Broken Window Theory, i.e. fixing what we can before mistakes get copied and propagate further in code; but here I don't see a perspective for getting rid of soc_device_to_device() completely to prevent new usages, nor can I test all of those platforms myself. Has a cleanup based on custom_attr_group been attempted already and is waiting on patches to get reviewed and merged through maintainer trees, or do we need to prepare new cleanup patches here? A search for "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 20:10 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >> Hi Greg, >> >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>> let's export it as GPL symbol. >>> >>> I thought we were fixing the soc drivers to not need this. What >>> happened to that effort? I thought I had patches in my tree (or >>> someone's tree) that did some of this work already, such that this >>> symbol isn't needed anymore. >> >> I do still see this function used in next-20191108 in drivers/soc/. >> >> I'll be happy to adjust my RFC driver if someone points me to how! > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > entries") for how you can just use the default attributes for the soc to > create the needed sysfs files, instead of having to do it "by hand" > which is racy and incorrect. Unrelated. >> Given the current struct layout, a type cast might work (but ugly). >> Or if we stay with my current RFC driver design, we could use the >> platform_device instead of the soc_device (which would clutter the >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > for in-tree code? No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ As I indicated above, I used it for a dev_info(), which I can easily avoid by using pr_info() instead: diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index e5078c6731fd..f9380e831659 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, soc_dev); - dev_info(soc_device_to_device(soc_dev), - "%s %s (0x%08x) rev %s (0x%08x) detected\n", + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, soc_dev_attr->revision, chip_rev); But as I said, there is still in-tree code using this helper: arch/arm/mach-ep93xx/core.c: return soc_device_to_device(soc_dev); Returned from ep93xx_init_soc(), which is passed through by ep93xx_init_devices(): arch/arm/mach-ep93xx/adssphere.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/edb93xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/gesbc9312.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/micro9.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/simone.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/snappercl15.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/vision_ep9307.c: ep93xx_init_devices(); Return value unused everywhere. arch/arm/mach-imx/cpu.c: return soc_device_to_device(soc_dev); Used as return value of imx_soc_device_init(): arch/arm/mach-imx/mach-imx6q.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sl.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sx.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6ul.c: parent = imx_soc_device_init(); These do a NULL check and pass it to of_platform_default_populate(). arch/arm/mach-imx/mach-imx7d.c: parent = imx_soc_device_init(); This one only does a NULL check. arch/arm/mach-imx/mach-imx7ulp.c: of_platform_default_populate(NULL, NULL, imx_soc_device_init()); Speaks for itself. arch/arm/mach-mxs/mach-mxs.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). arch/arm/mach-omap2/id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). arch/arm/mach-zynq/common.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). drivers/soc/amlogic/meson-gx-socinfo.c: dev = soc_device_to_device(soc_dev); Used for dev_info(). CONFIG_MESON_GX_SOCINFO is bool, thus not affected. drivers/soc/amlogic/meson-mx-socinfo.c: dev_info(soc_device_to_device(soc_dev), "Amlogic %s %s detected\n", Speaks for itself. CONFIG_MESON_MX_SOCINFO is bool, thus not affected. drivers/soc/tegra/fuse/fuse-tegra.c: return soc_device_to_device(dev); Returned from tegra_soc_device_register(). For arm64 NULL-checked only, but also used for arm in arch/arm/mach-tegra/tegra.c:tegra_dt_init(), which passes it to of_platform_default_populate(). drivers/soc/ux500/ux500-soc-id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-integrator.c: dev = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_board_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_build_attr); Speaks for itself. So, not counting my unmerged Realtek driver, * we have two cases of struct device being used for dev_info(), which could be cleaned up with device-less pr_info(), I could post a patch, * frequent usage in arm/mach-* for of_platform_default_populate(), this seems most difficult to replace if we neither want to cast nor expose the struct, * some simply unused, which could be refactored to return void, and * some for device_create_file(), which could probably be avoided with custom_attr_group. It also raises the question of whether new arm platforms such as RTD1195 (mach-realtek) should attempt to use of_platform_default_populate() with the soc_device somehow, or if not, whether those platforms should be refactored to consistently no longer do so? I believe in the Broken Window Theory, i.e. fixing what we can before mistakes get copied and propagate further in code; but here I don't see a perspective for getting rid of soc_device_to_device() completely to prevent new usages, nor can I test all of those platforms myself. Has a cleanup based on custom_attr_group been attempted already and is waiting on patches to get reviewed and merged through maintainer trees, or do we need to prepare new cleanup patches here? A search for "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-11 20:10 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-11 20:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Hartley Sweeten, Alexander Sverdlin, Tony Lindgren, linux-omap, Michal Simek, Kevin Hilman, linux-amlogic, Thierry Reding, Jonathan Hunter, linux-tegra, Linus Walleij Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >> Hi Greg, >> >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>> let's export it as GPL symbol. >>> >>> I thought we were fixing the soc drivers to not need this. What >>> happened to that effort? I thought I had patches in my tree (or >>> someone's tree) that did some of this work already, such that this >>> symbol isn't needed anymore. >> >> I do still see this function used in next-20191108 in drivers/soc/. >> >> I'll be happy to adjust my RFC driver if someone points me to how! > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > entries") for how you can just use the default attributes for the soc to > create the needed sysfs files, instead of having to do it "by hand" > which is racy and incorrect. Unrelated. >> Given the current struct layout, a type cast might work (but ugly). >> Or if we stay with my current RFC driver design, we could use the >> platform_device instead of the soc_device (which would clutter the >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > for in-tree code? No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ As I indicated above, I used it for a dev_info(), which I can easily avoid by using pr_info() instead: diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index e5078c6731fd..f9380e831659 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, soc_dev); - dev_info(soc_device_to_device(soc_dev), - "%s %s (0x%08x) rev %s (0x%08x) detected\n", + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, soc_dev_attr->revision, chip_rev); But as I said, there is still in-tree code using this helper: arch/arm/mach-ep93xx/core.c: return soc_device_to_device(soc_dev); Returned from ep93xx_init_soc(), which is passed through by ep93xx_init_devices(): arch/arm/mach-ep93xx/adssphere.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/edb93xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/gesbc9312.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/micro9.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/simone.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/snappercl15.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/vision_ep9307.c: ep93xx_init_devices(); Return value unused everywhere. arch/arm/mach-imx/cpu.c: return soc_device_to_device(soc_dev); Used as return value of imx_soc_device_init(): arch/arm/mach-imx/mach-imx6q.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sl.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sx.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6ul.c: parent = imx_soc_device_init(); These do a NULL check and pass it to of_platform_default_populate(). arch/arm/mach-imx/mach-imx7d.c: parent = imx_soc_device_init(); This one only does a NULL check. arch/arm/mach-imx/mach-imx7ulp.c: of_platform_default_populate(NULL, NULL, imx_soc_device_init()); Speaks for itself. arch/arm/mach-mxs/mach-mxs.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). arch/arm/mach-omap2/id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). arch/arm/mach-zynq/common.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). drivers/soc/amlogic/meson-gx-socinfo.c: dev = soc_device_to_device(soc_dev); Used for dev_info(). CONFIG_MESON_GX_SOCINFO is bool, thus not affected. drivers/soc/amlogic/meson-mx-socinfo.c: dev_info(soc_device_to_device(soc_dev), "Amlogic %s %s detected\n", Speaks for itself. CONFIG_MESON_MX_SOCINFO is bool, thus not affected. drivers/soc/tegra/fuse/fuse-tegra.c: return soc_device_to_device(dev); Returned from tegra_soc_device_register(). For arm64 NULL-checked only, but also used for arm in arch/arm/mach-tegra/tegra.c:tegra_dt_init(), which passes it to of_platform_default_populate(). drivers/soc/ux500/ux500-soc-id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-integrator.c: dev = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_board_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_build_attr); Speaks for itself. So, not counting my unmerged Realtek driver, * we have two cases of struct device being used for dev_info(), which could be cleaned up with device-less pr_info(), I could post a patch, * frequent usage in arm/mach-* for of_platform_default_populate(), this seems most difficult to replace if we neither want to cast nor expose the struct, * some simply unused, which could be refactored to return void, and * some for device_create_file(), which could probably be avoided with custom_attr_group. It also raises the question of whether new arm platforms such as RTD1195 (mach-realtek) should attempt to use of_platform_default_populate() with the soc_device somehow, or if not, whether those platforms should be refactored to consistently no longer do so? I believe in the Broken Window Theory, i.e. fixing what we can before mistakes get copied and propagate further in code; but here I don't see a perspective for getting rid of soc_device_to_device() completely to prevent new usages, nor can I test all of those platforms myself. Has a cleanup based on custom_attr_group been attempted already and is waiting on patches to get reviewed and merged through maintainer trees, or do we need to prepare new cleanup patches here? A search for "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 20:10 ` Andreas Färber (?) (?) @ 2019-11-12 0:29 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 0:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel Am 11.11.19 um 21:10 schrieb Andreas Färber: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>> Hi Greg, >>> >>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>> let's export it as GPL symbol. >>>> >>>> I thought we were fixing the soc drivers to not need this. What >>>> happened to that effort? I thought I had patches in my tree (or >>>> someone's tree) that did some of this work already, such that this >>>> symbol isn't needed anymore. >>> >>> I do still see this function used in next-20191108 in drivers/soc/. >>> >>> I'll be happy to adjust my RFC driver if someone points me to how! >> >> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >> entries") for how you can just use the default attributes for the soc to >> create the needed sysfs files, instead of having to do it "by hand" >> which is racy and incorrect. > > Unrelated. > >>> Given the current struct layout, a type cast might work (but ugly). >>> Or if we stay with my current RFC driver design, we could use the >>> platform_device instead of the soc_device (which would clutter the >>> screen more than "soc soc0:") or resort to pr_info() w/o device. >> >> Ick, no, don't cast blindly. What do you need the pointer for? Is this >> for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); > Tested and squashed in my tree. > > But as I said, there is still in-tree code using this helper: [snip] > So, not counting my unmerged Realtek driver, > * we have two cases of struct device being used for dev_info(), which > could be cleaned up with device-less pr_info(), I could post a patch, Patch sent: https://patchwork.kernel.org/patch/11237949/ (untested) > * frequent usage in arm/mach-* for of_platform_default_populate(), this > seems most difficult to replace if we neither want to cast nor expose > the struct, One clever way might be to implement a new of_soc_default_populate() in drivers/base/soc.c that takes a soc_device instead of device, doing the conversion inside soc.c and calling of_platform_default_populate() from there. Then we could convert present users to pass around soc_device instead of device, with a perspective to make soc_device_to_device() static inside base/soc.c. sys_soc.h does not presently #include any OF headers, so the declaration may need to go into of_platform.h and to consider CONFIG_SOC_BUS. Will require compile-testing for each platform and ideally some kbuild bot passes to get right, so not a quick shot. While at it, an of_soc_device_register() variant could fill soc_device_attribute::machine in common code instead of each platform duplicating to read this from the DT root node's model property. > * some simply unused, which could be refactored to return void, and Patch sent: https://patchwork.kernel.org/patch/11237971/ (untested) > * some for device_create_file(), which could probably be avoided with > custom_attr_group. > > It also raises the question of whether new arm platforms such as RTD1195 > (mach-realtek) should attempt to use of_platform_default_populate() with > the soc_device somehow, or if not, whether those platforms should be > refactored to consistently no longer do so? > > I believe in the Broken Window Theory, i.e. fixing what we can before > mistakes get copied and propagate further in code; but here I don't see > a perspective for getting rid of soc_device_to_device() completely to > prevent new usages, nor can I test all of those platforms myself. > > Has a cleanup based on custom_attr_group been attempted already and is > waiting on patches to get reviewed and merged through maintainer trees, > or do we need to prepare new cleanup patches here? A search for > "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Actually I don't find a single user of custom_attr_group in linux-next, which may be because the patch introducing it is from October and people are waiting on the next -rc1 before they can merge patches using it? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 0:29 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 0:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 11.11.19 um 21:10 schrieb Andreas Färber: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>> Hi Greg, >>> >>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>> let's export it as GPL symbol. >>>> >>>> I thought we were fixing the soc drivers to not need this. What >>>> happened to that effort? I thought I had patches in my tree (or >>>> someone's tree) that did some of this work already, such that this >>>> symbol isn't needed anymore. >>> >>> I do still see this function used in next-20191108 in drivers/soc/. >>> >>> I'll be happy to adjust my RFC driver if someone points me to how! >> >> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >> entries") for how you can just use the default attributes for the soc to >> create the needed sysfs files, instead of having to do it "by hand" >> which is racy and incorrect. > > Unrelated. > >>> Given the current struct layout, a type cast might work (but ugly). >>> Or if we stay with my current RFC driver design, we could use the >>> platform_device instead of the soc_device (which would clutter the >>> screen more than "soc soc0:") or resort to pr_info() w/o device. >> >> Ick, no, don't cast blindly. What do you need the pointer for? Is this >> for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); > Tested and squashed in my tree. > > But as I said, there is still in-tree code using this helper: [snip] > So, not counting my unmerged Realtek driver, > * we have two cases of struct device being used for dev_info(), which > could be cleaned up with device-less pr_info(), I could post a patch, Patch sent: https://patchwork.kernel.org/patch/11237949/ (untested) > * frequent usage in arm/mach-* for of_platform_default_populate(), this > seems most difficult to replace if we neither want to cast nor expose > the struct, One clever way might be to implement a new of_soc_default_populate() in drivers/base/soc.c that takes a soc_device instead of device, doing the conversion inside soc.c and calling of_platform_default_populate() from there. Then we could convert present users to pass around soc_device instead of device, with a perspective to make soc_device_to_device() static inside base/soc.c. sys_soc.h does not presently #include any OF headers, so the declaration may need to go into of_platform.h and to consider CONFIG_SOC_BUS. Will require compile-testing for each platform and ideally some kbuild bot passes to get right, so not a quick shot. While at it, an of_soc_device_register() variant could fill soc_device_attribute::machine in common code instead of each platform duplicating to read this from the DT root node's model property. > * some simply unused, which could be refactored to return void, and Patch sent: https://patchwork.kernel.org/patch/11237971/ (untested) > * some for device_create_file(), which could probably be avoided with > custom_attr_group. > > It also raises the question of whether new arm platforms such as RTD1195 > (mach-realtek) should attempt to use of_platform_default_populate() with > the soc_device somehow, or if not, whether those platforms should be > refactored to consistently no longer do so? > > I believe in the Broken Window Theory, i.e. fixing what we can before > mistakes get copied and propagate further in code; but here I don't see > a perspective for getting rid of soc_device_to_device() completely to > prevent new usages, nor can I test all of those platforms myself. > > Has a cleanup based on custom_attr_group been attempted already and is > waiting on patches to get reviewed and merged through maintainer trees, > or do we need to prepare new cleanup patches here? A search for > "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Actually I don't find a single user of custom_attr_group in linux-next, which may be because the patch introducing it is from October and people are waiting on the next -rc1 before they can merge patches using it? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 0:29 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 0:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 11.11.19 um 21:10 schrieb Andreas Färber: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>> Hi Greg, >>> >>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>> let's export it as GPL symbol. >>>> >>>> I thought we were fixing the soc drivers to not need this. What >>>> happened to that effort? I thought I had patches in my tree (or >>>> someone's tree) that did some of this work already, such that this >>>> symbol isn't needed anymore. >>> >>> I do still see this function used in next-20191108 in drivers/soc/. >>> >>> I'll be happy to adjust my RFC driver if someone points me to how! >> >> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >> entries") for how you can just use the default attributes for the soc to >> create the needed sysfs files, instead of having to do it "by hand" >> which is racy and incorrect. > > Unrelated. > >>> Given the current struct layout, a type cast might work (but ugly). >>> Or if we stay with my current RFC driver design, we could use the >>> platform_device instead of the soc_device (which would clutter the >>> screen more than "soc soc0:") or resort to pr_info() w/o device. >> >> Ick, no, don't cast blindly. What do you need the pointer for? Is this >> for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); > Tested and squashed in my tree. > > But as I said, there is still in-tree code using this helper: [snip] > So, not counting my unmerged Realtek driver, > * we have two cases of struct device being used for dev_info(), which > could be cleaned up with device-less pr_info(), I could post a patch, Patch sent: https://patchwork.kernel.org/patch/11237949/ (untested) > * frequent usage in arm/mach-* for of_platform_default_populate(), this > seems most difficult to replace if we neither want to cast nor expose > the struct, One clever way might be to implement a new of_soc_default_populate() in drivers/base/soc.c that takes a soc_device instead of device, doing the conversion inside soc.c and calling of_platform_default_populate() from there. Then we could convert present users to pass around soc_device instead of device, with a perspective to make soc_device_to_device() static inside base/soc.c. sys_soc.h does not presently #include any OF headers, so the declaration may need to go into of_platform.h and to consider CONFIG_SOC_BUS. Will require compile-testing for each platform and ideally some kbuild bot passes to get right, so not a quick shot. While at it, an of_soc_device_register() variant could fill soc_device_attribute::machine in common code instead of each platform duplicating to read this from the DT root node's model property. > * some simply unused, which could be refactored to return void, and Patch sent: https://patchwork.kernel.org/patch/11237971/ (untested) > * some for device_create_file(), which could probably be avoided with > custom_attr_group. > > It also raises the question of whether new arm platforms such as RTD1195 > (mach-realtek) should attempt to use of_platform_default_populate() with > the soc_device somehow, or if not, whether those platforms should be > refactored to consistently no longer do so? > > I believe in the Broken Window Theory, i.e. fixing what we can before > mistakes get copied and propagate further in code; but here I don't see > a perspective for getting rid of soc_device_to_device() completely to > prevent new usages, nor can I test all of those platforms myself. > > Has a cleanup based on custom_attr_group been attempted already and is > waiting on patches to get reviewed and merged through maintainer trees, > or do we need to prepare new cleanup patches here? A search for > "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Actually I don't find a single user of custom_attr_group in linux-next, which may be because the patch introducing it is from October and people are waiting on the next -rc1 before they can merge patches using it? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 0:29 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 0:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 11.11.19 um 21:10 schrieb Andreas Färber: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>> Hi Greg, >>> >>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>> let's export it as GPL symbol. >>>> >>>> I thought we were fixing the soc drivers to not need this. What >>>> happened to that effort? I thought I had patches in my tree (or >>>> someone's tree) that did some of this work already, such that this >>>> symbol isn't needed anymore. >>> >>> I do still see this function used in next-20191108 in drivers/soc/. >>> >>> I'll be happy to adjust my RFC driver if someone points me to how! >> >> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >> entries") for how you can just use the default attributes for the soc to >> create the needed sysfs files, instead of having to do it "by hand" >> which is racy and incorrect. > > Unrelated. > >>> Given the current struct layout, a type cast might work (but ugly). >>> Or if we stay with my current RFC driver design, we could use the >>> platform_device instead of the soc_device (which would clutter the >>> screen more than "soc soc0:") or resort to pr_info() w/o device. >> >> Ick, no, don't cast blindly. What do you need the pointer for? Is this >> for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); > Tested and squashed in my tree. > > But as I said, there is still in-tree code using this helper: [snip] > So, not counting my unmerged Realtek driver, > * we have two cases of struct device being used for dev_info(), which > could be cleaned up with device-less pr_info(), I could post a patch, Patch sent: https://patchwork.kernel.org/patch/11237949/ (untested) > * frequent usage in arm/mach-* for of_platform_default_populate(), this > seems most difficult to replace if we neither want to cast nor expose > the struct, One clever way might be to implement a new of_soc_default_populate() in drivers/base/soc.c that takes a soc_device instead of device, doing the conversion inside soc.c and calling of_platform_default_populate() from there. Then we could convert present users to pass around soc_device instead of device, with a perspective to make soc_device_to_device() static inside base/soc.c. sys_soc.h does not presently #include any OF headers, so the declaration may need to go into of_platform.h and to consider CONFIG_SOC_BUS. Will require compile-testing for each platform and ideally some kbuild bot passes to get right, so not a quick shot. While at it, an of_soc_device_register() variant could fill soc_device_attribute::machine in common code instead of each platform duplicating to read this from the DT root node's model property. > * some simply unused, which could be refactored to return void, and Patch sent: https://patchwork.kernel.org/patch/11237971/ (untested) > * some for device_create_file(), which could probably be avoided with > custom_attr_group. > > It also raises the question of whether new arm platforms such as RTD1195 > (mach-realtek) should attempt to use of_platform_default_populate() with > the soc_device somehow, or if not, whether those platforms should be > refactored to consistently no longer do so? > > I believe in the Broken Window Theory, i.e. fixing what we can before > mistakes get copied and propagate further in code; but here I don't see > a perspective for getting rid of soc_device_to_device() completely to > prevent new usages, nor can I test all of those platforms myself. > > Has a cleanup based on custom_attr_group been attempted already and is > waiting on patches to get reviewed and merged through maintainer trees, > or do we need to prepare new cleanup patches here? A search for > "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Actually I don't find a single user of custom_attr_group in linux-next, which may be because the patch introducing it is from October and people are waiting on the next -rc1 before they can merge patches using it? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-11 20:10 ` Andreas Färber (?) (?) @ 2019-11-12 5:23 ` Greg Kroah-Hartman -1 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-12 5:23 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >> Hi Greg, > >> > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>> let's export it as GPL symbol. > >>> > >>> I thought we were fixing the soc drivers to not need this. What > >>> happened to that effort? I thought I had patches in my tree (or > >>> someone's tree) that did some of this work already, such that this > >>> symbol isn't needed anymore. > >> > >> I do still see this function used in next-20191108 in drivers/soc/. > >> > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > entries") for how you can just use the default attributes for the soc to > > create the needed sysfs files, instead of having to do it "by hand" > > which is racy and incorrect. > > Unrelated. > > >> Given the current struct layout, a type cast might work (but ugly). > >> Or if we stay with my current RFC driver design, we could use the > >> platform_device instead of the soc_device (which would clutter the > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); First off, the driver should not be spitting out noise for when all goes well like this :) Anyway, just use the pdev pointer here, not the soc dev as that is NOT a pointer you have control over (as is evident by the fact that you need this call to try to get it.) I'll look at your other instances later when I've had my coffee... thanks, greg k-h ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 5:23 ` Greg Kroah-Hartman 0 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-12 5:23 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >> Hi Greg, > >> > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>> let's export it as GPL symbol. > >>> > >>> I thought we were fixing the soc drivers to not need this. What > >>> happened to that effort? I thought I had patches in my tree (or > >>> someone's tree) that did some of this work already, such that this > >>> symbol isn't needed anymore. > >> > >> I do still see this function used in next-20191108 in drivers/soc/. > >> > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > entries") for how you can just use the default attributes for the soc to > > create the needed sysfs files, instead of having to do it "by hand" > > which is racy and incorrect. > > Unrelated. > > >> Given the current struct layout, a type cast might work (but ugly). > >> Or if we stay with my current RFC driver design, we could use the > >> platform_device instead of the soc_device (which would clutter the > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); First off, the driver should not be spitting out noise for when all goes well like this :) Anyway, just use the pdev pointer here, not the soc dev as that is NOT a pointer you have control over (as is evident by the fact that you need this call to try to get it.) I'll look at your other instances later when I've had my coffee... thanks, greg k-h _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 5:23 ` Greg Kroah-Hartman 0 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-12 5:23 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >> Hi Greg, > >> > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>> let's export it as GPL symbol. > >>> > >>> I thought we were fixing the soc drivers to not need this. What > >>> happened to that effort? I thought I had patches in my tree (or > >>> someone's tree) that did some of this work already, such that this > >>> symbol isn't needed anymore. > >> > >> I do still see this function used in next-20191108 in drivers/soc/. > >> > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > entries") for how you can just use the default attributes for the soc to > > create the needed sysfs files, instead of having to do it "by hand" > > which is racy and incorrect. > > Unrelated. > > >> Given the current struct layout, a type cast might work (but ugly). > >> Or if we stay with my current RFC driver design, we could use the > >> platform_device instead of the soc_device (which would clutter the > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); First off, the driver should not be spitting out noise for when all goes well like this :) Anyway, just use the pdev pointer here, not the soc dev as that is NOT a pointer you have control over (as is evident by the fact that you need this call to try to get it.) I'll look at your other instances later when I've had my coffee... thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 5:23 ` Greg Kroah-Hartman 0 siblings, 0 replies; 117+ messages in thread From: Greg Kroah-Hartman @ 2019-11-12 5:23 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Lee Jones, Bjorn Andersson, Geert Uytterhoeven, Rafael J. Wysocki, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Hartley Sweeten, Alexander Sverdlin, Tony Lindgren, linux-omap, Michal Simek, Kevin Hilman, linux-amlogic, Thierry Reding, Jonathan Hunter, linux-tegra, Linus Walleij On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >> Hi Greg, > >> > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>> let's export it as GPL symbol. > >>> > >>> I thought we were fixing the soc drivers to not need this. What > >>> happened to that effort? I thought I had patches in my tree (or > >>> someone's tree) that did some of this work already, such that this > >>> symbol isn't needed anymore. > >> > >> I do still see this function used in next-20191108 in drivers/soc/. > >> > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > entries") for how you can just use the default attributes for the soc to > > create the needed sysfs files, instead of having to do it "by hand" > > which is racy and incorrect. > > Unrelated. > > >> Given the current struct layout, a type cast might work (but ugly). > >> Or if we stay with my current RFC driver design, we could use the > >> platform_device instead of the soc_device (which would clutter the > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > for in-tree code? > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > As I indicated above, I used it for a dev_info(), which I can easily > avoid by using pr_info() instead: > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > index e5078c6731fd..f9380e831659 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, soc_dev); > > - dev_info(soc_device_to_device(soc_dev), > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > soc_dev_attr->revision, chip_rev); First off, the driver should not be spitting out noise for when all goes well like this :) Anyway, just use the pdev pointer here, not the soc dev as that is NOT a pointer you have control over (as is evident by the fact that you need this call to try to get it.) I'll look at your other instances later when I've had my coffee... thanks, greg k-h ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-12 5:23 ` Greg Kroah-Hartman (?) (?) @ 2019-11-12 7:29 ` Uwe Kleine-König -1 siblings, 0 replies; 117+ messages in thread From: Uwe Kleine-König @ 2019-11-12 7:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > >> Hi Greg, > > >> > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > >>>> let's export it as GPL symbol. > > >>> > > >>> I thought we were fixing the soc drivers to not need this. What > > >>> happened to that effort? I thought I had patches in my tree (or > > >>> someone's tree) that did some of this work already, such that this > > >>> symbol isn't needed anymore. > > >> > > >> I do still see this function used in next-20191108 in drivers/soc/. > > >> > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > entries") for how you can just use the default attributes for the soc to > > > create the needed sysfs files, instead of having to do it "by hand" > > > which is racy and incorrect. > > > > Unrelated. > > > > >> Given the current struct layout, a type cast might work (but ugly). > > >> Or if we stay with my current RFC driver design, we could use the > > >> platform_device instead of the soc_device (which would clutter the > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > for in-tree code? > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > As I indicated above, I used it for a dev_info(), which I can easily > > avoid by using pr_info() instead: > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > index e5078c6731fd..f9380e831659 100644 > > --- a/drivers/soc/realtek/chip.c > > +++ b/drivers/soc/realtek/chip.c > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, soc_dev); > > > > - dev_info(soc_device_to_device(soc_dev), > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > soc_dev_attr->revision, chip_rev); > > First off, the driver should not be spitting out noise for when all goes > well like this :) I didn't follow the discussion closely, but I think I want to object here a bit. While I agree that each driver emitting some stuff to the log buffer is hardly helpful, seeing the exact SoC details is indeed useful at times. With my Debian kernel team member hat on, I'd say keep this information. This way the SoC details make it into kernel bug reports without effort on our side. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 7:29 ` Uwe Kleine-König 0 siblings, 0 replies; 117+ messages in thread From: Uwe Kleine-König @ 2019-11-12 7:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > >> Hi Greg, > > >> > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > >>>> let's export it as GPL symbol. > > >>> > > >>> I thought we were fixing the soc drivers to not need this. What > > >>> happened to that effort? I thought I had patches in my tree (or > > >>> someone's tree) that did some of this work already, such that this > > >>> symbol isn't needed anymore. > > >> > > >> I do still see this function used in next-20191108 in drivers/soc/. > > >> > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > entries") for how you can just use the default attributes for the soc to > > > create the needed sysfs files, instead of having to do it "by hand" > > > which is racy and incorrect. > > > > Unrelated. > > > > >> Given the current struct layout, a type cast might work (but ugly). > > >> Or if we stay with my current RFC driver design, we could use the > > >> platform_device instead of the soc_device (which would clutter the > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > for in-tree code? > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > As I indicated above, I used it for a dev_info(), which I can easily > > avoid by using pr_info() instead: > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > index e5078c6731fd..f9380e831659 100644 > > --- a/drivers/soc/realtek/chip.c > > +++ b/drivers/soc/realtek/chip.c > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, soc_dev); > > > > - dev_info(soc_device_to_device(soc_dev), > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > soc_dev_attr->revision, chip_rev); > > First off, the driver should not be spitting out noise for when all goes > well like this :) I didn't follow the discussion closely, but I think I want to object here a bit. While I agree that each driver emitting some stuff to the log buffer is hardly helpful, seeing the exact SoC details is indeed useful at times. With my Debian kernel team member hat on, I'd say keep this information. This way the SoC details make it into kernel bug reports without effort on our side. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ | _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 7:29 ` Uwe Kleine-König 0 siblings, 0 replies; 117+ messages in thread From: Uwe Kleine-König @ 2019-11-12 7:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > >> Hi Greg, > > >> > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > >>>> let's export it as GPL symbol. > > >>> > > >>> I thought we were fixing the soc drivers to not need this. What > > >>> happened to that effort? I thought I had patches in my tree (or > > >>> someone's tree) that did some of this work already, such that this > > >>> symbol isn't needed anymore. > > >> > > >> I do still see this function used in next-20191108 in drivers/soc/. > > >> > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > entries") for how you can just use the default attributes for the soc to > > > create the needed sysfs files, instead of having to do it "by hand" > > > which is racy and incorrect. > > > > Unrelated. > > > > >> Given the current struct layout, a type cast might work (but ugly). > > >> Or if we stay with my current RFC driver design, we could use the > > >> platform_device instead of the soc_device (which would clutter the > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > for in-tree code? > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > As I indicated above, I used it for a dev_info(), which I can easily > > avoid by using pr_info() instead: > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > index e5078c6731fd..f9380e831659 100644 > > --- a/drivers/soc/realtek/chip.c > > +++ b/drivers/soc/realtek/chip.c > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, soc_dev); > > > > - dev_info(soc_device_to_device(soc_dev), > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > soc_dev_attr->revision, chip_rev); > > First off, the driver should not be spitting out noise for when all goes > well like this :) I didn't follow the discussion closely, but I think I want to object here a bit. While I agree that each driver emitting some stuff to the log buffer is hardly helpful, seeing the exact SoC details is indeed useful at times. With my Debian kernel team member hat on, I'd say keep this information. This way the SoC details make it into kernel bug reports without effort on our side. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 7:29 ` Uwe Kleine-König 0 siblings, 0 replies; 117+ messages in thread From: Uwe Kleine-König @ 2019-11-12 7:29 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Andreas Färber, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > >> Hi Greg, > > >> > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > >>>> let's export it as GPL symbol. > > >>> > > >>> I thought we were fixing the soc drivers to not need this. What > > >>> happened to that effort? I thought I had patches in my tree (or > > >>> someone's tree) that did some of this work already, such that this > > >>> symbol isn't needed anymore. > > >> > > >> I do still see this function used in next-20191108 in drivers/soc/. > > >> > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > entries") for how you can just use the default attributes for the soc to > > > create the needed sysfs files, instead of having to do it "by hand" > > > which is racy and incorrect. > > > > Unrelated. > > > > >> Given the current struct layout, a type cast might work (but ugly). > > >> Or if we stay with my current RFC driver design, we could use the > > >> platform_device instead of the soc_device (which would clutter the > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > for in-tree code? > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > As I indicated above, I used it for a dev_info(), which I can easily > > avoid by using pr_info() instead: > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > index e5078c6731fd..f9380e831659 100644 > > --- a/drivers/soc/realtek/chip.c > > +++ b/drivers/soc/realtek/chip.c > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > platform_set_drvdata(pdev, soc_dev); > > > > - dev_info(soc_device_to_device(soc_dev), > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > soc_dev_attr->revision, chip_rev); > > First off, the driver should not be spitting out noise for when all goes > well like this :) I didn't follow the discussion closely, but I think I want to object here a bit. While I agree that each driver emitting some stuff to the log buffer is hardly helpful, seeing the exact SoC details is indeed useful at times. With my Debian kernel team member hat on, I'd say keep this information. This way the SoC details make it into kernel bug reports without effort on our side. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 117+ messages in thread
* Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-12 7:29 ` Uwe Kleine-König (?) (?) @ 2019-11-12 10:47 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 10:47 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>> let's export it as GPL symbol. >>>>>> >>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>> someone's tree) that did some of this work already, such that this >>>>>> symbol isn't needed anymore. >>>>> >>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>> >>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>> >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>> entries") for how you can just use the default attributes for the soc to >>>> create the needed sysfs files, instead of having to do it "by hand" >>>> which is racy and incorrect. >>> >>> Unrelated. >>> >>>>> Given the current struct layout, a type cast might work (but ugly). >>>>> Or if we stay with my current RFC driver design, we could use the >>>>> platform_device instead of the soc_device (which would clutter the >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>> >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>> for in-tree code? >>> >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>> >>> As I indicated above, I used it for a dev_info(), which I can easily >>> avoid by using pr_info() instead: >>> >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>> index e5078c6731fd..f9380e831659 100644 >>> --- a/drivers/soc/realtek/chip.c >>> +++ b/drivers/soc/realtek/chip.c >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>> >>> platform_set_drvdata(pdev, soc_dev); >>> >>> - dev_info(soc_device_to_device(soc_dev), >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>> soc_dev_attr->revision, chip_rev); >> >> First off, the driver should not be spitting out noise for when all goes >> well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Seconded. For example, RTD1295 will support LSADC only from revision B00 on (and it's not the first time I'm seeing such things in the industry). So if a user complains, it will be helpful to see that information. Referencing your Amlogic review, with all due respect for its authors, the common framework here just lets that information evaporate into the deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but ordinary users will at most upload dmesg output to a Bugzilla ticket. And it was precisely info-level boot output from the Amlogic GX driver that made me aware of this common framework and inspired me to later contribute such a driver elsewhere myself. That's not a bad effect. ;) So if anything, we should standardize that output and move it into soc_device_register(): "<family> <soc_id> [rev <revision>] detected" with suitable NULL checks? (what I did above for Realtek, minus hex) The info level seems correct to me - it allows people to use a different log_level if they only care about warnings or errors on the console; it's not debug info for that driver, except in my case the accompanying hex numbers that I'd be happy to drop in favor of standardization. Another aspect here is that the overall amount of soc_device_register() users is just an estimated one third above the analysis shared before. In particular server platforms, be it arm64 or x86_64, that potentially have more than one SoC integrated in a multi-socket configuration, don't feed into this soc bus at all! Therefore my comment that dev_info()-printed "soc soc0:" is kind of useless if there's only one SoC on those boards. I'm not aware of any tool or a more common file aggregating this information, certainly not /proc/cpuinfo and I'm not aware of any special "lssoc" tool either. And if there's no ACPI/DMI driver feeding support-relevant information into this framework to be generally useful, I don't expect the big distros to spend time on improving its usability. So if we move info output into base/soc.c, we could continue using dev_info() with "soc"-grep'able prefix in the hopes that someday we'll have more than one soc device on the bus and will need to distinguish; otherwise yes, pr_info() would change the output format for Amlogic (and so would a harmonization of the text), but does anyone really care in practice? Tools shouldn't be relying on its output format, and humans will understand equally either way. Finally, arch/arm seems unique in that it has the machine_desc mechanism that allows individual SoCs to force creating their soc_device early and using it as parent for further DT-created platform_devices. With arm64 we've lost that ability, and nios2 is not using it either. A bad side effect (with SUSE hat on) is that this parent design pattern does not allow to build such drivers as modules, which means that distro configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get unnecessary code creep as new platforms get added over time (beyond the basic clk, pinctrl, tty and maybe timer). Even if it were possible to call into a driver module that early, using it as parent would seem to imply that all the references by its children would not allow to unload the module, which I'd consider a flawed design for such an "optional" read-once driver. If we want the device hierarchy to have a soc root then most DT based platforms will have a /soc DT node anyway (although no device_type = "soc") that we probably could have a device registered for in common code rather than each SoC platform handling that differently? That might then make soc_register_device() not the creator of the device (if pre-existent) but the supplier of data to that core device, which should then allow to unload the data provider with just the sysfs data disappearing until re-inserted (speeding up the develop-and-test cycle on say not-so-resource-constrained platforms). On the other hand, one might argue that such information should just be parsed by EBBR-conformant bootloaders and be passed to the kernel via standard UEFI interfaces and DMI tables. But I'm not aware of Barebox having implemented any of that yet, and even for U-Boot (e.g., Realtek based consumer devices...) not everyone has the GPL sources or tools to update their bootloader. So, having the kernel we control gather information relevant to kernel developers does make some sense to me. Thoughts? Regards, Andreas P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into this fundamental use case discussion. arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-tegra/tegra.c: struct device *parent = tegra_soc_device_register(); arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); arch/nios2/platform/platform.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/bcm/brcmstb/common.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/qcom/socinfo.c: qs->soc_dev = soc_device_register(&qs->attr); drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/renesas/renesas-soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/samsung/exynos-chipid.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); drivers/soc/ux500/ux500-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-integrator.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-realview.c: soc_dev = soc_device_register(soc_dev_attr); -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-12 10:47 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 10:47 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>> let's export it as GPL symbol. >>>>>> >>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>> someone's tree) that did some of this work already, such that this >>>>>> symbol isn't needed anymore. >>>>> >>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>> >>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>> >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>> entries") for how you can just use the default attributes for the soc to >>>> create the needed sysfs files, instead of having to do it "by hand" >>>> which is racy and incorrect. >>> >>> Unrelated. >>> >>>>> Given the current struct layout, a type cast might work (but ugly). >>>>> Or if we stay with my current RFC driver design, we could use the >>>>> platform_device instead of the soc_device (which would clutter the >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>> >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>> for in-tree code? >>> >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>> >>> As I indicated above, I used it for a dev_info(), which I can easily >>> avoid by using pr_info() instead: >>> >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>> index e5078c6731fd..f9380e831659 100644 >>> --- a/drivers/soc/realtek/chip.c >>> +++ b/drivers/soc/realtek/chip.c >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>> >>> platform_set_drvdata(pdev, soc_dev); >>> >>> - dev_info(soc_device_to_device(soc_dev), >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>> soc_dev_attr->revision, chip_rev); >> >> First off, the driver should not be spitting out noise for when all goes >> well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Seconded. For example, RTD1295 will support LSADC only from revision B00 on (and it's not the first time I'm seeing such things in the industry). So if a user complains, it will be helpful to see that information. Referencing your Amlogic review, with all due respect for its authors, the common framework here just lets that information evaporate into the deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but ordinary users will at most upload dmesg output to a Bugzilla ticket. And it was precisely info-level boot output from the Amlogic GX driver that made me aware of this common framework and inspired me to later contribute such a driver elsewhere myself. That's not a bad effect. ;) So if anything, we should standardize that output and move it into soc_device_register(): "<family> <soc_id> [rev <revision>] detected" with suitable NULL checks? (what I did above for Realtek, minus hex) The info level seems correct to me - it allows people to use a different log_level if they only care about warnings or errors on the console; it's not debug info for that driver, except in my case the accompanying hex numbers that I'd be happy to drop in favor of standardization. Another aspect here is that the overall amount of soc_device_register() users is just an estimated one third above the analysis shared before. In particular server platforms, be it arm64 or x86_64, that potentially have more than one SoC integrated in a multi-socket configuration, don't feed into this soc bus at all! Therefore my comment that dev_info()-printed "soc soc0:" is kind of useless if there's only one SoC on those boards. I'm not aware of any tool or a more common file aggregating this information, certainly not /proc/cpuinfo and I'm not aware of any special "lssoc" tool either. And if there's no ACPI/DMI driver feeding support-relevant information into this framework to be generally useful, I don't expect the big distros to spend time on improving its usability. So if we move info output into base/soc.c, we could continue using dev_info() with "soc"-grep'able prefix in the hopes that someday we'll have more than one soc device on the bus and will need to distinguish; otherwise yes, pr_info() would change the output format for Amlogic (and so would a harmonization of the text), but does anyone really care in practice? Tools shouldn't be relying on its output format, and humans will understand equally either way. Finally, arch/arm seems unique in that it has the machine_desc mechanism that allows individual SoCs to force creating their soc_device early and using it as parent for further DT-created platform_devices. With arm64 we've lost that ability, and nios2 is not using it either. A bad side effect (with SUSE hat on) is that this parent design pattern does not allow to build such drivers as modules, which means that distro configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get unnecessary code creep as new platforms get added over time (beyond the basic clk, pinctrl, tty and maybe timer). Even if it were possible to call into a driver module that early, using it as parent would seem to imply that all the references by its children would not allow to unload the module, which I'd consider a flawed design for such an "optional" read-once driver. If we want the device hierarchy to have a soc root then most DT based platforms will have a /soc DT node anyway (although no device_type = "soc") that we probably could have a device registered for in common code rather than each SoC platform handling that differently? That might then make soc_register_device() not the creator of the device (if pre-existent) but the supplier of data to that core device, which should then allow to unload the data provider with just the sysfs data disappearing until re-inserted (speeding up the develop-and-test cycle on say not-so-resource-constrained platforms). On the other hand, one might argue that such information should just be parsed by EBBR-conformant bootloaders and be passed to the kernel via standard UEFI interfaces and DMI tables. But I'm not aware of Barebox having implemented any of that yet, and even for U-Boot (e.g., Realtek based consumer devices...) not everyone has the GPL sources or tools to update their bootloader. So, having the kernel we control gather information relevant to kernel developers does make some sense to me. Thoughts? Regards, Andreas P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into this fundamental use case discussion. arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-tegra/tegra.c: struct device *parent = tegra_soc_device_register(); arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); arch/nios2/platform/platform.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/bcm/brcmstb/common.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/qcom/socinfo.c: qs->soc_dev = soc_device_register(&qs->attr); drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/renesas/renesas-soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/samsung/exynos-chipid.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); drivers/soc/ux500/ux500-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-integrator.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-realview.c: soc_dev = soc_device_register(soc_dev_attr); -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-12 10:47 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 10:47 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>> let's export it as GPL symbol. >>>>>> >>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>> someone's tree) that did some of this work already, such that this >>>>>> symbol isn't needed anymore. >>>>> >>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>> >>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>> >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>> entries") for how you can just use the default attributes for the soc to >>>> create the needed sysfs files, instead of having to do it "by hand" >>>> which is racy and incorrect. >>> >>> Unrelated. >>> >>>>> Given the current struct layout, a type cast might work (but ugly). >>>>> Or if we stay with my current RFC driver design, we could use the >>>>> platform_device instead of the soc_device (which would clutter the >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>> >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>> for in-tree code? >>> >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>> >>> As I indicated above, I used it for a dev_info(), which I can easily >>> avoid by using pr_info() instead: >>> >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>> index e5078c6731fd..f9380e831659 100644 >>> --- a/drivers/soc/realtek/chip.c >>> +++ b/drivers/soc/realtek/chip.c >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>> >>> platform_set_drvdata(pdev, soc_dev); >>> >>> - dev_info(soc_device_to_device(soc_dev), >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>> soc_dev_attr->revision, chip_rev); >> >> First off, the driver should not be spitting out noise for when all goes >> well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Seconded. For example, RTD1295 will support LSADC only from revision B00 on (and it's not the first time I'm seeing such things in the industry). So if a user complains, it will be helpful to see that information. Referencing your Amlogic review, with all due respect for its authors, the common framework here just lets that information evaporate into the deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but ordinary users will at most upload dmesg output to a Bugzilla ticket. And it was precisely info-level boot output from the Amlogic GX driver that made me aware of this common framework and inspired me to later contribute such a driver elsewhere myself. That's not a bad effect. ;) So if anything, we should standardize that output and move it into soc_device_register(): "<family> <soc_id> [rev <revision>] detected" with suitable NULL checks? (what I did above for Realtek, minus hex) The info level seems correct to me - it allows people to use a different log_level if they only care about warnings or errors on the console; it's not debug info for that driver, except in my case the accompanying hex numbers that I'd be happy to drop in favor of standardization. Another aspect here is that the overall amount of soc_device_register() users is just an estimated one third above the analysis shared before. In particular server platforms, be it arm64 or x86_64, that potentially have more than one SoC integrated in a multi-socket configuration, don't feed into this soc bus at all! Therefore my comment that dev_info()-printed "soc soc0:" is kind of useless if there's only one SoC on those boards. I'm not aware of any tool or a more common file aggregating this information, certainly not /proc/cpuinfo and I'm not aware of any special "lssoc" tool either. And if there's no ACPI/DMI driver feeding support-relevant information into this framework to be generally useful, I don't expect the big distros to spend time on improving its usability. So if we move info output into base/soc.c, we could continue using dev_info() with "soc"-grep'able prefix in the hopes that someday we'll have more than one soc device on the bus and will need to distinguish; otherwise yes, pr_info() would change the output format for Amlogic (and so would a harmonization of the text), but does anyone really care in practice? Tools shouldn't be relying on its output format, and humans will understand equally either way. Finally, arch/arm seems unique in that it has the machine_desc mechanism that allows individual SoCs to force creating their soc_device early and using it as parent for further DT-created platform_devices. With arm64 we've lost that ability, and nios2 is not using it either. A bad side effect (with SUSE hat on) is that this parent design pattern does not allow to build such drivers as modules, which means that distro configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get unnecessary code creep as new platforms get added over time (beyond the basic clk, pinctrl, tty and maybe timer). Even if it were possible to call into a driver module that early, using it as parent would seem to imply that all the references by its children would not allow to unload the module, which I'd consider a flawed design for such an "optional" read-once driver. If we want the device hierarchy to have a soc root then most DT based platforms will have a /soc DT node anyway (although no device_type = "soc") that we probably could have a device registered for in common code rather than each SoC platform handling that differently? That might then make soc_register_device() not the creator of the device (if pre-existent) but the supplier of data to that core device, which should then allow to unload the data provider with just the sysfs data disappearing until re-inserted (speeding up the develop-and-test cycle on say not-so-resource-constrained platforms). On the other hand, one might argue that such information should just be parsed by EBBR-conformant bootloaders and be passed to the kernel via standard UEFI interfaces and DMI tables. But I'm not aware of Barebox having implemented any of that yet, and even for U-Boot (e.g., Realtek based consumer devices...) not everyone has the GPL sources or tools to update their bootloader. So, having the kernel we control gather information relevant to kernel developers does make some sense to me. Thoughts? Regards, Andreas P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into this fundamental use case discussion. arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-tegra/tegra.c: struct device *parent = tegra_soc_device_register(); arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); arch/nios2/platform/platform.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/bcm/brcmstb/common.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/qcom/socinfo.c: qs->soc_dev = soc_device_register(&qs->attr); drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/renesas/renesas-soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/samsung/exynos-chipid.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); drivers/soc/ux500/ux500-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-integrator.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-realview.c: soc_dev = soc_device_register(soc_dev_attr); -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-12 10:47 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-12 10:47 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Rob Herring, boot-architecture Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>> let's export it as GPL symbol. >>>>>> >>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>> someone's tree) that did some of this work already, such that this >>>>>> symbol isn't needed anymore. >>>>> >>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>> >>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>> >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>> entries") for how you can just use the default attributes for the soc to >>>> create the needed sysfs files, instead of having to do it "by hand" >>>> which is racy and incorrect. >>> >>> Unrelated. >>> >>>>> Given the current struct layout, a type cast might work (but ugly). >>>>> Or if we stay with my current RFC driver design, we could use the >>>>> platform_device instead of the soc_device (which would clutter the >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>> >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>> for in-tree code? >>> >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>> >>> As I indicated above, I used it for a dev_info(), which I can easily >>> avoid by using pr_info() instead: >>> >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>> index e5078c6731fd..f9380e831659 100644 >>> --- a/drivers/soc/realtek/chip.c >>> +++ b/drivers/soc/realtek/chip.c >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>> >>> platform_set_drvdata(pdev, soc_dev); >>> >>> - dev_info(soc_device_to_device(soc_dev), >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>> soc_dev_attr->revision, chip_rev); >> >> First off, the driver should not be spitting out noise for when all goes >> well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Seconded. For example, RTD1295 will support LSADC only from revision B00 on (and it's not the first time I'm seeing such things in the industry). So if a user complains, it will be helpful to see that information. Referencing your Amlogic review, with all due respect for its authors, the common framework here just lets that information evaporate into the deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but ordinary users will at most upload dmesg output to a Bugzilla ticket. And it was precisely info-level boot output from the Amlogic GX driver that made me aware of this common framework and inspired me to later contribute such a driver elsewhere myself. That's not a bad effect. ;) So if anything, we should standardize that output and move it into soc_device_register(): "<family> <soc_id> [rev <revision>] detected" with suitable NULL checks? (what I did above for Realtek, minus hex) The info level seems correct to me - it allows people to use a different log_level if they only care about warnings or errors on the console; it's not debug info for that driver, except in my case the accompanying hex numbers that I'd be happy to drop in favor of standardization. Another aspect here is that the overall amount of soc_device_register() users is just an estimated one third above the analysis shared before. In particular server platforms, be it arm64 or x86_64, that potentially have more than one SoC integrated in a multi-socket configuration, don't feed into this soc bus at all! Therefore my comment that dev_info()-printed "soc soc0:" is kind of useless if there's only one SoC on those boards. I'm not aware of any tool or a more common file aggregating this information, certainly not /proc/cpuinfo and I'm not aware of any special "lssoc" tool either. And if there's no ACPI/DMI driver feeding support-relevant information into this framework to be generally useful, I don't expect the big distros to spend time on improving its usability. So if we move info output into base/soc.c, we could continue using dev_info() with "soc"-grep'able prefix in the hopes that someday we'll have more than one soc device on the bus and will need to distinguish; otherwise yes, pr_info() would change the output format for Amlogic (and so would a harmonization of the text), but does anyone really care in practice? Tools shouldn't be relying on its output format, and humans will understand equally either way. Finally, arch/arm seems unique in that it has the machine_desc mechanism that allows individual SoCs to force creating their soc_device early and using it as parent for further DT-created platform_devices. With arm64 we've lost that ability, and nios2 is not using it either. A bad side effect (with SUSE hat on) is that this parent design pattern does not allow to build such drivers as modules, which means that distro configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get unnecessary code creep as new platforms get added over time (beyond the basic clk, pinctrl, tty and maybe timer). Even if it were possible to call into a driver module that early, using it as parent would seem to imply that all the references by its children would not allow to unload the module, which I'd consider a flawed design for such an "optional" read-once driver. If we want the device hierarchy to have a soc root then most DT based platforms will have a /soc DT node anyway (although no device_type = "soc") that we probably could have a device registered for in common code rather than each SoC platform handling that differently? That might then make soc_register_device() not the creator of the device (if pre-existent) but the supplier of data to that core device, which should then allow to unload the data provider with just the sysfs data disappearing until re-inserted (speeding up the develop-and-test cycle on say not-so-resource-constrained platforms). On the other hand, one might argue that such information should just be parsed by EBBR-conformant bootloaders and be passed to the kernel via standard UEFI interfaces and DMI tables. But I'm not aware of Barebox having implemented any of that yet, and even for U-Boot (e.g., Realtek based consumer devices...) not everyone has the GPL sources or tools to update their bootloader. So, having the kernel we control gather information relevant to kernel developers does make some sense to me. Thoughts? Regards, Andreas P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into this fundamental use case discussion. arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); arch/arm/mach-tegra/tegra.c: struct device *parent = tegra_soc_device_register(); arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); arch/nios2/platform/platform.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/bcm/brcmstb/common.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/qcom/socinfo.c: qs->soc_dev = soc_device_register(&qs->attr); drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/renesas/renesas-soc.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/samsung/exynos-chipid.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); drivers/soc/ux500/ux500-soc-id.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-integrator.c: soc_dev = soc_device_register(soc_dev_attr); drivers/soc/versatile/soc-realview.c: soc_dev = soc_device_register(soc_dev_attr); -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-12 10:47 ` Andreas Färber (?) (?) @ 2019-11-14 22:09 ` Rob Herring -1 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-14 22:09 UTC (permalink / raw) To: Andreas Färber Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson... On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>> let's export it as GPL symbol. > >>>>>> > >>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>> someone's tree) that did some of this work already, such that this > >>>>>> symbol isn't needed anymore. > >>>>> > >>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>> > >>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>> > >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>> entries") for how you can just use the default attributes for the soc to > >>>> create the needed sysfs files, instead of having to do it "by hand" > >>>> which is racy and incorrect. > >>> > >>> Unrelated. > >>> > >>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>> Or if we stay with my current RFC driver design, we could use the > >>>>> platform_device instead of the soc_device (which would clutter the > >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>> > >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>> for in-tree code? > >>> > >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>> > >>> As I indicated above, I used it for a dev_info(), which I can easily > >>> avoid by using pr_info() instead: > >>> > >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>> index e5078c6731fd..f9380e831659 100644 > >>> --- a/drivers/soc/realtek/chip.c > >>> +++ b/drivers/soc/realtek/chip.c > >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>> > >>> platform_set_drvdata(pdev, soc_dev); > >>> > >>> - dev_info(soc_device_to_device(soc_dev), > >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>> soc_dev_attr->revision, chip_rev); > >> > >> First off, the driver should not be spitting out noise for when all goes > >> well like this :) > > > > I didn't follow the discussion closely, but I think I want to object > > here a bit. While I agree that each driver emitting some stuff to the > > log buffer is hardly helpful, seeing the exact SoC details is indeed > > useful at times. With my Debian kernel team member hat on, I'd say > > keep this information. This way the SoC details make it into kernel bug > > reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. lshw? That works with info from DT, sysfs, and DMI. It did have some endian bugs (written for sparc/power) last time I looked at it 5+ years ago. > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). I for one would like to for this to be consistent. Either we always have an SoC device parent or never. I wouldn't decide based on having a DT node or not either. Generally, we should always have MMIO devices under a bus node and perhaps more than one, but that doesn't always happen. I think building the drivers as modules is a good reason to do away with the parent device. It would also allow getting rid of remaining of_platform_default_populate calls in arm platforms except for auxdata cases. Pretty much that's the ones you list below in arch/arm/. > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Rob > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > > -- > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer > HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-14 22:09 ` Rob Herring 0 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-14 22:09 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., linux-omap, Alexander Sverdlin, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>> let's export it as GPL symbol. > >>>>>> > >>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>> someone's tree) that did some of this work already, such that this > >>>>>> symbol isn't needed anymore. > >>>>> > >>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>> > >>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>> > >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>> entries") for how you can just use the default attributes for the soc to > >>>> create the needed sysfs files, instead of having to do it "by hand" > >>>> which is racy and incorrect. > >>> > >>> Unrelated. > >>> > >>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>> Or if we stay with my current RFC driver design, we could use the > >>>>> platform_device instead of the soc_device (which would clutter the > >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>> > >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>> for in-tree code? > >>> > >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>> > >>> As I indicated above, I used it for a dev_info(), which I can easily > >>> avoid by using pr_info() instead: > >>> > >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>> index e5078c6731fd..f9380e831659 100644 > >>> --- a/drivers/soc/realtek/chip.c > >>> +++ b/drivers/soc/realtek/chip.c > >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>> > >>> platform_set_drvdata(pdev, soc_dev); > >>> > >>> - dev_info(soc_device_to_device(soc_dev), > >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>> soc_dev_attr->revision, chip_rev); > >> > >> First off, the driver should not be spitting out noise for when all goes > >> well like this :) > > > > I didn't follow the discussion closely, but I think I want to object > > here a bit. While I agree that each driver emitting some stuff to the > > log buffer is hardly helpful, seeing the exact SoC details is indeed > > useful at times. With my Debian kernel team member hat on, I'd say > > keep this information. This way the SoC details make it into kernel bug > > reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. lshw? That works with info from DT, sysfs, and DMI. It did have some endian bugs (written for sparc/power) last time I looked at it 5+ years ago. > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). I for one would like to for this to be consistent. Either we always have an SoC device parent or never. I wouldn't decide based on having a DT node or not either. Generally, we should always have MMIO devices under a bus node and perhaps more than one, but that doesn't always happen. I think building the drivers as modules is a good reason to do away with the parent device. It would also allow getting rid of remaining of_platform_default_populate calls in arm platforms except for auxdata cases. Pretty much that's the ones you list below in arch/arm/. > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Rob > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > > -- > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer > HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-14 22:09 ` Rob Herring 0 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-14 22:09 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., linux-omap, Alexander Sverdlin, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>> let's export it as GPL symbol. > >>>>>> > >>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>> someone's tree) that did some of this work already, such that this > >>>>>> symbol isn't needed anymore. > >>>>> > >>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>> > >>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>> > >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>> entries") for how you can just use the default attributes for the soc to > >>>> create the needed sysfs files, instead of having to do it "by hand" > >>>> which is racy and incorrect. > >>> > >>> Unrelated. > >>> > >>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>> Or if we stay with my current RFC driver design, we could use the > >>>>> platform_device instead of the soc_device (which would clutter the > >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>> > >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>> for in-tree code? > >>> > >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>> > >>> As I indicated above, I used it for a dev_info(), which I can easily > >>> avoid by using pr_info() instead: > >>> > >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>> index e5078c6731fd..f9380e831659 100644 > >>> --- a/drivers/soc/realtek/chip.c > >>> +++ b/drivers/soc/realtek/chip.c > >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>> > >>> platform_set_drvdata(pdev, soc_dev); > >>> > >>> - dev_info(soc_device_to_device(soc_dev), > >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>> soc_dev_attr->revision, chip_rev); > >> > >> First off, the driver should not be spitting out noise for when all goes > >> well like this :) > > > > I didn't follow the discussion closely, but I think I want to object > > here a bit. While I agree that each driver emitting some stuff to the > > log buffer is hardly helpful, seeing the exact SoC details is indeed > > useful at times. With my Debian kernel team member hat on, I'd say > > keep this information. This way the SoC details make it into kernel bug > > reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. lshw? That works with info from DT, sysfs, and DMI. It did have some endian bugs (written for sparc/power) last time I looked at it 5+ years ago. > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). I for one would like to for this to be consistent. Either we always have an SoC device parent or never. I wouldn't decide based on having a DT node or not either. Generally, we should always have MMIO devices under a bus node and perhaps more than one, but that doesn't always happen. I think building the drivers as modules is a good reason to do away with the parent device. It would also allow getting rid of remaining of_platform_default_populate calls in arm platforms except for auxdata cases. Pretty much that's the ones you list below in arch/arm/. > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Rob > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > > -- > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer > HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-14 22:09 ` Rob Herring 0 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-14 22:09 UTC (permalink / raw) To: Andreas Färber Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, linux-omap, Alexander Sverdlin, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Architecture Mailman List On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>> let's export it as GPL symbol. > >>>>>> > >>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>> someone's tree) that did some of this work already, such that this > >>>>>> symbol isn't needed anymore. > >>>>> > >>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>> > >>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>> > >>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>> entries") for how you can just use the default attributes for the soc to > >>>> create the needed sysfs files, instead of having to do it "by hand" > >>>> which is racy and incorrect. > >>> > >>> Unrelated. > >>> > >>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>> Or if we stay with my current RFC driver design, we could use the > >>>>> platform_device instead of the soc_device (which would clutter the > >>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>> > >>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>> for in-tree code? > >>> > >>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>> > >>> As I indicated above, I used it for a dev_info(), which I can easily > >>> avoid by using pr_info() instead: > >>> > >>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>> index e5078c6731fd..f9380e831659 100644 > >>> --- a/drivers/soc/realtek/chip.c > >>> +++ b/drivers/soc/realtek/chip.c > >>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>> > >>> platform_set_drvdata(pdev, soc_dev); > >>> > >>> - dev_info(soc_device_to_device(soc_dev), > >>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>> soc_dev_attr->revision, chip_rev); > >> > >> First off, the driver should not be spitting out noise for when all goes > >> well like this :) > > > > I didn't follow the discussion closely, but I think I want to object > > here a bit. While I agree that each driver emitting some stuff to the > > log buffer is hardly helpful, seeing the exact SoC details is indeed > > useful at times. With my Debian kernel team member hat on, I'd say > > keep this information. This way the SoC details make it into kernel bug > > reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. lshw? That works with info from DT, sysfs, and DMI. It did have some endian bugs (written for sparc/power) last time I looked at it 5+ years ago. > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). I for one would like to for this to be consistent. Either we always have an SoC device parent or never. I wouldn't decide based on having a DT node or not either. Generally, we should always have MMIO devices under a bus node and perhaps more than one, but that doesn't always happen. I think building the drivers as modules is a good reason to do away with the parent device. It would also allow getting rid of remaining of_platform_default_populate calls in arm platforms except for auxdata cases. Pretty much that's the ones you list below in arch/arm/. > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Rob > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > > -- > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer > HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-14 22:09 ` Rob Herring ` (2 preceding siblings ...) (?) @ 2019-11-15 11:15 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:15 UTC (permalink / raw) To: Rob Herring Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson... Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: 00000000******** UUID: 30303030-3030-3030-6437-623461336666 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:15 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:15 UTC (permalink / raw) To: Rob Herring Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, U-Boot, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., linux-omap, Alexander Sverdlin, LAKML, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: 00000000******** UUID: 30303030-3030-3030-6437-623461336666 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* [U-Boot] Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:15 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:15 UTC (permalink / raw) To: u-boot Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: 00000000******** UUID: 30303030-3030-3030-6437-623461336666 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:15 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:15 UTC (permalink / raw) To: Rob Herring Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, U-Boot, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., linux-omap, Alexander Sverdlin, LAKML, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: 00000000******** UUID: 30303030-3030-3030-6437-623461336666 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:15 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:15 UTC (permalink / raw) To: Rob Herring Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, linux-omap, Alexander Sverdlin, LAKML, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Architecture Mailman List, U-Boot Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> On the other hand, one might argue that such information should just be >> parsed by EBBR-conformant bootloaders and be passed to the kernel via >> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox >> having implemented any of that yet, and even for U-Boot (e.g., Realtek >> based consumer devices...) not everyone has the GPL sources or tools to >> update their bootloader. So, having the kernel we control gather >> information relevant to kernel developers does make some sense to me. > > UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system. Not sure, that's why I CC'ed the EBBR folks for input. If it's not mandatory today, the next revision of EBBR could just require it - if that's the unified way between SBBR and EBBR. Little point in doing it only for EBBR. On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the non-filled Processor Information delivered by U-Boot: raspi3:~ # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 253 bytes. Table at 0x3CB3E020. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2019.10 Release Date: 10/26/2019 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: 00000000******** UUID: 30303030-3030-3030-6437-623461336666 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: raspberrypi Product Name: rpi Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: raspberrypi Type: Desktop Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 Handle 0x0004, DMI type 4, 48 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Unknown Manufacturer: Unknown ID: 00 00 00 00 00 00 00 00 Version: Unknown Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: None L1 Cache Handle: Not Provided L2 Cache Handle: Not Provided L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Characteristics: None Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-14 22:09 ` Rob Herring (?) (?) @ 2019-11-15 11:49 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:49 UTC (permalink / raw) To: Rob Herring Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> Finally, arch/arm seems unique in that it has the machine_desc mechanism >> that allows individual SoCs to force creating their soc_device early and >> using it as parent for further DT-created platform_devices. With arm64 >> we've lost that ability, and nios2 is not using it either. >> A bad side effect (with SUSE hat on) is that this parent design pattern >> does not allow to build such drivers as modules, which means that distro >> configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get >> unnecessary code creep as new platforms get added over time (beyond the >> basic clk, pinctrl, tty and maybe timer). >> Even if it were possible to call into a driver module that early, using >> it as parent would seem to imply that all the references by its children >> would not allow to unload the module, which I'd consider a flawed design >> for such an "optional" read-once driver. If we want the device hierarchy >> to have a soc root then most DT based platforms will have a /soc DT node >> anyway (although no device_type = "soc") that we probably could have a >> device registered for in common code rather than each SoC platform >> handling that differently? That might then make soc_register_device() >> not the creator of the device (if pre-existent) but the supplier of data >> to that core device, which should then allow to unload the data provider >> with just the sysfs data disappearing until re-inserted (speeding up the >> develop-and-test cycle on say not-so-resource-constrained platforms). > > I for one would like to for this to be consistent. Either we always > have an SoC device parent or never. I wouldn't decide based on having > a DT node or not either. Sure, if we can always be consistent, that might be best. Where I was coming from here is that, if we're not supposed to use soc_device_to_device(), then we have no way to associate an of_node with the soc_device from the outside (and nobody was doing it today, as per my analysis). We'd either need a new helper of_soc_device_register() with additional argument for the node, or it would need to be done entirely in the infrastructure as I suggested, be it by looking for one hardcoded /soc node or for nodes with device_type = "soc". Rob, in light of this discussion, should we start adding the latter property for new DTs such as my new Realtek SoCs, or was there a reason this has not been used consistently outside of powerpc and nios2? Intel/Altera appear to be the only two in arm64, with only three more in arm, none in mips. (BTW my assumption was that we don't follow the booting-without-of.txt documented schema of soc<SOCname> so that we can share .dtsi across differently named SoCs, is that correct?) > Generally, we should always have MMIO devices > under a bus node and perhaps more than one, but that doesn't always > happen. I think building the drivers as modules is a good reason to do > away with the parent device. > > It would also allow getting rid of remaining > of_platform_default_populate calls in arm platforms except for auxdata > cases. Pretty much that's the ones you list below in arch/arm/. The majority was indeed passing in NULL, so yeah, we might clean that up, if someone could come up with a plan of where/how to implement it. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:49 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:49 UTC (permalink / raw) To: Rob Herring Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, DTML, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, LAKML, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> Finally, arch/arm seems unique in that it has the machine_desc mechanism >> that allows individual SoCs to force creating their soc_device early and >> using it as parent for further DT-created platform_devices. With arm64 >> we've lost that ability, and nios2 is not using it either. >> A bad side effect (with SUSE hat on) is that this parent design pattern >> does not allow to build such drivers as modules, which means that distro >> configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get >> unnecessary code creep as new platforms get added over time (beyond the >> basic clk, pinctrl, tty and maybe timer). >> Even if it were possible to call into a driver module that early, using >> it as parent would seem to imply that all the references by its children >> would not allow to unload the module, which I'd consider a flawed design >> for such an "optional" read-once driver. If we want the device hierarchy >> to have a soc root then most DT based platforms will have a /soc DT node >> anyway (although no device_type = "soc") that we probably could have a >> device registered for in common code rather than each SoC platform >> handling that differently? That might then make soc_register_device() >> not the creator of the device (if pre-existent) but the supplier of data >> to that core device, which should then allow to unload the data provider >> with just the sysfs data disappearing until re-inserted (speeding up the >> develop-and-test cycle on say not-so-resource-constrained platforms). > > I for one would like to for this to be consistent. Either we always > have an SoC device parent or never. I wouldn't decide based on having > a DT node or not either. Sure, if we can always be consistent, that might be best. Where I was coming from here is that, if we're not supposed to use soc_device_to_device(), then we have no way to associate an of_node with the soc_device from the outside (and nobody was doing it today, as per my analysis). We'd either need a new helper of_soc_device_register() with additional argument for the node, or it would need to be done entirely in the infrastructure as I suggested, be it by looking for one hardcoded /soc node or for nodes with device_type = "soc". Rob, in light of this discussion, should we start adding the latter property for new DTs such as my new Realtek SoCs, or was there a reason this has not been used consistently outside of powerpc and nios2? Intel/Altera appear to be the only two in arm64, with only three more in arm, none in mips. (BTW my assumption was that we don't follow the booting-without-of.txt documented schema of soc<SOCname> so that we can share .dtsi across differently named SoCs, is that correct?) > Generally, we should always have MMIO devices > under a bus node and perhaps more than one, but that doesn't always > happen. I think building the drivers as modules is a good reason to do > away with the parent device. > > It would also allow getting rid of remaining > of_platform_default_populate calls in arm platforms except for auxdata > cases. Pretty much that's the ones you list below in arch/arm/. The majority was indeed passing in NULL, so yeah, we might clean that up, if someone could come up with a plan of where/how to implement it. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:49 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:49 UTC (permalink / raw) To: Rob Herring Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, DTML, Architecture Mailman List, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, LAKML, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> Finally, arch/arm seems unique in that it has the machine_desc mechanism >> that allows individual SoCs to force creating their soc_device early and >> using it as parent for further DT-created platform_devices. With arm64 >> we've lost that ability, and nios2 is not using it either. >> A bad side effect (with SUSE hat on) is that this parent design pattern >> does not allow to build such drivers as modules, which means that distro >> configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get >> unnecessary code creep as new platforms get added over time (beyond the >> basic clk, pinctrl, tty and maybe timer). >> Even if it were possible to call into a driver module that early, using >> it as parent would seem to imply that all the references by its children >> would not allow to unload the module, which I'd consider a flawed design >> for such an "optional" read-once driver. If we want the device hierarchy >> to have a soc root then most DT based platforms will have a /soc DT node >> anyway (although no device_type = "soc") that we probably could have a >> device registered for in common code rather than each SoC platform >> handling that differently? That might then make soc_register_device() >> not the creator of the device (if pre-existent) but the supplier of data >> to that core device, which should then allow to unload the data provider >> with just the sysfs data disappearing until re-inserted (speeding up the >> develop-and-test cycle on say not-so-resource-constrained platforms). > > I for one would like to for this to be consistent. Either we always > have an SoC device parent or never. I wouldn't decide based on having > a DT node or not either. Sure, if we can always be consistent, that might be best. Where I was coming from here is that, if we're not supposed to use soc_device_to_device(), then we have no way to associate an of_node with the soc_device from the outside (and nobody was doing it today, as per my analysis). We'd either need a new helper of_soc_device_register() with additional argument for the node, or it would need to be done entirely in the infrastructure as I suggested, be it by looking for one hardcoded /soc node or for nodes with device_type = "soc". Rob, in light of this discussion, should we start adding the latter property for new DTs such as my new Realtek SoCs, or was there a reason this has not been used consistently outside of powerpc and nios2? Intel/Altera appear to be the only two in arm64, with only three more in arm, none in mips. (BTW my assumption was that we don't follow the booting-without-of.txt documented schema of soc<SOCname> so that we can share .dtsi across differently named SoCs, is that correct?) > Generally, we should always have MMIO devices > under a bus node and perhaps more than one, but that doesn't always > happen. I think building the drivers as modules is a good reason to do > away with the parent device. > > It would also allow getting rid of remaining > of_platform_default_populate calls in arm platforms except for auxdata > cases. Pretty much that's the ones you list below in arch/arm/. The majority was indeed passing in NULL, so yeah, we might clean that up, if someone could come up with a plan of where/how to implement it. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 11:49 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 11:49 UTC (permalink / raw) To: Rob Herring Cc: Greg Kroah-Hartman, Uwe Kleine-König, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, LAKML, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Architecture Mailman List, DTML Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> Finally, arch/arm seems unique in that it has the machine_desc mechanism >> that allows individual SoCs to force creating their soc_device early and >> using it as parent for further DT-created platform_devices. With arm64 >> we've lost that ability, and nios2 is not using it either. >> A bad side effect (with SUSE hat on) is that this parent design pattern >> does not allow to build such drivers as modules, which means that distro >> configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get >> unnecessary code creep as new platforms get added over time (beyond the >> basic clk, pinctrl, tty and maybe timer). >> Even if it were possible to call into a driver module that early, using >> it as parent would seem to imply that all the references by its children >> would not allow to unload the module, which I'd consider a flawed design >> for such an "optional" read-once driver. If we want the device hierarchy >> to have a soc root then most DT based platforms will have a /soc DT node >> anyway (although no device_type = "soc") that we probably could have a >> device registered for in common code rather than each SoC platform >> handling that differently? That might then make soc_register_device() >> not the creator of the device (if pre-existent) but the supplier of data >> to that core device, which should then allow to unload the data provider >> with just the sysfs data disappearing until re-inserted (speeding up the >> develop-and-test cycle on say not-so-resource-constrained platforms). > > I for one would like to for this to be consistent. Either we always > have an SoC device parent or never. I wouldn't decide based on having > a DT node or not either. Sure, if we can always be consistent, that might be best. Where I was coming from here is that, if we're not supposed to use soc_device_to_device(), then we have no way to associate an of_node with the soc_device from the outside (and nobody was doing it today, as per my analysis). We'd either need a new helper of_soc_device_register() with additional argument for the node, or it would need to be done entirely in the infrastructure as I suggested, be it by looking for one hardcoded /soc node or for nodes with device_type = "soc". Rob, in light of this discussion, should we start adding the latter property for new DTs such as my new Realtek SoCs, or was there a reason this has not been used consistently outside of powerpc and nios2? Intel/Altera appear to be the only two in arm64, with only three more in arm, none in mips. (BTW my assumption was that we don't follow the booting-without-of.txt documented schema of soc<SOCname> so that we can share .dtsi across differently named SoCs, is that correct?) > Generally, we should always have MMIO devices > under a bus node and perhaps more than one, but that doesn't always > happen. I think building the drivers as modules is a good reason to do > away with the parent device. > > It would also allow getting rid of remaining > of_platform_default_populate calls in arm platforms except for auxdata > cases. Pretty much that's the ones you list below in arch/arm/. The majority was indeed passing in NULL, so yeah, we might clean that up, if someone could come up with a plan of where/how to implement it. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-12 10:47 ` Andreas Färber (?) (?) @ 2019-11-15 8:52 ` Neil Armstrong -1 siblings, 0 replies; 117+ messages in thread From: Neil Armstrong @ 2019-11-15 8:52 UTC (permalink / raw) To: Andreas Färber, Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra On 12/11/2019 11:47, Andreas Färber wrote: > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>>> let's export it as GPL symbol. >>>>>>> >>>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>>> someone's tree) that did some of this work already, such that this >>>>>>> symbol isn't needed anymore. >>>>>> >>>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>>> >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>>> >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>>> entries") for how you can just use the default attributes for the soc to >>>>> create the needed sysfs files, instead of having to do it "by hand" >>>>> which is racy and incorrect. >>>> >>>> Unrelated. >>>> >>>>>> Given the current struct layout, a type cast might work (but ugly). >>>>>> Or if we stay with my current RFC driver design, we could use the >>>>>> platform_device instead of the soc_device (which would clutter the >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>>> >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>>> for in-tree code? >>>> >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>>> >>>> As I indicated above, I used it for a dev_info(), which I can easily >>>> avoid by using pr_info() instead: >>>> >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>>> index e5078c6731fd..f9380e831659 100644 >>>> --- a/drivers/soc/realtek/chip.c >>>> +++ b/drivers/soc/realtek/chip.c >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>>> >>>> platform_set_drvdata(pdev, soc_dev); >>>> >>>> - dev_info(soc_device_to_device(soc_dev), >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>>> soc_dev_attr->revision, chip_rev); >>> >>> First off, the driver should not be spitting out noise for when all goes >>> well like this :) >> >> I didn't follow the discussion closely, but I think I want to object >> here a bit. While I agree that each driver emitting some stuff to the >> log buffer is hardly helpful, seeing the exact SoC details is indeed >> useful at times. With my Debian kernel team member hat on, I'd say >> keep this information. This way the SoC details make it into kernel bug >> reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help. Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes. Neil > People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. > > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). > > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:52 ` Neil Armstrong 0 siblings, 0 replies; 117+ messages in thread From: Neil Armstrong @ 2019-11-15 8:52 UTC (permalink / raw) To: Andreas Färber, Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On 12/11/2019 11:47, Andreas Färber wrote: > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>>> let's export it as GPL symbol. >>>>>>> >>>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>>> someone's tree) that did some of this work already, such that this >>>>>>> symbol isn't needed anymore. >>>>>> >>>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>>> >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>>> >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>>> entries") for how you can just use the default attributes for the soc to >>>>> create the needed sysfs files, instead of having to do it "by hand" >>>>> which is racy and incorrect. >>>> >>>> Unrelated. >>>> >>>>>> Given the current struct layout, a type cast might work (but ugly). >>>>>> Or if we stay with my current RFC driver design, we could use the >>>>>> platform_device instead of the soc_device (which would clutter the >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>>> >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>>> for in-tree code? >>>> >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>>> >>>> As I indicated above, I used it for a dev_info(), which I can easily >>>> avoid by using pr_info() instead: >>>> >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>>> index e5078c6731fd..f9380e831659 100644 >>>> --- a/drivers/soc/realtek/chip.c >>>> +++ b/drivers/soc/realtek/chip.c >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>>> >>>> platform_set_drvdata(pdev, soc_dev); >>>> >>>> - dev_info(soc_device_to_device(soc_dev), >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>>> soc_dev_attr->revision, chip_rev); >>> >>> First off, the driver should not be spitting out noise for when all goes >>> well like this :) >> >> I didn't follow the discussion closely, but I think I want to object >> here a bit. While I agree that each driver emitting some stuff to the >> log buffer is hardly helpful, seeing the exact SoC details is indeed >> useful at times. With my Debian kernel team member hat on, I'd say >> keep this information. This way the SoC details make it into kernel bug >> reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help. Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes. Neil > People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. > > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). > > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:52 ` Neil Armstrong 0 siblings, 0 replies; 117+ messages in thread From: Neil Armstrong @ 2019-11-15 8:52 UTC (permalink / raw) To: Andreas Färber, Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On 12/11/2019 11:47, Andreas Färber wrote: > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>>> let's export it as GPL symbol. >>>>>>> >>>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>>> someone's tree) that did some of this work already, such that this >>>>>>> symbol isn't needed anymore. >>>>>> >>>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>>> >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>>> >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>>> entries") for how you can just use the default attributes for the soc to >>>>> create the needed sysfs files, instead of having to do it "by hand" >>>>> which is racy and incorrect. >>>> >>>> Unrelated. >>>> >>>>>> Given the current struct layout, a type cast might work (but ugly). >>>>>> Or if we stay with my current RFC driver design, we could use the >>>>>> platform_device instead of the soc_device (which would clutter the >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>>> >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>>> for in-tree code? >>>> >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>>> >>>> As I indicated above, I used it for a dev_info(), which I can easily >>>> avoid by using pr_info() instead: >>>> >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>>> index e5078c6731fd..f9380e831659 100644 >>>> --- a/drivers/soc/realtek/chip.c >>>> +++ b/drivers/soc/realtek/chip.c >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>>> >>>> platform_set_drvdata(pdev, soc_dev); >>>> >>>> - dev_info(soc_device_to_device(soc_dev), >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>>> soc_dev_attr->revision, chip_rev); >>> >>> First off, the driver should not be spitting out noise for when all goes >>> well like this :) >> >> I didn't follow the discussion closely, but I think I want to object >> here a bit. While I agree that each driver emitting some stuff to the >> log buffer is hardly helpful, seeing the exact SoC details is indeed >> useful at times. With my Debian kernel team member hat on, I'd say >> keep this information. This way the SoC details make it into kernel bug >> reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help. Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes. Neil > People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. > > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). > > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:52 ` Neil Armstrong 0 siblings, 0 replies; 117+ messages in thread From: Neil Armstrong @ 2019-11-15 8:52 UTC (permalink / raw) To: Andreas Färber, Greg Kroah-Hartman Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On 12/11/2019 11:47, Andreas Färber wrote: > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>>> let's export it as GPL symbol. >>>>>>> >>>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>>> someone's tree) that did some of this work already, such that this >>>>>>> symbol isn't needed anymore. >>>>>> >>>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>>> >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>>> >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>>> entries") for how you can just use the default attributes for the soc to >>>>> create the needed sysfs files, instead of having to do it "by hand" >>>>> which is racy and incorrect. >>>> >>>> Unrelated. >>>> >>>>>> Given the current struct layout, a type cast might work (but ugly). >>>>>> Or if we stay with my current RFC driver design, we could use the >>>>>> platform_device instead of the soc_device (which would clutter the >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>>> >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>>> for in-tree code? >>>> >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>>> >>>> As I indicated above, I used it for a dev_info(), which I can easily >>>> avoid by using pr_info() instead: >>>> >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>>> index e5078c6731fd..f9380e831659 100644 >>>> --- a/drivers/soc/realtek/chip.c >>>> +++ b/drivers/soc/realtek/chip.c >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>>> >>>> platform_set_drvdata(pdev, soc_dev); >>>> >>>> - dev_info(soc_device_to_device(soc_dev), >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>>> soc_dev_attr->revision, chip_rev); >>> >>> First off, the driver should not be spitting out noise for when all goes >>> well like this :) >> >> I didn't follow the discussion closely, but I think I want to object >> here a bit. While I agree that each driver emitting some stuff to the >> log buffer is hardly helpful, seeing the exact SoC details is indeed >> useful at times. With my Debian kernel team member hat on, I'd say >> keep this information. This way the SoC details make it into kernel bug >> reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help. Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes. Neil > People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. > > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). > > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); > ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-15 8:52 ` Neil Armstrong (?) (?) @ 2019-11-15 8:58 ` Geert Uytterhoeven -1 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 8:58 UTC (permalink / raw) To: Neil Armstrong Cc: Andreas Färber, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer Hi Neil, On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > On 12/11/2019 11:47, Andreas Färber wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>>> let's export it as GPL symbol. > >>>>>>> > >>>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>>> someone's tree) that did some of this work already, such that this > >>>>>>> symbol isn't needed anymore. > >>>>>> > >>>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>>> > >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>>> > >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>>> entries") for how you can just use the default attributes for the soc to > >>>>> create the needed sysfs files, instead of having to do it "by hand" > >>>>> which is racy and incorrect. > >>>> > >>>> Unrelated. > >>>> > >>>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>>> Or if we stay with my current RFC driver design, we could use the > >>>>>> platform_device instead of the soc_device (which would clutter the > >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>>> > >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>>> for in-tree code? > >>>> > >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>>> > >>>> As I indicated above, I used it for a dev_info(), which I can easily > >>>> avoid by using pr_info() instead: > >>>> > >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>>> index e5078c6731fd..f9380e831659 100644 > >>>> --- a/drivers/soc/realtek/chip.c > >>>> +++ b/drivers/soc/realtek/chip.c > >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>>> > >>>> platform_set_drvdata(pdev, soc_dev); > >>>> > >>>> - dev_info(soc_device_to_device(soc_dev), > >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>>> soc_dev_attr->revision, chip_rev); > >>> > >>> First off, the driver should not be spitting out noise for when all goes > >>> well like this :) > >> > >> I didn't follow the discussion closely, but I think I want to object > >> here a bit. While I agree that each driver emitting some stuff to the > >> log buffer is hardly helpful, seeing the exact SoC details is indeed > >> useful at times. With my Debian kernel team member hat on, I'd say > >> keep this information. This way the SoC details make it into kernel bug > >> reports without effort on our side. > > > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > > on (and it's not the first time I'm seeing such things in the industry). > > So if a user complains, it will be helpful to see that information. > > > > Referencing your Amlogic review, with all due respect for its authors, > > the common framework here just lets that information evaporate into the > > deeps of sysfs. > > Hopefully we never had the case where needed to use the soc info in drivers, > but now we have one and having such infrastructure already in-place will help. > > Renesas platforms makes a extensive usage of the soc info infrastructure to > figure out plenty of HW parameters at runtime and lower their DT changes. We do our best to use it solely for detecting quirks in early SoC revisions. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:58 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 8:58 UTC (permalink / raw) To: Neil Armstrong Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber Hi Neil, On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > On 12/11/2019 11:47, Andreas Färber wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>>> let's export it as GPL symbol. > >>>>>>> > >>>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>>> someone's tree) that did some of this work already, such that this > >>>>>>> symbol isn't needed anymore. > >>>>>> > >>>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>>> > >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>>> > >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>>> entries") for how you can just use the default attributes for the soc to > >>>>> create the needed sysfs files, instead of having to do it "by hand" > >>>>> which is racy and incorrect. > >>>> > >>>> Unrelated. > >>>> > >>>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>>> Or if we stay with my current RFC driver design, we could use the > >>>>>> platform_device instead of the soc_device (which would clutter the > >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>>> > >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>>> for in-tree code? > >>>> > >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>>> > >>>> As I indicated above, I used it for a dev_info(), which I can easily > >>>> avoid by using pr_info() instead: > >>>> > >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>>> index e5078c6731fd..f9380e831659 100644 > >>>> --- a/drivers/soc/realtek/chip.c > >>>> +++ b/drivers/soc/realtek/chip.c > >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>>> > >>>> platform_set_drvdata(pdev, soc_dev); > >>>> > >>>> - dev_info(soc_device_to_device(soc_dev), > >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>>> soc_dev_attr->revision, chip_rev); > >>> > >>> First off, the driver should not be spitting out noise for when all goes > >>> well like this :) > >> > >> I didn't follow the discussion closely, but I think I want to object > >> here a bit. While I agree that each driver emitting some stuff to the > >> log buffer is hardly helpful, seeing the exact SoC details is indeed > >> useful at times. With my Debian kernel team member hat on, I'd say > >> keep this information. This way the SoC details make it into kernel bug > >> reports without effort on our side. > > > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > > on (and it's not the first time I'm seeing such things in the industry). > > So if a user complains, it will be helpful to see that information. > > > > Referencing your Amlogic review, with all due respect for its authors, > > the common framework here just lets that information evaporate into the > > deeps of sysfs. > > Hopefully we never had the case where needed to use the soc info in drivers, > but now we have one and having such infrastructure already in-place will help. > > Renesas platforms makes a extensive usage of the soc info infrastructure to > figure out plenty of HW parameters at runtime and lower their DT changes. We do our best to use it solely for detecting quirks in early SoC revisions. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:58 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 8:58 UTC (permalink / raw) To: Neil Armstrong Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber Hi Neil, On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > On 12/11/2019 11:47, Andreas Färber wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>>> let's export it as GPL symbol. > >>>>>>> > >>>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>>> someone's tree) that did some of this work already, such that this > >>>>>>> symbol isn't needed anymore. > >>>>>> > >>>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>>> > >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>>> > >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>>> entries") for how you can just use the default attributes for the soc to > >>>>> create the needed sysfs files, instead of having to do it "by hand" > >>>>> which is racy and incorrect. > >>>> > >>>> Unrelated. > >>>> > >>>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>>> Or if we stay with my current RFC driver design, we could use the > >>>>>> platform_device instead of the soc_device (which would clutter the > >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>>> > >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>>> for in-tree code? > >>>> > >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>>> > >>>> As I indicated above, I used it for a dev_info(), which I can easily > >>>> avoid by using pr_info() instead: > >>>> > >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>>> index e5078c6731fd..f9380e831659 100644 > >>>> --- a/drivers/soc/realtek/chip.c > >>>> +++ b/drivers/soc/realtek/chip.c > >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>>> > >>>> platform_set_drvdata(pdev, soc_dev); > >>>> > >>>> - dev_info(soc_device_to_device(soc_dev), > >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>>> soc_dev_attr->revision, chip_rev); > >>> > >>> First off, the driver should not be spitting out noise for when all goes > >>> well like this :) > >> > >> I didn't follow the discussion closely, but I think I want to object > >> here a bit. While I agree that each driver emitting some stuff to the > >> log buffer is hardly helpful, seeing the exact SoC details is indeed > >> useful at times. With my Debian kernel team member hat on, I'd say > >> keep this information. This way the SoC details make it into kernel bug > >> reports without effort on our side. > > > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > > on (and it's not the first time I'm seeing such things in the industry). > > So if a user complains, it will be helpful to see that information. > > > > Referencing your Amlogic review, with all due respect for its authors, > > the common framework here just lets that information evaporate into the > > deeps of sysfs. > > Hopefully we never had the case where needed to use the soc info in drivers, > but now we have one and having such infrastructure already in-place will help. > > Renesas platforms makes a extensive usage of the soc info infrastructure to > figure out plenty of HW parameters at runtime and lower their DT changes. We do our best to use it solely for detecting quirks in early SoC revisions. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 8:58 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 8:58 UTC (permalink / raw) To: Neil Armstrong Cc: Andreas Färber, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Hi Neil, On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > On 12/11/2019 11:47, Andreas Färber wrote: > > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: > >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. > >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > >>>>>>>> let's export it as GPL symbol. > >>>>>>> > >>>>>>> I thought we were fixing the soc drivers to not need this. What > >>>>>>> happened to that effort? I thought I had patches in my tree (or > >>>>>>> someone's tree) that did some of this work already, such that this > >>>>>>> symbol isn't needed anymore. > >>>>>> > >>>>>> I do still see this function used in next-20191108 in drivers/soc/. > >>>>>> > >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! > >>>>> > >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > >>>>> entries") for how you can just use the default attributes for the soc to > >>>>> create the needed sysfs files, instead of having to do it "by hand" > >>>>> which is racy and incorrect. > >>>> > >>>> Unrelated. > >>>> > >>>>>> Given the current struct layout, a type cast might work (but ugly). > >>>>>> Or if we stay with my current RFC driver design, we could use the > >>>>>> platform_device instead of the soc_device (which would clutter the > >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. > >>>>> > >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this > >>>>> for in-tree code? > >>>> > >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > >>>> > >>>> As I indicated above, I used it for a dev_info(), which I can easily > >>>> avoid by using pr_info() instead: > >>>> > >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > >>>> index e5078c6731fd..f9380e831659 100644 > >>>> --- a/drivers/soc/realtek/chip.c > >>>> +++ b/drivers/soc/realtek/chip.c > >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > >>>> > >>>> platform_set_drvdata(pdev, soc_dev); > >>>> > >>>> - dev_info(soc_device_to_device(soc_dev), > >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > >>>> soc_dev_attr->revision, chip_rev); > >>> > >>> First off, the driver should not be spitting out noise for when all goes > >>> well like this :) > >> > >> I didn't follow the discussion closely, but I think I want to object > >> here a bit. While I agree that each driver emitting some stuff to the > >> log buffer is hardly helpful, seeing the exact SoC details is indeed > >> useful at times. With my Debian kernel team member hat on, I'd say > >> keep this information. This way the SoC details make it into kernel bug > >> reports without effort on our side. > > > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > > on (and it's not the first time I'm seeing such things in the industry). > > So if a user complains, it will be helpful to see that information. > > > > Referencing your Amlogic review, with all due respect for its authors, > > the common framework here just lets that information evaporate into the > > deeps of sysfs. > > Hopefully we never had the case where needed to use the soc info in drivers, > but now we have one and having such infrastructure already in-place will help. > > Renesas platforms makes a extensive usage of the soc info infrastructure to > figure out plenty of HW parameters at runtime and lower their DT changes. We do our best to use it solely for detecting quirks in early SoC revisions. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-15 8:58 ` Geert Uytterhoeven (?) (?) @ 2019-11-15 12:00 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 12:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer Hi Geert, Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> On 12/11/2019 11:47, Andreas Färber wrote: >>> For example, RTD1295 will support LSADC only from revision B00 >>> on (and it's not the first time I'm seeing such things in the industry). >>> So if a user complains, it will be helpful to see that information. >>> >>> Referencing your Amlogic review, with all due respect for its authors, >>> the common framework here just lets that information evaporate into the >>> deeps of sysfs. >> >> Hopefully we never had the case where needed to use the soc info in drivers, >> but now we have one and having such infrastructure already in-place will help. >> >> Renesas platforms makes a extensive usage of the soc info infrastructure to >> figure out plenty of HW parameters at runtime and lower their DT changes. > > We do our best to use it solely for detecting quirks in early SoC revisions. Got a pointer? I fail to immediately understand how sysfs would help drivers (as opposed to userspace) detect quirks: Parsing strings back doesn't sound efficient, and I don't see you exporting any custom APIs in drivers/soc/renesas/renesas-soc.c? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:00 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 12:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo Hi Geert, Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> On 12/11/2019 11:47, Andreas Färber wrote: >>> For example, RTD1295 will support LSADC only from revision B00 >>> on (and it's not the first time I'm seeing such things in the industry). >>> So if a user complains, it will be helpful to see that information. >>> >>> Referencing your Amlogic review, with all due respect for its authors, >>> the common framework here just lets that information evaporate into the >>> deeps of sysfs. >> >> Hopefully we never had the case where needed to use the soc info in drivers, >> but now we have one and having such infrastructure already in-place will help. >> >> Renesas platforms makes a extensive usage of the soc info infrastructure to >> figure out plenty of HW parameters at runtime and lower their DT changes. > > We do our best to use it solely for detecting quirks in early SoC revisions. Got a pointer? I fail to immediately understand how sysfs would help drivers (as opposed to userspace) detect quirks: Parsing strings back doesn't sound efficient, and I don't see you exporting any custom APIs in drivers/soc/renesas/renesas-soc.c? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:00 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 12:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, linux-amlogic, Lee Jones, linux-omap, Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo Hi Geert, Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> On 12/11/2019 11:47, Andreas Färber wrote: >>> For example, RTD1295 will support LSADC only from revision B00 >>> on (and it's not the first time I'm seeing such things in the industry). >>> So if a user complains, it will be helpful to see that information. >>> >>> Referencing your Amlogic review, with all due respect for its authors, >>> the common framework here just lets that information evaporate into the >>> deeps of sysfs. >> >> Hopefully we never had the case where needed to use the soc info in drivers, >> but now we have one and having such infrastructure already in-place will help. >> >> Renesas platforms makes a extensive usage of the soc info infrastructure to >> figure out plenty of HW parameters at runtime and lower their DT changes. > > We do our best to use it solely for detecting quirks in early SoC revisions. Got a pointer? I fail to immediately understand how sysfs would help drivers (as opposed to userspace) detect quirks: Parsing strings back doesn't sound efficient, and I don't see you exporting any custom APIs in drivers/soc/renesas/renesas-soc.c? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:00 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-15 12:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, Linux ARM, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Hi Geert, Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> On 12/11/2019 11:47, Andreas Färber wrote: >>> For example, RTD1295 will support LSADC only from revision B00 >>> on (and it's not the first time I'm seeing such things in the industry). >>> So if a user complains, it will be helpful to see that information. >>> >>> Referencing your Amlogic review, with all due respect for its authors, >>> the common framework here just lets that information evaporate into the >>> deeps of sysfs. >> >> Hopefully we never had the case where needed to use the soc info in drivers, >> but now we have one and having such infrastructure already in-place will help. >> >> Renesas platforms makes a extensive usage of the soc info infrastructure to >> figure out plenty of HW parameters at runtime and lower their DT changes. > > We do our best to use it solely for detecting quirks in early SoC revisions. Got a pointer? I fail to immediately understand how sysfs would help drivers (as opposed to userspace) detect quirks: Parsing strings back doesn't sound efficient, and I don't see you exporting any custom APIs in drivers/soc/renesas/renesas-soc.c? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-15 12:00 ` Andreas Färber (?) (?) @ 2019-11-15 12:34 ` Geert Uytterhoeven -1 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 12:34 UTC (permalink / raw) To: Andreas Färber Cc: Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer Hi Andreas, On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> On 12/11/2019 11:47, Andreas Färber wrote: > >>> For example, RTD1295 will support LSADC only from revision B00 > >>> on (and it's not the first time I'm seeing such things in the industry). > >>> So if a user complains, it will be helpful to see that information. > >>> > >>> Referencing your Amlogic review, with all due respect for its authors, > >>> the common framework here just lets that information evaporate into the > >>> deeps of sysfs. > >> > >> Hopefully we never had the case where needed to use the soc info in drivers, > >> but now we have one and having such infrastructure already in-place will help. > >> > >> Renesas platforms makes a extensive usage of the soc info infrastructure to > >> figure out plenty of HW parameters at runtime and lower their DT changes. > > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > Got a pointer? I fail to immediately understand how sysfs would help > drivers (as opposed to userspace) detect quirks: Parsing strings back > doesn't sound efficient, and I don't see you exporting any custom APIs > in drivers/soc/renesas/renesas-soc.c? We use soc_device_match(), inside kernel drivers. Exposure through sysfs is a side-effect of using soc_device_register(), and welcomed, as it allows the user to find out quickly which SoC and revision is being used. FTR, lshw (Ubuntu 18.04 has v2.18, which does seem to be the latest upstream version) does not parse /sys/devices/soc0/. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 12:34 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo Hi Andreas, On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> On 12/11/2019 11:47, Andreas Färber wrote: > >>> For example, RTD1295 will support LSADC only from revision B00 > >>> on (and it's not the first time I'm seeing such things in the industry). > >>> So if a user complains, it will be helpful to see that information. > >>> > >>> Referencing your Amlogic review, with all due respect for its authors, > >>> the common framework here just lets that information evaporate into the > >>> deeps of sysfs. > >> > >> Hopefully we never had the case where needed to use the soc info in drivers, > >> but now we have one and having such infrastructure already in-place will help. > >> > >> Renesas platforms makes a extensive usage of the soc info infrastructure to > >> figure out plenty of HW parameters at runtime and lower their DT changes. > > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > Got a pointer? I fail to immediately understand how sysfs would help > drivers (as opposed to userspace) detect quirks: Parsing strings back > doesn't sound efficient, and I don't see you exporting any custom APIs > in drivers/soc/renesas/renesas-soc.c? We use soc_device_match(), inside kernel drivers. Exposure through sysfs is a side-effect of using soc_device_register(), and welcomed, as it allows the user to find out quickly which SoC and revision is being used. FTR, lshw (Ubuntu 18.04 has v2.18, which does seem to be the latest upstream version) does not parse /sys/devices/soc0/. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 12:34 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo Hi Andreas, On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> On 12/11/2019 11:47, Andreas Färber wrote: > >>> For example, RTD1295 will support LSADC only from revision B00 > >>> on (and it's not the first time I'm seeing such things in the industry). > >>> So if a user complains, it will be helpful to see that information. > >>> > >>> Referencing your Amlogic review, with all due respect for its authors, > >>> the common framework here just lets that information evaporate into the > >>> deeps of sysfs. > >> > >> Hopefully we never had the case where needed to use the soc info in drivers, > >> but now we have one and having such infrastructure already in-place will help. > >> > >> Renesas platforms makes a extensive usage of the soc info infrastructure to > >> figure out plenty of HW parameters at runtime and lower their DT changes. > > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > Got a pointer? I fail to immediately understand how sysfs would help > drivers (as opposed to userspace) detect quirks: Parsing strings back > doesn't sound efficient, and I don't see you exporting any custom APIs > in drivers/soc/renesas/renesas-soc.c? We use soc_device_match(), inside kernel drivers. Exposure through sysfs is a side-effect of using soc_device_register(), and welcomed, as it allows the user to find out quickly which SoC and revision is being used. FTR, lshw (Ubuntu 18.04 has v2.18, which does seem to be the latest upstream version) does not parse /sys/devices/soc0/. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-15 12:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 117+ messages in thread From: Geert Uytterhoeven @ 2019-11-15 12:34 UTC (permalink / raw) To: Andreas Färber Cc: Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo Hi Andreas, On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> On 12/11/2019 11:47, Andreas Färber wrote: > >>> For example, RTD1295 will support LSADC only from revision B00 > >>> on (and it's not the first time I'm seeing such things in the industry). > >>> So if a user complains, it will be helpful to see that information. > >>> > >>> Referencing your Amlogic review, with all due respect for its authors, > >>> the common framework here just lets that information evaporate into the > >>> deeps of sysfs. > >> > >> Hopefully we never had the case where needed to use the soc info in drivers, > >> but now we have one and having such infrastructure already in-place will help. > >> > >> Renesas platforms makes a extensive usage of the soc info infrastructure to > >> figure out plenty of HW parameters at runtime and lower their DT changes. > > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > Got a pointer? I fail to immediately understand how sysfs would help > drivers (as opposed to userspace) detect quirks: Parsing strings back > doesn't sound efficient, and I don't see you exporting any custom APIs > in drivers/soc/renesas/renesas-soc.c? We use soc_device_match(), inside kernel drivers. Exposure through sysfs is a side-effect of using soc_device_register(), and welcomed, as it allows the user to find out quickly which SoC and revision is being used. FTR, lshw (Ubuntu 18.04 has v2.18, which does seem to be the latest upstream version) does not parse /sys/devices/soc0/. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) 2019-11-15 12:34 ` Geert Uytterhoeven (?) (?) @ 2019-11-18 15:55 ` Tony Lindgren -1 siblings, 0 replies; 117+ messages in thread From: Tony Lindgren @ 2019-11-18 15:55 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Andreas Färber, Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer * Geert Uytterhoeven <geert@linux-m68k.org> [191115 15:51]: > On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > > > Got a pointer? I fail to immediately understand how sysfs would help > > drivers (as opposed to userspace) detect quirks: Parsing strings back > > doesn't sound efficient, and I don't see you exporting any custom APIs > > in drivers/soc/renesas/renesas-soc.c? > > We use soc_device_match(), inside kernel drivers. > Exposure through sysfs is a side-effect of using soc_device_register(), > and welcomed, as it allows the user to find out quickly which SoC and > revision is being used. For the omap variants too, we've so far gotten away with early SoC detection for platform code, and then use soc_device_match() in few cases for drivers at probe time if needed. Regards, Tony ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-18 15:55 ` Tony Lindgren 0 siblings, 0 replies; 117+ messages in thread From: Tony Lindgren @ 2019-11-18 15:55 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, linux-realtek-soc, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo, Andreas Färber * Geert Uytterhoeven <geert@linux-m68k.org> [191115 15:51]: > On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > > > Got a pointer? I fail to immediately understand how sysfs would help > > drivers (as opposed to userspace) detect quirks: Parsing strings back > > doesn't sound efficient, and I don't see you exporting any custom APIs > > in drivers/soc/renesas/renesas-soc.c? > > We use soc_device_match(), inside kernel drivers. > Exposure through sysfs is a side-effect of using soc_device_register(), > and welcomed, as it allows the user to find out quickly which SoC and > revision is being used. For the omap variants too, we've so far gotten away with early SoC detection for platform code, and then use soc_device_match() in few cases for drivers at probe time if needed. Regards, Tony _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-18 15:55 ` Tony Lindgren 0 siblings, 0 replies; 117+ messages in thread From: Tony Lindgren @ 2019-11-18 15:55 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Geert Uytterhoeven, linux-realtek-soc, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Rob Herring, Kevin Hilman, Neil Armstrong, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, linux-tegra, open list:ARM/Amlogic Meson..., Lee Jones, open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Greg Kroah-Hartman, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Rafael J. Wysocki, Shawn Guo, Andreas Färber * Geert Uytterhoeven <geert@linux-m68k.org> [191115 15:51]: > On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > > > Got a pointer? I fail to immediately understand how sysfs would help > > drivers (as opposed to userspace) detect quirks: Parsing strings back > > doesn't sound efficient, and I don't see you exporting any custom APIs > > in drivers/soc/renesas/renesas-soc.c? > > We use soc_device_match(), inside kernel drivers. > Exposure through sysfs is a side-effect of using soc_device_register(), > and welcomed, as it allows the user to find out quickly which SoC and > revision is being used. For the omap variants too, we've so far gotten away with early SoC detection for platform code, and then use soc_device_match() in few cases for drivers at probe time if needed. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) @ 2019-11-18 15:55 ` Tony Lindgren 0 siblings, 0 replies; 117+ messages in thread From: Tony Lindgren @ 2019-11-18 15:55 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Andreas Färber, Neil Armstrong, Greg Kroah-Hartman, Geert Uytterhoeven, linux-realtek-soc, Linus Walleij, Bjorn Andersson, Thierry Reding, Lee Jones, Rob Herring, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Uwe Kleine-König, boot-architecture, Sascha Hauer, Fabio Estevam, linux-tegra, open list:ARM/Amlogic Meson..., open list:TI ETHERNET SWITCH DRIVER (CPSW), Alexander Sverdlin, Linux ARM, Linux Kernel Mailing List, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo * Geert Uytterhoeven <geert@linux-m68k.org> [191115 15:51]: > On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@suse.de> wrote: > > Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven: > > > We do our best to use it solely for detecting quirks in early SoC revisions. > > > > Got a pointer? I fail to immediately understand how sysfs would help > > drivers (as opposed to userspace) detect quirks: Parsing strings back > > doesn't sound efficient, and I don't see you exporting any custom APIs > > in drivers/soc/renesas/renesas-soc.c? > > We use soc_device_match(), inside kernel drivers. > Exposure through sysfs is a side-effect of using soc_device_register(), > and welcomed, as it allows the user to find out quickly which SoC and > revision is being used. For the omap variants too, we've so far gotten away with early SoC detection for platform code, and then use soc_device_match() in few cases for drivers at probe time if needed. Regards, Tony ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper 2019-11-12 7:29 ` Uwe Kleine-König (?) (?) @ 2019-11-12 10:48 ` Lee Jones -1 siblings, 0 replies; 117+ messages in thread From: Lee Jones @ 2019-11-12 10:48 UTC (permalink / raw) To: Uwe Kleine-König Cc: Greg Kroah-Hartman, Andreas Färber, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, linux-omap On Tue, 12 Nov 2019, Uwe Kleine-König wrote: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > > >> Hi Greg, > > > >> > > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > > >>>> let's export it as GPL symbol. > > > >>> > > > >>> I thought we were fixing the soc drivers to not need this. What > > > >>> happened to that effort? I thought I had patches in my tree (or > > > >>> someone's tree) that did some of this work already, such that this > > > >>> symbol isn't needed anymore. > > > >> > > > >> I do still see this function used in next-20191108 in drivers/soc/. > > > >> > > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > > entries") for how you can just use the default attributes for the soc to > > > > create the needed sysfs files, instead of having to do it "by hand" > > > > which is racy and incorrect. > > > > > > Unrelated. > > > > > > >> Given the current struct layout, a type cast might work (but ugly). > > > >> Or if we stay with my current RFC driver design, we could use the > > > >> platform_device instead of the soc_device (which would clutter the > > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > > for in-tree code? > > > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > > > As I indicated above, I used it for a dev_info(), which I can easily > > > avoid by using pr_info() instead: > > > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > > index e5078c6731fd..f9380e831659 100644 > > > --- a/drivers/soc/realtek/chip.c > > > +++ b/drivers/soc/realtek/chip.c > > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > > > platform_set_drvdata(pdev, soc_dev); > > > > > > - dev_info(soc_device_to_device(soc_dev), > > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > > soc_dev_attr->revision, chip_rev); > > > > First off, the driver should not be spitting out noise for when all goes > > well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Right. From my angle we are starting to be way too aggressive with the point about not printing information to the kernel log. In only a small set of cases does this actually cause an issue i.e. with platforms containing so many devices that printing information from each of them does significantly increase boot times. In my world of small electronics I've been greatly hindered by the lack of information, such that it has cost days of engineering trying to track down fictitious bugs and the like. For platforms where printing useful information culminates in negative effects, perhaps simply lower their log level, rather than suffocate all platforms. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 10:48 ` Lee Jones 0 siblings, 0 replies; 117+ messages in thread From: Lee Jones @ 2019-11-12 10:48 UTC (permalink / raw) To: Uwe Kleine-König Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber On Tue, 12 Nov 2019, Uwe Kleine-König wrote: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > > >> Hi Greg, > > > >> > > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > > >>>> let's export it as GPL symbol. > > > >>> > > > >>> I thought we were fixing the soc drivers to not need this. What > > > >>> happened to that effort? I thought I had patches in my tree (or > > > >>> someone's tree) that did some of this work already, such that this > > > >>> symbol isn't needed anymore. > > > >> > > > >> I do still see this function used in next-20191108 in drivers/soc/. > > > >> > > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > > entries") for how you can just use the default attributes for the soc to > > > > create the needed sysfs files, instead of having to do it "by hand" > > > > which is racy and incorrect. > > > > > > Unrelated. > > > > > > >> Given the current struct layout, a type cast might work (but ugly). > > > >> Or if we stay with my current RFC driver design, we could use the > > > >> platform_device instead of the soc_device (which would clutter the > > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > > for in-tree code? > > > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > > > As I indicated above, I used it for a dev_info(), which I can easily > > > avoid by using pr_info() instead: > > > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > > index e5078c6731fd..f9380e831659 100644 > > > --- a/drivers/soc/realtek/chip.c > > > +++ b/drivers/soc/realtek/chip.c > > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > > > platform_set_drvdata(pdev, soc_dev); > > > > > > - dev_info(soc_device_to_device(soc_dev), > > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > > soc_dev_attr->revision, chip_rev); > > > > First off, the driver should not be spitting out noise for when all goes > > well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Right. From my angle we are starting to be way too aggressive with the point about not printing information to the kernel log. In only a small set of cases does this actually cause an issue i.e. with platforms containing so many devices that printing information from each of them does significantly increase boot times. In my world of small electronics I've been greatly hindered by the lack of information, such that it has cost days of engineering trying to track down fictitious bugs and the like. For platforms where printing useful information culminates in negative effects, perhaps simply lower their log level, rather than suffocate all platforms. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 10:48 ` Lee Jones 0 siblings, 0 replies; 117+ messages in thread From: Lee Jones @ 2019-11-12 10:48 UTC (permalink / raw) To: Uwe Kleine-König Cc: Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo, Andreas Färber On Tue, 12 Nov 2019, Uwe Kleine-König wrote: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > > >> Hi Greg, > > > >> > > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > > >>>> let's export it as GPL symbol. > > > >>> > > > >>> I thought we were fixing the soc drivers to not need this. What > > > >>> happened to that effort? I thought I had patches in my tree (or > > > >>> someone's tree) that did some of this work already, such that this > > > >>> symbol isn't needed anymore. > > > >> > > > >> I do still see this function used in next-20191108 in drivers/soc/. > > > >> > > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > > entries") for how you can just use the default attributes for the soc to > > > > create the needed sysfs files, instead of having to do it "by hand" > > > > which is racy and incorrect. > > > > > > Unrelated. > > > > > > >> Given the current struct layout, a type cast might work (but ugly). > > > >> Or if we stay with my current RFC driver design, we could use the > > > >> platform_device instead of the soc_device (which would clutter the > > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > > for in-tree code? > > > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > > > As I indicated above, I used it for a dev_info(), which I can easily > > > avoid by using pr_info() instead: > > > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > > index e5078c6731fd..f9380e831659 100644 > > > --- a/drivers/soc/realtek/chip.c > > > +++ b/drivers/soc/realtek/chip.c > > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > > > platform_set_drvdata(pdev, soc_dev); > > > > > > - dev_info(soc_device_to_device(soc_dev), > > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > > soc_dev_attr->revision, chip_rev); > > > > First off, the driver should not be spitting out noise for when all goes > > well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Right. From my angle we are starting to be way too aggressive with the point about not printing information to the kernel log. In only a small set of cases does this actually cause an issue i.e. with platforms containing so many devices that printing information from each of them does significantly increase boot times. In my world of small electronics I've been greatly hindered by the lack of information, such that it has cost days of engineering trying to track down fictitious bugs and the like. For platforms where printing useful information culminates in negative effects, perhaps simply lower their log level, rather than suffocate all platforms. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [PATCH] base: soc: Export soc_device_to_device() helper @ 2019-11-12 10:48 ` Lee Jones 0 siblings, 0 replies; 117+ messages in thread From: Lee Jones @ 2019-11-12 10:48 UTC (permalink / raw) To: Uwe Kleine-König Cc: Greg Kroah-Hartman, Andreas Färber, Geert Uytterhoeven, linux-realtek-soc, Tony Lindgren, Linus Walleij, Bjorn Andersson, Thierry Reding, Fabio Estevam, Kevin Hilman, Rafael J. Wysocki, Michal Simek, Jonathan Hunter, NXP Linux Team, Sascha Hauer, linux-tegra, linux-amlogic, linux-omap, Alexander Sverdlin, linux-arm-kernel, linux-kernel, Hartley Sweeten, Pengutronix Kernel Team, Shawn Guo On Tue, 12 Nov 2019, Uwe Kleine-König wrote: > On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: > > > Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > > > > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: > > > >> Hi Greg, > > > >> > > > >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: > > > >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: > > > >>>> Use of soc_device_to_device() in driver modules causes a build failure. > > > >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, > > > >>>> let's export it as GPL symbol. > > > >>> > > > >>> I thought we were fixing the soc drivers to not need this. What > > > >>> happened to that effort? I thought I had patches in my tree (or > > > >>> someone's tree) that did some of this work already, such that this > > > >>> symbol isn't needed anymore. > > > >> > > > >> I do still see this function used in next-20191108 in drivers/soc/. > > > >> > > > >> I'll be happy to adjust my RFC driver if someone points me to how! > > > > > > > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > > > > entries") for how you can just use the default attributes for the soc to > > > > create the needed sysfs files, instead of having to do it "by hand" > > > > which is racy and incorrect. > > > > > > Unrelated. > > > > > > >> Given the current struct layout, a type cast might work (but ugly). > > > >> Or if we stay with my current RFC driver design, we could use the > > > >> platform_device instead of the soc_device (which would clutter the > > > >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > > > > > > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > > > > for in-tree code? > > > > > > No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ > > > > > > As I indicated above, I used it for a dev_info(), which I can easily > > > avoid by using pr_info() instead: > > > > > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c > > > index e5078c6731fd..f9380e831659 100644 > > > --- a/drivers/soc/realtek/chip.c > > > +++ b/drivers/soc/realtek/chip.c > > > @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) > > > > > > platform_set_drvdata(pdev, soc_dev); > > > > > > - dev_info(soc_device_to_device(soc_dev), > > > - "%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", > > > soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > > > soc_dev_attr->revision, chip_rev); > > > > First off, the driver should not be spitting out noise for when all goes > > well like this :) > > I didn't follow the discussion closely, but I think I want to object > here a bit. While I agree that each driver emitting some stuff to the > log buffer is hardly helpful, seeing the exact SoC details is indeed > useful at times. With my Debian kernel team member hat on, I'd say > keep this information. This way the SoC details make it into kernel bug > reports without effort on our side. Right. From my angle we are starting to be way too aggressive with the point about not printing information to the kernel log. In only a small set of cases does this actually cause an issue i.e. with platforms containing so many devices that printing information from each of them does significantly increase boot times. In my world of small electronics I've been greatly hindered by the lack of information, such that it has cost days of engineering trying to track down fictitious bugs and the like. For platforms where printing useful information culminates in negative effects, perhaps simply lower their log level, rather than suffocate all platforms. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2019-11-03 1:36 ` Andreas Färber @ 2020-01-02 14:29 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:29 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Add Stanley Chang for review. > Add a soc bus driver to print chip model and revision details. > > Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > Naming: What to call the family vs. soc_id? > > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/realtek/Kconfig | 13 ++++ > drivers/soc/realtek/Makefile | 2 + > drivers/soc/realtek/chip.c | 164 > +++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 181 insertions(+) > create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 > drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c > > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index > 833e04a7835c..06ae9d97321c 100644 > --- a/drivers/soc/Kconfig > +++ b/drivers/soc/Kconfig > @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" > source "drivers/soc/ixp4xx/Kconfig" > source "drivers/soc/mediatek/Kconfig" > source "drivers/soc/qcom/Kconfig" > +source "drivers/soc/realtek/Kconfig" > source "drivers/soc/renesas/Kconfig" > source "drivers/soc/rockchip/Kconfig" > source "drivers/soc/samsung/Kconfig" > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index > 2ec355003524..1d55d838a342 100644 > --- a/drivers/soc/Makefile > +++ b/drivers/soc/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ > obj-y += mediatek/ > obj-y += amlogic/ > obj-y += qcom/ > +obj-y += realtek/ > obj-y += renesas/ > obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ > obj-$(CONFIG_SOC_SAMSUNG) += samsung/ > diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file > mode 100644 index 000000000000..be75c1889c61 > --- /dev/null > +++ b/drivers/soc/realtek/Kconfig > @@ -0,0 +1,13 @@ > +# SPDX-License-Identifier: GPL-2.0-or-later if ARCH_REALTEK || > +COMPILE_TEST > + > +config REALTEK_SOC > + tristate "Realtek chip info" > + default ARCH_REALTEK > + select SOC_BUS > + help > + Say 'y' here to enable support for SoC info on Realtek RTD1195 and > + RTD1295 SoC families. > + If unsure, say 'n'. > + > +endif > diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new > file mode 100644 index 000000000000..49900273905b > --- /dev/null > +++ b/drivers/soc/realtek/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-or-later > +obj-$(CONFIG_REALTEK_SOC) += chip.o > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file > mode 100644 index 000000000000..9d13422e9936 > --- /dev/null > +++ b/drivers/soc/realtek/chip.c > @@ -0,0 +1,164 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Realtek System-on-Chip info > + * > + * Copyright (c) 2017-2019 Andreas Färber */ > + > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> > +#include <linux/sys_soc.h> > + > +#define REG_CHIP_ID 0x0 > +#define REG_CHIP_REV 0x4 > + > +struct rtd_soc_revision { > + const char *name; > + u32 chip_rev; > +}; > + > +static const struct rtd_soc_revision rtd1195_revisions[] = { > + { "A", 0x00000000 }, > + { "B", 0x00010000 }, > + { "C", 0x00020000 }, > + { "D", 0x00030000 }, > + { } > +}; > + > +static const struct rtd_soc_revision rtd1295_revisions[] = { > + { "A00", 0x00000000 }, > + { "A01", 0x00010000 }, > + { "B00", 0x00020000 }, > + { "B01", 0x00030000 }, > + { } > +}; > + > +struct rtd_soc { > + u32 chip_id; > + const char *family; > + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); > + const struct rtd_soc_revision *revisions; > + const char *codename; > +}; > + > +static const char *default_name(struct device *dev, const struct > +rtd_soc *s) { > + return s->family; > +} > + > +static const struct rtd_soc rtd_soc_families[] = { > + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, > + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, > +}; > + > +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) { > + int i; > + > + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { > + const struct rtd_soc *family = &rtd_soc_families[i]; > + > + if (family->chip_id == chip_id) > + return family; > + } > + return NULL; > +} > + > +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 > +chip_rev) { > + if (family) { > + const struct rtd_soc_revision *rev = family->revisions; > + > + while (rev && rev->name) { > + if (rev->chip_rev == chip_rev) > + return rev->name; > + rev++; > + } > + } > + return "unknown"; > +} > + > +static int rtd_soc_probe(struct platform_device *pdev) { > + const struct rtd_soc *s; > + struct soc_device_attribute *soc_dev_attr; > + struct soc_device *soc_dev; > + struct device_node *node; > + void __iomem *base; > + u32 chip_id, chip_rev; > + > + base = of_iomap(pdev->dev.of_node, 0); > + if (!base) > + return -ENODEV; > + > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); > + if (!soc_dev_attr) > + return -ENOMEM; > + > + chip_id = readl_relaxed(base + REG_CHIP_ID); > + chip_rev = readl_relaxed(base + REG_CHIP_REV); > + > + node = of_find_node_by_path("/"); > + of_property_read_string(node, "model", &soc_dev_attr->machine); > + of_node_put(node); > + > + s = rtd_soc_by_chip_id(chip_id); > + > + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", > + (s && s->codename) ? s->codename : > + ((s && s->family) ? s->family : "Digital Home Center")); > + > + if (likely(s && s->get_name)) > + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); > + else > + soc_dev_attr->soc_id = "unknown"; > + > + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); > + > + soc_dev = soc_device_register(soc_dev_attr); > + if (IS_ERR(soc_dev)) { > + kfree(soc_dev_attr->family); > + kfree(soc_dev_attr); > + return PTR_ERR(soc_dev); > + } > + > + platform_set_drvdata(pdev, soc_dev); > + > + dev_info(soc_device_to_device(soc_dev), > + "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > + soc_dev_attr->revision, chip_rev); > + > + return 0; > +} > + > +static int rtd_soc_remove(struct platform_device *pdev) { > + struct soc_device *soc_dev = platform_get_drvdata(pdev); > + > + soc_device_unregister(soc_dev); > + > + return 0; > +} > + > +static const struct of_device_id rtd_soc_dt_ids[] = { > + { .compatible = "realtek,rtd1195-chip" }, > + { } > +}; > + > +static struct platform_driver rtd_soc_driver = { > + .probe = rtd_soc_probe, > + .remove = rtd_soc_remove, > + .driver = { > + .name = "rtd1195-soc", > + .of_match_table = rtd_soc_dt_ids, > + }, > +}; > +module_platform_driver(rtd_soc_driver); > + > +MODULE_DESCRIPTION("Realtek SoC identification"); > +MODULE_LICENSE("GPL"); > -- > 2.16.4 > > > _______________________________________________ > linux-realtek-soc mailing list > linux-realtek-soc@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-realtek-soc > > ------Please consider the environment before printing this e-mail. ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2020-01-02 14:29 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:29 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Add Stanley Chang for review. > Add a soc bus driver to print chip model and revision details. > > Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > Naming: What to call the family vs. soc_id? > > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/realtek/Kconfig | 13 ++++ > drivers/soc/realtek/Makefile | 2 + > drivers/soc/realtek/chip.c | 164 > +++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 181 insertions(+) > create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 > drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c > > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index > 833e04a7835c..06ae9d97321c 100644 > --- a/drivers/soc/Kconfig > +++ b/drivers/soc/Kconfig > @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" > source "drivers/soc/ixp4xx/Kconfig" > source "drivers/soc/mediatek/Kconfig" > source "drivers/soc/qcom/Kconfig" > +source "drivers/soc/realtek/Kconfig" > source "drivers/soc/renesas/Kconfig" > source "drivers/soc/rockchip/Kconfig" > source "drivers/soc/samsung/Kconfig" > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index > 2ec355003524..1d55d838a342 100644 > --- a/drivers/soc/Makefile > +++ b/drivers/soc/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ > obj-y += mediatek/ > obj-y += amlogic/ > obj-y += qcom/ > +obj-y += realtek/ > obj-y += renesas/ > obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ > obj-$(CONFIG_SOC_SAMSUNG) += samsung/ > diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file > mode 100644 index 000000000000..be75c1889c61 > --- /dev/null > +++ b/drivers/soc/realtek/Kconfig > @@ -0,0 +1,13 @@ > +# SPDX-License-Identifier: GPL-2.0-or-later if ARCH_REALTEK || > +COMPILE_TEST > + > +config REALTEK_SOC > + tristate "Realtek chip info" > + default ARCH_REALTEK > + select SOC_BUS > + help > + Say 'y' here to enable support for SoC info on Realtek RTD1195 and > + RTD1295 SoC families. > + If unsure, say 'n'. > + > +endif > diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new > file mode 100644 index 000000000000..49900273905b > --- /dev/null > +++ b/drivers/soc/realtek/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-or-later > +obj-$(CONFIG_REALTEK_SOC) += chip.o > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file > mode 100644 index 000000000000..9d13422e9936 > --- /dev/null > +++ b/drivers/soc/realtek/chip.c > @@ -0,0 +1,164 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Realtek System-on-Chip info > + * > + * Copyright (c) 2017-2019 Andreas Färber */ > + > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> > +#include <linux/sys_soc.h> > + > +#define REG_CHIP_ID 0x0 > +#define REG_CHIP_REV 0x4 > + > +struct rtd_soc_revision { > + const char *name; > + u32 chip_rev; > +}; > + > +static const struct rtd_soc_revision rtd1195_revisions[] = { > + { "A", 0x00000000 }, > + { "B", 0x00010000 }, > + { "C", 0x00020000 }, > + { "D", 0x00030000 }, > + { } > +}; > + > +static const struct rtd_soc_revision rtd1295_revisions[] = { > + { "A00", 0x00000000 }, > + { "A01", 0x00010000 }, > + { "B00", 0x00020000 }, > + { "B01", 0x00030000 }, > + { } > +}; > + > +struct rtd_soc { > + u32 chip_id; > + const char *family; > + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); > + const struct rtd_soc_revision *revisions; > + const char *codename; > +}; > + > +static const char *default_name(struct device *dev, const struct > +rtd_soc *s) { > + return s->family; > +} > + > +static const struct rtd_soc rtd_soc_families[] = { > + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, > + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, > +}; > + > +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) { > + int i; > + > + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { > + const struct rtd_soc *family = &rtd_soc_families[i]; > + > + if (family->chip_id == chip_id) > + return family; > + } > + return NULL; > +} > + > +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 > +chip_rev) { > + if (family) { > + const struct rtd_soc_revision *rev = family->revisions; > + > + while (rev && rev->name) { > + if (rev->chip_rev == chip_rev) > + return rev->name; > + rev++; > + } > + } > + return "unknown"; > +} > + > +static int rtd_soc_probe(struct platform_device *pdev) { > + const struct rtd_soc *s; > + struct soc_device_attribute *soc_dev_attr; > + struct soc_device *soc_dev; > + struct device_node *node; > + void __iomem *base; > + u32 chip_id, chip_rev; > + > + base = of_iomap(pdev->dev.of_node, 0); > + if (!base) > + return -ENODEV; > + > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); > + if (!soc_dev_attr) > + return -ENOMEM; > + > + chip_id = readl_relaxed(base + REG_CHIP_ID); > + chip_rev = readl_relaxed(base + REG_CHIP_REV); > + > + node = of_find_node_by_path("/"); > + of_property_read_string(node, "model", &soc_dev_attr->machine); > + of_node_put(node); > + > + s = rtd_soc_by_chip_id(chip_id); > + > + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", > + (s && s->codename) ? s->codename : > + ((s && s->family) ? s->family : "Digital Home Center")); > + > + if (likely(s && s->get_name)) > + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); > + else > + soc_dev_attr->soc_id = "unknown"; > + > + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); > + > + soc_dev = soc_device_register(soc_dev_attr); > + if (IS_ERR(soc_dev)) { > + kfree(soc_dev_attr->family); > + kfree(soc_dev_attr); > + return PTR_ERR(soc_dev); > + } > + > + platform_set_drvdata(pdev, soc_dev); > + > + dev_info(soc_device_to_device(soc_dev), > + "%s %s (0x%08x) rev %s (0x%08x) detected\n", > + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, > + soc_dev_attr->revision, chip_rev); > + > + return 0; > +} > + > +static int rtd_soc_remove(struct platform_device *pdev) { > + struct soc_device *soc_dev = platform_get_drvdata(pdev); > + > + soc_device_unregister(soc_dev); > + > + return 0; > +} > + > +static const struct of_device_id rtd_soc_dt_ids[] = { > + { .compatible = "realtek,rtd1195-chip" }, > + { } > +}; > + > +static struct platform_driver rtd_soc_driver = { > + .probe = rtd_soc_probe, > + .remove = rtd_soc_remove, > + .driver = { > + .name = "rtd1195-soc", > + .of_match_table = rtd_soc_dt_ids, > + }, > +}; > +module_platform_driver(rtd_soc_driver); > + > +MODULE_DESCRIPTION("Realtek SoC identification"); > +MODULE_LICENSE("GPL"); > -- > 2.16.4 > > > _______________________________________________ > linux-realtek-soc mailing list > linux-realtek-soc@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-realtek-soc > > ------Please consider the environment before printing this e-mail. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2020-01-02 14:29 ` James Tai @ 2020-01-02 14:39 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2020-01-02 14:39 UTC (permalink / raw) To: James Tai, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Am 02.01.20 um 15:29 schrieb James Tai: > Add Stanley Chang for review. Did you forget to CC him? Note that this series needs updates once we apply my syscon patches. > >> Add a soc bus driver to print chip model and revision details. >> >> Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> Naming: What to call the family vs. soc_id? >> >> drivers/soc/Kconfig | 1 + >> drivers/soc/Makefile | 1 + >> drivers/soc/realtek/Kconfig | 13 ++++ >> drivers/soc/realtek/Makefile | 2 + >> drivers/soc/realtek/chip.c | 164 >> +++++++++++++++++++++++++++++++++++++++++++ >> 5 files changed, 181 insertions(+) >> create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 >> drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c >> >> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index >> 833e04a7835c..06ae9d97321c 100644 >> --- a/drivers/soc/Kconfig >> +++ b/drivers/soc/Kconfig >> @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" >> source "drivers/soc/ixp4xx/Kconfig" >> source "drivers/soc/mediatek/Kconfig" >> source "drivers/soc/qcom/Kconfig" >> +source "drivers/soc/realtek/Kconfig" >> source "drivers/soc/renesas/Kconfig" >> source "drivers/soc/rockchip/Kconfig" >> source "drivers/soc/samsung/Kconfig" >> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index >> 2ec355003524..1d55d838a342 100644 >> --- a/drivers/soc/Makefile >> +++ b/drivers/soc/Makefile >> @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ >> obj-y += mediatek/ >> obj-y += amlogic/ >> obj-y += qcom/ >> +obj-y += realtek/ >> obj-y += renesas/ >> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ >> obj-$(CONFIG_SOC_SAMSUNG) += samsung/ >> diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file >> mode 100644 index 000000000000..be75c1889c61 >> --- /dev/null >> +++ b/drivers/soc/realtek/Kconfig >> @@ -0,0 +1,13 @@ >> +# SPDX-License-Identifier: GPL-2.0-or-later if ARCH_REALTEK || >> +COMPILE_TEST >> + >> +config REALTEK_SOC >> + tristate "Realtek chip info" >> + default ARCH_REALTEK >> + select SOC_BUS >> + help >> + Say 'y' here to enable support for SoC info on Realtek RTD1195 and >> + RTD1295 SoC families. >> + If unsure, say 'n'. >> + >> +endif >> diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new >> file mode 100644 index 000000000000..49900273905b >> --- /dev/null >> +++ b/drivers/soc/realtek/Makefile >> @@ -0,0 +1,2 @@ >> +# SPDX-License-Identifier: GPL-2.0-or-later >> +obj-$(CONFIG_REALTEK_SOC) += chip.o >> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file >> mode 100644 index 000000000000..9d13422e9936 >> --- /dev/null >> +++ b/drivers/soc/realtek/chip.c >> @@ -0,0 +1,164 @@ >> +// SPDX-License-Identifier: GPL-2.0-or-later >> +/* >> + * Realtek System-on-Chip info >> + * >> + * Copyright (c) 2017-2019 Andreas Färber */ >> + >> +#include <linux/io.h> >> +#include <linux/module.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/platform_device.h> >> +#include <linux/slab.h> >> +#include <linux/sys_soc.h> >> + >> +#define REG_CHIP_ID 0x0 >> +#define REG_CHIP_REV 0x4 >> + >> +struct rtd_soc_revision { >> + const char *name; >> + u32 chip_rev; >> +}; >> + >> +static const struct rtd_soc_revision rtd1195_revisions[] = { >> + { "A", 0x00000000 }, >> + { "B", 0x00010000 }, >> + { "C", 0x00020000 }, >> + { "D", 0x00030000 }, >> + { } >> +}; >> + >> +static const struct rtd_soc_revision rtd1295_revisions[] = { >> + { "A00", 0x00000000 }, >> + { "A01", 0x00010000 }, >> + { "B00", 0x00020000 }, >> + { "B01", 0x00030000 }, >> + { } >> +}; I believe the lower 16 bits are reserved, so we should only be comparing the upper 16. >> + >> +struct rtd_soc { >> + u32 chip_id; >> + const char *family; >> + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); >> + const struct rtd_soc_revision *revisions; >> + const char *codename; >> +}; >> + >> +static const char *default_name(struct device *dev, const struct >> +rtd_soc *s) { >> + return s->family; >> +} >> + >> +static const struct rtd_soc rtd_soc_families[] = { >> + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, >> + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, >> +}; Similarly here I believe the upper 16 bits are reserved, so we should only be comparing the lower 16, which should make it easier to stay within 80 characters per line. Regards, Andreas >> + >> +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) { >> + int i; >> + >> + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { >> + const struct rtd_soc *family = &rtd_soc_families[i]; >> + >> + if (family->chip_id == chip_id) >> + return family; >> + } >> + return NULL; >> +} >> + >> +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 >> +chip_rev) { >> + if (family) { >> + const struct rtd_soc_revision *rev = family->revisions; >> + >> + while (rev && rev->name) { >> + if (rev->chip_rev == chip_rev) >> + return rev->name; >> + rev++; >> + } >> + } >> + return "unknown"; >> +} >> + >> +static int rtd_soc_probe(struct platform_device *pdev) { >> + const struct rtd_soc *s; >> + struct soc_device_attribute *soc_dev_attr; >> + struct soc_device *soc_dev; >> + struct device_node *node; >> + void __iomem *base; >> + u32 chip_id, chip_rev; >> + >> + base = of_iomap(pdev->dev.of_node, 0); >> + if (!base) >> + return -ENODEV; >> + >> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); >> + if (!soc_dev_attr) >> + return -ENOMEM; >> + >> + chip_id = readl_relaxed(base + REG_CHIP_ID); >> + chip_rev = readl_relaxed(base + REG_CHIP_REV); >> + >> + node = of_find_node_by_path("/"); >> + of_property_read_string(node, "model", &soc_dev_attr->machine); >> + of_node_put(node); >> + >> + s = rtd_soc_by_chip_id(chip_id); >> + >> + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", >> + (s && s->codename) ? s->codename : >> + ((s && s->family) ? s->family : "Digital Home Center")); >> + >> + if (likely(s && s->get_name)) >> + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); >> + else >> + soc_dev_attr->soc_id = "unknown"; >> + >> + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); >> + >> + soc_dev = soc_device_register(soc_dev_attr); >> + if (IS_ERR(soc_dev)) { >> + kfree(soc_dev_attr->family); >> + kfree(soc_dev_attr); >> + return PTR_ERR(soc_dev); >> + } >> + >> + platform_set_drvdata(pdev, soc_dev); >> + >> + dev_info(soc_device_to_device(soc_dev), >> + "%s %s (0x%08x) rev %s (0x%08x) detected\n", >> + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >> + soc_dev_attr->revision, chip_rev); >> + >> + return 0; >> +} >> + >> +static int rtd_soc_remove(struct platform_device *pdev) { >> + struct soc_device *soc_dev = platform_get_drvdata(pdev); >> + >> + soc_device_unregister(soc_dev); >> + >> + return 0; >> +} >> + >> +static const struct of_device_id rtd_soc_dt_ids[] = { >> + { .compatible = "realtek,rtd1195-chip" }, >> + { } >> +}; >> + >> +static struct platform_driver rtd_soc_driver = { >> + .probe = rtd_soc_probe, >> + .remove = rtd_soc_remove, >> + .driver = { >> + .name = "rtd1195-soc", >> + .of_match_table = rtd_soc_dt_ids, >> + }, >> +}; >> +module_platform_driver(rtd_soc_driver); >> + >> +MODULE_DESCRIPTION("Realtek SoC identification"); >> +MODULE_LICENSE("GPL"); >> -- >> 2.16.4 >> >> >> _______________________________________________ >> linux-realtek-soc mailing list >> linux-realtek-soc@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-realtek-soc >> >> ------Please consider the environment before printing this e-mail. -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2020-01-02 14:39 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2020-01-02 14:39 UTC (permalink / raw) To: James Tai, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel Am 02.01.20 um 15:29 schrieb James Tai: > Add Stanley Chang for review. Did you forget to CC him? Note that this series needs updates once we apply my syscon patches. > >> Add a soc bus driver to print chip model and revision details. >> >> Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> Naming: What to call the family vs. soc_id? >> >> drivers/soc/Kconfig | 1 + >> drivers/soc/Makefile | 1 + >> drivers/soc/realtek/Kconfig | 13 ++++ >> drivers/soc/realtek/Makefile | 2 + >> drivers/soc/realtek/chip.c | 164 >> +++++++++++++++++++++++++++++++++++++++++++ >> 5 files changed, 181 insertions(+) >> create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 >> drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c >> >> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index >> 833e04a7835c..06ae9d97321c 100644 >> --- a/drivers/soc/Kconfig >> +++ b/drivers/soc/Kconfig >> @@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig" >> source "drivers/soc/ixp4xx/Kconfig" >> source "drivers/soc/mediatek/Kconfig" >> source "drivers/soc/qcom/Kconfig" >> +source "drivers/soc/realtek/Kconfig" >> source "drivers/soc/renesas/Kconfig" >> source "drivers/soc/rockchip/Kconfig" >> source "drivers/soc/samsung/Kconfig" >> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index >> 2ec355003524..1d55d838a342 100644 >> --- a/drivers/soc/Makefile >> +++ b/drivers/soc/Makefile >> @@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY) += lantiq/ >> obj-y += mediatek/ >> obj-y += amlogic/ >> obj-y += qcom/ >> +obj-y += realtek/ >> obj-y += renesas/ >> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ >> obj-$(CONFIG_SOC_SAMSUNG) += samsung/ >> diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig new file >> mode 100644 index 000000000000..be75c1889c61 >> --- /dev/null >> +++ b/drivers/soc/realtek/Kconfig >> @@ -0,0 +1,13 @@ >> +# SPDX-License-Identifier: GPL-2.0-or-later if ARCH_REALTEK || >> +COMPILE_TEST >> + >> +config REALTEK_SOC >> + tristate "Realtek chip info" >> + default ARCH_REALTEK >> + select SOC_BUS >> + help >> + Say 'y' here to enable support for SoC info on Realtek RTD1195 and >> + RTD1295 SoC families. >> + If unsure, say 'n'. >> + >> +endif >> diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile new >> file mode 100644 index 000000000000..49900273905b >> --- /dev/null >> +++ b/drivers/soc/realtek/Makefile >> @@ -0,0 +1,2 @@ >> +# SPDX-License-Identifier: GPL-2.0-or-later >> +obj-$(CONFIG_REALTEK_SOC) += chip.o >> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c new file >> mode 100644 index 000000000000..9d13422e9936 >> --- /dev/null >> +++ b/drivers/soc/realtek/chip.c >> @@ -0,0 +1,164 @@ >> +// SPDX-License-Identifier: GPL-2.0-or-later >> +/* >> + * Realtek System-on-Chip info >> + * >> + * Copyright (c) 2017-2019 Andreas Färber */ >> + >> +#include <linux/io.h> >> +#include <linux/module.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/platform_device.h> >> +#include <linux/slab.h> >> +#include <linux/sys_soc.h> >> + >> +#define REG_CHIP_ID 0x0 >> +#define REG_CHIP_REV 0x4 >> + >> +struct rtd_soc_revision { >> + const char *name; >> + u32 chip_rev; >> +}; >> + >> +static const struct rtd_soc_revision rtd1195_revisions[] = { >> + { "A", 0x00000000 }, >> + { "B", 0x00010000 }, >> + { "C", 0x00020000 }, >> + { "D", 0x00030000 }, >> + { } >> +}; >> + >> +static const struct rtd_soc_revision rtd1295_revisions[] = { >> + { "A00", 0x00000000 }, >> + { "A01", 0x00010000 }, >> + { "B00", 0x00020000 }, >> + { "B01", 0x00030000 }, >> + { } >> +}; I believe the lower 16 bits are reserved, so we should only be comparing the upper 16. >> + >> +struct rtd_soc { >> + u32 chip_id; >> + const char *family; >> + const char *(*get_name)(struct device *dev, const struct rtd_soc *s); >> + const struct rtd_soc_revision *revisions; >> + const char *codename; >> +}; >> + >> +static const char *default_name(struct device *dev, const struct >> +rtd_soc *s) { >> + return s->family; >> +} >> + >> +static const struct rtd_soc rtd_soc_families[] = { >> + { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, >> + { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, >> +}; Similarly here I believe the upper 16 bits are reserved, so we should only be comparing the lower 16, which should make it easier to stay within 80 characters per line. Regards, Andreas >> + >> +static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) { >> + int i; >> + >> + for (i = 0; i < ARRAY_SIZE(rtd_soc_families); i++) { >> + const struct rtd_soc *family = &rtd_soc_families[i]; >> + >> + if (family->chip_id == chip_id) >> + return family; >> + } >> + return NULL; >> +} >> + >> +static const char *rtd_soc_rev(const struct rtd_soc *family, u32 >> +chip_rev) { >> + if (family) { >> + const struct rtd_soc_revision *rev = family->revisions; >> + >> + while (rev && rev->name) { >> + if (rev->chip_rev == chip_rev) >> + return rev->name; >> + rev++; >> + } >> + } >> + return "unknown"; >> +} >> + >> +static int rtd_soc_probe(struct platform_device *pdev) { >> + const struct rtd_soc *s; >> + struct soc_device_attribute *soc_dev_attr; >> + struct soc_device *soc_dev; >> + struct device_node *node; >> + void __iomem *base; >> + u32 chip_id, chip_rev; >> + >> + base = of_iomap(pdev->dev.of_node, 0); >> + if (!base) >> + return -ENODEV; >> + >> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); >> + if (!soc_dev_attr) >> + return -ENOMEM; >> + >> + chip_id = readl_relaxed(base + REG_CHIP_ID); >> + chip_rev = readl_relaxed(base + REG_CHIP_REV); >> + >> + node = of_find_node_by_path("/"); >> + of_property_read_string(node, "model", &soc_dev_attr->machine); >> + of_node_put(node); >> + >> + s = rtd_soc_by_chip_id(chip_id); >> + >> + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Realtek %s", >> + (s && s->codename) ? s->codename : >> + ((s && s->family) ? s->family : "Digital Home Center")); >> + >> + if (likely(s && s->get_name)) >> + soc_dev_attr->soc_id = s->get_name(&pdev->dev, s); >> + else >> + soc_dev_attr->soc_id = "unknown"; >> + >> + soc_dev_attr->revision = rtd_soc_rev(s, chip_rev); >> + >> + soc_dev = soc_device_register(soc_dev_attr); >> + if (IS_ERR(soc_dev)) { >> + kfree(soc_dev_attr->family); >> + kfree(soc_dev_attr); >> + return PTR_ERR(soc_dev); >> + } >> + >> + platform_set_drvdata(pdev, soc_dev); >> + >> + dev_info(soc_device_to_device(soc_dev), >> + "%s %s (0x%08x) rev %s (0x%08x) detected\n", >> + soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >> + soc_dev_attr->revision, chip_rev); >> + >> + return 0; >> +} >> + >> +static int rtd_soc_remove(struct platform_device *pdev) { >> + struct soc_device *soc_dev = platform_get_drvdata(pdev); >> + >> + soc_device_unregister(soc_dev); >> + >> + return 0; >> +} >> + >> +static const struct of_device_id rtd_soc_dt_ids[] = { >> + { .compatible = "realtek,rtd1195-chip" }, >> + { } >> +}; >> + >> +static struct platform_driver rtd_soc_driver = { >> + .probe = rtd_soc_probe, >> + .remove = rtd_soc_remove, >> + .driver = { >> + .name = "rtd1195-soc", >> + .of_match_table = rtd_soc_dt_ids, >> + }, >> +}; >> +module_platform_driver(rtd_soc_driver); >> + >> +MODULE_DESCRIPTION("Realtek SoC identification"); >> +MODULE_LICENSE("GPL"); >> -- >> 2.16.4 >> >> >> _______________________________________________ >> linux-realtek-soc mailing list >> linux-realtek-soc@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-realtek-soc >> >> ------Please consider the environment before printing this e-mail. -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2020-01-02 14:39 ` Andreas Färber @ 2020-01-02 15:02 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 15:02 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel > Am 02.01.20 um 15:29 schrieb James Tai: > > Add Stanley Chang for review. > > Did you forget to CC him? No, Stanley Chang is in linux-realtek-soc mailing list. Thanks. Regards, James ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2020-01-02 15:02 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 15:02 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel > Am 02.01.20 um 15:29 schrieb James Tai: > > Add Stanley Chang for review. > > Did you forget to CC him? No, Stanley Chang is in linux-realtek-soc mailing list. Thanks. Regards, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 2020-01-02 14:29 ` James Tai @ 2020-01-03 5:07 ` Stanley Chang[昌育德] -1 siblings, 0 replies; 117+ messages in thread From: Stanley Chang[昌育德] @ 2020-01-03 5:07 UTC (permalink / raw) To: James Tai, Andreas Färber, linux-realtek-soc Cc: linux-kernel, linux-arm-kernel Hi Andreas, I have tested this patch in my local platform. And this patch is fine and it can work. > > Add Stanley Chang for review. > > > Add a soc bus driver to print chip model and revision details. > > > > Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. > > > > Signed-off-by: Andreas Färber <afaerber@suse.de> > > --- > > Naming: What to call the family vs. soc_id? > > > > drivers/soc/Kconfig | 1 + > > drivers/soc/Makefile | 1 + > > drivers/soc/realtek/Kconfig | 13 ++++ > > drivers/soc/realtek/Makefile | 2 + > > drivers/soc/realtek/chip.c | 164 > > +++++++++++++++++++++++++++++++++++++++++++ > > 5 files changed, 181 insertions(+) > > create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 > > drivers/soc/realtek/Makefile create mode 100644 > > drivers/soc/realtek/chip.c Tested-by: Stanley Chang <stanley_chang@realtek.com> Reviewed-by: Stanley Chang <stanley_chang@realtek.com> Thanks, Stanley ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 @ 2020-01-03 5:07 ` Stanley Chang[昌育德] 0 siblings, 0 replies; 117+ messages in thread From: Stanley Chang[昌育德] @ 2020-01-03 5:07 UTC (permalink / raw) To: James Tai, Andreas Färber, linux-realtek-soc Cc: linux-kernel, linux-arm-kernel Hi Andreas, I have tested this patch in my local platform. And this patch is fine and it can work. > > Add Stanley Chang for review. > > > Add a soc bus driver to print chip model and revision details. > > > > Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c. > > > > Signed-off-by: Andreas Färber <afaerber@suse.de> > > --- > > Naming: What to call the family vs. soc_id? > > > > drivers/soc/Kconfig | 1 + > > drivers/soc/Makefile | 1 + > > drivers/soc/realtek/Kconfig | 13 ++++ > > drivers/soc/realtek/Makefile | 2 + > > drivers/soc/realtek/chip.c | 164 > > +++++++++++++++++++++++++++++++++++++++++++ > > 5 files changed, 181 insertions(+) > > create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 > > drivers/soc/realtek/Makefile create mode 100644 > > drivers/soc/realtek/chip.c Tested-by: Stanley Chang <stanley_chang@realtek.com> Reviewed-by: Stanley Chang <stanley_chang@realtek.com> Thanks, Stanley _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree Add a DT node for chip identification. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index 4433114476f5..15a7c249155d 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -84,6 +84,11 @@ status = "disabled"; }; + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>; + }; + uart1: serial@9801b200 { compatible = "snps,dw-apb-uart"; reg = <0x9801b200 0x100>; -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel Add a DT node for chip identification. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index 4433114476f5..15a7c249155d 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -84,6 +84,11 @@ status = "disabled"; }; + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>; + }; + uart1: serial@9801b200 { compatible = "snps,dw-apb-uart"; reg = <0x9801b200 0x100>; -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node 2019-11-03 1:36 ` Andreas Färber @ 2020-01-02 14:32 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:32 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, linux-arm-kernel Add Stanley Chang for review. > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > > > _______________________________________________ > linux-realtek-soc mailing list > linux-realtek-soc@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-realtek-soc > > ------Please consider the environment before printing this e-mail. ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node @ 2020-01-02 14:32 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:32 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, linux-arm-kernel Add Stanley Chang for review. > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > > > _______________________________________________ > linux-realtek-soc mailing list > linux-realtek-soc@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-realtek-soc > > ------Please consider the environment before printing this e-mail. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node 2020-01-02 14:32 ` James Tai @ 2020-01-03 5:07 ` Stanley Chang[昌育德] -1 siblings, 0 replies; 117+ messages in thread From: Stanley Chang[昌育德] @ 2020-01-03 5:07 UTC (permalink / raw) To: James Tai, Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, linux-arm-kernel Hi Andreas, This patch is work in my platform. > Add Stanley Chang for review. > > > Add a DT node for chip identification. > > > > Signed-off-by: Andreas Färber <afaerber@suse.de> > > --- > > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > index 4433114476f5..15a7c249155d 100644 > > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > @@ -84,6 +84,11 @@ > > status = "disabled"; > > }; > > > > + chip-info@9801a200 { > > + compatible = "realtek,rtd1195-chip"; > > + reg = <0x9801a200 0x8>; > > + }; > > + > > uart1: serial@9801b200 { > > compatible = "snps,dw-apb-uart"; > > reg = <0x9801b200 0x100>; > > -- > > 2.16.4 > > Tested-by: Stanley Chang <stanley_chang@realtek.com> Reviewed-by: Stanley Chang <stanley_chang@realtek.com> Thanks, Stanley ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node @ 2020-01-03 5:07 ` Stanley Chang[昌育德] 0 siblings, 0 replies; 117+ messages in thread From: Stanley Chang[昌育德] @ 2020-01-03 5:07 UTC (permalink / raw) To: James Tai, Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, linux-arm-kernel Hi Andreas, This patch is work in my platform. > Add Stanley Chang for review. > > > Add a DT node for chip identification. > > > > Signed-off-by: Andreas Färber <afaerber@suse.de> > > --- > > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > index 4433114476f5..15a7c249155d 100644 > > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > > @@ -84,6 +84,11 @@ > > status = "disabled"; > > }; > > > > + chip-info@9801a200 { > > + compatible = "realtek,rtd1195-chip"; > > + reg = <0x9801a200 0x8>; > > + }; > > + > > uart1: serial@9801b200 { > > compatible = "snps,dw-apb-uart"; > > reg = <0x9801b200 0x100>; > > -- > > 2.16.4 > > Tested-by: Stanley Chang <stanley_chang@realtek.com> Reviewed-by: Stanley Chang <stanley_chang@realtek.com> Thanks, Stanley _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node 2019-11-03 1:36 ` Andreas Färber @ 2020-01-02 14:33 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:33 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, linux-arm-kernel > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node @ 2020-01-02 14:33 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:33 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, linux-arm-kernel > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node 2019-11-03 1:36 ` Andreas Färber @ 2020-01-02 14:34 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:34 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, linux-arm-kernel > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node @ 2020-01-02 14:34 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:34 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, linux-arm-kernel > Add a DT node for chip identification. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..15a7c249155d 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -84,6 +84,11 @@ > status = "disabled"; > }; > > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>; > + }; > + > uart1: serial@9801b200 { > compatible = "snps,dw-apb-uart"; > reg = <0x9801b200 0x100>; > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 04/11] ARM: dts: rtd1195: Add chip info node 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree Add a DT node for chip identification. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm/boot/dts/rtd1195.dtsi | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi index 9e088f669bd7..dd4f3ee6be43 100644 --- a/arch/arm/boot/dts/rtd1195.dtsi +++ b/arch/arm/boot/dts/rtd1195.dtsi @@ -133,6 +133,11 @@ status = "disabled"; }; + chip-info@1801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x1801a200 0x8>; + }; + uart1: serial@1801b200 { compatible = "snps,dw-apb-uart"; reg = <0x1801b200 0x100>; -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 04/11] ARM: dts: rtd1195: Add chip info node @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel Add a DT node for chip identification. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm/boot/dts/rtd1195.dtsi | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi index 9e088f669bd7..dd4f3ee6be43 100644 --- a/arch/arm/boot/dts/rtd1195.dtsi +++ b/arch/arm/boot/dts/rtd1195.dtsi @@ -133,6 +133,11 @@ status = "disabled"; }; + chip-info@1801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x1801a200 0x8>; + }; + uart1: serial@1801b200 { compatible = "snps,dw-apb-uart"; reg = <0x1801b200 0x100>; -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree Allow to optionally specify a second register to identify the chip. Whether needed and which register to specify depends on the family; RTD1295 family will want the CHIP_INFO1 register. Signed-off-by: Andreas Färber <afaerber@suse.de> --- A SoC specific binding would defeat the purpose of the generic Linux driver; is it possible to check the root node's compatible in an if: expression to prohibit using more than one reg on "realtek,rtd1195"? .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml index 565ad2419553..e431cf559b66 100644 --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -11,13 +11,15 @@ maintainers: description: | The Realtek SoCs have some registers to identify the chip and revision. + To identify the exact model within a family, further registers are needed. properties: compatible: const: "realtek,rtd1195-chip" reg: - maxItems: 1 + minItems: 1 + maxItems: 2 required: - compatible @@ -29,4 +31,10 @@ examples: compatible = "realtek,rtd1195-chip"; reg = <0x1801a200 0x8>; }; + - | + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>; + }; ... -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel Allow to optionally specify a second register to identify the chip. Whether needed and which register to specify depends on the family; RTD1295 family will want the CHIP_INFO1 register. Signed-off-by: Andreas Färber <afaerber@suse.de> --- A SoC specific binding would defeat the purpose of the generic Linux driver; is it possible to check the root node's compatible in an if: expression to prohibit using more than one reg on "realtek,rtd1195"? .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml index 565ad2419553..e431cf559b66 100644 --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -11,13 +11,15 @@ maintainers: description: | The Realtek SoCs have some registers to identify the chip and revision. + To identify the exact model within a family, further registers are needed. properties: compatible: const: "realtek,rtd1195-chip" reg: - maxItems: 1 + minItems: 1 + maxItems: 2 required: - compatible @@ -29,4 +31,10 @@ examples: compatible = "realtek,rtd1195-chip"; reg = <0x1801a200 0x8>; }; + - | + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>; + }; ... -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property 2019-11-03 1:36 ` Andreas Färber @ 2019-11-06 4:46 ` Rob Herring -1 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-06 4:46 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-arm-kernel, linux-kernel, Mark Rutland, devicetree On Sun, Nov 03, 2019 at 02:36:39AM +0100, Andreas Färber wrote: > Allow to optionally specify a second register to identify the chip. > Whether needed and which register to specify depends on the family; > RTD1295 family will want the CHIP_INFO1 register. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > A SoC specific binding would defeat the purpose of the generic Linux driver; Why? You can map any number of compatibles to a generic driver. > is it possible to check the root node's compatible in an if: expression > to prohibit using more than one reg on "realtek,rtd1195"? The "rule" is different programming model, different compatible string for the block. But this looks simple enough, I don't really care. > > .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > index 565ad2419553..e431cf559b66 100644 > --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > @@ -11,13 +11,15 @@ maintainers: > > description: | > The Realtek SoCs have some registers to identify the chip and revision. > + To identify the exact model within a family, further registers are needed. > > properties: > compatible: > const: "realtek,rtd1195-chip" > > reg: > - maxItems: 1 > + minItems: 1 > + maxItems: 2 > > required: > - compatible > @@ -29,4 +31,10 @@ examples: > compatible = "realtek,rtd1195-chip"; > reg = <0x1801a200 0x8>; > }; > + - | > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>, > + <0x98007028 0x4>; > + }; > ... > -- > 2.16.4 > ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property @ 2019-11-06 4:46 ` Rob Herring 0 siblings, 0 replies; 117+ messages in thread From: Rob Herring @ 2019-11-06 4:46 UTC (permalink / raw) To: Andreas Färber Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc On Sun, Nov 03, 2019 at 02:36:39AM +0100, Andreas Färber wrote: > Allow to optionally specify a second register to identify the chip. > Whether needed and which register to specify depends on the family; > RTD1295 family will want the CHIP_INFO1 register. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > A SoC specific binding would defeat the purpose of the generic Linux driver; Why? You can map any number of compatibles to a generic driver. > is it possible to check the root node's compatible in an if: expression > to prohibit using more than one reg on "realtek,rtd1195"? The "rule" is different programming model, different compatible string for the block. But this looks simple enough, I don't really care. > > .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > index 565ad2419553..e431cf559b66 100644 > --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml > @@ -11,13 +11,15 @@ maintainers: > > description: | > The Realtek SoCs have some registers to identify the chip and revision. > + To identify the exact model within a family, further registers are needed. > > properties: > compatible: > const: "realtek,rtd1195-chip" > > reg: > - maxItems: 1 > + minItems: 1 > + maxItems: 2 > > required: > - compatible > @@ -29,4 +31,10 @@ examples: > compatible = "realtek,rtd1195-chip"; > reg = <0x1801a200 0x8>; > }; > + - | > + chip-info@9801a200 { > + compatible = "realtek,rtd1195-chip"; > + reg = <0x9801a200 0x8>, > + <0x98007028 0x4>; > + }; > ... > -- > 2.16.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property 2019-11-06 4:46 ` Rob Herring @ 2019-11-06 8:42 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-06 8:42 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc Am 06.11.19 um 05:46 schrieb Rob Herring: > On Sun, Nov 03, 2019 at 02:36:39AM +0100, Andreas Färber wrote: >> Allow to optionally specify a second register to identify the chip. >> Whether needed and which register to specify depends on the family; >> RTD1295 family will want the CHIP_INFO1 register. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> A SoC specific binding would defeat the purpose of the generic Linux driver; > > Why? You can map any number of compatibles to a generic driver. Because the purpose of the driver is to read from the registers which chip it is. If we tell it via the compatible what it is supposed to be, 1) only the revision would need to be read, and 2) how should it react if the compatible tells it one thing and the register value another. Also it doesn't solve the problem that we may need to extend the binding as new models emerge, or instead of just rtd1195, rtd1295, rtd1395, etc. we'd also need one for each chip, i.e., rtd1296, cf. 1) above. >> is it possible to check the root node's compatible in an if: expression >> to prohibit using more than one reg on "realtek,rtd1195"? > > The "rule" is different programming model, different compatible string > for the block. Agreed in general. > But this looks simple enough, I don't really care. Hope you also read the cover letter wrt syscon? That would probably obsolete this binding then and require to move the driver's logic into a module init instead for lack of dedicated compatible to bind against, like Meson does. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property @ 2019-11-06 8:42 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-06 8:42 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc Am 06.11.19 um 05:46 schrieb Rob Herring: > On Sun, Nov 03, 2019 at 02:36:39AM +0100, Andreas Färber wrote: >> Allow to optionally specify a second register to identify the chip. >> Whether needed and which register to specify depends on the family; >> RTD1295 family will want the CHIP_INFO1 register. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> A SoC specific binding would defeat the purpose of the generic Linux driver; > > Why? You can map any number of compatibles to a generic driver. Because the purpose of the driver is to read from the registers which chip it is. If we tell it via the compatible what it is supposed to be, 1) only the revision would need to be read, and 2) how should it react if the compatible tells it one thing and the register value another. Also it doesn't solve the problem that we may need to extend the binding as new models emerge, or instead of just rtd1195, rtd1295, rtd1395, etc. we'd also need one for each chip, i.e., rtd1296, cf. 1) above. >> is it possible to check the root node's compatible in an if: expression >> to prohibit using more than one reg on "realtek,rtd1195"? > > The "rule" is different programming model, different compatible string > for the block. Agreed in general. > But this looks simple enough, I don't really care. Hope you also read the cover letter wrt syscon? That would probably obsolete this binding then and require to move the driver's logic into a module init instead for lack of dedicated compatible to bind against, like Meson does. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 06/11] soc: realtek: chip: Detect RTD1296 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-arm-kernel, linux-kernel, Andreas Färber Detection logic from downstream drivers/soc/realtek/rtd129x/rtk_chip.c. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index 9d13422e9936..ba653c097644 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -50,9 +50,25 @@ static const char *default_name(struct device *dev, const struct rtd_soc *s) return s->family; } +static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) +{ + void __iomem *base; + + base = of_iomap(dev->of_node, 1); + if (base) { + u32 chipinfo1 = readl_relaxed(base); + iounmap(base); + if (chipinfo1 & BIT(11)) { + return "RTD1296"; + } + } + + return "RTD1295"; +} + static const struct rtd_soc rtd_soc_families[] = { { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, - { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, + { 0x00006421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" }, }; static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 06/11] soc: realtek: chip: Detect RTD1296 @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel, Andreas Färber Detection logic from downstream drivers/soc/realtek/rtd129x/rtk_chip.c. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index 9d13422e9936..ba653c097644 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -50,9 +50,25 @@ static const char *default_name(struct device *dev, const struct rtd_soc *s) return s->family; } +static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) +{ + void __iomem *base; + + base = of_iomap(dev->of_node, 1); + if (base) { + u32 chipinfo1 = readl_relaxed(base); + iounmap(base); + if (chipinfo1 & BIT(11)) { + return "RTD1296"; + } + } + + return "RTD1295"; +} + static const struct rtd_soc rtd_soc_families[] = { { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, - { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, + { 0x00006421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" }, }; static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* RE: [RFC 06/11] soc: realtek: chip: Detect RTD1296 2019-11-03 1:36 ` Andreas Färber @ 2020-01-02 14:35 ` James Tai -1 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:35 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel > Detection logic from downstream drivers/soc/realtek/rtd129x/rtk_chip.c. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > drivers/soc/realtek/chip.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index > 9d13422e9936..ba653c097644 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -50,9 +50,25 @@ static const char *default_name(struct device *dev, > const struct rtd_soc *s) > return s->family; > } > > +static const char *rtd1295_name(struct device *dev, const struct > +rtd_soc *s) { > + void __iomem *base; > + > + base = of_iomap(dev->of_node, 1); > + if (base) { > + u32 chipinfo1 = readl_relaxed(base); > + iounmap(base); > + if (chipinfo1 & BIT(11)) { > + return "RTD1296"; > + } > + } > + > + return "RTD1295"; > +} > + > static const struct rtd_soc rtd_soc_families[] = { > { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, > - { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, > + { 0x00006421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" }, > }; > > static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> ^ permalink raw reply [flat|nested] 117+ messages in thread
* RE: [RFC 06/11] soc: realtek: chip: Detect RTD1296 @ 2020-01-02 14:35 ` James Tai 0 siblings, 0 replies; 117+ messages in thread From: James Tai @ 2020-01-02 14:35 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel > Detection logic from downstream drivers/soc/realtek/rtd129x/rtk_chip.c. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > drivers/soc/realtek/chip.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index > 9d13422e9936..ba653c097644 100644 > --- a/drivers/soc/realtek/chip.c > +++ b/drivers/soc/realtek/chip.c > @@ -50,9 +50,25 @@ static const char *default_name(struct device *dev, > const struct rtd_soc *s) > return s->family; > } > > +static const char *rtd1295_name(struct device *dev, const struct > +rtd_soc *s) { > + void __iomem *base; > + > + base = of_iomap(dev->of_node, 1); > + if (base) { > + u32 chipinfo1 = readl_relaxed(base); > + iounmap(base); > + if (chipinfo1 & BIT(11)) { > + return "RTD1296"; > + } > + } > + > + return "RTD1295"; > +} > + > static const struct rtd_soc rtd_soc_families[] = { > { 0x00006329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" }, > - { 0x00006421, "RTD1295", default_name, rtd1295_revisions, "Kylin" }, > + { 0x00006421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" }, > }; > > static const struct rtd_soc *rtd_soc_by_chip_id(u32 chip_id) > -- > 2.16.4 > Acked-by: James Tai <james.tai@realtek.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
* [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree This additional register is needed to distinguish RTD1296 from RTD1295. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index 15a7c249155d..fea7c1ed7d08 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -86,7 +86,8 @@ chip-info@9801a200 { compatible = "realtek,rtd1195-chip"; - reg = <0x9801a200 0x8>; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>; }; uart1: serial@9801b200 { -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel This additional register is needed to distinguish RTD1296 from RTD1295. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index 15a7c249155d..fea7c1ed7d08 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -86,7 +86,8 @@ chip-info@9801a200 { compatible = "realtek,rtd1195-chip"; - reg = <0x9801a200 0x8>; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>; }; uart1: serial@9801b200 { -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 08/11] soc: realtek: chip: Detect RTD1293 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-arm-kernel, linux-kernel, Andreas Färber Logic self-determined by comparing DS418j and DS418 registers. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index ba653c097644..f4b26fb048c7 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -59,6 +59,8 @@ static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) u32 chipinfo1 = readl_relaxed(base); iounmap(base); if (chipinfo1 & BIT(11)) { + if (chipinfo1 & BIT(4)) + return "RTD1293"; return "RTD1296"; } } -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 08/11] soc: realtek: chip: Detect RTD1293 @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel, Andreas Färber Logic self-determined by comparing DS418j and DS418 registers. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index ba653c097644..f4b26fb048c7 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -59,6 +59,8 @@ static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) u32 chipinfo1 = readl_relaxed(base); iounmap(base); if (chipinfo1 & BIT(11)) { + if (chipinfo1 & BIT(4)) + return "RTD1293"; return "RTD1296"; } } -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree Allow to optionally specify a third register to identify the chip. Whether needed and which register to specify depends on the family; RTD1295 family will want an efuse register. Signed-off-by: Andreas Färber <afaerber@suse.de> --- I don't like specifying an efuse register here, which seems its own IP block. .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml index e431cf559b66..249737e116d7 100644 --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -19,7 +19,7 @@ properties: reg: minItems: 1 - maxItems: 2 + maxItems: 3 required: - compatible @@ -37,4 +37,11 @@ examples: reg = <0x9801a200 0x8>, <0x98007028 0x4>; }; + - | + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>, + <0x980171d8 0x4>; + }; ... -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel Allow to optionally specify a third register to identify the chip. Whether needed and which register to specify depends on the family; RTD1295 family will want an efuse register. Signed-off-by: Andreas Färber <afaerber@suse.de> --- I don't like specifying an efuse register here, which seems its own IP block. .../devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml index e431cf559b66..249737e116d7 100644 --- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml @@ -19,7 +19,7 @@ properties: reg: minItems: 1 - maxItems: 2 + maxItems: 3 required: - compatible @@ -37,4 +37,11 @@ examples: reg = <0x9801a200 0x8>, <0x98007028 0x4>; }; + - | + chip-info@9801a200 { + compatible = "realtek,rtd1195-chip"; + reg = <0x9801a200 0x8>, + <0x98007028 0x4>, + <0x980171d8 0x4>; + }; ... -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 10/11] soc: realtek: chip: Detect RTD1294 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-arm-kernel, linux-kernel, Andreas Färber Detection logic from downstream include/soc/realtek/rtd129x_cpu.h. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index f4b26fb048c7..e13339a4ca2e 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -54,6 +54,14 @@ static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) { void __iomem *base; + base = of_iomap(dev->of_node, 2); + if (base) { + u32 efuse = readl_relaxed(base); + iounmap(base); + if ((efuse & 0x3) == 0x1) + return "RTD1294"; + } + base = of_iomap(dev->of_node, 1); if (base) { u32 chipinfo1 = readl_relaxed(base); -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 10/11] soc: realtek: chip: Detect RTD1294 @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc; +Cc: linux-kernel, linux-arm-kernel, Andreas Färber Detection logic from downstream include/soc/realtek/rtd129x_cpu.h. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/soc/realtek/chip.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index f4b26fb048c7..e13339a4ca2e 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -54,6 +54,14 @@ static const char *rtd1295_name(struct device *dev, const struct rtd_soc *s) { void __iomem *base; + base = of_iomap(dev->of_node, 2); + if (base) { + u32 efuse = readl_relaxed(base); + iounmap(base); + if ((efuse & 0x3) == 0x1) + return "RTD1294"; + } + base = of_iomap(dev->of_node, 1); if (base) { u32 chipinfo1 = readl_relaxed(base); -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse 2019-11-03 1:36 ` Andreas Färber @ 2019-11-03 1:36 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: linux-arm-kernel, linux-kernel, Andreas Färber, Rob Herring, Mark Rutland, devicetree This register is needed to detect RTD1294. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index fea7c1ed7d08..670efa86f661 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -87,7 +87,8 @@ chip-info@9801a200 { compatible = "realtek,rtd1195-chip"; reg = <0x9801a200 0x8>, - <0x98007028 0x4>; + <0x98007028 0x4>, + <0x980171d8 0x4>; }; uart1: serial@9801b200 { -- 2.16.4 ^ permalink raw reply related [flat|nested] 117+ messages in thread
* [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse @ 2019-11-03 1:36 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-03 1:36 UTC (permalink / raw) To: linux-realtek-soc Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Andreas Färber, linux-arm-kernel This register is needed to detect RTD1294. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index fea7c1ed7d08..670efa86f661 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -87,7 +87,8 @@ chip-info@9801a200 { compatible = "realtek,rtd1195-chip"; reg = <0x9801a200 0x8>, - <0x98007028 0x4>; + <0x98007028 0x4>, + <0x980171d8 0x4>; }; uart1: serial@9801b200 { -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 117+ messages in thread
* Re: [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info 2019-11-03 1:36 ` Andreas Färber @ 2019-11-07 7:16 ` Andreas Färber -1 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-07 7:16 UTC (permalink / raw) To: linux-realtek-soc; +Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel Am 03.11.19 um 02:36 schrieb Andreas Färber: > Prepared but not included here is: > * RTD1395 family, which we don't have a DT for yet, > * RTD1619 family, which we don't have a DT for yet, Chip ID to be verified, > * RTD1319 family, which we don't have a DT for yet, with TODO for its Chip ID. > > Latest experimental patches at: > https://github.com/afaerber/linux/commits/rtd1295-next For anyone wondering, the RTD1395 SoC info patch in above tree had a typo in the chip id that has been fixed and tested on BPi-M4 now. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 117+ messages in thread
* Re: [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info @ 2019-11-07 7:16 ` Andreas Färber 0 siblings, 0 replies; 117+ messages in thread From: Andreas Färber @ 2019-11-07 7:16 UTC (permalink / raw) To: linux-realtek-soc; +Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel Am 03.11.19 um 02:36 schrieb Andreas Färber: > Prepared but not included here is: > * RTD1395 family, which we don't have a DT for yet, > * RTD1619 family, which we don't have a DT for yet, Chip ID to be verified, > * RTD1319 family, which we don't have a DT for yet, with TODO for its Chip ID. > > Latest experimental patches at: > https://github.com/afaerber/linux/commits/rtd1295-next For anyone wondering, the RTD1395 SoC info patch in above tree had a typo in the chip id that has been fixed and tested on BPi-M4 now. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 117+ messages in thread
end of thread, other threads:[~2020-01-03 5:07 UTC | newest] Thread overview: 117+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-03 1:36 [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-06 4:41 ` Rob Herring 2019-11-06 4:41 ` Rob Herring 2019-11-03 1:36 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:45 ` Andreas Färber 2019-11-03 1:45 ` Andreas Färber 2019-11-11 4:56 ` [PATCH] base: soc: Export soc_device_to_device() helper Andreas Färber 2019-11-11 4:56 ` Andreas Färber 2019-11-11 5:27 ` Greg Kroah-Hartman 2019-11-11 5:27 ` Greg Kroah-Hartman 2019-11-11 5:42 ` Andreas Färber 2019-11-11 5:42 ` Andreas Färber 2019-11-11 6:40 ` Greg Kroah-Hartman 2019-11-11 6:40 ` Greg Kroah-Hartman 2019-11-11 20:10 ` Andreas Färber 2019-11-11 20:10 ` Andreas Färber 2019-11-11 20:10 ` Andreas Färber 2019-11-11 20:10 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 10:47 ` Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Andreas Färber 2019-11-12 10:47 ` Andreas Färber 2019-11-12 10:47 ` Andreas Färber 2019-11-12 10:47 ` Andreas Färber 2019-11-14 22:09 ` Rob Herring 2019-11-14 22:09 ` Rob Herring 2019-11-14 22:09 ` Rob Herring 2019-11-14 22:09 ` Rob Herring 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:15 ` [U-Boot] " Andreas Färber 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber 2019-11-15 8:52 ` Neil Armstrong 2019-11-15 8:52 ` Neil Armstrong 2019-11-15 8:52 ` Neil Armstrong 2019-11-15 8:52 ` Neil Armstrong 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-18 15:55 ` Tony Lindgren 2019-11-18 15:55 ` Tony Lindgren 2019-11-18 15:55 ` Tony Lindgren 2019-11-18 15:55 ` Tony Lindgren 2019-11-12 10:48 ` [PATCH] base: soc: Export soc_device_to_device() helper Lee Jones 2019-11-12 10:48 ` Lee Jones 2019-11-12 10:48 ` Lee Jones 2019-11-12 10:48 ` Lee Jones 2020-01-02 14:29 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 James Tai 2020-01-02 14:29 ` James Tai 2020-01-02 14:39 ` Andreas Färber 2020-01-02 14:39 ` Andreas Färber 2020-01-02 15:02 ` James Tai 2020-01-02 15:02 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2020-01-03 5:07 ` Stanley Chang[昌育德] 2019-11-03 1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2020-01-02 14:32 ` James Tai 2020-01-02 14:32 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2020-01-03 5:07 ` Stanley Chang[昌育德] 2020-01-02 14:33 ` James Tai 2020-01-02 14:33 ` James Tai 2020-01-02 14:34 ` James Tai 2020-01-02 14:34 ` James Tai 2019-11-03 1:36 ` [RFC 04/11] ARM: dts: rtd1195: " Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-06 4:46 ` Rob Herring 2019-11-06 4:46 ` Rob Herring 2019-11-06 8:42 ` Andreas Färber 2019-11-06 8:42 ` Andreas Färber 2019-11-03 1:36 ` [RFC 06/11] soc: realtek: chip: Detect RTD1296 Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2020-01-02 14:35 ` James Tai 2020-01-02 14:35 ` James Tai 2019-11-03 1:36 ` [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 08/11] soc: realtek: chip: Detect RTD1293 Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 10/11] soc: realtek: chip: Detect RTD1294 Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-03 1:36 ` [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse Andreas Färber 2019-11-03 1:36 ` Andreas Färber 2019-11-07 7:16 ` [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber 2019-11-07 7:16 ` Andreas Färber
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.