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, 30 Sep 2013 11:12:56 -0600 From: Jason Gunthorpe <jgunthorpe@...idianresearch.com> To: Michal Simek <monstr@...str.eu> 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 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. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists