From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA627C54E8F for ; Mon, 11 May 2020 16:39:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AA36520714 for ; Mon, 11 May 2020 16:39:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="kRR8fAIc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729550AbgEKQjR (ORCPT ); Mon, 11 May 2020 12:39:17 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:54004 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728556AbgEKQjQ (ORCPT ); Mon, 11 May 2020 12:39:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PO2c3L65UWqL1EcOkY6DtrTcnu4QOhrD4mFFAvp9mOQ=; b=kRR8fAIckpSJoyBIVZvk5Ch9q/ 8NsxPE3cQU+6IoWGenHjd+iDoF4PopnCIiln9GsylXeZN+Gmg4aLn2Gh/1wGK/q2s53Oi1jc9iamT 2W8dv+rlBtfIaLOlx01u831Bev6nPjrTpk8VeQZez+6vCAEUVxnsA+6FTKo0EkYG12fU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jYBSM-001sLM-JX; Mon, 11 May 2020 18:39:06 +0200 Date: Mon, 11 May 2020 18:39:06 +0200 From: Andrew Lunn To: Bartosz Golaszewski Cc: Rob Herring , "David S . Miller" , Matthias Brugger , John Crispin , Sean Wang , Mark Lee , Jakub Kicinski , Arnd Bergmann , Fabien Parent , Heiner Kallweit , Edwin Peer , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Stephane Le Provost , Pedro Tsai , Andrew Perepech , Bartosz Golaszewski Subject: Re: [PATCH v2 05/14] net: core: provide priv_to_netdev() Message-ID: <20200511163906.GD413878@lunn.ch> References: <20200511150759.18766-1-brgl@bgdev.pl> <20200511150759.18766-6-brgl@bgdev.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200511150759.18766-6-brgl@bgdev.pl> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, May 11, 2020 at 05:07:50PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Appropriate amount of extra memory for private data is allocated at > the end of struct net_device. We have a helper - netdev_priv() - that > returns its address but we don't have the reverse: a function which > given the address of the private data, returns the address of struct > net_device. > > This has caused many drivers to store the pointer to net_device in > the private data structure, which basically means storing the pointer > to a structure in this very structure. To some extent, that is the way it is done now. To do anything else just makes your driver different and so harder to maintain. Is 4/8 bytes for a pointer really worth being different? Andrew