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

Wed Nov 27 05:35:10 EST 2019

On Wed, Nov 27, 2019 at 09:50:45AM +0100, Petr Štetiar wrote:
> Russell King - ARM Linux admin <linux at armlinux.org.uk> [2019-11-26 00:07:43]:
> 
> Hi,
> 
> > I can see your reply in the OpenWrt archives, but I never received
> > it, so I can't reply to it...  (I'm not subscribed to openwrt-devel.)
> 
> FYI René just didn't Cc: you.

Yes, I guessed as much, as some mailing lists are switching to a "reply
to list" policy - which is fine if you can guarantee that all who post
there are subscribed.  With an open list, you end up with exactly this
problem.

> > My impression is that the build system is designed to keep people out!
> 
> You mean Make was designed to keep people out? :-)
> 
> Puting jokes aside, if you imagine, that OpenWrt provides complete flashable
> images (bootloader, kernel, modules, firmware, userspace, web UI), packages
> with package manager, package feeds, SDK, image builder and all of this for
> insane number of platforms and devices. Then add Linux/macOS/WSL host build
> systems in the mix and you'll end up with pretty complex prerequisites.

It makes it very difficult to understand.  For example, where is the
kernel + kmod package version/release set - and should it be
incremented so that opkg on the target doesn't mess up it's "status"
file when reinstalling the kmod packages?  (Yes, I've had to manually
edit that file to get rid of any entry with "install ok not-installed"
status, because opkg won't do _anything_ with those.

> > Some guidance would be most helpful.  Silence on the other hand
> > will result in nothing changing.
> 
> 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?

> > 1) as these are touching phy code, using 7xx numbers would be
> >    reasonable  Or maybe 0xx for at least some?
> 
> It's just a soft guidance, not pedantic system, I mean if you look at mvebu
> patches, you can see net/phy related patches with 5xx numbering scheme.
> Sometimes it's being done on purpose, in order to make refreshing of patches
> easier and/or to avoid clashes with some other patches.
> 
> If you take a look in include/quilt.mk you'll find out following:
> 
>  $(call PatchDir,$(LINUX_DIR),$(GENERIC_BACKPORT_DIR),generic-backport/)
>  $(call PatchDir,$(LINUX_DIR),$(GENERIC_PATCH_DIR),generic/)
>  $(call PatchDir,$(LINUX_DIR),$(GENERIC_HACK_DIR),generic-hack/)
>  $(call PatchDir,$(LINUX_DIR),$(PATCH_DIR),platform/)
> 
> which means, that the resulting kernel is being constructed from
> generic/backport, generic/pending, generic/hack, generic/files,
> platfrom/patches and platform/files sources.
> 
> So when you're adding something it's good to keep this in mind in order to
> avoid possible clashes. I would probably just stick with 7xx.

Ok.

> > 2) there are no 7xx numbers in target/linux/generic/backport-4.19, so
> >    numbering them 700 through to 742 for the first patches would be
> >    okay?  These are all queued in mainline net-next. 
> 
> Yes. FYI in order to make the kernel refresh process easier/obvious, it's nice
> to have (not mandatory) the kernel version at the beginning of the filename.

Ok.  I've needed to move some additional patches from mvebu to generic
for this.

> > 3) patch 3 aren't queued yet, but are published in my git tree, and will
> >    be sent for the next merge window.  Does this still qualify as
> >    suitable for backport-4.19, or should they go elsewhere? 
> 
> From my POV it's backport.

Ok.

> > 4) patch 4, the uDPU patches stay in target/linux/mvebu/patches-4.19?
> 
> Yes.

Ok.

> >    3xx or some other number?
> 
> 0xx or 3xx, usually whatever avoids clashes with any previous/later patches :-)

I've ended up giving them 544..546 to follow on from the last DTS patch.
Looking at the numbering used there, there doesn't seem to be any rhyme
or reason to it.

> > 5) the final patch, which isn't in mainline, and probably needs further
> >    work - should that go in target/linux/generic/hack-4.19 ? 
> 
> If you're talking here about 1/4, then this one is probably just fine as it
> is.

I'm talking about 4/4, the "work around Nokia GPON module's TX_FAULT
assertion" patch.

> >  What about the numbering of the existing 7xx patches there - do I just pick
> >  the first available 7xx number, i.o.w. 701 ?
> 
> Yes.

Thanks, your reply has allowed me to proceed with some confidence that
I'm doing the correct thing.

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