usb: make device-next default and move legacy sample code to legacy directory

[jfischer-no]

Make USB device-next samples default and move legacy code to legacy directory.

[tmon-nordic]

There are also some CDC ACM twister failures, some where both USB stacks seem to be active simultaneously and some where there doesn't seem to be CDC ACM devicetree instance.

[henrikbrixandersen]

Pretty much same comment as last time this was proposed (see #80985 (comment)):

As already stated in an earlier comment on this PR (#80985 (review)) I do not think "device_next" is ready becoming the default USB device stack in Zephyr v4.1.

There's the issue with lack of "vendor" testing (tested it on a random selection of development boards, three of the new USB device drivers failed to enumerate on MS Windows), the lack of support for a number of platforms (I know some people find it acceptable to "leave these behind"), the list of open bug reports - and especially the vastly increased RAM/ROM footprint as reported in #83309. These are all mentioned in #42066 but not yet handled with 9 days until v4.1 feature freeze.

[carlescufi]

the lack of support for a number of platforms (I know some people find it acceptable to "leave these behind"),

We agreed those would not be a factor I believe, after I sent an informative email to devel@

the list of open bug reports

Which are those? I am not familiar with these.

and especially the vastly increased RAM/ROM footprint as reported in #83309.

Agreed, this needs to be addressed.

[henrikbrixandersen]

Which are those? I am not familiar with these.

I meant the open issues reported against the device_next stack here on GitHub. Personally, I think the following would be relevant to look at before making this the default stack. Some of these have gone months without any maintainer feedback:

• usb: device: next: increased RAM and flash footprint with "device_next" USB stack #83309
• UDC events silently dropped on queue full lead to USB stack issues #74058
• USB device serial numbers may change between current device stack and the device_next stack #78979
• USB next stack: make SOF events optional #87732 (brought up by before in drivers: usb: udc: add USB device controller SoF report capability #76073 (comment))
• USB NEXT: Error while adding interface string descriptor #86718

[carlescufi]

I meant the open issues reported against the device_next stack here on GitHub. Personally, I think the following would be relevant to look at before making this the default stack. Some of these have gone months without any maintainer feedback:

I agree with you. @jfischer-no and @tmon-nordic could you please go over these and see what can be fixed?

[jfischer-no]

I meant the open issues reported against the device_next stack here on GitHub. Personally, I think the following would be relevant to look at before making this the default stack. Some of these have gone months without any maintainer feedback:

I agree with you. @jfischer-no and @tmon-nordic could you please go over these and see what can be fixed?

I am on
#74058
#87732 (is not a bug)
#86718 (is not a bug)

[carlescufi]

@fabiobaltieri @henrikbrixandersen @nandojve @jukkar @tmon-nordic
Last push is just bringing the MCUboot commit into Zephyr's fork.

[hakehuang]

this breaks sample.net.sockets.http.server on many NXP platforms like mimxrt1170_evk

[ArekBalysNordic]

@jfischer-no The legacy USB driver has been deprecated. Where can I find a migration guide to the new USB driver?

[jfischer-no]

@jfischer-no The legacy USB driver has been deprecated. Where can I find a migration guide to the new USB driver?

There is no porting guide yet, but all the use cases are covered by the samples, so please take a look at samples/subsys/usb/cdc_acm, samples/subsys/usb/console, or, I guess, 895cc01 or 6c4847d may help you as well.