On Fri, 1 Jul 2022 11:59:59 +0000 Dmitry Rokosov <DDRokosov@xxxxxxxxxxxxxx> wrote: > Hello Jonathan, > > This patch has been on the mailing list for one month already, but no > comments from other IIO reviewers. What do you think we should do with it? > Is it a helpful change or not? Given I'm way behind and timing in cycle, I'm probably going to kick this back to start of the next cycle. Sorry for delay, Jonathan > > On Sat, Jun 04, 2022 at 02:59:55PM +0100, Jonathan Cameron wrote: > > On Wed, 1 Jun 2022 17:48:32 +0000 > > Dmitry Rokosov <DDRokosov@xxxxxxxxxxxxxx> wrote: > > > > > To provide a new IIO trigger to the IIO core, usually driver executes the > > > following pipeline: allocate()/register()/get(). Before, IIO core assigned > > > trig->owner as a pointer to the module which registered this trigger at > > > the register() stage. But actually the trigger object is owned by the > > > module earlier, on the allocate() stage, when trigger object is > > > successfully allocated for the driver. > > > > > > This patch moves trig->owner initialization from register() > > > stage of trigger initialization pipeline to allocate() stage to > > > eliminate all misunderstandings and time gaps between trigger object > > > creation and owner acquiring. > > > > > > Signed-off-by: Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx> > > > > Hi Dmitry, > > > > I 'think' this is fine, but its in the high risk category that I'd like > > to keep it on list for a few weeks before applying. > > > > Note I'm still keen that in general we keep the flow such that > > we do allocate()/register()/get() as there is no guarantee that the get() > > will never do anything that requires the trigger to be registered, even > > though that is true today. Which is another way of saying I'm still > > keen we fix up any cases that sneak in after your fix up set dealt with > > the current ones. > > > > Thanks for following up on this! > > > > Jonathan > > >
