The Huygens is a Rainier with modifed FSI wiring.
Signed-off-by: Eddie James <[email protected]>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-ibm-huygens.dts | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 5e3392621697a..ac2804c96554a 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-ibm-bonnell.dtb \
aspeed-bmc-ibm-everest.dtb \
aspeed-bmc-ibm-fuji.dtb \
+ aspeed-bmc-ibm-huygens.dtb \
aspeed-bmc-ibm-rainier.dtb \
aspeed-bmc-ibm-rainier-1s4u.dtb \
aspeed-bmc-ibm-rainier-4u.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts
new file mode 100644
index 0000000000000..4a731b772fc0b
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2024 IBM Corp.
+/dts-v1/;
+
+#include "aspeed-bmc-ibm-rainier.dts"
+
+/ {
+ model = "Huygens";
+};
+
+&fsim0 {
+ /delete-node/ cfam@0,0;
+ /delete-property/ cfam-reset-gpios;
+
+ bus-frequency = <100000000>;
+};
+
+&fsim1 {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ status = "okay";
+ bus-frequency = <100000000>;
+};
--
2.39.3
Hi Eddie,
kernel test robot noticed the following build errors:
[auto build test ERROR on andi-shyti/i2c/i2c-host]
[also build test ERROR on linus/master v6.9 next-20240523]
[cannot apply to robh/for-next broonie-spi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Eddie-James/spi-dt-bindings-Document-the-IBM-FSI-attached-SPI-controller/20240523-033334
base: git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git i2c/i2c-host
patch link: https://lore.kernel.org/r/20240522192524.3286237-18-eajames%40linux.ibm.com
patch subject: [PATCH v6 17/20] ARM: dts: aspeed: Add IBM Huygens BMC system
config: arm-randconfig-001-20240523 (https://download.01.org/0day-ci/archive/20240523/[email protected]/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240523/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts:13.2-37 Properties must precede subnodes
FATAL ERROR: Unable to parse input tree
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
> The Huygens is a Rainier with modifed FSI wiring.
Will imperative wordings become helpful for a better commit message here?
Regards,
Markus
On 5/23/24 13:45, Markus Elfring wrote:
>> The Huygens is a Rainier with modifed FSI wiring.
> Will imperative wordings become helpful for a better commit message here?
This statement is a description of hardware. I cannot word that
imperatively. The commit message is imperative - "Add Huygens system".
>
> Regards,
> Markus
On 5/23/24 07:48, kernel test robot wrote:
> Hi Eddie,
>
> kernel test robot noticed the following build errors:
Silly mistake. If this patch can be dropped from the series, I can send
an updated Huygens DTS after this series is merged, unless I need to do
a v7.
Thanks,
Eddie
>
> [auto build test ERROR on andi-shyti/i2c/i2c-host]
> [also build test ERROR on linus/master v6.9 next-20240523]
> [cannot apply to robh/for-next broonie-spi/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Eddie-James/spi-dt-bindings-Document-the-IBM-FSI-attached-SPI-controller/20240523-033334
> base: git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git i2c/i2c-host
> patch link: https://lore.kernel.org/r/20240522192524.3286237-18-eajames%40linux.ibm.com
> patch subject: [PATCH v6 17/20] ARM: dts: aspeed: Add IBM Huygens BMC system
> config: arm-randconfig-001-20240523 (https://download.01.org/0day-ci/archive/20240523/[email protected]/config)
> compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240523/[email protected]/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
> All errors (new ones prefixed by >>):
>
>>> Error: arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-huygens.dts:13.2-37 Properties must precede subnodes
> FATAL ERROR: Unable to parse input tree
>
>>> The Huygens is a Rainier with modifed FSI wiring.
>> Will imperative wordings become helpful for a better commit message here?
>
>
> This statement is a description of hardware. I cannot word that imperatively.
Please take another look at corresponding improvement possibilities.
> The commit message is imperative - "Add Huygens system".
This information fits to the summary phrase.
Would you like to mention in the changelog that a hardware description
should be extended anyhow?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94
Regards,
Markus
Markus,
On Thu, May 23, 2024 at 09:30:55PM +0200, Markus Elfring wrote:
> >>> The Huygens is a Rainier with modifed FSI wiring.
> >> Will imperative wordings become helpful for a better commit message here?
> >
> >
> > This statement is a description of hardware. I cannot word that imperatively.
>
> Please take another look at corresponding improvement possibilities.
>
>
> > The commit message is imperative - "Add Huygens system".
>
> This information fits to the summary phrase.
>
> Would you like to mention in the changelog that a hardware description
> should be extended anyhow?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94
You are talking absolute crap here. Stop harassing contributors with
your inane comments.
Thanks,
Conor.
>> Would you like to mention in the changelog that a hardware description
>> should be extended anyhow?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94
>
> You are talking absolute crap here. Stop harassing contributors with
> your inane comments.
Why do you interpret my patch review contributions in this direction
when the official Linux development documentation provides special advice
on affected wording details?
Regards,
Markus
On 23/05/2024 21:00, Eddie James wrote:
>
> On 5/23/24 13:45, Markus Elfring wrote:
>>> The Huygens is a Rainier with modifed FSI wiring.
>> Will imperative wordings become helpful for a better commit message here?
>
>
> This statement is a description of hardware. I cannot word that
> imperatively. The commit message is imperative - "Add Huygens system".
Feel free to ignore all comments coming from Markus (or implement,
entirely up to you).
Markus is banned from mailing lists and most of maintainers already
ignore him or already marked as spam.
Best regards,
Krzysztof
> Markus is banned from mailing lists and most of maintainers already
> ignore him or already marked as spam.
The running patch review can eventually become more constructive
despite of recurring communication difficulties.
Regards,
Markus
Reviewed-by: Ninad Palsule <[email protected]>
On Thu, May 23, 2024 at 09:46:48PM +0200, Markus Elfring wrote:
> >> Would you like to mention in the changelog that a hardware description
> >> should be extended anyhow?
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9#n94
> >
> > You are talking absolute crap here. Stop harassing contributors with
> > your inane comments.
>
> Why do you interpret my patch review contributions in this direction
> when the official Linux development documentation provides special advice
> on affected wording details?
Your "contributions" are garbage in general, and this thread is not an exception.
More specifically, you are picking an advice that is inapplicable, transforming
it into a question and "contributing" the result.
And your entire modus operandi fits that pattern - you spew random garbage and
expect the contributors to spend their time and efforts on checking if your
(contents-free) "advice" happens to make any sense.
That. Is. Worthless.
According to people who'd met you in person you *are* a member of our species,
and I can't exclude the possibility that in some other environments you might
be capable of sentience. Unfortunately, the kernel development is clearly
not among those.
>> Why do you interpret my patch review contributions in this direction
>> when the official Linux development documentation provides special advice
>> on affected wording details?
>
> Your "contributions" are garbage in general,
My contributions are also varying (as usual) through the years.
> and this thread is not an exception.
It is just another example for involved communication challenges.
> More specifically, you are picking an advice
Some development activities are reminders according to known information sources.
> that is inapplicable,
> transforming it into a question and "contributing" the result.
>
> And your entire modus operandi fits that pattern - you spew random garbage and
> expect the contributors to spend their time and efforts on checking if your
> (contents-free) "advice" happens to make any sense.
Do you express special concerns here which can be reconsidered because of
advices and requirements from software development guidelines?
…
> Unfortunately, the kernel development is clearly
> not among those.
How does such a view fit to an other data representation?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Elfring
Regards,
Markus