The meaning of any one Device I/O Control code is subject to some convention. Microsoft defines the code in bit fields, the most notable of which is the high word as a device type. Microsoft defines many I/O control codes for many types of device. If a driver is executing to handle that type of device, it should expect to receive those corresponding I/O control codes and to interpret them as Microsoft defines. These I/O control codes are in this sense well-defined such that if you or a diagnostics tool see one, identifying it by a known symbolic value is sound.
However, drivers can create device objects that have nothing to do with hardware. Such devices won't be the target for any device I/O control to help with managing any type of device that the system knows or cares about, and so the driver can make up whatever I/O control codes it wants. This is a long established mechanism by which drivers communicate with a co-operating application.
Conventionally, I/O control codes that are invented for this purpose tend to have 0x0022, i.e., FILE_DEVICE_UNKNOWN, as the device type. The practical consequence for you in your reverse engineering is that the same device I/O control code that has 0x0022 as the high word can mean completely unrelated things to different devices, even if implemented in the same driver.
Now, Microsoft does muddy the water a little by using FILE_DEVICE_UNKNOWN for I/O control codes that can be sent to drivers for physical devices. But unless you or your diagnostics tool know that you're looking at a driver that's in place to receive those I/O control codes, any symbol that the tool resolves a 0x0022XXXX number to is very likely a fantasy that you do better to ignore.