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]

Message-ID: <CAAtXAHd9zC3+25Hb0mRvSX4E3O3kts4K-g8qzUuA7AaDPXH1gA@mail.gmail.com>
Date:	Fri, 22 Jan 2016 12:01:43 +0100
From:	Moritz Fischer <moritz.fischer@...us.com>
To:	Alan Tull <atull@...nsource.altera.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

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?

> +       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.

Cheers,

Moritz