linux-kernel - Re: local bus enumeration beyond a PCI device

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <11b9ff3a-514e-4c50-88c2-fd6f53398b9c@alliedtelesis.co.nz>
Date: Tue, 23 Apr 2024 01:12:33 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Andy Shevchenko <andy.shevchenko@...il.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, Herve Codina
	<herve.codina@...tlin.com>, Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: local bus enumeration beyond a PCI device


On 22/04/24 19:59, Andy Shevchenko wrote:
> Thu, Apr 18, 2024 at 12:24:06AM +0000, Chris Packham kirjoitti:
>> Hi,
>>
>> We've got a custom x86_64 based design that is using an ASIX9100 to
>> provide a PCI to local bus bridge. Attached to that local bus is an FPGA
>> which mostly provides some GPIOs accessed via registers on the local
>> bus. Right now we've got a custom driver that bundles everything
>> together so effectively we've got a PCI device that provides GPIOs.
>>
>> But as things can change based on the FPGA program I'd like some
>> flexibility to treat it separately from the PCI bridge.
> Why? AFAIU the architecture, you have an FPGA with a real PCI bridge / switch,
> no? If it's the case, the software shouldn't care if the respective IP comes
> from FPGA or SoC.

No the FPGA has a parallel interface. We did try to push the HW 
designers into using a FPGA with a proper PCI-e interface but they 
sighted reasons of cost and schedule so they ended up adding the 
ASIX9100 so they could re-use a lot of the design they had from an older 
product.

>
>> So really I'd
>> like to have a PCI device driver for the ASIX9100 that provides a local
>> bus controller and a (platform?) driver for the FPGA that provides the
>> GPIOs where I can have different compatibles for the different
>> implementations.
>>
>> Then in the ACPI overlay I'd have something like
>>
>>       Scope (\_SB.PCI0.D0B0)
>>       {
>>           Device (ASIX)
>>           {
>>               Name (_ADR, 0x0000)
>>
>>               Device (FPGA)
>>               {
>>                           Name (_HID, "PRP0001")
>>                           Name (_DSD, Package ()
>>                           {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>                                       Package ()
>>                                       {
>>                                                   Package () {
>> "compatible", "my-platform-driver-for-fpga" },
>>                                       }
>>                           })
>>               }
>>           }
>>       }
>>
>>      Scope(\_SB)
>>      {
>>           Device(OTHR)
>>           {
>>               GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
>> "\\_SB.PCI0.D0B0.ASIX.FPGA",) { 0 }
>>           }
>>      }
>>
>> Is it even possible to register a host controller for another platform bus?
> AFAIK there is an FPGA framework in the kernel and the idea is that each FPGA
> configuration provides a complimentary DT to describe the hardware setup. As
> Bjorn Cc'ed this to Herve you may get the answer on what's going on there much
> better as I'm not involved in the development of that topic.
I do need to have a better look at the FPGA framework in the kernel. 
We've mostly done without it on other products.