From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90DE5C433F5 for ; Fri, 11 Feb 2022 14:23:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242290AbiBKOXZ (ORCPT ); Fri, 11 Feb 2022 09:23:25 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:58480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236314AbiBKOXY (ORCPT ); Fri, 11 Feb 2022 09:23:24 -0500 Received: from mail.enpas.org (zhong.enpas.org [46.38.239.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3E7A2188 for ; Fri, 11 Feb 2022 06:23:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.enpas.org (Postfix) with ESMTPSA id 562DCFF837; Fri, 11 Feb 2022 14:23:22 +0000 (UTC) Date: Fri, 11 Feb 2022 15:23:19 +0100 From: Max Staudt To: Greg Kroah-Hartman Cc: linux-can@vger.kernel.org, Marc Kleine-Budde , Wolfgang Grandegger , Oliver Neukum , Jiri Slaby Subject: Re: [PATCH v2] can, tty: elmcan CAN/ldisc driver for ELM327 based OBD-II adapters Message-ID: <20220211152319.7745598b.max@enpas.org> In-Reply-To: References: <20220210171315.87796-1-max@enpas.org> <20220210212047.589c2f3d.max@enpas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On Fri, 11 Feb 2022 10:01:42 +0100 Greg Kroah-Hartman wrote: > On Thu, Feb 10, 2022 at 09:20:47PM +0100, Max Staudt wrote: > > I'll hardcode the driver to be more lenient - i.e. > > accept_flaky_uart=1. Whoever relies on it for critical systems > > likely hasn't read the disclaimer anyway :) > > > > > > How about inverting the option, thus having a debug_extra_strict > > module option for debugging purposes, so users can more easily see > > if their adapter is at fault? > > Will anyone really do that? And if so, what can they do about it? > The kernel's job is to work around broken hardware, so we might as > well just deal with it :( True, let's hardcode a behaviour. I've thought about it a bit more and flipped the switch though :) The rationale is as follows: 1) In my latest tests, my hardware behaved just fine, so I likely had an EMI problem in my setup when I wrote that option years ago. 2) The errors I was working around were random insertions and bitflips. Which can lead to incorrect rather than dropped data. The driver can report obvious errors, but there is no way to detect a bitflip in those places where it really hurts (i.e. the data packets). If the driver has reason to believe there is a problem, I'd rather it avoid forwarding possibly incorrect data to the user. 3) If the driver's users DO wish for a change, it's always easier to make the driver more lenient rather than more strict. The only thing it can do then is to restart the device anyway... So, I'll kick the option out and keep the driver strict. > > Maybe > > #define N_DEVELOPMENT 29 > > or something like that? > > > > And then from this point onwards, NR_LDISCS needs only be > > incremented once a new ldisc is actually upstreamed. > > That would work, want to send a patch right now for that? Just did: Message-Id: <20220211141036.6403-1-max@enpas.org> Max