| Message ID | 20230721122931.505957-1-dober6023@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] Watchdog: New module for ITE 5632 watchdog | expand |
On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: > This modules is to allow for the new ITE 5632 EC chip > to support the watchdog for initial use in the Lenovo SE10 > > Signed-off-by: David Ober <dober6023@gmail.com> > > V2 Fix stop to deactivate wdog on unload of module > V2 Remove extra logging that is not needed > V2 change udelays to usleep_range > V2 Changed to now request region on start and release on stop instead > of for every ping and read/write > V3 add counter to while loops so it will not hang > V3 rework code to use platform_device_register_simple > V3 rework getting the Chip ID to remove duplicate code and close IO > V3 change some extra logging to be debug only > --- > drivers/watchdog/Kconfig | 10 ++ > drivers/watchdog/Makefile | 1 + > drivers/watchdog/ite5632_wdt.c | 278 +++++++++++++++++++++++++++++++++ > 3 files changed, 289 insertions(+) > create mode 100644 drivers/watchdog/ite5632_wdt.c > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index ee97d89dfc11..861cc0eff468 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -264,6 +264,16 @@ config MENZ069_WATCHDOG > This driver can also be built as a module. If so the module > will be called menz069_wdt. > > +config ITE5632_WDT > + tristate "ITE 5632" > + select WATCHDOG_CORE > + help > + If you say yes here you get support for the watchdog > + functionality of the ITE 5632 eSIO chip. > + > + This driver can also be built as a module. If so, the module > + will be called ite5632_wdt. > + > config WDAT_WDT > tristate "ACPI Watchdog Action Table (WDAT)" > depends on ACPI > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 3633f5b98236..32c8340f3175 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -119,6 +119,7 @@ obj-$(CONFIG_WAFER_WDT) += wafer5823wdt.o > obj-$(CONFIG_I6300ESB_WDT) += i6300esb.o > obj-$(CONFIG_IE6XX_WDT) += ie6xx_wdt.o > obj-$(CONFIG_ITCO_WDT) += iTCO_wdt.o > +obj-$(CONFIG_ITE5632_WDT) += ite5632_wdt.o > ifeq ($(CONFIG_ITCO_VENDOR_SUPPORT),y) > obj-$(CONFIG_ITCO_WDT) += iTCO_vendor_support.o > endif > diff --git a/drivers/watchdog/ite5632_wdt.c b/drivers/watchdog/ite5632_wdt.c > new file mode 100644 > index 000000000000..efa0881eef4a > --- /dev/null > +++ b/drivers/watchdog/ite5632_wdt.c > @@ -0,0 +1,278 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Customized ITE5632 WDT driver for Lenovo SE10. > + * > + */ > + > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > +#include <linux/delay.h> > +#include <linux/init.h> > +#include <linux/io.h> > +#include <linux/ioport.h> > +#include <linux/module.h> > +#include <linux/moduleparam.h> > +#include <linux/platform_device.h> > +#include <linux/string.h> > +#include <linux/types.h> > +#include <linux/watchdog.h> > + > +#define ITE5632_SIO_UNLOCK_KEY 0x87 > +#define ITE5632_SIO_LOCK_KEY 0xAA > + > +#define EC_STATUS_port 0x6C > +#define EC_CMD_port 0x6C > +#define EC_DATA_port 0x68 > +#define EC_OBF 0x01 > +#define EC_IBF 0x02 > +#define CFG_LDN 0x07 > +#define CFG_BRAM_LDN 0x10 /* for BRAM Base */ > +#define CFG_PORT 0x2E > + > +#define CUS_WDT_SWI 0x1A > +#define CUS_WDT_CFG 0x1B > +#define CUS_WDT_FEED 0xB0 > +#define CUS_WDT_CNT 0xB1 > + > +#define DRVNAME "ite5632" > + > +/*The timeout range is 1-255 seconds*/ > +#define MIN_TIMEOUT 1 > +#define MAX_TIMEOUT 255 > +#define MAX_WAIT 10 > + > +#define WATCHDOG_TIMEOUT 60 /* 60 sec default timeout */ > +static unsigned short bram_base; > + > +static int timeout; /* in seconds */ > +module_param(timeout, int, 0); > +MODULE_PARM_DESC(timeout, > + "Watchdog timeout in seconds. 1 <= timeout <= 255, default=" > + __MODULE_STRING(WATCHDOG_TIMEOUT) "."); > + > +static bool nowayout = WATCHDOG_NOWAYOUT; > +module_param(nowayout, bool, 0); > +MODULE_PARM_DESC(nowayout, > + "Watchdog cannot be stopped once started (default=" > + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")"); > + > +/* the watchdog platform device */ > +static struct platform_device *ite5632wdt_platform_device; > + > +/* Kernel methods. */ > +static void set_bram(unsigned char offset, unsigned char val) > +{ > + outb(offset, bram_base); > + outb(val, bram_base + 1); > +} > + > +/* wait EC output buffer full */ > +static void wait_EC_OBF(void) > +{ > + int loop = 0; > + > + while (1) { > + if (inb(EC_STATUS_port) & EC_OBF || loop > MAX_WAIT) > + break; > + loop++; > + usleep_range(10, 125); > + } > +} > + > +/* wait EC input buffer empty */ > +static void wait_EC_IBE(void) > +{ > + int loop = 0; > + > + while (1) { > + if (!(inb(EC_STATUS_port) & EC_IBF) || loop > MAX_WAIT) > + break; > + loop++; > + usleep_range(10, 125); > + } > +} > + > +static void send_EC_cmd(unsigned char eccmd) > +{ > + wait_EC_IBE(); > + outb(eccmd, EC_CMD_port); > + wait_EC_IBE(); > +} > + > +static unsigned char Read_EC_data(void) > +{ > + wait_EC_OBF(); > + return inb(EC_DATA_port); > +} > + > +static void LPC_Write_Byte(unsigned char index, unsigned char data) > +{ > + outb(index, CFG_PORT); > + outb(data, CFG_PORT + 1); > +} > + > +static unsigned char LPC_Read_Byte(unsigned char index) > +{ > + outb(index, CFG_PORT); > + return inb(CFG_PORT + 1); > +} > + > +static int GetChipID(void) > +{ > + unsigned char MSB, LSB; > + unsigned char cmd = 0x55; > + > + outb(ITE5632_SIO_UNLOCK_KEY, CFG_PORT); > + outb(0x01, CFG_PORT); > + outb(0x55, CFG_PORT); > + outb(cmd, CFG_PORT); > + MSB = LPC_Read_Byte(0x20); > + LSB = LPC_Read_Byte(0x21); > + outb(ITE5632_SIO_LOCK_KEY, CFG_PORT); > + return (MSB * 256 + LSB); > +} > + > +static int wdt_start(struct watchdog_device *wdog) > +{ > + set_bram(CUS_WDT_SWI, 0x80); > + return 0; > +} > + > +static int wdt_set_timeout(struct watchdog_device *wdog, unsigned int timeout) > +{ > + wdog->timeout = timeout; > + set_bram(CUS_WDT_CFG, wdog->timeout); > + return 0; > +} > + > +static int wdt_stop(struct watchdog_device *wdog) > +{ > + set_bram(CUS_WDT_SWI, 0); > + return 0; > +} > + > +static unsigned int wdt_get_time(struct watchdog_device *wdog) > +{ > + unsigned int timeleft; > + > + send_EC_cmd(CUS_WDT_CNT); > + > + timeleft = Read_EC_data(); > + return timeleft; > +} > + > +static int wdt_ping(struct watchdog_device *wdog) > +{ > + send_EC_cmd(CUS_WDT_FEED); > + return 0; > +} > + > +/* Kernel Interfaces */ > +static const struct watchdog_info wdt_info = { > + .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE, > + .identity = "5632 Watchdog", > +}; > + > +static const struct watchdog_ops wdt_ops = { > + .owner = THIS_MODULE, > + .start = wdt_start, > + .stop = wdt_stop, > + .ping = wdt_ping, > + .set_timeout = wdt_set_timeout, > + .get_timeleft = wdt_get_time, > +}; > + > +static int ite5632_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct watchdog_device *wdt; > + int ret; > + > + dev_dbg(&pdev->dev, "Probe ITE5632 called\n"); > + > + wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL); > + if (!wdt) { > + release_region(EC_DATA_port, 5); > + return -ENOMEM; > + } > + > + wdt->info = &wdt_info, > + wdt->ops = &wdt_ops, > + wdt->timeout = WATCHDOG_TIMEOUT; /* Set default timeout */ > + wdt->min_timeout = MIN_TIMEOUT; > + wdt->max_timeout = MAX_TIMEOUT; > + wdt->parent = &pdev->dev; > + > + watchdog_init_timeout(wdt, timeout, &pdev->dev); > + watchdog_set_nowayout(wdt, nowayout); > + watchdog_stop_on_reboot(wdt); > + watchdog_stop_on_unregister(wdt); > + > + ret = devm_watchdog_register_device(dev, wdt); > + > + dev_dbg(&pdev->dev, "initialized. timeout=%d sec (nowayout=%d)\n", > + wdt->timeout, nowayout); > + > + return ret; > +} > + > +static struct platform_driver ite5632_driver = { > + .driver = { > + .name = DRVNAME, > + }, > + .probe = ite5632_probe, > +}; > + > +static int __init wdt_init(void) > +{ > + int err; > + int chip; > + > + if (!request_region(EC_DATA_port, 5, "EC")) { > + pr_err(":request fail\n"); > + return -EIO; > + } > + chip = GetChipID(); > + > + if (chip != 0x5632) { > + release_region(EC_DATA_port, 5); > + return -ENODEV; > + } > + pr_info("Found ITE ChipID = %4X\n", chip); > + > + LPC_Write_Byte(CFG_LDN, CFG_BRAM_LDN); > + bram_base = (LPC_Read_Byte(0x60) << 8) | LPC_Read_Byte(0x61); > + > + ite5632wdt_platform_device = platform_device_register_simple(DRVNAME, > + -1, NULL, 0); > + if (IS_ERR(ite5632wdt_platform_device)) { > + release_region(EC_DATA_port, 5); > + return PTR_ERR(ite5632wdt_platform_device); > + } > + > + err = platform_driver_probe(&ite5632_driver, ite5632_probe); > + if (err) > + goto unreg_platform_device; > + > + return 0; > + > +unreg_platform_device: > + platform_device_unregister(ite5632wdt_platform_device); > + release_region(EC_DATA_port, 5); > + return err; > +} > + > +static void __exit wdt_exit(void) > +{ > + platform_device_unregister(ite5632wdt_platform_device); > + platform_driver_unregister(&ite5632_driver); > + > + release_region(EC_DATA_port, 5); > +} > + > +module_init(wdt_init); > +module_exit(wdt_exit); > + > +MODULE_LICENSE("GPL"); > +MODULE_AUTHOR("David Ober<dober@lenovo.com>"); > +MODULE_DESCRIPTION("WDT driver for ITE5632"); > -- > 2.34.1 Tested this on my SE10 using the kernel selftests watchdog-test utility and it worked well. Was able to configure timeouts and system rebooted when either hung via sysrq-trigger; or by pausing the watchdog feeding. Was able to enable and then disable the watchdog and not trigger a reboot. Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. Mark
On 2/23/24 11:58, Mark Pearson wrote: > On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >> This modules is to allow for the new ITE 5632 EC chip >> to support the watchdog for initial use in the Lenovo SE10 >> >> Signed-off-by: David Ober <dober6023@gmail.com> >> >> V2 Fix stop to deactivate wdog on unload of module >> V2 Remove extra logging that is not needed >> V2 change udelays to usleep_range >> V2 Changed to now request region on start and release on stop instead >> of for every ping and read/write >> V3 add counter to while loops so it will not hang >> V3 rework code to use platform_device_register_simple >> V3 rework getting the Chip ID to remove duplicate code and close IO >> V3 change some extra logging to be debug only >> --- [ ... ] >> +config ITE5632_WDT >> + tristate "ITE 5632" >> + select WATCHDOG_CORE >> + help >> + If you say yes here you get support for the watchdog >> + functionality of the ITE 5632 eSIO chip. >> + >> + This driver can also be built as a module. If so, the module >> + will be called ite5632_wdt. >> + [ ... ] > > > Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. > I am sure I commented on this before. The fact that the Lenovo SE10 uses an ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to replace the ITE chip with a Nuvoton chip, use the same API to talk with it, and the watchdog would work perfectly fine. This is a driver for the watchdog implemented in the embedded controller on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip used in that Lenovo system is completely irrelevant, even more so since this seems to be one of those undocumented ITE chips which officially don't even exist. Claiming that this would be a watchdog driver for ITE5632 would be not only misleading but simply wrong. It seems that we can not agree on this. That means that, from my perspective, there is no real path to move forward. Wim will have to decide if and how to proceed. Thanks, Guenter
Thanks Guenter On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: > On 2/23/24 11:58, Mark Pearson wrote: >> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>> This modules is to allow for the new ITE 5632 EC chip >>> to support the watchdog for initial use in the Lenovo SE10 >>> >>> Signed-off-by: David Ober <dober6023@gmail.com> >>> >>> V2 Fix stop to deactivate wdog on unload of module >>> V2 Remove extra logging that is not needed >>> V2 change udelays to usleep_range >>> V2 Changed to now request region on start and release on stop instead >>> of for every ping and read/write >>> V3 add counter to while loops so it will not hang >>> V3 rework code to use platform_device_register_simple >>> V3 rework getting the Chip ID to remove duplicate code and close IO >>> V3 change some extra logging to be debug only >>> --- > [ ... ] >>> +config ITE5632_WDT >>> + tristate "ITE 5632" >>> + select WATCHDOG_CORE >>> + help >>> + If you say yes here you get support for the watchdog >>> + functionality of the ITE 5632 eSIO chip. >>> + >>> + This driver can also be built as a module. If so, the module >>> + will be called ite5632_wdt. >>> + > > [ ... ] > >> >> >> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >> > > I am sure I commented on this before. The fact that the Lenovo SE10 uses an > ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to > replace the ITE chip with a Nuvoton chip, use the same API to talk with it, > and the watchdog would work perfectly fine. > > This is a driver for the watchdog implemented in the embedded controller > on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip > used in that Lenovo system is completely irrelevant, even more so since > this seems to be one of those undocumented ITE chips which officially > don't even exist. Claiming that this would be a watchdog driver for ITE5632 > would be not only misleading but simply wrong. > > It seems that we can not agree on this. That means that, from my perspective, > there is no real path to move forward. Wim will have to decide if and how > to proceed. > My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? If it's more subtle than that, is there something you propose instead? Thanks Mark
On 2/23/24 16:43, Mark Pearson wrote: > Thanks Guenter > > On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >> On 2/23/24 11:58, Mark Pearson wrote: >>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>> This modules is to allow for the new ITE 5632 EC chip >>>> to support the watchdog for initial use in the Lenovo SE10 >>>> >>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>> >>>> V2 Fix stop to deactivate wdog on unload of module >>>> V2 Remove extra logging that is not needed >>>> V2 change udelays to usleep_range >>>> V2 Changed to now request region on start and release on stop instead >>>> of for every ping and read/write >>>> V3 add counter to while loops so it will not hang >>>> V3 rework code to use platform_device_register_simple >>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>> V3 change some extra logging to be debug only >>>> --- >> [ ... ] >>>> +config ITE5632_WDT >>>> + tristate "ITE 5632" >>>> + select WATCHDOG_CORE >>>> + help >>>> + If you say yes here you get support for the watchdog >>>> + functionality of the ITE 5632 eSIO chip. >>>> + >>>> + This driver can also be built as a module. If so, the module >>>> + will be called ite5632_wdt. >>>> + >> >> [ ... ] >> >>> >>> >>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>> >> >> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >> and the watchdog would work perfectly fine. >> >> This is a driver for the watchdog implemented in the embedded controller >> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >> used in that Lenovo system is completely irrelevant, even more so since >> this seems to be one of those undocumented ITE chips which officially >> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >> would be not only misleading but simply wrong. >> >> It seems that we can not agree on this. That means that, from my perspective, >> there is no real path to move forward. Wim will have to decide if and how >> to proceed. >> > My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. > > Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? > There would have to be additional changes. For example, the driver does not return errors if its wait loops time out, and it doesn't reserve the IO address range used by the chip. Tying the wait time to the number of wait loops and not to the elapsed time is also something that would need to be explained. Also, I notice that the communication is similar to the communication with Super-IO chips from ITE, but not the same. Specifically, the unlock key is the same, but the lock key is different. This means that the code may unlock other chips from ITE in a given system, but not lock them. Some of those chips are ... let's call it less then perfect. They will act oddly on the bus if left unlocked. Some of those chips will act oddly if an attempt is made to lock them after unlocking them, and they have to remain unlocked to avoid corrupting communication with other chips on the same bus. The impact on other chips from the same vendor will have to be explored further. > I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? > Why would that be the case ? Maybe I am missing something essential. If you insist to tie this driver to the ITE5632 and not to the system, you will have to provide additional information. The chip does not even exist in public, so no one but you and ITE really knows what its capabilities are. Is this is a chip which is used, or is going to be used, in a variety of systems, possibly including systems from other vendors ? Is the communication between main CPU and the chip tied to the chip and will/may only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like chip with fixed capabilities, or is it a programmed micro-controller ? To a large degree all that is due to ITE and its customers not providing information about their chips to the public. Due to that lack of information, my assumption was that it is a programmed micro-controller. The code itself suggests, through the use of the term "EC" in the driver, that it is an embedded controller, not a Suoer-IO or other fixed-capability chip. If that is not the case, and if the communication with the chip is fixed and not programmable, you'll have to explain that. If it is an EC, the protocol is defined by its microcode, and the driver needs to be tied to the systems using that microcode. If it is a fixed-capability chip, the driver should not suggest that it communicates with an embedded controller but with a fixed-capability chip. Thanks, Guenter
Thanks Guenter, On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: > On 2/23/24 16:43, Mark Pearson wrote: >> Thanks Guenter >> >> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>> On 2/23/24 11:58, Mark Pearson wrote: >>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>> This modules is to allow for the new ITE 5632 EC chip >>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>> >>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>> >>>>> V2 Fix stop to deactivate wdog on unload of module >>>>> V2 Remove extra logging that is not needed >>>>> V2 change udelays to usleep_range >>>>> V2 Changed to now request region on start and release on stop instead >>>>> of for every ping and read/write >>>>> V3 add counter to while loops so it will not hang >>>>> V3 rework code to use platform_device_register_simple >>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>> V3 change some extra logging to be debug only >>>>> --- >>> [ ... ] >>>>> +config ITE5632_WDT >>>>> + tristate "ITE 5632" >>>>> + select WATCHDOG_CORE >>>>> + help >>>>> + If you say yes here you get support for the watchdog >>>>> + functionality of the ITE 5632 eSIO chip. >>>>> + >>>>> + This driver can also be built as a module. If so, the module >>>>> + will be called ite5632_wdt. >>>>> + >>> >>> [ ... ] >>> >>>> >>>> >>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>> >>> >>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>> and the watchdog would work perfectly fine. >>> >>> This is a driver for the watchdog implemented in the embedded controller >>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>> used in that Lenovo system is completely irrelevant, even more so since >>> this seems to be one of those undocumented ITE chips which officially >>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>> would be not only misleading but simply wrong. >>> >>> It seems that we can not agree on this. That means that, from my perspective, >>> there is no real path to move forward. Wim will have to decide if and how >>> to proceed. >>> >> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >> >> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >> > > There would have to be additional changes. For example, the driver does not > return errors if its wait loops time out, and it doesn't reserve the IO address > range used by the chip. Tying the wait time to the number of wait loops > and not to the elapsed time is also something that would need to be explained. > Ack - we can look at those. Thanks for the feedback. > Also, I notice that the communication is similar to the communication with > Super-IO chips from ITE, but not the same. Specifically, the unlock key is > the same, but the lock key is different. This means that the code may unlock > other chips from ITE in a given system, but not lock them. Some of those chips > are ... let's call it less then perfect. They will act oddly on the bus if left > unlocked. Some of those chips will act oddly if an attempt is made to lock them > after unlocking them, and they have to remain unlocked to avoid corrupting > communication with other chips on the same bus. The impact on other chips > from the same vendor will have to be explored further. Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. Agreed that having this available generically is not a good idea. > >> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >> > > Why would that be the case ? > > Maybe I am missing something essential. If you insist to tie this driver to the > ITE5632 and not to the system, you will have to provide additional information. I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) > The chip does not even exist in public, so no one but you and ITE really knows > what its capabilities are. Is this is a chip which is used, or is going to be > used, in a variety of systems, possibly including systems from other vendors ? > Is the communication between main CPU and the chip tied to the chip and will/may > only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like > chip with fixed capabilities, or is it a programmed micro-controller ? > Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? > To a large degree all that is due to ITE and its customers not > providing information > about their chips to the public. Due to that lack of information, my > assumption was > that it is a programmed micro-controller. The code itself suggests, > through the > use of the term "EC" in the driver, that it is an embedded controller, > not a Suoer-IO > or other fixed-capability chip. If that is not the case, and if the > communication > with the chip is fixed and not programmable, you'll have to explain > that. Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. > > If it is an EC, the protocol is defined by its microcode, and the > driver needs > to be tied to the systems using that microcode. If it is a > fixed-capability chip, > the driver should not suggest that it communicates with an embedded > controller > but with a fixed-capability chip. > OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. Appreciate the patience as this is a learning experience for us for this kernel sub-tree. Mark
On 2/24/24 12:19, Mark Pearson wrote: > Thanks Guenter, > > On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: >> On 2/23/24 16:43, Mark Pearson wrote: >>> Thanks Guenter >>> >>> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>>> On 2/23/24 11:58, Mark Pearson wrote: >>>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>>> This modules is to allow for the new ITE 5632 EC chip >>>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>>> >>>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>>> >>>>>> V2 Fix stop to deactivate wdog on unload of module >>>>>> V2 Remove extra logging that is not needed >>>>>> V2 change udelays to usleep_range >>>>>> V2 Changed to now request region on start and release on stop instead >>>>>> of for every ping and read/write >>>>>> V3 add counter to while loops so it will not hang >>>>>> V3 rework code to use platform_device_register_simple >>>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>>> V3 change some extra logging to be debug only >>>>>> --- >>>> [ ... ] >>>>>> +config ITE5632_WDT >>>>>> + tristate "ITE 5632" >>>>>> + select WATCHDOG_CORE >>>>>> + help >>>>>> + If you say yes here you get support for the watchdog >>>>>> + functionality of the ITE 5632 eSIO chip. >>>>>> + >>>>>> + This driver can also be built as a module. If so, the module >>>>>> + will be called ite5632_wdt. >>>>>> + >>>> >>>> [ ... ] >>>> >>>>> >>>>> >>>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>>> >>>> >>>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>>> and the watchdog would work perfectly fine. >>>> >>>> This is a driver for the watchdog implemented in the embedded controller >>>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>>> used in that Lenovo system is completely irrelevant, even more so since >>>> this seems to be one of those undocumented ITE chips which officially >>>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>>> would be not only misleading but simply wrong. >>>> >>>> It seems that we can not agree on this. That means that, from my perspective, >>>> there is no real path to move forward. Wim will have to decide if and how >>>> to proceed. >>>> >>> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >>> >>> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >>> >> >> There would have to be additional changes. For example, the driver does not >> return errors if its wait loops time out, and it doesn't reserve the IO address >> range used by the chip. Tying the wait time to the number of wait loops >> and not to the elapsed time is also something that would need to be explained. >> > Ack - we can look at those. Thanks for the feedback. > >> Also, I notice that the communication is similar to the communication with >> Super-IO chips from ITE, but not the same. Specifically, the unlock key is >> the same, but the lock key is different. This means that the code may unlock >> other chips from ITE in a given system, but not lock them. Some of those chips >> are ... let's call it less then perfect. They will act oddly on the bus if left >> unlocked. Some of those chips will act oddly if an attempt is made to lock them >> after unlocking them, and they have to remain unlocked to avoid corrupting >> communication with other chips on the same bus. The impact on other chips >> from the same vendor will have to be explored further. > > Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. Yes. > Agreed that having this available generically is not a good idea. > >> >>> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >>> >> >> Why would that be the case ? >> >> Maybe I am missing something essential. If you insist to tie this driver to the >> ITE5632 and not to the system, you will have to provide additional information. > > I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) > >> The chip does not even exist in public, so no one but you and ITE really knows >> what its capabilities are. Is this is a chip which is used, or is going to be >> used, in a variety of systems, possibly including systems from other vendors ? >> Is the communication between main CPU and the chip tied to the chip and will/may >> only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like >> chip with fixed capabilities, or is it a programmed micro-controller ? >> > > Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? > Just try to find information about this chip anywhere. The only evidence that the chip even exists appears to be this submission. >> To a large degree all that is due to ITE and its customers not >> providing information >> about their chips to the public. Due to that lack of information, my >> assumption was >> that it is a programmed micro-controller. The code itself suggests, >> through the >> use of the term "EC" in the driver, that it is an embedded controller, >> not a Suoer-IO >> or other fixed-capability chip. If that is not the case, and if the >> communication >> with the chip is fixed and not programmable, you'll have to explain >> that. > > Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. > I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. I can't say that I am surprised. It is quite common for chips from ITE. Most of them seem to be custom builds made for specific customers/boards, with little if any information available. People providing tools for Windows can often sign NDAs with board vendors to get the information they need to implement support in those tools. Unfortunately that isn't an option for Linux kernel maintainers. > The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. > >> >> If it is an EC, the protocol is defined by its microcode, and the >> driver needs >> to be tied to the systems using that microcode. If it is a >> fixed-capability chip, >> the driver should not suggest that it communicates with an embedded >> controller >> but with a fixed-capability chip. >> > > OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. > > Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. > Appreciate the patience as this is a learning experience for us for this kernel sub-tree. > And I still have no idea if this an EC or not ;-). My best guess would be that it is an NDS32 based micro-controller, related to IT5671. Of course, the next question would be if this chip has additional functionality, such as hardware monitoring. I guess I'll see that when I get a patch introducing its hwmon driver. Guenter
Thanks! On Sun, Feb 25, 2024, at 1:43 AM, Guenter Roeck wrote: > On 2/24/24 12:19, Mark Pearson wrote: >> Thanks Guenter, >> >> On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: >>> On 2/23/24 16:43, Mark Pearson wrote: >>>> Thanks Guenter >>>> >>>> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>>>> On 2/23/24 11:58, Mark Pearson wrote: >>>>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>>>> This modules is to allow for the new ITE 5632 EC chip >>>>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>>>> >>>>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>>>> >>>>>>> V2 Fix stop to deactivate wdog on unload of module >>>>>>> V2 Remove extra logging that is not needed >>>>>>> V2 change udelays to usleep_range >>>>>>> V2 Changed to now request region on start and release on stop instead >>>>>>> of for every ping and read/write >>>>>>> V3 add counter to while loops so it will not hang >>>>>>> V3 rework code to use platform_device_register_simple >>>>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>>>> V3 change some extra logging to be debug only >>>>>>> --- >>>>> [ ... ] >>>>>>> +config ITE5632_WDT >>>>>>> + tristate "ITE 5632" >>>>>>> + select WATCHDOG_CORE >>>>>>> + help >>>>>>> + If you say yes here you get support for the watchdog >>>>>>> + functionality of the ITE 5632 eSIO chip. >>>>>>> + >>>>>>> + This driver can also be built as a module. If so, the module >>>>>>> + will be called ite5632_wdt. >>>>>>> + >>>>> >>>>> [ ... ] >>>>> >>>>>> >>>>>> >>>>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>>>> >>>>> >>>>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>>>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>>>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>>>> and the watchdog would work perfectly fine. >>>>> >>>>> This is a driver for the watchdog implemented in the embedded controller >>>>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>>>> used in that Lenovo system is completely irrelevant, even more so since >>>>> this seems to be one of those undocumented ITE chips which officially >>>>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>>>> would be not only misleading but simply wrong. >>>>> >>>>> It seems that we can not agree on this. That means that, from my perspective, >>>>> there is no real path to move forward. Wim will have to decide if and how >>>>> to proceed. >>>>> >>>> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >>>> >>>> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >>>> >>> >>> There would have to be additional changes. For example, the driver does not >>> return errors if its wait loops time out, and it doesn't reserve the IO address >>> range used by the chip. Tying the wait time to the number of wait loops >>> and not to the elapsed time is also something that would need to be explained. >>> >> Ack - we can look at those. Thanks for the feedback. >> >>> Also, I notice that the communication is similar to the communication with >>> Super-IO chips from ITE, but not the same. Specifically, the unlock key is >>> the same, but the lock key is different. This means that the code may unlock >>> other chips from ITE in a given system, but not lock them. Some of those chips >>> are ... let's call it less then perfect. They will act oddly on the bus if left >>> unlocked. Some of those chips will act oddly if an attempt is made to lock them >>> after unlocking them, and they have to remain unlocked to avoid corrupting >>> communication with other chips on the same bus. The impact on other chips >>> from the same vendor will have to be explored further. >> >> Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. > > Yes. > >> Agreed that having this available generically is not a good idea. >> >>> >>>> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >>>> >>> >>> Why would that be the case ? >>> >>> Maybe I am missing something essential. If you insist to tie this driver to the >>> ITE5632 and not to the system, you will have to provide additional information. >> >> I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) >> >>> The chip does not even exist in public, so no one but you and ITE really knows >>> what its capabilities are. Is this is a chip which is used, or is going to be >>> used, in a variety of systems, possibly including systems from other vendors ? >>> Is the communication between main CPU and the chip tied to the chip and will/may >>> only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like >>> chip with fixed capabilities, or is it a programmed micro-controller ? >>> >> >> Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? >> > > Just try to find information about this chip anywhere. The only > evidence that the > chip even exists appears to be this submission. > >>> To a large degree all that is due to ITE and its customers not >>> providing information >>> about their chips to the public. Due to that lack of information, my >>> assumption was >>> that it is a programmed micro-controller. The code itself suggests, >>> through the >>> use of the term "EC" in the driver, that it is an embedded controller, >>> not a Suoer-IO >>> or other fixed-capability chip. If that is not the case, and if the >>> communication >>> with the chip is fixed and not programmable, you'll have to explain >>> that. >> >> Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. >> I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. > > I can't say that I am surprised. It is quite common for chips from ITE. > Most of them seem to be custom builds made for specific customers/boards, > with little if any information available. People providing tools for Windows > can often sign NDAs with board vendors to get the information they need to > implement support in those tools. Unfortunately that isn't an option for > Linux kernel maintainers. > >> The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. >> >>> >>> If it is an EC, the protocol is defined by its microcode, and the >>> driver needs >>> to be tied to the systems using that microcode. If it is a >>> fixed-capability chip, >>> the driver should not suggest that it communicates with an embedded >>> controller >>> but with a fixed-capability chip. >>> >> >> OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. >> >> Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. >> Appreciate the patience as this is a learning experience for us for this kernel sub-tree. >> > And I still have no idea if this an EC or not ;-). My best guess would > be that it is an NDS32 based micro-controller, related to IT5671. > > Of course, the next question would be if this chip has additional > functionality, such as hardware monitoring. I guess I'll see that > when I get a patch introducing its hwmon driver. > We believe it is only providing watchdog functionality, but we're double checking with the HW team to be sure. Afraid I don't have the details on what it is based on to be able to answer that. Mark
Hi Guenter, On Mon, Feb 26, 2024, at 11:23 AM, Mark Pearson wrote: > Thanks! > > On Sun, Feb 25, 2024, at 1:43 AM, Guenter Roeck wrote: >> On 2/24/24 12:19, Mark Pearson wrote: >>> Thanks Guenter, >>> >>> On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: >>>> On 2/23/24 16:43, Mark Pearson wrote: >>>>> Thanks Guenter >>>>> >>>>> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>>>>> On 2/23/24 11:58, Mark Pearson wrote: >>>>>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>>>>> This modules is to allow for the new ITE 5632 EC chip >>>>>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>>>>> >>>>>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>>>>> >>>>>>>> V2 Fix stop to deactivate wdog on unload of module >>>>>>>> V2 Remove extra logging that is not needed >>>>>>>> V2 change udelays to usleep_range >>>>>>>> V2 Changed to now request region on start and release on stop instead >>>>>>>> of for every ping and read/write >>>>>>>> V3 add counter to while loops so it will not hang >>>>>>>> V3 rework code to use platform_device_register_simple >>>>>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>>>>> V3 change some extra logging to be debug only >>>>>>>> --- >>>>>> [ ... ] >>>>>>>> +config ITE5632_WDT >>>>>>>> + tristate "ITE 5632" >>>>>>>> + select WATCHDOG_CORE >>>>>>>> + help >>>>>>>> + If you say yes here you get support for the watchdog >>>>>>>> + functionality of the ITE 5632 eSIO chip. >>>>>>>> + >>>>>>>> + This driver can also be built as a module. If so, the module >>>>>>>> + will be called ite5632_wdt. >>>>>>>> + >>>>>> >>>>>> [ ... ] >>>>>> >>>>>>> >>>>>>> >>>>>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>>>>> >>>>>> >>>>>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>>>>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>>>>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>>>>> and the watchdog would work perfectly fine. >>>>>> >>>>>> This is a driver for the watchdog implemented in the embedded controller >>>>>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>>>>> used in that Lenovo system is completely irrelevant, even more so since >>>>>> this seems to be one of those undocumented ITE chips which officially >>>>>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>>>>> would be not only misleading but simply wrong. >>>>>> >>>>>> It seems that we can not agree on this. That means that, from my perspective, >>>>>> there is no real path to move forward. Wim will have to decide if and how >>>>>> to proceed. >>>>>> >>>>> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >>>>> >>>>> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >>>>> >>>> >>>> There would have to be additional changes. For example, the driver does not >>>> return errors if its wait loops time out, and it doesn't reserve the IO address >>>> range used by the chip. Tying the wait time to the number of wait loops >>>> and not to the elapsed time is also something that would need to be explained. >>>> >>> Ack - we can look at those. Thanks for the feedback. >>> >>>> Also, I notice that the communication is similar to the communication with >>>> Super-IO chips from ITE, but not the same. Specifically, the unlock key is >>>> the same, but the lock key is different. This means that the code may unlock >>>> other chips from ITE in a given system, but not lock them. Some of those chips >>>> are ... let's call it less then perfect. They will act oddly on the bus if left >>>> unlocked. Some of those chips will act oddly if an attempt is made to lock them >>>> after unlocking them, and they have to remain unlocked to avoid corrupting >>>> communication with other chips on the same bus. The impact on other chips >>>> from the same vendor will have to be explored further. >>> >>> Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. >> >> Yes. >> >>> Agreed that having this available generically is not a good idea. >>> >>>> >>>>> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >>>>> >>>> >>>> Why would that be the case ? >>>> >>>> Maybe I am missing something essential. If you insist to tie this driver to the >>>> ITE5632 and not to the system, you will have to provide additional information. >>> >>> I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) >>> >>>> The chip does not even exist in public, so no one but you and ITE really knows >>>> what its capabilities are. Is this is a chip which is used, or is going to be >>>> used, in a variety of systems, possibly including systems from other vendors ? >>>> Is the communication between main CPU and the chip tied to the chip and will/may >>>> only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like >>>> chip with fixed capabilities, or is it a programmed micro-controller ? >>>> >>> >>> Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? >>> >> >> Just try to find information about this chip anywhere. The only >> evidence that the >> chip even exists appears to be this submission. >> >>>> To a large degree all that is due to ITE and its customers not >>>> providing information >>>> about their chips to the public. Due to that lack of information, my >>>> assumption was >>>> that it is a programmed micro-controller. The code itself suggests, >>>> through the >>>> use of the term "EC" in the driver, that it is an embedded controller, >>>> not a Suoer-IO >>>> or other fixed-capability chip. If that is not the case, and if the >>>> communication >>>> with the chip is fixed and not programmable, you'll have to explain >>>> that. >>> >>> Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. >>> I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. >> >> I can't say that I am surprised. It is quite common for chips from ITE. >> Most of them seem to be custom builds made for specific customers/boards, >> with little if any information available. People providing tools for Windows >> can often sign NDAs with board vendors to get the information they need to >> implement support in those tools. Unfortunately that isn't an option for >> Linux kernel maintainers. >> >>> The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. >>> >>>> >>>> If it is an EC, the protocol is defined by its microcode, and the >>>> driver needs >>>> to be tied to the systems using that microcode. If it is a >>>> fixed-capability chip, >>>> the driver should not suggest that it communicates with an embedded >>>> controller >>>> but with a fixed-capability chip. >>>> >>> >>> OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. >>> >>> Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. >>> Appreciate the patience as this is a learning experience for us for this kernel sub-tree. >>> >> And I still have no idea if this an EC or not ;-). My best guess would >> be that it is an NDS32 based micro-controller, related to IT5671. >> >> Of course, the next question would be if this chip has additional >> functionality, such as hardware monitoring. I guess I'll see that >> when I get a patch introducing its hwmon driver. >> > We believe it is only providing watchdog functionality, but we're > double checking with the HW team to be sure. > > Afraid I don't have the details on what it is based on to be able to > answer that. > I got some answers - and I was wrong. This device is capable of more than watchdog functionality. On this platform it does provide some temperature sensors (it could do fan control but the device is fanless so that's moot). My understanding is this means the right way forward is to create a MFD driver. I played with this a bit, and think I understand what is involved - but wanted to check if there were any recommendations on the following plan: - Create a lenovo-think-mfd driver. We'd use this to probe the system (DMI) and then match it up with our platforms and use appropriate mfd_cells. - Initially we'd target the device on the SE10. We also have the watchdog driver for the SE30 (NCT6692D device) that I think may be a good candidate too. - Create a new lenovo-se10-wdt watchdog driver, that would be linked to the MFD driver. - (Once confirmed) do the same for the lenovo-se30-wdt driver. - I'm going to look at the temp sensors for the SE10, but don't plan on having that in the initial patchset. It's something we'd add at a later date. If that's all logical - are there any preferences as to how these come in as commits? I'm guessing one for the mfd driver, one for the SE10 watchdog, one for the SE30 watchdog? Documentation would need to be updated as well. Anything else that would be important? Would appreciate if you can let me know if I'm missing anything or if I'm heading in the wrong direction. Thanks Mark
On 2/29/24 08:40, Mark Pearson wrote: > Hi Guenter, > > On Mon, Feb 26, 2024, at 11:23 AM, Mark Pearson wrote: >> Thanks! >> >> On Sun, Feb 25, 2024, at 1:43 AM, Guenter Roeck wrote: >>> On 2/24/24 12:19, Mark Pearson wrote: >>>> Thanks Guenter, >>>> >>>> On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: >>>>> On 2/23/24 16:43, Mark Pearson wrote: >>>>>> Thanks Guenter >>>>>> >>>>>> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>>>>>> On 2/23/24 11:58, Mark Pearson wrote: >>>>>>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>>>>>> This modules is to allow for the new ITE 5632 EC chip >>>>>>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>>>>>> >>>>>>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>>>>>> >>>>>>>>> V2 Fix stop to deactivate wdog on unload of module >>>>>>>>> V2 Remove extra logging that is not needed >>>>>>>>> V2 change udelays to usleep_range >>>>>>>>> V2 Changed to now request region on start and release on stop instead >>>>>>>>> of for every ping and read/write >>>>>>>>> V3 add counter to while loops so it will not hang >>>>>>>>> V3 rework code to use platform_device_register_simple >>>>>>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>>>>>> V3 change some extra logging to be debug only >>>>>>>>> --- >>>>>>> [ ... ] >>>>>>>>> +config ITE5632_WDT >>>>>>>>> + tristate "ITE 5632" >>>>>>>>> + select WATCHDOG_CORE >>>>>>>>> + help >>>>>>>>> + If you say yes here you get support for the watchdog >>>>>>>>> + functionality of the ITE 5632 eSIO chip. >>>>>>>>> + >>>>>>>>> + This driver can also be built as a module. If so, the module >>>>>>>>> + will be called ite5632_wdt. >>>>>>>>> + >>>>>>> >>>>>>> [ ... ] >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>>>>>> >>>>>>> >>>>>>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>>>>>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>>>>>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>>>>>> and the watchdog would work perfectly fine. >>>>>>> >>>>>>> This is a driver for the watchdog implemented in the embedded controller >>>>>>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>>>>>> used in that Lenovo system is completely irrelevant, even more so since >>>>>>> this seems to be one of those undocumented ITE chips which officially >>>>>>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>>>>>> would be not only misleading but simply wrong. >>>>>>> >>>>>>> It seems that we can not agree on this. That means that, from my perspective, >>>>>>> there is no real path to move forward. Wim will have to decide if and how >>>>>>> to proceed. >>>>>>> >>>>>> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >>>>>> >>>>>> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >>>>>> >>>>> >>>>> There would have to be additional changes. For example, the driver does not >>>>> return errors if its wait loops time out, and it doesn't reserve the IO address >>>>> range used by the chip. Tying the wait time to the number of wait loops >>>>> and not to the elapsed time is also something that would need to be explained. >>>>> >>>> Ack - we can look at those. Thanks for the feedback. >>>> >>>>> Also, I notice that the communication is similar to the communication with >>>>> Super-IO chips from ITE, but not the same. Specifically, the unlock key is >>>>> the same, but the lock key is different. This means that the code may unlock >>>>> other chips from ITE in a given system, but not lock them. Some of those chips >>>>> are ... let's call it less then perfect. They will act oddly on the bus if left >>>>> unlocked. Some of those chips will act oddly if an attempt is made to lock them >>>>> after unlocking them, and they have to remain unlocked to avoid corrupting >>>>> communication with other chips on the same bus. The impact on other chips >>>>> from the same vendor will have to be explored further. >>>> >>>> Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. >>> >>> Yes. >>> >>>> Agreed that having this available generically is not a good idea. >>>> >>>>> >>>>>> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >>>>>> >>>>> >>>>> Why would that be the case ? >>>>> >>>>> Maybe I am missing something essential. If you insist to tie this driver to the >>>>> ITE5632 and not to the system, you will have to provide additional information. >>>> >>>> I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) >>>> >>>>> The chip does not even exist in public, so no one but you and ITE really knows >>>>> what its capabilities are. Is this is a chip which is used, or is going to be >>>>> used, in a variety of systems, possibly including systems from other vendors ? >>>>> Is the communication between main CPU and the chip tied to the chip and will/may >>>>> only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like >>>>> chip with fixed capabilities, or is it a programmed micro-controller ? >>>>> >>>> >>>> Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? >>>> >>> >>> Just try to find information about this chip anywhere. The only >>> evidence that the >>> chip even exists appears to be this submission. >>> >>>>> To a large degree all that is due to ITE and its customers not >>>>> providing information >>>>> about their chips to the public. Due to that lack of information, my >>>>> assumption was >>>>> that it is a programmed micro-controller. The code itself suggests, >>>>> through the >>>>> use of the term "EC" in the driver, that it is an embedded controller, >>>>> not a Suoer-IO >>>>> or other fixed-capability chip. If that is not the case, and if the >>>>> communication >>>>> with the chip is fixed and not programmable, you'll have to explain >>>>> that. >>>> >>>> Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. >>>> I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. >>> >>> I can't say that I am surprised. It is quite common for chips from ITE. >>> Most of them seem to be custom builds made for specific customers/boards, >>> with little if any information available. People providing tools for Windows >>> can often sign NDAs with board vendors to get the information they need to >>> implement support in those tools. Unfortunately that isn't an option for >>> Linux kernel maintainers. >>> >>>> The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. >>>> >>>>> >>>>> If it is an EC, the protocol is defined by its microcode, and the >>>>> driver needs >>>>> to be tied to the systems using that microcode. If it is a >>>>> fixed-capability chip, >>>>> the driver should not suggest that it communicates with an embedded >>>>> controller >>>>> but with a fixed-capability chip. >>>>> >>>> >>>> OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. >>>> >>>> Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. >>>> Appreciate the patience as this is a learning experience for us for this kernel sub-tree. >>>> >>> And I still have no idea if this an EC or not ;-). My best guess would >>> be that it is an NDS32 based micro-controller, related to IT5671. >>> >>> Of course, the next question would be if this chip has additional >>> functionality, such as hardware monitoring. I guess I'll see that >>> when I get a patch introducing its hwmon driver. >>> >> We believe it is only providing watchdog functionality, but we're >> double checking with the HW team to be sure. >> >> Afraid I don't have the details on what it is based on to be able to >> answer that. >> > > I got some answers - and I was wrong. This device is capable of more than watchdog functionality. On this platform it does provide some temperature sensors (it could do fan control but the device is fanless so that's moot). > > My understanding is this means the right way forward is to create a MFD driver. I played with this a bit, and think I understand what is involved - but wanted to check if there were any recommendations on the following plan: > > - Create a lenovo-think-mfd driver. We'd use this to probe the system (DMI) and then match it up with our platforms and use appropriate mfd_cells. > - Initially we'd target the device on the SE10. We also have the watchdog driver for the SE30 (NCT6692D device) that I think may be a good candidate too. > - Create a new lenovo-se10-wdt watchdog driver, that would be linked to the MFD driver. > - (Once confirmed) do the same for the lenovo-se30-wdt driver. > - I'm going to look at the temp sensors for the SE10, but don't plan on having that in the initial patchset. It's something we'd add at a later date. > > If that's all logical - are there any preferences as to how these come in as commits? > I'm guessing one for the mfd driver, one for the SE10 watchdog, one for the SE30 watchdog? > Documentation would need to be updated as well. > Anything else that would be important? > > Would appreciate if you can let me know if I'm missing anything or if I'm heading in the wrong direction. > This summarizes pretty much what I dislike about those undocumented chips. Is it necessary to treat this differently than, say, drivers/hwmon/it87.c and drivers/watchdog/it87_wdt.c ? Those work together nicely because most of the address space is separate; access through Super-IO registers is limited enough that it can be shared by using request_muxed_region() in both drivers. I'll have to look deeper into NCT6692D (and NCT6686, for that matter), to see if those require mfd drivers. I'll also need to get the datasheets for those chips and confirm that they really need different watchdog drivers to start with. Guenter
Hi Guenter On Thu, Feb 29, 2024, at 12:25 PM, Guenter Roeck wrote: > On 2/29/24 08:40, Mark Pearson wrote: >> Hi Guenter, >> >> On Mon, Feb 26, 2024, at 11:23 AM, Mark Pearson wrote: >>> Thanks! >>> >>> On Sun, Feb 25, 2024, at 1:43 AM, Guenter Roeck wrote: >>>> On 2/24/24 12:19, Mark Pearson wrote: >>>>> Thanks Guenter, >>>>> >>>>> On Sat, Feb 24, 2024, at 10:49 AM, Guenter Roeck wrote: >>>>>> On 2/23/24 16:43, Mark Pearson wrote: >>>>>>> Thanks Guenter >>>>>>> >>>>>>> On Fri, Feb 23, 2024, at 3:21 PM, Guenter Roeck wrote: >>>>>>>> On 2/23/24 11:58, Mark Pearson wrote: >>>>>>>>> On Fri, Jul 21, 2023, at 8:29 AM, David Ober wrote: >>>>>>>>>> This modules is to allow for the new ITE 5632 EC chip >>>>>>>>>> to support the watchdog for initial use in the Lenovo SE10 >>>>>>>>>> >>>>>>>>>> Signed-off-by: David Ober <dober6023@gmail.com> >>>>>>>>>> >>>>>>>>>> V2 Fix stop to deactivate wdog on unload of module >>>>>>>>>> V2 Remove extra logging that is not needed >>>>>>>>>> V2 change udelays to usleep_range >>>>>>>>>> V2 Changed to now request region on start and release on stop instead >>>>>>>>>> of for every ping and read/write >>>>>>>>>> V3 add counter to while loops so it will not hang >>>>>>>>>> V3 rework code to use platform_device_register_simple >>>>>>>>>> V3 rework getting the Chip ID to remove duplicate code and close IO >>>>>>>>>> V3 change some extra logging to be debug only >>>>>>>>>> --- >>>>>>>> [ ... ] >>>>>>>>>> +config ITE5632_WDT >>>>>>>>>> + tristate "ITE 5632" >>>>>>>>>> + select WATCHDOG_CORE >>>>>>>>>> + help >>>>>>>>>> + If you say yes here you get support for the watchdog >>>>>>>>>> + functionality of the ITE 5632 eSIO chip. >>>>>>>>>> + >>>>>>>>>> + This driver can also be built as a module. If so, the module >>>>>>>>>> + will be called ite5632_wdt. >>>>>>>>>> + >>>>>>>> >>>>>>>> [ ... ] >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please let us know if there is anything else needed to get this accepted. Happy to address any feedback. >>>>>>>>> >>>>>>>> >>>>>>>> I am sure I commented on this before. The fact that the Lenovo SE10 uses an >>>>>>>> ITE 5632 controller is completely irrelevant. Lenovo could decide tomorrow to >>>>>>>> replace the ITE chip with a Nuvoton chip, use the same API to talk with it, >>>>>>>> and the watchdog would work perfectly fine. >>>>>>>> >>>>>>>> This is a driver for the watchdog implemented in the embedded controller >>>>>>>> on Lenovo SE10. It is not a watchdog driver for ITE5632. Again, the EC chip >>>>>>>> used in that Lenovo system is completely irrelevant, even more so since >>>>>>>> this seems to be one of those undocumented ITE chips which officially >>>>>>>> don't even exist. Claiming that this would be a watchdog driver for ITE5632 >>>>>>>> would be not only misleading but simply wrong. >>>>>>>> >>>>>>>> It seems that we can not agree on this. That means that, from my perspective, >>>>>>>> there is no real path to move forward. Wim will have to decide if and how >>>>>>>> to proceed. >>>>>>>> >>>>>>> My apologies - I hadn't realised that was the issue (my fault for missing it). Appreciate the clarification. >>>>>>> >>>>>>> Is this as simple as renaming this driver as (for example) a lenovo_se_wdt device, and adding in the appropriate checking during the init that it is only used on Lenovo SE10 platforms? >>>>>>> >>>>>> >>>>>> There would have to be additional changes. For example, the driver does not >>>>>> return errors if its wait loops time out, and it doesn't reserve the IO address >>>>>> range used by the chip. Tying the wait time to the number of wait loops >>>>>> and not to the elapsed time is also something that would need to be explained. >>>>>> >>>>> Ack - we can look at those. Thanks for the feedback. >>>>> >>>>>> Also, I notice that the communication is similar to the communication with >>>>>> Super-IO chips from ITE, but not the same. Specifically, the unlock key is >>>>>> the same, but the lock key is different. This means that the code may unlock >>>>>> other chips from ITE in a given system, but not lock them. Some of those chips >>>>>> are ... let's call it less then perfect. They will act oddly on the bus if left >>>>>> unlocked. Some of those chips will act oddly if an attempt is made to lock them >>>>>> after unlocking them, and they have to remain unlocked to avoid corrupting >>>>>> communication with other chips on the same bus. The impact on other chips >>>>>> from the same vendor will have to be explored further. >>>>> >>>>> Afraid I'm still missing something here. If we make it so this driver is only used on the SE10 platform, then does that remove the concern? At that point it's specific to that HW platform and no HW changes are planned. >>>> >>>> Yes. >>>> >>>>> Agreed that having this available generically is not a good idea. >>>>> >>>>>> >>>>>>> I don't understand the concern if a different chip was used - wouldn't that need a different driver at that point? >>>>>>> >>>>>> >>>>>> Why would that be the case ? >>>>>> >>>>>> Maybe I am missing something essential. If you insist to tie this driver to the >>>>>> ITE5632 and not to the system, you will have to provide additional information. >>>>> >>>>> I'm in agreement we should tie this to the platform - we'll make that change. No insistence implied :) >>>>> >>>>>> The chip does not even exist in public, so no one but you and ITE really knows >>>>>> what its capabilities are. Is this is a chip which is used, or is going to be >>>>>> used, in a variety of systems, possibly including systems from other vendors ? >>>>>> Is the communication between main CPU and the chip tied to the chip and will/may >>>>>> only be used with this chip or variants of it ? Is the ITE5632 a SuperIO-like >>>>>> chip with fixed capabilities, or is it a programmed micro-controller ? >>>>>> >>>>> >>>>> Afraid I don't understand the point about the chip not existing in public - do you just mean publicly available datasheets? At the risk of being repetitive, if this driver is locked to the Lenovo SE10 platform does that address the concerns? >>>>> >>>> >>>> Just try to find information about this chip anywhere. The only >>>> evidence that the >>>> chip even exists appears to be this submission. >>>> >>>>>> To a large degree all that is due to ITE and its customers not >>>>>> providing information >>>>>> about their chips to the public. Due to that lack of information, my >>>>>> assumption was >>>>>> that it is a programmed micro-controller. The code itself suggests, >>>>>> through the >>>>>> use of the term "EC" in the driver, that it is an embedded controller, >>>>>> not a Suoer-IO >>>>>> or other fixed-capability chip. If that is not the case, and if the >>>>>> communication >>>>>> with the chip is fixed and not programmable, you'll have to explain >>>>>> that. >>>>> >>>>> Yeah, ack to that - and in that's something we need to address going forward in contracts we set for platforms that will have Linux support. I can't change what has already been done I'm afraid. We do have access, under NDA, to more details - but we're also limited in what we can disclose. >>>>> I need to go look at the details for this again, with David, and see what we can do to address any questions; but there are going to be some limits I'm afraid and I'm hoping they aren't blockers. >>>> >>>> I can't say that I am surprised. It is quite common for chips from ITE. >>>> Most of them seem to be custom builds made for specific customers/boards, >>>> with little if any information available. People providing tools for Windows >>>> can often sign NDAs with board vendors to get the information they need to >>>> implement support in those tools. Unfortunately that isn't an option for >>>> Linux kernel maintainers. >>>> >>>>> The aim is to get a driver working for this platform in shape enough to get accepted upstream and be useful. >>>>> >>>>>> >>>>>> If it is an EC, the protocol is defined by its microcode, and the >>>>>> driver needs >>>>>> to be tied to the systems using that microcode. If it is a >>>>>> fixed-capability chip, >>>>>> the driver should not suggest that it communicates with an embedded >>>>>> controller >>>>>> but with a fixed-capability chip. >>>>>> >>>>> >>>>> OK - we may also have used some incorrect terminology inadvertently, so I don't want to jump to too many conclusions. Will look into this. >>>>> >>>>> Thanks for the detailed notes - we weren't sure what had been missing from the driver since the last submission so it's helpful to know where improvements are needed. >>>>> Appreciate the patience as this is a learning experience for us for this kernel sub-tree. >>>>> >>>> And I still have no idea if this an EC or not ;-). My best guess would >>>> be that it is an NDS32 based micro-controller, related to IT5671. >>>> >>>> Of course, the next question would be if this chip has additional >>>> functionality, such as hardware monitoring. I guess I'll see that >>>> when I get a patch introducing its hwmon driver. >>>> >>> We believe it is only providing watchdog functionality, but we're >>> double checking with the HW team to be sure. >>> >>> Afraid I don't have the details on what it is based on to be able to >>> answer that. >>> >> >> I got some answers - and I was wrong. This device is capable of more than watchdog functionality. On this platform it does provide some temperature sensors (it could do fan control but the device is fanless so that's moot). >> >> My understanding is this means the right way forward is to create a MFD driver. I played with this a bit, and think I understand what is involved - but wanted to check if there were any recommendations on the following plan: >> >> - Create a lenovo-think-mfd driver. We'd use this to probe the system (DMI) and then match it up with our platforms and use appropriate mfd_cells. >> - Initially we'd target the device on the SE10. We also have the watchdog driver for the SE30 (NCT6692D device) that I think may be a good candidate too. >> - Create a new lenovo-se10-wdt watchdog driver, that would be linked to the MFD driver. >> - (Once confirmed) do the same for the lenovo-se30-wdt driver. >> - I'm going to look at the temp sensors for the SE10, but don't plan on having that in the initial patchset. It's something we'd add at a later date. >> >> If that's all logical - are there any preferences as to how these come in as commits? >> I'm guessing one for the mfd driver, one for the SE10 watchdog, one for the SE30 watchdog? >> Documentation would need to be updated as well. >> Anything else that would be important? >> >> Would appreciate if you can let me know if I'm missing anything or if I'm heading in the wrong direction. >> > > This summarizes pretty much what I dislike about those undocumented chips. > > Is it necessary to treat this differently than, say, > drivers/hwmon/it87.c and drivers/watchdog/it87_wdt.c ? > Those work together nicely because most of the address space is > separate; access through Super-IO registers > is limited enough that it can be shared by using request_muxed_region() > in both drivers. > > I'll have to look deeper into NCT6692D (and NCT6686, for that matter), > to see if those require mfd drivers. > I'll also need to get the datasheets for those chips and confirm that > they really need different watchdog > drivers to start with. > Ack - I'll look at those and see. Quick look at the watchdog driver and it looks possible but I need to check the details more carefully. Afraid I can't share the datasheet as I don't have permission to release it. How much of a blocker is that for you? Mark
On 2/29/24 10:12, Mark Pearson wrote: [ ... ] >> Is it necessary to treat this differently than, say, >> drivers/hwmon/it87.c and drivers/watchdog/it87_wdt.c ? >> Those work together nicely because most of the address space is >> separate; access through Super-IO registers >> is limited enough that it can be shared by using request_muxed_region() >> in both drivers. >> >> I'll have to look deeper into NCT6692D (and NCT6686, for that matter), >> to see if those require mfd drivers. >> I'll also need to get the datasheets for those chips and confirm that >> they really need different watchdog >> drivers to start with. >> > Ack - I'll look at those and see. Quick look at the watchdog driver and it looks possible but I need to check the details more carefully. > Afraid I can't share the datasheet as I don't have permission to release it. How much of a blocker is that for you? > I do have the datasheet for the NCT6683 EC space. I'll need to check if it matches the code submitted for the NCT6686 watchdog. For NCT6692D, I asked Nuvoton if they can share the datasheet. Given that it is some kind of security controller chip, it may well be that Lenovo has an NDA with Nuvoton which prevents them from sharing the datasheet. We'll see. Undocumented ITE chips are simply not supportable. No matter what, someone will have to step up as maintainer for those chips. Guenter
On Thu, Feb 29, 2024, at 1:47 PM, Guenter Roeck wrote: > On 2/29/24 10:12, Mark Pearson wrote: > [ ... ] > >>> Is it necessary to treat this differently than, say, >>> drivers/hwmon/it87.c and drivers/watchdog/it87_wdt.c ? >>> Those work together nicely because most of the address space is >>> separate; access through Super-IO registers >>> is limited enough that it can be shared by using request_muxed_region() >>> in both drivers. >>> >>> I'll have to look deeper into NCT6692D (and NCT6686, for that matter), >>> to see if those require mfd drivers. >>> I'll also need to get the datasheets for those chips and confirm that >>> they really need different watchdog >>> drivers to start with. >>> >> Ack - I'll look at those and see. Quick look at the watchdog driver and it looks possible but I need to check the details more carefully. >> Afraid I can't share the datasheet as I don't have permission to release it. How much of a blocker is that for you? >> > > I do have the datasheet for the NCT6683 EC space. I'll need to check if > it matches the code submitted for the NCT6686 watchdog. > > For NCT6692D, I asked Nuvoton if they can share the datasheet. > Given that it is some kind of security controller chip, it may well be > that Lenovo has an NDA with Nuvoton which prevents them from sharing > the datasheet. We'll see. > > Undocumented ITE chips are simply not supportable. No matter what, someone > will have to step up as maintainer for those chips. > Ack, but given the ITE chip is for our platform, are we as the submitter not on the hook for maintaining it - especially if we're making so it's only usable on the Lenovo platform? I'd expect myself or David to need to respond to any issues. Looking at the it87 driver - it looks like the main thing is the request/release of the region when doing a superio_enter/exit, which we are missing and would be needed. Can definitely do that in our version, instead of the MFD, if that is preferred. I haven't gone and looked back at the NCT devices again. Need to do that. Thanks Mark
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index ee97d89dfc11..861cc0eff468 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -264,6 +264,16 @@ config MENZ069_WATCHDOG This driver can also be built as a module. If so the module will be called menz069_wdt. +config ITE5632_WDT + tristate "ITE 5632" + select WATCHDOG_CORE + help + If you say yes here you get support for the watchdog + functionality of the ITE 5632 eSIO chip. + + This driver can also be built as a module. If so, the module + will be called ite5632_wdt. + config WDAT_WDT tristate "ACPI Watchdog Action Table (WDAT)" depends on ACPI diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 3633f5b98236..32c8340f3175 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -119,6 +119,7 @@ obj-$(CONFIG_WAFER_WDT) += wafer5823wdt.o obj-$(CONFIG_I6300ESB_WDT) += i6300esb.o obj-$(CONFIG_IE6XX_WDT) += ie6xx_wdt.o obj-$(CONFIG_ITCO_WDT) += iTCO_wdt.o +obj-$(CONFIG_ITE5632_WDT) += ite5632_wdt.o ifeq ($(CONFIG_ITCO_VENDOR_SUPPORT),y) obj-$(CONFIG_ITCO_WDT) += iTCO_vendor_support.o endif diff --git a/drivers/watchdog/ite5632_wdt.c b/drivers/watchdog/ite5632_wdt.c new file mode 100644 index 000000000000..efa0881eef4a --- /dev/null +++ b/drivers/watchdog/ite5632_wdt.c @@ -0,0 +1,278 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Customized ITE5632 WDT driver for Lenovo SE10. + * + */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include <linux/delay.h> +#include <linux/init.h> +#include <linux/io.h> +#include <linux/ioport.h> +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/platform_device.h> +#include <linux/string.h> +#include <linux/types.h> +#include <linux/watchdog.h> + +#define ITE5632_SIO_UNLOCK_KEY 0x87 +#define ITE5632_SIO_LOCK_KEY 0xAA + +#define EC_STATUS_port 0x6C +#define EC_CMD_port 0x6C +#define EC_DATA_port 0x68 +#define EC_OBF 0x01 +#define EC_IBF 0x02 +#define CFG_LDN 0x07 +#define CFG_BRAM_LDN 0x10 /* for BRAM Base */ +#define CFG_PORT 0x2E + +#define CUS_WDT_SWI 0x1A +#define CUS_WDT_CFG 0x1B +#define CUS_WDT_FEED 0xB0 +#define CUS_WDT_CNT 0xB1 + +#define DRVNAME "ite5632" + +/*The timeout range is 1-255 seconds*/ +#define MIN_TIMEOUT 1 +#define MAX_TIMEOUT 255 +#define MAX_WAIT 10 + +#define WATCHDOG_TIMEOUT 60 /* 60 sec default timeout */ +static unsigned short bram_base; + +static int timeout; /* in seconds */ +module_param(timeout, int, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in seconds. 1 <= timeout <= 255, default=" + __MODULE_STRING(WATCHDOG_TIMEOUT) "."); + +static bool nowayout = WATCHDOG_NOWAYOUT; +module_param(nowayout, bool, 0); +MODULE_PARM_DESC(nowayout, + "Watchdog cannot be stopped once started (default=" + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")"); + +/* the watchdog platform device */ +static struct platform_device *ite5632wdt_platform_device; + +/* Kernel methods. */ +static void set_bram(unsigned char offset, unsigned char val) +{ + outb(offset, bram_base); + outb(val, bram_base + 1); +} + +/* wait EC output buffer full */ +static void wait_EC_OBF(void) +{ + int loop = 0; + + while (1) { + if (inb(EC_STATUS_port) & EC_OBF || loop > MAX_WAIT) + break; + loop++; + usleep_range(10, 125); + } +} + +/* wait EC input buffer empty */ +static void wait_EC_IBE(void) +{ + int loop = 0; + + while (1) { + if (!(inb(EC_STATUS_port) & EC_IBF) || loop > MAX_WAIT) + break; + loop++; + usleep_range(10, 125); + } +} + +static void send_EC_cmd(unsigned char eccmd) +{ + wait_EC_IBE(); + outb(eccmd, EC_CMD_port); + wait_EC_IBE(); +} + +static unsigned char Read_EC_data(void) +{ + wait_EC_OBF(); + return inb(EC_DATA_port); +} + +static void LPC_Write_Byte(unsigned char index, unsigned char data) +{ + outb(index, CFG_PORT); + outb(data, CFG_PORT + 1); +} + +static unsigned char LPC_Read_Byte(unsigned char index) +{ + outb(index, CFG_PORT); + return inb(CFG_PORT + 1); +} + +static int GetChipID(void) +{ + unsigned char MSB, LSB; + unsigned char cmd = 0x55; + + outb(ITE5632_SIO_UNLOCK_KEY, CFG_PORT); + outb(0x01, CFG_PORT); + outb(0x55, CFG_PORT); + outb(cmd, CFG_PORT); + MSB = LPC_Read_Byte(0x20); + LSB = LPC_Read_Byte(0x21); + outb(ITE5632_SIO_LOCK_KEY, CFG_PORT); + return (MSB * 256 + LSB); +} + +static int wdt_start(struct watchdog_device *wdog) +{ + set_bram(CUS_WDT_SWI, 0x80); + return 0; +} + +static int wdt_set_timeout(struct watchdog_device *wdog, unsigned int timeout) +{ + wdog->timeout = timeout; + set_bram(CUS_WDT_CFG, wdog->timeout); + return 0; +} + +static int wdt_stop(struct watchdog_device *wdog) +{ + set_bram(CUS_WDT_SWI, 0); + return 0; +} + +static unsigned int wdt_get_time(struct watchdog_device *wdog) +{ + unsigned int timeleft; + + send_EC_cmd(CUS_WDT_CNT); + + timeleft = Read_EC_data(); + return timeleft; +} + +static int wdt_ping(struct watchdog_device *wdog) +{ + send_EC_cmd(CUS_WDT_FEED); + return 0; +} + +/* Kernel Interfaces */ +static const struct watchdog_info wdt_info = { + .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE, + .identity = "5632 Watchdog", +}; + +static const struct watchdog_ops wdt_ops = { + .owner = THIS_MODULE, + .start = wdt_start, + .stop = wdt_stop, + .ping = wdt_ping, + .set_timeout = wdt_set_timeout, + .get_timeleft = wdt_get_time, +}; + +static int ite5632_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct watchdog_device *wdt; + int ret; + + dev_dbg(&pdev->dev, "Probe ITE5632 called\n"); + + wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL); + if (!wdt) { + release_region(EC_DATA_port, 5); + return -ENOMEM; + } + + wdt->info = &wdt_info, + wdt->ops = &wdt_ops, + wdt->timeout = WATCHDOG_TIMEOUT; /* Set default timeout */ + wdt->min_timeout = MIN_TIMEOUT; + wdt->max_timeout = MAX_TIMEOUT; + wdt->parent = &pdev->dev; + + watchdog_init_timeout(wdt, timeout, &pdev->dev); + watchdog_set_nowayout(wdt, nowayout); + watchdog_stop_on_reboot(wdt); + watchdog_stop_on_unregister(wdt); + + ret = devm_watchdog_register_device(dev, wdt); + + dev_dbg(&pdev->dev, "initialized. timeout=%d sec (nowayout=%d)\n", + wdt->timeout, nowayout); + + return ret; +} + +static struct platform_driver ite5632_driver = { + .driver = { + .name = DRVNAME, + }, + .probe = ite5632_probe, +}; + +static int __init wdt_init(void) +{ + int err; + int chip; + + if (!request_region(EC_DATA_port, 5, "EC")) { + pr_err(":request fail\n"); + return -EIO; + } + chip = GetChipID(); + + if (chip != 0x5632) { + release_region(EC_DATA_port, 5); + return -ENODEV; + } + pr_info("Found ITE ChipID = %4X\n", chip); + + LPC_Write_Byte(CFG_LDN, CFG_BRAM_LDN); + bram_base = (LPC_Read_Byte(0x60) << 8) | LPC_Read_Byte(0x61); + + ite5632wdt_platform_device = platform_device_register_simple(DRVNAME, + -1, NULL, 0); + if (IS_ERR(ite5632wdt_platform_device)) { + release_region(EC_DATA_port, 5); + return PTR_ERR(ite5632wdt_platform_device); + } + + err = platform_driver_probe(&ite5632_driver, ite5632_probe); + if (err) + goto unreg_platform_device; + + return 0; + +unreg_platform_device: + platform_device_unregister(ite5632wdt_platform_device); + release_region(EC_DATA_port, 5); + return err; +} + +static void __exit wdt_exit(void) +{ + platform_device_unregister(ite5632wdt_platform_device); + platform_driver_unregister(&ite5632_driver); + + release_region(EC_DATA_port, 5); +} + +module_init(wdt_init); +module_exit(wdt_exit); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("David Ober<dober@lenovo.com>"); +MODULE_DESCRIPTION("WDT driver for ITE5632");
This modules is to allow for the new ITE 5632 EC chip to support the watchdog for initial use in the Lenovo SE10 Signed-off-by: David Ober <dober6023@gmail.com> V2 Fix stop to deactivate wdog on unload of module V2 Remove extra logging that is not needed V2 change udelays to usleep_range V2 Changed to now request region on start and release on stop instead of for every ping and read/write V3 add counter to while loops so it will not hang V3 rework code to use platform_device_register_simple V3 rework getting the Chip ID to remove duplicate code and close IO V3 change some extra logging to be debug only --- drivers/watchdog/Kconfig | 10 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/ite5632_wdt.c | 278 +++++++++++++++++++++++++++++++++ 3 files changed, 289 insertions(+) create mode 100644 drivers/watchdog/ite5632_wdt.c