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 778FDC433F5 for ; Tue, 22 Feb 2022 10:21:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230477AbiBVKVf (ORCPT ); Tue, 22 Feb 2022 05:21:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229772AbiBVKVa (ORCPT ); Tue, 22 Feb 2022 05:21:30 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0231013EFB5; Tue, 22 Feb 2022 02:21:01 -0800 (PST) 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 sin.source.kernel.org (Postfix) with ESMTPS id 611A8CE1316; Tue, 22 Feb 2022 10:20:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AE0BC340E8; Tue, 22 Feb 2022 10:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645525257; bh=c+MUjJQQSEz6EcrkGQwWMDKOpd6pQpqW5YnvVC432Ls=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gpJBpDdcB+qqUdfAoLh6lZyh+2gHjF8UO4QG+ufHTaisPt7A3i6lr6jdsxBU6G3FT ECQwmhgctyORBzXN1ozJ/2+UXL8QwWyR0/m1yjtikrNtPmudn9JHg5BZUDdkRLZEgg AUWkcrwQ4hB4XVRNR8gJk0WIhw72vseVvXZqzVZQ= Date: Tue, 22 Feb 2022 11:20:54 +0100 From: Greg Kroah-Hartman To: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= Cc: Andy Shevchenko , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , "Rafael J . Wysocki" , Wolfram Sang , Peter Rosin , Russell King , Andrew Lunn , Heiner Kallweit , "David S . Miller" , Jakub Kicinski , Linux Kernel Mailing List , ACPI Devel Maling List , linux-i2c , netdev , Thomas Petazzoni , Alexandre Belloni Subject: Re: [RFC 02/10] property: add fwnode_get_match_data() Message-ID: References: <20220221162652.103834-1-clement.leger@bootlin.com> <20220221162652.103834-3-clement.leger@bootlin.com> <20220222091902.198ce809@fixe.home> <20220222094623.1f7166c3@fixe.home> <20220222104705.54a73165@fixe.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220222104705.54a73165@fixe.home> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 22, 2022 at 10:47:05AM +0100, Clément Léger wrote: > Le Tue, 22 Feb 2022 10:24:13 +0100, > Andy Shevchenko a écrit : > > > > > If you want to use the device on an ACPI based platform, you need to > > > > describe it in ACPI as much as possible. The rest we may discuss. > > > > > > Agreed but the PCIe card might also be plugged in a system using a > > > device-tree description (ARM for instance). I should I do that without > > > duplicating the description both in DT and ACPI ? > > > > Why is it (duplication) a problem? > > Each platform has its own kind of description, so one needs to provide > > it in the format the platform accepts. > > > > The problem that I see is not only duplication but also that the PCIe > card won't work out of the box and will need a specific SSDT overlays > each time it is used. According to your document about SSDT overlays, > there is no way to load this from the driver. This means that the user > will have to compile a platform specific .aml file to match its > platform configuration. If the user wants to change the PCIe port, than > I guess it will have to load another .aml file. I do not think a user > expect to do so when plugging a PCIe card. > > Moreover, the APCI documentation [1] says the following: > > "PCI devices, which are below the host bridge, generally do not need to > be described via ACPI. The OS can discover them via the standard PCI > enumeration mechanism, using config accesses to discover and identify > devices and read and size their BARs. However, ACPI may describe PCI > devices if it provides power management or hotplug functionality for > them or if the device has INTx interrupts connected by platform > interrupt controllers and a _PRT is needed to describe those > connections." > > The device I want to use (a PCIe switch) does not fall into these > categories so there should be no need to describe it using ACPI. There should not be any need to describe it in any way, the device should provide all of the needed information. PCIe devices do not need a DT entry, as that does not make sense. thanks, greg k-h