Hi, On Thu, May 21, 2015 at 06:39:06PM +0200, Stefan Schmidt wrote: > Hello. > > On 21/05/15 17:39, Alexander Aring wrote: > >On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote: > >>Hello. > >> > >>On 20/05/15 15:21, Stefan Schmidt wrote: > >>>Hello. > >>> > >>>On 20/05/15 15:18, Stefan Schmidt wrote: > >>>>Hello. > >>>> > >>>>Nothing to be appliad to the kernel but rather the atusb firmware repo. Just > >>>>sending it here as it is releated to the mainline driver and the device users > >>>>are reading here. > >>>> > >>>>These are the four patches I consider we need to have a working 0.2 release. > >>>>The revert might be only needed for my qemu setup with USB passthrough, but > >>>>without it I'm not able to get the device to show up in qemu. Thoughts > >>>>appreciated. > >>>> > >>>>Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work > >>>>well with nodes using ARET. > >>>> > >>>>Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to > >>>>the firmware file. I will followup with a mail attaching the binary I'm using > >>>>right now and I consider the final 0.2 if everyone agrees with these patches. > >>>> > >>>Binary firmware image attached. Alexander, if you could give that a test > >>>it would be appreciated. > >>> > >>>Everyone else with a atusb please test as well if you have the time. > >>The pending patches have been pushed and I tagged the atusb firmware 0.2 > >>release in git: > >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/ > >> > >>The firmware binary should be available from the website soon. If you are > >>eager you can get it here: > >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu > >> > >>If anyone has patches for the firmware pending or upcoming please CC me. I > >>should be able help reviewing, testing and pushing them. > >> > >Maybe send patches to be maintainer of atusb driver? > Guess I can do that if you want. I have some more patches coming but they > are not ready yet. Mostly catch up with what the stack learned in the last > months. Adding the hooks inside the driver. Things like > .set_promiscuous_mode, .set_frame_retries, .set_txpower, etc. > in case of set_frame_retries above 0 this is will be fun, because you need to turn then into TX_ARET_ON instead TX_ON state. :-) In case of promiscuous mode, if the PHR field (the len byte) is evaluated you need to remember that the phy doesn't filter anything and then the len could be above 127. I introduced for this use case the ieee802154_is_valid_psdu_len function. But depends if the firmware use this value before. It's a mess when the len field is not correct then you can guess where the lqi byte is. In case of at86rf231 we need to be sure that the len is not above the MTU otherwise we have an invalid array dereference of the pdu payload. I am sure you will care about all these things. :-) - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
