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@xxxxxxxxxxx> >>> >>> 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
