Provide an option to change RGMII delay value via devicetree.

v4:
- Remove VSC8531_02 support. Existing code will identify VSC8531_01/02
and there is no unique functionality to be added for either version.
- Correct type of rx/tx_delay to accept correct return value.
- Added Andrew's tag to patch 1

Lore link for v3: 
https://lore.kernel.org/netdev/20230511120808.28646-1-harini.katakam@amd.com/

v3 changes:
- Remove patch 2/3 from v2 as custom mscc properties dont need to be
defined. rx-internal-delay-ps and tx-internal-delay-ps can be used.
- Change RGMII delay precedence as advised by Vladimir:
 phy-mode                       rgmii                          rgmii-rxid/rgmii-id
 --------------------------------------------------------------------------------------------
 rx-internal-delay-ps absent    0.2 ns                         2 ns
 rx-internal-delay-ps present   follow rx-internal-delay-ps    follow rx-internal-delay-ps
- Split VSC8531-02 and RGMII delay config into separate patches.
- Correct vendor ID
- Update commit description and subject everywhere to say RGMII delays
instead of RGMII tuning.

v2 changes:
- Added patch to use a common vendor phy id match
- Removed dt include header patch because delays should be specied in
ps, not register values
- Updated DT binding description and commit for optional delay tuning to
be clearer on the precedence
- Updated dt property name to include vendor instead of phy device name
- Switch both VSC8531 and VSC8531-02 to use exact phy id match as they
share the same model number
- Ensure RCT
- Improve optional property read

Harini Katakam (2):
  phy: mscc: Use PHY_ID_MATCH_VENDOR to minimize PHY ID table
  phy: mscc: Add support for RGMII delay configuration

 drivers/net/phy/mscc/mscc.h      |  3 ++
 drivers/net/phy/mscc/mscc_main.c | 49 +++++++++++++++++++-------------
 2 files changed, 32 insertions(+), 20 deletions(-)

-- 
2.17.1

Hi Harini,

On Mon, May 22, 2023 at 05:58:27PM +0530, Harini Katakam wrote:
> Provide an option to change RGMII delay value via devicetree.
> 
> v4:
> - Remove VSC8531_02 support. Existing code will identify VSC8531_01/02
> and there is no unique functionality to be added for either version.
> - Correct type of rx/tx_delay to accept correct return value.
> - Added Andrew's tag to patch 1

Would you mind waiting until this patch set for "net" is merged first,
then rebasing your "net-next" work on top of it?
https://patchwork.kernel.org/project/netdevbpf/cover/20230523153108.18548-1-david.epping@missinglinkelectronics.com/

You should be able to resend your patch set tomorrow, after the net pull
request and the subsequent net -> net-next merge.

There are going to be merge conflicts if your series gets applied
simultaneously, and they're ugly enough that I would prefer you to deal
with them locally, before submitting, rather than leaving the netdev
maintainers do it.

Hi Vladimir,

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Sent: Wednesday, May 24, 2023 3:27 PM
> To: Katakam, Harini <harini.katakam@amd.com>
> Cc: andrew@lunn.ch; hkallweit1@gmail.com; linux@armlinux.org.uk;
> davem@davemloft.net; kuba@kernel.org; edumazet@google.com;
> pabeni@redhat.com; wsa+renesas@sang-engineering.com;
> simon.horman@corigine.com; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; harinikatakamlinux@gmail.com; Simek, Michal
> <michal.simek@amd.com>; Pandey, Radhey Shyam
> <radhey.shyam.pandey@amd.com>
> Subject: Re: [PATCH net-next v4 0/2] Add support for VSC85xx DT RGMII
> delays
> 
> Hi Harini,
> 
> On Mon, May 22, 2023 at 05:58:27PM +0530, Harini Katakam wrote:
> > Provide an option to change RGMII delay value via devicetree.
> >
> > v4:
> > - Remove VSC8531_02 support. Existing code will identify VSC8531_01/02
> > and there is no unique functionality to be added for either version.
> > - Correct type of rx/tx_delay to accept correct return value.
> > - Added Andrew's tag to patch 1
> 
> Would you mind waiting until this patch set for "net" is merged first, then
> rebasing your "net-next" work on top of it?
> https://patchwork.kernel.org/project/netdevbpf/cover/20230523153108.1854
> 8-1-david.epping@missinglinkelectronics.com/
> 
> You should be able to resend your patch set tomorrow, after the net pull
> request and the subsequent net -> net-next merge.
> 
> There are going to be merge conflicts if your series gets applied
> simultaneously, and they're ugly enough that I would prefer you to deal with
> them locally, before submitting, rather than leaving the netdev maintainers do
> it.

Ok sure, I'll wait and rebase after the above set is merged.

Regards,
Harini