lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6348ae7e-21f3-51ef-e60a-b3ceccc38be4@gmail.com>
Date:   Thu, 12 Oct 2023 15:56:52 +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/11/2023 11:05 PM 寫道:
> 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.

The LKML link is https://lkml.org/lkml/2023/9/6/1245. Is this link to 
the patch
sufficient?

And, I'll move the "eiois200.h" to "include/linux/mfd/".

> 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

Unfortunately, all sub-drivers mostly communicate with the EC firmware
through the MFD core driver's driver-driver API, only a few uses regmap.
So should the MFD core driver and its sub-drivers be reviewed by the same
maintainers?

Best regards,
Wenkai


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ