Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030365AbdDTJoI (ORCPT ); Thu, 20 Apr 2017 05:44:08 -0400 Received: from foss.arm.com ([217.140.101.70]:51722 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S944108AbdDTJnP (ORCPT ); Thu, 20 Apr 2017 05:43:15 -0400 Subject: Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge To: Mason , Thomas Gleixner References: <91db1f47-3024-9712-309a-fb4b21e42028@free.fr> <310db9dd-7db6-2106-2e53-f0083b2d3758@free.fr> <012f7fcb-eaeb-70dd-a1a9-06c213789d30@arm.com> <0502e180-5517-12d6-e3a1-bcea0da7e201@free.fr> <4edd799a-650c-0189-cd5c-e9fc18c5f8bc@arm.com> <30f662a6-5dab-515b-e35a-a312f3c7b509@free.fr> <5f81730d-fbe3-1f4c-de34-09bbfb893ee1@arm.com> <2b5eef4c-32f2-54f1-ca2f-f9426e68fb2c@free.fr> <67014006-a380-9e3b-c9af-a421052cb8e0@arm.com> <241b130e-1fb7-ecd4-034e-eb02065ada66@free.fr> <37cd6172-b04e-fcad-18fc-4fbb26cc611b@arm.com> <87d48d57-5f9f-1b35-99da-ab39de2d3d48@free.fr> <2003d851-e17e-1a43-3889-ec6e79e635e3@free.fr> Cc: Bjorn Helgaas , Robin Murphy , Lorenzo Pieralisi , Liviu Dudau , David Laight , linux-pci , Linux ARM , Thibaud Cornic , LKML From: Marc Zyngier Organization: ARM Ltd Message-ID: Date: Thu, 20 Apr 2017 10:43:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2003d851-e17e-1a43-3889-ec6e79e635e3@free.fr> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1131 Lines: 37 On 20/04/17 09:20, Mason wrote: > On 19/04/2017 13:19, Mason wrote: > >> My biggest problem is that tango_unmask() is never called. > > FTR, the missing incantation was: > Explicitly calling tango_{mask/unmask/ack} from the corresponding msi_{mask/unmask/ack} Using irq_chip_mask_parent and co, you mean? > Marc, I have one nagging doubt, wrt splitting MSI line selection > and MSI enable. > > tango_irq_domain_alloc : finds an available MSI 'j' to allocate > tango_irq_domain_free : release MSI 'j' > tango_unmask : enable MSI 'j' > tango_mask : disable MSI 'j' > > Is the following scenario guaranteed to never happen? > > tango_irq_domain_alloc // alloc 0 > tango_irq_domain_free // free 0 > tango_irq_domain_alloc // alloc 0 > tango_unmask // enable 0 > tango_unmask // enable 0 = NOP > tango_mask // disable 0 > > In this theoretical scenario, we would be left with a non-functional > MSI 0. I'm not sure I get the example above, and what the various alloc/free calls have to do with anything. If you have unbalanced enable/disable_irq, you loose. Don't do that. M. -- Jazz is not dead. It just smells funny...