netdev - Re: [ofa-general][PATCH 2/2] mlx4: ConnectX multi functional device support

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, 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