lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Oct 2022 10:58:58 +0200 From: Clément Léger <clement.leger@...tlin.com> To: Sonal Santan <sonal.santan@....com> Cc: Rob Herring <robh@...nel.org>, Frank Rowand <frowand.list@...il.com>, Lizhi Hou <lizhi.hou@....com>, linux-pci@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, helgaas@...nel.org, max.zhen@....com, larry.liu@....com, brian.xu@....com, stefano.stabellini@...inx.com, trix@...hat.com, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Alexandre Belloni <alexandre.belloni@...tlin.com>, "Allan.Nielsen@...rochip.com" <Allan.Nielsen@...rochip.com>, "Horatiu.Vultur@...rochip.com" <Horatiu.Vultur@...rochip.com>, "Steen.Hegelund@...rochip.com" <Steen.Hegelund@...rochip.com> Subject: Re: [PATCH RFC 0/2] Generate device tree node for pci devices Le Fri, 7 Oct 2022 15:45:17 -0700, Sonal Santan <sonal.santan@....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). > > > 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 -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
Powered by blists - more mailing lists