Ability to use an API with device without extending its own API

[nordic-krch]

Is your feature request related to a problem? Please describe.
Recently a generic module appeared (onoff service) which fits into clock management (for limited devices) where multiple sources (clients) want to control state of the clock (service). However, currently there is no way to use that API on clock device without extending clock control API and community is reluctant to extend API's like that and expect to get mechanism which will allow to use device with external API.

Another, similar case appeared in SPI and I2C where new extension to the API which adds transaction support is discarded (#22371) because "transaction manager should become a generic module". Yet still there is no mechanism to use it with a device.

Describe the solution you'd like
I would like to see an API which will allow user to use another API (but supported by given device) as it cannot be used directly:

struct device *dev = get_device_binding(DEV_NAME);
struct onoff_client cli;

err = onoff_request(???, cli);

Something like:

struct device *dev = get_device_binding(DEV_NAME);
struct onoff_client cli;
struct onoff_service *srv = device_get_onoff_service(dev); /* Missing part */
if (srv == NULL) {
    //onoff service not supported by the device
    return;
}
err = onoff_request(srv, cli);

Solution should:

• take into consideration that multiple API's can be supported by a device
• perfomance
• memory constraints

To be checked it device specific API extensions (https://docs.zephyrproject.org/latest/reference/drivers/index.html#device-specific-api-extensions) could be used.

Alternative proposal #22409.

[nordic-krch]

Here is an example: clock_control driver which support onoff service. In order to use onoff service a reference to that service associated with given device needs to be fetched from the driver data:
https://github.com/nordic-krch/zephyr/blob/1acf5c77f9e996f91725f1f3ad7b64ad49273e70/drivers/timer/nrf_rtc_timer.c#L93

shortened version:

   struct onoff_service *srv;
   struct device *clock;

   clock = device_get_binding(DT_INST_0_NORDIC_NRF_CLOCK_LABEL);
   srv = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_LF);

   err = onoff_request(srv, &cli);

In that case custom api is used to fetch that data: z_nrf_clock_control_get_onoff() and it's ok here because it's nordic specific code but ideally there should be a method to get that service from device in a generic way.

[pabigot]

I think that example makes some assumptions that were not the assumptions under which the on-off service was designed. The expectation was that the existing or reworked clock control API would provide a wrapper function like clock_control_on() that would invoke the on-off service underneath.

Similarly for power management, which should be done through the device_pm_* interface even if an on-off service provides the underlying implementation.

The on-off service is not intended for direct use by users to perform state changes on core infrastructure. It does not incorporate syscall support and so probably can't be used from usermode. It is, in fact, not a driver or device API: it's a generic data structure analogous to a C++ class (state plus behavior) with simulated virtual functions (the service-specific transitions).

[nordic-krch]

well, i'm lost. I got the impression from @tbursztyka comment (#22371 (comment)) that he does not want to go into direction where specific api's are extended and if i understand you correctly you expected to see clock_control_request which wraps on-off functionality. I thought that in case of clock control we stick to current (low level) api with asynchronous/blocking on and off functions. For many cases where there is only one clock owner that is enough, for cases where clock is shared, clock is accessed by on-off api. in the implementation i started, mixing onoff with direct acceess returns error.

[carlescufi]

@jukkar would you mind linking to the way the networking stack does this already?

[jukkar]

here is no way to use that API on clock device without extending clock control API and community is reluctant to extend API's like that and expect to get mechanism which will allow to use device with external API.

After reading the description more carefully, I think my initial idea is not applicable here. We have some APIs in networking side, like network interface (include/net/net_if.h) and we extend that for Ethernet network interfaces (include/net/ethernet.h) that provides more functionality for the interface. But if that kind of extending is not wanted, then that idea cannot be used here.