[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8dcf0fb8-697f-8443-68c3-0faae6fe412e@collabora.com>
Date: Tue, 4 Dec 2018 12:52:52 +0100
From: Enric Balletbo i Serra <enric.balletbo@...labora.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: gwendal@...omium.org, drinkcat@...omium.org,
linux-kernel@...r.kernel.org, groeck@...omium.org,
kernel@...labora.com, bleung@...omium.org,
Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes
to its own driver.
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@...labora.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
>>>
>
Powered by blists - more mailing lists