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]
Message-ID: <20200306102009.0817bb06@kicinski-fedora-PC1C0HJN>
Date:   Fri, 6 Mar 2020 10:20:09 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004

On Thu, 5 Mar 2020 23:43:44 -0800 Shannon Nelson wrote:
> Yes, and if we were just writing registers, that would make sense. When 
> I can get to it I do intend to try expand our use of the devlink 
> interfaces where it will work for us.

Yes, please do that.

> However, this device id does exist on some of the DSC configurations, 
> and I'd prefer to explicitly acknowledge its existence in the driver and 
> perhaps keep better control over it, whether or not it gets used by our 
> 3rd party tool, rather than leave it as some obscure port for someone to 
> "discover".

I understand, but disagree. Your driver can certainly bind to that
management device but it has to be for the internal use of the kernel.
You shouldn't just expose that FW interface right out to user space as 
a netdev.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ