netdev - Re: [PATCH v2 2/2] drivers: net: phy: mdio-mux: Add support for Generic Mux controls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 25 Feb 2019 14:56:23 +0000
From:   Peter Rosin <peda@...ntia.se>
To:     Andrew Lunn <andrew@...n.ch>, Pankaj Bansal <pankaj.bansal@....com>
CC:     Leo Li <leoyang.li@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] drivers: net: phy: mdio-mux: Add support for
 Generic Mux controls

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