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 CD381C4332F for ; Tue, 22 Feb 2022 09:24:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230131AbiBVJZT (ORCPT ); Tue, 22 Feb 2022 04:25:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbiBVJZQ (ORCPT ); Tue, 22 Feb 2022 04:25:16 -0500 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AD9213D92A; Tue, 22 Feb 2022 01:24:51 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id s24so28926415edr.5; Tue, 22 Feb 2022 01:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tG0N4GsMvluqwN7hLyreWf4WVYklGtFdMXvbW9AWJag=; b=dnud/zCQnhD0sZZU8bovA0ObMhMoe/FKEx2PhqHT7SHUuASH4fmXhamRY6HgJg6oJU plhWj8BBtGfmNntw5P1s6WuMtXlTBcrGiGTw7ilx0E//iTUkKW8r5Zf/ShYtamV/HKAY kzjCNt6ldGOThL6gNEdjCS11gdu9cVawSk1QU1k/9m+1bUcOEdzEykQQnm/JmwupRNiX zsYSRg+sQRrtYaOCHdK9rwT3NsDTHTEapOAB1SZWxmrHCXUFHgOeyr17Le62PuU5Vy6R RUFton38ZQ0PctxliCZTRF6YDXStuAOg+uaDQsAF2Fl4O/Z13oMTl4uJ7kfvUcNiNFnt ZFVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tG0N4GsMvluqwN7hLyreWf4WVYklGtFdMXvbW9AWJag=; b=5pDRtp41/M5SDtRZW4gcgdcSVKw9oEcDBAfH8kk3uhWa+DvJoY9P2RYR2UQ8F0Equd j7hnRFggk1iqAXFi2IW96088yPEfm7lOoYPNOL+UQBlLGp59IQzav69tALN25zE9iEKq AtIHiZdze4raQYKc4QteOhZzceyiydy2vVLUXDClt8Syif0hKtTDqmjBVgIDTXxg47PZ 4UuYbmbTrA3oJOZCgMEdwp57CXfWLfmfAPt+MK6mFDKwAEhkjRTCW4HK/zGWWWJ9weDS OcYqJxWhzooVvVlTqTjvZ2Q7AdTerZW/F+bo6rFI0SCRkbDrF2OOYPSt+w1vADjvMY9X OScg== X-Gm-Message-State: AOAM531VeAA9IGNBZqX+iPK4SgZUVTNqjKvG9DhJbDiy+TwjoG2o2Eyn YpO0+cr2BxvM3gMeQ4SKMCGAMMBu+hB/VfggZ0c= X-Google-Smtp-Source: ABdhPJyI3GDjnoSQo+fN01UE7v65Zug0IXRCllwGih/MFgPgyibztVZL42KonHclXFqjafIjGF70IhRGsukb/bM10fk= X-Received: by 2002:a05:6402:d08:b0:412:a33e:24fe with SMTP id eb8-20020a0564020d0800b00412a33e24femr25921136edb.281.1645521889689; Tue, 22 Feb 2022 01:24:49 -0800 (PST) MIME-Version: 1.0 References: <20220221162652.103834-1-clement.leger@bootlin.com> <20220221162652.103834-3-clement.leger@bootlin.com> <20220222091902.198ce809@fixe.home> <20220222094623.1f7166c3@fixe.home> In-Reply-To: <20220222094623.1f7166c3@fixe.home> From: Andy Shevchenko Date: Tue, 22 Feb 2022 10:24:13 +0100 Message-ID: Subject: Re: [RFC 02/10] property: add fwnode_get_match_data() To: =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= Cc: Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Greg Kroah-Hartman , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 22, 2022 at 9:47 AM Cl=C3=A9ment L=C3=A9ger wrote: > Le Tue, 22 Feb 2022 09:33:32 +0100, > Andy Shevchenko a =C3=A9crit : > > On Tue, Feb 22, 2022 at 9:24 AM Cl=C3=A9ment L=C3=A9ger wrote: > > > Le Mon, 21 Feb 2022 19:46:12 +0200, > > > Andy Shevchenko a =C3=A9crit : ... > > > The idea is to allow device with a software_node description to match > > > with the content of the of_match_table. Without this, we would need a > > > new type of match table that would probably duplicates part of the > > > of_match_table to be able to match software_node against a driver. > > > I did not found an other way to do it without modifying drivers > > > individually to support software_nodes. > > > > software nodes should not be used as a replacement of the real > > firmware nodes. The idea behind is to fill the gaps in the cases when > > firmware doesn't provide enough information to the OS. I think Heikki > > can confirm or correct me. > > Yes, the documentation states that: > > NOTE! The primary hardware description should always come from either > ACPI tables or DT. Describing an entire system with software nodes, > though possible, is not acceptable! The software nodes should only > complement the primary hardware description. > > > 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. --=20 With Best Regards, Andy Shevchenko