Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp2035856imm; Thu, 21 Jun 2018 06:19:02 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI9ADmhzzpXjZ8fTZJgDWtcQAsmVffMKI+dbxj1Vf1gnd5y02E3Xfcnlxi8KMjCoPhmGfvs X-Received: by 2002:a62:1656:: with SMTP id 83-v6mr27412536pfw.61.1529587142114; Thu, 21 Jun 2018 06:19:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529587142; cv=none; d=google.com; s=arc-20160816; b=MLwY51vk7S/y4ZwNMVMGUcMVbo5SKkmgEWqGA+aVysmxoAzaCgqNuVLpzLwx8DbOhf 24asQrehKeBk/hhYca4/xfSPFcmBv7wm3iVJsiwlI+u460xijQ5hBPGZ4Fx775jykKWp CIp862AeRLM7v8aToJDGPNP+L+YQeEGYlY1mNQK3zEBnhS6RnEMRYbE7RmRhDCU4t5Bm LnJczWrb+gOcdOIUhbEyrxKlavrEsCz0PSasPThDedfmrD7mJoGfbjiM+O/wJcXTVjqr H77yiT2ndxgYeW8ylZRrNPcYHF4vhFsSwjwrCcykS7ZFohGOcP0CIvvs4i0bqxjdnfO1 bWEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=2wKRwGYSRKpL2oPzx0N4bjqsdVlL6haHs1enSDD/BRI=; b=EL64/1qdg02kbiZNcLGhDqVgz+QGPxvgJ6X7JAYDPy/FGH1pYRqEjRi6f3BjLFynve 95Vj4md3EcD/V7CrcjaJOdDe+3yqwlMlcBQnKnLgs9P9ebFovmtrfsFh7/ipbXCaTUZC n+9J3JlrOqNSWiCwuzAOI637Z9YaLTtmRf94me3zFHJgYzCjP6T5l5cDpjfZFlSgPUrb S7YukQMozsix3mXkWLFa6FbrZ+S4b1b050NhK0KxgudfvS0WWvbUenkaIIvvxPl8EEuZ KRN+rBkQMtDy0fDjSTlsdwT9cIlH+EFUPTL5gz35sdDH8ScJLfxIpAJp1P/VgRz65lQT Hgwg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x66-v6si5082559pfx.67.2018.06.21.06.18.47; Thu, 21 Jun 2018 06:19:02 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933304AbeFUNR3 (ORCPT + 99 others); Thu, 21 Jun 2018 09:17:29 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:43901 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932747AbeFUNR2 (ORCPT ); Thu, 21 Jun 2018 09:17:28 -0400 X-IronPort-AV: E=Sophos;i="5.51,252,1526335200"; d="scan'208";a="332746881" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 15:17:26 +0200 Date: Thu, 21 Jun 2018 15:17:26 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Joe Perches cc: Guenter Roeck , Tomer Maimon , cocci , robh+dt@kernel.org, mark.rutland@arm.com, jdelvare@suse.com, avifishman70@gmail.com, yuenn@google.com, brendanhiggins@google.com, venture@google.com, joel@jms.id.au, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, openbmc@lists.ozlabs.org Subject: Re: [PATCH v2 2/2] hwmon: npcm750: add NPCM7xx PWM and Fan driver In-Reply-To: Message-ID: References: <20180619105352.97181-1-tmaimon77@gmail.com> <20180619105352.97181-3-tmaimon77@gmail.com> <20180620164853.GA3459@roeck-us.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jun 2018, Joe Perches wrote: > (adding Julia Lawall and cocci mailing list) > > On Wed, 2018-06-20 at 09:48 -0700, Guenter Roeck wrote: > [] > > > +static inline void npcm7xx_fan_start_capture(struct npcm7xx_pwm_fan_data *data, > > > + u8 fan, u8 cmp) > > > +{ > > > + u8 fan_id = 0; > > > + u8 reg_mode = 0; > > > + u8 reg_int = 0; > > > + unsigned long flags; > > > + > > > + fan_id = NPCM7XX_FAN_INPUT(fan, cmp); > > > + > > > + /* to check whether any fan tach is enable */ > > > + if (data->npcm7xx_fan[fan_id].FanStFlag != FAN_DISABLE) { > > > + /* reset status */ > > > + spin_lock_irqsave(&data->npcm7xx_fan_lock[fan], flags); > > > + > > > + data->npcm7xx_fan[fan_id].FanStFlag = FAN_INIT; > > > + reg_int = ioread8(NPCM7XX_FAN_REG_TIEN(data->fan_base, fan)); > > > + > > > + if (cmp == NPCM7XX_FAN_CMPA) { > > > + /* enable interrupt */ > > > + iowrite8((u8) (reg_int | (NPCM7XX_FAN_TIEN_TAIEN | > > > + NPCM7XX_FAN_TIEN_TEIEN)), > > > > Is the (u8) typecast really necessary ? Seems unlikely. > > The cast is not really necessary here as there would > be an implicit cast already. > > Some might complain about loss of type safety and > "make W=123" would probably emit something here. > > But casts to the same type are not necessary. > > A possible coccinelle script to find casts to the > same type is below, but there are some false positives > for things like __force and __user casts > > Also, spatch (1.0.4) seems to have a defect for this > when the type is used in operations that change a > smaller type to int or unsigned int. > > i.e.: (offset is u16, but offset * 2 is int) Ah. The rule is that the result type is always the larger one? Unfortunately, Coccinelle doesn't know the size of any type. I could add some special cases, but that may be more confusing than helpful. julia > > While running the cocci script below: > > HANDLING: drivers/net/ethernet/intel/igb/e1000_nvm.c > diff = > diff -u -p a/drivers/net/drivers/net/ethernet/intel/igb/e1000_nvm.c b/drivers/net/ethernet/intel/igb/e1000_nvm.c > --- a/drivers/net/ethernet/intel/igb/e1000_nvm.c > +++ b/drivers/net/ethernet/intel/igb/e1000_nvm.c > @@ -335,7 +335,7 @@ s32 igb_read_nvm_spi(struct e1000_hw *hw > > /* Send the READ command (opcode + addr) */ > igb_shift_out_eec_bits(hw, read_opcode, nvm->opcode_bits); > - igb_shift_out_eec_bits(hw, (u16)(offset*2), nvm->address_bits); > + igb_shift_out_eec_bits(hw, (offset * 2), nvm->address_bits); > > /* Read the data. SPI NVMs increment the address with each byte > * read and will roll over if reading beyond the end. This allows > > --- > > Anyway, here's the cocci script: > > $ cat same_typecast.cocci > @@ > type T; > T foo; > @@ > > - (T *)&foo > + &foo > > @@ > type T; > T foo; > @@ > > - (T)foo > + foo > >