From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [RFC PATCH v3 07/18] xen/arm: ITS: implement
 hw_irq_controller for LPIs
Date: Mon, 29 Jun 2015 12:53:08 +0100
Message-ID: <1435578788.32500.284.camel@citrix.com>
References: <1434974517-12136-1-git-send-email-vijay.kilari@gmail.com>
	<1434974517-12136-8-git-send-email-vijay.kilari@gmail.com>
	<55896DEC.2030101@citrix.com>
	<CALicx6vKzTzVV_kgAsGdT9FBkSdBdfvk4ZyiXP_mzDB6hiwC+Q@mail.gmail.com>
	<558D6A4E.90202@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <558D6A4E.90202@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@citrix.com>
Cc: Vijay Kilari <vijay.kilari@gmail.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, manish.jaggi@caviumnetworks.com
List-Id: xen-devel@lists.xenproject.org

On Fri, 2015-06-26 at 17:05 +0200, Julien Grall wrote:
> Hi Vijay,
> 
> On 26/06/2015 14:54, Vijay Kilari wrote:
> > On Tue, Jun 23, 2015 at 8:02 PM, Julien Grall <julien.grall@citrix.com> wrote:
> >> Hi Vijay,
> >>
> >> On 22/06/15 13:01, vijay.kilari@gmail.com wrote:
> >>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> >>>
> >>> Implements hw_irq_controller api's required
> >>> to handle LPI's
> >>
> >> This patch doesn't hw_irq_controller for LPI but just hack around the
> >> current GICv3 host hw_irq_controller.
> >>
> >> As said on the previous version, the goal of hw_irq_controller is too
> >> keep things simple (i.e few conditional code). Please introduce a
> >> separate hw_irq_controller for LPIs.
> >
> > If new hw_irq_controller is introduced for LPIs, then this has to
> > be exported using some lpi structure which holds pointer to hw_irq_controller
> > for guest & host type similar to gic_hw_ops
> 
> The interface is not set in stone, you are free to change what you want 
> as long as we keep something clean and comprehensible. It's the same for 
> the functions (I have in mind route_irq_to_guest).

Ack.

> In this case, I would prefer to see 2 callbacks (one for the host the 
> other for the guest) which return the correct IRQ controller for a 
> specific IRQ. I have in mind something like:
> 
>     get_guest_hw_irq_controller(unsigned int irq)
>     {
>         if ( !is_lpi )
>           return &gicv3_guest_irq_controller
>         else
>           return &gicv3_guest_lpi_controller
>     }
> 	
> Same for the host irq controller. So the selection of the IRQ controller 
> would be hidden from gic.c and keep the code a generic as possible.

Yes, this is how I would expect it too.

Alternatively I notice that the pattern today is:
        desc->handler = gic_hw_ops->gic_(host|guest)_irq_type;
     [set_bit(_IRQ_GUEST, &desc->status) or not]
     gic_set_irq_properties(desc,[...]);

So an alternative might be for the set_irq_properties hook in the ops to
also setup the handler (based on desc->status&_IRQ_GUEST and desc->irq),
perhaps renaming it to something less "property" based. Both callers are
git_route_irq_to_... so perhaps gic_route_irq?

Ian.