From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757223AbcEDHkl (ORCPT ); Wed, 4 May 2016 03:40:41 -0400 Received: from mail-lf0-f41.google.com ([209.85.215.41]:33403 "EHLO mail-lf0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751310AbcEDHkj (ORCPT ); Wed, 4 May 2016 03:40:39 -0400 Date: Wed, 4 May 2016 09:40:38 +0200 From: Johan Hovold To: Mathieu OTHACEHE Cc: Johan Hovold , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: serial: ti_usb_3410_5052: add MOXA UPORT 11x0 support Message-ID: <20160504074038.GC1367@localhost> References: <20160502180407.GA4330@gmail.com> <20160502183715.GA4453@gmail.com> <20160503081422.GC25025@localhost> <87vb2vnz2s.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vb2vnz2s.fsf@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 03, 2016 at 01:46:51PM +0200, Mathieu OTHACEHE wrote: > > No, I was trying to say that the we should not attempt to load a > > firmware on the "ti_usb-v%04x-p%04x.fw" format before loading the moxa > > firmware. > > For MTS devices (mts_*.fw) and for devices using generic firmware (ti_3410.fw > and ti_5052.fw), ti_usb-v%04x-p%04x.fw loading is already failing. > > So, I can patch the driver to request firmwares in this order : > > 1. VID dependant (MTS and MOXA now) > 2. ti_usb-v%04x-p%04x.fw format > 3. Generic firmware > > But, for generic firmware users, ti_usb-v%04x-p%04x.fw loading will > still always fail ... > > Or we can get rid of ti_usb-v%04x-p%04x.fw loading because no one has > defined a firmware with this format in linux-firmware repository ? Let's try to be conservative and not necessarily change the current behaviour right away. Just make sure the Moxa firmware is loaded directly, without fallback, and we can see about possibly cleaning up the legacy behaviour later (in incremental patches that can easily be reverted if anyone complains). Thanks, Johan