linux-kernel - Re: [RFC PATCH net-next 2/2] net: dsa: mt7530: introduce MMIO driver for MT7988 SoC

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Mar 2023 16:00:30 +0100
From:   Daniel Golle <daniel@...rotopia.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sam Shih <Sam.Shih@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        John Crispin <john@...ozen.org>, Felix Fietkau <nbd@....name>
Subject: Re: [RFC PATCH net-next 2/2] net: dsa: mt7530: introduce MMIO driver
 for MT7988 SoC

On Tue, Mar 28, 2023 at 05:16:28PM +0300, Vladimir Oltean wrote:
> On Tue, Mar 28, 2023 at 02:08:18PM +0100, Daniel Golle wrote:
> > I agree that using regmap would be better and I have evaluated that
> > approach as well. As regmap doesn't allow lock-skipping and mt7530.c is
> > much more complex than xrs700x in the way indirect access to its MDIO bus
> > and interrupts work, using regmap accessors for everything would not be
> > trivial.
> > 
> > So here we can of course use regmap_read_poll_timeout and a bunch of
> > readmap_write operations. However, each of them will individually acquire
> > and release the mdio bus mutex while the current code acquires the lock
> > at the top of the function and then uses unlocked operations.
> > regmap currently doesn't offer any way to skip the locking and/or perform
> > locking manually. regmap_read, regmap_write, regmap_update_bits, ... always
> > acquire and release the lock on each operation.
> 
> What does struct regmap_config :: disable_locking do?

I thought I can't use that on a per-operation base because the
instance of struct regmap_config itself isn't protected by any lock
and hence setting disable_locking=false before calling one of the
accessor functions may affect also other congruent calls to the
accessors which will then ignore locking and screw things up.
Please correct me if I'm wrong there.

Yet another way I thought about now could also be to have two regmap
instances, one for locked and one for unlocked accessed to the same
regmap_bus.