On Wed, 2024-04-17 at 12:51 +0200, Alexander Lobakin wrote:
> Just FYI: kdoc accepts only this pattern:
>
> * @last_param: blah
> *
> * Return: blah
>
> NOT
>
> * Returns: blah
Actually, it does accept that, the regex is "returns?". It's just
documented only as "Return" . IMHO it sometimes
On Fri, 2023-10-27 at 12:50 +0300, Dmitry Antipov wrote:
> Locals can't be used for scatterlists/DMA/etc., right?
Well, a scatterlist by itself doesn't imply anything necessarily, it's
just a data structure.
But yes, you cannot do DMA from the stack, which seems to happen in this
case, or at
On Fri, 2023-10-27 at 11:23 +0300, Dmitry Antipov wrote:
> There isn't too much sense to 'kzalloc()' buffer
Actually, there is. Consider what's done with it.
johannes
___
ath10k mailing list
ath10k@lists.infradead.org
On Tue, 2023-10-24 at 14:41 -0600, Gustavo A. R. Silva wrote:
>
> It seems we run into the same issue in the function below, even in the
> case this `memset()` is unnecessary (which it seems it's not):
>
> 8920 memset(skb->data, 0, sizeof(*cmd));
>
> Notice that if
On Tue, 2023-10-24 at 13:50 -0600, Gustavo A. R. Silva wrote:
> Hi all,
>
> While working on tranforming one-element array `peer_chan_list` in
> `struct wmi_tdls_peer_capabilities` into a flex-array member
>
> 7187 struct wmi_tdls_peer_capabilities {
> ...
> 7199 struct wmi_channel
On Wed, 2023-02-22 at 08:22 +0800, Wen Gong wrote:
> On 2/15/2023 11:10 PM, Johannes Berg wrote:
> > > > Why is this even needed? You should always get reg_notifier after this
> > > > anyway?
> > > Currently when channel flag changed through the beacon hi
> >
> > Why is this even needed? You should always get reg_notifier after this
> > anyway?
>
> Currently when channel flag changed through the beacon hints are not
> informed to driver.
>
> reg_notifier will be triggered for regdomain changes but not for channel flag
> changes due to beacon
> +++ b/include/net/cfg80211.h
> @@ -5386,6 +5386,8 @@ struct wiphy {
> void (*reg_notifier)(struct wiphy *wiphy,
>struct regulatory_request *request);
>
> + void (*beacon_hint_notifier)(struct wiphy *wiphy);
missing documentation, for sure
Also this
On Wed, 2022-10-12 at 19:57 +0530, Youghandhar Chintala wrote:
>
> @@ -418,6 +426,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> .dynamic_sar_support = false,
> .hw_restart_disconnect = false,
> .use_fw_tx_credits = true,
> +
I already applied this patch, and sent a separate ifdef fix ...
johannes
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Thu, 2022-02-24 at 11:59 +0200, Kalle Valo wrote:
>
> A good question. I have always just thought we should avoid void pointer
> arithmetic due to the C standard, but now that you mention it void
> pointers can indeed simplify the code. So I'm not so sure anymore.
>
> Any opinions? Is there a
> @@ -5475,7 +5476,7 @@ noinstr int lock_is_held_type(const struct lockdep_map
> *lock, int read)
> /* avoid false negative lockdep_assert_not_held()
>* and lockdep_assert_held()
>*/
> - return -1;
> + return
On Mon, 2021-02-15 at 17:04 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
> > On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
> > > I think something like so will work, but please double check.
> >
>
On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
>
> I think something like so will work, but please double check.
Yeah, that looks better.
> +++ b/include/linux/lockdep.h
> @@ -294,11 +294,15 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
> struct pin_cookie);
>
> #define
> > Yes but you have to iterate all the stations and check they belong to
> > the interface and all that I think?
> >
> Maybe not need.
> if NL80211_IFTYPE_STATION and NON-WLAN_STA_TDLS_PEER, it has only 1
> station for the ieee80211_vif
> by my understand.
Well, yes, but there's no counter.
On Fri, 2020-11-13 at 17:09 +0800, Wen Gong wrote:
> On 2020-11-13 16:51, Johannes Berg wrote:
> > On Fri, 2020-11-13 at 16:51 +0800, Wen Gong wrote:
> >
> > > yes.
> > > It can add check with supp_rates[band] of ieee80211_sta for
> > > NL80211_IF
On Fri, 2020-11-13 at 16:51 +0800, Wen Gong wrote:
> yes.
> It can add check with supp_rates[band] of ieee80211_sta for
> NL80211_IFTYPE_STATION type.
> for others, check with sdata->vif.bss_conf.basic_rates
Right.
Though, might need to check that only if there's no TDLS station or
something?
On Fri, 2020-11-13 at 16:35 +0800, Wen Gong wrote:
>
> > I guess if we really want to redefine the user rate mask to not apply
> > to
> > control frames, then we can relax this?
> >
> Yes, for AP mode, it is hard to calculate the usable rates over all
> stations.
> But for STATION mode, it can
On Fri, 2020-11-13 at 16:14 +0800, Wen Gong wrote:
> On 2020-11-13 15:38, Johannes Berg wrote:
> > On Fri, 2020-11-13 at 10:08 +0800, Wen Gong wrote:
> > > > Which was the intent of this change, wasn't it?
> >
> > Indeed. Permitting this leads to warnings later.
On Fri, 2020-11-13 at 10:08 +0800, Wen Gong wrote:
>
> > Which was the intent of this change, wasn't it?
Indeed. Permitting this leads to warnings later.
> We need to set the tx rate to fixed at a single rate, e.g.,
> 54M/48M/36M... for a test case.
> I do not want a clear error message, I
On Sat, 2020-11-07 at 11:05 -0800, Jakub Kicinski wrote:
> On Sat, 7 Nov 2020 17:21:31 + Taehee Yoo wrote:
> > When debugfs file is opened, its module should not be removed until
> > it's closed.
> > Because debugfs internally uses the module's data.
> > So, it could access freed memory.
> >
Hi,
Looks pretty good. Some comments, mostly nits, below.
> +/**
> + * nl80211_sar_attrs - Attributes for SAR spec
missing enum
> + *
> + * @NL80211_SAR_ATTR_TYPE: the SAR type and it's defined in
> %nl80211_sar_type.
better use nl80211_sar_type for a link in docs
> + *
> + *
On Tue, 2020-11-03 at 10:34 +0800, Carl Huang wrote:
> On 2020-10-31 10:46, Abhishek Kumar wrote:
> > From: kua...@chromium.org
> >
> > There are few more additional comments here.
> > > + * @NL80211_CMD_SET_SAR_SPECS: SAR power limitation configuration is
> > > + * passed using
On Tue, 2020-09-22 at 13:49 +0800, Carl Huang wrote:
> NL80211_CMD_SET_SAR_SPECS is added to configure SAR from
> user space. NL80211_ATTR_SAR_SPEC is used to pass the SAR
> power specification when used with NL80211_CMD_SET_SAR_SPECS.
>
> Wireless driver needs to register SAR type, supported
Hi,
Sorry ... long delay.
> > The reason I'm asking is that it's starting to sound like we really
> > ought to be implementing devlink, but we've got a bunch of
> > infrastructure that uses the devcoredump, and it'll take time
> > (significantly so) to change all that...
>
> In devlink world
On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote:
> > > So to me it feels like the best solution forward is to go with the
> > > vendor API, do you agree? We can, of course, later switch to the common
> > > API if we manage to create one which is usable for everyone.
But why wouldn't we try
On Mon, 2020-06-01 at 18:32 -0700, Brian Norris wrote:
> I haven't quite reached the 3 month lag on the prior replies here :)
But I did, almost ;-)
> I do want to see this question resolved somehow, or else we'll be
> dragging along out-of-tree patches for...(counts on fingers)...4
> different
On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote:
> We do have the usage of napi_gro_receive and netif_receive_skb in mac80211.
> /* deliver to local stack */
> if (rx->napi)
> napi_gro_receive(rx->napi, skb);
> else
>
On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote:
> > > - WARN_ON_ONCE(softirq_count() == 0);
> > > + WARN_ON_ONCE(napi && softirq_count() == 0);
> >
> > FWIW, I'm pretty sure this is incorrect - we make assumptions on
> > softirqs being disabled in mac80211 for serialization and in place
On Tue, 2020-07-21 at 22:44 +0530, Rakesh Pillai wrote:
> The function ieee80211_rx_napi can be now called
> from a thread context as well, with napi context
> being NULL.
>
> Hence add the napi context check before giving out
> a warning for softirq count being 0.
>
> Tested-on: WCN3990 hw1.0
On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
> I'm considering testing a different approach (with mt76 initially):
> - Add a mac80211 rx function that puts processed skbs into a list
> instead of handing them to the network stack directly.
Would this be *after* all the mac80211
On Fri, 2020-05-22 at 10:17 -0700, Jakub Kicinski wrote:
> > > --- a/net/core/Makefile
> > > +++ b/net/core/Makefile
> > > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o
> > > obj-$(CONFIG_BPF_STREAM_PARSER) += sock_map.o
> > > obj-$(CONFIG_DST_CACHE) += dst_cache.o
> > >
On Mon, 2020-05-18 at 13:35 -0700, Jakub Kicinski wrote:
>
> It's intended to be a generic netlink channel for configuring devices.
>
> All the firmware-related interfaces have no dependencies on netdevs,
> in fact that's one of the reasons we moved to devlink - we don't want
> to hold rtnl lock
On Mon, 2020-05-18 at 13:28 -0700, Jakub Kicinski wrote:
> On Mon, 18 May 2020 21:25:09 +0200 Johannes Berg wrote:
> > It's pretty clear, but even then, first of all I doubt this is the case
> > for many of the places that you've sprinkled the annotation on, and
> > secon
On Mon, 2020-05-18 at 19:59 +, Luis Chamberlain wrote:
> > Err, no. Those two are most definitely related. Have you looked at (most
> > or some or whatever) staging drivers recently? Those contain all kinds
> > of garbage that might do whatever with your kernel.
>
> No, I stay away :)
:)
>
On Mon, 2020-05-18 at 19:09 +, Luis Chamberlain wrote:
> > Unfortunately a "taint" is interpreted by many users as: "your kernel
> > is really F#*D up, you better do something about it right now."
> > Assuming they're paying attention at all in the first place of course.
>
> Taint
On Sat, 2020-05-16 at 15:24 +0200, Johannes Berg wrote:
> Instead of the kernel taint, IMHO you should provide an annotation in
> sysfs (or somewhere else) for the *struct device* that had its firmware
> crash. Or maybe, if it's too complex to walk the entire hierarchy
> checking fo
On Fri, 2020-05-15 at 21:28 +, Luis Chamberlain wrote:>
module_firmware_crashed
You didn't CC me or the wireless list on the rest of the patches, so I'm
replying to a random one, but ...
What is the point here?
This should in no way affect the integrity of the system/kernel, for
most
On Tue, 2020-03-17 at 18:54 +0200, Kalle Valo wrote:
> For me either solutions are good enough, I'm not familiar enough with
> all the different SAR user space interfaces to make a good decision.
Brian probably has most insight into this :-)
I really didn't want to have to be the referee here,
On Wed, 2019-12-18 at 18:12 +0800, yi...@codeaurora.org wrote:
>
> Yes, this is a fix to the first patch. Actually, the rest of two patches
> are also serve the same. So, are you suggesting to merge them to the
> first patch?
Yes.
> Previouly, I had added Toke's signature in this patch but
I'm going to assume that Toke will review all of this and there will be
changes, so you'd resend anyway ...
> - * @airtime_weight: station weight for airtime fairness calculation purposes
> + * @airtime_weight: station per-AC weight for airtime fairness calculation
> + * purposes
If you do,
On Fri, 2019-12-13 at 15:19 +0800, Yibo Zhao wrote:
> In a loop txqs dequeue scenario, if the first txq in the rbtree gets
> removed from rbtree immediately in the ieee80211_return_txq(), the
> loop will break soon in the ieee80211_next_txq() due to schedule_pos
> not leading to the second txq in
On Fri, 2019-11-08 at 12:10 +0100, Toke Høiland-Jørgensen wrote:
> Right, bugger. I was thinking maybe there's a case where skbs can be
> cloned (and retain the tx_time_est field) and then released twice?
They could be cloned, but I don't see how that'd be while *inside* the
stack and then they
On Fri, 2019-11-08 at 12:01 +0100, Toke Høiland-Jørgensen wrote:
>
> My reasoning for doing it this way was that we have another set of APIs
> dealing with airtime which doesn't do any shifting; so keeping the APIs
> in the same unit (straight airtime) seemed less confusing.
Fair enough.
> We
On Fri, 2019-11-08 at 11:56 +0100, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
> > >
> > > +void ieee80211_sta_update_pending_airtime(struct ieee80211_local *local,
> > > +
On Fri, 2019-11-08 at 11:55 +0100, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
> > > From: Toke Høiland-Jørgensen
> > >
> > > Felix recently added code to calculate airt
FWIW, I applied the first patch since it's just some preparation.
Couple of questions on this.
> +/**
> + * ieee80211_set_hw_80211_encap - enable hardware encapsulation offloading.
> + *
> + * This function is used to notify mac80211 that a vif can be passed raw
> 802.3.
> + * The driver needs
On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
>
> + if (info->tx_time_est) {
> + struct sta_info *sta = NULL, *s;
> + struct rhlist_head *tmp;
> +
> + rcu_read_lock();
> +
> + for_each_sta_info(local, hdr->addr1, s, tmp) {
> +
On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
>
>
> +void ieee80211_sta_update_pending_airtime(struct ieee80211_local *local,
> + struct sta_info *sta, u8 ac,
> + u16 tx_airtime, bool tx_completed)
>
On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
> From: Toke Høiland-Jørgensen
>
> Felix recently added code to calculate airtime of packets to the mt76
> driver. Import this into mac80211 so we can use it for airtime queue limit
> calculations later.
>
> The airtime.c file is
On Wed, 2019-10-23 at 11:59 +0200, Toke Høiland-Jørgensen wrote:
> From: Toke Høiland-Jørgensen
>
> To implement airtime queue limiting, we need to keep a running account of
> the estimated airtime of all skbs queued into the device. Do to this
> correctly, we need to store the airtime estimate
On Thu, 2019-10-17 at 18:11 -0700, Kan Yan wrote:
> I don't think it is hard to take care of extra header size for frames
> with VLAN tags
VLAN tags are payload as far as wifi is concerned, so no need to take
that into account ...
johannes
___
On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
>
> > We can also play with the units of the airtime, e.g. making that a
> > multiple of 2 or 4 us? Seems unlikely to matter much?
>
> Sure, that's a good point! Increments of 4us means we can fit 4ms is 10
> bits, leaving plenty
On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
> Right. Well in that case, let's try it. As long as we fail in a
> reasonable way, we can just see if we run into anything that breaks? I
> guess in this case that means rejecting requests from userspace if we
> run out of IDs
On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote:
> Well, let's try to do the actual math... A full-size (1538 bytes) packet
> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's
> certainly still less that 4096 us, so 12 bits is plenty.
What about A-MSDUs?
On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
> Kan Yan writes:
>
> > The "tx_time_est" field, shared by control and status, is not able to
> > survive until the skb returns to the mac80211 layer in some
> > architectures. The same space is defined as driver_data and some
> >
On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
> However, there's a nice juicy 'u16 ack_frame_id' at the start of
> ieee80211_tx_info. Could we potentially use that? We could use the top
> bit as a disambiguation flag; I think we're fine with 15 bits for the TX
> time itself (a
On Thu, 2019-10-10 at 19:24 -0700, Kan Yan wrote:
> > > + * ieee80211_txq_aql_check - check if a txq can send frame to device
> > I wonder if this really should even be have "aql" in the name? It's also
> > going to return NULL if there's nothing on the TXQ, for example, right?
>
> Renamed to
Hi,
A couple of points...
First, I'd like Toke to review & ack this if possible :-)
Second, I probably won't apply this until I return from vacation (will
be out next week & the week after).
Third, a couple of more comments on the code:
> +/* The per TXQ firmware queue limit in airtime */
I
On Tue, 2019-10-01 at 15:21 +0300, Kalle Valo wrote:
> > > > padded_len = ath10k_sdio_calc_txrx_padded_len(ar_sdio,
> > > > skb->len);
> > > > - skb_trim(skb, padded_len);
> > > > + /* FIXME:
On Mon, 2019-09-23 at 15:19 +0800, Yibo Zhao wrote:
> This series fix some issues when enabling virtual time-based airtime
> scheduler on ath10k.
>
Given the lengthy discussion here and also over in the related thread
about AQL, I'm assuming you're going to repost this eventually.
johannes
On Tue, 2019-09-17 at 14:36 +0800, Yibo Zhao wrote:
>
> Do you mean it should be something like:
>
> Co-developed-by: Toke Høiland-Jørgensen
> Signed-off-by: Yibo Zhao
> Signed-off-by: Toke Høiland-Jørgensen
Yes, I think you mean the right thing. For the record, it seems to me it
should be
Without really looking at the code -
> If station is ineligible for transmission in ieee80211_txq_may_transmit(),
> no packet will be delivered to FW. During the tests in push-pull mode with
> many clients, after several seconds, not a single station is an eligible
> candidate for transmission
On Wed, 2019-09-11 at 21:19 +0300, Kalle Valo wrote:
> > Looks like indeed the driver gives the device at least *3 seconds* for
> > every command, see ath10k_wmi_cmd_send(), so most likely this would
> > eventually have finished, but who knows how many firmware commands it
> > would still have
On Wed, 2019-09-04 at 14:15 +0800, Wen Gong wrote:
> Make it possibly for drivers to adjust the default mat_mtu
> by storing it in the hardware struct.
>
> +++ b/net/mac80211/iface.c
> @@ -1877,7 +1877,10 @@ int ieee80211_if_add(struct ieee80211_local *local,
> const char *name,
>
>
On Sat, 2019-08-10 at 18:10 +0530, Tamizh chelvam wrote:
> On 2019-07-31 14:55, Johannes Berg wrote:
> > On Tue, 2019-06-18 at 10:57 +0530, Tamizh chelvam wrote:
> > > /**
> > > + * enum nl80211_tid_config - TID config state
> > > + * @NL80211_TID_CONFIG
On Sat, 2019-08-10 at 17:36 +0530, Tamizh chelvam wrote:
>
> > > + [NL80211_TID_ATTR_CONFIG_RETRY] = { .type = NLA_FLAG },
> > > + [NL80211_TID_ATTR_CONFIG_RETRY_SHORT] = NLA_POLICY_MIN(NLA_U8, 0),
> > > + [NL80211_TID_ATTR_CONFIG_RETRY_LONG] = NLA_POLICY_MIN(NLA_U8, 0),
> >
> > min of 0 doesn't
On Tue, 2019-06-18 at 10:57 +0530, Tamizh chelvam wrote:
>
> @@ -1626,6 +1635,14 @@ struct ieee80211_vif {
>
> bool txqs_stopped[IEEE80211_NUM_ACS];
>
> + int noack[IEEE80211_TID_MAX];
> + int retry_short[IEEE80211_TID_MAX];
> + int retry_long[IEEE80211_TID_MAX];
> + int
> /**
> + * enum nl80211_tx_rate_setting - TX rate configuration type
> + * @NL80211_TX_RATE_AUTOMATIC: automatically determine TX rate
> + * @NL80211_TX_RATE_LIMITED: limit the TX rate by the TX rate parameter
> + * @NL80211_TX_RATE_FIXED: fix TX rate to the TX rate parameter
> + */
> +enum
On Tue, 2019-06-18 at 10:57 +0530, Tamizh chelvam wrote:
>
> + if (!wiphy_ext_feature_isset(>wiphy,
> + NL80211_EXT_FEATURE_PER_TID_AMPDU_CTRL)) {
> + NL_SET_ERR_MSG_ATTR(extack,
> +
>
On Tue, 2019-06-18 at 10:57 +0530, Tamizh chelvam wrote:
>
> /**
> + * enum nl80211_tid_config - TID config state
> + * @NL80211_TID_CONFIG_DEFAULT: Default config for the TID
> + * @NL80211_TID_CONFIG_ENABLE: Enable config for the TID
> + * NL80211_TID_CONFIG_DISABLE: Disable config for the TID
^^ there's a typo in the subject
> @@ -3951,6 +3957,7 @@ enum wiphy_flags {
> WIPHY_FLAG_SUPPORTS_5_10_MHZ= BIT(22),
> WIPHY_FLAG_HAS_CHANNEL_SWITCH = BIT(23),
> WIPHY_FLAG_HAS_STATIC_WEP = BIT(24),
> + WIPHY_FLAG_HAS_MAX_DATA_RETRY_COUNT
Hi,
Was waiting for you to address Sergey's feedback, but now that I looked
anyway, I have some of my own. Sorry for the long delay though!
> + * @NL80211_ATTR_TID_CONFIG: TID specific configuration in a
> + * nested attribute with %NL80211_TID_ATTR_* sub-attributes.
Please use
On Thu, 2019-06-27 at 21:12 +0200, Johannes Berg wrote:
> On Thu, 2019-06-27 at 21:47 +0300, Kalle Valo wrote:
> > Fixes checkpatch warnings:
> >
> > drivers/net/wireless/ath/ath10k/pci.c:926: unnecessary cast may hide bugs,
> > see http://c-faq.com/malloc/ma
> >
On Thu, 2019-06-27 at 21:47 +0300, Kalle Valo wrote:
> Fixes checkpatch warnings:
>
> drivers/net/wireless/ath/ath10k/pci.c:926: unnecessary cast may hide bugs,
> see http://c-faq.com/malloc/ma
> drivers/net/wireless/ath/ath10k/pci.c:1072: unnecessary cast may hide bugs,
> see
On Fri, 2019-06-14 at 10:52 +0800, Yibo Zhao wrote:
>
> May I know if it is fine that WARN_ON_ONCE() to be applied in kernel in
> the future? If a separate patch for it is needed, please let me know so
> that I can raise a new one.
Please do send a new patch.
johannes
On Tue, 2019-05-14 at 11:54 -0700, Ben Greear wrote:
>
> Here is the info I have in my commit that changed this to WARN_ON_ONCE.
> I never posted it because I had to hack ath10k to get to this state, so maybe
> this is not a valid case to debug.
>
>
> Maybe Yibo Zhao has a better example.
>
>
> We know the WARN hits, we have the backtrace, and it is easy enough (in my
> setup
> at least) to reproduce this. So, the WARN logic has done its job.
>
> Having more of these spam the kernel doesn't add much benefit I think.
Well, this doesn't necessarily just catch a *single* issue, so
On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
> On 2019-05-14 17:05, Johannes Berg wrote:
> > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> > > In multiple SSID cases, it takes time to prepare every AP interface
> > > to be ready in initializing ph
On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at
On Fri, 2019-05-10 at 15:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at
> @@ -13354,6 +13367,42 @@ static int parse_tid_conf(struct
> cfg80211_registered_device *rdev,
> nla_get_u8(attrs[NL80211_ATTR_TID_CONFIG_RTSCTS_CTRL]);
> }
>
> + if (attrs[NL80211_ATTR_TID_CONFIG_TX_RATES_TYPE]) {
> + int idx;
> + enum
On Tue, 2019-03-26 at 14:59 +0530, Tamizh chelvam wrote:
>
> @@ -13288,6 +13291,37 @@ static int parse_tid_conf(struct
> cfg80211_registered_device *rdev,
> nla_get_u8(attrs[NL80211_ATTR_TID_CONFIG_NOACK]);
> }
>
> + if
On Tue, 2019-03-26 at 14:59 +0530, Tamizh chelvam wrote:
>
> + [NL80211_ATTR_TID_CONFIG_RETRY] = { .type = NLA_FLAG },
> + [NL80211_ATTR_TID_CONFIG_RETRY_SHORT] = NLA_POLICY_MIN(NLA_U8, 1),
> + [NL80211_ATTR_TID_CONFIG_RETRY_LONG] = NLA_POLICY_MIN(NLA_U8, 1),
>
I guess it's a
Hi,
Sorry, I apologize for taking so long to review this (again).
> +enum ieee80211_tid_conf_mask {
> + IEEE80211_TID_CONF_NOACK= BIT(0),
> +};
> +
> +/**
> + * struct ieee80211_tid_cfg - TID specific configuration
> + * @tid: TID number
> + * @tid_conf_mask: bitmap indicating which
On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
>
> I understand your concern. Yes, I am using high end AP for throughput
> test. I'd say 1.2 Gbps is not the worst case since we can achieve max
> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is
> the minimum
On Tue, 2019-04-02 at 08:59 -0400, Bob Copeland wrote:
> On Tue, Apr 02, 2019 at 12:00:29PM +0530, Balaji Pothunoori wrote:
> > > Should this really dBm? It's a bit asymmetric for WIPHY_TX_POWER_LEVEL
> > > to
> > > use mBm and this to use dBm, and I might want to adjust in half-dB steps
> > > if
On Wed, 2019-03-13 at 11:08 +0800, Yibo Zhao wrote:
> Currently, we are using u32 for tx_bytes in fq_tin.
> If the throughput stays more than 1.2Gbps, tx_bytes
> statistics overflow in about 1 min.
>
> In order to allow us to trace the tx_bytes statistics
> for longer time in high throughput,
On Fri, 2019-02-22 at 14:40 +0100, Toke Høiland-Jørgensen wrote:
>
> And send it directly to stable, or does it need to go through you?
I added a Cc: stable tag. So all you really need to do is wait for the
emails telling you it failed to apply, and handle accordingly :)
johannes
On Fri, 2019-02-22 at 14:06 +0100, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > Toke Høiland-Jørgensen wrote:
> >
> > > When we did the original tests for the optimal value of sk_pacing_shift,
> > > we
> > > came up with 6 ms of buff
On Mon, 2019-01-28 at 10:19 +0530, Karthikeyan Periyasamy wrote:
> > At the same time, what happens today actually? Do all frames from non-
> > associated clients come up to the host? If so, is this not a problem
> > for all APs, not just ath10k?
>
> Today, without this patch. No frames from
On Tue, 2018-11-20 at 08:10 +0530, Karthikeyan Periyasamy wrote:
> > This patch only talks about "allow an AP" etc. and so while important,
> > power isn't the _utmost_ concern like on mobile. Given an efficient
> > filtering solution in software, would that be sufficient?
>
> Assume in a
> +void ieee80211_schedule_txq(struct ieee80211_hw *hw,
> + struct ieee80211_txq *txq)
> + __acquires(txq_lock) __releases(txq_lock)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> + struct txq_info *txqi = to_txq_info(txq);
> +
> +
On Thu, 2019-01-17 at 16:54 +0530, Balaji Pothunoori wrote:
>
> + * @txpwr: indicates the tx power, in mBm, to be used when sending data
> frames
> + * to the STA.
> + * @type: In particular if TPC %type is NL80211_TX_POWER_LIMITED then txpwr
> will
> + * be less than or equal to specified
On Thu, 2019-01-17 at 16:52 +0530, Balaji Pothunoori wrote:
>
> + s16 txpwr;
> + enum nl80211_tx_power_setting type;
you should probably call this txpwr_type, or do something like
struct {
s16 power;
enum ... type;
} txpwr;
> + [NL80211_ATTR_STA_TX_POWER_SETTING] =
On Thu, 2018-11-15 at 09:10 -0800, Toke Høiland-Jørgensen wrote:
> Louie Lu writes:
>
> > Hi Rajkumar, Toke,
> >
> > I found the series (v3,4/6) remove the debugfs remove reset station's
> > airtime method, and didn't added at here.
> >
> > Not sure how to help this kind of situation, do I
On Fri, 2018-11-09 at 09:40 +, Sergey Matyukevich wrote:
>
> Ok. So if driver receives retry value (-1), it should reset to some
> default value known to driver or firmware. IMHO it worth making it
> more explicit: in its current form this convention will not be obvious
> for driver authors.
On Sat, 2018-10-20 at 04:05 -0700, Rajkumar Manoharan wrote:
>
> + * @txq: pointer obtained from station or virtual interface, or from
> + * ieee80211_next_txq()
nit: please just indent by a single tab for continuation, trying to line
it all up doesn't really make it more readable
I see
On Mon, 2018-10-22 at 23:25 +0530, Tamizh chelvam wrote:
>
> +/*
> + * @NL80211_ATTR_TID: a TID value (u8 attribute)
This comment should have the kernel-doc boilerplate
Also, the names should be NL80211_TID_ATTR_* to disambiguate the
namespace from the top-level NL80211_ATTR_*.
> +static const
Hi,
> Adds infrastructure for driver to offload NoAck functionality,
> driver like ath10k could make use of it. Also extends the
> current ndev wide NoAck policy to per-station, with sta level
> NoAck policy configuration userspace could selectively turn off/on
> Noack based on various connection
1 - 100 of 219 matches
Mail list logo
