[PATCH] wlcore: implement .flush callback

[PATCH] wlcore: implement .flush callback

[Luciano Coelho]

From: Eliad Peller <eliad@wizery.com>

implement the .flush() callback by simply calling wl1271_tx_flush().

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
 drivers/net/wireless/ti/wlcore/main.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 709f6dd..6ac3323 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -4637,6 +4637,13 @@ out:
 	mutex_unlock(&wl->mutex);
 }
 
+static void wlcore_op_flush(struct ieee80211_hw *hw, bool drop)
+{
+	struct wl1271 *wl = hw->priv;
+
+	wl1271_tx_flush(wl);
+}
+
 static bool wl1271_tx_frames_pending(struct ieee80211_hw *hw)
 {
 	struct wl1271 *wl = hw->priv;
@@ -4827,6 +4834,7 @@ static const struct ieee80211_ops wl1271_ops = {
 	.tx_frames_pending = wl1271_tx_frames_pending,
 	.set_bitrate_mask = wl12xx_set_bitrate_mask,
 	.channel_switch = wl12xx_op_channel_switch,
+	.flush = wlcore_op_flush,
 	CFG80211_TESTMODE_CMD(wl1271_tm_cmd)
 };
 
-- 
1.7.10

Re: [PATCH] wlcore: implement .flush callback

[Luciano Coelho]

On Wed, 2012-06-27 at 19:09 +0300, Luciano Coelho wrote:
> From: Eliad Peller <eliad@wizery.com>
> 
> implement the .flush() callback by simply calling wl1271_tx_flush().
> 
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---

Applied and pushed.

--
Luca.

Re: [PATCH] wlcore: implement .flush callback

[Arend van Spriel]

On 06/27/2012 06:09 PM, Luciano Coelho wrote:
> From: Eliad Peller <eliad@wizery.com>
> 
> implement the .flush() callback by simply calling wl1271_tx_flush().
> 
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
>  drivers/net/wireless/ti/wlcore/main.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
> +static void wlcore_op_flush(struct ieee80211_hw *hw, bool drop)
> +{
> +	struct wl1271 *wl = hw->priv;
> +
> +	wl1271_tx_flush(wl);
> +}
> +

So not taking the drop flag into account? Any plan to change that?

Gr. AvS

Re: [PATCH] wlcore: implement .flush callback

[Eliad Peller]

On Thu, Jun 28, 2012 at 2:07 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 06/27/2012 06:09 PM, Luciano Coelho wrote:
>> From: Eliad Peller <eliad@wizery.com>
>>
>> implement the .flush() callback by simply calling wl1271_tx_flush().
>>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> Signed-off-by: Luciano Coelho <coelho@ti.com>
>> ---
>>  drivers/net/wireless/ti/wlcore/main.c |    8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
>> +static void wlcore_op_flush(struct ieee80211_hw *hw, bool drop)
>> +{
>> +     struct wl1271 *wl = hw->priv;
>> +
>> +     wl1271_tx_flush(wl);
>> +}
>> +
>
> So not taking the drop flag into account? Any plan to change that?
>
yeah, good point...
i guess we'll want to add support for the drop flag as well.

Luca - you can either drop this patch, or apply it for now and i'll
send another patch later on.

thanks,
Eliad.

Re: [PATCH] wlcore: implement .flush callback

[Arik Nemtsov]

On Thu, Jun 28, 2012 at 2:25 PM, Eliad Peller <eliad@wizery.com> wrote:
> On Thu, Jun 28, 2012 at 2:07 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 06/27/2012 06:09 PM, Luciano Coelho wrote:
>>> From: Eliad Peller <eliad@wizery.com>
>>>
>>> implement the .flush() callback by simply calling wl1271_tx_flush().
>>>
>>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>>> Signed-off-by: Luciano Coelho <coelho@ti.com>
>>> ---
>>>  drivers/net/wireless/ti/wlcore/main.c |    8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
>>> +static void wlcore_op_flush(struct ieee80211_hw *hw, bool drop)
>>> +{
>>> +     struct wl1271 *wl = hw->priv;
>>> +
>>> +     wl1271_tx_flush(wl);
>>> +}
>>> +
>>
>> So not taking the drop flag into account? Any plan to change that?
>>
> yeah, good point...
> i guess we'll want to add support for the drop flag as well.
>
> Luca - you can either drop this patch, or apply it for now and i'll
> send another patch later on.

Currently we drop all the packets if we can't flush them within a
reasonable time. We always do this right now. I think that's good
enough?

Re: [PATCH] wlcore: implement .flush callback

[Arend van Spriel]

On 06/28/2012 01:31 PM, Arik Nemtsov wrote:
> On Thu, Jun 28, 2012 at 2:25 PM, Eliad Peller <eliad@wizery.com> wrote:
>> On Thu, Jun 28, 2012 at 2:07 PM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 06/27/2012 06:09 PM, Luciano Coelho wrote:
>>>> From: Eliad Peller <eliad@wizery.com>
>>>>
>>>> implement the .flush() callback by simply calling wl1271_tx_flush().
>>>>
>>>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>>>> Signed-off-by: Luciano Coelho <coelho@ti.com>
>>>> ---
>>>>  drivers/net/wireless/ti/wlcore/main.c |    8 ++++++++
>>>>  1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
>>>> +static void wlcore_op_flush(struct ieee80211_hw *hw, bool drop)
>>>> +{
>>>> +     struct wl1271 *wl = hw->priv;
>>>> +
>>>> +     wl1271_tx_flush(wl);
>>>> +}
>>>> +
>>>
>>> So not taking the drop flag into account? Any plan to change that?
>>>
>> yeah, good point...
>> i guess we'll want to add support for the drop flag as well.
>>
>> Luca - you can either drop this patch, or apply it for now and i'll
>> send another patch later on.
> 
> Currently we drop all the packets if we can't flush them within a
> reasonable time. We always do this right now. I think that's good
> enough?
> 

Hard to say as I am working mostly on your side of this API. However,
the drop flag is part of the API so there is probably a reason for
having it. Johannes?

Gr. AvS

Re: [PATCH] wlcore: implement .flush callback

[Johannes Berg]

On Thu, 2012-06-28 at 20:44 +0200, Arend van Spriel wrote:

> >>> So not taking the drop flag into account? Any plan to change that?
> >>>
> >> yeah, good point...
> >> i guess we'll want to add support for the drop flag as well.
> >>
> >> Luca - you can either drop this patch, or apply it for now and i'll
> >> send another patch later on.
> > 
> > Currently we drop all the packets if we can't flush them within a
> > reasonable time. We always do this right now. I think that's good
> > enough?
> > 
> 
> Hard to say as I am working mostly on your side of this API. However,
> the drop flag is part of the API so there is probably a reason for
> having it. Johannes?

The drop never actually used today... but we had plans to use it in some
cases I think.

johannes

Re: [PATCH] wlcore: implement .flush callback

[Luciano Coelho]

On Thu, 2012-06-28 at 20:48 +0200, Johannes Berg wrote:
> On Thu, 2012-06-28 at 20:44 +0200, Arend van Spriel wrote:
> 
> > >>> So not taking the drop flag into account? Any plan to change that?
> > >>>
> > >> yeah, good point...
> > >> i guess we'll want to add support for the drop flag as well.
> > >>
> > >> Luca - you can either drop this patch, or apply it for now and i'll
> > >> send another patch later on.
> > > 
> > > Currently we drop all the packets if we can't flush them within a
> > > reasonable time. We always do this right now. I think that's good
> > > enough?
> > > 
> > 
> > Hard to say as I am working mostly on your side of this API. However,
> > the drop flag is part of the API so there is probably a reason for
> > having it. Johannes?
> 
> The drop never actually used today... but we had plans to use it in some
> cases I think.

I have just grepped the code and I also see that drop is always false as
it is.

Of course, the API specifies this drop parameter and how it should be
handled, so we should treat it too, so nothing breaks if mac80211
changes.

But, as defined in the API documentation:

 * @flush: Flush all pending frames from the hardware queue, making sure
 *	that the hardware queues are empty. If the parameter @drop is set
 *	to %true, pending frames may be dropped. The callback can sleep.

Frames *may* be dropped if drop is set to true.  We don't *have* to drop
them, so it should be fine to ignore it and remain true to the API
specification.

--
Luca.