[PATCH 2/4] net: phy: marvell: Allow targets to skip MII RX/TX errata

[Timothy Pearson]

----- Original Message -----
> From: "Paul Fertser" <fercerpav at gmail.com>
> To: "Timothy Pearson" <tpearson at raptorengineering.com>
> Cc: "openbmc" <openbmc at lists.ozlabs.org>
> Sent: Friday, March 21, 2025 12:43:12 PM
> Subject: Re: [PATCH 2/4] net: phy: marvell: Allow targets to skip MII RX/TX errata

> On Fri, Mar 21, 2025 at 11:30:04AM -0500, Timothy Pearson wrote:
>>  application
> 
> A rather uninformative commit message again.
> 
>> Upstream-Status: Pending
> 
> Pending what exactly and why? I guess you're supposed to send your
> series upstream (to Linux devs) first, then after they're accepted you
> can ask for backporting them to OpenBMC tree. There're exceptions but
> you need to provide a rather convincing reason for that I guess. I'm
> not saying that in any official capacity, just as a sidenote, Joel
> will clarify if I'm wrong.
> 
>> +if PHY_MARVELL
>> +
>> +config PHY_MARVELL_APPLY_MII_RXTX_ERRATA
>> +	bool
>> +	default n
>> +
>> +endif # PHY_MARVELL
> 
> This doesn't seem to be the right approach at all. If it needs to be
> specified per board, you need to add it to Device Tree schema and
> those Device Tree board files that are affected.
> 
>> +		/* Per the vendor, certain Marvell devices will not function if
>> +		 * the RGMII TX/RX delay registers are modified.  If an
>> +		 * affected design has been selected, do not write the
>> +		 * RX/TX delay registers.
>> +		 */
> 
> This doesn't say much. Please reference the actual errata document
> number or cite its text or find some other way to explain which
> devices are affected how. Proper implementation depends a lot on those
> details.

Understood.  I am navigating a bit of a sea of NDA restricted / proprietary components here, apologies for the lack of detail.

Let me see if I can get that information and get approval for public disclosure.  These patches are in support of the SIE Cronos board, which unfortunately was designed by a third party without proper U-boot / OpenBMC integration in mind.  As a result, there are unique hardware decisions that were made, and the DT is not authoritative on these platforms.