Hi Jerry,
On Fri, May 23, 2025 at 07:32:26AM +0000, Jerry C Chen/WYHQ/Wiwynn wrote:
Sorry for late replay, it takes some effort to change company policy of the proprietary.
I can imagine! However it's not necessary to send patches from corporate e-mail address via the corporate mail server, you can just send from your own personal account with the appropriate From: specification to attribute it to your corporate address[0].
For the questions:
Please consider just using standard inline method of replying in the future, letting your MUA quote the original message for context properly.
- What upstream tree did you intend it for and why?
- Linux mainline
We are developing openBMC with kernel-6.6. For submitting patch to kernel-6.6 stable tree, it should exist in mainline first. Reference: https://github.com/openbmc/linux/commits/dev-6.6/
Indeed, and the process of submitting to mainline implies that for each subsystem there's a tree which subsystem maintainer(s) use for the integration and which is later offered as a the pull request for the upcoming version, usually it's called {subsystem}-next (also such trees get tested together being merged into linux-next regularly). I guess in this case you should make sure your patch applies to net-next (and makes sense there). Neither the current submission[1] nor the previous one[2] were applicable (see "netdev/tree_selection success Guessing tree name failed - patch did not apply" and indeed I tried to "git am" it manually to what was "net-next" back then and it failed.
- Have you seen such cards in the wild? It wouldn't harm mentioning
specific examples in the commit message to probably help people searching for problems specific to them later. You can also consider adding Fixes: and Cc: stable tags if this bugfix solves a real issue and should be backported to stable kernels.
- This NIC is developed by META terminus team and the problematic string is:
The channel Version Str : 24.12.08-000 I will update it to commit message later.
I see, thank you. Sigh, this 12 characters limit doesn't seem to make much sense, too restrictive to fit a useful part of "git describe --tags" even, but it is what it is...
[0] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#from-... [1] https://patchwork.kernel.org/project/netdevbpf/patch/20250515083448.3511588-... [2] https://patchwork.kernel.org/project/netdevbpf/patch/20250227055044.3878374-...