Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

[Julien Grall <julien.grall@xxxxxxx>]

Hi Oleksandr,

On 01/08/2019 19:40, Oleksandr wrote:
> On 01.08.19 18:46, Jan Beulich wrote:
> > On 01.08.2019 16:54, Oleksandr wrote:
> > > On 01.08.19 17:34, Jan Beulich wrote:
> > > > On 01.08.2019 16:31, Oleksandr wrote:
> > > > >     This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which 
> > > > > may request
> > > > >     deferred probing (returns -EPROBE_DEFER) depending on what device will 
> > > > > be probed the first
> > > > >     (Root device must be registered before Cache devices. If not the case,
> > > > >     driver will deny further Cache device probes until Root device is 
> > > > > registered).
> > > > > As we can't guarantee a fixed pre-defined order for the device nodes in DT, 
> > > > > we need to be ready for the situation where devices being probed
> > > > > in "any" order. So, framework (drivers/passthrough/arm/iommu.c) will be 
> > > > > modified a bit to be able to handle -EPROBE_DEFER returning by driver.
> > > > I'm sure this can be had without introducing a new error code.
> > > By reusing existing one (EAGAIN comes to mind)?
> > For example. Or by using some positive value instead of the (negative)
> > errno.h ones.
> Actually, why not? Thank you.
>
> We could find common ground on what driver's init callback should return if 
> driver wants to request deferred probing and document this behavior in 
> device_init usage.
> I would use EAGAIN, but I am open to other options here.
>
> Julien, what do you think?
I don't have any particular opinion as long as the errno cannot be used for 
something else in that code path.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel