From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932343AbdJ0SwM (ORCPT ); Fri, 27 Oct 2017 14:52:12 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:48288 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751393AbdJ0SwL (ORCPT ); Fri, 27 Oct 2017 14:52:11 -0400 X-Google-Smtp-Source: ABhQp+Sd94/9grQ7/pj0pYej8jXmMIcs9Zy37PUMW776frrg74BDpmN0hnu9//ufFXG3qKBSi8sVHAoaJM//AJ/4w60= MIME-Version: 1.0 In-Reply-To: References: <2245486.jYtPfSLF5g@aspire.rjw.lan> <20171024055409.GA5805@intel.com> <2465945.6cfLQGiipl@aspire.rjw.lan> From: Andy Shevchenko Date: Fri, 27 Oct 2017 21:52:09 +0300 Message-ID: Subject: Re: [PATCH] PM / QoS: Fix device resume latency PM QoS To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , ramesh.thomas@intel.com, Linux PM , LKML , Reinette Chatre , Alex Shi , Ulf Hansson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 26, 2017 at 11:38 AM, Rafael J. Wysocki wrote: > On Wed, Oct 25, 2017 at 10:06 PM, Andy Shevchenko > wrote: >> On Tue, Oct 24, 2017 at 11:49 AM, Rafael J. Wysocki wrote: >>> On Tuesday, October 24, 2017 7:54:09 AM CEST Ramesh Thomas wrote: >>>> On 2017-10-20 at 13:27:34 +0200, Rafael J. Wysocki wrote: >> >>>> > static ssize_t pm_qos_resume_latency_store(struct device *dev, >>>> > @@ -228,11 +235,19 @@ static ssize_t pm_qos_resume_latency_sto >>>> > s32 value; >>>> > int ret; >> >>>> > + if (!kstrtos32(buf, 0, &value)) { >>>> > + /* >>>> > + * Prevent users from writing negative or "no constraint" values >>>> > + * directly. >>>> > + */ >>>> > + if (value < 0 || value == PM_QOS_RESUME_LATENCY_NO_CONSTRAINT) >>>> > + return -EINVAL; >> >>>> > + if (value == 0) >>>> > + value = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT; >>>> > + } else if (!strcmp(buf, "n/a") || !strcmp(buf, "n/a\n")) { >>>> >>>> Can the 2 checks for "n/a" be combined by checking first 3 characters? >>> >>> No, because "n/asomething" would then match too. >> >> If I don't missed anything, kernfs is aware of \n which means the >> first check is enough. >> Am I correct? > > I'm not sure, honestly. :-) Okay, just a summary: 1. kernfs guarantees that buffer is NULL terminated 2. sysfs guarantees that the buffer is not empty 3. kstrto* are aware of '\n' 4. sysfs_streq() and __sysfs_match_string() are aware of '\n' Thus, we just may use sysfs_streq() for that. I will prepare a clean up patch on top of this fix if you are okay with it. > Anyway, that can be fixed up later and the bug in question is rather urgent. Sure. -- With Best Regards, Andy Shevchenko