Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4518917yba; Wed, 17 Apr 2019 13:16:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxIfTrOHQ+GvD+qu2U9IWpSB35sTl/8JoNLoG2Bva3Q/BbD3PhkapVBqubXfXZrjtFKBfm0 X-Received: by 2002:a63:2a8f:: with SMTP id q137mr82943883pgq.31.1555532213004; Wed, 17 Apr 2019 13:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555532212; cv=none; d=google.com; s=arc-20160816; b=ROQ755GUsGLhLx1P9LDgMF3N78ro0pRoLxAujSMact2vKoi0rDruZ0yr/LIcaXGYmF Q3xb93U3T3cOXkWo6PuXt6kzW+k+TOJEmR4sc1p+336nUB8DQaCu7EAeJwFEeRdhZPi5 Gz5ms8GQt379j0X6VVJSCH6lRw7MpAxchjNTD8JAQHtDVpnWOe9G+70IVSUQPYKbMGbu kJML4pqJzi56h+OhFDqjx+yMXZglu2NomPwdhREyBo7fPliCUpVFp7YIshekTf51ufaP dDKZgxl2WikS1NIH9Kt1QKhX8I/tZbPYwX71Cl2g+uX3SFJeaj2i6AHQpGWBbg4hUajU KDKA== 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=kfnMntbzy0M9uFLs2hBBOTxlK7L1qqSvFtWogjNcSFw=; b=CsdfR/igueGpcZwGpMF+iE7hrRgkDDs0/t3Uh4Gz90Gjx6YnemgzIqDZzdQAWWQdNv /Re7EEM8fSC0tkiSVnpJ0z/K9S7Vr05ywDM4e/G4hf05SX8CHb260mkyng9BOEY0uCIL qBOLQAOQIHFO7IAaDI3YJm3S/eDRFnZhUaCZuQfQNdv0fwD4nel+SP53SwJZp2GZgjs0 D3hxevTs/AhX0yIoWnjrGQOPZqj504DIofyaN8WVeAdLEVHLhINwz3H9d8f7J1VbMKvc AoZwKlXlf9PUDYpmeQqo+4bqwW7+3pHWhn6qsQMMwF32fV9SuQnRqRpyTavdb4iaGyzQ NIPQ== 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 15si2459619pgt.505.2019.04.17.13.16.38; Wed, 17 Apr 2019 13:16:52 -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 S1731305AbfDQUPc (ORCPT + 99 others); Wed, 17 Apr 2019 16:15:32 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:58953 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725848AbfDQUPb (ORCPT ); Wed, 17 Apr 2019 16:15:31 -0400 Received: from [192.168.1.110] ([95.117.89.119]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1Md6V3-1ggh712z2Z-00aBmZ; Wed, 17 Apr 2019 22:14:04 +0200 Subject: Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card To: =?UTF-8?Q?Andreas_F=c3=a4rber?= Cc: Sven Van Asbroeck , Rob Herring , 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> <31245f21-ae98-f10f-9484-a1719164ce16@suse.de> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: <293d9421-4a1c-cc12-f3a7-3f6ea3adb6ea@metux.net> Date: Wed, 17 Apr 2019 22:13:59 +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: <31245f21-ae98-f10f-9484-a1719164ce16@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:RslL9JEQ43EjUWwyo4ZLUo0XqNN21ltWInyz0jUjIDZj+Nn3neO ZpwkwTszdO9752lNgVAwtw6QBs6YPIfpjz5g3A6k8DvJZuiPCoztnBBSJcHf31JyQJ2SnVf oT+K7AP3yqmRu3fKPZVwSkfq1ZNMgzJyZRxJoHmjbKUo7UYxq9b5d2UOmfz07beetYm9WZ9 7esMCmWc5LFUfdzOqYSoA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:s9QDRNhL2bo=:RfTlmRSrpQo2GZWBNZ/Z/O rggTItsRDktdYXi5T24lAx3j/T8njbowmvR56RURpEAwcHU5bf6fzK7a6bxLXnHXS2P4mxIsi dMCnYjLCJJZ5myi88LGCBCba0jPX1/S88jGSGv+G5N8eG2IJijiWlzNryF5mVAv+3ZuHiKDi9 vAepC5DUDDc6xmNjgRm9TTT+DTUv+OZsHPHSRBEikIylsmLr8XLeJwIE9yBbIXe+bYkDqEKQ8 Bv6YsmJnnhJTlg0cre1UrWR5TSnqmhndHMR+TB28TI2T/Jq1F8K1eAba3Z2ebOaxAr1puZf+g exkQNv5Sk7kgro4S1fIrTZZ1kLiqez/cPRB1lENjBOQq7zQ/GNGbF0TBTqdCftHoBe3conWUJ Q2hQdMrdY1nUgnUDOIkWDnvU2OTnCKWsdPo1Acju9vTDst8TAafSDw+opIleqbEzByS0HS1Dd Jg4L8YjVEENvQr0xwaGEp6PK+xct4DvPGaX0YSFKoe2IPHm8V48k/S+g1y1XFWHJQA1UN2jTY c0DvDDTwiG0aZk+olX7Ca6ZBPT27t8oG0ugq5Y9lYp8xNMmA5qTA/wncr34MplUScoJKRvymt /KjRZQ31wf1u9zdtaDt11Ip9+MD/Ct9LF/eiguMcBRlcVvnS6xFDRidXewNkiVShiLskpXF1k 5p77tESkKRk/iY6iQWM77LXqtp9xC+M++ZAJ316v3KiqnCvJYHoalIxtao3lHUZToTAU3Yigx O4pCRW1nZAw7Yh8UneTE3ni43yNjTMCIEfPWuYe7eJqNuQi83mb0lVAnv7ykfH3zyDRewKfTE nmyH5xFsollXT5SVgj8dXVcgNszbr33G/j+YMITBo1q5El3qYVApOEA7Tlwt8LdeY67D/0p Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.04.19 19:04, Andreas Färber wrote: Hi, > If you see specific conflicts or differences, please explain them> instead of just throwing around bus names. :) Then we can more easily> discuss whether to make changes to this framework or whether we indeed> need some fieldbus/iec61158/ subdirectory. For example, MVB semantically is more similar to can/canopen or even SNMP than to iec61158. T-bus is logically more a typically network interface (similar to 802.3 or HDLC), WTB is actually HDCL via RS485. KNX has similarities to canopen or SNMP. DALI is somewhat similar to I2C. Ergo: there're various fieldbus protocols with entirely different concepts. Distributed process memory like in iec61158 is just one of them. > For your RS-485 I don't see > conflict as that'll just go via tty/serial/ and optionally serdev, no? That's just layer 0/1. Ontop of that there're various protocols. Some folks do some ASCII-based protocol ontop of that (eg. elevators, water plants, etc), others put in HDLC (eg. WTB), some do completely weird things ;-) > However, I'd be curious how I/O Link might relate to this, it seems to> have no public specifications. https://io-link.com/de/Download/Download.php https://io-link.com/share/Downloads/Spec-Interface/IOL-Interface-Spec_10002_V112_Jul13.pdf > While I do like sockets, they seem more useful for packet-based> communication, which may be an implementation detail of fieldbus_dev> drivers, but AFAIU that's unrelated to Sven's memory-focused subsystem> representing a view of the data received, which may be different from> the last packet received. Also, when a packet is received via socket, it> gets dequeued, whereas you'll want to access the device's memory without> restrictions. okay, if the device always represents the current process memory, w/o showing the actual communication, then Sven's approach makes sense. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287