| Message ID | 20220226133047.6226-1-zev@bewilderbeest.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | hwmon: (nct6775) Add i2c support | expand |
On Sat, Feb 26, 2022 at 05:30:42AM PST, Zev Weiss wrote: >Hello, > >This patch series augments the existing nct6775 driver with support >for the hardware's i2c interface. > > <snip> > >I've tested the nct6775-platform and nct6775-i2c drivers with the >NCT6779D in an ASRock ROMED8HM3 system (the latter driver on its >AST2500 BMC); both seem to work as expected. Broader testing would of >course be welcome though, as is review feedback. > Also, for the sake of anyone testing or otherwise applying these patches I should mention that the series is based on Guenter's hwmon-next tree (commit 9db3b740a801). Zev
On 2/26/22 05:30, Zev Weiss wrote: > Hello, > > This patch series augments the existing nct6775 driver with support > for the hardware's i2c interface. > > Thus far the nct6775 driver has only supported the LPC interface, > which is the main interface by which the Super-I/O chip is typically > connected to the host (x86) processor. > > However, these chips also provide an i2c interface, which can provide > a way for a BMC to also monitor sensor readings from them. On some > systems (such as the ASRock Rack ROMED8HM3 and X570-D4U) this may be > the only way for the BMC to monitor host CPU temperatures (e.g. to > indirectly access a TSI interface); this functionality is thus an > important component of enabling OpenBMC to support such systems. > > In such an arrangement the Super-I/O chip is simultaneously controlled > by two independent processors (the host and the BMC) which typically > do not coordinate their accesses with each other. In order to avoid > conflicts between the two, the i2c driver avoids all writes to the > device, since the BMC's needs with the hardware are merely that it be > able to retrieve sensor readings. This allows the host processor to > remain ultimately in control of the chip and unaware of the BMC's use > of it at all. > > The sole exception to the "no writes" rule for the i2c driver is for > the bank-select register -- while I haven't been able to find any > explicit statement in the Nuvoton datasheets guaranteeing this, all > experiments I've done have indicated that, as one might hope, the i2c > interface has its own bank-select register independent of the one used > by the LPC interface. > That will a more detailed confirmation. Please explain in detail the experiments you have done. Other chips (specifically those served by the it87 driver) have the same problem, and there it was never really solved. That resulted in random crashes. I don't want to end up in the same situation. > In terms of code structure, the approach taken in this series is to > split the LPC-specific parts of the driver out into a separate module > (called nct6775-platform), leaving the interface-independent parts in > a generic driver (called nct6775-core). The nct6775-i2c driver is > then added as an additional consumer of the nct6775-core module's > functionality. > How about wmi ? Shouldn't that be separated as well ? Guenter > The first two patches make some relatively small infrastructural > changes to the nct6775 driver; the bulk of the core/platform driver > split is in the third patch. The final two patches add DT bindings > and the i2c driver itself. > > I've tested the nct6775-platform and nct6775-i2c drivers with the > NCT6779D in an ASRock ROMED8HM3 system (the latter driver on its > AST2500 BMC); both seem to work as expected. Broader testing would of > course be welcome though, as is review feedback. >
Hello. On sobota 26. února 2022 14:30:42 CET Zev Weiss wrote: > Hello, > > This patch series augments the existing nct6775 driver with support > for the hardware's i2c interface. Is it something I can test on my ASUS Pro WS X570-ACE board as an ordinary user, and if so, how? Thanks. > Thus far the nct6775 driver has only supported the LPC interface, > which is the main interface by which the Super-I/O chip is typically > connected to the host (x86) processor. > > However, these chips also provide an i2c interface, which can provide > a way for a BMC to also monitor sensor readings from them. On some > systems (such as the ASRock Rack ROMED8HM3 and X570-D4U) this may be > the only way for the BMC to monitor host CPU temperatures (e.g. to > indirectly access a TSI interface); this functionality is thus an > important component of enabling OpenBMC to support such systems. > > In such an arrangement the Super-I/O chip is simultaneously controlled > by two independent processors (the host and the BMC) which typically > do not coordinate their accesses with each other. In order to avoid > conflicts between the two, the i2c driver avoids all writes to the > device, since the BMC's needs with the hardware are merely that it be > able to retrieve sensor readings. This allows the host processor to > remain ultimately in control of the chip and unaware of the BMC's use > of it at all. > > The sole exception to the "no writes" rule for the i2c driver is for > the bank-select register -- while I haven't been able to find any > explicit statement in the Nuvoton datasheets guaranteeing this, all > experiments I've done have indicated that, as one might hope, the i2c > interface has its own bank-select register independent of the one used > by the LPC interface. > > In terms of code structure, the approach taken in this series is to > split the LPC-specific parts of the driver out into a separate module > (called nct6775-platform), leaving the interface-independent parts in > a generic driver (called nct6775-core). The nct6775-i2c driver is > then added as an additional consumer of the nct6775-core module's > functionality. > > The first two patches make some relatively small infrastructural > changes to the nct6775 driver; the bulk of the core/platform driver > split is in the third patch. The final two patches add DT bindings > and the i2c driver itself. > > I've tested the nct6775-platform and nct6775-i2c drivers with the > NCT6779D in an ASRock ROMED8HM3 system (the latter driver on its > AST2500 BMC); both seem to work as expected. Broader testing would of > course be welcome though, as is review feedback. > > > Thanks, > Zev > > > Zev Weiss (5): > hwmon: (nct6775) Rearrange attr-group initialization > hwmon: (nct6775) Add read-only mode > hwmon: (nct6775) Split core and platform driver > dt-bindings: hwmon: Add nuvoton,nct6775 > hwmon: (nct6775) Add i2c driver > > .../bindings/hwmon/nuvoton,nct6775.yaml | 48 + > MAINTAINERS | 12 +- > drivers/hwmon/Kconfig | 32 +- > drivers/hwmon/Makefile | 4 +- > drivers/hwmon/{nct6775.c => nct6775-core.c} | 1464 +---------------- > drivers/hwmon/nct6775-i2c.c | 191 +++ > drivers/hwmon/nct6775-platform.c | 1185 +++++++++++++ > drivers/hwmon/nct6775.h | 233 +++ > 8 files changed, 1763 insertions(+), 1406 deletions(-) > create mode 100644 Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml > rename drivers/hwmon/{nct6775.c => nct6775-core.c} (75%) > create mode 100644 drivers/hwmon/nct6775-i2c.c > create mode 100644 drivers/hwmon/nct6775-platform.c > create mode 100644 drivers/hwmon/nct6775.h > >
On Sat, Feb 26, 2022 at 04:14:12PM PST, Oleksandr Natalenko wrote: >Hello. > >On sobota 26. února 2022 14:30:42 CET Zev Weiss wrote: >> Hello, >> >> This patch series augments the existing nct6775 driver with support >> for the hardware's i2c interface. > >Is it something I can test on my ASUS Pro WS X570-ACE board as an ordinary user, and if so, how? > You could certainly test that the nct6775-platform driver still works as it did previously, which would be good to confirm -- you'll need to enable CONFIG_SENSORS_NCT6775_PLATFORM now to build it. From what I've been able to find about that board though it looks like it doesn't have a BMC, so testing the i2c driver on it probably isn't going to be possible. (Even if it does in fact have a BMC, it would require at least a partial port of OpenBMC or similar, and re-flashing your BMC firmware with that, and is hence a non-trivial undertaking.) Zev
[Adding Denis re: wmi discussion below...] On Sat, Feb 26, 2022 at 03:54:42PM PST, Guenter Roeck wrote: >On 2/26/22 05:30, Zev Weiss wrote: >>Hello, >> >>This patch series augments the existing nct6775 driver with support >>for the hardware's i2c interface. >> >>Thus far the nct6775 driver has only supported the LPC interface, >>which is the main interface by which the Super-I/O chip is typically >>connected to the host (x86) processor. >> >>However, these chips also provide an i2c interface, which can provide >>a way for a BMC to also monitor sensor readings from them. On some >>systems (such as the ASRock Rack ROMED8HM3 and X570-D4U) this may be >>the only way for the BMC to monitor host CPU temperatures (e.g. to >>indirectly access a TSI interface); this functionality is thus an >>important component of enabling OpenBMC to support such systems. >> >>In such an arrangement the Super-I/O chip is simultaneously controlled >>by two independent processors (the host and the BMC) which typically >>do not coordinate their accesses with each other. In order to avoid >>conflicts between the two, the i2c driver avoids all writes to the >>device, since the BMC's needs with the hardware are merely that it be >>able to retrieve sensor readings. This allows the host processor to >>remain ultimately in control of the chip and unaware of the BMC's use >>of it at all. >> >>The sole exception to the "no writes" rule for the i2c driver is for >>the bank-select register -- while I haven't been able to find any >>explicit statement in the Nuvoton datasheets guaranteeing this, all >>experiments I've done have indicated that, as one might hope, the i2c >>interface has its own bank-select register independent of the one used >>by the LPC interface. >> > >That will a more detailed confirmation. Please explain in detail >the experiments you have done. > >Other chips (specifically those served by the it87 driver) have the >same problem, and there it was never really solved. That resulted >in random crashes. I don't want to end up in the same situation. > On an ASRock Rack ROMED8HM3, I used the following program to manually peek and poke device registers from the host: host# cat port.c #include <stdlib.h> #include <string.h> #include <stdio.h> #include <sys/io.h> int main(int argc, char** argv) { unsigned long addr, val; if (iopl(3)) { perror("iopl"); exit(1); } if (argc == 3 && !strcmp(argv[1], "r")) { addr = strtoul(argv[2], NULL, 0); printf("%03lx: %02x\n", addr, inb(addr)); } else if (argc == 4 && !strcmp(argv[1], "w")) { addr = strtoul(argv[2], NULL, 0); val = strtoul(argv[3], NULL, 0); printf("%03lx <- %02lx\n", addr, val); outb(val, addr); } else { fprintf(stderr, "Usage: %s [rw] ADDR [VALUE]\n", argv[0]); exit(1); } return 0; } host# cc -o port port.c At the same time, I used i2cget & i2cset to do the same from the BMC (the nct6779 is at address 0x2d on bus 1). Interleaving some shell transcripts chronologically (no drivers bound on either processor): host# ./port w 0x295 0x4e && ./port r 0x296 295 <- 4e 296: 08 bmc# i2cget -y 1 0x2d 0x4e 0x02 bmc# i2cset -y 1 0x2d 0x4e 0x01 bmc# i2cget -y 1 0x2d 0x4e 0x01 host# ./port w 0x295 0x4e && ./port r 0x296 295 <- 4e 296: 08 So, starting from an initial state where the two sides were reporting different values for the bank select register, a write to the bank select register via the BMC's i2c interface is seen by a subsequent read over that same interface, but the host still sees the same value it saw initially. Reversing the roles (host writing the bank-select register), the BMC is likewise unaffected: bmc# i2cget -y 1 0x2d 0x4e 0x01 host# ./port w 0x295 0x4e && ./port r 0x296 295 <- 4e 296: 08 host# ./port w 0x295 0x4e && ./port w 0x296 0x06 295 <- 4e 296 <- 06 host# ./port w 0x295 0x4e && ./port r 0x296 295 <- 4e 296: 06 bmc# i2cget -y 1 0x2d 0x4e 0x01 In contrast, looking at a different read/write register (the config register at 0x40 in bank 0, for example), writes from each side are seen by the other: host# ./port w 0x295 0x4e && ./port w 0x296 0x00 295 <- 4e 296 <- 00 host# ./port w 0x295 0x40 && ./port r 0x296 295 <- 40 296: 03 bmc# i2cset -y 1 0x2d 0x4e 0x00 bmc# i2cget -y 1 0x2d 0x40 0x03 bmc# i2cset -y 1 0x2d 0x40 0x01 bmc# i2cget -y 1 0x2d 0x40 0x01 host# ./port w 0x295 0x40 && ./port r 0x296 295 <- 40 296: 01 host# ./port w 0x295 0x40 && ./port w 0x296 0x03 295 <- 40 296 <- 03 host# ./port w 0x295 0x40 && ./port r 0x296 295 <- 40 296: 03 bmc# i2cget -y 1 0x2d 0x40 0x03 To be cautious we could perhaps trim down the list of supported chips in the i2c driver to include only the models that are known to pass tests like the above; I can certainly make that change if that would be preferred. >>In terms of code structure, the approach taken in this series is to >>split the LPC-specific parts of the driver out into a separate module >>(called nct6775-platform), leaving the interface-independent parts in >>a generic driver (called nct6775-core). The nct6775-i2c driver is >>then added as an additional consumer of the nct6775-core module's >>functionality. >> > >How about wmi ? Shouldn't that be separated as well ? > I admittedly don't know much about wmi, but from what I could see in the code it looked to me like it essentially just acts as an alternate software/firmware path to the same underlying LPC interface, so I figured it would make sense to leave it integrated with the rest of the platform driver as it is currently. If there's a particular benefit to be gained from splitting it out as well I can look into doing so, but from my current understanding it seems like it would lead to either: - duplication between the wmi and bare inb/outb versions of the platform driver, or - to eliminate the duplication, a third (intermediate) module containing the code that was common to the two of them, leaving the two platform driver modules as little else than the bare register I/O routines (superio_[wmi_]inb, nct6775_[wmi_]read_value, etc.), i.e. the differences that are already handled via the indirection of the function pointers Denis added recently. I suppose the hypothetical intermediate module in the second scenario above could also be integrated back into nct6775-core, though that part of it would then be needless dead weight for the typically more resource-constrained systems (e.g. BMCs) that are only going to use the i2c driver. Anyway, none of the above possibilities seemed terribly appealing to me, but if there's something I've misunderstood or factors I haven't taken into account please let me know. Thanks, Zev
Hello. On neděle 27. února 2022 1:27:55 CET Zev Weiss wrote: > On Sat, Feb 26, 2022 at 04:14:12PM PST, Oleksandr Natalenko wrote: > >Hello. > > > >On sobota 26. února 2022 14:30:42 CET Zev Weiss wrote: > >> Hello, > >> > >> This patch series augments the existing nct6775 driver with support > >> for the hardware's i2c interface. > > > >Is it something I can test on my ASUS Pro WS X570-ACE board as an ordinary user, and if so, how? > > > > You could certainly test that the nct6775-platform driver still works as > it did previously, which would be good to confirm -- you'll need to > enable CONFIG_SENSORS_NCT6775_PLATFORM now to build it. Ack. > From what I've been able to find about that board though it looks like > it doesn't have a BMC, so testing the i2c driver on it probably isn't > going to be possible. (Even if it does in fact have a BMC, it would > require at least a partial port of OpenBMC or similar, and re-flashing > your BMC firmware with that, and is hence a non-trivial undertaking.) It should have, the BMC is based on RTL8117, although I have no idea if it is something that can be called true IPMI as I've never enabled/used it. Thanks. > > > Zev > >
On Sun, Feb 27, 2022 at 01:38:31PM PST, Oleksandr Natalenko wrote: >Hello. > >On neděle 27. února 2022 1:27:55 CET Zev Weiss wrote: >> On Sat, Feb 26, 2022 at 04:14:12PM PST, Oleksandr Natalenko wrote: >> >Hello. >> > >> >On sobota 26. února 2022 14:30:42 CET Zev Weiss wrote: >> >> Hello, >> >> >> >> This patch series augments the existing nct6775 driver with support >> >> for the hardware's i2c interface. >> > >> >Is it something I can test on my ASUS Pro WS X570-ACE board as an ordinary user, and if so, how? >> > >> >> You could certainly test that the nct6775-platform driver still works as >> it did previously, which would be good to confirm -- you'll need to >> enable CONFIG_SENSORS_NCT6775_PLATFORM now to build it. > >Ack. > >> From what I've been able to find about that board though it looks like >> it doesn't have a BMC, so testing the i2c driver on it probably isn't >> going to be possible. (Even if it does in fact have a BMC, it would >> require at least a partial port of OpenBMC or similar, and re-flashing >> your BMC firmware with that, and is hence a non-trivial undertaking.) > >It should have, the BMC is based on RTL8117, although I have no idea if it is something that can be called true IPMI as I've never enabled/used it. > Ah, interesting -- I hadn't heard of that chip before, and web searches mostly seem to turn up discussions of that particular board (and sibling models), so I guess it's probably not very widely used elsewhere. It does appear to run an OpenWRT-based firmware with source available (https://gitlab.com/gplmirror/rtl8117), though apparently with a rather old (4.4) kernel (and with added fun goodies like what looks to be a partial implementation of an in-kernel VNC server??). So I guess in theory if you were feeling adventurous and wanted to backport these patches to that kernel, recompile the firmware, and flash the result onto your hardware you could *maybe* test out the i2c driver, though it's probably a much deeper rabbit hole than is likely to be worthwhile, and with significant risk of leaving your hardware in an awkward (potentially bricked) state if things go awry, so it's not something I'd recommend taking on casually. There would also still be the process of figuring out at what i2c bus/address the Super-I/O chip lives for the rtl8117, if its i2c interface is even attached at all, which I don't think is guaranteed -- the rtl8117 might not need it if it's not in charge of thermal monitoring/fan control on that board, and even if it is handling that it might have a direct connection to the TSI interface instead of going through the Super-I/O chip as is done on the ASRock boards I'm familiar with. Zev
Hello, This patch series augments the existing nct6775 driver with support for the hardware's i2c interface. Thus far the nct6775 driver has only supported the LPC interface, which is the main interface by which the Super-I/O chip is typically connected to the host (x86) processor. However, these chips also provide an i2c interface, which can provide a way for a BMC to also monitor sensor readings from them. On some systems (such as the ASRock Rack ROMED8HM3 and X570-D4U) this may be the only way for the BMC to monitor host CPU temperatures (e.g. to indirectly access a TSI interface); this functionality is thus an important component of enabling OpenBMC to support such systems. In such an arrangement the Super-I/O chip is simultaneously controlled by two independent processors (the host and the BMC) which typically do not coordinate their accesses with each other. In order to avoid conflicts between the two, the i2c driver avoids all writes to the device, since the BMC's needs with the hardware are merely that it be able to retrieve sensor readings. This allows the host processor to remain ultimately in control of the chip and unaware of the BMC's use of it at all. The sole exception to the "no writes" rule for the i2c driver is for the bank-select register -- while I haven't been able to find any explicit statement in the Nuvoton datasheets guaranteeing this, all experiments I've done have indicated that, as one might hope, the i2c interface has its own bank-select register independent of the one used by the LPC interface. In terms of code structure, the approach taken in this series is to split the LPC-specific parts of the driver out into a separate module (called nct6775-platform), leaving the interface-independent parts in a generic driver (called nct6775-core). The nct6775-i2c driver is then added as an additional consumer of the nct6775-core module's functionality. The first two patches make some relatively small infrastructural changes to the nct6775 driver; the bulk of the core/platform driver split is in the third patch. The final two patches add DT bindings and the i2c driver itself. I've tested the nct6775-platform and nct6775-i2c drivers with the NCT6779D in an ASRock ROMED8HM3 system (the latter driver on its AST2500 BMC); both seem to work as expected. Broader testing would of course be welcome though, as is review feedback. Thanks, Zev Zev Weiss (5): hwmon: (nct6775) Rearrange attr-group initialization hwmon: (nct6775) Add read-only mode hwmon: (nct6775) Split core and platform driver dt-bindings: hwmon: Add nuvoton,nct6775 hwmon: (nct6775) Add i2c driver .../bindings/hwmon/nuvoton,nct6775.yaml | 48 + MAINTAINERS | 12 +- drivers/hwmon/Kconfig | 32 +- drivers/hwmon/Makefile | 4 +- drivers/hwmon/{nct6775.c => nct6775-core.c} | 1464 +---------------- drivers/hwmon/nct6775-i2c.c | 191 +++ drivers/hwmon/nct6775-platform.c | 1185 +++++++++++++ drivers/hwmon/nct6775.h | 233 +++ 8 files changed, 1763 insertions(+), 1406 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml rename drivers/hwmon/{nct6775.c => nct6775-core.c} (75%) create mode 100644 drivers/hwmon/nct6775-i2c.c create mode 100644 drivers/hwmon/nct6775-platform.c create mode 100644 drivers/hwmon/nct6775.h