Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5076745imd; Tue, 30 Oct 2018 11:35:14 -0700 (PDT) X-Google-Smtp-Source: AJdET5cNYDkG0/Qswe0RI/M3gAMqc5Lmga797mLywHb2pnzt/X13GfFCfMwwuoslVlURsNl78Wad X-Received: by 2002:a62:8288:: with SMTP id w130-v6mr4111842pfd.68.1540924514772; Tue, 30 Oct 2018 11:35:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540924514; cv=none; d=google.com; s=arc-20160816; b=LsOPKs2Cc7/J5/vRsp+zhalvnaMVdwHUrkIVBPygNPF48R8nphz/mJh2rxsGTtm0sc RxQIgUridcKwtpUcbWxxkGRVYZBfIzcw4QI5Xp/r2aooVdte4EwH5+s+ULctB/n8Q6QH qvzRabTAuTu6bAjInXwUNCvqXHY1EqJtLuigMuG3IivbYA0nHlblz5+F+NNrbstjRkHD s4cvVF960SiQGuJjXl4ivk+9vcGM1AJifLiVyUe0i+/5gvrjLC5nIyCjDLcH2HrAjFkN 6bBrWCRR+JbVGu82TF9bfOXKi3y2JF7kq2M4Sb8PPLjzcRk0zzFL+Zr5p3cWil2VRVrO pSNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=n3ldqB7sqGLLhjb7b7WUPwK9+CPZA78yPvaHaPUjv0A=; b=eNKjmlvzAr7CjAD0irtdnYvfHLw59mI+nmLTkctWimHRpm4mKmy/05UpYTw2Yzy5xg dtiHtBdArmP+8NZk8Iyv33zjWHPrKDnvGUdc0X5th510PM1M6wORTPMp0xYYprRjzVeK qJbL823yFrZvIr7uf/CllUmf1pk7QoODifTuj/OoXHBSzw4z3SeplJ2RMinr1ZiXqtz2 lBlb7PmOm5/VkXIz35YsyiHTqLQy+wnZtVqcneuY2izG8ktxDHjY7mCgbRKpogF1ccxB dMrsBFhfCQjR59J3aRqez2D5eNPc/vml8k595ZOgXP3be5/MGLu0BBLcSS7e+iLN8oAR 811A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nf4zCaJh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7-v6si274254pgp.233.2018.10.30.11.34.47; Tue, 30 Oct 2018 11:35:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nf4zCaJh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728410AbeJaD2Q (ORCPT + 99 others); Tue, 30 Oct 2018 23:28:16 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:40711 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728056AbeJaD2P (ORCPT ); Tue, 30 Oct 2018 23:28:15 -0400 Received: by mail-qt1-f193.google.com with SMTP id k12so8836942qtf.7; Tue, 30 Oct 2018 11:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n3ldqB7sqGLLhjb7b7WUPwK9+CPZA78yPvaHaPUjv0A=; b=nf4zCaJhdTQ6jGzq7PLBpTix6P1G2XG+Eu4tHDL8YZr7n4P3JBEMgxQx614myxrBL4 V8hM9CTvVsrNoIocG1JxvTfhSsGnE9PIf/Ew/QAZWuyG+NqK1I8vDo6nQ+xNH2BMjrkO 9IUEVMry5MXqHI9anc13Kq1RAhs0ODll/aWMTTPUjsFRHVUHQf3ZH5H2/OH8z+762/EF H8AD87DiluzLWROSZvXpJeATN+P5/18sMmLghPziuZmwbg2uwaJoeBciFF+ozBPXDSMH KrCzylnEPOMOqltEIB0B0QCWHFfxnROg5KpRQxk5vtWYIRYahLuhqBGjq/noY7MOgm73 0nyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n3ldqB7sqGLLhjb7b7WUPwK9+CPZA78yPvaHaPUjv0A=; b=L0u55UkDdMQTEFuK2qpuWQkT2yx1fid7fBps3ycLFbqyl0QzCxupWnE2g7tcHtp7WG JoY9coI6vInqL5h03Csy3SVGTCiw9Ea0Ey0WGY+3cApJbSwvKRw6kUMW1Qqcz3ZcPU8j 3+F6xIrPpND7JTqxlhZ2FI/UNuFsZzb8K9pbwUk2vNpaHTr7bxl0TnR/ymTdFEYx0no4 U5Z6c6t5+Qb7Xf2y2O0hQfRuyrX4osos4kAYoJBPadys9593o4xd9RmdXSxZTVfWsLw4 yonNTK3Y9c2nvnmchF0Im39WKXDXOP/hfNRdgmj9uCP9r9xn9h9WwRuVyhoDtrC62X5q tdxg== X-Gm-Message-State: AGRZ1gIuZFTIKNr+GyV7do5XvlV8QgRRE5wtHS3BTmCQkh34YpnZ8e3J UmvLRK3hMIRMVld3qt7hwrQHcvFeV8Ss9QsnFfQ= X-Received: by 2002:ac8:2413:: with SMTP id c19-v6mr3295168qtc.194.1540924419084; Tue, 30 Oct 2018 11:33:39 -0700 (PDT) MIME-Version: 1.0 References: <20181006065113.669-1-rajneesh.bhardwaj@linux.intel.com> <0d940313e1be7ddaa06c5ebf4aea7a4df84540f2.camel@linux.intel.com> In-Reply-To: <0d940313e1be7ddaa06c5ebf4aea7a4df84540f2.camel@linux.intel.com> From: Andy Shevchenko Date: Tue, 30 Oct 2018 20:33:06 +0200 Message-ID: Subject: Re: [PATCH v2 1/4] platform/x86: intel_pmc_core: Show Latency Tolerance info To: Srinivas Pandruvada Cc: rajneesh.bhardwaj@linux.intel.com, Platform Driver , Darren Hart , Andy Shevchenko , Linux Kernel Mailing List , Rajneesh Bhardwaj Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 30, 2018 at 8:03 PM Srinivas Pandruvada wrote: > > > Index printing is required here (for LTR Show and LTR Ignore) > > > because it > > > paves an obvious and easy way for the users of this driver to know > > > the > > > IP number to be used for LTR ignore. This was specifically > > > requested by > > > some customer and Srinivas asked me to implement this so adding him > > > for > > > his inputs. > > > > So, why it should be in kernel? When user prints this, they usually > > call `cat /.../file`, right? > > Is it too hard to call `cat -n /.../file` instead? The benefit of > > such > > approach is that it's independent on the file we are printing. > > > > (Note, `grep -n /.../file` does the same`) > > > > For more variants > > > https://stackoverflow.com/questions/8206370/add-numbers-to-the-beginning-of-every-line-in-a-file > > > We get copy/paste data from some serial terminals from systems which > don't have traditional linux shell or busy box. Not sure if they can do > cat "-n" option or have this command at all. So line number helps. They > can't even store output as as file as this is RO file system. Hmm... I'm not following this. If there is serial connection where at least you may see things, how it's guaranteed that it will not print more enough to rewrite the DTE's input buffer? On the other hand if you copy the data to the other system which, I bet, has `cat -n` available, not a problem either. So, the use case here, AFAICS, if you have a debug log enabled and it's spitted out like SysRq where you can see, but not able to copy and it's guaranteed not to overflow on the screen / output device. > But I am not as sticky on this. Since it's a debugfs and not any ABI implied, I'm fine with it to have, but I would like to understand the real use case of it (and this definitely should be reflected in the commit message). -- With Best Regards, Andy Shevchenko