The best clean alternative would be add new resource handling infrastructure.
* Expose the currently static alloc_resource() in kernel/resource.c
With this, driver initialization can allocate the resource once
for the lifetime of the driver and it it fails,
* Add a new insert_muxed_region() / __insert_muxed_region() function with
different semantics from request_muxed_region() / __request_region():
1 Accept a pointer to already allocated resource.
2 If the conflicting resource doesn't have IORESOURCE_MUXED set,
complain loudly in the syslog but still go into the wait queue.
The conflicting resource also has the name which can be printed
so the inconsistent resource / region usage can be fixed.
We can also just modify the __request_region() semantics, so:
1 It accepts a pointer to an allocated resource or NULL.
In the second case, the resource is allocated internally and can
still fail.
2 The above second point. But this may cause an error in code that
expects the old semantics.
The window for request_muxed_region()+release_region() is so short
that the requested I/O port range would not show up in /proc/ioports.
All this would be to fix only 3 drivers in a no-error scenario and only
achieving the functionality of a mutex seems to be overkill.
Another alternative is to revert commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
that caused the regression in sp5100_tco in the first place.
Best regards,
ZoltÃn BÃszÃrmÃnyi