devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: "Clément Léger" <clement.leger@bootlin.com>,
	"Sonal Santan" <sonal.santan@amd.com>
Cc: Rob Herring <robh@kernel.org>, Lizhi Hou <lizhi.hou@amd.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, helgaas@kernel.org,
	max.zhen@amd.com, larry.liu@amd.com, brian.xu@amd.com,
	stefano.stabellini@xilinx.com, trix@redhat.com,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	"Allan.Nielsen@microchip.com" <Allan.Nielsen@microchip.com>,
	"Horatiu.Vultur@microchip.com" <Horatiu.Vultur@microchip.com>,
	"Steen.Hegelund@microchip.com" <Steen.Hegelund@microchip.com>
Subject: Re: [PATCH RFC 0/2] Generate device tree node for pci devices
Date: Thu, 13 Oct 2022 01:08:10 -0500	[thread overview]
Message-ID: <a616f56c-60c7-ff7f-4a3c-a5d36d692a15@gmail.com> (raw)
In-Reply-To: <20221010105858.140a8e98@fixe.home>

On 10/10/22 03:58, Clément Léger wrote:
> Le Fri, 7 Oct 2022 15:45:17 -0700,
> Sonal Santan <sonal.santan@amd.com> a écrit :
> 
>>>> Bringing this thread back into focus. Any thoughts on how to move forward?  
>>>
>>> Reviewers raise concerns/issues and the submitters work to address
>>> them or explain why they aren't an issue. The submitter has to push
>>> things forward. That's how the process works.
>>>   
> 
> Up to now, there does not seems to be a better solution to this
> problem in term of maintainability, reusability and ease of use.
> 
> Again, patching the pre-boot description (ACPI or DT) is not an option,
> the user is entitled to plug the card in whatever PCI slot he wants.
> This is either probbly not possible and ACPI based system and would
> require a difficult setup to even try to achieve that. This would also
> result in two different description to support the same device.
> 
>> We are working on updating the patch set to address the feedback. The 
>> design is still based on device tree overlay infrastructure.
> 
> Agreed, moreover saying that "the overlay support is fragile" seems to
> be a shortcut to do nothing and move all the support outside of the
> kernel. If buggy, then it would be better to fix this support (if there
> are real problems encountered with it) or kill it by removing it
> entirely if not usable (option 1 would of course be preferred).

"Buggy" is true, but not an adequate description.  See my other reply in
this thread a couple of minutes ago regarding "proof of concept".

Rob has suggested removing it at least a couple of times this year.

-Frank

> 
>>
>>> As I noted, much of this is needed on a DT system with PCI device not
>>> described in DT. So you could split out any ACPI system support to
>>> avoid that concern for example. Enabling others to exercise these
>>> patches may help too. Perhaps use QEMU to create some imaginary
>>> device.  
>> To verify this patch set, in addition to a x86_64/ACPI based system, we 
>> also have an AARCH64/DT QEMU setup where we have attached a physical 
>> Alveo device. We haven't run into any ACPI or DTO issues so far.
> 
> I've been able to use the same patch set with a X86 QEMU system by
> attaching my physical PCI card to it. No issues were encountered
> (although the usage was rather limited). Gaining some users of this
> support would allow to gather more feedback.
> 
>>
>> Perhaps we can introduce this feature in a phased manner where we first 
>> enable DT based platforms and then enable ACPI based platforms?
>>
>> -Sonal
>>>
>>> Rob  
> 
> 


      reply	other threads:[~2022-10-13  6:08 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29 21:43 [PATCH RFC 0/2] Generate device tree node for pci devices Lizhi Hou
2022-08-29 21:43 ` [PATCH RFC 1/2] of: dynamic: add of_node_alloc() Lizhi Hou
2022-09-16 23:15   ` Frank Rowand
2022-08-29 21:43 ` [PATCH RFC 2/2] pci: create device tree node for selected devices Lizhi Hou
2022-09-02 18:54   ` Rob Herring
2022-09-12  6:33     ` Frank Rowand
2022-09-13  7:03       ` Frank Rowand
2022-09-16 23:20         ` Frank Rowand
2022-09-13  5:49     ` Lizhi Hou
2022-09-02 20:43 ` [PATCH RFC 0/2] Generate device tree node for pci devices Bjorn Helgaas
2022-09-09 23:06   ` Lizhi Hou
2022-09-13  7:00 ` Frank Rowand
2022-09-13 17:10   ` Lizhi Hou
2022-09-13 17:41     ` Frank Rowand
2022-09-13 21:02       ` Lizhi Hou
2022-09-17  2:23         ` Frank Rowand
2022-09-17 18:36           ` Tom Rix
2022-09-20  3:12             ` Frank Rowand
2022-09-26  3:03               ` Sonal Santan
2022-10-14 21:25                 ` Frank Rowand
2022-10-10  8:42       ` [PATCH RFC 0/2] Generate device tree node for pci devicesgain, Clément Léger
2022-10-13  6:05         ` Frank Rowand
2022-10-13  8:02           ` Clément Léger
2022-10-13 17:28             ` Frank Rowand
2022-10-14 17:33               ` Rob Herring
2022-10-14 18:52                 ` Frank Rowand
2022-10-17  7:18                   ` Clément Léger
2022-10-26 21:20                     ` Sonal Santan
2022-09-14 13:35 ` [PATCH RFC 0/2] Generate device tree node for pci devices Jeremi Piotrowski
2022-09-14 18:08   ` Rob Herring
2022-09-16 23:15 ` Frank Rowand
2022-09-26 22:44   ` Rob Herring
2022-09-30 19:29     ` Sonal Santan
2022-10-06 15:10       ` Rob Herring
2022-10-07 22:45         ` Sonal Santan
2022-10-10  8:58           ` Clément Léger
2022-10-13  6:08             ` Frank Rowand [this message]

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=a616f56c-60c7-ff7f-4a3c-a5d36d692a15@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=Allan.Nielsen@microchip.com \
    --cc=Horatiu.Vultur@microchip.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=brian.xu@amd.com \
    --cc=clement.leger@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=helgaas@kernel.org \
    --cc=larry.liu@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=max.zhen@amd.com \
    --cc=robh@kernel.org \
    --cc=sonal.santan@amd.com \
    --cc=stefano.stabellini@xilinx.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=trix@redhat.com \
    /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).