Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5481735pxb; Wed, 26 Jan 2022 13:04:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZFQ8+7cEBTwoibyo7tEDQyUEVYzSKncHSzG56vwsiSAHvci1PXNSlk99kY8mh/fDknKhE X-Received: by 2002:a05:6a00:23d3:: with SMTP id g19mr247463pfc.27.1643231091639; Wed, 26 Jan 2022 13:04:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643231091; cv=none; d=google.com; s=arc-20160816; b=dpExEiPngbuFR+0tNCR7/bOSDtPvbuFwjKAT7g7yAFpE9SYhcSAjRXTj9i8pa7EiUp w4lFWn+1McPGoP/Fj0QAlM2EON/JPE7u4Ess5MR+zFuugso9kTfpprm2GAbOgT3mz+lr 3xK4ZF7SUn3TVInyKaIsWaYNgqACfNN8mlZBM/NDKRZWTf8BBfezKIGI2ht5JdZZOdPa vHB5H9Vrtxl0BNy/ZUcONLO5kDKeE7EX/V/Vazcko2klGMd2nSDYYjCaXGP9zhuD44uJ hY5zHpiIVPDr2SZvn+tytSKnjXMVNOyCWIOiX0gP8iS6UpTFno0EIISMhJ5lqLJKBVTX AUFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=SF8OHFEbxLyyeZ4zcDww2bhWV6r5yPqGOc0x+VHktfg=; b=e0h1iMyKJGbrkeQS8IljdfZo+FTKPq3DchVFLJD4shvJyIH9MBpY+w3WqBjrDZixib HMN2wU0zW6pYvtL/fK3/tywfU3Khhe7BSeO7HXTmG4PX82qjSClj1G4GDIuURHdji/Ja pfA1DA7vnoURB47pRsYoU8Skoi57JuLTsIu1KOC5BN0INMb2UQINYT457ChwQuueUtVL 3uLM0m4lZJmwf4SWvvVWFJMmkQcOsYsCZSANIwNUlPr6V4LckV4FVUBJvjxjM4r/JB/b elPKJ+fxdqhR1T0im2WjSQA+1i806AxtPabRTySnBPzii9m+b1rcMyZAXV41cTLtbnx1 wIYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=iIdSmBlg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id me15si4499375pjb.98.2022.01.26.13.04.39; Wed, 26 Jan 2022 13:04:51 -0800 (PST) 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; dkim=pass header.i=@intel.com header.s=Intel header.b=iIdSmBlg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240135AbiAZKoA (ORCPT + 99 others); Wed, 26 Jan 2022 05:44:00 -0500 Received: from mga18.intel.com ([134.134.136.126]:8052 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232745AbiAZKnw (ORCPT ); Wed, 26 Jan 2022 05:43:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643193832; x=1674729832; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Vtg1dgMFp7p9GgxTmw0mrktziInoebLsnCNjJeItTWc=; b=iIdSmBlgfe6azUNDmzVOK3xp8rEb15h6JBAwVSfR4fxuSdZU9T0NXNqE An5UpTaqMRTz15Ls8Q7kQXzvlaVJB5/dFIKrgZ1/ldLj1XsAVuAVZVS47 xkjcUaJGTbOSrBdYAgh23Sppu3svjph/TsU2VQDZsjZVqnmslNLJLmHp4 WVL1pxeCjm3Ql2RZV1n8LwzB+TUOEH71gA5YltAgBLmH6m8fD8UQH3WWN Jp9YId36ELAdrJydcrgx1PRIhBfwcnU0Vgb0sz1CWlVS69f2Z40TBT4Hn GSPrP+UCzS6rwUItRg/+/ryksE0KS6fY/Jcri3DdeIBQBhZ4AmHrrPaHt Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10238"; a="230098001" X-IronPort-AV: E=Sophos;i="5.88,317,1635231600"; d="scan'208";a="230098001" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2022 02:43:51 -0800 X-IronPort-AV: E=Sophos;i="5.88,317,1635231600"; d="scan'208";a="624796941" Received: from richardt-mobl1.amr.corp.intel.com (HELO ldmartin-desk2) ([10.212.143.219]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2022 02:43:48 -0800 Date: Wed, 26 Jan 2022 02:43:45 -0800 From: Lucas De Marchi To: Andy Shevchenko Cc: Emma Anholt , David Airlie , nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel@lists.freedesktop.org, Chris Wilson , Vishal Kulkarni , Francis Laniel , Kentaro Takeda , amd-gfx@lists.freedesktop.org, Ben Skeggs , Jakub Kicinski , Harry Wentland , Petr Mladek , Sakari Ailus , Leo Li , intel-gfx@lists.freedesktop.org, Raju Rangoju , Julia Lawall , Rahul Lakkireddy , Steven Rostedt , Andy Shevchenko , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Christian =?utf-8?B?S8O2bmln?= , Sergey Senozhatsky , linux-security-module@vger.kernel.org, netdev@vger.kernel.org, Alex Deucher , Andrew Morton , "David S. Miller" Subject: Re: [Intel-gfx] [PATCH v2 09/11] drm: Convert open-coded yes/no strings to yesno() Message-ID: <20220126104345.r6libof7z7tqjqxi@ldmartin-desk2> X-Patchwork-Hint: comment References: <20220126093951.1470898-1-lucas.demarchi@intel.com> <20220126093951.1470898-10-lucas.demarchi@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote: >On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi > wrote: >> >> linux/string_helpers.h provides a helper to return "yes"/"no" strings. >> Replace the open coded versions with str_yes_no(). The places were oops, I replaced yesno() here but forgot to do so in the title >> identified with the following semantic patch: >> >> @@ >> expression b; >> @@ >> >> - b ? "yes" : "no" >> + str_yes_no(b) >> >> Then the includes were added, so we include-what-we-use, and parenthesis >> adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we >> still see the same binary sizes: >> >> text data bss dec hex filename >> 51149 3295 212 54656 d580 virtio/virtio-gpu.ko.old >> 51149 3295 212 54656 d580 virtio/virtio-gpu.ko >> 1441491 60340 800 1502631 16eda7 radeon/radeon.ko.old >> 1441491 60340 800 1502631 16eda7 radeon/radeon.ko >> 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko.old >> 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko >> 411986 10490 6176 428652 68a6c drm.ko.old >> 411986 10490 6176 428652 68a6c drm.ko >> 98129 1636 264 100029 186bd dp/drm_dp_helper.ko.old >> 98129 1636 264 100029 186bd dp/drm_dp_helper.ko >> 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko.old >> 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko > >This probably won't change for modules, but if you compile in the >linker may try to optimize it. Would be nice to see the old-new for >`make allyesconfig` or equivalent. just like it would already do, no? I can try and see what happens, but my feeling is that we won't have any change. > >... > >> seq_printf(m, "\tDP branch device present: %s\n", >> - branch_device ? "yes" : "no"); >> + str_yes_no(branch_device)); > >Can it be now on one line? Same Q for all similar cases in the entire series. I saw that question in the previous version. I think those are very subjective is they all go a little bit over 80 chars. Some maintainers may prefer one way or the other. Here we are reducing just 3 chars so I assumed that is the preferred style here. Also keeping it as is helps with the mass conversion since it's easily repeatable if another iteration is needed. thanks Lucas De Marchi