linux-kernel - Re: [PATCH v3 63/65] ASoC: tlv320aic32x4: pll: Switch to determine

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]

Message-ID: <6b83dd87-3819-4db4-bd07-92487a1df09d@sirena.org.uk>
Date:   Wed, 5 Apr 2023 16:09:49 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Max Filippov <jcmvbkbc@...il.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Luca Ceresoli <luca.ceresoli@...tlin.com>,
        David Lechner <david@...hnology.com>,
        Sekhar Nori <nsekhar@...com>, Abel Vesa <abelvesa@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Prashant Gaikwad <pgaikwad@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>, Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-actions@...ts.infradead.org, patches@...nsource.cirrus.com,
        linux-stm32@...md-mailman.stormreply.com,
        linux-mediatek@...ts.infradead.org,
        linux-renesas-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-phy@...ts.infradead.org,
        linux-rtc@...r.kernel.org, linux-sunxi@...ts.linux.dev,
        alsa-devel@...a-project.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH v3 63/65] ASoC: tlv320aic32x4: pll: Switch to
 determine_rate

On Tue, Apr 04, 2023 at 12:11:53PM +0200, Maxime Ripard wrote:

> The driver does implement round_rate() though, which means that we can
> change the rate of the clock, but we will never get to change the
> parent.

> However, It's hard to tell whether it's been done on purpose or not.

> Since we'll start mandating a determine_rate() implementation, let's
> convert the round_rate() implementation to a determine_rate(), which
> will also make the current behavior explicit. And if it was an
> oversight, the clock behaviour can be adjusted later on.

Similar comments to the other patch, I'm pretty sure this is just
surprising design on the part of the clock API and we should just allow
reparenting.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)