Date:   Wed, 11 Oct 2023 12:08:57 +0800
From:   Wenkai <advantech.susiteam@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
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



Guenter Roeck 於 10/6/2023 10:16 PM 寫道:
> On Fri, Oct 06, 2023 at 05:27:48PM +0800, Wenkai wrote:
>>
>> Guenter Roeck 於 10/6/2023 11:02 AM 寫道:
>>> On Thu, Oct 05, 2023 at 04:51:18PM +0800, advantech.susiteam@...il.com wrote:
>>>> From: Wenkai <advantech.susiteam@...il.com>
>>>>
>>>> This patch series aims to add support for the Advantech EIO-IS200
>>>> Embedded Controller's watchdog timer to the Linux kernel. The EIO-IS200
>>>> is a widely used embedded controller, and this series introduces a
>>>> native driver for its watchdog timer functionality within the Linux
>>>> ecosystem.
>>>>
>>> I am not going to review this patch series. This is just ne watchdog driver.
>>> One patch is sufficient.
>>>
>>> Guenter
>> Hi Guenter,
>>
>> Advantech's EIO-IS200 watchdog supports 5 output pins: RESET, Power
>> Button, SCI, IRQ, and GPIO. The most traditional scenario is that the
>> Pretimeout triggers IRQ, and the timeout triggers RESET.
>>
>> However, unfortunately, for industrial usages, there are various use
>> cases, which require certain mechanisms and logic to manage which signal
>> is output when Pretimeout and timeout expire. I am concerned that
>> consolidating all these features into a single patch for upstream may
>> lead to confusion and make the source code less readable and
>> understandable.
>>
> The 1st patch in your series doesn't even compile. I don't call that
> understandable.
>
> Oh, it fails to compile because you include a non-existing file from
> ../mfd directly and because you select a non-existing configuration option
> instead of depending on it.
>
> None of those is even remotely acceptable. Are you seriously sending me
> a series of patches that don't even build to review ?

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?
>> Therefore, I have divided the implementation into 5 separate patches,
>> aiming to make the code more comprehensible and acceptable. If it's
>> acceptable to you, I am more than willing to provide a single patch as
>> per your preference.
>>
> Frankly, your series is one more nail in the coffin. I am now seriously
> considering to resign as co-maintainer of the watchdog subsystem.
>
> Guenter

I also appreciate your patience, dedication, and valuable contributions
to the Linux community. Your longstanding efforts and expertise are
commendable and have been instrumental in advancing the Linux ecosystem.
I understand that upstream review can be a meticulous and vital, albeit
thankless, task. I don't want my actions to cause any inconvenience or
distress, especially to someone as esteemed as you are in the Linux
community. Your insights and guidance are incredibly valuable to all of
us.

Once again, thank you for your understanding, and I am committed to
delivering high-quality code for your review.

Best regards,
Wenkai

Powered by blists - more mailing lists