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 28DDFC433EF for ; Wed, 15 Sep 2021 14:54:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03D2E61108 for ; Wed, 15 Sep 2021 14:54:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237109AbhIOO4R (ORCPT ); Wed, 15 Sep 2021 10:56:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230499AbhIOO4Q (ORCPT ); Wed, 15 Sep 2021 10:56:16 -0400 Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5A77C061574 for ; Wed, 15 Sep 2021 07:54:57 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id v20-20020a4a2554000000b0028f8cc17378so992634ooe.0 for ; Wed, 15 Sep 2021 07:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AXnoUZnX9K8Jhtgp+DkwEDwJ5ZLLpWofUK2pY6hDpAM=; b=LA7FPzs6pR84FmZNffrKtaJHU2md8KIPc7XAnKxXa+LpD6K0n0DBqCxCfLov688Pzc 6xnlrcEH7LCJ8CXu9KLpQwLOviDdT1TLZspcF2xROvUwzg7V3YR0R+NzAAPG9WWrgbX6 daV+xOgUwUXAfnsjqTJ0Tg2zPbv27hEOEi7+wV+5H0N+jLR4fJybXTF5xtmWQqjgADNz F0p0H6AtZl1GeJ0TRxDKKfXh7pUxA5OLLqCxzeNDj4G5o2hXhEs/JYkPv/ZVJJDv9fXh twrE98dGFWP8G5cDcWN2FWSzt5r4cvZgyapKB+1sG4/QqwizCs9O0CC9EHGLNhYWoJqp I4sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AXnoUZnX9K8Jhtgp+DkwEDwJ5ZLLpWofUK2pY6hDpAM=; b=asjN+2ZmdKhvzm2yIdtgBudzxUuWA1CSexFJWtBA9PHz4vwOGsFZSoeaRpUz93EWty FSZebrsQGRV5CCuCay7NR2VhPtcuC3kZ1cSOvyYtdlGFTAtf/kEeOJ/MYQDY4uCGinS4 Uid6HiGF3K0JlixdwTCpSkmtg8bydw+zoA+Hcek9W+0ga2DKk/wOJkyOt2Sij9jGmu0q 3nmONUFTPqR5w+y7MKFJc+qT4b+03hLyTPitzsk6y0hEhUTT99JryvBEzpuljK0ooeiS ZGlycordIKSVHo3NA8ETSG4Q3nDlWpvndAUUIybUtmoFWZ0tgjMiDEECWDZtD1UEe1Fz p8/A== X-Gm-Message-State: AOAM5326VLdgPpEc4+U/op38AYJ1SO4qbgcLS1ldinWRfFsMOwY1DHoH pSXmW1WNIHYTaQx/hC+OkpO9CFrD14hOWf0lyVcH9v1U8fE= X-Google-Smtp-Source: ABdhPJzpZFdn092oNsC+zvyL8CJ0KIPVW8cpKj2vPvv3a2v2btOeLYqKZxc9SEuJLvXQVGdE9YkMPXLa1kz4gRUEOGI= X-Received: by 2002:a4a:a40c:: with SMTP id v12mr166613ool.72.1631717697088; Wed, 15 Sep 2021 07:54:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ajay Garg Date: Wed, 15 Sep 2021 20:24:44 +0530 Message-ID: Subject: Re: How to register a new "function" in configfs? To: Michael Sweet Cc: linux-usb@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Any pointers, please? On Sat, Sep 11, 2021 at 8:28 PM Ajay Garg wrote: > > Hi Michael, > > Thanks for the reply. > > I am a bit of old-school, and would prefer things in one place only > (in the kernel) :) > Thus : > > a) > I wish to have all the endpoints configuration/management in the > kernel only (like done in drivers/usb/gadget/function/f_serial.c, > drivers/usb/gadget/function/u_serial.c). > > b) > Only the attributes like vendorId/productId would be in configfs, to > help setup the device. > > c) > No user-space management of kernel objects. > > > Either-way, I think that my issue of "function exposure" would remain > the same, irrespective of whether we use configfs for managing the > kernel-objects (please correct me if I am wrong). > > > Thanks again for your time, look forward to listening back ! > > > Thanks and Regards, > Ajay > > On Sat, Sep 11, 2021 at 8:01 PM Michael Sweet wrote: > > > > Ajay, > > > > Quick question (as someone who has been down this road), do you need to= do a kernel driver or could you just use the functionfs support to impleme= nt everything in userspace? I found that path to be much easier and less e= rror-prone (and one of these days I'm going to be contributing some documen= tation changes to make some things clearer...) and I was able to get my IPP= -USB implementation up and running very quickly. > > > > > > > On Sep 11, 2021, at 1:43 AM, Ajay Garg wrote= : > > > > > > Hi All. > > > > > > As a first step, I have been able to load a gadget on configfs, which > > > binds to the function "gser" (thus loading up the usb_f_serial module > > > when the gadget mounts). Things work well till here. > > > > > > Now, I have written a brand-new gadget-side device-driver, trying to > > > create a new function "gusb", via DECLARE_USB_FUNCTION_INIT. > > > However, now when I try to load the gadget for binding to "gusb", I > > > get the error that the function cannot be found. > > > > > > Seems that firing up a new gadget-side driver, that registers a new > > > function via DECLARE_USB_FUNCTION_INIT, is not enough to make the new > > > function visible across the kernel. > > > > > > Kindly let know what I am missing. > > > Will be grateful for pointers. > > > > > > > > > Thanks and Regards, > > > Ajay > > > > > > > ________________________ > > Michael Sweet > > > > > >