* 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
pgpwOZAeb44rY.pgp
Description: PGP signature
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss