• Let me confirm:
  • I did simple bug fix to 2.2 first: rG3ecd1a41be7c: build: Check -Wlogical-op flag availability with -Werror.
  • For such a simple fix, the person who commits also apply to master <-- Is this right?
• Learned USB suspend/wakeup.
  • It should be fully-automatic.
  • Nothing needed for scdaemon implementation (provided it doesn't want to know these events).
    • USB suspend is supported by kernel USB driver. If it is supported, when no use of USB device, lsusb -v -d <HUB's PID:VID> can show the status of each port, like:

Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0107 power suspend enable connect

• • In USB suspend, no USB trafic. Device requires less current consumption (< 2.5mA by the spec)
  • Start of traffic (should) wakes up device from USB suspend.
  • Related but different
    • SUSPEND to RAM
      • configured device will fail after wakeup, if an application keeps using same FD. Application needs to close and open again.
      • behavior depends on HUB
        • Some recent root HUB supports power down on port, it seems
• Gnuk support for USB suspend is ready (in master).
  • Chopstx supports sleep mode and lower clock (in master).

• E236 on 11-27: will be absent (out of town to visit Tohoku area).
• X448 for Gnuk at first
  • Field specific routines (mul, add, sqr, weak-reduce, strong-reduce), with 28-bit limb, avoiding carry
• Plan
  • Then, implement in libgcrypt and GnuPG
    • How we introduce representation like 28-bit limb, it might differ (e.g., 56-bit for 64-bit arch) at compile time.
  • For EdDSA on 448 curve on Goldilocks field, we need more new things.

Yes, should be merged. But I think it is okay to merge several such things per day at once. Let's discuss this again.

Do we reuse the fd in scdaemon after a wakeup from suspend to RAM? Or is out error handler good enough to do this?
We should anyway send a HUP to gpg-agent before suspending to flush the caches.