From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Luo Jie <quic_luoj@quicinc.com>
Cc: agross@kernel.org, andersson@kernel.org,
konrad.dybcio@linaro.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, andrew@lunn.ch, hkallweit1@gmail.com,
robert.marko@sartura.hr, linux-arm-msm@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_srichara@quicinc.com
Subject: Re: [PATCH v4 1/5] net: mdio: ipq4019: move eth_ldo_rdy before MDIO bus register
Date: Tue, 2 Jan 2024 17:24:45 +0000 [thread overview]
Message-ID: <ZZRG3eZJM5QouR9+@shell.armlinux.org.uk> (raw)
In-Reply-To: <20231225084424.30986-2-quic_luoj@quicinc.com>
On Mon, Dec 25, 2023 at 04:44:20PM +0800, Luo Jie wrote:
> +/* Maximum SOC PCS(uniphy) number on IPQ platform */
> +#define ETH_LDO_RDY_CNT 3
> +
> struct ipq4019_mdio_data {
> - void __iomem *membase;
> - void __iomem *eth_ldo_rdy;
> + void __iomem *membase;
> + void __iomem *eth_ldo_rdy[ETH_LDO_RDY_CNT];
Do you have any plans to make use of eth_ldo_rdy other than by code that
you touch in this patch? If you don't, what is the point of storing
these points in struct ipq4019_mdio_data ? You're using devm_ioremap()
which will already store the pointer internally to be able to free the
resource at the appropriate moment, so if your only use is shortly after
devm_ioremap(), you can use a local variable for this... meaning this
becomes (in addition to the other suggestion):
> + /* This resource are optional */
> + for (index = 0; index < ETH_LDO_RDY_CNT; index++) {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, index + 1);
> + if (res) {
> + priv->eth_ldo_rdy[index] = devm_ioremap(&pdev->dev,
> + res->start,
> + resource_size(res));
> +
> + /* The ethernet LDO enable is necessary to reset PHY
> + * by GPIO, some PHY(such as qca8084) GPIO reset uses
> + * the MDIO level reset, so this function should be
> + * called before the MDIO bus register.
> + */
> + if (priv->eth_ldo_rdy[index]) {
> + u32 val;
> +
> + val = readl(priv->eth_ldo_rdy[index]);
> + val |= BIT(0);
> + writel(val, priv->eth_ldo_rdy[index]);
> + fsleep(IPQ_PHY_SET_DELAY_US);
> + }
> + }
void __iomem *eth_ldo_rdy;
u32 val;
res = platform_get_resource(pdev, IORESOURCE_MEM, index + 1);
if (!res)
break;
eth_ldo_rdy = devm_ioremap(&pdev->dev, res->start,
resource_size(res));
if (!eth_ldo_rdy)
continue;
val = readl(eth_ldo_rdy) | BIT(0);
writel(val, eth_ldo_rdy);
... whatever sleep is deemed required ...
Other issues:
1. if devm_ioremap() fails (returns NULL) is it right that we should
just ignore that resource?
2. Do you need to sleep after each write, or will sleeping after
writing all of these do? It may be more efficient to detect when
we have at least one eth_ldo_rdy and then sleep once.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-01-02 17:25 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-25 8:44 [PATCH v4 0/5] support ipq5332 platform Luo Jie
2023-12-25 8:44 ` [PATCH v4 1/5] net: mdio: ipq4019: move eth_ldo_rdy before MDIO bus register Luo Jie
2023-12-28 9:49 ` Konrad Dybcio
2023-12-30 3:15 ` Jie Luo
2024-01-02 17:24 ` Russell King (Oracle) [this message]
2024-01-03 13:27 ` Jie Luo
2023-12-25 8:44 ` [PATCH v4 2/5] net: mdio: ipq4019: enable the SoC uniphy clocks for ipq5332 platform Luo Jie
2024-01-03 9:48 ` Bryan O'Donoghue
2024-01-03 13:25 ` Jie Luo
2023-12-25 8:44 ` [PATCH v4 3/5] net: mdio: ipq4019: configure CMN PLL clock for ipq5332 Luo Jie
2024-01-03 9:50 ` Bryan O'Donoghue
2024-01-03 13:06 ` Jie Luo
2023-12-25 8:44 ` [PATCH v4 4/5] net: mdio: ipq4019: support MDIO clock frequency divider Luo Jie
2023-12-25 8:44 ` [PATCH v4 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332 platform Luo Jie
2023-12-25 10:29 ` Krzysztof Kozlowski
2023-12-26 7:25 ` Jie Luo
2023-12-26 9:28 ` Krzysztof Kozlowski
2023-12-26 12:21 ` Conor Dooley
2023-12-26 13:14 ` Jie Luo
2023-12-26 13:19 ` Krzysztof Kozlowski
2023-12-28 7:36 ` Jie Luo
2023-12-26 13:06 ` Jie Luo
2023-12-26 13:18 ` Krzysztof Kozlowski
2023-12-28 7:38 ` Jie Luo
2024-01-04 7:47 ` Krzysztof Kozlowski
2024-01-04 10:06 ` Jie Luo
2024-01-01 23:01 ` [PATCH v4 0/5] support " Sergey Ryazanov
2024-01-03 13:31 ` Jie Luo
2024-01-05 2:48 ` Sergey Ryazanov
2024-01-05 10:34 ` Jie Luo
2024-01-06 1:24 ` Sergey Ryazanov
2024-01-06 15:45 ` Andrew Lunn
2024-01-06 22:03 ` Sergey Ryazanov
2024-01-07 16:08 ` Andrew Lunn
2024-01-08 9:06 ` Jie Luo
2024-01-08 9:01 ` Jie Luo
2024-01-08 13:27 ` Andrew Lunn
2024-01-09 11:33 ` Jie Luo
2024-01-08 15:53 ` Russell King (Oracle)
2024-01-09 11:35 ` Jie Luo
2024-01-05 13:52 ` Andrew Lunn
2024-01-05 15:42 ` Alex Elder
2024-01-05 20:14 ` Sergey Ryazanov
2024-01-08 9:30 ` Jie Luo
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=ZZRG3eZJM5QouR9+@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_luoj@quicinc.com \
--cc=quic_srichara@quicinc.com \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).