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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 990B2C4338F for ; Mon, 26 Jul 2021 22:40:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E7A760F6C for ; Mon, 26 Jul 2021 22:40:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233858AbhGZV7d (ORCPT ); Mon, 26 Jul 2021 17:59:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233817AbhGZV7d (ORCPT ); Mon, 26 Jul 2021 17:59:33 -0400 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60761C061757; Mon, 26 Jul 2021 15:40:00 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id 19-20020a9d08930000b02904b98d90c82cso11572453otf.5; Mon, 26 Jul 2021 15:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fyYS83TJhhxVOfsNmu5c001LjoG5UgZ/hJ8MDBaDVrk=; b=ax0x11gYfKsrv5i8QpmztTa8rW81guRfm6vJ9GoNpNGMhjpJlwvWlmkjrykyNYd4qt CDC8rgfh//cXjINJ1Rsnh553J+QQOHDiBlxr1fTQsbT6ufjzDWUae93YxOLwoXL1KdW4 pVybN4jHUxkCZeLnE3lPAL+jsUe9pDRIgYoxRUrvbfTk3fPPThzwtztr8npwTxsXjsMa 9UXdRWsV9KmTLHKVGL1Wg8whYZQWNxPHrHS0jY4a5su8RbiR9PcBbdQid9HcbqX9du9n K518pKRvgSLU5SjOMdjehY3TDotw7dnTth0K2euObdN/NoQGSWYctjHdyJXrsdeCH9EH K9zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fyYS83TJhhxVOfsNmu5c001LjoG5UgZ/hJ8MDBaDVrk=; b=radkGYOQtCzDpc9QD7CwgtyFR/Yc5qsOvk1hiHRmvttudkF2VgH/TqzrwByi1Mhkch /cmwUTBZwO8SfRPbNUJZPoUtwY2axkWQnTHOrcBtiPVUykOxbZZ/SSIvBMDFiwVK/Ol4 DM8EPFjnDY++NVjgzPvyXc//7irvq+bDmU0bxDK1GWtxfye7Nj4eGZyEzAq9PKj04nf0 PBO6JFuS6uqmeAusBSCC4Ne3s4wKhYXZA9MJLvzKOHa8cGTiLyWoiexajIkLr6nELNXR 2VPLGKUMuZXSHJJSmQwTSdBfcBoEEaIOV9koz/rAybmljC73zkp8aIf30v5TVvuQdN5+ CcLg== X-Gm-Message-State: AOAM533PnQXB0zrl74gvt9psPxaT9imZ8FkY7zAwH9nOy3WododdRVVh kCqkZ1NFFtWJw292goE1R6rCD7HxBemMKGlKA54= X-Google-Smtp-Source: ABdhPJwDiHLckB0JbibpoC/Qkq6c662oX2jEeuzB25zfWmbxwwssxd71D586oKFQCzcpzw5AqtAookmewbmv48f+oEg= X-Received: by 2002:a9d:6d83:: with SMTP id x3mr12761570otp.110.1627339199143; Mon, 26 Jul 2021 15:39:59 -0700 (PDT) MIME-Version: 1.0 References: <20210719145317.79692-1-stephan@gerhold.net> <20210719145317.79692-5-stephan@gerhold.net> In-Reply-To: From: Sergey Ryazanov Date: Tue, 27 Jul 2021 01:40:10 +0300 Message-ID: Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver To: Aleksander Morgado Cc: =?UTF-8?Q?Bj=C3=B8rn_Mork?= , Stephan Gerhold , Loic Poulain , "David S. Miller" , Jakub Kicinski , Johannes Berg , Bjorn Andersson , Andy Gross , Vinod Koul , Rob Herring , Network Development , linux-arm-msm , dmaengine@vger.kernel.org, devicetree , open list , phone-devel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, Jeffrey Hugo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Hello Aleksander, On Mon, Jul 26, 2021 at 11:11 AM Aleksander Morgado wrote: >> But what if we implement the QMI multiplexing management part in the >> kernel? This way the kernel will take care about modem-to-host >> communication protocols and interfaces, and provides userspace with a >> single WWAN device (possibly with multiple network and network >> management interfaces). >> >> I do not propose to fully implement QMI protocol inside the kernel, >> but implement only a mux management part, while passing all other >> messages between a "modem" and a userspace software as-is. >> >> What pros and cons of such a design do you see? > > The original GobiNet driver already provided some QMI protocol > implementation in the driver itself. In addition to initial device > setup as you suggest, it also allowed userspace applications to > allocate and release QMI clients for the different services that could > be used independently by different processes. Not going to say that > was the wrong way to do it, but the implementation is definitely not > simple. The decision taken in qmi_wwan to make the driver as simple as > possible and leave all the QMI management to userspace was quite an > important one; it made the driver extremely simple, leaving all the > complexity of managing the protocol to userspace, and while it had > some initial drawbacks (e.g. only one process could talk QMI at a > time) the userspace tools have evolved to avoid them (e.g. the > qmi-proxy). > > I wrote some time ago about this, maybe it's still relevant today: > Blogpost https://sigquit.wordpress.com/2014/06/11/qmiwwan-or-gobinet/, > Article in PDF https://aleksander.es/data/Qualcomm%20Gobi%20devices%20on%20Linux.pdf > > Making the driver talk QMI just for device setup would require the > kernel to know how the QMI protocol works, how QMI client allocations > and releases are done, how errors are reported, how is the format of > the requests and responses involved; it would require the kernel to > wait until the QMI protocol endpoint in the modem is capable of > returning QMI responses (this could be up to 20 or 30 secs after the > device is available in the bus), it would require to have possibly > some specific rules on how the QMI clients are managed after a > suspend/resume operation. It would also require to sync the access to > the CTL service, which is the one running QMI service allocations and > releases, so that both kernel and userspace can perform operations > with that service at the same time. It would need to know how > different QMI capable devices behave, because not all devices support > the same services, and some don't even support the WDA service that > would be the one needed to setup data aggregation. There is definitely > some overlap on what the kernel could do and what userspace could do, > and I'd say that we have much more flexibility in userspace to do all > this leaving all the complexity out of the kernel driver. > > ModemManager already provides a unified API to e.g. setup multiplexed > data sessions, regardless of what the underlying kernel implementation > is (qmi_wwan only, qmi_wwan+rmnet, ipa+rmnet, bam-dmux, cdc_mbim...) . > The logic doing all that is extremely complex and possibly full of > errors, I would definitely not want to have all that logic in the > kernel itself, let the errors be in userspace! Unifying stuff in the > kernel is a good idea, but if you ask me, it should be done in a way > that is as simple as possible, leaving complexity to userspace, even > if that means that userspace still needs to know what type of device > we have behind the wwan subsystem, because userspace will anyway need > to know all that. Ouch! All these QMI internals are like a can of worms. Each time I start thinking that I learned something I face another complexity. Many thanks for your detailed reply and for your blogpost, for me it was quite helpful for understanding to see a side by side comparison of approaches! The argument for keeping drivers minimalistic to keep the system stable sounds reasonable. But I am still feeling uncomfortable when a userspace software manages a device at such a low level. Maybe it is a matter of taste, or maybe I still do not realize the whole complexity. Anyway, in the context of your clarification, I should be more careful in the future with calls to implement QMI in the kernel :) -- Sergey