Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <8ea70992-d4e9-8bbd-0fca-d5700f84e071@amd.com>
Date:   Fri, 30 Sep 2022 12:29:40 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH RFC 0/2] Generate device tree node for pci devices
Content-Language: en-US
To:     Rob Herring <robh@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>
Cc:     Lizhi Hou <lizhi.hou@amd.com>, linux-pci@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        helgaas@kernel.org, clement.leger@bootlin.com, max.zhen@amd.com,
        larry.liu@amd.com, brian.xu@amd.com, stefano.stabellini@xilinx.com,
        trix@redhat.com
References: <1661809417-11370-1-git-send-email-lizhi.hou@amd.com>
 <f831f62b-004b-4f73-2a66-de9d675c44b6@gmail.com>
 <CAL_JsqJn=i=TT9NArHK25g1NkZN_G1GjN3EGEeTAvyW_PUhgcw@mail.gmail.com>
From:   Sonal Santan <sonal.santan@amd.com>
In-Reply-To: <CAL_JsqJn=i=TT9NArHK25g1NkZN_G1GjN3EGEeTAvyW_PUhgcw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NXB2R1pVeXFGaWF6djVlN25oN0NVaXVGZWMxRGJGa1dPYnA1WEtUUWZtblB5?=
 =?utf-8?B?d2xMOXF0UWRDVDU5QzQ2eHBmdjRxWk1WYWJNcjZkWHZhZGdyMFJmTVJCVUh3?=
 =?utf-8?B?SDd5WHJMR0UvRWxhYkNCSmhSOWFIT3g4TnErYitndHhXSE8zMmNsQzZVR1RB?=
 =?utf-8?B?dXFKSmE5TC9SajJDS0RsSHR1M0x5YUxNMThRcXpzQkxKSjBRNUdsQ2c3Z3R3?=
 =?utf-8?B?NjZQZVg3S2ljaHAvTmI0SGR4S2Y1N3FtdWZmM3g5SmlvM05XeU1SNEgzajdZ?=
 =?utf-8?B?c1RhZHpOUTRqVEZqMmsrQ3JGY25YZDkyL0YxT2FjUkY0UFFzd3Baem1XaURx?=
 =?utf-8?B?UDBsblIzKzl4T1hYZjVvSERpWVloczhWQTFjeE4rT3d1RWdOeUhLeDJvaGRo?=
 =?utf-8?B?QWZjYnVBdUwyQmtDeUZZbTY2aDY3Rk1DUWtNRk53MWdObFYreXJ4b0F1dmNn?=
 =?utf-8?B?YnI0aThqcXArbTR5WTVSODMwSTQxVVJSNVNwdEl3Z0U1TGNTT2lSN2ltUDI4?=
 =?utf-8?B?dFdWQ0tIRCttcExHbGVKVXJ1LzJrZGt2RmEyeTNnU04yNGtvNm01dEFIYmxZ?=
 =?utf-8?B?a3ViSXgxZG5pNDR1SkpuYVIyL1lGQklDcGVpU3RRRDNWNmgrd3RDR1F1eHl4?=
 =?utf-8?B?K01JVitIZENERll2L2RUL0g3QUcxUmFEYkpCckNGRTl4TEFsVTM4TTN0WkIx?=
 =?utf-8?B?bXpGQU9MZHI2WE5DQ0dSdG1TYUdiLy90QXlybU9mejhNYmErUmdmSjhBSTVI?=
 =?utf-8?B?cytmME9sc2x2dlNhbEk5Nms2ckJ5eEphV0RORUFKbTc1SS9haWNaK0d4QjJj?=
 =?utf-8?B?Y0E0dEY1SzhybUEvQU41WFZubnRhc1BySHI2TlVidGI2eDBCZlA4dmt2UXB6?=
 =?utf-8?B?TlJYRmUrU0htbWFyWVR3UTg3ZUtvWmZFWndnaUdiZy9qREozSGV5SGx5aVda?=
 =?utf-8?B?dm12QldaWDlmOS9OdzFqNFpiVzhEQ0c0ZWsvWmRWOUYvaXJQTWZ4UmxyN0c0?=
 =?utf-8?B?UUo4MWpLNTZlbnQ1aXRrRDZQdk1DVHBDZzJLa0t0ZEdDV08ybFRUd203MkxP?=
 =?utf-8?B?a0Q4YUJuUjNsaXlQSWdnZW0yL3orcU9tOXp3MkcwTis5MlNRZ0xDeVVGVm5O?=
 =?utf-8?B?RXJHYXdKOWxlSmRXaWdlWk5QN1VkVDcxTjRpWHBjeUVMai9Gazh5M1llWW1l?=
 =?utf-8?B?MnNGMGxGS2twcVVoOWNobitSUm50cmE4cWowbjc2WDdPSkVHM1hRejlHRHJJ?=
 =?utf-8?B?QVBpN2ZGT2E2aVJQSFdaakZkWVdlb3BEUnpqNkRHMTZhMGJRTWpveHBKUUxH?=
 =?utf-8?B?VFcrS1l4enpzQ1N2RnJ5U0h1bnNNTTE3WFVCNUVtb0RrWmE3T2l0OGJiZ0Uz?=
 =?utf-8?B?Y2R0TzJFNVY4Z2tWVEdmK3g5MEFucEdKZ1VRbG9nVm5MM1h0anQ5ZXNMaS9M?=
 =?utf-8?B?UVQrT3N1cXJSVnJJM3h2S1VKNGtiV1lmdURkOXJ5WXlYK1gvb3hPQ0FJdlg3?=
 =?utf-8?B?SFRRY0dKODdLSW5YcTZxaEl6bk1LTUFoWjBkc3VHTTQ1NnRDYlUzT1VQdnJk?=
 =?utf-8?B?YTN1TTNTSzVMM3QvU3EybFlnQTJzSjRKOVFSRC9MSWh5RUg2dlA1UXpId2dW?=
 =?utf-8?B?TzcrY0VTdmNnd3NNNDJTSlpqRmE0UHF6U2x1dE5HZUZpNmUxSVlJL3dhS1Rx?=
 =?utf-8?B?dDhvVGtsRytLREpQNzFaOTZkUFZoWEp3Q1VaS3FmWVZ2SkxZSzBOQ3hhSHFH?=
 =?utf-8?B?bUdOR1YvWHpJcDJaODU5ZU94MFF3VCtzOWVacFkva3Y5OUV3eEpGeDhMOEll?=
 =?utf-8?B?MkR6T0FZSEozSmFKVndIOCtwT3NQMU5vT0oxOFJKUEg2Z25XNGhyYitpbXJL?=
 =?utf-8?B?TE9WTUdEVmwyWjgwRVZQelF6cklOU1RBa2dkUjZxN1RZVk9CMzB4emZyVjA1?=
 =?utf-8?B?VDROdTUxa3EzdHJlWTR2WWxPRTZjdTdTMi9VUHY0NEpRcGgrQTRSWDJBc0Fj?=
 =?utf-8?B?N2pJL3A3ZFpNbStTWlc1RnY3WDhpZWozd2pMMWIxWG1Tb0pLSTBpL1hTZGFa?=
 =?utf-8?B?enE3elZmM1hlZmUvaXhuSytIWEpWTXJndmNCdDRkSWlIMm9FYmRieDBYeVFt?=
 =?utf-8?Q?CIGVFx8FOgV/q13LoCjk+8l8t?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd7cc266-5273-4478-3c1f-08daa31a2094
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4502.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2022 19:29:43.8502
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: T0YETLiaBA1GQ2G/MA0oGE/ji9VnQSTgo2dd3qK2GSeKuNiHJAz8LucInYqU6uRR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5926
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/26/22 15:44, Rob Herring wrote:
> On Fri, Sep 16, 2022 at 6:15 PM Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 8/29/22 16:43, 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. An example device is Xilinx/AMD
>>> Alveo PCIe accelerators. Second, it allows reuse of a OF compatible
>>> driver -- often used in SoC platforms -- in a PCI host based system. An
>>> example device is Microchip LAN9662 Ethernet Controller.
>>>
>>> This patch series consolidates previous efforts to define such an
>>> infrastructure:
>>> https://lore.kernel.org/lkml/20220305052304.726050-1-lizhi.hou@xilinx.com/
>>> 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.
>>
>> I still do not agree with this statement.  The device tree overlay
>> implementation is very incomplete and should not be used until it
>> becomes more complete.  No need to debate this right now, but I don't want
>> to let this go unchallenged.
> 
> Then we should remove overlay support. The only way it becomes more
> complete is having actual users.
> 
> But really, whether this is the right solution to the problem is
> independent of the state of kernel overlay support.
> 
>> If there is no base system device tree on an ACPI based system, then I
>> am not convinced that a mixed ACPI / device tree implementation is
>> good architecture.
> 
> Most/all of this series is needed for a DT system in which the PCI
> devices are not populated in the DT.
> 
>>   I might be more supportive of using a device tree
>> description of a PCI device in a detached device tree (not linked to
>> the system device tree, but instead freestanding).  Unfortunately the
>> device tree functions assume a single system devicetree, with no concept
>> of a freestanding tree (eg, if a NULL device tree node is provided to
>> a function or macro, it often defaults to the root of the system device
>> tree).  I need to go look at whether the flag OF_DETACHED handles this,
>> or if it could be leveraged to do so.
> 
> Instead of worrying about a theoretical problem, we should see if
> there is an actual problem for a user.
> 
> I'm not so worried about DT functions themselves, but places which
> have 'if ACPI ... else (DT) ...' paths.
>

Bringing this thread back into focus. Any thoughts on how to move forward?

-Sonal

> Rob