linux-kernel - Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

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]

Date:	Fri, 22 Jan 2016 10:37:26 -0600
From:	atull <atull@...nsource.altera.com>
To:	Moritz Fischer <moritz.fischer@...us.com>
CC:	Rob Herring <robh+dt@...nel.org>, Josh Cartwright <joshc@...com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	"Kumar Gala" <galak@...eaurora.org>,
	Jonathan Corbet <corbet@....net>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	Devicetree List <devicetree@...r.kernel.org>,
	<linux-doc@...r.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	"dinguyen@...nsource.altera.com" <dinguyen@...nsource.altera.com>
Subject: Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control
 for FPGA

On Fri, 22 Jan 2016, Moritz Fischer wrote:

> Alan,
> 
> On Wed, Jan 20, 2016 at 8:24 PM,  <atull@...nsource.altera.com> wrote:
> 
> > +static int fpga_area_probe(struct platform_device *pdev)
> > +{
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *np = dev->of_node;
> > +       struct fpga_area *area;
> > +       int ret;
> > +
> > +       area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> > +       if (!area)
> > +               return -ENOMEM;
> > +
> > +       INIT_LIST_HEAD(&area->bridge_list);
> > +
> > +       ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> > +       if (ret)
> > +               return ret;
> > +       area->br = dev_get_drvdata(dev);
> > +
> > +       if (of_property_read_string(np, "firmware-name",
> > +                                   &area->firmware_name)) {
> > +               of_platform_populate(np, of_default_bus_match_table, NULL, dev);
> > +               return 0;
> > +       }
> 
> This is the use case where the bootloader loaded the fpga, and you
> just want to populate
> the devices in the fabric, right?

Hi Moritz,

Yes

> 
> > +       if (of_property_read_bool(np, "partial-reconfig"))
> > +               area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> > +
> > +       ret = fpga_area_get_bus(area);
> > +       if (ret) {
> > +               dev_dbg(dev, "Should be child of a FPGA Bus");
> > +               goto err_unreg;
> > +       }
> 
> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> need to become a subnode of fpgabus@0 at the same place?
> 
> i.e. /soc/fpgamgr@...06000 -> /soc/fpgabus@...pgamgr@...06000
> 
> and the ranges property would be used to translate to the fpga memory
> mapped space?
> 
> I know we're going back and forth on this. I think Rob brought up a
> similar question:
> "Does the bus really go thru the fpgamgr and then the bridge as this
> implies? Or fpgamgr is a sideband controller?"
> 
> To which I think the answer is 'sideband' controller, yet with the new
> bindings it looks like
> the bus goes through the fpgamgr.

Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus to
exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
the bridges and manager that are associated with a certain FPGA.  This allows
the system designer to specify which FPGA is getting programmed with which
image/hardware.  So at minimum, we need some way of associating a FPGA Bus with
a FPGA Manager.

As far as the target path is concerned, in the case of no bridges, we could have
the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
logical.  This would just be a documentation change; I think fpga-area.c will
work OK if you specify the FPGA bus as your target (the manager still has to
be a child of the bus so the bus knows what manager to use).

Alan

> 
> Cheers,
> 
> Moritz
>