From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Tue, 28 Nov 2017 15:01:47 +0000 Subject: Re: ALSA: nm256: Fine-tuning for three function implementations Message-Id: List-Id: 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> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Takashi Iwai , alsa-devel@alsa-project.org Cc: Arvind Yadav , Takashi Sakamoto , kernel-janitors@vger.kernel.org, LKML >>> 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