lib: system: zephyr: Use default metal_generic_bus

[glneo]

The only difference is the DMA ops, which the generic ops turns into simple cache operation which zephyr does support.

[arnopo]

Code around metal_generic_dev_xxx is quite old and odd
As you mention map/unmap operation in zephyr is not supported. So seems better to having a structure that points to the ops. Except if you see a blocking point that would require this update...

[glneo]

No blocking point, this was just a general cleanup I noticed while fixing other things.

I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

[arnopo]

No blocking point, this was just a general cleanup I noticed while fixing other things.

I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

[tnmysh]

No blocking point, this was just a general cleanup I noticed while fixing other things.
I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

Agree with Arnaud.

[edmooring]

No blocking point, this was just a general cleanup I noticed while fixing other things.
I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

Agreed. We are between a rock and a hard place because of the demands of supporting Linux user space. It may be that the kernel's support for userspace drivers has advanced enough in the 8 years since libmetal was originally implemented that there is a simpler way now, but that is far out of the scope of what this PR is doing.

[edmooring]

This looks good to go.

[github-actions]

This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity.