Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220226204507.2511633-1-michael@walle.cc>
In-Reply-To: <20220226204507.2511633-1-michael@walle.cc>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 15 Mar 2022 01:57:16 +0100
Message-ID: <CACRpkdaDxYntOxnJiX-fwUU8UPFu7SFR_5UnoUPzhWG-xtJphQ@mail.gmail.com>
Subject: Re: [PATCH v2 0/5] pinctrl: microchip-sgpio: locking and synchronous output
To:     Michael Walle <michael@walle.cc>
Cc:     Lars Povlsen <lars.povlsen@microchip.com>,
        Steen Hegelund <Steen.Hegelund@microchip.com>,
        UNGLinuxDriver@microchip.com, linux-arm-kernel@lists.infradead.org,
        linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        Colin Foster <colin.foster@in-advantage.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Feb 26, 2022 at 9:45 PM Michael Walle <michael@walle.cc> wrote:

> There are boards which use the output of the SGPIO to drive I2C muxers.
> SGPIO right now is broken in a way that when the software sets this bit
> there is a rather large delay until that value ends up on the hardware
> pin.
>
> While digging into this, I've noticed that there is no locking at all
> in this driver. Add locking for all RWM accesses.
>
> Please note, that parts of the modification of the first patch are
> removed again in a later patch. This is because the first patch is
> intended to be backported to the stable trees.
>
> This was also just tested on a LAN9668 SoC. If you have additional
> hardware, please test.

Nobody is protesting for three weeks or so, I just applied the patches
for v5.18.

If there are problems we can fix them in the v5.18-rc:s

Yours,
Linus Walleij