From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935674AbcIWLti (ORCPT ); Fri, 23 Sep 2016 07:49:38 -0400 Received: from mout.web.de ([212.227.15.14]:49893 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759472AbcIWLtg (ORCPT ); Fri, 23 Sep 2016 07:49:36 -0400 Subject: Re: GPU-DRM-TTM: Fine-tuning for several function implementations To: =?UTF-8?Q?Christian_K=c3=b6nig?= References: <566ABCD9.1060404@users.sourceforge.net> <4d34446f-05ad-c3ce-5d33-8fb4f25af25c@users.sourceforge.net> <05418fb1-ad66-aba3-bd8c-f6b684a83279@users.sourceforge.net> Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Emil Velikov , Julia Lawall , kernel-janitors@vger.kernel.org, LKML From: SF Markus Elfring Message-ID: <160f8c46-3601-aca9-cccc-054531cf16a8@users.sourceforge.net> Date: Fri, 23 Sep 2016 13:49:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oIW3QvizIcGfo2mgxlS5k5P5wCCPpxA98pLr5wogz9BOX7skHG+ NYwh4LscnNNoDB4E3IEzy9pRItVZKGJikoWM+0FfMxWEj4a0LSUI8gpO7cE3uRQlQbPYoNd phtt9xQTwocXisUUD3unFtHmnWrsHR1FvNtuEzboOZe2iiwiomOLYgNK2d7duLx9KDnow0j dJCZdvEn6W5/toq9yN60Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:bfTf5zWQg1E=:Vq2QWwY28E6UMNRfYPcgvq chAGAh7uWlxpC1wpVBpAwQ6usr63z8xd/GomWBa1ek2wuColcfhpc2p87tfpECt9quLv8MySP OtB9Xk+VUGtpQ2S7qUw+aLEl3qkyWcAgcYD5Dxy8cVKniWTOfnz1y3zX8+TXYmF177/hDnMqh s7XGVt63q0W9oBFNNXAvWJV4gJ8+mVkR1EY0At/drAb16H+N4wMAS95mhlEFleXFLEhfToGFE tX29j8HlYDiWcMNjU+RQJ/w2IzSZNsKqTwN0J9VN3EfIETJNgSwwfoECYaZFKBA/ICm+MLv8P yb4+I7Jv5rbxpInw7hzZLRPmcytRp5ALtJGzLZ6o5djnHpTLkpwmnvyqrbmrkeiT8ItH0sP5f Fr3h454RZEz1pg72bMxjRNHRzgysEnKW+mpH+cO/hvlwr2i6NoQfPm/IfnF4ZlsQSco0jVJJw EVRw0MLpCrcP2YMlFppJA+CX0XgSpRJAYzKkbfVSlLZsGzxcqi+cY6CcbDVi0AkSEqlJJaxGw 9bVipM3sJgfQcRn4Rzrmdiq0bl4pk+GSNjcujB5kx5fCDQ5VHCepJU0DDfjUhEE/QMaaX+csN 5BZ272Z9fEJRWHAK/G/+CwAk9mh7IVfuSHPOZ4P0DvuC+TAZ3AejDx7Rz//DMJ7aTU2TntLHQ Z/KaHw9nkQ2mAJW+qFY20izlpfaNI8Dk8CZMucyDpHaz4r12iHAK92dvj30psics6AMjoXnL+ MSaj3HP6667sI7dIURehV+L+EsMn7Z6n74kIpE4qaBL9Os6rLPdZiXZxJqPcfRVcbkyWP9A/u vfBnLFR Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Calling the label "unlock" instead of "out" is arguable a little better, Thanks that you can follow a renaming for this direction in principle. > but nothing I would call a major improvement either. This was not my intention for such an use case. I am proposing some small software updates according to such a design pattern. > So that is a clear NAK to all those patches. Do you reject also update steps like the following then? * drm/ttm: Use kmalloc_array() in two (or four?) functions" * drm/ttm: Less function calls in ttm_dma_pool_init() after error detection * Would you like to improve the usage of the variables "n" and "t" in the function "ttm_dma_pool_init" any further as Joe Perches suggested it? >> 2. How do you think about to add a single space character before any label? > > Bad as well. Why would anybody want to do this? Do you find another software evolution interesting according to a recent commit? "docs: Remove space-before-label guidance from CodingStyle" https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=79c70c304b0b443429b2a0019518532c5162817a Regards, Markus