From: Kalle Valo <kvalo@codeaurora.org>
To: Pkshih <pkshih@realtek.com>
Cc: "linux-wireless\@vger.kernel.org"
<linux-wireless@vger.kernel.org>,
"Bernie Huang" <phhuang@realtek.com>
Subject: Re: [PATCH 1/2] rtw89: update scan_mac_addr during scanning period
Date: Mon, 29 Nov 2021 11:11:28 +0200 [thread overview]
Message-ID: <8735nffhrz.fsf@codeaurora.org> (raw)
In-Reply-To: <2021378f787172b58115f6b12973e5a20af6fce0.camel@realtek.com> (Pkshih's message of "Sat, 27 Nov 2021 00:58:02 +0000")
Pkshih <pkshih@realtek.com> writes:
> On Fri, 2021-11-26 at 16:12 +0000, Kalle Valo wrote:
>> Ping-Ke Shih <pkshih@realtek.com> wrote:
>>
>> > 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
next prev parent reply other threads:[~2021-11-29 9:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 2:37 [PATCH 0/2] rtw89: correct scan behavior and results Ping-Ke Shih
2021-11-11 2:37 ` [PATCH 1/2] rtw89: update scan_mac_addr during scanning period Ping-Ke Shih
2021-11-26 16:12 ` Kalle Valo
2021-11-27 0:58 ` Pkshih
2021-11-29 9:11 ` Kalle Valo [this message]
2021-12-08 18:27 ` Kalle Valo
2021-11-11 2:37 ` [PATCH 2/2] rtw89: fix incorrect channel info during scan Ping-Ke Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735nffhrz.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=phhuang@realtek.com \
--cc=pkshih@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.