From: Heiner Kallweit <hkallweit1@gmail.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Kevin Hilman <khilman@baylibre.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>
Subject: Re: [PATCH net-next] net: phy: meson-gxl: support more G12A-internal PHY versions
Date: Thu, 19 Jan 2023 23:42:54 +0100 [thread overview]
Message-ID: <e75ed56f-ba25-f337-e879-33cc2a784740@gmail.com> (raw)
In-Reply-To: <6de25c61-c187-fb88-5bd7-477b1db1510e@gmail.com>
On 15.01.2023 21:38, Heiner Kallweit wrote:
> On 15.01.2023 19:43, Neil Armstrong wrote:
>> Hi Heiner,
>>
>> Le 15/01/2023 à 18:09, Heiner Kallweit a écrit :
>>> On 15.01.2023 17:57, Andrew Lunn wrote:
>>>> On Sun, Jan 15, 2023 at 04:19:37PM +0100, Heiner Kallweit wrote:
>>>>> On my SC2-based system the genphy driver was used because the PHY
>>>>> identifies as 0x01803300. It works normal with the meson g12a
>>>>> driver after this change.
>>>>> Switch to PHY_ID_MATCH_MODEL to cover the different sub-versions.
>>>>
>>>> Hi Heiner
>>>>
>>>> Are there any datasheets for these devices? Anything which documents
>>>> the lower nibble really is a revision?
>>>>
>>>> I'm just trying to avoid future problems where we find it is actually
>>>> a different PHY, needs its own MATCH_EXACT entry, and then we find we
>>>> break devices using 0x01803302 which we had no idea exists, but got
>>>> covered by this change.
>>>>
>>> The SC2 platform inherited a lot from G12A, therefore it's plausible
>>> that it's the same PHY. Also the vendor driver for SC2 gives a hint
>>> as it has the following compatible for the PHY:
>>>
>>> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>>>
>>> But you're right, I can't say for sure as I don't have the datasheets.
>>
>> On G12A (& GXL), the PHY ID is set in the MDIO MUX registers,
>> please see:
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/mdio/mdio-mux-meson-g12a.c#L36
>>
>> So you should either add support for the PHY mux in SC2 or check
>> what is in the ETH_PHY_CNTL0 register.
>>
> Thanks for the hint. I just checked and reading back ETH_PHY_CNTL0 at the
> end of g12a_enable_internal_mdio() gives me the expected result of 0x33010180.
> But still the PHY reports 3300.
> Even if I write some other random value to ETH_PHY_CNTL0, I get 0180/3300
> as PHY ID.
>
> For u-boot I found the following:
>
> https://github.com/khadas/u-boot/blob/khadas-vim4-r-64bit/drivers/net/phy/amlogic.c
>
> static struct phy_driver amlogic_internal_driver = {
> .name = "Meson GXL Internal PHY",
> .uid = 0x01803300,
> .mask = 0xfffffff0,
> .features = PHY_BASIC_FEATURES,
> .config = &meson_phy_config,
> .startup = &meson_aml_startup,
> .shutdown = &genphy_shutdown,
> };
>
> So it's the same PHY ID I'm seeing in Linux.
>
> My best guess is that the following is the case:
>
> The PHY compatible string in DT is the following in all cases:
> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>
> Therefore id 0180/3301 is used even if the PHY reports something else.
> Means it doesn't matter which value you write to ETH_PHY_CNTL0.
>
> I reduced the compatible string to compatible = "ethernet-phy-ieee802.3-c22"
> and this resulted in the actual PHY ID being used.
> You could change the compatible in dts the same way for any g12a system
> and I assume you would get 0180/3300 too.
>
> Remaining question is why the value in ETH_PHY_CNTL0 is ignored.
>
I think I found what's going on. The PHY ID written to SoC register
ETH_PHY_CNTL0 isn't effective immediately. It takes a PHY soft reset before
it reports the new PHY ID. Would be good to have a comment in the
g12a mdio mux code mentioning this constraint.
I see no easy way to trigger a soft reset early enough. Therefore it's indeed
the simplest option to specify the new PHY ID in the compatible.
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Kevin Hilman <khilman@baylibre.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>
Subject: Re: [PATCH net-next] net: phy: meson-gxl: support more G12A-internal PHY versions
Date: Thu, 19 Jan 2023 23:42:54 +0100 [thread overview]
Message-ID: <e75ed56f-ba25-f337-e879-33cc2a784740@gmail.com> (raw)
In-Reply-To: <6de25c61-c187-fb88-5bd7-477b1db1510e@gmail.com>
On 15.01.2023 21:38, Heiner Kallweit wrote:
> On 15.01.2023 19:43, Neil Armstrong wrote:
>> Hi Heiner,
>>
>> Le 15/01/2023 à 18:09, Heiner Kallweit a écrit :
>>> On 15.01.2023 17:57, Andrew Lunn wrote:
>>>> On Sun, Jan 15, 2023 at 04:19:37PM +0100, Heiner Kallweit wrote:
>>>>> On my SC2-based system the genphy driver was used because the PHY
>>>>> identifies as 0x01803300. It works normal with the meson g12a
>>>>> driver after this change.
>>>>> Switch to PHY_ID_MATCH_MODEL to cover the different sub-versions.
>>>>
>>>> Hi Heiner
>>>>
>>>> Are there any datasheets for these devices? Anything which documents
>>>> the lower nibble really is a revision?
>>>>
>>>> I'm just trying to avoid future problems where we find it is actually
>>>> a different PHY, needs its own MATCH_EXACT entry, and then we find we
>>>> break devices using 0x01803302 which we had no idea exists, but got
>>>> covered by this change.
>>>>
>>> The SC2 platform inherited a lot from G12A, therefore it's plausible
>>> that it's the same PHY. Also the vendor driver for SC2 gives a hint
>>> as it has the following compatible for the PHY:
>>>
>>> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>>>
>>> But you're right, I can't say for sure as I don't have the datasheets.
>>
>> On G12A (& GXL), the PHY ID is set in the MDIO MUX registers,
>> please see:
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/mdio/mdio-mux-meson-g12a.c#L36
>>
>> So you should either add support for the PHY mux in SC2 or check
>> what is in the ETH_PHY_CNTL0 register.
>>
> Thanks for the hint. I just checked and reading back ETH_PHY_CNTL0 at the
> end of g12a_enable_internal_mdio() gives me the expected result of 0x33010180.
> But still the PHY reports 3300.
> Even if I write some other random value to ETH_PHY_CNTL0, I get 0180/3300
> as PHY ID.
>
> For u-boot I found the following:
>
> https://github.com/khadas/u-boot/blob/khadas-vim4-r-64bit/drivers/net/phy/amlogic.c
>
> static struct phy_driver amlogic_internal_driver = {
> .name = "Meson GXL Internal PHY",
> .uid = 0x01803300,
> .mask = 0xfffffff0,
> .features = PHY_BASIC_FEATURES,
> .config = &meson_phy_config,
> .startup = &meson_aml_startup,
> .shutdown = &genphy_shutdown,
> };
>
> So it's the same PHY ID I'm seeing in Linux.
>
> My best guess is that the following is the case:
>
> The PHY compatible string in DT is the following in all cases:
> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>
> Therefore id 0180/3301 is used even if the PHY reports something else.
> Means it doesn't matter which value you write to ETH_PHY_CNTL0.
>
> I reduced the compatible string to compatible = "ethernet-phy-ieee802.3-c22"
> and this resulted in the actual PHY ID being used.
> You could change the compatible in dts the same way for any g12a system
> and I assume you would get 0180/3300 too.
>
> Remaining question is why the value in ETH_PHY_CNTL0 is ignored.
>
I think I found what's going on. The PHY ID written to SoC register
ETH_PHY_CNTL0 isn't effective immediately. It takes a PHY soft reset before
it reports the new PHY ID. Would be good to have a comment in the
g12a mdio mux code mentioning this constraint.
I see no easy way to trigger a soft reset early enough. Therefore it's indeed
the simplest option to specify the new PHY ID in the compatible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Kevin Hilman <khilman@baylibre.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>
Subject: Re: [PATCH net-next] net: phy: meson-gxl: support more G12A-internal PHY versions
Date: Thu, 19 Jan 2023 23:42:54 +0100 [thread overview]
Message-ID: <e75ed56f-ba25-f337-e879-33cc2a784740@gmail.com> (raw)
In-Reply-To: <6de25c61-c187-fb88-5bd7-477b1db1510e@gmail.com>
On 15.01.2023 21:38, Heiner Kallweit wrote:
> On 15.01.2023 19:43, Neil Armstrong wrote:
>> Hi Heiner,
>>
>> Le 15/01/2023 à 18:09, Heiner Kallweit a écrit :
>>> On 15.01.2023 17:57, Andrew Lunn wrote:
>>>> On Sun, Jan 15, 2023 at 04:19:37PM +0100, Heiner Kallweit wrote:
>>>>> On my SC2-based system the genphy driver was used because the PHY
>>>>> identifies as 0x01803300. It works normal with the meson g12a
>>>>> driver after this change.
>>>>> Switch to PHY_ID_MATCH_MODEL to cover the different sub-versions.
>>>>
>>>> Hi Heiner
>>>>
>>>> Are there any datasheets for these devices? Anything which documents
>>>> the lower nibble really is a revision?
>>>>
>>>> I'm just trying to avoid future problems where we find it is actually
>>>> a different PHY, needs its own MATCH_EXACT entry, and then we find we
>>>> break devices using 0x01803302 which we had no idea exists, but got
>>>> covered by this change.
>>>>
>>> The SC2 platform inherited a lot from G12A, therefore it's plausible
>>> that it's the same PHY. Also the vendor driver for SC2 gives a hint
>>> as it has the following compatible for the PHY:
>>>
>>> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>>>
>>> But you're right, I can't say for sure as I don't have the datasheets.
>>
>> On G12A (& GXL), the PHY ID is set in the MDIO MUX registers,
>> please see:
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/mdio/mdio-mux-meson-g12a.c#L36
>>
>> So you should either add support for the PHY mux in SC2 or check
>> what is in the ETH_PHY_CNTL0 register.
>>
> Thanks for the hint. I just checked and reading back ETH_PHY_CNTL0 at the
> end of g12a_enable_internal_mdio() gives me the expected result of 0x33010180.
> But still the PHY reports 3300.
> Even if I write some other random value to ETH_PHY_CNTL0, I get 0180/3300
> as PHY ID.
>
> For u-boot I found the following:
>
> https://github.com/khadas/u-boot/blob/khadas-vim4-r-64bit/drivers/net/phy/amlogic.c
>
> static struct phy_driver amlogic_internal_driver = {
> .name = "Meson GXL Internal PHY",
> .uid = 0x01803300,
> .mask = 0xfffffff0,
> .features = PHY_BASIC_FEATURES,
> .config = &meson_phy_config,
> .startup = &meson_aml_startup,
> .shutdown = &genphy_shutdown,
> };
>
> So it's the same PHY ID I'm seeing in Linux.
>
> My best guess is that the following is the case:
>
> The PHY compatible string in DT is the following in all cases:
> compatible = "ethernet-phy-id0180.3301", "ethernet-phy-ieee802.3-c22";
>
> Therefore id 0180/3301 is used even if the PHY reports something else.
> Means it doesn't matter which value you write to ETH_PHY_CNTL0.
>
> I reduced the compatible string to compatible = "ethernet-phy-ieee802.3-c22"
> and this resulted in the actual PHY ID being used.
> You could change the compatible in dts the same way for any g12a system
> and I assume you would get 0180/3300 too.
>
> Remaining question is why the value in ETH_PHY_CNTL0 is ignored.
>
I think I found what's going on. The PHY ID written to SoC register
ETH_PHY_CNTL0 isn't effective immediately. It takes a PHY soft reset before
it reports the new PHY ID. Would be good to have a comment in the
g12a mdio mux code mentioning this constraint.
I see no easy way to trigger a soft reset early enough. Therefore it's indeed
the simplest option to specify the new PHY ID in the compatible.
next prev parent reply other threads:[~2023-01-19 22:43 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 15:19 [PATCH net-next] net: phy: meson-gxl: support more G12A-internal PHY versions Heiner Kallweit
2023-01-15 15:19 ` Heiner Kallweit
2023-01-15 15:19 ` Heiner Kallweit
2023-01-15 16:57 ` Andrew Lunn
2023-01-15 16:57 ` Andrew Lunn
2023-01-15 16:57 ` Andrew Lunn
2023-01-15 17:09 ` Heiner Kallweit
2023-01-15 17:09 ` Heiner Kallweit
2023-01-15 17:09 ` Heiner Kallweit
2023-01-15 18:43 ` Neil Armstrong
2023-01-15 18:43 ` Neil Armstrong
2023-01-15 18:43 ` Neil Armstrong
2023-01-15 19:42 ` Anand Moon
2023-01-15 19:42 ` Anand Moon
2023-01-15 19:42 ` Anand Moon
2023-01-15 20:38 ` Heiner Kallweit
2023-01-15 20:38 ` Heiner Kallweit
2023-01-15 20:38 ` Heiner Kallweit
2023-01-17 12:04 ` Paolo Abeni
2023-01-17 12:04 ` Paolo Abeni
2023-01-17 12:04 ` Paolo Abeni
2023-01-17 13:30 ` Andrew Lunn
2023-01-17 13:30 ` Andrew Lunn
2023-01-17 13:30 ` Andrew Lunn
2023-01-17 14:51 ` Heiner Kallweit
2023-01-17 14:51 ` Heiner Kallweit
2023-01-17 14:51 ` Heiner Kallweit
2023-01-20 9:55 ` Jerome Brunet
2023-01-20 9:55 ` Jerome Brunet
2023-01-20 9:55 ` Jerome Brunet
2023-01-19 22:42 ` Heiner Kallweit [this message]
2023-01-19 22:42 ` Heiner Kallweit
2023-01-19 22:42 ` Heiner Kallweit
2023-01-20 10:01 ` Jerome Brunet
2023-01-20 10:01 ` Jerome Brunet
2023-01-20 10:01 ` Jerome Brunet
2023-01-20 10:22 ` Heiner Kallweit
2023-01-20 10:22 ` Heiner Kallweit
2023-01-20 10:22 ` Heiner Kallweit
2023-01-20 10:52 ` Heiner Kallweit
2023-01-20 10:52 ` Heiner Kallweit
2023-01-20 10:52 ` Heiner Kallweit
2023-01-20 12:48 ` Jerome Brunet
2023-01-20 12:48 ` Jerome Brunet
2023-01-20 12:48 ` Jerome Brunet
2023-01-19 22:56 ` [PATCH net-next] net: mdio: mux-meson-g12a: use devm_clk_get_enabled to simplify the code Heiner Kallweit
2023-01-19 22:56 ` Heiner Kallweit
2023-01-19 22:56 ` Heiner Kallweit
2023-01-20 10:14 ` Jerome Brunet
2023-01-20 10:14 ` Jerome Brunet
2023-01-20 10:14 ` Jerome Brunet
2023-01-23 14:50 ` patchwork-bot+netdevbpf
2023-01-23 14:50 ` patchwork-bot+netdevbpf
2023-01-23 14:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e75ed56f-ba25-f337-e879-33cc2a784740@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=kuba@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.