Skip to content

usb: Use composite equipment codes as universal codes for enumeration#10084

Closed
zyfeier wants to merge 3 commits into
apache:masterfrom
zyfeier:usb_3
Closed

usb: Use composite equipment codes as universal codes for enumeration#10084
zyfeier wants to merge 3 commits into
apache:masterfrom
zyfeier:usb_3

Conversation

@zyfeier
Copy link
Copy Markdown
Contributor

@zyfeier zyfeier commented Aug 4, 2023

Summary

The enumeration process in each class driver is similar. Extracting the common enumeration process code to composite.c can reduce redundant code. In this PR, only the adb class has been modified, and it will be applicable to all classes in the next PR.

Impact

usb enumeration

Testing

sim:usbdev and bes board

zhangyuan21 added 3 commits August 4, 2023 17:09
The enumeration process for composite and non-composite devices
has a lot of duplicate code. Treating the code for composite
devices as universal enumeration code can reduce redundant code.

Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
@raiden00pl
Copy link
Copy Markdown
Member

I don't think coupling USB device class logic with composite device logic is a good idea. These are two separate functionalities, and device class logic should not depend on composite logic.

Why not move the common USB device logic to a separate file, private for drivers/usbdev e.g. usbdev_common.c/usbdev_common.h ?

@zyfeier
Copy link
Copy Markdown
Contributor Author

zyfeier commented Aug 7, 2023

I don't think coupling USB device class logic with composite device logic is a good idea. These are two separate functionalities, and device class logic should not depend on composite logic.

Why not move the common USB device logic to a separate file, private for drivers/usbdev e.g. usbdev_common.c/usbdev_common.h ?

Hi, raiden00pl:
I initially extracted the common code, but found that it was almost identical to the code in composite.c. Additionally, the main difference between composite and non-composite devices is that composite devices support multiple functions, which can be distinguished through configuration. Therefore, I felt that it was more appropriate to directly use composite.c.

@raiden00pl
Copy link
Copy Markdown
Member

Then composite devices and other USB devices should use common USB device logic. Now the code gives the impression that non-composite USB device is just composite device with one supported device - which is wrong and confusing.

@xiaoxiang781216
Copy link
Copy Markdown
Contributor

Then composite devices and other USB devices should use common USB device logic. Now the code gives the impression that non-composite USB device is just composite device with one supported device - which is wrong and confusing.

so @raiden00pl do you want to rename the current composite driver to a general name and let's composite driver forward the call to these common function?

@raiden00pl
Copy link
Copy Markdown
Member

@xiaoxiang781216 it would actually make sense that way but composite specific functionality should be keep in the composite.c (eg. composite_ep0submit())

@xiaoxiang781216
Copy link
Copy Markdown
Contributor

Ok, let's do it in the next step.

@zyfeier zyfeier deleted the usb_3 branch August 11, 2023 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants