From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE1EDC43334 for ; Fri, 22 Jul 2022 21:39:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231682AbiGVVj1 (ORCPT ); Fri, 22 Jul 2022 17:39:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236273AbiGVVjX (ORCPT ); Fri, 22 Jul 2022 17:39:23 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19099B8786 for ; Fri, 22 Jul 2022 14:39:21 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id b26so8164104wrc.2 for ; Fri, 22 Jul 2022 14:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FxcKHw+KeNRqCkk5qROt/9GMubXJxUVMHKA1De+QJz8=; b=P4rzv0+8JfcWUKy1JivKJYMUetypR5ZiNXPA/6TSTJ0YOhLtsMWwVXnQAHjl5ygmW9 dSBVgFFBSsuonWbdOk8Ky+8qccZi6wfbk6zGgOEGk0PVttqaVNlAyBadARwj1Y//JgTT wL6bVCh2M0D2piZA9vHUlRbbhnt5btt+pxUjCwafnt83Hj6JsO3UAIXiah1okFR8mkjn XW3LXj5OrIDz9y0dGYXXNmg2sdZwG8rkxjOyqFkSkwPRULwu5FrrylKP4IeJIMyTOz30 OH0e6tl4+7ksBnlFP1VAGBJQezXleYMqd17bvJr97uuUoAOxjo7DEfiyq52KAf/qLNWt Shew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FxcKHw+KeNRqCkk5qROt/9GMubXJxUVMHKA1De+QJz8=; b=huCdVcJY0MqTflD2rix8oLnmsUd/59HUun2GvQ2LQpdeAONBpmkOc1voeoMHFXnHD8 NnohThd769QvnCBh9ed/zEmeVBUTRE91USPcQR3bERHb1eJ9y/pNrpPsBwdyAAHaJ5wj oDPmDZsWiWYIXmd92pglm/6OhTKt6e8YUIEEjCCQLnSiLzPPdKiEXbEUG8Jy/mShH45j bnnxGALDFsd166LnGyQbUDapk5UTqexPAAPjJ+3zbLEB3p1DxVLwq1xtJmeNY264kMjw tGjUjiUfU/gWEIX2VHyFA16XFhx6AL7dpbGeg32YFxyE0BG57Pu9DsPW7jjBRYTpi7Qe LGkg== X-Gm-Message-State: AJIora9NxSB7lbph5t9c2hdpgtqXkp7CL9VBHjLxbX0Gcd5THUxN2hbC n4w1ONxnUJvaez84A4xPnulTWA== X-Google-Smtp-Source: AGRyM1tPVIVZfV6qM8vhMpTbxX0oe2mvWjKidKhJrKbIkCzM/uzQTakUQbNW/CotdHpNthpStjOk6Q== X-Received: by 2002:a5d:6285:0:b0:21e:6554:5e31 with SMTP id k5-20020a5d6285000000b0021e65545e31mr1109911wru.21.1658525959500; Fri, 22 Jul 2022 14:39:19 -0700 (PDT) Received: from smtpclient.apple (global-5-142.n-2.net.cam.ac.uk. [131.111.5.142]) by smtp.gmail.com with ESMTPSA id ay36-20020a05600c1e2400b003a2d6c623f3sm10104785wmb.19.2022.07.22.14.39.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2022 14:39:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it From: Jessica Clarke In-Reply-To: Date: Fri, 22 Jul 2022 22:39:18 +0100 Cc: Rob Herring , Palmer Dabbelt , Bjorn Helgaas , "Maciej W. Rozycki" , Stafford Horne , "linux-kernel@vger.kernel.org" , Catalin Marinas , Will Deacon , Guo Ren , Paul Walmsley , Albert Ou , Richard Weinberger , Anton Ivanov , Johannes Berg , linux-arm-kernel , linux-csky@vger.kernel.org, linux-riscv , linux-um , PCI , "open list:GENERIC INCLUDE/ASM HEADER FILES" Content-Transfer-Encoding: quoted-printable Message-Id: <41B9AC54-DCFE-4055-B950-265B3CBDD842@jrtc27.com> References: To: Arnd Bergmann X-Mailer: Apple Mail (2.3696.80.82.1.1) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22 Jul 2022, at 20:55, Arnd Bergmann wrote: >=20 > On Fri, Jul 22, 2022 at 6:36 PM Rob Herring wrote: >> On Fri, Jul 22, 2022 at 9:27 AM Palmer Dabbelt = wrote: >>=20 >> =46rom fu740: >> ranges =3D <0x81000000 0x0 0x60080000 0x0 >> 0x60080000 0x0 0x10000>, /* I/O */ > ... >> So again, how does one get a 0 address handed out when that's not = even >> a valid region according to DT? Is there some legacy stuff that >> ignores the bridge windows? >=20 > The PCI-side port number 0x60080000 gets turned into Linux I/O = resource 0, > which I think is what __pci_assign_resource operates on. >=20 > The other question is why the platform would want to configure the > PCI bus to have a PCI I/O space window of size 0x10000 at the address > it's mapped into, rather than putting it at address zero. Is this a = hardware > bug, a bootloader bug, or just badly set up in the DT? >=20 > Putting the PCI address of the I/O space window at port 0 is usually > better because it works with PCI devices and drivers that assume that > port numbers are below 0xfffff, and makes the PCI port number match > the Linux port number. Possibly related is the (harmless) warning spew seen during boot on FreeBSD. The bridge, and all downstream ones, reset to having I/O window 0x0-0xfff and memory/prefetch window 0x0-0xfffff (which FreeBSD tries to allocate, fails because that=E2=80=99s outside the valid ranges = above, so it then just paves over with a sane fresh config). Linux resets the controller on probe so this is the initial state when enumerating, and perhaps that=E2=80=99s not handled so gracefully as on FreeBSD (which = also resets in device_attach, the second half of what Linux calls probe)? Jess