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 D025CCA0ED3 for ; Wed, 4 Sep 2024 08:43:08 +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=czuWwJfvtYwCI1yRbL1xXo5MWTUEx5+lgQqq8jdG4Bg=; b=0Z0beFZPRQLu2zHrzAaeQYVhse 7AGSBU/F+19N/u3LIOZYTsbtaozDpFadYjbF+S37yNZs2fNVr0lWI9xPoy1yTEnVYQFCrJKE4oLeC ca5PqIZUi7xvfegtYrZkWayp3+vDZAD2ORwU57xj5HzBkb6D808DEAmeKFWZCKb9g8OB/qGdEDMi0 LomSn/fBYzUzOFKnCcFxmYiUeemy9kVYFwKp8KX5wFl8vQC3c8SfcaWY2RSE0uEwTh1nbhyadncqB WbbqjTuUnLgCVTvEsHD+Tl1qQyCuqdMw9bRfD3u/3SxuwOMoo473xAycnot5g9s71G96df+wU00gZ i3C8Pv3A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sllbM-00000003U1Q-194C; Wed, 04 Sep 2024 08:42:56 +0000 Received: from mail-ej1-x644.google.com ([2a00:1450:4864:20::644]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sllRg-00000003QDO-3ij9 for linux-arm-kernel@lists.infradead.org; Wed, 04 Sep 2024 08:32:58 +0000 Received: by mail-ej1-x644.google.com with SMTP id a640c23a62f3a-a8692bbec79so718953066b.3 for ; Wed, 04 Sep 2024 01:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725438775; x=1726043575; 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=czuWwJfvtYwCI1yRbL1xXo5MWTUEx5+lgQqq8jdG4Bg=; b=HNmAgn+osWNwYEo9q0/AXtuOYhlgv4Bxei8muVsDCzE98Xa6DosxddgwA4r2tewNUX W4J8ZQXpXirF1p+N7Acgbb8k2UQpVXWjodIKumAXtxdaW6bM7G1siwV36oV63uiC7iQA FKHjBOBIvMEv5Mfq/sjF2wKDqLVokD10qjkRI8fjjwQkVjFFwFVeQqlmnI2ilcE50sh5 j8r13oX43Eck+o5sceHbJ4bnNrkpr/7/ruou3vlhDYqrDvukQacj2RC7c9ompnMOiYPR mEusUBSRDBcCevJr5lfqQmgF8RCva2ln3SoUNwdyXJmNNHyaU8iG9UttpDymke3QNus8 635w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725438775; x=1726043575; 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=czuWwJfvtYwCI1yRbL1xXo5MWTUEx5+lgQqq8jdG4Bg=; b=jScxuzSbW4FnqhdpXD4m7YZDbYwdCd+VwjfBoXqtkGZIIg3hvbwmnBx7xpRt/60L0J c4sF6G20BbqIsbxPjeis/ARPgtP/M8BrtuKa9J2IezLj7zY02KsIkkjuInAUOQAKA2WS QWHdubpNU4wLl7XNPyMtVBRoioxSrxL5qkPqO0UQAfyYIvKckYhzu2PVKSTayiPTHbv0 UX4feISoMYTzPB5JE7NMd4+tcWJpadbN/0zBdqgyUCo4Fz3zScZGd0XRqiKjElQlYxwd ucIP1HlO/oJDOfgAxBX9uLfeZreuhwP5hZscttt2TxrWG+8zJCcqNncNBx0bPpUTUfOs dKzg== X-Forwarded-Encrypted: i=1; AJvYcCXQOt5JBd4i9qZZhsaCtCrez6KitJ4XCKGUIy934+a4VD45ZKFr2x8cNa6cK5yTZKVJ2sPK21JKG7pB2w+et/ZF@lists.infradead.org X-Gm-Message-State: AOJu0YwxMyGdEFihAbe7DHrw1f7JeDV0fVxBqdyasnDIcWNs3TxUBy0r 3mf4Kvr0hN6R0Eal6EFl9w0tUXX9iZb/c9X14cBEb4sDIGu7ig/CEqkMcjzLz/g= X-Google-Smtp-Source: AGHT+IFsYrIc/8V6Dd0Wb4ac4K3yCfFqAZyqP0j4It4wu1Ti01Hf/Xj9KyshDVwvjUwn7G7BVIArrg== X-Received: by 2002:a17:907:1c94:b0:a7a:b643:654f with SMTP id a640c23a62f3a-a89a358274emr1229334866b.15.1725438774327; Wed, 04 Sep 2024 01:32:54 -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-a8a3d3177basm69728966b.64.2024.09.04.01.32.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 01:32:53 -0700 (PDT) From: Andrea della Porta X-Google-Original-From: Andrea della Porta Date: Wed, 4 Sep 2024 10:33:02 +0200 To: Rob Herring 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240904_013256_961834_8E280E12 X-CRM114-Status: GOOD ( 36.29 ) 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 , Herve Codina , Catalin Marinas , Michael Turquette , Claudiu Beznea , Eric Dumazet , Dragan Cvetic , Thomas Petazzoni , Will Deacon , linux-clk@vger.kernel.org, linux-arch@vger.kernel.org, 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 Rob, On 13:46 Tue 03 Sep , Rob Herring wrote: > On Tue, Sep 3, 2024 at 11:15 AM Andrea della Porta > wrote: > > > > Hi Rob, > > > > On 14:37 Fri 30 Aug , Rob Herring wrote: > > > On Thu, Aug 29, 2024 at 11:26 AM Andrea della Porta > > > wrote: > > > > > > > > Hi Rob, > > > > > > > > ... > > > > > > > > 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 > > > > > > > Hmmm.. not sure how this is going to work. The PCI device (RP1) will > > havei, at runtime, a compatible like this: > > > > compatible = "pci1de4,1\0pciclass,0200000\0pciclass,0200"; > > > > that is basically generated automatically by the OF framework. So, in the > > schema you proposed above, I can put something like: > > > > properties: > > compatible: > > contains: > > pattern: '^pci1de4,1' > > No, it should be like this: > > compatible: > items: > - const: pci1de4,1 > - const: pciclass,0200000 > - const: pciclass,0200 > > or > > compatible: > addtionalItems: true > maxItems: 3 > items: > - const: pci1de4,1 > Ack. > > Alternatively, we could instead only generate 'pciclass' compatibles > for bridge nodes. The reason being that being an ethernet controller > doesn't really tell us anything. There's no standard interface > associated with that class. I'd avoid this one, since the class is not representative in this case. RP1 is an MFD and not an Ethernet controller. Also, it would prevent other similar PCI devices with differnt class from using this schema. > > > or maybe I could omit the compatible entirely, like in: > > No. > > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-iommu.yaml > > That's not a device node, but just part of pci-host-bridge.yaml. > > > that seems to refer to generic compatible values. > > In both cases though, I don't see how these binding could work with > > make dt_binding_check, since there's no compatible known at compile > > time (for the first approach), or no compatible at all (the second > > approach). > > Is it intended only as a loose documentation? > > No, schemas define exactly what a binding can and can't contain. But > they are divided into device schemas and common schemas. The latter > are incomplete and are included by the former. Generally, "compatible" > goes in device schemas. Ack. > > > Or are you proposing that for a future new bus (hence with a new, specific, > > compatible) that could be described by the schema above? > > The above schema would be the common schema included by a RP1 schema, > LAN966x schema, or any other device doing the same thing. Many thanks, I believe I've got it now :) Cheers, Andrea > Rob