Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1750988AbdFQEQn (ORCPT <rfc822;w@1wt.eu>);
        Sat, 17 Jun 2017 00:16:43 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:36506 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750733AbdFQEQl (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 17 Jun 2017 00:16:41 -0400
Date: Sat, 17 Jun 2017 06:16:35 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
        Brian Norris <computersforpeace@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        Fengguang Wu <fengguang.wu@intel.com>, shuah@kernel.org,
        LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
        linux-kselftest@vger.kernel.org, yi1.li@linux.intel.com,
        takahiro.akashi@linaro.org, Martin Fuzzey <mfuzzey@parkeon.com>,
        Alan Cox <alan@linux.intel.com>
Subject: Re: LTS testing with latest kselftests - some failures
Message-ID: <20170617041635.GA26923@kroah.com>
References: <CAO_48GFNXyqTDN85y8FKLV3wj19JJ28sWXuX4Vex3LVzaxzGCw@mail.gmail.com>
 <20170616164651.GA21846@wotan.suse.de>
 <20170616192952.GA22037@kroah.com>
 <20170616194721.GE21846@wotan.suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170616194721.GE21846@wotan.suse.de>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 925
Lines: 20

On Fri, Jun 16, 2017 at 09:47:21PM +0200, Luis R. Rodriguez wrote:
> Some of the knobs however are for extending tests for
> existing APIs in older kernels, the async and custom fallback one are an
> example.  There are a series of test cases later added which could help
> test LTS kernels. Would Linaro pick these test driver enhancements to help
> increase coverage of tests? Or is it not worth it? If its worth it then
> what I was curious was how to help make this easier for this process to
> bloom.

I don't understand, what do you mean by "pick these test driver
enhancements"?  What kind of "knobs" are there in tests?  Shouldn't the
tests "just work" with no kind of special configuration of the tests be
needed?  No user is going to know to enable something special.

Make the tests "just work" please, because given the large number of
them, no one is going to know to look for special things.

thanks,

greg k-h