All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: gwendal@chromium.org, drinkcat@chromium.org,
	linux-kernel@vger.kernel.org, groeck@chromium.org,
	kernel@collabora.com, bleung@chromium.org,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver.
Date: Wed, 5 Dec 2018 07:25:23 +0000	[thread overview]
Message-ID: <20181205072523.GW26661@dell> (raw)
In-Reply-To: <8dcf0fb8-697f-8443-68c3-0faae6fe412e@collabora.com>

On Tue, 04 Dec 2018, Enric Balletbo i Serra wrote:
> On 4/12/18 10:21, Lee Jones wrote:
> > On Mon, 03 Dec 2018, Enric Balletbo i Serra wrote:
> >> On 3/12/18 11:36, Lee Jones wrote:
> >>> On Tue, 27 Nov 2018, Enric Balletbo i Serra wrote:
> >>>
> >>>> The entire way how cros sysfs attibutes are created is broken.
> >>>> cros_ec_lightbar should be its own driver and its attributes should be
> >>>> associated with a lightbar driver not the mfd driver. In order to retain
> >>>> the path, the lightbar attributes are attached to the cros_class.
> >>>
> >>> I'm not exactly clear on what a lightbar is, but shouldn't it live in
> >>> the appropriate subsystem.  Like LED for example?
> >>>
> >>
> >> The lightbar is a four-color indicator available on some Chromebook, but the
> >> fact that can you can program this lightbar with different sequences, including
> >> user defined sequences makes the device a bit special and very chrome platform
> >> specific. The same happens with the VBC driver.
> > 
> > Being Chrome specific doesn't necessarily mean that these drivers
> > shouldn't reside in a proper subsystem.  A lot of drivers in the
> > kernel are only relevant to very specific hardware/platforms.
> 
> Agree, and we try to put these drivers in their subsystem when we think it is
> appropriate (we have in rtc, power, iio, keyboard, etc.)

Right.  I can see that.  This is good.

> > IMHO code in drivers/platform should pertain only to the core platform
> > itself.  Any drivers for leaf hardware/functionality should be split
> > out into the subsystems, however niche you think they are.
> 
> To be honest, I don't have a hard opinion yet on if the drivers/platform should
> pertain only to the core platform itself.
> 
> The cros_ec_lightbar.c file already exists in drivers/platform, the patch just
> converts it to a kernel module (only adds few lines). The main purpose of the se
> patches was have cros-ec mfd code and their subdrivers separated instead of
> having crossed calls.

Right.  I have no intention of blocking *this* patch.  All we're doing
here is highlighting potential issues I see.

> I don't mind to move to another subsystem (I need to discuss with the chromium
> guys

Wonderful.  That's exactly what I wanted to hear.

> and I am still not sure if LED fits very well in this case, I can look in
> more detail)

Sure.

> but shouldn't be this a follow up patch?

Absolutely.

> I am also worried on how this could affect the current user interface. Well,
> something to look, right.

Right.

Thanks again for looking into this.  I will re-review your patch, this
time *not* taking the location of the driver into consideration.

> > I also understand the convenience factor of not having to go through
> > a !Google Maintainer, but this is not a loophole I'm prepared to
> > support. ;)
> > 
> >> Other subdevices like, rtc, keyboard, usbpd charger,etc. are already in their
> >> subsystems.
> >>
> >>>> The patch also adds the sysfs documentation.
> >>>>
> >>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>> ---
> >>>>
> >>>> Changes in v3:
> >>>> - Removed unneded check for ec_dev.
> >>>>
> >>>> Changes in v2:
> >>>> - Removed the two exported functions to attach/detach to the cros_class.
> >>>> - Use dev_warn instead of dev_err when adding the lightbar.
> >>>>
> >>>>  ...sfs-class-chromeos-driver-cros-ec-lightbar | 74 +++++++++++++++
> >>>>  drivers/mfd/cros_ec_dev.c                     | 24 ++---
> >>>>  drivers/mfd/cros_ec_dev.h                     |  6 --
> >>>>  drivers/platform/chrome/Kconfig               | 10 ++
> >>>>  drivers/platform/chrome/Makefile              |  3 +-
> >>>>  drivers/platform/chrome/cros_ec_lightbar.c    | 95 ++++++++++++++-----
> >>>>  include/linux/mfd/cros_ec.h                   |  1 -
> >>>>  7 files changed, 172 insertions(+), 41 deletions(-)
> >>>>  create mode 100644 Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> >>>
> > 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  parent reply	other threads:[~2018-12-05  7:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27 12:18 [PATCH v3 0/8] mfd / platform: cros_ec: move cros_ec sysfs attributes to its own drivers Enric Balletbo i Serra
2018-11-27 12:18 ` [PATCH v3 1/8] mfd / platform: cros_ec: use devm_mfd_add_devices Enric Balletbo i Serra
2018-11-29 23:30   ` Guenter Roeck
2018-12-03 10:32   ` Lee Jones
2018-12-03 22:13     ` Enric Balletbo i Serra
2018-12-04  9:22       ` Lee Jones
2018-11-27 12:18 ` [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver Enric Balletbo i Serra
2018-11-29 23:34   ` Guenter Roeck
2018-12-03 10:36   ` Lee Jones
2018-12-03 22:21     ` Enric Balletbo i Serra
2018-12-04  9:21       ` Lee Jones
2018-12-04 11:52         ` Enric Balletbo i Serra
2018-12-04 16:57           ` Guenter Roeck
2018-12-05  8:09             ` Lee Jones
2018-12-05  7:25           ` Lee Jones [this message]
2018-11-27 12:18 ` [PATCH v3 3/8] mfd / platform: cros_ec: move vbc " Enric Balletbo i Serra
2018-11-29 23:36   ` Guenter Roeck
2018-12-03 10:42   ` Lee Jones
2018-11-27 12:18 ` [PATCH v3 4/8] mfd / platform: cros_ec: move debugfs " Enric Balletbo i Serra
2018-12-03 10:55   ` Lee Jones
2018-12-10 18:04   ` Guenter Roeck
2018-11-27 12:18 ` [PATCH v3 5/8] mfd / platform: cros_ec: move device sysfs " Enric Balletbo i Serra
2018-12-03 10:56   ` Lee Jones
2018-12-10 18:13   ` Guenter Roeck
2018-12-10 18:22     ` Enric Balletbo i Serra
2018-12-10 18:28       ` Guenter Roeck
2018-12-10 21:27         ` Enric Balletbo Serra
2018-12-10 21:50           ` Guenter Roeck
2018-12-10 22:11             ` Enric Balletbo Serra
2018-12-10 22:25               ` Guenter Roeck
2018-11-27 12:18 ` [PATCH v3 6/8] mfd / platform: cros_ec: instantiate only if th EC has a VBC NVRAM Enric Balletbo i Serra
2018-12-03 10:57   ` Lee Jones
2018-12-10 18:15   ` Guenter Roeck
2018-12-10 18:30     ` Guenter Roeck
2018-11-27 12:18 ` [PATCH v3 7/8] platform/chrome: cros_ec_lightbar: instantiate only if the EC has a lightbar Enric Balletbo i Serra
2018-12-10 18:20   ` Guenter Roeck
2018-12-11 11:18     ` Enric Balletbo i Serra
2018-11-27 12:18 ` [PATCH v3 8/8] mfd: cros_ec: add a dev_release empty method Enric Balletbo i Serra
2018-11-27 17:29   ` Guenter Roeck
2018-11-27 17:52     ` Greg Kroah-Hartman
2018-11-29  1:17       ` Guenter Roeck
2018-11-29  7:55         ` Greg Kroah-Hartman
2018-11-29 22:11           ` Enric Balletbo i Serra
2018-11-29 22:28             ` Guenter Roeck
2018-11-30  8:30             ` Greg Kroah-Hartman

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=20181205072523.GW26661@dell \
    --to=lee.jones@linaro.org \
    --cc=bleung@chromium.org \
    --cc=drinkcat@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    /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.