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

[Enric Balletbo i Serra]

Hi Lee,

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.)

> 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.

I don't mind to move to another subsystem (I need to discuss with the chromium
guys and I am still not sure if LED fits very well in this case, I can look in
more detail) but shouldn't be this a follow up patch?

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

Thanks,
 Enric


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