Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4336412imm; Mon, 30 Jul 2018 12:43:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdFVBZXOT6DpeYi286zRZpNmP3Oe9M3Gcby5GiKEZmwbQ2r1EoLqiTTf+FYlNxKDkpRtF7r X-Received: by 2002:a62:954:: with SMTP id e81-v6mr19162965pfd.231.1532979829515; Mon, 30 Jul 2018 12:43:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532979829; cv=none; d=google.com; s=arc-20160816; b=yeNh4VCjyGS7Ae0jERrsIAdGcNjVf/rPCYSXPaI6my60CCknZc/oh3TX6+OVTvNSH/ O6MqCrSrtlN9vkj81y67MbjZhZkwb5/STEBq17zOQAvkIc4R9QCVIq+cGYYciWR6DxYM 7oMyuuLO3TBy1qTigmu9Kh3wkMkmpQ4gsqrOTKzpgcbYiwzL6JP/40U5vJJ1lQmFGqY4 HZ+sxNBeyyYHrWNkyagVgheaUkYLlx4lTQha/HVK6/x6SpsJ2j4I2GTkgS6EwBTO+6xR /GGOLbXBSdBX5Y5t067H6t2+WXUd5Akr9uWHGUzujhODNWvb2CKt18Tu0/8xA1/AtBg1 tQKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DBy4+jeK2b4RviwAXN4US5OCUkjIerFewxLMrC4mypQ=; b=YneIK1KEXO3975YxspH7GUyOkES0eZ+F+J1KwmtdVA5kUovy2h0CK7tg/vcxn0s0h+ 1+O5DjSi7CVn6R+Xs9YoDp+bh1+wy51jBsO7yDQjhhCaudKckidCqIVZ8NAwDLghqmjw Os11MJ/zya1VJqTNeEs4mTLp+kpxXtWdPec05iuGyrSWUA8i32svFO8cwOA5i80jHYED QjgextceXVB6t5dS3cGHYNfES1BaZ4lcQyz53e2PF4WzlBIoo7UezpZshIYtO5WiF79v DXhTno0ng1JaAVK5+2SvbHzSX/2coHWmH4+iyuBtJav34y8BP/asxMJNwgkSOfQGduj/ b3oQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v65-v6si12410489pfk.261.2018.07.30.12.43.35; Mon, 30 Jul 2018 12:43:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731812AbeG3VTR (ORCPT + 99 others); Mon, 30 Jul 2018 17:19:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:52846 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727037AbeG3VTQ (ORCPT ); Mon, 30 Jul 2018 17:19:16 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5DB67ACC8; Mon, 30 Jul 2018 19:42:44 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 989F1A0BE8; Mon, 30 Jul 2018 21:42:42 +0200 (CEST) Date: Mon, 30 Jul 2018 21:42:42 +0200 From: Michal Kubecek To: Andrew Lunn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jiri Pirko , David Miller , Florian Fainelli , Roopa Prabhu , Jakub Kicinski , "John W. Linville" Subject: Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message Message-ID: <20180730194242.daornhxcc74o7f4c@unicorn.suse.cz> References: <67d3b68a50e95db9612cc96e42a52ce332f716a9.1532953989.git.mkubecek@suse.cz> <20180730190941.GL2983@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180730190941.GL2983@lunn.ch> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 30, 2018 at 09:09:41PM +0200, Andrew Lunn wrote: > > +Response contents: > > + > > + ETHA_SETTINGS_LINK (u32) link state > > > + [ETHA_SETTINGS_LINK] = { .type = NLA_FLAG }, > > Is this correct? NLA_FLAG is wrong, we need three states: on/off/unknown for "get" replies and on/off/keep for "set" requests. > The link is either up or down. So a u32 seems a bit big. I tend to use u32 everywhere with some obvious exceptions. The reason is that netlink attributes are padded to 32 bits so that no matter if you use u8, u16 or u32, the attribute still ends up taking 8 bytes. But yes, this looks like an obvious exception where u8 wouldn't mean any risk of running out of values one day. Michal Kubecek