Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3688155yba; Mon, 29 Apr 2019 06:58:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqycoh5ZwpYgt/33IRAkdDMqWu1x/GVJdOkbcDH6RcmL6D8xS1qK1YpJGMJNIukwStsDkAsU X-Received: by 2002:aa7:810e:: with SMTP id b14mr19610974pfi.112.1556546320409; Mon, 29 Apr 2019 06:58:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556546320; cv=none; d=google.com; s=arc-20160816; b=mWPnSDU8TolXpevBveN8/SWb4cJ7iYgSb1sMhbJMSnWvXoUAy7vdu4BFxZFSDvS4xJ PKRQ2F+0XIRCT4SVv42B/FPwHv++QRTmeCHSE4hpR4+IHc6zruw2fqj3gO8viP49GoWb vo16oPgJD0fLnGUFYQ2e3NaKg3qWtq6DqjM7PO4iIgHDdzjtyp9GBQTr5v00UIaznnpN za9/zZCo9USuTJEzlEq/tzlX6RqqIVFq9H+ynIVg3IId+JfhnpcAR/X5wZIOJJIWAB2H MUUrAb9GrrU/nNkv+m157lYpBoraWin1NfSC88YMKURpmwhfDEmOEGtPAGX0hUiBczO/ 1Gmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=OwUQ71sKeAgpilNKEgTN9DuCOYLTriyiBnyygrWANpM=; b=QYrlF6bq1SfC9QHTofZaIat6wzQaUjn1nFxA/+JHNFhnVfIKgpXetYexpu1XLkbQZF JbyFpXzvuZNVjJAIJHT0wizQu9v1Q3SFqsUR7936A4J2Vw+ZXEx0uWcSpghQDx0CHfth Dt+laYH0jMqiZLlvNRxIqRLkZjP2oROaJ7Ks0Sz01fQjlNqDc1ye6PQihp0voy6815/N GYAwEBY5kHl17eWFf8RyFc9R98BZCK9Av228BJgjLtKkIy1t0M5DNk7Ikre1gyKq4F7x jDTDDexDYObwWj9dRcEsQ6GP9gdz9TtSAVEnp7g8Uz9zTIU+bmz1yOjqa0ucELLaVhuP QZ0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q1si26774899pgd.223.2019.04.29.06.58.24; Mon, 29 Apr 2019 06:58:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728271AbfD2Nz7 (ORCPT + 99 others); Mon, 29 Apr 2019 09:55:59 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:37433 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725838AbfD2Nz6 (ORCPT ); Mon, 29 Apr 2019 09:55:58 -0400 Received: from [192.168.1.110] ([77.9.18.117]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MwPjf-1gT9H42mKz-00sLKc; Mon, 29 Apr 2019 15:54:35 +0200 Subject: Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card To: Sven Van Asbroeck , Oliver Hartkopp Cc: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Linus Walleij , Lee Jones , mark.rutland@arm.com, treding@nvidia.com, David Lechner , noralf@tronnes.org, johan@kernel.org, Michal Simek , michal.vokac@ysoft.com, Arnd Bergmann , Greg KH , john.garry@huawei.com, geert+renesas@glider.be, robin.murphy@arm.com, Paul Gortmaker , sebastien.bourdelin@savoirfairelinux.com, icenowy@aosc.io, Stuart Yoder , "J. Kiszka" , maxime.ripard@bootlin.com, Linux Kernel Mailing List , netdev References: <20190409144250.7237-1-TheSven73@gmail.com> <982e69c6-4e68-6f62-8bed-cd5a1802272b@metux.net> <23a25601-ed98-5348-9bac-bf8fc2baea5e@metux.net> <7ceaeb70-f937-bd84-95e5-d7a6baeb5d87@metux.net> <06024a8a-ad00-8062-215b-01b2f95a6e24@hartkopp.net> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: <2bed794d-4960-df09-df16-e063cc41eaae@metux.net> Date: Mon, 29 Apr 2019 15:54:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:XKZ+U9p2e+DR5HEHnRD3a5YgCyikZoBUmNnTjxGi9hDiE/mOW05 MWW8x9pjhr0I3vtT2M9L+ZdxFYT2ydXVisV1SSZ4hu9gz4ovnbPz1NTvo5JQXim7xMcH7tP 6Od4jzmaMi36swtR+Wdrmha4aSlss0Dfv9o+1HZuyWDeK9Fz9UhWkTft5ncMplULHCuAgla lrqMyJPjIzrg+38RmVIfA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:YGZf1uj3/6I=:uILxPV5x+bGgNNEKC7e4j3 ZRnzQN+YTtXwsHoDQMyaNWvu6Jm7U6Qcha21dg/ejOZ71z2RNiORCtPH1g+emerxdEwWlWC4v NJUVRdpmXdaLcpHejA/Z9q0bjPLg0EGzJXtPjCkgGdQd7ZUp3i7s6OcI+QCZ2IjXVzsFSi4cE TmEIqfQagpIzOJ7bf2j7RimRZXupWLauRVEoTaEx7TgoUI8iskH3gf93pfdDVbJBTRs5bZhci ch31pjCpbIcoHExjCYiqFoQJ78lPhME0GbbKsfurukisZqmem9FdEC15H8Et68fC1yYuwLjms L7tRPSfDyMBZcOnig8r1HdMyoMVz66tBunZi/cWtCNc7WO5l/NyCLVugUVXxUyVAG6n0jc2Cz Y2k1p3aHTRiABAPzLC/yL4uZHDTRDE2FD75HqlklkPSk279L2bISEYkMRGHSug7NJd/yQ2fDs 2dKUHCjIZrGbtQnAujSvjQ3pRvstKFZ3Y6t5To45/MvG3RwhK0zfdSzISNVZnFJ63PnV+8im5 sEfUC21/QW4Pg/y1lyKCQ3micL1i4PTJJz8OkBFcmMdzzuf6AiR3Jc8QkFIxuBT64PrzEC0ZP /KbTFQOI7ZuUa1GmQZvQN4UUitAS7JxFwcudbo2NV2LSBoQu9hy3Z3WWuNJwD3Ki3OFoe6zeI Xm/xlbRLcs8VhaKrrGsDeD+kVcjSyKZAmFR04lBir4zLsbSATgJmeL6LPOiMWPJL9Vmo+LiYW WnIOZoTymEHcEagvuhA2+r973IIV3lfRv9SZZ8h1cqtsiZ/0XtHRbM3onu8= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24.04.19 17:10, Sven Van Asbroeck wrote: > The subsystem is called fieldbus_dev "fieldbus device" because it> abstracts Linux fieldbus clients that want to expose themselves as> e.g. an actuator, motor, console light, switch, ... Sounds a bit confusing. With that description, I'd expect highlevel interfaces similar to LED, input, IIO, etc ... but you're actually implementing an distributed process memory system. This in turn is just a subset of the fieldbus world. > During one of the eleven review cycles, drivers/fieldbus_dev got> truncated to drivers/fieldbus because the reviewers felt that> _dev was redundant, given the lack of other fieldbus> subsystems. There is at least one: CAN. Sometimes CAN is used in the IEC61158-way, but also completely different, even both in combination. > These cards are not controllers, but slaves on the bus. Do they really implement the process memory part or just the lower layer communications ? > I'm by no means a fieldbus expert. It seems that the term> 'fieldbus' is much broader than these process-memory based> standards? Yes, indeed. > I am open to any _concrete_ naming suggestion > that can get consensus. Maybe IEC61158 ? > I'm a bit confused by Wikipedia's entry for fieldbus. > It suggests that IEC 61158 and Fieldbus are > interchangeable? > https://en.wikipedia.org/wiki/Fieldbus That's wrong. > > Fieldbus is the name of a family of industrial computer > network protocols used for real-time distributed control, > standardized as IEC 61158. > IEC 61158 only standardizes one particular approach: the distributed process memory. > Given that CAN/EtherCAT are not process memory based > (that I know of), the fieldbus_dev subsystem is probably > not a good fit. ACK. Neither are MVB+friends. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287