Received: by 2002:a05:6520:3645:b029:c0:f950:43e0 with SMTP id l5csp6299791lki; Thu, 4 Mar 2021 09:33:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJymZ8VKIoT9vSeqptj/ronEVz4RiVWfJ/mHNIsd2UevWBXG8wcregp1R2a3lGFYINl2tBN0 X-Received: by 2002:aa7:c645:: with SMTP id z5mr5870379edr.126.1614879217944; Thu, 04 Mar 2021 09:33:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614879217; cv=none; d=google.com; s=arc-20160816; b=pCFYk3WJ5gnicqtoeNubPYOPrbIVANccsjk8UCd5IkgB6ET6Q0Kn68zB+v1ufnBwoq /wl40YcWUUHJ/dKj7PKp3/HMPwPk9Dm4dq9Wrr/d+l6vPUORkWKEbiXLXE2RMHAitaom Whyy1TZCTuNHCayqOXjahdl1+bY5Y1iRycvfigZwwB10RBseMiyjAOc33nrJ7n1ALPYJ 4g93aEISMaFpNe3P4FgKcpf6CLV4miHUAHYigH8KYJXhpjlCNHJj1faUqad4pFCnJQiL v1EA6UG6ezis4+t188a4bLg8LaXctJeVLQADxfDtGKIfzN0mCQKmmnqJ+7IAdWD9Cra2 cGaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=vckiuo5o0lbsf+iCp4TD+mlnrNoZKeBTtEoYHD3gcKU=; b=d8mJlAKuoyq1Eyt23Q513IY/zBFfrKZWJQc4kPh8+rSGgIBNjK/yBDh3/38gVN7fgM q20Vt6GJCoD0zcAq4hh4ePIfGIJukgnWM7VHgqZ3R5zPveM7JhesU/e7AeeAWWebtyPE HV8cSC++NreIMJc8C2n9kcA897tdp1JGSqU5i0RtMSZj99UGsKaQJXhOeKPzwiZ7cWZ4 A404xZEj04XWONpTeTy9RpQK7EVg+om7uKYIqWezDLj6efrantFCuTXY8kTkEDuxUxpD gjvKlc97C6HO/0RBTQx4UVgznt5v6p5IkH9A4e5FSSSO272WXayxpuv8QpUHotbUPqlu bPdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iROoJwYG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lh6si12076072ejb.613.2021.03.04.09.33.14; Thu, 04 Mar 2021 09:33:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iROoJwYG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241560AbhCDNtI (ORCPT + 99 others); Thu, 4 Mar 2021 08:49:08 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:58862 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241538AbhCDNtF (ORCPT ); Thu, 4 Mar 2021 08:49:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614865660; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vckiuo5o0lbsf+iCp4TD+mlnrNoZKeBTtEoYHD3gcKU=; b=iROoJwYGXbQuylKgDZkOvEZYeaGf+zO9eL9e9i6dYvPHyOFdk0SOwExoANu7lPtfgJTcNg RXEtbrCy3EsqTDQ17Bzob+HWImDejXdAFXq94A5lB5wRG4vLs0HRNMUx2wkHyngKqa8vUq gdTmvL2xdD77luvxIqi72vYR13gwUIg= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429-rCl8BRpOOiWy_rwcwZG4xA-1; Thu, 04 Mar 2021 08:47:38 -0500 X-MC-Unique: rCl8BRpOOiWy_rwcwZG4xA-1 Received: by mail-ej1-f69.google.com with SMTP id gv58so5916870ejc.6 for ; Thu, 04 Mar 2021 05:47:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vckiuo5o0lbsf+iCp4TD+mlnrNoZKeBTtEoYHD3gcKU=; b=ugvLsaSsdrsQJsjx2tgu8XHP1fIg2ZlBk7OFJI4J0kpDYvh0tHxV3V9aHtiZ4Vt0Cg oyJ/cC3a1sA8EQdvqw0DgGpep0Paz+bOlVXxfCUIo0PuleAOO/N0wBSmaagKQNynhKlT MlNjjaQh203T5KzTASUFLV3B+zQLhPYgTIu/pTYGxsqbnXTWJBRKNpge32tG5lJfwtA6 vX+a8WDg+t1xIdBYcwXSQfEIQ0Y8AcvEkrAAleax2EXXePFUWEFflvkIycUiDsV26nap 7Uxaldo3Y9Uk+XDH0lJASy+FBNC+eB1NO4q+tRhNkpeTj8nnR0SiRYng0IMeQMk/ae6v K0hw== X-Gm-Message-State: AOAM531wPsYmVFL55YIlKy7ZblzTUnx6nFYLLokHAPh18M0B37Uadg3n kl+UUPXDlnWiKMTCisl2ATka+/v9kBaqW1PnwzoEAihd5UJLdzku9uuYQ1sHAgIeB8n5tGm6ZNj t3YK8qm31M449buptcvQtgz56 X-Received: by 2002:aa7:c450:: with SMTP id n16mr4333424edr.16.1614865657198; Thu, 04 Mar 2021 05:47:37 -0800 (PST) X-Received: by 2002:aa7:c450:: with SMTP id n16mr4333397edr.16.1614865656987; Thu, 04 Mar 2021 05:47:36 -0800 (PST) Received: from x1.localdomain (2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:1054:9d19:e0f0:8214]) by smtp.gmail.com with ESMTPSA id ld19sm1373084ejb.102.2021.03.04.05.47.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Mar 2021 05:47:36 -0800 (PST) Subject: Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices To: Andy Shevchenko , Henning Schild Cc: Linux Kernel Mailing List , Linux LED Subsystem , Platform Driver , linux-watchdog@vger.kernel.org, Srikanth Krishnakar , Jan Kiszka , Gerd Haeussler , Guenter Roeck , Wim Van Sebroeck , Mark Gross , Pavel Machek References: <20210302163309.25528-1-henning.schild@siemens.com> <20210302163309.25528-2-henning.schild@siemens.com> From: Hans de Goede Message-ID: <2fad304a-9e1e-c83d-7a9e-02b35ed22418@redhat.com> Date: Thu, 4 Mar 2021 14:47:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 3/4/21 11:11 AM, Andy Shevchenko wrote: > On Thu, Mar 4, 2021 at 8:36 AM Henning Schild > wrote: >> >> From: Henning Schild >> >> This mainly implements detection of these devices and will allow >> secondary drivers to work on such machines. >> >> The identification is DMI-based with a vendor specific way to tell them >> apart in a reliable way. >> >> Drivers for LEDs and Watchdogs will follow to make use of that platform >> detection. > >> Signed-off-by: Gerd Haeussler >> Signed-off-by: Henning Schild > > The order is wrong taking into account the From line in the body. So, > it's not clear who is the author, who is a co-developer, and who is > the committer (one person may utilize few roles). > Check for the rest of the series as well (basically this is the rule > of thumb to recheck entire code for the comment you have got at any > single place of it). > > ... > >> +config SIEMENS_SIMATIC_IPC >> + tristate "Siemens Simatic IPC Class driver" >> + depends on PCI >> + help >> + This Simatic IPC class driver is the central of several drivers. It >> + is mainly used for system identification, after which drivers in other >> + classes will take care of driving specifics of those machines. >> + i.e. leds and watchdogs > > LEDs > watchdog. (missed period and singular form) > > Module name? > >> endif # X86_PLATFORM_DEVICES > > Not sure about the ordering of the section in Kconfig, but it is up to > maintainers. > > ... > >> +# Siemens Simatic Industrial PCs >> +obj-$(CONFIG_SIEMENS_SIMATIC_IPC) += simatic-ipc.o > > Ditto. > > ... > >> + * Siemens SIMATIC IPC driver for LEDs > > It seems to be used in patch 4 which is not LED related. Also, why is > it here if it's for LEDs? > > ... > >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. > > Replace with SPDX > > ... > >> +#include >> +#include >> +#include > > Ordered? > >> +#include > > ... > >> +static int register_platform_devices(u32 station_id) >> +{ >> + int i; >> + u8 ledmode = SIMATIC_IPC_DEVICE_NONE; >> + u8 wdtmode = SIMATIC_IPC_DEVICE_NONE; > > Reversed xmas tree order? > >> + platform_data.devmode = SIMATIC_IPC_DEVICE_NONE; >> + >> + for (i = 0; i < ARRAY_SIZE(device_modes); i++) { >> + if (device_modes[i].station_id == station_id) { >> + ledmode = device_modes[i].led_mode; >> + wdtmode = device_modes[i].wdt_mode; >> + break; >> + } >> + } >> + >> + if (ledmode != SIMATIC_IPC_DEVICE_NONE) { >> + platform_data.devmode = ledmode; > >> + ipc_led_platform_device = platform_device_register_data >> + (NULL, KBUILD_MODNAME "_leds", PLATFORM_DEVID_NONE, >> + &platform_data, sizeof(struct simatic_ipc_platform)); > > Strange indentation (second line). > >> + if (IS_ERR(ipc_led_platform_device)) >> + return PTR_ERR(ipc_led_platform_device); > >> + pr_debug(KBUILD_MODNAME ": device=%s created\n", >> + ipc_led_platform_device->name); > > Utilize pr_fmt() instead of adding prefixes like this. > >> + } > >> + if (wdtmode != SIMATIC_IPC_DEVICE_NONE) { >> + platform_data.devmode = wdtmode; >> + ipc_wdt_platform_device = platform_device_register_data >> + (NULL, KBUILD_MODNAME "_wdt", PLATFORM_DEVID_NONE, >> + &platform_data, sizeof(struct simatic_ipc_platform)); >> + if (IS_ERR(ipc_wdt_platform_device)) >> + return PTR_ERR(ipc_wdt_platform_device); >> + >> + pr_debug(KBUILD_MODNAME ": device=%s created\n", >> + ipc_wdt_platform_device->name); >> + } > > Same comments as above. > >> + if (ledmode == SIMATIC_IPC_DEVICE_NONE && >> + wdtmode == SIMATIC_IPC_DEVICE_NONE) { >> + pr_warn(KBUILD_MODNAME >> + ": unsupported IPC detected, station id=%08x\n", >> + station_id); > > Ugly indentation. With pr_fmt() in use will be much better. > >> + return -EINVAL; > >> + } else { > > Redundant. > >> + return 0; >> + } >> +} > > ... > >> +/* >> + * Get membase address from PCI, used in leds and wdt modul. Here we read >> + * the bar0. The final address calculation is done in the appropriate modules > > bar -> BAR > Missed period. > >> + */ > >> + > > Unneeded blank line. > >> +u32 simatic_ipc_get_membase0(unsigned int p2sb) >> +{ >> + u32 bar0 = 0; > >> +#ifdef CONFIG_PCI > > It's ugly besides the fact that you have a dependency. > >> + struct pci_bus *bus; > > Missed blank line. > >> + /* >> + * The GPIO memory is bar0 of the hidden P2SB device. Unhide the device >> + * to have a quick look at it, before we hide it again. >> + * Also grab the pci rescan lock so that device does not get discovered >> + * and remapped while it is visible. >> + * This code is inspired by drivers/mfd/lpc_ich.c >> + */ >> + bus = pci_find_bus(0, 0); >> + pci_lock_rescan_remove(); >> + pci_bus_write_config_byte(bus, p2sb, 0xE1, 0x0); >> + pci_bus_read_config_dword(bus, p2sb, PCI_BASE_ADDRESS_0, &bar0); >> + >> + bar0 &= ~0xf; >> + pci_bus_write_config_byte(bus, p2sb, 0xE1, 0x1); >> + pci_unlock_rescan_remove(); >> +#endif /* CONFIG_PCI */ >> + return bar0; >> +} >> +EXPORT_SYMBOL(simatic_ipc_get_membase0); > > Oy vey! I know what this is and let's do it differently. I have some > (relatively old) patch series I can send you privately for testing. This bit stood out the most to me too, it would be good if we can this fixed in some cleaner work. So I'm curious how things will look with Andy's work integrated. Also I don't think this should be exported. Instead this (or its replacement) should be used to get the address for an IOMEM resource to add the platform devices when they are instantiated. Then the platform-dev drivers can just use the regular functions to get their resources instead of relying on this module. Regards, Hans > > ... > >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. > > Not needed when you have SPDX. > > ... > >> +#include > > Wrong header. Should be types.h > > ... > >> +#include >> +#include > > Missed headers. You need to include ones that the code below is a > direct user of. > > Like types.h >