Re: [PATCH] ARM: mvebu_v7_defconfig: fix Ethernet on Clearfog

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Tue, Jun 11, 2019 at 01:28:32PM +0200, Gregory CLEMENT wrote:
> Jan Kundrát <jan.kundrat@cesnet.cz> writes:
> 
> > On sobota 18. května 2019 0:50:28 CEST, Jan Kundrát wrote:
> >>> Well, this is just about configuration, I don't consider this is
> >>> something that is a candidate for a fix.
> >>> 
> >>> If there is a regression, then, it is maybe located in the Kconfig
> >>> dependency.
> >>> 
> >>> Of course I can change my mind with good arguments :)
> >>
> >> Hi Gregory,
> >> I agree that it's just a config bug, but it's also something 
> >> which can silently produce broken systems. If this is not fixed, 
> >> people building their 5.2 kernels will not have working network 
> >> on Clearfog unless they take an extra action. For example, a 
> >> Buildroot defconfig that's been available for quite some time 
> >> (and which uses just `mvebu_v7_defconfig` for kernel) suddenly 
> >> becomes broken.
> >>
> >> Isn't the whole point of the -rc release to find *and* fix bugs 
> >> early? This trivial patch does not introduce any new or untested 
> >> code. I made a choice to test a pre-release kernel, I hit a bug 
> >> -- no big deal. I found the root cause, I sent a trivial fix 
> >> upstream, and now I'm told by a maintainer that they will let 
> >> the next kernel version, which is about seven -rc releases away, 
> >> be released without a fully functioning network, I am surprised 
> >> by that. I would have understood this better if we were at the 
> >> final -rc stage, but during the merge window? Or is that perhaps 
> >> a misunderstanding and you're planning to send this in time 
> >> after -rc1?
> >
> > Hi Gregory,
> > was I successful in persuading you that this patch should be included in 
> > the 5.2 tree, so that Clearfog Base has all three Ethernet interfaces?
> 
> Finally I moved the commit from mvebu/arm to mvebu/fixes. I still think
> the problem is at driver level, but I didn't take enough time to find
> where and we didn't have any feedback from the author of the initila
> patch.

I don't see that there's much that I need to say, and I'm at a total
loss to work out why you think it's a problem at driver level.

Why do you think it's appropriate for mvneta to know whether the a38x
comphy driver is configured for the current kernel or not, given that
mvneta is not exclusively used on Armada 38x systems?

We're already doing the best we can do with ignoring the comphy if
not present; the only case that we defer probe is when
devm_of_phy_get() returns -EPROBE_DEFER, which could mean "the comphy
driver is a module but is not loaded yet" or "the comphy driver has
not been probed yet" - we can't ignore those.

> So let's try to push it to fixes, I will do the pull request for arm-soc
> before end of the week.

That's the correct solution, and it should also have a Fixes: tag on
it.  Unfortunately, keeping the defconfigs up to date is quite a hard
problem unless you have lots of computing power to build and boot all
the defconfigs on all platforms (I don't.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel