Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp1318261pxb; Sun, 11 Apr 2021 15:32:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYnXt6lyKM+AqXrX3CDcdxbUhhEF8Z0lbWkLUZF9uvB0p900GF3pi41nYhkNvCWOYKRJYD X-Received: by 2002:a63:4d0:: with SMTP id 199mr24470093pge.304.1618180356634; Sun, 11 Apr 2021 15:32:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618180356; cv=none; d=google.com; s=arc-20160816; b=ZwN/r8aLE1LdEEkeW2EpsePbBxSR2TRJPzfHS303Ym3keROurv6nHHzJLs4W/IzhgN v8wmaviTdX7ucIo5wC8zNcnn5ZuI+OSoGVkKlK2IIaP3pd4SiHAb67dGuI2shnTPinv1 fYHP8TdWHsoe1EUtFWc1PyYawOeS4ajMdztz6Z+tWViU4ZCLShkpgmbUAIiw97SKEYC9 Dr85v8TyWNVB5rszjGJ7uoT8AUJhh6i/DGQcecKHZZvQXZG6OzEuIGfLtHI8p06IDsmS tVnl4qAdknQyQsQAK2VovDmTnLqGYiacMEbGPMKTIDMM1Vt2exVM66NEAu5A2o9WcWPP WVIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=iJL3wYx/uxEtUNsDamoxNj35RU0zcLl5Q8CjdokNYO4=; b=wNPeqzTfM8OetCGWV1lg99TAcWqQxQgf8a1tia23M0eedPctYe+MdWG7DnI890H/hN /mda4YK4F557P3bUtojrzI6kncjBPx5p7PZpBG0GNw4kyrbHRbJ2FCEg2ABD+qfs3OWE nUsv9eI4PmCzzeqR8Khj8+ne0KzY9vrmTTm1CTH27NIUmtCd/CWOgNjrUkn+uzmHeC6b BGpEDA3V8R7UidgXybgbqkwmsMOrzhxhJrfFhMD0jjjpzVQpH3XD+ePVH0zGw3i+RHJi OxZdZmXLr3X5GyjhF+aEzAXICZPhc5hkrQMmRFpAOTRkIAUgBfYpSxFq3ySoW1inJcBs AdpQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id my7si11732251pjb.17.2021.04.11.15.32.24; Sun, 11 Apr 2021 15:32:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235487AbhDKVIg (ORCPT + 99 others); Sun, 11 Apr 2021 17:08:36 -0400 Received: from smtprelay0075.hostedemail.com ([216.40.44.75]:36066 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S235005AbhDKVIf (ORCPT ); Sun, 11 Apr 2021 17:08:35 -0400 Received: from omf16.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id EBD491DF1; Sun, 11 Apr 2021 21:08:17 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf16.hostedemail.com (Postfix) with ESMTPA id 532C12550F1; Sun, 11 Apr 2021 21:08:16 +0000 (UTC) Message-ID: <9a9246c417587f17009543f8048d5f9b7a2ed68f.camel@perches.com> Subject: Re: [PATCH] iommu/amd: Fix extended features logging From: Joe Perches To: John Ogness , Alexander Monakov Cc: Paul Menzel , Joerg Roedel , Suravee Suthikulpanit , iommu@lists.linux-foundation.org, LKML , Petr Mladek , Sergey Senozhatsky , Steven Rostedt Date: Sun, 11 Apr 2021 14:08:14 -0700 In-Reply-To: <87o8ekioo4.fsf@jogness.linutronix.de> References: <20210410211152.1938-1-amonakov@ispras.ru> <87o8ekioo4.fsf@jogness.linutronix.de> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout03 X-Rspamd-Queue-Id: 532C12550F1 X-Spam-Status: No, score=0.10 X-Stat-Signature: eagcefjgbbk7hk8ng65r7rhy6cygbpet X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX1/lZU62XoRvdiKemSYJQ3VV6E25IAI9M3o= X-HE-Tag: 1618175296-55556 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote: > I'd rather fix dev_info callers to allow pr_cont and then fix any code > that is using this workaround. Assuming you mean all dev_() uses, me too. > And if the print maintainers agree it is OK to encourage > pr_cont(LOGLEVEL "...") usage, then people should really start using > that if the loglevel on those pieces is important. I have no stong feeling about the use of pr_cont( as valuable or not. I think it's just a trivial bit that could be somewhat useful when interleaving occurs. A somewhat better mechanism would be to have an explicit cookie use like: cookie = printk_multipart_init(KERN_LEVEL, fmt, ...); while () printk_multipart_cont(cookie, fmt, ...); printk_multipark_end(cookie, fmt, ...); And separately, there should be a pr_debug_cont or equivalent.