On Sat, Aug 05, 2023 at 01:45:53AM +0200, Andi Shyti wrote: > On Tue, Aug 01, 2023 at 01:01:43AM +0200, Michał Mirosław wrote: > > On Mon, Jul 31, 2023 at 12:11:47AM +0200, Michał Mirosław wrote: > > > On Sun, Jul 30, 2023 at 10:25:07PM +0200, Andi Shyti wrote: > > > > On Sat, Jul 29, 2023 at 07:08:57PM +0300, Svyatoslav Ryhel wrote: > > > > > +static int i2c_hotplug_activate(struct i2c_hotplug_priv *priv) > > > [...] > > > > > +{ > > > > > + int ret; > > > > > + > > > > > + if (priv->adap.algo_data) > > > > > + return 0; > > > [...] > > > > > + ret = i2c_add_adapter(&priv->adap); > > > > > + if (!ret) > > > > > + priv->adap.algo_data = (void *)1; > > > > > > > > You want to set algo_data to "1" in order to keep the > > > > activate/deactivate ordering. > > > > > > > > But if we fail to add the adapter, what's the point to keep it > > > > active? > > > > > > The code above does "if we added the adapter, remember we did so". > > > IOW, if we failed to add the adapter we don't set the mark so that > > > the next interrupt edge can trigger another try. Also we prevent > > > trying to remove an adapter we didn't successfully add. > > > > Maybe the function's name is misleading? We could find a better one. > > Activation/deactivation in this driver means "initialize/shutdown the > > hotplugged bus" and is done in response to an edge (triggering an > > interrupt) of the hotplug-detect signal. > > So that algo_data is randomly chosen as a boolean value given the > fact that this particular driver doesn't have its own algorithms > but it's using the ones from the parent. Right? [...] Not exactly. There is an 'algorithm for this driver just forwards the calls to the parent bus and has no use of the algo_data field. The field is thus used to store a flag noting whether the child bus was registered or not. > And... thinking aloud... are there race conditions here? I > mean... you can't attach two docking stations, but are there > other scenarios? The driver depends on I2C core code synchronization (e.g. i2c_del_adapter() waiting for ongoing transfers). Outside of probe/remove there is only a single thread used by the driver: the interrupt handler. While reading to answer your question I noticed that IRQF_ONESHOT can be removed: if the thread picks up the signal then it atomically clears the trigger flag; if another signal arrives before the handler is done, handler will be called again. Best Regards, Michał Mirosław