[PATCH net 0/4] net: axienet: Fix deferred probe loop

Sean Anderson posted 4 patches 3 months, 3 weeks ago
There is a newer version of this series
drivers/base/auxiliary.c                      |   6 +-
drivers/net/ethernet/xilinx/Kconfig           |   1 +
.../net/ethernet/xilinx/xilinx_axienet_main.c | 391 +++++++++---------
.../net/ethernet/xilinx/xilinx_axienet_mdio.c |  32 +-
include/linux/auxiliary_bus.h                 |   4 +-
5 files changed, 234 insertions(+), 200 deletions(-)
[PATCH net 0/4] net: axienet: Fix deferred probe loop
Posted by Sean Anderson 3 months, 3 weeks ago
Upon further investigation, the EPROBE_DEFER loop outlined in [1] can
occur even without the PCS subsystem, as described in patch 4/4. The
second patch is a general fix, and could be applied even without the
auxdev conversion.

[1] https://lore.kernel.org/all/20250610183459.3395328-1-sean.anderson@linux.dev/


Sean Anderson (4):
  auxiliary: Allow empty id
  net: axienet: Fix resource release ordering
  net: axienet: Rearrange lifetime functions
  net: axienet: Split into MAC and MDIO drivers

 drivers/base/auxiliary.c                      |   6 +-
 drivers/net/ethernet/xilinx/Kconfig           |   1 +
 .../net/ethernet/xilinx/xilinx_axienet_main.c | 391 +++++++++---------
 .../net/ethernet/xilinx/xilinx_axienet_mdio.c |  32 +-
 include/linux/auxiliary_bus.h                 |   4 +-
 5 files changed, 234 insertions(+), 200 deletions(-)

-- 
2.35.1.1320.gc452695387.dirty
Re: [PATCH net 0/4] net: axienet: Fix deferred probe loop
Posted by Greg Kroah-Hartman 3 months, 2 weeks ago
On Thu, Jun 19, 2025 at 04:05:33PM -0400, Sean Anderson wrote:
> Upon further investigation, the EPROBE_DEFER loop outlined in [1] can
> occur even without the PCS subsystem, as described in patch 4/4. The
> second patch is a general fix, and could be applied even without the
> auxdev conversion.
> 
> [1] https://lore.kernel.org/all/20250610183459.3395328-1-sean.anderson@linux.dev/

I have no idea what this summary means at all, which isn't a good start
to a patch series :(

What problem are you trying to solve?  What overall solution did you
come up with?  Who is supposed to be reviewing any of this?

totally confused,

greg k-h
Re: [PATCH net 0/4] net: axienet: Fix deferred probe loop
Posted by Sean Anderson 3 months, 2 weeks ago
On 6/20/25 01:10, Greg Kroah-Hartman wrote:
> On Thu, Jun 19, 2025 at 04:05:33PM -0400, Sean Anderson wrote:
>> Upon further investigation, the EPROBE_DEFER loop outlined in [1] can
>> occur even without the PCS subsystem, as described in patch 4/4. The
>> second patch is a general fix, and could be applied even without the
>> auxdev conversion.
>> 
>> [1] https://lore.kernel.org/all/20250610183459.3395328-1-sean.anderson@linux.dev/
> 
> I have no idea what this summary means at all, which isn't a good start
> to a patch series :(
> 
> What problem are you trying to solve?

See patch 4/4.

> What overall solution did you come up with?

See patch 4/4.

> Who is supposed to be reviewing any of this?

Netdev. Hence "PATCH net".

And see [1] above for background. I will quote it more-extensively next time.

--Sean
Re: [PATCH net 0/4] net: axienet: Fix deferred probe loop
Posted by Greg Kroah-Hartman 3 months, 2 weeks ago
On Fri, Jun 20, 2025 at 11:41:52AM -0400, Sean Anderson wrote:
> On 6/20/25 01:10, Greg Kroah-Hartman wrote:
> > On Thu, Jun 19, 2025 at 04:05:33PM -0400, Sean Anderson wrote:
> >> Upon further investigation, the EPROBE_DEFER loop outlined in [1] can
> >> occur even without the PCS subsystem, as described in patch 4/4. The
> >> second patch is a general fix, and could be applied even without the
> >> auxdev conversion.
> >> 
> >> [1] https://lore.kernel.org/all/20250610183459.3395328-1-sean.anderson@linux.dev/
> > 
> > I have no idea what this summary means at all, which isn't a good start
> > to a patch series :(
> > 
> > What problem are you trying to solve?
> 
> See patch 4/4.

That's not what should be in patch 0/4 then, right?

> > What overall solution did you come up with?
> 
> See patch 4/4.

Again, why write a 0/4 summary at all then?

> > Who is supposed to be reviewing any of this?
> 
> Netdev. Hence "PATCH net".
> 
> And see [1] above for background. I will quote it more-extensively next time.

Referring to random links doesn't always work as we deal with thousands
of patches daily, and sometimes don't even have internet access (like
when reviewing patches on long flights/train rides...)

Make things self-contained please.

thanks,

greg k-h
Re: [PATCH net 0/4] net: axienet: Fix deferred probe loop
Posted by Sean Anderson 3 months, 2 weeks ago
On 6/20/25 12:01, Greg Kroah-Hartman wrote:
> On Fri, Jun 20, 2025 at 11:41:52AM -0400, Sean Anderson wrote:
>> On 6/20/25 01:10, Greg Kroah-Hartman wrote:
>> > On Thu, Jun 19, 2025 at 04:05:33PM -0400, Sean Anderson wrote:
>> >> Upon further investigation, the EPROBE_DEFER loop outlined in [1] can
>> >> occur even without the PCS subsystem, as described in patch 4/4. The
>> >> second patch is a general fix, and could be applied even without the
>> >> auxdev conversion.
>> >> 
>> >> [1] https://lore.kernel.org/all/20250610183459.3395328-1-sean.anderson@linux.dev/
>> > 
>> > I have no idea what this summary means at all, which isn't a good start
>> > to a patch series :(
>> > 
>> > What problem are you trying to solve?
>> 
>> See patch 4/4.
> 
> That's not what should be in patch 0/4 then, right?
> 
>> > What overall solution did you come up with?
>> 
>> See patch 4/4.
> 
> Again, why write a 0/4 summary at all then?

So if I decide in v2 that some patch other than "auxiliary: Allow empty
id" has to come first then the series still has the same subject. This
makes it easier for maintainers to figure out which v1 the v2 is for.

>> > Who is supposed to be reviewing any of this?
>> 
>> Netdev. Hence "PATCH net".
>> 
>> And see [1] above for background. I will quote it more-extensively next time.
> 
> Referring to random links doesn't always work as we deal with thousands
> of patches daily, and sometimes don't even have internet access (like
> when reviewing patches on long flights/train rides...)

Well, the link contains the message-id, so you are more than welcome to
look it up in your email client. But to spare you the trouble I will
quote from it next time in addition to linking.

--Sean