linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Clément Léger" <clement.leger@bootlin.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Wolfram Sang <wsa@kernel.org>, Peter Rosin <peda@axentia.se>,
	Russell King <linux@armlinux.org.uk>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>
Subject: Re: [RFC 02/10] property: add fwnode_get_match_data()
Date: Tue, 22 Feb 2022 10:47:05 +0100	[thread overview]
Message-ID: <20220222104705.54a73165@fixe.home> (raw)
In-Reply-To: <CAHp75VfduXwRvxkNg=At5jaN-tcP3=utiukEDL35PEv_grK4Pw@mail.gmail.com>

Le Tue, 22 Feb 2022 10:24:13 +0100,
Andy Shevchenko <andy.shevchenko@gmail.com> 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.
Regarding the use of software nodes, the documentation also says that:

"The software nodes can be used to complement fwnodes representing real
firmware nodes when they are incomplete, for example missing device
properties, *and to supply the primary fwnode when the firmware lacks
hardware description for a device completely.*"

I think my device falls into this last category but I might be wrong. I
understand that using software_node is probably not the best idea to do
so but I did not found any other convenient way to do it and SSDT
overlays do not really seems to be ideal. I would be glad if you
could provide me with an example of such usage to check if it's really
usable.

Thanks,

[1] https://www.kernel.org/doc/html/latest/PCI/acpi-info.html
-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com

  reply	other threads:[~2022-02-22  9:48 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 16:26 [RFC 00/10] add support for fwnode in i2c mux system and sfp Clément Léger
2022-02-21 16:26 ` [RFC 01/10] property: add fwnode_match_node() Clément Léger
2022-02-21 17:44   ` Andy Shevchenko
2022-02-22  8:14     ` Clément Léger
2022-02-21 16:26 ` [RFC 02/10] property: add fwnode_get_match_data() Clément Léger
2022-02-21 17:46   ` Andy Shevchenko
2022-02-22  8:19     ` Clément Léger
2022-02-22  8:33       ` Andy Shevchenko
2022-02-22  8:46         ` Clément Léger
2022-02-22  9:24           ` Andy Shevchenko
2022-02-22  9:47             ` Clément Léger [this message]
2022-02-22 10:20               ` Greg Kroah-Hartman
2022-02-22 15:16                 ` Clément Léger
2022-02-21 16:26 ` [RFC 03/10] base: swnode: use fwnode_get_match_data() Clément Léger
2022-02-21 17:48   ` Andy Shevchenko
2022-02-22  8:39     ` Clément Léger
2022-02-23 15:05       ` Sakari Ailus
2022-02-23 15:15         ` Clément Léger
2022-02-23 15:21           ` Sakari Ailus
2022-02-21 16:26 ` [RFC 04/10] property: add a callback parameter to fwnode_property_match_string() Clément Léger
2022-02-21 17:51   ` Andy Shevchenko
2022-02-21 16:26 ` [RFC 05/10] property: add fwnode_property_read_string_index() Clément Léger
2022-02-21 16:26 ` [RFC 06/10] i2c: fwnode: add fwnode_find_i2c_adapter_by_node() Clément Léger
2022-02-21 18:00   ` Andy Shevchenko
2022-02-21 16:26 ` [RFC 07/10] i2c: of: use fwnode_get_i2c_adapter_by_node() Clément Léger
2022-02-21 16:26 ` [RFC 08/10] i2c: mux: pinctrl: remove CONFIG_OF dependency and use fwnode API Clément Léger
2022-02-21 16:26 ` [RFC 09/10] i2c: mux: add support for fwnode Clément Léger
2022-02-21 17:55   ` Andy Shevchenko
2022-02-22  8:53     ` Clément Léger
2022-02-22 10:57       ` Andrew Lunn
2022-02-22 20:31         ` Alexandre Belloni
2022-02-21 16:26 ` [RFC 10/10] net: sfp: " Clément Léger
2022-02-21 16:45   ` Russell King (Oracle)
2022-02-21 17:57   ` Andy Shevchenko
2022-02-22 13:25     ` Clément Léger
2022-02-23 11:22       ` Andy Shevchenko
2022-02-23 12:02         ` Hans de Goede
2022-02-23 12:31           ` Andrew Lunn
2022-02-23 12:41           ` Russell King (Oracle)
2022-02-23 13:39             ` Hans de Goede
2022-02-23 14:14               ` Clément Léger
2022-02-23 15:23                 ` Andrew Lunn
2022-02-23 15:27                   ` Hans de Goede
2022-02-23 15:27                   ` Hans de Goede
2022-02-23 15:36                     ` Andy Shevchenko
2022-02-23 15:38                   ` Clément Léger
2022-02-23 14:37             ` Andy Shevchenko
2022-02-21 17:41 ` [RFC 00/10] add support for fwnode in i2c mux system and sfp Andy Shevchenko
2022-02-22 16:30   ` Clément Léger
2022-02-23 14:46     ` Andy Shevchenko
2022-02-23 15:11       ` Clément Léger
2022-02-23 15:24         ` Andy Shevchenko
2022-02-23 17:41           ` Mark Brown
2022-02-23 17:59             ` Clément Léger
2022-02-23 18:12               ` Mark Brown
2022-02-23 18:19             ` Andy Shevchenko
2022-02-21 21:44 ` Andrew Lunn
2022-02-22  8:26   ` Andy Shevchenko
2022-02-22  8:57     ` Andrew Lunn
2022-02-22  9:20       ` Andy Shevchenko
2022-02-24 14:40 ` Clément Léger
2022-02-24 14:58   ` Hans de Goede
2022-02-24 15:33     ` Mark Brown
2022-02-24 18:14       ` Sakari Ailus
2022-02-24 18:39         ` Alexandre Belloni
2022-02-24 18:43           ` Mark Brown
2022-02-24 18:39         ` Mark Brown
2022-02-24 16:42     ` Clément Léger
2022-02-24 17:26       ` Mark Brown
2022-03-03  8:48         ` Clément Léger
2022-03-03 12:26           ` Mark Brown
2022-03-08 10:45   ` Clément Léger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220222104705.54a73165@fixe.home \
    --to=clement.leger@bootlin.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=davem@davemloft.net \
    --cc=djrscally@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).