This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 5 02:06:30 2024 >From mailfetcher Tue Apr 30 18:29:37 2019 Envelope-to: lkml@grols.ch Delivery-date: Tue, 30 Apr 2019 18:29:36 +0200 Received: from stout.grols.ch [195.201.141.146] by 72459556e3a9 with IMAP (fetchmail-6.3.26) for (single-drop); Tue, 30 Apr 2019 18:29:37 +0200 (CEST) Received: from vger.kernel.org ([209.132.180.67]) by stout.grols.ch with esmtp (Exim 4.89) (envelope-from ) id 1hLVdQ-0005La-41 for lkml@grols.ch; Tue, 30 Apr 2019 18:29:36 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726552AbfD3Q33 (ORCPT ); Tue, 30 Apr 2019 12:29:29 -0400 Received: from mga05.intel.com ([192.55.52.43]:20323 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726028AbfD3Q33 (ORCPT ); Tue, 30 Apr 2019 12:29:29 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 09:29:24 -0700 X-ExtLoop1: 1 X-Ironport-AV: E=Sophos;i="5.60,414,1549958400"; d="scan'208";a="147139281" Received: from cng16-mobl.amr.corp.intel.com (HELO [10.252.205.95]) ([10.252.205.95]) by fmsmga007.fm.intel.com with ESMTP; 30 Apr 2019 09:29:22 -0700 Subject: Re: [alsa-devel] [PATCH v3 2/5] soundwire: fix style issues To: =?UTF-8?Q?Vfi=06inod_Koul?= Cc: alsa-devel@alsa-project.org, tiwai@suse.de, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, liam.r.girdwood@linux.intel.com, broonie@kernel.org, srinivas.kandagatla@linaro.org, jank@cadence.com, joe@perches.com, References: <20190411031701.5926-1-pierre-louis.bossart@linux.intel.com> <20190411031701.5926-3-pierre-louis.bossart@linux.intel.com> <20190414095839.GG28103@vkoul-mobl> <08ea1442-361a-ecfc-ca26-d3bd8a0ec37b@linux.intel.com> <20190430085153.GS3845@vkoul-mobl.Dlink> From: Pierre-Louis Bossart Message-Id: <72ff2d4f-85a7-b117-3d51-229c5f421734@linux.intel.com> Date: Tue, 30 Apr 2019 11:29:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Mime-Version: 1.0 In-Reply-To: <20190430145444.GU3845@vkoul-mobl.Dlink> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: -1.9 X-Spam-Score-Bar: - X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: RCVD_COUNT_FIVE(0.00) Symbol: BAYES_HAM(-3.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_EXCESS_QP(1.20) Symbol: TO_DN_SOME(0.00) Symbol: PRECEDENCE_BULK(0.00) Symbol: MIME_GOOD(-0.10) Symbol: DMARC_POLICY_SOFTFA On 4/30/19 9:54 AM, Vfiinod Koul wrote: > On 30-04-19, 08:38, Pierre-Louis Bossart wrote: >> On 4/30/19 3:51 AM, Vinod Koul wrote: >>> On 15-04-19, 08:09, Pierre-Louis Bossart wrote: >>>> >>>>>> >>>>>> Signed-off-by: Pierre-Louis Bossart >>>>>> --- >>>>>> drivers/soundwire/Kconfig | 2 +- >>>>>> drivers/soundwire/bus.c | 87 ++++++++-------- >>>>>> drivers/soundwire/bus.h | 16 +-- >>>>>> drivers/soundwire/bus_type.c | 4 +- >>>>>> drivers/soundwire/cadence_master.c | 87 ++++++++-------- >>>>>> drivers/soundwire/cadence_master.h | 22 ++-- >>>>>> drivers/soundwire/intel.c | 87 ++++++++-------- >>>>>> drivers/soundwire/intel.h | 4 +- >>>>>> drivers/soundwire/intel_init.c | 12 +-- >>>>>> drivers/soundwire/mipi_disco.c | 116 +++++++++++---------- >>>>>> drivers/soundwire/slave.c | 10 +- >>>>>> drivers/soundwire/stream.c | 161 +++++++++++++++-------------- >>>>> >>>>> I would prefer this to be a patch per module. It doesnt help to have a >>>>> single patch for all the files! >>>>> >>>>> It would be great to have cleanup done per logical group, for example >>>>> typos in a patch, aligns in another etc... >>>> >>>> You've got to be kidding. I've never seen people ask for this sort of >>>> detail. >>> >>> Nope this is the way it should be. A patch is patch and which >>> should do one thing! Even if it is a cleanup one. >>> >>> I dislike a patch which touches everything, core, modules, so please >>> split up. As a said in review it takes guesswork to find why a change >>> was done, was it whitespace fix, indentation or not, so please split up >>> based on type of fixes. >> >> With all due respect, you are not helping here but rather slowing things >> down. I've done dozens of cleanups in the ALSA tree and I didn't go in this >> sort of details. > > Thats fine, it is upto people, everyone has different views, mine is > different from Takashi's. We all know for example networking has > different stable and code style rule. That is how it is and I dont think > we would have one rule for all kernel. > > All I ask is to be able to review and split up accordingly, I guess that > is a fair request > >> The fact that the series was tagged as Reviewed by Takashi >> on April 11 and we are still discussing trivial changes tells me the >> integration model is broken. > > Is it? you got feedback on 15th (that too after my 2 week conf/vacation > break) and I got called crazy for that, not helping!! > > >> It's not just me the patches related to >> runtime-pm from your own Linaro colleagues posted on March 28 went nowhere >> either. > > Does it matter it was a Linaro colleague or not, a patch was posted, > feedback given (similar to cadence one) we agreed that the fix > is not correct and so patch was not applied. I don't think Srini cried > over it! > >> Moving forward, I suggest we merge SoundWire-related patches through the >> sound tree. There will be dependencies in the coming weeks between SOF and >> SoundWire and it makes no sense to have separate maintainers and make the >> life of early adopters more complicated than it needs to be. If we have >> 3-week delays for trivial stuff, I can't imagine what the pace will be when >> I publish the next 20-odd patches I am still working on, and the code needed >> for the SoundWire audio device class being standardized as we speak. Things >> were fine up to now since no one was actually using the code, we are in a >> different model now. > > I disagree and wont accept it. I dont think you understand that you are > not the most important person in the whole world, the 20 patches series > you are cooking would sure be greatest ever, but that is not the point. > The kernel has a process, you got a feedback, please fix that and post > v2 rather than cribbing, complaining and calling crazy. The energy would > have been better spent on fixing the feedback provided. > > Dependencies are _always_ there in kernel development and we know how to > deal with it. Am sure Takashi, Mark and me can come to reasonable > agreement, I wouldn't worry about that! > > What we dont do is create new model for your 20 patches. > > And I guess I dont have anything more to say on this thread, so I wont > bother replying, please feel free to post v2 and I shall review. Friends have disagreements. We remain friends and I will provide a v2. I still believe it makes no sense to split the integration of SoundWire-related patches in two different trees. The only rationale for it might be that SoundWire is a 'bus' than could be used in other areas. Except that for now and the foreseeable future (2022+) it's only for audio as a replacement of HDaudio, so the pragmatic way of dealing with SoundWire is to merge the code through the audio tree. And given that the code is not in a usable state at the moment, dealing with the audio tree would not have any negative impact on anyone.