Re: [PATCH v6 3/3] arm: dts: altera: add Draeger M48 CPU Module

[Petko Manolov]

On 26-09-18 13:57:22, Krzysztof Kozlowski wrote:
> On Thu, Sep 17, 2026 at 07:31:56PM +0300, Petko Manolov wrote:
> > Draeger M48 CPU Module that is built around Altera SoCFPGA.
> 
> How can you run a CPU module alone? To my knowledge there is only one such
> case, only one exception, and it was explained by the authors. If this is
> second, I already asked you to properly explain the hardware in commit msg.

I've described the board/carrier/module/whatever in the cover letter.  When i
put the same text in the commit message Sashiko rejected the patch on the
grounds that there should be just one CPU architecture there.  But there are
two.

> Your sentence above explains nothing.

Pleases read the above.  And now the explanation.

I'll try to describe the board once again.  Draeger folks are CCed so they can
correct me where i'm wrong.

This is a _proprietary_ board that consist of a carrier where the peripheral
devices live and SoM (hence 'module') where the _two_ SoCs live.  As i've
mentioned at least five times already, the imx6 and socfpga work _independently_
of each other but do _monitor_ each other constantly.  If one of the players
detect that the other one misbehaves or malfunctioned due to software or
hardware error, the respective, healthy SoC, takes over.

In this regard there's no _primary_ SoC as the other is capable of performing
the same tasks.  This is a heterogeneous board/module/younameit that is based on
two SoCs.  This is also not so uncommon in the industry.

This is where i am at right now:

	a) if i mention imx6 in the commit message of Altera socfpga binding or
	.dts Sashiko gets mad at me and rejects the patch;

	b) if i remove imx6 of the said commit you yell at me;

	c) M48 is a proprietary board with just one user - Draeger; 

I agree that my patches should not break the existing _semantic_ rules and they
should be refined before being accepted.

However, i do not understand why is it so hard for you to grasp the M48 concept
and apply some logic instead of stubbornness.  The commit message is not perfect
- how big of a deal is it?  Will it break anything important?  Either help me
make the commit message perfect or just accept it as it is.  We've already
wasted so much time on this stupid dts...


		Petko