Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756851AbbEVI0g (ORCPT ); Fri, 22 May 2015 04:26:36 -0400 Received: from foss.arm.com ([217.140.101.70]:43105 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756634AbbEVI03 (ORCPT ); Fri, 22 May 2015 04:26:29 -0400 Message-ID: <555EE831.2020503@arm.com> Date: Fri, 22 May 2015 09:26:25 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Robert Richter CC: Robert Richter , Thomas Gleixner , Jason Cooper , Tirumalesh Chalamarla , Radha Mohan Chintakuntla , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 1/4] arm64: gicv3: its: Encode domain number in PCI stream id References: <1430686172-18222-1-git-send-email-rric@kernel.org> <1430686172-18222-2-git-send-email-rric@kernel.org> <20150520131138.2c94a32a@why.wild-wind.fr.eu.org> <20150520124827.GF10428@rric.localhost> In-Reply-To: <20150520124827.GF10428@rric.localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2535 Lines: 60 On 20/05/15 13:48, Robert Richter wrote: > Mark, > > thanks for review, also of the other patches of this series. > > See below > > On 20.05.15 13:11:38, Marc Zyngier wrote: >>> - dev_alias->dev_id = alias; >>> + dev_alias->dev_id = (pci_domain_nr(pdev->bus) << 16) | alias; > >> This feels very scary. We're now assuming that the domain number will >> always be presented to the doorbell. What guarantee do we have that >> this is always the case, irrespective of the platform? >> >> Also, domains have no PCI reality, they are a Linux thing. And they can >> be "randomly" assigned, unless you force the domain in DT with a >> linux,pci-domain property. This looks even more wrong, specially >> considering ACPI. > > The main problem here is that device ids (32 bits) are system > specific. Since we have more than one PCI root complex we need the > upper 16 bits in the devid for mapping. Using pci_domain_nr for this > fits our needs for now and shouldn't affect systems with a single RC > only as the domain nr is zero then. > > The domain number is incremented during initialization beginnig with > zero and the order of it is fixed since it is taken from DT or ACPI > tables. So we have full controll of it. I don't see issues here. This may match what you have on ThunderX (as long as the kernel doesn't adopt another behaviour when allocating the domain number). But other platforms may have a completely different numbering, which will mess them up entirely. >> It really feels like we need a way to describe how the BDF numbering is >> augmented. We also need to guarantee that we get the actual bridge >> number, as opposed to the domain number. > > But true, the obove is just intermediate. In the end we need some sort > of handler that is setup during cpu initialization that registers a > callback for the gic to determine the device id of that paricular > system. I don't really like the idea of a callback from the GIC - I'd prefer it to be standalone, and rely on the topology information to build the DeviceID. Mark Rutland had some ideas for DT (he posted an RFC a while ago), maybe it would be good to get back to that and find out what we can do. ACPI should also have similar information (IORT?). Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/