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: 16+ 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
2025-02-04 13:09 ` 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
2025-02-04 13:09 ` 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
2025-02-04 13:09 ` 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
2025-02-04 13:09 ` 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 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.