| 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
| ||
|
Message-Id: <20220718191454.5B5D3C341C0@smtp.kernel.org>
Date: Mon, 18 Jul 2022 12:14:52 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Tomer Maimon <tmaimon77@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Avi Fishman <avifishman70@...il.com>,
Benjamin Fair <benjaminfair@...gle.com>,
Biju Das <biju.das.jz@...renesas.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Greg KH <gregkh@...uxfoundation.org>,
Jonathan Neuschäfer <j.neuschaefer@....net>,
Jiri Slaby <jirislaby@...nel.org>,
Joel Stanley <joel@....id.au>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Guenter Roeck <linux@...ck-us.net>,
Lubomir Rintel <lkundrak@...sk>,
Marcel Ziswiler <marcel.ziswiler@...adex.com>,
Michael Turquette <mturquette@...libre.com>,
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
Olof Johansson <olof@...om.net>,
Philipp Zabel <p.zabel@...gutronix.de>,
Robert Hancock <robert.hancock@...ian.com>,
Rob Herring <robh+dt@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Tali Perry <tali.perry1@...il.com>,
Thomas G leixner <tglx@...utronix.de>,
Patrick Venture <venture@...gle.com>,
Vinod Koul <vkoul@...nel.org>, Will Deacon <will@...nel.org>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Nancy Yuen <yuenn@...gle.com>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-clk <linux-clk@...r.kernel.org>, open list:
SERIAL DRIVERS <linux-serial@...r.kernel.org>,
LINUXWATCHDOG <linux-watchdog@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>, ;
Subject: Re: [PATCH v8 04/16] clk: npcm8xx: add clock controller
Quoting Tomer Maimon (2022-07-12 00:28:30)
> On Mon, 11 Jul 2022 at 22:55, Stephen Boyd <sboyd@...nel.org> wrote:
> >
> > Quoting Tomer Maimon (2022-07-11 05:35:07)
> > > + */
> > > + int onecell_idx;
> > > +};
> > > +
> > > +struct npcm8xx_clk_pll_data {
> > > + u32 reg;
> > > + const char *name;
> > > + const char *parent_name;
> >
> > Any reason why we're not using clk_parent_data or direct clk_hw
> > pointers?
> For more historical reasons, I did the same method as done in the
> NPCM7XX driver.
> The clk_init_data struct can use * const *parent_names,
> https://elixir.bootlin.com/linux/v5.19-rc6/source/include/linux/clk-provider.h#L289
> Is it problematic?
It will need to be changed to not use global string matching. Ideally
new drivers use clk_parent_data or clk_hw pointers directly. It's faster
and preferred.
> >
> > > + NPCM8XX_CLK_S_AHB, CLK_DIVIDER_READ_ONLY, 0, NPCM8XX_CLK_SPI0},
> > > + /* bit 10-6 SPI0CKDV*/
> > > + {NPCM8XX_CLKDIV3, 1, 5, NPCM8XX_CLK_S_SPIX,
> > > + NPCM8XX_CLK_S_AHB, CLK_DIVIDER_READ_ONLY, 0, NPCM8XX_CLK_SPIX},
> > > + /* bit 5-1 SPIXCKDV*/
> > > +
> > > + {NPCM8XX_CLKDIV4, 28, 4, NPCM8XX_CLK_S_RG, NPCM8XX_CLK_S_RG_MUX,
> > > + CLK_DIVIDER_READ_ONLY, 0, NPCM8XX_CLK_RG},
> > > + /* bit 31-28 RGREFDIV*/
> > > + {NPCM8XX_CLKDIV4, 12, 4, NPCM8XX_CLK_S_RCP, NPCM8XX_CLK_S_RCP_MUX,
> > > + CLK_DIVIDER_READ_ONLY, 0, NPCM8XX_CLK_RCP},
> > > + /* bit 15-12 RCPREFDIV*/
> > > + {NPCM8XX_THRTL_CNT, 0, 2, NPCM8XX_CLK_S_TH, NPCM8XX_CLK_S_CPU_MUX,
> > > + CLK_DIVIDER_READ_ONLY | CLK_DIVIDER_POWER_OF_TWO, 0, NPCM8XX_CLK_TH},
> > > + /* bit 1-0 TH_DIV*/
> > > +};
> > > +
> > > +static DEFINE_SPINLOCK(npcm8xx_clk_lock);
> > > +
> > > +static int npcm8xx_clk_probe(struct platform_device *pdev)
> > > +{
> > > + struct clk_hw_onecell_data *npcm8xx_clk_data;
> > > + struct device *dev = &pdev->dev;
> > > + struct device_node *np = dev->of_node;
> > > + void __iomem *clk_base;
> > > + struct resource res;
> > > + struct clk_hw *hw;
> > > + int i, err;
> > > +
> > > + npcm8xx_clk_data = devm_kzalloc(dev, struct_size(npcm8xx_clk_data, hws,
> > > + NPCM8XX_NUM_CLOCKS),
> > > + GFP_KERNEL);
> > > + if (!npcm8xx_clk_data)
> > > + return -ENOMEM;
> > > +
> > > + err = of_address_to_resource(np, 0, &res);
> >
> > Why can't we use platform_get_resource()?
> >
> > > + if (err) {
> > > + dev_err(dev, "Failed to get resource, ret %d\n", err);
> > > + return err;
> > > + }
> > > +
> > > + clk_base = ioremap(res.start, resource_size(&res));
> >
> > And use devm_platform_ioremap_resource()?
> Clock and reset driver use the same memory register map 0xF0801000 - 0xF0801FFF.
> For historical reasons the registers of both modules are mixed in the
> memory range 0xF0801000 - 0xF0801FFF this is why we can't have a
> separate region for each module.
> In case I will use devm_platform_ioremap_resource function the reset
> ioremap will fail so the driver using the method above.
So the clk and reset driver should be the same driver, or one driver
should register the other and use the auxiliary bus to express the
relationship. That way we know that the drivers are tightly coupled and
aren't going to stomp over each other.
> >
> > > + if (!clk_base) {
> > > + dev_err(&pdev->dev, "Failed to remap I/O memory\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + npcm8xx_clk_data->num = NPCM8XX_NUM_CLOCKS;
> > > +
> > > + for (i = 0; i < NPCM8XX_NUM_CLOCKS; i++)
> > > + npcm8xx_clk_data->hws[i] = ERR_PTR(-EPROBE_DEFER);
> > > +
> > > + /* Reference 25MHz clock */
> >
> > Does this exist on the board? If so, I'd make a fixed rate clk in the
> > dts and have 'refclk' be an input in the binding for this clk controller.
> No, it is an internal clock in the SoC, this is why it is in the driver.
Ok. I suppose that could be inside the 'soc' node for this device as a
fixed rate clk but registering it here is also fine.
Powered by blists - more mailing lists