1. Please describe the problem:

The booting process of Fedora on Hyperbook NH5/Clevo NH55RCQ (with GeForce GTX 1660 Ti) hangs on:
> Wait for Complete Device Initialization
for 60s+.

After intensive research I have found a culprit and blacklisting i2c_nvidia_hpu helps. However, (if possible) it could be fixed upstream or at least applied automatically in corresponding cases.

2. What is the Version-Release number of the kernel:
kernel-core-5.2.0-0.rc4.git0.1.fc30.x86_64 (rebuilt from SRPM due to https://bugs.freedesktop.org/show_bug.cgi?id=110830)
kernel-core-5.1.5-300.fc30.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Not with the original kernel in Fedora 30 - it was also affected. I haven't tested with the previous Fedora versions.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Try to boot Fedora.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Yes, with:
kernel-core-5.2.0-0.rc4.git0.1.fc30.x86_64

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

As it took me ahile, I post here a way how I found a reason to (potentially) help others struggling with similar issues.

> Jun 14 11:14:06 foobar systemd[1]: Starting udev Wait for Complete Device Initialization...
> ...
> Jun 14 11:14:12 foobar systemd[1]: systemd-rfkill.service: Succeeded.
> Jun 14 11:14:12 foobar audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? >
> Jun 14 11:14:12 foobar kernel: kauditd_printk_skb: 42 callbacks suppressed
> Jun 14 11:14:12 foobar kernel: audit: type=1131 audit(1560503652.402:64): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" h>
> Jun 14 11:15:07 foobar systemd-udevd[1095]: 24-0008: Worker [1171] processing SEQNUM=3730 is taking a long time
> Jun 14 11:15:40 foobar systemd[1]: Started udev Wait for Complete Device Initialization.


"systemd-analyze blame" confirmed "systemd-udev-settle.service" as the main delay point.

I turned on debug logs in udev by adding udev_log="debug" in /etc/udev/udev.conf. With that I've got:

> $ journalctl -b -2 | grep 24-0008
> Jun 14 12:44:48 foobar systemd-udevd[1089]: 24-0008: Device (SEQNUM=3683, ACTION=add) is queued
> Jun 14 12:44:48 foobar systemd-udevd[1089]: 24-0008: sd-device-monitor: Passed 195 byte to netlink monitor
> Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: Processing device (SEQNUM=3683, ACTION=add)
> Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:14
> Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: No entry found from hwdb.
> Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: IMPORT builtin 'hwdb' fails: No data available
> Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5
> Jun 14 12:45:48 foobar systemd-udevd[1089]: 24-0008: Worker [1098] processing SEQNUM=3683 is taking a long time
> Jun 14 12:46:21 foobar systemd-udevd[1089]: 24-0008: Device (SEQNUM=3959, ACTION=bind) is queued
> Jun 14 12:46:21 foobar systemd-udevd[1098]: 24-0008: Device (SEQNUM=3683, ACTION=add) processed
> Jun 14 12:46:21 foobar systemd-udevd[1098]: 24-0008: sd-device-monitor: Passed 195 byte to netlink monitor
> Jun 14 12:46:21 foobar systemd-udevd[1089]: 24-0008: sd-device-monitor: Passed 213 byte to netlink monitor
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: Processing device (SEQNUM=3959, ACTION=bind)
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:14
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: No entry found from hwdb.
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: IMPORT builtin 'hwdb' fails: No data available
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: Device (SEQNUM=3959, ACTION=bind) processed
> Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: sd-device-monitor: Passed 213 byte to netlink monitor
> Jun 14 12:47:16 foobar kernel: ucsi_ccg 24-0008: failed to reset PPM!
> Jun 14 12:47:16 foobar kernel: ucsi_ccg 24-0008: PPM init failed (-110)

And:

> $ udevadm info /sys/bus/i2c/devices/24-0008
> Successfully loaded SELinux database in 1.002ms, size on heap is 328K.
> P: /devices/pci0000:00/0000:00:01.0/0000:01:00.3/i2c-24/24-0008
> L: 0
> E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.3/i2c-24/24-0008
> E: DRIVER=ucsi_ccg
> E: MODALIAS=i2c:ccgx-ucsi
> E: SUBSYSTEM=i2c

which suggests NVidia. Having more keywords I was albe to find this thread related to similar Clevo-based laptop:
https://github.com/pop-os/pop/issues/520#issuecomment-486338074

Blacklisting i2c_nvidia_gpu in fact removed the delay.