[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au>
Date: Fri, 08 Nov 2024 16:10:49 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Jakub Kicinski <kuba@...nel.org>, Khang Nguyen
<khangng@...amperecomputing.com>
Cc: Matt Johnston <matt@...econstruct.com.au>, Andrew Lunn
<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
Horman <horms@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
ampere-linux-kernel@...ts.amperecomputing.com, Phong Vo
<phong@...amperecomputing.com>, Thang Nguyen
<thang@...amperecomputing.com>, Khanh Pham <khpham@...erecomputing.com>,
Phong Vo <pvo@...erecomputing.com>, Quan Nguyen
<quan@...amperecomputing.com>, Chanh Nguyen <chanh@...amperecomputing.com>,
Thu Nguyen <thu@...amperecomputing.com>, Hieu Le
<hieul@...erecomputing.com>, openbmc@...ts.ozlabs.org,
patches@...erecomputing.com
Subject: Re: [PATCH net-next] net: mctp: Expose transport binding identifier
via IFLA attribute
Hi Jakub,
> > However, we currently have no means to get this information from
> > MCTP links.
>
> I'm not opposed to the netlink attribute, but to be clear this info
> is indirectly available in sysfs, right? We link the netdev to
> the parent device so the type of /sys/class/net/$your_ifc/device
> should reveal what the transport is?
It's likely derivable from the parent device, but requires some
heuristics in userspace to map this to a transport type.
Having a well-defined place to provide the DMTF-specified transport
identifier makes this a little more straightforward to determine which
spec we're dealing with, for any transport-specific behaviour. For
example, some bus types require endpoints to announce their presence,
others do not.
Cheers,
Jeremy
Powered by blists - more mailing lists