* Re: cellular modem APIs - take 2
From: Johannes Berg @ 2019-05-29 20:16 UTC (permalink / raw)
To: Dan Williams, netdev, linux-wireless
Cc: Subash Abhinov Kasiviswanathan, Sean Tranchetti, Daniele Palmas,
Aleksander Morgado, Bjørn Mork
In-Reply-To: <cb2ef612be9e347a7cbceb26831f8d5ebea4eacf.camel@redhat.com>
Hi Dan,
> > Quite possibly there might be some additional (vendor-dependent?)
> > configuration for when such netdevs are created, but we need to
> > figure out if that really needs to be at creation time, or just
> > ethtool later or something like that. I guess it depends on how
> > generic it needs to be.
>
> I'm pretty sure it would have to be async via netlink or ethtool or
> whatever later, because the control plane (ModemManager,
> libmbim/libqmi, oFono, etc) is what sets up the PDP/EPS context and
> thus the data channel. A netdev (or a queue on that netdev) would be a
> representation of that data channel, but that's not something the
> kernel knows beforehand.
Right.
It just seemed that people do want to have a netdev (if only to see that
their driver loaded and use ethtool to dump the firmware version), and
then you can reassign it to some actual context later?
It doesn't really matter much. If you have a control channel and higher-
level abstraction (wwan device) then having the netdev is probably more
of a nuisance and mostly irrelevant, just might be useful for legacy
reasons.
> > 3) Separately, we need to have an ability to create "generalized control
> > channels". I'm thinking there would be a general command "create
> > control channel" with a given type (e.g. ATCMD, RPC, MBIM, GNSS) plus
> > a list of vendor-specific channels (e.g. for tracing).
> >
> > I'm unsure where this channel should really go - somehow it seems to
> > me that for many (most?) of these registering them as a serial line
> > would be most appropriate, but some, especially vendor-defined
> > channels like tracing, would probably better use a transport that's
> > higher bandwidth than, e.g. netdevs.
>
> There's only a couple protocols that are run over serial transport,
> namely AT, DM/DIAG, and Sierra's CnS.
Right.
> Most of the rest like QMI and MBIM are packet-based protocols that can
> use different transports. QMI for example can use CDC-WDM for USB
> devices but on SoCs will use Qualcomm's SMD I believe.
Right, though transport and protocol are sort of different issues.
> Should you really need to account for these specially, or would some
> kind of sysfs linkage like SET_NETDEV_DEV() be more appropriate?
>
> Really all you want to do is (a) identify which WWAN device a given
> control/data channel is for and (b) perhaps tag different control/data
> channels with attributes like primary/secondary/gps/sim/etc often
> through USB attributes or hardcoded data on SoCs.
Ah, that brings up something I completely forgot.
I was thinking only of the case that the control channel(s) to the
device is/are all managed by the *kernel* driver, i.e. you'd have some
device-specific driver that has an interface into userspace to talk to
the modem's control channel (and that we could abstract).
However, yes, that's not true - many will be like USB where the control
channel is driven by a generic kernel driver (e.g. maybe usb-serial) or
no kernel driver at all, and then this linkage is probably the right
approach. Need to think about it.
OTOH, there will be device-specific ways to add more control channels
(say for debug/trace purposes etc.) and those would not have a "natural"
interface to userspace like control channels with generic/no drivers.
> > One way I thought of doing this was to create an abstraction in the
> > wwan framework that lets the driver use SKBs anyway (i.e. TX and RX
> > on these channels using SKBs) and then translate them to some channel
> > in the framework - that way, we can even select at runtime if we want
> > a netdev (not really plugged into the network stack, ARPHDR_VOID?) or
> > some other kind of transport. Building that would allow us to add
> > transport types in the future too.
>
> I'm not quite sure what you mean here, can you explain?
I was just thinking of the mechanics of doing this in the driver (while,
like I said above, completely forgetting about the non-monolithic driver
case). It's not really that important.
> > I guess such a channel should also be created by default, if it's
> > not already created by the driver in some out-of-band way anyway (and
> > most likely it shouldn't be, but I guess drivers might have some
> > entirely different communication channels for AT CMDs?)
>
> For existing devices we're not talking about monolithic drivers here
> (excepting 'hso') which I guess is part of the issue.
Right, and doesn't help I forgot about this ;-)
> A given device
> might be driven by 2 or 3 different kernel drivers (usb-serial derived,
> netdev, cdc-wdm) and they all expose different channels and none of
> them coordinate. You have to do sysfs matching up the family tree to
> find out they are associated with each other. If the kernel can take
> over some of that responsibility great.
Right. I guess it's hard for the kernel to take responsibility unless we
teach all the components (usb-serial, ...) that certain devices are
modems and should get some (additional?) registration?
> But the diversity is large. Any given TTY representing an AT channel
> could be from USB drivers (usb-serial, cdc-wdm, vendor-specific driver
> like sierra/hso, option) or PCI (nozomi) or platform stuff (Qualcomm
> SoC ones). You can also do AT-over-QMI if you want.
Right. The linkage here is the interesting part - for platform stuff
that might be easier (devicetree?) but not sure how we could teach that
to e.g. usb-serial, and nozomi is interesting because ... where is the
data plane even?
> I think it's worth discussing how this could be better unified but
> maybe small steps to get there are more feasible.
Fair point.
> > 4) There was a question about something like pure IP channels that
> > belong to another PDN and apparently now separate netdevs might be
> > used, but it seems to me that could just be a queue reserved on the
> > regular netdevs and then when you say ("enable video streaming on
> > wwan1 interface") that can do some magic to classify the video
> > packets (DSCP?) to another hardware queue for better QoS.
>
> Most stuff is pure IP these days (both for QMI/rmnet and MBIM at least)
> and having ethernet encapsulation is kinda pointless.
Yeah, true, not really sure why I was distinguishing this in these
terms. I think the use case really was just giving some packets higher
priority, putting them into a different *hardware* queue so the device
can see them even if the "normal" hardware queue is completely
backlogged.
Kinda a typical multi-queue TX use case.
> But anyway you'd
> need some mechanism to map that particular queue to a given channel/PDN
> created by the control channel.
Well, I was thinking that mechanism was creating the netdev, but then
*within* that some QoS seems to be desired.
> But classification is mostly done in the hardware/network because
> setting different QoS for a given PDP/EPS context is basically saying
> how much airtime the queue gets. No amount of kernel involvement is
> going to change what the network lets you transmit.
Right.
> And I honestly
> don't know how the firmware responds when its internal queues for a
> given context are full that would tell a kernel queue to stop sending
> more.
Well, at the very least it'll stop pulling packets from DMA/whatever, so
the kernel has to back off, right?
johannes
^ permalink raw reply
* Re: cellular modem APIs - take 2
From: Denis Kenzior @ 2019-05-29 20:35 UTC (permalink / raw)
To: Johannes Berg, Dan Williams, netdev, linux-wireless
Cc: Subash Abhinov Kasiviswanathan, Sean Tranchetti, Daniele Palmas,
Aleksander Morgado, Bjørn Mork
In-Reply-To: <58bc88b7eda912133ad0fc4718ac917adc8fa63b.camel@sipsolutions.net>
Hi Johannes,
>
> It just seemed that people do want to have a netdev (if only to see that
> their driver loaded and use ethtool to dump the firmware version), and
> then you can reassign it to some actual context later?
I can see that this is useful for developers, but really
counterproductive in production. You have a bunch of services (systemd,
NM, ConnMan, dhcpcd, etc, etc, etc) all observing the newly created
devices and trying to 'own' them. Which makes no freaking sense to do
until those devices are really usable. Just because it is a netdev,
doesn't mean it is ethernet or behaves like it.
That also leads to expectations from users that want stuff like
udev-consistent-naming to work, even though udev has no idea wtf a given
device is, when it is ready or not ready, etc. And the flip side, there
may be systems that do not use systemd/udevd, so the daemons responsible
for management of such devices cannot sanely assume anything. It is
just pure chaos.
And then there's hotplug/unplug to worry about ;)
So I would like to reiterate Marcel's point: creating unmanaged devices
should not be the default behavior.
>
> It doesn't really matter much. If you have a control channel and higher-
> level abstraction (wwan device) then having the netdev is probably more
> of a nuisance and mostly irrelevant, just might be useful for legacy
> reasons.
Which we should be trying to eradicate, not encourage ;)
>> Should you really need to account for these specially, or would some
>> kind of sysfs linkage like SET_NETDEV_DEV() be more appropriate?
>>
>> Really all you want to do is (a) identify which WWAN device a given
>> control/data channel is for and (b) perhaps tag different control/data
>> channels with attributes like primary/secondary/gps/sim/etc often
>> through USB attributes or hardcoded data on SoCs.
Userspace can also choose to do its own multiplexing, so you can't even
really assume the above is what you 'want'.
Regards,
-Denis
^ permalink raw reply
* Re: cellular modem APIs - take 2
From: Denis Kenzior @ 2019-05-29 20:44 UTC (permalink / raw)
To: Johannes Berg, Marcel Holtmann
Cc: netdev, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Sean Tranchetti, Daniele Palmas, Aleksander Morgado,
Bjørn Mork
In-Reply-To: <acf18b398fd63f2dfece5981ebd5057141529e6a.camel@sipsolutions.net>
Hi Johannes,
>
> After all, I'm not really proposing that we put oFono or something like
> it into the kernel - far from it! I'm only proposing that we kill the
> many various ways of creating and managing the necessary netdevs (VLANs,
> sysfs, rmnet, ...) from a piece of software like oFono (or libmbim or
> whatever else).
I do like the concept of unifying this if possible. The question is, is
it actually possible :) I think Dan covered most of the aspects of what
userspace has to deal with already. But the basic issue is that there's
a heck of a lot of different ways of doing it.
>
> Apart from CAIF and phonet, oFono doesn't even try to do this though,
> afaict, so I guess it relies on the default netdev created, or some out-
> of-band configuration is still needed?
Actually it can. We can drive modems which provide only a single serial
port and run multiplexing over that. So we fully control the number of
control channels created, the number of netdevs created and even
create/destroy them on as needed basis. And these netdevs can be PPP
encapsulated or pure IP or whatever else.
Regards,
-Denis
^ permalink raw reply
* [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Lorenzo Bianconi @ 2019-05-29 21:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
aligned buffer sizes for rx") since it breaks A-MSDU support.
When A-MSDU is enable the device can receive frames up to
q->buf_size but they will be discarded in mt76u_process_rx_entry
since there is no enough room for skb_shared_info.
Fix it by introducing q->data_size and take info account
skb_shared_info size in q->buf_size
Moreover increase buffer size even for legacy mode (scatter-gather not
available)
Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ++++
drivers/net/wireless/mediatek/mt76/usb.c | 26 ++++++++++++-----------
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 8ecbf81a906f..f118919ca5ff 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -31,6 +31,9 @@
#define MT_MCU_RING_SIZE 32
#define MT_RX_BUF_SIZE 2048
+#define MT_BUF_WITH_OVERHEAD(x) \
+ ((x) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
+
struct mt76_dev;
struct mt76_wcid;
@@ -124,6 +127,7 @@ struct mt76_queue {
u16 tail;
int ndesc;
int queued;
+ int data_size;
int buf_size;
bool stopped;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index bbaa1365bbda..9e328e4532b3 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -299,7 +299,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue *q, struct urb *urb,
page = virt_to_head_page(data);
offset = data - page_address(page);
- sg_set_page(&urb->sg[i], page, q->buf_size, offset);
+ sg_set_page(&urb->sg[i], page, q->data_size, offset);
}
if (i < nsgs) {
@@ -311,7 +311,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue *q, struct urb *urb,
}
urb->num_sgs = max_t(int, i, urb->num_sgs);
- urb->transfer_buffer_length = urb->num_sgs * q->buf_size,
+ urb->transfer_buffer_length = urb->num_sgs * q->data_size;
sg_init_marker(urb->sg, urb->num_sgs);
return i ? : -ENOMEM;
@@ -322,14 +322,13 @@ mt76u_refill_rx(struct mt76_dev *dev, struct urb *urb, int nsgs, gfp_t gfp)
{
struct mt76_queue *q = &dev->q_rx[MT_RXQ_MAIN];
- if (dev->usb.sg_en) {
+ if (dev->usb.sg_en)
return mt76u_fill_rx_sg(dev, q, urb, nsgs, gfp);
- } else {
- urb->transfer_buffer_length = q->buf_size;
- urb->transfer_buffer = page_frag_alloc(&q->rx_page,
- q->buf_size, gfp);
- return urb->transfer_buffer ? 0 : -ENOMEM;
- }
+
+ urb->transfer_buffer_length = q->data_size;
+ urb->transfer_buffer = page_frag_alloc(&q->rx_page, q->buf_size, gfp);
+
+ return urb->transfer_buffer ? 0 : -ENOMEM;
}
static int
@@ -446,8 +445,9 @@ mt76u_process_rx_entry(struct mt76_dev *dev, struct urb *urb)
return 0;
data_len = min_t(int, len, data_len - MT_DMA_HDR_LEN);
- if (MT_DMA_HDR_LEN + data_len > SKB_WITH_OVERHEAD(q->buf_size)) {
- dev_err_ratelimited(dev->dev, "rx data too big %d\n", data_len);
+ if (MT_DMA_HDR_LEN + data_len > q->data_size) {
+ dev_err_ratelimited(dev->dev, "rx data too big %d\n",
+ data_len);
return 0;
}
@@ -577,8 +577,10 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
if (!q->entry)
return -ENOMEM;
- q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
+ q->data_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
+ q->buf_size = MT_BUF_WITH_OVERHEAD(q->data_size);
q->ndesc = MT_NUM_RX_ENTRIES;
+
for (i = 0; i < q->ndesc; i++) {
err = mt76u_rx_urb_alloc(dev, &q->entry[i]);
if (err < 0)
--
2.21.0
^ permalink raw reply related
* [PATCH] ath10k: fix PCIE device wake up failed
From: Miaoqing Pan @ 2019-05-30 1:49 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Miaoqing Pan
Observed PCIE device wake up failed after ~120 iterations of
soft-reboot test. The error message is
"ath10k_pci 0000:01:00.0: failed to wake up device : -110"
The call trace as below:
ath10k_pci_probe -> ath10k_pci_force_wake -> ath10k_pci_wake_wait ->
ath10k_pci_is_awake
Once trigger the device to wake up, we will continuously check the RTC
state until it returns RTC_STATE_V_ON or timeout.
But for QCA99x0 chips, we use wrong value for RTC_STATE_V_ON.
Occasionally, we get 0x7 on the fist read, we thought as a failure
case, but actually is the right value, also verified with the spec.
So fix the issue by changing RTC_STATE_V_ON from 0x5 to 0x7, passed
~2000 iterations.
Tested HW: QCA9984
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index ad082b7..b242085 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -158,7 +158,7 @@
};
const struct ath10k_hw_values qca99x0_values = {
- .rtc_state_val_on = 5,
+ .rtc_state_val_on = 7,
.ce_count = 12,
.msi_assign_ce_max = 12,
.num_target_ce_config_wlan = 10,
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Tony Chuang @ 2019-05-30 2:29 UTC (permalink / raw)
To: Larry Finger, kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <f5bd9ab0-c32c-dcc6-9451-09e6b7f50a96@lwfinger.net>
> -----Original Message-----
> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
> Sent: Wednesday, May 29, 2019 11:17 PM
> To: Tony Chuang; kvalo@codeaurora.org
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>
> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >
> > Some functions that should be static are unnecessarily exposed, remove
> > their declaration in header file phy.h.
> >
> > After resolving their declaration order, they can be declared as static.
> > So this commit changes nothing except the order and marking them static.
> >
> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> This patch does not apply. Using quilt to see what is wrong, there are 6
> changes
> that have already been applied.
>
> Larry
>
These patches are based on
https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-drivers
branch master
commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
Author: YueHaibing <yuehaibing@huawei.com>
Date: Sat May 4 18:32:24 2019 +0800
rtw88: Make some symbols static
It should apply, did I miss something?
Yan-Hsuan
^ permalink raw reply
* RE: [PATCH] rtw88: Remove set but not used variable 'ip_sel' and 'orig'
From: Tony Chuang @ 2019-05-30 2:32 UTC (permalink / raw)
To: YueHaibing, kvalo@codeaurora.org, davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20190529145740.22804-1-yuehaibing@huawei.com>
> -----Original Message-----
> From: YueHaibing [mailto:yuehaibing@huawei.com]
> Sent: Wednesday, May 29, 2019 10:58 PM
> To: Tony Chuang; kvalo@codeaurora.org; davem@davemloft.net
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> linux-wireless@vger.kernel.org; YueHaibing
> Subject: [PATCH] rtw88: Remove set but not used variable 'ip_sel' and 'orig'
>
> Fixes gcc '-Wunused-but-set-variable' warnings:
>
> drivers/net/wireless/realtek/rtw88/pci.c: In function rtw_pci_phy_cfg:
> drivers/net/wireless/realtek/rtw88/pci.c:978:6: warning: variable ip_sel set
> but not used [-Wunused-but-set-variable]
> drivers/net/wireless/realtek/rtw88/phy.c: In function
> phy_tx_power_limit_config:
> drivers/net/wireless/realtek/rtw88/phy.c:1607:11: warning: variable orig set
> but not used [-Wunused-but-set-variable]
>
> They are never used, so can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 3 ---
> drivers/net/wireless/realtek/rtw88/phy.c | 3 +--
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index 353871c27779..8329f4e447b7 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -977,7 +977,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
> u16 cut;
> u16 value;
> u16 offset;
> - u16 ip_sel;
> int i;
>
> cut = BIT(0) << rtwdev->hal.cut_version;
> @@ -990,7 +989,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
> break;
> offset = para->offset;
> value = para->value;
> - ip_sel = para->ip_sel;
> if (para->ip_sel == RTW_IP_SEL_PHY)
> rtw_mdio_write(rtwdev, offset, value, true);
> else
> @@ -1005,7 +1003,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev
> *rtwdev)
> break;
> offset = para->offset;
> value = para->value;
> - ip_sel = para->ip_sel;
> if (para->ip_sel == RTW_IP_SEL_PHY)
> rtw_mdio_write(rtwdev, offset, value, false);
> else
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.c
> b/drivers/net/wireless/realtek/rtw88/phy.c
> index 404d89432c96..c3e75ffe27b5 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.c
> +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> @@ -1604,12 +1604,11 @@ void rtw_phy_tx_power_by_rate_config(struct
> rtw_hal *hal)
> static void
> phy_tx_power_limit_config(struct rtw_hal *hal, u8 regd, u8 bw, u8 rs)
> {
> - s8 base, orig;
> + s8 base;
> u8 ch;
>
> for (ch = 0; ch < RTW_MAX_CHANNEL_NUM_2G; ch++) {
> base = hal->tx_pwr_by_rate_base_2g[0][rs];
> - orig = hal->tx_pwr_limit_2g[regd][bw][rs][ch];
> hal->tx_pwr_limit_2g[regd][bw][rs][ch] -= base;
> }
>
Hi Haibing
I have submitted a patch fix the unused variable in phy.c
Which is,
> drivers/net/wireless/realtek/rtw88/phy.c: In function
> phy_tx_power_limit_config:
> drivers/net/wireless/realtek/rtw88/phy.c:1607:11: warning: variable orig set
> but not used [-Wunused-but-set-variable]
Can you drop the changes in phy.c and remain the changes in pci.c?
Thanks.
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Larry Finger @ 2019-05-30 2:57 UTC (permalink / raw)
To: Tony Chuang, kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17FABBF@RTITMBSVM04.realtek.com.tw>
On 5/29/19 9:29 PM, Tony Chuang wrote:
>
>
>> -----Original Message-----
>> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
>> Sent: Wednesday, May 29, 2019 11:17 PM
>> To: Tony Chuang; kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>>
>> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
>>> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>>>
>>> Some functions that should be static are unnecessarily exposed, remove
>>> their declaration in header file phy.h.
>>>
>>> After resolving their declaration order, they can be declared as static.
>>> So this commit changes nothing except the order and marking them static.
>>>
>>> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>>
>> This patch does not apply. Using quilt to see what is wrong, there are 6
>> changes
>> that have already been applied.
>>
>> Larry
>>
>
>
> These patches are based on
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-drivers
> branch master
>
> commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> Author: YueHaibing <yuehaibing@huawei.com>
> Date: Sat May 4 18:32:24 2019 +0800
>
> rtw88: Make some symbols static
>
>
> It should apply, did I miss something?
I was trying to apply the patch to wireless-drivers-next. That may be my
problem. The other 10 applied OK.
Larry
^ permalink raw reply
* Re: [RFC PATCH v3] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-05-30 4:51 UTC (permalink / raw)
To: Daniel Drake
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp46on32VgWtCe7WsGHXp3Jk16qTh6saf0Vj0Y4Ry5z1n7g@mail.gmail.com>
On Thu, May 30, 2019 at 2:12 AM Daniel Drake <drake@endlessm.com> wrote:
>
> Hi Chris,
>
> On Tue, May 28, 2019 at 11:03 PM Chris Chiu <chiu@endlessm.com> wrote:
> > + /*
> > + * Single virtual interface permitted since the driver supports STATION
> > + * mode only.
>
> I think you can be a bit more explicit by saying e.g.:
>
> Only one virtual interface permitted because only STA mode is
> supported and no iface_combinations are provided.
>
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > index 039e5ca9d2e4..2d612c2df5b2 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > @@ -4345,7 +4345,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> > h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
> >
> > h2c.ramask.arg = 0x80;
> > - h2c.b_macid_cfg.data1 = 0;
> > + h2c.b_macid_cfg.data1 = priv->ratr_index;
>
> I think ratr_index can be moved to be a function parameter of the
> update_rate_mask function. It looks like all callsites already know
> which value they want to set. Then you don't have to store it in the
> priv structure.
>
You mean moving the ratr_index to be the 4th function parameter of
update_rate_mask which has 2 candidates rtl8xxxu_update_rate_mask
and rtl8xxxu_gen2_update_rate_mask? I was planning to keep the
rtl8xxxu_update_rate_mask the same because old chips seems don't
need the rate index when invoking H2C command to change rate mask.
And rate index is not a common phrase/term for rate adaptive. Theoretically
we just need packet error rate, sgi and other factors to determine the rate
mask. This rate index seems to be only specific to newer Realtek drivers
or firmware for rate adaptive algorithm. I'd like to keep this for gen2 but
I admit it's ugly to put it in the priv structure. Any suggestion is
appreciated.
Thanks
> > @@ -5471,6 +5509,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
> >
> > switch (vif->type) {
> > case NL80211_IFTYPE_STATION:
> > + if (!priv->vif)
> > + priv->vif = vif;
> > + else
> > + return -EOPNOTSUPP;
> > rtl8xxxu_stop_tx_beacon(priv);
>
> rtl8xxxu_remove_interface should also set priv->vif back to NULL.
>
> > @@ -6183,6 +6259,8 @@ static void rtl8xxxu_disconnect(struct usb_interface *interface)
> > mutex_destroy(&priv->usb_buf_mutex);
> > mutex_destroy(&priv->h2c_mutex);
> >
> > + cancel_delayed_work_sync(&priv->ra_watchdog);
>
> Given that the work was started in rtl8xxxu_start, I think it should
> be cancelled in rtl8xxxu_stop() instead.
>
> Daniel
^ permalink raw reply
* Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Kalle Valo @ 2019-05-30 4:56 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
In-Reply-To: <f1f5b9f564e374174a9a2bbae29f4b72fd4c6ddd.1559163190.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
> Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
> aligned buffer sizes for rx") since it breaks A-MSDU support.
> When A-MSDU is enable the device can receive frames up to
> q->buf_size but they will be discarded in mt76u_process_rx_entry
> since there is no enough room for skb_shared_info.
> Fix it by introducing q->data_size and take info account
> skb_shared_info size in q->buf_size
> Moreover increase buffer size even for legacy mode (scatter-gather not
> available)
>
> Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Felix, can I take this directly to wireless-drivers?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH v3] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-05-30 4:58 UTC (permalink / raw)
To: Larry Finger
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <5f5e262d-aadb-cca0-8576-879735366a73@lwfinger.net>
On Thu, May 30, 2019 at 2:22 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> On 5/29/19 12:03 AM, Chris Chiu wrote:
> > We have 3 laptops which connect the wifi by the same RTL8723BU.
> > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> > They have the same problem with the in-kernel rtl8xxxu driver, the
> > iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> > Nevertheless, the signal strength is reported as around -40dBm,
> > which is quite good. From the wireshark capture, the tx rate for each
> > data and qos data packet is only 1Mbps. Compare to the driver from
> > https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12
> > Mbps or more. The signal strength is reported similarly around
> > -40dBm. That's why we want to improve.
>
> The driver at GitHub was written by Realtek. I only published it in a prominent
> location, and fix it for kernel API changes. I would say "the Realtek driver at
> https://...", and every mention of "Larry's driver" should say "Realtek's
> driver". That attribution is more correct.
Thanks. I'll modify this in next revision.
> >
> > After reading the source code of the rtl8xxxu driver and Larry's, the
> > major difference is that Larry's driver has a watchdog which will keep
> > monitoring the signal quality and updating the rate mask just like the
> > rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> > And this kind of watchdog also exists in rtlwifi driver of some specific
> > chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> > the same member function named dm_watchdog and will invoke the
> > corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> > mask.
> >
> > With this commit, the tx rate of each data and qos data packet will
> > be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> > to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> > the lowest rate from the rate mask and explains why the tx rate of
> > data and qos data is always lowest 1Mbps because the default rate mask
> > passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> > and MCS rate. However, with Larry's driver, the tx rate observed from
> > wireshark under the same condition is almost 65Mbps or 72Mbps.
> >
> > I believe the firmware of RTL8723BU may need fix. And I think we
> > can still bring in the dm_watchdog as rtlwifi to improve from the
> > driver side. Please leave precious comments for my commits and
> > suggest what I can do better. Or suggest if there's any better idea
> > to fix this. Thanks.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
>
> I have not tested this patch, but I plan to soon.
>
> Larry
>
>
^ permalink raw reply
* Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Kalle Valo @ 2019-05-30 4:59 UTC (permalink / raw)
To: Tony Chuang; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17FABBF@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> -----Original Message-----
>> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
>> Sent: Wednesday, May 29, 2019 11:17 PM
>> To: Tony Chuang; kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>>
>> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
>> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> >
>> > Some functions that should be static are unnecessarily exposed, remove
>> > their declaration in header file phy.h.
>> >
>> > After resolving their declaration order, they can be declared as static.
>> > So this commit changes nothing except the order and marking them static.
>> >
>> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>>
>> This patch does not apply. Using quilt to see what is wrong, there are 6
>> changes
>> that have already been applied.
>>
>> Larry
>>
>
>
> These patches are based on
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-drivers
> branch master
>
> commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> Author: YueHaibing <yuehaibing@huawei.com>
> Date: Sat May 4 18:32:24 2019 +0800
>
> rtw88: Make some symbols static
>
>
> It should apply, did I miss something?
I keep the bar high and take to wireless-drivers only patches which fix
important, user visible problems. Everything else goes to
wireless-drivers-next. So you should use wireless-drivers-next as the
baseline for all regular patches.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Tony Chuang @ 2019-05-30 5:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <87v9xspmfd.fsf@codeaurora.org>
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Thursday, May 30, 2019 1:00 PM
> To: Tony Chuang
> Cc: Larry Finger; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>
> Tony Chuang <yhchuang@realtek.com> writes:
>
> >> -----Original Message-----
> >> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry
> Finger
> >> Sent: Wednesday, May 29, 2019 11:17 PM
> >> To: Tony Chuang; kvalo@codeaurora.org
> >> Cc: linux-wireless@vger.kernel.org
> >> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting
> routines
> >>
> >> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
> >> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >> >
> >> > Some functions that should be static are unnecessarily exposed, remove
> >> > their declaration in header file phy.h.
> >> >
> >> > After resolving their declaration order, they can be declared as static.
> >> > So this commit changes nothing except the order and marking them
> static.
> >> >
> >> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >>
> >> This patch does not apply. Using quilt to see what is wrong, there are 6
> >> changes
> >> that have already been applied.
> >>
> >> Larry
> >>
> >
> >
> > These patches are based on
> >
> >
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
> ivers
> > branch master
> >
> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> > Author: YueHaibing <yuehaibing@huawei.com>
> > Date: Sat May 4 18:32:24 2019 +0800
> >
> > rtw88: Make some symbols static
> >
> >
> > It should apply, did I miss something?
>
> I keep the bar high and take to wireless-drivers only patches which fix
> important, user visible problems. Everything else goes to
> wireless-drivers-next. So you should use wireless-drivers-next as the
> baseline for all regular patches.
Hi, Kalle
But this series has dependency with " rtw88: Make some symbols static"
Or you can handle it
>
> --
> Kalle Valo
>
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Kalle Valo @ 2019-05-30 5:11 UTC (permalink / raw)
To: Tony Chuang; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17FAD0F@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> > These patches are based on
>> >
>> >
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
>> ivers
>> > branch master
>> >
>> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
>> > Author: YueHaibing <yuehaibing@huawei.com>
>> > Date: Sat May 4 18:32:24 2019 +0800
>> >
>> > rtw88: Make some symbols static
>> >
>> >
>> > It should apply, did I miss something?
>>
>> I keep the bar high and take to wireless-drivers only patches which fix
>> important, user visible problems. Everything else goes to
>> wireless-drivers-next. So you should use wireless-drivers-next as the
>> baseline for all regular patches.
>
> But this series has dependency with " rtw88: Make some symbols static"
This is exactly why I keep the bar high for patches going to
wireless-drivers :) These depencies and conflicts are just too time
consuming otherwise.
> Or you can handle it
Unfortunately not, as I made a mistake when fast-forwarding
wireless-drivers and I cannot merge wireless-drivers into
wireles-drivers-next right now. So you just need to wait for the
depencies to trickle down to w-d-next, that will take few weeks.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Tony Chuang @ 2019-05-30 5:15 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <87r28gplw5.fsf@codeaurora.org>
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Thursday, May 30, 2019 1:11 PM
> To: Tony Chuang
> Cc: Larry Finger; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>
> Tony Chuang <yhchuang@realtek.com> writes:
>
> >> > These patches are based on
> >> >
> >> >
> >>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
> >> ivers
> >> > branch master
> >> >
> >> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> >> > Author: YueHaibing <yuehaibing@huawei.com>
> >> > Date: Sat May 4 18:32:24 2019 +0800
> >> >
> >> > rtw88: Make some symbols static
> >> >
> >> >
> >> > It should apply, did I miss something?
> >>
> >> I keep the bar high and take to wireless-drivers only patches which fix
> >> important, user visible problems. Everything else goes to
> >> wireless-drivers-next. So you should use wireless-drivers-next as the
> >> baseline for all regular patches.
> >
> > But this series has dependency with " rtw88: Make some symbols static"
>
> This is exactly why I keep the bar high for patches going to
> wireless-drivers :) These depencies and conflicts are just too time
> consuming otherwise.
>
> > Or you can handle it
>
> Unfortunately not, as I made a mistake when fast-forwarding
> wireless-drivers and I cannot merge wireless-drivers into
> wireles-drivers-next right now. So you just need to wait for the
> depencies to trickle down to w-d-next, that will take few weeks.
It means that I just need to wait for the patches in w-d to go to w-d-next?
So I don't need to resend them, just wait and you can merge this.
Yan-Hsuan
^ permalink raw reply
* Re: cellular modem APIs - take 2
From: Marcel Holtmann @ 2019-05-30 5:28 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Sean Tranchetti, Daniele Palmas, Aleksander Morgado,
Bjørn Mork
In-Reply-To: <acf18b398fd63f2dfece5981ebd5057141529e6a.camel@sipsolutions.net>
Hi Johannes,
>> Have you actually looked at Phonet or CAIF.
>
> Phonet is just a specific protocol spoken by a specific modem (family)
> for their control plane. Not all modems are going to be speaking this.
> Same for CAIF, really. I don't really see all that much that's generic
> (enough) here. It's unfortunate that in all this time nobody ever
> bothered to even try though, and just invented all their own mechanisms
> to precisely mirror the hardware and firmware they were working with.
>
> Theoretically now, you could build a driver that still speaks CAIF or
> phonet and then translates to a specific modem, but what would the point
> be?
>
> Now, I'm looking more at the data plan than the control plane, so I
> guess you could argue I should've not just mentioned MBIM and AT
> commands, but also something like Phonet/CAIF.
actually Phonet and CAIF are the transports and endpoint connections in the devices. The modem control protocol of Phonet was ISI and for CAIF it was actually AT commands (but I think there was a plan for ISI over CAIF).
>> And netdev by default seems like repeating the same mistake we have
>> done with WiFi. Your default context in LTE cases is only available
>> when actually registered to the LTE bearer. It is pretty much
>> pointless to have a netdev if you are not registered to the network.
>
> I partially agree with this.
>
> Of course, for WiFi, that's just wrong since the control path is on the
> netdev. Without a netdev, nothing works, and so not having one by
> default just adds something pointless to the setup necessary to bring up
> anything at all. It can be argued whether not allowing to remove it is
> right, but that just detracts from the discussion at hand and there's
> also a lot of history here.
Actually we need to have that history discussion on how it was also wrong for WiFi from my point of view. I do understand how things have made sense back in the days, but these days clinging to a netdev for control point even in WiFi makes no sense. Anyway, that is a different discussion.
My point is really that a lot of other things are ongoing before a modem even gets a data plane that would be mapped to a netdev.
> I do understand (and mostly agree) that having a netdev by default
> that's not connected to anything and has no functionality until you've
> done some out-of-band (as far as the netdev is concerned) setup is
> fairly much pointless, but OTOH having a netdev is something that people
> seem to want for various reasons (discovery, ethtool, …).
That worries me even more. Discovery via RTNL is pointless and totally racy. Usage of ethtool is pointless as well since we are dealing with IP only interfaces.
I have a felling that these points are from people that don’t really understand 3GPP and want to use command line tools to handle cellular modem. Back in the days iwconfig worked as well and so did pppd, but by now we all learned that this is not going to work. Especially in the world of 3GPP it is not going to work. I do not care a bit if ethtool or any other command line tool that wants to talk directly to kernel. Unless you have a way for a telephony daemon like oFono to get its work done, any of this above is just a distraction.
>> You have to do a lot of initial modem setup before you ever get to the
>> having your default context connected. Have a look at oFono and what
>> it does to bring up the modem.
>
> Sure.
>
>>> 2) Clearly, one needs to be able to create PDN netdevs, with the PDN
>>> given to the command. Here's another advantage: If these are created
>>> on top of another abstraction, not another netdev, they can have
>>> their own queues, multiqueue RX etc. much more easily.
> [...]
>> I think you need to provide actually a lot more details on how queue
>> control inside Linux would be helpful and actually work in the first
>> place. I don’t see how Linux will be ever in charge and not the modem
>> do this all for you.
>
> I think you misunderstand. I wasn't really talking about *queue control*
> (packet dequeue etc.) although this is *also* something that could be
> interesting, since the modem can only control packets that ever made it
> to the hardware.
>
> I was more thinking of what I actually wrote - "have their own queues,
> multiqueue RX etc." - i.e. control the software layer of the queues in
> the driver, rather than having all of that managed in some stacked
> netdev like VLAN.
>
> For example, with stacked netdevs like VLANs it gets difficult (and
> awkward from a network stack perspective) to put frames for different
> connections (stacked netdevs) into different hardware queues and manage
> flow control correctly.
>
> Similarly, if one connection has maybe multiple hardware queues (say for
> a specific video stream) disentangling that when you have stacked
> netdevs is much harder than when they're all separate.
>
> (And, of course, there's little point in having the underlying netdev to
> start with since it speaks a device-specific protocol the network stack
> will never understand.)
I am not convinced that any of this will help us since it is all network specific and the Linux job is just to feed the packets into the hardware.
>>> 3) Separately, we need to have an ability to create "generalized control
>>> channels". I'm thinking there would be a general command "create
>>> control channel" with a given type (e.g. ATCMD, RPC, MBIM, GNSS) plus
>>> a list of vendor-specific channels (e.g. for tracing).
> [...]
>>> I guess such a channel should also be created by default, if it's
>>> not already created by the driver in some out-of-band way anyway (and
>>> most likely it shouldn't be, but I guess drivers might have some
>>> entirely different communication channels for AT CMDs?)
>>
>> I would just use sockets like Phonet and CAIF.
>
> It was in fact one of the options I considered, but it seems to have
> very little traction with any other userspace, and having a separate
> socket family yet again also seems a bit pointless. I guess for devices
> that do already speak Phonet or CAIF that would make sense. Possible to
> some extent, but not really useful, would be to terminate the Phonet or
> CAIF protocol inside the driver or stack, but then you end up having to
> emulate some specific firmware behaviour ...
>
> So ultimately it boils down to what protocols you want to support and
> what kind of API they typically use. I guess I don't have enough hubris
> to propose unifying the whole command set and how you talk to your
> device ;-)
>
> I suppose you could have a socket type for AT commands, but is that
> really all that useful? Or a socket type that muxes the different
> control channels you might have, which gets close to phonet/caif.
As I stated above, Phonet and CAIF where just there to connect endpoints inside the hardware / platform. The protocol running inside these pipes could have been anything. I think what is more important is to figure out on how you access the pipes.
I think that Dan already stated this, the difference is just that we have protocols that underneath accept a transport that is serialized and stream based and others where the transport has packet boundaries and is packetized. These would obviously match to SOCK_STREAM and SOCK_SEQPACKET if you had to classify them.
Now that said, it is nice to just get a file descriptor from the kernel and then drive your protocol from userspace. We have used AT commands over TCP to connect to Phonesim for example. The AT commands don’t care if it is a real serial port, an emulated one by the modem driver or even a SOCK_STREAM socket. Same applies to all the other protocols and implementation that have been written over the years.
Dan also stated the major problems that the control and data path endpoints have been served by different drivers and figuring out what character device belongs to what network interface has been a mess. Creating a character device or a TTY is far too simple and because everybody wants to run pppd on a TTY that is what led us into this mess.
So what is really needed is a way to discovery the cellular modem and its capabilities towards the Linux host. Not all modems are equal and the number of control paths might be limited in the same way as the number of contexts it can expose or its voice to the host streams.
>> Frankly I have a problem if this is designed from the hardware point
>> of view. Unless you are familiar with how 3GPP works and what a
>> telephony stack like oFono has to do, there is really no point in
>> trying to create a WWAN subsystem.
>>
>> Anything defined needs to be defined in terms of 3GPP and not what
>> current drivers have hacked together.
>
> That objection makes no sense to me. 3GPP doesn't define how the data
> plane is implemented in your device/OS. There's a data plane, it carries
> IP packets, but how you get those to your applications?
>
> After all, I'm not really proposing that we put oFono or something like
> it into the kernel - far from it! I'm only proposing that we kill the
> many various ways of creating and managing the necessary netdevs (VLANs,
> sysfs, rmnet, ...) from a piece of software like oFono (or libmbim or
> whatever else).
>
> Apart from CAIF and phonet, oFono doesn't even try to do this though,
> afaict, so I guess it relies on the default netdev created, or some out-
> of-band configuration is still needed?
As stated above, that is the problem of default netdev by drivers. Phonet and CAIF (and also our own support with 207.07 and RawIP) are superior in these regards. That is also why phones used these. The rest was then cellular data cards where the thinking was ATD+PPP.
Regards
Marcel
^ permalink raw reply
* iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Marc Haber @ 2019-05-30 8:12 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev
Hi,
on my primary notebook, a Lenovo X260, with an Intel Wireless 8260
(8086:24f3), running Debian unstable, I have started to see network
hangs since upgrading to kernel 5.1. In this situation, I cannot
restart Network-Manager (the call just hangs), I can log out of X, but
the system does not cleanly shut down and I need to Magic SysRq myself
out of the running system. This happens about once every two days.
dmesg:
[38083.673678] lanw0: authenticate with 92:2a:a8:cb:8b:6c
[38083.682971] lanw0: send auth to 92:2a:a8:cb:8b:6c (try 1/3)
[38083.693860] lanw0: authenticated
[38083.697711] lanw0: associate with 92:2a:a8:cb:8b:6c (try 1/3)
[38083.703029] lanw0: RX ReassocResp from 92:2a:a8:cb:8b:6c (capab=0x411 status=0 aid=1)
[38083.705838] lanw0: associated
[38114.658765] lanw0: disconnect from AP 92:2a:a8:cb:8b:6c for new auth to 02:9f:c2:ab:b6:9f
[38114.671649] lanw0: authenticate with 02:9f:c2:ab:b6:9f
[38114.680074] lanw0: send auth to 02:9f:c2:ab:b6:9f (try 1/3)
[38114.692359] lanw0: authenticated
[38114.693609] lanw0: associate with 02:9f:c2:ab:b6:9f (try 1/3)
[38114.698697] lanw0: RX ReassocResp from 02:9f:c2:ab:b6:9f (capab=0x411 status=0 aid=1)
[38114.700878] lanw0: associated
[38179.708187] lanw0: disconnect from AP 02:9f:c2:ab:b6:9f for new auth to 92:2a:a8:cb:8b:6c
[38179.720183] lanw0: authenticate with 92:2a:a8:cb:8b:6c
[38179.728924] lanw0: send auth to 92:2a:a8:cb:8b:6c (try 1/3)
[38179.741439] lanw0: authenticated
[38179.745606] lanw0: associate with 92:2a:a8:cb:8b:6c (try 1/3)
[38179.750579] lanw0: RX ReassocResp from 92:2a:a8:cb:8b:6c (capab=0x411 status=0 aid=1)
[38179.752854] lanw0: associated
[38179.854525] list_del corruption. next->prev should be ffff88839d6167f8, but was ffff88839d616108
[38179.854533] ------------[ cut here ]------------
[38179.854535] kernel BUG at lib/list_debug.c:56!
[38179.854539] invalid opcode: 0000 [#2] SMP PTI
[38179.854542] CPU: 0 PID: 1869 Comm: kworker/0:2 Tainted: G D O 5.1.1-zgws1 #5.1.1.20190514.3
[38179.854543] Hardware name: LENOVO 20F5S5X100/20F5S5X100, BIOS R02ET63W (1.36 ) 12/15/2017
[38179.854552] Workqueue: events iwl_mvm_add_new_dqa_stream_wk [iwlmvm]
[38179.854556] RIP: 0010:__list_del_entry_valid.cold.1+0x20/0x4c
[38179.854557] Code: e3 d8 81 e8 a7 f2 da ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 20 e4 d8 81 e8 93 f2 da ff 0f 0b 48 c7 c7 d0 e4 d8 81 e8 85 f2 da ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 90 e4 d8 81 e8 71 f2 da ff 0f 0b
38179.854559] RSP: 0018:ffffc9000844fde8 EFLAGS: 00010246
[38179.854560] RAX: 0000000000000054 RBX: ffff88839d6167f8 RCX: 0000000000000000
[38179.854561] RDX: 0000000000000000 RSI: ffff8884318164d8 RDI: ffff8884318164d8
[38179.854562] RBP: ffff888150a56888 R08: 000000000000042a R09: 0000000000000063
[38179.854563] R10: 0000000000000000 R11: ffffc9000844fc88 R12: 000000000000000a
[38179.854564] R13: 0000000000000000 R14: ffff88842bdfe388 R15: 0000000000000000
[38179.854566] FS: 0000000000000000(0000) GS:ffff888431800000(0000) knlGS:0000000000000000
[38179.854567] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38179.854568] CR2: 00007f87c26a5000 CR3: 000000033154a006 CR4: 00000000003626f0
[38179.854569] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38179.854570] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[38179.854571] Call Trace:
[38179.854578] iwl_mvm_add_new_dqa_stream_wk+0x2b2/0x760 [iwlmvm]
[38179.854582] process_one_work+0x195/0x3d0
[38179.854584] worker_thread+0x2b/0x390
[38179.854586] ? create_worker+0x190/0x190
[38179.854588] kthread+0x111/0x130
[38179.854589] ? kthread_bind+0x20/0x20
[38179.854592] ret_from_fork+0x35/0x40
[38179.854594] Modules linked in: vhost_net vhost tap ext2 mmc_block tun hid_generic usbhid hid ctr ccm rfcomm fuse acpi_call(O) cpufreq_userspace cpufreq_powersave cpufreq_conservative cmac bnep option cdc_ether btusb usbnet btbcm btintel usb_wwan mii usbserial bluetooth hmac drbg ansi_cprng ecdh_generic msr bridge stp llc dummy ip6t_REJECT arc4 nf_reject_ipv6 ip6_tables nft_chain_nat ipt_MASQUERADE nf_nat wmi_bmof nft_chain_route_ipv4 snd_hda_codec_hdmi iwlmvm xt_TCPMSS mac80211 snd_hda_codec_realtek nft_counter snd_hda_codec_generic iwlwifi snd_hda_intel intel_rapl snd_hda_codec x86_pkg_temp_thermal intel_powerclamp ipt_REJECT nf_reject_ipv4 kvm_intel xt_tcpudp snd_hda_core kvm irqbypass snd_hwdep xt_conntrack intel_cstate intel_rapl_perf nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 snd_pcm nft_compat input_leds serio_raw snd_timer cfg80211 thinkpad_acpi nf_tables sg nvram mei_hdcp ledtrig_audio intel_pch_thermal tpm_tis snd nfnetlink tpm_tis_core soundcore tpm rfkill wmi rng_core a
c battery
[38179.854623] evdev pcc_cpufreq button tcp_bbr sch_fq nfsd auth_rpcgss nfs_acl lockd grace coretemp sunrpc loop ip_tables x_tables autofs4 btrfs zlib_deflate ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci libahci psmouse xhci_pci i2c_i801 e1000e libata xhci_hcd rtsx_pci mfd_core scsi_mod usbcore usb_common i915 i2c_algo_bit drm_kms_helper drm i2c_core thermal video
[38179.854652] ---[ end trace fd93637fcde969e6 ]---
[38179.854654] RIP: 0010:compaction_alloc+0x569/0x8c0
[38179.854656] Code: 62 01 00 00 49 be 00 00 00 00 00 16 00 00 eb 72 48 b8 00 00 00 00 00 ea ff ff 49 89 da 49 c1 e2 06 4d 8d 2c 02 4d 85 ed 74 3b <41> 8b 45 30 25 80 00 00 f0 3d 00 00 00 f0 0f 84 f9 00 00 00 41 80
[38179.854657] RSP: 0018:ffffc90001a5f900 EFLAGS: 00010286
[38179.854658] RAX: ffffea0000000000 RBX: 80000000000ffe00 RCX: 000000000000003c
[38179.854659] RDX: 80000000000ffe00 RSI: 0000000000000000 RDI: ffff8884417f42c0
[38179.854660] RBP: 8000000000100000 R08: 0000000000000000 R09: ffff8884417fab80
[38179.854661] R10: 0000000003ff8000 R11: 8000000000122c00 R12: 0000000000000020
[38179.854662] R13: ffffea0003ff8000 R14: 0000160000000000 R15: ffffc90001a5fae0
[38179.854664] FS: 0000000000000000(0000) GS:ffff888431800000(0000) knlGS:0000000000000000
[38179.854665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38179.854666] CR2: 00007f87c26a5000 CR3: 000000033154a006 CR4: 00000000003626f0
[38179.854667] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38179.854667] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Is that a known issue? I currently have this with 5.1.5, are there patches in
the queue that may be candidates to stabilize my wireless again?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Lorenzo Bianconi @ 2019-05-30 9:23 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
In-Reply-To: <87zhn4pmjv.fsf@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
> > aligned buffer sizes for rx") since it breaks A-MSDU support.
> > When A-MSDU is enable the device can receive frames up to
> > q->buf_size but they will be discarded in mt76u_process_rx_entry
> > since there is no enough room for skb_shared_info.
> > Fix it by introducing q->data_size and take info account
> > skb_shared_info size in q->buf_size
> > Moreover increase buffer size even for legacy mode (scatter-gather not
> > available)
> >
> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Felix, can I take this directly to wireless-drivers?
Hi Kalle,
please hold on with this patch, I will post a new one with a different
approach based on what Felix has suggested me
Regards,
Lorenzo
>
> --
> Kalle Valo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v5] ath10k: add support for controlling tx power to a station
From: Balaji Pothunoori @ 2019-05-30 9:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ashok Raj Nagarajan, Balaji Pothunoori
From: Ashok Raj Nagarajan <arnagara@codeaurora.org>
This patch will add the support to control the transmit power for traffic
to a station associated with the AP.
Underlying firmware will enforce that the maximum tx power will be based
on the regulatory requirements. If the user given transmit power is greater
than the allowed tx power in the given channel, then the firmware will use
the maximum tx power in the same channel.
Max and Min tx power values will depends on no of tx chain masks,
for QCA9984 allowed tx power range values from 6 to 23.
When 0 is sent to the firmware as tx power, it will revert to the default
tx power for the station.
Tested Hardware : QCA9984
Tested Firmware : 10.4-3.9.0.2-00046
Co-developed-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Ashok Raj Nagarajan <arnagara@codeaurora.org>
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
---
v2: removed mBm to dBm conversion
v3: rebased wmi.h changes
v4: no changes, rebased
v5: updated firmware details which
addresses Bob comments.
updated commit log.
Note: mac80211/cfg80211 patches got merged hence sending
ath10k alone with v5 and mentioned 10.4-3.9.0.2-00046
firmware is yet to be upstream.
patchwork links :
https://patchwork.kernel.org/patch/10876859/
https://patchwork.kernel.org/patch/10876853/
drivers/net/wireless/ath/ath10k/debug.h | 3 +++
drivers/net/wireless/ath/ath10k/mac.c | 39 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 6 +++++
3 files changed, 48 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index db78e85..2e43d8d 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -71,6 +71,9 @@ struct ath10k_pktlog_hdr {
/* FIXME: How to calculate the buffer size sanely? */
#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
+#define ATH10K_TX_POWER_MAX_VAL 70
+#define ATH10K_TX_POWER_MIN_VAL 0
+
extern unsigned int ath10k_debug_mask;
__printf(2, 3) void ath10k_info(struct ath10k *ar, const char *fmt, ...);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b500fd4..7e3e403 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6358,6 +6358,41 @@ static void ath10k_mac_dec_num_stations(struct ath10k_vif *arvif,
ar->num_stations--;
}
+static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
+ int ret = 0;
+ s16 txpwr;
+
+ if (sta->txpwr.type == NL80211_TX_POWER_AUTOMATIC) {
+ txpwr = 0;
+ } else {
+ txpwr = sta->txpwr.power;
+ if (!txpwr)
+ return -EINVAL;
+ }
+
+ if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+
+ ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_USE_FIXED_PWR, txpwr);
+ if (ret) {
+ ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
+ ret);
+ goto out;
+ }
+
+out:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static int ath10k_sta_state(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -8015,6 +8050,7 @@ static const struct ieee80211_ops ath10k_ops = {
.set_key = ath10k_set_key,
.set_default_unicast_key = ath10k_set_default_unicast_key,
.sta_state = ath10k_sta_state,
+ .sta_set_txpwr = ath10k_sta_set_txpwr,
.conf_tx = ath10k_conf_tx,
.remain_on_channel = ath10k_remain_on_channel,
.cancel_remain_on_channel = ath10k_cancel_remain_on_channel,
@@ -8703,6 +8739,9 @@ int ath10k_mac_register(struct ath10k *ar)
wiphy_ext_feature_set(ar->hw->wiphy,
NL80211_EXT_FEATURE_ENABLE_FTM_RESPONDER);
+ if (test_bit(WMI_SERVICE_TX_PWR_PER_PEER, ar->wmi.svc_map))
+ wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
/*
* on LL hardware queues are managed entirely by the FW
* so we only advertise to mac we can do the queues thing
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 12f57f9..a0ed078 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -200,6 +200,7 @@ enum wmi_service {
WMI_SERVICE_RTT_RESPONDER_ROLE,
WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
WMI_SERVICE_REPORT_AIRTIME,
+ WMI_SERVICE_TX_PWR_PER_PEER,
/* Remember to add the new value to wmi_service_name()! */
@@ -367,6 +368,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_RTT_RESPONDER_ROLE,
WMI_10_4_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
WMI_10_4_SERVICE_REPORT_AIRTIME,
+ WMI_10_4_SERVICE_TX_PWR_PER_PEER,
};
static inline char *wmi_service_name(enum wmi_service service_id)
@@ -491,6 +493,7 @@ static inline char *wmi_service_name(enum wmi_service service_id)
SVCSTR(WMI_SERVICE_RTT_RESPONDER_ROLE);
SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
SVCSTR(WMI_SERVICE_REPORT_AIRTIME);
+ SVCSTR(WMI_SERVICE_TX_PWR_PER_PEER);
case WMI_SERVICE_MAX:
return NULL;
@@ -818,6 +821,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, unsigned long *out,
WMI_SERVICE_PER_PACKET_SW_ENCRYPT, len);
SVCMAP(WMI_10_4_SERVICE_REPORT_AIRTIME,
WMI_SERVICE_REPORT_AIRTIME, len);
+ SVCMAP(WMI_10_4_SERVICE_TX_PWR_PER_PEER,
+ WMI_SERVICE_TX_PWR_PER_PEER, len);
}
#undef SVCMAP
@@ -6262,6 +6267,7 @@ enum wmi_peer_param {
WMI_PEER_USE_4ADDR = 0x6,
WMI_PEER_DEBUG = 0xa,
WMI_PEER_PHYMODE = 0xd,
+ WMI_PEER_USE_FIXED_PWR = 0x8,
WMI_PEER_DUMMY_VAR = 0xff, /* dummy parameter for STA PS workaround */
};
--
2.7.4
^ permalink raw reply related
* RE: [PATCH 1/2] mwifiex: add support for host wakeup via PCIE wake#
From: Ganapathi Bhat @ 2019-05-30 10:01 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Cc: Cathy Luo, Zhiyuan Yang, James Cao, Rakesh Parmar,
Sharvari Harisangam
In-Reply-To: <1559209955-10089-1-git-send-email-gbhat@marvell.com>
Hi Kalle,
I have pushed two patches usingn 'git send-mail' and below patch is the first one;
I could not see the patches in patchwork page(https://patchwork.kernel.org/project/linux-wireless/list/); Did you get this patch?
Regards,
Ganapathi
> -----Original Message-----
> From: Ganapathi Bhat <gbhat@marvell.com>
> Sent: Thursday, May 30, 2019 3:23 PM
> To: linux-wireless@vger.kernel.org
> Cc: Cathy Luo <cluo@marvell.com>; Zhiyuan Yang <yangzy@marvell.com>;
> James Cao <jcao@marvell.com>; Rakesh Parmar <rakeshp@marvell.com>;
> Sharvari Harisangam <sharvari@marvell.com>; Ganapathi Bhat
> <gbhat@marvell.com>
> Subject: [PATCH 1/2] mwifiex: add support for host wakeup via PCIE wake#
>
> From: Sharvari Harisangam <sharvari@marvell.com>
>
> PCIE WAKE# is asserted by firmware, when WoWLAN conditions are
> matched. Current driver does not enable PME bit needed for WAKE#
> assertion, causing host to remain in sleep even after WoWLAN conditions are
> matched. This commit fixes it by enabling wakeup (PME bit) in suspend
> handler.
>
> Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 27 +++++++++++++++------------
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 3fe81b2..0bd81d4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -147,11 +147,10 @@ static bool mwifiex_pcie_ok_to_access_hw(struct
> mwifiex_adapter *adapter)
> * If already not suspended, this function allocates and sends a host
> * sleep activate request to the firmware and turns off the traffic.
> */
> -static int mwifiex_pcie_suspend(struct device *dev)
> +static int mwifiex_pcie_suspend(struct pci_dev *pdev, pm_message_t
> +state)
> {
> struct mwifiex_adapter *adapter;
> struct pcie_service_card *card;
> - struct pci_dev *pdev = to_pci_dev(dev);
>
> card = pci_get_drvdata(pdev);
>
> @@ -160,7 +159,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
>
> adapter = card->adapter;
> if (!adapter) {
> - dev_err(dev, "adapter is not valid\n");
> + dev_err(&pdev->dev, "adapter is not valid\n");
> return 0;
> }
>
> @@ -181,6 +180,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
> set_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags);
> clear_bit(MWIFIEX_IS_HS_ENABLING, &adapter->work_flags);
>
> + pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
> + pci_save_state(pdev);
> + pci_set_power_state(pdev, pci_choose_state(pdev, state));
> +
> return 0;
> }
>
> @@ -192,16 +195,20 @@ static int mwifiex_pcie_suspend(struct device
> *dev)
> * If already not resumed, this function turns on the traffic and
> * sends a host sleep cancel request to the firmware.
> */
> -static int mwifiex_pcie_resume(struct device *dev)
> +static int mwifiex_pcie_resume(struct pci_dev *pdev)
> {
> struct mwifiex_adapter *adapter;
> struct pcie_service_card *card;
> - struct pci_dev *pdev = to_pci_dev(dev);
> +
> + pci_set_power_state(pdev, PCI_D0);
> + pci_restore_state(pdev);
> + pci_enable_wake(pdev, PCI_D0, 0);
> +
>
> card = pci_get_drvdata(pdev);
>
> if (!card->adapter) {
> - dev_err(dev, "adapter structure is not valid\n");
> + dev_err(&pdev->dev, "adapter structure is not valid\n");
> return 0;
> }
>
> @@ -416,11 +423,6 @@ static void mwifiex_pcie_reset_done(struct pci_dev
> *pdev)
> .reset_done = mwifiex_pcie_reset_done,
> };
>
> -#ifdef CONFIG_PM_SLEEP
> -/* Power Management Hooks */
> -static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops, mwifiex_pcie_suspend,
> - mwifiex_pcie_resume);
> -#endif
>
> /* PCI Device Driver */
> static struct pci_driver __refdata mwifiex_pcie = { @@ -431,7 +433,8 @@
> static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops, mwifiex_pcie_suspend,
> .driver = {
> .coredump = mwifiex_pcie_coredump,
> #ifdef CONFIG_PM_SLEEP
> - .pm = &mwifiex_pcie_pm_ops,
> + .suspend = mwifiex_pcie_suspend,
> + .resume = mwifiex_pcie_resume,
> #endif
> },
> .shutdown = mwifiex_pcie_shutdown,
> --
> 1.9.1
^ permalink raw reply
* RE: [PATCH 2/2] mwifiex: add support for WIPHY_WOWLAN_ANY
From: Ganapathi Bhat @ 2019-05-30 10:03 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Cc: Cathy Luo, Zhiyuan Yang, James Cao, Rakesh Parmar,
Sharvari Harisangam
In-Reply-To: <1559209955-10089-2-git-send-email-gbhat@marvell.com>
Hi Kalle,
Below is the second patch in the series; Kindly help to merge both;
Regards,
Ganapathi
> -----Original Message-----
> From: Ganapathi Bhat <gbhat@marvell.com>
> Sent: Thursday, May 30, 2019 3:23 PM
> To: linux-wireless@vger.kernel.org
> Cc: Cathy Luo <cluo@marvell.com>; Zhiyuan Yang <yangzy@marvell.com>;
> James Cao <jcao@marvell.com>; Rakesh Parmar <rakeshp@marvell.com>;
> Sharvari Harisangam <sharvari@marvell.com>; Ganapathi Bhat
> <gbhat@marvell.com>
> Subject: [PATCH 2/2] mwifiex: add support for WIPHY_WOWLAN_ANY
>
> From: Sharvari Harisangam <sharvari@marvell.com>
>
> Advertise support for WIPHY_WOWLAN_ANY trigger. Update default
> hostsleep condition to handle magic packet.
>
> Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 +++---
> drivers/net/wireless/marvell/mwifiex/fw.h | 4 +++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index e11a4bb..f23bb9c 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -3492,7 +3492,7 @@ static int mwifiex_cfg80211_suspend(struct wiphy
> *wiphy,
> wowlan->nd_config);
> }
>
> - if (wowlan->disconnect) {
> + if (wowlan->disconnect || wowlan->any || wowlan->magic_pkt) {
> hs_cfg.conditions |= HS_CFG_COND_MAC_EVENT;
> mwifiex_dbg(sta_priv->adapter, INFO, "Wake on device
> disconnect\n");
> }
> @@ -4232,7 +4232,7 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy,
> struct wireless_dev *wdev, static const struct wiphy_wowlan_support
> mwifiex_wowlan_support = {
> .flags = WIPHY_WOWLAN_MAGIC_PKT |
> WIPHY_WOWLAN_DISCONNECT |
> WIPHY_WOWLAN_NET_DETECT |
> WIPHY_WOWLAN_SUPPORTS_GTK_REKEY |
> - WIPHY_WOWLAN_GTK_REKEY_FAILURE,
> + WIPHY_WOWLAN_GTK_REKEY_FAILURE |
> WIPHY_WOWLAN_ANY,
> .n_patterns = MWIFIEX_MEF_MAX_FILTERS,
> .pattern_min_len = 1,
> .pattern_max_len = MWIFIEX_MAX_PATTERN_LEN, @@ -4242,7
> +4242,7 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy, struct
> wireless_dev *wdev,
>
> static const struct wiphy_wowlan_support
> mwifiex_wowlan_support_no_gtk = {
> .flags = WIPHY_WOWLAN_MAGIC_PKT |
> WIPHY_WOWLAN_DISCONNECT |
> - WIPHY_WOWLAN_NET_DETECT,
> + WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_ANY,
> .n_patterns = MWIFIEX_MEF_MAX_FILTERS,
> .pattern_min_len = 1,
> .pattern_max_len = MWIFIEX_MAX_PATTERN_LEN, diff --git
> a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index b73f99d..ad34b25 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -478,7 +478,9 @@ enum mwifiex_channel_flags {
> #define HostCmd_SCAN_RADIO_TYPE_A 1
>
> #define HS_CFG_CANCEL 0xffffffff
> -#define HS_CFG_COND_DEF 0x00000000
> +#define HS_CFG_COND_DEF (HS_CFG_COND_BROADCAST_DATA
> |\
> + HS_CFG_COND_UNICAST_DATA |\
> + HS_CFG_COND_MULTICAST_DATA)
> #define HS_CFG_GPIO_DEF 0xff
> #define HS_CFG_GAP_DEF 0xff
> #define HS_CFG_COND_BROADCAST_DATA 0x00000001
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Kalle Valo @ 2019-05-30 10:19 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
In-Reply-To: <20190530092327.GA2626@localhost.localdomain>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>>
>> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
>> > aligned buffer sizes for rx") since it breaks A-MSDU support.
>> > When A-MSDU is enable the device can receive frames up to
>> > q->buf_size but they will be discarded in mt76u_process_rx_entry
>> > since there is no enough room for skb_shared_info.
>> > Fix it by introducing q->data_size and take info account
>> > skb_shared_info size in q->buf_size
>> > Moreover increase buffer size even for legacy mode (scatter-gather not
>> > available)
>> >
>> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>
>> Felix, can I take this directly to wireless-drivers?
>
> Hi Kalle,
>
> please hold on with this patch, I will post a new one with a different
> approach based on what Felix has suggested me
Ok, thanks for letting me know.
--
Kalle Valo
^ permalink raw reply
* [PATCH] wireless-regdb: update source of information for CU
From: Xose Vazquez Perez @ 2019-05-30 11:00 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Seth Forshee, WIRELESS ML, REGDB ML
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: WIRELESS ML <linux-wireless@vger.kernel.org>
Cc: REGDB ML <wireless-regdb@lists.infradead.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 6b65312..3bdc7c0 100644
--- a/db.txt
+++ b/db.txt
@@ -316,7 +316,7 @@ country CR: DFS-FCC
(5735 - 5835 @ 20), (30)
# Source:
-# http://www.mincom.gob.cu/?q=marcoregulatorio
+# https://www.mincom.gob.cu/es/marco-legal
# - Redes Informáticas
# Resolución 127- 2011 Reglamento de Banda de frecuencias de 2,4 GHz.
country CU: DFS-FCC
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 1/2] mwifiex: Fix possible buffer overflows at parsing bss descriptor
From: Kalle Valo @ 2019-05-30 11:22 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-wireless, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, huangwen, Solar Designer,
Marcus Meissner
In-Reply-To: <20190529125220.17066-2-tiwai@suse.de>
Takashi Iwai <tiwai@suse.de> wrote:
> mwifiex_update_bss_desc_with_ie() calls memcpy() unconditionally in
> a couple places without checking the destination size. Since the
> source is given from user-space, this may trigger a heap buffer
> overflow.
>
> Fix it by putting the length check before performing memcpy().
>
> This fix addresses CVE-2019-3846.
>
> Reported-by: huangwen <huangwen@venustech.com.cn>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 patches applied to wireless-drivers.git, thanks.
13ec7f10b87f mwifiex: Fix possible buffer overflows at parsing bss descriptor
685c9b7750bf mwifiex: Abort at too short BSS descriptor element
--
https://patchwork.kernel.org/patch/10967049/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Jeff Johnson @ 2019-05-30 14:53 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1558353645-18119-2-git-send-email-arend.vanspriel@broadcom.com>
On 2019-05-20 05:00, Arend van Spriel wrote:
> [...snip...]
> enum nl80211_band {
> NL80211_BAND_2GHZ,
> NL80211_BAND_5GHZ,
> + NL80211_BAND_6GHZ,
> NL80211_BAND_60GHZ,
>
> NUM_NL80211_BANDS,
Is it not a concern that this changes the value of NL80211_BAND_60GHZ
and hence will break any ABI which expects the current value?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox