@marcan oh yeah, I don't mean dragging the entire subsystem and all of the leaves along, I meant treating this all as one big driver and pulling in what you need from those subsystems. Guessing still too big a lift?
Top-level
@marcan oh yeah, I don't mean dragging the entire subsystem and all of the leaves along, I meant treating this all as one big driver and pulling in what you need from those subsystems. Guessing still too big a lift? 2 comments
|
@sawyerbergeron I'm leaning towards that option if the current approach ends up completely nonviable, but it would still require at least a pretty horrible patchset to a few other drivers to make them play nicely. E.g. we will probably have to add some kind of ugly hooks to dwc3 so it can call into the PHY driver in more, fine-grained places. And also get rid of its workqueue nonsense for role-switch actions, since running stuff in other threads is a recipe for disaster. The only way this is going to work and be robust is if all the mode changes and init/shutdown logic runs within a single (logical) thread (per Type C port/controller). And then we need to do something about tipd, though I'm starting to lean towards "fork/rewrite it", given how much Apple's variant is already diverging from upstream tipd, and how the non-Apple tipd driver is very barebones and has no altmode support at all anyway.
But then the question remains, is this ever going to be upstreamable. Because if it isn't, we lose long term.
@sawyerbergeron I'm leaning towards that option if the current approach ends up completely nonviable, but it would still require at least a pretty horrible patchset to a few other drivers to make them play nicely. E.g. we will probably have to add some kind of ugly hooks to dwc3 so it can call into the PHY driver in more, fine-grained places. And also get rid of its workqueue nonsense for role-switch actions, since running stuff in other threads is a recipe for disaster. The only way this is going...