Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 29 Apr 2020 14:27:50 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Yuti Amonkar <yamonkar@cadence.com>
Cc:     linux-kernel@vger.kernel.org, kishon@ti.com, mark.rutland@arm.com,
        jsarha@ti.com, tomi.valkeinen@ti.com, praneeth@ti.com,
        mparab@cadence.com, sjakhade@cadence.com
Subject: Re: [PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to
 set PHY attributes
Message-ID: <20200429122750.hup7vbmz3xnpfwa5@gilmour.lan>
References: <1588057804-29161-1-git-send-email-yamonkar@cadence.com>
 <1588057804-29161-3-git-send-email-yamonkar@cadence.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="pfunkpzcbipvw67a"
Content-Disposition: inline
In-Reply-To: <1588057804-29161-3-git-send-email-yamonkar@cadence.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--pfunkpzcbipvw67a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 28, 2020 at 09:10:04AM +0200, Yuti Amonkar wrote:
> From: Swapnil Jakhade <sjakhade@cadence.com>
>=20
> Use generic PHY framework function phy_set_bus_width() to set number
> of lanes and function phy_set_max_link_rate() to set maximum link rate
> supported by PHY.
>=20
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>

This should have your SoB.

> ---
>  drivers/phy/cadence/phy-cadence-torrent.c | 3 +++
>  1 file changed, 3 insertions(+)
>=20
> diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cade=
nce/phy-cadence-torrent.c
> index 7116127358ee..b914e5ddf93c 100644
> --- a/drivers/phy/cadence/phy-cadence-torrent.c
> +++ b/drivers/phy/cadence/phy-cadence-torrent.c
> @@ -1852,6 +1852,9 @@ static int cdns_torrent_phy_probe(struct platform_d=
evice *pdev)
>  				 cdns_phy->phys[node].num_lanes,
>  				 cdns_phy->max_bit_rate / 1000,
>  				 cdns_phy->max_bit_rate % 1000);
> +
> +			phy_set_bus_width(gphy, cdns_phy->phys[node].num_lanes);
> +			phy_set_max_link_rate(gphy, cdns_phy->max_bit_rate);

I think what Kishon meant in his previous mail is that it's not really clea=
r (to
me at least) how that function would be useful.

In this particular case, what would the consumer make of that information? =
Does
the phy needs to be reconfigured based on the max rate being changed?

Some phy_configure_opts structures also have a somewhat similar field that =
can
be negociated between the provider and the consumer using phy_validate, wou=
ldn't
that be redundant?

Most of that discussion can only happen when you've provided a use-case for=
 that
series, so a consumer using it would help greatly there.

Maxime

--pfunkpzcbipvw67a
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXqlyxgAKCRDj7w1vZxhR
xThKAQC5OdZLjKA1gu+WdGB9xXEOgeEfSI/um2KMqdAy9BYvRgEA5286nZI3e4Ei
hzBjNawMbJBAFARUzhy2ASwB6++dBAM=
=dF3D
-----END PGP SIGNATURE-----

--pfunkpzcbipvw67a--