Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 10 Sep 2020 10:08:50 +0200
From:   Johan Hovold <johan@kernel.org>
To:     Lars Melin <larsm17@gmail.com>
Cc:     Oliver Neukum <oneukum@suse.de>,
        James Hilliard <james.hilliard1@gmail.com>,
        linux-usb@vger.kernel.org, Johan Hovold <johan@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, Russ Dill <Russ.Dill@gmail.com>,
        Hector Martin <hector@marcansoft.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
Message-ID: <20200910080850.GD24441@localhost>
References: <20200909193419.2006744-1-james.hilliard1@gmail.com>
 <1599706954.10822.3.camel@suse.de>
 <a1161f77-5b37-39ea-eb91-7b0b59278960@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a1161f77-5b37-39ea-eb91-7b0b59278960@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Sep 10, 2020 at 12:33:55PM +0700, Lars Melin wrote:
> On 9/10/2020 10:02, Oliver Neukum wrote:
> > Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> This patch detects and reverses the effects of the malicious FTDI
> >> Windows driver version 2.12.00(FTDIgate).
> > 
> > Hi,
> > 
> > this raises questions.
> > Should we do this unconditionally without asking?
> > Does this belong into kernel space?
> > 
> 
> My answer to both of those question is a strong NO.
> 
> The patch author tries to justify the patch with egoistical arguments 
> (easier for him and his customers) without thinking of all other users 
> of memory constrained embedded hardware that doesn't need the patch code 
> but have to carry it.
> 
> The bricked PID is btw already supported by the linux ftdi driver so 
> there is no functionality gain in the patch.

I fully agree. This doesn't belong in the kernel. If the Windows driver
breaks someones device on purpose they should know about it, and *if*
they want they can reprogram the device using the tools mentioned in the
thread. But the kernel shouldn't be playing such games and reprogram
eeproms behind people's backs.

Johan