What is the right way to apply a patch to a dts while building

I am working on bringing up a build for an orangepi one (1GB RAM variant). Everything has gone swimmingly except for my efforts to enable the USB OTG port in host mode. I've gathered from other discussions about this issue that the path of least resistance is to reconfigure usb_otg 'dr_mode = "otg"' to 'dr_mode = "host"'.

I imagine there are multiple ways to attack this issue, but my first instinct was to put a .patch file in projects/Allwinner/devices/H3/patches/linux/ which just modifies that single line in the orangepi zero's dts. So, I created the patch, and ran a clean build. Looking through the logs, I see that the build ran through all the other .patch files in that subdirectory, but didn't even attempt to process my patch. Of course, in the end, the dtb file did not have my intended changes.

My next attempt was to put the exact same .patch file in projects/Allwinner/patches/linux instead. Clean build, and the log showed that the patch was taken and applied. And the dtb was modified as I intended.

Is it reasonable that putting the patch file in one subdirectory is automatically picked up and included in the build, but not in the other subdirectory? Is there anything extra I should expect to have to do, when I create a new patch specifically in projects/Allwinner/devices/H3/patches/linux?

Follow-up: My patch file was incomplete. It only contained the raw content of the git diff:

git diff arch/arm/boot/dts/sun8i-h3-orangepi-one.dts > 0003-ARM-dts-sun8i-orangepi-one-enable-usb0-host.patch

Notably, it did not include any of the additional information present in other patch files already in the DEVICE directory:

From xxx
From: xxx
Date: xxx
Subject: xxx

Description

Signed-off-by: xxx
---
 file-list

So I added a header in that format to the beginning of my patch file.

Interestingly, the absence of that header didn't seem to make any difference when the patch file was in the PROJECT directory, but when it's in the DEVICE directory it seems to be mandatory.

Now that that is behind me, I wonder -- is this the sort of thing that could also be achieved using a dto? Typically, I've seen dto files used only to do something like take a "disabled" object and turn it into an "okay" object. But in this case, I am taking an already "okay" object and changing one of its properties ('dr_mode = "otg"' to 'dr_mode = "host"').