On 2018-09-18 13:41, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan writes:
Also an option to add the node at head or tail would be preferred.
If
return_txq adds node at head of list, then it is forcing the driver
to
serve same txq until it becomes empty. Also this will not allow the
Rajkumar Manoharan writes:
>>> Also an option to add the node at head or tail would be preferred. If
>>> return_txq adds node at head of list, then it is forcing the driver to
>>> serve same txq until it becomes empty. Also this will not allow the
>>> driver to send N frames from each txqs.
>>
On 2018-09-18 03:29, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan writes:
On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote:
return_txq() should return a bool to inform the driver that whether
txq is queued back or not.
What would the driver do with that return value, exactly?
never
On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka wrote:
>
> On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote:
> > Sorry to bump the one thing that we both agreed was low priority but
> >
> > So was testing all of my dongles that use the driver you are working
> > on, and running them
mt76x0 isn't in 4.18 at all, it's being added in 4.19 isn't it? I'm
not sure you can call it a regression, but adding a new driver with a
known bug that breaks an entire use case (monitor mode) seems silly
when a small and tested fix is available. Pretty please.
Thanks,
Zero
On Tue, Sep 18,
Operating on a DFS channel doesn't mean we can't leave it for a short
time - actually, some features like off-channel CAC work by leaving the
operation channel to check other channels for availability (although
off-channel CAC isn't implemented in mac80211). In our case, we want to
use mesh while
On Tue, 18 Sep 2018 14:20:16 +0200, Stanislaw Gruszka wrote:
>On Mon, Sep 17, 2018 at 06:32:51PM +0200, Tomislav Požega wrote:
>> Use curr_band instead of rf->channel among various subroutines -
>> mostly for 2.4GHz band but in some circumstances for 5GHz band too.
>
>What is the reason for that
Stanislaw Gruszka writes:
> On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote:
>> On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote:
>> > According to vendor sdk, vco calibration has to be executed
>> > for each channel configuration whereas mcu calibration has to
On Mon, Sep 17, 2018 at 06:32:52PM +0200, Tomislav Požega wrote:
> - switch (rt2x00dev->default_ant.tx_chain_num) {
> - case 3:
> - /* Turn on tertiary PAs */
> - rt2x00_set_field32(_pin, TX_PIN_CFG_PA_PE_A2_EN,
> -rf->channel > 14);
On Mon, Sep 17, 2018 at 06:32:51PM +0200, Tomislav Požega wrote:
> Use curr_band instead of rf->channel among various subroutines -
> mostly for 2.4GHz band but in some circumstances for 5GHz band too.
What is the reason for that change ?
> @@ -9265,8 +9278,9 @@ static int
Remove not useful WARN_ON macros in mt76u_get_rx_entry_len routine
since corrupted frames should just be silently discarded
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/usb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote:
> On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote:
> > According to vendor sdk, vco calibration has to be executed
> > for each channel configuration whereas mcu calibration has to be
> > performed during channel
On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote:
> Sorry to bump the one thing that we both agreed was low priority but
>
> So was testing all of my dongles that use the driver you are working
> on, and running them through my connect scripts. I moved the AP to
> maybe <5ft from the
On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote:
> According to vendor sdk, vco calibration has to be executed
> for each channel configuration whereas mcu calibration has to be
> performed during channel scanning. This patch fixes the mt76x0
> monitor mode issue since in that
Rajkumar Manoharan writes:
> On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote:
>> +/**
>> + * ieee80211_return_txq - return a TXQ previously acquired by
>> ieee80211_next_txq()
>> + *
>> + * @hw: pointer as obtained from ieee80211_alloc_hw()
>> + * @txq: pointer obtained from station or virtual
Hi Samuel,
On 6/8/2018 12:38 PM, Daniel Mack wrote:
On Tuesday, July 24, 2018 11:59 AM, Daniel Mack wrote:
This v3 of a series of patches for the ST95HF driver.
Patch #1 reverts a change that I have submitted earlier and which is
sitting in nfc-next already. Given that the tree hasn't been
Hi Kalle,
Here's a large batch of mt76 code cleanup / deduplication / fixes,
rebased to your latest wireless-drivers-next.
- Felix
The following changes since commit 43e2f2904160b9a95aad77df9cbc1622910b8598:
Merge wireless-drivers into wireless-drivers-next (2018-09-17 17:41:02 +0300)
are
17 matches
Mail list logo
