* Grant Likely wrote:
> No.  ERR_PTR is a horrible pattern because you cannot tell by looking
> at a prototype that returns a pointer whether or not the correct
> failure test is "if (!ptr)" or "if (IS_ERR(ptr))".  Unless it is
> absolutely critical for an error code to be returned (which isn't the
> case here) I will not accept new code that uses ERR_PTR().
> 
> In this case, if irq_domain_add_simple() fails, then something is very
> wrong.  I'd much rather the routine complain loudly regardless of the
> error condition.

Okay, I'll keep the WARN_ON(1) and simply return NULL.

> Actually, looking again at irq_domain_generate_simple() it should
> probably succeed even if it cannot find a matching node since an
> irq_domain does more than just device tree translation.  Although,
> irq_domain_generate_simple() is a stop-gap solution that will
> eventually be removed.

So I'll just handle errors in irq_domain_generate_simple() the same way as in
irq_domain_add_simple() and will return NULL if no matching node is found.

Thierry

Attachment: pgpwOZAeb44rY.pgp
Description: PGP signature

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Reply via email to