[PATCH vfs.git] MAINTAINERS: Add git tree for the FILESYSTEMS entry
From: Rafał Miłecki This helps finding the latest development code. Signed-off-by: Rafał Miłecki --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index d92f85ca831d..67317bfd46e3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6890,6 +6890,7 @@ FILESYSTEMS (VFS and infrastructure) M: Alexander Viro L: linux-fsde...@vger.kernel.org S: Maintained +T: git git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git F: fs/* F: include/linux/fs.h F: include/linux/fs_types.h -- 2.26.2
Re: New 'make dtbs_check W=1' warnings
On 2021-04-09 05:37, Florian Fainelli wrote: On 4/8/2021 8:08 AM, Arnd Bergmann wrote: Greetings to all Arm platform maintainers, I've just gone through the DT merges I've received so far and, with a little help from Rob, managed to run 'make dtbs_check W=1' before and after, to see what warnings we get. The good news is that the number of warnings is going down, but unfortunately there is still an unmanageable amount of remaining warnings, and some new ones crept in. I'm still working on my tooling for this, to catch these better, but ideally I think we should try to not introduce new warnings. I think some platforms are already clean, and I did not see any new warnings for mvebu, samsung and broadcom. There were a lot of warnings from .dtsi files, and I probably did an incomplete job at deduplicating those. There are definitively a ton of warnings for Broacom DTS files, a number of those warnings exist because the bindings were not converted to YAML. Rafal, do you think you could help me with taking care of the BCM5301X/4908 warnings? Sure, I got rid of one or two warnings already, I'll keep working on that.
Re: [PATCH] mtd: require write permissions for locking and badblock ioctls
On 03.03.2021 16:57, Michael Walle wrote:
MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
write permission. Depending on the hardware MEMLOCK might even be
write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
is always write-once.
MEMSETBADBLOCK modifies the bad block table.
Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions")
Signed-off-by: Michael Walle
Should be fine for OpenWrt tools to my best knowledge (and quick testing).
Acked-by: Rafał Miłecki
Re: [PATCH v2] net: broadcom: BCM4908_ENET should not default to y, unconditionally
On 2021-03-16 15:03, Geert Uytterhoeven wrote:
Merely enabling compile-testing should not enable additional code.
To fix this, restrict the automatic enabling of BCM4908_ENET to
ARCH_BCM4908.
Fixes: 4feffeadbcb2e5b1 ("net: broadcom: bcm4908enet: add BCM4908
controller driver")
Signed-off-by: Geert Uytterhoeven
Acked-by: Rafał Miłecki
Re: [PATCH] net: broadcom: BCM4908_ENET should not default to y, unconditionally
On 2021-03-16 14:38, Geert Uytterhoeven wrote:
Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, drop the automatic enabling of BCM4908_ENET.
Fixes: 4feffeadbcb2e5b1 ("net: broadcom: bcm4908enet: add BCM4908
controller driver")
Signed-off-by: Geert Uytterhoeven
---
Feel free to change to "default y if ARCH_BCM4908" and
To fix this, restrict the automatic enabling of BCM4908_ENET to
ARCH_BCM4908.
if you think BCM4908 SoCs cannot be used without enabling this.
Yes, please make it
default y if ARCH_BCM4908
instead.
Re: [PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml
On 2021-03-15 11:41, Vinod Koul wrote: On 11-03-21, 21:31, Rafał Miłecki wrote: Hi, On 16.11.2020 08:46, Rafał Miłecki wrote: > From: Rafał Miłecki > > 1. Change syntax from txt to yaml > 2. Drop "Driver for" from the title > 3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check) > 4. Specify license > > Signed-off-by: Rafał Miłecki > --- > I think this should go through linux-phy tree. Kishon, Vinod, can you > take this patch? > > This patch generates a false positive checkpatch.pl warning [0]. > Please ignore: > WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst > > [0] https://lkml.org/lkml/2020/2/18/1084 Kishon, Vinod: I sent this patch back in December, it was Reviewed-by Rob, but never accepted. Could you push this patch to the linux-phy.git? Can you please rebase and resent me this patch. I am trying to streamline patches now using phy ml and pw instance so that we dont miss anything.. Both patches apply cleanly. Maybe your mail client malformed them for you? They are accessible in the devicetree-bindings patchwork: https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201116074650.16070-1-zaj...@gmail.com/ https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201116074650.16070-2-zaj...@gmail.com/ You can apply both patches doing e.g.: curl https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201116074650.16070-1-zaj...@gmail.com/mbox/ | git am curl https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201116074650.16070-2-zaj...@gmail.com/mbox/ | git am
Re: [PATCH v5 2/3] dt-bindings: mtd: Document use of nvmem-cells compatible
On 11.03.2021 11:50, Ansuel Smith wrote: On Thu, Mar 11, 2021 at 10:32:21AM -0700, Rob Herring wrote: On Thu, Mar 11, 2021 at 06:12:48AM +0100, Ansuel Smith wrote: Document nvmem-cells compatible used to treat mtd partitions as a nvmem provider. Signed-off-by: Ansuel Smith --- .../bindings/mtd/partitions/nvmem-cells.yaml | 99 +++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml new file mode 100644 index ..b53faf87d4e4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/nvmem-cells.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nvmem cells + +description: | + Any partition containing the compatible "nvmem-cells" will register as a + nvmem provider. + Each direct subnodes represents a nvmem cell following the nvmem binding. + Nvmem binding to declare nvmem-cells can be found in: + Documentation/devicetree/bindings/nvmem/nvmem.yaml + +maintainers: + - Ansuel Smith + +allOf: + - $ref: "../../nvmem/nvmem.yaml#" I'd rather have the 'absolute' path: /schemas/nvmem/nvmem.yaml Otherwise, Reviewed-by: Rob Herring Should I send a v7? Yes, please, let's make it the right way :) When sending V7 please: 1. Include above "Reviewed-by" in the "dt-bindings: mtd: Document use of nvmem-cells compatible" 2. Include my "Tested-by" in the "mtd: core: add nvmem-cells compatible to parse mtd as nvmem cells" Reference: [PATCH v2 2/3] mtd: core: add nvmem-partitions compatible to parse mtd as nvmem cells https://patchwork.ozlabs.org/project/linux-mtd/patch/20210216212638.28382-3-ansuels...@gmail.com/
Re: [PATCH] dt-bindings: phy: bcm-ns-usb2-phy: convert to yaml
On 16.11.2020 08:46, Rafał Miłecki wrote:
From: Rafał Miłecki
1. Convert from txt to yaml
2. Drop "Driver for" from the title
3. Document "#phy-cells"
4. Fix example node name (noticed by dt_binding_check)
5. Add #include to example (noticed by dt_binding_check)
6. Specify license
Signed-off-by: Rafał Miłecki
---
I think this should go through linux-phy tree. Kishon, Vinod, can you
take this patch?
This patch generates a false positive checkpatch.pl warning [0].
Please ignore:
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
[0] https://lkml.org/lkml/2020/2/18/1084
Same thing here.
Kishon, Vinod: I sent this patch back in December, it was Reviewed-by
Rob, but never accepted.
Could you push this patch to the linux-phy.git?
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/bcm-ns-usb2-phy.yaml | 59 +++
2 files changed, 59 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
deleted file mode 100644
index a7aee9ea8926..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Driver for Broadcom Northstar USB 2.0 PHY
-
-Required properties:
-- compatible: brcm,ns-usb2-phy
-- reg: iomem address range of DMU (Device Management Unit)
-- reg-names: "dmu", the only needed & supported reg right now
-- clocks: USB PHY reference clock
-- clock-names: "phy-ref-clk", the only needed & supported clock right now
-
-To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
-requires passing phandle to the USB PHY reference clock.
-
-Example:
- usb2-phy {
- compatible = "brcm,ns-usb2-phy";
- reg = <0x1800c000 0x1000>;
- reg-names = "dmu";
- #phy-cells = <0>;
- clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
- clock-names = "phy-ref-clk";
- };
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
new file mode 100644
index ..05b4dcd80019
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/bcm-ns-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 2.0 PHY
+
+description: >
+ To initialize USB 2.0 PHY driver needs to setup PLL correctly.
+ To do this it requires passing phandle to the USB PHY reference clock.
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,ns-usb2-phy
+
+ reg:
+items:
+ - description: iomem address range of DMU (Device Management Unit)
+
+ reg-names:
+items:
+ - const: dmu
+
+ clocks:
+items:
+ - description: USB PHY reference clock
+
+ clock-names:
+items:
+ - const: phy-ref-clk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+phy@1800c000 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x1800c000 0x1000>;
+reg-names = "dmu";
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
Re: [PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml
Hi,
On 16.11.2020 08:46, Rafał Miłecki wrote:
From: Rafał Miłecki
1. Change syntax from txt to yaml
2. Drop "Driver for" from the title
3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check)
4. Specify license
Signed-off-by: Rafał Miłecki
---
I think this should go through linux-phy tree. Kishon, Vinod, can you
take this patch?
This patch generates a false positive checkpatch.pl warning [0].
Please ignore:
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
[0] https://lkml.org/lkml/2020/2/18/1084
Kishon, Vinod: I sent this patch back in December, it was Reviewed-by
Rob, but never accepted.
Could you push this patch to the linux-phy.git?
---
.../bindings/phy/bcm-ns-usb3-phy.txt | 34 --
.../bindings/phy/bcm-ns-usb3-phy.yaml | 62 +++
2 files changed, 62 insertions(+), 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
deleted file mode 100644
index 32f057260351..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Driver for Broadcom Northstar USB 3.0 PHY
-
-Required properties:
-
-- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
-- reg: address of MDIO bus device
-- usb3-dmp-syscon: phandle to syscon with DMP (Device Management Plugin)
- registers
-- #phy-cells: must be 0
-
-Initialization of USB 3.0 PHY depends on Northstar version. There are currently
-three known series: Ax, Bx and Cx.
-Known A0: BCM4707 rev 0
-Known B0: BCM4707 rev 4, BCM53573 rev 2
-Known B1: BCM4707 rev 6
-Known C0: BCM47094 rev 0
-
-Example:
- mdio: mdio@0 {
- reg = <0x0>;
- #size-cells = <1>;
- #address-cells = <0>;
-
- usb3-phy@10 {
- compatible = "brcm,ns-ax-usb3-phy";
- reg = <0x10>;
- usb3-dmp-syscon = <_dmp>;
- #phy-cells = <0>;
- };
- };
-
- usb3_dmp: syscon@18105000 {
- reg = <0x18105000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
new file mode 100644
index ..7fd419db45d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/bcm-ns-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 3.0 PHY
+
+description: |
+ Initialization of USB 3.0 PHY depends on Northstar version. There are
currently
+ three known series: Ax, Bx and Cx.
+ Known A0: BCM4707 rev 0
+ Known B0: BCM4707 rev 4, BCM53573 rev 2
+ Known B1: BCM4707 rev 6
+ Known C0: BCM47094 rev 0
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,ns-ax-usb3-phy
+ - brcm,ns-bx-usb3-phy
+
+ reg:
+description: address of MDIO bus device
+maxItems: 1
+
+ usb3-dmp-syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ Phandle to the DMP (Device Management Plugin) syscon
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - usb3-dmp-syscon
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+mdio {
+#address-cells = <1>;
+#size-cells = <0>;
+
+usb3-phy@10 {
+compatible = "brcm,ns-ax-usb3-phy";
+reg = <0x10>;
+usb3-dmp-syscon = <_dmp>;
+#phy-cells = <0>;
+};
+};
+
+usb3_dmp: syscon@18105000 {
+reg = <0x18105000 0x1000>;
+};
Re: [PATCH v4 2/3] dt-bindings: mtd: Document use of nvmem-cells compatible
On 10.03.2021 23:47, Ansuel Smith wrote: On Wed, Mar 10, 2021 at 11:41:24PM +0100, Rafał Miłecki wrote: See inline On 10.03.2021 22:08, Ansuel Smith wrote: Document nvmem-cells compatible used to treat mtd partitions as a nvmem provider. Signed-off-by: Ansuel Smith --- .../bindings/mtd/partitions/nvmem-cells.yaml | 96 +++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml new file mode 100644 index ..f70d7597a6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/nvmem-cells.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nvmem cells + +description: | + Any partition containing the compatible "nvmem-cells" will register as a + nvmem provider. + Each direct subnodes represents a nvmem cell following the nvmem binding. + Nvmem binding to declare nvmem-cells can be found in: + Documentation/devicetree/bindings/nvmem/nvmem.yaml + +maintainers: + - Ansuel Smith I think that when Rob wrote: On 10.03.2021 03:58, Rob Herring wrote: I think this should reference nvmem.yaml. he meant you using: allOf: - $ref: "nvmem.yaml#" (you'll need to adjust binding path). Please check how it's done in Documentation/devicetree/bindings/nvmem/*.yaml files Aside from that, should I readd the old properties or I can keep the compatible as the only one required? What old properties do you mean? You shouldn't need to add anything to the list of "required" I think. Some NVMEM providers add "#address-cells" and "#size-cells". That makes sense if NVMEM provider must provide at least 1 cell. I'm not sure if we need that for MTD. Even "compatible" is actually redundant but most YAML files list it for convenience. Source: On 10.12.2020 03:48, Rob Herring wrote: > And drop 'compatible' as required. It's redundant anyways because the > schema will only be applied if compatible matches. http://lists.infradead.org/pipermail/linux-mtd/2020-December/084574.html https://patchwork.ozlabs.org/comment/2597326/
Re: [PATCH v4 2/3] dt-bindings: mtd: Document use of nvmem-cells compatible
See inline On 10.03.2021 22:08, Ansuel Smith wrote: Document nvmem-cells compatible used to treat mtd partitions as a nvmem provider. Signed-off-by: Ansuel Smith --- .../bindings/mtd/partitions/nvmem-cells.yaml | 96 +++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml new file mode 100644 index ..f70d7597a6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/nvmem-cells.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nvmem cells + +description: | + Any partition containing the compatible "nvmem-cells" will register as a + nvmem provider. + Each direct subnodes represents a nvmem cell following the nvmem binding. + Nvmem binding to declare nvmem-cells can be found in: + Documentation/devicetree/bindings/nvmem/nvmem.yaml + +maintainers: + - Ansuel Smith I think that when Rob wrote: On 10.03.2021 03:58, Rob Herring wrote: > I think this should reference nvmem.yaml. he meant you using: allOf: - $ref: "nvmem.yaml#" (you'll need to adjust binding path). Please check how it's done in Documentation/devicetree/bindings/nvmem/*.yaml files +properties: + compatible: +const: nvmem-cells
Re: [PATCH 2/3] dt-bindings: phy: brcm,ns-usb2-phy: bind single CRU reg
On 06.03.2021 22:52, Rob Herring wrote:
On Fri, Feb 26, 2021 at 12:45:00PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU register that controls
USB 2.0 PHY. It's still required to reference CRU generic clkset
register so add a syscon for that.
For a full DMU & CRU description see arch/arm/boot/dts/bcm5301x.dtsi .
The old binding is deprecated now.
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
I'd really like to get Rob's ack to make sure I don't do anything stupid
It's a reworked version of my abonded 2019 patch:
[PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20190108123907.19816-1-zaj...@gmail.com/
---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 46 +++
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
index b8b683ce8fa9..8e056d4d205a 100644
--- a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -16,11 +16,20 @@ properties:
const: brcm,ns-usb2-phy
reg:
-maxItems: 1
-description: DMU (Device Management Unit) address range
+anyOf:
+ - maxItems: 1
+description: PHY control register
+ - maxItems: 1
+description: DMU (Device Management Unit) address range
+deprecated: true
reg-names:
const: dmu
+deprecated: true
+
+ brcm,syscon-clkset:
+description: phandle to syscon for clkset register
+$ref: /schemas/types.yaml#/definitions/phandle
Don't really need this as it's just a compatible node of the parent
node.
Thanks
clocks:
maxItems: 1
@@ -34,22 +43,39 @@ properties:
required:
- reg
- - reg-names
- clocks
- clock-names
- "#phy-cells"
+oneOf:
+ - required:
+ - brcm,syscon-clkset
+ - required:
+ - reg-names
+
additionalProperties: false
examples:
- |
#include
-usb2-phy@1800c000 {
-compatible = "brcm,ns-usb2-phy";
-reg = <0x1800c000 0x1000>;
-reg-names = "dmu";
-clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
-clock-names = "phy-ref-clk";
-#phy-cells = <0>;
+cru-bus@1800c100 {
+compatible = "simple-bus";
A specific compatible is needed for this block.
I've just sent independently following patch:
[PATCH robh next] dt-bindings: bus: add Broadcom CRU
+ranges = <0 0x1800c100 0x1a4>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+usb2-phy@64 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x64 0x4>;
+brcm,syscon-clkset = <>;
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
+
+clkset: syscon@80 {
+compatible = "brcm,cru-clkset", "syscon";
+reg = <0x80 0x4>;
+};
Is this going to expand to 0x1a4/4 child nodes? The problem with one
node per register is I don't know when it ends and you have to
constantly update your DT.
I'm sorry, I don't fully understand that expanding question.
Most of CRU subblocks are standalone devices occupying multiple
registers. The last one is thermal@1800c2c0. That "brcm,cru-clkset"
seems to be an exception in the CRU space. clkset is a single
register so it should never become reg = <0x80 0x8>;
The finally documented CRU is expected to look like:
cru-bus@1800c100 {
compatible = "brcm,cru", "simple-bus";
reg = <0x1800c100 0x1d0>;
ranges = <0 0x1800c100 0x1d0>;
#address-cells = <1>;
#size-cells = <1>;
lcpll0@0 {
compatible = "brcm,nsp-lcpll0";
reg = <0x0 0x14>;
(...)
};
genpll@40 {
compatible = "brcm,nsp-genpll";
reg = <0x40 0x24>;
(...)
};
usb2-phy@64 {
compatible = "brcm,ns-usb2-phy";
reg = <0x64 0x4>;
brcm,syscon-clkset = <>;
clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
clock-names = "phy-ref-clk";
#phy-cells = <0>;
};
clkset: syscon@80 {
compatible = "brcm,cru-clkset", "syscon";
reg = <0x80 0x4>;
};
pin-controller@c0 {
compatible = "brcm,bcm4708-pinmux";
reg = <0xc0 0x24>;
(...)
};
thermal@1c0 {
compatible = "brcm,ns-thermal";
reg = <0x1c0 0x10>;
(...)
};
};
[PATCH robh next] dt-bindings: usb: add USB controller port
From: Rafał Miłecki
USB bindings already allow specifying USB device hard wired to a
specific controller port but they don't allow describing port on its
own.
This fixes:
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml: usb@23000: port@1:
'compatible' is a required property
From schema: Documentation/devicetree/bindings/usb/generic-xhci.yaml
Signed-off-by: Rafał Miłecki
---
Please check if I got the $nodename part right. Somehow I don't see any
errors / warnings when using:
something@1 {
reg = <1>;
};
---
.../devicetree/bindings/usb/usb-hcd.yaml | 4 +-
.../devicetree/bindings/usb/usb-port.yaml | 39 +++
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-port.yaml
diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
index 56853c17af66..b0c6a79cad57 100644
--- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
@@ -33,7 +33,9 @@ patternProperties:
"^.*@[0-9a-f]{1,2}$":
description: The hard wired USB devices
type: object
-$ref: /usb/usb-device.yaml
+oneOf:
+ - $ref: /usb/usb-port.yaml
+ - $ref: /usb/usb-device.yaml
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/usb-port.yaml
b/Documentation/devicetree/bindings/usb/usb-port.yaml
new file mode 100644
index ..68fe16c8703e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-port.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB port on USB controller
+
+maintainers:
+ - Rafał Miłecki
+
+description: |
+ This binding describes a single USB controller port that doesn't have any
+ device hard wired.
+
+properties:
+ $nodename:
+pattern: "^port@[0-9a-f]{1,2}$"
+
+ reg:
+description: number of USB controller port
+maxItems: 1
+
+required:
+ - reg
+
+additionalProperties: true
+
+examples:
+ - |
+usb@1127 {
+reg = <0x1127 0x1000>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+reg = <1>;
+};
+};
--
2.26.2
Re: [PATCH stblinux.git 1/2] dt-bindings: firmware: add Broadcom's NVRAM memory mapping
On 08.03.2021 22:37, Rafał Miłecki wrote: On 08.03.2021 19:43, Rob Herring wrote: On Tue, Mar 02, 2021 at 08:44:04AM +0100, Rafał Miłecki wrote: From: Rafał Miłecki NVRAM structure contains device data and can be accessed using MMIO. Signed-off-by: Rafał Miłecki --- .../bindings/firmware/brcm,nvram.yaml | 41 +++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/brcm,nvram.yaml diff --git a/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml new file mode 100644 index ..12af8e2e7c9c --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/firmware/brcm,nvram.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Broadcom's NVRAM + +maintainers: + - Rafał Miłecki + +description: | + NVRAM is a structure containing device specific environment variables. + It is used for storing device configuration, booting parameters and + calibration data. The structure of the data is fully discoverable just from a genericish 'brcm,nvram'? Yes, NVRAM structure is a header (with magic and length) and a list of key-value pairs separated by \0. If you map memory at given address you should verify magic and start reading key-value pairs. Content example: foo=bar\0baz=qux\0quux(...) There is no predefined order of pairs, set of keys or anything similar I could think of. I can't think of anything more worth describing in DT. Ah, I've just realized, I'm replying to the "firmware" binding patch. Florian suggested to look at NVMEM subsystem instead. Please kindly check [PATCH V2 1/2] dt-bindings: nvmem: add Broadcom's NVRAM
Re: [PATCH stblinux.git 1/2] dt-bindings: firmware: add Broadcom's NVRAM memory mapping
On 08.03.2021 19:43, Rob Herring wrote: On Tue, Mar 02, 2021 at 08:44:04AM +0100, Rafał Miłecki wrote: From: Rafał Miłecki NVRAM structure contains device data and can be accessed using MMIO. Signed-off-by: Rafał Miłecki --- .../bindings/firmware/brcm,nvram.yaml | 41 +++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/brcm,nvram.yaml diff --git a/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml new file mode 100644 index ..12af8e2e7c9c --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/firmware/brcm,nvram.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Broadcom's NVRAM + +maintainers: + - Rafał Miłecki + +description: | + NVRAM is a structure containing device specific environment variables. + It is used for storing device configuration, booting parameters and + calibration data. The structure of the data is fully discoverable just from a genericish 'brcm,nvram'? Yes, NVRAM structure is a header (with magic and length) and a list of key-value pairs separated by \0. If you map memory at given address you should verify magic and start reading key-value pairs. Content example: foo=bar\0baz=qux\0quux(...) There is no predefined order of pairs, set of keys or anything similar I could think of. I can't think of anything more worth describing in DT. And it's a dedicated memory outside of regular RAM? Yes
Re: [PATCH v2 3/3] dt-bindings: mtd: Document use of nvmem-partitions compatible
On 07.03.2021 18:04, Ansuel Smith wrote: On Mon, Mar 08, 2021 at 10:48:32AM +0100, Rafał Miłecki wrote: On 16.02.2021 22:26, Ansuel Smith wrote: Document nvmem-partitions compatible used to treat mtd partitions as a nvmem provider. I'm just wondering if "nvmem-partitions" is accurate enough. Partitions bit sounds a bit ambiguous in the mtd context. What do you think about "mtd-nvmem-cells" or just "nvmem-cells"? I read somewhere that mtd is not so standard so "nvmem-cells" should be the right compatible. To sum up, with v2 I should change the compatible name and just push the 2 and 3 patch. (waiting your fix to be accepted) Correct? I'm also quite sure you're fine to send V2 now, if you just let maintainers know (e.g. in a comment below a --- tear line) that it depends on the: [PATCH] mtd: parsers: ofpart: limit parsing of deprecated DT syntax In other words: you don't need to wait for my patch to get accepted.
Re: [PATCH v2 3/3] dt-bindings: mtd: Document use of nvmem-partitions compatible
On 07.03.2021 18:04, Ansuel Smith wrote: On Mon, Mar 08, 2021 at 10:48:32AM +0100, Rafał Miłecki wrote: On 16.02.2021 22:26, Ansuel Smith wrote: Document nvmem-partitions compatible used to treat mtd partitions as a nvmem provider. I'm just wondering if "nvmem-partitions" is accurate enough. Partitions bit sounds a bit ambiguous in the mtd context. What do you think about "mtd-nvmem-cells" or just "nvmem-cells"? I read somewhere that mtd is not so standard so "nvmem-cells" should be the right compatible. To sum up, with v2 I should change the compatible name and just push the 2 and 3 patch. (waiting your fix to be accepted) Correct? Yes, I believe so
Re: [PATCH v2 3/3] dt-bindings: mtd: Document use of nvmem-partitions compatible
On 16.02.2021 22:26, Ansuel Smith wrote: Document nvmem-partitions compatible used to treat mtd partitions as a nvmem provider. I'm just wondering if "nvmem-partitions" is accurate enough. Partitions bit sounds a bit ambiguous in the mtd context. What do you think about "mtd-nvmem-cells" or just "nvmem-cells"?
Re: [PATCH v2 3/3] dt-bindings: mtd: Document use of nvmem-partitions compatible
On 05.03.2021 23:23, Rob Herring wrote:
On Wed, Mar 03, 2021 at 11:01:55AM +0100, Rafał Miłecki wrote:
[Rob: please advise]
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
Until now we were using "compatible" string in partition node only for
parsers (looking for subpartitions). We need to think if this change can
break anything from DT / Linux perspective.
Compatible strings should be unique, so there is no risk of conflict
between NVMEM and parsers.
Now: can we ever need mtd partition to:
1. Contain subpartitions
2. Provide NVMEM
at the same time?
Let's say:
partition@0 {
compatible = "vendor,dynamic-firmware-partitions", "nvmem-partitions";
I think you'd want the "vendor,dynamic-firmware-partitions" parser/code
to serve up any nvmem regions. Whether you have a fallback here depends
if an OS could make use of the regions knowing nothing about
"vendor,dynamic-firmware-partitions".
Perfect! I didn't think that driver handling
"vendor,dynamic-firmware-partitions" may also take care of NVMEM.
Thank you.
[PATCH mips/linux.git 5/5] firmware: bcm47xx_nvram: inline code checking NVRAM size
From: Rafał Miłecki
Separated function was not improving code quality much (or at all).
Moreover it expected possible flash end address as argument and it was
returning NVRAM size.
The new code always operates on offsets which means less logic and less
calculations.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 25 +++
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 1d2271b1e07a..bd235833b687 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -42,18 +42,6 @@ static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
}
-static u32 find_nvram_size(void __iomem *end)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
- if (bcm47xx_nvram_is_valid(end - nvram_sizes[i]))
- return nvram_sizes[i];
- }
-
- return 0;
-}
-
/**
* bcm47xx_nvram_copy - copy NVRAM to internal buffer
*/
@@ -85,7 +73,7 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
{
size_t flash_size;
size_t offset;
- u32 size;
+ int i;
if (nvram_len) {
pr_warn("nvram already initialized\n");
@@ -93,12 +81,13 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
+
+ /* Try every possible flash size and check for NVRAM at its end */
for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
- /* Windowed flash access */
- size = find_nvram_size(flash_start + flash_size);
- if (size) {
- offset = flash_size - size;
- goto found;
+ for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
+ offset = flash_size - nvram_sizes[i];
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
+ goto found;
}
}
--
2.26.2
[PATCH mips/linux.git 4/5] firmware: bcm47xx_nvram: look for NVRAM with for instead of while
From: Rafał Miłecki
This loop requires variable initialization, stop condition and post
iteration increment. It's pretty much a for loop definition.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 09f51b95849e..1d2271b1e07a 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -93,15 +93,13 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
- flash_size = FLASH_MIN;
- while (flash_size <= res_size) {
+ for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
/* Windowed flash access */
size = find_nvram_size(flash_start + flash_size);
if (size) {
offset = flash_size - size;
goto found;
}
- flash_size <<= 1;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
--
2.26.2
[PATCH mips/linux.git 3/5] firmware: bcm47xx_nvram: extract code copying NVRAM
From: Rafał Miłecki
This simplifies function finding NVRAM. It doesn't directly deal with
NVRAM structure anymore and is a bit smaller.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 43 +--
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 99f3ec180be6..09f51b95849e 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -54,12 +54,35 @@ static u32 find_nvram_size(void __iomem *end)
return 0;
}
+/**
+ * bcm47xx_nvram_copy - copy NVRAM to internal buffer
+ */
+static void bcm47xx_nvram_copy(void __iomem *nvram_start, size_t res_size)
+{
+ struct nvram_header __iomem *header = nvram_start;
+ size_t copy_size;
+
+ copy_size = header->len;
+ if (copy_size > res_size) {
+ pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
+ copy_size = res_size;
+ }
+ if (copy_size >= NVRAM_SPACE) {
+ pr_err("nvram on flash (%zu bytes) is bigger than the reserved
space in memory, will just copy the first %i bytes\n",
+ copy_size, NVRAM_SPACE - 1);
+ copy_size = NVRAM_SPACE - 1;
+ }
+
+ __ioread32_copy(nvram_buf, nvram_start, DIV_ROUND_UP(copy_size, 4));
+ nvram_buf[NVRAM_SPACE - 1] = '\0';
+ nvram_len = copy_size;
+}
+
/**
* bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
*/
static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t
res_size)
{
- struct nvram_header __iomem *header;
size_t flash_size;
size_t offset;
u32 size;
@@ -95,23 +118,7 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
return -ENXIO;
found:
- header = (struct nvram_header *)(flash_start + offset);
- __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
- nvram_len = ((struct nvram_header *)(nvram_buf))->len;
- size = res_size - offset;
- if (nvram_len > size) {
- pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
- nvram_len = size;
- }
- if (nvram_len >= NVRAM_SPACE) {
- pr_err("nvram on flash (%zu bytes) is bigger than the reserved
space in memory, will just copy the first %i bytes\n",
- nvram_len, NVRAM_SPACE - 1);
- nvram_len = NVRAM_SPACE - 1;
- }
- /* proceed reading data after header */
- __ioread32_copy(nvram_buf + sizeof(*header), header + 1,
- DIV_ROUND_UP(nvram_len, 4));
- nvram_buf[NVRAM_SPACE - 1] = '\0';
+ bcm47xx_nvram_copy(flash_start + offset, res_size - offset);
return 0;
}
--
2.26.2
[PATCH mips/linux.git 2/5] firmware: bcm47xx_nvram: add helper checking for NVRAM
From: Rafał Miłecki
This avoids duplicating code doing casting and checking for NVRAM magic.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 30 ++-
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index b04007adc79f..99f3ec180be6 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -34,14 +34,20 @@ static char nvram_buf[NVRAM_SPACE];
static size_t nvram_len;
static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
+/**
+ * bcm47xx_nvram_is_valid - check for a valid NVRAM at specified memory
+ */
+static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
+{
+ return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
+}
+
static u32 find_nvram_size(void __iomem *end)
{
- struct nvram_header __iomem *header;
int i;
for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
- header = (struct nvram_header *)(end - nvram_sizes[i]);
- if (header->magic == NVRAM_MAGIC)
+ if (bcm47xx_nvram_is_valid(end - nvram_sizes[i]))
return nvram_sizes[i];
}
@@ -55,6 +61,7 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
{
struct nvram_header __iomem *header;
size_t flash_size;
+ size_t offset;
u32 size;
if (nvram_len) {
@@ -68,31 +75,30 @@ static int bcm47xx_nvram_find_and_copy(void __iomem
*flash_start, size_t res_siz
/* Windowed flash access */
size = find_nvram_size(flash_start + flash_size);
if (size) {
- header = (struct nvram_header *)(flash_start +
flash_size - size);
+ offset = flash_size - size;
goto found;
}
flash_size <<= 1;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
- header = (struct nvram_header *)(flash_start + 4096);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
+
+ offset = 4096;
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
goto found;
- }
- header = (struct nvram_header *)(flash_start + 1024);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
+ offset = 1024;
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
goto found;
- }
pr_err("no nvram found\n");
return -ENXIO;
found:
+ header = (struct nvram_header *)(flash_start + offset);
__ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
nvram_len = ((struct nvram_header *)(nvram_buf))->len;
+ size = res_size - offset;
if (nvram_len > size) {
pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
nvram_len = size;
--
2.26.2
[PATCH mips/linux.git 1/5] firmware: bcm47xx_nvram: rename finding function and its variables
From: Rafał Miłecki
1. Use "bcm47xx_" function name prefix for consistency
2. It takes flash start as argument so s/iobase/flash_start/
3. "off" was used for finding flash end so just call it "flash_size"
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 24 ---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..b04007adc79f 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -48,11 +48,13 @@ static u32 find_nvram_size(void __iomem *end)
return 0;
}
-/* Probe for NVRAM header */
-static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
+/**
+ * bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
+ */
+static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t
res_size)
{
struct nvram_header __iomem *header;
- u32 off;
+ size_t flash_size;
u32 size;
if (nvram_len) {
@@ -61,25 +63,25 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
lim)
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
- off = FLASH_MIN;
- while (off <= lim) {
+ flash_size = FLASH_MIN;
+ while (flash_size <= res_size) {
/* Windowed flash access */
- size = find_nvram_size(iobase + off);
+ size = find_nvram_size(flash_start + flash_size);
if (size) {
- header = (struct nvram_header *)(iobase + off - size);
+ header = (struct nvram_header *)(flash_start +
flash_size - size);
goto found;
}
- off <<= 1;
+ flash_size <<= 1;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
- header = (struct nvram_header *)(iobase + 4096);
+ header = (struct nvram_header *)(flash_start + 4096);
if (header->magic == NVRAM_MAGIC) {
size = NVRAM_SPACE;
goto found;
}
- header = (struct nvram_header *)(iobase + 1024);
+ header = (struct nvram_header *)(flash_start + 1024);
if (header->magic == NVRAM_MAGIC) {
size = NVRAM_SPACE;
goto found;
@@ -124,7 +126,7 @@ int bcm47xx_nvram_init_from_mem(u32 base, u32 lim)
if (!iobase)
return -ENOMEM;
- err = nvram_find_and_copy(iobase, lim);
+ err = bcm47xx_nvram_find_and_copy(iobase, lim);
iounmap(iobase);
--
2.26.2
[PATCH mips/linux.git 0/5] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
From: Rafał Miłecki This patchset refactors driver part finding and reading NVRAM. It been tested on BCM4706. Updated code checks the same offsets as before. Driver still finds & copies NVRAM content. It's a new patchset replacing previous single-patch attempt: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM Rafał Miłecki (5): firmware: bcm47xx_nvram: rename finding function and its variables firmware: bcm47xx_nvram: add helper checking for NVRAM firmware: bcm47xx_nvram: extract code copying NVRAM firmware: bcm47xx_nvram: look for NVRAM with for instead of while firmware: bcm47xx_nvram: inline code checking NVRAM size drivers/firmware/broadcom/bcm47xx_nvram.c | 92 --- 1 file changed, 47 insertions(+), 45 deletions(-) -- 2.26.2
Re: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
On 2021-03-06 09:00, Thomas Bogendoerfer wrote: On Fri, Mar 05, 2021 at 12:56:55PM +0100, Rafał Miłecki wrote: On 05.03.2021 12:47, Philippe Mathieu-Daudé wrote: > On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote: > > On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote: > > > On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote: > > > > > > > > From: Rafał Miłecki > > > > > > > > 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead > > > > of e.g. "iobase", "end") > > > > 2. Always operate on "offset" instead of mix of start, end, size, etc. > > > > > > "instead of a mix" > > > > > > > 3. Add helper checking for NVRAM to avoid duplicating code > > > > 4. Use "found" variable instead of goto > > > > 5. Use simpler checking of offsets and sizes (2 nested loops with > > > > trivial check instead of extra function) > > > > > > This could be a series of trivial patches, why did you choose to make a mixed > > > bag harder to review? > > > > It's a subjective thing and often a matter of maintainer taste. I can > > say that after contributing to various Linux subsystems. If you split a > > similar patch for MTD subsystem you'll get complains about making > > changes too small & too hard to review (sic!). > > Fine. MTD subsystem developers are probably smarter than I'm :) > > > This isn't a bomb really: 63 insertions(+), 48 deletions(-) > > Too many changes at once for my brain stack doesn't mean others are > willing to review it. But to me that means each time I'll have to pass over > it while bisecting or reviewing git history I'll suffer the same overflow. > Anyway, matter of taste as you said. If I hear another voice for splitting this change into smaller patches I'm 100% happy to do so. Honestly! I just don't know if by splitting I won't annoy other people by making changes too small. Please speak up! :) please split it. IMHO the current is patch is hard to review, because of the different changes mixed together. Will do, thank you for comments Philippe, Thomas!
Re: [PATCH 3/3] phy: bcm-ns-usb2: support updated single CRU reg DT binding
Cc linux-phy@ again (after fixing recipients ML limit)
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has been deprecated and stays as a fallback method.
Signed-off-by: Rafał Miłecki
---
It's a reworked version of my abonded 2019 patch:
[PATCH V2 2/2] phy: bcm-ns-usb2: support updated DT binding with the CRU syscon
https://lore.kernel.org/patchwork/patch/1029863/
---
drivers/phy/broadcom/phy-bcm-ns-usb2.c | 52 +-
1 file changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
index 4b015b8a71c3..98d32729a45d 100644
--- a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
+++ b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
@@ -9,17 +9,23 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
struct bcm_ns_usb2 {
struct device *dev;
struct clk *ref_clk;
struct phy *phy;
+ struct regmap *clkset;
+ void __iomem *base;
+
+ /* Deprecated binding */
void __iomem *dmu;
};
@@ -27,7 +33,6 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
{
struct bcm_ns_usb2 *usb2 = phy_get_drvdata(phy);
struct device *dev = usb2->dev;
- void __iomem *dmu = usb2->dmu;
u32 ref_clk_rate, usb2ctl, usb_pll_ndiv, usb_pll_pdiv;
int err = 0;
@@ -44,7 +49,10 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
goto err_clk_off;
}
- usb2ctl = readl(dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ usb2ctl = readl(usb2->base);
+ else
+ usb2ctl = readl(usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
if (usb2ctl & BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_PDIV_MASK) {
usb_pll_pdiv = usb2ctl;
@@ -58,15 +66,24 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
usb_pll_ndiv = (192000 * usb_pll_pdiv) / ref_clk_rate;
/* Unlock DMU PLL settings with some magic value */
- writel(0xea68, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0xea68);
+ else
+ writel(0xea68, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
/* Write USB 2.0 PLL control setting */
usb2ctl &= ~BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_MASK;
usb2ctl |= usb_pll_ndiv << BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_SHIFT;
- writel(usb2ctl, dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ writel(usb2ctl, usb2->base);
+ else
+ writel(usb2ctl, usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
/* Lock DMU PLL settings */
- writel(0x, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0x);
+ else
+ writel(0x, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
err_clk_off:
clk_disable_unprepare(usb2->ref_clk);
@@ -90,10 +107,27 @@ static int bcm_ns_usb2_probe(struct platform_device *pdev)
return -ENOMEM;
usb2->dev = dev;
- usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
- if (IS_ERR(usb2->dmu)) {
- dev_err(dev, "Failed to map DMU regs\n");
- return PTR_ERR(usb2->dmu);
+ if (of_find_property(dev->of_node, "brcm,syscon-clkset", NULL)) {
+ usb2->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(usb2->base)) {
+ dev_err(dev, "Failed to map control reg\n");
+ return PTR_ERR(usb2->base);
+ }
+
+ usb2->clkset = syscon_regmap_lookup_by_phandle(dev->of_node,
+
"brcm,syscon-clkset");
+ if (IS_ERR(usb2->clkset)) {
+ dev_err(dev, "Failed to lookup clkset regmap\n");
+ return PTR_ERR(usb2->clkset);
+ }
+ } else {
+ usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
+ if (IS_ERR(usb2->dmu)) {
+ dev_err(dev, "Failed to map DMU regs\n");
+ return PTR_ERR(usb2->dmu);
+ }
+
+ dev_warn(dev, "using deprecated DT binding\n");
}
usb2->ref_clk = devm_clk_get(dev, "phy-ref-clk");
Re: [PATCH 2/3] dt-bindings: phy: brcm,ns-usb2-phy: bind single CRU reg
Cc linux-phy@ again (after fixing recipients ML limit)
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU register that controls
USB 2.0 PHY. It's still required to reference CRU generic clkset
register so add a syscon for that.
For a full DMU & CRU description see arch/arm/boot/dts/bcm5301x.dtsi .
The old binding is deprecated now.
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
I'd really like to get Rob's ack to make sure I don't do anything stupid
It's a reworked version of my abonded 2019 patch:
[PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20190108123907.19816-1-zaj...@gmail.com/
---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 46 +++
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
index b8b683ce8fa9..8e056d4d205a 100644
--- a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -16,11 +16,20 @@ properties:
const: brcm,ns-usb2-phy
reg:
-maxItems: 1
-description: DMU (Device Management Unit) address range
+anyOf:
+ - maxItems: 1
+description: PHY control register
+ - maxItems: 1
+description: DMU (Device Management Unit) address range
+deprecated: true
reg-names:
const: dmu
+deprecated: true
+
+ brcm,syscon-clkset:
+description: phandle to syscon for clkset register
+$ref: /schemas/types.yaml#/definitions/phandle
clocks:
maxItems: 1
@@ -34,22 +43,39 @@ properties:
required:
- reg
- - reg-names
- clocks
- clock-names
- "#phy-cells"
+oneOf:
+ - required:
+ - brcm,syscon-clkset
+ - required:
+ - reg-names
+
additionalProperties: false
examples:
- |
#include
-usb2-phy@1800c000 {
-compatible = "brcm,ns-usb2-phy";
-reg = <0x1800c000 0x1000>;
-reg-names = "dmu";
-clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
-clock-names = "phy-ref-clk";
-#phy-cells = <0>;
+cru-bus@1800c100 {
+compatible = "simple-bus";
+ranges = <0 0x1800c100 0x1a4>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+usb2-phy@64 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x64 0x4>;
+brcm,syscon-clkset = <>;
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
+
+clkset: syscon@80 {
+compatible = "brcm,cru-clkset", "syscon";
+reg = <0x80 0x4>;
+};
};
Re: [PATCH 1/3] dt-bindings: phy: convert Broadcom NS USB 2.0 to the json-schema
Cc linux-phy@ again (after fixing recipients limit)
On 26.02.2021 12:44, Rafał Miłecki wrote:
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 55 +++
2 files changed, 55 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
deleted file mode 100644
index a7aee9ea8926..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Driver for Broadcom Northstar USB 2.0 PHY
-
-Required properties:
-- compatible: brcm,ns-usb2-phy
-- reg: iomem address range of DMU (Device Management Unit)
-- reg-names: "dmu", the only needed & supported reg right now
-- clocks: USB PHY reference clock
-- clock-names: "phy-ref-clk", the only needed & supported clock right now
-
-To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
-requires passing phandle to the USB PHY reference clock.
-
-Example:
- usb2-phy {
- compatible = "brcm,ns-usb2-phy";
- reg = <0x1800c000 0x1000>;
- reg-names = "dmu";
- #phy-cells = <0>;
- clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
- clock-names = "phy-ref-clk";
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
new file mode 100644
index ..b8b683ce8fa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,ns-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 2.0 PHY
+
+description: Broadcom's USB 2.0 PHY integrated into Northstar family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,ns-usb2-phy
+
+ reg:
+maxItems: 1
+description: DMU (Device Management Unit) address range
+
+ reg-names:
+const: dmu
+
+ clocks:
+maxItems: 1
+description: USB PHY reference clock
+
+ clock-names:
+const: phy-ref-clk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+usb2-phy@1800c000 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x1800c000 0x1000>;
+reg-names = "dmu";
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
[PATCH V2 1/2] dt-bindings: nvmem: add Broadcom's NVRAM
From: Rafał Miłecki
Broadcom's NVRAM structure contains device data and can be accessed
using I/O mapping.
Signed-off-by: Rafał Miłecki
---
V2: Use Broadcom's NVRAM specific binding. Generic "nvmem-iomap" binding
didn't make much sense. Thanks Srinivas!
---
.../devicetree/bindings/nvmem/brcm,nvram.yaml | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
new file mode 100644
index ..58ff6b0bdb1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/brcm,nvram.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom's NVRAM
+
+description: |
+ Broadcom's NVRAM is a structure containing device specific environment
+ variables. It is used for storing device configuration, booting parameters
+ and calibration data.
+
+ NVRAM can be accessed on Broadcom BCM47xx MIPS and Northstar ARM Cortex-A9
+ devices usiong I/O mapped memory.
+
+maintainers:
+ - Rafał Miłecki
+
+allOf:
+ - $ref: "nvmem.yaml#"
+
+properties:
+ compatible:
+const: brcm,nvram
+
+unevaluatedProperties: false
+
+examples:
+ - |
+nvram@1eff {
+compatible = "brcm,nvram";
+reg = <0x1eff 0x1>;
+};
--
2.26.2
[PATCH V2 2/2] nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM
From: Rafał Miłecki
This driver provides access to Broadcom's NVRAM.
Signed-off-by: Rafał Miłecki
---
V2: Applied Srinivas's suggestions:
* Simplified brcm_nvram_read
* Drop unneeded check & prints from probe
* Fixed MODULE_LICENSE
* Switched to Broadcom specific binding & driver. This is such a trivial
driver that even if we get another similar one, it probably won't be worth
it to share their code.
Thank you Srinivas!
---
drivers/nvmem/Kconfig | 9 +
drivers/nvmem/Makefile | 2 +
drivers/nvmem/brcm_nvram.c | 78 ++
3 files changed, 89 insertions(+)
create mode 100644 drivers/nvmem/brcm_nvram.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 75d2594c16e1..d2a848fab82a 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -278,4 +278,13 @@ config NVMEM_RMEM
This driver can also be built as a module. If so, the module
will be called nvmem-rmem.
+
+config NVMEM_BRCM_NVRAM
+ tristate "Broadcom's NVRAM support"
+ depends on ARCH_BCM_5301X || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ This driver provides support for Broadcom's NVRAM that can be accessed
+ using I/O mapping.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 5376b8e0dae5..bbea1410240a 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -57,3 +57,5 @@ obj-$(CONFIG_SPRD_EFUSE) += nvmem_sprd_efuse.o
nvmem_sprd_efuse-y := sprd-efuse.o
obj-$(CONFIG_NVMEM_RMEM) += nvmem-rmem.o
nvmem-rmem-y := rmem.o
+obj-$(CONFIG_NVMEM_BRCM_NVRAM) += nvmem_brcm_nvram.o
+nvmem_brcm_nvram-y := brcm_nvram.o
diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c
new file mode 100644
index ..bd2ecaaf4585
--- /dev/null
+++ b/drivers/nvmem/brcm_nvram.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct brcm_nvram {
+ struct device *dev;
+ void __iomem *base;
+};
+
+static int brcm_nvram_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct brcm_nvram *priv = context;
+ u8 *dst = val;
+
+ while (bytes--)
+ *dst++ = readb(priv->base + offset++);
+
+ return 0;
+}
+
+static int brcm_nvram_probe(struct platform_device *pdev)
+{
+ struct nvmem_config config = {
+ .name = "brcm-nvram",
+ .reg_read = brcm_nvram_read,
+ };
+ struct device *dev = >dev;
+ struct resource *res;
+ struct brcm_nvram *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ config.dev = dev;
+ config.priv = priv;
+ config.size = resource_size(res);
+
+ return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, ));
+}
+
+static const struct of_device_id brcm_nvram_of_match_table[] = {
+ { .compatible = "brcm,nvram", },
+ {},
+};
+
+static struct platform_driver brcm_nvram_driver = {
+ .probe = brcm_nvram_probe,
+ .driver = {
+ .name = "brcm_nvram",
+ .of_match_table = brcm_nvram_of_match_table,
+ },
+};
+
+static int __init brcm_nvram_init(void)
+{
+ return platform_driver_register(_nvram_driver);
+}
+
+subsys_initcall_sync(brcm_nvram_init);
+
+MODULE_AUTHOR("Rafał Miłecki");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, brcm_nvram_of_match_table);
--
2.26.2
Re: [PATCH 3/3] phy: bcm-ns-usb2: support updated single CRU reg DT binding
Cc linux-phy@
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has been deprecated and stays as a fallback method.
Signed-off-by: Rafał Miłecki
---
It's a reworked version of my abonded 2019 patch:
[PATCH V2 2/2] phy: bcm-ns-usb2: support updated DT binding with the CRU syscon
https://lore.kernel.org/patchwork/patch/1029863/
---
drivers/phy/broadcom/phy-bcm-ns-usb2.c | 52 +-
1 file changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
index 4b015b8a71c3..98d32729a45d 100644
--- a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
+++ b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
@@ -9,17 +9,23 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
struct bcm_ns_usb2 {
struct device *dev;
struct clk *ref_clk;
struct phy *phy;
+ struct regmap *clkset;
+ void __iomem *base;
+
+ /* Deprecated binding */
void __iomem *dmu;
};
@@ -27,7 +33,6 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
{
struct bcm_ns_usb2 *usb2 = phy_get_drvdata(phy);
struct device *dev = usb2->dev;
- void __iomem *dmu = usb2->dmu;
u32 ref_clk_rate, usb2ctl, usb_pll_ndiv, usb_pll_pdiv;
int err = 0;
@@ -44,7 +49,10 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
goto err_clk_off;
}
- usb2ctl = readl(dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ usb2ctl = readl(usb2->base);
+ else
+ usb2ctl = readl(usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
if (usb2ctl & BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_PDIV_MASK) {
usb_pll_pdiv = usb2ctl;
@@ -58,15 +66,24 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
usb_pll_ndiv = (192000 * usb_pll_pdiv) / ref_clk_rate;
/* Unlock DMU PLL settings with some magic value */
- writel(0xea68, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0xea68);
+ else
+ writel(0xea68, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
/* Write USB 2.0 PLL control setting */
usb2ctl &= ~BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_MASK;
usb2ctl |= usb_pll_ndiv << BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_SHIFT;
- writel(usb2ctl, dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ writel(usb2ctl, usb2->base);
+ else
+ writel(usb2ctl, usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
/* Lock DMU PLL settings */
- writel(0x, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0x);
+ else
+ writel(0x, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
err_clk_off:
clk_disable_unprepare(usb2->ref_clk);
@@ -90,10 +107,27 @@ static int bcm_ns_usb2_probe(struct platform_device *pdev)
return -ENOMEM;
usb2->dev = dev;
- usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
- if (IS_ERR(usb2->dmu)) {
- dev_err(dev, "Failed to map DMU regs\n");
- return PTR_ERR(usb2->dmu);
+ if (of_find_property(dev->of_node, "brcm,syscon-clkset", NULL)) {
+ usb2->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(usb2->base)) {
+ dev_err(dev, "Failed to map control reg\n");
+ return PTR_ERR(usb2->base);
+ }
+
+ usb2->clkset = syscon_regmap_lookup_by_phandle(dev->of_node,
+
"brcm,syscon-clkset");
+ if (IS_ERR(usb2->clkset)) {
+ dev_err(dev, "Failed to lookup clkset regmap\n");
+ return PTR_ERR(usb2->clkset);
+ }
+ } else {
+ usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
+ if (IS_ERR(usb2->dmu)) {
+ dev_err(dev, "Failed to map DMU regs\n");
+ return PTR_ERR(usb2->dmu);
+ }
+
+ dev_warn(dev, "using deprecated DT binding\n");
}
usb2->ref_clk = devm_clk_get(dev, "phy-ref-clk");
Re: [PATCH 2/3] dt-bindings: phy: brcm,ns-usb2-phy: bind single CRU reg
Cc linux-phy@
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU register that controls
USB 2.0 PHY. It's still required to reference CRU generic clkset
register so add a syscon for that.
For a full DMU & CRU description see arch/arm/boot/dts/bcm5301x.dtsi .
The old binding is deprecated now.
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
I'd really like to get Rob's ack to make sure I don't do anything stupid
It's a reworked version of my abonded 2019 patch:
[PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20190108123907.19816-1-zaj...@gmail.com/
---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 46 +++
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
index b8b683ce8fa9..8e056d4d205a 100644
--- a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -16,11 +16,20 @@ properties:
const: brcm,ns-usb2-phy
reg:
-maxItems: 1
-description: DMU (Device Management Unit) address range
+anyOf:
+ - maxItems: 1
+description: PHY control register
+ - maxItems: 1
+description: DMU (Device Management Unit) address range
+deprecated: true
reg-names:
const: dmu
+deprecated: true
+
+ brcm,syscon-clkset:
+description: phandle to syscon for clkset register
+$ref: /schemas/types.yaml#/definitions/phandle
clocks:
maxItems: 1
@@ -34,22 +43,39 @@ properties:
required:
- reg
- - reg-names
- clocks
- clock-names
- "#phy-cells"
+oneOf:
+ - required:
+ - brcm,syscon-clkset
+ - required:
+ - reg-names
+
additionalProperties: false
examples:
- |
#include
-usb2-phy@1800c000 {
-compatible = "brcm,ns-usb2-phy";
-reg = <0x1800c000 0x1000>;
-reg-names = "dmu";
-clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
-clock-names = "phy-ref-clk";
-#phy-cells = <0>;
+cru-bus@1800c100 {
+compatible = "simple-bus";
+ranges = <0 0x1800c100 0x1a4>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+usb2-phy@64 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x64 0x4>;
+brcm,syscon-clkset = <>;
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
+
+clkset: syscon@80 {
+compatible = "brcm,cru-clkset", "syscon";
+reg = <0x80 0x4>;
+};
};
Re: [PATCH 1/3] dt-bindings: phy: convert Broadcom NS USB 2.0 to the json-schema
Cc linux-phy@
On 26.02.2021 12:44, Rafał Miłecki wrote:
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 55 +++
2 files changed, 55 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
deleted file mode 100644
index a7aee9ea8926..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Driver for Broadcom Northstar USB 2.0 PHY
-
-Required properties:
-- compatible: brcm,ns-usb2-phy
-- reg: iomem address range of DMU (Device Management Unit)
-- reg-names: "dmu", the only needed & supported reg right now
-- clocks: USB PHY reference clock
-- clock-names: "phy-ref-clk", the only needed & supported clock right now
-
-To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
-requires passing phandle to the USB PHY reference clock.
-
-Example:
- usb2-phy {
- compatible = "brcm,ns-usb2-phy";
- reg = <0x1800c000 0x1000>;
- reg-names = "dmu";
- #phy-cells = <0>;
- clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
- clock-names = "phy-ref-clk";
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
new file mode 100644
index ..b8b683ce8fa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,ns-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 2.0 PHY
+
+description: Broadcom's USB 2.0 PHY integrated into Northstar family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,ns-usb2-phy
+
+ reg:
+maxItems: 1
+description: DMU (Device Management Unit) address range
+
+ reg-names:
+const: dmu
+
+ clocks:
+maxItems: 1
+description: USB PHY reference clock
+
+ clock-names:
+const: phy-ref-clk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+usb2-phy@1800c000 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x1800c000 0x1000>;
+reg-names = "dmu";
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
Re: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
On 05.03.2021 12:47, Philippe Mathieu-Daudé wrote: On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote: On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote: On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote: From: Rafał Miłecki 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead of e.g. "iobase", "end") 2. Always operate on "offset" instead of mix of start, end, size, etc. "instead of a mix" 3. Add helper checking for NVRAM to avoid duplicating code 4. Use "found" variable instead of goto 5. Use simpler checking of offsets and sizes (2 nested loops with trivial check instead of extra function) This could be a series of trivial patches, why did you choose to make a mixed bag harder to review? It's a subjective thing and often a matter of maintainer taste. I can say that after contributing to various Linux subsystems. If you split a similar patch for MTD subsystem you'll get complains about making changes too small & too hard to review (sic!). Fine. MTD subsystem developers are probably smarter than I'm :) This isn't a bomb really: 63 insertions(+), 48 deletions(-) Too many changes at once for my brain stack doesn't mean others are willing to review it. But to me that means each time I'll have to pass over it while bisecting or reviewing git history I'll suffer the same overflow. Anyway, matter of taste as you said. If I hear another voice for splitting this change into smaller patches I'm 100% happy to do so. Honestly! I just don't know if by splitting I won't annoy other people by making changes too small. Please speak up! :)
Re: [PATCH 2/2] nvmem: iomap: new driver exposing NVMEM accessible using I/O mapping
On 05.03.2021 11:33, Srinivas Kandagatla wrote:
On 05/03/2021 10:24, Rafał Miłecki wrote:
+static int iomap_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct iomap *priv = context;
+ u8 *src = priv->base + offset;
+ u8 *dst = val;
+ size_t tmp;
+
+ tmp = offset % 4;
+ memcpy_fromio(dst, src, tmp);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ tmp = rounddown(bytes, 4);
+ __ioread32_copy(dst, src, tmp / 4);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ memcpy_fromio(dst, src, bytes);
+
You could just do this!
while (bytes--)
*val++ = readb(priv->base + offset + i++);
Do you mean that as replacement for "memcpy_fromio" or the whole
function code?
Yes please!
The reason for using __ioread32_copy() was to improve reading
performance (using aligned 32 bit access where possible). I'm not sure
if that really matters?
Just simple while loop is much readable than the previous code TBH!
P.S.
Please don't yell at me in every sentence :( Makes me a bit sad :(
Sorry!! I did not mean anything as such! :-)
All clear (I hope)! Thanks for your review!
Re: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
Hi, On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote: On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote: From: Rafał Miłecki 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead of e.g. "iobase", "end") 2. Always operate on "offset" instead of mix of start, end, size, etc. "instead of a mix" 3. Add helper checking for NVRAM to avoid duplicating code 4. Use "found" variable instead of goto 5. Use simpler checking of offsets and sizes (2 nested loops with trivial check instead of extra function) This could be a series of trivial patches, why did you choose to make a mixed bag harder to review? It's a subjective thing and often a matter of maintainer taste. I can say that after contributing to various Linux subsystems. If you split a similar patch for MTD subsystem you'll get complains about making changes too small & too hard to review (sic!). This isn't a bomb really: 63 insertions(+), 48 deletions(-) That said I admit I don't know MIPS tree habits. Thomas: do you prefer smaller patches in case like this?
Re: [PATCH 2/2] nvmem: iomap: new driver exposing NVMEM accessible using I/O mapping
On 05.03.2021 11:02, Srinivas Kandagatla wrote:
On 04/03/2021 14:41, Rafał Miłecki wrote:
From: Rafał Miłecki
This is a generic NVMEM access method used e.g. by Broadcom for their
NVRAM on MIPS and Northstar devices.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/Kconfig | 7 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/iomap.c | 99 ++
3 files changed, 108 insertions(+)
create mode 100644 drivers/nvmem/iomap.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 75d2594c16e1..3d5c5684685d 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -278,4 +278,11 @@ config NVMEM_RMEM
This driver can also be built as a module. If so, the module
will be called nvmem-rmem.
+
+config NVMEM_IOMAP
+ tristate "I/O mapped NVMEM support"
+ depends on HAS_IOMEM
+ help
+ This driver supports NVMEM that can be accessed using I/O mapping.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 5376b8e0dae5..88a3b6979c53 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -57,3 +57,5 @@ obj-$(CONFIG_SPRD_EFUSE) += nvmem_sprd_efuse.o
nvmem_sprd_efuse-y := sprd-efuse.o
obj-$(CONFIG_NVMEM_RMEM) += nvmem-rmem.o
nvmem-rmem-y := rmem.o
+obj-$(CONFIG_NVMEM_IOMAP) += nvmem_iomap.o
+nvmem_iomap-y := iomap.o
diff --git a/drivers/nvmem/iomap.c b/drivers/nvmem/iomap.c
new file mode 100644
index ..ab6b40858a64
--- /dev/null
+++ b/drivers/nvmem/iomap.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct iomap {
+ struct device *dev;
+ void __iomem *base;
+};
+
+static int iomap_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct iomap *priv = context;
+ u8 *src = priv->base + offset;
+ u8 *dst = val;
+ size_t tmp;
+
+ tmp = offset % 4;
+ memcpy_fromio(dst, src, tmp);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ tmp = rounddown(bytes, 4);
+ __ioread32_copy(dst, src, tmp / 4);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ memcpy_fromio(dst, src, bytes);
+
You could just do this!
while (bytes--)
*val++ = readb(priv->base + offset + i++);
Do you mean that as replacement for "memcpy_fromio" or the whole
function code?
The reason for using __ioread32_copy() was to improve reading
performance (using aligned 32 bit access where possible). I'm not sure
if that really matters?
P.S.
Please don't yell at me in every sentence :( Makes me a bit sad :(
Re: [PATCH -next] mtd: parsers: ofpart: make symbol 'bcm4908_partitions_quirks' static
On 04.03.2021 07:46, 'Wei Yongjun wrote:
From: Wei Yongjun
The sparse tool complains as follows:
drivers/mtd/parsers/ofpart_core.c:25:32: warning:
symbol 'bcm4908_partitions_quirks' was not declared. Should it be static?
This symbol is not used outside of ofpart_core.c, so this
commit marks it static.
Fixes: 457da931b608 ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
Looks good ofc, thanks.
[PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicating code
4. Use "found" variable instead of goto
5. Use simpler checking of offsets and sizes (2 nested loops with
trivial check instead of extra function)
This change has been tested on BCM4706. Updated code checks the same
offsets as before. Driver still finds & copies NVRAM content.
Signed-off-by: Rafał Miłecki
---
V2: Fix comment to match actual function name
Reported-by: kernel test robot
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 111 --
1 file changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..b47c80a79358 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -34,26 +34,47 @@ static char nvram_buf[NVRAM_SPACE];
static size_t nvram_len;
static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
-static u32 find_nvram_size(void __iomem *end)
+/**
+ * bcm47xx_nvram_is_valid - check for a valid NVRAM at specified memory
+ */
+static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
{
- struct nvram_header __iomem *header;
- int i;
+ return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
+}
- for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
- header = (struct nvram_header *)(end - nvram_sizes[i]);
- if (header->magic == NVRAM_MAGIC)
- return nvram_sizes[i];
+/**
+ * bcm47xx_nvram_copy - copy NVRAM to internal buffer
+ */
+static void bcm47xx_nvram_copy(void __iomem *nvram_start, size_t res_size)
+{
+ struct nvram_header __iomem *header = nvram_start;
+ size_t copy_size;
+
+ copy_size = header->len;
+ if (copy_size > res_size) {
+ pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
+ copy_size = res_size;
+ }
+ if (copy_size >= NVRAM_SPACE) {
+ pr_err("nvram on flash (%zu bytes) is bigger than the reserved
space in memory, will just copy the first %i bytes\n",
+ copy_size, NVRAM_SPACE - 1);
+ copy_size = NVRAM_SPACE - 1;
}
- return 0;
+ __ioread32_copy(nvram_buf, nvram_start, DIV_ROUND_UP(copy_size, 4));
+ nvram_buf[NVRAM_SPACE - 1] = '\0';
+ nvram_len = copy_size;
}
-/* Probe for NVRAM header */
-static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
+/**
+ * bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
+ */
+static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t
res_size)
{
- struct nvram_header __iomem *header;
- u32 off;
- u32 size;
+ size_t flash_size;
+ size_t offset;
+ bool found;
+ int i;
if (nvram_len) {
pr_warn("nvram already initialized\n");
@@ -61,49 +82,43 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
lim)
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
- off = FLASH_MIN;
- while (off <= lim) {
- /* Windowed flash access */
- size = find_nvram_size(iobase + off);
- if (size) {
- header = (struct nvram_header *)(iobase + off - size);
- goto found;
+
+ found = false;
+
+ /* Try every possible flash size and check for NVRAM at its end */
+ for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
+ for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
+ offset = flash_size - nvram_sizes[i];
+ if (bcm47xx_nvram_is_valid(flash_start + offset)) {
+ found = true;
+ break;
+ }
}
- off <<= 1;
+
+ if (found)
+ break;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
- header = (struct nvram_header *)(iobase + 4096);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
- }
- header = (struct nvram_header *)(iobase + 1024);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
+ if (!found) {
+ offset = 4096;
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
+ found = true;
}
- pr_err("no nvram found\n");
-
[PATCH 2/2] nvmem: iomap: new driver exposing NVMEM accessible using I/O mapping
From: Rafał Miłecki
This is a generic NVMEM access method used e.g. by Broadcom for their
NVRAM on MIPS and Northstar devices.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/Kconfig | 7 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/iomap.c | 99 ++
3 files changed, 108 insertions(+)
create mode 100644 drivers/nvmem/iomap.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 75d2594c16e1..3d5c5684685d 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -278,4 +278,11 @@ config NVMEM_RMEM
This driver can also be built as a module. If so, the module
will be called nvmem-rmem.
+
+config NVMEM_IOMAP
+ tristate "I/O mapped NVMEM support"
+ depends on HAS_IOMEM
+ help
+ This driver supports NVMEM that can be accessed using I/O mapping.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 5376b8e0dae5..88a3b6979c53 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -57,3 +57,5 @@ obj-$(CONFIG_SPRD_EFUSE) += nvmem_sprd_efuse.o
nvmem_sprd_efuse-y := sprd-efuse.o
obj-$(CONFIG_NVMEM_RMEM) += nvmem-rmem.o
nvmem-rmem-y := rmem.o
+obj-$(CONFIG_NVMEM_IOMAP) += nvmem_iomap.o
+nvmem_iomap-y := iomap.o
diff --git a/drivers/nvmem/iomap.c b/drivers/nvmem/iomap.c
new file mode 100644
index ..ab6b40858a64
--- /dev/null
+++ b/drivers/nvmem/iomap.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct iomap {
+ struct device *dev;
+ void __iomem *base;
+};
+
+static int iomap_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct iomap *priv = context;
+ u8 *src = priv->base + offset;
+ u8 *dst = val;
+ size_t tmp;
+
+ tmp = offset % 4;
+ memcpy_fromio(dst, src, tmp);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ tmp = rounddown(bytes, 4);
+ __ioread32_copy(dst, src, tmp / 4);
+ dst += tmp;
+ src += tmp;
+ bytes -= tmp;
+
+ memcpy_fromio(dst, src, bytes);
+
+ return 0;
+}
+
+static int iomap_probe(struct platform_device *pdev)
+{
+ struct nvmem_config config = {
+ .name = "iomap",
+ .reg_read = iomap_read,
+ };
+ struct device *dev = >dev;
+ struct resource *res;
+ struct iomap *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Failed to get resource\n");
+ return -ENODEV;
+ }
+
+ priv->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->base)) {
+ dev_err(dev, "Failed to map resource: %ld\n",
PTR_ERR(priv->base));
+ return PTR_ERR(priv->base);
+ }
+
+ config.dev = dev;
+ config.priv = priv;
+ config.size = resource_size(res);
+
+ return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, ));
+}
+
+static const struct of_device_id iomap_of_match_table[] = {
+ { .compatible = "brcm,nvram", },
+ { .compatible = "nvmem-iomap", },
+ {},
+};
+
+static struct platform_driver iomap_driver = {
+ .probe = iomap_probe,
+ .driver = {
+ .name = "nvmem_iomap",
+ .of_match_table = iomap_of_match_table,
+ },
+};
+
+static int __init iomap_init(void)
+{
+ return platform_driver_register(_driver);
+}
+
+subsys_initcall_sync(iomap_init);
+
+MODULE_AUTHOR("Rafał Miłecki");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, iomap_of_match_table);
--
2.26.2
[PATCH 1/2] dt-bindings: nvmem: add binding for I/O mapped NVMEM
From: Rafał Miłecki
NVMEM on some devices can be accessed using I/O mapping. For example on
Broadcom MIPS and ARM Northstar platforms NVRAM can be accessed that
way.
Signed-off-by: Rafał Miłecki
---
.../devicetree/bindings/nvmem/iomap.yaml | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/iomap.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/iomap.yaml
b/Documentation/devicetree/bindings/nvmem/iomap.yaml
new file mode 100644
index ..ec8764598061
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/iomap.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/iomap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I/O mapped NVMEM
+
+maintainers:
+ - Rafał Miłecki
+
+allOf:
+ - $ref: "nvmem.yaml#"
+
+properties:
+ compatible:
+items:
+ - enum:
+ - brcm,nvram
+ - const: nvmem-iomap
+
+unevaluatedProperties: false
+
+examples:
+ - |
+nvram@1eff {
+compatible = "brcm,nvram", "nvmem-iomap";
+reg = <0x1eff 0x1>;
+};
--
2.26.2
[PATCH mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicating code
4. Use "found" variable instead of goto
5. Use simpler checking of offsets and sizes (2 nested loops with
trivial check instead of extra function)
This change has been tested on BCM4706. Updated code checks the same
offsets as before. Driver still finds & copies NVRAM content.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 111 --
1 file changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..7cfe857b3e98 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -34,26 +34,47 @@ static char nvram_buf[NVRAM_SPACE];
static size_t nvram_len;
static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
-static u32 find_nvram_size(void __iomem *end)
+/**
+ * bcm47xx_nvram_validate - check for a valid NVRAM at specified memory
+ */
+static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
{
- struct nvram_header __iomem *header;
- int i;
+ return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
+}
- for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
- header = (struct nvram_header *)(end - nvram_sizes[i]);
- if (header->magic == NVRAM_MAGIC)
- return nvram_sizes[i];
+/**
+ * bcm47xx_nvram_copy - copy NVRAM to internal buffer
+ */
+static void bcm47xx_nvram_copy(void __iomem *nvram_start, size_t res_size)
+{
+ struct nvram_header __iomem *header = nvram_start;
+ size_t copy_size;
+
+ copy_size = header->len;
+ if (copy_size > res_size) {
+ pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
+ copy_size = res_size;
+ }
+ if (copy_size >= NVRAM_SPACE) {
+ pr_err("nvram on flash (%zu bytes) is bigger than the reserved
space in memory, will just copy the first %i bytes\n",
+ copy_size, NVRAM_SPACE - 1);
+ copy_size = NVRAM_SPACE - 1;
}
- return 0;
+ __ioread32_copy(nvram_buf, nvram_start, DIV_ROUND_UP(copy_size, 4));
+ nvram_buf[NVRAM_SPACE - 1] = '\0';
+ nvram_len = copy_size;
}
-/* Probe for NVRAM header */
-static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
+/**
+ * bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
+ */
+static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t
res_size)
{
- struct nvram_header __iomem *header;
- u32 off;
- u32 size;
+ size_t flash_size;
+ size_t offset;
+ bool found;
+ int i;
if (nvram_len) {
pr_warn("nvram already initialized\n");
@@ -61,49 +82,43 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
lim)
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
- off = FLASH_MIN;
- while (off <= lim) {
- /* Windowed flash access */
- size = find_nvram_size(iobase + off);
- if (size) {
- header = (struct nvram_header *)(iobase + off - size);
- goto found;
+
+ found = false;
+
+ /* Try every possible flash size and check for NVRAM at its end */
+ for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
+ for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
+ offset = flash_size - nvram_sizes[i];
+ if (bcm47xx_nvram_is_valid(flash_start + offset)) {
+ found = true;
+ break;
+ }
}
- off <<= 1;
+
+ if (found)
+ break;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
- header = (struct nvram_header *)(iobase + 4096);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
- }
- header = (struct nvram_header *)(iobase + 1024);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
+ if (!found) {
+ offset = 4096;
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
+ found = true;
}
- pr_err("no nvram found\n");
- return -ENXIO;
-
-found:
- __ioread32_copy(nvram_buf, header, sizeof(*head
Re: [PATCH stblinux.git 2/2] firmware: bcm47xx_nvram: support platform device "brcm,nvram"
On 02.03.2021 17:59, Florian Fainelli wrote: On 3/1/21 11:44 PM, Rafał Miłecki wrote: From: Rafał Miłecki Add support for platform device providing mapping resource. This allows reading NVRAM based on DT mapping binding. It's required for devices that boot depending on NVRAM stored setup and provides early access to NVRAM data. Signed-off-by: Rafał Miłecki --- bcm47xx_nvram driver was originally added through MIPS tree, but this change doesn't affect BCM47XX (MIPS) as it doesn't use DT. It targets ARCH_BCM_5301X so I suggest this goes through the stblinux.git tree. Can you see if this change can be replaced by the nvmem-rmem work that Nicolas recently did to support something similar for the Raspberry Pi 4: https://lkml.org/lkml/2021/1/29/235 I don't think it fits my case. It's a reserved memory binding/driver which refers to the system memory. In NVRAM case we need to do a mapping. I think it's different? nvmem-rmem registers NVMEM device without providing any cells. It also doesn't understand NVRAM data structure. I guess nvmem-rmem only exposes NVMEM for user-space access. I need to access NVRAM to e.g. detect boot parameters in kernel code. I was thinking for a moment about treating NVRAM like a NVMEM but NVRAM doesn't seem to fit current design and kernel API. NVMEM assumes that every cell has a specific offset and size. Reading NVRAM should be based on string keys (nof offsets). See nvmem_reg_read_t for details. This won't make a huge difference I think, but for a slightly cleaner design I could probably have NVRAM devices without cells and make it setup NVRAM. Let me see if I can code that.
Re: [PATCH v2 3/3] dt-bindings: mtd: Document use of nvmem-partitions compatible
[Rob: please advise]
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
Until now we were using "compatible" string in partition node only for
parsers (looking for subpartitions). We need to think if this change can
break anything from DT / Linux perspective.
Compatible strings should be unique, so there is no risk of conflict
between NVMEM and parsers.
Now: can we ever need mtd partition to:
1. Contain subpartitions
2. Provide NVMEM
at the same time?
Let's say:
partition@0 {
compatible = "vendor,dynamic-firmware-partitions", "nvmem-partitions";
label = "firmware";
reg = <0x0 0x10>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x10>;
firmware-version@10 {
reg = <0x10 0x4>;
};
firmware-date@10 {
reg = <0x20 0x4>;
};
};
Is that allowed to respect both "compatible" strings and have:
1. Linux parser parse "firmware" for subpartitions
2. Linux MTD register "firmware" as NVMEM device
?
If not, what other options do we have? Is that allowed to have a
dangling MTD NVMEM node with phandle to MTD partition?
firmware: partition@0 {
compatible = "vendor,dynamic-firmware-partitions";
label = "firmware";
reg = <0x0 0x10>;
};
(...)
firmware-version@10 {
compatible = "mtd-nvmem";
reg = <0x10 0x4>;
mtd = <>;
};
firmware-date@10 {
compatible = "mtd-nvmem";
reg = <0x20 0x4>;
mtd = <>;
};
Rob: I'd really appreciate your input & help here.
Re: [PATCH v2 2/3] mtd: core: add nvmem-partitions compatible to parse mtd as nvmem cells
On 16.02.2021 22:26, Ansuel Smith wrote:
Partitions that contains the nvmem-partitions compatible will register
their direct subonodes as nvmem cells and the node will be treated as a
nvmem provider.
Signed-off-by: Ansuel Smith
Tested-by: Rafał Miłecki
I applied this patch on top of the:
[PATCH] mtd: parsers: ofpart: limit parsing of deprecated DT syntax
I succesfully used NVMEM cell defined in bootloader mtd partition for
reading device MAC address.
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
compatible = "nvmem-partitions";
label = "bootloader";
reg = <0x0 0x10>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x10>;
base_mac_addr: mac@106a0 {
reg = <0x106a0 0x6>;
};
};
}
Re: [PATCH v2 1/3] mtd: partitions: ofpart: skip subnodes parse with compatible
On 16.02.2021 22:26, Ansuel Smith wrote:
If a partitions structure is not used, parse direct subnodes as
fixed-partitions only if a compatible is not found or is of type
fixed-partition. A parser can be used directly on the subnode and
subnodes should not be parsed as fixed-partitions by default.
Signed-off-by: Ansuel Smith
---
drivers/mtd/parsers/ofpart.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..4b363dd0311c 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -50,6 +50,11 @@ static int parse_fixed_partitions(struct mtd_info *master,
master->name, mtd_node);
ofpart_node = mtd_node;
dedicated = false;
+
+ /* Skip parsing direct subnodes if a compatible is found and is
not fixed-partitions */
+ if (node_has_compatible(ofpart_node) &&
+ !of_device_is_compatible(ofpart_node, "fixed-partitions"))
+ return 0;
} else if (!of_device_is_compatible(ofpart_node, "fixed-partitions")) {
/* The 'partitions' subnode might be used by another parser */
return 0;
I admit I'm not familiar with the old binding, so let me know if my
understanding is incorrect.
It seems to me however that your change will break parsing in cases
like:
spi-flash@0 {
compatible = "jedec,spi-nor";
reg = <0x0>;
partition@0 {
label = "bootloader";
reg = <0x0 0x10>;
};
};
nandcs@0 {
compatible = "brcm,nandcs";
reg = <0>;
partition@0 {
label = "bootloader";
reg = <0x000 0x1>;
};
};
Did we ever use "fixed-partitions" without partitions { } subnode?
[PATCH stblinux.git 1/2] dt-bindings: firmware: add Broadcom's NVRAM memory mapping
From: Rafał Miłecki
NVRAM structure contains device data and can be accessed using MMIO.
Signed-off-by: Rafał Miłecki
---
.../bindings/firmware/brcm,nvram.yaml | 41 +++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/brcm,nvram.yaml
diff --git a/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml
b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml
new file mode 100644
index ..12af8e2e7c9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/brcm,nvram.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/firmware/brcm,nvram.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Broadcom's NVRAM
+
+maintainers:
+ - Rafał Miłecki
+
+description: |
+ NVRAM is a structure containing device specific environment variables.
+ It is used for storing device configuration, booting parameters and
+ calibration data.
+
+ It's required very early in booting process and so is made available
+ using memory mapping.
+
+ NVRAM can be found on Broadcom BCM47xx MIPS, Northstar ARM Cortex-A9
+ and some more devices.
+
+properties:
+ compatible:
+const: brcm,nvram
+
+ reg:
+description: memory region with NVRAM data
+maxItems: 1
+
+required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+nvram@1e00 {
+ compatible = "brcm,nvram";
+ reg = <0x1e00 0x1>;
+};
--
2.26.2
[PATCH stblinux.git 2/2] firmware: bcm47xx_nvram: support platform device "brcm,nvram"
From: Rafał Miłecki
Add support for platform device providing mapping resource. This allows
reading NVRAM based on DT mapping binding. It's required for devices
that boot depending on NVRAM stored setup and provides early access to
NVRAM data.
Signed-off-by: Rafał Miłecki
---
bcm47xx_nvram driver was originally added through MIPS tree, but this
change doesn't affect BCM47XX (MIPS) as it doesn't use DT. It targets
ARCH_BCM_5301X so I suggest this goes through the stblinux.git tree.
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..d5d19dd1b9e1 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#define NVRAM_MAGIC0x48534C46 /* 'FLSH' */
@@ -162,6 +163,60 @@ static int nvram_init(void)
return -ENXIO;
}
+static int brcm_nvram_probe(struct platform_device *pdev)
+{
+ struct nvram_header __iomem *header;
+ struct device *dev = >dev;
+ struct resource *res;
+ void __iomem *mmio;
+ size_t copy_len;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Failed to get resource\n");
+ return -ENODEV;
+ }
+
+ mmio = ioremap(res->start, resource_size(res));
+ if (!mmio)
+ return -ENOMEM;
+
+ header = (struct nvram_header *)mmio;
+ copy_len = DIV_ROUND_UP(sizeof(*header) + header->len, 4);
+ if (header->magic != NVRAM_MAGIC) {
+ dev_err(dev, "No NVRAM found at %pR\n", res);
+ return -EPROTO;
+ } else if (copy_len > resource_size(res)) {
+ dev_err(dev, "NVRAM size exceeds %pR\n", res);
+ return -ERANGE;
+ } else if (copy_len >= NVRAM_SPACE) {
+ dev_err(dev, "NVRAM size exceeds buffer size %d\n",
NVRAM_SPACE);
+ return -ENOMEM;
+ }
+
+ __ioread32_copy(nvram_buf, mmio, copy_len);
+ nvram_buf[NVRAM_SPACE - 1] = '\0';
+
+ iounmap(mmio);
+
+ return 0;
+}
+
+static const struct of_device_id brcm_nvram_of_match[] = {
+ { .compatible = "brcm,nvram "},
+ {},
+};
+
+static struct platform_driver brcm_nvram_driver = {
+ .driver = {
+ .name = "brcm_nvram",
+ .of_match_table = brcm_nvram_of_match,
+ },
+ .probe = brcm_nvram_probe,
+};
+
+module_platform_driver(brcm_nvram_driver);
+
int bcm47xx_nvram_getenv(const char *name, char *val, size_t val_len)
{
char *var, *value, *end, *eq;
--
2.26.2
[PATCH 2/3] dt-bindings: phy: brcm,ns-usb2-phy: bind single CRU reg
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU register that controls
USB 2.0 PHY. It's still required to reference CRU generic clkset
register so add a syscon for that.
For a full DMU & CRU description see arch/arm/boot/dts/bcm5301x.dtsi .
The old binding is deprecated now.
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
I'd really like to get Rob's ack to make sure I don't do anything stupid
It's a reworked version of my abonded 2019 patch:
[PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20190108123907.19816-1-zaj...@gmail.com/
---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 46 +++
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
index b8b683ce8fa9..8e056d4d205a 100644
--- a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -16,11 +16,20 @@ properties:
const: brcm,ns-usb2-phy
reg:
-maxItems: 1
-description: DMU (Device Management Unit) address range
+anyOf:
+ - maxItems: 1
+description: PHY control register
+ - maxItems: 1
+description: DMU (Device Management Unit) address range
+deprecated: true
reg-names:
const: dmu
+deprecated: true
+
+ brcm,syscon-clkset:
+description: phandle to syscon for clkset register
+$ref: /schemas/types.yaml#/definitions/phandle
clocks:
maxItems: 1
@@ -34,22 +43,39 @@ properties:
required:
- reg
- - reg-names
- clocks
- clock-names
- "#phy-cells"
+oneOf:
+ - required:
+ - brcm,syscon-clkset
+ - required:
+ - reg-names
+
additionalProperties: false
examples:
- |
#include
-usb2-phy@1800c000 {
-compatible = "brcm,ns-usb2-phy";
-reg = <0x1800c000 0x1000>;
-reg-names = "dmu";
-clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
-clock-names = "phy-ref-clk";
-#phy-cells = <0>;
+cru-bus@1800c100 {
+compatible = "simple-bus";
+ranges = <0 0x1800c100 0x1a4>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+usb2-phy@64 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x64 0x4>;
+brcm,syscon-clkset = <>;
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
+
+clkset: syscon@80 {
+compatible = "brcm,cru-clkset", "syscon";
+reg = <0x80 0x4>;
+};
};
--
2.26.2
[PATCH 3/3] phy: bcm-ns-usb2: support updated single CRU reg DT binding
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has been deprecated and stays as a fallback method.
Signed-off-by: Rafał Miłecki
---
It's a reworked version of my abonded 2019 patch:
[PATCH V2 2/2] phy: bcm-ns-usb2: support updated DT binding with the CRU syscon
https://lore.kernel.org/patchwork/patch/1029863/
---
drivers/phy/broadcom/phy-bcm-ns-usb2.c | 52 +-
1 file changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
index 4b015b8a71c3..98d32729a45d 100644
--- a/drivers/phy/broadcom/phy-bcm-ns-usb2.c
+++ b/drivers/phy/broadcom/phy-bcm-ns-usb2.c
@@ -9,17 +9,23 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
struct bcm_ns_usb2 {
struct device *dev;
struct clk *ref_clk;
struct phy *phy;
+ struct regmap *clkset;
+ void __iomem *base;
+
+ /* Deprecated binding */
void __iomem *dmu;
};
@@ -27,7 +33,6 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
{
struct bcm_ns_usb2 *usb2 = phy_get_drvdata(phy);
struct device *dev = usb2->dev;
- void __iomem *dmu = usb2->dmu;
u32 ref_clk_rate, usb2ctl, usb_pll_ndiv, usb_pll_pdiv;
int err = 0;
@@ -44,7 +49,10 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
goto err_clk_off;
}
- usb2ctl = readl(dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ usb2ctl = readl(usb2->base);
+ else
+ usb2ctl = readl(usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
if (usb2ctl & BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_PDIV_MASK) {
usb_pll_pdiv = usb2ctl;
@@ -58,15 +66,24 @@ static int bcm_ns_usb2_phy_init(struct phy *phy)
usb_pll_ndiv = (192000 * usb_pll_pdiv) / ref_clk_rate;
/* Unlock DMU PLL settings with some magic value */
- writel(0xea68, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0xea68);
+ else
+ writel(0xea68, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
/* Write USB 2.0 PLL control setting */
usb2ctl &= ~BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_MASK;
usb2ctl |= usb_pll_ndiv << BCMA_DMU_CRU_USB2_CONTROL_USB_PLL_NDIV_SHIFT;
- writel(usb2ctl, dmu + BCMA_DMU_CRU_USB2_CONTROL);
+ if (usb2->base)
+ writel(usb2ctl, usb2->base);
+ else
+ writel(usb2ctl, usb2->dmu + BCMA_DMU_CRU_USB2_CONTROL);
/* Lock DMU PLL settings */
- writel(0x, dmu + BCMA_DMU_CRU_CLKSET_KEY);
+ if (usb2->clkset)
+ regmap_write(usb2->clkset, 0, 0x);
+ else
+ writel(0x, usb2->dmu + BCMA_DMU_CRU_CLKSET_KEY);
err_clk_off:
clk_disable_unprepare(usb2->ref_clk);
@@ -90,10 +107,27 @@ static int bcm_ns_usb2_probe(struct platform_device *pdev)
return -ENOMEM;
usb2->dev = dev;
- usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
- if (IS_ERR(usb2->dmu)) {
- dev_err(dev, "Failed to map DMU regs\n");
- return PTR_ERR(usb2->dmu);
+ if (of_find_property(dev->of_node, "brcm,syscon-clkset", NULL)) {
+ usb2->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(usb2->base)) {
+ dev_err(dev, "Failed to map control reg\n");
+ return PTR_ERR(usb2->base);
+ }
+
+ usb2->clkset = syscon_regmap_lookup_by_phandle(dev->of_node,
+
"brcm,syscon-clkset");
+ if (IS_ERR(usb2->clkset)) {
+ dev_err(dev, "Failed to lookup clkset regmap\n");
+ return PTR_ERR(usb2->clkset);
+ }
+ } else {
+ usb2->dmu = devm_platform_ioremap_resource_byname(pdev, "dmu");
+ if (IS_ERR(usb2->dmu)) {
+ dev_err(dev, "Failed to map DMU regs\n");
+ return PTR_ERR(usb2->dmu);
+ }
+
+ dev_warn(dev, "using deprecated DT binding\n");
}
usb2->ref_clk = devm_clk_get(dev, "phy-ref-clk");
--
2.26.2
[PATCH 1/3] dt-bindings: phy: convert Broadcom NS USB 2.0 to the json-schema
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 55 +++
2 files changed, 55 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
deleted file mode 100644
index a7aee9ea8926..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Driver for Broadcom Northstar USB 2.0 PHY
-
-Required properties:
-- compatible: brcm,ns-usb2-phy
-- reg: iomem address range of DMU (Device Management Unit)
-- reg-names: "dmu", the only needed & supported reg right now
-- clocks: USB PHY reference clock
-- clock-names: "phy-ref-clk", the only needed & supported clock right now
-
-To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
-requires passing phandle to the USB PHY reference clock.
-
-Example:
- usb2-phy {
- compatible = "brcm,ns-usb2-phy";
- reg = <0x1800c000 0x1000>;
- reg-names = "dmu";
- #phy-cells = <0>;
- clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
- clock-names = "phy-ref-clk";
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
new file mode 100644
index ..b8b683ce8fa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,ns-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 2.0 PHY
+
+description: Broadcom's USB 2.0 PHY integrated into Northstar family SoCs
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,ns-usb2-phy
+
+ reg:
+maxItems: 1
+description: DMU (Device Management Unit) address range
+
+ reg-names:
+const: dmu
+
+ clocks:
+maxItems: 1
+description: USB PHY reference clock
+
+ clock-names:
+const: phy-ref-clk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+usb2-phy@1800c000 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x1800c000 0x1000>;
+reg-names = "dmu";
+clocks = < BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
--
2.26.2
Re: [PATCH] mtd: parsers: add MTD_OF_PARTS_BCM4908 config option
On Mon, 15 Feb 2021 at 10:37, Rafał Miłecki wrote: > From: Rafał Miłecki > > Right now ofpart parser gets always compiled with the BCM4908 support. > It's not a big issue at this point as BCM4908 partitioning support comes > at close-to-zero cost. It may differ for possible further ofpart quirks > though. > > Make BCM4908 support selectable to set a clean pattern for adding further > quirks. Patch to be dropped. I'll rework original patch, hopefully without breaking anything this time.
Re: linux-next: build failure after merge of the mtd tree
Hi Stephen!
On 15.02.2021 02:28, Stephen Rothwell wrote:
After merging the mtd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse" [drivers/mtd/parsers/ofpart.ko]
undefined!
Caused by commit
09cf6ee6d21c ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
I have used the mtd tree from next-20210212 for today.
Thank you for the report!
It has been fixed by the
[PATCH] mtd: parsers: ofpart: fix building as module
https://patchwork.ozlabs.org/project/linux-mtd/patch/20210215072844.16136-1-zaj...@gmail.com/
https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/commit/?h=mtd/next=bc6dcf44da2bea215ae3edbdac5d350e96de3996
[PATCH] mtd: parsers: add MTD_OF_PARTS_BCM4908 config option
From: Rafał Miłecki
Right now ofpart parser gets always compiled with the BCM4908 support.
It's not a big issue at this point as BCM4908 partitioning support comes
at close-to-zero cost. It may differ for possible further ofpart quirks
though.
Make BCM4908 support selectable to set a clean pattern for adding further
quirks.
Signed-off-by: Rafał Miłecki
---
This is NOT urgent and is NOT intended for the 5.12. Please review this
change in a free moment, probably after merge window closes.
---
drivers/mtd/parsers/Kconfig | 9 +
drivers/mtd/parsers/Makefile | 3 ++-
.../parsers/{bcm4908-partitions.c => ofpart_bcm4908.c} | 2 +-
.../parsers/{bcm4908-partitions.h => ofpart_bcm4908.h} | 8
drivers/mtd/parsers/{ofpart.c => ofpart_core.c} | 2 +-
5 files changed, 21 insertions(+), 3 deletions(-)
rename drivers/mtd/parsers/{bcm4908-partitions.c => ofpart_bcm4908.c} (97%)
rename drivers/mtd/parsers/{bcm4908-partitions.h => ofpart_bcm4908.h} (52%)
rename drivers/mtd/parsers/{ofpart.c => ofpart_core.c} (99%)
diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
index d90c30229052..05b6a24cedd8 100644
--- a/drivers/mtd/parsers/Kconfig
+++ b/drivers/mtd/parsers/Kconfig
@@ -67,6 +67,15 @@ config MTD_OF_PARTS
flash memory node, as described in
Documentation/devicetree/bindings/mtd/partition.txt.
+config MTD_OF_PARTS_BCM4908
+ bool "BCM4908 partitioning support"
+ depends on MTD_OF_PARTS && (ARCH_BCM4908 || COMPILE_TEST)
+ default ARCH_BCM4908
+ help
+ This provides partitions parser for BCM4908 family devices
+ that can have multiple "firmware" partitions. It takes care of
+ finding currently used one and backup ones.
+
config MTD_PARSER_IMAGETAG
tristate "Parser for BCM963XX Image Tag format partitions"
depends on BCM63XX || BMIPS_GENERIC || COMPILE_TEST
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index bf58a5221730..2dfe9fb602de 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,7 +4,8 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
-ofpart-objs:= bcm4908-partitions.o
+ofpart-y += ofpart_core.o
+ofpart-$(CONFIG_MTD_OF_PARTS_BCM4908) += ofpart_bcm4908.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/ofpart_bcm4908.c
similarity index 97%
rename from drivers/mtd/parsers/bcm4908-partitions.c
rename to drivers/mtd/parsers/ofpart_bcm4908.c
index ac69a2169763..3cfa4f4ec562 100644
--- a/drivers/mtd/parsers/bcm4908-partitions.c
+++ b/drivers/mtd/parsers/ofpart_bcm4908.c
@@ -10,7 +10,7 @@
#include
#include
-#include "bcm4908-partitions.h"
+#include "ofpart_bcm4908.h"
#define BLPARAMS_FW_OFFSET "NAND_RFS_OFS"
diff --git a/drivers/mtd/parsers/bcm4908-partitions.h
b/drivers/mtd/parsers/ofpart_bcm4908.h
similarity index 52%
rename from drivers/mtd/parsers/bcm4908-partitions.h
rename to drivers/mtd/parsers/ofpart_bcm4908.h
index df25f0487d0a..80f8c086641f 100644
--- a/drivers/mtd/parsers/bcm4908-partitions.h
+++ b/drivers/mtd/parsers/ofpart_bcm4908.h
@@ -2,6 +2,14 @@
#ifndef __BCM4908_PARTITIONS_H
#define __BCM4908_PARTITIONS_H
+#ifdef CONFIG_MTD_OF_PARTS_BCM4908
int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts);
+#else
+static inline int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct
mtd_partition *parts,
+ int nr_parts)
+{
+ return -EOPNOTSUPP;
+}
+#endif
#endif
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart_core.c
similarity index 99%
rename from drivers/mtd/parsers/ofpart.c
rename to drivers/mtd/parsers/ofpart_core.c
index 6b221df8401c..258c06a42283 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart_core.c
@@ -16,7 +16,7 @@
#include
#include
-#include "bcm4908-partitions.h"
+#include "ofpart_bcm4908.h"
struct fixed_partitions_quirks {
int (*post_parse)(struct mtd_info *mtd, struct mtd_partition *parts,
int nr_parts);
--
2.26.2
[PATCH] mtd: parsers: ofpart: fix building as module
From: Rafał Miłecki
This fixes:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse" [drivers/mtd/parsers/ofpart.ko]
undefined!
Reported-by: Stephen Rothwell
Fixes: 09cf6ee6d21c ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Makefile | 2 +-
drivers/mtd/parsers/bcm4908-partitions.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 01972a5edc5c..bf58a5221730 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
-obj-$(CONFIG_MTD_OF_PARTS) += bcm4908-partitions.o
+ofpart-objs:= bcm4908-partitions.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/bcm4908-partitions.c
index 40eb3b3801c3..ac69a2169763 100644
--- a/drivers/mtd/parsers/bcm4908-partitions.c
+++ b/drivers/mtd/parsers/bcm4908-partitions.c
@@ -62,3 +62,5 @@ int bcm4908_partitions_post_parse(struct mtd_info *mtd,
struct mtd_partition *pa
return 0;
}
+
+MODULE_LICENSE("GPL");
--
2.26.2
[PATCH V3 mtd/next 2/3] dt-bindings: mtd: add binding for BCM4908 partitions
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those partitions
should be marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
V2: Use enum: [ 1, 2 ] for address & size
Use ^partition@[0-9a-f]+$ pattern ("partition" was added)
Drop unneeded allOf
Add unevaluatedProperties
---
.../partitions/brcm,bcm4908-partitions.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
diff --git
a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
new file mode 100644
index ..7b113e5e3421
--- /dev/null
+++
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/brcm,bcm4908-partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 partitioning
+
+description: |
+ Broadcom BCM4908 CFE bootloader supports two firmware partitions. One is used
+ for regular booting, the other is treated as fallback.
+
+ This binding allows defining all fixed partitions and marking those
containing
+ firmware. System can use that information e.g. for booting or flashing
+ purposes.
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,bcm4908-partitions
+
+ "#address-cells":
+enum: [ 1, 2 ]
+
+ "#size-cells":
+enum: [ 1, 2 ]
+
+patternProperties:
+ "^partition@[0-9a-f]+$":
+$ref: "partition.yaml#"
+properties:
+ compatible:
+const: brcm,bcm4908-firmware
+unevaluatedProperties: false
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+partitions {
+compatible = "brcm,bcm4908-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+label = "cferom";
+reg = <0x0 0x10>;
+};
+
+partition@10 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x10 0xf0>;
+};
+
+partition@100 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x100 0xf0>;
+};
+
+partition@1f0 {
+label = "calibration";
+reg = <0x1f0 0x10>;
+};
+};
--
2.26.2
[PATCH V3 mtd/next 3/3] mtd: parsers: ofpart: support BCM4908 fixed partitions
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c code) support for post-parsing callback was added.
BCM4908 callback simply reads offset of currently used firmware
partition from the DT. Bootloader specifies it using the "brcm_blparms"
property.
Signed-off-by: Rafał Miłecki
---
V3: Add #include "bcm4908-partitions.h" to fix:
drivers/mtd/parsers/bcm4908-partitions.c:45:5: warning: no previous prototype
for function 'bcm4908_partitions_post_parse' [-Wmissing-prototypes]
Reported-by: kernel test robot
---
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/bcm4908-partitions.c | 64
drivers/mtd/parsers/bcm4908-partitions.h | 7 +++
drivers/mtd/parsers/ofpart.c | 28 ++-
4 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.c
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.h
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 50eb0b0a2210..01972a5edc5c 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
+obj-$(CONFIG_MTD_OF_PARTS) += bcm4908-partitions.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/bcm4908-partitions.c
new file mode 100644
index ..40eb3b3801c3
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bcm4908-partitions.h"
+
+#define BLPARAMS_FW_OFFSET "NAND_RFS_OFS"
+
+static long long bcm4908_partitions_fw_offset(void)
+{
+ struct device_node *root;
+ struct property *prop;
+ const char *s;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -ENOENT;
+
+ of_property_for_each_string(root, "brcm_blparms", prop, s) {
+ size_t len = strlen(BLPARAMS_FW_OFFSET);
+ unsigned long offset;
+ int err;
+
+ if (strncmp(s, BLPARAMS_FW_OFFSET, len) || s[len] != '=')
+ continue;
+
+ err = kstrtoul(s + len + 1, 0, );
+ if (err) {
+ pr_err("failed to parse %s\n", s + len + 1);
+ return err;
+ }
+
+ return offset << 10;
+ }
+
+ return -ENOENT;
+}
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts)
+{
+ long long fw_offset;
+ int i;
+
+ fw_offset = bcm4908_partitions_fw_offset();
+
+ for (i = 0; i < nr_parts; i++) {
+ if (of_device_is_compatible(parts[i].of_node,
"brcm,bcm4908-firmware")) {
+ if (fw_offset < 0 || parts[i].offset == fw_offset)
+ parts[i].name = "firmware";
+ else
+ parts[i].name = "backup";
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/mtd/parsers/bcm4908-partitions.h
b/drivers/mtd/parsers/bcm4908-partitions.h
new file mode 100644
index ..df25f0487d0a
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __BCM4908_PARTITIONS_H
+#define __BCM4908_PARTITIONS_H
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts);
+
+#endif
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..6b221df8401c 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -16,6 +16,18 @@
#include
#include
+#include "bcm4908-partitions.h"
+
+struct fixed_partitions_quirks {
+ int (*post_parse)(struct mtd_info *mtd, struct mtd_partition *parts,
int nr_parts);
+};
+
+struct fixed_partitions_quirks bcm4908_partitions_quirks = {
+ .post_parse = bcm4908_partitions_post_parse,
+};
+
+static const struct of_device_id parse_ofpart_match_table[];
+
static bool node_has_compatible(struct device_node *pp)
{
r
[PATCH V3 mtd/next 1/3] dt-bindings: mtd: move partition binding to its own file
From: Rafał Miłecki Single partition binding is quite common and may be: 1. Used by multiple parsers 2. Extended for more specific cases Move it to separated file to avoid code duplication. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring --- .../mtd/partitions/fixed-partitions.yaml | 33 + .../bindings/mtd/partitions/partition.yaml| 47 +++ 2 files changed, 48 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml index 6d4a3450e064..ea4cace6a955 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml @@ -27,38 +27,7 @@ properties: patternProperties: "@[0-9a-f]+$": -description: node describing a single flash partition -type: object - -properties: - reg: -description: partition's offset and size within the flash -maxItems: 1 - - label: -description: The label / name for this partition. If omitted, the label - is taken from the node name (excluding the unit address). - - read-only: -description: This parameter, if present, is a hint that this partition - should only be mounted read-only. This is usually used for flash - partitions containing early-boot firmware images or data which should - not be clobbered. -type: boolean - - lock: -description: Do not unlock the partition at initialization time (not - supported on all devices) -type: boolean - - slc-mode: -description: This parameter, if present, allows one to emulate SLC mode - on a partition attached to an MLC NAND thus making this partition - immune to paired-pages corruptions -type: boolean - -required: - - reg +$ref: "partition.yaml#" required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml new file mode 100644 index ..e1ac08064425 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/partition.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Partition + +description: | + This binding describes a single flash partition. Each partition must have its + relative offset and size specified. Depending on partition function extra + properties can be used. + +maintainers: + - Rafał Miłecki + +properties: + reg: +description: partition's offset and size within the flash +maxItems: 1 + + label: +description: The label / name for this partition. If omitted, the label + is taken from the node name (excluding the unit address). + + read-only: +description: This parameter, if present, is a hint that this partition + should only be mounted read-only. This is usually used for flash + partitions containing early-boot firmware images or data which should + not be clobbered. +type: boolean + + lock: +description: Do not unlock the partition at initialization time (not + supported on all devices) +type: boolean + + slc-mode: +description: This parameter, if present, allows one to emulate SLC mode + on a partition attached to an MLC NAND thus making this partition + immune to paired-pages corruptions +type: boolean + +required: + - reg + +additionalProperties: true -- 2.26.2
[PATCH V2 mtd/next 3/3] mtd: parsers: ofpart: support BCM4908 fixed partitions
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c code) support for post-parsing callback was added.
BCM4908 callback simply reads offset of currently used firmware
partition from the DT. Bootloader specifies it using the "brcm_blparms"
property.
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/bcm4908-partitions.c | 62
drivers/mtd/parsers/bcm4908-partitions.h | 7 +++
drivers/mtd/parsers/ofpart.c | 28 ++-
4 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.c
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.h
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 50eb0b0a2210..01972a5edc5c 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
+obj-$(CONFIG_MTD_OF_PARTS) += bcm4908-partitions.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/bcm4908-partitions.c
new file mode 100644
index ..032a4b1b8a5f
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BLPARAMS_FW_OFFSET "NAND_RFS_OFS"
+
+static long long bcm4908_partitions_fw_offset(void)
+{
+ struct device_node *root;
+ struct property *prop;
+ const char *s;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -ENOENT;
+
+ of_property_for_each_string(root, "brcm_blparms", prop, s) {
+ size_t len = strlen(BLPARAMS_FW_OFFSET);
+ unsigned long offset;
+ int err;
+
+ if (strncmp(s, BLPARAMS_FW_OFFSET, len) || s[len] != '=')
+ continue;
+
+ err = kstrtoul(s + len + 1, 0, );
+ if (err) {
+ pr_err("failed to parse %s\n", s + len + 1);
+ return err;
+ }
+
+ return offset << 10;
+ }
+
+ return -ENOENT;
+}
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts)
+{
+ long long fw_offset;
+ int i;
+
+ fw_offset = bcm4908_partitions_fw_offset();
+
+ for (i = 0; i < nr_parts; i++) {
+ if (of_device_is_compatible(parts[i].of_node,
"brcm,bcm4908-firmware")) {
+ if (fw_offset < 0 || parts[i].offset == fw_offset)
+ parts[i].name = "firmware";
+ else
+ parts[i].name = "backup";
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/mtd/parsers/bcm4908-partitions.h
b/drivers/mtd/parsers/bcm4908-partitions.h
new file mode 100644
index ..df25f0487d0a
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __BCM4908_PARTITIONS_H
+#define __BCM4908_PARTITIONS_H
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts);
+
+#endif
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..6b221df8401c 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -16,6 +16,18 @@
#include
#include
+#include "bcm4908-partitions.h"
+
+struct fixed_partitions_quirks {
+ int (*post_parse)(struct mtd_info *mtd, struct mtd_partition *parts,
int nr_parts);
+};
+
+struct fixed_partitions_quirks bcm4908_partitions_quirks = {
+ .post_parse = bcm4908_partitions_post_parse,
+};
+
+static const struct of_device_id parse_ofpart_match_table[];
+
static bool node_has_compatible(struct device_node *pp)
{
return of_get_property(pp, "compatible", NULL);
@@ -25,6 +37,8 @@ static int parse_fixed_partitions(struct mtd_info *master,
const struct mtd_partition **pparts,
struct mtd_part_parser_data *data)
{
+ const struct fixed_partitions_quirks *q
[PATCH V2 mtd/next 2/3] dt-bindings: mtd: add binding for BCM4908 partitions
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those partitions
should be marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
V2: Use enum: [ 1, 2 ] for address & size
Use ^partition@[0-9a-f]+$ pattern ("partition" was added)
Drop unneeded allOf
Add unevaluatedProperties
---
.../partitions/brcm,bcm4908-partitions.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
diff --git
a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
new file mode 100644
index ..7b113e5e3421
--- /dev/null
+++
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/brcm,bcm4908-partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 partitioning
+
+description: |
+ Broadcom BCM4908 CFE bootloader supports two firmware partitions. One is used
+ for regular booting, the other is treated as fallback.
+
+ This binding allows defining all fixed partitions and marking those
containing
+ firmware. System can use that information e.g. for booting or flashing
+ purposes.
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,bcm4908-partitions
+
+ "#address-cells":
+enum: [ 1, 2 ]
+
+ "#size-cells":
+enum: [ 1, 2 ]
+
+patternProperties:
+ "^partition@[0-9a-f]+$":
+$ref: "partition.yaml#"
+properties:
+ compatible:
+const: brcm,bcm4908-firmware
+unevaluatedProperties: false
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+partitions {
+compatible = "brcm,bcm4908-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+label = "cferom";
+reg = <0x0 0x10>;
+};
+
+partition@10 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x10 0xf0>;
+};
+
+partition@100 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x100 0xf0>;
+};
+
+partition@1f0 {
+label = "calibration";
+reg = <0x1f0 0x10>;
+};
+};
--
2.26.2
[PATCH V2 mtd/next 1/3] dt-bindings: mtd: move partition binding to its own file
From: Rafał Miłecki Single partition binding is quite common and may be: 1. Used by multiple parsers 2. Extended for more specific cases Move it to separated file to avoid code duplication. Signed-off-by: Rafał Miłecki Reviewed-by: Rob Herring --- .../mtd/partitions/fixed-partitions.yaml | 33 + .../bindings/mtd/partitions/partition.yaml| 47 +++ 2 files changed, 48 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml index 6d4a3450e064..ea4cace6a955 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml @@ -27,38 +27,7 @@ properties: patternProperties: "@[0-9a-f]+$": -description: node describing a single flash partition -type: object - -properties: - reg: -description: partition's offset and size within the flash -maxItems: 1 - - label: -description: The label / name for this partition. If omitted, the label - is taken from the node name (excluding the unit address). - - read-only: -description: This parameter, if present, is a hint that this partition - should only be mounted read-only. This is usually used for flash - partitions containing early-boot firmware images or data which should - not be clobbered. -type: boolean - - lock: -description: Do not unlock the partition at initialization time (not - supported on all devices) -type: boolean - - slc-mode: -description: This parameter, if present, allows one to emulate SLC mode - on a partition attached to an MLC NAND thus making this partition - immune to paired-pages corruptions -type: boolean - -required: - - reg +$ref: "partition.yaml#" required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml new file mode 100644 index ..e1ac08064425 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/partition.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Partition + +description: | + This binding describes a single flash partition. Each partition must have its + relative offset and size specified. Depending on partition function extra + properties can be used. + +maintainers: + - Rafał Miłecki + +properties: + reg: +description: partition's offset and size within the flash +maxItems: 1 + + label: +description: The label / name for this partition. If omitted, the label + is taken from the node name (excluding the unit address). + + read-only: +description: This parameter, if present, is a hint that this partition + should only be mounted read-only. This is usually used for flash + partitions containing early-boot firmware images or data which should + not be clobbered. +type: boolean + + lock: +description: Do not unlock the partition at initialization time (not + supported on all devices) +type: boolean + + slc-mode: +description: This parameter, if present, allows one to emulate SLC mode + on a partition attached to an MLC NAND thus making this partition + immune to paired-pages corruptions +type: boolean + +required: + - reg + +additionalProperties: true -- 2.26.2
Re: [PATCH] MAINTAINERS: rectify BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER
On 2021-02-08 08:16, Lukas Bulwahn wrote:
Commit 8bcac4011ebe ("soc: bcm: add PM driver for Broadcom's PMB")
includes
a new MAINTAINERS section BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER
with
'drivers/soc/bcm/bcm-pmb.c', but the file was actually added at
'drivers/soc/bcm/bcm63xx/bcm-pmb.c'.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F:drivers/soc/bcm/bcm-pmb.c
Point the file entry to the right location.
Signed-off-by: Lukas Bulwahn
Thanks!
Acked-by: Rafał Miłecki
Re: [PATCH Broadcom/stblinux] soc: brcmstb: add stubs for getting platform IDs
On 20.01.2021 20:58, Florian Fainelli wrote: On 1/20/2021 11:48 AM, Florian Fainelli wrote: On Thu, 14 Jan 2021 11:53:18 +0100, Rafał Miłecki wrote: From: Rafał Miłecki Some brcmstb drivers may be shared with other SoC families. E.g. the same USB PHY block is shared by brcmstb and BCM4908. To avoid building brcmstb common code on non-brcmstb platforms we need stubs for: 1. brcmstb_get_family_id() 2. brcmstb_get_product_id() (to avoid "undefined reference to" errors). With this change PHY_BRCM_USB will not have to unconditionally select SOC_BRCMSTB anymore. Signed-off-by: Rafał Miłecki --- Applied to drivers/next, thanks! Made some tweaks to the patch: - subject is prefixed with: soc: bcm: brcmstb to match previous patches - used IS_ENABLED() instead of #ifdef because this may have to be a loadable module in the future (because of GKI) Thanks! Thank you!
[PATCH 3/3] mtd: parsers: ofpart: support BCM4908 fixed partitions
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c code) support for post-parsing callback was added.
BCM4908 callback simply reads offset of currently used firmware
partition from the DT. Bootloader specifies it using the "brcm_blparms"
property.
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/bcm4908-partitions.c | 62
drivers/mtd/parsers/bcm4908-partitions.h | 7 +++
drivers/mtd/parsers/ofpart.c | 28 ++-
4 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.c
create mode 100644 drivers/mtd/parsers/bcm4908-partitions.h
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index b0c5f62f9e85..3e26001f743c 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
+obj-$(CONFIG_MTD_OF_PARTS) += bcm4908-partitions.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/bcm4908-partitions.c
new file mode 100644
index ..032a4b1b8a5f
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BLPARAMS_FW_OFFSET "NAND_RFS_OFS"
+
+static long long bcm4908_partitions_fw_offset(void)
+{
+ struct device_node *root;
+ struct property *prop;
+ const char *s;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -ENOENT;
+
+ of_property_for_each_string(root, "brcm_blparms", prop, s) {
+ size_t len = strlen(BLPARAMS_FW_OFFSET);
+ unsigned long offset;
+ int err;
+
+ if (strncmp(s, BLPARAMS_FW_OFFSET, len) || s[len] != '=')
+ continue;
+
+ err = kstrtoul(s + len + 1, 0, );
+ if (err) {
+ pr_err("failed to parse %s\n", s + len + 1);
+ return err;
+ }
+
+ return offset << 10;
+ }
+
+ return -ENOENT;
+}
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts)
+{
+ long long fw_offset;
+ int i;
+
+ fw_offset = bcm4908_partitions_fw_offset();
+
+ for (i = 0; i < nr_parts; i++) {
+ if (of_device_is_compatible(parts[i].of_node,
"brcm,bcm4908-firmware")) {
+ if (fw_offset < 0 || parts[i].offset == fw_offset)
+ parts[i].name = "firmware";
+ else
+ parts[i].name = "backup";
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/mtd/parsers/bcm4908-partitions.h
b/drivers/mtd/parsers/bcm4908-partitions.h
new file mode 100644
index ..df25f0487d0a
--- /dev/null
+++ b/drivers/mtd/parsers/bcm4908-partitions.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __BCM4908_PARTITIONS_H
+#define __BCM4908_PARTITIONS_H
+
+int bcm4908_partitions_post_parse(struct mtd_info *mtd, struct mtd_partition
*parts, int nr_parts);
+
+#endif
diff --git a/drivers/mtd/parsers/ofpart.c b/drivers/mtd/parsers/ofpart.c
index daf507c123e6..6b221df8401c 100644
--- a/drivers/mtd/parsers/ofpart.c
+++ b/drivers/mtd/parsers/ofpart.c
@@ -16,6 +16,18 @@
#include
#include
+#include "bcm4908-partitions.h"
+
+struct fixed_partitions_quirks {
+ int (*post_parse)(struct mtd_info *mtd, struct mtd_partition *parts,
int nr_parts);
+};
+
+struct fixed_partitions_quirks bcm4908_partitions_quirks = {
+ .post_parse = bcm4908_partitions_post_parse,
+};
+
+static const struct of_device_id parse_ofpart_match_table[];
+
static bool node_has_compatible(struct device_node *pp)
{
return of_get_property(pp, "compatible", NULL);
@@ -25,6 +37,8 @@ static int parse_fixed_partitions(struct mtd_info *master,
const struct mtd_partition **pparts,
struct mtd_part_parser_data *data)
{
+ const struct fixed_partitions_quirks *q
[PATCH 2/3] dt-bindings: mtd: add binding from BCM4908 partitions
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those should be
marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
.../partitions/brcm,bcm4908-partitions.yaml | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
diff --git
a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
new file mode 100644
index ..4090b61a3da7
--- /dev/null
+++
b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/brcm,bcm4908-partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 partitioning
+
+description: |
+ Broadcom BCM4908 CFE bootloader supports two firmware partitions. One is used
+ for regular booting, the other is treated as fallback.
+
+ This binding allows defining all fixed partitions and marking those
containing
+ firmware. System can use that information e.g. for booting or flashing
+ purposes.
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,bcm4908-partitions
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+patternProperties:
+ "@[0-9a-f]+$":
+allOf:
+ - $ref: "partition.yaml#"
+ - properties:
+ compatible:
+const: brcm,bcm4908-firmware
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+partitions {
+compatible = "brcm,bcm4908-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+label = "cferom";
+reg = <0x0 0x10>;
+};
+
+partition@10 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x10 0xf0>;
+};
+
+partition@100 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x100 0xf0>;
+};
+
+partition@1f0 {
+label = "calibration";
+reg = <0x1f0 0x10>;
+};
+};
--
2.26.2
[PATCH 1/3] dt-bindings: mtd: move partition binding to its own file
From: Rafał Miłecki Single partition binding is quite common and may be: 1. Used by multiple parsers 2. Extended for more specific cases Move it to separated file to avoid code duplication. Signed-off-by: Rafał Miłecki --- .../mtd/partitions/fixed-partitions.yaml | 33 + .../bindings/mtd/partitions/partition.yaml| 47 +++ 2 files changed, 48 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml index 6d4a3450e064..ea4cace6a955 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml @@ -27,38 +27,7 @@ properties: patternProperties: "@[0-9a-f]+$": -description: node describing a single flash partition -type: object - -properties: - reg: -description: partition's offset and size within the flash -maxItems: 1 - - label: -description: The label / name for this partition. If omitted, the label - is taken from the node name (excluding the unit address). - - read-only: -description: This parameter, if present, is a hint that this partition - should only be mounted read-only. This is usually used for flash - partitions containing early-boot firmware images or data which should - not be clobbered. -type: boolean - - lock: -description: Do not unlock the partition at initialization time (not - supported on all devices) -type: boolean - - slc-mode: -description: This parameter, if present, allows one to emulate SLC mode - on a partition attached to an MLC NAND thus making this partition - immune to paired-pages corruptions -type: boolean - -required: - - reg +$ref: "partition.yaml#" required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml new file mode 100644 index ..e1ac08064425 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/partition.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Partition + +description: | + This binding describes a single flash partition. Each partition must have its + relative offset and size specified. Depending on partition function extra + properties can be used. + +maintainers: + - Rafał Miłecki + +properties: + reg: +description: partition's offset and size within the flash +maxItems: 1 + + label: +description: The label / name for this partition. If omitted, the label + is taken from the node name (excluding the unit address). + + read-only: +description: This parameter, if present, is a hint that this partition + should only be mounted read-only. This is usually used for flash + partitions containing early-boot firmware images or data which should + not be clobbered. +type: boolean + + lock: +description: Do not unlock the partition at initialization time (not + supported on all devices) +type: boolean + + slc-mode: +description: This parameter, if present, allows one to emulate SLC mode + on a partition attached to an MLC NAND thus making this partition + immune to paired-pages corruptions +type: boolean + +required: + - reg + +additionalProperties: true -- 2.26.2
[PATCH Broadcom/stblinux 2/2] soc: bcm: bcm-pmb: add BCM63138 SATA support
From: Rafał Miłecki
BCM63138 has SATA controller that needs to be powered up using PMB.
Signed-off-by: Rafał Miłecki
---
Florian: this is based on your patches
ARM: dts: BCM63xx: enable SATA PHY and AHCI controller
reset: bcm63xx: Add Broadcom BCM63138 reset controller driver
I didn't test it as I don't own any bcm63xx devices.
---
drivers/soc/bcm/bcm63xx/bcm-pmb.c | 30 ++
include/dt-bindings/soc/bcm-pmb.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/soc/bcm/bcm63xx/bcm-pmb.c
b/drivers/soc/bcm/bcm63xx/bcm-pmb.c
index c223023dc64f..774465c119be 100644
--- a/drivers/soc/bcm/bcm63xx/bcm-pmb.c
+++ b/drivers/soc/bcm/bcm63xx/bcm-pmb.c
@@ -209,6 +209,28 @@ static int bcm_pmb_power_on_device(struct bcm_pmb *pmb,
int bus, u8 device)
return err;
}
+static int bcm_pmb_power_on_sata(struct bcm_pmb *pmb, int bus, u8 device)
+{
+ int err;
+
+ err = bcm_pmb_power_on_zone(pmb, bus, device, 0);
+ if (err)
+ return err;
+
+ /* Does not apply to the BCM963158 */
+ err = bcm_pmb_bpcm_write(pmb, bus, device, BPCM_MISC_CONTROL, 0);
+ if (err)
+ return err;
+
+ err = bcm_pmb_bpcm_write(pmb, bus, device, BPCM_SR_CONTROL, 0x);
+ if (err)
+ return err;
+
+ err = bcm_pmb_bpcm_write(pmb, bus, device, BPCM_SR_CONTROL, 0);
+
+ return err;
+}
+
static int bcm_pmb_power_on(struct generic_pm_domain *genpd)
{
struct bcm_pmb_pm_domain *pd = container_of(genpd, struct
bcm_pmb_pm_domain, genpd);
@@ -222,6 +244,8 @@ static int bcm_pmb_power_on(struct generic_pm_domain *genpd)
return bcm_pmb_power_on_zone(pmb, data->bus, data->device, 0);
case BCM_PMB_HOST_USB:
return bcm_pmb_power_on_device(pmb, data->bus, data->device);
+ case BCM_PMB_SATA:
+ return bcm_pmb_power_on_sata(pmb, data->bus, data->device);
default:
dev_err(pmb->dev, "unsupported device id: %d\n", data->id);
return -EINVAL;
@@ -317,8 +341,14 @@ static const struct bcm_pmb_pd_data bcm_pmb_bcm4908_data[]
= {
{ },
};
+static const struct bcm_pmb_pd_data bcm_pmb_bcm63138_data[] = {
+ { .name = "sata", .id = BCM_PMB_SATA, .bus = 0, .device = 3, },
+ { },
+};
+
static const struct of_device_id bcm_pmb_of_match[] = {
{ .compatible = "brcm,bcm4908-pmb", .data = _pmb_bcm4908_data, },
+ { .compatible = "brcm,bcm63138-pmb", .data = _pmb_bcm63138_data, },
{ },
};
diff --git a/include/dt-bindings/soc/bcm-pmb.h
b/include/dt-bindings/soc/bcm-pmb.h
index 744dc3af4d41..385884468007 100644
--- a/include/dt-bindings/soc/bcm-pmb.h
+++ b/include/dt-bindings/soc/bcm-pmb.h
@@ -7,5 +7,6 @@
#define BCM_PMB_PCIE1 0x02
#define BCM_PMB_PCIE2 0x03
#define BCM_PMB_HOST_USB 0x04
+#define BCM_PMB_SATA 0x05
#endif
--
2.26.2
[PATCH Broadcom/stblinux 1/2] dt-bindings: power: bcm-pmb: add BCM63138 binding
From: Rafał Miłecki PMB can be also found on bcm63xx chipsets. It uses difference device addresses so a new binding is required. Signed-off-by: Rafał Miłecki --- Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml index 40b08d83c80b..f8e7ddbd2705 100644 --- a/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml +++ b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: - brcm,bcm4908-pmb + - brcm,bcm63138-pmb reg: description: register space of one or more buses -- 2.26.2
[PATCH Broadcom/stblinux] soc: brcmstb: add stubs for getting platform IDs
From: Rafał Miłecki
Some brcmstb drivers may be shared with other SoC families. E.g. the
same USB PHY block is shared by brcmstb and BCM4908.
To avoid building brcmstb common code on non-brcmstb platforms we need
stubs for:
1. brcmstb_get_family_id()
2. brcmstb_get_product_id()
(to avoid "undefined reference to" errors).
With this change PHY_BRCM_USB will not have to unconditionally select
SOC_BRCMSTB anymore.
Signed-off-by: Rafał Miłecki
---
include/linux/soc/brcmstb/brcmstb.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/soc/brcmstb/brcmstb.h
b/include/linux/soc/brcmstb/brcmstb.h
index 8e884e0dda0a..9433f5c8fd94 100644
--- a/include/linux/soc/brcmstb/brcmstb.h
+++ b/include/linux/soc/brcmstb/brcmstb.h
@@ -12,6 +12,8 @@ static inline u32 BRCM_REV(u32 reg)
return reg & 0xff;
}
+#ifdef CONFIG_SOC_BRCMSTB
+
/*
* Helper functions for getting family or product id from the
* SoC driver.
@@ -19,4 +21,18 @@ static inline u32 BRCM_REV(u32 reg)
u32 brcmstb_get_family_id(void);
u32 brcmstb_get_product_id(void);
+#else
+
+static inline u32 brcmstb_get_family_id(void)
+{
+ return 0;
+}
+
+static inline u32 brcmstb_get_product_id(void)
+{
+ return 0;
+}
+
+#endif
+
#endif /* __BRCMSTB_SOC_H */
--
2.26.2
[PATCH V4 2/3] dt-bindings: phy: brcm,brcmstb-usb-phy: add BCM4908 binding
From: Rafał Miłecki BCM4908 uses the same PHY and may require just a slightly different programming. Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli Acked-by: Rob Herring --- .../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index a5780beadf97..0497368d1fca 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -15,6 +15,7 @@ maintainers: properties: compatible: enum: + - brcm,bcm4908-usb-phy - brcm,bcm7211-usb-phy - brcm,bcm7216-usb-phy - brcm,brcmstb-usb-phy @@ -113,7 +114,9 @@ allOf: properties: compatible: contains: -const: brcm,brcmstb-usb-phy +enum: + - const: brcm,bcm4908-usb-phy + - const: brcm,brcmstb-usb-phy then: properties: reg: -- 2.26.2
[PATCH V4 3/3] phy: phy-brcm-usb: support PHY on the BCM4908
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index a1f1a9c90d0d..09256339bd04 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -91,10 +91,11 @@ config PHY_BRCM_SATA
config PHY_BRCM_USB
tristate "Broadcom STB USB PHY driver"
- depends on ARCH_BRCMSTB || COMPILE_TEST
+ depends on ARCH_BCM4908 || ARCH_BRCMSTB || COMPILE_TEST
depends on OF
select GENERIC_PHY
select SOC_BRCMSTB
+ default ARCH_BCM4908
default ARCH_BRCMSTB
help
Enable this to support the Broadcom STB USB PHY.
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index 99fbc7e4138b..63f922a5f29b 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -285,6 +285,10 @@ static const struct match_chip_info chip_info_7445 = {
};
static const struct of_device_id brcm_usb_dt_ids[] = {
+ {
+ .compatible = "brcm,bcm4908-usb-phy",
+ .data = _info_7445,
+ },
{
.compatible = "brcm,bcm7216-usb-phy",
.data = _info_7216,
--
2.26.2
[PATCH V4 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In examples they
were integers and Linux checks for int as well. Both got uint32.
3. Added minimal description
Signed-off-by: Rafał Miłecki
---
V2: Add Al as maintainer
V3: Define "reg" and "reg-names" directly in the properties
V4: additionalProperties: false
Fix example to use brcm,syscon-piarbctl (with the prefix)
---
.../bindings/phy/brcm,brcmstb-usb-phy.txt | 86
.../bindings/phy/brcm,brcmstb-usb-phy.yaml| 193 ++
2 files changed, 193 insertions(+), 86 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
create mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
deleted file mode 100644
index 698aacbdcfc4..
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Broadcom STB USB PHY
-
-Required properties:
-- compatible: should be one of
- "brcm,brcmstb-usb-phy"
- "brcm,bcm7216-usb-phy"
- "brcm,bcm7211-usb-phy"
-
-- reg and reg-names properties requirements are specific to the
- compatible string.
- "brcm,brcmstb-usb-phy":
-- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
- and an optional pair for systems with USB 3.x support
-- reg-names: not specified
- "brcm,bcm7216-usb-phy":
-- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
- registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
- "brcm,bcm7211-usb-phy":
-- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
- USB_PHY and USB_MDIO registers and an optional pair
- for the BDC registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
-
-- #phy-cells: Shall be 1 as it expects one argument for setting
- the type of the PHY. Possible values are:
- - PHY_TYPE_USB2 for USB1.1/2.0 PHY
- - PHY_TYPE_USB3 for USB3.x PHY
-
-Optional Properties:
-- clocks : clock phandles.
-- clock-names: String, clock name.
-- interrupts: wakeup interrupt
-- interrupt-names: "wakeup"
-- brcm,ipp: Boolean, Invert Port Power.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- brcm,ioc: Boolean, Invert Over Current detection.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- dr_mode: String, PHY Device mode.
- Possible values are: "host", "peripheral ", "drd" or "typec-pd"
- If this property is not defined, the phy will default to "host" mode.
-- brcm,syscon-piarbctl: phandle to syscon for handling config registers
-NOTE: one or both of the following two properties must be set
-- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
-- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
-
-
-Example:
-
-usbphy_0: usb-phy@f0470200 {
- reg = <0xf0470200 0xb8>,
- <0xf0471940 0x6c0>;
- compatible = "brcm,brcmstb-usb-phy";
- #phy-cells = <1>;
- dr_mode = "host"
- brcm,ioc = <1>;
- brcm,ipp = <1>;
- brcm,has-xhci;
- brcm,has-eohci;
- clocks = <>, <>;
- clock-names = "sw_usb", "sw_usb3";
-};
-
-usb-phy@29f0200 {
- reg = <0x29f0200 0x200>,
- <0x29c0880 0x30>,
- <0x29cc100 0x534>,
- <0x2808000 0x24>,
- <0x2980080 0x8>;
- reg-names = "ctrl",
- "xhci_ec",
- "xhci_gbl",
- "usb_phy",
- "usb_mdio";
- brcm,ioc = <0x0>;
- brcm,ipp = <0x0>;
- compatible = "brcm,bcm7211-usb-phy";
- interrupts = <0x30>;
- interrupt-parent = <_intr1_nosec_intc>;
- interrupt-names = "wake";
- #phy-cells = <0x1>;
- brcm,has-xhci;
- syscon-piarbctl = <_piarbctl>;
- clocks = <_clk 256>;
- clock-names = "sw_usb";
-};
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
new file mode 100644
index ..a5780beadf97
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-ph
[PATCH V3 3/3] phy: phy-brcm-usb: support PHY on the BCM4908
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index a1f1a9c90d0d..09256339bd04 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -91,10 +91,11 @@ config PHY_BRCM_SATA
config PHY_BRCM_USB
tristate "Broadcom STB USB PHY driver"
- depends on ARCH_BRCMSTB || COMPILE_TEST
+ depends on ARCH_BCM4908 || ARCH_BRCMSTB || COMPILE_TEST
depends on OF
select GENERIC_PHY
select SOC_BRCMSTB
+ default ARCH_BCM4908
default ARCH_BRCMSTB
help
Enable this to support the Broadcom STB USB PHY.
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index 99fbc7e4138b..63f922a5f29b 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -285,6 +285,10 @@ static const struct match_chip_info chip_info_7445 = {
};
static const struct of_device_id brcm_usb_dt_ids[] = {
+ {
+ .compatible = "brcm,bcm4908-usb-phy",
+ .data = _info_7445,
+ },
{
.compatible = "brcm,bcm7216-usb-phy",
.data = _info_7216,
--
2.26.2
[PATCH V3 2/3] dt-bindings: phy: brcm,brcmstb-usb-phy: add BCM4908 binding
From: Rafał Miłecki BCM4908 uses the same PHY and may require just a slightly different programming. Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli Acked-by: Rob Herring --- .../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 4b8958d8c119..2d9ae83250ab 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -15,6 +15,7 @@ maintainers: properties: compatible: enum: + - brcm,bcm4908-usb-phy - brcm,bcm7211-usb-phy - brcm,bcm7216-usb-phy - brcm,brcmstb-usb-phy @@ -113,7 +114,9 @@ allOf: properties: compatible: contains: -const: brcm,brcmstb-usb-phy +enum: + - const: brcm,bcm4908-usb-phy + - const: brcm,brcmstb-usb-phy then: properties: reg: -- 2.26.2
[PATCH V3 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In examples they
were integers and Linux checks for int as well. Both got uint32.
3. Added minimal description
Signed-off-by: Rafał Miłecki
---
V2: Add Al as maintainer
V3: Define "reg" and "reg-names" directly in the properties
---
.../bindings/phy/brcm,brcmstb-usb-phy.txt | 86
.../bindings/phy/brcm,brcmstb-usb-phy.yaml| 193 ++
2 files changed, 193 insertions(+), 86 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
create mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
deleted file mode 100644
index 698aacbdcfc4..
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Broadcom STB USB PHY
-
-Required properties:
-- compatible: should be one of
- "brcm,brcmstb-usb-phy"
- "brcm,bcm7216-usb-phy"
- "brcm,bcm7211-usb-phy"
-
-- reg and reg-names properties requirements are specific to the
- compatible string.
- "brcm,brcmstb-usb-phy":
-- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
- and an optional pair for systems with USB 3.x support
-- reg-names: not specified
- "brcm,bcm7216-usb-phy":
-- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
- registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
- "brcm,bcm7211-usb-phy":
-- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
- USB_PHY and USB_MDIO registers and an optional pair
- for the BDC registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
-
-- #phy-cells: Shall be 1 as it expects one argument for setting
- the type of the PHY. Possible values are:
- - PHY_TYPE_USB2 for USB1.1/2.0 PHY
- - PHY_TYPE_USB3 for USB3.x PHY
-
-Optional Properties:
-- clocks : clock phandles.
-- clock-names: String, clock name.
-- interrupts: wakeup interrupt
-- interrupt-names: "wakeup"
-- brcm,ipp: Boolean, Invert Port Power.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- brcm,ioc: Boolean, Invert Over Current detection.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- dr_mode: String, PHY Device mode.
- Possible values are: "host", "peripheral ", "drd" or "typec-pd"
- If this property is not defined, the phy will default to "host" mode.
-- brcm,syscon-piarbctl: phandle to syscon for handling config registers
-NOTE: one or both of the following two properties must be set
-- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
-- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
-
-
-Example:
-
-usbphy_0: usb-phy@f0470200 {
- reg = <0xf0470200 0xb8>,
- <0xf0471940 0x6c0>;
- compatible = "brcm,brcmstb-usb-phy";
- #phy-cells = <1>;
- dr_mode = "host"
- brcm,ioc = <1>;
- brcm,ipp = <1>;
- brcm,has-xhci;
- brcm,has-eohci;
- clocks = <>, <>;
- clock-names = "sw_usb", "sw_usb3";
-};
-
-usb-phy@29f0200 {
- reg = <0x29f0200 0x200>,
- <0x29c0880 0x30>,
- <0x29cc100 0x534>,
- <0x2808000 0x24>,
- <0x2980080 0x8>;
- reg-names = "ctrl",
- "xhci_ec",
- "xhci_gbl",
- "usb_phy",
- "usb_mdio";
- brcm,ioc = <0x0>;
- brcm,ipp = <0x0>;
- compatible = "brcm,bcm7211-usb-phy";
- interrupts = <0x30>;
- interrupt-parent = <_intr1_nosec_intc>;
- interrupt-names = "wake";
- #phy-cells = <0x1>;
- brcm,has-xhci;
- syscon-piarbctl = <_piarbctl>;
- clocks = <_clk 256>;
- clock-names = "sw_usb";
-};
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
new file mode 100644
index ..4b8958d8c119
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
Re: [PATCH V2 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
On 03.01.2021 17:23, Rob Herring wrote: On Mon, Dec 21, 2020 at 06:23:37AM +0100, Rafał Miłecki wrote: From: Rafał Miłecki Changes that require mentioning: 1. interrupt-names Name "wakeup" was changed to the "wake". It matches example and what Linux driver looks for in the first place 2. brcm,ipp and brcm,ioc Both were described as booleans with 0 / 1 values. In examples they were integers and Linux driver checks for int as well. I made both uint32 but that probably should be refactored later. Why? You're stuck with that now. "Why?" refactor later? I thought it makes more sense for boolean-like settings to use boolean type. Just a slightly cleaner approach. If we care to, I believe I can do that without breaking backward compatibility. A simple value length check: length 1: treat 0 as false, treat 1 as true length 0: treat property existence as true
[PATCH V2 3/3] phy: phy-brcm-usb: support PHY on the BCM4908
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index a1f1a9c90d0d..09256339bd04 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -91,10 +91,11 @@ config PHY_BRCM_SATA
config PHY_BRCM_USB
tristate "Broadcom STB USB PHY driver"
- depends on ARCH_BRCMSTB || COMPILE_TEST
+ depends on ARCH_BCM4908 || ARCH_BRCMSTB || COMPILE_TEST
depends on OF
select GENERIC_PHY
select SOC_BRCMSTB
+ default ARCH_BCM4908
default ARCH_BRCMSTB
help
Enable this to support the Broadcom STB USB PHY.
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index 99fbc7e4138b..63f922a5f29b 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -285,6 +285,10 @@ static const struct match_chip_info chip_info_7445 = {
};
static const struct of_device_id brcm_usb_dt_ids[] = {
+ {
+ .compatible = "brcm,bcm4908-usb-phy",
+ .data = _info_7445,
+ },
{
.compatible = "brcm,bcm7216-usb-phy",
.data = _info_7216,
--
2.26.2
[PATCH V2 2/3] dt-bindings: phy: brcm,brcmstb-usb-phy: add BCM4908 binding
From: Rafał Miłecki BCM4908 uses the same PHY and may require just a slightly different programming. Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli --- .../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 1dad1e3df1a5..2bdcb649808b 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -15,6 +15,7 @@ maintainers: properties: compatible: enum: + - brcm,bcm4908-usb-phy - brcm,bcm7211-usb-phy - brcm,bcm7216-usb-phy - brcm,brcmstb-usb-phy @@ -91,7 +92,9 @@ allOf: properties: compatible: contains: -const: brcm,brcmstb-usb-phy +enum: + - const: brcm,bcm4908-usb-phy + - const: brcm,brcmstb-usb-phy then: properties: reg: -- 2.26.2
[PATCH V2 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In examples they
were integers and Linux driver checks for int as well.
I made both uint32 but that probably should be refactored later.
3. Added minimal description
Signed-off-by: Rafał Miłecki
---
V2: Add Al as maintainer
---
.../bindings/phy/brcm,brcmstb-usb-phy.txt | 86
.../bindings/phy/brcm,brcmstb-usb-phy.yaml| 196 ++
2 files changed, 196 insertions(+), 86 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
create mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
deleted file mode 100644
index 698aacbdcfc4..
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Broadcom STB USB PHY
-
-Required properties:
-- compatible: should be one of
- "brcm,brcmstb-usb-phy"
- "brcm,bcm7216-usb-phy"
- "brcm,bcm7211-usb-phy"
-
-- reg and reg-names properties requirements are specific to the
- compatible string.
- "brcm,brcmstb-usb-phy":
-- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
- and an optional pair for systems with USB 3.x support
-- reg-names: not specified
- "brcm,bcm7216-usb-phy":
-- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
- registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
- "brcm,bcm7211-usb-phy":
-- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
- USB_PHY and USB_MDIO registers and an optional pair
- for the BDC registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
-
-- #phy-cells: Shall be 1 as it expects one argument for setting
- the type of the PHY. Possible values are:
- - PHY_TYPE_USB2 for USB1.1/2.0 PHY
- - PHY_TYPE_USB3 for USB3.x PHY
-
-Optional Properties:
-- clocks : clock phandles.
-- clock-names: String, clock name.
-- interrupts: wakeup interrupt
-- interrupt-names: "wakeup"
-- brcm,ipp: Boolean, Invert Port Power.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- brcm,ioc: Boolean, Invert Over Current detection.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- dr_mode: String, PHY Device mode.
- Possible values are: "host", "peripheral ", "drd" or "typec-pd"
- If this property is not defined, the phy will default to "host" mode.
-- brcm,syscon-piarbctl: phandle to syscon for handling config registers
-NOTE: one or both of the following two properties must be set
-- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
-- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
-
-
-Example:
-
-usbphy_0: usb-phy@f0470200 {
- reg = <0xf0470200 0xb8>,
- <0xf0471940 0x6c0>;
- compatible = "brcm,brcmstb-usb-phy";
- #phy-cells = <1>;
- dr_mode = "host"
- brcm,ioc = <1>;
- brcm,ipp = <1>;
- brcm,has-xhci;
- brcm,has-eohci;
- clocks = <>, <>;
- clock-names = "sw_usb", "sw_usb3";
-};
-
-usb-phy@29f0200 {
- reg = <0x29f0200 0x200>,
- <0x29c0880 0x30>,
- <0x29cc100 0x534>,
- <0x2808000 0x24>,
- <0x2980080 0x8>;
- reg-names = "ctrl",
- "xhci_ec",
- "xhci_gbl",
- "usb_phy",
- "usb_mdio";
- brcm,ioc = <0x0>;
- brcm,ipp = <0x0>;
- compatible = "brcm,bcm7211-usb-phy";
- interrupts = <0x30>;
- interrupt-parent = <_intr1_nosec_intc>;
- interrupt-names = "wake";
- #phy-cells = <0x1>;
- brcm,has-xhci;
- syscon-piarbctl = <_piarbctl>;
- clocks = <_clk 256>;
- clock-names = "sw_usb";
-};
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
new file mode 100644
index 0000..1dad1e3df1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicet
[PATCH 2/2] phy: phy-brcm-usb: specify init function format at struct level
From: Rafał Miłecki
This is slightly cleaner solution that assures noone assings a wrong
function to the pointer.
Signed-off-by: Rafał Miłecki
---
drivers/phy/broadcom/phy-brcm-usb.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index f0f01060bd12..116fb23aebd9 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -35,7 +35,7 @@ struct value_to_name_map {
};
struct match_chip_info {
- void *init_func;
+ void (*init_func)(struct brcm_usb_init_params *params);
u8 required_regs[BRCM_REGS_MAX + 1];
u8 optional_reg;
};
@@ -432,7 +432,6 @@ static int brcm_usb_phy_probe(struct platform_device *pdev)
struct device_node *dn = pdev->dev.of_node;
int err;
const char *mode;
- void (*dvr_init)(struct brcm_usb_init_params *params);
const struct match_chip_info *info;
struct regmap *rmap;
int x;
@@ -448,8 +447,8 @@ static int brcm_usb_phy_probe(struct platform_device *pdev)
info = of_device_get_match_data(>dev);
if (!info)
return -ENOENT;
- dvr_init = info->init_func;
- (*dvr_init)(>ini);
+
+ info->init_func(>ini);
dev_dbg(dev, "Best mapping table is for %s\n",
priv->ini.family_name);
--
2.26.2
[PATCH 1/2] phy: phy-brcm-usb: improve getting OF matching data
From: Rafał Miłecki 1. Use of_device_get_match_data() helper to simplify the code 2. Check for NULL as a good practice Signed-off-by: Rafał Miłecki --- drivers/phy/broadcom/phy-brcm-usb.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/phy/broadcom/phy-brcm-usb.c b/drivers/phy/broadcom/phy-brcm-usb.c index 63f922a5f29b..f0f01060bd12 100644 --- a/drivers/phy/broadcom/phy-brcm-usb.c +++ b/drivers/phy/broadcom/phy-brcm-usb.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -431,7 +432,6 @@ static int brcm_usb_phy_probe(struct platform_device *pdev) struct device_node *dn = pdev->dev.of_node; int err; const char *mode; - const struct of_device_id *match; void (*dvr_init)(struct brcm_usb_init_params *params); const struct match_chip_info *info; struct regmap *rmap; @@ -445,8 +445,9 @@ static int brcm_usb_phy_probe(struct platform_device *pdev) priv->ini.family_id = brcmstb_get_family_id(); priv->ini.product_id = brcmstb_get_product_id(); - match = of_match_node(brcm_usb_dt_ids, dev->of_node); - info = match->data; + info = of_device_get_match_data(>dev); + if (!info) + return -ENOENT; dvr_init = info->init_func; (*dvr_init)(>ini); -- 2.26.2
[PATCH 3/3] phy: phy-brcm-usb: support BCM4908 binding
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but work when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
drivers/phy/broadcom/phy-brcm-usb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers/phy/broadcom/phy-brcm-usb.c
index 99fbc7e4138b..63f922a5f29b 100644
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -285,6 +285,10 @@ static const struct match_chip_info chip_info_7445 = {
};
static const struct of_device_id brcm_usb_dt_ids[] = {
+ {
+ .compatible = "brcm,bcm4908-usb-phy",
+ .data = _info_7445,
+ },
{
.compatible = "brcm,bcm7216-usb-phy",
.data = _info_7216,
--
2.26.2
[PATCH 2/3] dt-bindings: phy: brcm,brcmstb-usb-phy: add BCM4908 binding
From: Rafał Miłecki BCM4908 uses the same PHY and may require just slightly different programming. Signed-off-by: Rafał Miłecki --- .../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 34664bdfa4be..021d3171be75 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -14,6 +14,7 @@ maintainers: properties: compatible: enum: + - brcm,bcm4908-usb-phy - brcm,bcm7211-usb-phy - brcm,bcm7216-usb-phy - brcm,brcmstb-usb-phy @@ -90,7 +91,9 @@ allOf: properties: compatible: contains: -const: brcm,brcmstb-usb-phy +enum: + - const: brcm,bcm4908-usb-phy + - const: brcm,brcmstb-usb-phy then: properties: reg: -- 2.26.2
[PATCH 1/3] dt-bindings: phy: brcm,brcmstb-usb-phy: convert to the json-schema
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In examples they
were integers and Linux driver checks for int as well.
I made both uint32 but that probably should be refactored later.
3. Added minimal description
Signed-off-by: Rafał Miłecki
---
.../bindings/phy/brcm,brcmstb-usb-phy.txt | 86
.../bindings/phy/brcm,brcmstb-usb-phy.yaml| 195 ++
2 files changed, 195 insertions(+), 86 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
create mode 100644
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
deleted file mode 100644
index 698aacbdcfc4..
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Broadcom STB USB PHY
-
-Required properties:
-- compatible: should be one of
- "brcm,brcmstb-usb-phy"
- "brcm,bcm7216-usb-phy"
- "brcm,bcm7211-usb-phy"
-
-- reg and reg-names properties requirements are specific to the
- compatible string.
- "brcm,brcmstb-usb-phy":
-- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
- and an optional pair for systems with USB 3.x support
-- reg-names: not specified
- "brcm,bcm7216-usb-phy":
-- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
- registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
- "brcm,bcm7211-usb-phy":
-- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
- USB_PHY and USB_MDIO registers and an optional pair
- for the BDC registers
-- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
-
-- #phy-cells: Shall be 1 as it expects one argument for setting
- the type of the PHY. Possible values are:
- - PHY_TYPE_USB2 for USB1.1/2.0 PHY
- - PHY_TYPE_USB3 for USB3.x PHY
-
-Optional Properties:
-- clocks : clock phandles.
-- clock-names: String, clock name.
-- interrupts: wakeup interrupt
-- interrupt-names: "wakeup"
-- brcm,ipp: Boolean, Invert Port Power.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- brcm,ioc: Boolean, Invert Over Current detection.
- Possible values are: 0 (Don't invert), 1 (Invert)
-- dr_mode: String, PHY Device mode.
- Possible values are: "host", "peripheral ", "drd" or "typec-pd"
- If this property is not defined, the phy will default to "host" mode.
-- brcm,syscon-piarbctl: phandle to syscon for handling config registers
-NOTE: one or both of the following two properties must be set
-- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
-- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
-
-
-Example:
-
-usbphy_0: usb-phy@f0470200 {
- reg = <0xf0470200 0xb8>,
- <0xf0471940 0x6c0>;
- compatible = "brcm,brcmstb-usb-phy";
- #phy-cells = <1>;
- dr_mode = "host"
- brcm,ioc = <1>;
- brcm,ipp = <1>;
- brcm,has-xhci;
- brcm,has-eohci;
- clocks = <>, <>;
- clock-names = "sw_usb", "sw_usb3";
-};
-
-usb-phy@29f0200 {
- reg = <0x29f0200 0x200>,
- <0x29c0880 0x30>,
- <0x29cc100 0x534>,
- <0x2808000 0x24>,
- <0x2980080 0x8>;
- reg-names = "ctrl",
- "xhci_ec",
- "xhci_gbl",
- "usb_phy",
- "usb_mdio";
- brcm,ioc = <0x0>;
- brcm,ipp = <0x0>;
- compatible = "brcm,bcm7211-usb-phy";
- interrupts = <0x30>;
- interrupt-parent = <_intr1_nosec_intc>;
- interrupt-names = "wake";
- #phy-cells = <0x1>;
- brcm,has-xhci;
- syscon-piarbctl = <_piarbctl>;
- clocks = <_clk 256>;
- clock-names = "sw_usb";
-};
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
new file mode 100644
index ..34664bdfa4be
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,brc
Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
On 14.12.2020 18:32, Florian Fainelli wrote: On 12/14/20 4:24 AM, Rafał Miłecki wrote: On 11.12.2020 23:08, Florian Fainelli wrote: On 12/11/20 1:59 PM, Rafał Miłecki wrote: From: Rafał Miłecki PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138). It's needed to power on and off SoC blocks like PCIe, SATA, USB. Signed-off-by: Rafał Miłecki I will do a more thorough review tonight, however do you mind moving the driver under drives/soc/bcm/bcm63xx? The first SoC that had PMB was 63138 and that one is DSL. I now realized that bcm63xx's: * Kconfig is wrapper in: if SOC_BCM63XX * Makefile is conditional: obj-$(CONFIG_SOC_BCM63XX) So it means I've to either: 1. Refactor bcm63xx structure 2. Make SOC_BCM63XX selectable on ARCH_BCM4908 and select it I'm not sure if any of above is a really good idea. Any further thought, ideas? Well, I was thinking about thing along those lines below, it's really about putting drivers that belong to the same SoC family in the same basket for easier maintenance while submitting patches/pull requests from my side. diff --git a/drivers/soc/bcm/Makefile b/drivers/soc/bcm/Makefile index 7bc90e0bd773..0f0efa28d92b 100644 --- a/drivers/soc/bcm/Makefile +++ b/drivers/soc/bcm/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_BCM2835_POWER)+= bcm2835-power.o obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o -obj-$(CONFIG_SOC_BCM63XX) += bcm63xx/ +obj-y += bcm63xx/ obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/ diff --git a/drivers/soc/bcm/bcm63xx/Kconfig b/drivers/soc/bcm/bcm63xx/Kconfig index 16f648a6c70a..76fb61e7377e 100644 --- a/drivers/soc/bcm/bcm63xx/Kconfig +++ b/drivers/soc/bcm/bcm63xx/Kconfig @@ -10,3 +10,8 @@ config BCM63XX_POWER BCM6318, BCM6328, BCM6362 and BCM63268 SoCs. endif # SOC_BCM63XX + +config BCM_PMB_POWER + tristate "Broadcom PMB bus power domain driver" + depends on BMIPS_GENERIC || ARCH_BCM4908 || COMPILE_TEST + default ARCH_BCM4908 Sounds OK to me, thanks for clarifying what approach you're OK with!
[PATCH V2 2/2] soc: bcm: add PM driver for Broadcom's PMB
From: Rafał Miłecki PMB originally comes from BCM63138 but can be also found on many other chipsets (e.g. BCM4908). It's needed to power on and off SoC blocks like PCIe, SATA, USB. Signed-off-by: Rafał Miłecki --- V2: Use drivers/soc/bcm/bcm63xx/ Add help to the config BCM_PMB Drop debugging print --- MAINTAINERS | 10 + drivers/soc/bcm/Makefile | 2 +- drivers/soc/bcm/bcm63xx/Kconfig | 9 + drivers/soc/bcm/bcm63xx/Makefile | 1 + drivers/soc/bcm/bcm63xx/bcm-pmb.c | 333 ++ 5 files changed, 354 insertions(+), 1 deletion(-) create mode 100644 drivers/soc/bcm/bcm63xx/bcm-pmb.c diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..75140f0d1541 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3656,6 +3656,16 @@ L: linux-m...@vger.kernel.org S: Maintained F: drivers/firmware/broadcom/* +BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER +M: Rafał Miłecki +M: Florian Fainelli +M: bcm-kernel-feedback-l...@broadcom.com +L: linux...@vger.kernel.org +S: Maintained +T: git git://github.com/broadcom/stblinux.git +F: drivers/soc/bcm/bcm-pmb.c +F: include/dt-bindings/soc/bcm-pmb.h + BROADCOM SPECIFIC AMBA DRIVER (BCMA) M: Rafał Miłecki L: linux-wirel...@vger.kernel.org diff --git a/drivers/soc/bcm/Makefile b/drivers/soc/bcm/Makefile index 7bc90e0bd773..0f0efa28d92b 100644 --- a/drivers/soc/bcm/Makefile +++ b/drivers/soc/bcm/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_BCM2835_POWER)+= bcm2835-power.o obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o -obj-$(CONFIG_SOC_BCM63XX) += bcm63xx/ +obj-y += bcm63xx/ obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/ diff --git a/drivers/soc/bcm/bcm63xx/Kconfig b/drivers/soc/bcm/bcm63xx/Kconfig index 16f648a6c70a..9e501c8ac5ce 100644 --- a/drivers/soc/bcm/bcm63xx/Kconfig +++ b/drivers/soc/bcm/bcm63xx/Kconfig @@ -10,3 +10,12 @@ config BCM63XX_POWER BCM6318, BCM6328, BCM6362 and BCM63268 SoCs. endif # SOC_BCM63XX + +config BCM_PMB + bool "Broadcom PMB (Power Management Bus) driver" + depends on ARCH_BCM4908 || (COMPILE_TEST && OF) + default ARCH_BCM4908 + select PM_GENERIC_DOMAINS if PM + help + This enables support for the Broadcom's PMB (Power Management Bus) that + is used for disabling and enabling SoC devices. diff --git a/drivers/soc/bcm/bcm63xx/Makefile b/drivers/soc/bcm/bcm63xx/Makefile index 0710d5e018cc..557eed3d67bd 100644 --- a/drivers/soc/bcm/bcm63xx/Makefile +++ b/drivers/soc/bcm/bcm63xx/Makefile @@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_BCM63XX_POWER) += bcm63xx-power.o +obj-$(CONFIG_BCM_PMB) += bcm-pmb.o diff --git a/drivers/soc/bcm/bcm63xx/bcm-pmb.c b/drivers/soc/bcm/bcm63xx/bcm-pmb.c new file mode 100644 index ..c223023dc64f --- /dev/null +++ b/drivers/soc/bcm/bcm63xx/bcm-pmb.c @@ -0,0 +1,333 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Copyright (c) 2013 Broadcom + * Copyright (C) 2020 Rafał Miłecki + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define BPCM_ID_REG0x00 +#define BPCM_CAPABILITIES 0x04 +#define BPCM_CAP_NUM_ZONES0x00ff +#define BPCM_CAP_SR_REG_BITS 0xff00 +#define BPCM_CAP_PLLTYPE 0x0003 +#define BPCM_CAP_UBUS 0x0008 +#define BPCM_CONTROL 0x08 +#define BPCM_STATUS0x0c +#define BPCM_ROSC_CONTROL 0x10 +#define BPCM_ROSC_THRESH_H 0x14 +#define BPCM_ROSC_THRESHOLD_BCM68380x14 +#define BPCM_ROSC_THRESH_S 0x18 +#define BPCM_ROSC_COUNT_BCM68380x18 +#define BPCM_ROSC_COUNT0x1c +#define BPCM_PWD_CONTROL_BCM6838 0x1c +#define BPCM_PWD_CONTROL 0x20 +#define BPCM_SR_CONTROL_BCM68380x20 +#define BPCM_PWD_ACCUM_CONTROL 0x24 +#define BPCM_SR_CONTROL0x28 +#define BPCM_GLOBAL_CONTROL0x2c +#define BPCM_MISC_CONTROL 0x30 +#define BPCM_MISC_CONTROL2 0x34 +#define BPCM_SGPHY_CNTL0x38 +#define BPCM_SGPHY_STATUS 0x3c +#define BPCM_ZONE0 0x40 +#define BPCM_ZONE_CONTROL 0x00 +#define BPCM_ZONE_CONTROL_MANUAL_CLK_EN 0x0001 +#define BPCM_ZONE_CONTRO
[PATCH V2 0/2] Broadcom's PMB (Power Management Bus) support
From: Rafał Miłecki PMB is a hardware block used for powering SoC devices like PCIe, USB, SATA. Initially I planned to treat it as a reset controller and Philipp pointed out in review that PMB driver should use a power subsystem. This is my refactored support. *** Please note one difference when compared to the initial reset attempt. As I store info about SoC devices in the driver now, I had to put support for multiple buses there. That's required to avoid things like: compatible = "brcm,bcm4908-pmb-no-1"; compatible = "brcm,bcm4908-pmb-no-2"; So now a single "reg" covers bigger buses (e.g. 0x40) in size, see: reg = <0x802800e0 0x40>; Other SoCs my use something like: reg = <0x802800e0 0x20>; reg = <0x802800e0 0x60>; *** AFAIU this should go through Florian's tree. I based in on top of the soc-arm64/next. V2: Use drivers/soc/bcm/bcm63xx/ and add Kconfig help message Rafał Miłecki (2): dt-bindings: power: document Broadcom's PMB binding soc: bcm: add PM driver for Broadcom's PMB .../bindings/power/brcm,bcm-pmb.yaml | 50 +++ MAINTAINERS | 10 + drivers/soc/bcm/Makefile | 2 +- drivers/soc/bcm/bcm63xx/Kconfig | 9 + drivers/soc/bcm/bcm63xx/Makefile | 1 + drivers/soc/bcm/bcm63xx/bcm-pmb.c | 333 ++ include/dt-bindings/soc/bcm-pmb.h | 11 + 7 files changed, 415 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml create mode 100644 drivers/soc/bcm/bcm63xx/bcm-pmb.c create mode 100644 include/dt-bindings/soc/bcm-pmb.h -- 2.26.2
[PATCH V2 1/2] dt-bindings: power: document Broadcom's PMB binding
From: Rafał Miłecki
Broadcom's PMB is power controller used for disabling and enabling SoC
devices.
Signed-off-by: Rafał Miłecki
---
.../bindings/power/brcm,bcm-pmb.yaml | 50 +++
include/dt-bindings/soc/bcm-pmb.h | 11
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
create mode 100644 include/dt-bindings/soc/bcm-pmb.h
diff --git a/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
new file mode 100644
index ..40b08d83c80b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/brcm,bcm-pmb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom PMB (Power Management Bus) controller
+
+description: This document describes Broadcom's PMB controller. It supports
+ powering various types of connected devices (e.g. PCIe, USB, SATA).
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm4908-pmb
+
+ reg:
+description: register space of one or more buses
+maxItems: 1
+
+ big-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Flag to use for block working in big endian mode.
+
+ "#power-domain-cells":
+description: cell specifies device ID (see bcm-pmb.h)
+const: 1
+
+required:
+ - reg
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+pmb: power-controller@802800e0 {
+compatible = "brcm,bcm4908-pmb";
+reg = <0x802800e0 0x40>;
+#power-domain-cells = <1>;
+};
+
+foo {
+power-domains = < BCM_PMB_PCIE0>;
+};
diff --git a/include/dt-bindings/soc/bcm-pmb.h
b/include/dt-bindings/soc/bcm-pmb.h
new file mode 100644
index ..744dc3af4d41
--- /dev/null
+++ b/include/dt-bindings/soc/bcm-pmb.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */
+
+#ifndef __DT_BINDINGS_SOC_BCM_PMB_H
+#define __DT_BINDINGS_SOC_BCM_PMB_H
+
+#define BCM_PMB_PCIE0 0x01
+#define BCM_PMB_PCIE1 0x02
+#define BCM_PMB_PCIE2 0x03
+#define BCM_PMB_HOST_USB 0x04
+
+#endif
--
2.26.2
Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
On 11.12.2020 23:08, Florian Fainelli wrote: On 12/11/20 1:59 PM, Rafał Miłecki wrote: From: Rafał Miłecki PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138). It's needed to power on and off SoC blocks like PCIe, SATA, USB. Signed-off-by: Rafał Miłecki I will do a more thorough review tonight, however do you mind moving the driver under drives/soc/bcm/bcm63xx? The first SoC that had PMB was 63138 and that one is DSL. I now realized that bcm63xx's: * Kconfig is wrapper in: if SOC_BCM63XX * Makefile is conditional: obj-$(CONFIG_SOC_BCM63XX) So it means I've to either: 1. Refactor bcm63xx structure 2. Make SOC_BCM63XX selectable on ARCH_BCM4908 and select it I'm not sure if any of above is a really good idea. Any further thought, ideas?
Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
On 12.12.2020 04:26, Florian Fainelli wrote:
+
+static const struct bcm_pmb_pd_data bcm_pmb_bcm4908_data[] = {
+ { .name = "pcie2", .id = BCM_PMB_PCIE2, .bus = 0, .device = 2, },
+ { .name = "pcie0", .id = BCM_PMB_PCIE0, .bus = 1, .device = 14, },
+ { .name = "pcie1", .id = BCM_PMB_PCIE1, .bus = 1, .device = 15, },
+ { .name = "usb", .id = BCM_PMB_HOST_USB, .bus = 1, .device = 17, },
Do you have to be more specific and spell out whether this is the host
controller (xhci) or device (bdc)? If not, then this looks good to me.
I believe I have to and I believe I already do. I used BCM_PMB_HOST_USB
which clearly (I believe) points to the HOST controller.
In 6838 part of pmc_drv.h from Broadcom's SDK I found:
enum {
USB30_2X_Zone_Common,
USB30_2X_Zone_USB_Host,
USB30_2X_Zone_USB_Device,
};
and that's what makes me believe we need to specify HOST explicitly.
Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
On 11.12.2020 22:59, Rafał Miłecki wrote: @@ -13,6 +13,14 @@ config BCM2835_POWER firmware means that Linux usage of the same power domain must be accessed using the RASPBERRYPI_POWER driver +config BCM_PMB + bool "Broadcom PMB (Power Management Bus) driver" + depends on ARCH_BCM4908 || (COMPILE_TEST && OF) + default ARCH_BCM4908 + select PM_GENERIC_DOMAINS if PM + help + Foo I'll improve description a bit in V2 ;)
Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
On Fri, 11 Dec 2020 at 23:08, Florian Fainelli wrote: > On 12/11/20 1:59 PM, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138). > > It's needed to power on and off SoC blocks like PCIe, SATA, USB. > > > > Signed-off-by: Rafał Miłecki > > I will do a more thorough review tonight, however do you mind moving the > driver under drives/soc/bcm/bcm63xx? The first SoC that had PMB was > 63138 and that one is DSL. > > And we would probably need a MAINTAINERS file update for this driver? Sounds good! -- Rafał
[PATCH 1/2] dt-bindings: power: document Broadcom's PMB binding
From: Rafał Miłecki
Broadcom's PMB is power controller used for disabling and enabling SoC
devices.
Signed-off-by: Rafał Miłecki
---
.../bindings/power/brcm,bcm-pmb.yaml | 50 +++
include/dt-bindings/soc/bcm-pmb.h | 11
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
create mode 100644 include/dt-bindings/soc/bcm-pmb.h
diff --git a/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
new file mode 100644
index ..40b08d83c80b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/brcm,bcm-pmb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom PMB (Power Management Bus) controller
+
+description: This document describes Broadcom's PMB controller. It supports
+ powering various types of connected devices (e.g. PCIe, USB, SATA).
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm4908-pmb
+
+ reg:
+description: register space of one or more buses
+maxItems: 1
+
+ big-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Flag to use for block working in big endian mode.
+
+ "#power-domain-cells":
+description: cell specifies device ID (see bcm-pmb.h)
+const: 1
+
+required:
+ - reg
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+pmb: power-controller@802800e0 {
+compatible = "brcm,bcm4908-pmb";
+reg = <0x802800e0 0x40>;
+#power-domain-cells = <1>;
+};
+
+foo {
+power-domains = < BCM_PMB_PCIE0>;
+};
diff --git a/include/dt-bindings/soc/bcm-pmb.h
b/include/dt-bindings/soc/bcm-pmb.h
new file mode 100644
index ..744dc3af4d41
--- /dev/null
+++ b/include/dt-bindings/soc/bcm-pmb.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */
+
+#ifndef __DT_BINDINGS_SOC_BCM_PMB_H
+#define __DT_BINDINGS_SOC_BCM_PMB_H
+
+#define BCM_PMB_PCIE0 0x01
+#define BCM_PMB_PCIE1 0x02
+#define BCM_PMB_PCIE2 0x03
+#define BCM_PMB_HOST_USB 0x04
+
+#endif
--
2.26.2
[PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB
From: Rafał Miłecki PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138). It's needed to power on and off SoC blocks like PCIe, SATA, USB. Signed-off-by: Rafał Miłecki --- drivers/soc/bcm/Kconfig | 8 + drivers/soc/bcm/Makefile | 1 + drivers/soc/bcm/bcm-pmb.c | 335 ++ 3 files changed, 344 insertions(+) create mode 100644 drivers/soc/bcm/bcm-pmb.c diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig index 24f92a6e882a..327cfbd88471 100644 --- a/drivers/soc/bcm/Kconfig +++ b/drivers/soc/bcm/Kconfig @@ -13,6 +13,14 @@ config BCM2835_POWER firmware means that Linux usage of the same power domain must be accessed using the RASPBERRYPI_POWER driver +config BCM_PMB + bool "Broadcom PMB (Power Management Bus) driver" + depends on ARCH_BCM4908 || (COMPILE_TEST && OF) + default ARCH_BCM4908 + select PM_GENERIC_DOMAINS if PM + help + Foo + config RASPBERRYPI_POWER bool "Raspberry Pi power domain driver" depends on ARCH_BCM2835 || (COMPILE_TEST && OF) diff --git a/drivers/soc/bcm/Makefile b/drivers/soc/bcm/Makefile index 7bc90e0bd773..c451ee76259f 100644 --- a/drivers/soc/bcm/Makefile +++ b/drivers/soc/bcm/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_BCM2835_POWER)+= bcm2835-power.o +obj-$(CONFIG_BCM_PMB) += bcm-pmb.o obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o obj-$(CONFIG_SOC_BCM63XX) += bcm63xx/ obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/ diff --git a/drivers/soc/bcm/bcm-pmb.c b/drivers/soc/bcm/bcm-pmb.c new file mode 100644 index ..31820e56418d --- /dev/null +++ b/drivers/soc/bcm/bcm-pmb.c @@ -0,0 +1,335 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Copyright (c) 2013 Broadcom + * Copyright (C) 2020 Rafał Miłecki + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define BPCM_ID_REG0x00 +#define BPCM_CAPABILITIES 0x04 +#define BPCM_CAP_NUM_ZONES0x00ff +#define BPCM_CAP_SR_REG_BITS 0xff00 +#define BPCM_CAP_PLLTYPE 0x0003 +#define BPCM_CAP_UBUS 0x0008 +#define BPCM_CONTROL 0x08 +#define BPCM_STATUS0x0c +#define BPCM_ROSC_CONTROL 0x10 +#define BPCM_ROSC_THRESH_H 0x14 +#define BPCM_ROSC_THRESHOLD_BCM68380x14 +#define BPCM_ROSC_THRESH_S 0x18 +#define BPCM_ROSC_COUNT_BCM68380x18 +#define BPCM_ROSC_COUNT0x1c +#define BPCM_PWD_CONTROL_BCM6838 0x1c +#define BPCM_PWD_CONTROL 0x20 +#define BPCM_SR_CONTROL_BCM68380x20 +#define BPCM_PWD_ACCUM_CONTROL 0x24 +#define BPCM_SR_CONTROL0x28 +#define BPCM_GLOBAL_CONTROL0x2c +#define BPCM_MISC_CONTROL 0x30 +#define BPCM_MISC_CONTROL2 0x34 +#define BPCM_SGPHY_CNTL0x38 +#define BPCM_SGPHY_STATUS 0x3c +#define BPCM_ZONE0 0x40 +#define BPCM_ZONE_CONTROL 0x00 +#define BPCM_ZONE_CONTROL_MANUAL_CLK_EN 0x0001 +#define BPCM_ZONE_CONTROL_MANUAL_RESET_CTL 0x0002 +#define BPCM_ZONE_CONTROL_FREQ_SCALE_USED0x0004 /* R/O */ +#define BPCM_ZONE_CONTROL_DPG_CAPABLE0x0008 /* R/O */ +#define BPCM_ZONE_CONTROL_MANUAL_MEM_PWR 0x0030 +#define BPCM_ZONE_CONTROL_MANUAL_ISO_CTL 0x0040 +#define BPCM_ZONE_CONTROL_MANUAL_CTL 0x0080 +#define BPCM_ZONE_CONTROL_DPG_CTL_EN 0x0100 +#define BPCM_ZONE_CONTROL_PWR_DN_REQ 0x0200 +#define BPCM_ZONE_CONTROL_PWR_UP_REQ 0x0400 +#define BPCM_ZONE_CONTROL_MEM_PWR_CTL_EN 0x0800 +#define BPCM_ZONE_CONTROL_BLK_RESET_ASSERT 0x1000 +#define BPCM_ZONE_CONTROL_MEM_STBY 0x2000 +#define BPCM_ZONE_CONTROL_RESERVED 0x0007c000 +#define BPCM_ZONE_CONTROL_PWR_CNTL_STATE 0x00f8 +#define BPCM_ZONE_CONTROL_FREQ_SCALAR_DYN_SEL0x0100 /* R/O */ +#define BPCM_ZONE_CONTROL_PWR_OFF_STATE 0x0200 /* R/O */ +#define BPCM_ZONE_CONTROL_PWR_ON_STATE 0x0400 /* R/O */ +
[PATCH 0/2] Broadcom's PMB (Power Management Bus) support
From: Rafał Miłecki PMB is a hardware block used for powering SoC devices like PCIe, USB, SATA. Initially I planned to treat it as a reset controller and Philipp pointed out in review that PMB driver should use a power subsystem. This is my refactored support. *** Please note one difference when compared to the initial reset attempt. As I store info about SoC devices in the driver now, I had to put support for multiple buses there. That's required to avoid things like: compatible = "brcm,bcm4908-pmb-no-1"; compatible = "brcm,bcm4908-pmb-no-2"; So now a single "reg" covers bigger buses (e.g. 0x40) in size, see: reg = <0x802800e0 0x40>; Other SoCs my use something like: reg = <0x802800e0 0x20>; reg = <0x802800e0 0x60>; *** AFAIU this should go through Florian's tree. I based in on top of the soc-arm64/next. Rafał Miłecki (2): dt-bindings: power: document Broadcom's PMB binding soc: bcm: add PM driver for Broadcom's PMB .../bindings/power/brcm,bcm-pmb.yaml | 50 +++ drivers/soc/bcm/Kconfig | 8 + drivers/soc/bcm/Makefile | 1 + drivers/soc/bcm/bcm-pmb.c | 335 ++ include/dt-bindings/soc/bcm-pmb.h | 11 + 5 files changed, 405 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml create mode 100644 drivers/soc/bcm/bcm-pmb.c create mode 100644 include/dt-bindings/soc/bcm-pmb.h -- 2.26.2
Re: [PATCH 1/2] dt-bindings: phy: Add binding for BCM4908 USB PHYs
On Wed, 2 Dec 2020 at 21:48, Rafał Miłecki wrote: > From: Rafał Miłecki > > BCM4908 SoCs have USB 2.0 PHY and USB 3.0 PHY attached to the MDIO bus. > Those bindings allow describing them. > > Signed-off-by: Rafał Miłecki Please drop this patchset for now as Florian pointed that the existing driver may be adapted / reused for those PHYs.
Re: [PATCH 2/2] reset: bcm4908-usb: add driver for BCM4908 USB reset controller
On 04.12.2020 17:38, Florian Fainelli wrote: On 12/4/2020 1:37 AM, Rafał Miłecki wrote: From: Rafał Miłecki This controller is responsible for OHCI, EHCI, XHCI and PHYs setup that has to be handled in the proper order. One unusual thing about this controller is that is provides access to the MDIO bus. There are two registers (in the middle of block space) responsible for that. For that reason this driver initializes regmap so a proper MDIO driver can use them. Signed-off-by: Rafał Miłecki --- [snip] + +#define BCM4908_USB_RESET_SETUP 0x +#define BCM4908_USBH_IPP (1<<5) +#define BCM4908_USBH_IOC (1<<4) +#define BCM4908_USB2_OC_DISABLE_PORT0 (1<<28) +#define BCM4908_USB2_OC_DISABLE_PORT1 (1<<29) +#define BCM4908_USB3_OC_DISABLE_PORT0 (1<<30) +#define BCM4908_USB3_OC_DISABLE_PORT1 (1<<31) +#define BCM4908_USB_RESET_PLL_CTL 0x0004 +#define BCM4908_USB_RESET_FLADJ_VALUE 0x0008 +#define BCM4908_USB_RESET_BRIDGE_CTL 0x000c +#define BCM4908_USB_RESET_SPARE1 0x0010 +#define BCM4908_USB_RESET_MDIO 0x0014 +#define BCM4908_USB_RESET_MDIO2 0x0018 +#define BCM4908_USB_RESET_TEST_PORT_CONTROL0x001c +#define BCM4908_USB_RESET_USB_SIMCTL 0x0020 +#define BCM4908_USBH_OHCI_MEM_REQ_DIS (1<<1) +#define BCM4908_USB_RESET_USB_TESTCTL 0x0024 +#define BCM4908_USB_RESET_USB_TESTMON 0x0028 +#define BCM4908_USB_RESET_UTMI_CTL_1 0x002c +#define BCM4908_USB_RESET_SPARE2 0x0030 +#define BCM4908_USB_RESET_USB_PM 0x0034 +#define BCM4908_XHC_SOFT_RESETB (1<<22) +#define BCM4908_USB_PWRDWN(1<<31) +#define BCM4908_USB_RESET_USB_PM_STATUS 0x0038 +#define BCM4908_USB_RESET_SPARE3 0x003c +#define BCM4908_USB_RESET_PLL_LDO_CTL 0x0040 +#define BCM4908_USB_RESET_PLL_LDO_PLLBIAS 0x0044 +#define BCM4908_USB_RESET_PLL_AFE_BG_CNTL 0x0048 +#define BCM4908_USB_RESET_AFE_USBIO_TST 0x004c +#define BCM4908_USB_RESET_PLL_NDIV_FRAC 0x0050 +#define BCM4908_USB_RESET_TP_DIAG 0x0054 +#define BCM4908_USB_RESET_AHB_CAPTURE_FIFO 0x0058 +#define BCM4908_USB_RESET_SPARE4 0x005c +#define BCM4908_USB_RESET_USB30_CTL1 0x0060 +#define BCM4908_PHY3_PLL_SEQ_START(1<<4) +#define BCM4908_USB_RESET_USB30_CTL2 0x0064 +#define BCM4908_USB_RESET_USB30_CTL3 0x0068 +#define BCM4908_USB_RESET_USB30_CTL4 0x006c +#define BCM4908_USB_RESET_USB30_PCTL 0x0070 +#define BCM4908_USB_RESET_USB30_CTL5 0x0074 +#define BCM4908_USB_RESET_SPARE5 0x0078 +#define BCM4908_USB_RESET_SPARE6 0x007c +#define BCM4908_USB_RESET_SPARE7 0x0080 +#define BCM4908_USB_RESET_USB_DEVICE_CTL1 0x0090 +#define BCM4908_USB_RESET_USB_DEVICE_CTL2 0x0094 +#define BCM4908_USB_RESET_USB20_ID 0x0150 +#define BCM4908_USB_RESET_USB30_ID 0x0154 +#define BCM4908_USB_RESET_BDC_COREID 0x0158 +#define BCM4908_USB_RESET_USB_REVID0x015c This register layout is nearly identical to the one described under drivers/phy/broadcom/phy-brcm-usb-init.c and this is because within Broadcom the same design group has been supplying the USB PHY and host controllers to the DSL and STB product lines. I would model this the same way we have done it for the Broadcom STB HCI drivers and add a separate compatible string along with an optional reset line. As far as MDIO goes as you can see the USB PHY driver uses a mix of memory mappe
Re: [PATCH 1/2] dt-bindings: reset: document Broadcom's BCM4908 USB reset binding
On 04.12.2020 17:32, Florian Fainelli wrote:
On 12/4/2020 1:37 AM, Rafał Miłecki wrote:
From: Rafał Miłecki
Document binding of block responsible for initializing USB controllers
(OHCI, EHCI, XHCI).
Signed-off-by: Rafał Miłecki
---
.../reset/brcm,bcm4908-usb-reset.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/brcm,bcm4908-usb-reset.yaml
diff --git
a/Documentation/devicetree/bindings/reset/brcm,bcm4908-usb-reset.yaml
b/Documentation/devicetree/bindings/reset/brcm,bcm4908-usb-reset.yaml
new file mode 100644
index ..31beb1c8f3cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm4908-usb-reset.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/brcm,bcm4908-usb-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 USB host controller reset
+
+description: >
+ BCM4908 has a separated block controlling all USB controllers. It handles the
+ whole setup process and takes care of initializing PHYs at the right time
+ (state).
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm4908-usb-reset
+
+ reg:
+maxItems: 1
+
+ resets:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+ phys:
+minItems: 2
+maxItems: 2
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+ phy-names:
+items:
+ - const: usb2
+ - const: usb3
+
+ "#reset-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - phys
+ - phy-names
+ - "#reset-cells"
+
+additionalProperties: true
+
+examples:
+ - |
+reset-controller@8000c200 {
+compatible = "brcm,bcm4908-usb-reset";
+reg = <0x8000c200 0x100>;
+
+phys = <_phy>, <_phy>;
+phy-names = "usb2", "usb3";
This looks quite unusual, usually the *HCI controllers would be
consumers of the PHY and the PHY may be a consumer of the reset controller.
(still going through my emails have not fully read your separate email
on the topic, so pardon me if this is being discussed twice).
I agree, it's the the best solution I found for this specific design.
This specific hw block perform various operations before, in the middle and
after PHY initialization. That made me make reset controlller initialize PHYs.
I'm happy to implement a more proper design if someone can just suggest how.
I don't have any better idea :(
Re: [PATCH 2/2] reset: bcm4908-usb: add driver for BCM4908 USB reset controller
On Fri, 4 Dec 2020 at 17:13, Philipp Zabel wrote:
> On Fri, 2020-12-04 at 10:37 +0100, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > This controller is responsible for OHCI, EHCI, XHCI and PHYs setup that
> > has to be handled in the proper order.
> >
> > One unusual thing about this controller is that is provides access to
> > the MDIO bus. There are two registers (in the middle of block space)
> > responsible for that. For that reason this driver initializes regmap so
> > a proper MDIO driver can use them.
> >
> > Signed-off-by: Rafał Miłecki
>
> This doesn't look like a reset controller to me, but rather like
> something that belongs in drivers/usb.
I think I found the reset API to match the best setup requirements and
assumed it should be treated as a reset controller.
Any advice, idea, how should I integrate this driver with the USB
subsystem? Rested made it easy as all I needed was:
usb@c300 {
compatible = "generic-ehci";
reg = <0xc300 0x100>;
interrupts = ;
resets = <_reset>;
};
--
Rafał
