linux-kernel - Re: [RFC PATCH v1 0/2] platform: toradex: Add toradex embedded controller

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: <20250317100856.GC17428@francesco-nb>
Date: Mon, 17 Mar 2025 11:08:56 +0100
From: Francesco Dolcini <francesco@...cini.it>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Francesco Dolcini <francesco@...cini.it>,
	Emanuele Ghidoli <ghidoliemanuele@...il.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Francesco Dolcini <francesco.dolcini@...adex.com>,
	Emanuele Ghidoli <emanuele.ghidoli@...adex.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	soc@...nel.org, Andy Shevchenko <andy@...nel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Subject: Re: [RFC PATCH v1 0/2] platform: toradex: Add toradex embedded
 controller

Hello Hans,
first thanks for the feedback.

On Thu, Mar 13, 2025 at 04:08:14PM +0100, Hans de Goede wrote:
> On 13-Mar-25 3:43 PM, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini@...adex.com>
> > 
> > This series adds support for the Toradex Embedded Controller, currently used
> > on Toradex SMARC iMX95 and iMX8MP boards, with more to come in the future.
> > 
> > The EC provides board power-off, reset and GPIO expander functionalities.
> > 
> > Sending it as an RFC to gather initial feedback on it before investing more
> > time in testing and adding the remaining functionalities, with that said both
> > the code and the binding are in condition to be wholly reviewed.
> > 
> > Emanuele Ghidoli (2):
> >   dt-bindings: firmware: add toradex,embedded-controller
> >   platform: toradex: add preliminary support for Embedded Controller
> 
> Thank you for your patches.
> 
> 2 remarks, as Andy already hinted at drivers/platform/arm64/ likely
> is a better location for this.

Ack.

This driver is not going to be specific of ARM64, but today we have only
ARM64 systems that would benefit from it. We might as well use it on a
RISCV based SoM in a few years.

With that said we'll move it there, we can always move it out if
anything changes on this regard.

> The reason for having ARM EC drivers there is that these are for
> x86-pc-like laptops with all the typical laptops bells and whistles
> like EC handled battery charging limits / spk/mic mute-leds built
> into keys on the keyboards. Special key handling (like mute, kbd
> backlight) done by the EC etc.
> 
> Since all the experience for dealing with those laptop-esque features
> and exporting them to userspace with a consistent userspace API is
> in hands of the maintainers of drivers/platform/x86 it was decided to
> add a new drivers/platform/arm64 directory maintained by the same folks.
> 
> If this EC driver's only functionality is: "The EC provides board
> power-off, reset and GPIO expander functionalities." I'm not sure
> that drivers/platform/arm64 is the best place for this.

The directory decision / architecture was mainly inspired by
`drivers/platform/cznic`.

This EC is used on a SMARC SoM [1][2], so we are not talking about a
laptop nor a device with a keyboard.

But we do have a power button, a LID switch, some handling and
coordination of low power mode and more.
This device is between the SOC, the PMIC, and various IOs used for
low-power, power-up/down, boot configuration (selecting the boot
device), ...

The short term goal is just the 2 basic functionalities mentioned in
the cover letter available to the driver:
 - power/reset (already implemented)
 - GPIO (working on it as we speak)

Starting small, and adding features when/if required.

> Also you mention GPIO expander, but that does not seem to be
> supported yet?
Correct, coming soon.

> 1. A drivers/mfd/ MFD driver with the regmap stuff,
>    registering "board-reset" and "gpio" cells

So, we considered the idea of going with an MFD driver, but looking at
drivers/platform/cznic, that is doing something relatively close to what
we are doing (just more feature rich, as of now), drivers/platform/
seemed a better fit.

I am not 100% sure what's Andy opinion on this topic, from what I can
understand his concerns are about the toradex directory (that we'll get
rid of), not the drivers/platform/ parent you are concerned about.

Francesco