linux-kernel - Re: [PATCH net-next] net: mctp: Expose transport binding identifier via IFLA attribute

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4c5b08d2-e81e-4492-a1a7-7e1e6445ddc4@amperemail.onmicrosoft.com>
Date: Fri, 8 Nov 2024 12:47:36 +0700
From: Khang D Nguyen <khangng@...eremail.onmicrosoft.com>
To: Jakub Kicinski <kuba@...nel.org>,
 Khang Nguyen <khangng@...amperecomputing.com>
Cc: Jeremy Kerr <jk@...econstruct.com.au>,
 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

On 08/11/2024 11:41, Jakub Kicinski wrote:
> On Tue,  5 Nov 2024 14:19:15 +0700 Khang Nguyen wrote:
>> 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?

Good point, I did not think about using the parent device, that would be 
a good workaround for the currently supported interfaces.

For the long term, we should still need the attribute. For example, 
vendor-defined transports need their 0xFF code, which cannot be derived 
anywhere. Or binding implementations that have parent SoC platform 
devices from the device tree, which do not always have a clear type 
shown in the sysfs...

(The MCTP-over-serial binding also does not have a parent device 
currently, but I believe we can fix that if necessary)