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 45A8ACA0EC3 for ; Mon, 11 Sep 2023 23:15:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243598AbjIKXMc (ORCPT ); Mon, 11 Sep 2023 19:12:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347195AbjIKVYc (ORCPT ); Mon, 11 Sep 2023 17:24:32 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4C411B194; Mon, 11 Sep 2023 14:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694466711; x=1726002711; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ej0zR/ZPGvA8Tfy05E1nu86gMtOlLF6H6/avtJBmGSE=; b=IofKu3Z5iBymBezuzHJij0ObtDeSy9pdVy7AoTpGweJex9XGLqaplRkf XKeED3u+ghug1Gcv4AbskfGfC4ml02FDh4LSxqPz+uZM0UqcFmJ7tyXeF Ag3BxLy0wdff5XQlb4XqjtkJEbvtviW2VqQyM7mJNK+Xy2aYK9Y+GZ1g5 NE9b290TTN7Hg5sB+jCe0QHN75j8y7DwCY27LEBLEpJAaw16ZPEITciof bggPxQQLJunNvLeAYGVpOLMLYX2MFG4+Sgn4euiaQpyHJpzN9Dr2BGg9G os9aFruV82iMxMGJmJjNtMC00ErhbJJsgT7OiQJIbfxH6G6ZLXEPrLd4U Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="377117647" X-IronPort-AV: E=Sophos;i="6.02,244,1688454000"; d="scan'208";a="377117647" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2023 14:08:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="746590016" X-IronPort-AV: E=Sophos;i="6.02,244,1688454000"; d="scan'208";a="746590016" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2023 14:08:19 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qfo8n-008QN4-0g; Tue, 12 Sep 2023 00:08:17 +0300 Date: Tue, 12 Sep 2023 00:08:16 +0300 From: Andy Shevchenko To: Lizhi Hou Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robh@kernel.org, max.zhen@amd.com, sonal.santan@amd.com, stefano.stabellini@xilinx.com Subject: Re: [PATCH V13 0/5] Generate device tree node for pci devices Message-ID: References: <1692120000-46900-1-git-send-email-lizhi.hou@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1692120000-46900-1-git-send-email-lizhi.hou@amd.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote: > This patch series introduces OF overlay support for PCI devices which > primarily addresses two use cases. First, it provides a data driven method > to describe hardware peripherals that are present in a PCI endpoint and > hence can be accessed by the PCI host. Second, it allows reuse of a OF > compatible driver -- often used in SoC platforms -- in a PCI host based > system. > > There are 2 series devices rely on this patch: > > 1) Xilinx Alveo Accelerator cards (FPGA based device) > 2) Microchip LAN9662 Ethernet Controller > > Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/ > > Normally, the PCI core discovers PCI devices and their BARs using the > PCI enumeration process. However, the process does not provide a way to > discover the hardware peripherals that are present in a PCI device, and > which can be accessed through the PCI BARs. Also, the enumeration process > does not provide a way to associate MSI-X vectors of a PCI device with the > hardware peripherals that are present in the device. PCI device drivers > often use header files to describe the hardware peripherals and their > resources as there is no standard data driven way to do so. This patch > series proposes to use flattened device tree blob to describe the > peripherals in a data driven way. Based on previous discussion, using > device tree overlay is the best way to unflatten the blob and populate > platform devices. To use device tree overlay, there are three obvious > problems that need to be resolved. > > First, we need to create a base tree for non-DT system such as x86_64. A > patch series has been submitted for this: > https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/ > https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/ > > Second, a device tree node corresponding to the PCI endpoint is required > for overlaying the flattened device tree blob for that PCI endpoint. > Because PCI is a self-discoverable bus, a device tree node is usually not > created for PCI devices. This series adds support to generate a device > tree node for a PCI device which advertises itself using PCI quirks > infrastructure. > > Third, we need to generate device tree nodes for PCI bridges since a child > PCI endpoint may choose to have a device tree node created. > > This patch series is made up of three patches. > > The first patch is adding OF interface to create or destroy OF node > dynamically. > > The second patch introduces a kernel option, CONFIG_PCI_DYNAMIC_OF_NODES. > When the option is turned on, the kernel will generate device tree nodes > for all PCI bridges unconditionally. The patch also shows how to use the > PCI quirks infrastructure, DECLARE_PCI_FIXUP_FINAL to generate a device > tree node for a device. Specifically, the patch generates a device tree > node for Xilinx Alveo U50 PCIe accelerator device. The generated device > tree nodes do not have any property. > > The third patch adds basic properties ('reg', 'compatible' and > 'device_type') to the dynamically generated device tree nodes. More > properties can be added in the future. In my opinion this series needs much more work (esp. cleaning up one) to not look like a NIH here and there. -- With Best Regards, Andy Shevchenko