Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp282352ybj; Fri, 8 May 2020 11:41:50 -0700 (PDT) X-Google-Smtp-Source: APiQypIMu22+fell6fgnEc4ByuB6GTYXg9MtTgvNat+dwsJeZ2dV61O3d5s0KvpPuUBy/+1ftJ/H X-Received: by 2002:aa7:cf16:: with SMTP id a22mr3342390edy.77.1588963310316; Fri, 08 May 2020 11:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588963310; cv=none; d=google.com; s=arc-20160816; b=PcvsHTqTA0cM5K88tL7VYHJvg0BBjV92CXWKnSEPBXhbR8uPoBmSMsQqO+kQN0IbdQ RRL56vU+KC+2aiugBQiPvt7bBaDRIvI2uUrVEsuJgP2w08DWi0Z8KsBGS5n8xUAodq4Q Ee9WO0fkJqgq4AdX20bsuUbT7UlqCwAQan1Rc5b8DgXjTFAdDVI27vZfxGo20eL4Eoub TEO+4CvEvgVrjPxKHzcdUtWibQ5KTpb+uQEFdY/oje1SVehf3YNRhGErIMDsyOfLNjX3 IN5AAHtWqAVBxoA6PYblFD1g4Ky6Mnv4uKTQT6IFlZsSUnpmFK+0EQMydyakozxFLui/ AiKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=RGIpRsn9hXDxHTNl/QnLM0SbzmG3DHjOVcysfR1ByLg=; b=1CYl6azeMrGCFDwGLDrHqe+npQuaG/lR+LMYnqHFpp3/YkznloHKZjvuZ8JaHoOIeZ KmQ3qamhT1n8k0hRRHKNHdyAvBpT7gs/8SFDKUeBHoHbX/OZlxAchnFVl2a6kOMfuqIV zRADzQtr51KCW52EqnHAd3x9f4nqdYgKaCnEQaFKxt78goTU5eR2kNPogVpLz9z7z7ls VUwA82SwtLnuptY0zq1rxC4M16gOAOpJnsx/gNp9LZkEZNeNNTzAFOdeONV1BKTCpDNn gc7s8LqhrQDgRA96xDgvO3c+SS9caMwN+vebA0+hktFgTlSASudfabp3UA/8vEWaQV6f PcrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=bqJnS5va; 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 g14si1379975ejo.108.2020.05.08.11.41.27; Fri, 08 May 2020 11:41:50 -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=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=bqJnS5va; 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 S1727111AbgEHSje (ORCPT + 99 others); Fri, 8 May 2020 14:39:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726817AbgEHSje (ORCPT ); Fri, 8 May 2020 14:39:34 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53C02C05BD43 for ; Fri, 8 May 2020 11:39:34 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id r2so2328187ilo.6 for ; Fri, 08 May 2020 11:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RGIpRsn9hXDxHTNl/QnLM0SbzmG3DHjOVcysfR1ByLg=; b=bqJnS5vane6smgkAuFEEcD0f6Ycc9yf0lJgeJRU4JjUw54yjKs7BXh8x7lk1vbGGnV 0f+IMGeKn3Gw8E15EFVxSoihcpqVq3H2ka3HfRPYyf0OuTLXCPToeBb+OyVQEtZC7lHl zuolyQtCP3X66zQBV9+hARMxLnivHPtSnxXf5rUK+0xz88gPQQ3kiIwNSw4silZ09ksy iZesm817N+ct23uLjo+cnMxE5KHcCYtZJFFhLRXkIQCkpT0bZ5O/5lBtIwyt1tjgyZpr XXPJFtNZ04z6cdHl7rsn9ul842f84tS91OI8taD3ChAh0ODWd61l9meBxJla50/OQul7 oA8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RGIpRsn9hXDxHTNl/QnLM0SbzmG3DHjOVcysfR1ByLg=; b=suTdqsGNmd9snOKpzLCHyethhRL3qXPnWjR+vTtzpD+/JiGl9U1KNjroBpsxNkNWdV ZiFHU59Yg9HHkxfe2trgvGfDmnALzrxMcbW5bwWu6Kv/Ynrm3cO7iq8eLbSwhSNa3FrJ YMo3uEf0OK+h/MTCUw2pbYnZyTgL44jn0B2Sk7kgt32f6lEj/g3g+1t9etB2N3ZJhuoo ew74EDoPWDv9itwXLscpL2NjqgXh/kYCAMjohbVufRbWunjBolGy93ic8AucmIpsXGaV SfeapicaW6atz0BF7UoRB0vvBOw6GnxsUfXJUFWE/izIuUsnbdZMoiZfNb4aVghpwzxz VGFg== X-Gm-Message-State: AGi0Pua0aL0WfgAFc5BFbX+c2P1F+OIwumjxxFzbdMZ+R3cVj82+Wrzs JKJtUkPkne96Vp6dVbsEwHezbUqb7ZBjFfaGKNcdXw== X-Received: by 2002:a92:aa07:: with SMTP id j7mr4467857ili.40.1588963173745; Fri, 08 May 2020 11:39:33 -0700 (PDT) MIME-Version: 1.0 References: <20200505140231.16600-1-brgl@bgdev.pl> <20200505140231.16600-6-brgl@bgdev.pl> <20200505103105.1c8b0ce3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200506101236.25a13609@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200507095315.1154a1a6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200507155650.0c19229e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: From: Bartosz Golaszewski Date: Fri, 8 May 2020 20:39:22 +0200 Message-ID: Subject: Re: [PATCH 05/11] net: core: provide devm_register_netdev() To: Heiner Kallweit Cc: Jakub Kicinski , Bartosz Golaszewski , Rob Herring , "David S . Miller" , Matthias Brugger , John Crispin , Sean Wang , Mark Lee , Arnd Bergmann , Fabien Parent , devicetree , Linux Kernel Mailing List , netdev , Linux ARM , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org pt., 8 maj 2020 o 07:54 Heiner Kallweit napisa=C5=82= (a): > > On 08.05.2020 00:56, Jakub Kicinski wrote: > > On Thu, 7 May 2020 19:03:44 +0200 Bartosz Golaszewski wrote: > >>> To implement Edwin's suggestion? Makes sense, but I'm no expert, let'= s > >>> also CC Heiner since he was asking about it last time. > >> > >> Yes, because taking the last bit of priv_flags from net_device seems > >> to be more controversial but if net maintainers are fine with that I > >> can simply go with the current approach. > > > > From my perspective what Edwin suggests makes sense. Apart from > > little use for the bit after probe, it also seems cleaner for devres > > to be able to recognize managed objects based on its own state. > > > What I was saying is that we should catch the case that a driver > author uses a device-managed register() w/o doing the same for the > alloc(). A core function should not assume that driver authors do > sane things only. > I don't have a strong preference how it should be done. > Considering what is being discussed, have a look at get_pci_dr() and > find_pci_dr(), they deal with managing which parts of the PCI > subsystem are device-managed. Yes, I have - that's why I asked if anyone objects to me moving all networking devres functions into their own source file. The reason for that being: devres_find() needs to know the address of the release function, meanwhile devm_register_netdev() would have to go into net/core, while devm_alloc_etherdev() lives in net/ethernet. Bart