From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFFE7C433EF for ; Thu, 3 Mar 2022 10:44:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232460AbiCCKph (ORCPT ); Thu, 3 Mar 2022 05:45:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232428AbiCCKpg (ORCPT ); Thu, 3 Mar 2022 05:45:36 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15D5B4707D; Thu, 3 Mar 2022 02:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646304291; x=1677840291; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=dVD9z92VH43KxwwjXiWGXRu7osivdsQyI2JqeG5AhT4=; b=c+os0yg8l1HErMjKTbPs9ZO3Qo1AdWDUvSywRr7KAUtbS7eFpJJ1bhpe ewKhv/eTaH9N/3AQMwMPNTS8g3MHMj8UYoFWRU8cSTHkDvLtDQl1r921/ eAqHFdGePvoKm412oJmHja/q349O7sjGHw9xUFyQk5Lf3Grj3eJCm8eo3 HzRQIUpmOC7j9deDLyqcMKlK1W6MBGbabtRbDI+DAdBRGx3vhn8zuBn1G bh2YpwzRernus65UocaXL1srpikZRVbPhyB+Xsnf8DoDnRQyMpyQq7lrj TDCfelSEBzRNRyISgxy7MD8mb1pve8l9BxAgRM+Hv0+f1he0piFJBbR0T Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10274"; a="253373147" X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="253373147" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 02:44:50 -0800 X-IronPort-AV: E=Sophos;i="5.90,151,1643702400"; d="scan'208";a="576447018" Received: from smile.fi.intel.com ([10.237.72.59]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 02:44:44 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nPiw8-00AkCJ-VT; Thu, 03 Mar 2022 12:43:56 +0200 Date: Thu, 3 Mar 2022 12:43:56 +0200 From: Andy Shevchenko To: Tyrone Ting Cc: avifishman70@gmail.com, tmaimon77@gmail.com, tali.perry1@gmail.com, venture@google.com, yuenn@google.com, benjaminfair@google.com, robh+dt@kernel.org, krzysztof.kozlowski@canonical.com, yangyicong@hisilicon.com, semen.protsenko@linaro.org, wsa@kernel.org, jie.deng@intel.com, sven@svenpeter.dev, bence98@sch.bme.hu, lukas.bulwahn@gmail.com, arnd@arndb.de, olof@lixom.net, tali.perry@nuvoton.com, Avi.Fishman@nuvoton.com, tomer.maimon@nuvoton.com, KWLIU@nuvoton.com, JJLIU0@nuvoton.com, kfting@nuvoton.com, openbmc@lists.ozlabs.org, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 11/11] i2c: npcm: Support NPCM845 Message-ID: References: <20220303083141.8742-1-warp5tw@gmail.com> <20220303083141.8742-12-warp5tw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220303083141.8742-12-warp5tw@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Mar 03, 2022 at 04:31:41PM +0800, Tyrone Ting wrote: > From: Tyrone Ting > > Add NPCM8XX I2C support. > The NPCM8XX uses a similar i2c module as NPCM7XX. > The internal HW FIFO is larger in NPCM8XX. > > Signed-off-by: Tyrone Ting > Signed-off-by: Tali Perry Wrong SoB chain. ... > +static const struct npcm_i2c_data npxm7xx_i2c_data = { > + .fifo_size = 16, > + .segctl_init_val = 0x0333F000, > + .txf_sts_tx_bytes = GENMASK(4, 0), > + .rxf_sts_rx_bytes = GENMASK(4, 0), > + .rxf_ctl_last_pec = BIT(5) + Comma. > +}; > + > +static const struct npcm_i2c_data npxm8xx_i2c_data = { > + .fifo_size = 32, > + .segctl_init_val = 0x9333F000, > + .txf_sts_tx_bytes = GENMASK(5, 0), > + .rxf_sts_rx_bytes = GENMASK(5, 0), > + .rxf_ctl_last_pec = BIT(7) Ditto. > +}; ... > - left_in_fifo = FIELD_GET(NPCM_I2CTXF_STS_TX_BYTES, > - ioread8(bus->reg + NPCM_I2CTXF_STS)); > + left_in_fifo = (bus->data->txf_sts_tx_bytes & > + ioread8(bus->reg + NPCM_I2CTXF_STS)); Besides too many parentheses, this is an interesting change. So, in different versions of IP the field is on different bits? Perhaps it means that you need something like internal ops structure for all these, where you will have been using the statically defined masks? ... > + match = of_match_device(npcm_i2c_bus_of_table, dev); > + if (!match) { > + dev_err(dev, "OF data missing\n"); > + return -EINVAL; > + } > + bus->data = match->data; This is NIH of_device_get_match_data(). ... > -static const struct of_device_id npcm_i2c_bus_of_table[] = { > - { .compatible = "nuvoton,npcm750-i2c", }, > - {} > -}; > -MODULE_DEVICE_TABLE(of, npcm_i2c_bus_of_table); > - Redundant change, leave this as is. -- With Best Regards, Andy Shevchenko