All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Olof Johansson <olof@lixom.net>,
	Doug Anderson <dianders@chromium.org>,
	Bill Richardson <wfrichar@chromium.org>,
	Simon Glass <sjg@google.com>,
	Gwendal Grignou <gwendal@google.com>,
	Stephen Barber <smbarber@chromium.org>,
	Filipe Brandenburger <filbranden@google.com>,
	Todd Broch <tbroch@chromium.org>,
	Alexandru M Stan <amstan@chromium.org>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Gwendal Grignou <gwendal@chromium.org>
Subject: Re: [PATCH v3 6/7] mfd: cros_ec: Support multiple EC in a system
Date: Wed, 27 May 2015 10:11:54 +0100	[thread overview]
Message-ID: <20150527091154.GX11677@x1> (raw)
In-Reply-To: <1432309340-13688-7-git-send-email-javier.martinez@collabora.co.uk>

On Fri, 22 May 2015, Javier Martinez Canillas wrote:

> From: Gwendal Grignou <gwendal@chromium.org>
> 
> Chromebooks can have more than one Embedded Controller so the
> cros_ec device id has to be incremented for each EC registered.
> 
> Add code to handle multiple EC. First ec found is cros-ec0,
> second cros-ec1 and so on.
> 
> Add a new structure to represent multiple EC as different char
> devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
> cros_ec_device and allows sysfs inferface for cros_pd.
> 
> Also reduce number of allocated objects, make chromeos sysfs
> class object a static and add refcounting to prevent object
> deletion while command is in progress.
> 
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> 
> Changes since v2: None
> 
> Changes since v1:
>   - Squash patch that adds support to represent EC's as different
>     char devices (e.g: /dev/cros_ec, /dev/cros_pd):
>     https://chromium-review.googlesource.com/#/c/217297/
>     Suggested by Gwendal Grignou
>   - Use cros_ec instead of cros-ec in the subject line to be consistent.
>     Suggested by Gwendal Grignou
> ---
>  drivers/input/keyboard/cros_ec_keyb.c      |   2 +-
>  drivers/mfd/cros_ec.c                      |  66 +++++++++++++--
>  drivers/mfd/cros_ec_i2c.c                  |   1 -
>  drivers/mfd/cros_ec_spi.c                  |   1 -
>  drivers/platform/chrome/cros_ec_dev.c      | 128 ++++++++++++++++++++---------
>  drivers/platform/chrome/cros_ec_dev.h      |   7 --
>  drivers/platform/chrome/cros_ec_lightbar.c |  75 +++++++++--------
>  drivers/platform/chrome/cros_ec_lpc.c      |   1 -
>  drivers/platform/chrome/cros_ec_sysfs.c    |  48 +++++------
>  include/linux/mfd/cros_ec.h                |  44 ++++++++--
>  10 files changed, 247 insertions(+), 126 deletions(-)
> 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 974154a74505..b01966dc7eb3 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -275,7 +275,7 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
>  	ckdev->dev = dev;
>  	dev_set_drvdata(&pdev->dev, ckdev);
>  
> -	idev->name = ec->ec_name;
> +	idev->name = CROS_EC_DEV_NAME;
>  	idev->phys = ec->phys_name;
>  	__set_bit(EV_REP, idev->evbit);
>  
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 08d82bfc5268..99292bc2fe5f 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -24,12 +24,48 @@
>  #include <linux/mfd/core.h>
>  #include <linux/mfd/cros_ec.h>
>  
> -static const struct mfd_cell cros_devs[] = {
> -	{
> +static int dev_id;
> +
> +static int cros_ec_dev_register(struct cros_ec_device *ec_dev,
> +				int dev_id, int devidx)

What's the difference between dev_id and devidx.

Confusing don't you think?

> +{
> +	struct device *dev = ec_dev->dev;
> +	struct cros_ec_platform ec_p = {
> +		.cmd_offset = 0,
> +	};
> +
> +	struct mfd_cell ec_cell = {
>  		.name = "cros-ec-ctl",
>  		.id = PLATFORM_DEVID_AUTO,
> -	},
> -};
> +		.platform_data = &ec_p,
> +		.pdata_size = sizeof(ec_p),
> +	};

Why have you bought this into here?  The convention is usually to have
this at the top of the file, outside any functions.  Declaring and
initialising structs inside functions makes things looks messy IMHO.



> +	switch (devidx) {
> +	case 0:

Please define these.  I have no idea what devidx 0 or 1 is.

> +		if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> +			ec_p.ec_name = of_get_property(dev->of_node, "devname",
> +						       NULL);
> +			if (ec_p.ec_name == NULL) {

if (!ec_p.ec_name)

> +				dev_dbg(dev,
> +					"Device name not found, using default");
> +				ec_p.ec_name = CROS_EC_DEV_NAME;
> +			}
> +		} else {
> +			ec_p.ec_name = CROS_EC_DEV_NAME;
> +		}

I'd save yourself a few lines and do:

if (OF)
   name = get_name();

if (!name)
   name = DEFAULT_NAME;

Then rid the 'else'.  Rid the dev_dbg() too if you can.

> +		break;
> +	case 1:
> +		ec_p.ec_name = CROS_EC_DEV_PD_NAME;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	ec_p.cmd_offset = EC_CMD_PASSTHRU_OFFSET(devidx);

'\n' here.

> +	return mfd_add_devices(dev, dev_id, &ec_cell, 1,
> +			       NULL, ec_dev->irq, NULL);
> +}
>  
>  int cros_ec_register(struct cros_ec_device *ec_dev)
>  {
> @@ -52,14 +88,28 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>  
>  	cros_ec_query_all(ec_dev);
>  
> -	err = mfd_add_devices(dev, 0, cros_devs,
> -			      ARRAY_SIZE(cros_devs),
> -			      NULL, ec_dev->irq, NULL);
> +	err = cros_ec_dev_register(ec_dev, dev_id++, 0);
>  	if (err) {
> -		dev_err(dev, "failed to add mfd devices\n");
> +		dev_err(dev, "failed to add ec\n");
>  		return err;
>  	}
>  
> +	if (ec_dev->max_passthru) {
> +		/*
> +		 * Register a PD device as well on top of this device.
> +		 * We make the following assumptions:
> +		 * - behind an EC, we have a pd
> +		 * - only one device added.
> +		 * - the EC is responsive at init time (it is not true for a
> +		 *   sensor hub.
> +		 */
> +		err = cros_ec_dev_register(ec_dev, dev_id++, 1);

I don't really like this devidx business.  Just keep it simple and
define more than one mfd_cell structure.

> +		if (err) {
> +			dev_err(dev, "failed to add additional ec\n");
> +			return err;
> +		}
> +	}
> +
>  	if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
>  		err = of_platform_populate(dev->of_node, NULL, NULL, dev);
>  		if (err) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-05-27  9:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-22 15:42 [PATCH v3 0/7] mfd: cros_ec: Add multi EC and proto v3 support Javier Martinez Canillas
2015-05-22 15:42 ` [PATCH v3 1/7] mfd: cros_ec: Use a zero-length array for command data Javier Martinez Canillas
2015-05-27  8:36   ` Lee Jones
2015-05-27  8:39     ` Javier Martinez Canillas
2015-05-22 15:42 ` [PATCH v3 2/7] mfd: cros_ec: rev cros_ec_commands.h Javier Martinez Canillas
2015-05-22 15:42 ` [PATCH v3 3/7] mfd: cros_ec: Move protocol helpers out of the MFD driver Javier Martinez Canillas
2015-05-27  8:38   ` Lee Jones
2015-05-22 15:42 ` [PATCH v3 4/7] mfd: cros_ec: add proto v3 skeleton Javier Martinez Canillas
2015-05-27  8:39   ` Lee Jones
2015-05-22 15:42 ` [PATCH v3 5/7] mfd: cros_ec: add bus-specific proto v3 code Javier Martinez Canillas
2015-05-27  8:53   ` Lee Jones
2015-05-27  9:06     ` Javier Martinez Canillas
2015-05-22 15:42 ` [PATCH v3 6/7] mfd: cros_ec: Support multiple EC in a system Javier Martinez Canillas
2015-05-27  9:11   ` Lee Jones [this message]
2015-05-28 14:00     ` Javier Martinez Canillas
2015-05-28 14:26       ` Lee Jones
2015-05-28 14:28         ` Javier Martinez Canillas
2015-05-22 15:42 ` [PATCH v3 7/7] mfd: cros_ec: spi: Add delay for asserting CS Javier Martinez Canillas
2015-05-27  9:14   ` Lee Jones
2015-05-22 19:28 ` [PATCH v3 0/7] mfd: cros_ec: Add multi EC and proto v3 support Heiko Stuebner

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=20150527091154.GX11677@x1 \
    --to=lee.jones@linaro.org \
    --cc=amstan@chromium.org \
    --cc=dianders@chromium.org \
    --cc=filbranden@google.com \
    --cc=gwendal@chromium.org \
    --cc=gwendal@google.com \
    --cc=heiko@sntech.de \
    --cc=javier.martinez@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sameo@linux.intel.com \
    --cc=sjg@google.com \
    --cc=smbarber@chromium.org \
    --cc=tbroch@chromium.org \
    --cc=wfrichar@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.