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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B6A68C38142 for ; Thu, 19 Jan 2023 05:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xlAfNDFgfoRodKHsfJEhY2fJdch3qHoeipts5BoJIwY=; b=I8QZVxrEgxfCZW Y4VY9JZw0FEBaE55Mlu0vATMuSpMD1OXRpNW/2IUN9bM43CY65+AySqhRhN++KzxnqGofkoxiogL+ J8S1Aw0+aeSc2y0FGMkefEKAqci8xjSxsW9jokDNg0Yngc6S9JdHmLXRNyflqDMcwPutC2PiJ5AP+ zK3sea02+/n6PmvURSxEXO3nk7yyXLJxn7/y43DxPrN4rb+rlUMuXJc86WxOmhj4Ur5DuY1r1wA2h HV4oJSepAZ5cpCbJt2QFgKy5iGPoyfu150feLXwXnxp6j3J+7khb2WWCrgAQbCLZS7uoqCukp28Pf F0d/7kjhWW9DLD4DIMjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pINCj-003dwi-Ss; Thu, 19 Jan 2023 05:11:14 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pINCd-003dvu-Iq; Thu, 19 Jan 2023 05:11:11 +0000 Received: by mail-wr1-x435.google.com with SMTP id bk16so684892wrb.11; Wed, 18 Jan 2023 21:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/Tjbpu1SxuTEzHSu4hfhiQLazDPHI+RGvql9dhrL0NQ=; b=BZHdfb3xC+QUE9x42xdBIAVgRdnD+oADJ+j2t4Lg6k78gutt71TMP9p8T+msJiZLIW 68FHTJK0KLA+8x8xskBC/94eRIK+woqo4c+qzMJ9LmNyJ4u3pMllBanunBPvsFnpuFeD oZuY10iqQwhG5MKy8hFDgr1RjYdNSskxz4NMVGMsHKZ9Ki5TQOmf5zfnMvDcyW+Hrxbt a0ddXCwV2bS+CxdnI6AooGaamiMFE/oji8rb7DFd8OIQYcJQTuRqMYenigUzUaWCeI7X /VmWlrYtGA+JyOGyj3ms51Ccgq0EmxO3R6QTOBot5p6pFTLf1E/K0yXLEuZDhKnyd/1W Ce8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/Tjbpu1SxuTEzHSu4hfhiQLazDPHI+RGvql9dhrL0NQ=; b=DMNrItcTA0OwNbjLddbUuvC5hKY90sw2JUb6pfBtrq9h0XD0mS1k/KzSxAA3EI4jNk HVEQo7PTBN6Cyay2l1mHBBPbC6VsSL7qRHeX2Xxsq/lVyUFvsq1Nk2w+P+ajJutKMEBf u2wtFEFir6HbbYLS1Qthp+ZkbG+EbJUkmI8QkoMTlC9fgBb+Rl8ocmR30+MoOlIdBxeA czDxxKnuXmQT3cG0ZvsNRwu9njKMdy9t8XnaZhWDUcVDBQEfdsw7o4eBGbixqMeT7axr cYgIDsZOVivDNevxiUvc7RiIYWE2joA7ApP8Wd5KbwHjDFbBMVq50kE2hlB/vowZPE4u h7Ig== X-Gm-Message-State: AFqh2kogZPpuQ/tt8iBcwjqFl62My1KsOVtYmo80amWdGbPKXaUR3QMJ HzpDLMBdLOkUeUCwsO80H7g= X-Google-Smtp-Source: AMrXdXtJite6JKf4pGTxLI2ygDKj1sCVv+/+7k0s80+bC+EzVSmIycwrf+SCCakYVITW5cqgnqALEQ== X-Received: by 2002:adf:f085:0:b0:2bd:d4bd:581d with SMTP id n5-20020adff085000000b002bdd4bd581dmr4037847wro.53.1674105063778; Wed, 18 Jan 2023 21:11:03 -0800 (PST) Received: from localhost ([102.36.222.112]) by smtp.gmail.com with ESMTPSA id t13-20020adfe10d000000b002b6bcc0b64dsm20494305wrz.4.2023.01.18.21.11.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 21:11:03 -0800 (PST) Date: Thu, 19 Jan 2023 08:11:00 +0300 From: Dan Carpenter To: Stefan Wahren Cc: Umang Jain , Phil Elwell , linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , linux-rpi-kernel@lists.infradead.org, Florian Fainelli , Adrien Thierry , Dave Stevenson , Kieran Bingham , Laurent Pinchart , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] Drop custom logging Message-ID: References: <20230118115810.21979-1-umang.jain@ideasonboard.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230118_211107_994997_D832204F X-CRM114-Status: GOOD ( 20.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 18, 2023 at 06:54:56PM +0100, Stefan Wahren wrote: > Hi Umang, > > [add Phil] > > Am 18.01.23 um 12:58 schrieb Umang Jain: > > Drop custom logging from the vchiq interface. > > Mostly of them are replaced with dev_dbg and friends > > and/or pr_info and friends. > > > > The debugfs log levels (in 4/4) are mapped to kernel > > logs levels (coming from include/linux/kern_levels.h) > > Would like some thoughts on it as I am not sure (hence > > marking this is RFC) > > > > From drivers/staging/vc04_services/interface/TODO: > > > > """ > > * Cleanup logging mechanism > > > > The driver should probably be using the standard kernel logging mechanisms > > such as dev_info, dev_dbg, and friends. > > i don't have any experience with vchiq logging/debug. So i'm not sure if > it's acceptable to lose the second log level dimension (like > vchiq_arm_log_level) completely. Complex drivers like brcmfmac have a debug > mask to avoid log spamming [1]. Maybe this is a compromise. > > Btw some loglevel locations has already been messed up during refactoring > :-( > > [1] - drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h > Kernel logging is actually has a bunch of features. You can turn them on for just a module or function or enable a specific message. See Documentation/admin-guide/dynamic-debug-howto.rst for more info. This vchiq logging is a re-implementation of a subset of the features that normal kernel logging infrastructure provides. Moving to normal logging will make it cleaner but also more flexible and powerful. It's better in every way. The broadcom stuff is different and more complicated than what this module is trying to do. They are sorting out their logging according to various components. I understand the motivation, but they would probably have been better just use standard logging like everyone else. regards, dan carpenter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel