From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Josua Mayer <josua@solid-run.com>, Nishanth Menon <nm@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Yazan Shhady <yazan.shhady@solid-run.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>
Subject: Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
Date: Mon, 15 Jan 2024 11:21:01 +0100 [thread overview]
Message-ID: <a6a02c39-8c7a-41d6-b751-5a230ac7e785@linaro.org> (raw)
In-Reply-To: <2879689e-5a4e-4242-a23b-d2aa9f004b1d@solid-run.com>
On 15/01/2024 11:05, Josua Mayer wrote:
> Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
>
>> On 14/01/2024 15:16, Josua Mayer wrote:
>>> Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>>>
>>>>> + /* PRU Ethernet Controller */
>>>>> + icssg1_eth: icssg1-eth {
>>>> Node names should be generic.
>>> This name intentionally includes the name of the ip block within am64 soc
>>> providing software-defined ethernet controller through coprocessors TI call "pru".
>> Why? This intentionally should not include specific name.
> I understand. Which is why I imagined in the other reference had intentionally
> diverged from that rule.
>>
>> Also, wrap your emails at proper length so they will be manageable...
>>
>>>> See also an explanation and list of
>>>> examples (not exhaustive) in DT specification:
>>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>>>
>>>>
>>>>> + compatible = "ti,am642-icssg-prueth";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>>>>> +
>>>>> + sram = <&oc_sram>;
>>>>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>>>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>>>> +
>>>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>>>> + <2>,
>>>>> + <2>,
>>>>> + <2>, /* MII mode */
>>>>> + <2>,
>>>>> + <2>;
>>>>> +
>>>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>>>> +
>>>>> + interrupt-parent = <&icssg1_intc>;
>>>>> + interrupts = <24 0 2>, <25 1 3>;
>>>> None of these are typical interrupt constants/flags?
>>>>
>>>>> + interrupt-names = "tx_ts0", "tx_ts1";
>>>>> +
>>>>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>>>>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>>>>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>>>>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
>>>>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>>>>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>>>>> + "rx0", "rx1";
>>>>> +
>>>>> + status = "okay";
>>>> Drop. Didn't you get such comments before?
>>> Yes, but again I can point to an in-tree example of the same structure.
>>> I see no reason for describing the same thing differently in different places.
>> So if there is a bug, you are going to duplicate it.
> I was torn between making my own solution, and using recently
> added and topical (to my submission) code as template.
>>
>> Please provide real argument why this is needed, not "I saw it
>> somewhere", or drop it. Otherwise it's a NAK from me.
> I will attempt to improve the magic numbers in this whole node,
> and reconsider the node name. Thanks.
What magic numbers? My comment was under one specific line. There are no
numbers in status.
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-01-15 10:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
2024-01-12 17:12 ` [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
2024-01-12 17:12 ` [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml Josua Mayer
2024-01-12 17:18 ` Krzysztof Kozlowski
2024-01-14 15:56 ` Josua Mayer
2024-01-14 16:26 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:17 ` Josua Mayer
2024-01-15 10:20 ` Krzysztof Kozlowski
2024-01-12 17:12 ` [PATCH v2 3/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
2024-01-12 17:22 ` Krzysztof Kozlowski
2024-01-14 14:16 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:05 ` Josua Mayer
2024-01-15 10:21 ` Krzysztof Kozlowski [this message]
2024-01-15 10:32 ` Josua Mayer
2024-01-16 13:29 ` Josua Mayer
2024-01-12 17:50 ` Andrew Davis
2024-01-14 15:14 ` Josua Mayer
2024-01-12 17:12 ` [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer
2024-01-12 17:58 ` Andrew Davis
2024-01-14 15:25 ` Josua Mayer
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=a6a02c39-8c7a-41d6-b751-5a230ac7e785@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=josua@solid-run.com \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
--cc=yazan.shhady@solid-run.com \
/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: link
Be 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