On Fri, 11 Feb 2022 10:01:42 +0100 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> Max
