As a practical matter, if you use a PD controller, it will implement BC 1.2 spec and the 5V 3A may be available if the host provides it. Many or even most hosts support battery charging and data, so the 100mA limitation is a legacy thing only. If you want to interoperate with legacy cables and need a couple of watts of power in all situations, a PD controller is a must whether you buy it or make your own - not for USB-C BMC signaling, but for dealing with layers of legacy crud on D+/D-
Not using a PD controller has you implement all the spec and the oddball corners of it manually, and it’s hard work. Especially considering BC and potential proprietary “extensions” that PD controllers can support (like the “Apple” resistor scheme, 5V QuickCharge, Samsung, etc.) Been there, done it, in the end it was only worth it because the PD controller availability was iffy or nil for what we needed. “Plugfest”-style testing was a pain but very revealing.
You have a simple application it seems and any PD 3 controller will tell you how much power is available so you don’t need to learn the full spec that way. Not using a PD controller essentially means you will have to pass certification tests (whether formal or informal) just to be sure you didn’t mess up in your own implementation.
This way I can power it and configure it.
No USB device can just power up chugging 5W. It doesn’t matter what connector it uses. Enumeration and configuration must be possible down to 5V 100mA even if your device has a USB-C connector - precisely for full legacy compatibility. If you can’t do it, you won’t pass compliance tests IIRC. The device doesn’t have to be fully functional at such power levels of course. But it must accept that not enough power is provided and stay safe.
What exactly is the maximum power my sink will be able to draw here and why?
If you plug it into a legacy USB 2 hub that doesn’t support BC nor proprietary charging extensions, you get 100mA at 5V until enumerated.
If you plug into any modern USB 2 type A port, you’ll have at least some BC power levels available, potentially Apple proprietary power levels if it’s a hub made to play ball in the Apple ecosystem, Samsung proprietary is possible too, etc. A competent PD controller will handle all that.
Rd is chosen to request USB Default power. Could it be chosen to request 5 V @ 1.5 or even 3 A, like in Table 4-38 with a USB3 Type-A on Source side?
You can request what you want but you may not get it. There is no mechanism in a dumb Type-A to Type-C cable to make much use of the CC channel. All you basically get on the USB-C side is an indication that the cable is there - the cable side CC termination - and VBUS goes up immediately. That indicates that no CC signaling is possible and there’s nothing listening to your requests or denying them. Whatever you connect to the CC line on such a cable is immaterial. You can leave it open and it’ll work (but of course not be in spec!).
Re 3: In practice if your device is not a USB 3 device then anything USB-3 is irrelevant. And even if it was, it must operate to the lowest denominator of USB-2 legacy with no BC, think a USB 1.1 host pretty much. Sensible power levels from Type A to Type C over passive cables are a matter of battery charging protocols that work over D+/D- lines for modern hosts, and USB 2 configuration if no BC or proprietary charging is detected. None of that other stuff you worry about matters much. If BC or proprietary charging is available then USB 2 enumeration and configuration doesn’t figure in power levels. It only really is a thing if no other way of establishing the host’s power supply capacity is possible.
Re 4: If a port is a sink only, then that’s what it is. To power anything at all you will need a source port. It doesn’t need a full featured PD controller for that. Role swap is not necessary since that’s only when a port has to reverse power flow. When you have a flash drive, it is always a sink, so no role swapping involved. But USB-C flash drives can be either vconn powered or vbus powered IIRC, so having a minimal controller is in practice the simplest way to do it. Vconn has to be protected from reverse current flow and overcurrent. With a competent PD chip it comes built-in.
If your own device is Vconn-powered, it still can be a source for low power sinks. Those are orthogonal concerns. If the USB2 flash drive has a configuration that fits within vconn power budget available to you, you can power it even though you only got vconn coming in.
Finally, the CC channel signaling is only a tiny part of a PD controller. You still need power path protection to be in spec. Basically, and USB-C device should survive a hard always on 20V on VBUS or you’re not compliant IIRC. There needs to be overcurrent protection and reverse current protection on both VBUS and Vconn. There must be proper discharging to VSafe5 or Vsafe0 as prescribed. And that’s just the start. So, in practice, a PD controller is useful also because it has a protected, compliant power path, and because it can advertise and accept battery charging “negotiated” over D+/D-, even if the CC signaling is not a big deal to “homebrew”.
That’s also why there are rather few “CC PHY” solutions out there and most are not recommended for new designs or are obsolete. The signaling part of PD is not too hard, there’s at least two major open source firmware libraries implementing the policy magic (from ST and Google), but everything else will consume BOM allowance rather quickly if you’re not seasoned in power path design.
TL;DR Connecting to Type A ports is a worst case of 100mA on unpowered hubs and 500mA on powered hubs and legacy hosts, iff USB 2 configuration is successful. USB 2 sleep handling is also required for devices with a USB 2 data path (so anything with USB-C connector with data). You must accept it and deal with it. If your device is non-functional without say 5W of power, then it won’t work with some Type A ports and there’s nothing anyone can do about it. USB-C doesn’t even figure in any of it - you’d have the same problem had you used a Type-A to Type-B cable.
TL;TL;DR: A full featured PD 3 controller will let you get most power anyone else could get from a given connection without you worrying how it happens for the most part. QuickCharge 3 is not always supported but if the firmware is editable then you can add that in with existing analog circuits the PD already has.
