Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2607707pxj; Mon, 14 Jun 2021 02:54:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzU5jLB2rbCNHhr1t3NNsd53ssPY0KQFthd8Yxvx65KGxKuWwxtjAzMC1NHAgAFV8hjqYFd X-Received: by 2002:a05:6402:35cc:: with SMTP id z12mr3514475edc.45.1623664479097; Mon, 14 Jun 2021 02:54:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623664479; cv=none; d=google.com; s=arc-20160816; b=ld4a62tJ85kvborelrwqEePhn7OMdIFectFUvidJf782eSttEFKEdF6n6BOpZ6PjWc cwah4bCFesU7/Q03LQOuGKGL9xVmW3zF/vJRM+/aYEVUi5qwTC+cURCxhWuOhvfw9YyT vraaSXp9B6lJAOFgSZVI6OEFi0OdOeWoSmpj06BnhDEIUPIKZG8zAzhwznqqrYrmXb8n NvX71DyaxBbpByZwve5VIEu7KYylCuuycvtr+rDf5LHu4SC3rlVLcLk0iCksvRbqZFsA pXsxCyLxK2Jhc9qX1jTVRTYfUsFyfRXVWpkhAUgDQwrLFr9PRap+jVTuHJbI6p5QpoYj 1H/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=tyrwULaDA/8yLqlpZdEOiGOlczFmIcq5jIHr0JXrByc=; b=plgseK+EYsZkFRpk5lgubY7+QhA/HmHd2KCDiv0qVPGIxlJbvtlK/cdXG7ayxUQAOs vsoasYYh6pxhMYL8fwOdKD6AFyAL18wBW4w0kkRec7MWWyalcUxatjjibzK0rICnJk+m IH25zV3FIcFYx7mpOJkL9qGMBzS3ka1xPVR52VAnq3kzjyEX6Grx0Jq5w9BXzLQr8V5r yYtX/gsEK0610epIiu5ho73N9/RkGnvGKV3oVqMU2ORah6xOlcjhL1vE1HHwwfnsSDy0 KKZ1ve1D45CMzuOhOlPHQLM5Giw/yw4WJyHCBJP+JR3fPz1ZGK81bpgiSHA6eQeluX6Y 4AGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=igPrVeoH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd3si10605303edb.307.2021.06.14.02.54.15; Mon, 14 Jun 2021 02:54:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@linaro.org header.s=google header.b=igPrVeoH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232817AbhFNJy2 (ORCPT + 99 others); Mon, 14 Jun 2021 05:54:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232815AbhFNJy1 (ORCPT ); Mon, 14 Jun 2021 05:54:27 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C98EC061574 for ; Mon, 14 Jun 2021 02:52:24 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id g4so9417266pjk.0 for ; Mon, 14 Jun 2021 02:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tyrwULaDA/8yLqlpZdEOiGOlczFmIcq5jIHr0JXrByc=; b=igPrVeoHcTmiAINqhls6RiJIDB5nLDcSwdZ3KpExZuE8yIUZMRE1RVmBm+B0fXRIyB 6ew0i/Ft0rDT+XS5FZf4NnMvWhY8OhRlIhSSvjrha4+p9GtHzdWDfp/C9QLrdWDJsxmX qxp4xFgElsZTEkQTGWYkHbx6zEz7RFqykq/1SlcX5WQ9RjPmy16hpDvvmEmmv0A3GcL6 HLSCp5yL4L6wJ82932X6X9djic9QkAGXl4cCM25kjm+J1bMx1Q53X9ivtme2uTZv8kKI Wgc+c7O5qFXbU1v8N5gb7swqmNalHRSEHxyDVGXgnzJPySQT21tPHhCi6QkTzJn/52ZU shVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tyrwULaDA/8yLqlpZdEOiGOlczFmIcq5jIHr0JXrByc=; b=aXsZp6YY62EyM1JZAE88yRE8kkSv8Tbjy9SvzhKWtczK2HE8yDyrcD59pDDN70vsom 5R23uTZyUZ6c6yNEetZeqwxohxCgNPshzj4EuOjkSo37/ggefL+nS+0i+cVnQpqbQCe+ hgjLlE+xo9diCjgKy+jKQkZwjcp8jpqy5ZNWw4NNgYafVQNkZiN6vxE/sqlEs1Z9yGr4 t6btKn0oF2aiXpjMRVJD46fW07N4aTPMb2BPlolqNfK4pB7LELBhS6CDIbWBmi0ggU0D jPeirMRosGmEClXpF+XQrfqyS0SCgdO2MmZEZC6H6bJnL5VcRBCHqX3jVZuEJyLVNckt bpoA== X-Gm-Message-State: AOAM533Xtler6zNOlzdWdEHM1pLBb3LmnLBxg3akoNCgxWdDxmDdouLI HXZkr4M2oUFjQTo16opowRXgCw== X-Received: by 2002:a17:90a:2d8e:: with SMTP id p14mr17631924pjd.131.1623664343718; Mon, 14 Jun 2021 02:52:23 -0700 (PDT) Received: from localhost ([136.185.134.182]) by smtp.gmail.com with ESMTPSA id v1sm12224241pfi.194.2021.06.14.02.52.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 02:52:23 -0700 (PDT) Date: Mon, 14 Jun 2021 15:22:21 +0530 From: Viresh Kumar To: "Enrico Weigelt, metux IT consult" Cc: Andy Shevchenko , Geert Uytterhoeven , Linus Walleij , Bjorn Andersson , Bartosz Golaszewski , "Enrico Weigelt, metux IT consult" , Viresh Kumar , "Michael S. Tsirkin" , Jason Wang , Vincent Guittot , Bill Mills , Alex =?utf-8?Q?Benn=C3=A9e?= , stratos-dev@op-lists.linaro.org, "open list:GPIO SUBSYSTEM" , linux-kernel , Stefan Hajnoczi , "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" , virtualization@lists.linux-foundation.org, Alistair Strachan Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver Message-ID: <20210614095221.7qngyzhbxbckolpj@vireshk-i7> References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> <20210611035623.z4f2ynumzozigqnv@vireshk-i7> <20210611080122.tlkidv6bowuka6fw@vireshk-i7> <0478822f-9d10-deb8-86ae-3b4ac3bb0c6c@metux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14-06-21, 11:17, Enrico Weigelt, metux IT consult wrote: > On 14.06.21 10:12, Andy Shevchenko wrote: > > > That's why we have a thing called standard. And AFAIU virtio API/ABIs > > should be officially registered and standardized. > > Absolutely. > > I've submitted my spec to virtio folks last nov, but this wasn't in form > of patch against their tex-based documentation yet (just ascii text), > thus laying around in the pipeline. > > (meanwhile the actual implementation is running in the field for over > 6 month now) > > Viresh picked it up, but made something totally different out of it. > I wonder why he didn't consult me first. Here I asked you on 26th of May, if you would be fine if I take it forward as you didn't do anything with it formally in the last 5-6 months (Yes I know you were busy with other stuff). https://lore.kernel.org/linux-doc/20210526033206.5v362hdywb55msve@vireshk-i7/ You chose not to reply. I did the same before picking up the kernel code. You chose not to reply. I am not inclined to do offlist discussions as they aren't fruitful eventually, and it is better to do these discussions over open lists, so others can chime in as well. > All that needed to be done was > translated the ascii documentation into tex and rephrase a bit in order > to match the formal terminology and structure used in virtio specs. Not really. There were things lagging, which are normally caught in reviews and fixed/updated. But that never happened in this case. You only sent the specs once to virtio list, that too as an attachment and it never made it to the virtio guys there (as the list doesn't take attachments). https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg06946.html > This makes me very unhappy. I know you have solutions running in products which depend on the layout of the config structure or request/responses, based on your original write-up, but unless something is merged in open source code or specification, it is going to get changed, normally because of reviews. And you will be required to change things based on reviews, you just can't say that I have products running the code and so I won't change it. That is why people say, Upstream first. So you don't get into this mess. Yes, this is tough and that's the way it is. You keep saying that I have changed the original specification too much, which is incorrect, I tried to point out earlier what all is changed and why. https://lore.kernel.org/linux-gpio/CAKohpokxSoSVtAJkL-T_OOoS8dW-gYG1Gs5=_DwebvJETE48Xw@mail.gmail.com/ You chose not to reply to that. Lemme say this again. This is a generic protocol we are trying to define here. It needs to take everyone's view into account and their use cases. We are required here to collaborate. A solution thought to be good enough for one person or use-case, isn't going to fly. The changes I did to it are required to make it useful for the generic solution for a protocol. I am sure there would be shortcomings, like the one identified by Jean-Philippe Brucker, where he asked to add offset of the gpios-name thing. He made a sensible suggestion, which I am required to incorporate. I just can't reply to him and say I won't change it because I have already designed my product based on this. Lets try to improve the code and specification here and make it work for both of us by giving very specific feedback on wherever you think the protocol or code is not efficient or correct. Being unhappy isn't going make anything better. -- viresh