From: Krzysztof Kozlowski <krzk@kernel.org>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
Guenter Roeck <linux@roeck-us.net>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
"biju.das.au" <biju.das.au@gmail.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 3/5] watchdog: Make RZV2HWDT driver depend on ARCH_R9A09G47
Date: Fri, 24 Jan 2025 14:20:02 +0100 [thread overview]
Message-ID: <80bedf6c-ff2b-45e4-93e1-a05f4d3416ec@kernel.org> (raw)
In-Reply-To: <TY3PR01MB1134676CABA2ACBA48395491086E32@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On 24/01/2025 14:10, Biju Das wrote:
>>>> Rather tell me why this is supposed to be different than other vendors?
>>>
>>> It is not different from other vendors.
>>>
>>> See, for eg:
>>> config S3C2410_WATCHDOG
>>> 557 tristate "S3C6410/S5Pv210/Exynos Watchdog"
>>> 558 depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
>>
>> You see - only one ARCH_EXYNOS.
>>
>> That's the arch and vendor. Exynos is the entire arch for arm32 and
>> arm64 consisting of all of SoCs.
>
> In Renesas case it is ARCH_RENESAS.
So that's your dependency. Said in this thread long time ago.
>
>>
>> S3C and S5P are entirely different, much older archs - these even could not be combined in one image
>> with Exynos some time ago.
>>
>>>
>>>
>>> 575 config SA1100_WATCHDOG
>>> 576 tristate "SA1100/PXA2xx watchdog"
>>> 577 depends on ARCH_SA1100 || ARCH_PXA || COMPILE_TEST
>>>
>>> and many more.
>>
>> Again: only one SA1100, one PXA. Not per each PXA SoC.
>>
>> So these prove my point - use only your ARCH
>>>
>>>
>>>>
>>>> || ARM64 is already used solution
>>>
>>> If you are correct, then all should depend on either on ARM or ARM64 or RISCV etc...
>>>
>>>
>>>>
>>>>>
>>>>> Since most of IP's in RZ/V2H and RZ/G3E are identical we could
>>>>> introduce a new family SoC ARCH_RZG3E_RZV2H to cover both or top level ARCH_RENESAS??
>>>>
>>>> You should not write drivers per SoCs (or even two or there SoCs) and
>>>> there is really no need to restrict them per each SoC.
>>>
>>> If I am not wrong, The watchdog subsystem uses similar approach.
>>>
>>>>
>>>> Otherwise come with arguments to my first question: why do you need
>>>> exception here from generic kernel approach?
>>>
>>> It is not deviating from generic kernel approach as lot of vendors are doing this way.
>>> eg:
>>>
>>> config OMAP_WATCHDOG
>>> tristate "OMAP Watchdog"
>>> depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || COMPILE_TEST
>>
>> Anyway, that's ancient OMAP, we speak about new devices.
>>
>>>
>>>
>>> config DAVINCI_WATCHDOG
>>> tristate "DaVinci watchdog"
>>> depends on ARCH_DAVINCI || ARCH_KEYSTONE || COMPILE_TEST
>>
>> Different ARCH, not SoCs!
>>
>>>
>>>
>>> config K3_RTI_WATCHDOG
>>> tristate "Texas Instruments K3 RTI watchdog"
>>> depends on ARCH_K3 || COMPILE_TEST
>>
>> Dependency on ARCH.
>>
>> Do you understand the difference between ARCH and SoC (ARCH_R9A09G47 is the SoC - individual or
>> family)?
>
> ARCH_R9A09G47 --> Is a SoC (RZ/G3E)
> ARCH_R9A09G57 --> Is a SoC (RZ/V2H)
>
> 90%of IP between these SoCs are same. So can't this belongs to same family of SoCs(eg: ARCH_RZ_G3E_V2H family)?
We do not discuss what these SoCs belong to. How does it matter if you
create ARCH_RZ_ONE_TWO_THREE_SOCS? Your dependency is ARCH, so unified
kernel image will be easier to create. This is not helping in unified
image and Greg was talking about this *multiple times*.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-01-24 13:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 10:38 [PATCH 0/5] Add support for RZ/G3E WDT Biju Das
2025-01-15 10:38 ` [PATCH 1/5] dt-bindings: watchdog: renesas,wdt: Document RZ/G3E support Biju Das
2025-01-18 15:51 ` Krzysztof Kozlowski
2025-01-23 10:15 ` Geert Uytterhoeven
2025-01-15 10:38 ` [PATCH 2/5] clk: renesas: r9a09g047: Add WDT clocks/resets Biju Das
2025-01-23 10:15 ` Geert Uytterhoeven
2025-01-15 10:38 ` [PATCH 3/5] watchdog: Make RZV2HWDT driver depend on ARCH_R9A09G47 Biju Das
2025-01-15 14:55 ` Guenter Roeck
2025-01-15 17:17 ` Biju Das
2025-01-18 15:51 ` Krzysztof Kozlowski
2025-01-24 10:20 ` Biju Das
2025-01-24 10:34 ` Krzysztof Kozlowski
2025-01-24 10:57 ` Biju Das
2025-01-24 12:41 ` Krzysztof Kozlowski
2025-01-24 12:55 ` Biju Das
2025-01-24 13:00 ` Krzysztof Kozlowski
2025-01-24 13:10 ` Biju Das
2025-01-24 13:20 ` Krzysztof Kozlowski [this message]
2025-01-24 13:24 ` Biju Das
2025-01-24 13:40 ` Krzysztof Kozlowski
2025-01-24 13:51 ` Biju Das
2025-01-24 13:56 ` Geert Uytterhoeven
2025-01-15 10:38 ` [PATCH 4/5] arm64: dts: renesas: r9a09g047: Add WDT1-WDT3 nodes Biju Das
2025-01-23 10:15 ` Geert Uytterhoeven
2025-01-15 10:38 ` [PATCH 5/5] arm64: dts: renesas: r9a09g047e57-smarc: Enable watchdog Biju Das
2025-01-15 17:19 ` Biju Das
2025-01-23 10:17 ` Geert Uytterhoeven
2025-01-23 10:23 ` Biju Das
2025-01-19 14:28 ` [PATCH 0/5] Add support for RZ/G3E WDT Tommaso Merciai
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=80bedf6c-ff2b-45e4-93e1-a05f4d3416ec@kernel.org \
--to=krzk@kernel.org \
--cc=biju.das.au@gmail.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=geert+renesas@glider.be \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=wim@linux-watchdog.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.