Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1853599pxb; Sat, 2 Apr 2022 06:04:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz40eauK+P6OSQNU1zFvMVDptvmGO+/gGOkMgGRhLUEkjX7Hpnr4iMVtxDFHF3zEtuuI+Lq X-Received: by 2002:a17:907:3e1a:b0:6e0:5ba8:8e0f with SMTP id hp26-20020a1709073e1a00b006e05ba88e0fmr3611209ejc.581.1648904669423; Sat, 02 Apr 2022 06:04:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648904669; cv=none; d=google.com; s=arc-20160816; b=QvUBW1deXoKVJhQC3mwiTflEuf7yg52GtC1lrtaYO/uPUToIc0b48TxZBO9Jg/dhMY XSE61P98KjicPoVN/xK7sJt7udyFsu4ZAABfZGkuZLBKjsJ8b9r3V0E38ZEdpCO0/GwC w6iTb5yGCd38hhjp2I+8B8FZ4jRNlbtCGimnuSapGQG98SgN1tjhFZwUkmZ8ulFlbnp+ UbqTz3DHgKxpazimqwb5pdylMP3QeidIXzl6kqdS2iW8m9cwVlNNAIqklZxsGxQx2rQS iGBjjk73Ns7GTIOA1LcHXCxFW/Hoi11l9EAkqadUJ7u271Jfo+x+OsccuGrzRv23PPGN deOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kfwBWFWfOHC8bjArIU07VGdOycnfNJJBN0AlwV+rWHA=; b=ycVosg2+HQE6+d5oG5LLT3Eor1vfAHhh8l9XCqcM6pNkYq2HR1CIR7RUB5P8Hkj6zx bNk+5xhgfSUxCKDse0pV7CHGWvv7D3sEZIFIBHQE1plbzWXnDdaGjImRcj5Vu0h+dT9y LUn/c0wVXQOX2RWMXe+W+ny6e4UPqaJoQcUQWKw6ebE6LX29/uD0Pgonvj5ttM1AKB9i YR8ure/0BeBJNAAlL3sMGwQyRUO5C4KWWIy5i55W/8rcnJsVoYHkXrcPT6I2fxbL6gMv LlefNJj8PpjqBZG92HbPhY0zIhpKjbm0i12PIoWY5ItWeNErP+owflVuYUdJq8sd3NMe NjUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=TvE+JXsj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a50cf05000000b00418c2b5bd2fsi3324892edk.17.2022.04.02.06.04.04; Sat, 02 Apr 2022 06:04:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=TvE+JXsj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245290AbiDAGMP (ORCPT + 99 others); Fri, 1 Apr 2022 02:12:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235432AbiDAGMN (ORCPT ); Fri, 1 Apr 2022 02:12:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A13B54699 for ; Thu, 31 Mar 2022 23:10:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 16F3BB823DC for ; Fri, 1 Apr 2022 06:10:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AB3AC340EE; Fri, 1 Apr 2022 06:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1648793421; bh=rozckvYCH6DkysLLr4xlH/qYY4wlewysqNuUHaglUy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TvE+JXsjadyuO6RU/3z5Q/sYwPrHJ7r4p17AoSkNq2lryy4xj0H0uB8gqD4ZRiSBa eb/i7wtl0mm4nnNuTEovIUQADYiGJo+Ormixd7fmpgCcU214wZ56Y+PW3CWJ6AGnTP y+7F27D+Y6DjsqKx1TzeqmghNRazUs4v3X3vaN5c= Date: Fri, 1 Apr 2022 08:10:14 +0200 From: reg Kroah-Hartman To: Bruno Moreira-Guedes Cc: Martyn Welch , Manohar Vanga , linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, outreachy@lists.linux.dev Subject: Re: [PATCH] staging: vme: Adjusted VME_USER in Kconfig Message-ID: References: <20220401050045.3686663-1-codeagain@codeagain.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 01, 2022 at 08:08:17AM +0200, reg Kroah-Hartman wrote: > On Fri, Apr 01, 2022 at 02:00:45AM -0300, Bruno Moreira-Guedes wrote: > > Currently, the VME_USER driver is in the staging tree Kconfig, unlike > > other VME drivers already moved to the main portions of the kernel tree. > > Its configuration is, however, nested into the VME_BUS config option, > > which might be misleading. > > > > Since the staging tree "[...] is used to hold stand-alone[1] drivers and > > filesystem that are not ready to be merged into the main portion of the > > Linux kernel tree [...]"[1], IMHO all staging drivers should appear > > nested into the Main Menu -> Device Drivers -> Staging Drivers to make > > sure the user don't pick it without being fully aware of its staging > > status as it could be the case in Menu -> Device Drivers -> VME bridge > > support (the current location). > > > > With this change menuconfig users will clearly know this is not a driver > > in the main portion of the kernel tree and decide whether to build it or > > not with that clearly in mind. > > > > This change goes into the same direction of commit 4b4cdf3979c3 > > ("STAGING: Move staging drivers back to staging-specific menu") > > > > [1] https://lkml.org/lkml/2009/3/18/314 > > > > Signed-off-by: Bruno Moreira-Guedes > > --- > > drivers/staging/Kconfig | 2 ++ > > drivers/vme/Kconfig | 2 -- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > > index 932acb4e8cbc..0545850eb2ff 100644 > > --- a/drivers/staging/Kconfig > > +++ b/drivers/staging/Kconfig > > @@ -88,4 +88,6 @@ source "drivers/staging/qlge/Kconfig" > > > > source "drivers/staging/wfx/Kconfig" > > > > +source "drivers/staging/vme/devices/Kconfig" > > + > > endif # STAGING > > diff --git a/drivers/vme/Kconfig b/drivers/vme/Kconfig > > index 936392ca3c8c..c13dd9d2a604 100644 > > --- a/drivers/vme/Kconfig > > +++ b/drivers/vme/Kconfig > > @@ -15,6 +15,4 @@ source "drivers/vme/bridges/Kconfig" > > > > source "drivers/vme/boards/Kconfig" > > > > -source "drivers/staging/vme/devices/Kconfig" > > - > > endif # VME > > -- > > 2.35.1 > > > > > > The problem with this change is that you just changed the initialization > order of the drivers if they are built into the kernel. Are you sure > that you can initialize a vme device driver before the vme bridge and > bus code is run? I don't know if that will work properly, which is why > the Kconfig entries are in the order they currently are in (we preserved > the link order.) > > It's not an obvious thing at all, sorry, but build order defines link > order, which defines the order in which things are initialized in the > kernel. > > So I can't take this change unless you are able to prove that it still > works properly on the hardware that these drivers control. Do you have > this hardware to test this change with? Oh wait, it's the Makefile order that controls this, not the Kconfig order. Sorry for the noise here, it's still early... So this change _should_ be fine, but it would be good if you could prove it still works with some build tests. How did you test this change? thanks, greg k-h