Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4048292ybi; Tue, 18 Jun 2019 10:51:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqzPEA7vVxp6Ev8AAo7BLRDq6TLnPi+Oq8aF5MuYi3gNw1XyHqkcN8TzSRVjWMEdWsKVrILm X-Received: by 2002:a17:902:59da:: with SMTP id d26mr54930907plj.306.1560880264288; Tue, 18 Jun 2019 10:51:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560880264; cv=none; d=google.com; s=arc-20160816; b=j97vVHmkZyEyLKSbcorgcUQL95AHV2QXpn5xpHd0MgXY/KcB4wU3io1zMeYQyR3BKk 6zIAsZswxrMGBoltDgJlrpw64qnvHPEl6SqVS7H6LJLkRfvFOOCb8cAXfHVX8c5C1Lk0 kCLnlCH9Wv8e8iDA1KQkwR0G2uBPwTNcSTx8MUwzaxXqgoRmnR0M4BG/ojvK6URD5zia JqZzthhRN2WnKERi8/Z5od1SAHKsfW+mC/aZgRbAaT1gTRj1GAulDj3ynDCf9MnbPokv qQxLdKPUgr/mKlX9FCx2Rl7VdMuBg9M8gPU3XyVM2nvXuWjRZWkM6IGiW0dnigz6bhkz /1/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=c1WigYm0cUIC6hZkrAWAPPTHDebRZz1ezFBY1qzMeiw=; b=xLpodSi05hz4uU7eoCN8tKe1WspnmiIgg/e7emuJ0SRP/VCiI/i5g7prWhBrAHVSfL KvgCvIq+LD7GOTZLYVFSZP3KkUGJufnfgvLuKzYztxWSMotV9tyyD4J4i9l9U6nQMh2V mCi0q6pyCegOeGyFlBvZr1i73CdMLVZz+2HXJ3ynpswAwN6M1M37mGNmyIQSeDEBRnEf Yp9wso+cN1GI+LtmqO4Zm4kb2lcfoaB0lViqKQik3Bki7pc7fEjTG3AOrbSiipPPzHO8 TQkBYaQepFUNmrt90dFT4mj5iDIeJpVDsps67MY1sAdq6Ed5WmuO1ITWqnHzzlGms1mi T+oA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RwBVnBXM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s23si2808679pji.52.2019.06.18.10.50.48; Tue, 18 Jun 2019 10:51:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RwBVnBXM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729994AbfFRRuj (ORCPT + 99 others); Tue, 18 Jun 2019 13:50:39 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:35591 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729285AbfFRRui (ORCPT ); Tue, 18 Jun 2019 13:50:38 -0400 Received: by mail-wm1-f66.google.com with SMTP id c6so4182535wml.0 for ; Tue, 18 Jun 2019 10:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c1WigYm0cUIC6hZkrAWAPPTHDebRZz1ezFBY1qzMeiw=; b=RwBVnBXMUs6CyRSqQXw1Doxy4/DTjCa3zCPa//ustSWnjdVbTRmtoP9TN/oSuf+krX xl4fkoWrMAxa7R40u5rQS4PdI+iEJcO3uKO4D0bkbh/B5KWBLvg3lGo7+FdIxMUrU+Bk rvEmDc+IBNiTeTABtleg0an5BGIUgk10CMRKiYoZNAttBlfEicQfnQLY+9kDs29ckxqz 65IqBq5uwXfydw2R7Lg1zG/1DFjmBXIwHeqx3q8Ijsr1e4cNt7GKq0hvEoPL5iNKvtQq U6SWTmZI7yQGUfc753z1fEtZRZPvUdKT1kOJcVZtu+PEDdRq29uH2R2DzGprlWoXffg8 KCVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c1WigYm0cUIC6hZkrAWAPPTHDebRZz1ezFBY1qzMeiw=; b=rK/0v8bIvO3mBHLpO2hL1QXLj1VmBeGNqmjoZ+lDuOkCMGyzwdZR+gs16C5+0zJ+3c LnLiw+RacUp/ON8X0+JkJcJRw5viEZdk3PgvuQaMu8MK0qAPGoNtc3KelzJdt/3SeoUG h162+LAnm3w94g3YxhmLySZPiWIKES4V1nGAk3l0tB/YSFRzavD2bQUyd3AmvRB7N/2g 6jr0YaoQQCo+oNiH8Rcu/4iefd/k8cXk7guPitTrBqEQphjQs95rDObxEEwuK/C0fT8U hZYcPndLczodl9Q/tD9sAVePKS0eIctS1zQ14Dv1F8PhFSL49z8x1Lm07luGI0xXt0Wx yaLw== X-Gm-Message-State: APjAAAWWXwtiBxyi1+Aw76s5SaAUGukozpBlfPIo7i9/6WYGl37ldXaP qpA/E9Q2dUZC2Iik2A/vJAXDJA7hX7sQfCrcNWXr X-Received: by 2002:a1c:f102:: with SMTP id p2mr4299194wmh.60.1560880235583; Tue, 18 Jun 2019 10:50:35 -0700 (PDT) MIME-Version: 1.0 References: <1560507893-42553-1-git-send-email-john.garry@huawei.com> <82840955-6365-0b95-6d69-8a2f7c7880af@huawei.com> <9e8b6971-3189-9d4b-de9a-ff09f859f4f6@huawei.com> <539835d3-770c-285c-0c49-ae15ceaa3079@huawei.com> In-Reply-To: <539835d3-770c-285c-0c49-ae15ceaa3079@huawei.com> From: Bjorn Helgaas Date: Tue, 18 Jun 2019 12:50:23 -0500 Message-ID: Subject: Re: [PATCH v2] bus: hisi_lpc: Don't use devm_kzalloc() to allocate logical PIO range To: John Garry Cc: xuwei5@huawei.com, linuxarm@huawei.com, arm@kernel.org, Linux Kernel Mailing List , Joe Perches , linux-pci@kernel.org, "Rafael J. Wysocki" , Mika Westerberg , Jiang Liu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc Rafael, Mika, Jiang, linux-pci for ACPI host bridge hotplug test question] On Tue, Jun 18, 2019 at 3:44 AM John Garry wrote: > >>> Could you just move the logic_pio_register_range() call farther down > >>> in hisi_lpc_probe()? IIUC, once logic_pio_register_range() returns, > >>> an inb() with the right port number will try to access that port, so > >>> we should be prepared for that, i.e., maybe this in the wrong order to > >>> begin with? > >> > >> No, unfortunately we can't. The reason is that we need the logical PIO > >> base for that range before we enumerate the children of that host. We > >> need that base address for "translating" the child bus addresses to > >> logical PIO addresses. > > Ah, yeah, that makes sense. I think. We do assume that we know all > > the MMIO and I/O port translations before enumerating devices. It's > > *conceivable* that could be changed someday since we don't actually > > need the translations until a driver claims the device, > > We actually need them before a driver claims the device. > > The reason is that when we create that child platform device we set the > device's IORESOURCE_IO resources according to the translated logic PIO > addresses, and not the host bus address. This is what makes the host > transparent to the child device driver. I think you need it to set pdev->resource[], which is currently done long before the driver claims the device (though one could imagine delaying it even as far as pci_enable_device()-time). I don't think the translation is actually *used* until the driver claims the device because only the driver knows how to do any inb/outb to the device. But of course, that's all speculative and doesn't change what you need to do now. The current code assumes we know the translations during enumeration, so you need to do the logic_pio registration before enumerating. > > and it would > > gain some flexibility if we didn't have to program the host bridge > > windows until we know how much space is required. But I don't see > > that happening anytime soon. > My problem is that I need to ensure that the new logical PIO unregister > function works ok for hot-pluggable host bridges. I need to get some way > to test this. Advice? Good question. The ACPI host bridge driver (drivers/acpi/pci_root.c) should support hotplug, but I'm not sure if there's a manual way to trigger it via sysfs or something similar. If there is, and you have a machine with more than one host bridge, you might be able to remove one that leads to non-essential devices. Bjorn