From mboxrd@z Thu Jan 1 00:00:00 1970 From: atull Subject: Re: [PATCH v2 2/3] fpga manager: framework core Date: Thu, 18 Dec 2014 14:50:09 -0600 Message-ID: References: <1414007405-32186-1-git-send-email-atull@opensource.altera.com> <1414007405-32186-3-git-send-email-atull@opensource.altera.com> <20141024105200.GA20775@amd> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Grant Likely Cc: Pavel Machek , Greg Kroah-Hartman , Jason Gunthorpe , "H. Peter Anvin" , Michal Simek , Michal Simek , Randy Dunlap , Linux Kernel Mailing List , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pantelis Antoniou , Rob Herring , Ira Snyder , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Mark Brown , philip-6RQC9ztksjxg9hUCZPvPmw@public.gmane.org, rubini , Steffen Trumtrar , Jason , kyle.teske-acOepvfBmUk@public.gmane.org, Nicolas Pitre , "Balbi, Felipe" , Mauro Carvalho Chehab , David List-Id: devicetree@vger.kernel.org On Sat, 6 Dec 2014, Grant Likely wrote: > >> +int fpga_mgr_write(struct fpga_manager *mgr, const char *buf, size_t count) > >> +{ > >> + int ret; > >> + > >> + if (test_and_set_bit_lock(FPGA_MGR_BUSY, &mgr->flags)) > >> + return -EBUSY; > >> + > >> + dev_info(mgr->dev, "writing buffer to %s\n", mgr->name); > >> + > >> + ret = __fpga_mgr_write(mgr, buf, count); > >> + clear_bit_unlock(FPGA_MGR_BUSY, &mgr->flags); > >> + > >> + return ret; > >> +} > >> +EXPORT_SYMBOL_GPL(fpga_mgr_write); > > > > Is the EBUSY -- userspace please try again, but you don't know when to > > try again -- right interface? I mean, normally kernel would wait, so > > that userland does not have to poll? > > Custom locking schemes are just wrong. A mutex is the right thing to > do here and then an -EBUSY isn't required. > I've changed it to a mutex in the next version. > > > >> +static ssize_t fpga_mgr_firmware_store(struct device *dev, > >> + struct device_attribute *attr, > >> + const char *buf, size_t count) > >> +{ > >> + struct fpga_manager *mgr = dev_get_drvdata(dev); > >> + unsigned int len; > >> + char image_name[NAME_MAX]; > > Hard coding a string length is a warning sign. That is the sort of > thing that can memdup() or strdup() can handle. > OK, I'll fix it using kstrdup() in v6. Alan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html