Re: git: 548ada00e54a - main - LinuxKPI: add bcd.h
Date: Mon, 25 Oct 2021 21:26:51 UTC
On Mon, 2021-10-25 at 21:17 +0000, Bjoern A. Zeeb wrote: > On Mon, 25 Oct 2021, Ian Lepore wrote: > > > On Mon, 2021-10-25 at 20:23 +0000, Bjoern A. Zeeb wrote: > > > The branch main has been updated by bz: > > > > > > URL: > > > https://cgit.FreeBSD.org/src/commit/?id=548ada00e54a9e7745d041b1ec7f68f3bd493365 > > > > > > commit 548ada00e54a9e7745d041b1ec7f68f3bd493365 > > > Author: Bjoern A. Zeeb <bz@FreeBSD.org> > > > AuthorDate: 2021-10-25 18:14:08 +0000 > > > Commit: Bjoern A. Zeeb <bz@FreeBSD.org> > > > CommitDate: 2021-10-25 20:20:53 +0000 > > > > > > LinuxKPI: add bcd.h > > > > > > Add bcd2bin() as linuxkpi_bcd2bin(). Libkern does provide a > > > bcd2bin() > > > > > > [...] > > > + * We could use libkern, but we need the argument truncating. > > > + * > > > > > > What does that mean, "we need the argument truncating"? > > This one takes an uint8_t as argument. > > If my memory serves me correctly the Linux driver code through > macros passes in larger values 0xabcdxx which are truncated by > the argument type. > > We take an int and then have a KASSERT() which doesn't work so well > for these larger values. > > /bz > > -- > Bjoern A. Zeeb > r15:7 I had forgotten that we added a KASSERT a few years ago. But we don't expect linux to be relying on getting bad answers in response to bad inputs, do we? I wonder why we can't just change the prototype of our inline function from int to uint8_t and remove the >= 0 part from the assert? -- Ian