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

Wed Nov 27 06:40:09 EST 2019

On Wed, Nov 27, 2019 at 10:35:10AM +0000, Russell King - ARM Linux admin wrote:
> 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.

Sorry, looks like I never sent that one (which would've been patch 5!)

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

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