Hello,

I am looking for an advice regarding board code that needs to call driver upper half after the device is registered.

As far as I understand it, the usual code flow is like this:

- board code calls lower_half_register function, provides filesystem path and other parameters
- lower half calls upper_half_register function
- upper half calls register_driver
- only integer status is returned to board code, the only information available is therefore the filesystem path and the configuration given

To be specific - I am attempting to implement byte reordering in WS2812 RGB LED upper half driver. These LEDs receive their data in green-red-blue order and that is what lower halves take care of when they receive RGB data from userspace. Upper half just passes data back and forth. However, I encountered a variant of these LEDs which for some reason wants the data in red-green-blue order.

The reordering could be done in (every) lower half but it seems to me that this is a job for common code. I have an initial implementation ready and working, it adds some fields to ws2812_dev_s and based on settings in those fields, the upper half optionally reorders the data. The question is, how to configure this.

It seems to me that this should be done by upper half code since the functionality is isolated in upper half. Let's say like this

- board code calls lower_half_register, the call chain happens as mentioned above
- board code calls something like upper_half_configure

However, I found no way to obtain any handle for the driver instance that could be used for the upper half call

This somewhat looks like a job for ioctl but I want to avoid that one since I don't think this should be exposed to the userspace. The board code knows what LEDs are connected to it after all, it's not the job for the application to deal with that in my opinion.

Another (fallback) option is to provide the needed configuration to the lower_half_register but I would like it if it was possible to implement without the need to change all the lower halves and all of their call sites (ie. to made it available for all board code easily)

Any pointers/ideas are appreciated

If anyone wants to look at what I am trying to achieve, initial implementation is available in my "nuttx.git" repository at git.kerogit.eu accessible through HTTP/S. The relevant branch is named avrdx_ws2812_upstream_v2 - last two patches (the other patches are for the AVR driver lower half itself and for support infrastructure - to be merged hopefully but not merged yet, waiting in PR queue for 2nd review.)

Reply via email to