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

[Jonas Gorski]

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.

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.


Best regards
Jonas

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