Re: [PATCH net-next v8 0/7] net: pse-pd: decouple controller lookup from MDIO probe

[Kyle Swenson <kyle.swenson@est.tech>]

Hello Carlo,

On Tue, Oct 13, 2026 at 11:09:33AM +0200, Carlo Szelinsky wrote:
> On 10/13/26 10:39, Kory Maincent wrote:
> > On 10/13/26 09:40, Paolo Abeni wrote:
> >> @Carlo: you should always reply to the AI review, even to point out
> >> previous discussion on the same point. And you should try to be more
> >> concise (even in the cover latter, should a repost be needed).
> >
> > Indeed, the cover letter should be more concise. It's hard to read like 
> > that.
> 
> Hi Köry, hi Paolo,
> 
> Thanks for the feedback. I will reply to the AI review points and make
> the cover letter shorter.
> 
> I am already working on v9, because some of the AI findings are real.
> So if you don't mind, you may want to wait for v9 before reviewing.
> 
> Thanks,
> Carlo
> 

I just wanted to give some words of encouragement after having gone
through the past versions of your series and all the sashiko reviews...

I've been pulling your series off the list pretty regularly to fix
exactly the core problem you're trying to solve: that is, a pse driver
built as a module causes the netdevs associated with a PI to
EPROBE_DEFER until the module is probed.  I hit this with the LTC4266
driver I've posted, and since that platform has a cascaded DSA setup
with two switches, building the pse driver as a module resulted in no
netdevs.

Beyond just words here, if you add me to cc for your next revisions,
I'll pull it and test it locally with the LTC4266 driver I've got up on
the list.  Even if you don't, I'll look for the updated series, test it,
and then if it (still) works to solve the EPROBE_DEFER problem when the
ltc4266 is built as module, I'll offer my Tested-by tag.

Cheers, and keep it up!

Thanks,
Kyle