From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C23AAC433EF for ; Fri, 26 Nov 2021 13:21:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233254AbhKZNYQ (ORCPT ); Fri, 26 Nov 2021 08:24:16 -0500 Received: from gecko.sbs.de ([194.138.37.40]:53534 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232058AbhKZNWQ (ORCPT ); Fri, 26 Nov 2021 08:22:16 -0500 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 1AQDIGi1027289 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Nov 2021 14:18:16 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.47.90]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1AQDIF6d021653; Fri, 26 Nov 2021 14:18:15 +0100 Date: Fri, 26 Nov 2021 14:18:14 +0100 From: Henning Schild To: Guenter Roeck Cc: Andy Shevchenko , "Enrico Weigelt, metux IT consult" , Linux Kernel Mailing List , Linux LED Subsystem , Platform Driver , linux-watchdog@vger.kernel.org, Srikanth Krishnakar , Jan Kiszka , Gerd Haeussler , Wim Van Sebroeck , Mark Gross , Hans de Goede , Pavel Machek Subject: Re: [PATCH v3 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs Message-ID: <20211126141814.044c27ec@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20210329174928.18816-1-henning.schild@siemens.com> <20210329174928.18816-4-henning.schild@siemens.com> <20210406165247.78791bf7@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org Am Wed, 7 Apr 2021 05:17:12 -0700 schrieb Guenter Roeck : > On 4/7/21 1:53 AM, Andy Shevchenko wrote: > > On Tue, Apr 6, 2021 at 5:56 PM Henning Schild > > wrote: > >> > >> Am Thu, 1 Apr 2021 18:15:41 +0200 > >> schrieb "Enrico Weigelt, metux IT consult" : > >> > >>> On 29.03.21 19:49, Henning Schild wrote: > >>> > >>> Hi, > >>> > >>>> This driver adds initial support for several devices from > >>>> Siemens. It is based on a platform driver introduced in an > >>>> earlier commit. > >>> > >>> Where does the wdt actually come from ? > >>> > >>> Is it in the SoC ? (which SoC exactly). SoC-builtin wdt is a > >>> pretty usual case. > >>> > >>> Or some external chip ? > >> > >> I guess external chip, but again we are talking about multiple > >> machines. And the manuals i read so far do not go into that sort of > >> detail. In fact on some of the machines you will have two > >> watchdogs, one from the SoC and that "special" one. > >> That has several reasons, probably not too important here. The HW > >> guys are adding another wd not just for fun, and it would be nice > >> to have a driver. > >> > >>> The code smells a bit like two entirely different wdt's that just > >>> have some similarities. If that's the case, I'd rather split it > >>> into two separate drivers and let the parent driver (board file) > >>> instantiate the correct one. > >> > >> Yes, it is two. Just like for the LEDs. One version PIO-based > >> another version gpio/p2sb/mmio based. > > > > I tend to agree with Enrico that this should be two separate > > drivers. > > Agreed. > > Guenter I will ignore the wish for a split in v4. Reason is that it would cause a lot of duplication are spreading code over many files. like i.e. a -common.c Internally we have that driver in fact already support a few more machines, which could call a split at some point. Or could also upset people of the many CONFIG_ knobs and files as we keep pushing machine support forward in the upstream drivers. But i would like to discuss that in patch qs coming after a merge and not split (maybe not yet). Also splitting wdt and having leds in one file would be inconsistent. So when there will be a split it should be on both ends. But please allow me to postpone that. regards, Henning > >> In fact the latter should very likely be based on that gpio pinctl, > >> whether it really needs to be a separate driver will have to be > >> seen. There are probably pros and cons for both options. > > > > >