Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp161640pxb; Mon, 25 Oct 2021 05:59:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOWzq/I47qepOxn7R7XP+1JxBUc5V0JTzApmScitxL3Dj0qOMhMx0RDp0Jzju6wWR6DzA6 X-Received: by 2002:a63:ed13:: with SMTP id d19mr13491602pgi.430.1635166754731; Mon, 25 Oct 2021 05:59:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635166754; cv=none; d=google.com; s=arc-20160816; b=q/eH5u+y5Y1UN7cSkk2xRZXxNhjowj/KWj7VE/G02exIE5PUtMfHJufvqtq6XQ8Ueq TA8EuhuB/xU1P+25UbVx78l+1T3aCG58Rb8Dq4l7UBzE12Vfe9tNF0/BLsM8cCYNwRwK JH/xbvSHnH/mNj+Z2t2icPTf0kGowZXU6Vvk1BA/w251o+NojxT6nsNVRNZJKuiR9GS+ ZwX+nXxgahUOwjCUJ2N3KM6uzfMrQb0bTw/kF5Fa/Fq83HrrXaBVOC50Zmg1Gs+efF49 b38NbyMbymuz/bPksPuyF2jqcF0tuzZCsaayfDpyAny67JG81aWvrTaWbYHonDgWAGz9 45ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=BJUXLAeOja2uyUyFrzv6UyWtqWE/tDBeLaXMDO5KNPk=; b=hbGaMTAC20nQrRzr1mMH5JZD96mB2qCLgbMjMq9Yo69BPBYCID3PV44dNIhNWFmCIL onTNvW0u+CckRbbboi6T50QtN9wha3D9JL+kQxI+UkuqbbxAdsFQET5SPY3Jee5fazre tKpFOKvD3AV0YgNcDx516MedEemgohoq0t7Kgx6wUrKi4jixhGNmJ5fjd3hbqTin+QUI ecl5mXGs71vllYAtTlLl3jhDk+8SdZcX7MDGEho7FoJXPQg89BK3yxBo9h379oLgl0i8 Gs0pIa8ocDjNwi2x23xJEts1hc60R3rftFPYSm2rvpP3XakO1lcWn69wUwdBrZvimd77 v5QA== 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; dmarc=fail (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 y129si21463194pfb.64.2021.10.25.05.58.57; Mon, 25 Oct 2021 05:59:14 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233346AbhJYM75 (ORCPT + 99 others); Mon, 25 Oct 2021 08:59:57 -0400 Received: from mga05.intel.com ([192.55.52.43]:54793 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233315AbhJYM74 (ORCPT ); Mon, 25 Oct 2021 08:59:56 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10147"; a="315846780" X-IronPort-AV: E=Sophos;i="5.87,180,1631602800"; d="scan'208";a="315846780" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2021 05:57:30 -0700 X-IronPort-AV: E=Sophos;i="5.87,180,1631602800"; d="scan'208";a="485664166" Received: from smile.fi.intel.com ([10.237.72.184]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2021 05:57:27 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1mezXG-000ceU-FU; Mon, 25 Oct 2021 15:57:06 +0300 Date: Mon, 25 Oct 2021 15:57:06 +0300 From: "andriy.shevchenko" To: "changlianzhi@uniontech.com" Cc: linux-kernel , "dmitry.torokhov" , gregkh , jirislaby , 282827961 <282827961@qq.com> Subject: Re: [PATCH v6] tty: Fix the keyboard led light display problem Message-ID: References: <20211021020511.18016-1-changlianzhi@uniontech.com> <202110250129181502896@uniontech.com> <202110251224440412487@uniontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202110251224440412487@uniontech.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 25, 2021 at 12:24:45PM +0800, changlianzhi@uniontech.com wrote: > On Mon, Oct 25, 2021 at 01:29:18AM +0800, changlianzhi@uniontech.com wrote: > > > >>On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote: ... > > > >> + unsigned long leds; > > > >> + > > > >> + leds = (unsigned long)ledstate; > > > > > > >Can be one line. > > > > > > >But most important question you are ignoring to answer / address is why do you > > > >use casting? > > > > >>But most important question you are ignoring to answer / address is why do you > > > >>use casting? > > > Casting is used here because: > > > The second parameter of test_bit is "volatile unsigned long *addr" (see constant_test_bit() in /arch/x86/include/asm/bitops.h), but ledstate is an "unsigned int" type. If casting is not used, > > > compile Will report an error. > > > Wait, you are casting pointer to an integer?! > > This is completely wrong in this case! > > Hello, I did not do that. For the complete code, please check the > "patch v6" email I sent earlier. My code is like this: > +static void kbd_update_ledstate(struct input_dev *dev) > +{ > + unsigned long leds; > + > + leds = (unsigned long)ledstate; > + > + if (!!test_bit(LED_NUML, dev->led) != !!test_bit(VC_NUMLOCK, &leds)) > + ledstate ^= BIT(VC_NUMLOCK); > + if (!!test_bit(LED_CAPSL, dev->led) != !!test_bit(VC_CAPSLOCK, &leds)) > + ledstate ^= BIT(VC_CAPSLOCK); > + if (!!test_bit(LED_SCROLLL, dev->led) != !!test_bit(VC_SCROLLOCK, &leds)) > + ledstate ^= BIT(VC_SCROLLOCK); > +} > I mean, the second parameter of test_bit is "volatile unsigned long *addr", > which is a pointer. And ledstate is an unsigned int type, so I defined an > unsigned long type leds, assign the ledstate to the leds after forced > conversion, and then when calling the test_bit function, get the address > of the leds as a parameter. This all is fine, but why casting is needed? I didn't still get. -- With Best Regards, Andy Shevchenko