Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4132405pxk; Tue, 8 Sep 2020 11:29:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwf7l9qOhnVozjf3OlNW2uMqSFb8F/1vOqGLbS44CQGXhrjSMPDpLurTquU1GQOeFf8HEzV X-Received: by 2002:a17:906:e4f:: with SMTP id q15mr28672396eji.155.1599589757945; Tue, 08 Sep 2020 11:29:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599589757; cv=none; d=google.com; s=arc-20160816; b=hh4LXWWl8O1WMOxS0CeWR1GqWXG0xqME0r+O/GslPMTHnG6iHs7ceWTRIdRzGHb0lZ JKSlEizJ910Y3iKU+89kSTKUcXk9upLHPZilWd5eLX4VNeBomPBRyPGhy7HkxtT3D+P2 DyIp0iODDytbyep1F8iZ1dtP+VdQvlKHAnatxi05lvu35kTzYi2k4mhnhc2x2B+o7PWY nsvCnyCcCKCPL9Ha/Gy5maRADRejqCiAT/Cv40Zf1lEcu7zTzUFmEkFSJwfMTsy+5ZVt MOu4LeTm+r6NsA7s3Dyk2IwtiNFR282zjcHq52qb7FW+8ma+78EqEyq7MQeDtPm4CQzn vURw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uNuxlVSQupp8D4yUKqLqyQh8NXsr1nT5A98zI7FbR6g=; b=HuKbRl1FQRvE8SkvjJcOFcVZggS1wvHj2wWFvja4SqEPXsUs5glSLa2/VVD4T48sfx m1CYkCy9DV2eSDS9uBOq16boBU1RfkvYKMGahhzj6mOkZ3gGuv887KRZYA95mnkcb0qy DkxU9F04k4ZCAEhtQlqs9fLFzXgow5CNTVXQBmnDrimzxlXvAMcsesyvPFJlyUXQR6Yc aw/neiFV9Lxd7XwbGi8e7r2YH0wxnnyCOVze7NUujrwpftofbV6x0mB7lJDO9jyLoT/I DnSz4ogyZzon6ULSJmT4T2l/Ly+3q58THI4+soDrtfO7Ef+Y3LW3c5Rw1sc4vlM/HmGK gd/g== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s20si12416760edy.352.2020.09.08.11.28.55; Tue, 08 Sep 2020 11:29:17 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731651AbgIHSZD (ORCPT + 99 others); Tue, 8 Sep 2020 14:25:03 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:50582 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730748AbgIHSWZ (ORCPT ); Tue, 8 Sep 2020 14:22:25 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kFiG4-00Dp7f-7W; Tue, 08 Sep 2020 20:22:20 +0200 Date: Tue, 8 Sep 2020 20:22:20 +0200 From: Andrew Lunn To: Lukasz Stelmach Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org, b.zolnierkie@samsung.com, netdev@vger.kernel.org, Russell King , Krzysztof Kozlowski , linux-kernel@vger.kernel.org, Rob Herring , Kukjin Kim , Jakub Kicinski , "David S. Miller" , linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com Subject: Re: [PATCH 1/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver Message-ID: <20200908182220.GA3290129@lunn.ch> References: <20200907181854.GD3254313@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 08, 2020 at 07:49:20PM +0200, Lukasz Stelmach wrote: > It was <2020-09-07 pon 20:18>, when Andrew Lunn wrote: > >> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote: > >> >> +++ b/drivers/net/ethernet/asix/ax88796c_ioctl.c > >> > > >> > This is an odd filename. The ioctl code is wrong anyway, but there is > >> > a lot more than ioctl in here. I suggest you give it a new name. > >> > > >> > >> Sure, any suggestions? > > > > Sorry, i have forgotten what is actually contained. > > IOCTL handler (.ndo_do_ioctl), ethtool ops, and a bunch of hw control > functions. > > > Does it even need to be a separate file? > > It doesn't need, but I think it makes sense to keep ioctl and ethtool > stuff in a separate file. Some of the hw control function look like they > might change after using phylib. _ethtool.c is a common file name. > Good point. I need to figure out how to do it. Can you point (from the > top fou your head) a driver which does it for a simmilarly integrated > device? Being integrated or not makes no difference. The API usage is the same. drivers/net/usb/smsc95xx.c has an integrated PHY i think. > I am not arguing to keep the parameter at any cost, but I would really > like to know if there is a viable alternative for DT and ACPI. This chip > is for smaller systems which not necessarily implement advanced > bootloaders (and DT). What bootload is being used, if not uboot or bearbox? > According to module.h > > /* > * Author(s), use "Name " or just "Name", for multiple > * authors use multiple MODULE_AUTHOR() statements/lines. > */ Thanks, did not know that. > >> >> + struct net_device *ndev = ax_local->ndev; > >> >> + int status; > >> >> + > >> >> + do { > >> >> + if (!(ax_local->checksum & AX_RX_CHECKSUM)) > >> >> + break; > >> >> + > >> >> + /* checksum error bit is set */ > >> >> + if ((rxhdr->flags & RX_HDR3_L3_ERR) || > >> >> + (rxhdr->flags & RX_HDR3_L4_ERR)) > >> >> + break; > >> >> + > >> >> + if ((rxhdr->flags & RX_HDR3_L4_TYPE_TCP) || > >> >> + (rxhdr->flags & RX_HDR3_L4_TYPE_UDP)) { > >> >> + skb->ip_summed = CHECKSUM_UNNECESSARY; > >> >> + } > >> >> + } while (0); > >> > > >> > > >> > ?? > >> > > >> > >> if() break; Should I use goto? > > > > Sorry, i was too ambiguous. Why: > > > > do { > > } while (0); > > > > It is an odd construct. > > As to "why" — you have correctly spotted, this is a vendor driver I am > porting. Although it's not like I am trying to avoid any changes, but > because this driver worked for us on older kernels (v3.10.9) I am trying > not to touch pieces which IMHO are good enough. My experience with vendor drivers is you nearly end up rewriting it to bring it up to mainline standards. I would suggest first setting up some automated tests, and then make lots of small changes, committed to git. You can then go backwards and find where regressions have been introduced and found by the automated tests. And then every so often squash it all together, ready for submission. > To avoid using do{}while(0) it requires either goto (instead of breaks), > nesting those if()s in one another or a humongous single if(). Neither > looks pretty and the last one is even less readable than > do()while. I removed too much context. Does anything useful happen afterwards? Maybe you can just use return? Or put that code into a helper which can use return rather than break? Andrew