All of lore.kernel.org
 help / color / mirror / Atom feed
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:00:14 +0100	[thread overview]
Message-ID: <8bdb2cdf-92cd-46e8-b795-7d5d412a4e07@kernel.org> (raw)
In-Reply-To: <TY3PR01MB11346BADEA961847B84D911E986E32@TY3PR01MB11346.jpnprd01.prod.outlook.com>

On 24/01/2025 13:55, Biju Das wrote:
> Hi Krzysztof Kozlowski,
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: 24 January 2025 12:42
>> Subject: Re: [PATCH 3/5] watchdog: Make RZV2HWDT driver depend on ARCH_R9A09G47
>>
>> On 24/01/2025 11:57, Biju Das wrote:
>>> Hi Krzysztof Kozlowski,
>>>
>>>> -----Original Message-----
>>>> From: Krzysztof Kozlowski <krzk@kernel.org>
>>>> Sent: 24 January 2025 10:35
>>>> Subject: Re: [PATCH 3/5] watchdog: Make RZV2HWDT driver depend on
>>>> ARCH_R9A09G47
>>>>
>>>> On 24/01/2025 11:20, Biju Das wrote:
>>>>>>
>>>>>>> +	depends on ARCH_R9A09G047 || ARCH_R9A09G057 || COMPILE_TEST
>>>>>>
>>>>>> But this is just wrong. You are supposed to depend on renesas ARHC,
>>>>>> not your individual SoC (and this is what you called here "ARCH_R9A...").
>>>>>>
>>>>>> Greg many times gave strong opinion that even full ARCH is wrong
>>>>>> and we managed to convince him that it has a meaning (or he did not
>>>>>> want to keep discussing). But restricting it per soc is pointless
>>>>>> and impossible to defend in
>>>> discussion.
>>>>>
>>>>> Currently for building RZ/G3E WDT, I need to always have RZ/V2H SoC config.
>>>>> which is pointless. May be ARCH_RENESAS should ok in this case??
>>>> Assuming ARCH_RENESAS covers your individual SoCs above, yes, that's
>>>> the way for driver to limit themselves to usable family.
>>>
>>> ARCH_RENESAS has ARM, ARM64 and RISC based SoCs.
>>>
>>> Currently it covers ARCH_RCAR_GEN1, ARCH_RCAR_GEN2,  ARCH_RCAR_GEN3,
>>> ARCH_RCAR_GEN4, ARCH_RMOBILE, ARCH_RZG2L, ARCH_RZN1 Family SOCs and
>>> rest of the individual SoCs such as RZ/V2H abnd RZ/g3E.
>>
>>
>> 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.

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)?



Best regards,
Krzysztof

  reply	other threads:[~2025-01-24 13:00 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 [this message]
2025-01-24 13:10                 ` Biju Das
2025-01-24 13:20                   ` Krzysztof Kozlowski
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=8bdb2cdf-92cd-46e8-b795-7d5d412a4e07@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.