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 C9249C43334 for ; Fri, 22 Jul 2022 19:42:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236527AbiGVTmm (ORCPT ); Fri, 22 Jul 2022 15:42:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236532AbiGVTml (ORCPT ); Fri, 22 Jul 2022 15:42:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9959A7822C; Fri, 22 Jul 2022 12:42:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3917A61EFD; Fri, 22 Jul 2022 19:42:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D82BC341D2; Fri, 22 Jul 2022 19:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658518959; bh=YWzIul9hGbwyzj2QABvAP1bl4Le92NfHp2dc2pubYJc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=h8zN0U/XN5NU2wFfkFyroujrtY/386+7fCTYjcuMUkmD4XIGlpSn7ZnU4ZolmV/x1 eCezEU3aHdNDxS3SqdB3SnELmLCsbL2IewKbYyRbHxs3sjPnt48iaNXde+SaB+BCh0 HI3d477Tf2sEvehgNwadjad+rH80Q3SJgzmHVzgb+0JdTSt2+xwtrIpNgPKScXu1hp 8v/K+ewAaSFvpGGDZjLIFiHnjB6CLM+QiPngj3CcyDQVmVcqaqJ1r6N2TihxNN+9/6 uL8UA+9uwHwH7CpGbkqFW8moMpd9btIOgLwly2ylF5WLM1Qa+GdcZMipgiYLnKguaI fjlW0z2gG4eTg== Received: by mail-vs1-f46.google.com with SMTP id o4so2045239vsc.12; Fri, 22 Jul 2022 12:42:39 -0700 (PDT) X-Gm-Message-State: AJIora9fJzZZTpGyJUoBGT3e5Relf1UtfdADUo3r2ecOUQaCHawNkRsh f3n3nuexUBxDg6WmKFGl5xg64SI+s6WJ5karog== X-Google-Smtp-Source: AGRyM1sYSLwcS2d5BKZ605LbIBDuQ7FVSSV1zuVCvhEy9wn82CnrWQCs9eT+2Zp2gVSOkp8hHljE+zkArm7bYaXLsO0= X-Received: by 2002:a67:d194:0:b0:357:8ea:5554 with SMTP id w20-20020a67d194000000b0035708ea5554mr641848vsi.0.1658518958470; Fri, 22 Jul 2022 12:42:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Herring Date: Fri, 22 Jul 2022 13:42:27 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] asm-generic: Add new pci.h and use it To: "Maciej W. Rozycki" Cc: Palmer Dabbelt , Bjorn Helgaas , Stafford Horne , "linux-kernel@vger.kernel.org" , Arnd Bergmann , 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@lists.infradead.org, PCI , "open list:GENERIC INCLUDE/ASM HEADER FILES" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Fri, Jul 22, 2022 at 1:23 PM Maciej W. Rozycki wrote: > > On Fri, 22 Jul 2022, Rob Herring wrote: > > > > Maybe the right thing to do here is actually to make the default > > > definitions of these macros non-zero, or to add some sort of ARCH_ > > > flavor of them and move that non-zero requirement closer to where it > > > comes from? From the look of it any port that uses the generic port I/O > > > functions and has 0 for these will be broken in the same way. > > > > > > That said, I'm not really a PCI guy so maybe Bjorn or Maciej has a > > > better idea? > > > > >From fu740: > > ranges = <0x81000000 0x0 0x60080000 0x0 > > 0x60080000 0x0 0x10000>, /* I/O */ > > <0x82000000 0x0 0x60090000 0x0 > > 0x60090000 0x0 0xff70000>, /* mem */ > > <0x82000000 0x0 0x70000000 0x0 > > 0x70000000 0x0 0x1000000>, /* mem */ > > <0xc3000000 0x20 0x00000000 0x20 > > 0x00000000 0x20 0x00000000>; /* mem prefetchable */ > > > > 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? > > It doesn't matter as just sets it as a generic parameter for > the platform, reflecting the limitation of PCI core, which in the course > of the discussion referred was found rather infeasible to remove. The > FU740 does not decode to PCI at 0, but another RISC-V device could. And I > think that DT should faithfully describe hardware and not our software > limitations. Let me ask this another way. When would a 0 memory or i/o address ever work? It doesn't seem this s/w limitation has anything specific to Risc-V. Given pci_iomap_range() rejects 0, I can't see how it could ever work. Maybe only for legacy ISA? So should the generic defaults just be what Risc-V is using instead of 0? Rob