One more driver (my Apple SPI-HID driver) will need a crc16 implementation.
Rather than continue the spread of duplicate crc16() functions, let's extract this one into a common header?
I think it will be better to commit another crc16 implementation and then apply 'code duplication fix' by moving function used in both places to independent header. The reason is, that I cannot confirm that it is 'generic' and 'right' crc16 implementation. I can only confirm, that this implementation is suitable for ext2fs.
The polynomial 0x8005 is CRC-16-IBM or CRC-16-ANSI.
Linux has a separate header for crc-16-ansi: https://elixir.bootlin.com/linux/latest/source/include/linux/crc16.h
It's used for ext4: https://elixir.bootlin.com/linux/latest/source/fs/ext4/super.c#L2825
I see no reason not to put this implementation in a separate header file.
It is easy. See e.g. lib/libufs/Makefile which imports crc32 from libkern.
From the other side there are no crc16 users in default kernel, so it will be unused most of time.
One small thing that can be done here is moving crc16_table out of crc16() and making latter inlined.
I'm still not exactly sure why sometimes arc can apply with metadata and sometimes it can't…
afaik Phabricator can (usually) handle git metadata on supplied patches but does not store it and doesn't have a way to return it again when downloading a patch
Yes. It was also created with -U9999999 or whatever to get the entire files... That's great for reviews, terrible for applying the patch in general because patch is unhappy with mismatches in different ways...
Both the bugzilla work flow and doing it this way require special, weird names / URLS to be fetched to the raw file that can be fed into git am. bz at least has a helper tool to download and apply.