Yes, I was looking at the G505S and its EC when considering these patches.

The situation with the EC in the G505S seems a bit odd. The EC is named `ene932`, but there are several commits in the codebase which reference the chip as a KB9012. The KB9012 datasheet, however, reference the ENE930 series chips as the predecessor chip to the KB9010 series.

The S230U has a KB9012 and the Compal firmware seems to have a similar `OperationRegion` layout to the firmware in the `ene932`, but the EC query values are completely different. The S230U basically defines its own EC in its mainboard tree and only uses the `ene932` code for its helper I/O space functions.

If anyone has a G505S or its vendor documentation to check that the chip on the board is really an ENE930 series, I think that would help clear this up.

This is something I was considering trying to refactor as well, by giving the S230U its own `ec/` common code. However, I would probably throw that patch in with my mainboard's patchset (Lenovo Edge E530), since otherwise the S230U would be the only user of that code.

From: Ivan Ivanov <qmastery16@gmail.com>
Sent: Friday, April 8, 2022, 4:38 AM
To: Abel Briggs <abelbriggs1@hotmail.com>
Cc: coreboot@coreboot.org <coreboot@coreboot.org>
Subject: Re: [coreboot] Refactoring duplicate Embedded Controller code

If this could help you, coreboot-supported Lenovo G505S also has EC KB9012

ÞÔ, 7 ÁÐÒ. 2022 Ç. × 06:44, Abel Briggs <abelbriggs1@hotmail.com>:
>
> Hello,
>
> I was looking at the code and ACPI for a number of different embedded
> controllers while adding support for a Lenovo mainboard.
> The mainboard in question has an EC nearly identical to the Twist S230U
> (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI
> into its own chip.
>
> While doing this, I noticed there were several duplicate functions
> across the `ec/` directory, so I'd like to potentially submit some
> patches to clean them up. However, I'm not sure of the best way to
> go about this.
>
> The following is what I currently have in mind:
>
> - Removing most individual `ec_write_cmd()`
>   and similar functions andreplacing calls with their respective `ec/acpi/ec.c` library functions
> - Removing individual `kbc_` polling functions and sharing the ones defined
>   in `drivers/pc80/keyboard.c`
>   - Should public library functions for sending and receiving data from
>     a PC80 keyboard controller be defined in the PC80 driver and exported
>     in `include/pc80/keyboard.h`?
>   - We already have `send_keyboard()` there,
>     which sends a command and receives data - would it be good to add
>     individual functions for those operations as well?
>
> Any suggestions or recommendations would be appreciated. I looked for
> guidelines on suggested code organization in the docs/commit history/
> mailing list, but came up mostly empty-handed.
>
> Thanks!
>
> _______________________________________________
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-leave@coreboot.org