| Message ID | 45c5366f-cbee-4c7d-bb62-a446935b2729@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | i2c: i801: Use I2C_CLASS_HWMON for i2c mux children | expand |
Hi Heiner, On Tue, 31 Oct 2023 21:30:22 +0100, Heiner Kallweit wrote: > In case there ever should be a jc42-driven device on a muxed child bus, > we may end up with multiple logical devices, see linked discussion. > > jc42 is the only remaining i2c client device driver supporting > I2C_CLASS_SPD, however it supports I2C_CLASS_HWMON too. Therefore > we can safely switch to I2C_CLASS_HWMON on the muxed child busses. > IMO it's more logical anyway that the muxed child busses support > the same class that the parent supports if it's not muxed. > > This change is one further step towards removing I2C_CLASS_SPD. > > Link: https://www.spinics.net/lists/linux-i2c/msg65458.html > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> > --- > drivers/i2c/busses/i2c-i801.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c > index 070999139..8c9bb2e09 100644 > --- a/drivers/i2c/busses/i2c-i801.c > +++ b/drivers/i2c/busses/i2c-i801.c > @@ -1298,7 +1298,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d12 = { > .gpio_chip = "gpio_ich", > .values = { 0x02, 0x03 }, > .n_values = 2, > - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD }, > + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON }, > .gpios = { 52, 53 }, > .n_gpios = 2, > }; > @@ -1307,7 +1307,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d18 = { > .gpio_chip = "gpio_ich", > .values = { 0x02, 0x03, 0x01 }, > .n_values = 3, > - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD, I2C_CLASS_SPD }, > + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON, I2C_CLASS_HWMON }, > .gpios = { 52, 53 }, > .n_gpios = 2, > }; > @@ -1395,6 +1395,9 @@ static void i801_add_mux(struct i801_priv *priv) > > mux_config = id->driver_data; > > + /* Parent and mux children class support must not overlap */ > + priv->adapter.class = 0; There may also be a hardware monitoring device on the parent segment on these boards. With this change, that device will no longer be detected. That would be a regression, so I have to nack this proposed change, sorry. The only way forward I can think of (if we want to get rid of I2C_CLASS_SPD) would be to remove device auto-detection on children segments completely (.class = 0 for them) and instead actively probe for SPD EEPROMs and JC42 thermal sensors on these segments. For SPD we should be able to just reuse i2c_register_spd(). For JC42 we would need similar code, which doesn't exist yet.
On 06.11.2023 15:50, Jean Delvare wrote: > Hi Heiner, > > On Tue, 31 Oct 2023 21:30:22 +0100, Heiner Kallweit wrote: >> In case there ever should be a jc42-driven device on a muxed child bus, >> we may end up with multiple logical devices, see linked discussion. >> >> jc42 is the only remaining i2c client device driver supporting >> I2C_CLASS_SPD, however it supports I2C_CLASS_HWMON too. Therefore >> we can safely switch to I2C_CLASS_HWMON on the muxed child busses. >> IMO it's more logical anyway that the muxed child busses support >> the same class that the parent supports if it's not muxed. >> >> This change is one further step towards removing I2C_CLASS_SPD. >> >> Link: https://www.spinics.net/lists/linux-i2c/msg65458.html >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> >> --- >> drivers/i2c/busses/i2c-i801.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c >> index 070999139..8c9bb2e09 100644 >> --- a/drivers/i2c/busses/i2c-i801.c >> +++ b/drivers/i2c/busses/i2c-i801.c >> @@ -1298,7 +1298,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d12 = { >> .gpio_chip = "gpio_ich", >> .values = { 0x02, 0x03 }, >> .n_values = 2, >> - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD }, >> + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON }, >> .gpios = { 52, 53 }, >> .n_gpios = 2, >> }; >> @@ -1307,7 +1307,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d18 = { >> .gpio_chip = "gpio_ich", >> .values = { 0x02, 0x03, 0x01 }, >> .n_values = 3, >> - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD, I2C_CLASS_SPD }, >> + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON, I2C_CLASS_HWMON }, >> .gpios = { 52, 53 }, >> .n_gpios = 2, >> }; >> @@ -1395,6 +1395,9 @@ static void i801_add_mux(struct i801_priv *priv) >> >> mux_config = id->driver_data; >> >> + /* Parent and mux children class support must not overlap */ >> + priv->adapter.class = 0; > > There may also be a hardware monitoring device on the parent segment on > these boards. With this change, that device will no longer be detected. > That would be a regression, so I have to nack this proposed change, > sorry. > Hmm, right. To me it seems we have a fundamental problem: The parent has no way to find out whether a detected device sits on the parent segment or whether it belongs to a muxed child segment. In the latter case the device may show up twice, as you mentioned before. And the core check "supported classes of parent and child must not overlap" doesn't consider that we may have e.g. hwmon devices on parent segment and on muxed child segment too. > The only way forward I can think of (if we want to get rid of > I2C_CLASS_SPD) would be to remove device auto-detection on children > segments completely (.class = 0 for them) and instead actively probe > for SPD EEPROMs and JC42 thermal sensors on these segments. For SPD we > should be able to just reuse i2c_register_spd(). For JC42 we would need > similar code, which doesn't exist yet. > Regarding the first part, removing auto-detection on muxed children: We have only two i2c mux drivers supporting auto-detection, i2c-mux-gpio and i2c-mux-reg. Both do not support auto-detection for DT-configured systems. Only user for i2c-mux-gpio is i801. Only user for i2c-mux-reg is drivers/platform/x86/mlx-platform, and it doesn't make use of auto-detection. So I think as first step we should remove auto-detection support from i2c-mux-reg. Then we could do the same for i2c-mux-gpio, and afterwards remove the class parameter from i2c_mux_add_adapter(). So we need an "i2c_register_jc42()" only for use by i801. What's good, because we can make this function private to i801 and won't attract any potential additional users. + i2c-mux-gpio and i2c-mux-reg maintainers
Hi Heiner, On Tue, 7 Nov 2023 09:04:34 +0100, Heiner Kallweit wrote: > On 06.11.2023 15:50, Jean Delvare wrote: > > There may also be a hardware monitoring device on the parent segment on > > these boards. With this change, that device will no longer be detected. > > That would be a regression, so I have to nack this proposed change, > > sorry. > > Hmm, right. To me it seems we have a fundamental problem: > The parent has no way to find out whether a detected device sits on > the parent segment or whether it belongs to a muxed child segment. > In the latter case the device may show up twice, as you mentioned > before. Indeed. This is a fundamental limitation of SMBus multiplexing, which makes devices on the parent segment also visible on all children segments. > And the core check "supported classes of parent and child must not > overlap" doesn't consider that we may have e.g. hwmon devices > on parent segment and on muxed child segment too. Indeed. This worked when I implemented it only due to the combination of 3 factors: * The only hardware monitoring devices on the children SMBus segments of the supported Asus boards were the temperature sensors optionally integrated in the memory modules. * No I2C device driver was using more than one auto-detection class, so it was possible to partition auto-detection based on class flags (this assumption got broken by commit eacc48ce3acc later on). * The jc42 driver was using class I2C_CLASS_SPD instead of I2C_CLASS_HWMON (something we want to change now). The only safe and universal way to handle a muxed SMBus topology is to get rid of auto-detection entirely and instead explicitly instantiate all devices on the bus segment where we know they reside. > > The only way forward I can think of (if we want to get rid of > > I2C_CLASS_SPD) would be to remove device auto-detection on children > > segments completely (.class = 0 for them) and instead actively probe > > for SPD EEPROMs and JC42 thermal sensors on these segments. For SPD we > > should be able to just reuse i2c_register_spd(). For JC42 we would need > > similar code, which doesn't exist yet. > > Regarding the first part, removing auto-detection on muxed children: > We have only two i2c mux drivers supporting auto-detection, i2c-mux-gpio > and i2c-mux-reg. Both do not support auto-detection for DT-configured > systems. Well, if a device tree has been defined then devices are listed explicitly and auto-detection isn't needed. > Only user for i2c-mux-gpio is i801. Only user for i2c-mux-reg is > drivers/platform/x86/mlx-platform, and it doesn't make use of > auto-detection. > So I think as first step we should remove auto-detection support from > i2c-mux-reg. If it's unused, yes, we could and should, to prevent future usage as we now know this isn't the way to go. > Then we could do the same for i2c-mux-gpio, and afterwards remove the > class parameter from i2c_mux_add_adapter(). Right now, things are a bit clumsy, as the same device may end up being registered twice (once on the parent segment, once on the child segment) but this does not prevent monitoring the system. If you drop auto-detection without providing a replacement, you actually break system monitoring altogether. So the explicit device registration code must be ready before we consider dropping auto-detection support. In other words, we must convert the users first, and only when there's no user left, we can drop the unused code. > So we need an "i2c_register_jc42()" only for use by i801. > What's good, because we can make this function private to i801 and > won't attract any potential additional users. I disagree on that point. There's nothing i2c-i801-specific to i2c_register_jc42(), and it should be just as public and usable by other I2C bus drivers as i2c_register_spd(). Not only we don't want to discourage people from using these functions, but with the removal of the legacy eeprom driver, we actually want to encourage people to use these fonctions, to restore the lost functionality. My work on i2c-i801 with commit 01590f361e94 ("i2c: i801: Instantiate SPD EEPROMs automatically") was meant as an experiment to pave the road. There's no reason why other SMBus controller drivers used on PC-style systems wouldn't do exactly the same. The i2c-piix4 driver is a prime example of this. Not sure if there are actually other drivers falling into that category, as I think all Intel-based systems would use i2c-i801 and all AMD-based systems would use i2c-piix4 these days. About i2c_register_jc42(), I'm not sure if it can be a standalone function separated from i2c_register_spd(). While SPD EEPROMs are mandatory to have on memory modules, temperature sensors aren't. Also I think I recall that the JC42.4 temperature sensors standard is tied to the DDR4 memory type. So, to be on the safe side, we shouldn't blindly probe for jc42 devices on all supported addresses. Instead, we should only probe for addresses which correspond to an SPD EEPROM which has been successfully probed earlier, and only if memory type is DDR4. For example, if DMI data says the system is using DDR4 and we were able to detect and instantiate an ee1004 SPD device at I2C address 0x50 then we should probe for a JC42.4-compliant temperature sensor device at I2C address 0x18. An SPD EEPROM at 0x51 would correspond to a possible JC42.4-compliant device at 0x19, and so on. This is a little more work than probing all supported addresses arbitrarily, but this will avoid poking at other devices in ways which could have nasty side effects.
On 09.11.2023 14:52, Jean Delvare wrote: > Hi Heiner, > > On Tue, 7 Nov 2023 09:04:34 +0100, Heiner Kallweit wrote: >> On 06.11.2023 15:50, Jean Delvare wrote: >>> There may also be a hardware monitoring device on the parent segment on >>> these boards. With this change, that device will no longer be detected. >>> That would be a regression, so I have to nack this proposed change, >>> sorry. >> >> Hmm, right. To me it seems we have a fundamental problem: >> The parent has no way to find out whether a detected device sits on >> the parent segment or whether it belongs to a muxed child segment. >> In the latter case the device may show up twice, as you mentioned >> before. > > Indeed. This is a fundamental limitation of SMBus multiplexing, which > makes devices on the parent segment also visible on all children > segments. > >> And the core check "supported classes of parent and child must not >> overlap" doesn't consider that we may have e.g. hwmon devices >> on parent segment and on muxed child segment too. > > Indeed. This worked when I implemented it only due to the combination > of 3 factors: > * The only hardware monitoring devices on the children SMBus segments > of the supported Asus boards were the temperature sensors optionally > integrated in the memory modules. > * No I2C device driver was using more than one auto-detection class, so > it was possible to partition auto-detection based on class flags > (this assumption got broken by commit eacc48ce3acc later on). > * The jc42 driver was using class I2C_CLASS_SPD instead of > I2C_CLASS_HWMON (something we want to change now). > > The only safe and universal way to handle a muxed SMBus topology is to > get rid of auto-detection entirely and instead explicitly instantiate > all devices on the bus segment where we know they reside. > >>> The only way forward I can think of (if we want to get rid of >>> I2C_CLASS_SPD) would be to remove device auto-detection on children >>> segments completely (.class = 0 for them) and instead actively probe >>> for SPD EEPROMs and JC42 thermal sensors on these segments. For SPD we >>> should be able to just reuse i2c_register_spd(). For JC42 we would need >>> similar code, which doesn't exist yet. >> >> Regarding the first part, removing auto-detection on muxed children: >> We have only two i2c mux drivers supporting auto-detection, i2c-mux-gpio >> and i2c-mux-reg. Both do not support auto-detection for DT-configured >> systems. > > Well, if a device tree has been defined then devices are listed > explicitly and auto-detection isn't needed. > >> Only user for i2c-mux-gpio is i801. Only user for i2c-mux-reg is >> drivers/platform/x86/mlx-platform, and it doesn't make use of >> auto-detection. >> So I think as first step we should remove auto-detection support from >> i2c-mux-reg. > > If it's unused, yes, we could and should, to prevent future usage as we > now know this isn't the way to go. > >> Then we could do the same for i2c-mux-gpio, and afterwards remove the >> class parameter from i2c_mux_add_adapter(). > > Right now, things are a bit clumsy, as the same device may end up being > registered twice (once on the parent segment, once on the child > segment) but this does not prevent monitoring the system. If you drop > auto-detection without providing a replacement, you actually break > system monitoring altogether. So the explicit device registration code > must be ready before we consider dropping auto-detection support. > > In other words, we must convert the users first, and only when there's > no user left, we can drop the unused code. > >> So we need an "i2c_register_jc42()" only for use by i801. >> What's good, because we can make this function private to i801 and >> won't attract any potential additional users. > > I disagree on that point. There's nothing i2c-i801-specific to > i2c_register_jc42(), and it should be just as public and usable by > other I2C bus drivers as i2c_register_spd(). Not only we don't want to > discourage people from using these functions, but with the removal of > the legacy eeprom driver, we actually want to encourage people to use > these fonctions, to restore the lost functionality. > > My work on i2c-i801 with commit 01590f361e94 ("i2c: i801: Instantiate > SPD EEPROMs automatically") was meant as an experiment to pave the > road. There's no reason why other SMBus controller drivers used on > PC-style systems wouldn't do exactly the same. The i2c-piix4 driver is > a prime example of this. Not sure if there are actually other drivers > falling into that category, as I think all Intel-based systems would use > i2c-i801 and all AMD-based systems would use i2c-piix4 these days. > > About i2c_register_jc42(), I'm not sure if it can be a standalone > function separated from i2c_register_spd(). While SPD EEPROMs are > mandatory to have on memory modules, temperature sensors aren't. Also I > think I recall that the JC42.4 temperature sensors standard is tied to > the DDR4 memory type. So, to be on the safe side, we shouldn't blindly At least the Kconfig descriptions mentions that supported temperature sensors can be found on certain DDR3 modules. > probe for jc42 devices on all supported addresses. Instead, we should > only probe for addresses which correspond to an SPD EEPROM which has > been successfully probed earlier, and only if memory type is DDR4. > > For example, if DMI data says the system is using DDR4 and we were able > to detect and instantiate an ee1004 SPD device at I2C address 0x50 then > we should probe for a JC42.4-compliant temperature sensor device at I2C > address 0x18. An SPD EEPROM at 0x51 would correspond to a possible > JC42.4-compliant device at 0x19, and so on. > Nice idea. How about our ASUS use case in i801? i2c_register_spd() isn't called in case of muxing, neither for the parent nor for the mux children. > This is a little more work than probing all supported addresses > arbitrarily, but this will avoid poking at other devices in ways which > could have nasty side effects. >
Hi Heiner, On Thu, 9 Nov 2023 17:34:15 +0100, Heiner Kallweit wrote: > On 09.11.2023 14:52, Jean Delvare wrote: > > For example, if DMI data says the system is using DDR4 and we were able > > to detect and instantiate an ee1004 SPD device at I2C address 0x50 then > > we should probe for a JC42.4-compliant temperature sensor device at I2C > > address 0x18. An SPD EEPROM at 0x51 would correspond to a possible > > JC42.4-compliant device at 0x19, and so on. > > Nice idea. How about our ASUS use case in i801? i2c_register_spd() isn't > called in case of muxing, neither for the parent nor for the mux children. When I introduced i2c_register_spd(), I wanted to go one step at a time, as I didn't know what to expect due to the wide variety of systems affected. For this reason, systems where the SMBus is multiplexed were originally excluded. There's also a limitation in the function itself, on the number of memory slots, which is 4 for now, but could be lifted to 8 (maximum number of memory slots connected to a single SMBus segment). The Asus boards we are talking about may have more than 8 memory slots, so they would fail the test. If we want to be able to use i2c_register_spd() on these boards, some adjustments will be needed. For example, we could add a parameter to bypass the memory slot counting, so that the function could be called on children segments (only a subset of the memory slots will be connected to that segment, so the total slot count it irrelevant). We would ignore the DMI data and hard-code dimm_count to 8 in that case, to probe all possible addresses. Another approach would be to add a parameter (probably a bit field) describing which addresses should be probed, instead of guessing that from the dimm_count collected from DMI data. For the Asus boards in question, the information is known, and this would speed things up a bit by not probing addresses which can't possibly correspond to a memory module on a given board. That's only a minor optimization though, so not necessarily worth it. OTOH having that possibility would give more control on the probing, which may be useful for specific boards.
On 10.11.2023 12:08, Jean Delvare wrote: > Hi Heiner, > > On Thu, 9 Nov 2023 17:34:15 +0100, Heiner Kallweit wrote: >> On 09.11.2023 14:52, Jean Delvare wrote: >>> For example, if DMI data says the system is using DDR4 and we were able >>> to detect and instantiate an ee1004 SPD device at I2C address 0x50 then >>> we should probe for a JC42.4-compliant temperature sensor device at I2C >>> address 0x18. An SPD EEPROM at 0x51 would correspond to a possible >>> JC42.4-compliant device at 0x19, and so on. >> >> Nice idea. How about our ASUS use case in i801? i2c_register_spd() isn't >> called in case of muxing, neither for the parent nor for the mux children. > > When I introduced i2c_register_spd(), I wanted to go one step at a > time, as I didn't know what to expect due to the wide variety of > systems affected. For this reason, systems where the SMBus is > multiplexed were originally excluded. There's also a limitation in the > function itself, on the number of memory slots, which is 4 for now, but > could be lifted to 8 (maximum number of memory slots connected to a > single SMBus segment). > > The Asus boards we are talking about may have more than 8 memory slots, > so they would fail the test. If we want to be able to use > i2c_register_spd() on these boards, some adjustments will be needed. > For example, we could add a parameter to bypass the memory slot > counting, so that the function could be called on children segments > (only a subset of the memory slots will be connected to that segment, > so the total slot count it irrelevant). We would ignore the DMI data > and hard-code dimm_count to 8 in that case, to probe all possible > addresses. > > Another approach would be to add a parameter (probably a bit field) > describing which addresses should be probed, instead of guessing that > from the dimm_count collected from DMI data. For the Asus boards in > question, the information is known, and this would speed things up a > bit by not probing addresses which can't possibly correspond to a > memory module on a given board. That's only a minor optimization > though, so not necessarily worth it. OTOH having that possibility would > give more control on the probing, which may be useful for specific > boards. > Apart from the described extension of i2c_register_spd() I wonder where to best call it for the muxed smbus segments. At first I think we have to make the assumption that in case of muxing memory slots are on the muxed child segments only. At least I don't see an easy way to deal with the potential scenario that some memory slots are on the parent segment, and some on muxed segments. i801_add_mux() instantiates the i2c-mux-gpio platform device, and I think loading and probing the i2c-mux-gpio driver can happen asynchronously. This would mean we can't call i2c_register_spd() for the child segments from i801. So we may have to call it from the i2c-mux-gpio driver.
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c index 070999139..8c9bb2e09 100644 --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -1298,7 +1298,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d12 = { .gpio_chip = "gpio_ich", .values = { 0x02, 0x03 }, .n_values = 2, - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD }, + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON }, .gpios = { 52, 53 }, .n_gpios = 2, }; @@ -1307,7 +1307,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d18 = { .gpio_chip = "gpio_ich", .values = { 0x02, 0x03, 0x01 }, .n_values = 3, - .classes = { I2C_CLASS_SPD, I2C_CLASS_SPD, I2C_CLASS_SPD }, + .classes = { I2C_CLASS_HWMON, I2C_CLASS_HWMON, I2C_CLASS_HWMON }, .gpios = { 52, 53 }, .n_gpios = 2, }; @@ -1395,6 +1395,9 @@ static void i801_add_mux(struct i801_priv *priv) mux_config = id->driver_data; + /* Parent and mux children class support must not overlap */ + priv->adapter.class = 0; + /* Prepare the platform data */ memset(&gpio_data, 0, sizeof(struct i2c_mux_gpio_platform_data)); gpio_data.parent = priv->adapter.nr;
In case there ever should be a jc42-driven device on a muxed child bus, we may end up with multiple logical devices, see linked discussion. jc42 is the only remaining i2c client device driver supporting I2C_CLASS_SPD, however it supports I2C_CLASS_HWMON too. Therefore we can safely switch to I2C_CLASS_HWMON on the muxed child busses. IMO it's more logical anyway that the muxed child busses support the same class that the parent supports if it's not muxed. This change is one further step towards removing I2C_CLASS_SPD. Link: https://www.spinics.net/lists/linux-i2c/msg65458.html Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- drivers/i2c/busses/i2c-i801.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)