Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1249859pxb; Sat, 29 Jan 2022 00:11:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJzKgAefyS4vmLiapV1lBR/S/CtrkECYgHhgS56/JPfuQpX1info4p9w1VLNa7PHO5EI6mAR X-Received: by 2002:a17:906:d551:: with SMTP id cr17mr9496686ejc.27.1643443916062; Sat, 29 Jan 2022 00:11:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643443916; cv=none; d=google.com; s=arc-20160816; b=XKIPm5YH76un3KW7Fzj6obYjskmIBRsobo4FKo5FX0KcLVrkzhwq1v5cGHipkLYoLI px69XAjKSvAuJmRR0kTUNNDOmHEnTqrkWzbVHltidwgGGiU+XO3IDqMmHTl5+J2OWau8 ypn1EYjRuSmwvJC2xnCtMh2Ipjx+/or/8M7Dy+JaKgHIyyOSUWyd9rZd4dhKzwnkJVSx 51i2JGCrdjjbRoH3mPL2Rtog+V/aGkIdrFHzPAaxesC0XP8/ZIFZotTwhHyFj7zGxMFg 5JwVKmcXVXBejGK6zdckkxVOB1hzgFSiol/gmi6NkDN5UR7ZWmr79shvJgc5zpmxJgnL 10oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=xrY6uJKYKEB1OpHKb3XWelE8KrDIRLTBw4SSV6nUVDQ=; b=hsTuNwvjvFjkUX1JaR2AA6+p4Ub84DLOIe8sjeAYDv2FCo6c7Ujeo043Z+o53b+zKy GVJUc4m6wGbnoRQD8TBuc7lijmAMhqV14vwiCrZHafiYA6elUR9WtNi69KKIeZOBzFL5 vrxgmVUy5p7VF+eP6idTXikllkA44k5OJircUM5+0dKzzm+dYzBwfuidEAEupxw9tssd Ojs5Jdlm0ICD2H0mMQq5nvM7SFmeEPzOguaAbg35VRMCztjNRJwcqgTxh21PyeJaZxjH aq8g8egrTMNaenrjkZmxUe3ZeuoAD8ICMZlHpiC0GboESE/QoOlaVPbWWQDdRjQaeYkq lvoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CxvkUWSZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id en5si4046081edb.335.2022.01.29.00.11.31; Sat, 29 Jan 2022 00:11:56 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CxvkUWSZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345205AbiA1B56 (ORCPT + 99 others); Thu, 27 Jan 2022 20:57:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345178AbiA1B55 (ORCPT ); Thu, 27 Jan 2022 20:57:57 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 494F4C061714; Thu, 27 Jan 2022 17:57:57 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AA7F1B8241B; Fri, 28 Jan 2022 01:57:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15552C340E5; Fri, 28 Jan 2022 01:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643335073; bh=TysClmp2wYd6iFt2FNNZ24/T6VG/tjD1dbeLuKE4/wo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CxvkUWSZR1brvkZrepb8/Ywk1zcj9GpgN4/Z65wiidOiWUuT8p+azdMFi5qx6fGlR tdlczA+iArJ4ND88VFdeabfTLxaQUjEAV0BZ9ZgR7qk0cLuN5DWNST83phTnilWrZP lJtM7RcvXzPdkJn/3tszihq1wlRCHjfnN03cMG2kZlrR21TbHGDEN9GwBRMFwFemXi oQkFnVyz1KgmF5nT9MvDpGKttkUz4UDogi9fT0BBKBp9KCbqHMdjE7g22z0iEx3GS3 UFIEbIs3Z5k+quO8/BriyW00MyrOyFTQwCHA5P1o/EgkHjKYfMJGf9TAT8Y7qYeKYQ 1cnIR+RA51HoQ== Date: Thu, 27 Jan 2022 17:57:51 -0800 From: Jakub Kicinski To: Joseph CHAMG Cc: "David S . Miller" , Rob Herring , joseph_chang@davicom.com.tw, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com, andrew@lunn.ch, leon@kernel.org Subject: Re: [PATCH v14, 2/2] net: Add dm9051 driver Message-ID: <20220127175751.7ef239c1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20220127032701.23056-3-josright123@gmail.com> References: <20220127032701.23056-1-josright123@gmail.com> <20220127032701.23056-3-josright123@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Jan 2022 11:27:01 +0800 Joseph CHAMG wrote: > Add davicom dm9051 spi ethernet driver, The driver work for the > device platform which has the spi master > > Signed-off-by: Joseph CHAMG > +/* event: write into the mac registers and eeprom directly > + */ > +static int dm9051_set_mac_address(struct net_device *ndev, void *p) > +{ > + struct board_info *db = to_dm9051_board(ndev); > + int ret; > + > + ret = eth_mac_addr(ndev, p); You should not be using this helper if the write can fail. See what this function does internally and: - put the eth_prepare_mac_addr_change() call here > + if (ret < 0) > + return ret; > + > + ret = regmap_bulk_write(db->regmap_dmbulk, DM9051_PAR, ndev->dev_addr, ETH_ALEN); > + if (ret < 0) > + netif_err(db, drv, ndev, "%s: error %d bulk writing reg %02x, len %d\n", > + __func__, ret, DM9051_PAR, ETH_ALEN); - put the eth_commit_mac_addr_change() call here > + return ret; > +} > +static void dm9051_netdev(struct net_device *ndev) > +{ > + ndev->mtu = 1500; Unnecessary, ether_setup() does this already. > + ndev->if_port = IF_PORT_100BASET; Why set this? The if_port API is a leftover from very old 10Mbit Ethernet days, we have ethtool link APIs now. > + ndev->netdev_ops = &dm9051_netdev_ops; > + ndev->ethtool_ops = &dm9051_ethtool_ops; Just inline there two lines into the caller and remove the helper. dm9051_netdev() does not sound like a function that does setup. > +} > + > +static int dm9051_map_init(struct spi_device *spi, struct board_info *db) > +{ > + /* create two regmap instances, > + * run read/write and bulk_read/bulk_write individually, > + * to resolve regmap execution confliction problem > + */ > + regconfigdm.lock_arg = db; > + db->regmap_dm = devm_regmap_init_spi(db->spidev, ®configdm); > + > + if (IS_ERR(db->regmap_dm)) > + return PTR_ERR_OR_ZERO(db->regmap_dm); > + > + regconfigdmbulk.lock_arg = db; > + db->regmap_dmbulk = devm_regmap_init_spi(db->spidev, ®configdmbulk); > + Please remove all the empty lines between function call and error checking the result. > + if (IS_ERR(db->regmap_dmbulk)) > + return PTR_ERR_OR_ZERO(db->regmap_dmbulk); Why _OR_ZERO() when you're in a IS_ERR() condition already? > + return 0; > + ret = devm_register_netdev(dev, ndev); > + if (ret) { > + dev_err(dev, "failed to register network device\n"); > + kthread_stop(db->kwr_task_kw); > + phy_disconnect(db->phydev); > + return ret; > + } > + > + skb_queue_head_init(&db->txq); All the state must be initialized before netdev is registered, otherwise another thread may immediately open the device and start to transmit. > + return 0; > + > +err_stopthread: > + kthread_stop(db->kwr_task_kw); > + return ret; > +}