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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 17-Mar-25 11:08, Francesco Dolcini wrote:
> 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@toradex.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.

So looking at drivers/platform/cznic this does not look like a good
example how to do things. I see multiple sub-drivers each in their
own file, but it is all directly linked using symbols from the modules
to each other.

The cznic code looks like a classic example where a MFD approach
creating child devices for each functions and having separate
drivers bind to each function would be a much cleaner way to
do things, especially since they now also have #ifdef's to allow
disabling some functions where as with the MFD approach one can
simply e.g. not build the GPIO driver at all.

Especially if you plan to re-use the baseboard / EC with possible
SOMs of a different architecture, in which case drivers/platform/aarch64
also seems like a bad fit.

The example of the MFD approach is that e.g. your GPIO driver can live
under drivers/gpio and thus will be reviewed by the GPIO subsystem
maintainers benefiting from all their experience with GPIO drivers.

But if Andy and Ilpo are happy to take this as a more monolithic
driver under drivers/platform/aarch64 I'm not going to nack that
approach.

Regards,

Hans