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

Wed Nov 27 08:27:49 EST 2019

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?

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.

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.

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.

So, I find the build system very limiting and problematical, but
that doesn't mean that I've been hacking around it - the only
changes are those that I've published plus the addition of one
additional kernel patch file.

-- 
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

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