Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver.

[Lee Jones]

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@xxxxxxxxxxxxx>
> >>>> ---
> >>>>
> >>>> 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