Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753388AbbETMsr (ORCPT ); Wed, 20 May 2015 08:48:47 -0400 Received: from mail-bn1bon0092.outbound.protection.outlook.com ([157.56.111.92]:34256 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753243AbbETMsp (ORCPT ); Wed, 20 May 2015 08:48:45 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Robert.Richter@caviumnetworks.com; Date: Wed, 20 May 2015 14:48:27 +0200 From: Robert Richter To: Marc Zyngier 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 Message-ID: <20150520124827.GF10428@rric.localhost> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150520131138.2c94a32a@why.wild-wind.fr.eu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [78.53.86.157] X-ClientProxiedBy: AMSPR04CA0050.eurprd04.prod.outlook.com (10.242.87.168) To DM2PR0701MB809.namprd07.prod.outlook.com (10.242.127.23) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0701MB809; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:DM2PR0701MB809;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0701MB809; X-Forefront-PRVS: 0582641F53 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6069001)(24454002)(51704005)(199003)(189002)(54356999)(66066001)(47776003)(81156007)(110136002)(40100003)(5001830100001)(64706001)(76176999)(4001540100001)(50986999)(5001860100001)(33656002)(97736004)(5001960100002)(122386002)(92566002)(46102003)(23726002)(189998001)(87976001)(4001350100001)(86362001)(50466002)(97756001)(101416001)(83506001)(105586002)(106356001)(77156002)(62966003)(46406003)(42186005)(2950100001)(68736005)(76506005)(77096005);DIR:OUT;SFP:1101;SCL:1;SRVR:DM2PR0701MB809;H:rric.localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2015 12:48:41.1419 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0701MB809 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1816 Lines: 44 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. > 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. -Robert -- 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/