Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp1550275lkv; Wed, 19 May 2021 12:33:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvoUwXCWwiRh8lv8LPUnjw++i2jX1MQzXgtljNko3qPxQDXUyet7N+jnpjcpWFDj6HpJ0/ X-Received: by 2002:a6b:f21a:: with SMTP id q26mr1154123ioh.152.1621452792322; Wed, 19 May 2021 12:33:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621452792; cv=none; d=google.com; s=arc-20160816; b=mXASdcU3Qh9xawb0pfNdC6SmKCLl9svZ62rdXFRd/BX6tx/OZT+pmL68ecBDCXWL7o SAuTVL/DW7nj1JXdLfKGLG1uVtYcUEOaJbf+QanudEeS8UeDDxKcoteQNIzGgQVnub5w mU6YEI84nNP04607NvZ6sXr4gpN+Q+e3OCQhfYE9BM2V1+A1jNunVkyJLBkZJJ5OI0bN esZgAHdgF7DO70hIoFlWUgdwJK9+jgaDHpqCMnMUA8wJ3ucWMXbXrv7FZF7851msuVBA KK1OAZye0C/ocY2CtHa8Z67sY+dH53qqceovJgFRmApz0sNGvERp5F9BKI5IjlT1/FLE G2Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=iPJX7n32ZqUihk3cs9bEttHAe7eWM5NFJjTzqpkn35A=; b=zHMMVzZ1kqYfXjEvIuLfOcVPycKhBspWD6Ybw+ZWiOPdZ4lM6V3sf097dxHGdKybRO gy5XBiaDmxDTm4hE9EUOdZLrv4ocoYKff2W0xp3yMK3OB5lkEaNRim6C42wGu0+5AoYo SCJ9rSYRvX5Bfys0vO9mYbkpnn2c4BeXJsVXXk8CfBCczDwJzLT2U6BsD/pTF+zT2C0d Gyopm8x393/880ooaGCtKz8Mw7G4qB6Dy41NHVTR0B+5H9dfM7TR5tTtceBEIJSWFTJr Tlktdu5mkGb6o/Hu3sTXFL4f3H+WP/pyr312pmf8oF2uuR89DK05bAP5wH27Uit18xT1 nY3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pCNyEIxV; 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 q3si670460ilu.88.2021.05.19.12.32.59; Wed, 19 May 2021 12:33:12 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pCNyEIxV; 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 S1353471AbhESM5o (ORCPT + 99 others); Wed, 19 May 2021 08:57:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:58586 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232671AbhESM5m (ORCPT ); Wed, 19 May 2021 08:57:42 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C0EAA6124C; Wed, 19 May 2021 12:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621428982; bh=uHLg5icCC3xpZyJI1+jRahgAtowPa/rbAim0BxR6NR8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pCNyEIxV9y1+0VGujexB6B/CDIPzVD7OZ2RN9jpzcgqUbSqVs+425K63NnxyeOLiW qroY126NCh4zhx0dBonpOioJ4PUpLAtkTx/MuCYzEE/vgSK+FJLumLjCbLsAK3ngtb krIDkJgejF5SVLTmDqZGp85NLbINqcabNg4YyxjCS6IA5KodCRWo4m6J2rEOQBvdfy COwpEt0BJLSbTDVM2q+BcT5CYUkCnt1q7+H61v5J+0+4RQCLvUX6VapzcjN7y9XWsF zBSYjeg+0RX8+U8hfz8qVTrO8CC0BOTlux96NksmCBL5/jBLEhSaWz94k1TLcs+2l6 gYaUSm3zE1CiA== Date: Wed, 19 May 2021 15:56:18 +0300 From: Leon Romanovsky To: Peter Geis Cc: Heiner Kallweit , Andrew Lunn , Russell King , "David S . Miller" , Jakub Kicinski , Linux Kernel Mailing List , Linux Kernel Network Developers , "open list:ARM/Rockchip SoC..." Subject: Re: [PATCH] net: phy: add driver for Motorcomm yt8511 phy Message-ID: References: <20210511214605.2937099-1-pgwipeout@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 19, 2021 at 08:45:21AM -0400, Peter Geis wrote: > On Wed, May 19, 2021 at 7:50 AM Leon Romanovsky wrote: > > > > On Wed, May 19, 2021 at 12:37:43PM +0200, Heiner Kallweit wrote: > > > On 19.05.2021 10:18, Leon Romanovsky wrote: > > > > On Tue, May 18, 2021 at 08:20:03PM -0400, Peter Geis wrote: > > > >> On Tue, May 18, 2021 at 4:59 AM Leon Romanovsky wrote: > > > >>> > > > >>> On Tue, May 11, 2021 at 05:46:06PM -0400, Peter Geis wrote: > > > >>>> Add a driver for the Motorcomm yt8511 phy that will be used in the > > > >>>> production Pine64 rk3566-quartz64 development board. > > > >>>> It supports gigabit transfer speeds, rgmii, and 125mhz clk output. > > > >>>> > > > >>>> Signed-off-by: Peter Geis > > > >>>> --- > > > >>>> MAINTAINERS | 6 +++ > > > >>>> drivers/net/phy/Kconfig | 6 +++ > > > >>>> drivers/net/phy/Makefile | 1 + > > > >>>> drivers/net/phy/motorcomm.c | 85 +++++++++++++++++++++++++++++++++++++ > > > >>>> 4 files changed, 98 insertions(+) > > > >>>> create mode 100644 drivers/net/phy/motorcomm.c > > > >>> > > > >>> <...> > > > >>> > > > >>>> +static const struct mdio_device_id __maybe_unused motorcomm_tbl[] = { > > > >>>> + { PHY_ID_MATCH_EXACT(PHY_ID_YT8511) }, > > > >>>> + { /* sentinal */ } > > > >>>> +} > > > >>> > > > >>> Why is this "__maybe_unused"? This *.c file doesn't have any compilation option > > > >>> to compile part of it. > > > >>> > > > >>> The "__maybe_unused" is not needed in this case. > > > >> > > > >> I was simply following convention, for example the realtek.c, > > > >> micrel.c, and smsc.c drivers all have this as well. > > > > > > > > Maybe they have a reason, but this specific driver doesn't have such. > > > > > > > > > > It's used like this: > > > MODULE_DEVICE_TABLE(mdio, ); > > > > > > And MODULE_DEVICE_TABLE is a no-op if MODULE isn't defined: > > > > > > #ifdef MODULE > > > /* Creates an alias so file2alias.c can find device table. */ > > > #define MODULE_DEVICE_TABLE(type, name) \ > > > extern typeof(name) __mod_##type##__##name##_device_table \ > > > __attribute__ ((unused, alias(__stringify(name)))) > > > #else /* !MODULE */ > > > #define MODULE_DEVICE_TABLE(type, name) > > > #endif > > > > > > In this case the table is unused. > > > > Do you see compilation warning for such scenario? > > The issue you are describing has been fixed since 2010: > > commit cf93c94581bab447a5634c6d737c1cf38c080261 > Author: Uwe Kleine-K?nig > Date: Sun Oct 3 23:43:32 2010 +0000 > > net/phy: fix many "defined but unused" warnings > > MODULE_DEVICE_TABLE only expands to something if it's compiled > for a module. So when building-in support for the phys, the > mdio_device_id tables are unused. Marking them with __maybe_unused > fixes the following warnings: > > There is a strong push to fix all warnings during build, including W=1 warnings. > For fun I rebuilt without module support and confirmed that removing > this does trigger a W=1 warning. I'm sorry that I continue to ask, but is net/phy/* usable without MODULE? If not, the better fix is to require it in Kconfig instead of fixing all drivers. Thanks for your answers. > > > > > Thanks > > > > > > > > > Thanks > > > > > > > >> > > > >>> > > > >>> Thanks > > > > > >