linux-kernel - Re: [RFC PATCH] fpga: Introduce new fpga subsystem

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] [day] [month] [year] [list]

Date:	Tue, 01 Oct 2013 17:59:56 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Jason Cooper <jason@...edaemon.net>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, Alan Tull <atull@...era.com>,
	Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stephen Warren <swarren@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	David Brown <davidb@...eaurora.org>,
	Dom Cobley <popcornmix@...il.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem

On 09/30/2013 07:12 PM, Jason Gunthorpe wrote:
> On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
> 
>> I expect that you are detecting/specifying in the driver which
>> fpga is connected and you also need to know size of this device.
>> Then your driver allocate buffer with this size in the kernel
>> and streming data to this buffer. When this is done you are
>> using another sysfs files to control device programming.
> 
> No, it just streams:
> 
> static ssize_t fpga_config_write(struct file *filp,struct kobject *kobj,
>                                  struct bin_attribute *attr,
>                                  char *buf, loff_t off, size_t len)
> {
>         struct device *dev = container_of(kobj, struct device, kobj);
>         struct platform_device *pdev = to_platform_device(dev);
>         struct fpga_priv *priv = platform_get_drvdata(pdev);
>         uint8_t *cur = buf;
>         size_t total = len;
>         unsigned int bit;
> 
>         for (; len != 0; len--, cur++) {
>                 gpio_set_value(priv->gpio[GPIO_CCLK],0);
> 
>                 for (bit = 0; bit != 8; bit++)
>                         gpio_set_value(priv->data_gpio[bit],
>                                        (*cur & (1<<bit)) != 0);
> 
>                 gpio_set_value(priv->gpio[GPIO_CCLK],1);
> 
>                 if (gpio_get_value(priv->gpio[GPIO_INIT_B]) == 0)
>                         return -EIO;
>         }
>         return total;
> }
> 
> static struct bin_attribute dev_attr_config_data = {
>         .attr = {
>                 .name = "config_data",
>                 .mode = 0600,
>         },
>         .size = 0,
>         .write = fpga_config_write,
> };
> 
> User space does as many writes as necessary to send the entire
> bitstream, the sysfs layer chunks things into PAGE_SIZE blocks, so it
> acts much like a socket with O_NONBLOCK set.
> 
> We are controlling the other related GPIOs from userspace, but for
> your purposes I would pair the data sysfs file with a control sysfs
> file much like request firwmare does.
> 
> Here is a suggestion.
> - Two files fpga_config_state, fpga_config_data
> - fpga_config_state is a one value text string values are like
>    initializing, clearing, programming, operating, error_clear_failed,
>    error_bistream_crc
> - Userspace writes to fpga_config_state which causes the kernel FSM
>   to move to that state. The normal progression would be initializing,
>   clearing, programming and finally operating
> - The kernel can move to an error_* state if it detects a problem
> - The programming state data from fpga_config_data to the
>   configuration bus and userspace writes 'operating' once the stream
>   is done to perform the post-configuration actions.

yes, there is necessary to provide also any state to be able to control
the flow. For your case above with streams this is not necessary.

Thanks for this description I wanted to make sure that we are on the same page.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)