From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S939990AbdDTIVC (ORCPT ); Thu, 20 Apr 2017 04:21:02 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:16217 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbdDTIU5 (ORCPT ); Thu, 20 Apr 2017 04:20:57 -0400 Subject: Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge From: Mason To: Marc Zyngier , Thomas Gleixner Cc: Bjorn Helgaas , Robin Murphy , Lorenzo Pieralisi , Liviu Dudau , David Laight , linux-pci , Linux ARM , Thibaud Cornic , LKML 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> Message-ID: <2003d851-e17e-1a43-3889-ec6e79e635e3@free.fr> Date: Thu, 20 Apr 2017 10:20:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 MIME-Version: 1.0 In-Reply-To: <87d48d57-5f9f-1b35-99da-ab39de2d3d48@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 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} 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. Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 From: slash.tmp@free.fr (Mason) Date: Thu, 20 Apr 2017 10:20:31 +0200 Subject: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge In-Reply-To: <87d48d57-5f9f-1b35-99da-ab39de2d3d48@free.fr> 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> Message-ID: <2003d851-e17e-1a43-3889-ec6e79e635e3@free.fr> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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} 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. Regards.