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
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
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
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
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
> ---
>
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?
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 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
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
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
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.
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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.
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
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
---
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
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
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
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
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.
>
>
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
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
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
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
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 |
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
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
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(+),
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
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
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
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 *);
> > >
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
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
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
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
Patches 3-5 looks ok to me, I'll rebase and resend them.
Thanks
Stanislaw
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(_pin,
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 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
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
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,
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];
>> +
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
- 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
> > 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
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
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
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,
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 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
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
70 matches
Mail list logo
