Received: by 2002:a19:ef0c:0:0:0:0:0 with SMTP id n12csp951070lfh; Tue, 1 Feb 2022 12:53:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwFXZZK2NxQBsR4LJ2ze2vR+k52mxbJy/Y7k5BpNiM0AexihIglfTymer5tSNDt87flt3ut X-Received: by 2002:a17:90b:f07:: with SMTP id br7mr4350645pjb.89.1643748810466; Tue, 01 Feb 2022 12:53:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643748810; cv=none; d=google.com; s=arc-20160816; b=pZLU906UM4HL4Uw3qS7JSELa5PDYJQ3agH0LgScqNMHK2xB8/naoluF+PkVw8Jp9QN 6wt6lF0PIezFadlvcrr7j8UmdIMWWjZ/YqFKabgUozvq/eWLHPVq7SxR68r7YD5bnJdA sPM1tN3m7mRtOehBiQj8AB3ymCPLqzvAuLD9plNu1Wf+Q1f47HfMv5SRiqQEiUq/kfc5 j4Qp6ljNJTYg/KXN8n68zOGawiaofmj8JttMcQf0feqfYSemM5rzBAbVSLsJYVUieB5R eWSKFYydK4EW/+Dz03DygO80t/1mcYHVyf2lXV6Dm1rC+b3E5txyFZlvaq0L+Mv8Dagw gZ9g== 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=iZPK2sAyA69eoDqEXUQzxvsoijuCaRQioI5r1fK2jIg=; b=nixOznfsVF1SQfef1Pzj3TP3PU7ztej9757f8R72V2yLGy71POgtNkbqB7K3TAW8Ra CjCT1JHTXNHbeVOBRVu0Wwn13Zfb1+joINEOv5/94XP62PYkVojW+8HDDnuz67SloluH QrMuZfL4tdvW+kpPOeOzXj6/3CESYIjLzlBk5hJQcuZoIupffhbNvDuII7OF60tvISjv A1gfg0KV1/YYQeRo1NW3AYnwxD8WUaYxlkvCbh43oVo7XqZ027QXNRUyMtwseUlcfb3V LPLmt/u71uJD5W0bOr8F62wOpha6DaaIG03V4d/Qt/tplEVs4hZgVmkViQuxyVkfgFpU y/BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IeYmosIh; 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 o3si16559193pfu.92.2022.02.01.12.53.19; Tue, 01 Feb 2022 12:53:30 -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=IeYmosIh; 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 S237776AbiAaXNY (ORCPT + 99 others); Mon, 31 Jan 2022 18:13:24 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:57272 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237496AbiAaXNW (ORCPT ); Mon, 31 Jan 2022 18:13:22 -0500 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 15A8AB82CC6; Mon, 31 Jan 2022 23:13:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93EF1C340E8; Mon, 31 Jan 2022 23:13:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643670799; bh=3qFSuUKUP32If9vkUAh7+Qa4t/86G61Dz7klzbTOZIA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IeYmosIheVuVTUo8TbFb42UxdN1/uJoNP+EbfjiSm2MkeSo6BfXFwSuLDx5lb1De1 KIAVWr3dMYWV+oVY6i8Xrs8OVh8/UKXM6RfUdXMrosGM0viyNH0MIQXNRkLJvVInDO 1SmGwAvIA2AMzJLEJETvv/RUbca9pnH9yda62Wxqtbw7m8neBTLLKidDvRoBeM891Z 7YMJk0If2vdvZegbHkI/+ajhc2tAR1s7O6Z7g9oqcXmqnuimV/1l+xB8WbPzyBcdb5 H+VNEnflBc5Gms8USCZQW2rN4gV04YZ7iT0lGiGRw8Bkc3tMId0hqqhPIDY9lY5+Iy UrrAc0Zg68K4g== Date: Mon, 31 Jan 2022 15:13:15 -0800 From: Jakub Kicinski To: Florian Fainelli 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 Subject: Re: [PATCH net-next] net: kbuild: Don't default net vendor configs to y Message-ID: <20220131151315.4ec5f2d3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <7dc930c6-4ffc-0dd0-8385-d7956e7d16ff@gmail.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> <7dc930c6-4ffc-0dd0-8385-d7956e7d16ff@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 Mon, 31 Jan 2022 15:06:01 -0800 Florian Fainelli wrote: > >> 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. The oldconfigs would have to not be updated on any intervening kernel in the last 10+ years to break, right? Or is there another way that an oldconfig would not have the vendor config set to y at this point?