MAINTAINERS.yml: drivers: ethernet: add usb ethernet drivers #100435
Conversation
add usb ethernet/networking drivers to ethernet drivers area, as they use the ethernet api. Generally I would like them to move, buts that's for later. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
|
jfischer-no
left a comment
jfischer-no
left a comment
There was a problem hiding this comment.
I do not think it makes sense to move them, as all the emulated drivers are inside the USB folder, nor to add you as a maintainer to these files.
They are ethernet devices and drivers and therefore should be part of the ethernet drivers. |
No. There is nothing that forces them to be part of "the ethernet drivers". They are very specific to the USB device stack and are maintained as part of the built-in functions. Under no circumstances will I agree to move them to a different location. Furthermore, you did not contribute anything to USB or these functions, and I am not only talking about the code, so you cannot even be considered as contributor to this area or files.
Not even. They are emulated.
They also use UDC API and USBD class API. That are two USB APIs versus not existing Ethernet driver API (where is include/zephyr/drivers/ethernet.h ?). Look, there are also different USB functions used as backends for something across the tree, and they use USB APIs, but I would not claiming maintainership over these, even though I wrote some of them or contributed to them. |
|
IMHO I would keep these under USB subsystem as they are more "related" to USB than to Ethernet. |
agree. The ownership or maintainership here is not being moved, it is being duplicated creating confusion about who actually maintains those, there is not good reason for duplicating the entries. If the intention is to get notified and to collaborate on the ethernet functionality, a file group within usb can be created where collaborators for those specific file can be added. |
IMO this is not that different to the Platform areas (STM, NXP, Nordic, ...), that also overlap with the Driver Areas. If a driver is using a api from the vendor hal or if it is using another subsystem, it is not that different. Vendors could also put all their drivers into their hal module, but I don't think that is what is wanted. So why should it be different for subsystems. |
6 participants
add usb ethernet/networking drivers to
ethernet drivers area, as they use the
ethernet api. Generally I would like them
to move, buts that's for later.