Pkshih [off-list ref] writes:

On Fri, 2021-11-26 at 16:12 +0000, Kalle Valo wrote:

quoted

Ping-Ke Shih [off-list ref] wrote:

quoted

Update scan_mac_addr to address CAM as A1, so hardware can ACK probe
response properly.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Failed to apply to wireless-drivers-next, please respin.

error: sha1 information is lacking or useless
(drivers/net/wireless/realtek/rtw89/txrx.h).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Applying: rtw89: fix incorrect channel info during scan
Patch failed at 0001 rtw89: fix incorrect channel info during scan

2 patches set to Changes Requested.

12613957 [1/2] rtw89: update scan_mac_addr during scanning period
12613959 [2/2] rtw89: fix incorrect channel info during scan

This patchset is based on the the 2 patches of another patchset
whose status is Awaiting Upstream:

12628209 [v3,2/3] rtw89: add const in the cast of le32_get_bits()
12628211 [v3,3/3] rtw89: use inline function instead macro to set H2C and CAM

If I do rebase on this patchset and get merged, the awaiting patchset
could be conflict. Should I wait the awaiting patchset get merged?

Please guide me the way to deal with this.

I think the easiest is that I also mark these patches as Awaiting
Upstream and apply the patches after the dependencies have been applied.

Sorry for the inconvenience.

No problem, this is business as usual. But this is exactly why I keep
the bar high in patches going to wireless-drivers and only take
important fixes, the conflicts between w-d and w-d-next just cause too
much of a hassle.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches