Date
1 - 20 of 20
Inconsistent and ever-changing device naming in Zephyr
Paul Sokolovsky
Hello,
Writing on this was in my TODO at least since November, but I expected this to be a controversial topic, so kind of skipped it. Controversial, as in: different parties finding to be "obvious" quite different, if not opposite solutions to the problem. Well, the breakage continues, so this should be raised. (Recent) facts: 1. Update to Kinetis (BOARD=frdm_k64f) port broke GPIO support in a (complex) Zephyr-based application, Zephyr.js: https://github.com/01org/zephyr.js/issues/665 2. A day or two, Arduino 101 I2C support in Zephyr.js was updated, apparently because Zephyr upgrade broke it. Today it became known that the fix for Arduino 101 broke FRDM-K64F. https://github.com/01org/zephyr.js/issues/676 Investigating the issues, the causes of them are: 1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta". 2. Name of (one of) I2C device for arduino_101 changed from "I2C_0" to "I2C_SS_0". This is not the first time when device names change in Zephyr (see reference above to November 2016), it's the first time (at least for last half-year), when the naming changes in relatively well developed ports, which leads to cascade of breakage in the one. And one case, it can be seen how inconsistent naming (and changes of it) can be. The question what to do about this. Possible high-level approaches can be: a) Establish (well, reconfirm/clarify) and uphold consistent naming conventions across ports, architectures, and boards. b) Send a strong message to application developers that they should not rely on any patterns of Zephyr device naming, and even on the naming at all, and instead should treat it as a configuration parameter, which ultimately should be set by a user (and thus apps should make such configuration explicit and easy for users). Whether a) is a viable solution in turn depends on paradigmatic decision what aim Zephyr is trying to achieve: I. Is it a common platform, literally, an Operating System, providing consistent means to develop software *across* various hardware? II. Or is it loose collection of APIs of working with hardware, with the aim of getting most (or something) of a particular hardware, without pledging much for consistency and portability across hardware. It would be nice to get opinions of both the core maintainers and the maintainers of particular ports, as well as specific suggestions how to deal with the bugs above. Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Daniel Thompson <daniel.thompson@...>
On 06/02/17 13:34, Paul Sokolovsky wrote:
Hello,Or c) inherit the device names from device tree? I don't actually remember that much about the proposed DT tooling but it should certainly be included in this discussion. It might be made slightly more complex by the presence of aliased names in DT (often used to bridge SoC datasheet namings into board based names). I guess Zephyr might prefer to use the most-derived alias rather then the SoC datasheet name? Daniel.
|
|
Maureen Helm
Hi Paul,
toggle quoted messageShow quoted text
-----Original Message-----This is my fault. I was not aware the port names were being used this way. I tend to use the config names rather than the strings themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig: config FXOS8700_GPIO_NAME default GPIO_MCUX_PORTC_NAME Please, please let me know if you encounter problems like this again. Since you're most affected, mind making a proposal?
|
|
Andy Gross
On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:The alias {} node can indeed be used for this. But unless we define a specific format, parsing this might be interesting. However we have some solutions for that if we want to go that route. A board specific yaml file could specify the alias format. It's need to be something that can co-exist with existing DT files that might be imported from Linux. Maybe something along the lines of: zephyr,uart-0 = &node@xxxxxxxx; zephyr,uart-1 = &node@xxxxxxxx; and so on and so forth. These can ghost the aliases already present if they have something like uart0 = &node@xxxxxxxx; The zephyr,XXXXX need to be standardized for each device type. We strip the zephyr part and the generated string name becomes UART-0 or UART0 or whatever standard we want. I think this solves both the unified naming and the assigning of the names to specific nodes.
|
|
Paul Sokolovsky
Hello Daniel,
toggle quoted messageShow quoted text
On Mon, 6 Feb 2017 16:59:26 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote: [] I'm not familiar enough with devicetree details to imagine how exactlya) Establish (well, reconfirm/clarify) and uphold consistent namingOr c) inherit the device names from device tree? that would be done, but Andy's response confirms it's possible to do something along those ways. But as far as I can see, that still would depend on establishing common conventions for naming. Perhaps, doing it via DT would allow to achieve consistency easier, and verify/maintain it. But the current question is whether consistency is desirable at all, i.e. would maintainers of individual SoCs agree each making some changes to their code/config, and Zephyr maintainers agree to uphold it afterwards. Given that DT has yet some way to go widely in Zephyr, discussion or at least consideration of this "consistent naming" idea might start in parallel. Daniel.Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Jon Medhurst (Tixy) <tixy@...>
On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:
On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:So, if I get this right, this is device-tree aliases being used toOn 06/02/17 13:34, Paul Sokolovsky wrote:The alias {} node can indeed be used for this. But unless we define a specify the driver name in Zephy? I.e. the drv_name parameter passed to DEVICE_INIT and the string passed to device_get_binding to get a pointer to that driver instance. I thought aliases we're going to be used as a method to replace the 'fixup' files in the current DT RFC patches by matching device-tree node names (<compataible-string>_<address>_<property>) to driver defines (<foo>_<port_N>_<bar> or similar) Is the latter wrong? Or is it a different alias entry in DT used for that? -- Tixy
|
|
Daniel Thompson <daniel.thompson@...>
On 08/02/17 20:39, Paul Sokolovsky wrote:
Hello Daniel,Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc). As a trivial example I'd really dislike a system where "for consistency" we force BSPs to call something "UART-0" when the silkscreen (or front-panel) says "DB9-1". I guess that is an argument *against* board-to-board consistency! Daniel.
|
|
Erwan Gouriou
Hi Paul,
For STM32, my view is as follows: I understand the concern and need for having naming consistency, thought, I'm concerned about different instances numbering. Some starts from 0, some starts from 1: UART_1 in ref manual being referenced as UART_2 in Zephyr could be source of error. At least keeping numbering (or "lettering" for A/B/C) consistent from board/manual to API is required from my point of view. Then I'm ok if there is a naming convention "UART_x" accross vendors. Erwan
|
|
Chuck Jordan <Chuck.Jordan@...>
Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). As a trivial example I'd really dislike a system where "for consistency" I guess that is an argument *against* board-to-board consistency![chuck] Minor point, but the device driver talks to a UART and the UART may have a different designation on the schematic, not visible to the outside user. A name like "DB9-1" is a physical connector name, and it can be unclear which UART is attached to it, which jumpers need to be changed, whether there is another layer of switching between UART and connector and so forth. I've seen boards where a UART can be directed to one of many different connectors via jumper choices. So opening "DB9-1" might fail if the jumpers are wrong, for example. Driver is for UART only ... not the physical wiring beyond the UART.
|
|
Andy Gross
On 9 February 2017 at 03:52, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:Right now the device names are defined in the Kconfig options. TheOn 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:So, if I get this right, this is device-tree aliases being used toOn 06/02/17 13:34, Paul Sokolovsky wrote:The alias {} node can indeed be used for this. But unless we define a device tree aims to replace that by determining that via the contents of the device tree file. Not only the device name needs to be derived but also the current information that is fixed up by the fixup file. So from a Linux perspective, the alias is used by client programs to determine the device node for specific things. A good example is mapping of serial ports to make sure the console ends up on the right device. In the zephyr use case, we don't care about client programs using the compiled blob. And we don't want to conflict with DTS files that have been imported from Linux and that need to work in both Zephyr and Linux (STM has some examples coming of this). One way around this collision is to follow the example of the zephyr entries in the chosen{} node. Perhaps it would be better to define a zephyr node that contains the zephyr specific mappings and the sram, flash, and console entries. That brings us to the device names themselves. I am of two minds on this. On one hand, the names need to match the names on the board or board documentation. It makes it difficult for users to have to determine the zephyr name that matches the silkscreen name. On the other hand, having all these different formats trigger my OCD. I feel stronger about the silkscreen/documentation matching the names. So place my vote in the chaos column. As for matching device names to #defines to device tree data, I think the solution for that lies in the YAML file itself. As part of the config, we put in the device name we want and this is used to parse the DT and get the right mapping. In addition this allows us to generate whatever device specific prefix we need. Regards, Andy
|
|
Jon Medhurst (Tixy) <tixy@...>
On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
As for matching device names to #defines to device tree data, I thinkHmm, my concern was about having to have per-board or per-soc yaml files (which I think is a wrong step) e.g. to have to do mappings from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems to me that DT parser can be smart and sort things by <REG_ADDRESS> and assign them instance numbers 0..N. Also, if Zephyr device drivers are changed to use macro prefixes that match device-tree compatibles, there is also no need for any driver specific name mangling either. E.g. if device-tree has: uart@12340000 { compatible = "foo,bar-uart"; reg = 0x12340000; initerrupts = <11>, <12>; initerrupt-names = "rx", "tx"; } the DT parser outputs generated header with defines like: #define FOO_BAR_UART_0 /* So we can easily test it exists */ #define FOO_BAR_UART_0_BASE_ADDRESS 0x12340000 #define FOO_BAR_UART_0_INTERRUPT_RX 11 #define FOO_BAR_UART_0_INTERRUPT_TX 12 Then current device drivers can just change the macro names it uses to match that. And, for a transitional arrangement if there are still non- DT users of the driver needing the Kconfig way, the driver can #if !defined(FOO_BAR_UART_0_VALUE) && defined(CONFIG_FOOBAR_VALUE) #define FOO_BAR_UART_0_VALUE CONFIG_FOOBAR_VALUE #endif Basically, I can see that device-driver specific config (e.g. the yaml files) are going to be needed to specify things like Kconfig options required to enable a driver, and for constructing data structures needed for its initialisation (replacing the current #define/#ifdef/Kconfig mess) but I don't see it as a good step if we _add_ to the the current problem in the intermediate stages. E.g. by adding any per board or soc yaml config or 'fixup' files. -- Tixy
|
|
Daniel Thompson <daniel.thompson@...>
On 09/02/17 19:27, Chuck Jordan wrote:
Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). [chuck] Minor point, but the device driver talks to a UART and theQuite so, board designers have so many different ways they can make serial ports harder than necessary to use. In fact that's *exactly* why peripheral naming needs ultimately should be a per-board decision in the BSP (possibly expressed via DT). Note that this does *not* mean that SoC-wide defaults are bad. SoC-wide defaults are great and simplify things for uses of sane or simple board designs. So opening "DB9-1" might fail if the jumpers areBoards like this are rare and the BSP still has the option to call it whatever is neccessary to disambiguate. Daniel.
|
|
Paul Sokolovsky
Hello Maureen,
toggle quoted messageShow quoted text
On Tue, 7 Feb 2017 21:45:24 +0000
Maureen Helm <maureen.helm@nxp.com> wrote: [] Thanks for understanding of these issues.1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!)This is my fault. I was not aware the port names were being used this [] Ok, let me also start with facts (in preference of starting with my ownThe question what to do about this. Possible high-level approachesSince you're most affected, mind making a proposal? opinion). 1. So, mentioned previously Zephyr.js project has code like this: https://github.com/01org/zephyr.js/blob/master/src/zjs_gpio.c#L459 . In other words, Zephyr.js expects GPIO_0, GPIO_1, GPIO_2, etc. It used to be a fatal error if any device could not be opened. Couple of months ago I contributed a patch which makes it a non-fatal condition, at at the same time argued that it wouldn't scale for Zephyr.js to use such naming and make other assumptions, like the # of ports available, etc. 2. Let's see how GPIO devices are named across various ports in 1.6.0 (I take that version as having old naming for Kinetis ports). (The list is made using manual filtering of grep -i -r '"GPIO' results): The config params for naming is also split between: arch/ : arc/soc/em9d/Kconfig.defconfig: default "GPIO_PORTA" arc/soc/em11d/Kconfig.defconfig: default "GPIO_PORTB" arc/soc/em7d/Kconfig.defconfig: default "GPIO_PORTC" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_CW" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_RW" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_0" and drivers/gpio/: gpio_stm32.c:GPIO_DEVICE_INIT("GPIOA", a, GPIOA_BASE, STM32_PORTA, Kconfig.cmsdk_ahb: default "GPIO_0" Kconfig.dw: default "GPIO_0" Kconfig.k64: default "GPIO_0" Kconfig.nrf5: default "GPIO_0" Kconfig.pcal9535a: default "GPIO_P0" Kconfig.qmsi: default "GPIO_0" Kconfig.qmsi: default "GPIO_SS_1" Kconfig.sch: default "GPIO_0" So, from this listing it's clear that simplistic "use numbers for identification, start from 0", as assumed by the Z.js code above, wouldn't be achievable. One basic reason is given by Erwan Gouriou in his response - if a vendor datasheet names devices (not necessarily GPIO ports) from 1, and not 0, then it would be hard time to argue that Zephyr should still count from 0, as indeed, that would be recurring confusion point. That would mean that point "b) Send a strong message to application developers that they should not rely on any patterns of Zephyr device naming" would be there no matter what. Does that mean that there should not be any convention to Zephyr device naming? Just as other participants in the discussion, I think it's better to have them, because lack of conventions and directions may mean that there would be "random" changes, as in case of Kinetis/MCUX port name change discussed above. Looking at the grep results above, I'd formulate guidelines as: 1. Devices of similar type should have consistent prefix, e.g. "GPIO_", "I2C_", etc. 2. Device name should be uppercase. 3. Underscores should be used as separators. 4. Device type prefix should be separated by an underscore too (all devicenames above follow that, except stm32 with "GPIOA", "GPIOB", etc.) 5. Device names should be short and avoid having superfluous parts. E.g., it's a basic GPIO hardware fact that GPIO ping go packed in ports. So, "GPIO_PORTA" is way too verbose and doesn't convey much useful information in its "PORT" part. Examples of good names: GPIO_0, GPIO_99, GPIO_A, GPIO_AA (27th port), GPIO_SS_0 (as used by multicore-core Quark SoC above to differentiate ports on different cores, hard to argue they shouldn't be doing that, though I have no idea what "SS" means). Examples of bad names: GPIOA (missing underscore), GPIO_PORTA (too verbose, "PORT" is superfluous), GPIO_P0 ("P" apparently means port, superfluous), gpio_1 (should be upper case), PIN_1 (even if it happens to be 1 pin on a port, follow the standard prefix), GPO_1 (even if it's output-only port/pin, follow the standard prefix). []b) Send a strong message to application developers that they should -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Paul Sokolovsky
Hello Daniel,
On Fri, 10 Feb 2017 11:54:27 +0000 Daniel Thompson <daniel.thompson@linaro.org> wrote: On 09/02/17 19:27, Chuck Jordan wrote:To clarify, the concern behind my original mail is exactly regardingPersonally I'm not a fan of gratuitously different naming (for having a good consistent scheme for "SoC-wide defaults". Across SoCs of course, and with an idea that "reference" boards for these SoCs (as available in Zephyr upstream) would follow them. With a usecase you present above - support for widely varying OEM boards, I agree that it should be possible to override "anything", and the only scalable way to do that appears to be the Device Tree. (I would argue whether each and every OEM should override too much for a particular board, and if many actually would do that, but that's not the point of the discussion, it instead being that Zephyr should provide flexibility to do so, while hopefully also giving good guidelines on suggested naming, and provide in-tree device ports which adhere to these guidelines). [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Paul Sokolovsky
Hello Andy,
toggle quoted messageShow quoted text
On Thu, 9 Feb 2017 22:56:40 -0600
Andy Gross <andy.gross@linaro.org> wrote: [] That brings us to the device names themselves. I am of two minds onWell, there're dozens of architectures in the world. Thousands of individual SoC/MCU models using them, and millions of individual board models using those SoCs. Generally, no OS can support this million-variety upstream, and even if it gives *perfect* and the *easiest* to use tools for that downstream, a lot of vendors behind those millions of boards still won't use them right or at all (projections roughly based on the Linux experience). So, the talk is that "SoC" level should be the primary, and naming for one SoC should be reasonably consistent with all the rest. Than a board OEM can save a bunch of trouble both themselves and their users by just naming their board signals what the SoC calls them - or go thru the trouble of overriding them on OS, etc. levels, documenting how their virtual signals map to real SoC's, etc. [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Paul Sokolovsky
On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote: On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:I understand this discusses details of DT bindings and processing, butAs for matching device names to #defines to device tree data, IHmm, my concern was about having to have per-board or per-soc yaml for my own and other folks' understanding, I'd like to point that for a device name (as in: the string you pass to device_get_binding() indeed), any automatic means of derivation e.g. based on base address won't work. That's because ultimately these names should match a datasheet (I guess it would be hard to find someone who'd challenge that), and those means of identification are vendor-specific and look arbitrary for the reset of the world. For example, UART1's base address doesn't have to be greater than UART0's. Examples of identification starting from 1 and using other sequences (e.g. letters) were given before. And there can be arbitrary gaps, e.g. a specific SoC may have Timers: 3, 4, and 7 (ditto for GPIO ports, ditto for anything). [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Jon Medhurst (Tixy) <tixy@...>
On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:
Yes, I agree with that. That's why I original asked about which 'name'Hmm, my concern was about having to have per-board or per-soc yamlI understand this discusses details of DT bindings and processing, but aliases in DT we're being used for, a) the name you pass to device_get_binding, or b) the name used in C macro name inside the device implementation, or, I guess c) both, if you have different aliases to do that. a) makes sense and what this email thread seems to agree on, but b) was what was hinted at when I asked about avoiding the need for the current fixup file workaround in the RFC patchset. So I was trying to get some clarity. (Guess that means I sorta hijacked the thread, sorry) -- Tixy
|
|
Paul Sokolovsky
On Fri, 10 Feb 2017 15:08:29 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote: On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:Nope, I really appreciate different people approaching this fromYes, I agree with that. That's why I original asked about which 'name'Hmm, my concern was about having to have per-board or per-soc yamlI understand this discusses details of DT bindings and processing, different sides, and considering the usecases and details they have in mind. Well, I myself raised it with just one case in mind: how Zephyr middleware like Zephyr.js, MicroPython, etc. can deal with that, but of course there're more facets to it. And I don't hold my breath for an immediate solution, but starting to search for a common ground is definitely useful. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
Andy Gross
On 10 February 2017 at 08:43, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote: On Fri, 10 Feb 2017 11:47:02 +0000SoC uart mappings are one thing. Board uart mappings are another. SoC uart mappings are merely assigning an index to a base address and then generating the label based on some prefix. The yaml is just about how to parse and build up the labels for the contents of the DT. The DT needs to specify what the board uart mappings are and you will have a per board DT file which includes a SoC file. And with a DT overlay, we can then support application layer changes which today are done in the prj files. The thing is, there is the datasheet and there is the board. From a end user perspective, the only thing that matters is the board's labeling. Board uart 0 may be SoC uart 3. And they did that because they couldn't use uart0 because the rx/tx pins for that were being used for something else. And, the base address can't really be used to derive index because there are plenty of vendors who don't to ordered addresses on nodes, or they skip around. On top of that, what if you have more than one unique UART IP on the board? Which is uart0 then? For example, UART1's base address doesn't have to be greater thanExactly.
|
|
Chuck Jordan <Chuck.Jordan@...>
Actually, I'm leaning toward the opinion that the names of the I/O shouldn't matter.
toggle quoted messageShow quoted text
But what does matter, are the properties associated with that object. Take GPIO, for example. Some GPIO implementation may support special capabilities like debounce and interrupts. Other GPIO may not. So given a NAME of an instance, you would want some means of fetching the "gestalt" (old Apple term) for that object. Each named I/O instance, register with the I/O subsystem, probably needs to have "key-value" pairs that convey things about the instance. You would also need to be able to iterate over I/O instances, and FILTER thru them to find ones that have the capabilities you're looking for. For example, you might want to search all I/O that are both GPIO, have DEBOUNCE and have INTERRUPT capability. Or, suppose you want to search thru all I/O that is UART, and can support baud rates greater than 115200. Or to search for a file-system capable mass storage device that has free space greater than 1MB. The I/O abstraction layer should provide these details. This allows the application developer, once they've figured out what name to use during an OPEN, to also check, via ioctl or some such, that their I/O is capable of supporting what they are after. So the problem is not just knowing the name, its also knowing whether that named instance has the right-stuff. -ChuckJ
-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky Sent: Friday, February 10, 2017 4:31 AM To: Maureen Helm <maureen.helm@nxp.com> Cc: devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] Inconsistent and ever-changing device naming in Zephyr Hello Maureen, On Tue, 7 Feb 2017 21:45:24 +0000 Maureen Helm <maureen.helm@nxp.com> wrote: [] Thanks for understanding of these issues.1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!)This is my fault. I was not aware the port names were being used this [] Ok, let me also start with facts (in preference of starting with my own opinion).The question what to do about this. Possible high-level approachesSince you're most affected, mind making a proposal? 1. So, mentioned previously Zephyr.js project has code like this: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_01org_zephyr.js_blob_master_src_zjs-5Fgpio.c-23L459&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=EcdSrQuy87WyLUQVduyfZhZloOcN8_WXoy128Vjhbjo&e= . In other words, Zephyr.js expects GPIO_0, GPIO_1, GPIO_2, etc. It used to be a fatal error if any device could not be opened. Couple of months ago I contributed a patch which makes it a non-fatal condition, at at the same time argued that it wouldn't scale for Zephyr.js to use such naming and make other assumptions, like the # of ports available, etc. 2. Let's see how GPIO devices are named across various ports in 1.6.0 (I take that version as having old naming for Kinetis ports). (The list is made using manual filtering of grep -i -r '"GPIO' results): The config params for naming is also split between: arch/ : arc/soc/em9d/Kconfig.defconfig: default "GPIO_PORTA" arc/soc/em11d/Kconfig.defconfig: default "GPIO_PORTB" arc/soc/em7d/Kconfig.defconfig: default "GPIO_PORTC" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_CW" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_RW" x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_0" and drivers/gpio/: gpio_stm32.c:GPIO_DEVICE_INIT("GPIOA", a, GPIOA_BASE, STM32_PORTA, Kconfig.cmsdk_ahb: default "GPIO_0" Kconfig.dw: default "GPIO_0" Kconfig.k64: default "GPIO_0" Kconfig.nrf5: default "GPIO_0" Kconfig.pcal9535a: default "GPIO_P0" Kconfig.qmsi: default "GPIO_0" Kconfig.qmsi: default "GPIO_SS_1" Kconfig.sch: default "GPIO_0" So, from this listing it's clear that simplistic "use numbers for identification, start from 0", as assumed by the Z.js code above, wouldn't be achievable. One basic reason is given by Erwan Gouriou in his response - if a vendor datasheet names devices (not necessarily GPIO ports) from 1, and not 0, then it would be hard time to argue that Zephyr should still count from 0, as indeed, that would be recurring confusion point. That would mean that point "b) Send a strong message to application developers that they should not rely on any patterns of Zephyr device naming" would be there no matter what. Does that mean that there should not be any convention to Zephyr device naming? Just as other participants in the discussion, I think it's better to have them, because lack of conventions and directions may mean that there would be "random" changes, as in case of Kinetis/MCUX port name change discussed above. Looking at the grep results above, I'd formulate guidelines as: 1. Devices of similar type should have consistent prefix, e.g. "GPIO_", "I2C_", etc. 2. Device name should be uppercase. 3. Underscores should be used as separators. 4. Device type prefix should be separated by an underscore too (all devicenames above follow that, except stm32 with "GPIOA", "GPIOB", etc.) 5. Device names should be short and avoid having superfluous parts. E.g., it's a basic GPIO hardware fact that GPIO ping go packed in ports. So, "GPIO_PORTA" is way too verbose and doesn't convey much useful information in its "PORT" part. Examples of good names: GPIO_0, GPIO_99, GPIO_A, GPIO_AA (27th port), GPIO_SS_0 (as used by multicore-core Quark SoC above to differentiate ports on different cores, hard to argue they shouldn't be doing that, though I have no idea what "SS" means). Examples of bad names: GPIOA (missing underscore), GPIO_PORTA (too verbose, "PORT" is superfluous), GPIO_P0 ("P" apparently means port, superfluous), gpio_1 (should be upper case), PIN_1 (even if it happens to be 1 pin on a port, follow the standard prefix), GPO_1 (even if it's output-only port/pin, follow the standard prefix). []b) Send a strong message to application developers that they should -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_pages_Linaro&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=ZKgYBpmkadgt4k-GWgxk0qpEr54xDeQDKSf-91I0unU&e= https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_-23-21_linaroorg&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=pO_5cWLMg5XInmbA0OiEkBQSYK6IbxbX9-lnHVlwirA&e= - https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linaro.org_linaro-2Dblog&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=CAFTnOsX1RZEqPKcLxbzK6nNCHo37S76ZsuUf6UNfqk&e= _______________________________________________ Zephyr-devel mailing list Zephyr-devel@lists.zephyrproject.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=NICXw6qnd35aaKp2WfCFJND4zLjD53CZSxNLBk8sOkI&e=
|
|