Received: by 2002:a19:ef0c:0:0:0:0:0 with SMTP id n12csp951365lfh; Tue, 1 Feb 2022 12:54:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJyyqPa8jzOqStbxcel1u2awOP8ibdIghb0/3TTV1U0fPquEkuBEhFVWKFQCfHpWl69+VsCi X-Received: by 2002:a63:580e:: with SMTP id m14mr22237588pgb.351.1643748745866; Tue, 01 Feb 2022 12:52:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643748745; cv=none; d=google.com; s=arc-20160816; b=t42+EadqoMMiMmW4vWCK8NIsmCXK228/6tUMCXzU9kgv1T12Vk+w1+2B0a5Nl3NkVv jjS1hxOao7AaODCCGqUqj0pw1o2E+IVXWGKlzVUE99AxzqAkDEjtqQQ+2AyGdGWWOMTK sapvBUNEsscDFpW2hf5vbPrrCu5SOs//qZlOs/G+tmCuAdLxliRU8z/rHI+Rh47smSSt 11pqAw/X7VdF5qAlWucvQstcwHH2qZI8Xhq5ySf8/29SPDd32b0jtno+JYcfqbddfuN4 DAyPwJjGwnNv3Yr8n9ZzayY7w8Bbj2edeEuLoI7HKm3jA1QIORQ8f+w88ZBLJh68DKgo mohQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=v5RcyeeHHXW9j3hXHNrkcObjXy4CdCazV/xa6UgsjRk=; b=moH+8YsT/FixqNph2C81iM94wPUey270mtSXqcsmPZJv/INOZMz1Np5TOFXCkWykDy 1NluyypV1FpK/wOd666gAYvLv627LlwCG7uc9mxcb+cqI0HunSUxG1nGkfDvgmZhPlkr aQWGHvoAjvzwqVa+rleINKvUt0q/+5IMw3qRK8qfl0B9qA2d02gsbYSd9Ls3KiKdQUWZ Q47dZp//+u2DamJSOQvjVxB1bXFnYF/6UvwKc+D3E+NoVSD+ezBdBTxQFMr6hWSK+eXj 1JISQR29peExjXikBXL9uhvzb00/xUDvdd127ew18t5HSX5qwtxJsCJYSU5S8RQl9noG ULbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=FuLO1unf; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y18si1076429plb.204.2022.02.01.12.52.14; Tue, 01 Feb 2022 12:52:25 -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=@gmail.com header.s=20210112 header.b=FuLO1unf; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237013AbiAaXGJ (ORCPT + 99 others); Mon, 31 Jan 2022 18:06:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235258AbiAaXGI (ORCPT ); Mon, 31 Jan 2022 18:06:08 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 953C7C061714; Mon, 31 Jan 2022 15:06:08 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id i186so11714587pfe.0; Mon, 31 Jan 2022 15:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=v5RcyeeHHXW9j3hXHNrkcObjXy4CdCazV/xa6UgsjRk=; b=FuLO1unfVDoVExaEbAXmMG9VT/XrOxSzURa4tb2lWs/3zb6PQsqobF2i9HNgnVWIcZ 6TEtH+pMj/eZ1ZbIrdxWCmJ7akU6yPujMiyI27+AQj4RgErAG05Yejjm0B5E0kINMMpJ PUPEIzwCcqDYsP53mzCSk2flxEPLDTCLy3MxEVCQ0Cc9Lj+h1pija49ucqBL85K5GzNB +3S+rtiU+gSpJFO8H2sRj80O6cuUCz0wg2mIUj1OTcnA4BKaLNG/+6h0VNq9FtPjuukX bBs2XgOgHjsrEldPoKWc6dxLTS0NM9vTBwwCoq1OEfeQMbBG1j/K/AyPKMobKYpDJoN4 RmXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=v5RcyeeHHXW9j3hXHNrkcObjXy4CdCazV/xa6UgsjRk=; b=G4/YBZgFTSui22vivbmr5Adf+r8LymQjv/Dnwzem0y5ai9KPx76PznlKr2CWhdN5YO paDlJfOelPwfzN/OpF0OCsQkEAgA1NT9S3BYlp4jGS5k9D+bmiFrNWOe4RUzZ0gSnW/l yJXBvdqutrFntFaivxXuQGSAR6BqeurrGo0hm+xQibnubIb3zTuR9yTio53Yxln7y6wn Qa9dN7WBapLvo14+QGSpFSRWdNeByJQ37KIlbA4G7il2m30ussqQw0QqB7U3xglT8DBd DwBeQsoVQ0j5qlJZY4FTOkV3vfcKdnPCWPwLyrEt/FGIk0dW6TDIUMdR23AI6Q1uMoPv hOiw== X-Gm-Message-State: AOAM532hpqGg0djmLEqHSNFW2tzemTvzcnpTKiyyA99Vkg+O8hl6hAcs 61e4Nu7qy8cctgNJO0fTwqM= X-Received: by 2002:a63:8ac9:: with SMTP id y192mr18240787pgd.409.1643670367856; Mon, 31 Jan 2022 15:06:07 -0800 (PST) Received: from [192.168.1.3] (ip72-194-116-95.oc.oc.cox.net. [72.194.116.95]) by smtp.gmail.com with ESMTPSA id gb5sm366101pjb.16.2022.01.31.15.06.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 15:06:07 -0800 (PST) Message-ID: <7dc930c6-4ffc-0dd0-8385-d7956e7d16ff@gmail.com> Date: Mon, 31 Jan 2022 15:06:01 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH net-next] net: kbuild: Don't default net vendor configs to y Content-Language: en-US To: Jakub Kicinski Cc: Saeed Mahameed , Geert Uytterhoeven , Stephen Hemminger , Saeed Mahameed , "David S. Miller" , Mark Einon , Lino Sanfilippo , Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Shay Agroskin , Arthur Kiyanovski , David Arinzon , Noam Dagan , Saeed Bishara , Chris Snook , Nicolas Ferre , Claudiu Beznea , Hans Ulli Kroll , Linus Walleij , Jeroen de Borst , Catherine Sullivan , David Awogbemila , Yisen Zhuang , Salil Mehta , Jesse Brandeburg , Tony Nguyen , "K . Y . Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Vladimir Oltean , Claudiu Manoil , Alexandre Belloni , Microchip Linux Driver Support , Jon Mason , Simon Horman , Rain River , Zhu Yanjun , Shannon Nelson , drivers@pensando.io, Sergey Shtylyov , Jiri Pirko , Edward Cree , Martin Habets , Maxime Coquelin , Alexandre Torgue , Jose Abreu , Andy Gospodarek , Michal Simek , Arnd Bergmann , Jacob Keller , Vegard Nossum , Rob Herring , l.stelmach@samsung.com, rafal@milecki.pl, Edwin Peer , Geert Uytterhoeven , Michael Chan , Richard Cochran , Gerhard Engleder , Marcin Wojtas , Oleksij Rempel , Gabriel Somlo , Joel Stanley , Slark Xiao , Christophe Leroy , Liming Sun , David Thompson , Asmaa Mnebhi , Lars Povlsen , Horatiu Vultur , Steen Hegelund , Prabhakar Kushwaha , Omkar Kulkarni , Shai Malin , Randy Dunlap , Vignesh Raghavendra , Stefan Wahren , Gary Guo , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, intel-wired-lan@lists.osuosl.org, linux-hyperv@vger.kernel.org, oss-drivers@corigine.com, linux-renesas-soc@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com References: <20220131172450.4905-1-saeed@kernel.org> <20220131095905.08722670@hermes.local> <20220131183540.6ekn3z7tudy5ocdl@sx1> <30ed8220-e24d-4b40-c7a6-4b09c84f9a1f@gmail.com> <20220131121027.4fe3e8dc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> From: Florian Fainelli In-Reply-To: <20220131121027.4fe3e8dc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/31/2022 12:10 PM, Jakub Kicinski wrote: > On Mon, 31 Jan 2022 10:40:38 -0800 Florian Fainelli wrote: >>>> And changing the defaults means all defconfigs must be updated first, >>>> else the user's configs will end up without drivers needed. >>>> >>> >>> As I understand correctly, at least for most common net drivers, having >>> NET_VENDOR_XYZ=y doesn't actually build anything, we have flags per >>> module for each vendor and those are defaulted to N. >> >> Right, but once you start hiding NET_VENDOR_DRIVER_XYZ under a >> NET_VENDOR_XYZ Kconfig symbol dependency, if NET_VENDOR_XYZ is not set >> to Y, then you have no way to select NET_VENDOR_DRIVER_XYZ and so your >> old defconfig breaks. > > To be clear do we actually care about *old* configs or *def* configs? I think we care about oldconfig but maybe less so about defconfigs which are in tree and can be updated. > > Breaking defconfigs seems bad, but I don't think we can break > reasonable oldconfigs at this point? No preference either way for me, just like Richard, all of the systems I typically work with either require a carefully curated configuration file to strip out unwanted features. I do like Geert's suggestion of adding default ARCH_ for slightly esoteric controllers that are not found in off the shelf hardware. > >>>> It might make sense to tune some of the defaults (i.e. change to >>>> "default y if ARCH_*") for drivers with clear platform dependencies. >>>> >>> >>> either set hard default to 'n' or just keep it as is, anything else is just >>> more confusion. >> >> Maybe the rule should go like this: any new driver vendor defaults to n, >> and existing ones remain set to y, until we deprecate doing that and >> switching them all off to n by 5.18? > > I'd be afraid that given the work of fixing up defconfigs is > non-trivial we may end up never switching old drivers. And then we'd > have a semi-random soup of defaults :( Fair enough. -- Florian