drivers: use codegen for device instantiation #9163

b0661 · 2018-07-29T06:25:21Z

Overview

Use codegen #6762 for device instantiation.

This PR includes PR #6762.

Motivation for or Use Case

Demonstrate the usage of codegen and the included devicedeclare module for device instantiation.

Design Details

The following drivers are adapted to use codegen for device instantiation:

I2C: i2c_ll_stm32.c (commit: drivers: i2c: stm32: use codegen driver instantiation)
SPI: spi_ll_stm32.c (commit: drivers: spi: stm32: use codegen driver instantiation)
SERIAL: uart_stm32.c: (commit: drivers: serial: stm32: use codegen driver instantiation)
CAN: stm32_can.c: (commit: drivers: can: stm32: use codegen driver instantiation)
PWM: pwm_stm32.c (drivers: pwm: stm32: use codegen driver instantiation)
INT: exti_stm32.c (drivers: interrupt: stm32: use codegen driver instantiation)

Codegen #6762 provides two device declaration functions in it's devicedeclare module.

devicedeclare.device_declare
Provides a sophisticated device declaration API. It is transferred from @erwango 's work in Generated driver instantiation prototype #8561.
devicedeclare.device_declare_single/multi
Provides a more raw device declaration API that allows for a fine grained control of the device instantiation template. It is the basis also for devicedeclare.device_declare.

All drivers above except INT are adapted to use the devicedeclare.device_declare_multi API.

The interrupt driver uses the devicedeclare.device_declare API. It is a minimal conversion to show the feasibility. For elaborated examples of the devciedeclare.device_declare API see #8561.

Codegen's device declaration is done using a device info template with placeholders that is used for every device instance. The placeholders are replaced by the respective device tree, or Kconfig, or device instance values:

Device tree property placeholder are defined by the property path; either ${[property path]} for properties of the actual device instance or ${[device id]:[property path]} for another device instance property.
Kconfig placeholders are ${CONFIG_[config name]}.
The device instance placeholders ${device-[xxx]} provide device instance specific info that is autogenerated eg. device name, driver name, name of the data structure ...

/**
 * @code{.codegen}
 * codegen.import_module('devicedeclare')
 *
 * device_configs = ['CONFIG_I2C_{}'.format(x) for x in range(0, 5)]
 * driver_names = ['I2C_{}'.format(x) for x in range(0, 5)]
 * device_inits = 'i2c_stm32_init'
 * device_levels = 'POST_KERNEL'
 * device_prios = 'CONFIG_KERNEL_INIT_PRIORITY_DEVICE'
 * device_api = 'api_funcs'
 * device_info = \
 * """
 * #if CONFIG_I2C_STM32_INTERRUPT
 * DEVICE_DECLARE(${device-name});
 * static void ${device-config-irq}(struct device *dev)
 * {
 * #ifdef CONFIG_I2C_STM32_COMBINED_INTERRUPT
 *         IRQ_CONNECT(${interrupts/combined/irq}, ${interrupts/combined/priority}, \\
 *                     stm32_i2c_combined_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/combined/irq});
 * #else
 *         IRQ_CONNECT(${interrupts/event/irq}, ${interrupts/event/priority}, \\
 *                     stm32_i2c_event_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/event/irq});
 *         IRQ_CONNECT(${interrupts/error/irq}, ${interrupts/error/priority}, \\
 *                     stm32_i2c_error_isr, \\
 *                     DEVICE_GET(${device-name}), 0);
 *         irq_enable(${interrupts/error/irq});
 * #endif
 * }
 * #endif
 * static const struct i2c_stm32_config ${device-config-info} = {
 *         .i2c = (I2C_TypeDef *)${reg/0/address/0},
 *         .pclken.bus = ${clocks/0/bus},
 *         .pclken.enr = ${clocks/0/bits},
 * #if CONFIG_I2C_STM32_INTERRUPT
 *         .irq_config_func = ${device-config-irq},
 * #endif
 *         .bitrate = ${clock-frequency},
 * #if defined(CONFIG_SOC_SERIES_STM32F3X) || defined(CONFIG_SOC_SERIES_STM32F0X)
 *         .ll_clock_source = LL_${driver-name}_CLOCKSOURCE,
 * #endif
 * };
 * static struct i2c_stm32_data ${device-data};
 * """
 *
 * devicedeclare.device_declare_multi( \
 *     device_configs,
 *     driver_names,
 *     device_inits,
 *     device_levels,
 *     device_prios,
 *     device_api,
 *     device_info)
 * @endcode{.codegen}
 */
/** @code{.codeins}@endcode */

Test Strategy

This PR extends the SPI loopback test for the NUCLEO F091RC board. It was tested using this test and some
sample applications.

Signed-off-by: Bobby Noelte [email protected]

codecov-io · 2018-07-29T06:51:49Z

Codecov Report

Merging #9163 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9163   +/-   ##
=======================================
  Coverage   52.15%   52.15%           
=======================================
  Files         212      212           
  Lines       25916    25916           
  Branches     5582     5582           
=======================================
  Hits        13517    13517           
  Misses      10149    10149           
  Partials     2250     2250

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7983606...fe86193. Read the comment docs.

superna9999 · 2018-07-30T07:42:59Z

drivers/spi/spi_ll_stm32.h

Is it strictly necessary to remove this header for this change ?

No it is not necessary. It just happened over the various adaptations to the changing requirements to codegen.

superna9999 · 2018-07-30T07:44:23Z

drivers/spi/Kconfig.stm32

I understand this would be great, but this should go in a separate changeset

Of course it can go to a different changeset. This PR includes various changes that I applied to make the drivers work with codegen (or better work). Currently it is a massive maintenance/ rebase effort that increases with every changeset to be managed. If codegen is accepted I can restructure the driver changes.

superna9999 · 2018-07-30T07:45:10Z

drivers/spi/spi_ll_stm32.c

I maybe missed a bit, but where do you declare the device compatible ? How do you link with the DT node and it's attributes ?

I declare the driver names. Device compatible is then read from the device tree. Linkage to the device tree attributes is done by the placeholders - e.g ${reg/0/address/0} relates to the device tree reg property address 0 of register 0.

Could you clarify link between driver names and DT?

The driver name (aka. the label property from DTS) is used to identify the driver instance and to retrieve all the data from the extended DTS database. The DTS database is searched for a device where the label property matches the driver name.

Is it a Zephyr policy to use label for that ?
In the normal DT world (Linux, U-Boot, ...) we use the compatible and the aliases to determine the driver and the id of the device, the "label" property is only used to give a label on the device, not to link device<->driver.
AFAIK we used the compatible to generate the defines (ST_STM32_I2C_V2_) and we used the label to generate the config (CONFIG_I2C_1_). Then we used the fixup to link the two.
Why can't we generate the fixups using codegen ?

@b0661 , I agree with @superna9999 on the usual use of 'compatible'. It should be sufficient to link driver to the nodes. Using 'label', you might face issues, for instance when it is not numbered, but use letters for enumeration, or with only one instance.

@superna9999 , indeed they can be generated. But ideally fixups should not be needed and we should be able to generate directly the device init code with values from dt, w/o using intermediate defines. Btw, in #8561, I'm demonstrating an generation API, also based on codegen, and using 'compatible' as the link between driver and dts file.

@erwango

Using 'label', you might face issues, for instance when it is not numbered, but use letters for enumeration, or with only one instance.

This is not a problem as the driver writer knows about the labels and can create whatever list of labels is necessary. This is not restricted to numbers.

The driver writer can also derive the labels from the 'compatible' devices as you do in your device_declare API. As this is a raw API it is just made visible. The real benefit is that you do not have to assume/ impose that all config values are of the form CONFIG_[label] but can be of any form as long as they are listen in the same sequence as the related labels.

You always need a link between the driver instance and the DTS instance. There are only two practical properties, the label and the base address. Also in your device_declare API you have choosen to link the DTS by label. It is just hidden behind the API. The label is first searched by the 'compatible' property and then used for the CONFIG_[label] value.

To have full flexibilty for the raw version I am using the label for the linkage to the DTS. How these labels are found/ defined is up to a more sophisticated API.

@superna9999

.. and we used the label to generate the config (CONFIG_I2C_1_).

This is a linkage done by the label.

As explained before the linkage by label is a minimal low level interface that provides unique linkage between a driver instance and the related DTS instance. It provides maximum flexibility to build sopisticated device_declare APIs (as @erwango ´s) on top. A base interface should not impose restrictions where restrictions are not necessary. Using 'compatible' would impose such unnecessary restrictions. @erwango ´s API implementation shows that you can implement 'comaptible' based linkage on top of the raw interface.

superna9999 · 2018-07-30T07:46:00Z

drivers/i2c/i2c_ll_stm32.c

Can't this go in a separate changeset ? Please stick to codegen only changes

I had to do this change to use the codegen devicedeclare easily. The selction of clock source by config define and base address in i2c_stm32_runtime_configure was not possible the way it was after conversion to codegen.

Agree with @superna9999 , difficult to review and comment on mix of several new additions.
Please remove the clock source part and introduce it in another PR

This PR is about introducing codegen for driver intiantiation. The PR includes various changes that I applied to make the drivers work with codegen (or better work). Currently it is a massive maintenance/ rebase effort that increases with every changeset to be managed. If codegen is accepted I can restructure the driver changes.

erwango

As commented, I'm not in favor of this raw device driver instantiation generation.
Main point is generated code should stick with available dts properties and we should be able to detec and warn when a property is missing and not generate bogus code.

This is why code generation requires some 'magic' that could be provided by a more elaborated generation function.

erwango · 2018-07-31T07:30:08Z

doc/subsystems/codegen/modules.rst

As discussed earlier, there should be no need to provide the number of available IPs.
Besides, it should be updated when a new SoC with a n+1 instance is introduced

Ok. Will also work if you replace the upper limit by e.g. 100. Should be enough for Most SoCs.

erwango · 2018-07-31T07:32:25Z

doc/subsystems/codegen/modules.rst

Same here (instance numbering range should not be needed).
Besides, couldn't we use dts property 'label' instead of yet another instance name.

See above. The driver writer can choose an upper limit that covers all future SoCs. As only the configured and activated devices will be intiantiated the upper limit can be any big number.

Besides, couldn't we use dts property 'label' instead of yet another instance name.

The driver name is the same as the 'label' property. In the INIT macro it is called driver_name so I stick with it. The extended DTS database is searched for a matching 'label' property to retrieve the DTS properties of the device instance with the given driver name.

erwango · 2018-07-31T07:54:05Z

drivers/can/stm32_can.c

I think #ifdef should not be available in driver instantiation template (and this is why I'm not in favor of full 'raw' templates).
In this example, when generating this code with a F0 dts file, F0 dts file does not provide rx, tx interrupts properties.
So, either generation will break because properties are not available.
Either, you're able to fill missing property with '0', generating bogus code (which is not clean even if won't be compiled). And it also means you're not able to generate a warning/error when a missing property occurs in the F0 case (which is, I think, required).

This is why I think driver instances code generation requires some magic and could not be fully raw.

@erwango

This is the raw version of device declare as I explained in several places. Your sophisticated version of device_declare can go without #ifdefs. The raw version shall just show how easily the non codegen code can be transformed to use codegen, and how readability and maintainability is given.

I transfered your device_declare API to the devicedeclare codegen module. Please see how this uses the raw API to provide the sopisticated API.

I think #ifdef should not be available in driver instantiation template (and this is why I'm not in favor of full 'raw' templates).

In your sopisticated device_declare API you are using #ifdef behind the scenes for the interrupt flag. The raw version sould support to be used to implement your more sophisticated API. Also the raw version is only for cases where the sophisticated device declare API does not provide enough control on the driver info template. Adding any limitations to the usage of C code in the template would render the extended template control worthless.

So, either generation will break because properties are not available.

Generation will not break - but compilation will break if DTS properties are not available because the placeholder will not be replaced in this case.

And it also means you're not able to generate a warning/error when a missing property occurs in the F0 case (which is, I think, required).

Compiler error should be enough to provide guidance for the driver writer/ tester. There is no undetected invalid code.

erwango · 2018-07-31T08:00:24Z

drivers/i2c/i2c_ll_stm32.c

Agree with @superna9999 , difficult to review and comment on mix of several new additions.
Please remove the clock source part and introduce it in another PR

b0661 · 2018-07-31T11:59:26Z

Can‘t remove, won‘t complle.

pizi-nordic · 2018-07-31T13:48:42Z

FYI: @nordic-krch, @anangl

b0661 · 2018-07-31T22:16:37Z

@erwango

As commented, I'm not in favor of this raw device driver instantiation generation.

As I transfered your device_declare API to the codegen devicedeclare module every driver author can choose to use your more sopisticated API. I also added this to the documentation suggesting to use the raw API only in case the sopisticated API does not provide enough control on the driver info template.

Main point is generated code should stick with available dts properties and we should be able to detec and warn when a property is missing and not generate bogus code.

The generated code just does not compile if a DTS property is not available. Template placeholders (like e.g. ${label}) are not replaced if the property is not available. The C compiler will complain about the literal (e.g. ${label}).

This is why code generation requires some 'magic' that could be provided by a more elaborated generation function.

The magic for detection and warning in case of missing DTS properties is already build into the template placeholder replacement.

erwango · 2018-08-01T08:47:32Z

@b0661 , motivation for this PR is a bit clearer now. I understand this is to demonstrate capability to provide other API to use codegen, and demonstrated one is raw, which indeed could be useful in some cases.
Thought, I personally don't think the approach of using 'label' to bind driver code with device node is adequate, as in usual dt scheme this is the main purpose of 'compatible', and the way it is used in all other dt projects. I don't see a particular reason we should do otherwise, as this is proved to be working with codegen too.

b0661 · 2018-08-01T16:00:42Z

@erwango

Thought, I personally don't think the approach of using 'label' to bind driver code with device node is adequate, as in usual dt scheme this is the main purpose of 'compatible', and the way it is used in all other dt projects. I don't see a particular reason we should do otherwise, as this is proved to be working with codegen too.

As explained above the linkage by 'label' is a low level/ raw interface. Sophisticated device declare APIs (as yours) are based on the raw interface. The global linkage by 'compatible' is also using the linkage by 'label' to have a unique driver instance to DTS instance mapping behind the scenes.

Quotation from above:

The driver writer can also derive the labels from the 'compatible' devices as you do in your device_declare API. As this is a raw API it is just made visible. The real benefit is that you do not have to assume/ impose that all config values are of the form CONFIG_[label] but can be of any form as long as they are listen in the same sequence as the related labels.

You always need a link between the driver instance and the DTS instance. There are only two practical properties, the label and the base address. Also in your device_declare API you have choosen to link the DTS by label. It is just hidden behind the API. The label is first searched by the 'compatible' property and then used for the CONFIG_[label] value.

To have full flexibilty for the raw version I am using the label for the linkage to the DTS. How these labels are found/ defined is up to a more sophisticated API like yours.

dbkinder · 2018-08-01T19:19:32Z

doc/subsystems/codegen/codegen.rst

Technically, I suspect this should read:

The lines immediately before the ``@code{.codeins}@endcode`` comment are the output from the generator.

The output is filled between @endcode{.codegen} and @code{.codeins}@endcode. There is no output currently.

Maybe a silly question, but I mention this because I'm wondering how careful folks need to be about using the exact layout you give in your examples, and what happens if they add comments around these constructs. For example, what will the output look like if I were to add some more comments after the @Endcode{.codegen} or I futz around with the @code{.codeins}@Endcode comment block? Are my comments preserved in the generated output?

/* This is my C file. */ ... /** * @code{.codegen} * fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing'] * for fn in fnames: * codegen.outl("void %s();" % fn) * @endcode{.codegen} * Here are some more comments about the codegen block */ /** * And here is another comment * @code{.codeins} * @endcode */ ...

what will the output look like if I were to add some more comments after the @Endcode{.codegen} or I futz around with the @code{.codeins}@Endcode comment block? Are my comments preserved in the generated output?

Everything between @endcode{.codegen} and @code{.codeins}@endcode will be replaced by the generated code in the generated file. There will be no changes in the source file itself - it is preserved there.

You should not add comments after @endcode{.codegen} and/ or before @code{.codeins}@endcode. You should also not split the @code{.codeins}@endcode marker into two lines.

I did not test all the possible fuzz around. If some standard fuzzing patterns will emerge the parser will have to be made more robust. Currently it assumes some well defined marker structure.

This will probably work to comment the codegen block in the source file. It will be replaced in the generated file. So it does not make much sense.

/* This is my C file. */ ... /** * @code{.codegen} * fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing'] * for fn in fnames: * codegen.outl("void %s();" % fn) * @endcode{.codegen} */ /* Here are some more comments about the codegen block */ /* And here is another comment */ Some other woodoo. /** @code{.codeins}@endcode */ ...

dbkinder · 2018-08-22T00:01:37Z

doc/subsystems/codegen/codegen.rst

+processed by Codegen and the generated source files are written to the CMake
+binary directory.
+
+The inlined Python snippets can contain any Python code, they are regular


Does this have security implications with ANY Python code allowed? I suppose thorough code reviews would catch something malicious being added, and I suspect it's hard to limit the allowed Python snippets.

Codegen is a file generation tool. It uses pieces of Python code in the source file as generators to generate whatever text is needed. If a source file is added by zephyr_sources_codegen(..) or zephyr_sources_codegen_ifdef(..) codegen will be executed and the generated file stored to the build directory. Compilation will run on the generated file only. Codegen is based on Cog. All files taken from Cog are modified. The files are marked by the Cog author's copyright: Copyright 2004-2016, Ned Batchelder. http://nedbatchelder.com/code/cog SPDX-License-Identifier: MIT Origin: https://pypi.python.org/pypi/cogapp Status: 2.5.1 Description: A code generator for executing Python snippets in source files. Dependencies: python URL: https://pypi.python.org/pypi/cogapp commit: 2.5.1 Maintained-by: External License: MIT License Link: URL: https://pypi.python.org/pypi/cogapp Signed-off-by: Bobby Noelte <[email protected]>

Document the inline code generation tool codegen and its integration in the CMake build process. Signed-off-by: Bobby Noelte <[email protected]>

Create extended DTS database to be used by codegen and others. Signed-off-by: Bobby Noelte <[email protected]>

Extract compatible info and make it available by EDTS. This way the compatible info of all activated devices can be used in drivers. Signed-off-by: Bobby Noelte <[email protected]>

Extend reg directive handling to fill the EDTS datanbase. Signed-off-by: Bobby Noelte <[email protected]>

Extend interrupts directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

Extend clocks directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

Extend default directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

Extend directive handling to use heuristics to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

modules/devicedeclare.py: Device declaration functions. Signed-off-by: Bobby Noelte <[email protected]>

Document the modules that can be imported and the templates that can be included by inline code generation. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Extend binding to allow DTS extraction for device info. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Extend bindings to allow DTS extract for device info. Correct DTS to be used in SPI driver. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Extend binding to allow DTS extraction for device info. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Extend binding to allow DTS extract for device info. Correct DTS to be used in CAN driver. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Extend binding to allow DTS extraction for device info. Remove defines from dts.fixup that are now taken from DTS. Adapt samples. Signed-off-by: Bobby Noelte <[email protected]> drivers: pwm: stm32: use codegen driver instantiation (SQUASH#1) Signed-off-by: Bobby Noelte <[email protected]>

Replace device instances code by codegen solution. Add binding to allow DTS extract for device info. Add DTS to be used in EXTI driver. Signed-off-by: Bobby Noelte <[email protected]>

The NUCLEO FO91RC, F070RB, F030R8 boards use SPI_1 for loopback test. Signed-off-by: Bobby Noelte <[email protected]>

b0661 requested review from SebastianBoe, dbkinder, erwango, nashif, superna9999, tbursztyka and ydamigos as code owners July 29, 2018 06:25

b0661 mentioned this pull request Jul 29, 2018

Generated driver instantiation prototype #8561

Closed

b0661 force-pushed the pr_codegen_drivers branch 2 times, most recently from af9a3cf to e527a87 Compare July 29, 2018 20:25

superna9999 suggested changes Jul 30, 2018

View reviewed changes

erwango requested changes Jul 31, 2018

View reviewed changes

pizi-nordic self-requested a review July 31, 2018 13:48

b0661 force-pushed the pr_codegen_drivers branch from e527a87 to df95729 Compare August 1, 2018 06:22

b0661 force-pushed the pr_codegen_drivers branch from df95729 to 85a11c0 Compare August 1, 2018 17:49

dbkinder reviewed Aug 2, 2018

View reviewed changes

b0661 force-pushed the pr_codegen_drivers branch from 85a11c0 to f097ca5 Compare August 6, 2018 17:52

b0661 mentioned this pull request Aug 10, 2018

scripts: add Zephyr inline code generation with Python #6762

Closed

b0661 force-pushed the pr_codegen_drivers branch from f097ca5 to 6962534 Compare August 11, 2018 09:18

b0661 requested a review from andrewboie as a code owner August 11, 2018 09:18

b0661 force-pushed the pr_codegen_drivers branch 3 times, most recently from b40838b to 7aa0de8 Compare August 20, 2018 17:44

dbkinder reviewed Aug 22, 2018

View reviewed changes

b0661 added 18 commits August 24, 2018 07:25

doc: codegen: add inline code generation documentation

5d4135d

Document the inline code generation tool codegen and its integration in the CMake build process. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: create EDTS database for codegen

b5cef69

Create extended DTS database to be used by codegen and others. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: extract compatible to EDTS database

2057743

Extract compatible info and make it available by EDTS. This way the compatible info of all activated devices can be used in drivers. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: extract reg to EDTS database

6e5986b

Extend reg directive handling to fill the EDTS datanbase. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: extract interrupts to EDTS database

10c1ad5

Extend interrupts directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: extract clocks to EDTS database

f34ae50

Extend clocks directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: default extract to EDTS database

b15dd19

Extend default directive handling to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

scripts: extract_dts_includes.py: extract heuristics to EDTS database

512d607

Extend directive handling to use heuristics to fill the EDTS database. Signed-off-by: Bobby Noelte <[email protected]>

scripts: codegen: add generic module

7e270f7

modules/devicedeclare.py: Device declaration functions. Signed-off-by: Bobby Noelte <[email protected]>

doc: codegen: add modules and templates doc

6bd9606

Document the modules that can be imported and the templates that can be included by inline code generation. Signed-off-by: Bobby Noelte <[email protected]>

drivers: i2c: stm32: use codegen driver instantiation

e3d9943

Replace device instances code by codegen solution. Extend binding to allow DTS extraction for device info. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

drivers: serial: stm32: use codegen driver instantiation

b76f686

Replace device instances code by codegen solution. Extend binding to allow DTS extraction for device info. Remove defines from dts.fixup that are now taken from DTS. Signed-off-by: Bobby Noelte <[email protected]>

drivers: interrupt: stm32: use codegen driver instantiation

5a5a1e7

Replace device instances code by codegen solution. Add binding to allow DTS extract for device info. Add DTS to be used in EXTI driver. Signed-off-by: Bobby Noelte <[email protected]>

tests: drivers: spi: support NUCLEO F0x boards

fe86193

The NUCLEO FO91RC, F070RB, F030R8 boards use SPI_1 for loopback test. Signed-off-by: Bobby Noelte <[email protected]>

b0661 force-pushed the pr_codegen_drivers branch from 7aa0de8 to fe86193 Compare August 24, 2018 06:02

mbolivar mentioned this pull request Sep 6, 2018

1.14 Merge Order #9831

Closed

b0661 mentioned this pull request Sep 12, 2018

Device Tree support overhaul #8499

Closed

6 tasks

b0661 closed this Oct 16, 2018

b0661 deleted the pr_codegen_drivers branch October 16, 2018 16:49

SavinayDharmappa mentioned this pull request Oct 25, 2018

drivers: serial: qmsi: use codegen for driver instantiation #10855

Closed

This was referenced Oct 26, 2018

scripts: inline code generation with cogeno (and edts) #10885

Closed

drivers: use codegen for device instantiation #10888

Closed

drivers: use codegen for device instantiation #9163

drivers: use codegen for device instantiation #9163

Uh oh!

Conversation

b0661 commented Jul 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Motivation for or Use Case

Design Details

Test Strategy

Uh oh!

codecov-io commented Jul 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 Jul 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 Jul 31, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 Jul 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erwango left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 Jul 31, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 Jul 31, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b0661 commented Jul 31, 2018

Uh oh!

b0661 commented Jul 29, 2018 •

edited

Loading

codecov-io commented Jul 29, 2018 •

edited

Loading

b0661 Jul 30, 2018 •

edited

Loading

b0661 Jul 31, 2018 •

edited

Loading

b0661 Jul 30, 2018 •

edited

Loading

b0661 Jul 31, 2018 •

edited

Loading

b0661 Jul 31, 2018 •

edited

Loading

b0661 commented Jul 31, 2018 •

edited

Loading

b0661 commented Aug 1, 2018 •

edited

Loading

b0661 Aug 6, 2018 •

edited

Loading

b0661 Aug 8, 2018 •

edited

Loading