[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140917120202.3b9058ae@alan.etchedpixels.co.uk>
Date: Wed, 17 Sep 2014 12:02:02 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: "David E. Box" <david.e.box@...ux.intel.com>
Cc: wsa@...-dreams.de, jdelvare@...e.de, arnd@...db.de,
dianders@...omium.org, sjg@...omium.org,
laurent.pinchart+renesas@...asonboard.com,
u.kleine-koenig@...gutronix.de, boris.brezillon@...e-electrons.com,
maxime.coquelin@...com, max.schwarz@...ine.de,
schwidefsky@...ibm.com, iivanov@...sol.com,
jacob.jun.pan@...ux.intel.com, soren.brinkmann@...inx.com,
bjorn.andersson@...ymobile.com, andrew@...n.ch, skuribay@...ox.com,
christian.ruppert@...lis.com, Romain.Baeriswyl@...lis.com,
mika.westerberg@...ux.intel.com, linux-kernel@...r.kernel.org,
linux-i2c@...r.kernel.org
Subject: Re: [PATCH] i2c-designware: Intel BayTrail PMIC I2C bus support
On Fri, 12 Sep 2014 10:36:07 -0700
"David E. Box" <david.e.box@...ux.intel.com> wrote:
> +#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
> +extern int i2c_acquire_ownership(struct device *dev);
> +extern int i2c_release_ownership(struct device *dev);
> +#endif
You can just have the prototypes anyway - no need for more ifdefs than
required
> +#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
> +int i2c_shared_controller_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
> + int num)
> +{
> + struct dw_i2c_dev *dev = i2c_get_adapdata(adap);
> + int err;
> +
> + if (dev->shared_host) {
> + err = dev->acquire_ownership(dev->dev);
> + if (!err) {
> + err = i2c_dw_xfer(adap, msgs, num);
> + dev->release_ownership(dev->dev);
> + } else
> + dev_WARN(dev->dev, "couldnt acquire ownership\n");
> +
> + return err;
> + } else
> + return i2c_dw_xfer(adap, msgs, num);
> +}
> +
> +static struct i2c_algorithm i2c_sc_algo = {
> + .master_xfer = i2c_shared_controller_xfer,
> + .functionality = i2c_dw_func,
> +};
> +#endif
I think this might be a lot cleaner if you put these pieces as functions
into i2c-designware-sem.c or a similar file and made the methods NULL
functions in the header in the case it's not supported ? Most of the
ifdeffery would then vanish into the extra file and keep the core code
cleaner ?
Alan
--
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