You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by xi...@apache.org on 2022/06/27 03:30:59 UTC
[incubator-nuttx] branch master updated: Fix mistakes in comments and docs
This is an automated email from the ASF dual-hosted git repository.
xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new 6057960331 Fix mistakes in comments and docs
6057960331 is described below
commit 60579603311fc565fe60d8b0811947d217e1ae28
Author: Nathan Hartman <59...@users.noreply.github.com>
AuthorDate: Sun Jun 26 15:40:32 2022 -0400
Fix mistakes in comments and docs
* drivers/wireless/bluetooth/bt_null.c: Fix misleading comment
* drivers/wireless/spirit/Kconfig: Fix incorrect word (absolution).
* drivers/wireless/spirit/drivers/Kconfig: Fix wrong name (TMicro->STMicro)
* drivers/wireless/spirit/drivers/spirit_netdev.c: Fix wrong word
(verify->very).
* drivers/wireless/spirit/drivers/spirit_netdev.c: Fix double "the" and typo.
* include/nuttx/net/radiodev.h: Fix various typos and errors.
---
drivers/wireless/bluetooth/bt_null.c | 2 +-
drivers/wireless/spirit/Kconfig | 2 +-
drivers/wireless/spirit/drivers/Kconfig | 2 +-
drivers/wireless/spirit/drivers/spirit_netdev.c | 6 ++--
include/nuttx/net/radiodev.h | 41 ++++++++++++-------------
5 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/wireless/bluetooth/bt_null.c b/drivers/wireless/bluetooth/bt_null.c
index df8979613d..b3c49284f9 100644
--- a/drivers/wireless/bluetooth/bt_null.c
+++ b/drivers/wireless/bluetooth/bt_null.c
@@ -18,7 +18,7 @@
*
****************************************************************************/
-/* UART based Bluetooth driver */
+/* NULL (do-nothing) Bluetooth driver */
/****************************************************************************
* Included Files
diff --git a/drivers/wireless/spirit/Kconfig b/drivers/wireless/spirit/Kconfig
index ee17c488d0..6a33766d6d 100644
--- a/drivers/wireless/spirit/Kconfig
+++ b/drivers/wireless/spirit/Kconfig
@@ -18,7 +18,7 @@ config WL_SPIRIT_SPIFREQUENCY
default 10000000
---help---
Frequency at which to operate the SPI interface to the Spirit part.
- The default is the absolution maximum and you may likely have to
+ The default is the absolute maximum and you may likely have to
reduce this for your board.
config WL_SPIRIT_REGDEBUG
diff --git a/drivers/wireless/spirit/drivers/Kconfig b/drivers/wireless/spirit/drivers/Kconfig
index aebca03446..e99aa8342e 100644
--- a/drivers/wireless/spirit/drivers/Kconfig
+++ b/drivers/wireless/spirit/drivers/Kconfig
@@ -9,7 +9,7 @@ config SPIRIT_NETDEV
select WL_SPIRIT
select ARCH_HAVE_NETDEV_STATISTICS
---help---
- This selection enables support for the TMicro Spirit1-based device.
+ This selection enables support for the STMicro Spirit1-based device.
This configuration generates an IEEE802.15.4 work-alike radio device that
works with the 6LoWPAN stack.
diff --git a/drivers/wireless/spirit/drivers/spirit_netdev.c b/drivers/wireless/spirit/drivers/spirit_netdev.c
index 656ec1934a..3d0c7222af 100644
--- a/drivers/wireless/spirit/drivers/spirit_netdev.c
+++ b/drivers/wireless/spirit/drivers/spirit_netdev.c
@@ -33,7 +33,7 @@
* input of all frames into the network, (2) queuing of all output frames,
* and all network housekeeping such as periodic polling.
*
- * Interrupt handling is verify brief since it only schedules the interrupt
+ * Interrupt handling is very brief since it only schedules the interrupt
* work to occur on the HP work queue. Several things are done for the
* interrupt handling, but the primary things are: (1) receipt of incoming
* packets, and (2) handling of the completion of TX transfers.
@@ -81,9 +81,9 @@
* size
*
* Another consideration is the nature of the GPIO interrupts. For STM32,
- * for example, disabling the Spirit interrupt tears down the the entire
+ * for example, disabling the Spirit interrupt tears down the entire
* interrupt setup so, for example, any interrupts that are received while
- * interrupts are disable, aka torn down, will be lost. Hence, it may be
+ * interrupts are disabled, aka torn down, will be lost. Hence, it may be
* necessary to process pending interrupts whenever interrupts are re-
* enabled.
*/
diff --git a/include/nuttx/net/radiodev.h b/include/nuttx/net/radiodev.h
index 861d3a51f9..e1a52765f2 100644
--- a/include/nuttx/net/radiodev.h
+++ b/include/nuttx/net/radiodev.h
@@ -62,32 +62,31 @@ struct radiodev_properties_s
* The radio network driver does not use the d_buf packet buffer directly.
* Rather, it uses a list smaller frame buffers.
*
- * - Outgoing frame data is provided in an IOB in the via the
- * r_req_data() interface method each time that the radio needs to
- * send more data. The length of the frame is provided in the io_len
- * field of the IOB.
+ * - Outgoing frame data is provided in an IOB via the r_req_data()
+ * interface method each time that the radio needs to send more data.
+ * The length of the frame is provided in the io_len field of the IOB.
*
* Outgoing frames are generated when the radio network driver calls
* the devif_poll(), sixlowpan_input(), or ieee802154_input()
* interfaces. In each case, the radio driver must provide a working
* buffer in the d_buf pointer. A special form of the packet buffer
- * must be used, struct sixlowpan_reassbuf_s. This special for
+ * must be used, struct sixlowpan_reassbuf_s. This special form
* includes appended data for managing reassembly of packets.
*
* - Received frames are provided by radio network driver to the network
- * via an IOB parameter in the sixlowpan_input() pr ieee802154_input()
- * interface. The length of the frame is io_len.
+ * via an IOB parameter in the sixlowpan_input() or ieee802154_input()
+ * interfaces. The length of the frame is io_len.
*
* Again, the radio network driver must provide an instance of struct
* sixlowpan_reassbuf_s as the packet buffer in the d_buf field. This
- * driver-provided data will only be used if the the receive frames are
+ * driver-provided data will only be used if the receive frames are
* not fragmented.
*
- * - Received 6LoWPAN frames and will be uncompressed and possibly
- * reassembled in resassembled the d_buf; d_len will hold the size of
- * the reassembled packet.
+ * - Received 6LoWPAN frames will be uncompressed and possibly
+ * reassembled in the d_buf; d_len will hold the size of the
+ * reassembled packet.
*
- * For fagemented frames, d_buf provided by radio driver will not be
+ * For fragmented frames, d_buf provided by radio driver will not be
* used. 6LoWPAN must handle multiple reassemblies from different
* sources simultaneously. To support this, 6LoWPAN will allocate a
* unique reassembly buffer for each active reassembly, based on the
@@ -104,10 +103,10 @@ struct radiodev_properties_s
* structure. In general, all fields must be set to NULL. In addition:
*
* 1. On a TX poll, the radio network driver should provide its driver
- * structure along is (single) reassemby buffer provided at d_buf.
- * During the course of the poll, the networking layer may generate
- * outgoing frames. These frames will by provided to the radio network
- * driver via the req_data() method.
+ * structure along with its (single) reassembly buffer provided at
+ * d_buf. During the course of the poll, the networking layer may
+ * generate outgoing frames. These frames will by provided to the
+ * radio network driver via the req_data() method.
*
* After sending each frame through the radio, the MAC driver must
* return the frame to the pool of free IOBs using the iob_free().
@@ -128,7 +127,7 @@ struct radiodev_properties_s
* CONFIG_NET_6LOWPAN_PKTSIZE, plus CONFIG_NET_GUARDSIZE and some
* additional overhead for reassembly state data.
*
- * The radio network driver should then inform the network of the recipt
+ * The radio network driver should then inform the network of the receipt
* of a frame by calling sixlowpan_input() or ieee802154_input(). That
* single frame (or, perhaps, list of frames) should be provided as
* second argument of that call.
@@ -154,11 +153,11 @@ struct radio_driver_s
#ifdef CONFIG_WIRELESS_IEEE802154
/* The msdu_handle is basically an id for the frame. The standard just
* says that the next highest layer should determine it. It is used in
- * three places
+ * three places:
*
* 1. When you do that data request
* 2. When the transmission is complete, the conf_data is called with
- * that handle so that the user can be notified of the frames success/
+ * that handle so that the user can be notified of the frame's success/
* failure
* 3. For a req_purge, to basically "cancel" the transaction. This is
* often particularly useful on a coordinator that has indirect data
@@ -179,12 +178,12 @@ struct radio_driver_s
* Calculate the MAC header length given the frame meta-data.
*
* Input Parameters:
- * netdev - The networkd device that will mediate the MAC interface
+ * netdev - The network device that will mediate the MAC interface
* meta - Obfuscated metadata structure needed to recreate the
* radio MAC header
*
* Returned Value:
- * A non-negative MAC headeer length is returned on success; a negated
+ * A non-negative MAC header length is returned on success; a negated
* errno value is returned on any failure.
*
**************************************************************************/