On 2018-10-11 03:38, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan writes:
Hmm... mine is bit different. txqs are refilled only once for all
txqs.
It will give more opportunity for non-served txqs. drv_wake_tx_queue
won't be
called from may_tx as the driver anyway will not push packets in
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues with the brcmfmac
driver and a 4.19 kernel. For me that's enough evidence to say that the SDIO
driver wor
Hi Kalle,
This is the fourth batch of patches intended for v4.20. This includes
only the last patchset I sent. Usual development work, mostly queue
handling cleanups. More details about the contents in the tag
description.
I have sent this out before and kbuildbot reported success.
Please let
On Thu, Oct 11, 2018 at 02:39:25PM +0200, Tom Psyborg wrote:
> so this is RX test where I assume your 7265 card is sending data. is
> that HT20 or HT40 mode and do you get regression on TX too?
>
> can you try same case 2 test but with registers set to:
>
> TX_SW_CFG0, 0x0401
> TX_SW_CFG1, 0x
From: Tomislav Požega
Remove band check from rf53xx channel config routine since all chips
using it are single band.
Signed-off-by: Tomislav Požega
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 103 -
1 file changed, 50 insertion
v3 -> v4:
- do not program addition registers for MT7620
- fix RT6362 typo
v2 -> v3:
- fix wrongly applied hunk during rebase
- add SoB
Stanislaw Gruszka (5):
rt2800: fix registers init for MT7620
rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7
There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
causes we do not perform register initialization for RT6352 (MT7620
SOCs) in correct branch. Fix this and disable registers initialization
that is specific to particular MT7620 revision.
Signed-off-by: Stanislaw Gruszka
---
drive
Do not enable TX_PIN_CFG_LNA_PE_A* bits for 2.4GHz band and
vice versa TX_PIN_CFG_LNA_PE_G* bits for 5GHz.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wirel
The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
restore old behavaviour since setting this bit maight not be
correct for older devices.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c
From: Tomislav Požega
Register 66 was causing issues on RT6352 if set to the same value as
in MTK driver. With 1c reg value device was working fine in both HT20
and HT40 modes.
Signed-off-by: Tomislav Požega
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c |
Remove rt2x00_rt(rt2x00dev, RT6352)) check from
rt2800_config_channel_rf53xx() which is not called for RT6352 devices.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ra
We do not need separate lines for calculating register values.
Also add comment that value is different than in vendor driver.
Suggested-by: Daniel Golle
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletio
From: Tomislav Požega
Use default value of TX_SW_CFG2 register that is in charge
of LNA timings. Works for somewhat higher RX throughput.
Signed-off-by: Tomislav Požega
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
On 10/12/18 10:00 AM, Arend van Spriel wrote:
> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
>> Hi Franky and Arend,
>>
>> today I could get a SDIO Wifi module, which includes a BCM43455.
>> I was able to get this up and running without any issues with the
>> brcmfmac
>> driver and a 4.19 ker
On 10/11/2018 10:19 PM, Dan Haab wrote:
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares wi
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
On 10/12/18 10:00 AM, Arend van Spriel wrote:
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues with t
On Sun, 2018-10-07 at 21:58 +0200, Johannes Berg wrote:
>
> > > + * @partial: indicates that this is a partial result for this type
> >
> > Is partial set to false for the last result of this measurement type? This
> > may
> > be useful, for example if requesting multiple measurement types, user
From: Johannes Berg
Add a new "peer measurement" API, that can be used to measure
certain things related to a peer. Right now, only implement
FTM (flight time measurement) over it, but the idea is that
it'll be extensible to also support measuring the necessary
things to calculate e.g. angle-of-a
Rajkumar Manoharan writes:
> On 2018-10-11 03:38, Toke Høiland-Jørgensen wrote:
>> Rajkumar Manoharan writes:
>>
>>> Hmm... mine is bit different. txqs are refilled only once for all
>>> txqs.
>>> It will give more opportunity for non-served txqs. drv_wake_tx_queue
>>> won't be
>>> called from
Update vga tuning algorithm to the one used in mt76x2 driver
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/phy.c | 56 +--
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
b/drivers/net/
Move mt76x2_get_rssi_gain_thresh and mt76x2_get_low_rssi_gain_thresh
routines in mt76x02-lib module in order to be reused by mt76x0 driver
for dynamic vga calibration
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x02_phy.h | 26
.../wireless/mediatek/mt
Add mt76x02_init_agc_gain routine in mt76x02-lib moudule in
order to be reused by mt76x0 for vga initalization
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/mt76x02_phy.c| 12
drivers/net/wireless/mediatek/mt76/mt76x02_phy.h| 1 +
drivers/net/wirele
Introduce phy/vco temperature calibration.
Moreover fix configuration of register 67 on bank0
during temperature reading and use mt76_poll utility routine
to poll core34 register.
Furthermore temperature compensation needs to be disabled
if the device supports tssi compensation.
This issue has neve
Add mt76x0_tssi_enabled in order to check if tssi compensation
is enabled since mt76x0 condition differs from mt76x2 one.
Moreover move back mt76x02_temp_tx_alc_enabled and mt76x02_tssi_enabled
routines in mt76x2/eeprom.h since they are mt76x2 specific
Signed-off-by: Lorenzo Bianconi
---
.../wir
Move mt76x02_phy_adjust_vga_gain routine in mt76x02-lib module
in order to be reused by mt76x0 driver for vga calibration
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x02_phy.c | 21 ++
.../net/wireless/mediatek/mt76/mt76x02_phy.h | 1 +
.../wireless/
Do not perform phy/vga calibration during channel switch.
Moreover remove mt76x0_agc_save and mt76x0_agc_restore routines
since they are no longer necessary. Furthermore run mt76_set_channel
in order to check if there are pending frames during channel switch
Signed-off-by: Lorenzo Bianconi
---
.
Use mt76x0_phy as prefix for routines in mt76x0/phy.c
Moreover use mt76x0_phy_rf_set to enable vco calibration in
mt76x0_phy_vco_cal
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/init.c | 2 +-
.../wireless/mediatek/mt76/mt76x0/mt76x0.h| 2 +-
.../net/wireles
Add mt76x0_phy_calirate routine in order to perform
phy calibration for mt76x0e devices.
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/mcu.h | 3 ++
.../wireless/mediatek/mt76/mt76x0/mt76x0.h| 1 +
.../net/wireless/mediatek/mt76/mt76x0/pci.c | 1 +
.../net/
Move mt76x02_phy_set_band routine in mt76x02_phy.c since
it is shared between mt76x0 and mt76x2 drivers and remove
duplicated code
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/phy.c | 16 ++--
.../net/wireless/mediatek/mt76/mt76x02_phy.c | 19 +
Do not run mt76x0_vco_cal and mt76x0_bbp_set_bw routines and
configure MT_TX_SW_CFG0 register for pcie devices in
mt76x0_phy_set_channel function.
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/phy.c| 18 +-
1 file changed, 13 insertions(+), 5 delet
Rename mt76x0_phy_calibrate routine in mt76x0_phy_calibration_work
in order to not collide with calibration routine for mt76x0e
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/
Move mt76x02_phy_set_bw routine in mt76x02_phy.c since
it is shared between mt76x0 and mt76x2 drivers and remove
duplicated code
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/phy.c | 29 +--
.../net/wireless/mediatek/mt76/mt76x02_phy.c | 26
Introduce vga, temperature and phy calibration routines for
mt76x0e driver. Move phy shared code in mt76x02-lib module.
Moreover do not run calibration during channel switch
Changes since rfc:
- run vco calibration during freq scanning
- use mt76x0_phy as prefix for phy routines
Lorenzo Bianconi
On 10/12/2018 12:08 PM, Johannes Berg wrote:
From: Johannes Berg
Add a new "peer measurement" API, that can be used to measure
certain things related to a peer. Right now, only implement
FTM (flight time measurement) over it, but the idea is that
it'll be extensible to also support measuring th
On 2018-10-10 12:31, Lorenzo Bianconi wrote:
> Remove unused channel parameter from mt76x0_phy_set_chan_bbp_params
> routine signature
>
> Signed-off-by: Lorenzo Bianconi
Merged, thanks.
- Felix
> You have no recollection what happened in the earlier versions, right? :-p
v1 was very incomplete, it didn't have any results reporting, etc.
> > v3:
> > - add a bit to report "final" for partial results
> > - remove list keeping etc. and just unicast out the results
> >to the requester
On 10/12/2018 12:41 PM, Johannes Berg wrote:
+ NL80211_ATTR_TIMEOUT,
+
Guess you consider reuse of the TIMEOUT attribute?
Yes, I was actually surprised we don't have one already :-)
Dito.
Arend
chip version support exist in daniel's tree since a long time ago. so
don't disable registers initialization but try to upstream his
changes.
changing TX_SW_CFG* entries did not make any noticeable difference in
my tests either, besides small RX improvement with configured
TX_SW_CFG2.
waiting for
is there some specific reason to read TX_PIN_CFG register on RT6352,
rather than just null it before programming in tx values like in other
chips?
On 12/10/2018, Stanislaw Gruszka wrote:
> The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
> restore old behavaviour since setting
On 10/12/2018 10:59 AM, Christoph Müllner wrote:
On 10/12/18 10:00 AM, Arend van Spriel wrote:
On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, which includes a BCM43455.
I was able to get this up and running without any issues with t
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.
I do not see reason for for blocking this change because some other
changes are not unstr
On Fri, Oct 12, 2018 at 12:52:13PM +0200, Tom Psyborg wrote:
> is there some specific reason to read TX_PIN_CFG register on RT6352,
> rather than just null it before programming in tx values like in other
> chips?
I don't remember the details, but Daniel explained that tere are
some bits in the T
it will cause regression on other devices
On 12/10/2018, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
>> chip version support exist in daniel's tree since a long time ago. so
>> don't disable registers initialization but try to upstream his
>> changes.
>
Please stop top-posting.
On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
> it will cause regression on other devices
How exactly ? On upstream tree where this patch is intended
additional registers where never programmed as proper branch
were never used, because of additional check
> On 12.10.2018, at 13:22, Arend van Spriel
> wrote:
>
> On 10/12/2018 10:59 AM, Christoph Müllner wrote:
>>
>>
>> On 10/12/18 10:00 AM, Arend van Spriel wrote:
>>> On 10/11/2018 6:04 PM, Christoph Müllner wrote:
Hi Franky and Arend,
today I could get a SDIO Wifi module, whic
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
On 12/10/2018, Stanislaw Gruszka wrote:
> Please stop top-posting.
>
> On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
>> it will cause regression on other devices
>
> How exactly ?
the same way your wifi works without TX_SW_CFG entries and mine
doesn't, while both are RT6352
> On u
On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> > On upstream tree where this patch is intended
> > additional registers where never programmed as proper branch
> > were never used, because of additional check in RT5390 branch.
> >
>
> on my hardware additional registers were progra
On Fri, Oct 12, 2018 at 12:16:20PM +0200, Lorenzo Bianconi wrote:
> Add mt76x0_phy_calirate routine in order to perform
> phy calibration for mt76x0e devices.
> @@ -671,9 +713,14 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
> /* Vendor driver don't do it */
> /* mt76x0_phy_se
On 12/10/2018, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> > On upstream tree where this patch is intended
>> > additional registers where never programmed as proper branch
>> > were never used, because of additional check in RT5390 branch.
>> >
>>
>>
>
> On Fri, Oct 12, 2018 at 12:16:20PM +0200, Lorenzo Bianconi wrote:
> > Add mt76x0_phy_calirate routine in order to perform
> > phy calibration for mt76x0e devices.
>
> > @@ -671,9 +713,14 @@ int mt76x0_phy_set_channel(struct mt76x02_dev *dev,
> > /* Vendor driver don't do it */
> >
On Fri, Oct 12, 2018 at 3:02 AM Arend van Spriel
wrote:
>
> On 10/11/2018 10:19 PM, Dan Haab wrote:
> > The newest firmwares provide STA info using v7 of the struct. As v7
> > isn't backward compatible, a union is needed.
> >
> > Even though brcmfmac does not use any of the new info it's important
On 2018-10-12 12:16, Lorenzo Bianconi wrote:
> Introduce vga, temperature and phy calibration routines for
> mt76x0e driver. Move phy shared code in mt76x02-lib module.
> Moreover do not run calibration during channel switch
>
> Changes since rfc:
> - run vco calibration during freq scanning
> - u
On 10/10/2018 01:14 PM, Johannes Berg wrote:
> Looking at all this wid_list stuff again,
>
>> +wid_list[wid_cnt].id = WID_SUCCESS_FRAME_COUNT;
>> +wid_list[wid_cnt].type = WID_INT;
>> +wid_list[wid_cnt].size = sizeof(u32);
>> +wid_list[wid_cnt].val = (s8 *)(&(dummyval));
>> +
On 10/11/2018 12:01 AM, Johannes Berg wrote:
>
>> Agree. parameter validation can be done before scheduling the work,
>> and hence appropriate error can be returned to caller .
>
>
>> If I got your point correctly, you are referring to the lines that
>> stores the parameters into the hif_drv->
From: Luca Coelho
The rs_rate_from_ucode_rate() function may return -EINVAL if the rate
is invalid, but none of the callsites check for the error, potentially
making us access arrays with index IWL_RATE_INVALID, which is larger
than the arrays, causing an out-of-bounds access. This will trigger
On Sat, 2018-10-13 at 09:46 +0300, Luca Coelho wrote:
> From: Luca Coelho
>
> The rs_rate_from_ucode_rate() function may return -EINVAL if the rate
> is invalid, but none of the callsites check for the error,
> potentially
> making us access arrays with index IWL_RATE_INVALID, which is larger
> t
From: Johannes Berg
John Garry reported that when we actually use the current
implementation of __NLA_ENSURE, he gets compiler warnings
from -Wvla since there's an array in there, and for some
reason the compiler cannot immediately prove that its size
is constant. It must eventually be able to pr
From: Johannes Berg
John Garry requested to be able to use FIELD_PREP() and friends
in constant initializers, so the thing we can do is switch all
the compile-time assertions to use BUILD_BUG_ON_ZERO() instead
of regular BUILD_BUG_ON().
The only downside is that we lose all the error messages, b
wow pause iface config controls the PCI D0/D3-WOW cases for pcie
bus state. Firmware does not expects WOW_IFACE_PAUSE_ENABLED config
for bus/link that cannot be suspended ex:snoc and does not trigger
common subsystem shutdown.
Disable interface pause wow config for integrated chipset(WCN3990)
for c
Register snoc bus layer suspend/resume PM ops and configure
the wakeup source(CE2) for the device.
Testing:
Tested on WCN3990 HW.
Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
Signed-off-by: Govind Singh
---
drivers/net/wireless/ath/ath10k/snoc.c | 45 ++
1 file c
This series adds support for driver suspend/resume and wake over wlan support
for WCN3990 chipset. CE2 is configured as wakeup source before driver suspend
and FW can wake up application processor on Magic packet/Deauth/AP lost.
Govind Singh (3):
ath10k: Enable bus layer suspend/resume for WCN39
FW credit flow control is enabled for only WMI ctrl
service(CE3) but credit update is requested unconditionally
on all HTC services as part of HTC tx in CE3/CE0/CE4.
This is causing WOW failure as FW is not expecting credit
report request on other end-points(CE0/CE4).
Request credit report only o
FW credit flow control is enabled for only WMI ctrl
service(CE3) but credit update is requested unconditionally
on all HTC services as part of HTC tx in CE3/CE0/CE4.
This is causing WOW failure as FW is not expecting credit
report request on other end-points(CE0/CE4).
Request credit report only o
This series adds support for driver suspend/resume and wake over wlan support
for WCN3990 chipset. CE2 is configured as wakeup source before driver suspend
and FW can wake up application processor on Magic packet/Deauth/AP lost.
change since v1:
Log enhancement in "ath10k: Enable bus layer suspe
wow pause iface config controls the PCI D0/D3-WOW cases for pcie
bus state. Firmware does not expects WOW_IFACE_PAUSE_ENABLED config
for bus/link that cannot be suspended ex:snoc and does not trigger
common subsystem shutdown.
Disable interface pause wow config for integrated chipset(WCN3990)
for c
Register snoc bus layer suspend/resume PM ops and configure
the wakeup source(CE2) for the device.
Testing:
Tested on WCN3990 HW.
Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
Signed-off-by: Govind Singh
---
drivers/net/wireless/ath/ath10k/snoc.c | 45 ++
1 file c
From: Johannes Berg
We already have BUILD_BUG_ON_ZERO() which I just hadn't found
before, so we should use it here instead of open-coding another
implementation thereof.
Signed-off-by: Johannes Berg
---
v2: remove all the language about -Wvla, I misunderstood John
and he was just referring
Hi Dave,
Here's another set of updates. Note that there's a patch here
(lib80211 skcipher removal to simplify the code) that will
cause conflicts when merging with the crypto tree, the new
code from this should be used. Please advise Greg/Linus unless
the crypto tree will somehow end up in your tr
Anilkumar Kolli wrote:
> Mesh path metric needs tx rate information from ieee80211_tx_status()
> call but in ath10k there is no mechanism to report tx rate information
> via ieee80211_tx_status(), the tx rate is only accessible via
> sta_statiscs() op.
>
> Per peer tx stats has tx rate info avai
On Mon, Oct 08, 2018 at 05:36:30PM -0700, Brian Norris wrote:
> + linux-msm
>
> Hi Govind, Kalle,
>
> On Wed, Aug 15, 2018 at 02:56:31PM +0530, Govind Singh wrote:
> > Add QMI client handshakes for Q6 integrated WLAN connectivity subsystem.
> > This module is responsible for communicating WLAN co
Rakesh Pillai writes:
> WCN3990 supports sending tx completion for multiple
> management frames bundled together in a single event.
>
> Add support to handle the bundled tx completion
> event for WCN3990.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Signed-off-by: Rake
+ linux-wireless, arnd
kbuild test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
> head: 70aa9eaba2a46b3d53caf03060576a7615182814
> commit: 108924d7a14299b2bcced255feb14bfdde7cb9d4 [10/15] ath10k: Fill
> the channel survey results for WCN3990 cor
Rakesh Pillai wrote:
> The host driver currently expects the channel info event to be
> received in pairs for all the channels, i.e. the first
> chan_info event for a particular channel will not have the
> COMPLETE flag set and the second chan_info event for the
> same channel will have the COMPL
On Fri, Oct 12, 2018 at 4:32 PM Kalle Valo wrote:
>
> + linux-wireless, arnd
>
> >
> >>> ERROR: "__udivdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko]
> >>> undefined!
> >>> ERROR: "__divdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko]
> >>> undefined!
>
> I'm not sure what this is ab
Arnd Bergmann writes:
> On Fri, Oct 12, 2018 at 4:32 PM Kalle Valo wrote:
>>
>> + linux-wireless, arnd
>>
>> >
>> >>> ERROR: "__udivdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko]
>> >>> undefined!
>> >>> ERROR: "__divdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko]
>> >>> undefined
Wen Gong writes:
> In the noisy environment, if there are packets in the queue and can't
> send out, the suspend timing will be more than 5 seconds due to the wait,
> flush the queue to optimize the suspend timing, and let the upper layer to
> retry the packets after resume.
>
> Tested with QCA61
Venkateswara Naralasetty writes:
> ath10k_dbg() is called in ath10k_process_rx() with huge set of arguments
> which is causing CPU overhead even when debug_mask is not set.
> Good improvement was observed in the receive side performance when call
> to ath10k_dbg() is avoided in the RX path.
>
> S
Wen Gong writes:
> On 2018-09-04 19:43, Kalle Valo wrote:
>> Wen Gong writes:
>>
> +enum wmi_nlo_cipher_algorithm {
> +WMI_NLO_CIPHER_ALGO_NONE = 0x00,
> +WMI_NLO_CIPHER_ALGO_WEP40 = 0x01,
> +WMI_NLO_CIPHER_ALGO_TKIP = 0x02
Kalle Valo writes:
> Rakesh Pillai wrote:
>
>> The host driver currently expects the channel info event to be
>> received in pairs for all the channels, i.e. the first
>> chan_info event for a particular channel will not have the
>> COMPLETE flag set and the second chan_info event for the
>> sam
Niklas Cassel writes:
> On Mon, Oct 08, 2018 at 05:36:30PM -0700, Brian Norris wrote:
>> + linux-msm
>>
>> Hi Govind, Kalle,
>>
>> On Wed, Aug 15, 2018 at 02:56:31PM +0530, Govind Singh wrote:
>> > Add QMI client handshakes for Q6 integrated WLAN connectivity subsystem.
>> > This module is resp
On Wed, 10 Oct 2018 17:22:54 +0530, Govind Singh wrote:
> Add missing optional properties in WCN3990 wifi node.
>
> Signed-off-by: Govind Singh
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 28
> --
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
Review
On Wed, 10 Oct 2018 17:22:56 +0530, Govind Singh wrote:
> WCN3990 wifi module can optionally make use of the IOMMU.
> Add binding documentation for phandle to the IOMMU and
> the stream id of wifi iommu block.
>
> Signed-off-by: Govind Singh
> ---
> Documentation/devicetree/bindings/net/wireless
On Friday, October 12, 2018 2:08:37 AM CEST Matthias Kaehlcke wrote:
> Maybe the doc should include a recommendation to use aliases
> sparingly? I'm open to input on that from folks who have a better
> understanding of the potential pitfalls
I had a similar discussion with the OpenWrt devs over t
From: Johannes Berg
Date: Fri, 12 Oct 2018 13:13:53 +0200
> Here's another set of updates. Note that there's a patch here
> (lib80211 skcipher removal to simplify the code) that will
> cause conflicts when merging with the crypto tree, the new
> code from this should be used. Please advise Greg/L
From: Johannes Berg
Date: Fri, 12 Oct 2018 12:53:00 +0200
> From: Johannes Berg
>
> We already have BUILD_BUG_ON_ZERO() which I just hadn't found
> before, so we should use it here instead of open-coding another
> implementation thereof.
>
> Signed-off-by: Johannes Berg
> ---
> v2: remove all
Umm, I really should've tested this :-)
As John points out, it can't possibly compile, e.g. because
> +#define __BF_FIELD_CHECK(_mask, _reg, _val) \
> + BUILD_BUG_ON_ZERO(!__builtin_constant_p(_mask)) + \
this isn't actually a constant expression.
This
From: Johannes Berg
John Garry requested to be able to use FIELD_PREP() and friends
in constant initializers, but we cannot completely switch all of
the current assertions to BUILD_BUG_ON_ZERO().
So instead of this, add __FIELD_PREP() which is suitable in such
contexts, and also add __{u,le,be}{
On Wed, Oct 10, 2018 at 05:22:53PM +0530, Govind Singh wrote:
> This series enables ath10k wifi driver support for WCN3990 target
> on sdm845 SOC. This series also updates the missing dt binding documentation
> and adds optional iommu property.
For the series:
Reviewed-by: Brian Norris
Tested-by
Similar to regulator error handling, we should only start tearing down
the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might
end up with an unbalanced clock, where we never successfully enabled the
clock, but we try to disable it anyway.
Signed-off-by: Brian Norris
---
drivers/ne
ath10k_wcn3990_clk_info and ath10k_wcn3990_vreg_info are not
WCN3990-specific structures. They hold generic data. So don't name them
with wcn3990 specifics.
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/ath10k/snoc.c | 34 +-
drivers/net/wireless/ath/ath10k/sno
If a regulator fails to set its voltage, we end up with an unbalanced
call to regulator_disable(), because the error path starts with the
current regulator (which was never enabled).
Factor out the "on" function to perform (and unwind if failed) a single
regulator at a time, and then main loop (at
I rarely see drivers specify precise voltage requirements like this, but
if we really have to...let's at least give a little wiggle room. Board
designs (and accompanying device trees) may not provide exactly the
voltage listed here, and we shouldn't fail to probe just because of
this.
Round these
Hi Johannes,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc7 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Johannes,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc7 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
95 matches
Mail list logo