Message ID | 20250227045824.91480-1-quic_sarishar@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | wifi: mac80211/ath12k: add support to fill link statistics of multi-link station | expand |
On Thu, 2025-02-27 at 10:28 +0530, Sarika Sharma wrote: > Currently, station statistics are filled at deflink for both non-ML and > multi-link(ML) station. > > Hence, add support to fill station statistics for the corresponding > link of station. > > Depends-On: [RFC,v3,00/12] wifi: cfg80211/mac80211: add support to > handle per link statistics of multi-link station > Link: https://patchwork.kernel.org/project/linux-wireless/cover/20250213171632.1646538-1-quic_sarishar@quicinc.com/ That can't work for the automation... Also, even _with_ that, this series doesn't apply on wireless-next, likely because it requires some changes from the ath tree. Given that we want to run the automation now, that really means you need to adjust your workflow to send only series to the list that can actually apply on a single tree... So I guess in this case it means you should split it. In fact I'm not even sure why this is one series in the first place - the first patch fixes an issue but it _doesn't_ introduce any API or anything that'd actually be _required_ for the remaining patches, so it shouldn't be a single series anyway. johannes
Hi Johannes, Johannes Berg <johannes@sipsolutions.net> wrote: > On Thu, 2025-02-27 at 10:28 +0530, Sarika Sharma wrote: > > Currently, station statistics are filled at deflink for both non-ML and > > multi-link(ML) station. > > > > Hence, add support to fill station statistics for the corresponding > > link of station. > > > > Depends-On: [RFC,v3,00/12] wifi: cfg80211/mac80211: add support to > > handle per link statistics of multi-link station > > Link: > https://patchwork.kernel.org/project/linux-wireless/cover/20250213171632.1646538-1-quic_sarishar@quici > nc.com/ > > That can't work for the automation... I have encountered structural (not functional) dependency problem too. Could you share how I can tell NIPA the dependency between two patchset? Ping-Ke
On Thu, 2025-02-27 at 09:30 +0000, Ping-Ke Shih wrote: > > I have encountered structural (not functional) dependency problem too. > Could you share how I can tell NIPA the dependency between two patchset? > I don't think you can at all, at this point. johannes
On 2/27/2025 1:32 AM, Johannes Berg wrote: > On Thu, 2025-02-27 at 09:30 +0000, Ping-Ke Shih wrote: >> >> I have encountered structural (not functional) dependency problem too. >> Could you share how I can tell NIPA the dependency between two patchset? >> > > I don't think you can at all, at this point. So it doesn't support the mechanism 'b4' can handle, namely having a base-commit: tag along with one or more prerequisite-patch-id: tags? (note this series was not created with b4 so it doesn't have those tags, but just curious if it had been created with b4, if the patches could have been applied)
On Thu, 2025-02-27 at 11:35 -0800, Jeff Johnson wrote: > On 2/27/2025 1:32 AM, Johannes Berg wrote: > > On Thu, 2025-02-27 at 09:30 +0000, Ping-Ke Shih wrote: > > > > > > I have encountered structural (not functional) dependency problem too. > > > Could you share how I can tell NIPA the dependency between two patchset? > > > > > > > I don't think you can at all, at this point. > > So it doesn't support the mechanism 'b4' can handle, namely having a > base-commit: tag along with one or more prerequisite-patch-id: tags? I don't really know, but I don't think so. Note that (afaict) b4 also doesn't really use it to select the base to apply things to, it uses it to make a 3-way merge to the tree you want to apply the patches to. I doubt that would have helped here, given that it was trying to apply the patches to the wireless-next tree, where that commit likely wouldn't have been present anyway. johannes