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

Andrew Jeffery andrew at codeconstruct.com.au
Mon Mar 24 15:55:39 AEDT 2025


On Sat, 2025-03-22 at 23:20 +0300, Paul Fertser wrote:
> On Sat, Mar 22, 2025 at 12:24:23PM -0500, Timothy Pearson wrote:
> > > On Fri, Mar 21, 2025 at 08:43:12PM +0300, Paul Fertser wrote:
> > > > On Fri, Mar 21, 2025 at 11:30:04AM -0500, Timothy Pearson wrote:
> > > > > 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.
> > > 
> > > Huh, it wasn't at all obvious to me that your patches were meant for
> > > U-boot, not Linux, sorry (and you didn't specify that in the
> > > subject). There slightly different rules apply, but in general my
> > > comments should all be still relevant. Overall impression I got is
> > > that you're adding a bunch of hacks and that most things about them
> > > would need to be heavily reworked to become digestible for upstream. I
> > > hope more experienced developers will correct me if I'm wrong here.
> ...
> > 
> > I am assuming that new OpenBMC platforms can be merged into the
> > U-boot tree here vs. upstream U-boot, as upstream doesn't fully
> > support the ASpeed device?  When I attempted to apply and test to
> > upstream, there was a lot of missing code and it wasn't clear at all
> > that the result would ever be bootable on typical OpenBMC hardware
> > designs.
> 
> It looks like like the current state is that people send patches like
> [0] and [1] (notice the subject line, recepients, informative commit
> messages etc), 
> 

Timothy: Yes, please put some effort into conforming to community
expectations such as those outlined by Paul, as well as producing a
properly threaded series of patches under a cover letter.

> then it gets synced to OpenBMC by changes like [2],
> then probably it used to propogate to Aspeed [3] (interesting how they
> have a much newer branch but everybody is still stuck at v2019 one).

I'm short of time for the most part, but if people would like more
recent trees then maybe we can start to identify where the work is and
coordinate on making progress.

Andrew



More information about the openbmc mailing list