From: Patrick Williams <patrick@stwcx.xyz> To: Howard Chiu <howard10703049@gmail.com> Cc: arnd@arndb.de, olof@lixom.net, robh+dt@kernel.org, joel@jms.id.au, andrew@aj.id.au, soc@kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, Howard Chiu <howard.chiu@quantatw.com> Subject: Re: [PATCH v1] ARM: dts: aspeed: Adding Facebook Bletchley BMC Date: Wed, 3 Nov 2021 09:20:36 -0500 [thread overview] Message-ID: <YYKatBCCroiYxLew@heinlein> (raw) In-Reply-To: <20211103071417.388388-1-howard.chiu@quantatw.com> [-- Attachment #1: Type: text/plain, Size: 3516 bytes --] Hello Howard, Thanks for supplying this. I have a few comments below. On Wed, Nov 03, 2021 at 03:14:18PM +0800, Howard Chiu wrote: > Initial introduction of Facebook Bletchley equipped with > Aspeed 2600 BMC SoC. > > Signed-off-by: Howard Chiu <howard.chiu@quantatw.com> > --- > arch/arm/boot/dts/Makefile | 1 + > .../dts/aspeed-bmc-facebook-bletchley.dts | 1160 +++++++++++++++++ > 2 files changed, 1161 insertions(+) > create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 7e0934180724..2cc2d804e75a 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -1474,6 +1474,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \ > aspeed-bmc-facebook-wedge400.dtb \ > aspeed-bmc-facebook-yamp.dtb \ > aspeed-bmc-facebook-yosemitev2.dtb \ > + aspeed-bmc-facebook-bletchley.dtb \ > aspeed-bmc-ibm-everest.dtb \ > aspeed-bmc-ibm-rainier.dtb \ > aspeed-bmc-ibm-rainier-1s4u.dtb \ I believe the preference is to keep these sorted. > diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > new file mode 100644 > index 000000000000..af30be95fb23 > --- /dev/null > +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > + > + chosen { > + bootargs = "console=ttyS4,115200n8"; > + }; Do we want this to be 115200 or 57600? > + fan1_ember { > + retain-state-shutdown; > + default-state = "off"; > + gpios = <&fan_ioexp 13 GPIO_ACTIVE_HIGH>; I see a number of references to 'ember'/'EMBER'. I think the intention is 'amber'. amber: a honey-yellow color typical of amber or a yellow light used as a cautionary signal ember: a small piece of burning or glowing coal or wood in a dying fire. > +&fmc { > + status = "okay"; > + flash@0 { > + status = "okay"; > + m25p,fast-read; > + label = "bmc"; > + spi-max-frequency = <50000000>; > +#include "openbmc-flash-layout-64.dtsi" Is this board using 64MB or 128MB modules? Many of the newer systems have been starting to use 128MB. I just want to confirm this is correct. > + sled0_ioexp: pca9539@76 { > + compatible = "nxp,pca9539"; > + reg = <0x76>; > + #address-cells = <1>; > + #size-cells = <0>; > + gpio-controller; > + #gpio-cells = <2>; > + > + gpio-line-names = > + "","SLED0_BMC_CCG5_INT","SLED0_INA230_ALERT","SLED0_P12V_STBY_ALERT", > + "SLED0_SSD_ALERT","SLED0_MS_DETECT","SLED0_MD_REF_PWM","", > + "SLED0_MD_STBY_RESET","SLED0_MD_IOEXP_EN_FAULT","SLED0_MD_DIR","SLED0_MD_DECAY", > + "SLED0_MD_MODE1","SLED0_MD_MODE2","SLED0_MD_MODE3","SLED0_AC_PWR_EN"; In general, in OpenBMC, we have a preference for the GPIOs to not be schematic names but to be named based on their [software-oriented] function. Please take a look at: https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md Any function you see that isn't documented there we should try to get documented before fixing the GPIO name to match it. > + gpio-line-names = > + "SLED0_EMBER_LED","SLED0_BLUE_LED","SLED0_RST_IOEXP","", The LEDs are ones I know are already documented in the above linked file. > +&i2c13 { > + multi-master; > + aspeed,hw-timeout-ms = <1000>; > + status = "okay"; > +}; Was this intentional to have defined a multi-master bus with nothing on it? -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Williams <patrick@stwcx.xyz> To: Howard Chiu <howard10703049@gmail.com> Cc: arnd@arndb.de, olof@lixom.net, robh+dt@kernel.org, joel@jms.id.au, andrew@aj.id.au, soc@kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, Howard Chiu <howard.chiu@quantatw.com> Subject: Re: [PATCH v1] ARM: dts: aspeed: Adding Facebook Bletchley BMC Date: Wed, 3 Nov 2021 09:20:36 -0500 [thread overview] Message-ID: <YYKatBCCroiYxLew@heinlein> (raw) Message-ID: <20211103142036.M9SVDVe-2hxTSg69QeyqVBQOT3GJrVoLEVHoqJk5zzM@z> (raw) In-Reply-To: <20211103071417.388388-1-howard.chiu@quantatw.com> [-- Attachment #1.1: Type: text/plain, Size: 3516 bytes --] Hello Howard, Thanks for supplying this. I have a few comments below. On Wed, Nov 03, 2021 at 03:14:18PM +0800, Howard Chiu wrote: > Initial introduction of Facebook Bletchley equipped with > Aspeed 2600 BMC SoC. > > Signed-off-by: Howard Chiu <howard.chiu@quantatw.com> > --- > arch/arm/boot/dts/Makefile | 1 + > .../dts/aspeed-bmc-facebook-bletchley.dts | 1160 +++++++++++++++++ > 2 files changed, 1161 insertions(+) > create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 7e0934180724..2cc2d804e75a 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -1474,6 +1474,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \ > aspeed-bmc-facebook-wedge400.dtb \ > aspeed-bmc-facebook-yamp.dtb \ > aspeed-bmc-facebook-yosemitev2.dtb \ > + aspeed-bmc-facebook-bletchley.dtb \ > aspeed-bmc-ibm-everest.dtb \ > aspeed-bmc-ibm-rainier.dtb \ > aspeed-bmc-ibm-rainier-1s4u.dtb \ I believe the preference is to keep these sorted. > diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > new file mode 100644 > index 000000000000..af30be95fb23 > --- /dev/null > +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-bletchley.dts > + > + chosen { > + bootargs = "console=ttyS4,115200n8"; > + }; Do we want this to be 115200 or 57600? > + fan1_ember { > + retain-state-shutdown; > + default-state = "off"; > + gpios = <&fan_ioexp 13 GPIO_ACTIVE_HIGH>; I see a number of references to 'ember'/'EMBER'. I think the intention is 'amber'. amber: a honey-yellow color typical of amber or a yellow light used as a cautionary signal ember: a small piece of burning or glowing coal or wood in a dying fire. > +&fmc { > + status = "okay"; > + flash@0 { > + status = "okay"; > + m25p,fast-read; > + label = "bmc"; > + spi-max-frequency = <50000000>; > +#include "openbmc-flash-layout-64.dtsi" Is this board using 64MB or 128MB modules? Many of the newer systems have been starting to use 128MB. I just want to confirm this is correct. > + sled0_ioexp: pca9539@76 { > + compatible = "nxp,pca9539"; > + reg = <0x76>; > + #address-cells = <1>; > + #size-cells = <0>; > + gpio-controller; > + #gpio-cells = <2>; > + > + gpio-line-names = > + "","SLED0_BMC_CCG5_INT","SLED0_INA230_ALERT","SLED0_P12V_STBY_ALERT", > + "SLED0_SSD_ALERT","SLED0_MS_DETECT","SLED0_MD_REF_PWM","", > + "SLED0_MD_STBY_RESET","SLED0_MD_IOEXP_EN_FAULT","SLED0_MD_DIR","SLED0_MD_DECAY", > + "SLED0_MD_MODE1","SLED0_MD_MODE2","SLED0_MD_MODE3","SLED0_AC_PWR_EN"; In general, in OpenBMC, we have a preference for the GPIOs to not be schematic names but to be named based on their [software-oriented] function. Please take a look at: https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md Any function you see that isn't documented there we should try to get documented before fixing the GPIO name to match it. > + gpio-line-names = > + "SLED0_EMBER_LED","SLED0_BLUE_LED","SLED0_RST_IOEXP","", The LEDs are ones I know are already documented in the above linked file. > +&i2c13 { > + multi-master; > + aspeed,hw-timeout-ms = <1000>; > + status = "okay"; > +}; Was this intentional to have defined a multi-master bus with nothing on it? -- Patrick Williams [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-03 14:20 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-03 7:14 [PATCH v1] ARM: dts: aspeed: Adding Facebook Bletchley BMC Howard Chiu 2021-11-03 7:14 ` Howard Chiu 2021-11-03 14:20 ` Patrick Williams [this message] 2021-11-03 14:20 ` Patrick Williams 2021-11-04 3:30 ` Howard Chiu (邱冠睿) 2021-11-04 3:30 ` Howard Chiu (邱冠睿) 2021-11-04 9:30 ` Patrick Williams 2021-11-04 9:30 ` Patrick Williams 2021-11-04 9:30 ` Patrick Williams 2021-11-05 2:02 ` Howard Chiu (邱冠睿)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YYKatBCCroiYxLew@heinlein \ --to=patrick@stwcx.xyz \ --cc=andrew@aj.id.au \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=howard.chiu@quantatw.com \ --cc=howard10703049@gmail.com \ --cc=joel@jms.id.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=olof@lixom.net \ --cc=robh+dt@kernel.org \ --cc=soc@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).