Re: [RFC bluetooth-next 0/4] ieee802154: add support for phy capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Varka,

On Fri, Apr 10, 2015 at 09:31:30AM +0530, Varka Bhadram wrote:
> 
> I think better interface would be get_tx_power() for returning the current power setting

No, we have already such functionality to get the current tx power and
the 802.15.4 standard describes this as part of the pib. [0] 802.15.4
describes this as integer and I hope s8 is enough as range. But this is
funny then, because transceivers allow also floating point dbm values :-)
That 802.15.4 describes this as integer we should use a int (s8) as well here,
that was a open question in my other mails.

This pib attribute should be also set if set_tx_power was successful
afterwards with the values which was set.

> and tx_power_supported() to get the all the available power levels.
> 

Yes we talking about the capabilities here only:

The general question about this capability is:

  1.  Does this interface will report all power levels for all page/channel?

  or

  2. Does this interface will report all power levels for current
     page/channel setting only?

  The second one is much easier to implement. But this is a question
  which should be answered before.

  If you asking yourself "which tx_powers for each ch/page?" This is not
  available for 2.4 Ghz transceivers, but transceivers like the
  at86rf212 which operates in 700/800/900Mhz have different tx power
  settings according the channel/page setting.


The subquestion is here more how we should implement it. Current
solutions are:

  1. Create a big array with some mask and set the bit about some
     tx_power range and do some mask |= BIT(SUPP_5DBM). But this will
     restrict the available setting of dbm levels.

  2. The second idea was do use a "context based iteration of available
     tx power settings". Netlink can do this quite well with nested
     attributes. Calltrace would look like:

     nla_nest_start
     rdev_get_tx_pwr(&pwr)
          rdev->ops->get_tx_pwr(&pwr)
	        mac802154_get_tx_pwr(&pwr)
		    /* driver_will_set_tx_pwr #1 */
     nla_put_s8(pwr)
     rdev_get_tx_pwr(&pwr)
          rdev->ops->get_tx_pwr(&pwr)
	        mac802154_get_tx_pwr(&pwr)
		    /* driver_will_set_tx_pwr #2 */
     nla_put_s8(pwr)
     rdev_get_tx_pwr(&pwr)
          rdev->ops->get_tx_pwr(&pwr)
	        mac802154_get_tx_pwr(&pwr)
		    /* driver_will_set_tx_pwr #3 */
     nla_put_s8(pwr)
     ....
     ....
     ....
     rdev_get_tx_pwr(&pwr)
          rdev->ops->get_tx_pwr(&pwr)
	        mac802154_get_tx_pwr(&pwr)
		    /* driver_will_set_tx_pwr last. Must return 1 */
     nla_put_s8(pwr)
     /* indicated because rdev_get_tx_pwr returned 1 */
     nla_nest_end


If you tell me you want "tx_power_supported()", please give me more
details how this interface will be look like.

- Alex

[0] http://lxr.free-electrons.com/source/include/net/cfg802154.h#L78
[1] http://www.atmel.com/images/doc8168.pdf page 107
--
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




[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux