2017-04-01 18:20 keltezéssel, Boszormenyi Zoltan írta:
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,
(unfinished sentence) then the failure is during driver initialization,
not during runtime, possibly days or weeks later.
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
