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

[Petr Štetiar]

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.

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

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

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

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

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

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

Yes.

>    3xx or some other number?

0xx or 3xx, usually whatever avoids clashes with any previous/later patches :-)

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

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

Yes.

-- ynezz

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