i2c-hid: the touchpad crash was a printf format, not the driver

The PSOGM on the ASUS TUF A15 was a page fault in cprintf, from probe(),
in the touchpad driver's own success message. cprintf had no field widths:
"%04x" printed literally and consumed no argument, so the "%s" after it
was handed the product ID as a string pointer. "%lx" misprinted the same
way -- "0x4275838976x" for 0xFEDC2000 -- on the line before.

The driver's formats are fixed, and cprintf now steps over flags and
widths and takes l/ll/z as 64-bit, so a directive it does not render can
no longer shift every argument after it. Until now any %ld or %lu printed
the number followed by a stray letter.

The touchpad on/off entry in the boot menu has served its purpose and is
gone; the verbose step trace stays.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

kernel/drivers/bus/xhci/xhci.c

@@ -1059,10 +1059,9 @@ attach_device(struct xhci *x, const struct usb_dev *proto, int parent,
     goto fail;
   }
 
-  // cprintf understands %d %u %l %x %p %b %s and nothing else -- no field
-  // widths. "%04x" is not a directive to it: it prints '%' and '0' literally,
-  // consumes no argument, and every argument after it lands in the wrong
-  // place. That is what turned this line into rubbish, not the enumeration.
+  // cprintf does not pad: "%04x" prints like "%x". It used to be worse -- an
+  // unknown directive consumed no argument and every one after it landed in
+  // the wrong place, which is what once turned this line into rubbish.
   cprintf("usb: port %d%s slot %d %x:%x %s, %s speed, %d configuration%s\n",
           proto->port, proto->route ? " (via hub)" : "", slot,
           desc->idVendor, desc->idProduct,