Re: [RFC PATCH v1] iio: trigger: move trig->owner init to trigger allocate() stage

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 1 Jul 2022 11:59:59 +0000
Dmitry Rokosov <DDRokosov@sberdevices.ru> 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@sberdevices.ru> 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@sberdevices.ru>  
> > 
> > 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
> >   
>