netdev - Re: [patch net-next RFC 00/10] introduce line card support for modular switch

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 27 Jan 2021 07:57:49 -0700
From:   David Ahern <dsahern@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, jacob.e.keller@...el.com, roopa@...dia.com,
        mlxsw@...dia.com, vadimp@...dia.com
Subject: Re: [patch net-next RFC 00/10] introduce line card support for
 modular switch

On 1/27/21 7:14 AM, Andrew Lunn wrote:
>> I don't think it would apply. The thing is, i2c driver has a channel to
>> the linecard eeprom, from where it can read info about the linecard. The
>> i2c driver also knows when the linecard is plugged in, unlike mlxsw.
>> It acts as a standalone driver. Mlxsw has no way to directly find if the
>> card was plugged in (unpowered) and which type it is.
>>
>> Not sure how to "embed" it. I don't think any existing API could help.
>> Basicall mlxsw would have to register a callback to the i2c driver
>> called every time card is inserted to do auto-provision.
>> Now consider a case when there are multiple instances of the ASIC on the
>> system. How to assemble a relationship between mlxsw instance and i2c
>> driver instance?
> 
> You have that knowledge already, otherwise you cannot solve this
> problem at all. The switch is an PCIe device right? So when the bus is
> enumerated, the driver loads. How do you bind the i2c driver to the
> i2c bus? You cannot enumerate i2c, so you must have some hard coded
> knowledge somewhere? You just need to get that knowledge into the
> mlxsw driver so it can bind its internal i2c client driver to the i2c
> bus. That way you avoid user space, i guess maybe udev rules, or some
> daemon monitoring propriety /sys files?
> 
>> But again, auto-provision is only one usecase. Manual provisioning is
>> needed anyway. And that is exactly what my patchset is aiming to
>> introduce. Auto-provision can be added when/if needed later on.
> 
> I still don't actually get this use case. Why would i want to manually
> provision?
> 


+1.