zephyr

Commit Graph

Author	SHA1	Message	Date
Tomasz Bursztyka	e18fcbba5a	device: Const-ify all device driver instance pointers Now that device_api attribute is unmodified at runtime, as well as all the other attributes, it is possible to switch all device driver instance to be constant. A coccinelle rule is used for this: @r_const_dev_1 disable optional_qualifier @ @@ -struct device * +const struct device * @r_const_dev_2 disable optional_qualifier @ @@ -struct device * const +const struct device * Fixes #27399 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>	2020-09-02 13:48:13 +02:00
Kumar Gala	a1b77fd589	zephyr: replace zephyr integer types with C99 types git grep -l 'u\(8\\|16\\|32\\|64\)_t' \| \ xargs sed -i "s/u\(8\\|16\\|32\\|64\)_t/uint\1_t/g" git grep -l 's\(8\\|16\\|32\\|64\)_t' \| \ xargs sed -i "s/s\(8\\|16\\|32\\|64\)_t/int\1_t/g" Signed-off-by: Kumar Gala <kumar.gala@linaro.org>	2020-06-08 08:23:57 -05:00
Michael Scott	90e778d983	drivers: modem: context helper: introduce modem context helper driver Initial support for modems in Zephyr use the following driver model: - Main portions of code live in the modem specific driver. This includes internal socket management, command parsing, etc. - They leverage a UART-based modem receiver helper to gather data. - Interface with Zephyr networking via net_context offload APIs. This implementation was good enough to kick start interest in supporting modem usage in Zephyr, but lacks future scalability: - The net_context offload APIs don't allow for operations such as offloaded DNS, SSL/TLS and other HW specific features. - Since most of the code lives within the modem drivers, it's very hard for the Zephyr community to improve the driver layer over time. Bugs found in 1 driver probably affect others due to copy/paste method of development. - Lack of abstraction for different modem interfaces and command handlers makes it impossible to write a "dummy" layer which could be used for testing. - Lack of centralized processing makes implementing low power modes and other advanced topics more difficult. Introducing the modem context helper driver and sub-layers: - modem context helper acts as an umbrella for several configurable layers and exposes this data to externals such as the modem shell. Included in the helper is GPIO pin config functions which are currently duplicated in most drivers. - modem interface layer: this layer sits on the HW APIs for the peripheral which communicates with the modem. Users of the modem interface can handle data via read/write functions. Individual modem drivers can select from (potentially) several modem interfaces. - modem command parser layer: this layer communicates with the modem interface and processes the data for use by modem drivers. Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922 Signed-off-by: Michael Scott <mike@foundries.io>	2019-08-10 00:03:39 +02:00

Author

SHA1

Message

Date

Tomasz Bursztyka

e18fcbba5a

device: Const-ify all device driver instance pointers

Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.

A coccinelle rule is used for this:

@r_const_dev_1
  disable optional_qualifier
@
@@
-struct device *
+const struct device *

@r_const_dev_2
 disable optional_qualifier
@
@@
-struct device * const
+const struct device *

Fixes #27399

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>

2020-09-02 13:48:13 +02:00

Kumar Gala

a1b77fd589

zephyr: replace zephyr integer types with C99 types

git grep -l 'u\(8\|16\|32\|64\)_t' | \
		xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g"
	git grep -l 's\(8\|16\|32\|64\)_t' | \
		xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g"

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

2020-06-08 08:23:57 -05:00

Michael Scott

90e778d983

drivers: modem: context helper: introduce modem context helper driver

Initial support for modems in Zephyr use the following driver model:
- Main portions of code live in the modem specific driver.
  This includes internal socket management, command parsing, etc.
- They leverage a UART-based modem receiver helper to gather data.
- Interface with Zephyr networking via net_context offload APIs.

This implementation was good enough to kick start interest in
supporting modem usage in Zephyr, but lacks future scalability:
- The net_context offload APIs don't allow for operations such
  as offloaded DNS, SSL/TLS and other HW specific features.
- Since most of the code lives within the modem drivers, it's
  very hard for the Zephyr community to improve the driver layer
  over time.  Bugs found in 1 driver probably affect others due
  to copy/paste method of development.
- Lack of abstraction for different modem interfaces and command
  handlers makes it impossible to write a "dummy" layer which
  could be used for testing.
- Lack of centralized processing makes implementing low power modes
  and other advanced topics more difficult.

Introducing the modem context helper driver and sub-layers:
- modem context helper acts as an umbrella for several configurable
  layers and exposes this data to externals such as the modem shell.
  Included in the helper is GPIO pin config functions which are
  currently duplicated in most drivers.
- modem interface layer: this layer sits on the HW APIs for the
  peripheral which communicates with the modem.  Users of the modem
  interface can handle data via read/write functions.  Individual
  modem drivers can select from (potentially) several modem
  interfaces.
- modem command parser layer: this layer communicates with the
  modem interface and processes the data for use by modem drivers.

Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17922

Signed-off-by: Michael Scott <mike@foundries.io>

2019-08-10 00:03:39 +02:00

3 Commits