[OpenWrt-Devel] [PATCH 2/4] kernel: add backported phy/phylink/sfp patches

[Jonas Gorski]

On Wed, 27 Nov 2019 at 14:27, Russell King - ARM Linux admin
<linux at armlinux.org.uk> wrote:
>
> On Wed, Nov 27, 2019 at 02:03:40PM +0100, Jonas Gorski wrote:
> > On Wed, 27 Nov 2019 at 13:14, Russell King - ARM Linux admin
> > <linux at armlinux.org.uk> wrote:
> > >
> > > On Wed, Nov 27, 2019 at 12:57:35PM +0100, Petr Štetiar wrote:
> > > > Russell King - ARM Linux admin <linux at armlinux.org.uk> [2019-11-27 10:35:10]:
> > > >
> > > > > It makes it very difficult to understand.  For example, where is the
> > > > > kernel + kmod package version/release set
> > > >
> > > > from kmod-libphy_4.19.85-1_aarch64_cortex-a53.ipk/control.tar.gz/control:
> > > >
> > > >  Package: kmod-libphy
> > > >  Version: 4.19.85-1
> > > >  Depends: kernel (=4.19.85-1-f24e301be88eb921523d0eb26012ec0f)
> > > >
> > > > I'm interested how the Version: is set:
> > > >
> > > >  $ git grep Version: include/
> > > >  include/package-dumpinfo.mk:)Version: $(VERSION)
> > > >
> > > > So then I need to know how the VERSION is set:
> > > >
> > > >  $ git grep VERSION.*:.*= include/kernel*
> > > >  include/kernel.mk:    VERSION:=$(LINUX_VERSION)$(if $(PKG_VERSION),+$(PKG_VERSION))-$(if $(PKG_RELEASE),$(PKG_RELEASE),$(LINUX_RELEASE))
> > > >
> > > > So from above it's PKG_RELEASE or LINUX_RELEASE now:
> > > >
> > > >  $ git grep -E '(PKG_RELEASE|LINUX_RELEASE)' include/kernel*
> > > >  include/kernel-version.mk:LINUX_RELEASE?=1
> > > >
> > > > So in order to bump the release in the 4.19.85-1 from 1 to 2 I would probably
> > > > need to set LINUX_RELEASE:=2 somewhere in the Make files or provide it to Make
> > > > via commandline, as `make ... LINUX_RELEASE=2`.
> > >
> > > Thanks, that's useful information.
> >
> > To add to this, the f24e301be88eb921523d0eb26012ec0f part is the hash
> > of the kernel config used during the build of the module/kernel. This
> > is to avoid installing kernel modules build with a different ABI due
> > to different config.
> >
> > See https://github.com/openwrt/openwrt/blob/master/include/kernel-defaults.mk#L108
> > for how it's generated.
> >
> > > > > > AFAIK Jonas plans to borrow few SFP modules and test this on his ClearFog PRO
> > > > > > and he is eventually going to merge this as well.
> > > > >
> > > > > Surely only one person should be merging this?
> > > >
> > > > I'm not implying that, but Jonas is already involved and has access to the
> > > > actual hardware, so it makes sense to let him test and merge it.
> > >
> > > Hmm, so you're saying that the mainline kernel maintainer (me)
> > > shouldn't be pushing these patches for OpenWrt, because you don't
> > > trust me to test them, despite testing them on the uDPU, SolidRun
> > > Clearfog and cex7 platforms with multiple different SFP and SFP+
> > > modules from several vendors.
> > >
> > > Instead you'd rather trust someone with only one SFP module, who's
> > > patch that was merged into OpenWrt will break some modules that
> > > have been tested to work with the upstream kernel?
> > >
> > > Sound sane?
> > >
> > > I think you're actually confused about what I've asked Jonas to do.
> > > I haven't asked him to test these patches with a view to merging
> > > them, I've asked him to report back what the situation is with this
> > > patch set without his "450-reprobe_sfp_phy" patch applied, which
> > > never made it into the upstream kernel - and then we'll work on a
> > > way to make his module work with *both* OpenWrt and the mainline
> > > kernel.
> >
> > The bit you are probably missing is that I also happen to be an
> > OpenWrt maintainer with commit access.
> >
> > So unless you also have commit access yourself you would need someone
> > from the maintainer group to accept and merge your patches. And since
> > I have access to a device with an SFP port, I can do both the checks
> > you asked me to do as well as do the merge. Two birds with one stone
> > ;-)
> >
> > And sometimes changes can have unexpected side effects due to the
> > amount of local patches we have for each target, and I don't expect
> > anyone to be aware of all of them, or having tested all of them.
>
> Well, I expect your testing to fail, because your module is likely
> non-compliant in regard of holding the TX_FAULT signal active while
> it is initialising - but then most copper modules behave the same
> way, just for a shorter time.
>
> Given that your testing won't be successful, what do we do?

The testing doesn't need to succeed to be successful, it just needs to
not break anything else (in a obvious way).

I probably see that it still tries to detect the problematic SFP
module (and then fail to probe the PHY), test a few others that
hopefully do work (I can borrow some other modules from work), maybe
check one or two other 4.19 based targets to do a simple check for any
side effects to other targets, then merge it.

> Or are you proposing just a compile test?
>
> > I hope that clears it a bit up? Nothing about not trusting you and
> > your code, just not trusting it blindly. Especially since you
> > mentioned having issues with the OpenWrt build system.
>
> The build system is just very painful for a new-comer to understand.
> I don't doubt that it does what you need it to, but trying to work
> out stuff from it is a nightmare unless you have some knowledge
> about how it is setup.
>
> For example, referencing:
>
>  https://openwrt.org/docs/guide-developer/single.package
>
> and trying to build just the kernel.  So:
>
>  $ make tools/install
>  $ make toolchain/install
>  $ make target/linux/install
>
> fails because there is no opkg host tool present.

Congratulations, you found a bug!

Looks like there is a missing dependency in the build system. Feel
free to report it [1]. I might take a look at it regardless.

But there also is a systemic issue that there is no separate "compile
the kernel" build target, and it's mixed with the "assemble the rootfs
and images" step - which then requires opkg (and everything else).

So in all likelihood even with the dependency fixed it would have then
tried to build everything anyway, as target/linux/install is one of
the last steps in the build process.

>
> Trying to find out how to build opkg is really not easy.  You find
> "host-compile" and "host-install" targets in the makefiles, so you
> assume that if you try make package/system/opkg/host-install, maybe
> it'll install a host built opkg into staging_dir/host/bin - but no,
> that doesn't work.  That seems to be utterly impossible to do.
> That has alone made me develop a great hate for the implementation
> after spending a lot of time trying to figure it out.

I can understand that frustration, good documentation is hard to come
by. For me most of these things are "obvious" and "easy" since I'm
working since decades with it, but a lot of it is not really well
documented, or even at all.

>
> The only way seems to be to use plain "make" in the top level
> directory - so the information in the above URL is plainly
> misleading.  If you haven't been through the entire configuration
> in 'make menuconfig' before, you end up having to build an entire
> OpenWrt system - which really isn't nice if you're either limited
> with disk space or on a 'net connection with a limited monthly
> allowance.

I can also understand this frustration.

I don't know it it helps in the future, but there is a "make download"
command to make it just download everything, which might be helpful if
you can pre-download everything at work/mc-donalds/whereever you don't
have a metered connection, and then do the build later at home where
you are limited by the monthly allowance.

Best regards,
Jonas

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel