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