This all depends on complexity of the device, but even in case the device is really simple, you are underestimating the nature of the work needed.
In real life there are things related to device design and it's programming that simply cannot be inferred from it's exposed PCI interfaces, ie device is, for all intents and purposes, a blackbox. More over, things like these take insane amount of resources and time, the effort needed is often very asymetric (ie it take order of millions (hours, money, people) to solve).
Simple case in point is nvidia hardware to which no documentation is available. Read about nouveau driver for nvidia, how it was reverse engineered with help of thousands of people, and still can be considered only barely performing at alpha/beta level, even decades later.
Linux graphics stack is full of stories like that, of passable gfx hardware (especially in mobile) with shitty manufacturer drivers, not able to keep with the pace of kernel development. Manufacturer is blocked by some "business" reasons (silicon design licensing/patents, driver sub-components licensing/patents, plain greed) from releasing driver open and they themselves are unable to fully support it on their own. This hardware, often while present, is as good as useless.
Keep in mind that in mobile chipset market turnover is what, one two years at maximum? In two years company doesn't even care. Majority of the money from chips was already made, and current "consumers" are laggards cheapo chinese producers selling crappy products running outdated software, that is not even relevant.
So true reply is that yes nothing is impossible, the real question is where you are going to find money, talent and most importantly time for this endeavor?
Your best bet is to find a community and talent that already tried tackle the given problem (dealt with similar make of escon device on linux for example) and somehow persuade them to look into your, yet another, case.
Instead of reversing, it might be slightly much more productive to try get hardware register level documentation from manufacturer and find kernel driver developers to develop driver according to that. But please realize: reversing is "just" information gathering, even with full documentation you still have to write the new driver and make it work, and making it performant is at completely another level even.
Often manufacturer has driver for certain specific versions of the OS and you can ask them for it and then have "middle" locked down host running outdated OS interfacing with the product, and have some small adventurously brave and progressive developer house make software "inter-connector" to connect it to world of modern systems over some software API.
I have seen this approach work best.