worldsemi,ws2812-(gpio|rpi_pico-pio) pin property change into gpios

[soburi]

ws2812-gpio's in-gpios property is not used as an input pin.
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/led_strip/ws2812_gpio.c#L239

Renaming it to gpios to reflect the actual situation.

For sharing pin definition property among worldsemi,ws2812-gpio and worldsemi,ws2812-rpi_pico-pio,
rename output-pin to gpios.

[nordicjm]

This doesn't really make sense, it it still the output pin from the MCU side, it should remain named as output. You wouldn't name the MISO pin on an SPI bus as "output-gpios" because it's an output from the sensor side.

[soburi]

@nordicjm
Thank you for comment.

I am also aware of the contradictions and will consider them as well.
It's a definition borrowed from ws2812-gpio, and also the original doesn't seem to be good.

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/led_strip/ws2812_gpio.c#L239

This code uses in_gpio as output....

I think this is also included the scope for reconsideration.

I was looking at the review request for #67610.
I'm considering to create common-named gpio property between ws2812-gpio and ws2812-rpi-pico-pio for enabling to define common overlay.

I was interrupted and didn't pay attention to the details. Sorry for the confusion.

[raveious]

I think a more common binding would probably be a good idea. With all of the different variations of the binding and drivers, you almost have to do something like what I did in #67610 did in order to get many boards supported.

[soburi]

Since we are using a shield, I would like to describe the pins with connector definition.

In this case, such like below,

&bff_led_strip {
	output-pin = <&xiao_d 3 GPIO_ACTIVE_HIGH>;
};

To do that, we need to change the output-pin definition on the ws2812-rpi_pico-gpio side to one based on gpio.
I don't think the change is any major problems with this, and I think it will be a good improvement.

By the way, as shown above, if only the gpio pin is defined in overlay, it seems that ws2812-gpio and ws2812-rpi_pico-pio can share it if the gpio property name is the same.

Therefore, I am thinking of standardizing the pin specifications for ws2812-gpio and ws2812-rpi_pico-pio.
As pointed out, the definition of ws2812-gpio is in-gpios, and the meaning of the name is inconsistent with this one.
I think if I include this in the correction, you will be able to write the definition of shield neatly.

With all of the different variations of the binding and drivers, you almost have to do something like what I did in #67610 did in order to get many boards supported.

Since it is not possible to define a shield more over than "Use pin 3 of the Xiao Header", it is inevitable that the boards/*.overlay included in the shield directory will need to be supported.
Even though, I still think it is better to have a common definition that can be created more clearly than just a placeholder.

[simonguinot]

Hi @soburi,

This change looks good to me and I am not sure why this DT property was named in-gpios in a first place. Maybe @mbolivar-ampere can tell us more ?

In addition this PR breaks backwards compatibility of the worldsemi,ws2812-gpio DT node. And I suspect that a comment in doc/releases/migration-guide-3.6.rst won't cut it :) For example in doc/develop/api/api_lifecycle.rst I read that an RFC issue should be open for a breaking API change. Unfortunately I am not familiar with this procedure. So we need to ask for help here.

And to finish, you'll find my only comment below.

[soburi]

@simonguinot

Thank you for comment.

In addition this PR breaks backwards compatibility of the worldsemi,ws2812-gpio DT node. And I suspect that a comment in doc/releases/migration-guide-3.6.rst won't cut it :) For example in doc/develop/api/api_lifecycle.rst I read that an RFC issue should be open for a breaking API change. Unfortunately I am not familiar with this procedure. So we need to ask for help here.

@kartben

If you know of any rules that should be followed regarding this, please let me know.

Release notes comment addressed.

[raveious]

No new comments that aren't covered by others.

[soburi]

Rebased to after hwmv2 world.

[soburi]

CI error seems not related to this change.
May be somethings broken in hwmv2 changes.

hwmv2 applied

[nordicjm]

There is an overlay being applied to the network core which it should not because the network core does not have an i2s instance on nrf5340

[soburi]

@nordicjm

There is an overlay being applied to the network core which it should not because the network core does not have an i2s instance on nrf5340

Thank you for the notification.
I fixed it with renaming the files in the boards.