From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH for-4.5 7/8] xen/irq: Handle multiple action per IRQ Date: Tue, 18 Mar 2014 15:55:41 +0000 Message-ID: <53286C7D.8090207@linaro.org> References: <1390581822-32624-1-git-send-email-julien.grall@linaro.org> <1390581822-32624-8-git-send-email-julien.grall@linaro.org> <1392810905.29739.19.camel@kazak.uk.xensource.com> <530673BD.9010301@linaro.org> <530B5275.7010008@citrix.com> <530B6606020000780011ED39@nat28.tlf.novell.com> <530B5BAC.2010100@linaro.org> <531F28D5.1000901@linaro.org> <531F431D0200007800122EC3@nat28.tlf.novell.com> <53276389.8080109@linaro.org> <1395135184.12847.1.camel@kazak.uk.xensource.com> <53283B8D.4030401@linaro.org> <53285E08.1040508@linaro.org> <5328648A.8030100@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WPwMj-0007Qz-DR for xen-devel@lists.xenproject.org; Tue, 18 Mar 2014 15:55:45 +0000 Received: by mail-wg0-f51.google.com with SMTP id k14so5988955wgh.34 for ; Tue, 18 Mar 2014 08:55:43 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Keir Fraser , Ian Campbell , patches@linaro.org, tim@xen.org, stefano.stabellini@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 03/18/2014 03:39 PM, Stefano Stabellini wrote: > On Tue, 18 Mar 2014, Julien Grall wrote: >> Hi Stefano, >> >> On 03/18/2014 03:01 PM, Stefano Stabellini wrote: >> >>>> I understand the point that people can badly use multiple action in the >>>> future, but is it a good reason to make the code more difficult to >>>> understand? >>> >>> Can't we simply register all the irq handlers at boot time, regardless >>> of whether they are currently used? >>> >> >> This code is doing this actually. You need to know if the IRQ is >> represented multiple times in the "interrupts" list or not. > > Oh, that's right. > > You could rely on request_dt_irq() being able to handle failures > gracefully to make the code easier to read. > Overall I don't think the code is too bad. request_dt_irq doesn't sound the right place to handle it. How will you differentiate an IRQ already registered by another driver and an IRQ registered by the driver itself? IHMO, this hack is worst and could lead issue with the developper because of misconception of the error code. Regards, -- Julien Grall