RFC: Small additions to the atusb driver code
stefan at datenfreihafen.org
Thu Jun 23 06:34:55 EDT 2011
On Wed, 2011-06-22 at 22:20, Richard Sharpe wrote:
> On Wed, Jun 22, 2011 at 9:42 PM, Stefan Schmidt
> <stefan at datenfreihafen.org> wrote:
> > We never meet each other so you may wonder what I'm sending you here. :)
> > I got 6 atusb sticks to use them in my diploma thesis and Werner was kind enough
> > to forward me a, maybe outdated, version of your usb skeleton for the atusb
> > driver.
> I haven't done any work on this for a while ... but I plan to get back
> into it ...
> > I spent some time to get the the ieee802154 stack up on my laptop and starting
> > lookign through your code and the the at86rf231. During this I came up with to
> > little patches. Not sure if they still apply to your current work tree or might
> > already be no longer needed. Its up to you what to do with them. The first one
> > could as well be a switch/case but I'm always to lazy for this with only three
> > options. ;)
> Thanks for the patches. Is the code in a GIT repository anywhere? We
> should use standard git patches, with signed-off-by etc things.
Only in my local git. I did not sign them of as I consoidered them RFC
and thus not wanting them to be merged. :) Will add the sob when
> > The second one helps us to get rid of the double probing of the driver as it
> > does have two interfaces. We only care about interface 0 here. At least that is
> > my understanding.
> I will have to go back and look at the documentation, but you are
> probably correct.
Werner confoirmed this in the other mail so the patch should be fine.
Maybe adjusting the info message if needed.
> > I'm also wondering how we could sync best with the work on this driver. Werner
> > is still musing about the overall architecture and I'm happy with a coding
> > monkey role for this project. Also I have soem time pressure here as I'm needing
> > this low level parts for some other aspects of my diploma thesis.
> So, I have been looking through the protocol documentation to figure
> out the framing and other issues, but with two of us working on this
> perhaps things can move forward more quickly.
> The things I think we need to do are:
> 1. Come up with a design for this thing, in turns of turning it into a
> netdev device at one end (above it) and correctly handling the
> protocol below it. This can perhaps be done in conjunction with
> Werner, especially since it would be good to re-use code for the
> SPI-interfaced version to be used on the Ben.
I will comment on this at the reply from Werner.
> 2. Decide on a git repository for committing code ...
I'm happy with Werners suggestion of the qi-hw kernel repo.
> 3. Perhaps have weekly IRC meetings where we go over what we plan to
> do in the following week ...
Hmm, I hoped we don't need weeks to get this things started. :) I'll
hangout in #qi-hardware for discussions. Nick is stefan_schmidt
> 4. Perhaps finish of this driver to expose all the relevant registers
> via /sys/class/xxx/etc
For what purpose? For debugging we can have a sys file where we write
the reg number into and get the result out. I don't see much benefit
of having all registers exposed in sysfs. Towards mainline they would
have to go anyway.
> Anyway, if you can attach the patches as git format-patch patches I
> will apply them to what I have got, but we need to get it into a GIT
> repository some where.
They where prepared with format-patch and send with send-email. I can
attach them next time if gmail make you trounble. I find it way harder
to review them as attachments though.
More information about the discussion