Messages in this thread | | | Date | Wed, 5 Dec 2018 07:25:23 +0000 | From | Lee Jones <> | Subject | Re: [PATCH v3 2/8] mfd / platform: cros_ec: move lightbar attributes to its own driver. |
| |
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
| |