Message ID | 20230127193559.1001051-1-colin.foster@in-advantage.com (mailing list archive) |
---|---|
Headers | show |
Series | add support for the the vsc7512 internal copper phys | expand |
On Fri, Jan 27, 2023 at 11:35:46AM -0800, Colin Foster wrote: > This patch series is a continuation to add support for the VSC7512: > https://patchwork.kernel.org/project/netdevbpf/list/?series=674168&state=* > > That series added the framework and initial functionality for the > VSC7512 chip. Several of these patches grew during the initial > development of the framework, which is why v1 will include changelogs. > It was during v9 of that original MFD patch set that these were dropped. > > With that out of the way, the VSC7512 is mainly a subset of the VSC7514 > chip. The 7512 lacks an internal MIPS processor, but otherwise many of > the register definitions are identical. That is why several of these > patches are simply to expose common resources from > drivers/net/ethernet/mscc/*. > > This patch only adds support for the first four ports (swp0-swp3). The > remaining ports require more significant changes to the felix driver, > and will be handled in the future. For the whole series: Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression A minor nitpick after this is merged: please clean up and unexport stuff from include/soc/mscc/vsc7514_regs.h which was added with your previous approaches and then we steered mid-way. Congratulations!
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Fri, 27 Jan 2023 11:35:46 -0800 you wrote: > This patch series is a continuation to add support for the VSC7512: > https://patchwork.kernel.org/project/netdevbpf/list/?series=674168&state=* > > That series added the framework and initial functionality for the > VSC7512 chip. Several of these patches grew during the initial > development of the framework, which is why v1 will include changelogs. > It was during v9 of that original MFD patch set that these were dropped. > > [...] Here is the summary with links: - [v5,net-next,01/13] net: mscc: ocelot: expose ocelot wm functions https://git.kernel.org/netdev/net-next/c/c6a9321b0811 - [v5,net-next,02/13] net: mscc: ocelot: expose regfield definition to be used by other drivers https://git.kernel.org/netdev/net-next/c/728d8019f1a3 - [v5,net-next,03/13] net: mscc: ocelot: expose vcap_props structure https://git.kernel.org/netdev/net-next/c/beb9a74e0bf7 - [v5,net-next,04/13] net: mscc: ocelot: expose ocelot_reset routine https://git.kernel.org/netdev/net-next/c/b67f5502136f - [v5,net-next,05/13] net: mscc: ocelot: expose vsc7514_regmap definition https://git.kernel.org/netdev/net-next/c/2efaca411c96 - [v5,net-next,06/13] net: dsa: felix: add configurable device quirks https://git.kernel.org/netdev/net-next/c/1dc6a2a02320 - [v5,net-next,07/13] net: dsa: felix: add support for MFD configurations https://git.kernel.org/netdev/net-next/c/dc454fa4b764 - [v5,net-next,08/13] net: dsa: felix: add functionality when not all ports are supported https://git.kernel.org/netdev/net-next/c/de879a016a94 - [v5,net-next,09/13] mfd: ocelot: prepend resource size macros to be 32-bit https://git.kernel.org/netdev/net-next/c/fde0b6ced8ed - [v5,net-next,10/13] dt-bindings: net: mscc,vsc7514-switch: add dsa binding for the vsc7512 https://git.kernel.org/netdev/net-next/c/dd43f5e7684c - [v5,net-next,11/13] dt-bindings: mfd: ocelot: add ethernet-switch hardware support https://git.kernel.org/netdev/net-next/c/11fc80cbb225 - [v5,net-next,12/13] net: dsa: ocelot: add external ocelot switch control https://git.kernel.org/netdev/net-next/c/3d7316ac81ac - [v5,net-next,13/13] mfd: ocelot: add external ocelot switch control https://git.kernel.org/netdev/net-next/c/8dccdd277e0b You are awesome, thank you!
On Tue, 31 Jan 2023, patchwork-bot+netdevbpf@kernel.org wrote: > Hello: > > This series was applied to netdev/net-next.git (master) > by Jakub Kicinski <kuba@kernel.org>: Please don't do that. The commits do not have proper Acked-by tags. The plan is to merge these via MFD and send out a pull-request to an immutable branch. However, if you're prepared to convert all of the: Acked-for-MFD-by: Lee Jones <lee@kernel.org> to Acked-by: Lee Jones <lee@kernel.org> ... and send out a pull request to a succinct (only these patches) and immutable branch then that is also an acceptable solution. Please let me know what works best for you. Thanks. > > This patch series is a continuation to add support for the VSC7512: > > https://patchwork.kernel.org/project/netdevbpf/list/?series=674168&state=* > > > > That series added the framework and initial functionality for the > > VSC7512 chip. Several of these patches grew during the initial > > development of the framework, which is why v1 will include changelogs. > > It was during v9 of that original MFD patch set that these were dropped. > > > > [...] > > Here is the summary with links: > - [v5,net-next,01/13] net: mscc: ocelot: expose ocelot wm functions > https://git.kernel.org/netdev/net-next/c/c6a9321b0811 > - [v5,net-next,02/13] net: mscc: ocelot: expose regfield definition to be used by other drivers > https://git.kernel.org/netdev/net-next/c/728d8019f1a3 > - [v5,net-next,03/13] net: mscc: ocelot: expose vcap_props structure > https://git.kernel.org/netdev/net-next/c/beb9a74e0bf7 > - [v5,net-next,04/13] net: mscc: ocelot: expose ocelot_reset routine > https://git.kernel.org/netdev/net-next/c/b67f5502136f > - [v5,net-next,05/13] net: mscc: ocelot: expose vsc7514_regmap definition > https://git.kernel.org/netdev/net-next/c/2efaca411c96 > - [v5,net-next,06/13] net: dsa: felix: add configurable device quirks > https://git.kernel.org/netdev/net-next/c/1dc6a2a02320 > - [v5,net-next,07/13] net: dsa: felix: add support for MFD configurations > https://git.kernel.org/netdev/net-next/c/dc454fa4b764 > - [v5,net-next,08/13] net: dsa: felix: add functionality when not all ports are supported > https://git.kernel.org/netdev/net-next/c/de879a016a94 > - [v5,net-next,09/13] mfd: ocelot: prepend resource size macros to be 32-bit > https://git.kernel.org/netdev/net-next/c/fde0b6ced8ed > - [v5,net-next,10/13] dt-bindings: net: mscc,vsc7514-switch: add dsa binding for the vsc7512 > https://git.kernel.org/netdev/net-next/c/dd43f5e7684c > - [v5,net-next,11/13] dt-bindings: mfd: ocelot: add ethernet-switch hardware support > https://git.kernel.org/netdev/net-next/c/11fc80cbb225 > - [v5,net-next,12/13] net: dsa: ocelot: add external ocelot switch control > https://git.kernel.org/netdev/net-next/c/3d7316ac81ac > - [v5,net-next,13/13] mfd: ocelot: add external ocelot switch control > https://git.kernel.org/netdev/net-next/c/8dccdd277e0b > > You are awesome, thank you! > -- > Deet-doot-dot, I am a bot. > https://korg.docs.kernel.org/patchwork/pwbot.html > >
On Tue, 31 Jan 2023 09:06:22 +0000 Lee Jones wrote: > Please don't do that. The commits do not have proper Acked-by tags. > > The plan is to merge these via MFD and send out a pull-request to an > immutable branch. However, if you're prepared to convert all of the: > > Acked-for-MFD-by: Lee Jones <lee@kernel.org> > > to > > Acked-by: Lee Jones <lee@kernel.org> Sorry, I must have been blind yesterday because I definitely double checked this doesn't touch mfd code. And it does :/ The patches should not be sent for net-next if they are not supposed to be applied directly. Or at the very least says something about merging in the cover letter! > ... and send out a pull request to a succinct (only these patches) and > immutable branch then that is also an acceptable solution. > > Please let me know what works best for you. Sorry for messing up again. Stable branch would obviously had been best. Do we have to take action now, or can we just wait for the trees to converge during the merge window?
On Tue, Jan 31, 2023 at 11:45:38AM -0800, Jakub Kicinski wrote: > On Tue, 31 Jan 2023 09:06:22 +0000 Lee Jones wrote: > > Please don't do that. The commits do not have proper Acked-by tags. > > > > The plan is to merge these via MFD and send out a pull-request to an > > immutable branch. However, if you're prepared to convert all of the: > > > > Acked-for-MFD-by: Lee Jones <lee@kernel.org> > > > > to > > > > Acked-by: Lee Jones <lee@kernel.org> > > Sorry, I must have been blind yesterday because I definitely double > checked this doesn't touch mfd code. And it does :/ > > The patches should not be sent for net-next if they are not supposed > to be applied directly. Or at the very least says something about > merging in the cover letter! My apologies. I wasn't sure how these cross-tree syncs would be done (and I recognize Lee even asked during a previous submission.) I'll be more verbose in cover letters moving forward, should I ever be submitting against multiple trees like this.
On Tue, 31 Jan 2023, Jakub Kicinski wrote: > On Tue, 31 Jan 2023 09:06:22 +0000 Lee Jones wrote: > > Please don't do that. The commits do not have proper Acked-by tags. > > > > The plan is to merge these via MFD and send out a pull-request to an > > immutable branch. However, if you're prepared to convert all of the: > > > > Acked-for-MFD-by: Lee Jones <lee@kernel.org> > > > > to > > > > Acked-by: Lee Jones <lee@kernel.org> > > Sorry, I must have been blind yesterday because I definitely double > checked this doesn't touch mfd code. And it does :/ > > The patches should not be sent for net-next if they are not supposed > to be applied directly. Or at the very least says something about > merging in the cover letter! > > > ... and send out a pull request to a succinct (only these patches) and > > immutable branch then that is also an acceptable solution. > > > > Please let me know what works best for you. > > Sorry for messing up again. Stable branch would obviously had been best. > Do we have to take action now, or can we just wait for the trees to > converge during the merge window? Russell explained to me (off-list) that the net-next branch is immutable and the only way to fix this would be to revert the whole set. Let's not go to that much trouble this time. It does mean that I cannot take any more commits on the affected files, but that shouldn't be a big deal seeing how far into the release cycle we are. No real harm done.