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]
Date:   Fri, 27 Jan 2017 08:47:06 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     ming.lei@...onical.com, bp@...en8.de, wagi@...om.org, teg@...m.no,
        mchehab@....samsung.com, zajec5@...il.com,
        linux-kernel@...r.kernel.org, markivx@...eaurora.org,
        stephen.boyd@...aro.org, broonie@...nel.org,
        zohar@...ux.vnet.ibm.com, tiwai@...e.de, johannes@...solutions.net,
        chunkeey@...glemail.com, hauke@...ke-m.de,
        jwboyer@...oraproject.org, dmitry.torokhov@...il.com,
        dwmw2@...radead.org, jslaby@...e.com,
        torvalds@...ux-foundation.org, luto@...capital.net,
        fengguang.wu@...el.com, rpurdie@...ys.net,
        j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        dhowells@...hat.com, bjorn.andersson@...aro.org,
        arend.vanspriel@...adcom.com, kvalo@...eaurora.org
Subject: Re: [PATCH v4 3/3] p54: convert to sysdata API

On Thu, Jan 26, 2017 at 10:50:05PM +0100, Luis R. Rodriguez wrote:
> On Thu, Jan 19, 2017 at 05:27:51PM +0100, Luis R. Rodriguez wrote:
> > 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:
> > > > ---
> > > >  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.
> 
> OK I've added a respective helper call which would map 1-1 with the
> old sync mechanism to enable a 1-1 change, this will be called
> driver_data_request_simple(), but let me know if there is a preference
> for something else.
> 
> With this the only visible delta now is from taking advantage of new
> features. In p54's case this would re-organize the mess in
> drivers/net/wireless/intersil/p54/p54spi.c, the diff stat is a bit
> larger for that file just because of this but I think in this case
> its very much worth the small additions. In this case two routines are
> added for handling the work through callbacks on a sync call.
> 
>  1 file changed, 38 insertions(+), 30 deletions(-)

I agree with Linus, as well as, look, it's still bigger, so you are
making driver developers do more work :(

>  	/* FIXME: should driver use it's own struct device? */
> -	ret = request_firmware(&priv->firmware, "3826.arm", &priv->spi->dev);
> -
> -	if (ret < 0) {
> -		dev_err(&priv->spi->dev, "request_firmware() failed: %d", ret);
> +	ret = driver_data_request_simple("3826.arm", &priv->spi->dev,
> +					 &priv->firmware);
> +	if (ret < 0)
>  		return ret;
> -	}

Hm, a FIXME that you aren't fixing :(

I still fail to see why this new api is worth it at all, sorry.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ