Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2339021ybt; Fri, 3 Jul 2020 06:53:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrJ1q6zMxr0M8VjKN8Dm/m/JjhVPBx96/hjslyMbx0tWZAd7iniIXZJiB1luMZAzTlLm+b X-Received: by 2002:a17:906:fcb7:: with SMTP id qw23mr30579498ejb.229.1593784398064; Fri, 03 Jul 2020 06:53:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593784398; cv=none; d=google.com; s=arc-20160816; b=TDwH73PVlDA8vpJtvz+dV0qbJ3t3KdkqsLAVS/xnjrJdJYErKVYwDNefswcfycuRYC AMF2w7N5cLj6Wq2EpQT7O0oEJ465fR56aAv7xNrCLIEGttwzyqmr0HS4b36j+EpwDSwe xKLjqX/Louk877plqNX99LFst/V57V+Ncom4tTXMWoEIHKmSLeU4Dm4SnOIZsPkoJngw zz+4EnN2r+sBG/WZGDCm5YVrhvH07auFSg5p7A80ers0KO5uUXVAADfZQmcHhJ1MAhvF xhdCtidoNJTe5VulNYjzKZAJn3mA+hA5DVljQXdI24OEyStC/yoMYvRN2Ilhz4ZHXU/O ICTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=+CxntibhIWVV/CSRWYXDtWexhxsCBK/fYD1ekpU5mjw=; b=rhTo//y2GxwOauXSqWBFOvfzQH3E6kcyvsfrDpnY0hx9fCzN7oCUYFHPKxjejs7eOZ OAbTdMD986nlbResxmA+S3ob8s+H79dAsMkbs+J+gURhT46JN+SoHHZajS63simdLU62 jeJuRVN0JxK2FAGXoV//3j34huSMq/4pZCLl72GtmEJA016LNn3yias6Z22/CHF0csz+ VIQQTP2SDawAk7R7wNaPqdSHaZqetEoKFVPWGhByjdeEvOa6+327t9+RYk8s9q02+waw VPxqElGp7QQm62RxSFMr/r5fArrl+JpIykviepGPrbqq367VhJjuldFgDwbUZBYEZC6w TU8Q== 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 a8si7653139eds.491.2020.07.03.06.52.51; Fri, 03 Jul 2020 06:53:18 -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 S1726291AbgGCNwq (ORCPT + 99 others); Fri, 3 Jul 2020 09:52:46 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:59307 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726039AbgGCNwp (ORCPT ); Fri, 3 Jul 2020 09:52:45 -0400 Received: from [192.168.0.4] (ip5f5af280.dynamic.kabel-deutschland.de [95.90.242.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 967DB20225AE1; Fri, 3 Jul 2020 15:52:43 +0200 (CEST) Subject: Re: [PATCH 1/2] moduleparams: Add hex type parameter To: Linus Torvalds , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: Alex Deucher , Linux Kernel Mailing List , amd-gfx@lists.freedesktop.org References: <20200702140102.26129-1-pmenzel@molgen.mpg.de> <7c31d918-c967-5ebb-970e-7f6e913237e8@amd.com> From: Paul Menzel Message-ID: Date: Fri, 3 Jul 2020 15:52:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Linus, dear Christian, Am 02.07.20 um 21:42 schrieb Linus Torvalds: > On Thu, Jul 2, 2020 at 7:42 AM Christian König wrote: >> >> I'm just not sure how well this is received upstream because it only >> covers u32 >> >> On the other hand that is probably also the most used. > > Not necessarily true. I'd argue that "unsigned long" is equally > possible for some bit mask (or other hex-likely) type. > > So don't call it just "hex". Call it "hexint" (the hex does imply > "unsigned", I feel - showing hex numbers with a sign sounds insane). > > That way, if somebody ends up wanting it for unsigned long values, > we're not stuck. Good idea. Don.e > Another option is to just say that hex values always have bit _sizes_. > So "hex32" and "hex64" would also make sense as names to me. I went for int to be consistent in the naming, and kstrtouint is used in the macro. > While at it, should the hex numbers always be padded out to the size? > The example Paul used doesn't have that issue (high bit being set). > > Bbut often it may make sense to show a 32-bit hex number as "%#08x" > because it really makes things clearer when you're looking at high > bits, say. > > It's really hard to tell the difference between "just bit 27 set" and > "just bit 31" set otherwise, and that's not all that uncommon when the > bitmasks are sparse. Also good idea. Done. I just sent out the v2. Kind regards, Paul