Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-06-04 14:53:47 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Run codespell -w with the latest dictonary again

Browse Source 
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
This commit is contained in:
Xiang Xiao
2020-02-23 16:50:23 +08:00
committed by Abdelatif Guettouche
parent 55a7dfc9a7
commit cde88cabcc
1532 changed files with 3117 additions and 3117 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wireless/ieee802154/Kconfig
+2 -2
View File
@@ -110,7 +110,7 @@ config IEEE802154_MACDEV
if IEEE802154_MACDEV
config IEEE802154_MACDEV_RECVRPRIO
int "Priority of frame receiver registerd with the MAC layer"
int "Priority of frame receiver registered with the MAC layer"
default 0
---help---
When the MAC layer receives an incoming data frame, it passes the frame
@@ -141,7 +141,7 @@ config IEEE802154_NETDEV
if IEEE802154_NETDEV
config IEEE802154_NETDEV_RECVRPRIO
int "Priority of frame receiver registerd with the MAC layer"
int "Priority of frame receiver registered with the MAC layer"
default 1
---help---
When the MAC layer receives an incoming data frame, it passes the frame
wireless/ieee802154/ieee802154_primitive.c
+1 -1
View File
@@ -300,7 +300,7 @@ FAR struct ieee802154_primitive_s *ieee802154_primitive_allocate(void)
#endif
{
/* If we cannot a primitive structure from the free list, then we
* will have to allocate one from the kernal memory pool.
* will have to allocate one from the kernel memory pool.
*/
leave_critical_section(flags);
wireless/ieee802154/mac802154.h
+4 -4
View File
@@ -162,7 +162,7 @@ int mac802154_req_data(MACHANDLE mac,
* the struct mac802154_maccb_s->conf_purge callback.
*
* NOTE: The standard specifies that confirmation should be indicated via
* the asynchronous MLME-PURGE.confirm primitve. However, in our
* the asynchronous MLME-PURGE.confirm primitive. However, in our
* implementation we synchronously return the status from the request.
* Therefore, we merge the functionality of the MLME-PURGE.request and
* MLME-PURGE.confirm primitives together.
@@ -222,7 +222,7 @@ int mac802154_req_gts(MACHANDLE mac, FAR struct ieee802154_gts_req_s *req);
* that the MLME performs a reset operation.
*
* NOTE: The standard specifies that confirmation should be provided via
* via the asynchronous MLME-RESET.confirm primitve. However, in our
* via the asynchronous MLME-RESET.confirm primitive. However, in our
* implementation we synchronously return the value immediately. Therefore,
* we merge the functionality of the MLME-RESET.request and MLME-RESET.confirm
* primitives together.
@@ -274,7 +274,7 @@ int mac802154_req_scan(MACHANDLE mac, FAR struct ieee802154_scan_req_s *req);
* attribute.
*
* NOTE: The standard specifies that the attribute value should be returned
* via the asynchronous MLME-GET.confirm primitve. However, in our
* via the asynchronous MLME-GET.confirm primitive. However, in our
* implementation, we synchronously return the value immediately.Therefore, we
* merge the functionality of the MLME-GET.request and MLME-GET.confirm
* primitives together.
@@ -292,7 +292,7 @@ int mac802154_req_get(MACHANDLE mac, enum ieee802154_attr_e ,
* indicated MAC PIB attribute.
*
* NOTE: The standard specifies that confirmation should be indicated via
* the asynchronous MLME-SET.confirm primitve. However, in our implementation
* the asynchronous MLME-SET.confirm primitive. However, in our implementation
* we synchronously return the status from the request. Therefore, we do merge
* the functionality of the MLME-SET.request and MLME-SET.confirm primitives
* together.
wireless/ieee802154/mac802154_assoc.c
+2 -2
View File
@@ -237,7 +237,7 @@ int mac802154_req_associate(MACHANDLE mac,
txdesc->frametype = IEEE802154_FRAME_COMMAND;
txdesc->ackreq = true;
/* Save a copy of the destination addressing infromation into the tx
/* Save a copy of the destination addressing information into the tx
* descriptor. We only do this for commands to help with handling their
* progession.
*/
@@ -764,7 +764,7 @@ void mac802154_rx_assocresp(FAR struct ieee802154_privmac_s *priv,
*
* TODO: What is supposed to happen in this situation. Are we supposed
* to accept the request? Are we supposed to Disassociate with the
* network as a convienience to the PAN Coordinator. So that it does
* network as a convenience to the PAN Coordinator. So that it does
* not need to waste space holding our information?
*/
wireless/ieee802154/mac802154_device.c
+1 -1
View File
@@ -820,7 +820,7 @@ static int mac802154dev_rxframe(FAR struct mac802154_chardevice_s *dev,
* user-space
*
* Input Parameters:
* mac - Pointer to the mac layer struct to be registerd.
* mac - Pointer to the mac layer struct to be registered.
* minor - The device minor number. The IEEE802.15.4 MAC character device
* will be registered as /dev/ieeeN where N is the minor number
*
wireless/ieee802154/mac802154_getset.c
+2 -2
View File
@@ -67,7 +67,7 @@
* attribute.
*
* NOTE: The standard specifies that the attribute value should be returned
* via the asynchronous MLME-GET.confirm primitve. However, in our
* via the asynchronous MLME-GET.confirm primitive. However, in our
* implementation, we synchronously return the value immediately.Therefore, we
* merge the functionality of the MLME-GET.request and MLME-GET.confirm
* primitives together.
@@ -165,7 +165,7 @@ int mac802154_req_get(MACHANDLE mac, enum ieee802154_attr_e attr,
* indicated MAC PIB attribute.
*
* NOTE: The standard specifies that confirmation should be indicated via
* the asynchronous MLME-SET.confirm primitve. However, in our implementation
* the asynchronous MLME-SET.confirm primitive. However, in our implementation
* we synchronously return the status from the request. Therefore, we do merge
* the functionality of the MLME-SET.request and MLME-SET.confirm primitives
* together.
wireless/ieee802154/mac802154_loopback.c
+1 -1
View File
@@ -343,7 +343,7 @@ static int lo_loopback(FAR struct net_driver_s *dev)
IEEE802154_EADDRCOPY(ind.dest.eaddr, g_eaddr);
/* Loop while there framelist to be sent, i.e., while the freme list is not
* emtpy. Sending, of course, just means relaying back through the network
* empty. Sending, of course, just means relaying back through the network
* for this driver.
*/
wireless/ieee802154/mac802154_poll.c
+1 -1
View File
@@ -142,7 +142,7 @@ int mac802154_req_poll(MACHANDLE mac, FAR struct ieee802154_poll_req_s *req)
txdesc);
}
/* Save a copy of the destination addressing infromation into the tx descriptor.
/* Save a copy of the destination addressing information into the tx descriptor.
* We only do this for commands to help with handling their progession.
*/
wireless/ieee802154/mac802154_purge.c
+1 -1
View File
@@ -67,7 +67,7 @@
* the struct mac802154_maccb_s->conf_purge callback.
*
* NOTE: The standard specifies that confirmation should be indicated via
* the asynchronous MLME-PURGE.confirm primitve. However, in our
* the asynchronous MLME-PURGE.confirm primitive. However, in our
* implementation we synchronously return the status from the request.
* Therefore, we merge the functionality of the MLME-PURGE.request and
* MLME-PURGE.confirm primitives together.
wireless/ieee802154/mac802154_reset.c
+1 -1
View File
@@ -67,7 +67,7 @@
* that the MLME performs a reset operation.
*
* NOTE: The standard specifies that confirmation should be provided via
* via the asynchronous MLME-RESET.confirm primitve. However, in our
* via the asynchronous MLME-RESET.confirm primitive. However, in our
* implementation we synchronously return the value immediately. Therefore,
* we merge the functionality of the MLME-RESET.request and MLME-RESET.confirm
* primitives together.