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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 C4087C433E7 for ; Thu, 8 Oct 2020 08:00:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 62BC121D24 for ; Thu, 8 Oct 2020 08:00:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602144017; bh=AxG+Cu4gWXF9mzIpf5u5X66cZnQ7T2FI5kxlh5iSmvQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=1YS3b0dAnlfOl6fxBi472IadO2sWR4hlRhMgpRzn7SfVkdoOtK6b6YjT0BrOdKUm4 TiK7au17+inVjwnV/hXDLzgJUzKzAA4ZkieQUmrc5/z2wpHLTeFsPvtus/P5M2QP4w JI7+kDVAC5c5caa9QjB/8oZ5hiE5uPeLFqLkSs7w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728326AbgJHIAQ (ORCPT ); Thu, 8 Oct 2020 04:00:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:44602 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727303AbgJHIAQ (ORCPT ); Thu, 8 Oct 2020 04:00:16 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7826821927; Thu, 8 Oct 2020 08:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602144015; bh=AxG+Cu4gWXF9mzIpf5u5X66cZnQ7T2FI5kxlh5iSmvQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NBhnMPiBUad0ixKEcTOR0tHjZ2et/rEx+Ql65v7he9OtBvKy0sJ8ppNqbuWH0oWKT y/fZs3dFofIdhXxoV8c7pmshcuCeiW/YjzAYbPmdX/Q363EgA+uTfG7l6lTpzSM+t/ q2PMcHFwYwkoqav/CRLlYiuvbcrTOnq7nCEAn/Gk= Date: Thu, 8 Oct 2020 11:00:10 +0300 From: Leon Romanovsky To: Dan Williams Cc: "Ertman, David M" , Parav Pandit , Pierre-Louis Bossart , "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" , "Saleem, Shiraz" , "davem@davemloft.net" , "Patil, Kiran" Subject: Re: [PATCH v2 1/6] Add ancillary bus support Message-ID: <20201008080010.GK13580@unreal> References: <20201006170241.GM1874917@unreal> <20201007192610.GD3964015@unreal> <20201008052137.GA13580@unreal> <20201008070032.GG13580@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Oct 08, 2020 at 12:38:00AM -0700, Dan Williams wrote: > On Thu, Oct 8, 2020 at 12:01 AM Leon Romanovsky wrote: > [..] > > All stated above is my opinion, it can be different from yours. > > Yes, but we need to converge to move this forward. Jason was involved > in the current organization for registration, Greg was angling for > this to be core functionality. I have use cases outside of RDMA and > netdev. Parav was ok with the current organization. The SOF folks > already have a proposed incorporation of it. The argument I am hearing > is that "this registration api seems hard for driver writers" when we > have several driver writers who have already taken a look and can make > it work. If you want to follow on with a simpler wrappers for your use > case, great, but I do not yet see anyone concurring with your opinion > that the current organization is irretrievably broken or too obscure > to use. Can it be that I'm first one to use this bus for very large driver (>120K LOC) that has 5 different ->probe() flows? For example, this https://lore.kernel.org/linux-rdma/20201006172317.GN1874917@unreal/ hints to me that this bus wasn't used with anything complex as it was initially intended. And regarding registration, I said many times that init()/add() scheme is ok, the inability to call to uninit() after add() failure is not ok from my point of view. Thanks