On 10/9/24 02:04, Johannes Berg wrote:
Hi,
So ... I suppose I kind of get it, your product doesn't really need
things upstream and so you don't care all _that_ much, but I'd still
appreciate if you could take a bit more care.
There's always a large amount of friction with patches you send, which
at this point makes me not even want to really look at them, and then I
wonder if I should just fix it up or send it back ... Yes I can and do
fix trivial things, but it really isn't something I feel I should need
to be doing all the time.
And yes, I also understand you want to just throw ideas over the wall,
but really in a v2 patchset I think we're beyond that. I'd also
appreciate not seeing obviously wrong patches (e.g. with a ton of marker
comments or prints left in them) since that just detracts from the
purpose, but that's not relevant to this patchset here.
Anyway ...
I appreciate getting patches upstream, and sorry for sending a broken patch
and missing the fact that I had posted a v1 instead of just the RFC.
I believe the v3 cleans up the problems.
Thanks,
Ben
Here, the subject should've had "v2", and in the commit message, below a
--- marker, a description of what you changed.
memset(&info->status, 0, sizeof(info->status));
info->flags &= ~(IEEE80211_TX_STAT_ACK | IEEE80211_TX_STAT_TX_FILTERED);
+ if (link_sta_id != -1)
+ info->control.flags = u32_replace_bits(info->control.flags, link_sta_id, IEEE80211_TX_CTRL_MLO_LINK);
That line is clearly too long for no reason at all, and same below.
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
