RFC: Small additions to the atusb driver code

Werner Almesberger werner at almesberger.net
Thu Jun 23 09:56:34 EDT 2011


Stefan Schmidt wrote:
> Passing the IRQ through and letting the host driver take care of
> reading the register on its own. Lets hope we don't hit any timing
> problems with this approach.

There's still the race with synchronize_irq after changing
transceiver stat. Note quite sure yet how to solve this, but the
overall picture looks nicer.

> The problem that the received frame is still in the buffer while the
> new one should be written into it

If you add the synchronize_irq and flush_work ritual I posted on
the linux-zigbee list and solve the race I mentioned above, this
can never happen ;-)

> is something we can solve with
> emulating two different buffer for rx and tx. That would also be true
> for having two different interrupts instead a shared one.

Sounds scary :-)

> The downside is that we have more complex MCU code and need to change
> some of the logic of the original driver. That may be a bit to much of
> a downside to consider this. Hmm...

Yeah, if we have to go to such extreme means, it's better to just
keep all the complexity in the kernel driver and diverge from the
original at86rf230.c as needed.

There would clearly be a performance advantage in having a more
complex process running inside atusb, but I'd rather do this in a
later phase of development. I like goals one can reach in a few
days ;-)

- Werner




More information about the discussion mailing list


interactive