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 X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F4CDC4360C for ; Fri, 27 Sep 2019 12:25:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 66BCF21850 for ; Fri, 27 Sep 2019 12:25:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="q2Vwahk6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727138AbfI0MZZ (ORCPT ); Fri, 27 Sep 2019 08:25:25 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:41588 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbfI0MZZ (ORCPT ); Fri, 27 Sep 2019 08:25:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2A637Ahb7qsdDwnyq8c53qGLerD/lC6vZKHQyGPDsL0=; b=q2Vwahk68ubauaodCKHiiqHyeQ 0ssEzYEvHW4NU+kyLDdS+sn4TEFHVlWLxa0Td6qFXJ8Nl41qkUw8WPjYPQOEXlEMd0X9UZS1Q1E9d rcWAEVyl6Z/qiDhC4D3KyHhtARTLKsONPJ95Yuzz/A6JJB2wN2D71+PAsczB7MuRT/rs=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1iDpJG-0001eM-BA; Fri, 27 Sep 2019 14:25:18 +0200 Date: Fri, 27 Sep 2019 14:25:18 +0200 From: Andrew Lunn To: vincent.cheng.xh@renesas.com Cc: robh+dt@kernel.org, mark.rutland@arm.com, richardcochran@gmail.com, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] ptp: Add a ptp clock driver for IDT ClockMatrix. Message-ID: <20190927122518.GA25474@lunn.ch> References: <1569556128-22212-1-git-send-email-vincent.cheng.xh@renesas.com> <1569556128-22212-2-git-send-email-vincent.cheng.xh@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1569556128-22212-2-git-send-email-vincent.cheng.xh@renesas.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > +static s32 idtcm_xfer(struct idtcm *idtcm, > + u8 regaddr, > + u8 *buf, > + u16 count, > + bool write) > +{ > + struct i2c_client *client = idtcm->client; > + struct i2c_msg msg[2]; > + s32 cnt; > + > + msg[0].addr = client->addr; > + msg[0].flags = 0; > + msg[0].len = 1; > + msg[0].buf = ®addr; > + > + msg[1].addr = client->addr; > + msg[1].flags = write ? 0 : I2C_M_RD; > + msg[1].len = count; > + msg[1].buf = buf; > + > + cnt = i2c_transfer(client->adapter, msg, 2); > + > + if (cnt < 0) { > + dev_err(&client->dev, "i2c_transfer returned %d\n", cnt); > + return cnt; > + } else if (cnt != 2) { > + dev_err(&client->dev, > + "i2c_transfer sent only %d of %d messages\n", cnt, 2); > + return -EIO; > + } > + > + return 0; > +} > + > +static s32 idtcm_page_offset(struct idtcm *idtcm, u8 val) > +{ > + u8 buf[4]; > + s32 err; Hi Vincent All your functions return s32, rather than the usual int. err is an s32. i2c_transfer() will return an int, which you then assign to an s32. I've no idea, but maybe the static code checkers like smatch will complain about this, especially on 64 bit systems? I suspect on 64 bit machines, the compiler will be generating worse code, masking registers? Maybe use int, not s32? > +static s32 set_pll_output_mask(struct idtcm *idtcm, u16 addr, u8 val) > +{ > + s32 err = 0; > + > + switch (addr) { > + case OUTPUT_MASK_PLL0_ADDR: > + SET_U16_LSB(idtcm->channel[0].output_mask, val); > + break; > + case OUTPUT_MASK_PLL0_ADDR + 1: > + SET_U16_MSB(idtcm->channel[0].output_mask, val); > + break; > + case OUTPUT_MASK_PLL1_ADDR: > + SET_U16_LSB(idtcm->channel[1].output_mask, val); > + break; > + case OUTPUT_MASK_PLL1_ADDR + 1: > + SET_U16_MSB(idtcm->channel[1].output_mask, val); > + break; > + case OUTPUT_MASK_PLL2_ADDR: > + SET_U16_LSB(idtcm->channel[2].output_mask, val); > + break; > + case OUTPUT_MASK_PLL2_ADDR + 1: > + SET_U16_MSB(idtcm->channel[2].output_mask, val); > + break; > + case OUTPUT_MASK_PLL3_ADDR: > + SET_U16_LSB(idtcm->channel[3].output_mask, val); > + break; > + case OUTPUT_MASK_PLL3_ADDR + 1: > + SET_U16_MSB(idtcm->channel[3].output_mask, val); > + break; > + default: > + err = -1; EINVAL? > + break; > + } > + > + return err; > +} > +static void set_default_function_pointers(struct idtcm *idtcm) > +{ > + idtcm->_idtcm_gettime = _idtcm_gettime; > + idtcm->_idtcm_settime = _idtcm_settime; > + idtcm->_idtcm_rdwr = idtcm_rdwr; > + idtcm->_sync_pll_output = sync_pll_output; > +} Why does this indirection? Are the SPI versions of the silicon? Andrew