On 04/15/2015 02:33 AM, Johannes Berg wrote:
On Tue, 2015-04-14 at 08:55 -0700, Ben Greear wrote:
True, although I'd like to see the multi-channel issue addressed better.
I need a hint or two on what exactly you want changed in my patch to
address your request, or maybe you or someone else
On Tue, 2015-04-14 at 08:55 -0700, Ben Greear wrote:
True, although I'd like to see the multi-channel issue addressed better.
I need a hint or two on what exactly you want changed in my patch to
address your request, or maybe you or someone else can just address
the issue in follow-on
On Tue, 2015-03-31 at 08:56 -0700, Ben Greear wrote:
Well, depends. Our driver just asks the firmware to do the scan, and it
will do all the scheduling by itself, i.e. it'll go through the channels
at convenient times etc.
I do not want to offload scanning in user-space, which is the
On Tue, 2015-04-14 at 07:56 -0700, Ben Greear wrote:
Well, the question isn't really that offloading, the question is what
happens with the hw-scan logic in hwsim? Though I guess now that I think
about it, that wouldn't show up in userspace at all with your changes.
I think for HW scan
On 04/14/2015 01:13 AM, Johannes Berg wrote:
On Tue, 2015-03-31 at 08:56 -0700, Ben Greear wrote:
Well, depends. Our driver just asks the firmware to do the scan, and it
will do all the scheduling by itself, i.e. it'll go through the channels
at convenient times etc.
I do not want to
On 04/14/2015 08:06 AM, Johannes Berg wrote:
On Tue, 2015-04-14 at 07:56 -0700, Ben Greear wrote:
Well, the question isn't really that offloading, the question is what
happens with the hw-scan logic in hwsim? Though I guess now that I think
about it, that wouldn't show up in userspace at all
On Wed, 2015-03-11 at 14:05 -0700, Ben Greear wrote:
I took a look at the hw-scan code a bit...I guess we might could do additional
info calls to user-space as we iterate through the channels while scanning?
A real driver would be causing the NIC to change channels at these junctures,
On 03/31/2015 07:27 AM, Johannes Berg wrote:
On Wed, 2015-03-11 at 14:05 -0700, Ben Greear wrote:
I took a look at the hw-scan code a bit...I guess we might could do
additional
info calls to user-space as we iterate through the channels while scanning?
A real driver would be causing the
On 02/24/2015 06:40 AM, Johannes Berg wrote:
On Tue, 2015-02-24 at 06:36 -0800, Ben Greear wrote:
We could push more and more of this to user-space and let it decide whether
and
how to forward or accept frames for particular radios.
Sure, no objection to that. However, just arbitrarily
On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote:
This seems a bit strange - don't we already tag packets with the
frequency? Why would you need the channel change separately? What does
that even mean? Depending on how you use this it could entirely break
off-channel operation, for
On Tue, 2015-02-24 at 06:36 -0800, Ben Greear wrote:
We could push more and more of this to user-space and let it decide whether
and
how to forward or accept frames for particular radios.
Sure, no objection to that. However, just arbitrarily adding a change
channel call, without thinking
On 02/24/2015 02:11 AM, Johannes Berg wrote:
On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote:
This seems a bit strange - don't we already tag packets with the
frequency? Why would you need the channel change separately? What does
that even mean? Depending on how you use this it could
On Tue, 2015-02-17 at 15:59 -0800, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
The goal is to allow the user-space application to properly
filter packets before sending them down to the kernel. This
should more closely mimic what a real piece of hardware would
From: Ben Greear gree...@candelatech.com
The goal is to allow the user-space application to properly
filter packets before sending them down to the kernel. This
should more closely mimic what a real piece of hardware would
do.
Signed-off-by: Ben Greear gree...@candelatech.com
---
This is
14 matches
Mail list logo
