ARM: dts: aspeed: tyan-s7106: Update nct7802 config
Subsystems (2)
PATCH v2 1/1 ARM: dts: aspeed: tyan-s7106: Update nct7802 config
This change updates the configuration for the nct7802 hardware monitor to correctly configure its temperature sensors.
---
Changes from PATCH v1:
- Removed superfluous "status" from channels.
--- arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts +19 -0
@@ -213,6 +213,25 @@ &i2c0 { nct7802 at 28 { compatible = "nuvoton,nct7802"; reg = <0x28>; + channel at 0 { /* LTD */ + reg = <0>; + }; + channel at 1 { /* RTD1 */ + reg = <1>; + sensor-type = "temperature"; + temperature-mode = "thermistor"; + }; + + channel at 2 { /* RTD2 */ + reg = <2>; + sensor-type = "temperature"; + temperature-mode = "thermistor"; + }; + + channel at 3 { /* RTD3 */ + reg = <3>; + sensor-type = "temperature"; + }; }; /* Also connected to:
Signature · 1 line
2.34.0.rc0.344.g81b53c2807-goog
Joel Stanley
maintainerQuoted 5 lines · Oskar Senft
This change updates the configuration for the nct7802 hardware monitor to correctly configure its temperature sensors.
Signed-off-by Oskar Senft <[email protected]>
I applied this and tried comple testing, and got this warning:
DTC arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb
../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:217.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:220.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 1:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:226.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 2:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:232.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 3:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb: Warning (pci_device_reg):
Failed prerequisite 'reg_format' arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb: Warning (i2c_bus_reg):
Failed prerequisite 'reg_format' arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb: Warning (spi_bus_reg):
Failed prerequisite 'reg_format' ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:216.13-218.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0: Relying on default #address-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:216.13-218.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0: Relying on default #size-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:219.13-223.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 1: Relying on default #address-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:219.13-223.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 1: Relying on default #size-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:225.13-229.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 2: Relying on default #address-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:225.13-229.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 2: Relying on default #size-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:231.13-234.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 3: Relying on default #address-cells value ../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:231.13-234.5: Warning (avoid_default_addr_size):
/ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 3: Relying on default #size-cells value
You need to add this to the nct node:
#address-cells = <1>;
#size-cells = <0>;
Did you see this with your testing? I'm building on top of v5.15 and my distro's dtc is 1.6.0.
Quoted 40 lines
---
Changes from PATCH v1:
- Removed superfluous "status" from channels.--- arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts +19
-1@@ -213,6 +213,25 @@ &i2c0 { nct7802 at 28 { compatible = "nuvoton,nct7802"; reg = <0x28>; + channel at 0 { /* LTD */ + reg = <0>; + }; + channel at 1 { /* RTD1 */ + reg = <1>; + sensor-type = "temperature"; + temperature-mode = "thermistor"; + }; + + channel at 2 { /* RTD2 */ + reg = <2>; + sensor-type = "temperature"; + temperature-mode = "thermistor"; + }; + + channel at 3 { /* RTD3 */ + reg = <3>; + sensor-type = "temperature"; + }; }; /* Also connected to: --2.34.0.rc0.344.g81b53c2807-goog
Hi Joel
Oh man, this is embarrassing!
Quoted 10 lines
I applied this and tried comple testing, and got this warning:
DTC
arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb
../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:217.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
[...]
You need to add this to the nct node:
Quoted 2 lines
#address-cells = <1>;
#size-cells = <0>;
Oh yeah, of course. It's even in the example in the binding that I wrote.
Quoted 2 lines
Did you see this with your testing? I'm building on top of v5.15 and my distro's dtc is 1.6.0.
I built (as part of OpenBMC) and ran (on actual HW), but these warnings don't make it out to the console. In my "defense", I did run checkpatch.pl, though.
Is there an easy way for me to see these types of warnings? Or should they really come out as errors?
I'll fix and send a PATCH v3.
I'm really sorry, this shouldn't be so much work for you!
Oskar.
To answer my own question and as a reminder for myself ...
Quoted 9 lines
Quoted 7 lines
I applied this and tried comple testing, and got this warning:
DTC
arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb
../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:217.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)Is there an easy way for me to see these types of warnings? Or should they really come out as errors?
Yes, there is:
1) Copy the .config from the OpenBMC build directory:
cp ~/src/openbmc/build/s7106/tmp/work/s7106-openbmc-linux-gnueabi/linux-aspeed/5.15+gitAUTOINC+da6376d789-r0/linux-s7106-standard-build/.config .
2) Run
ARCH="arm" make aspeed-bmc-tyan-s7106.dtb
Oskar.
Joel Stanley
maintainerQuoted 4 lines · Oskar Senft
Hi Joel
Oh man, this is embarrassing!
Don't worry about it. I'm a bit confused as to why I didn't see it this morning; I thought I did a build test then.
Quoted 15 lines
Quoted 11 lines
I applied this and tried comple testing, and got this warning:
DTC
arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dtb
../arch/arm/boot/dts/aspeed-bmc-tyan-s7106.dts:217.4-14: Warning (reg_format): /ahb/apb/bus at 1e78a000/i2c-bus at 40/nct7802 at 28/channel at 0:reg:
property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
[...]
You need to add this to the nct node:Quoted 2 lines
#address-cells = <1>;
#size-cells = <0>;Oh yeah, of course. It's even in the example in the binding that I wrote.
Quoted 8 lines
Quoted 2 lines
Did you see this with your testing? I'm building on top of v5.15 and my distro's dtc is 1.6.0.
I built (as part of OpenBMC) and ran (on actual HW), but these warnings don't make it out to the console. In my "defense", I did run checkpatch.pl, though.
Is there an easy way for me to see these types of warnings? Or should they really come out as errors?
Good question. v5.15 adds -Werror to the top level makefile, but as these warnings come from the device tree compiler they won't cause the build to fail. We should probably fix that, as I consider any dtc warning cause to rework the patch.
I test the kernels independently of yocto; I recommend doing that with a cross compiler when submitting patches upstream. My flow looks like this:
CROSS_COMPILE="ccache arm-linux-gnueabi-" ARCH=arm make O=aspeed-g5-dev aspeed_g5_defconfig
CROSS_COMPILE="ccache arm-linux-gnueabi-" ARCH=arm make -j8 O=aspeed-g5-dev -s qemu-system-arm -M rainier-bmc -nographic -net nic -kernel aspeed-g5-dev/arch/arm/boot/zImage -dtb aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dtb -initrd /home/joel/dev/kernels/misc/broomstick.cpio.xz -append 'console=ttyS4,115200n8 quiet' -no-reboot
A few notes:
- I use the cross compiler from my distro. Debian unstable has GCC
11.2.0, which is the same as openbmc. You can use the compiler from your openbmc build tree if you aren't able to install a modern compiler
- Using ccache is optional
- building with -s means warnings stand out
- if you're working on device trees and want to ensure your binary is
being built each time, omit the -s and build the 'dtbs' target
- booting in qemu is a quick smoke test. You don't need to your board
supported in qemu to test it (although it does help to avoid warnings from eg. i2c devices that won't probe if the hardware isn't present)
- adding 'quiet' to the qemu command line again makes it easier to
pick out warnings
That's a bit about how I work. You don't have to follow my work flow, but feel free to cherry pick bits that are useful.
Quoted 4 lines
I'll fix and send a PATCH v3.
I'm really sorry, this shouldn't be so much work for you!
No problem at all. Good work on iterating quickly.
Cheers,
Joel
Quoted 2 lines
Oskar.
Hi Joel
Quoted 9 lines
I test the kernels independently of yocto; I recommend doing that with a cross compiler when submitting patches upstream. My flow looks like this:
[...]
A few notes:
- I use the cross compiler from my distro. Debian unstable has GCC
11.2.0, which is the same as openbmc. You can use the compiler from your openbmc build tree if you aren't able to install a modern compiler
I couldn't figure out how to use the compiler from the OpenBMC tree. The biggest issue is that it has "openbmc" in its name and Linux build was getting confused by it. I gave up on that approach and found how to install the right cross compiler in our environment. That worked well. Thanks for the hints!
Quoted 1 line
- building with -s means warnings stand out
Excellent idea, thank you!
Quoted 2 lines
- if you're working on device trees and want to ensure your binary is
being built each time, omit the -s and build the 'dtbs' target
Ack.
I'll send a PATCH v3 now.
Oskar.
Joel Stanley
maintainerQuoted 12 lines · Oskar Senft
Hi Joel
Quoted 9 lines
I test the kernels independently of yocto; I recommend doing that with a cross compiler when submitting patches upstream. My flow looks like this:
[...]
A few notes:
- I use the cross compiler from my distro. Debian unstable has GCC
11.2.0, which is the same as openbmc. You can use the compiler from your openbmc build tree if you aren't able to install a modern compiler
Quoted 5 lines
I couldn't figure out how to use the compiler from the OpenBMC tree. The biggest issue is that it has "openbmc" in its name and Linux build was getting confused by it. I gave up on that approach and found how to install the right cross compiler in our environment. That worked well. Thanks for the hints!
Cool. For reference, you should be able to do this:
CROSS_COMPILE="openbmc/build/p10bmc/tmp/sysroots-components/x86_64/gcc-cross-arm/usr/bin/arm-openbmc-linux-gnueabi/arm-openbmc-linux-gnueabi-"
Quoted 11 lines
Quoted 2 lines
- building with -s means warnings stand out
Excellent idea, thank you!
Quoted 2 lines
- if you're working on device trees and want to ensure your binary is
being built each time, omit the -s and build the 'dtbs' targetAck.
I'll send a PATCH v3 now.
Oskar.