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: <adaws70lttc.fsf@cisco.com>
Date:	Wed, 24 Jun 2009 23:18:55 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Yevgeny Petrilin <yevgenyp@...lanox.co.il>
Cc:	general@...ts.openfabrics.org, netdev@...r.kernel.org
Subject: Re: [ofa-general][PATCH 2/2] mlx4: ConnectX multi functional device support


 > MT26468 (0x6764) device can open multiple physical functions.
 > The current driver can only work with one (primary) pf.
 > For all other functions, QUERY_FW command would fail with
 > CMD_STAT_MULTI_FUNC_REQ error code. We should not work on those
 > devices, but they should remain in the driver's ownership.

Seems this patch should really be 1/2, since we want the driver to be
able to handle multi-func devices before we add the PCI ID for such
devices.  Also, it didn't occur to me before, but why does the driver
need to keep ownership of the non-primary functions?  It seems we could
avoid having the NOT_PRIME flag and all of that if we just gave up on a
device when QUERY_FW told us it wasn't the primary function.

Also from my naive point of view at least, it seems your hardware
interface could be simpler for software to handle if you just used a
different PCI ID for the non-primary physical function.  Not sure if
it's too late to change that (and maybe there's a reason I'm missing to
use the same PCI ID for functions that behave differently and require
different driver behavior to handle them??).

 - R.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ