On Mon, Oct 08, 2018 at 08:11:45PM +0200, Felix Fietkau wrote:
> On 2018-10-08 14:40, Lorenzo Bianconi wrote:
> > Fix restore value configured in 0x2124 register in
> > mt76x0_phy_recalibrate_after_assoc routine.
> >
> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
> > Signed-off-by: Lorenzo Bianconi
On 8 October 2018 at 22:03, Daniel Mack wrote:
> When powering down a SDIO connected card during suspend, make sure to call
> into the generic lbs_suspend() function before pulling the plug. This will
> make sure the card is successfully deregistered from the system to avoid
> communication to the
On Tue, 2018-10-09 at 04:23 +, adham.aboza...@microchip.com wrote:
>
> > I don't know what you need the shadow stuff for, but you should remove
> > it anyway, and use the cfg80211 functionality instead. If not
> > sufficient, propose patches to improve it?
>
> The point behind using a shadow
On Mon, 2018-10-08 at 10:51 -0700, Brian Norris wrote:
> clang warns about the misuse of enums:
>
> reg.c:246:26: warning: implicit conversion from enumeration type 'enum
> command_identify_by' to different enumeration type 'enum id_input'
> [-Wenum-conversion]
> err = handle_cmd(state,
From: Johannes Berg
I'm not really sure exactly _why_ I've been carrying a note
for what's probably _years_ to check that we don't do this,
but we clearly do reflect frames back to the station itself
if it sends such.
One way or the other, it's useless since the station doesn't
really need the A
On 2018-10-09 09:35, Stanislaw Gruszka wrote:
> On Mon, Oct 08, 2018 at 08:11:45PM +0200, Felix Fietkau wrote:
>> On 2018-10-08 14:40, Lorenzo Bianconi wrote:
>> > Fix restore value configured in 0x2124 register in
>> > mt76x0_phy_recalibrate_after_assoc routine.
>> >
>> > Fixes: 10de7a8b4ab9 ("mt
> > I think is needed we do:
> >
> > reg_val = mt76_rr(dev, 0x2124);
> > mt76_wr(dev, 0x2124, 0xff7e);
> >
> > CALIBRATE
> >
> > mt76_wr(dev, 0x2124, reg_val);
> >
> > so seems we have to restore orginal value after calibration.
> >
> > Referencing as MT_BBP(IBI, 9) is obv
- Use the register number define instead of a magic value
- Fix inverted bit test (override needs to be applied if the bit is not set)
Fixes: 2b2cb40bcd7d ("mt76x0: pci: add hw initialization at bootstrap")
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 13 +++
Fix restore value configured in MT_BBP(IBI, 9) register in
mt76x0_phy_recalibrate_after_assoc routine.
Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
Signed-off-by: Lorenzo Bianconi
---
Changes since v1:
- use proper register name
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 7 +++
1 fil
Hi,
Firstly, thanks alot for taking out time and reviewing our driver.
I will work on review comment and submit the updated code changes.
On 10/8/2018 7:46 PM, Johannes Berg wrote:
>> +static inline u16 get_beacon_period(u8 *data)
>> +{
>> +u16 bcn_per;
>> +
>> +bcn_per = data[0];
>> +
On Tue, 2018-10-09 at 15:12 +0530, Ajay Singh wrote:
> > > +static inline enum sub_frame_type get_sub_type(u8 *header)
> > > +{
> > > + return ((enum sub_frame_type)(header[0] & 0xFC));
> > > +}
> >
> > remove, use include/linux/ieee80211.h.
> >
>
> Did you mean to use '& IEEE80211_FCTL_STYPE'
Hi all,
On Tue, 2018-09-18 at 08:11 -0400, Jamal Hadi Salim wrote:
> On behalf of the NetDev Society, this is a formal announcement that
> Netdev 0x13 conference will be held in Prague, Czech Republic.
> Tentative dates are March 20-22, 2019.
Kalle and I have (more or less) decided to propose a w
On 10/8/2018 7:50 PM, Johannes Berg wrote:
> On Wed, 2018-09-26 at 15:55 +0530, Ajay Singh wrote:
>
>> +#include
> you include it
>
>> +#include "coreconfigurator.h"
>> +
>> +#define IDLE_MODE 0x00
>> +#define AP_MODE 0x01
>> +#define STATION_MODE0x02
>> +#define GO_MODE
On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
> > > +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
> > > +typedef void (*wilc_remain_on_chan_ready)(void *);
> I think as per coding style the typedef for function pointer are allowed.
True, I guess, but why do you need them?
>
On Mon, Sep 17, 2018 at 06:32:52PM +0200, Tomislav Požega wrote:
> Enable LNAs only for the current operating band. Change power
> amplifiers enabling style to the one in vco calibration routine
> and drop redundant cap_bt_coexist enable of PA0.
> - rt2x00_set_field32(&tx_pin, TX_PIN_C
Patches 3-5 looks ok to me, I'll rebase and resend them.
Thanks
Stanislaw
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
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 103 -
1 file changed, 50 insertions(+), 53 deletions(-)
diff --git
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
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 |
There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
Reported-by: Tomislav Požega
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
1 file changed, 1 insertio
On 10/9/2018 4:06 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>
+typedef void (*wilc_remain_on_chan_expired)(void *, u32);
+typedef void (*wilc_remain_on_chan_ready)(void *);
>> I think as per coding style the typedef for function pointer are allowed.
On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
> On 10/9/2018 4:06 PM, Johannes Berg wrote:
> > On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
> >
> > > > > +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
> > > > > +typedef void (*wilc_remain_on_chan_ready)(void *);
> > >
>
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 | 6 +-
1 file change
There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
Reported-by: Tomislav Požega
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
1 file changed, 1 insertio
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
---
v2 -> v3:
- fix wrongly applied hung during rebase
- add SoB
drivers/net/wireless/ralink/rt2x00/rt2800lib.c
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
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+),
On 10/9/2018 5:16 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
>> On 10/9/2018 4:06 PM, Johannes Berg wrote:
>>> On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>>>
>> +typedef void (*wilc_remain_on_chan_expired)(void *, u32);
>> +typedef void (*wil
On 2018-10-09 10:57, Lorenzo Bianconi wrote:
> Fix restore value configured in MT_BBP(IBI, 9) register in
> mt76x0_phy_recalibrate_after_assoc routine.
>
> Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
> Signed-off-by: Lorenzo Bianconi
Merged, thanks.
- Felix
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new callback, ieee80211_sta_register_airtime(), is added
that drivers can call to report airtime usage for stations.
When airtime information is present, mac80211 will schedule TXQs
(through ieee80211_next_txq()) in a way
This moves the ath9k driver to use the mac80211 TXQ scheduling and
airtime accounting APIs, removing the corresponding state tracking
inside the driver.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/ath9k.h | 14 --
drivers/net/wireless/ath/ath9k/debug.c |
This adds TX airtime statistics to the cfg80211 station dump (to go along
with the RX info already present), and adds a new parameter to set the
airtime weight of each station. The latter allows userspace to implement
policies for different stations by varying their weights.
Signed-off-by: Toke Hø
Another updated version, addressing a few issues with the previous
version.
- Moved the airtime deficit queue wakeup code to its own tasklet to
lower overhead.
- Change the tasklet to just wake a single queue on each invocation,
relying to TX completion to continue transmissions.
- Don't try
This adds an API to mac80211 to handle scheduling of TXQs. The interface
between driver and mac80211 for TXQ handling is changed by adding two new
functions: ieee80211_next_txq(), which will return the next TXQ to schedule
in the current round-robin rotation, and ieee80211_return_txq(), which the
d
Hi
On Tue, Oct 09, 2018 at 02:27:22PM +0200, Daniel Golle wrote:
> On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote:
> > 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.
>
> M
For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.
Since on some models these strings are too generic, this commit also adds
a quirk table overriding the strings for models listed in that table.
The board_type setting is
brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.
This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.
Signed-off-by: Hans de Goede
---
.../broadcom/brcm80211/brcmfmac/firmware.
Before this commit brcmf_fw_request_done would call
brcmf_fw_request_next_item to load the next item, which on an error would
call brcmf_fw_request_done, which if the error is recoverable (*) will
then continue calling brcmf_fw_request_next_item for the next item again
which on an error will call b
The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work OOTB, multiple (one per board) versions must
co-exist under /lib/firmware.
This commit adds support for callers of the brcmfm
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.
Signed-off-by: Hans de Goede
---
.../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 8 +
For of/devicetree using machines, set the board_type used for nvram file
selection to the first string listed in the top-level's node compatible
string, aka the machine-compatible as used by of_machine_is_compatible().
The board_type setting is used to load the board-specific nvram file with
a boa
Hi Stanislaw,
On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote:
> 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.
My guess is that this may change once we add proper TSSI which i
On Tue, Oct 09, 2018 at 02:47:48PM +0200, Stanislaw Gruszka wrote:
> Hi
>
> On Tue, Oct 09, 2018 at 02:27:22PM +0200, Daniel Golle wrote:
> > On Tue, Oct 09, 2018 at 01:56:08PM +0200, Gruszka wrote:
> > > Register 66 was causing issues on RT6352 if set to the same value as
> > > in MTK driver. Wi
On Tue, Oct 09, 2018 at 03:07:15PM +0200, Daniel Golle wrote:
> simply add these lines:
> /*
> * Despite the vendor driver using different values here, use 0x1c
> * for now. This may have to be changed once TSSI got implemented
> */
I will add this in sparate patch.
Thanks
Stanislaw
Ulf Hansson writes:
> On 8 October 2018 at 22:03, Daniel Mack wrote:
>> When powering down a SDIO connected card during suspend, make sure to call
>> into the generic lbs_suspend() function before pulling the plug. This will
>> make sure the card is successfully deregistered from the system to a
On 10/7/2018 10:58 PM, Johannes Berg wrote:
>>
>> Just curious, what's the advantage of this compared to sending the reply
>> only on
>> the socket that started the measurement?
>
> TBH, I don't really see any. Some people really wanted this for things
> like "let's do something in iw for measu
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Pu
On 10/09/2018 12:55 AM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 04:23 +, adham.aboza...@microchip.com wrote:
>>
>>> I don't know what you need the shadow stuff for, but you should remove
>>> it anyway, and use the cfg80211 functionality instead. If not
>>> sufficient, propose patches to
The current driver hard codes various features, ext features and supported
interface types when a new radio is created. This patch adds several new
hwsim attributes so user space can specify specific features the radio should
have:
- HWSIM_ATTR_FEATURE_SUPPORT
Bit field of nl80211_feature_
Hi Arend,
recently I got an SDIO module, which includes a BCM4359.
I tried to get it up and running via the SD card interface
on a RK3399 SoC and succeeded in doing so with
bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
All that was necessary was configure BCMDHD to run with
in-ban
On 10/09/2018 05:18 AM, Ajay Singh wrote:
>
> On 10/9/2018 5:16 PM, Johannes Berg wrote:
>> On Tue, 2018-10-09 at 17:14 +0530, Ajay Singh wrote:
>>> On 10/9/2018 4:06 PM, Johannes Berg wrote:
On Tue, 2018-10-09 at 16:04 +0530, Ajay Singh wrote:
>>> +typedef void (*wilc_remain_on_ch
Hi Christoph,
On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner
wrote:
>
> Hi Arend,
>
> recently I got an SDIO module, which includes a BCM4359.
> I tried to get it up and running via the SD card interface
> on a RK3399 SoC and succeeded in doing so with
> bcmdhd.1.579.77.41.x and a vendor kerne
On 10/9/2018 8:10 PM, Christoph Müllner wrote:
Hi Arend,
recently I got an SDIO module, which includes a BCM4359.
I tried to get it up and running via the SD card interface
on a RK3399 SoC and succeeded in doing so with
bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
All that was
On Tue, 2018-10-09 at 18:36 +, adham.aboza...@microchip.com wrote:
>
> Johannes, is the cfg80211_scan_request.ssid used for something else
> other than specifying the hidden networks that the controller should
> scan for?
Ahh, now I understand where you're coming from.
Well, it's the SSID to
On Tue, 2018-10-09 at 10:48 -0700, James Prestwood wrote:
> The current driver hard codes various features, ext features and supported
> interface types when a new radio is created. This patch adds several new
> hwsim attributes so user space can specify specific features the radio should
> have:
>
On 10/09/2018 12:14 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 18:36 +, adham.aboza...@microchip.com wrote:
>>
>> Johannes, is the cfg80211_scan_request.ssid used for something else
>> other than specifying the hidden networks that the controller should
>> scan for?
>
> Ahh, now I unde
On Tue, 2018-10-09 at 20:01 +, adham.aboza...@microchip.com wrote:
>
> Do you mean that it can also be used for probing specific networks even if
> they are broadcasting their SSID?
Yes.
> I think this might be a possible case if the user is trying to limit the scan
> results to a specific
On 10/09/2018 01:02 PM, Johannes Berg wrote:
> On Tue, 2018-10-09 at 20:01 +, adham.aboza...@microchip.com wrote:
>>
>> Do you mean that it can also be used for probing specific networks even if
>> they are broadcasting their SSID?
>
> Yes.
>
>> I think this might be a possible case if the
On Tue, 2018-10-09 at 21:41 +0200, Johannes Berg wrote:
> On Tue, 2018-10-09 at 10:48 -0700, James Prestwood wrote:
> > The current driver hard codes various features, ext features and
> > supported
> > interface types when a new radio is created. This patch adds
> > several new
> > hwsim attribute
On Tue, 2018-10-09 at 13:12 -0700, James Prestwood wrote:
> Ok, that makes sense. The intent here was to test logic for detecting
> and handling supported driver features/iftypes, rather than actually
> using the features. But I do understand it would be strange for anyone
> trying to enable a fea
On Tue, 2018-10-09 at 22:13 +0200, Johannes Berg wrote:
> On Tue, 2018-10-09 at 13:12 -0700, James Prestwood wrote:
>
> > Ok, that makes sense. The intent here was to test logic for
> > detecting
> > and handling supported driver features/iftypes, rather than
> > actually
> > using the features. B
On Tue, 2018-10-09 at 13:42 -0700, James Prestwood wrote:
> > In general, I guess what would work is to be able to *restrict* the
> > advertised features over what's currently the case, but I suspect
> > that's not something that would be so very much useful for you (unless we
> > also add more fe
Hi Franky,
thank's for your help.
As the BCM4359 is already supported (as PCIe device) in the brcmfmac
driver, I assumed that base addresses will be correct.
But having a closer look it is indeed the problematic part.
I've temporary fixed the return value in brcmf_chip_tcm_rambase
to the one matc
On Tue, 2018-10-09 at 22:47 +0200, Johannes Berg wrote:
> On Tue, 2018-10-09 at 13:42 -0700, James Prestwood wrote:
>
> > > In general, I guess what would work is to be able to *restrict*
> > > the
> > > advertised features over what's currently the case, but I suspect
> > > that's not something t
Hi Tomislav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On 09/10/2018, Stanislaw Gruszka wrote:
> Patches 3-5 looks ok to me, I'll rebase and resend them.
>
> Thanks
> Stanislaw
>
and what about patches 1-2 ? did you find any regression?
On 09/10/2018, Stanislaw Gruszka wrote:
> There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
> we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
>
> Reported-by: Tomislav Požega
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/ralink/
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Pu
Hi Tomislav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
James Prestwood writes:
> The current driver hard codes various features, ext features and supported
> interface types when a new radio is created. This patch adds several new
> hwsim attributes so user space can specify specific features the radio should
> have:
>
> - HWSIM_ATTR_FEATURE_SUPPORT
On 2018-10-09 05:32, Toke Høiland-Jørgensen wrote:
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new callback, ieee80211_sta_register_airtime(), is added
that drivers can call to report airtime usage for stations.
When airtime information is present, mac80211 will
Hi Brian,
On Tue, Oct 9, 2018 at 3:07 AM Brian Norris wrote:
> On Tue, Sep 25, 2018 at 02:02:55PM -0700, Matthias Kaehlcke wrote:
> > Add a global binding for the 'aliases' node. This includes an initial list
> > of standardized alias names for some hardware components that are commonly
> > found
On Thu, 2018-10-04 at 12:59 -0700, Cody Schuffelen wrote:
>
> I wasn't completely clear on whether I should change the title (net-next
> to mac80211-next) so I left it as is for v3 to try to keep the patchwork
> series together.
You can/should change it - patchwork doesn't really track this at al
When qtnf_trans_send_cmd_with_resp() fails, we have not yet initialized
'resp', as pointed out by a valid gcc warning:
drivers/net/wireless/quantenna/qtnfmac/commands.c: In function
'qtnf_cmd_send_with_reply':
drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error: 'resp' may be
used un
A couple of macros that deal with statistics in ath9k rely on the
declaration of the 'sc' variable, which they dereference.
However, when the statistics are disabled, the new instance in
ath_cmn_process_fft() causes a warning for an unused variable:
drivers/net/wireless/ath/ath9k/common-spectral.
On Tue, Oct 09, 2018 at 09:22:07AM +0200, Geert Uytterhoeven wrote:
> Please note these aliases become cumbersome once you start considering
> (dynamic) DT overlays. That's why I made them optional in the sh-sci
> serial driver, cfr. commit 7678f4c20fa7670f ("serial: sh-sci: Add support
> for dyna
>
> I have sent a patch to address this,
> https://patchwork.kernel.org/patch/10611943/
>
That's great.
Thanks for letting me know. :)
--
Gustavo
Hello Arnd,
> When qtnf_trans_send_cmd_with_resp() fails, we have not yet initialized
> 'resp', as pointed out by a valid gcc warning:
>
> drivers/net/wireless/quantenna/qtnfmac/commands.c: In function
> 'qtnf_cmd_send_with_reply':
> drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: erro
Hi Carl,
On Mon, Oct 08, 2018 at 05:49:42PM +0800, Carl Huang wrote:
> ath10k_pci_diag_write_mem may allocate big size of the dma memory
> based on the parameter nbytes. Take firmware diag download as
> example, the biggest size is about 500K. In some systems, the
> allocation is likely to fail be
78 matches
Mail list logo