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

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

[Alexander Aring]

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@itwm.fraunhofer.de>
Cc: Varka Bhadram <varkabhadram@gmail.com>

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(-)

-- 
2.3.5

[RFC bluetooth-next 1/4] ieee802154: introduce wpan_phy_supported struct

[Alexander Aring]

This patch introduce the wpan_phy_supported struct for wpan_phy. There
is currently no way to check if a transceiver can handle IEEE 802.15.4
complaint values. With this struct we can check before if the
transceiver supports these values before sending to driver layer.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Suggested-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Cc: Varka Bhadram <varkabhadram@gmail.com>
Cc: Alan Ott <alan@signal11.us>
---
 drivers/net/ieee802154/at86rf230.c |  8 ++++----
 drivers/net/ieee802154/cc2520.c    |  2 +-
 drivers/net/ieee802154/fakelb.c    | 30 +++++++++++++++---------------
 drivers/net/ieee802154/mrf24j40.c  |  2 +-
 include/net/cfg802154.h            |  6 +++++-
 net/ieee802154/nl-phy.c            |  4 ++--
 net/ieee802154/nl802154.c          |  2 +-
 net/mac802154/cfg.c                |  2 +-
 8 files changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 5ad46f7..1e8c532 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1556,7 +1556,7 @@ at86rf230_detect_device(struct at86rf230_local *lp)
 	case 3:
 		chip = "at86rf231";
 		lp->data = &at86rf231_data;
-		lp->hw->phy->channels_supported[0] = 0x7FFF800;
+		lp->hw->phy->supported.channels[0] = 0x7FFF800;
 		lp->hw->phy->current_channel = 11;
 		lp->hw->phy->symbol_duration = 16;
 		break;
@@ -1564,15 +1564,15 @@ at86rf230_detect_device(struct at86rf230_local *lp)
 		chip = "at86rf212";
 		lp->data = &at86rf212_data;
 		lp->hw->flags |= IEEE802154_HW_LBT;
-		lp->hw->phy->channels_supported[0] = 0x00007FF;
-		lp->hw->phy->channels_supported[2] = 0x00007FF;
+		lp->hw->phy->supported.channels[0] = 0x00007FF;
+		lp->hw->phy->supported.channels[2] = 0x00007FF;
 		lp->hw->phy->current_channel = 5;
 		lp->hw->phy->symbol_duration = 25;
 		break;
 	case 11:
 		chip = "at86rf233";
 		lp->data = &at86rf233_data;
-		lp->hw->phy->channels_supported[0] = 0x7FFF800;
+		lp->hw->phy->supported.channels[0] = 0x7FFF800;
 		lp->hw->phy->current_channel = 13;
 		lp->hw->phy->symbol_duration = 16;
 		break;
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index f833b8b..84b28a0 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -653,7 +653,7 @@ static int cc2520_register(struct cc2520_private *priv)
 	ieee802154_random_extended_addr(&priv->hw->phy->perm_extended_addr);
 
 	/* We do support only 2.4 Ghz */
-	priv->hw->phy->channels_supported[0] = 0x7FFF800;
+	priv->hw->phy->supported.channels[0] = 0x7FFF800;
 	priv->hw->flags = IEEE802154_HW_OMIT_CKSUM | IEEE802154_HW_AACK |
 			  IEEE802154_HW_AFILT;
 
diff --git a/drivers/net/ieee802154/fakelb.c b/drivers/net/ieee802154/fakelb.c
index dc2bfb6..91bbf03 100644
--- a/drivers/net/ieee802154/fakelb.c
+++ b/drivers/net/ieee802154/fakelb.c
@@ -149,35 +149,35 @@ static int fakelb_add_one(struct device *dev, struct fakelb_priv *fake)
 	priv->hw = hw;
 
 	/* 868 MHz BPSK	802.15.4-2003 */
-	hw->phy->channels_supported[0] |= 1;
+	hw->phy->supported.channels[0] |= 1;
 	/* 915 MHz BPSK	802.15.4-2003 */
-	hw->phy->channels_supported[0] |= 0x7fe;
+	hw->phy->supported.channels[0] |= 0x7fe;
 	/* 2.4 GHz O-QPSK 802.15.4-2003 */
-	hw->phy->channels_supported[0] |= 0x7FFF800;
+	hw->phy->supported.channels[0] |= 0x7FFF800;
 	/* 868 MHz ASK 802.15.4-2006 */
-	hw->phy->channels_supported[1] |= 1;
+	hw->phy->supported.channels[1] |= 1;
 	/* 915 MHz ASK 802.15.4-2006 */
-	hw->phy->channels_supported[1] |= 0x7fe;
+	hw->phy->supported.channels[1] |= 0x7fe;
 	/* 868 MHz O-QPSK 802.15.4-2006 */
-	hw->phy->channels_supported[2] |= 1;
+	hw->phy->supported.channels[2] |= 1;
 	/* 915 MHz O-QPSK 802.15.4-2006 */
-	hw->phy->channels_supported[2] |= 0x7fe;
+	hw->phy->supported.channels[2] |= 0x7fe;
 	/* 2.4 GHz CSS 802.15.4a-2007 */
-	hw->phy->channels_supported[3] |= 0x3fff;
+	hw->phy->supported.channels[3] |= 0x3fff;
 	/* UWB Sub-gigahertz 802.15.4a-2007 */
-	hw->phy->channels_supported[4] |= 1;
+	hw->phy->supported.channels[4] |= 1;
 	/* UWB Low band 802.15.4a-2007 */
-	hw->phy->channels_supported[4] |= 0x1e;
+	hw->phy->supported.channels[4] |= 0x1e;
 	/* UWB High band 802.15.4a-2007 */
-	hw->phy->channels_supported[4] |= 0xffe0;
+	hw->phy->supported.channels[4] |= 0xffe0;
 	/* 750 MHz O-QPSK 802.15.4c-2009 */
-	hw->phy->channels_supported[5] |= 0xf;
+	hw->phy->supported.channels[5] |= 0xf;
 	/* 750 MHz MPSK 802.15.4c-2009 */
-	hw->phy->channels_supported[5] |= 0xf0;
+	hw->phy->supported.channels[5] |= 0xf0;
 	/* 950 MHz BPSK 802.15.4d-2009 */
-	hw->phy->channels_supported[6] |= 0x3ff;
+	hw->phy->supported.channels[6] |= 0x3ff;
 	/* 950 MHz GFSK 802.15.4d-2009 */
-	hw->phy->channels_supported[6] |= 0x3ffc00;
+	hw->phy->supported.channels[6] |= 0x3ffc00;
 
 	INIT_LIST_HEAD(&priv->list);
 	priv->fake = fake;
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index fba2dfd..f2a1bd1 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -750,7 +750,7 @@ static int mrf24j40_probe(struct spi_device *spi)
 
 	devrec->hw->priv = devrec;
 	devrec->hw->parent = &devrec->spi->dev;
-	devrec->hw->phy->channels_supported[0] = CHANNEL_MASK;
+	devrec->hw->phy->supported.channels[0] = CHANNEL_MASK;
 	devrec->hw->flags = IEEE802154_HW_OMIT_CKSUM | IEEE802154_HW_AACK |
 			    IEEE802154_HW_AFILT;
 
diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index eeda676..c4d42ad 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -59,6 +59,10 @@ struct cfg802154_ops {
 				struct wpan_dev *wpan_dev, bool mode);
 };
 
+struct wpan_phy_supported {
+	u32 channels[IEEE802154_MAX_PAGE + 1];
+};
+
 struct wpan_phy_cca {
 	enum nl802154_cca_modes mode;
 	enum nl802154_cca_opts opt;
@@ -82,7 +86,7 @@ struct wpan_phy {
 	 */
 	u8 current_channel;
 	u8 current_page;
-	u32 channels_supported[IEEE802154_MAX_PAGE + 1];
+	struct wpan_phy_supported supported;
 	s8 transmit_power;
 	struct wpan_phy_cca cca;
 
diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
index 1b9d25f6..b6826cf 100644
--- a/net/ieee802154/nl-phy.c
+++ b/net/ieee802154/nl-phy.c
@@ -56,8 +56,8 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 portid,
 	    nla_put_u8(msg, IEEE802154_ATTR_CHANNEL, phy->current_channel))
 		goto nla_put_failure;
 	for (i = 0; i < 32; i++) {
-		if (phy->channels_supported[i])
-			buf[pages++] = phy->channels_supported[i] | (i << 27);
+		if (phy->supported.channels[i])
+			buf[pages++] = phy->supported.channels[i] | (i << 27);
 	}
 	if (pages &&
 	    nla_put(msg, IEEE802154_ATTR_CHANNEL_PAGE_LIST,
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index a4daf91..4172e21 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -248,7 +248,7 @@ nl802154_send_wpan_phy_channels(struct cfg802154_registered_device *rdev,
 
 	for (page = 0; page <= IEEE802154_MAX_PAGE; page++) {
 		if (nla_put_u32(msg, NL802154_ATTR_SUPPORTED_CHANNEL,
-				rdev->wpan_phy.channels_supported[page]))
+				rdev->wpan_phy.supported.channels[page]))
 			return -ENOBUFS;
 	}
 	nla_nest_end(msg, nl_page);
diff --git a/net/mac802154/cfg.c b/net/mac802154/cfg.c
index 5d9f68c..191143a 100644
--- a/net/mac802154/cfg.c
+++ b/net/mac802154/cfg.c
@@ -71,7 +71,7 @@ ieee802154_set_channel(struct wpan_phy *wpan_phy, u8 page, u8 channel)
 	ASSERT_RTNL();
 
 	/* check if phy support this setting */
-	if (!(wpan_phy->channels_supported[page] & BIT(channel)))
+	if (!(wpan_phy->supported.channels[page] & BIT(channel)))
 		return -EINVAL;
 
 	ret = drv_set_channel(local, page, channel);
-- 
2.3.5

Re: [RFC bluetooth-next 1/4] ieee802154: introduce wpan_phy_supported struct

[Varka Bhadram]

On 04/08/2015 04:48 PM, Alexander Aring wrote:
> This patch introduce the wpan_phy_supported struct for wpan_phy. There
> is currently no way to check if a transceiver can handle IEEE 802.15.4
> complaint values. With this struct we can check before if the
> transceiver supports these values before sending to driver layer.
>
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> Suggested-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
> Cc: Varka Bhadram <varkabhadram@gmail.com>
> Cc: Alan Ott <alan@signal11.us>
> ---
>  drivers/net/ieee802154/at86rf230.c |  8 ++++----
>  drivers/net/ieee802154/cc2520.c    |  2 +-
>  drivers/net/ieee802154/fakelb.c    | 30 +++++++++++++++---------------
>  drivers/net/ieee802154/mrf24j40.c  |  2 +-
>  include/net/cfg802154.h            |  6 +++++-
>  net/ieee802154/nl-phy.c            |  4 ++--
>  net/ieee802154/nl802154.c          |  2 +-
>  net/mac802154/cfg.c                |  2 +-
>  8 files changed, 30 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
> index 5ad46f7..1e8c532 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -1556,7 +1556,7 @@ at86rf230_detect_device(struct at86rf230_local *lp)
>  	case 3:
>  		chip = "at86rf231";
>  		lp->data = &at86rf231_data;
> -		lp->hw->phy->channels_supported[0] = 0x7FFF800;
> +		lp->hw->phy->supported.channels[0] = 0x7FFF800;
>  		lp->hw->phy->current_channel = 11;
>  		lp->hw->phy->symbol_duration = 16;
>  		break;
> @@ -1564,15 +1564,15 @@ at86rf230_detect_device(struct at86rf230_local *lp)
>  		chip = "at86rf212";
>  		lp->data = &at86rf212_data;
>  		lp->hw->flags |= IEEE802154_HW_LBT;
> -		lp->hw->phy->channels_supported[0] = 0x00007FF;
> -		lp->hw->phy->channels_supported[2] = 0x00007FF;
> +		lp->hw->phy->supported.channels[0] = 0x00007FF;
> +		lp->hw->phy->supported.channels[2] = 0x00007FF;
>  		lp->hw->phy->current_channel = 5;
>  		lp->hw->phy->symbol_duration = 25;
>  		break;
>  	case 11:
>  		chip = "at86rf233";
>  		lp->data = &at86rf233_data;
> -		lp->hw->phy->channels_supported[0] = 0x7FFF800;
> +		lp->hw->phy->supported.channels[0] = 0x7FFF800;
>  		lp->hw->phy->current_channel = 13;
>  		lp->hw->phy->symbol_duration = 16;
>  		break;
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index f833b8b..84b28a0 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -653,7 +653,7 @@ static int cc2520_register(struct cc2520_private *priv)
>  	ieee802154_random_extended_addr(&priv->hw->phy->perm_extended_addr);
>  
>  	/* We do support only 2.4 Ghz */
> -	priv->hw->phy->channels_supported[0] = 0x7FFF800;
> +	priv->hw->phy->supported.channels[0] = 0x7FFF800;
>  	priv->hw->flags = IEEE802154_HW_OMIT_CKSUM | IEEE802154_HW_AACK |
>  			  IEEE802154_HW_AFILT;
>  
> diff --git a/drivers/net/ieee802154/fakelb.c b/drivers/net/ieee802154/fakelb.c
> index dc2bfb6..91bbf03 100644
> --- a/drivers/net/ieee802154/fakelb.c
> +++ b/drivers/net/ieee802154/fakelb.c
> @@ -149,35 +149,35 @@ static int fakelb_add_one(struct device *dev, struct fakelb_priv *fake)
>  	priv->hw = hw;
>  
>  	/* 868 MHz BPSK	802.15.4-2003 */
> -	hw->phy->channels_supported[0] |= 1;
> +	hw->phy->supported.channels[0] |= 1;
>  	/* 915 MHz BPSK	802.15.4-2003 */
> -	hw->phy->channels_supported[0] |= 0x7fe;
> +	hw->phy->supported.channels[0] |= 0x7fe;
>  	/* 2.4 GHz O-QPSK 802.15.4-2003 */
> -	hw->phy->channels_supported[0] |= 0x7FFF800;
> +	hw->phy->supported.channels[0] |= 0x7FFF800;
>  	/* 868 MHz ASK 802.15.4-2006 */
> -	hw->phy->channels_supported[1] |= 1;
> +	hw->phy->supported.channels[1] |= 1;
>  	/* 915 MHz ASK 802.15.4-2006 */
> -	hw->phy->channels_supported[1] |= 0x7fe;
> +	hw->phy->supported.channels[1] |= 0x7fe;
>  	/* 868 MHz O-QPSK 802.15.4-2006 */
> -	hw->phy->channels_supported[2] |= 1;
> +	hw->phy->supported.channels[2] |= 1;
>  	/* 915 MHz O-QPSK 802.15.4-2006 */
> -	hw->phy->channels_supported[2] |= 0x7fe;
> +	hw->phy->supported.channels[2] |= 0x7fe;
>  	/* 2.4 GHz CSS 802.15.4a-2007 */
> -	hw->phy->channels_supported[3] |= 0x3fff;
> +	hw->phy->supported.channels[3] |= 0x3fff;
>  	/* UWB Sub-gigahertz 802.15.4a-2007 */
> -	hw->phy->channels_supported[4] |= 1;
> +	hw->phy->supported.channels[4] |= 1;
>  	/* UWB Low band 802.15.4a-2007 */
> -	hw->phy->channels_supported[4] |= 0x1e;
> +	hw->phy->supported.channels[4] |= 0x1e;
>  	/* UWB High band 802.15.4a-2007 */
> -	hw->phy->channels_supported[4] |= 0xffe0;
> +	hw->phy->supported.channels[4] |= 0xffe0;
>  	/* 750 MHz O-QPSK 802.15.4c-2009 */
> -	hw->phy->channels_supported[5] |= 0xf;
> +	hw->phy->supported.channels[5] |= 0xf;
>  	/* 750 MHz MPSK 802.15.4c-2009 */
> -	hw->phy->channels_supported[5] |= 0xf0;
> +	hw->phy->supported.channels[5] |= 0xf0;
>  	/* 950 MHz BPSK 802.15.4d-2009 */
> -	hw->phy->channels_supported[6] |= 0x3ff;
> +	hw->phy->supported.channels[6] |= 0x3ff;
>  	/* 950 MHz GFSK 802.15.4d-2009 */
> -	hw->phy->channels_supported[6] |= 0x3ffc00;
> +	hw->phy->supported.channels[6] |= 0x3ffc00;
>  
>  	INIT_LIST_HEAD(&priv->list);
>  	priv->fake = fake;
> diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
> index fba2dfd..f2a1bd1 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -750,7 +750,7 @@ static int mrf24j40_probe(struct spi_device *spi)
>  
>  	devrec->hw->priv = devrec;
>  	devrec->hw->parent = &devrec->spi->dev;
> -	devrec->hw->phy->channels_supported[0] = CHANNEL_MASK;
> +	devrec->hw->phy->supported.channels[0] = CHANNEL_MASK;
>  	devrec->hw->flags = IEEE802154_HW_OMIT_CKSUM | IEEE802154_HW_AACK |
>  			    IEEE802154_HW_AFILT;
>  
> diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
> index eeda676..c4d42ad 100644
> --- a/include/net/cfg802154.h
> +++ b/include/net/cfg802154.h
> @@ -59,6 +59,10 @@ struct cfg802154_ops {
>  				struct wpan_dev *wpan_dev, bool mode);
>  };
>  
> +struct wpan_phy_supported {
> +	u32 channels[IEEE802154_MAX_PAGE + 1];
> +};
> +
>  struct wpan_phy_cca {
>  	enum nl802154_cca_modes mode;
>  	enum nl802154_cca_opts opt;
> @@ -82,7 +86,7 @@ struct wpan_phy {
>  	 */
>  	u8 current_channel;
>  	u8 current_page;
> -	u32 channels_supported[IEEE802154_MAX_PAGE + 1];
> +	struct wpan_phy_supported supported;
>  	s8 transmit_power;
>  	struct wpan_phy_cca cca;
>  
> diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
> index 1b9d25f6..b6826cf 100644
> --- a/net/ieee802154/nl-phy.c
> +++ b/net/ieee802154/nl-phy.c
> @@ -56,8 +56,8 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 portid,
>  	    nla_put_u8(msg, IEEE802154_ATTR_CHANNEL, phy->current_channel))
>  		goto nla_put_failure;
>  	for (i = 0; i < 32; i++) {
> -		if (phy->channels_supported[i])
> -			buf[pages++] = phy->channels_supported[i] | (i << 27);
> +		if (phy->supported.channels[i])
> +			buf[pages++] = phy->supported.channels[i] | (i << 27);
>  	}
>  	if (pages &&
>  	    nla_put(msg, IEEE802154_ATTR_CHANNEL_PAGE_LIST,
> diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> index a4daf91..4172e21 100644
> --- a/net/ieee802154/nl802154.c
> +++ b/net/ieee802154/nl802154.c
> @@ -248,7 +248,7 @@ nl802154_send_wpan_phy_channels(struct cfg802154_registered_device *rdev,
>  
>  	for (page = 0; page <= IEEE802154_MAX_PAGE; page++) {
>  		if (nla_put_u32(msg, NL802154_ATTR_SUPPORTED_CHANNEL,
> -				rdev->wpan_phy.channels_supported[page]))
> +				rdev->wpan_phy.supported.channels[page]))
>  			return -ENOBUFS;
>  	}
>  	nla_nest_end(msg, nl_page);
> diff --git a/net/mac802154/cfg.c b/net/mac802154/cfg.c
> index 5d9f68c..191143a 100644
> --- a/net/mac802154/cfg.c
> +++ b/net/mac802154/cfg.c
> @@ -71,7 +71,7 @@ ieee802154_set_channel(struct wpan_phy *wpan_phy, u8 page, u8 channel)
>  	ASSERT_RTNL();
>  
>  	/* check if phy support this setting */
> -	if (!(wpan_phy->channels_supported[page] & BIT(channel)))
> +	if (!(wpan_phy->supported.channels[page] & BIT(channel)))
>  		return -EINVAL;
>  
>  	ret = drv_set_channel(local, page, channel);

This patch looks fine to me. 

For cc2520 change: Acked-by: Varka Bhadram <varkabhadram@gmail.com> 


-- 
Varka Bhadram

[RFC bluetooth-next 2/4] ieee802154: move channels supported out of softmac

[Alexander Aring]

This patch moves the check on channels_supported out of softmac
implementation. We can and should do that earlier in nl802154
implementation.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
 net/ieee802154/nl802154.c | 4 ++++
 net/mac802154/cfg.c       | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 4172e21..4ea64ef 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -628,6 +628,10 @@ static int nl802154_set_channel(struct sk_buff *skb, struct genl_info *info)
 	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL)
 		return -EINVAL;
 
+	/* check if phy support this setting */
+	if (!(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
+		return -EINVAL;
+
 	return rdev_set_channel(rdev, page, channel);
 }
 
diff --git a/net/mac802154/cfg.c b/net/mac802154/cfg.c
index 191143a..d8bb593 100644
--- a/net/mac802154/cfg.c
+++ b/net/mac802154/cfg.c
@@ -70,10 +70,6 @@ ieee802154_set_channel(struct wpan_phy *wpan_phy, u8 page, u8 channel)
 
 	ASSERT_RTNL();
 
-	/* check if phy support this setting */
-	if (!(wpan_phy->supported.channels[page] & BIT(channel)))
-		return -EINVAL;
-
 	ret = drv_set_channel(local, page, channel);
 	if (!ret) {
 		wpan_phy->current_page = page;
-- 
2.3.5

[RFC bluetooth-next 3/4] ieee802154: add several phy supported handling

[Alexander Aring]

This patch adds support for phy supported handling for all other already
existing handling 802.15.4 functionality. We assume now a fully 802.15.4
complaint transceiver at phy allocation. If a transceiver can support
802.15.4 default values only, then the values should be overwirtten by
values the transceiver supports.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Suggested-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
---
 include/net/cfg802154.h   |  5 +++++
 net/ieee802154/nl802154.c | 31 +++++++++++++++++++++----------
 net/mac802154/main.c      | 10 ++++++++++
 3 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index c4d42ad..c9d09b1 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -61,6 +61,11 @@ struct cfg802154_ops {
 
 struct wpan_phy_supported {
 	u32 channels[IEEE802154_MAX_PAGE + 1];
+	u8 cca_modes, cca_opts;
+	u8 min_minbe, max_minbe, min_maxbe, max_maxbe;
+	s8 min_frame_retries, max_frame_retries;
+	u8 min_csma_backoffs, max_csma_backoffs;
+	bool lbt;
 };
 
 struct wpan_phy_cca {
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 4ea64ef..7e3b2cc 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -625,11 +625,8 @@ static int nl802154_set_channel(struct sk_buff *skb, struct genl_info *info)
 	channel = nla_get_u8(info->attrs[NL802154_ATTR_CHANNEL]);
 
 	/* check 802.15.4 constraints */
-	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL)
-		return -EINVAL;
-
-	/* check if phy support this setting */
-	if (!(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
+	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL ||
+	    !(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
 		return -EINVAL;
 
 	return rdev_set_channel(rdev, page, channel);
@@ -645,7 +642,9 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
 
 	cca.mode = nla_get_u32(info->attrs[NL802154_ATTR_CCA_MODE]);
 	/* checking 802.15.4 constraints */
-	if (cca.mode < NL802154_CCA_ENERGY || cca.mode > NL802154_CCA_ATTR_MAX)
+	if (cca.mode < NL802154_CCA_ENERGY ||
+	    cca.mode > NL802154_CCA_ATTR_MAX ||
+	    !(rdev->wpan_phy.supported.cca_modes & BIT(cca.mode)))
 		return -EINVAL;
 
 	if (cca.mode == NL802154_CCA_ENERGY_CARRIER) {
@@ -653,7 +652,8 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
 			return -EINVAL;
 
 		cca.opt = nla_get_u32(info->attrs[NL802154_ATTR_CCA_OPT]);
-		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX)
+		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX ||
+		    !(rdev->wpan_phy.supported.cca_opts & BIT(cca.opt)))
 			return -EINVAL;
 	}
 
@@ -726,7 +726,11 @@ nl802154_set_backoff_exponent(struct sk_buff *skb, struct genl_info *info)
 	max_be = nla_get_u8(info->attrs[NL802154_ATTR_MAX_BE]);
 
 	/* check 802.15.4 constraints */
-	if (max_be < 3 || max_be > 8 || min_be > max_be)
+	if (max_be < 3 || max_be > 8 || min_be > max_be ||
+	    min_be < rdev->wpan_phy.supported.min_minbe ||
+	    min_be > rdev->wpan_phy.supported.max_minbe ||
+	    max_be < rdev->wpan_phy.supported.min_maxbe ||
+	    max_be > rdev->wpan_phy.supported.max_maxbe)
 		return -EINVAL;
 
 	return rdev_set_backoff_exponent(rdev, wpan_dev, min_be, max_be);
@@ -751,7 +755,9 @@ nl802154_set_max_csma_backoffs(struct sk_buff *skb, struct genl_info *info)
 			info->attrs[NL802154_ATTR_MAX_CSMA_BACKOFFS]);
 
 	/* check 802.15.4 constraints */
-	if (max_csma_backoffs > 5)
+	if (max_csma_backoffs > 5 ||
+	    max_csma_backoffs < rdev->wpan_phy.supported.min_csma_backoffs ||
+	    max_csma_backoffs > rdev->wpan_phy.supported.max_csma_backoffs)
 		return -EINVAL;
 
 	return rdev_set_max_csma_backoffs(rdev, wpan_dev, max_csma_backoffs);
@@ -775,7 +781,9 @@ nl802154_set_max_frame_retries(struct sk_buff *skb, struct genl_info *info)
 			info->attrs[NL802154_ATTR_MAX_FRAME_RETRIES]);
 
 	/* check 802.15.4 constraints */
-	if (max_frame_retries < -1 || max_frame_retries > 7)
+	if (max_frame_retries < -1 || max_frame_retries > 7 ||
+	    max_frame_retries < rdev->wpan_phy.supported.min_frame_retries ||
+	    max_frame_retries > rdev->wpan_phy.supported.max_frame_retries)
 		return -EINVAL;
 
 	return rdev_set_max_frame_retries(rdev, wpan_dev, max_frame_retries);
@@ -795,6 +803,9 @@ static int nl802154_set_lbt_mode(struct sk_buff *skb, struct genl_info *info)
 		return -EINVAL;
 
 	mode = !!nla_get_u8(info->attrs[NL802154_ATTR_LBT_MODE]);
+	if (mode && !rdev->wpan_phy.supported.lbt)
+		return -ENOTSUPP;
+
 	return rdev_set_lbt_mode(rdev, wpan_dev, mode);
 }
 
diff --git a/net/mac802154/main.c b/net/mac802154/main.c
index 8500378..a92eb5f 100644
--- a/net/mac802154/main.c
+++ b/net/mac802154/main.c
@@ -107,6 +107,16 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops)
 
 	skb_queue_head_init(&local->skb_queue);
 
+	/* init supported flags with 802.15.4 constraints */
+	phy->supported.max_minbe = 8;
+	phy->supported.min_maxbe = 3;
+	phy->supported.max_maxbe = 8;
+	phy->supported.min_frame_retries = -1;
+	phy->supported.max_frame_retries = 7;
+	phy->supported.max_csma_backoffs = 5;
+	phy->supported.cca_modes = 0xFF;
+	phy->supported.cca_opts = 0xFF;
+
 	return &local->hw;
 }
 EXPORT_SYMBOL(ieee802154_alloc_hw);
-- 
2.3.5

Re: [RFC bluetooth-next 3/4] ieee802154: add several phy supported handling

[Alexander Aring]

Hi,

On Wed, Apr 08, 2015 at 01:18:31PM +0200, Alexander Aring wrote:
> This patch adds support for phy supported handling for all other already
> existing handling 802.15.4 functionality. We assume now a fully 802.15.4
> complaint transceiver at phy allocation. If a transceiver can support
> 802.15.4 default values only, then the values should be overwirtten by
> values the transceiver supports.
> 
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> Suggested-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
> ---
>  include/net/cfg802154.h   |  5 +++++
>  net/ieee802154/nl802154.c | 31 +++++++++++++++++++++----------
>  net/mac802154/main.c      | 10 ++++++++++
>  3 files changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
> index c4d42ad..c9d09b1 100644
> --- a/include/net/cfg802154.h
> +++ b/include/net/cfg802154.h
> @@ -61,6 +61,11 @@ struct cfg802154_ops {
>  
>  struct wpan_phy_supported {
>  	u32 channels[IEEE802154_MAX_PAGE + 1];
> +	u8 cca_modes, cca_opts;
> +	u8 min_minbe, max_minbe, min_maxbe, max_maxbe;
> +	s8 min_frame_retries, max_frame_retries;
> +	u8 min_csma_backoffs, max_csma_backoffs;
> +	bool lbt;
>  };
>  
>  struct wpan_phy_cca {
> diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> index 4ea64ef..7e3b2cc 100644
> --- a/net/ieee802154/nl802154.c
> +++ b/net/ieee802154/nl802154.c
> @@ -625,11 +625,8 @@ static int nl802154_set_channel(struct sk_buff *skb, struct genl_info *info)
>  	channel = nla_get_u8(info->attrs[NL802154_ATTR_CHANNEL]);
>  
>  	/* check 802.15.4 constraints */
> -	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL)
> -		return -EINVAL;
> -
> -	/* check if phy support this setting */
> -	if (!(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
> +	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL ||
> +	    !(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
>  		return -EINVAL;
>  

better I do this cleanup in the previous patch, which moves this check
out of SoftMAC layer.

>  	return rdev_set_channel(rdev, page, channel);
> @@ -645,7 +642,9 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
>  
>  	cca.mode = nla_get_u32(info->attrs[NL802154_ATTR_CCA_MODE]);
>  	/* checking 802.15.4 constraints */
> -	if (cca.mode < NL802154_CCA_ENERGY || cca.mode > NL802154_CCA_ATTR_MAX)
> +	if (cca.mode < NL802154_CCA_ENERGY ||
> +	    cca.mode > NL802154_CCA_ATTR_MAX ||
> +	    !(rdev->wpan_phy.supported.cca_modes & BIT(cca.mode)))
>  		return -EINVAL;
>  
>  	if (cca.mode == NL802154_CCA_ENERGY_CARRIER) {
> @@ -653,7 +652,8 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
>  			return -EINVAL;
>  
>  		cca.opt = nla_get_u32(info->attrs[NL802154_ATTR_CCA_OPT]);
> -		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX)
> +		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX ||
> +		    !(rdev->wpan_phy.supported.cca_opts & BIT(cca.opt)))
>  			return -EINVAL;
>  	}
>  
> @@ -726,7 +726,11 @@ nl802154_set_backoff_exponent(struct sk_buff *skb, struct genl_info *info)
>  	max_be = nla_get_u8(info->attrs[NL802154_ATTR_MAX_BE]);
>  
>  	/* check 802.15.4 constraints */

remove the comment here, it's not anymore just 802.15.4. It's what the
phy supports.

> -	if (max_be < 3 || max_be > 8 || min_be > max_be)
> +	if (max_be < 3 || max_be > 8 || min_be > max_be ||

I will remove the "max_be < 3 || max_be > 8" it's not required here that
we have some "valid 802.15.4 range here" this should be replaced by
handle with:

max_be < rdev->wpan_phy.supported.min_maxbe ||
max_be > rdev->wpan_phy.supported.max_maxbe...

It could be that a driver set the supported values outside of 802.15.4
but this is then a bug inside the driver. For running transceivers out
of spec, we should introduce _maybe_ some vendor specific nl802154
command. If somebody wants to do that.

> +	    min_be < rdev->wpan_phy.supported.min_minbe ||
> +	    min_be > rdev->wpan_phy.supported.max_minbe ||
> +	    max_be < rdev->wpan_phy.supported.min_maxbe ||
> +	    max_be > rdev->wpan_phy.supported.max_maxbe)
>  		return -EINVAL;
>  
>  	return rdev_set_backoff_exponent(rdev, wpan_dev, min_be, max_be);
> @@ -751,7 +755,9 @@ nl802154_set_max_csma_backoffs(struct sk_buff *skb, struct genl_info *info)
>  			info->attrs[NL802154_ATTR_MAX_CSMA_BACKOFFS]);
>  
>  	/* check 802.15.4 constraints */
> -	if (max_csma_backoffs > 5)
> +	if (max_csma_backoffs > 5 ||

same here.

> +	    max_csma_backoffs < rdev->wpan_phy.supported.min_csma_backoffs ||
> +	    max_csma_backoffs > rdev->wpan_phy.supported.max_csma_backoffs)
>  		return -EINVAL;
>  
>  	return rdev_set_max_csma_backoffs(rdev, wpan_dev, max_csma_backoffs);
> @@ -775,7 +781,9 @@ nl802154_set_max_frame_retries(struct sk_buff *skb, struct genl_info *info)
>  			info->attrs[NL802154_ATTR_MAX_FRAME_RETRIES]);
>  
>  	/* check 802.15.4 constraints */
> -	if (max_frame_retries < -1 || max_frame_retries > 7)
> +	if (max_frame_retries < -1 || max_frame_retries > 7 ||

here, too.

> +	    max_frame_retries < rdev->wpan_phy.supported.min_frame_retries ||
> +	    max_frame_retries > rdev->wpan_phy.supported.max_frame_retries)
>  		return -EINVAL;
>  
>  	return rdev_set_max_frame_retries(rdev, wpan_dev, max_frame_retries);
> @@ -795,6 +803,9 @@ static int nl802154_set_lbt_mode(struct sk_buff *skb, struct genl_info *info)
>  		return -EINVAL;
>  
>  	mode = !!nla_get_u8(info->attrs[NL802154_ATTR_LBT_MODE]);
> +	if (mode && !rdev->wpan_phy.supported.lbt)
> +		return -ENOTSUPP;
> +

I am still not sure about checking lbt mode. But I think it's different
between "check if the value is allowed" or "check if operation is
supported". With this patch a non lbt phy can set the lbt value to
false (which is allowed), but the SoftMAC layer will tell then "sorry,
operation not supported".

Maybe we should check in SoftMAC if the value is really changed before
and if not do nothing and remove the check on if the driver_ops supports
the operation. [0]

>  	return rdev_set_lbt_mode(rdev, wpan_dev, mode);
>  }
>  
> diff --git a/net/mac802154/main.c b/net/mac802154/main.c
> index 8500378..a92eb5f 100644
> --- a/net/mac802154/main.c
> +++ b/net/mac802154/main.c
> @@ -107,6 +107,16 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops)
>  
>  	skb_queue_head_init(&local->skb_queue);
>  
> +	/* init supported flags with 802.15.4 constraints */
> +	phy->supported.max_minbe = 8;
> +	phy->supported.min_maxbe = 3;
> +	phy->supported.max_maxbe = 8;
> +	phy->supported.min_frame_retries = -1;
> +	phy->supported.max_frame_retries = 7;
> +	phy->supported.max_csma_backoffs = 5;
> +	phy->supported.cca_modes = 0xFF;
> +	phy->supported.cca_opts = 0xFF;

ehm, yes I will better use the real full possible bitmask here for
cca_modes and cca_opts.

- Alex

[0] http://lxr.free-electrons.com/source/net/mac802154/cfg.c#L191

Re: [RFC bluetooth-next 3/4] ieee802154: add several phy supported handling

[Alexander Aring]

On Thu, Apr 09, 2015 at 11:52:42AM +0530, Varka Bhadram wrote:
> On 04/08/2015 04:48 PM, Alexander Aring wrote:
> > This patch adds support for phy supported handling for all other already
> > existing handling 802.15.4 functionality. We assume now a fully 802.15.4
> > complaint transceiver at phy allocation. If a transceiver can support
> > 802.15.4 default values only, then the values should be overwirtten by
> > values the transceiver supports.
> >
> > Signed-off-by: Alexander Aring <alex.aring@gmail.com> <mailto:alex.aring@gmail.com>
> > Suggested-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> <mailto:phoebe.buckheister@itwm.fraunhofer.de>
> > ---
> >  include/net/cfg802154.h   |  5 +++++
> >  net/ieee802154/nl802154.c | 31 +++++++++++++++++++++----------
> >  net/mac802154/main.c      | 10 ++++++++++
> >  3 files changed, 36 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
> > index c4d42ad..c9d09b1 100644
> > --- a/include/net/cfg802154.h
> > +++ b/include/net/cfg802154.h
> > @@ -61,6 +61,11 @@ struct cfg802154_ops {
> >  
> >  struct wpan_phy_supported {
> >  	u32 channels[IEEE802154_MAX_PAGE + 1];
> > +	u8 cca_modes, cca_opts;
> > +	u8 min_minbe, max_minbe, min_maxbe, max_maxbe;
> > +	s8 min_frame_retries, max_frame_retries;
> > +	u8 min_csma_backoffs, max_csma_backoffs;
> > +	bool lbt;
> 
> Declare variables one after other in multiple lines... Not in single line. :-) 
> 

ok.

> >  };
> >  
> >  struct wpan_phy_cca {
> > diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> > index 4ea64ef..7e3b2cc 100644
> > --- a/net/ieee802154/nl802154.c
> > +++ b/net/ieee802154/nl802154.c
> > @@ -625,11 +625,8 @@ static int nl802154_set_channel(struct sk_buff *skb, struct genl_info *info)
> >  	channel = nla_get_u8(info->attrs[NL802154_ATTR_CHANNEL]);
> >  
> >  	/* check 802.15.4 constraints */
> > -	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL)
> > -		return -EINVAL;
> > -
> > -	/* check if phy support this setting */
> > -	if (!(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
> > +	if (page > IEEE802154_MAX_PAGE || channel > IEEE802154_MAX_CHANNEL ||
> > +	    !(rdev->wpan_phy.supported.channels[page] & BIT(channel)))
> >  		return -EINVAL;
> >  
> >  	return rdev_set_channel(rdev, page, channel);
> > @@ -645,7 +642,9 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
> >  
> >  	cca.mode = nla_get_u32(info->attrs[NL802154_ATTR_CCA_MODE]);
> >  	/* checking 802.15.4 constraints */
> > -	if (cca.mode < NL802154_CCA_ENERGY || cca.mode > NL802154_CCA_ATTR_MAX)
> > +	if (cca.mode < NL802154_CCA_ENERGY ||
> > +	    cca.mode > NL802154_CCA_ATTR_MAX ||
> > +	    !(rdev->wpan_phy.supported.cca_modes & BIT(cca.mode)))
> >  		return -EINVAL;
> >  
> >  	if (cca.mode == NL802154_CCA_ENERGY_CARRIER) {
> > @@ -653,7 +652,8 @@ static int nl802154_set_cca_mode(struct sk_buff *skb, struct genl_info *info)
> >  			return -EINVAL;
> >  
> >  		cca.opt = nla_get_u32(info->attrs[NL802154_ATTR_CCA_OPT]);
> > -		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX)
> > +		if (cca.opt > NL802154_CCA_OPT_ATTR_MAX ||
> > +		    !(rdev->wpan_phy.supported.cca_opts & BIT(cca.opt)))
> >  			return -EINVAL;
> >  	}
> >  
> > @@ -726,7 +726,11 @@ nl802154_set_backoff_exponent(struct sk_buff *skb, struct genl_info *info)
> >  	max_be = nla_get_u8(info->attrs[NL802154_ATTR_MAX_BE]);
> >  
> >  	/* check 802.15.4 constraints */
> > -	if (max_be < 3 || max_be > 8 || min_be > max_be)
> > +	if (max_be < 3 || max_be > 8 || min_be > max_be ||
> > +	    min_be < rdev->wpan_phy.supported.min_minbe ||
> > +	    min_be > rdev->wpan_phy.supported.max_minbe ||
> > +	    max_be < rdev->wpan_phy.supported.min_maxbe ||
> > +	    max_be > rdev->wpan_phy.supported.max_maxbe)
> >  		return -EINVAL;
> >  
> >  	return rdev_set_backoff_exponent(rdev, wpan_dev, min_be, max_be);
> > @@ -751,7 +755,9 @@ nl802154_set_max_csma_backoffs(struct sk_buff *skb, struct genl_info *info)
> >  			info->attrs[NL802154_ATTR_MAX_CSMA_BACKOFFS]);
> >  
> >  	/* check 802.15.4 constraints */
> > -	if (max_csma_backoffs > 5)
> > +	if (max_csma_backoffs > 5 ||
> > +	    max_csma_backoffs < rdev->wpan_phy.supported.min_csma_backoffs ||
> > +	    max_csma_backoffs > rdev->wpan_phy.supported.max_csma_backoffs)
> >  		return -EINVAL;
> >  
> >  	return rdev_set_max_csma_backoffs(rdev, wpan_dev, max_csma_backoffs);
> > @@ -775,7 +781,9 @@ nl802154_set_max_frame_retries(struct sk_buff *skb, struct genl_info *info)
> >  			info->attrs[NL802154_ATTR_MAX_FRAME_RETRIES]);
> >  
> >  	/* check 802.15.4 constraints */
> > -	if (max_frame_retries < -1 || max_frame_retries > 7)
> > +	if (max_frame_retries < -1 || max_frame_retries > 7 ||
> > +	    max_frame_retries < rdev->wpan_phy.supported.min_frame_retries ||
> > +	    max_frame_retries > rdev->wpan_phy.supported.max_frame_retries)
> >  		return -EINVAL;
> >  
> >  	return rdev_set_max_frame_retries(rdev, wpan_dev, max_frame_retries);
> > @@ -795,6 +803,9 @@ static int nl802154_set_lbt_mode(struct sk_buff *skb, struct genl_info *info)
> >  		return -EINVAL;
> >  
> >  	mode = !!nla_get_u8(info->attrs[NL802154_ATTR_LBT_MODE]);
> > +	if (mode && !rdev->wpan_phy.supported.lbt)
> > +		return -ENOTSUPP;
> > +
> >  	return rdev_set_lbt_mode(rdev, wpan_dev, mode);
> >  }
> >  
> > diff --git a/net/mac802154/main.c b/net/mac802154/main.c
> > index 8500378..a92eb5f 100644
> > --- a/net/mac802154/main.c
> > +++ b/net/mac802154/main.c
> > @@ -107,6 +107,16 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops)
> >  
> >  	skb_queue_head_init(&local->skb_queue);
> >  
> > +	/* init supported flags with 802.15.4 constraints */
> > +	phy->supported.max_minbe = 8;
> > +	phy->supported.min_maxbe = 3;
> > +	phy->supported.max_maxbe = 8;
> > +	phy->supported.min_frame_retries = -1;
> > +	phy->supported.max_frame_retries = 7;
> > +	phy->supported.max_csma_backoffs = 5;
> > +	phy->supported.cca_modes = 0xFF;
> > +	phy->supported.cca_opts = 0xFF;
> > +
> >  	return &local->hw;
> >  }
> >  EXPORT_SYMBOL(ieee802154_alloc_hw);
> 
> The question is what transceivers will support all above functionalities..?
> 

This values are all provided by 802.15.4, per default we assume that the
transceiver is fully 802.15.4 complaint and we can change these values. If
not, then the transceiver driver need to overwrite them.

In case of mrf24j40 it only supports the min_be setting. (What I
mentioned in another mail). I suppose that max_be is always be 802.15.4
default. So the driver normally need to set:

phy->supported.min_maxbe = 5;
phy->supported.max_maxbe = 5;

The transceiver can't be working without these configuration (expect the
transceiver doesn't support ARET handling).

We get into trouble on a interface up, when the transceiver doesn't support
802.15.4 default values (because we init our mib with these values).
But I don't think that there are transceivers outside which doesn't
support the 802.15.4 defaults. That also means that every transceiver
supports ARET handling.

What I saw outside of the transceivers world is that not every
transceiver supports every 802.15.4 complaint values, like mrf24j40 for
the max_be value, but at least 802.15.4 defaults.

So we should support "less than 802.15.4 functionality" but not "more
than 802.15.4 functionality". To support more than 802.15.4 I think I
will introduce some vendor nl802154 cmd, it's risky to use values beyond
802.15.4 functionality otherwise others transceivers can run into
troubles.

For cc2520:

I saw none of min_be/max_be setting, to be sure that these values are
default 802.15.4 values (which I suppose) you need to ask ti support.

You need to do something like this:

phy->supported.min_minbe = 3;
phy->supported.max_minbe = 3;
phy->supported.min_maxbe = 5;
phy->supported.max_maxbe = 5;

And add a dummy driver callback. (Maybe we can introduce some dummy
function which can be use by all drivers, if they don't allow to changed
these values).


First look into the datasheet is that it supports ARET and no ARET handling.
This looks much more complicated [0] on page 69. For max_frame_retries
== -1 then it should be the path which describes "No CSMA-CA" and
max_frame_retries => 0 should be the "unslotted csma-ca" mode. Then you
need to do kind of magic with "To retransmit the same frame again, simply
restart TX by issuing a STXON or STXONCCA command strobe." -> see page
68.

For the cca modes it looks like some ENERGY ABOVE THRESHOLD (I would ask
here also the ti support) read page 120. I also advice to always
enable CCA (because the 802.15.4 doesn't describe anything about
CCA_MODE_NONE) otherwise your transceiver running out of spec.


Also for csma_backoffs exists no real configuration, ask ti and do the
same like min/max be. But page 69 describe some "random backoffs" how many
backoffs doesn't describe the datasheet, my guess is it 802.15.4 default
which is 4. And it's random, but we need to know the "max" random
number, but this information isn't shown in the datasheet.

- Alex

[0] http://www.ti.com/lit/ds/symlink/cc2520.pdf

[RFC bluetooth-next 4/4] at86rf230: set cca_modes supported flags

[Alexander Aring]

The at86rf2xx doesn't support every 802.15.4 cca mode. This patch
overwrites the default behaviour with values what the at86rf2xx
supports.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
 drivers/net/ieee802154/at86rf230.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 1e8c532..cfc4178 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1546,6 +1546,11 @@ at86rf230_detect_device(struct at86rf230_local *lp)
 			IEEE802154_HW_TXPOWER | IEEE802154_HW_ARET |
 			IEEE802154_HW_AFILT | IEEE802154_HW_PROMISCUOUS;
 
+	lp->hw->phy->supported.cca_modes = BIT(NL802154_CCA_ENERGY) |
+		BIT(NL802154_CCA_CARRIER) | BIT(NL802154_CCA_ENERGY_CARRIER);
+	lp->hw->phy->supported.cca_opts = BIT(NL802154_CCA_OPT_ENERGY_CARRIER_AND) |
+		BIT(NL802154_CCA_OPT_ENERGY_CARRIER_OR);
+
 	lp->hw->phy->cca.mode = NL802154_CCA_ENERGY;
 
 	switch (part) {
@@ -1568,6 +1573,7 @@ at86rf230_detect_device(struct at86rf230_local *lp)
 		lp->hw->phy->supported.channels[2] = 0x00007FF;
 		lp->hw->phy->current_channel = 5;
 		lp->hw->phy->symbol_duration = 25;
+		lp->hw->phy->supported.lbt = true;
 		break;
 	case 11:
 		chip = "at86rf233";
-- 
2.3.5

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

[Varka Bhadram]

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@itwm.fraunhofer.de>
> Cc: Varka Bhadram <varkabhadram@gmail.com>
>
> 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.

-- 
Thanks
Varka Bhadram

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

[Alexander Aring]

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@itwm.fraunhofer.de>
> > Cc: Varka Bhadram <varkabhadram@gmail.com>
> >
> > 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

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

[Varka Bhadram]

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@itwm.fraunhofer.de>
>>> Cc: Varka Bhadram <varkabhadram@gmail.com>
>>>
>>> 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..?

How mac80211 is managing this issue..?

-- 
Varka Bhadram

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

[Alexander Aring]

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@itwm.fraunhofer.de>
> >>> Cc: Varka Bhadram <varkabhadram@gmail.com>
> >>>
> >>> 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

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

[Alexander Aring]

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@itwm.fraunhofer.de>
> > >>> Cc: Varka Bhadram <varkabhadram@gmail.com>
> > >>>
> > >>> 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

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

[Varka Bhadram]

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@itwm.fraunhofer.de>
>>>>>> Cc: Varka Bhadram <varkabhadram@gmail.com>
>>>>>>
>>>>>> 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

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

[Alexander Aring]

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

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

[Guido Günther]

On Thu, Apr 09, 2015 at 11:28:21AM +0200, 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@itwm.fraunhofer.de>
> > > Cc: Varka Bhadram <varkabhadram@gmail.com>
> > >
> > > 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

This sounds like wireless-regdb[1] for 802.15.4. ?
Cheers,
 -- Guido

[1] https://wireless.wiki.kernel.org/en/developers/regulatory/wireless-regdb