From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
ming.lei@canonical.com, bp@alien8.de, wagi@monom.org,
teg@jklm.no, mchehab@osg.samsung.com, zajec5@gmail.com,
linux-kernel@vger.kernel.org, markivx@codeaurora.org,
stephen.boyd@linaro.org, broonie@kernel.org,
zohar@linux.vnet.ibm.com, tiwai@suse.de,
johannes@sipsolutions.net, chunkeey@googlemail.com,
hauke@hauke-m.de, jwboyer@fedoraproject.org,
dmitry.torokhov@gmail.com, dwmw2@infradead.org, jslaby@suse.com,
torvalds@linux-foundation.org, luto@amacapital.net,
fengguang.wu@intel.com, rpurdie@rpsys.net,
j.anaszewski@samsung.com, Abhay_Salunke@dell.com,
Julia.Lawall@lip6.fr, Gilles.Muller@lip6.fr,
nicolas.palix@imag.fr, dhowells@redhat.com,
bjorn.andersson@linaro.org, arend.vanspriel@broadcom.com,
kvalo@codeaurora.org
Subject: Re: [PATCH v4 3/3] p54: convert to sysdata API
Date: Thu, 19 Jan 2017 17:27:51 +0100 [thread overview]
Message-ID: <20170119162751.GJ13946@wotan.suse.de> (raw)
In-Reply-To: <20170119113857.GQ28024@kroah.com>
On Thu, Jan 19, 2017 at 12:38:57PM +0100, Greg KH wrote:
> On Thu, Jan 12, 2017 at 07:02:44AM -0800, Luis R. Rodriguez wrote:
> > The Coccinelle sysdata patches were used to help with
> > this transition. The changes have been carefully manually
> > vetted for. With the conversion we modify the cases that do
> > not need the firmware to be kept so that the sysdata API
> > can release it for us. Using the new sysdata API also means
> > we can get rid of our own completions.
> >
> > v2: was not present
> > v3: initial release
> > v4: small cosmetic fixes
> > v5: bike shed changes
> > v6: forgot to change one piece of code during the bikeshed name change
> >
> > Generated-by: Coccinelle SmPL
>
> What is this tag for?
Every no wand then some tool scrapes for commit logs to see if
Coccinelle was used to help with a kernel commit. There are different
heuristics, this tag is to help make a more unique search more easily
identifiable as I used Coccinelle to do the original port.
> Also, meta-comment, put your vN: lines below the --- line like the
> kernel documentation says to do.
Oh, OK sounds good.
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > ---
> > drivers/net/wireless/intersil/p54/eeprom.c | 2 +-
> > drivers/net/wireless/intersil/p54/fwio.c | 5 +-
> > drivers/net/wireless/intersil/p54/led.c | 2 +-
> > drivers/net/wireless/intersil/p54/main.c | 2 +-
> > drivers/net/wireless/intersil/p54/p54.h | 3 +-
> > drivers/net/wireless/intersil/p54/p54pci.c | 26 ++++++----
> > drivers/net/wireless/intersil/p54/p54pci.h | 4 +-
> > drivers/net/wireless/intersil/p54/p54spi.c | 80 +++++++++++++++++++-----------
> > drivers/net/wireless/intersil/p54/p54spi.h | 2 +-
> > drivers/net/wireless/intersil/p54/p54usb.c | 18 +++----
> > drivers/net/wireless/intersil/p54/p54usb.h | 4 +-
> > drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> > 12 files changed, 89 insertions(+), 61 deletions(-)
>
> why does the "new" api require more lines?
This is a bare bones flexible API with only a few new tiny features to start
with, one of them was to enable the API do the freeing of the driver data for
you. In the kernel we have devres to help with this but devres only helps if
you would use the API call on probe. We want to support the ability to let the
API free the driver data for you even if your call is outside of probe, for this
to work we need a callback. For async calls this is rather trivial given we
already have a callback, for sync calls this means a new routine is needed.
Freeing the data for you is an option, but I decided to keep the callback
requirement even if you didn't want the free'ing to be done for you. The
addition of a callback is what accounts for the slight increase on this driver.
I could try avoiding the callback if no freeing is needed.
> > --- a/drivers/net/wireless/intersil/p54/p54spi.c
> > +++ b/drivers/net/wireless/intersil/p54/p54spi.c
> > @@ -162,53 +162,73 @@ static int p54spi_spi_write_dma(struct p54s_priv *priv, __le32 base,
> > return 0;
> > }
> >
> > +static int p54spi_request_firmware_found_cb(void *context,
> > + const struct drvdata *drvdata)
> > +{
> > + int ret;
> > + struct p54s_priv *priv = context;
> > +
> > + priv->firmware = drvdata;
> > + ret = p54_parse_firmware(priv->hw, priv->firmware);
> > + if (ret)
> > + release_drvdata(priv->firmware);
> > +
> > + return ret;
> > +}
> > +
> > static int p54spi_request_firmware(struct ieee80211_hw *dev)
> > {
> > struct p54s_priv *priv = dev->priv;
> > + const struct drvdata_req_params req_params = {
> > + DRVDATA_KEEP_SYNC(p54spi_request_firmware_found_cb, priv),
> > + };
> > int ret;
> >
> > /* FIXME: should driver use it's own struct device? */
> > - ret = request_firmware(&priv->firmware, "3826.arm", &priv->spi->dev);
> > -
> > + ret = drvdata_request("3826.arm", &req_params, &priv->spi->dev);
> > if (ret < 0) {
> > - dev_err(&priv->spi->dev, "request_firmware() failed: %d", ret);
> > - return ret;
> > + dev_err(&priv->spi->dev,
> > + "firmware request failed: %d", ret);
>
> shouldn't the call report this error to the kernel log? Why must each
> user print it out themselves again?
Great point. The API already has:
static int _drvdata_request(const struct drvdata **drvdata_p,
const char *name,
const struct drvdata_req_params *params,
struct device *device)
{
...
if (ret && !params->optional)
pr_err("Direct driver data load for %s failed with error %d\n",
name, ret);
...
}
So it is not needed for driver to moan about failures here.
Luis
next prev parent reply other threads:[~2017-01-19 16:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-16 11:46 [PATCH v3 0/4] firmware: add drvdata API Luis R. Rodriguez
2016-12-16 11:46 ` [PATCH v3 1/4] firmware: add new extensible firmware API - drvdata Luis R. Rodriguez
2016-12-16 11:46 ` [PATCH v3 2/4] test: add new drvdata loader tester Luis R. Rodriguez
2016-12-16 11:46 ` [PATCH v3 3/4] x86/microcode: convert to use sysdata API Luis R. Rodriguez
2016-12-16 11:46 ` [PATCH v3 4/4] p54: convert to " Luis R. Rodriguez
2016-12-16 17:14 ` Luis R. Rodriguez
2017-01-12 15:02 ` [PATCH v4 0/3] firmware: add drvdata API Luis R. Rodriguez
2017-01-12 15:02 ` [PATCH v4 1/3] firmware: add new extensible firmware API - drvdata Luis R. Rodriguez
2017-01-19 11:36 ` Greg KH
2017-01-19 16:54 ` Luis R. Rodriguez
2017-01-19 18:58 ` Bjorn Andersson
2017-02-03 21:56 ` Luis R. Rodriguez
2017-01-12 15:02 ` [PATCH v4 2/3] test: add new drvdata loader tester Luis R. Rodriguez
2017-01-12 15:02 ` [PATCH v4 3/3] p54: convert to sysdata API Luis R. Rodriguez
2017-01-16 11:32 ` Christian Lamparter
2017-01-19 11:38 ` Greg KH
2017-01-19 16:27 ` Luis R. Rodriguez [this message]
2017-01-26 21:50 ` Luis R. Rodriguez
2017-01-26 21:54 ` Linus Torvalds
2017-01-27 18:23 ` Luis R. Rodriguez
2017-01-27 20:53 ` Linus Torvalds
2017-01-27 21:34 ` Luis R. Rodriguez
2017-01-27 7:47 ` Greg KH
2017-01-27 11:25 ` Rafał Miłecki
2017-01-27 14:07 ` Greg KH
2017-01-27 14:14 ` Rafał Miłecki
2017-01-27 14:30 ` Greg KH
2017-01-27 14:39 ` Rafał Miłecki
2017-01-27 21:27 ` Luis R. Rodriguez
2017-02-07 1:08 ` [PATCH v5 0/2] firmware: add driver data API Luis R. Rodriguez
2017-02-07 1:08 ` [PATCH v5 1/2] firmware: add extensible " Luis R. Rodriguez
2017-02-07 1:08 ` [PATCH v5 2/2] test: add new driver_data load tester Luis R. Rodriguez
2017-02-10 14:31 ` [PATCH v5 0/2] firmware: add driver data API Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170119162751.GJ13946@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=Abhay_Salunke@dell.com \
--cc=Gilles.Muller@lip6.fr \
--cc=Julia.Lawall@lip6.fr \
--cc=arend.vanspriel@broadcom.com \
--cc=bjorn.andersson@linaro.org \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=chunkeey@googlemail.com \
--cc=dhowells@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=fengguang.wu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hauke@hauke-m.de \
--cc=j.anaszewski@samsung.com \
--cc=johannes@sipsolutions.net \
--cc=jslaby@suse.com \
--cc=jwboyer@fedoraproject.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=markivx@codeaurora.org \
--cc=mchehab@osg.samsung.com \
--cc=ming.lei@canonical.com \
--cc=nicolas.palix@imag.fr \
--cc=rpurdie@rpsys.net \
--cc=stephen.boyd@linaro.org \
--cc=teg@jklm.no \
--cc=tiwai@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=wagi@monom.org \
--cc=zajec5@gmail.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).