Having sent the kernel maintainers a patch adding support for hardware they don't have (in my case, it was a network card): they merge the code after just reading over the code and checking it compiles. Keep in mind, however, that they usually have decades of experience in their particular area of the kernel, so they often can tell at a glance when you're doing something wrong or unusual.
In practice, such code dumps usually get rejected out of hand because most unknown first-time contributors are unable to produce a fully functional driver without violating the coding practices of that subsystem and re-inventing the wheel in some fashion. The maintainers always prefer companies to do their driver development in a more open fashion so that there can be two-way feedback throughout the process to ensure the end result is something worthy of merging. Developers who play by the rules and ensure that their driver both fits into existing infrastructure and doesn't break anything else are usually developers who can be trusted to deliver code that works on the new hardware that's not yet public.
Does the maintainer merge the code after just reading over the code and checking it compiles, never having executed it?
My assumption has always been there's little testing in such a situation - but I can't square that with the fact the kernel seems to work so well :)