From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936535AbdKPSAb (ORCPT ); Thu, 16 Nov 2017 13:00:31 -0500 Received: from mout.web.de ([212.227.17.11]:56795 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935095AbdKPRtd (ORCPT ); Thu, 16 Nov 2017 12:49:33 -0500 Subject: Re: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations To: Takashi Iwai , alsa-devel@alsa-project.org Cc: Arvind Yadav , Jaroslav Kysela , Takashi Sakamoto , kernel-janitors@vger.kernel.org, LKML References: From: SF Markus Elfring Message-ID: Date: Thu, 16 Nov 2017 18:48:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BhLNZPK2IXmIaGURXp7759dnKmNQzBMNKVaWr2RIE/L7dysXKr/ p284VVPtXHPUvzyY9TWSVs7A93+zeS9TLRKdRRYpSqHbf95eY5/s4Y7D38SDap217dHwY3c rqmqj5U/smfOPSvK2WSLk4aFizijjU+Z8wSuPxikqtbjH5wn9U71F8DuQDEx4ZgUjfmoZx2 n3WP68LFbROZJRN+G7Pcg== X-UI-Out-Filterresults: notjunk:1;V01:K0:X0nqNmlsqZw=:7MD8Qj1xAMb31Fnc7STjda mELF7jwHZd6MNDIksNPtXIE/EiClTkuAIElwQtwWSvH3H8uYnhZZEXpA9gSeux5lBtVD6O43S oP2zYBpb4qF+58Ps8Kn7xL4nWeFoKG2JKLp1i24fufWYM+5uMhCEiLEOUpEfXF6TmKapuB4o+ 9Y7D8UAIwlwoK+Xfvwq2bH7CKAFr0XztkDlc2IsLmKtQJzS1nJGNrzmQpuxBBH3a93zBL39uP ztoLhkl7bjLEmqE87f75vl9UXYeME8aeaIkq2YVHlR3ZPKdEyicZt5SBtUXMW1TDeZ+x/CXnO 2iJawED4d6R9loNuBzQFp0ZxNsOhyMDB6vn6EU+qwpzGVae9WQFPwW1G+CuXha7sYqoBABhL/ dRc1qCoNy9uxZO24gd6Blydehvt5Nt/RZzolJ3FOZUUNlyveUrr/CzF2df+0dEpyBluDT9k2e rlNn9kDOX+JZKkQKoY9qdOB1o17s4dRhrwreFpfE38ARJci5X4QuB5ixmGN4VEioN6WBcdsN0 9FCEUbR+Pl4QQqzeV1WI9HHveC8E7MPyZTQUGv4PQ8Lj1Z2cHKnup6gbA5dAO64j3GyqMjt4g 2+1YQzAwnbWBJnyOd5QIJNPoY9oClCsxo+fbkV2m/io9CZXv6ouGl3IhxHtBo8cEFv2ELVWsQ 0eD8uWEkSEIPbaiO/9efOnm2xK7Dt8P1N4Z7M2PpO3Z9Dld8x0hs+cEcYk33htU0SFZiBDPBP 7yIXEjPIWLHvHQiLVNHlalkDKGWpQA8guUQ98efOJ8aOzA+dTR1xTLpd5kKaGWocTHJmaRq4g s2UGjA0OZGMyUdbd1R5TTtLkZvm+LEsCo/UQWpc++wbF0k8ORk= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> Two update suggestions were taken into account >> from static source code analysis. > > Markus, I'd apply this kind of patches only when they are really > tested on the hardware, I can not test all software and hardware combinations (so far) for which I dare to show change possibilities. > or they were converted systematically by a script like spatch. There is a general source code transformation pattern involved. So I find that it is systematic. But I did not dare to develop a script variant for the semantic patch language (Coccinelle software) which can handle all special use cases as a few of them are already demonstrated in this tiny patch series. > The reason is that you might break something There are the usual software development risks. > (and you already broke things in the past). I presented also some improvable update suggestions. Another look on the corresponding circumstances might be interesting for further clarification. > The merit by such a patch is negligible in comparison of the risk of breakage. I imagine that you might like a small object code reduction also for this software module. > These codes aren't too bad without fixing, after all; > everyone can read it pretty well as is. The script "checkpatch.pl" points implementation details out for further considerations. > If these patches were tested on a real hardware, I assume that this aspect can become a big challenge. > or at least on VM, so that you can show that they don't break anything, Which test results would you trust (from me)? > I'll happily apply them for the next (4.16) kernel. Thanks for your general offer. > Or, if you're really working on other real changes I would find a bit more efficient exception handling useful. > (no cosmetic coding style fixes nor the code shuffling, I propose to apply also corresponding checkpatch cosmetic. > but fixing a real bug) I am trying to adjust the software situation a bit more for better run time characteristics. > *and* such a cleanup is mandatory as preliminary, it can be accepted, too. There are change combinations needed for the proposed software design direction. Can you see positive effects here? Regards, Markus