RFC: Parse Kconfig to get driver API/feature info #50724

galak · 2022-09-27T18:31:20Z

The intent of this PR is to show how we can parse Kconfig data to extract driver API and feature information. We map from devicetree compatible to Kconfig.

If we standardize on the Kconfig symbols names and pattern, we can utilize this as a means to extract info we need for things like multi-api, shell, userspace, docs, testing, etc.

Add a Kconfig symbol that reflects the devicetree compatible string so we can map from dts compatible to Kconfig fully. Signed-off-by: Kumar Gala <[email protected]>

pull edt into kconfig so we can look at devicetree stuff Signed-off-by: Kumar Gala <[email protected]>

yvanderv · 2022-09-27T19:28:07Z

Kumar, could you define 'feature' here? And clarifying the end goal of this update would help.

galak · 2022-09-27T19:42:22Z

Kumar, could you define 'feature' here? And clarifying the end goal of this update would help.

Feature here is meant to be defined as what capabilities a driver implements. For something like serial drivers, this goes to what APIs are or not implemented. So if you look at something like include/zephyr/drivers/uart.h and what CONFIG_, the set of features would be:

CONFIG_UART_ASYNC_API
CONFIG_UART_DRV_CMD
CONFIG_UART_INTERRUPT_DRIVEN
CONFIG_UART_LINE_CTRL
CONFIG_UART_WIDE_DATA

The end goal would be to provide a means that we can "query" this information for whatever needs we might have, for example we can generate docs for a board to describe what features are supported, based on its devicetree and this information.

In addition to the features, we also have the API information. Today we don't have an easy way of associating a device with what API its supporting. The "type" information of the api pointer isn't kept anywhere we can determine in an easy way. There are some things we do for user space and parsing the ELF file to extract this info. But we can easily associate a struct device with the API type.

In what format the data we extract is exposed is a TBD based on the needs at hand.

The first goal of this PR is to show the capability and discuss the idea of standardizing on conventions for use of Kconfig symbol naming for conveying API and features.

Walk devicetree compatibles that are enabled and dump out API and feature info based on the Kconfig symbols we have enabled. Signed-off-by: Kumar Gala <[email protected]>

bjarki-andreasen · 2022-09-27T19:49:53Z

Please provide an example Kconfig file for some driver. I can't work out how the compatible property is defined in the Kconfig file.

galak · 2022-09-27T19:57:16Z

Please provide an example Kconfig file for some driver. I can't work out how the compatible property is defined in the Kconfig file.

The compatible Kconfig properties are auto-generated (look at Kconfig/Kconfig.dts in the build dir). All this does right now is output when you do the cmake config what API and features we can detect.

So for something like FRDM-K64F, we get:

dts compatible: "nxp,kinetis-ftfe"     Kconfig Symbol: SOC_FLASH_MCUX
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
api - SERIAL_HAS_DRIVER

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
feature - SERIAL_SUPPORT_ASYNC

dts compatible: "nxp,kinetis-rnga"     Kconfig Symbol: ENTROPY_MCUX_RNGA
api - ENTROPY_HAS_DRIVER

For something like qemu_x86 we get:

dts compatible: "ns16550"     Kconfig Symbol: UART_NS16550
api - SERIAL_HAS_DRIVER

dts compatible: "ns16550"     Kconfig Symbol: UART_NS16550
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "zephyr,sim-flash"     Kconfig Symbol: FLASH_SIMULATOR
api - FLASH_HAS_DRIVER_ENABLED

bjarki-andreasen · 2022-09-27T20:07:47Z

How would something like this look with the changes?

# Atmel SAM UART configuration options

# Copyright (c) 2017 Piotr Mienkowski
# Copyright (c) 2018 Justin Watson
# SPDX-License-Identifier: Apache-2.0

config UART_SAM
	bool "Atmel SAM MCU family UART driver"
	default y
	depends on DT_HAS_ATMEL_SAM_UART_ENABLED
	select SERIAL_HAS_DRIVER
	select SERIAL_SUPPORT_INTERRUPT
	help
	  This option enables the UARTx driver for Atmel SAM MCUs.

It would require no changes right?

galak · 2022-09-27T20:21:49Z

How would something like this look with the changes?

# Atmel SAM UART configuration options

# Copyright (c) 2017 Piotr Mienkowski
# Copyright (c) 2018 Justin Watson
# SPDX-License-Identifier: Apache-2.0

config UART_SAM
	bool "Atmel SAM MCU family UART driver"
	default y
	depends on DT_HAS_ATMEL_SAM_UART_ENABLED
	select SERIAL_HAS_DRIVER
	select SERIAL_SUPPORT_INTERRUPT
	help
	  This option enables the UARTx driver for Atmel SAM MCUs.

It would require no changes right?

So for something like sam_e70_xplained, we get:

dts compatible: "atmel,sam-flash-controller"     Kconfig Symbol: SOC_FLASH_SAM
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-trng"     Kconfig Symbol: ENTROPY_SAM_RNG
api - ENTROPY_HAS_DRIVER

(No change to any Kconfig, boards, etc).

galak · 2022-09-27T20:27:54Z

tdk_robokit1 might be a little more interesting as it has both uart and usart enabled:

dts compatible: "atmel,sam-flash-controller"     Kconfig Symbol: SOC_FLASH_SAM
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "atmel,sam-uart"     Kconfig Symbol: UART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-uart"     Kconfig Symbol: UART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-trng"     Kconfig Symbol: ENTROPY_SAM_RNG
api - ENTROPY_HAS_DRIVER

bjarki-andreasen · 2022-09-27T20:44:01Z

Some notes:

We should take out the SYM_TO_TYPE out of the kconfig.py script and in to one or more YAML/JSON files to allow for out-of-tree support for this feature. We can also do some validation on this files contents.
```
apis:
    - uart:
        config: SERIAL_HAS_DRIVER
        features:
            - SERIAL_SUPPORT_INTERRUPT
```
We should export a dictionary of the node information data to a pickle like we do for EDTLIB to be used for downstream scripts.
We should move the devicetree/kconfig merging feature outside of the kconfig.py file to its own file.
I personally do not like the naming scheme SERIAL_HAS_DRIVER. I would prefer UART_DRIVER_API and UART_DRIVER_FEATURE_x, selects UART_DRIVER_API makes grammatical sense

bjarki-andreasen · 2022-09-27T20:53:25Z

Also, We should add a config like DEVICE_DRIVER

config UART
    bool "uart"
    selects DEVICE_DRIVER

We could use this to validate the individual kconfig files which describe a device driver, make sure it has a compatible, an API etc. this could help maintain standardization.

bjarki-andreasen · 2022-09-27T21:07:03Z

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

Validating that a bindings file contains a property like device_type is also trivial, compared to kconfigs where some of them must be validated as device drivers, while some must not be validated at all, like files which just source other files.

Unless this solution can bring way more useful features than the bindings file solution, I don't think the complexity is worth it.

tbursztyka · 2022-09-28T11:33:40Z

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

I agree on api type in the bindings (in the yaml file so even if that's software feature being exposed, it's not strictly part of the DT which should only be about the hw, or are the yaml also under such rule?), it would be easier and more reliable to relate a compatible to an actual API.
But we may still need the features, some Kconfig options on certain drivers for can make a huge difference in behavior.

That said, @galak, could you expose exactly a few major use cases for such metadata extractions?
Besides the informative use-case (docs and testing mostly, the shell: who would really use to know the details via the shell?), I don't see much critical use for it.

Any which way this is solved, it will require a very strict normalization of Kconfig options name in order to differentiate what is a feature and what is not (i.e. just a simple config thing such as an obscure internal timeout)

gmarull · 2022-09-28T11:39:47Z

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

I agree on api type in the bindings (in the yaml file so even if that's software feature being exposed, it's not strictly part of the DT which should only be about the hw, or are the yaml also under such rule?), it would be easier and more reliable to relate a compatible to an actual API. But we may still need the features, some Kconfig options on certain drivers for can make a huge difference in behavior.

-1 on adding this info to bindings. Bindings are the schema of Devicetree, nothing else. And why should a binding be tied to a particular API? I can create my own sensor API out of tree and still use the same DT file. Btw, we are still missing why we need all this information. Can we come up with a problem that needs to be solved using it first?

bjarki-andreasen · 2022-09-28T12:29:25Z

@gmarull @tbursztyka

Adding api to bindings files is entirely appropriate according to ePAPR and Linux
The bindings file as described in ePAPR https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf section 2.3.1 to 2.3.11 contains properties that are binding firmware to hardware, like "name", "model", "compatible", and the now (in some cases) deprecated "device_type". As stated on page 18, line 16 to 17: "An ePAPR-compliant device tree describes device information in a system that cannot necessarily be dynamically detected by a client program." of which "device_type" or more aptly named, "api" falls into.
Regarding the Linux devicetree, the device_type is described here https://elinux.org/Device_Tree_Linux#device_type_property, and even further, the function which iterates through devices by said device_type property for_each_node_by_type is defined here in the Linux kernel https://github.com/torvalds/linux/blob/master/include/linux/of.h#L1343.

In summary:

The device_type / api property is in accordance with ePAPR
The device_property exists in the Linux devicetree bindings
Methods for getting device or devices by device type exists in the Linux kernel
We have a static device model, therefore we need a compile time macro for getting devices by device type.

The problems that need the API information
Some multi API models need to know the API, subsystems like shells and networking need to be able to group devices by supported API (the current solution for grouping network interfaces are a clear example of where being able to get all devices of a specific type would greatly reduce complexity) And if we want to add type safety in the future, we need to know what type of device something is to, (specifically to declare externs for it like we do for current generic devices).

In summary:

We may need it for multi API model
We could use it to simplify the net_if grouping
We need it for shells to get both devices and their properties at compile time
We may need it for a type safe API model
An example from Linux, use it to identify all displays on a system.

With the simplicity of the already supported feature on Linux, and the gain we will immediately get for the shells, and may get for future uses, I see no good argument against adding the feature.

Having the feature added will retrospectively reduce complexity as we will not need to touch the kconfig system.

bjarki-andreasen · 2022-09-28T12:51:49Z

@galak

An additional note to the "alternative solution" comment i made earlier, we can do both if there is enough other information we can get from kconfig files, just get the API from the node as is done with the compatible.

tbursztyka · 2022-09-28T12:55:32Z

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

I agree on api type in the bindings (in the yaml file so even if that's software feature being exposed, it's not strictly part of the DT which should only be about the hw, or are the yaml also under such rule?), it would be easier and more reliable to relate a compatible to an actual API. But we may still need the features, some Kconfig options on certain drivers for can make a huge difference in behavior.

-1 on adding this info to bindings. Bindings are the schema of Devicetree, nothing else.

Ok, thus my question in parenthesis. I was not sure the yaml files are that tight to the dtsi ones.
[edit] However, see previous comment from @bjarki-trackunit. DTS is confusing :)

Btw, we are still missing why we need all this information. Can we come up with a problem that needs to be solved using it first?

👍

henrikbrixandersen · 2022-09-28T14:05:02Z

3. We need it for shells to get both devices and their properties at compile time

While I am not as skeptical towards the DTS device_type/api approach as I am towards the Kconfig/property files solutions, I would like to point out the distinction between "need" and "could use". The Zephyr shell is working without this feature just fine.

gmarull · 2022-09-28T14:07:18Z

The device_type / api property is in accordance with ePAPR

This property is deprecated (as mentioned in the paper). From DT-spec: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

The device_type property was used in IEEE 1275 to describe the device’s FCode programming model. Because DTSpec does
not have FCode, new use of the property is deprecated, and it should be included only on
cpu and memory nodes for compatibility with IEEE 1275–derived devicetrees.

Also, we should not mix device type with API type, these are different things. I could add to a sensor device_type = "sensor" but use the API I want, it doesn't have to be the Zephyr sensor API.

galak · 2022-09-28T14:24:30Z

Devicetree is NOT the right place for this information. I repeat that devicetree is meant to describe hardware and should be agnostic to the software it is running on. One should be able to take a devicetree and use it with a different OS. So encoding Zephyr specific API choices is devicetree does not make sense.

galak · 2022-09-28T14:53:27Z

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support. The shell as @henrikbrixandersen mention works, but we can make it better with this information. There is some need for sensors that having this information seems like it might be useful, but I don't quite understand the use / need there (@yperess @MaureenHelm can you chime on the sensor need). There is some possible use with I3C and knowing the set of client devices. Also possibly simplifying some of the userspace/syscall logic that is extracting API type information out of the ELF file.

And than there is all the information cases - docs, testing, etc.

bjarki-andreasen · 2022-09-28T15:02:22Z

The device_type / api property is in accordance with ePAPR

This property is deprecated (as mentioned in the paper). From DT-spec: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

The device_type property was used in IEEE 1275 to describe the device’s FCode programming model. Because DTSpec does
not have FCode, new use of the property is deprecated, and it should be included only on
cpu and memory nodes for compatibility with IEEE 1275–derived devicetrees.

Also, we should not mix device type with API type, these are different things. I could add to a sensor device_type = "sensor" but use the API I want, it doesn't have to be the Zephyr sensor API.

The point is that it and "model" exist, showing precedent for having other metadata than compatible in the bindings files, not whether or not that specific property is deprecated which i even noted in the comment... It not only exists, it is in use in Linux.

galak · 2022-09-28T15:09:31Z

The device_type / api property is in accordance with ePAPR

This property is deprecated (as mentioned in the paper). From DT-spec: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

The device_type property was used in IEEE 1275 to describe the device’s FCode programming model. Because DTSpec does
not have FCode, new use of the property is deprecated, and it should be included only on
cpu and memory nodes for compatibility with IEEE 1275–derived devicetrees.

Also, we should not mix device type with API type, these are different things. I could add to a sensor device_type = "sensor" but use the API I want, it doesn't have to be the Zephyr sensor API.

The point is that it and "model" exist, showing precedent for having other metadata than compatible in the bindings files, not whether or not that specific property is deprecated which i even noted in the comment... It not only exists, it is in use in Linux.

I understand the point some of those things are hold overs from true IEEE 1275 and aren't utilized anymore. My point about encoding zephyr software choices in devicetree does not make sense and I don't support it for this purpose.

tbursztyka · 2022-09-28T17:33:01Z

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support.

How would this PR help to solve the multi-api issue that #49374 tried to (and could, if all instances were DTS based) do?

I know there are different approach to an issue. But so far, on things related to device model, it seems to me we are piling up more code and workarounds to the existing model than actually fixing its core issues.

(...) And than there is all the information cases - docs, testing, etc.

Informational use cases are far from being critical, not sure it's worth piling up more hacks on devices just for it. At least before fixing the core issuse.

galak · 2022-09-28T19:39:34Z

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support.

How would this PR help to solve the multi-api issue that #49374 tried to (and could, if all instances were DTS based) do?

I know there are different approach to an issue. But so far, on things related to device model, it seems to me we are piling up more code and workarounds to the existing model than actually fixing its core issues.

This doesn't solve the multi-api issue by itself. Its meant to demonstrate how to get the API type information associated with a devicetree compatible and driver (and thus can connect to a 'struct device'). Regardless of what solution we utilize we will have to have some means of associated and lookup the different API pointers for a "device".

(...) And than there is all the information cases - docs, testing, etc.

Informational use cases are far from being critical, not sure it's worth piling up more hacks on devices just for it. At least before fixing the core issuse.

I'm not sure what hack this is doing. It's utilizing the existing Kconfig information we already have, and suggesting we standardize on some aspects of it.

bjarki-andreasen · 2022-09-28T21:30:48Z

While researching into yet another solution to the issue of device driver capabilities, I stumbled upon the following problems that we should be able to account for with these solutions.

The new solution looks like this.

# The drivers kconfig symbol
driver: MODEM_GSM_PPP

# The devicetree compatibles this driver supports
compatible:
  - "quectel,bg95"
  - "quectel,bg96"
  - "simcom,sim-7080"
  - "ubloc,sara-r4"

# Which API(s) does the driver implement
api:
  - net_if

It describes what kconfig symbol selects the driver, which compatibles it works with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?

galak · 2022-09-29T01:33:01Z

It describes what kconfig symbol selects the driver, which compatibles it works with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?

Looking at the code it seems like the Kconfig MODEM_QUECTEL_BG9X is associated with quectel,bg9x. I don't see the linkage to MODEM_GSM_PPP. So we'd have the MODEM_QUECTEL_BG9X updated to have something like:

config MODEM_QUECTEL_BG9X
   depends on DT_HAS_QUECTEL_BG9X_ENABLED
   select NET_IF_API
    ...

bjarki-andreasen · 2022-09-29T07:46:08Z

It describes what kconfig symbol selects the driver, which compatibles it works with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?
Looking at the code it seems like the Kconfig MODEM_QUECTEL_BG9X is associated with quectel,bg9x. I don't see the linkage to MODEM_GSM_PPP. So we'd have the MODEM_QUECTEL_BG9X updated to have something like:
config MODEM_QUECTEL_BG9X
   depends on DT_HAS_QUECTEL_BG9X_ENABLED
   select NET_IF_API
    ...

The example is not related to the currently existing device drivers/bindings. Can this solution solve the problem shown in the example?

The modem drivers/bindings are bit messy currently, and will be updated to the example that i showed in the future. It should be possible to change which driver you use without changing the compatible, just by including MODEM_GSM_PPP instead of MODEM_QUECTEL_BG9X or reverse.

gmarull · 2022-09-29T08:03:42Z

I appreciate all the efforts on this topic, I'm sure it will be useful one way or the other. But remember, we still have no use for it. We have potential uses, so we don't really know if any of these proposals will fit. I'd go back to the original discussions and open RFCs if not in place:

We want multi-API. What are the options? Pros/Cons? Is meta-info required, or we have other alternatives?
We want better board docs. What do we want to have in a board page? Prepare a mockup that allows us to write requirements (e.g. need meta-info to do X).
...

galak · 2022-09-29T13:21:13Z

We want better board docs. What do we want to have in a board page? Prepare a mockup that allows us to write requirements (e.g. need meta-info to do X).

I'm not familiar with how we do other doc generation for things like Kconfig or dts bindings, but in boards we tend to have a section/table like:

https://docs.zephyrproject.org/latest/boards/arm/lpcxpresso55s06/doc/index.html#supported-features

We could autogenerate that based on this information being extracted from devicetree and Kconfig. (Thus it would always be correct and in sync). The following commit shows how the table got updated recently to expose features on a driver level: 569ef4c

galak · 2022-09-29T13:27:38Z

The modem drivers/bindings are bit messy currently, and will be updated to the example that i showed in the future. It should be possible to change which driver you use without changing the compatible, just by including MODEM_GSM_PPP instead of MODEM_QUECTEL_BG9X or reverse.

If we can describe the relationship in Kconfig than we can extract that information. So its easy enough to have something like:

config MODEM_GSM_PPP
   depends on DT_HAS_COMPAT_QUECTEL_BG95_ENABLED || DT_HAS_COMPAT_QUECTEL_BG96_ENABLED || \
                        DT_HAS_COMPAT_SIMCOM_SIM_7080_ENABLED || DT_HAS_COMPAT_UBLOC_SARA_R4
   select NET_IF_API

galak · 2022-09-29T13:31:13Z

We want multi-API. What are the options? Pros/Cons? Is meta-info required, or we have other alternatives?

We have a multi-API proposal from @bjarki-trackunit that requires meta-info (#48817). This PR shows an alternate to using a yet another YAML file to describe devicetree compatible to driver API type association.

mbolivar-nordic · 2022-09-29T16:21:03Z

@galak as discussed at dev-review it'd be good to get a view of the use cases and problems to solve here, with links to the relevant issues that should have good descriptions of those.

There are already 30 comments on this issue. I'd really not have to read all of them to find the ones that have answers to basic questions like "why" and "for what" -- i.e. it'd be better for all the reviewers if you can update the PR description instead of answering inline.

galak · 2022-09-29T16:40:53Z

@galak as discussed at dev-review it'd be good to get a view of the use cases and problems to solve here, with links to the relevant issues that should have good descriptions of those.

There are already 30 comments on this issue. I'd really not have to read all of them to find the ones that have answers to basic questions like "why" and "for what" -- i.e. it'd be better for all the reviewers if you can update the PR description instead of answering inline.

I'm going to close this PR for now since I agree, this is more about how to implement a solution to a specific problem, and not about the problems themselves.

galak added 2 commits September 27, 2022 13:22

dts: generate string for devicetree compatible

439201c

Add a Kconfig symbol that reflects the devicetree compatible string so we can map from dts compatible to Kconfig fully. Signed-off-by: Kumar Gala <[email protected]>

kconfig.py: import edt into kconfig.py

0fe53eb

pull edt into kconfig so we can look at devicetree stuff Signed-off-by: Kumar Gala <[email protected]>

galak requested review from henrikbrixandersen, gmarull, bjarki-andreasen, carlescufi, nashif and tejlmand September 27, 2022 18:31

galak added dev-review To be discussed in dev-review meeting area: Device Model labels Sep 27, 2022

carlocaione self-requested a review September 27, 2022 19:22

kconfig: dump API/feature info based on devicetree & Kconfig symbols

c400511

Walk devicetree compatibles that are enabled and dump out API and feature info based on the Kconfig symbols we have enabled. Signed-off-by: Kumar Gala <[email protected]>

galak force-pushed the kconfig-drv-api branch from 38ead4a to c400511 Compare September 27, 2022 19:45

bjarki-andreasen mentioned this pull request Sep 28, 2022

Zephyr is missing documentation and validation of device drivers #50788

Open

galak closed this Sep 29, 2022

galak removed the dev-review To be discussed in dev-review meeting label Sep 29, 2022

carlescufi mentioned this pull request Nov 22, 2022

User Need - easily find which features are supported on each board #51722

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: Parse Kconfig to get driver API/feature info #50724

RFC: Parse Kconfig to get driver API/feature info #50724

galak commented Sep 27, 2022

yvanderv commented Sep 27, 2022 •

edited

Loading

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

galak commented Sep 27, 2022

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

tbursztyka commented Sep 28, 2022 •

edited

Loading

gmarull commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 28, 2022

tbursztyka commented Sep 28, 2022 •

edited

Loading

henrikbrixandersen commented Sep 28, 2022

gmarull commented Sep 28, 2022 •

edited

Loading

galak commented Sep 28, 2022

galak commented Sep 28, 2022

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

galak commented Sep 28, 2022 •

edited

Loading

tbursztyka commented Sep 28, 2022

galak commented Sep 28, 2022

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

galak commented Sep 29, 2022

bjarki-andreasen commented Sep 29, 2022 •

edited

Loading

gmarull commented Sep 29, 2022

galak commented Sep 29, 2022

galak commented Sep 29, 2022

galak commented Sep 29, 2022

mbolivar-nordic commented Sep 29, 2022

galak commented Sep 29, 2022

RFC: Parse Kconfig to get driver API/feature info #50724

RFC: Parse Kconfig to get driver API/feature info #50724

Conversation

galak commented Sep 27, 2022

yvanderv commented Sep 27, 2022 • edited Loading

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022 • edited Loading

galak commented Sep 27, 2022

galak commented Sep 27, 2022

bjarki-andreasen commented Sep 27, 2022 • edited Loading

bjarki-andreasen commented Sep 27, 2022 • edited Loading

bjarki-andreasen commented Sep 27, 2022 • edited Loading

tbursztyka commented Sep 28, 2022 • edited Loading

gmarull commented Sep 28, 2022 • edited Loading

bjarki-andreasen commented Sep 28, 2022 • edited Loading

bjarki-andreasen commented Sep 28, 2022

tbursztyka commented Sep 28, 2022 • edited Loading

henrikbrixandersen commented Sep 28, 2022

gmarull commented Sep 28, 2022 • edited Loading

galak commented Sep 28, 2022

galak commented Sep 28, 2022

bjarki-andreasen commented Sep 28, 2022 • edited Loading

galak commented Sep 28, 2022 • edited Loading

tbursztyka commented Sep 28, 2022

galak commented Sep 28, 2022

bjarki-andreasen commented Sep 28, 2022 • edited Loading

galak commented Sep 29, 2022

bjarki-andreasen commented Sep 29, 2022 • edited Loading

gmarull commented Sep 29, 2022

galak commented Sep 29, 2022

galak commented Sep 29, 2022

galak commented Sep 29, 2022

mbolivar-nordic commented Sep 29, 2022

galak commented Sep 29, 2022

yvanderv commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

bjarki-andreasen commented Sep 27, 2022 •

edited

Loading

tbursztyka commented Sep 28, 2022 •

edited

Loading

gmarull commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

tbursztyka commented Sep 28, 2022 •

edited

Loading

gmarull commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

galak commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 28, 2022 •

edited

Loading

bjarki-andreasen commented Sep 29, 2022 •

edited

Loading