From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 379C5C433F5 for ; Tue, 12 Apr 2022 15:56:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241045AbiDLP6a (ORCPT ); Tue, 12 Apr 2022 11:58:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357469AbiDLP5R (ORCPT ); Tue, 12 Apr 2022 11:57:17 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CAB18388 for ; Tue, 12 Apr 2022 08:54:52 -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 sin.source.kernel.org (Postfix) with ESMTPS id 40D2ACE1F65 for ; Tue, 12 Apr 2022 15:54:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C0B4C385A1; Tue, 12 Apr 2022 15:54:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649778889; bh=dbQHjtWTndQ3IhJbJ7Bf8ue3XoQqen/tZP8psUGBdro=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=D0Flk52zzKTiOJtrDbgYOw3HQZfvDWYR5IKWnmBiBv05GWrNgJEFRwVa7lDxf2EDo SZIZG3XhBYGNiBN8PR23PBJWk6w73PpfhJ23BSXmSq0vypF4dM+TRah0cQD6APe0xP zZBeatO+KMyPwMoUvG1R1aTl//Qvq68wnbq4gPXw= Date: Tue, 12 Apr 2022 17:54:46 +0200 From: Greg 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> <37e5203d1efd310ea82cf91c18c6a07eea743ac7.camel@codeagain.dev> <20220412151432.zsdxrag7myyzgv6o@AN5Bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220412151432.zsdxrag7myyzgv6o@AN5Bruno> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 12, 2022 at 12:14:32PM -0300, Bruno Moreira-Guedes wrote: > On Sun, Apr 03, 2022 at 01:05:44PM +0200, Greg Kroah-Hartman wrote: > > > >On Fri, Apr 01, 2022 at 03:21:50PM -0300, Bruno wrote: > >> With my tests in my, I have found two other things that I think are > >> remarkable to mention. First one is a missing `depends on` line for > >> `VME_BRIDGE` in drivers/staging/vme/devices/Kconfig, not visible > >> because they were in the same tree, but now unveiled. I'm fixing it, > >> do you think it's best to add it in the same patch? > > > > Make that a second patch, and resend it as part of a patch series since > > your first patch here is gone from my queue. > > This patch is already sent, so I'll trim most of this message to avoid > duplicating the discussions. There's only one thing I'd like some input > first, if you don't mind. > > >> Do you think it would be interesting for a future patch to provide > >> some output when drivers from the staging tree are present in the > >> running kernel image? > > > > If you can figure out how to do so, that would be interesting to see. > I think I might have figured out. In "include/modules.h" and > "include/init.h" I happened to notice the driver initialization is > handled by some macros. After some inspection through gcc -E and looking > how they are defined, I figured out a scenario (when MODULE is not > defined) where the module_init() macro is defined as (among other > things) an inline initcall function that wraps the driver initialization > function. > > So I thought about implementing it by creating a -DSTAGING flag in > drivers/staging/Makefile, and then using this macro to make an #ifdef > STAGING to add a similar inline wrapping function, except that in this > case the function makes a pr_warning() before calling the initialization > function. > > Do you think it would be a good way of solving that? Yes, that would be a possible way, try it and see! greg k-h