From: Dimitri Fedrau <dima.fedrau@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
dimitri.fedrau@liebherr.com, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Andrew Davis <afd@ti.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v3 2/3] net: phy: Add helper for getting tx amplitude gain
Date: Thu, 6 Feb 2025 10:40:20 +0100 [thread overview]
Message-ID: <20250206094020.GA4585@debian> (raw)
In-Reply-To: <b28755b0-9104-4295-8cd3-508818445a4b@lunn.ch>
Am Wed, Feb 05, 2025 at 06:08:47PM +0100 schrieb Andrew Lunn:
> On Wed, Feb 05, 2025 at 06:22:18AM +0100, Dimitri Fedrau wrote:
> > Am Tue, Feb 04, 2025 at 05:54:53PM +0000 schrieb Russell King (Oracle):
> > > On Tue, Feb 04, 2025 at 02:09:16PM +0100, Dimitri Fedrau via B4 Relay wrote:
> > > > #if IS_ENABLED(CONFIG_OF_MDIO)
> > > > -static int phy_get_int_delay_property(struct device *dev, const char *name)
> > > > +static int phy_get_u32_property(struct device *dev, const char *name)
> > > > {
> > > > s32 int_delay;
> > > > int ret;
> > > > @@ -3108,7 +3108,7 @@ static int phy_get_int_delay_property(struct device *dev, const char *name)
> > > > return int_delay;
> > >
> > > Hmm. You're changing the name of this function from "int" to "u32", yet
> > > it still returns "int".
> > >
> >
> > I just wanted to reuse code for retrieving the u32, I found
> > phy_get_int_delay_property and renamed it. But the renaming from "int"
> > to "u32" is wrong as you outlined.
> >
> > > What range of values are you expecting to be returned by this function?
> > > If it's the full range of u32 values, then that overlaps with the error
> > > range returned by device_property_read_u32().
> > >
> >
> > Values are in percent, u8 would already be enough, so it wouldn't
> > overlap with the error range.
> >
> > > I'm wondering whether it would be better to follow the example set by
> > > these device_* functions, and pass a pointer for the value to them, and
> > > just have the return value indicating success/failure.
> > >
> >
> > I would prefer this, but this would mean changes in phy_get_internal_delay
> > if we don't want to duplicate code, as phy_get_internal_delay relies on
> > phy_get_int_delay_property and we change function parameters of
> > phy_get_int_delay_property as you described. I would switch from
> > static int phy_get_int_delay_property(struct device *dev, const char *name)
> > to
> > static int phy_get_u32_property(struct device *dev, const char *name, u32 *val)
> >
> > Do you agree ?
>
> This looks O.K. You should also rename the local variable int_delay.
>
> Humm, that function has other issues.
>
> static int phy_get_int_delay_property(struct device *dev, const char *name)
> {
> s32 int_delay;
> int ret;
>
> ret = device_property_read_u32(dev, name, &int_delay);
> if (ret)
> return ret;
>
> return int_delay;
> }
>
> int_delay should really be a u32. if ret is not an error, there should
> be a range check to ensure int_long actually fits in an s32, otherwise
> -EINVAL, or maybe -ERANGE.
>
> For delays, we never expect too much more than 2000ps, so no valid DT
> blob should trigger issues here.
>
I think you mention this because you want to avoid changes in
phy_get_internal_delay because this would lead to changes in other
drivers too. Is it worth fixing this ? Then we didn't have to workaround by
checking if int_long actually fits in an s32.
Best regards,
Dimitri Fedrau
next prev parent reply other threads:[~2025-02-06 9:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 13:09 [PATCH net-next v3 0/3] net: phy: dp83822: Add support for changing the transmit amplitude voltage Dimitri Fedrau via B4 Relay
2025-02-04 13:09 ` [PATCH net-next v3 1/3] dt-bindings: net: ethernet-phy: add property tx-amplitude-100base-tx-percent Dimitri Fedrau via B4 Relay
2025-02-04 14:28 ` Rob Herring (Arm)
2025-02-05 4:43 ` Dimitri Fedrau
2025-02-04 15:34 ` Rob Herring
2025-02-05 4:51 ` Dimitri Fedrau
2025-02-04 13:09 ` [PATCH net-next v3 2/3] net: phy: Add helper for getting tx amplitude gain Dimitri Fedrau via B4 Relay
2025-02-04 17:54 ` Russell King (Oracle)
2025-02-05 5:22 ` Dimitri Fedrau
2025-02-05 17:08 ` Andrew Lunn
2025-02-06 9:40 ` Dimitri Fedrau [this message]
2025-02-04 13:09 ` [PATCH net-next v3 3/3] net: phy: dp83822: Add support for changing the transmit amplitude voltage Dimitri Fedrau via B4 Relay
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=20250206094020.GA4585@debian \
--to=dima.fedrau@gmail.com \
--cc=afd@ti.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dimitri.fedrau@liebherr.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@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).