On 2019-02-24 15:57, Andrew Lunn wrote:
>> +static int mdio_mux_multiplexer_remove(struct platform_device *pdev)
>> +{
>> + struct mdio_mux_multiplexer_state *s = platform_get_drvdata(pdev);
>> +
>> + mdio_mux_uninit(s->mux_handle);
>
> I've never used the multiplexer framework before. But i think you need
> a call to mux_control_deselect() here in order to unlock the
> multiplexer. Without that, it will deadlock when you reload the
> module.
That is correct.
Some background; The mux framework was designed for cases where
a) two (or more) mux consumers "compete" for the same mux controller, or
b) where a single mux chip shares several mux controllers where each
controller might be used for some independent purpose.
The design is also built around short accesses, such that no single
mux consumer starves other consumers of a shared mux controller. I.e.
- select the mux and implicitly set it in the desired position
- do something short-ish which requires the mux
- deselect the mux
But it does work for exclusive consumers of a mux controller as in this
series. However, if the consumer
1) requires the implementation of a new mux controller,
2) does not need any of the existing mux drivers and
3) the situation is not in one of the a) and b) categories
then the mux framework is not really providing any killer features. I.e.
it seems like it is certainly an option to just open code the needed
regmap accesses and ignore the multiplexer subsystem in this case.
However, the changes needed in the mux framework are quite minimal in
this case [1], so 1) is arguably not applicable...
More details on the design can be found in the original mux series [2].
Cheers,
Peter
[1] https://lkml.org/lkml/2019/2/24/23
[2] https://lkml.org/lkml/2017/5/14/160
