From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753595AbbIIAGT (ORCPT ); Tue, 8 Sep 2015 20:06:19 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:22584 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752310AbbIIAGR (ORCPT ); Tue, 8 Sep 2015 20:06:17 -0400 X-AuditID: cbfec7f5-f794b6d000001495-0d-55ef77f637d0 Subject: Re: [PATCH] ARM: exynos_defconfig: Enable USB Video Class support To: Javier Martinez Canillas , linux-kernel@vger.kernel.org References: <1441662323-15468-1-git-send-email-javier@osg.samsung.com> <55EE9820.2010202@samsung.com> <55EE9F1A.9030703@osg.samsung.com> <55EEDECA.4040407@samsung.com> <55EEE370.9040705@osg.samsung.com> Cc: Kukjin Kim , Thierry Reding , Anand Moon , Russell King , linux-samsung-soc@vger.kernel.org, Lukasz Majewski , linux-arm-kernel@lists.infradead.org, Bartlomiej Zolnierkiewicz From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <55EF77EE.10301@samsung.com> Date: Wed, 09 Sep 2015 09:06:06 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 In-reply-to: <55EEE370.9040705@osg.samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42I5/e/4Zd1v5e9DDT6eUbHYOGM9q8Wbt2uY LF6/MLTof/ya2eLNw82MFpseX2O1uLxrDpvFjPP7mCzWbbzFbnH7Mq/F7d98DtweLc09bB47 Z91l99i0qpPNY/OSeo/e5ndsHlv6gUJ9W1YxenzeJBfAEcVlk5Kak1mWWqRvl8CVMe3KFvaC U1IVy+ZvZW9gbBHtYuTkkBAwkfi5/hsbhC0mceHeeiCbi0NIYCmjxL13zUwQzhdGiUvXu1hA qoQFvCSmnP/ODGKLCIRK/Lt4mxGi6ByjxLYfK8AcZoFDTBLPvpwEm8smYCyxefkSqB1yEr3d k8Am8QpoSJydswwsziKgKtE3ey4TiC0qECFx6uxbNogaQYkfk++B1XMK6Eu83XQAaDMH0AI9 ifsXtUDCzALyEpvXvGWewCg4C0nHLISqWUiqFjAyr2IUTS1NLihOSs810itOzC0uzUvXS87P 3cQIiZ6vOxiXHrM6xCjAwajEw6vh8S5UiDWxrLgy9xCjBAezkgjvXvH3oUK8KYmVValF+fFF pTmpxYcYpTlYlMR5Z+56HyIkkJ5YkpqdmlqQWgSTZeLglGpg7Hfrn+X9+5Ctep6i3a8nH/1v uOae3nCXrU7i9BPtf683pIamn9I1Dg3OSfLJMPtsY2VY8P1PHqvGsdfK71XnnJRfXJa4cWeW t9OuTcyHtj3dF/H+MXPHfwthl3NucVf+mk/J9vNgmRjree3AIp2FnDN2PrDLm6Vy7E3EDB5/ tgu/mn6fqdysqsRSnJFoqMVcVJwIAJ25rTCaAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08.09.2015 22:32, Javier Martinez Canillas wrote: (...) > >> Let me rephrase my question into: >> 1. What is worth enabling in exynos_defconfig? USB devices? I would >> argue, except they are needed to boot. > > Ok, I understand your concern. The question is where we draw the line. > >> So maybe enable everything which Exynos boards have hard-wired? That >> would make some sense... but we're making kernel larger. >> > > In the case of this WebCam, it's not a typical USB device in the sense > that is built in the Chromebook and not something that's plugged on an > external USB port. Right, that is the difference from regular USB devices. > >> 2. Maybe enable only what is a typical use case (including typical >> testing cases)? Then we would have to define what "typical" means. For >> example battery would be typical but camera would not. >> > > There are a lot of board specific drivers that we currently enable as > built-in like hwmon sensors or iio devices that are likely only present > on a single board or a family of boards. > > So then I think all those drivers should be changed as a module as well, > unless are critical for the board operation (i.e: thermal or fan drivers). Actually I think we should not judge by number of board using given component but its usefulness in general exynos_defconfig case. Even when something is used on just one board but it is important for that board, then it should be built-in. For example hwmon monitoring stuff to get information about board condition. Other example are leds on Odroid - to get visible condition of the board. This don't have to be critical, but just important for testing. Additionally such components can be accessed usually from limited user-space, e.g. system booted to console or SSH. If using a component requires more complex user-space (e.g. any kind of window system), then probably already modules could be easily used. In such cases I would expect the boot is not from network but from MMC and there is a full-blown distro working. >> 3. Argh, so maybe, if we agree that not everything is worth being >> enabled, that additional stuff could be build as module? >> > > Yes, I don't see anything wrong to enable more stuff as a module if > that will give more build / test coverage. > > The goal of kernelci is to add functional tests so besides testing > if a given kernel booted correctly, it's going to test if for example > USB enumeration is working and has no regressions. For that use case > is interesting to have support for the built-in USB devices like this > camera (either as built-in or as a module). Okay, so we have some agreement that other stuff which is not important but still hard-wired on Exynos boards (built into the board), can be enabled as a module. So now we we have to draw the line which is "important enough" to built-in and which is not so it could be as module. >>From my point of view media in general (cameras, tuners etc.) should be put in the second category (module), especially that in usual to test them you would have to boot system to a full graphical mode. Can you test them from SSH connection? Maybe you could test DVB tuners by reading status of packets but still output won't be visible. Any comments from other interested parties? Best regards, Krzysztof