From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753308AbdK1PCh (ORCPT ); Tue, 28 Nov 2017 10:02:37 -0500 Received: from mout.web.de ([212.227.15.3]:50765 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854AbdK1PCd (ORCPT ); Tue, 28 Nov 2017 10:02:33 -0500 Subject: Re: 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: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net> <2cbef557-5f89-c630-e108-14ef2ce6b41a@users.sourceforge.net> <1547a4c2-5b70-e3a3-b482-d28c538e615c@users.sourceforge.net> <539adde3-a713-721f-2a0d-1d1ef925fb86@users.sourceforge.net> <9a9348f4-d059-de28-1445-0189b7fb0ba3@users.sourceforge.net> <3b7b24bd-4bdf-752e-1a62-cc71e9152acc@users.sourceforge.net> From: SF Markus Elfring Message-ID: Date: Tue, 28 Nov 2017 16:01:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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:bYhp4AxOJ1GpMHJRZa0Tb/R3qX3yr7BDS+iYFbWAdyBA9MZnCNf TIIL+DfG/I5tO+cpXpr2ye3qym5MHt/TIwPUzO9F9ZzpXcg0Y+RORNfNgPpp0mPsQzskEri KcXHG5nfMWhni9rUloK6bi1279tFjOadhU15W63z6LuB6PM14IE0V/I/nNxYmu6FeXDomVZ itH/4mNK8ax1dUuqxzkAg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/HqPogAvKp0=:AIbHzHE+ll5u3BdJscp5Bv 3FiDS/CnOqckN8uL+aMZk3clhN4JH/6568Wv0Sxvhfx8r4lPv8XkuQ7eKV0A5JmhiZBu1qDOg zCZFGqZnHgSjZSP3FOtM5VGRU6eqIdTydM88YlWWW0dbYA7yHNMf8OdubnvpsLqNV6fnXiwix SIvaejROxzSxm0Kw1iWxNLAaBZRWgzmN765O0hDZFlbkZuL9xQNRNcfacfdVPR9UGeCyY8M8d 6cfQyvdtmm8/il2mFyFPBAFoZWw0yBR96ku6Cs61H+tz90mRUm5eRUfB1LcthTJl4LCUvAmyV QBP9rNyODGLdnKlGyx7cf/1c9jamvmDTDawL4TabJHLW9DyvKNoFF2Ue79OC46bydMRWu1tan OaK3riOgMf7bl29YI/fR0LhbtmU2NSCwwIt7+Sm/mD3cRtZAsCoaVwkycYEhBaFblZKluaR38 XUjAIrLtNjmANgNt8XFaKagVzl0hm/woyFJ/w/Ww/4u4uI5+w9x46a+iAQk0O1ASGUJAEs0r/ 1vnFJNltIpmH72Em5Zqgbo7/bhrsXanSvVF8PogNuWUOLR5qhAih6cRDVr548yLgAo0tm+lGz Kx4YtBIkoi9vSwRhiEI68O2U5vBDSK8LbdnhZ9AO7p922T7Bov6MJGOP5dfiGJmmwmSWsmxW9 PNCdCY+SOHVoFLPLFUPzznboq9o45rvvtD5L/unZGb5QrqC1CoarbnZ35sH2kk8WuyEBxpK0V zt9q3dHqgZF3AtwXvPxHS0pB2DH6gDAYV8X6y8vCOK2v2OtPKh0sn/ItA4XlLrJlngYoIKxm/ fkIw8RvbrjkxO5eBA5LrUgmW8Njie0+0yu5rrZ7OPAqVT1e7R4= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> Give the test result before speaking too much. >> >> Which concrete data do you expect here? > > Depends on the result. How can this vary? > The bottom line is that you run your patched kernel on the real hardware Which test configurations would you trust finally? > or equivalent (VM or emulation) for the device you touched. Can all the devices for which I dared to adjust their source code a bit tested in desired ways within virtual machines? > Run your patched kernel and the driver code on the real machine with > the corresponding device. Show the device is running. That's the > very first step. Then follow the more detailed tests, but it depends > on the subsystem. How can such descriptions improve the trust situation? Regards, Markus