Email or username:

Password:

Forgot your password?
Hector's posts Post Back to profile
Top-level
Hector Martin

@sawyerbergeron Major refactors are not viable out-of-tree. It would increase our rebase workload significantly. The only things viable to carry out-of-tree for longer periods of time are small fixes and whole new drivers, not major subsystem changes.

13 January at 19:03 | Open on social.treehouse.systems
3 comments
Sawyer Bergeron

@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?

13 January at 19:11 | Open on fosstodon.org
Hector Martin

@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...

13 January at 19:59 | Open on social.treehouse.systems
Raven667

@marcan @sawyerbergeron I'm no hardware engineer so I'm talking out of my ass here, but the way you describe it it seems like forking the relevant driver(s) and making a hacky prototype would allow you to get something working and tested out the door, then you would know more exactly what the scope of work would be to refactor/rewrite in a production/upstream ready style and what kind of glue would be needed to do all the work that ACPI/firmware provide on other systems, trying to make it production ready from the jump seems like it's a lot harder than you'd like. I suppose the problem for you (and all those other vendors out there) is that if there is no time to rewrite it later, then the time you put in now is the only time you'll have to work on it with this intensity, once it works you'll have other top priorities so if you only end up with a hacky prototype then maintaining it will become burden that takes time away from a production ready version being developed.

@marcan @sawyerbergeron I'm no hardware engineer so I'm talking out of my ass here, but the way you describe it it seems like forking the relevant driver(s) and making a hacky prototype would allow you to get something working and tested out the door, then you would know more exactly what the scope of work would be to refactor/rewrite in a production/upstream ready style and what kind of glue would be needed to do all the work that ACPI/firmware provide on other systems, trying to make it production...

14 January at 6:33 | Open on hachyderm.io
Go Up