Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1589757pxu; Sun, 6 Dec 2020 00:35:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxV57ZSL61pRUQBDPMNiIj62nqCHq+bKiEqGjdtW4rQsqJRawI6RaNhtWviYG9gtkH7Rqn4 X-Received: by 2002:a17:906:a29a:: with SMTP id i26mr14283783ejz.45.1607243724425; Sun, 06 Dec 2020 00:35:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607243724; cv=none; d=google.com; s=arc-20160816; b=HzDKm+pRw3SbfmXm36zkJhxg4aTjRtOvOItjbArgXgag4i5YuF/cYTHFVt8nVwICd4 hrcad2IS60I/74gYKfOhD65dTrB6NkNJG3FhTH8bf3K85gu13ymEgWm4CM5k+UwgqLM+ BsefbdOWRcb6cMlnOu/HDagFyDqK9HmVw+TprK6Cxfda/yQjPFFRtPJTJFFDWqRNPuq1 4oK3A48cv5kh+a16b9kSIUIw5EBwKaVvMr1+cPFF9KU2HceSRy9GHyK/vAZ2lADrfJ1Z za7ky+vwZUoQYr7dBoX4Fo6eZwHzcIY/piE6hu3Atf11BZKrC2292c8thkhs7x9W6WLr yQnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=PZZtgG4UkU9PtI0NdRDcASM/EZV0pQ2yV1TC0O+h9Vo=; b=A89ws0LSNlj7qxNVsmLAmZ3r7EieLzPK4/h53vsAJmoyM0ox31lQCoXCDtJgwsXGvm MOW76XQF5y5vXJKr330WY2/L6bQ6zl9jZTGU9zE601lSteZI2EyiADYlRs0uvQJT6Gkf 9qFSjkjXmR1nyxzXG6tGE7OxjXpzu7G4qInNAdJ61bWgGzGwgJkuARMKeWytGOM3VzVh rJuUn1KexhT/wfsLSxjUSUA1ZOKkf0HnqtVSuGxQIGOGNqTNwNTNPXD76JB0f0rts4WW UIXoKlHLU4shc9Rsk7rVuthpqWqSrLetbajnmsel0eMREnHT3AkZaZ2xRlJig0DHUhJj 1NHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VOqQuGPt; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v14si6130037edr.397.2020.12.06.00.34.59; Sun, 06 Dec 2020 00:35:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-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=@kernel.org header.s=k20201202 header.b=VOqQuGPt; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726774AbgLFIds (ORCPT + 99 others); Sun, 6 Dec 2020 03:33:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:44610 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725867AbgLFIdr (ORCPT ); Sun, 6 Dec 2020 03:33:47 -0500 Date: Sun, 6 Dec 2020 10:33:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607243586; bh=YxOwelJbt6Ldd1JmN1BBjPbwh7esl4+nGtdlpwDrHv8=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=VOqQuGPtUIIFyk+tnfst7FxjYZXe6qfKsID0qvnciJueai74WkaNSocZQEHXvuGdC zSsWvHpoDNcf2NtCn9NfzpTEySj3LKWMWaEdXXI0D71QAwMsGJv+ry34PQSWrhutxf Qoot7kuGh2FMwJUyQSDjiwVmoYQ6HaE+5Id4989C7Fhra/v2lGluif4S4iL5Jpxd8O 4zEsE1f0HvbRMfJ1Mq/UWR/4kipbVvELNcU4+T7VIeeWe1v83KZbh3nLumIfwLARZz yVY3VZIao0O0/nMRx9qrTFLGKT0XY2EGXpLPU2+FSZ1unmHPOYkqKQsbZ7NbVJfuNC WlMK3qPSlC/Bg== From: Leon Romanovsky To: Jeffrey Hugo Cc: Jakub Kicinski , Hemant Kumar , manivannan.sadhasivam@linaro.org, gregkh@linuxfoundation.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, bbhatt@codeaurora.org, loic.poulain@linaro.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, Kalle Valo Subject: Re: [PATCH v13 0/4] userspace MHI client interface driver Message-ID: <20201206083302.GA691268@unreal> References: <1606533966-22821-1-git-send-email-hemantk@codeaurora.org> <20201201112901.7f13e26c@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> <20201201120302.474d4c9b@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> <817a4346-efb7-cfe5-0678-d1b60d06627d@codeaurora.org> <20201201185506.77c4b3df@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, Dec 01, 2020 at 09:59:53PM -0700, Jeffrey Hugo wrote: > On 12/1/2020 7:55 PM, Jakub Kicinski wrote: > > On Tue, 1 Dec 2020 13:48:36 -0700 Jeffrey Hugo wrote: > > > On 12/1/2020 1:03 PM, Jakub Kicinski wrote: > > > > On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote: > > > > > On 12/1/2020 12:29 PM, Jakub Kicinski wrote: > > > > > > On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote: > > > > > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > > > > > clients to communicate to external MHI devices like modem and WLAN. UCI driver > > > > > > > probe creates standard character device file nodes for userspace clients to > > > > > > > perform open, read, write, poll and release file operations. These file > > > > > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > > > > > to communicate with MHI device. Patch is tested using arm64 based platform. > > > > > > > > > > > > Wait, I thought this was for modems. > > > > > > > > > > > > Why do WLAN devices need to communicate with user space? > > > > > > > > > > Why does it matter what type of device it is? Are modems somehow unique > > > > > in that they are the only type of device that userspace is allowed to > > > > > interact with? > > > > > > > > Yes modems are traditionally highly weird and require some serial > > > > device dance I don't even know about. > > > > > > > > We have proper interfaces in Linux for configuring WiFi which work > > > > across vendors. Having char device access to WiFi would be a step > > > > back. > > > > > > So a WLAN device is only ever allowed to do Wi-Fi? It can't also have > > > GPS functionality for example? > > > > No, but it's also not true that the only way to implement GPS is by > > opening a full on command/packet interface between fat proprietary > > firmware and custom user space (which may or may not be proprietary > > as well). > > Funny, that exactly what the GPS "API" in the kernel is, although a bit > limited to the specifics on the standardized GPS "sentences" and not > covering implementation specific configuration. > > > > > > > > However, I'll bite. Once such usecase would be QMI. QMI is a generic > > > > > messaging protocol, and is not strictly limited to the unique operations > > > > > of a modem. > > > > > > > > > > Another usecase would be Sahara - a custom file transfer protocol used > > > > > for uploading firmware images, and downloading crashdumps. > > > > > > > > Thanks, I was asking for use cases, not which proprietary vendor > > > > protocol you can implement over it. > > > > > > > > None of the use cases you mention here should require a direct FW - > > > > user space backdoor for WLAN. > > > > > > Uploading runtime firmware, with variations based on the runtime mode. > > > Flashing the onboard flash based on cryptographic keys. Accessing > > > configuration data. Accessing device logs. Configuring device logs. > > > Synchronizing the device time reference to Linux local or remote time > > > sources. Enabling debugging/performance hardware. Getting software > > > diagnostic events. Configuring redundancy hardware per workload. > > > Uploading new cryptographic keys. Invalidating cryptographic keys. > > > Uploading factory test data and running factory tests. > > > > > > Need more? > > > > This conversation is going nowhere. Are you trying to say that creating > > a common Linux API for those features is impossible and each vendor > > should be allowed to add their own proprietary way? > > > > This has been proven incorrect again and again, and Wi-Fi is a good > > example. > > > > You can do whatever you want for GPS etc. but don't come nowhere near > > networking with this attitude please. > > > > No I'm saying (and Bjorn/Mani by the looks of things), that there is > commonality in the core features - IP traffic, Wi-Fi, etc but then there are > vendor specific things which are either things you don't actually want in > the kernel, don't want the kernel doing, or have little commonality between > vendors such that attempting to unify them gains you little to nothing. > > Over in the networking space, I can see where standardization is plenty > useful. > > I can't speak for other vendors, but a "modem" or a "wlan" device from > Qualcomm is not something that just provides one service. They tend to > provide dozens of different functionalities, some of those are > "standardized" like wi-fi where common wi-fi interfaces are used. Others are > unique to Qualcomm. > > The point is "wlan device" is a superset of "wi-fi". You seem to be > equating them to be the same in a "shoot first, ask questions later" manner. > > This series provides a way for userspace to talk to remote MHI "widgets" for > usecases not covered elsewhere. Those "widgets" just happen to commonly > provide modem/wlan services, but ones that don't are not excluded. > > Regarding not coming near networking, I'd like to remind you it was you that > decided to come over here to the non-networking area and try to make this > about networking. Like it or not, but Jakub is absolutely right with his claim that providing user-visible interfaces without any standardization is proven as wrong. Thanks > > -- > Jeffrey Hugo > Qualcomm Technologies, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project.