lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7dab7267-a5f2-4b03-bb45-92b836e42c28@t-8ch.de>
Date: Mon, 6 May 2024 19:48:14 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: "Limonciello, Mario" <mario.limonciello@....com>
Cc: Lee Jones <lee@...nel.org>, Benson Leung <bleung@...omium.org>, 
	Guenter Roeck <groeck@...omium.org>, Tzung-Bi Shih <tzungbi@...nel.org>, linux-kernel@...r.kernel.org, 
	chrome-platform@...ts.linux.dev, "Dustin L. Howett" <dustin@...ett.net>, 
	Sebastian Reichel <sre@...nel.org>, linux-pm@...r.kernel.org
Subject: Re: [PATCH 1/2] platform/chrome: cros_ec_framework_laptop: introduce
 driver

On 2024-05-06 08:10:58+0000, Limonciello, Mario wrote:
> 
> 
> On 5/5/2024 3:56 PM, Thomas Weißschuh wrote:
> > Framework Laptops are using embedded controller firmware based on the
> > ChromeOS EC project.
> > In addition to the standard upstream commands, some vendor-specific
> > ones are implemented.
> > 
> > Add a driver for those custom EC commands.
> > 
> > At first, provide an empty driver that only takes care of scaffolding and
> > device binding.
> > Further patches will add functionality to the driver.
> > 
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> > ---
> >   MAINTAINERS                                        |  5 ++
> >   drivers/mfd/cros_ec_dev.c                          | 13 ++++++
> >   drivers/platform/chrome/Kconfig                    | 11 +++++
> >   drivers/platform/chrome/Makefile                   |  1 +
> >   drivers/platform/chrome/cros_ec_framework_laptop.c | 53 ++++++++++++++++++++++
> >   5 files changed, 83 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c23fda1aa1f0..60699c289757 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4988,6 +4988,11 @@ S:	Maintained
> >   F:	Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
> >   F:	sound/soc/codecs/cros_ec_codec.*
> > +CHROMEOS EC FRAMEWORK LAPTOP EXTENSIONS
> > +M:	Thomas Weißschuh <linux@...ssschuh.net>
> > +S:	Maintained
> > +F:	drivers/platform/chrome/cros_ec_framework_laptop.c
> > +
> >   CHROMEOS EC SUBDRIVERS
> >   M:	Benson Leung <bleung@...omium.org>
> >   R:	Guenter Roeck <groeck@...omium.org>
> > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > index a52d59cc2b1e..0a36e77e5039 100644
> > --- a/drivers/mfd/cros_ec_dev.c
> > +++ b/drivers/mfd/cros_ec_dev.c
> > @@ -145,6 +145,10 @@ static const struct mfd_cell cros_ec_vbc_cells[] = {
> >   	{ .name = "cros-ec-vbc", }
> >   };
> > +static const struct mfd_cell cros_ec_framework_cells[] = {
> > +	{ .name = "cros-ec-framework", }
> > +};
> > +
> >   static void cros_ec_class_release(struct device *dev)
> >   {
> >   	kfree(to_cros_ec_dev(dev));
> > @@ -299,6 +303,15 @@ static int ec_device_probe(struct platform_device *pdev)
> >   				 retval);
> >   	}
> > +	 /* The EC on Framework laptops implements some nonstandard features */
> 
> I don't think there is a spec really for cros_ec is there?  I think it will
> depend upon what features you're talking about if this is the right way to
> go.

I equate "standard" with "mainline".

> The reason I say this is that maybe some of the same kinds of features will
> make sense for chromebooks that use cros_ec in the future and thus they
> should be "generic" cros_ec mfd cells to probe for in some way.

The commands identifiers are just numbers.
So if multiple vendors use the same numbers there could be collisions.
By loading the subdriver only for the correct vendors devices we avoid those.

If other vendors or mainline CrOS EC implements the same commands we can
revisit this and move the functionality to a generic mfd cell.

But after the discussions on the cover letter, let's first see if a
vendor-specific driver is needed at all.

Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ