On Mon, Dec 26, 2022 at 06:54:37PM +0200, Laurent Pinchart wrote: > On Mon, Dec 19, 2022 at 11:48:51AM +0200, Andy Shevchenko wrote: > > On Mon, Dec 19, 2022 at 09:51:43AM +0100, Luca Ceresoli wrote: > > > On Sun, 11 Dec 2022 18:55:39 +0200 Laurent Pinchart wrote: > > > > On Thu, Dec 08, 2022 at 12:39:59PM +0200, Tomi Valkeinen wrote: ... > > > > This may be a stupid question, but couldn't you instead use the > > > > BUS_NOTIFY_ADD_DEVICE and BUS_NOTIFY_DEL_DEVICE bus notifiers ? > > > > > > I'm not sure they would be the correct tool for this task. Bus > > > notifiers inform about new events on the 'struct bus_type, i.e. any > > > event on the global i2c bus type. In the i2c world this means being > > > notified about new _adapters_, which is exactly what > > > drivers/i2c/i2c-dev.c does. > > > > > > Here, however, we need to be informed about new _clients_ being added > > > under a specific adapter. > > > > This is for example exactly what ACPI integration in I2C framework does. But... > > > > > I'm not sure whether the bus notifiers can > > > inform about new clients in addition of new adapters, but they at least > > > seem unable to provide per-adapter notification. > > > > ...personally I don't like notifiers, they looks like overkill for this task. > > But isn't this patch essentially implementing a custom notification > system ? If we need notifiers, why would it be better to add an ad-hoc > API for I2C instead of using bus notifiers ? Notifiers (as implemented in the Linux kernel) have some drawbacks IIUC. For example, it's not easy to pass the data over it. Another example is the context (you wouldn't know when the notifier be called and if it can hold some locks or not). That said, each case should be discussed individually despite the generic approach being present (i.o.w. do not consider notifiers as a silver bullet in _any_ notification scheme). > > > Does that seem correct? -- With Best Regards, Andy Shevchenko
