Standardize labels (string device names) used for device binding

[pdunaj]

To simplify OS API and allow cross platform application development it would be great if Zephyr defined a way in which device binding labels are set up.

At the moment there seem to be a mess with this. Let's take GPIO as an example.
Most SoCs have its label defined as "GPIO_0" the problem is that there is nothing in documentation that would say that using "GPIO_0" for binding will work for every system. As such strings can be (and for some devices are) configurable which make them unreliable.

On the other hand SoCs define dts fixups or specify labels that are macros pointing to the right name. This would be great solution but the name of label differs between SoC vendors. Zephyr does not define that to correctly bind to GPIO_0 you should use for example MAGIC_MACRO_GPIO_0_LABEL and on whatever platform you compile you will always get GPIO instance 0 as long as it is there.

[pdunaj]

@barsok ping

[erwango]

This topic has already been discussed long time back.

Problem is that vendors documents quite different names for their IPs.
If Zephyr specifies GPIO_5, how can I map this to my STM32, NXP, ARC, ... devices, where reference manual deals with GPIOA, some start numbering with GPIO_1, etc .... ?

Though, dts could define aliases. They are already used in for leds and buttons:

	aliases {
		led0 = &green_led_1;
		led1 = &green_led_2;
		led2 = &bt_blue_led;
		sw0 = &user_button;
		bt = &bt0;
	};

I think this can be re-used for other devices to some extent. Not sure we can generalize this to all devices though.

[pdunaj]

Hi @erwango , code that you pasted is what I would expect the OS to do. Create a mapping between the application and devices. In Linux if I open /dev/fb0 or /dev/console do I care who is the vendor?

To show an example how simple it could be note that Zephyr OS could document that SoC vendor creating an UART driver must name UART in following way: "UART_n" when n is sequential number starting from zero and representing UART instance on the SoC. Then at least application would be left which a choice which UART to chose while at the moment you need to use macro to fine entire name as name of the device can change (e.g. UART could be named "MAGIC_CHARDEV_0").

This may not work for all devices obviously but there are some that can be obviously standardized: e.g. GPIO, LEDS or UART.

[pfalcon]

This topic has already been discussed long time back.

Specifically: https://lists.zephyrproject.org/g/devel/message/42

@pdunaj, I like your approach, of 2 cases brought by you I've seen so far, 2 I tried to move forward before too. Definitely try to push them forward, you have my +10 on any good RFC you bring up. But as I already said elsewhere, a word of warning: "nobody cares". That's blatant oversimplification of course, more like "everybody cares in different direction, and all that with 800+ tickets/250+ patches (i.e. so many other topics to care about) open all the time". It's not a discouragement either - vice versa, a good "pep talk" that you should be ready to be very persistent, flexible, and not give up for a long time.

[pfalcon]

Oh, and btw, last thing I heard is that "ascii device names" are to be gone. Calling @tbursztyka (with apology if I mixed up and I heard that from somebody else).

[pdunaj]

@pfalcon Thanks ;)

[tbursztyka]

@pfalcon no you're right, hopefully one day we'll get rid of these names (see Issue #6293). But first, device instantiation automation has to go in (DTS/Codegen and all), so it's a long shot.

[erwango]

Specifically: https://lists.zephyrproject.org/g/devel/message/42

Thanks @pfalcon for the digging.

@pdunaj

This may not work for all devices obviously but there are some that can be obviously standardized: e.g. GPIO, LEDS or UART.

So, I think lot of arguments were exposed in the discussion, but let me highlight on one specific aspect.
I don't think the parallel Zephyr/Linux always works. Zephyr user is usually close to the HW board. Since it is a common source of error, I personally often look at pin mapping and usually it is not the fun part. So when I do, I'm always happy to find matching names in code and documentation.
So I know: GPIO_H, pin_10 I call in my code matches with GPIO_H, pin_10 on my board schematics which matches GPIO_10, pin_10 in my SoC datasheet.
So if we want to keep Zephyr HW friendly, I think we should keep this.
And if we really want to constrain all devices to use the same GPIO,PIN numbering, you'll need to take into account the documentation effort for SoCs and boards.

In any case, I advise using dt aliases, which should do the trick for most of the usages I think.

EDIT: The discussion from the archives was mentioning "ever changing device naming", @pfaclcon, I know you spent much less time in micropython lately but, did you notice an evolution on that precise aspect?

[pdunaj]

I don't think the parallel Zephyr/Linux always works. Zephyr user is usually close to the HW board.

@erwango I agree that there are differences in the target audience. Still I expect that applications running on Zephyr will become more complex in the coming years. In the end if this would not be true there would be a little need for the OS. I think more and more people will move further away from HW as they will be less concerned about which pin to use and more about how to process data and provide a service to the customer.

[galak]

@pfalcon no you're right, hopefully one day we'll get rid of these names (see Issue #6293). But first, device instantiation automation has to go in (DTS/Codegen and all), so it's a long shot.

I was thinking about this with the recent jinja work. I think it might not be that difficult to provide a means to get the device object from a DT means w/o a string. I want to phase out label in DT, or at least using and requiring them the way we do.

[pfalcon]

I want to phase out label in DT, or at least using and requiring them the way we do.

Note that we'll need "ascii device name" for POSIX subsystem (if we want to move it further along). I would be about ready to implement support for the following code:

int fd = open("/dev/tty/UART0", O_RDWR);
// Let's reset that pesky modem
write(fd, "ATZ\r\n", 5);
...

[gmarull]

Closing as labels are going to be deprecated, there are now alternative ways to obtain a device reference.