Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
Hi Scott, Kumar,
Looking at this patch I have realised that I had already submitted it
to the mailing list nearly 2 years ago:
https://patchwork.ozlabs.org/patch/842944/
Could you please make sure that this one gets merged in the next
window, so that I avoid forgetting such a patch a 2nd time ?
Thanks a lot
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted hunk
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
From: Scott Wood <oss@buserror.net> Date: 2019-07-28 20:10:13
On Sun, 2019-07-28 at 18:01 +0200, Valentin Longchamp wrote:
Hi Scott, Kumar,
Looking at this patch I have realised that I had already submitted it
to the mailing list nearly 2 years ago:
https://patchwork.ozlabs.org/patch/842944/
Could you please make sure that this one gets merged in the next
window, so that I avoid forgetting such a patch a 2nd time ?
Thanks a lot
I added it to my patchwork todo list; thanks for the reminder.
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I see
lots of phy-connection-type with fman. Madalin, does this patch look OK?
-Scott
Le dim. 28 juil. 2019 à 21:26, Scott Wood [off-list ref] a écrit :
On Sun, 2019-07-28 at 18:01 +0200, Valentin Longchamp wrote:
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I see
lots of phy-connection-type with fman. Madalin, does this patch look OK?
The fman driver (mac_probe()) calls of_get_phy_mode() which first
looks for phy-mode, and then phy-connection-type. Both should be the
same according to the device tree binding.
With some older kernels I remember we had issues with
phy-connection-type but not phy-mode, but this is more than 2 years
ago, I don't remember the details. phy-mode works well (tested ~2
weeks ago) with 4.14, 4.19 and 5.2, for sure.
Valentin
-----Original Message-----
From: Scott Wood <oss@buserror.net>
Sent: Sunday, July 28, 2019 10:27 PM
To: Valentin Longchamp <redacted>; linuxppc-
dev@lists.ozlabs.org; galak@kernel.crashing.org
Cc: Madalin-cristian Bucur <madalin.bucur@nxp.com>
Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy
properties
On Sun, 2019-07-28 at 18:01 +0200, Valentin Longchamp wrote:
quoted
Hi Scott, Kumar,
Looking at this patch I have realised that I had already submitted it
to the mailing list nearly 2 years ago:
https://patchwork.ozlabs.org/patch/842944/
Could you please make sure that this one gets merged in the next
window, so that I avoid forgetting such a patch a 2nd time ?
Thanks a lot
I added it to my patchwork todo list; thanks for the reminder.
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I see
lots of phy-connection-type with fman. Madalin, does this patch look OK?
-Scott
Hi,
we are using "phy-connection-type" not "phy-mode" for the NXP (former Freescale)
DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems to be
more recent, looking at the device tree bindings), the driver code in Linux seems
to use one or the other, not both so one should stick with the variant the driver
is using. To make things more complex, there may be dependencies in bootloaders,
I see code in u-boot using only "phy-connection-type" or only "phy-mode".
I'd leave "phy-connection-type" as is.
Madalin
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
[off-list ref] a écrit :
quoted
-----Original Message-----
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I see
lots of phy-connection-type with fman. Madalin, does this patch look OK?
-Scott
Hi,
we are using "phy-connection-type" not "phy-mode" for the NXP (former Freescale)
DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems to be
more recent, looking at the device tree bindings), the driver code in Linux seems
to use one or the other, not both so one should stick with the variant the driver
is using. To make things more complex, there may be dependencies in bootloaders,
I see code in u-boot using only "phy-connection-type" or only "phy-mode".
I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
From: Scott Wood <oss@buserror.net> Date: 2019-08-28 04:21:24
On Thu, 2019-08-08 at 23:09 +0200, Valentin Longchamp wrote:
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
[off-list ref] a écrit :
quoted
quoted
-----Original Message-----
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are
better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by
the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and
I see
lots of phy-connection-type with fman. Madalin, does this patch look
OK?
-Scott
Hi,
we are using "phy-connection-type" not "phy-mode" for the NXP (former
Freescale)
DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems
to be
more recent, looking at the device tree bindings), the driver code in
Linux seems
to use one or the other, not both so one should stick with the variant the
driver
is using. To make things more complex, there may be dependencies in
bootloaders,
I see code in u-boot using only "phy-connection-type" or only "phy-mode".
I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
Madalin, are you OK with the patch given this explanation?
-Scott
-----Original Message-----
From: Scott Wood <oss@buserror.net>
Sent: Wednesday, August 28, 2019 7:19 AM
To: Valentin Longchamp <redacted>; Madalin-cristian Bucur
[off-list ref]
Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org;
netdev@vger.kernel.org
Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy
properties
On Thu, 2019-08-08 at 23:09 +0200, Valentin Longchamp wrote:
quoted
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
[off-list ref] a écrit :
quoted
quoted
-----Original Message-----
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are
better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added
by
quoted
quoted
quoted
quoted
quoted
the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl,
and
quoted
quoted
quoted
I see
lots of phy-connection-type with fman. Madalin, does this patch
look
quoted
quoted
quoted
OK?
-Scott
Hi,
we are using "phy-connection-type" not "phy-mode" for the NXP (former
Freescale)
DPAA platforms. While the two seem to be interchangeable ("phy-mode"
seems
quoted
quoted
to be
more recent, looking at the device tree bindings), the driver code in
Linux seems
to use one or the other, not both so one should stick with the variant
the
quoted
quoted
driver
is using. To make things more complex, there may be dependencies in
bootloaders,
I see code in u-boot using only "phy-connection-type" or only "phy-
mode".
quoted
quoted
I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
Madalin, are you OK with the patch given this explanation?
-Scott
Yes, I understand that it's the only option they have, given the inability
to upgrade u-boot (this may prove to be an issue in the future, in other
situations).
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
From: Scott Wood <oss@buserror.net> Date: 2019-09-14 14:35:38
On Thu, 2019-08-29 at 11:25 +0000, Madalin-cristian Bucur wrote:
quoted
-----Original Message-----
From: Scott Wood <oss@buserror.net>
Sent: Wednesday, August 28, 2019 7:19 AM
To: Valentin Longchamp <redacted>; Madalin-cristian Bucur
[off-list ref]
Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org;
netdev@vger.kernel.org
Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy
properties
On Thu, 2019-08-08 at 23:09 +0200, Valentin Longchamp wrote:
quoted
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
[off-list ref] a écrit :
quoted
quoted
-----Original Message-----
quoted
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
[off-list ref] a écrit :
quoted
Change all phy-connection-type properties to phy-mode that are
better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added
by
quoted
quoted
quoted
quoted
quoted
the
phy.
Signed-off-by: Valentin Longchamp <redacted>
I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl,
and
quoted
quoted
quoted
I see
lots of phy-connection-type with fman. Madalin, does this patch
look
quoted
quoted
quoted
OK?
-Scott
Hi,
we are using "phy-connection-type" not "phy-mode" for the NXP (former
Freescale)
DPAA platforms. While the two seem to be interchangeable ("phy-mode"
seems
quoted
quoted
to be
more recent, looking at the device tree bindings), the driver code in
Linux seems
to use one or the other, not both so one should stick with the variant
the
quoted
quoted
driver
is using. To make things more complex, there may be dependencies in
bootloaders,
I see code in u-boot using only "phy-connection-type" or only "phy-
mode".
quoted
quoted
I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
Madalin, are you OK with the patch given this explanation?
-Scott
Yes, I understand that it's the only option they have, given the inability
to upgrade u-boot (this may prove to be an issue in the future, in other
situations).
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>