On Wed, Aug 05, 2015 at 10:46:04AM +0200, Stefan Schmidt wrote: ... > >>This confuses me. During alloc_hw we set min to 0 which makes sense for me > >>but afterwards we set both, min and max, to 3? Should it not only be max to > >>three here? Am I missing something? > >> > >Here is also meant the range. But in this case the transceiver doesn't > >support IEEE802154_HW_FRAME_RETRIES. Then the stack assumes the 802.15.4 > >default value and the range is "3..3". > > Hmm, would it not make sense to assume that a transceiver which does not > support IEEE802154_HW_FRAME_RETRIES does not support ARET at all? > We indicate right now that the frame_retries value "-1" indicates that the transceiver running in "no ARET" support. I am fine to introduce this with a new HW flag which indicates that the transceiver doesn't support ARET handling. But then we can also bring the AACK flag back. We can't forbid from stack that we doesn't send out MAC frames where the ack request bit is set. Some of the MLME-ops requires ack handling (or we simple don't do what the standard says and always clear this bit before transmit when IEEE802154_HW_NO_ARET is set). Or we can also do just printout a WARN_ONCE then that the user should buy a "real" transceiver. This is the same like the AACK handling flag. The mac802154 layer Should never see any ACK frames because we can't handle them and it looks also that when the transceivers support AACK handling, then ack frames are completely handled by the transceiver, they don't send them to the next layer (except if you are in promiscuous mode). Anyway, if the transceiver doesn't support ARET _or_ AACK you _always_ running in issues in 802.15.4 networks which use acknowledge handling. What I definitely want is to get the "-1" value out of frame_retries behaviour. The standard says a range of "0..7" here and if the driver implementation too poor to report it then we think it's 802.15.4 default. There exists no value which indicates "no frame_retries handling supported" (In case of mrf24j40 this is also true, because it doesn't support setting of frame_retries. It's in this case really always 3). See [0], "The aMaxFrameRetries value is a constant and not configurable." "... is not received after aMaxFrameRetries (3) transmissions." The ack handling can be set by setting some bit "TXNACKREQ" and currently the mrf24j40 implementation do this also per frame and check on ackreq bit [1]. In my opninion, we have the frame_retries = -1 value because historical issues and should do the handling like mrf24j40. btw: I currently try to work on some things on this driver. > For me it sounds more as if we would want to set the range to 0..0 here > because the transceiver does not support IEEE802154_HW_FRAME_RETRIES andthus > no ARET. > no, (frame_retries = 0) != no ARET. The reason is easy, you can set frame_retries to zero and going into ARET mode. The important thing is "the transceiver waits for an ACK frame after transmit", if this is not see then the transceiver logic is -> transmit failed. (In this case you have no retransmit, because frame_retries is 0). The diffirent between no ARET handling is, the transceiver _doesn't_ wait for an ACK frame and it's always successful to send something out. - Alex [0] http://ww1.microchip.com/downloads/en/DeviceDoc/39776C.pdf [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/mrf24j40.c#L355 -- 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
