On Thu, Apr 09, 2015 at 03:07:23PM +0530, Varka Bhadram wrote:
> On 04/09/2015 02:58 PM, Alexander Aring wrote:
> > On Thu, Apr 09, 2015 at 12:02:10PM +0530, Varka Bhadram wrote:
> >> On 04/08/2015 04:48 PM, Alexander Aring wrote:
> >>> Hi,
> >>>
> >>> this patches introduce a mechanism to get phy capabilities. We simple add
> >>> some additional pib values like "channels_supported" information. These
> >>> information also includes mib values which are phy dependent like frame_retries
> >>> or csma_backoffs, this is necessary because the phy doing a little bit mac
> >>> stuff. We simple extend the pib according these phy dependent mac values.
> >>>
> >>> These capabilities are by default full 802.15.4 complaint, if some transceiver
> >>> supports less functionality only then these values need to be overwritten inside
> >>> the driver-layer.
> >>>
> >>> Fruthermore we also add functionality to dump these values via
> >>> NL802154_CMD_GET_WPAN_PHY.
> >>>
> >>> - Alex
> >>>
> >>> Cc: Phoebe Buckheister <phoebe.buckheister@xxxxxxxxxxxxxxxxxx>
> >>> Cc: Varka Bhadram <varkabhadram@xxxxxxxxx>
> >>>
> >>> Alexander Aring (4):
> >>> ieee802154: introduce wpan_phy_supported struct
> >>> ieee802154: move channels supported out of softmac
> >>> ieee802154: add several phy supported handling
> >>> at86rf230: set cca_modes supported flags
> >>>
> >>> drivers/net/ieee802154/at86rf230.c | 14 ++++++++++----
> >>> drivers/net/ieee802154/cc2520.c | 2 +-
> >>> drivers/net/ieee802154/fakelb.c | 30 +++++++++++++++---------------
> >>> drivers/net/ieee802154/mrf24j40.c | 2 +-
> >>> include/net/cfg802154.h | 11 ++++++++++-
> >>> net/ieee802154/nl-phy.c | 4 ++--
> >>> net/ieee802154/nl802154.c | 29 ++++++++++++++++++++++-------
> >>> net/mac802154/cfg.c | 4 ----
> >>> net/mac802154/main.c | 10 ++++++++++
> >>> 9 files changed, 71 insertions(+), 35 deletions(-)
> >>>
> >> And also we need to look into expose available power level (supported by transeiver)
> >> to the user space by iwpan. Then user can configure the particular power level.
> >>
> >> If not user don't know the power levels that the transceiver support.
> >>
> > yep... I will try to add it to the next series, also for ed_level. For
> > 700/800/900 Mhz at86rf212 it depends on which band the transceiver operates
> > and the available tx_power settings.
> >
> > When I try to implement it, then I need to know the country/band laws
> > what's the min and max tx_power db values? Does something like this
> > exists? Is s8 as datatype really enough to support all available
> > tx_power settings? -> (not because I also saw some floating point tx_power
> > settings, but then we simple doesn't provide them). I will try to
> > introduce something which supports the at86rf2xx transceiver values. We
> > can still change the interface again later if it doesn't fit, but then
> > everybody will hate us. :-)
> >
> > - Alex
>
> I think its not going to work out. But i am worrying about how the driver user
> will know the power levels available..?
You mean to know the power levels in userspace? We will introduce
tx_power in wpan_phy_supported of course, then we will add support for
dumping these values on a wpan_phy dump.
>
> How mac80211 is managing this issue..?
s/mac80211/wireless/
yes, I also looked in wireless. They used a U32 type and making some
conversion to a floating point values by doing "value/100", do they have
some Y.XX value. They call the not converted value MBM and converted
value DBM, not sure for what MBM 100% stands.
This is for the tx_power value.
For requesting all supported tx_power values, I run "iw phy" on my side
and they have only some frequency @ dbm information. And in my case the
dbm value was always the same for all frequency.
This was probaly the "max tx power" value for the frequency [1].
What wireless has is a "automatic tx power" support, so there is some
heuristic around to detect the optimized tx_power setting.
The wireless tx_power looks very complicated at the moment and we should
first support some existing nl802154 cmd (which was also before there)
for setting a fixed tx_power mode. If wireless doesn't support dumping
for that, means not we should also not support it.
Maybe we can use some:
u64 tx_power[IEEE802154_MAX_PAGE + 1][IEEE802154_MAX_CHANNEL + 1];
Then start some enum:
enum nl802154_tx_power {
NL802154_TX_POWER_20DBM = BIT(0),
NL802154_TX_POWER_19DBM = BIT(1),
NL802154_TX_POWER_18DBM = BIT(2),
...
NL802154_TX_POWER_NEG_44DBM = BIT(63),
};
and set these with an u64 mask. The question is can be the tx_power not
higher than 30dbm and lower than -34 dbm? :-) Maybe we should simple
here vote for a valid range which we use then. All above and below isn't
support. The dbm value is a logarithm scale. The highest value on
at86rf233 is 5 dbm and I don't think that there are transceivers outside
which supports significant more. If there are transceivers outside which
supports more we can add some another u64 higher bits to the array for
have a type like u128 then or we don't allow other settings.
- Alex
[0] http://lxr.free-electrons.com/source/net/mac80211/cfg.c#L2099
[1] http://lxr.free-electrons.com/source/include/net/cfg80211.h#L168
--
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
