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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 383CCC43467 for ; Thu, 8 Oct 2020 07:15:28 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0072420714 for ; Thu, 8 Oct 2020 07:15:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="UyX0DLDX"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="pOaj6xSd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0072420714 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 6157016AA; Thu, 8 Oct 2020 09:14:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 6157016AA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1602141325; bh=X5Z4K6U98itd0H60xPt70F2wncl7ZCZ6qVutdluFaaE=; h=From:To:Subject:Date:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=UyX0DLDX9jlmsAA4d8ds9wHkokbVwkj0OQp3Zb94O++vPSt7M3BMbspvuTFYQg3Gx 1QarRRzV317/rUjpK50PRayKa3wzr6dkPc+HdVVxRhBHWTGV7cwN7Ij5c9vPsnZZ3N V6BUGT/DHPIhsokpiNNTDSA2vCPIwluaqcxvQ8O4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id ED369F8015A; Thu, 8 Oct 2020 09:14:34 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id ED11AF80164; Thu, 8 Oct 2020 09:14:32 +0200 (CEST) Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 2C4DCF8015A for ; Thu, 8 Oct 2020 09:14:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 2C4DCF8015A Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="pOaj6xSd" Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 08 Oct 2020 00:14:07 -0700 Received: from HQMAIL101.nvidia.com (172.20.187.10) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Oct 2020 07:14:19 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.52) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 8 Oct 2020 07:14:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V0FqPe2WXWYcXaRFAOuh6JKSQGDWNBwGr5HgweoDDVJesDbrfhvPqe/tEXMeXV2SKLKrzKcwQMPTE+UQVIMISK1oYewQysEi3geX5eaXU5MIZqcH3avkiIMXOKwNV/SuX21pUIYvkXkOSX6sdPcY3pPiE0E0UWiagQQ28lmW20FAI8WQXy09tYOKqNxdQvMo1RSlNibKDb3QtEPTj/Wvu7dWsXnXn4s8EcS8QV6nipIpz94kev9cK6c1NrQdBGpjewrY13fqDv3HIjuU7kBB38nyEs+aIFcnA4dzHQCBMfINqMy3P/IY1v35m3IJ39jZcFaig795FjG0hgLZkkUvRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4ZR/ODNvERLst5ICSYanZkACMwaB+mr7lzt5lxqrmY=; b=gLJRfL35nLc64V7WKr0alZhkqsn0eX7lECt4AN4aDl0rUpmIpxDrZx3cVJem9lBxsSEsucZMS3pYFTv9nQdtX+7Pu8F89k16TfQM1iuQUWYSFYDuYY6j/bHsj1QMu4P+LQGwHD2w/eP5D7JRC14TxxFToK5pNxCqDuWzE7MampjJl5Cf1yptjrpl9qcKzzyhrPKAChaejc5rQBdDNLFemnR9O4kAmIUd1RPlAmwI3Y/AsFpjInuIPMwFszAtJagXvI9/t1tfBJnh3tkn7iWQRHfbOdoqK6cdZuFw6fHGiPdBcd5ZNHKitHowfzH4t0Bb7E9QdoNXySRZT8Jj2w7cCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from BY5PR12MB4322.namprd12.prod.outlook.com (2603:10b6:a03:20a::20) by BY5PR12MB3954.namprd12.prod.outlook.com (2603:10b6:a03:1af::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Thu, 8 Oct 2020 07:14:18 +0000 Received: from BY5PR12MB4322.namprd12.prod.outlook.com ([fe80::3c25:6e4c:d506:6105]) by BY5PR12MB4322.namprd12.prod.outlook.com ([fe80::3c25:6e4c:d506:6105%6]) with mapi id 15.20.3455.023; Thu, 8 Oct 2020 07:14:18 +0000 From: Parav Pandit To: Leon Romanovsky Subject: RE: [PATCH v2 1/6] Add ancillary bus support Thread-Topic: [PATCH v2 1/6] Add ancillary bus support Thread-Index: AQHWm05cPW7H51WMukmCocLPE63Nf6mKKyGAgACGC4CAAB03gIABpCoAgAAWQgCAAAuCMIAACwKAgAADjQCAAAZvgIAAB6yAgABvlmCAAA/xgIAAF0PQ Date: Thu, 8 Oct 2020 07:14:17 +0000 Message-ID: References: <20201006170241.GM1874917@unreal> <20201007192610.GD3964015@unreal>

<20201008052623.GB13580@unreal> In-Reply-To: <20201008052623.GB13580@unreal> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [49.207.195.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 454bfa66-3fe9-4ec8-2d47-08d86b59c56d x-ms-traffictypediagnostic: BY5PR12MB3954: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0u0DlBvuXQYBxKvYM8uqdtmzUKWS189l3Ptmas5TlHp8jlsu8lXoDXLCjh4uA+wENhyQ5d9AW7sJNDpF7Y3bdaUoqGOvRobgop1FZSQrfMxJl56MujgkwPTZlXbd9ZxaejQCvho61bgJgdFT5JRcRKGv7d6DkM0uiHrqK0afhsstWFwb0xUH1XfjWfemln/3SP0j3w6KCh2LIgptyiHCegHTiMDJ5zkhkxJ/FkGyscK615n04eVfsMMA+LldwQXbw+2iBGw1baRbfsbg6ANHFKsEUGktXHBDzGrQW1b1hvA0PdYd35XgQrzsZsK0QCCF4LRMgnTNPzIR4JMMdp1raBK+1Wp1FjbQjoVks/WRwC7LqcKFSarUw6c3yatsnCZB26uivoe24ySFyIkzpIFR4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR12MB4322.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(53546011)(316002)(7416002)(55016002)(9686003)(2906002)(4326008)(54906003)(83380400001)(83080400001)(478600001)(8676002)(966005)(26005)(186003)(52536014)(33656002)(6506007)(86362001)(71200400001)(55236004)(6916009)(76116006)(66946007)(66556008)(8936002)(66446008)(64756008)(7696005)(5660300002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IvWvGCce/b1jkbHeiFiwBcOcJx1juAzOnvUpFsuQaT+z/DVUAZ4ZlJJJ0MuKjtgEcU+w2TfElrb6qNE1w+oSgRb5H3kpxD1YOwm4xTEaSrnZD9AV9yyuriE0qKLdk9NI3RcTfPEYWPpCbOHWszWShbBuDj33TctIie0Q32nVcHMuJ4nkoHT+xC0571g8f+La9lNd2E1YjxcF4VVidE89sPcyNIFy9R8kE+OLbpVg3ETfNcrOPNXABMwJKgbPNRxecEI9a1RxfTJGyv68Bs9Z6dycLBN4GVjVnXLlErj5XMe4vwIRoDfv4udUMmb/fJ+VCfeaIPDALtJJ8A0VNwcIvItqV2ABHGEDbHsvCsYDsREYjpW41zgMcWhAjvEhN6mmrIJi1xB8ZqmVWVWVqpbjVjjanaOtA251UHqORkJlBxyP6l2pmCYRc/+JLkMYzlXiDRO9gqZAcQDq7RmOAFVjclUeyhCNXd1/vvgIO1D/Dotd2cj+E3n82o8fgFa9kOoIzErcqYB0RKhBbkSiV1NPiRVwctw+yDQX8cNTCeXKlIxxs+q3bDeJUbWaYDNvm+Muin7MEqlmgdWT3m8JmJEsdKePrfGj3sQCPMFCGsXw78LSOrWfKyLgyDSR6JUR+RKrb8GjYqEHirBeZTfSSdYXBg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4322.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 454bfa66-3fe9-4ec8-2d47-08d86b59c56d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 07:14:18.0128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i0gP4yKgzsKxSUGk2nCR6G+/t2p1RPZQ3/CCXMSOWYp/P2fLMItFHlD/nC+L7WvzDZtf/6XSOxzUlefVq3VdZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3954 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1602141247; bh=N4ZR/ODNvERLst5ICSYanZkACMwaB+mr7lzt5lxqrmY=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To: CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ms-exchange-transport-forked: x-microsoft-antispam-prvs:x-ms-oob-tlc-oobclassifiers: x-ms-exchange-senderadcheck:x-microsoft-antispam: x-microsoft-antispam-message-info:x-forefront-antispam-report: x-ms-exchange-antispam-messagedata:Content-Type: Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=pOaj6xSdrprY479+0debN/8V3cyMlCgnAs564iWLDrNxqZIg20pU30aE17tnojDpu y0l8Epkx4BMoPUbimKAREBkc+2bJaja5WvOqet4sP6le6gezVC1xsLQaJl9mT9dqjm P3BqmlgoU/hzdd7yyGfyS0jcqwbDwNSEIZVpNtzhzd/7uzeRxwMg4LNjwlNRpwPL2w STC98T0dsNa1nmmkwYwvLXvT3aIhvD/khVZ3hfjtT/QHB2bwGBiDixoB9HxcxhqV6D rJjsquXK4py/H+Z5sEhqciWOvRi63JQZateGNaLNUcf/s3XkCeDjdKek75hGnkd3jV LCVixQYSUH+uw== Cc: "alsa-devel@alsa-project.org" , "kuba@kernel.org" , "parav@mellanox.com" , "tiwai@suse.de" , "netdev@vger.kernel.org" , Pierre-Louis Bossart , "ranjani.sridharan@linux.intel.com" , "fred.oh@linux.intel.com" , "linux-rdma@vger.kernel.org" , "dledford@redhat.com" , "broonie@kernel.org" , Jason Gunthorpe , "gregkh@linuxfoundation.org" , "Ertman, David M" , "Williams, Dan J" , "Saleem, Shiraz" , "davem@davemloft.net" , "Patil, Kiran" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" > From: Leon Romanovsky > Sent: Thursday, October 8, 2020 10:56 AM >=20 > On Thu, Oct 08, 2020 at 04:56:01AM +0000, Parav Pandit wrote: > > > > > > > From: Pierre-Louis Bossart > > > Sent: Thursday, October 8, 2020 3:20 AM > > > > > > > > > On 10/7/20 4:22 PM, Ertman, David M wrote: > > > >> -----Original Message----- > > > >> From: Pierre-Louis Bossart > > > >> Sent: Wednesday, October 7, 2020 1:59 PM > > > >> To: Ertman, David M ; Parav Pandit > > > >> ; Leon Romanovsky > > > >> Cc: alsa-devel@alsa-project.org; parav@mellanox.com; > > > >> tiwai@suse.de; netdev@vger.kernel.org; > > > >> ranjani.sridharan@linux.intel.com; > > > >> fred.oh@linux.intel.com; linux-rdma@vger.kernel.org; > > > >> dledford@redhat.com; broonie@kernel.org; Jason Gunthorpe > > > >> ; gregkh@linuxfoundation.org; kuba@kernel.org; > > > >> Williams, Dan J ; Saleem, Shiraz > > > >> ; davem@davemloft.net; Patil, Kiran > > > >> > > > >> Subject: Re: [PATCH v2 1/6] Add ancillary bus support > > > >> > > > >> > > > >> > > > >>>> Below is most simple, intuitive and matching with core APIs for > > > >>>> name and design pattern wise. > > > >>>> init() > > > >>>> { > > > >>>> err =3D ancillary_device_initialize(); > > > >>>> if (err) > > > >>>> return ret; > > > >>>> > > > >>>> err =3D ancillary_device_add(); > > > >>>> if (ret) > > > >>>> goto err_unwind; > > > >>>> > > > >>>> err =3D some_foo(); > > > >>>> if (err) > > > >>>> goto err_foo; > > > >>>> return 0; > > > >>>> > > > >>>> err_foo: > > > >>>> ancillary_device_del(adev); > > > >>>> err_unwind: > > > >>>> ancillary_device_put(adev->dev); > > > >>>> return err; > > > >>>> } > > > >>>> > > > >>>> cleanup() > > > >>>> { > > > >>>> ancillary_device_de(adev); > > > >>>> ancillary_device_put(adev); > > > >>>> /* It is common to have a one wrapper for this as > > > >>>> ancillary_device_unregister(). > > > >>>> * This will match with core device_unregister() that has > > > >>>> precise documentation. > > > >>>> * but given fact that init() code need proper error > > > >>>> unwinding, like above, > > > >>>> * it make sense to have two APIs, and no need to export > > > >>>> another symbol for unregister(). > > > >>>> * This pattern is very easy to audit and code. > > > >>>> */ > > > >>>> } > > > >>> > > > >>> I like this flow +1 > > > >>> > > > >>> But ... since the init() function is performing both device_init > > > >>> and device_add - it should probably be called > > > >>> ancillary_device_register, and we are back to a single exported > > > >>> API for both register and unregister. > > > >> > > > >> Kind reminder that we introduced the two functions to allow the > > > >> caller to know if it needed to free memory when initialize() > > > >> fails, and it didn't need to free memory when add() failed since > > > >> put_device() takes care of it. If you have a single init() > > > >> function it's impossible to know which behavior to select on error= . > > > >> > > > >> I also have a case with SoundWire where it's nice to first > > > >> initialize, then set some data and then add. > > > >> > > > > > > > > The flow as outlined by Parav above does an initialize as the > > > > first step, so every error path out of the function has to do a > > > > put_device(), so you would never need to manually free the memory > > > > in > > > the setup function. > > > > It would be freed in the release call. > > > > > > err =3D ancillary_device_initialize(); if (err) > > > return ret; > > > > > > where is the put_device() here? if the release function does any > > > sort of kfree, then you'd need to do it manually in this case. > > Since device_initialize() failed, put_device() cannot be done here. > > So yes, pseudo code should have shown, if (err) { > > kfree(adev); > > return err; > > } > > > > If we just want to follow register(), unregister() pattern, > > > > Than, > > > > ancillar_device_register() should be, > > > > /** > > * ancillar_device_register() - register an ancillary device > > * NOTE: __never directly free @adev after calling this function, even > > if it returned > > * an error. Always use ancillary_device_put() to give up the reference > initialized by this function. > > * This note matches with the core and caller knows exactly what to be > done. > > */ > > ancillary_device_register() > > { > > device_initialize(&adev->dev); > > if (!dev->parent || !adev->name) > > return -EINVAL; > > if (!dev->release && !(dev->type && dev->type->release)) { > > /* core is already capable and throws the warning when > release callback is not set. > > * It is done at drivers/base/core.c:1798. > > * For NULL release it says, "does not have a release() > function, it is broken and must be fixed" > > */ > > return -EINVAL; > > } > > err =3D dev_set_name(adev...); > > if (err) { > > /* kobject_release() -> kobject_cleanup() are capable to > detect if name is set/ not set > > * and free the const if it was set. > > */ > > return err; > > } > > err =3D device_add(&adev->dev); > > If (err) > > return err; > > } > > > > Caller code: > > init() > > { > > adev =3D kzalloc(sizeof(*foo_adev)..); > > if (!adev) > > return -ENOMEM; > > err =3D ancillary_device_register(&adev); > > if (err) > > goto err; > > > > err: > > ancillary_device_put(&adev); > > return err; > > } > > > > cleanup() > > { > > ancillary_device_unregister(&adev); > > } > > > > Above pattern is fine too matching the core. > > > > If I understand Leon correctly, he prefers simple register(), unregiste= r() > pattern. > > If, so it should be explicit register(), unregister() API. >=20 > This is my summary > https://lore.kernel.org/linux-rdma/20201008052137.GA13580@unreal > The API should be symmetric. >=20 I disagree to your below point. > 1. You are not providing driver/core API but simplification and obfuscati= on > of basic primitives and structures. This is new layer. There is no room f= or > a claim that we must to follow internal API. If ancillary bus has ancillary_device_add(), it cannot do device_initialize() and device_add() i= n both. I provided two examples and what really matters is a given patchset uses (n= eed to use) which pattern, initialize() + add(), or register() + unregister(). As we all know that API is not added for future. It is the future patch ext= ends it. So lets wait for Pierre to reply if soundwire can follow register(), unregi= ster() sequence. This way same APIs can service both use-cases. Regarding, > 3. You can't "ask" from users to call internal calls (put_device) over in= ternal > fields in ancillary_device. In that case if should be ancillary_device_put() ancillary_device_release()= . Or we should follow the patten of ib_alloc_device [1], ancillary_device_alloc() -> kzalloc(adev + dev) with compile time assert check like rdma and vdp= a subsystem. ->device_initialize() ancillary_device_add() ancillar_device_de() <- balances with add ancillary_device_dealloc() <-- balances with device_alloc(), which does the= put_device() + free the memory allocated in alloc(). This approach of [1] also eliminates exposing adev.dev.release =3D in drivers. And container_of() benefit also continues.. [1] https://elixir.bootlin.com/linux/v5.9-rc8/source/include/rdma/ib_verbs.= h#L2791