[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <655945a4-fc45-4d01-954b-88aa6fb7231f@roeck-us.net>
Date: Wed, 11 Oct 2023 08:05:03 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Wenkai <advantech.susiteam@...il.com>
Cc: wenkai.chung@...antech.com.tw, Susi.Driver@...antech.com,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [PATCH 0/5] watchdog: eiois200_wdt: Add EIO-IS200 Watchdog Driver
On Wed, Oct 11, 2023 at 12:08:57PM +0800, Wenkai wrote:
>
> I understand that the patches don't meet the expected quality standards.
> The compile issue is due to my MFD core driver, which is currently under
> review and has not been merged yet.
>
> I would also like to seek your advice on how to best proceed with the
> sub-drivers like the watchdog driver. Should I wait for my core MFD
> driver to be successfully merged before submitting the sub-drivers, or
> let Jones Lee review my core MFD driver and all its sub-drivers, or is
> there another approach that you recommend?
If the sub-drivers depend on the mfd driver, at least provide a reference
to the patch or patch series introducing that driver. Either case, a direct
include from "../mfd" is simply unacceptable. include/linux/mfd/ does exist
for a reason, after all.
I don't know the best solution for reviewing all the drivers. I didn't
(and do not plan to) look into the driver-driver API. If the interface
is regmap, reviewing sub-drivers on their own should be straightforward.
If the API is with function calls, things get more complicated because
the API needs the sub-drivers to be tested and everything needs to be
reviewed together.
Guenter
Powered by blists - more mailing lists