From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754128AbdF0Xv3 convert rfc822-to-8bit (ORCPT ); Tue, 27 Jun 2017 19:51:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:55542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753982AbdF0XvW (ORCPT ); Tue, 27 Jun 2017 19:51:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B948B214E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mcgrof@kernel.org MIME-Version: 1.0 In-Reply-To: <20170627153950.0911cc2a@cakuba.netronome.com> References: <20170623233702.20564-1-jakub.kicinski@netronome.com> <20170626212036.GE21846@wotan.suse.de> <20170626191009.0c11eed0@cakuba.netronome.com> <20170627163942.GQ21846@wotan.suse.de> <20170627142553.0fe417b3@cakuba.netronome.com> <20170627222419.GY21846@wotan.suse.de> <20170627153950.0911cc2a@cakuba.netronome.com> From: "Luis R. Rodriguez" Date: Tue, 27 Jun 2017 16:50:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] firmware: wake all waiters To: Jakub Kicinski Cc: Bjorn Andersson , Arend Van Spriel , Tom Gundersen , Daniel Wagner , Ming Lei , "Li, Yi" , "AKASHI, Takahiro" , Nicolas Broeking , Greg Kroah-Hartman , Martin Fuzzey , "Eric W. Biederman" , Dmitry Torokhov , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, "Rafael J. Wysocki" , atull@kernel.org, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , Luciano Coelho , Andy Lutomirski , Linus Torvalds , Kees Cook , David Howells , Peter Jones , Hans de Goede , Alan Cox , Tso Ted , Paul Gortmaker , mtosatti@redhat.com, Matthew Wilcox , Stephen Boyd , Vikram Mulukutla , "linux-kernel@vger.kernel.org" , oss-drivers@netronome.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 3:39 PM, Jakub Kicinski wrote: > 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.) I see only 1 request_firmware() request on your driver and its not optional? What I was suggesting was have 3 separate requests. Two optional files which you hunt for first, and if either of them are present you use them. If both are missing you go with the default. > 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... Yeah, that could work -- ie, for each of the 3 mode firmware you actually *first* look for the pci_name() derivative first, if any of them is found use that. Otherwise you then move on to the non pci_name() varaints with the same logic. The last one would be the default Fisher-Price® one. Anyway -- I still think *long term* this is best ironed out by identifying the modes and seeing if perhaps networking folks might come to some agreement on these as different modes, then your driver can have respective hooks for the different modes based on some user specified mode flip or requirement. If this is not possible... a sysfs know interface is always possible. Luis