Re: [PATCH] firmware: wake all waiters
From: Jakub Kicinski
Date: Tue Jun 27 2017 - 18:40:02 EST
On Wed, 28 Jun 2017 00:24:19 +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 27, 2017 at 02:25:53PM -0700, Jakub Kicinski wrote:
> > On Tue, 27 Jun 2017 18:39:42 +0200, Luis R. Rodriguez wrote:
> > >
> > > > The problem is that advanced NICs are quite programmable [1] and
> > > > depending on use case one may want to load different firmware files.
> > >
> > > Right, so in the 802.11 world some devices might use different firmware for
> > > different modes of operation, STA, AP, Mesh, but this is all very protocol
> > > specific, so userspace could tickle the kernel about a mode.
> > >
> > > Do your use cases have protocol definitions which can be exposed in userspace?
> > > Or are these just fw variants with different bells and whistles? How man
> > > different use cases are we talking about?
> >
> > Right now we have three modes that come from Netronome itself, a "basic
> > NIC" one, and two advanced for TC flower/Open vSwitch acceleration and
> > for eBPF offload. I was hoping some enumeration scheme could work here,
> > but I really can't come up with one.
>
> How about just supporting 3 firmware names, with the first two being optional,
> but if found one of those two is found it would use that one. Then only if
> both of these are not present would a default be looked for and used?
>
> In terms of interface, a simple symlink / renaming scheme would suffice to
> support this. No custom hooks at all.
That's what we do today as a stop-gap solution :) (BTW mkinitrd
doesn't seem to like symlinks so I use hard links.)
The issue is if you have two identical cards, how to load different FW
on them? We would have to encode the serial number into the firmware
name or the pci_name() at least. The nice thing about this solution is
that it requires almost zero code on the kernel size... hm...