On Thu, 27 Feb 2014 17:43:15 +0100, Jean-Jacques Hiblot <jjhiblot@xxxxxxxxxxxxxxx> wrote: > Hi Grant, > > 2014-02-21 17:22 GMT+01:00 Jean-Jacques Hiblot <jjhiblot@xxxxxxxxxxxxxxx>: > > Hi Grygorii, > > > > 2014-02-21 16:37 GMT+01:00 Strashko, Grygorii <grygorii.strashko@xxxxxx>: > >> Hi Jean-Jacques, > >> > >> Sorry for top posting. > >> > >> As I know, there have been several attempts to solve the same problem already:) > >> [1] https://lkml.org/lkml/2013/9/18/216 > >> [2] https://lkml.org/lkml/2013/11/22/520 > >> [3] https://lkml.org/lkml/2014/1/8/240 > >> > >> There are some questions related to your approach: > >> 1) How to distinguish between cases "IRQ domain not ready" and "wrong IRQ data in DT" or other IRQ parsing errors? > >> Otherwise, Driver's probe will be deffered wrongly and forever, > >> Thierry Reding has tried to solve this in [1]. > > > > This approach doesn't really care about the cause of the problem. I'm > > of the opinion that never-ending deferred probing is not a big issue, > > being not triggered so often after start-up (only when a new device is > > probed). But if we need to make it right, then we would have to change > > a bit the API of irq_create_of_mapping() and irq_of_parse_and_map() > > (or maybe duplicate this one to keep the patch small) to return a real > > error code instead a simple 0. Then would should be able to > > distinguish the different error causes. > > What do you think of the 2nd version of the patch? Is it all right to > allways return EPROBE_DEFER or should we try to discriminate the error > cause? The error cause must be determined. It is explicitly allowed for a single interrupt to be empty, and I believe there are users. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
