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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 24E57CD3420 for ; Tue, 3 Sep 2024 09:53:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wTnKFrfUmE/uIkrL7Z9DoBSa27AtxRfrH2Z2SWNCR6U=; b=S5UN6wBLuBV+rX8HWrS9Y+0Q/d /a9fgcXaVTxXfiaZ2lsjTY88kNsapHxKZaw2TY1D65kti6qaPXgiVFHuB9KeY4KHNrRPdIueVWkI1 8O2GOJmkuKqOZ5RLUSsiPg1pE5BooY4Xe+nsLrHxlVgVMRClD0Tx1QMc6WVIl2GFiEzO38HuEImU5 RQCKFuB/Jvz/G35U4kAx9flM+T3yqrJ2UzDBkFKV+Hdm9Z3XO/9qlEsJdC7phD9nx8uNSvGW2eP62 CmCZarU7GWWNoDR441TNRKflxBFsgKonrKWuvI4ldvUn1wRAT8ZwBx6u/MgqL/FZbUIYD239pJGdI wRQQRUag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slQDe-0000000HFZW-3bJI; Tue, 03 Sep 2024 09:53:02 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1slPuO-0000000HAl7-0NOM for linux-arm-kernel@lists.infradead.org; Tue, 03 Sep 2024 09:33:10 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a86984e035aso607778766b.2 for ; Tue, 03 Sep 2024 02:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725355985; x=1725960785; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=wTnKFrfUmE/uIkrL7Z9DoBSa27AtxRfrH2Z2SWNCR6U=; b=eDQY5eQFSx5YGwgCK3ESnAaQM6C7+ciIBjqQ3Cb1i+2tcc5esfDdgKlEvo+acGFaMX ex3mRSpgkLk5doyUu9bqhq0grxeLMTqEBJipUTpDnhdimIDpIQqG56rTJ6OHkkJIw1F/ 4cCeOnMnexJjYdSWbX0QBQEDl+x/OVO2SGXh6dhfYHXGpj3+EJ09g9s7a2t+nvSzcyql bRbDNpoQzxKVkLvoMQMYdZ2VmFf38Zagqkg55WDQCx1nLa+CWFZ51EYbpnP03JV5+COm L4uQP/RvFFqmjgs0QviY/sc3S0BMDf6IJ43VWOHPrZ+v5voJ/fzK+ZoECAEKpjISddm5 W92A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725355985; x=1725960785; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wTnKFrfUmE/uIkrL7Z9DoBSa27AtxRfrH2Z2SWNCR6U=; b=MFgcsuMQY5G7AXGXtVAhpsMybHEdGl1mkUiHqfRzcTXqEq6CHXxDds575UAj08V88w d2vlErbENTW8z7jNX18TpWH51JRzvcH2L9Yc8dv5xvBfXjhxB8kgt98YK0etzjHscepx AD2sDgI9O1e4l+sxe9UFglck08zdOwef7r6vfMe7wYnREvNgI0UaI95komNnpwQYBNGm /ls/uFtDm7QoWxDzDZhlMGrinSVOWwqrQdoa7Ls/Jj0zhB4QP4KgmIIIqHN+xcmOBFWp AFnnsVaef/bYDg8sgNHIk9Sd0hxkq5GzO8FpfWLgTOC/1lUHAWPJrSytn10lUeAJeT6W yhww== X-Forwarded-Encrypted: i=1; AJvYcCWVzWL+w3uJZwvQMsXjXUgkBjmYbcW6Yh9kluWXpmOuYOra9hoAcDB4u7qGCUANEb1y22qbVs69lfbCiNL3+j0q@lists.infradead.org X-Gm-Message-State: AOJu0Yyp0RiHMP5BCfrchtsdw2xdNoQ0xC4Fc9Rt1z7tlQnxpyj8+76r qB+yo6ShwNl9S/DaOkJwsOfRxeuZAr9eyme1GLVdVGTxcP2Bas30fsprcE0Men0= X-Google-Smtp-Source: AGHT+IF1reVINALdSgJc0RMsY6rt9TxEJ4rR+Xojf3y9r57wj6wnX0V9PBsi2NJ940berEZ0OfsA7Q== X-Received: by 2002:a17:907:72c7:b0:a86:a30f:4aef with SMTP id a640c23a62f3a-a89a35dee4cmr901597466b.22.1725355985011; Tue, 03 Sep 2024 02:33:05 -0700 (PDT) Received: from localhost (host-80-182-198-72.retail.telecomitalia.it. [80.182.198.72]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8988bdcf57sm659603066b.0.2024.09.03.02.33.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 02:33:04 -0700 (PDT) From: Andrea della Porta X-Google-Original-From: Andrea della Porta Date: Tue, 3 Sep 2024 11:33:12 +0200 To: Herve Codina Subject: Re: [PATCH 04/11] of: address: Preserve the flags portion on 1:1 dma-ranges mapping Message-ID: References: <5ca13a5b01c6c737f07416be53eb05b32811da21.1724159867.git.andrea.porta@suse.com> <20240821001618.GA2309328-robh@kernel.org> <20240903110953.2b1f55b6@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240903110953.2b1f55b6@bootlin.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240903_023308_161392_72EBFE1D X-CRM114-Status: GOOD ( 42.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Catalin Marinas , Michael Turquette , Claudiu Beznea , Eric Dumazet , Dragan Cvetic , Thomas Petazzoni , Will Deacon , linux-clk@vger.kernel.org, linux-arch@vger.kernel.org, Rob Herring , Florian Fainelli , Lee Jones , Saravana Kannan , Broadcom internal kernel review list , linux-pci@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Luca Ceresoli , Linus Walleij , devicetree@vger.kernel.org, Conor Dooley , Arnd Bergmann , linux-gpio@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, Bjorn Helgaas , Andrea della Porta , linux-arm-kernel@lists.infradead.org, Derek Kiernan , Stephen Boyd , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Stefan Wahren , netdev@vger.kernel.org, Krzysztof Kozlowski , "David S. Miller" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Herve, On 11:09 Tue 03 Sep , Herve Codina wrote: > Hi, > > On Fri, 30 Aug 2024 14:37:54 -0500 > Rob Herring wrote: > > ... > > > > this view is much like Bootlin's approach, also my pci-ep-bus node now would look > > > like this: > > > ... > > > pci-ep-bus@0 { > > > ranges = <0xc0 0x40000000 > > > 0x01 0x00 0x00000000 > > > 0x00 0x00400000>; > > > ... > > > }; > > > > > > and also the correct unit address here is 0 again, since the parent address in > > > ranges is 0x01 0x00 0x00000000 (0x01 is the flags and in this case represent > > > BAR1, I assume that for the unit address I should use only the address part that > > > is 0, right?). > > > > No, it should be 1 for BAR1. It's 1 node per BAR. > > It should be 1 node per BAR but in some cases it is not. > > Indeed, in the LAN966x case, the pci-ep-bus need to have access to several > BARs and we have: I second this, on RP1 there are multiple BARs too, but for this minimal implementation we need only one. Splitting them in one bus per BAR or merging them with multiple ranges entries depend on whether the peripherals can access different BARs simultaneously. Besides this contraint, I would say both approach are viable. > ... > pci-ep-bus@0 { > compatible = "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > > /* > * map @0xe2000000 (32MB) to BAR0 (CPU) > * map @0xe0000000 (16MB) to BAR1 (AMBA) > */ > ranges = <0xe2000000 0x00 0x00 0x00 0x2000000 > 0xe0000000 0x01 0x00 0x00 0x1000000>; > ... > > Some devices under this bus need to use both BARs and use two regs values > in their reg properties to access BAR0 and BAR1. > > > > > > > > The assumption so far with all of this is that you have some specific > > > > > > PCI device (and therefore a driver). The simple-buses under it are > > > > > > defined per BAR. Not really certain if that makes sense in all cases, > > > > > > but since the address assignment is dynamic, it may have to. I'm also > > > > > > not completely convinced we should reuse 'simple-bus' here or define > > > > > > something specific like 'pci-bar-bus' or something. > > > > > > > > > > Good point. Labeling a new bus for this kind of 'appliance' could be > > > > > beneficial to unify the dt overlay approach, and I guess it could be > > > > > adopted by the aforementioned Bootlin's Microchip patchset too. > > > > > However, since the difference with simple-bus would be basically non > > > > > existent, I believe that this could be done in a future patch due to > > > > > the fact that the dtbo is contained into the driver itself, so we do > > > > > not suffer from the proliferation that happens when dtb are managed > > > > > outside. > > > > > > > > It's an ABI, so we really need to decide first. > > > > > > Okay. How should we proceed? > > > > I think simple-bus where you have it is fine. It is really 1 level up > > that needs to be specified. Basically something that's referenced from > > the specific PCI device's schema (e.g. the RP1 schema (which you are > > missing)). > > > > That schema needs to roughly look like this: > > > > properties: > > "#address-cells": > > const: 3 > > "#size-cells": > > const: 2 > > ranges: > > minItems: 1 > > maxItems: 6 > > items: > > additionalItems: true > > items: > > - maximum: 5 # The BAR number > > - const: 0 > > - const: 0 > > - # TODO: valid PCI memory flags > > > > patternProperties: > > "^bar-bus@[0-5]$": > > type: object > > additionalProperties: true > > properties: > > compatible: > > const: simple-bus > > ranges: true > > > > IMHO, the node should not have 'bar' in the name. > In the LAN966x PCI use case, multiple BARs have to be accessed by devices > under this simple-bus. That's why I choose pci-ep-bus for this node name. > Agreed for your scenario. Anyway, since the dtbo and driver are shipped together, we are free to change the name anytime without impacting anything. Many thanks, Andrea > Best regards, > Hervé