On Mon, 2026-06-01 at 00:32 +0200, Danilo Krummrich wrote: > On Mon Jun 1, 2026 at 12:00 AM CEST, Markus Probst wrote: > > On Sun, 2026-05-31 at 23:49 +0200, Danilo Krummrich wrote: > > > On Sun May 31, 2026 at 9:42 PM CEST, Markus Probst wrote: > > > > I just noticed, is it even possible to use SRCU here? Currently the > > > > mutex not > > > > only ensures that no drvdata access happens after drvdata drop, but > > > > also that > > > > the receive_buf waits for the probe to complete, as the drvdata hasn't > > > > been > > > > initialized yet. > > > > > > Yeah, if you drop the completion, you need the mutex. > > Is the performance impact on an mutex or on srcu + completion higher? > > Weighing in the completion, the mutex probably wins as it will always be > uncontested under normal operation. > > > > > > > (In case it wasn't discussed in previous versions already, there is also > > > the > > > option to just attach separate private data to the receive callback, > > > which would > > > avoid this synchonization problem in the first place. > > > > > > You could have serdev::Device<Core>::open(), which takes its own private > > > data > > > and a corresponding close(), this way you'd allow drivers to control > > > whether > > > they want the serial line "open" or not. You just need to make sure it is > > > closed > > > eventually.) > > This would add complexity with types, as we need to ensure that write, > > set_baudrate, set_parity etc. does not run when closed. > > Right, but looking at a few serdev drivers, there seem to be a few cases where > drivers need to close and re-open. That is something we could consider once there is a user.
I am certain it would make it more complex, not less. > > > > That said, I don't know what turns out to be the better approach. And > > > maybe it > > > simply isn't something this initial series has to tackle? I think your > > > driver > > > does not implement the receive callback? > > The initial driver with only leds: no. > > > > That changes once the driver also takes care of hwmon (ADC sensor and > > fan failure) and input (power button and possibly other buttons). > > Maybe drop it from this initial series then and revisit with the first user? I would prefer it with this series. Except for probe and remove there should be no overhead if receive_buf is not implemented. As it will be needed eventually and it is basic serdev functionality, I don't see a reason to not include it now. Thanks - Markus Probst
signature.asc
Description: This is a digitally signed message part
