On 04/09/2015 06:03 PM, Alexander Aring wrote:
> On Thu, Apr 09, 2015 at 01:36:58PM +0200, Alexander Aring wrote:
>> 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),
>> };
>>
> I think a better interface would be a new driver_op. Something like
> "context based list interation while rtnl is hold", some new callback:
> int get_tx_power(s8 *dbm), then nl802154 can start some nested attribute
> and we calling get_tx_power until it returns 1 which indicate the end of
> tx_power lists and ends the nested attribute. I will try to implement
> this in this way.
>
> - Alex
I think better interface would be get_tx_power() for returning the current power setting
and tx_power_supported() to get the all the available power levels.
--
Varka Bhadram
--
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
