This should be considered a dirty hack. The proper solution would be
extracting write_reg logic to a separate regmap driver. Leaving only
"write BIT(2) to address 0x6" to the PHY driver.
The initial commit is already doing things wrong. The following patches
adding hi3798mv100 support is also very confusing. The name of the
enumeration "PHY_TYPE_x" is very misleading as if it's the phy which is
different across SoCs. But actually it's the bus (i.e. how to write to a
given address) which is different, not the PHY.
Signed-off-by: Yang Xiwen <[email protected]>
---
Changes in v3:
- address a few binding issue mistakenly missing in v2 (Krzysztof Kozlowski)
- add msg about hi3798mv100 being added to compatible list
- remove minItems for compatible
- remove | for reg:
- fix existing dts (hi3798cv200.dtsi) due to binding change.
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- rewrite commit msg to show why hisilicon,hi3798mv100-usb2-phy is added during YAML convertion.
- split required: to multiple line
- add allOf to wrap if:
- remove perictrl wrapper and the second phy in the example
- tested the binding both for mv200 and cv200 dts. fix some silly errors.
- remove Pengcheng Li from To:
Above all are suggested by Krzysztof
- use reset_control_array_* APIs to ensure all resets are controlled
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Yang Xiwen (5):
dt-bindings: phy: hisi-inno-usb2: convert to YAML
arm64: dts: hi3798cv200: add hisilicon,inno-usb2-phy to compatible list
phy: hisilicon: hisi-inno-phy: enable clocks for every ports
phy: hisilicon: hisi-inno-phy: add support for Hi3798MV200 INNO PHY
dt-bindings: phy: hisi-inno-usb2: add compatible of hisilicon,hi3798mv200-usb2-phy
.../bindings/phy/hisilicon,inno-usb2-phy.yaml | 123 +++++++++++++++++++++
.../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ------------
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 6 +-
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 69 +++++++-----
4 files changed, 169 insertions(+), 100 deletions(-)
---
base-commit: 8d3dea210042f54b952b481838c1e7dfc4ec751d
change-id: 20240216-inno-phy-a2d872f6b74b
Best regards,
--
Yang Xiwen <[email protected]>
From: Yang Xiwen <[email protected]>
Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
list due to prior driver change.
Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
compatible lists.
Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
Signed-off-by: Yang Xiwen <[email protected]>
---
.../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
.../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
2 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
new file mode 100644
index 000000000000..1b57e0396209
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon HiSTB SoCs INNO USB2 PHY device
+
+maintainers:
+ - Yang Xiwen <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - hisilicon,hi3798cv200-usb2-phy
+ - hisilicon,hi3798mv100-usb2-phy
+ - const: hisilicon,inno-usb2-phy
+
+ reg:
+ maxItems: 1
+ description: Should be the address space for PHY configuration register in
+ peripheral controller, e.g. PERI_USB0 for USB 2.0 PHY01 on Hi3798CV200 SoC,
+ or direct MMIO address space.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ clocks:
+ maxItems: 1
+ description: reference clock
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ 'phy@[0-9a-f]+':
+ type: object
+ additionalProperties: false
+ description: individual ports provided by INNO PHY
+
+ properties:
+ reg:
+ maxItems: 1
+ descrption: should be the port index (if under a perictrl node)
+ or port address space
+
+ '#phy-cells':
+ const: 0
+
+ resets:
+ maxItems: 1
+
+ required:
+ - reg
+ - '#phy-cells'
+ - resets
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/histb-clock.h>
+
+ usb2-phy@120 {
+ compatible = "hisilicon,hi3798cv200-usb2-phy", "hisilicon,inno-usb2-phy";
+ reg = <0x120 0x4>;
+ clocks = <&crg HISTB_USB2_PHY1_REF_CLK>;
+ resets = <&crg 0xbc 4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ resets = <&crg 0xbc 8>;
+ };
+
+ phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ resets = <&crg 0xbc 9>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
deleted file mode 100644
index 104953e849e7..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Device tree bindings for HiSilicon INNO USB2 PHY
-
-Required properties:
-- compatible: Should be one of the following strings:
- "hisilicon,inno-usb2-phy",
- "hisilicon,hi3798cv200-usb2-phy".
-- reg: Should be the address space for PHY configuration register in peripheral
- controller, e.g. PERI_USB0 for USB 2.0 PHY01 on Hi3798CV200 SoC.
-- clocks: The phandle and clock specifier pair for INNO USB2 PHY device
- reference clock.
-- resets: The phandle and reset specifier pair for INNO USB2 PHY device reset
- signal.
-- #address-cells: Must be 1.
-- #size-cells: Must be 0.
-
-The INNO USB2 PHY device should be a child node of peripheral controller that
-contains the PHY configuration register, and each device supports up to 2 PHY
-ports which are represented as child nodes of INNO USB2 PHY device.
-
-Required properties for PHY port node:
-- reg: The PHY port instance number.
-- #phy-cells: Defined by generic PHY bindings. Must be 0.
-- resets: The phandle and reset specifier pair for PHY port reset signal.
-
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
-
-perictrl: peripheral-controller@8a20000 {
- compatible = "hisilicon,hi3798cv200-perictrl", "simple-mfd";
- reg = <0x8a20000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x8a20000 0x1000>;
-
- usb2_phy1: usb2-phy@120 {
- compatible = "hisilicon,hi3798cv200-usb2-phy";
- reg = <0x120 0x4>;
- clocks = <&crg HISTB_USB2_PHY1_REF_CLK>;
- resets = <&crg 0xbc 4>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb2_phy1_port0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 8>;
- };
-
- usb2_phy1_port1: phy@1 {
- reg = <1>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 9>;
- };
- };
-
- usb2_phy2: usb2-phy@124 {
- compatible = "hisilicon,hi3798cv200-usb2-phy";
- reg = <0x124 0x4>;
- clocks = <&crg HISTB_USB2_PHY2_REF_CLK>;
- resets = <&crg 0xbc 6>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb2_phy2_port0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 10>;
- };
- };
-};
--
2.43.0
From: Yang Xiwen <[email protected]>
Direct MMIO resgiter access is used by Hi3798MV200. For other models,
of_iomap() returns 0 due to insufficient length. So they are unaffected.
Also Hi3798MV200 INNO PHY has an extra reset required to be deasserted,
switch to reset_control_bulk_() APIs to resolve this.
Signed-off-by: Yang Xiwen <[email protected]>
---
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 65 ++++++++++++++++++------------
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
index b7e740eb4752..5175e5a351ac 100644
--- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
+++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
@@ -10,6 +10,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/reset.h>
@@ -43,6 +44,7 @@
#define PHY_CLK_ENABLE BIT(2)
struct hisi_inno_phy_port {
+ void __iomem *base;
struct reset_control *utmi_rst;
struct hisi_inno_phy_priv *priv;
};
@@ -50,7 +52,7 @@ struct hisi_inno_phy_port {
struct hisi_inno_phy_priv {
void __iomem *mmio;
struct clk *ref_clk;
- struct reset_control *por_rst;
+ struct reset_control *rsts;
unsigned int type;
struct hisi_inno_phy_port ports[INNO_PHY_PORT_NUM];
};
@@ -62,26 +64,31 @@ static void hisi_inno_phy_write_reg(struct hisi_inno_phy_priv *priv,
u32 val;
u32 value;
- if (priv->type == PHY_TYPE_0)
- val = (data & PHY_TEST_DATA) |
- ((addr << PHY_TEST_ADDR_OFFSET) & PHY0_TEST_ADDR) |
- ((port << PHY0_TEST_PORT_OFFSET) & PHY0_TEST_PORT) |
- PHY0_TEST_WREN | PHY0_TEST_RST;
- else
- val = (data & PHY_TEST_DATA) |
- ((addr << PHY_TEST_ADDR_OFFSET) & PHY1_TEST_ADDR) |
- ((port << PHY1_TEST_PORT_OFFSET) & PHY1_TEST_PORT) |
- PHY1_TEST_WREN | PHY1_TEST_RST;
- writel(val, reg);
-
- value = val;
- if (priv->type == PHY_TYPE_0)
- value |= PHY0_TEST_CLK;
- else
- value |= PHY1_TEST_CLK;
- writel(value, reg);
-
- writel(val, reg);
+ if (priv->ports[port].base)
+ // stride is 4
+ writel(data, (u32 *)priv->ports[port].base + addr);
+ else {
+ if (priv->type == PHY_TYPE_0)
+ val = (data & PHY_TEST_DATA) |
+ ((addr << PHY_TEST_ADDR_OFFSET) & PHY0_TEST_ADDR) |
+ ((port << PHY0_TEST_PORT_OFFSET) & PHY0_TEST_PORT) |
+ PHY0_TEST_WREN | PHY0_TEST_RST;
+ else
+ val = (data & PHY_TEST_DATA) |
+ ((addr << PHY_TEST_ADDR_OFFSET) & PHY1_TEST_ADDR) |
+ ((port << PHY1_TEST_PORT_OFFSET) & PHY1_TEST_PORT) |
+ PHY1_TEST_WREN | PHY1_TEST_RST;
+ writel(val, reg);
+
+ value = val;
+ if (priv->type == PHY_TYPE_0)
+ value |= PHY0_TEST_CLK;
+ else
+ value |= PHY1_TEST_CLK;
+ writel(value, reg);
+
+ writel(val, reg);
+ }
}
static void hisi_inno_phy_setup(struct hisi_inno_phy_priv *priv)
@@ -104,7 +111,7 @@ static int hisi_inno_phy_init(struct phy *phy)
return ret;
udelay(REF_CLK_STABLE_TIME);
- reset_control_deassert(priv->por_rst);
+ reset_control_deassert(priv->rsts);
udelay(POR_RST_COMPLETE_TIME);
/* Set up phy registers */
@@ -122,7 +129,7 @@ static int hisi_inno_phy_exit(struct phy *phy)
struct hisi_inno_phy_priv *priv = port->priv;
reset_control_assert(port->utmi_rst);
- reset_control_assert(priv->por_rst);
+ reset_control_assert(priv->rsts);
clk_disable_unprepare(priv->ref_clk);
return 0;
@@ -158,15 +165,16 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
if (IS_ERR(priv->ref_clk))
return PTR_ERR(priv->ref_clk);
- priv->por_rst = devm_reset_control_get_exclusive(dev, NULL);
- if (IS_ERR(priv->por_rst))
- return PTR_ERR(priv->por_rst);
+ priv->rsts = devm_reset_control_array_get(dev, false, false);
+ if (IS_ERR(priv->rsts))
+ return PTR_ERR(priv->rsts);
priv->type = (uintptr_t) of_device_get_match_data(dev);
for_each_child_of_node(np, child) {
struct reset_control *rst;
struct phy *phy;
+ void __iomem *base;
rst = of_reset_control_get_exclusive(child, NULL);
if (IS_ERR(rst)) {
@@ -174,7 +182,10 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
return PTR_ERR(rst);
}
+ base = of_iomap(child, 0);
+
priv->ports[i].utmi_rst = rst;
+ priv->ports[i].base = base;
priv->ports[i].priv = priv;
phy = devm_phy_create(dev, child, &hisi_inno_phy_ops);
@@ -205,6 +216,8 @@ static const struct of_device_id hisi_inno_phy_of_match[] = {
.data = (void *) PHY_TYPE_0 },
{ .compatible = "hisilicon,hi3798mv100-usb2-phy",
.data = (void *) PHY_TYPE_1 },
+ { .compatible = "hisilicon,hi3798mv200-usb2-phy",
+ .data = (void *) PHY_TYPE_0 },
{ },
};
MODULE_DEVICE_TABLE(of, hisi_inno_phy_of_match);
--
2.43.0
From: Yang Xiwen <[email protected]>
This is needed for port1 to work.
Fixes: ba8b0ee81fbb ("phy: add inno-usb2-phy driver for hi3798cv200 SoC")
Signed-off-by: Yang Xiwen <[email protected]>
---
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
index c138cd4807d6..b7e740eb4752 100644
--- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
+++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
@@ -86,8 +86,10 @@ static void hisi_inno_phy_write_reg(struct hisi_inno_phy_priv *priv,
static void hisi_inno_phy_setup(struct hisi_inno_phy_priv *priv)
{
+ int i;
/* The phy clk is controlled by the port0 register 0x06. */
- hisi_inno_phy_write_reg(priv, 0, 0x06, PHY_CLK_ENABLE);
+ for (i = 0; i < INNO_PHY_PORT_NUM; i++)
+ hisi_inno_phy_write_reg(priv, i, 0x06, PHY_CLK_ENABLE);
msleep(PHY_CLK_STABLE_TIME);
}
--
2.43.0
From: Yang Xiwen <[email protected]>
It is accessed by direct MMIO, making "ranges" property mandatory for
it. Also there is an extra clock for the phy.
Signed-off-by: Yang Xiwen <[email protected]>
---
.../bindings/phy/hisilicon,inno-usb2-phy.yaml | 32 ++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
index 1b57e0396209..969fd3fb7537 100644
--- a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
@@ -15,6 +15,7 @@ properties:
- enum:
- hisilicon,hi3798cv200-usb2-phy
- hisilicon,hi3798mv100-usb2-phy
+ - hisilicon,hi3798mv200-usb2-phy
- const: hisilicon,inno-usb2-phy
reg:
@@ -23,18 +24,27 @@ properties:
peripheral controller, e.g. PERI_USB0 for USB 2.0 PHY01 on Hi3798CV200 SoC,
or direct MMIO address space.
+ ranges:
+ maxItems: 1
+
'#address-cells':
const: 1
'#size-cells':
- const: 0
+ enum: [0, 1]
clocks:
maxItems: 1
description: reference clock
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: port
+ - const: test
patternProperties:
'phy@[0-9a-f]+':
@@ -54,6 +64,9 @@ patternProperties:
resets:
maxItems: 1
+ phy_type:
+ const: utmi
+
required:
- reg
- '#phy-cells'
@@ -67,6 +80,21 @@ required:
- '#size-cells'
- resets
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: hisilicon,hi3798mv200-usb2-phy
+ then:
+ required:
+ - ranges
+ - reset-names
+ else:
+ properties:
+ ranges: false
+ reset-names: false
+
additionalProperties: false
examples:
--
2.43.0
On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <[email protected]>
>
> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
> list due to prior driver change.
>
> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
> compatible lists.
>
> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
I don't understand what is the bug being fixed here. Binding being in
TXT is not a bug.
This wasn't here before and I did not ask to add it.
Best regards,
Krzysztof
On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <[email protected]>
>
> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
> list due to prior driver change.
>
> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
> compatible lists.
>
> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
> Signed-off-by: Yang Xiwen <[email protected]>
> ---
> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
> 2 files changed, 95 insertions(+), 71 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
> new file mode 100644
> index 000000000000..1b57e0396209
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
> @@ -0,0 +1,95 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
> +
> +maintainers:
> + - Yang Xiwen <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - hisilicon,hi3798cv200-usb2-phy
> + - hisilicon,hi3798mv100-usb2-phy
> + - const: hisilicon,inno-usb2-phy
According to your driver hisilicon,hi3798mv100-usb2-phy and
hisilicon,inno-usb2-phy are not compatible.
This is confusing.
Best regards,
Krzysztof
On 19/02/2024 22:28, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <[email protected]>
>
> Direct MMIO resgiter access is used by Hi3798MV200. For other models,
> of_iomap() returns 0 due to insufficient length. So they are unaffected.
>
> Also Hi3798MV200 INNO PHY has an extra reset required to be deasserted,
> switch to reset_control_bulk_() APIs to resolve this.
>
> Signed-off-by: Yang Xiwen <[email protected]>
> ---
> drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 65 ++++++++++++++++++------------
> 1 file changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> index b7e740eb4752..5175e5a351ac 100644
> --- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> +++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> @@ -10,6 +10,7 @@
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> @@ -43,6 +44,7 @@
> #define PHY_CLK_ENABLE BIT(2)
>
> struct hisi_inno_phy_port {
> + void __iomem *base;
> struct reset_control *utmi_rst;
> struct hisi_inno_phy_priv *priv;
> };
> @@ -50,7 +52,7 @@ struct hisi_inno_phy_port {
> struct hisi_inno_phy_priv {
> void __iomem *mmio;
> struct clk *ref_clk;
> - struct reset_control *por_rst;
> + struct reset_control *rsts;
This does not look related to this patch at all.
> unsigned int type;
> struct hisi_inno_phy_port ports[INNO_PHY_PORT_NUM];
> };
Best regards,
Krzysztof
On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>> From: Yang Xiwen <[email protected]>
>>
>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>> list due to prior driver change.
>>
>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>> compatible lists.
>>
>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>> Signed-off-by: Yang Xiwen <[email protected]>
>> ---
>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>> new file mode 100644
>> index 000000000000..1b57e0396209
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>> @@ -0,0 +1,95 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>> +
>> +maintainers:
>> + - Yang Xiwen <[email protected]>
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - hisilicon,hi3798cv200-usb2-phy
>> + - hisilicon,hi3798mv100-usb2-phy
>> + - const: hisilicon,inno-usb2-phy
> According to your driver hisilicon,hi3798mv100-usb2-phy and
> hisilicon,inno-usb2-phy are not compatible.
Ah, i didn't pay too much attention to that. I should remove the entry
for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>
> This is confusing.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 19/02/2024 22:28, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <[email protected]>
>
> It is accessed by direct MMIO, making "ranges" property mandatory for
> it. Also there is an extra clock for the phy.
>
> Signed-off-by: Yang Xiwen <[email protected]>
> ---
> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 32 ++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
> index 1b57e0396209..969fd3fb7537 100644
> --- a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
> @@ -15,6 +15,7 @@ properties:
> - enum:
> - hisilicon,hi3798cv200-usb2-phy
> - hisilicon,hi3798mv100-usb2-phy
> + - hisilicon,hi3798mv200-usb2-phy
> - const: hisilicon,inno-usb2-phy
Bindings come before user, not after (see DT submitting patches).
Anyway, your driver and commit msg say hi3798mv200 has different
programming model, so these devices are not compatible.
Best regards,
Krzysztof
On 19/02/2024 22:33, Yang Xiwen wrote:
> On 2/20/2024 5:30 AM, Krzysztof Kozlowski wrote:
>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>> From: Yang Xiwen <[email protected]>
>>>
>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>> list due to prior driver change.
>>>
>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>> compatible lists.
>>>
>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>> I don't understand what is the bug being fixed here. Binding being in
>> TXT is not a bug.
> This commit adds the compatible "hisilicon,hi3798mv100-usb2-phy" to the
> driver, but binding change is left alone.
Then this patch is not a correct fix. It does something else then adding
missing compatible. Remember that one commit is one logical change.
Best regards,
Krzysztof
On 19/02/2024 22:35, Yang Xiwen wrote:
> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>> From: Yang Xiwen <[email protected]>
>>>
>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>> list due to prior driver change.
>>>
>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>> compatible lists.
>>>
>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>> Signed-off-by: Yang Xiwen <[email protected]>
>>> ---
>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>> new file mode 100644
>>> index 000000000000..1b57e0396209
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>> @@ -0,0 +1,95 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>> +
>>> +maintainers:
>>> + - Yang Xiwen <[email protected]>
>>> +
>>> +properties:
>>> + compatible:
>>> + items:
>>> + - enum:
>>> + - hisilicon,hi3798cv200-usb2-phy
>>> + - hisilicon,hi3798mv100-usb2-phy
>>> + - const: hisilicon,inno-usb2-phy
>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>> hisilicon,inno-usb2-phy are not compatible.
> Ah, i didn't pay too much attention to that. I should remove the entry
> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
We don't talk here about driver, although I used the driver as proof or
argument, because I don't have access to hardware datasheet (and no
intention to look there).
What I claim is these are not compatible, so respond to this argument,
not some other one.
Best regards,
Krzysztof
On 2/20/2024 5:34 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:28, Yang Xiwen via B4 Relay wrote:
>> From: Yang Xiwen <[email protected]>
>>
>> Direct MMIO resgiter access is used by Hi3798MV200. For other models,
>> of_iomap() returns 0 due to insufficient length. So they are unaffected.
>>
>> Also Hi3798MV200 INNO PHY has an extra reset required to be deasserted,
>> switch to reset_control_bulk_() APIs to resolve this.
>>
>> Signed-off-by: Yang Xiwen <[email protected]>
>> ---
>> drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 65 ++++++++++++++++++------------
>> 1 file changed, 39 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
>> index b7e740eb4752..5175e5a351ac 100644
>> --- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
>> +++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
>> @@ -10,6 +10,7 @@
>> #include <linux/io.h>
>> #include <linux/module.h>
>> #include <linux/of.h>
>> +#include <linux/of_address.h>
>> #include <linux/phy/phy.h>
>> #include <linux/platform_device.h>
>> #include <linux/reset.h>
>> @@ -43,6 +44,7 @@
>> #define PHY_CLK_ENABLE BIT(2)
>>
>> struct hisi_inno_phy_port {
>> + void __iomem *base;
>> struct reset_control *utmi_rst;
>> struct hisi_inno_phy_priv *priv;
>> };
>> @@ -50,7 +52,7 @@ struct hisi_inno_phy_port {
>> struct hisi_inno_phy_priv {
>> void __iomem *mmio;
>> struct clk *ref_clk;
>> - struct reset_control *por_rst;
>> + struct reset_control *rsts;
> This does not look related to this patch at all.
I should emphasize this in commit log. Hi3798MV200 have two resets
rather than one. To make things easier, I simply used
reset_control_array APIs instead.
>
>> unsigned int type;
>> struct hisi_inno_phy_port ports[INNO_PHY_PORT_NUM];
>> };
>
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 2/20/2024 5:30 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>> From: Yang Xiwen <[email protected]>
>>
>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>> list due to prior driver change.
>>
>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>> compatible lists.
>>
>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
> I don't understand what is the bug being fixed here. Binding being in
> TXT is not a bug.
This commit adds the compatible "hisilicon,hi3798mv100-usb2-phy" to the
driver, but binding change is left alone.
>
> This wasn't here before and I did not ask to add it.
>
>
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:35, Yang Xiwen wrote:
>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>> From: Yang Xiwen <[email protected]>
>>>>
>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>> list due to prior driver change.
>>>>
>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>> compatible lists.
>>>>
>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>> ---
>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>> new file mode 100644
>>>> index 000000000000..1b57e0396209
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>> @@ -0,0 +1,95 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>> +
>>>> +maintainers:
>>>> + - Yang Xiwen <[email protected]>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + items:
>>>> + - enum:
>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>> + - const: hisilicon,inno-usb2-phy
>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>> hisilicon,inno-usb2-phy are not compatible.
>> Ah, i didn't pay too much attention to that. I should remove the entry
>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
> We don't talk here about driver, although I used the driver as proof or
> argument, because I don't have access to hardware datasheet (and no
> intention to look there).
>
> What I claim is these are not compatible, so respond to this argument,
> not some other one.
Why not? Of course they are compatible. All 3 SoCs are using
inno-usb2-phy. The only difference here is the method to access the
registers. They are all enabled by `writing BIT(2) to address 0x6`. In
the cover letter, I said the driver is actually doing things wrong.
Especially the commit adding PHY_TYPE enums, the name is confusing and
conveys the wrong info. It's not PHY which are not compatible, it's the
bus. I'll fix the driver, but still the PHY hardwares are compatible
between these 3 SoCs.
I'll say the driver is broken from the beginning. They should move
write_reg function to a separate regmap driver and only left `write
BIT(2) to addr 0x6` to the PHY driver.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 2/20/2024 5:36 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:33, Yang Xiwen wrote:
>> On 2/20/2024 5:30 AM, Krzysztof Kozlowski wrote:
>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>> From: Yang Xiwen <[email protected]>
>>>>
>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>> list due to prior driver change.
>>>>
>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>> compatible lists.
>>>>
>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>> I don't understand what is the bug being fixed here. Binding being in
>>> TXT is not a bug.
>> This commit adds the compatible "hisilicon,hi3798mv100-usb2-phy" to the
>> driver, but binding change is left alone.
> Then this patch is not a correct fix. It does something else then adding
> missing compatible. Remember that one commit is one logical change.
Okay, that's fine. I'll break them into 2 patches.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On Tue, 20 Feb 2024 05:27:58 +0800, Yang Xiwen wrote:
> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
> list due to prior driver change.
>
> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
> compatible lists.
>
> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
> Signed-off-by: Yang Xiwen <[email protected]>
> ---
> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
> 2 files changed, 95 insertions(+), 71 deletions(-)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml: patternProperties:phy@[0-9a-f]+:properties:reg: 'anyOf' conditional failed, one must be fixed:
'descrption' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems']
'type' was expected
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml: patternProperties:phy@[0-9a-f]+:properties:reg: 'anyOf' conditional failed, one must be fixed:
'descrption' is not one of ['maxItems', 'description', 'deprecated']
hint: Only "maxItems" is required for a single entry if there are no constraints defined for the values.
Additional properties are not allowed ('descrption' was unexpected)
hint: Arrays must be described with a combination of minItems/maxItems/items
'maxItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf']
'descrption' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf']
1 is less than the minimum of 2
hint: Arrays must be described with a combination of minItems/maxItems/items
hint: cell array properties must define how many entries and what the entries are when there is more than one entry.
from schema $id: http://devicetree.org/meta-schemas/core.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
On 19/02/2024 22:49, Yang Xiwen wrote:
> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>> From: Yang Xiwen <[email protected]>
>>>>>
>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>> list due to prior driver change.
>>>>>
>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>> compatible lists.
>>>>>
>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>> ---
>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..1b57e0396209
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>> @@ -0,0 +1,95 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>> +
>>>>> +maintainers:
>>>>> + - Yang Xiwen <[email protected]>
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + items:
>>>>> + - enum:
>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>> + - const: hisilicon,inno-usb2-phy
>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>> hisilicon,inno-usb2-phy are not compatible.
>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>> We don't talk here about driver, although I used the driver as proof or
>> argument, because I don't have access to hardware datasheet (and no
>> intention to look there).
>>
>> What I claim is these are not compatible, so respond to this argument,
>> not some other one.
>
> Why not? Of course they are compatible. All 3 SoCs are using
Why? Because...
> inno-usb2-phy. The only difference here is the method to access the
.. here! Different programming interface means not compatible.
Please provide instead any argument that they are compatible, in the
meaning of Devicetree of course. You are claiming inno-usb2-phy can be
used for hi3798mv100 and it will work fine?
> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
> the cover letter, I said the driver is actually doing things wrong.
Cover letter does not matter, I don't even read them. Your commits matter.
> Especially the commit adding PHY_TYPE enums, the name is confusing and
> conveys the wrong info. It's not PHY which are not compatible, it's the
> bus. I'll fix the driver, but still the PHY hardwares are compatible
> between these 3 SoCs.
Provide any argument.
>
> I'll say the driver is broken from the beginning. They should move
> write_reg function to a separate regmap driver and only left `write
> BIT(2) to addr 0x6` to the PHY driver.
>
Best regards,
Krzysztof
On 19/02/2024 22:28, Yang Xiwen via B4 Relay wrote:
>
> resets:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: port
> + - const: test
Why old device now gets two resets? You need to constrain it per variant.
Best regards,
Krzysztof
On 2/20/2024 4:18 PM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:28, Yang Xiwen via B4 Relay wrote:
>>
>> resets:
>> - maxItems: 1
>> + minItems: 1
>> + maxItems: 2
>> +
>> + reset-names:
>> + items:
>> + - const: port
>> + - const: test
> Why old device now gets two resets? You need to constrain it per variant.
I only make reset-names mandatory for mv200. For other models, this
property is not allowed. I'll add constraint for resets too in next version.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
> On 19/02/2024 22:49, Yang Xiwen wrote:
>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>
>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>> list due to prior driver change.
>>>>>>
>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>> compatible lists.
>>>>>>
>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>> ---
>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..1b57e0396209
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>> @@ -0,0 +1,95 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Yang Xiwen <[email protected]>
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + items:
>>>>>> + - enum:
>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>> We don't talk here about driver, although I used the driver as proof or
>>> argument, because I don't have access to hardware datasheet (and no
>>> intention to look there).
>>>
>>> What I claim is these are not compatible, so respond to this argument,
>>> not some other one.
>> Why not? Of course they are compatible. All 3 SoCs are using
> Why? Because...
>
>> inno-usb2-phy. The only difference here is the method to access the
> ... here! Different programming interface means not compatible.
>
> Please provide instead any argument that they are compatible, in the
> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
> used for hi3798mv100 and it will work fine?
>
>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>> the cover letter, I said the driver is actually doing things wrong.
> Cover letter does not matter, I don't even read them. Your commits matter.
>
>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>> conveys the wrong info. It's not PHY which are not compatible, it's the
>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>> between these 3 SoCs.
> Provide any argument.
Just take a look at the driver. hisi_inno_phy_write_reg() is the
function that differs between different models. But for all of them,
hisi_inno_phy_setup() is the same.
hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
bus-related, not phy. PHY driver should not care how to access the bus,
but the bus driver should. The PHY driver only needs to use regmap_*
APIs to "write BIT(2) to addr 6".
For mv100 and cv200, the PHY master bus interface is attached to the
perictrl core in SoC (though the perictrl core provides slightly
different register offsets to access the PHY bus). For mv200, it is
directly attached to AHB/APB system bus so we don't need to put it under
a perictrl node anymore. So here, clearly it's the bus the PHY attached
to which is different, not the PHY itself.
That's why i say the driver is wrong from the beginning. It's mixing PHY
driver and bus driver together but they ought to be different. PHY is
always compatible, but the bus is not.
The correct fix should be moving hisi_inno_phy_write_reg() to a new bus
driver and migrating to regmap_* APIs in PHY driver. But i'll have to
write a new driver for that, which i try to avoid (it takes too much
time!). So i said clearly in the cover-letter this should be considered
a hack.
>
>> I'll say the driver is broken from the beginning. They should move
>> write_reg function to a separate regmap driver and only left `write
>> BIT(2) to addr 0x6` to the PHY driver.
>>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 20/02/2024 11:40, Yang Xiwen wrote:
> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>
>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>> list due to prior driver change.
>>>>>>>
>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>> compatible lists.
>>>>>>>
>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>> ---
>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..1b57e0396209
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>> @@ -0,0 +1,95 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>> +
>>>>>>> +properties:
>>>>>>> + compatible:
>>>>>>> + items:
>>>>>>> + - enum:
>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>> We don't talk here about driver, although I used the driver as proof or
>>>> argument, because I don't have access to hardware datasheet (and no
>>>> intention to look there).
>>>>
>>>> What I claim is these are not compatible, so respond to this argument,
>>>> not some other one.
>>> Why not? Of course they are compatible. All 3 SoCs are using
>> Why? Because...
>>
>>> inno-usb2-phy. The only difference here is the method to access the
>> ... here! Different programming interface means not compatible.
>>
>> Please provide instead any argument that they are compatible, in the
>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>> used for hi3798mv100 and it will work fine?
>>
>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>> the cover letter, I said the driver is actually doing things wrong.
>> Cover letter does not matter, I don't even read them. Your commits matter.
>>
>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>> between these 3 SoCs.
>> Provide any argument.
>
> Just take a look at the driver. hisi_inno_phy_write_reg() is the
> function that differs between different models. But for all of them,
> hisi_inno_phy_setup() is the same.
>
>
> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
> bus-related, not phy. PHY driver should not care how to access the bus,
So drivers are compatible or hardware? We talk about hardware, not
drivers...
> but the bus driver should. The PHY driver only needs to use regmap_*
> APIs to "write BIT(2) to addr 6".
Different programming interface, so not compatible.
>
>
> For mv100 and cv200, the PHY master bus interface is attached to the
> perictrl core in SoC (though the perictrl core provides slightly
> different register offsets to access the PHY bus). For mv200, it is
> directly attached to AHB/APB system bus so we don't need to put it under
> a perictrl node anymore. So here, clearly it's the bus the PHY attached
Different programming interface, so not compatible.
> to which is different, not the PHY itself.
>
>
> That's why i say the driver is wrong from the beginning. It's mixing PHY
I don't care. We do not talk about drivers.
> driver and bus driver together but they ought to be different. PHY is
> always compatible, but the bus is not.
Do you understand what does it mean "compatible" in DT?
>
>
> The correct fix should be moving hisi_inno_phy_write_reg() to a new bus
> driver and migrating to regmap_* APIs in PHY driver. But i'll have to
Don't care. Driver stuff.
> write a new driver for that, which i try to avoid (it takes too much
> time!). So i said clearly in the cover-letter this should be considered
> a hack.
Best regards,
Krzysztof
On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
> On 20/02/2024 11:40, Yang Xiwen wrote:
>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>
>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>> list due to prior driver change.
>>>>>>>>
>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>> compatible lists.
>>>>>>>>
>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>> ---
>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>> +%YAML 1.2
>>>>>>>> +---
>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>> +
>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> + compatible:
>>>>>>>> + items:
>>>>>>>> + - enum:
>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>> intention to look there).
>>>>>
>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>> not some other one.
>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>> Why? Because...
>>>
>>>> inno-usb2-phy. The only difference here is the method to access the
>>> ... here! Different programming interface means not compatible.
>>>
>>> Please provide instead any argument that they are compatible, in the
>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>> used for hi3798mv100 and it will work fine?
>>>
>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>> the cover letter, I said the driver is actually doing things wrong.
>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>
>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>> between these 3 SoCs.
>>> Provide any argument.
>>
>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>> function that differs between different models. But for all of them,
>> hisi_inno_phy_setup() is the same.
>>
>>
>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>> bus-related, not phy. PHY driver should not care how to access the bus,
>
> So drivers are compatible or hardware? We talk about hardware, not
> drivers...
>
>> but the bus driver should. The PHY driver only needs to use regmap_*
>> APIs to "write BIT(2) to addr 6".
>
> Different programming interface, so not compatible.
Although maybe I jumped to conclusions too fast. Do you claim that all
registers are the same? All the values, offsets, fields and masks?
Best regards,
Krzysztof
On 2/20/2024 7:43 PM, Krzysztof Kozlowski wrote:
> On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
>> On 20/02/2024 11:40, Yang Xiwen wrote:
>>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>>
>>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>>> list due to prior driver change.
>>>>>>>>>
>>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>>> compatible lists.
>>>>>>>>>
>>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>>> ---
>>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>> +%YAML 1.2
>>>>>>>>> +---
>>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>> +
>>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>>> +
>>>>>>>>> +maintainers:
>>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> + compatible:
>>>>>>>>> + items:
>>>>>>>>> + - enum:
>>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>>> intention to look there).
>>>>>>
>>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>>> not some other one.
>>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>>> Why? Because...
>>>>
>>>>> inno-usb2-phy. The only difference here is the method to access the
>>>> ... here! Different programming interface means not compatible.
>>>>
>>>> Please provide instead any argument that they are compatible, in the
>>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>>> used for hi3798mv100 and it will work fine?
>>>>
>>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>>> the cover letter, I said the driver is actually doing things wrong.
>>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>>
>>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>>> between these 3 SoCs.
>>>> Provide any argument.
>>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>>> function that differs between different models. But for all of them,
>>> hisi_inno_phy_setup() is the same.
>>>
>>>
>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>> bus-related, not phy. PHY driver should not care how to access the bus,
>> So drivers are compatible or hardware? We talk about hardware, not
>> drivers...
>>
>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>> APIs to "write BIT(2) to addr 6".
>> Different programming interface, so not compatible.
> Although maybe I jumped to conclusions too fast. Do you claim that all
> registers are the same? All the values, offsets, fields and masks?
I don't quite understand. I've said there are two register spaces. One
is the bus to access the PHY (i.e. perictrl for mv100 and cv200 and mmio
for mv200), the other is the PHY register space. So if you are talking
about the prior one, then no, because the PHY is attached to different
buses. But for the latter, yes.
So here we are talking about two devices. One is the PHY, the other is
the bus the phy attached to.
The old binding is mixing all the things up because INNO PHY is the only
device attached to the dedicated bus implemented by perictrl. But it's
not how it works. The binding is for the PHY, not for the bus.
For mv100 and cv200, it's: cpu->perictrl->inno-phy. For mv200, it's:
cpu->inno-phy. cpu always accesses peripherals with MMIO, both for
perictrl and mv200-inno-phy. But if the inno-phy is attached to
perictrl. CPU must access the registers of inno-phy through
perictrl(Here perictrl act as a bus driver like a I2C/SPI controller).
For mv100 and cv200, the difference here is only related to to perictrl,
not the PHY itself. For mv200, perictrl does not implement this strange
bus anymore, instead the phy is attached to system bus directly.
I don't understand why you say they are not compatible, simply because
they are attached to different buses. For x86, peripherals are mapped in
dedicated IO address spaces with `IN` and `OUT`, while for ARM, they are
all attached to MMIO buses like APB/AHB/AXI etc.. So peripherals for x86
and peripherals for arm are also not compatible?
The binding now is still broken. I admit it's true.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 20/02/2024 13:12, Yang Xiwen wrote:
> On 2/20/2024 7:43 PM, Krzysztof Kozlowski wrote:
>> On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
>>> On 20/02/2024 11:40, Yang Xiwen wrote:
>>>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>>>
>>>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>>>> list due to prior driver change.
>>>>>>>>>>
>>>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>>>> compatible lists.
>>>>>>>>>>
>>>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>>>> ---
>>>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>> +%YAML 1.2
>>>>>>>>>> +---
>>>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>> +
>>>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>>>> +
>>>>>>>>>> +maintainers:
>>>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>>>> +
>>>>>>>>>> +properties:
>>>>>>>>>> + compatible:
>>>>>>>>>> + items:
>>>>>>>>>> + - enum:
>>>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>>>> intention to look there).
>>>>>>>
>>>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>>>> not some other one.
>>>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>>>> Why? Because...
>>>>>
>>>>>> inno-usb2-phy. The only difference here is the method to access the
>>>>> ... here! Different programming interface means not compatible.
>>>>>
>>>>> Please provide instead any argument that they are compatible, in the
>>>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>>>> used for hi3798mv100 and it will work fine?
>>>>>
>>>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>>>> the cover letter, I said the driver is actually doing things wrong.
>>>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>>>
>>>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>>>> between these 3 SoCs.
>>>>> Provide any argument.
>>>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>>>> function that differs between different models. But for all of them,
>>>> hisi_inno_phy_setup() is the same.
>>>>
>>>>
>>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>>> bus-related, not phy. PHY driver should not care how to access the bus,
>>> So drivers are compatible or hardware? We talk about hardware, not
>>> drivers...
>>>
>>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>>> APIs to "write BIT(2) to addr 6".
>>> Different programming interface, so not compatible.
>> Although maybe I jumped to conclusions too fast. Do you claim that all
>> registers are the same? All the values, offsets, fields and masks?
>
>
> I don't quite understand. I've said there are two register spaces. One
> is the bus to access the PHY (i.e. perictrl for mv100 and cv200 and mmio
> for mv200), the other is the PHY register space. So if you are talking
> about the prior one, then no, because the PHY is attached to different
> buses. But for the latter, yes.
I am talking about the register address space which the binding document.
>
>
> So here we are talking about two devices. One is the PHY, the other is
> the bus the phy attached to.
>
>
> The old binding is mixing all the things up because INNO PHY is the only
> device attached to the dedicated bus implemented by perictrl. But it's
> not how it works. The binding is for the PHY, not for the bus.
>
>
> For mv100 and cv200, it's: cpu->perictrl->inno-phy. For mv200, it's:
> cpu->inno-phy. cpu always accesses peripherals with MMIO, both for
> perictrl and mv200-inno-phy. But if the inno-phy is attached to
> perictrl. CPU must access the registers of inno-phy through
> perictrl(Here perictrl act as a bus driver like a I2C/SPI controller).
> For mv100 and cv200, the difference here is only related to to perictrl,
> not the PHY itself. For mv200, perictrl does not implement this strange
> bus anymore, instead the phy is attached to system bus directly.
Your driver writes different values depending on the device. For one
model it writes PHY0_TEST_WREN+PHY0_TEST_RST+PHY0_TEST_CLK. For the
second PHY1-versions of above.
The PHY0_TEST_CLK is written to the "reg", so I understand that to the
device address space.
If you write two different values to the same register, devices are not
compatible usually.
>
>
> I don't understand why you say they are not compatible, simply because
> they are attached to different buses. For x86, peripherals are mapped in
I did not say that. I said that according to quick look in the driver
and to your explanations you had different programming models and
interfaces, which means devices are not compatible.
> dedicated IO address spaces with `IN` and `OUT`, while for ARM, they are
> all attached to MMIO buses like APB/AHB/AXI etc.. So peripherals for x86
> and peripherals for arm are also not compatible?
Depends. You did not answer to my question whether you even understand
what is "compatible", so I assume you don't. Compatible means
programming models are the same or one is subset of another, so
effectively both devices work with the same compatible and everything is
fine.
Answer yes or not:
Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
hisilicon,hi3798mv100-usb2-phy compatible and operate correctly, so you
remove hisilicon,hi3798mv100-usb2-phy from the driver and device
operates correctly?
Best regards,
Krzysztof
On 20/02/2024 12:43, Krzysztof Kozlowski wrote:
>>>
>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>> bus-related, not phy. PHY driver should not care how to access the bus,
>>
>> So drivers are compatible or hardware? We talk about hardware, not
>> drivers...
>>
>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>> APIs to "write BIT(2) to addr 6".
>>
>> Different programming interface, so not compatible.
>
> Although maybe I jumped to conclusions too fast. Do you claim that all
> registers are the same? All the values, offsets, fields and masks?
I still wait for the answer: yes or not, for above.
Best regards,
Krzysztof
On 21/02/2024 09:22, Krzysztof Kozlowski wrote:
> On 20/02/2024 13:12, Yang Xiwen wrote:
>> On 2/20/2024 7:43 PM, Krzysztof Kozlowski wrote:
>>> On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
>>>> On 20/02/2024 11:40, Yang Xiwen wrote:
>>>>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>>>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>>>>
>>>>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>>>>> list due to prior driver change.
>>>>>>>>>>>
>>>>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>>>>> compatible lists.
>>>>>>>>>>>
>>>>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>>>>> ---
>>>>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>>> +%YAML 1.2
>>>>>>>>>>> +---
>>>>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>>> +
>>>>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>>>>> +
>>>>>>>>>>> +maintainers:
>>>>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>>>>> +
>>>>>>>>>>> +properties:
>>>>>>>>>>> + compatible:
>>>>>>>>>>> + items:
>>>>>>>>>>> + - enum:
>>>>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>>>>> intention to look there).
>>>>>>>>
>>>>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>>>>> not some other one.
>>>>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>>>>> Why? Because...
>>>>>>
>>>>>>> inno-usb2-phy. The only difference here is the method to access the
>>>>>> ... here! Different programming interface means not compatible.
>>>>>>
>>>>>> Please provide instead any argument that they are compatible, in the
>>>>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>>>>> used for hi3798mv100 and it will work fine?
>>>>>>
>>>>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>>>>> the cover letter, I said the driver is actually doing things wrong.
>>>>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>>>>
>>>>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>>>>> between these 3 SoCs.
>>>>>> Provide any argument.
>>>>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>>>>> function that differs between different models. But for all of them,
>>>>> hisi_inno_phy_setup() is the same.
>>>>>
>>>>>
>>>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>>>> bus-related, not phy. PHY driver should not care how to access the bus,
>>>> So drivers are compatible or hardware? We talk about hardware, not
>>>> drivers...
>>>>
>>>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>>>> APIs to "write BIT(2) to addr 6".
>>>> Different programming interface, so not compatible.
>>> Although maybe I jumped to conclusions too fast. Do you claim that all
>>> registers are the same? All the values, offsets, fields and masks?
>>
>>
>> I don't quite understand. I've said there are two register spaces. One
>> is the bus to access the PHY (i.e. perictrl for mv100 and cv200 and mmio
>> for mv200), the other is the PHY register space. So if you are talking
>> about the prior one, then no, because the PHY is attached to different
>> buses. But for the latter, yes.
>
> I am talking about the register address space which the binding document.
>
>>
>>
>> So here we are talking about two devices. One is the PHY, the other is
>> the bus the phy attached to.
>>
>>
>> The old binding is mixing all the things up because INNO PHY is the only
>> device attached to the dedicated bus implemented by perictrl. But it's
>> not how it works. The binding is for the PHY, not for the bus.
>>
>>
>> For mv100 and cv200, it's: cpu->perictrl->inno-phy. For mv200, it's:
>> cpu->inno-phy. cpu always accesses peripherals with MMIO, both for
>> perictrl and mv200-inno-phy. But if the inno-phy is attached to
>> perictrl. CPU must access the registers of inno-phy through
>> perictrl(Here perictrl act as a bus driver like a I2C/SPI controller).
>> For mv100 and cv200, the difference here is only related to to perictrl,
>> not the PHY itself. For mv200, perictrl does not implement this strange
>> bus anymore, instead the phy is attached to system bus directly.
>
> Your driver writes different values depending on the device. For one
> model it writes PHY0_TEST_WREN+PHY0_TEST_RST+PHY0_TEST_CLK. For the
> second PHY1-versions of above.
>
> The PHY0_TEST_CLK is written to the "reg", so I understand that to the
> device address space.
>
> If you write two different values to the same register, devices are not
> compatible usually.
>
>>
>>
>> I don't understand why you say they are not compatible, simply because
>> they are attached to different buses. For x86, peripherals are mapped in
>
> I did not say that. I said that according to quick look in the driver
> and to your explanations you had different programming models and
> interfaces, which means devices are not compatible.
>
>> dedicated IO address spaces with `IN` and `OUT`, while for ARM, they are
>> all attached to MMIO buses like APB/AHB/AXI etc.. So peripherals for x86
>> and peripherals for arm are also not compatible?
>
> Depends. You did not answer to my question whether you even understand
> what is "compatible", so I assume you don't. Compatible means
> programming models are the same or one is subset of another, so
> effectively both devices work with the same compatible and everything is
> fine.
>
> Answer yes or not:
> Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
> hisilicon,hi3798mv100-usb2-phy compatible and operate correctly, so you
> remove hisilicon,hi3798mv100-usb2-phy from the driver and device
> operates correctly?
I mixed compatibles, this should be:
Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
"hisilicon,inno-usb2-phy" compatible and operate correctly, so you
remove hisilicon,hi3798mv100-usb2-phy from the driver and device
operates correctly?
Best regards,
Krzysztof
On 2/21/2024 4:22 PM, Krzysztof Kozlowski wrote:
> On 20/02/2024 13:12, Yang Xiwen wrote:
>> On 2/20/2024 7:43 PM, Krzysztof Kozlowski wrote:
>>> On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
>>>> On 20/02/2024 11:40, Yang Xiwen wrote:
>>>>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>>>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>>>>
>>>>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>>>>> list due to prior driver change.
>>>>>>>>>>>
>>>>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>>>>> compatible lists.
>>>>>>>>>>>
>>>>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>>>>> ---
>>>>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>>> +%YAML 1.2
>>>>>>>>>>> +---
>>>>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>>> +
>>>>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>>>>> +
>>>>>>>>>>> +maintainers:
>>>>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>>>>> +
>>>>>>>>>>> +properties:
>>>>>>>>>>> + compatible:
>>>>>>>>>>> + items:
>>>>>>>>>>> + - enum:
>>>>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>>>>> intention to look there).
>>>>>>>>
>>>>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>>>>> not some other one.
>>>>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>>>>> Why? Because...
>>>>>>
>>>>>>> inno-usb2-phy. The only difference here is the method to access the
>>>>>> ... here! Different programming interface means not compatible.
>>>>>>
>>>>>> Please provide instead any argument that they are compatible, in the
>>>>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>>>>> used for hi3798mv100 and it will work fine?
>>>>>>
>>>>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>>>>> the cover letter, I said the driver is actually doing things wrong.
>>>>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>>>>
>>>>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>>>>> between these 3 SoCs.
>>>>>> Provide any argument.
>>>>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>>>>> function that differs between different models. But for all of them,
>>>>> hisi_inno_phy_setup() is the same.
>>>>>
>>>>>
>>>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>>>> bus-related, not phy. PHY driver should not care how to access the bus,
>>>> So drivers are compatible or hardware? We talk about hardware, not
>>>> drivers...
>>>>
>>>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>>>> APIs to "write BIT(2) to addr 6".
>>>> Different programming interface, so not compatible.
>>> Although maybe I jumped to conclusions too fast. Do you claim that all
>>> registers are the same? All the values, offsets, fields and masks?
>>
>> I don't quite understand. I've said there are two register spaces. One
>> is the bus to access the PHY (i.e. perictrl for mv100 and cv200 and mmio
>> for mv200), the other is the PHY register space. So if you are talking
>> about the prior one, then no, because the PHY is attached to different
>> buses. But for the latter, yes.
> I am talking about the register address space which the binding document.
>
>>
>> So here we are talking about two devices. One is the PHY, the other is
>> the bus the phy attached to.
>>
>>
>> The old binding is mixing all the things up because INNO PHY is the only
>> device attached to the dedicated bus implemented by perictrl. But it's
>> not how it works. The binding is for the PHY, not for the bus.
>>
>>
>> For mv100 and cv200, it's: cpu->perictrl->inno-phy. For mv200, it's:
>> cpu->inno-phy. cpu always accesses peripherals with MMIO, both for
>> perictrl and mv200-inno-phy. But if the inno-phy is attached to
>> perictrl. CPU must access the registers of inno-phy through
>> perictrl(Here perictrl act as a bus driver like a I2C/SPI controller).
>> For mv100 and cv200, the difference here is only related to to perictrl,
>> not the PHY itself. For mv200, perictrl does not implement this strange
>> bus anymore, instead the phy is attached to system bus directly.
> Your driver writes different values depending on the device. For one
> model it writes PHY0_TEST_WREN+PHY0_TEST_RST+PHY0_TEST_CLK. For the
> second PHY1-versions of above.
>
> The PHY0_TEST_CLK is written to the "reg", so I understand that to the
> device address space.
All these stuff belongs to the bus interface, not the PHY. PHY0_TEST_CLK
belongs to perictrl bus interface, no the phy. It's not in device
register space.
clocks and resets are resources to the PHY actually. Here the driver
does not model it correctly. About WREN, it's only related to the bus,
not the PHY.
>
> If you write two different values to the same register, devices are not
> compatible usually.
>
>>
>> I don't understand why you say they are not compatible, simply because
>> they are attached to different buses. For x86, peripherals are mapped in
> I did not say that. I said that according to quick look in the driver
> and to your explanations you had different programming models and
> interfaces, which means devices are not compatible.
>
>> dedicated IO address spaces with `IN` and `OUT`, while for ARM, they are
>> all attached to MMIO buses like APB/AHB/AXI etc.. So peripherals for x86
>> and peripherals for arm are also not compatible?
> Depends. You did not answer to my question whether you even understand
> what is "compatible", so I assume you don't. Compatible means
> programming models are the same or one is subset of another, so
> effectively both devices work with the same compatible and everything is
> fine.
>
> Answer yes or not:
> Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
> hisilicon,hi3798mv100-usb2-phy compatible and operate correctly, so you
> remove hisilicon,hi3798mv100-usb2-phy from the driver and device
> operates correctly?
No, with this driver. Because it mixes bus interface and PHY. With
hisilicon,inno-usb2-phy compatible only, it's unable to know the bus
type (i.e. it doesn't know how to write to PHY registers).
But it's the driver which is currently broken, not the binding. The
correct fix would be extracting hisi_inno_phy_write_reg to a separate
driver, so this driver only needs to `write BIT(2) to addr 6` which is
done in hisi_inno_phy_setup().
You must have seen PHYn_TEST_CLK and PHYn_TEST_RST. They are the
resources of the PHY, so they should be modeled as clocks and reset
controls resources for the PHY. That's why i say the driver is terribly
tricky currently.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On 2/21/2024 4:25 PM, Krzysztof Kozlowski wrote:
> On 21/02/2024 09:22, Krzysztof Kozlowski wrote:
>> On 20/02/2024 13:12, Yang Xiwen wrote:
>>> On 2/20/2024 7:43 PM, Krzysztof Kozlowski wrote:
>>>> On 20/02/2024 12:41, Krzysztof Kozlowski wrote:
>>>>> On 20/02/2024 11:40, Yang Xiwen wrote:
>>>>>> On 2/20/2024 4:16 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 19/02/2024 22:49, Yang Xiwen wrote:
>>>>>>>> On 2/20/2024 5:37 AM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 19/02/2024 22:35, Yang Xiwen wrote:
>>>>>>>>>> On 2/20/2024 5:32 AM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 19/02/2024 22:27, Yang Xiwen via B4 Relay wrote:
>>>>>>>>>>>> From: Yang Xiwen <[email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>> Add missing compatible "hisilicon,hi3798mv100-usb2-phy" to compatible
>>>>>>>>>>>> list due to prior driver change.
>>>>>>>>>>>>
>>>>>>>>>>>> Also rename to hisilicon,inno-usb2-phy.yaml and add this name to
>>>>>>>>>>>> compatible lists.
>>>>>>>>>>>>
>>>>>>>>>>>> Fixes: 3940ffc65492 ("phy: hisilicon: Add inno-usb2-phy driver for Hi3798MV100")
>>>>>>>>>>>> Signed-off-by: Yang Xiwen <[email protected]>
>>>>>>>>>>>> ---
>>>>>>>>>>>> .../bindings/phy/hisilicon,inno-usb2-phy.yaml | 95 ++++++++++++++++++++++
>>>>>>>>>>>> .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 71 ----------------
>>>>>>>>>>>> 2 files changed, 95 insertions(+), 71 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>> index 000000000000..1b57e0396209
>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
>>>>>>>>>>>> @@ -0,0 +1,95 @@
>>>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>>>> +%YAML 1.2
>>>>>>>>>>>> +---
>>>>>>>>>>>> +$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
>>>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>>>> +
>>>>>>>>>>>> +title: HiSilicon HiSTB SoCs INNO USB2 PHY device
>>>>>>>>>>>> +
>>>>>>>>>>>> +maintainers:
>>>>>>>>>>>> + - Yang Xiwen <[email protected]>
>>>>>>>>>>>> +
>>>>>>>>>>>> +properties:
>>>>>>>>>>>> + compatible:
>>>>>>>>>>>> + items:
>>>>>>>>>>>> + - enum:
>>>>>>>>>>>> + - hisilicon,hi3798cv200-usb2-phy
>>>>>>>>>>>> + - hisilicon,hi3798mv100-usb2-phy
>>>>>>>>>>>> + - const: hisilicon,inno-usb2-phy
>>>>>>>>>>> According to your driver hisilicon,hi3798mv100-usb2-phy and
>>>>>>>>>>> hisilicon,inno-usb2-phy are not compatible.
>>>>>>>>>> Ah, i didn't pay too much attention to that. I should remove the entry
>>>>>>>>>> for hisilicon,inno-usb2-phy in the driver. Sorry for that.
>>>>>>>>> We don't talk here about driver, although I used the driver as proof or
>>>>>>>>> argument, because I don't have access to hardware datasheet (and no
>>>>>>>>> intention to look there).
>>>>>>>>>
>>>>>>>>> What I claim is these are not compatible, so respond to this argument,
>>>>>>>>> not some other one.
>>>>>>>> Why not? Of course they are compatible. All 3 SoCs are using
>>>>>>> Why? Because...
>>>>>>>
>>>>>>>> inno-usb2-phy. The only difference here is the method to access the
>>>>>>> ... here! Different programming interface means not compatible.
>>>>>>>
>>>>>>> Please provide instead any argument that they are compatible, in the
>>>>>>> meaning of Devicetree of course. You are claiming inno-usb2-phy can be
>>>>>>> used for hi3798mv100 and it will work fine?
>>>>>>>
>>>>>>>> registers. They are all enabled by `writing BIT(2) to address 0x6`. In
>>>>>>>> the cover letter, I said the driver is actually doing things wrong.
>>>>>>> Cover letter does not matter, I don't even read them. Your commits matter.
>>>>>>>
>>>>>>>> Especially the commit adding PHY_TYPE enums, the name is confusing and
>>>>>>>> conveys the wrong info. It's not PHY which are not compatible, it's the
>>>>>>>> bus. I'll fix the driver, but still the PHY hardwares are compatible
>>>>>>>> between these 3 SoCs.
>>>>>>> Provide any argument.
>>>>>> Just take a look at the driver. hisi_inno_phy_write_reg() is the
>>>>>> function that differs between different models. But for all of them,
>>>>>> hisi_inno_phy_setup() is the same.
>>>>>>
>>>>>>
>>>>>> hisi_inno_phy_write_reg() should be moved to a separate bus driver. It's
>>>>>> bus-related, not phy. PHY driver should not care how to access the bus,
>>>>> So drivers are compatible or hardware? We talk about hardware, not
>>>>> drivers...
>>>>>
>>>>>> but the bus driver should. The PHY driver only needs to use regmap_*
>>>>>> APIs to "write BIT(2) to addr 6".
>>>>> Different programming interface, so not compatible.
>>>> Although maybe I jumped to conclusions too fast. Do you claim that all
>>>> registers are the same? All the values, offsets, fields and masks?
>>>
>>> I don't quite understand. I've said there are two register spaces. One
>>> is the bus to access the PHY (i.e. perictrl for mv100 and cv200 and mmio
>>> for mv200), the other is the PHY register space. So if you are talking
>>> about the prior one, then no, because the PHY is attached to different
>>> buses. But for the latter, yes.
>> I am talking about the register address space which the binding document.
>>
>>>
>>> So here we are talking about two devices. One is the PHY, the other is
>>> the bus the phy attached to.
>>>
>>>
>>> The old binding is mixing all the things up because INNO PHY is the only
>>> device attached to the dedicated bus implemented by perictrl. But it's
>>> not how it works. The binding is for the PHY, not for the bus.
>>>
>>>
>>> For mv100 and cv200, it's: cpu->perictrl->inno-phy. For mv200, it's:
>>> cpu->inno-phy. cpu always accesses peripherals with MMIO, both for
>>> perictrl and mv200-inno-phy. But if the inno-phy is attached to
>>> perictrl. CPU must access the registers of inno-phy through
>>> perictrl(Here perictrl act as a bus driver like a I2C/SPI controller).
>>> For mv100 and cv200, the difference here is only related to to perictrl,
>>> not the PHY itself. For mv200, perictrl does not implement this strange
>>> bus anymore, instead the phy is attached to system bus directly.
>> Your driver writes different values depending on the device. For one
>> model it writes PHY0_TEST_WREN+PHY0_TEST_RST+PHY0_TEST_CLK. For the
>> second PHY1-versions of above.
>>
>> The PHY0_TEST_CLK is written to the "reg", so I understand that to the
>> device address space.
>>
>> If you write two different values to the same register, devices are not
>> compatible usually.
>>
>>>
>>> I don't understand why you say they are not compatible, simply because
>>> they are attached to different buses. For x86, peripherals are mapped in
>> I did not say that. I said that according to quick look in the driver
>> and to your explanations you had different programming models and
>> interfaces, which means devices are not compatible.
>>
>>> dedicated IO address spaces with `IN` and `OUT`, while for ARM, they are
>>> all attached to MMIO buses like APB/AHB/AXI etc.. So peripherals for x86
>>> and peripherals for arm are also not compatible?
>> Depends. You did not answer to my question whether you even understand
>> what is "compatible", so I assume you don't. Compatible means
>> programming models are the same or one is subset of another, so
>> effectively both devices work with the same compatible and everything is
>> fine.
>>
>> Answer yes or not:
>> Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
>> hisilicon,hi3798mv100-usb2-phy compatible and operate correctly, so you
>> remove hisilicon,hi3798mv100-usb2-phy from the driver and device
>> operates correctly?
> I mixed compatibles, this should be:
>
> Can PHY1 type of device, so hisilicon,hi3798mv100, bind using
> "hisilicon,inno-usb2-phy" compatible and operate correctly, so you
> remove hisilicon,hi3798mv100-usb2-phy from the driver and device
> operates correctly?
No, currently. But it's due to the fact that the bus to access the phy
registers are not compatible. Not the PHY itself is incompatible. So the
correct dt node (which represents the real hardware) for mv100/cv200
should be
perictrl@8a20000 {
compatible = "hisilicon,hi3798cv200-perictrl"; // or
hi3798mv100-perictrl
phy-bus@124 {
// the bus has its own address space
usb2-phy { // the PHY does not need an address
compatible = "hisilicon,inno-usb2-phy"
port@0 { // the port needs
// To enable a port, we need to write BIT(2) to address
0x6 from phy-bus@124
reg = <0>;
};
port@1 {
reg = <1>;
};
};
};
};
In this way, phy device gets regmap from parent bus node. So i would
insist that the PHY is always compatible. What is incompatible is the
bus to access the PHY, not the PHY itself.
Please note ONLY hisi_inno_phy_setup() function belongs to PHY driver.
hisi_inno_phy_write_reg() should be moved to the (not implemented yet)
PHY bus driver instead.
You say "programming interface" is different. But i'd say it's not. On
the opposite, it's the same in fact. Because all of
"hi3798mv100-usb2-phy", "hi3798cv200-usb2-phy" and even
"hi3798mv200-usb2-phy" are sharing the same hisi_inno_phy_setup()
function. And here is the key, this function should be considered as the
"programming interface", not hisi_inno_phy_write_reg(). And this is why
regmap API is introduced to the kernel, I think.
>
> Best regards,
> Krzysztof
>
--
Regards,
Yang Xiwen
On Di, 2024-02-20 at 05:28 +0800, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen <[email protected]>
>
> Direct MMIO resgiter access is used by Hi3798MV200. For other models,
register
> of_iomap() returns 0 due to insufficient length. So they are unaffected.
>
> Also Hi3798MV200 INNO PHY has an extra reset required to be deasserted,
> switch to reset_control_bulk_() APIs to resolve this.
reset_control_array_()
apparently.
> Signed-off-by: Yang Xiwen <[email protected]>
> ---
> drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 65 ++++++++++++++++++------------
> 1 file changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> index b7e740eb4752..5175e5a351ac 100644
> --- a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> +++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> @@ -10,6 +10,7 @@
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> @@ -43,6 +44,7 @@
> #define PHY_CLK_ENABLE BIT(2)
>
> struct hisi_inno_phy_port {
> + void __iomem *base;
> struct reset_control *utmi_rst;
> struct hisi_inno_phy_priv *priv;
> };
> @@ -50,7 +52,7 @@ struct hisi_inno_phy_port {
> struct hisi_inno_phy_priv {
> void __iomem *mmio;
> struct clk *ref_clk;
> - struct reset_control *por_rst;
> + struct reset_control *rsts;
> unsigned int type;
> struct hisi_inno_phy_port ports[INNO_PHY_PORT_NUM];
> };
> @@ -62,26 +64,31 @@ static void hisi_inno_phy_write_reg(struct hisi_inno_phy_priv *priv,
> u32 val;
> u32 value;
>
> - if (priv->type == PHY_TYPE_0)
> - val = (data & PHY_TEST_DATA) |
> - ((addr << PHY_TEST_ADDR_OFFSET) & PHY0_TEST_ADDR) |
> - ((port << PHY0_TEST_PORT_OFFSET) & PHY0_TEST_PORT) |
> - PHY0_TEST_WREN | PHY0_TEST_RST;
> - else
> - val = (data & PHY_TEST_DATA) |
> - ((addr << PHY_TEST_ADDR_OFFSET) & PHY1_TEST_ADDR) |
> - ((port << PHY1_TEST_PORT_OFFSET) & PHY1_TEST_PORT) |
> - PHY1_TEST_WREN | PHY1_TEST_RST;
> - writel(val, reg);
> -
> - value = val;
> - if (priv->type == PHY_TYPE_0)
> - value |= PHY0_TEST_CLK;
> - else
> - value |= PHY1_TEST_CLK;
> - writel(value, reg);
> -
> - writel(val, reg);
> + if (priv->ports[port].base)
> + // stride is 4
> + writel(data, (u32 *)priv->ports[port].base + addr);
> + else {
> + if (priv->type == PHY_TYPE_0)
> + val = (data & PHY_TEST_DATA) |
> + ((addr << PHY_TEST_ADDR_OFFSET) & PHY0_TEST_ADDR) |
> + ((port << PHY0_TEST_PORT_OFFSET) & PHY0_TEST_PORT) |
> + PHY0_TEST_WREN | PHY0_TEST_RST;
> + else
> + val = (data & PHY_TEST_DATA) |
> + ((addr << PHY_TEST_ADDR_OFFSET) & PHY1_TEST_ADDR) |
> + ((port << PHY1_TEST_PORT_OFFSET) & PHY1_TEST_PORT) |
> + PHY1_TEST_WREN | PHY1_TEST_RST;
> + writel(val, reg);
> +
> + value = val;
> + if (priv->type == PHY_TYPE_0)
> + value |= PHY0_TEST_CLK;
> + else
> + value |= PHY1_TEST_CLK;
> + writel(value, reg);
> +
> + writel(val, reg);
> + }
> }
>
> static void hisi_inno_phy_setup(struct hisi_inno_phy_priv *priv)
> @@ -104,7 +111,7 @@ static int hisi_inno_phy_init(struct phy *phy)
> return ret;
> udelay(REF_CLK_STABLE_TIME);
>
> - reset_control_deassert(priv->por_rst);
> + reset_control_deassert(priv->rsts);
> udelay(POR_RST_COMPLETE_TIME);
>
> /* Set up phy registers */
> @@ -122,7 +129,7 @@ static int hisi_inno_phy_exit(struct phy *phy)
> struct hisi_inno_phy_priv *priv = port->priv;
>
> reset_control_assert(port->utmi_rst);
> - reset_control_assert(priv->por_rst);
> + reset_control_assert(priv->rsts);
> clk_disable_unprepare(priv->ref_clk);
>
> return 0;
> @@ -158,15 +165,16 @@ static int hisi_inno_phy_probe(struct platform_device *pdev)
> if (IS_ERR(priv->ref_clk))
> return PTR_ERR(priv->ref_clk);
>
> - priv->por_rst = devm_reset_control_get_exclusive(dev, NULL);
> - if (IS_ERR(priv->por_rst))
> - return PTR_ERR(priv->por_rst);
> + priv->rsts = devm_reset_control_array_get(dev, false, false);
Please use devm_reset_control_array_get_exclusive() instead.
regards
Philipp