Pkshih <pkshih@xxxxxxxxxxx> writes: > On Fri, 2021-11-26 at 16:12 +0000, Kalle Valo wrote: >> Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote: >> >> > Update scan_mac_addr to address CAM as A1, so hardware can ACK probe >> > response properly. >> > >> > Signed-off-by: Ping-Ke Shih <pkshih@xxxxxxxxxxx> >> >> 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
