zephyr: ADC: adc shell failure when mismatch with dts device label

Describe the bug using adc command forces adc ADC_0 when ADC_1 is the first enabled ADC, causing any command to fail with device is not in device list error

To Reproduce Try on any STM32 EVB

Expected behavior The root cause for this bug is the ambiguous use of the sub command name, here “ADC_0”, and the device label configured in the dts. if “ADC_0” means “the first enabled ADC instance” in line 45: .device_name = DT_INST_LABEL(inst), sets the device_name field in the hdl struct as “ADC_1”, the device label string defined in the dts. But, in line 111 in function get_adc_from_list(char *name): if (!strcmp(name, adc_list[adc_idx].device_name)) { it is compared to the argv parameter given, which is “ADC_0”. thus always failing the search.

Note: using “ADC_1” as shell parameter fails the shell core as this is not a valid subcommand.

This can happen in the following cases, which causes the enabled device under instance index x to no be labelled “ADC_x”:

1. The arch dts device label defines are not 0-based (like in STM32 which start at ADC_1)
2. The first enabled device is not ADC_0, but ADC_1, or 2
3. The arch dts doesn’t even use the ADC_x naming for its labels. it can be “A2D_0” (for digital-to-analog) or something like that.

Solution: I suggest avoiding the double use of ADC_x for both the subcommand syntax and the device label. using index only for the subcommand. using adc 0 read 15 for example.

If this “ADC_x” naming convention is necessary, using “ADC_0” for “first enabled instance” is wrong, and it should be “ADC_1” for the device label as defined in the dts. can be achieved by dynamically creating the subcommand syntax.

For now, this code is malfunctioning in every ST core we used.