Hi Rami,
When I delete the project's directory
and I clone the project again
and I compile it with uncommented parameter "CONFIG_LIBNL32=y"
then the compilation is successful.
Thanks for the advice.
HI Pavlin,
Please try from scratch cloning the tree from scratch, then
cp defconfig .config,
On Mon, 2018-09-10 at 19:27 +0200, Lorenzo Bianconi wrote:
> >
> > Start wpa_supplicant
> > Attach to a Cisco AP (haven't tried too many other APs yet).
> > Desktop
> > locks up hard. I have some shell scripts I use start wpa_supp and
> > run
> > wpa_cli (I'm not going through the GNOME ui or
>
> Start wpa_supplicant
> Attach to a Cisco AP (haven't tried too many other APs yet). Desktop
> locks up hard. I have some shell scripts I use start wpa_supp and run
> wpa_cli (I'm not going through the GNOME ui or other).
>
> (Occurs to me I need to verify I didn't have the system's
>
Start wpa_supplicant
Attach to a Cisco AP (haven't tried too many other APs yet). Desktop
locks up hard. I have some shell scripts I use start wpa_supp and run
wpa_cli (I'm not going through the GNOME ui or other).
(Occurs to me I need to verify I didn't have the system's
wpa_supplicant
Johannes Berg writes:
> On Mon, 2018-09-10 at 15:18 +0200, Toke Høiland-Jørgensen wrote:
>
>> If we have the start_schedule() / end_schedule() pair anyway, the latter
>> could notify any TXQs that became eligible during the scheduling round.
>
> Do we even need end_schedule()? It's hard to pass
On Mon, 2018-09-10 at 15:18 +0200, Toke Høiland-Jørgensen wrote:
> If we have the start_schedule() / end_schedule() pair anyway, the latter
> could notify any TXQs that became eligible during the scheduling round.
Do we even need end_schedule()? It's hard to pass multiple things to a
single call
Johannes Berg writes:
> On Mon, 2018-09-10 at 15:08 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote:
>> >
>> > > > From then on, right now we basically just try to refill the hardware
>> > > > queue from the
On Mon, 2018-09-10 at 15:08 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote:
> >
> > > > From then on, right now we basically just try to refill the hardware
> > > > queue from the TXQ whenever the hardware
Johannes Berg writes:
> On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote:
>
>> > From then on, right now we basically just try to refill the hardware
>> > queue from the TXQ whenever the hardware releases frames from that
>> > queue. If there are none, we fall back to putting them
On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote:
> > From then on, right now we basically just try to refill the hardware
> > queue from the TXQ whenever the hardware releases frames from that
> > queue. If there are none, we fall back to putting them on the hardware
> > queue
Johannes Berg writes:
> On Mon, 2018-09-10 at 12:57 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>> > >
>> > > Usage of the new API is optional, so drivers can be ported one at a time.
>> >
>> > With
On Mon, 2018-09-10 at 13:17 +0200, Toke Høiland-Jørgensen wrote:
> > > - I did not add any locking around next_txq(); the driver is still
> > > supposed
> > > to maintain a lock that prevents two threads from trying to schedule the
> > > same AC at the same time. This is what drivers already
On Mon, 2018-09-10 at 13:16 +0200, Toke Høiland-Jørgensen wrote:
> > > - I didn't get rid of the register_airtime() callback. As far as I can
> > > tell,
> > > only iwlwifi uses the tx_time field in the struct tx_info. Which means
> > > that
> > > we *could* probably use it for this and
On Mon, 2018-09-10 at 13:13 +0200, Toke Høiland-Jørgensen wrote:
>
> Yeah, this is the API that would be used by drivers where the actual
> scheduling of TXQs is done by the hardware (i.e., ath10k in pull/push
> mode, and iwlwifi if I understand you correctly); whereas the next_txq()
> call is
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>>
>> A few things that were discussed in the last round that I did *not* change:
>
> Thanks for this list btw.
>
>> - I did not add any locking around next_txq(); the driver is still supposed
>> to
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>
>> - I didn't get rid of the register_airtime() callback. As far as I can tell,
>> only iwlwifi uses the tx_time field in the struct tx_info. Which means that
>> we *could* probably use it for this and
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>> This adds airtime statistics to the cfg80211 station dump, and also adds a
>> new
>> parameter to set the airtime weight of each station. The latter allows
>> userspace
>> to implement policies for
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>>
>> +/**
>> + * ieee80211_airtime_may_transmit - check whether TXQ is allowed to transmit
>> + *
>> + * This function is used to check whether given txq is allowed to transmit
>> by
>> + * the airtime
On Mon, 2018-09-10 at 13:02 +0200, Toke Høiland-Jørgensen wrote:
>
> > Is there a case where it's allowed to call this while *not* empty? At
> > least for the drivers it seems not, so perhaps when called from the
> > driver it should WARN() here or so?
>
> Yeah, mac80211 calls this on wake_txq,
On Mon, 2018-09-10 at 12:57 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
> > >
> > > Usage of the new API is optional, so drivers can be ported one at a time.
> >
> > With the 1:1 hardware queue/txq mapping
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>
>> +/**
>> + * ieee80211_next_txq - get next tx queue to pull packets from
>> + *
>> + * @hw: pointer as obtained from ieee80211_alloc_hw()
>> + * @ac: AC number to return packets from.
>> + * @first:
Johannes Berg writes:
> On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>>
>> Usage of the new API is optional, so drivers can be ported one at a time.
>
> With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to
> getting that patch in, though now the Jewish holidays
Kan Yan writes:
> Hi Toke,
>
> It is great to see finally there will be a general airtime fairness
> support in mac80211. I feel this patch set could still use some
> improvements to make it works better with 11ac drivers like ath10k. I
> did a version of airtime fairness in the ath10k driver
hI,
I would like to test network connection
between simulated Wi-Fi access point and a station by using hostapd.
Both reside on the same tesing machine which does not have Wi-Fi adapter.
I would like to test 802.1x + TLS authentication.
When I run hostapd
then I see error message:
OpenSSL:
On 2018-09-06 11:18, Stanislaw Gruszka wrote:
> From: Lorenzo Bianconi
>
> Move mt76x2u_set_txinfo routine in mt76x02-lib module and rename it in
> mt76x02_set_txinfo in order to be reused in mt76x0 driver
>
> Signed-off-by: Lorenzo Bianconi
> Signed-off-by: Stanislaw Gruszka
> ---
>
On 2018-09-06 12:43, Stanislaw Gruszka wrote:
> On Thu, Sep 06, 2018 at 11:33:55AM +0200, Felix Fietkau wrote:
>> On 2018-09-06 11:18, Stanislaw Gruszka wrote:
>> > Move some irq handling code to generic mmio module.
>> >
>> > Signed-off-by: Stanislaw Gruszka
>> Please drop this patch. This
On 2018-09-04 16:41, Stanislaw Gruszka wrote:
> We use q->hw_idx in very few places, remove it and provide hwq index
> by diffrent way. This will allow ot unify conf_tx mac80211 callback.
>
> Signed-off-by: Stanislaw Gruszka
I think this patch is a step in the wrong direction, especially when it
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
> This adds airtime statistics to the cfg80211 station dump, and also 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
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>
> +/**
> + * ieee80211_airtime_may_transmit - check whether TXQ is allowed to transmit
> + *
> + * This function is used to check whether given txq is allowed to transmit by
> + * the airtime scheduler, and can be used by drivers
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
> +/**
> + * ieee80211_next_txq - get next tx queue to pull packets from
> + *
> + * @hw: pointer as obtained from ieee80211_alloc_hw()
> + * @ac: AC number to return packets from.
> + * @first: Setting this to true signifies the
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>
> A few things that were discussed in the last round that I did *not* change:
Thanks for this list btw.
> - I did not add any locking around next_txq(); the driver is still supposed
> to maintain a lock that prevents two
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>
> Usage of the new API is optional, so drivers can be ported one at a time.
With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to
getting that patch in, though now the Jewish holidays mean a delay), I'm
not sure we'd
On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
> - I didn't get rid of the register_airtime() callback. As far as I can tell,
> only iwlwifi uses the tx_time field in the struct tx_info. Which means that
> we *could* probably use it for this and just make the other drivers
33 matches
Mail list logo
