diff mbox

doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs

Message ID 20171118155501.14148-1-starnight@g.ncu.edu.tw (mailing list archive)
State Accepted
Headers show

Commit Message

Jian-Hong Pan Nov. 18, 2017, 3:55 p.m. UTC
There are more functions and operations which must be used or implemented
in each IEEE 802.15.4 device driver, but are not mentioned in the Device
drivers API section of Documentation/networking/ieee802154.txt.  Therefore,
I want to fulfill the missed part into the documentation with this patch.

Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
---
 Documentation/networking/ieee802154.txt | 40 +++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

Comments

Alexander Aring Nov. 19, 2017, 4:19 p.m. UTC | #1
Hi,

On Sat, Nov 18, 2017 at 10:55 AM, Jian-Hong Pan <starnight@g.ncu.edu.tw> wrote:
> There are more functions and operations which must be used or implemented
> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
> drivers API section of Documentation/networking/ieee802154.txt.  Therefore,
> I want to fulfill the missed part into the documentation with this patch.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>

Acked-by: Alexander Aring <aring@mojatatu.com>

Thanks for doing this kind of job and blame for me that I didn't
update documentation...

xmit_complete is more a signal to say "frame transmission done", means
you can fill the hardware side frame buffer with new frames again.
It works together mit xmit_async, as xmit_sync (the old method) waits
until framebuffer fill is complete. It queues the work into workqueue
and people do "spi_sync" handling... but the ndo_xmit callback of
netdev works differently. It means "fill the frame into framebuffer
and start transmit" (in context of this callback) what "xmit_async" is
made for - not queue into workqueue (what xmit_sync) does.
Anyway I see problems when using subsystems e.g. traffic control which
assumes that at this time the frame is being to transmitted and not
queued somewhere else (in a software queue, e.g. workqueue).
People say to me, "spi_sync" "spi_async" - doesn't matter the spi
subsystem will do the same "things" afterwards, but then this is a bug
inside the spi subsystem to handle softirq context correctly.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jian-Hong Pan Nov. 20, 2017, 3:27 p.m. UTC | #2
Hi,

2017-11-20 0:19 GMT+08:00 Alexander Aring <aring@mojatatu.com>:
> Hi,
>
> On Sat, Nov 18, 2017 at 10:55 AM, Jian-Hong Pan <starnight@g.ncu.edu.tw> wrote:
>> There are more functions and operations which must be used or implemented
>> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
>> drivers API section of Documentation/networking/ieee802154.txt.  Therefore,
>> I want to fulfill the missed part into the documentation with this patch.
>>
>> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
>
> Acked-by: Alexander Aring <aring@mojatatu.com>
>
> Thanks for doing this kind of job and blame for me that I didn't
> update documentation...
>
> xmit_complete is more a signal to say "frame transmission done", means
> you can fill the hardware side frame buffer with new frames again.
> It works together mit xmit_async, as xmit_sync (the old method) waits
> until framebuffer fill is complete. It queues the work into workqueue
> and people do "spi_sync" handling... but the ndo_xmit callback of
> netdev works differently. It means "fill the frame into framebuffer
> and start transmit" (in context of this callback) what "xmit_async" is
> made for - not queue into workqueue (what xmit_sync) does.

Thanks for Alex's sharing.
And, Yes!  I was stuck here a while when I was developing the device driver.
I figured out what you mentioned after traced the code and the dumped error
message.

Jian-Hong, Pan

> Anyway I see problems when using subsystems e.g. traffic control which
> assumes that at this time the frame is being to transmitted and not
> queued somewhere else (in a software queue, e.g. workqueue).
> People say to me, "spi_sync" "spi_async" - doesn't matter the spi
> subsystem will do the same "things" afterwards, but then this is a bug
> inside the spi subsystem to handle softirq context correctly.
>
> - Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stefan Schmidt Nov. 29, 2017, 4:04 p.m. UTC | #3
Hello


On 11/18/2017 04:55 PM, Jian-Hong Pan wrote:
> There are more functions and operations which must be used or implemented
> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
> drivers API section of Documentation/networking/ieee802154.txt.  Therefore,
> I want to fulfill the missed part into the documentation with this patch.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> ---
>  Documentation/networking/ieee802154.txt | 40 +++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
> index 057e9fdbfac9..e74d8e1da0e2 100644
> --- a/Documentation/networking/ieee802154.txt
> +++ b/Documentation/networking/ieee802154.txt
> @@ -97,6 +97,46 @@ The include/net/mac802154.h defines following functions:
>   - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
>     freeing registered PHY
>  
> + - void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
> +                              u8 lqi):
> +   telling 802.15.4 module there is a new received frame in the skb with
> +   the RF Link Quality Indicator (LQI) from the hardware device
> +
> + - void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
> +                                 bool ifs_handling):
> +   telling 802.15.4 module the frame in the skb is or going to be
> +   transmitted through the hardware device
> +
> +The device driver must implement the following callbacks in the IEEE 802.15.4
> +operations structure at least:
> +struct ieee802154_ops {
> +	...
> +	int	(*start)(struct ieee802154_hw *hw);
> +	void	(*stop)(struct ieee802154_hw *hw);
> +	...
> +	int	(*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
> +	int	(*ed)(struct ieee802154_hw *hw, u8 *level);
> +	int	(*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
> +	...
> +};
> +
> + - int start(struct ieee802154_hw *hw):
> +   handler that 802.15.4 module calls for the hardware device initialization.
> +
> + - void stop(struct ieee802154_hw *hw):
> +   handler that 802.15.4 module calls for the hardware device cleanup.
> +
> + - int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
> +   handler that 802.15.4 module calls for each frame in the skb going to be
> +   transmitted through the hardware device.
> +
> + - int ed(struct ieee802154_hw *hw, u8 *level):
> +   handler that 802.15.4 module calls for Energy Detection from the hardware
> +   device.
> +
> + - int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
> +   set radio for listening on specific channel of the hardware device.
> +
>  Moreover IEEE 802.15.4 device operations structure should be filled.
>  
>  Fake drivers

This patch has been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

regards
Stefan Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 057e9fdbfac9..e74d8e1da0e2 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -97,6 +97,46 @@  The include/net/mac802154.h defines following functions:
  - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
    freeing registered PHY
 
+ - void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
+                              u8 lqi):
+   telling 802.15.4 module there is a new received frame in the skb with
+   the RF Link Quality Indicator (LQI) from the hardware device
+
+ - void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
+                                 bool ifs_handling):
+   telling 802.15.4 module the frame in the skb is or going to be
+   transmitted through the hardware device
+
+The device driver must implement the following callbacks in the IEEE 802.15.4
+operations structure at least:
+struct ieee802154_ops {
+	...
+	int	(*start)(struct ieee802154_hw *hw);
+	void	(*stop)(struct ieee802154_hw *hw);
+	...
+	int	(*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
+	int	(*ed)(struct ieee802154_hw *hw, u8 *level);
+	int	(*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
+	...
+};
+
+ - int start(struct ieee802154_hw *hw):
+   handler that 802.15.4 module calls for the hardware device initialization.
+
+ - void stop(struct ieee802154_hw *hw):
+   handler that 802.15.4 module calls for the hardware device cleanup.
+
+ - int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
+   handler that 802.15.4 module calls for each frame in the skb going to be
+   transmitted through the hardware device.
+
+ - int ed(struct ieee802154_hw *hw, u8 *level):
+   handler that 802.15.4 module calls for Energy Detection from the hardware
+   device.
+
+ - int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
+   set radio for listening on specific channel of the hardware device.
+
 Moreover IEEE 802.15.4 device operations structure should be filled.
 
 Fake drivers