From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757931AbdJLXFS (ORCPT ); Thu, 12 Oct 2017 19:05:18 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:56650 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757724AbdJLXFJ (ORCPT ); Thu, 12 Oct 2017 19:05:09 -0400 X-Google-Smtp-Source: AOwi7QB7RbvXQWlpuXbzFjxeOAlDNMt33jLbdXJTIrg2jT27Ia/JFo42lzqTNNYADIxLe2tpyl1Rng== Subject: Re: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member To: Vivien Didelot , netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, kernel@savoirfairelinux.com, "David S. Miller" , Andrew Lunn References: <20171012225156.20758-1-vivien.didelot@savoirfairelinux.com> <20171012225156.20758-6-vivien.didelot@savoirfairelinux.com> From: Florian Fainelli Message-ID: <5b637ea3-6c4b-1d93-ed43-09038af473f9@gmail.com> Date: Thu, 12 Oct 2017 16:05:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171012225156.20758-6-vivien.didelot@savoirfairelinux.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/12/2017 03:51 PM, Vivien Didelot wrote: > The dsa_port structure has a "netdev" member, which can be used for > either the master device, or the slave device, depending on its type. > > It is true that today, CPU port are not exposed to userspace, thus the > port's netdev member can be used to point to its master interface. > > But it is still slightly confusing, so split it into more explicit > "master" and "slave" members. I do see some value in doing that, although I also see value in having structure members be named after what they are, rather than their use (oh well, it's all debatable anyway), see below for a suggestion on how to reconcile the two: > struct dsa_port { > + /* Master device, physically connected if this is a CPU port */ > + struct net_device *master; > + > + /* Slave device, if this port is exposed to userspace */ > + struct net_device *slave; > + How about using: union { struct net_device *master; struct net_device *slave; } netdev; Such that this serves both purposes of clearly communicating what the structure member is, and it can be either one of the two, but not both at the same time? -- Florian