On Mon, 2022-03-21 at 20:46 +0100, Marek Vasut wrote: > On 3/21/22 17:10, Andy Shevchenko wrote: > > On Mon, Mar 21, 2022 at 03:46:51PM +0100, Marek Vasut wrote: > > > On 3/21/22 11:40, Andy Shevchenko wrote: > > > > On Sun, Mar 20, 2022 at 07:15:42PM +0100, Marek Vasut wrote: > > > > > Add runtime check to verify whether storagebits are at least > > > > > as big > > > > > as shifted realbits. This should help spot broken drivers > > > > > which may > > > > > set realbits + shift above storagebits. > > > > > > > > Thanks! > > > > > > > > ... > > > > > > > > > + /* Verify that sample bits fit into > > > > > storage */ > > > > > + WARN_ON(channels[i].scan_type.storage > > > > > bits < > > > > > + channels[i].scan_type.realbit > > > > > s + > > > > > + channels[i].scan_type.shift); > > > > > > > > Not sure WARN is a good level (it might be fatal on some setups > > > > and we won't that), > > > > besides the fact that we may use dev_WARN(). Perhaps dev_warn() > > > > would suffice? > > > > > > I was actually thinking about BUG(), but that might crash > > > existing systems. > > > I think we want a strong indicator that something wrong is going > > > on which > > > must be fixed and the splat produced by WARN_ON() is a good > > > indicator of > > > that. It also does not crash existing systems, > > > > It does crash _some_ of them, unfortunately. > > Details please ? > > WARN_ON() shouldn't cause crash outright, or do I miss something ? Arghh, completely forgot about this... Andy is right, maybe there are other cases (in which case, it would be nice to share :D), but this one is definitely one of them: https://elixir.bootlin.com/linux/latest/source/kernel/panic.c#L579 You can have a cmdline parameter to panic on _WARN() and some systems may have it. That said, the "nice" stack_dump using WARN is way more explicit about saying that something is seriously wrong and must be fixed. dev_warn() is easier to ignore... But surely it is not nice to brick existing systems. Not really sure here... - Nuno Sá
