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: <CAP6Zq1hk46xpQsVFz3RAF3CHU-PNCBxN+6SRKrdWzffRjRep4g@mail.gmail.com>
Date: Tue, 2 Apr 2024 22:42:55 +0300
From: Tomer Maimon <tmaimon77@...il.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: benjaminfair@...gle.com, joel@....id.au, krzysztof.kozlowski+dt@...aro.org, 
	mturquette@...libre.com, robh+dt@...nel.org, tali.perry1@...il.com, 
	venture@...gle.com, yuenn@...gle.com, openbmc@...ts.ozlabs.org, 
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH v23 3/3] clk: npcm8xx: add clock controller

Hi Stephen,

Kind remainder, appreciate if you can reply about the comment that
been sent few weeks ago.

Thanks,

Tomer

On Tue, 5 Mar 2024 at 17:59, Tomer Maimon <tmaimon77@...il.com> wrote:
>
> Hi Stephen,
>
> Appreciate it if you could reply to my email afew days ago, It is
> really important to us to move this driver to upstream.
>
> Thanks,
>
> Tomer
>
> On Thu, 29 Feb 2024 at 23:29, Tomer Maimon <tmaimon77@...il.com> wrote:
> >
> > Hi Stephen,
> >
> > Thanks for your reply.
> >
> > On Thu, 29 Feb 2024 at 00:48, Stephen Boyd <sboyd@...nel.org> wrote:
> > >
> > > Quoting Tomer Maimon (2024-02-25 10:00:35)
> > > > Hi Stephen,
> > > >
> > > > On Thu, 22 Feb 2024 at 07:58, Stephen Boyd <sboyd@...nel.org> wrote:
> > > > >
> > > > > Quoting Tomer Maimon (2024-01-31 10:26:53)
> > > > > > diff --git a/drivers/clk/clk-npcm8xx.c b/drivers/clk/clk-npcm8xx.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..eacb579d30af
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/clk/clk-npcm8xx.c
> > > > > > @@ -0,0 +1,509 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > +/*
> > > > > > + * Nuvoton NPCM8xx Clock Generator
> > > > > > + * All the clocks are initialized by the bootloader, so this driver allows only
> > > > > [...]
> > > > > > +
> > > > > > +/* external clock definition */
> > > > > > +#define NPCM8XX_CLK_S_REFCLK   "refclk"
> > > > > > +
> > > > > > +/* pll definition */
> > > > > > +#define NPCM8XX_CLK_S_PLL0     "pll0"
> > > > > > +#define NPCM8XX_CLK_S_PLL1     "pll1"
> > > > > > +#define NPCM8XX_CLK_S_PLL2     "pll2"
> > > > > > +#define NPCM8XX_CLK_S_PLL_GFX  "pll_gfx"
> > > > > > +
> > > > > > +/* early divider definition */
> > > > > > +#define NPCM8XX_CLK_S_PLL2_DIV2                "pll2_div2"
> > > > > > +#define NPCM8XX_CLK_S_PLL_GFX_DIV2     "pll_gfx_div2"
> > > > > > +#define NPCM8XX_CLK_S_PLL1_DIV2                "pll1_div2"
> > > > > > +
> > > > > > +/* mux definition */
> > > > > > +#define NPCM8XX_CLK_S_CPU_MUX     "cpu_mux"
> > > > > > +
> > > > > > +/* div definition */
> > > > > > +#define NPCM8XX_CLK_S_TH          "th"
> > > > > > +#define NPCM8XX_CLK_S_AXI         "axi"
> > > > >
> > > > > Please inline all these string #defines to the place they're used.
> > > > The version V21 you mention using define only when the definition is
> > > > used more than once
> > > > https://www.spinics.net/lists/kernel/msg5045826.html
> > > > Should I remove all the string definitions and add the string to the array?
> > >
> > > If it's a clk name for a clk registered in this file it should be
> > > inlined. Is that the case for everything besides refclk? And even refclk
> > > could be inlined so that we don't have to jump to the definition of a
> > > string.
> > I will add the string in the clock arrays and remove all the string definitions.
> > >
> > > > > > +
> > > > > > +static unsigned long npcm8xx_clk_div_get_parent(struct clk_hw *hw,
> > > > > > +                                               unsigned long parent_rate)
> > > > > > +{
> > > > > > +       struct npcm8xx_clk *div = to_npcm8xx_clk(hw);
> > > > > > +       unsigned int val;
> > > > > > +
> > > > > > +       regmap_read(div->clk_regmap, div->offset, &val);
> > > > > > +       val = val >> div->shift;
> > > > > > +       val &= clk_div_mask(div->width);
> > > > > > +
> > > > > > +       return divider_recalc_rate(hw, parent_rate, val, NULL, div->flags,
> > > > > > +                                  div->width);
> > > > > > +}
> > > > > > +
> > > > > > +static const struct clk_ops npcm8xx_clk_div_ops = {
> > > > > > +       .recalc_rate = npcm8xx_clk_div_get_parent,
> > > > > > +};
> > > > > > +
> > > > > > +static int npcm8xx_clk_probe(struct platform_device *pdev)
> > > > > > +{
> > > > > > +       struct device_node *parent_np = of_get_parent(pdev->dev.of_node);
> > > > >
> > > > > The parent of this device is not a syscon.
> > > > Once I have registered the map that handles both reset and the clock
> > > > in general is syscon, this is why we will modify the DTS so the clock
> > > > and the reset will be under syscon father node
> > > >                 sysctrl: system-controller@...01000 {
> > > >                         compatible = "syscon", "simple-mfd";
> > > >                         reg = <0x0 0xf0801000 0x0 0x1000>;
> > > >
> > > >                         rstc: reset-controller {
> > > >                                 compatible = "nuvoton,npcm845-reset";
> > > >                                 reg = <0x0 0xf0801000 0x0 0xC4>;
> > > >                                 #reset-cells = <2>;
> > > >                                 nuvoton,sysgcr = <&gcr>;
> > > >                         };
> > > >
> > > >                         clk: clock-controller {
> > > >                                 compatible = "nuvoton,npcm845-clk";
> > > >                                 #clock-cells = <1>;
> > > >                                 clocks = <&refclk>;
> > > >                                 clock-names = "refclk";
> > > >                         };
> > > >                 };
> > > > You can see other drivers that using the same method like
> > > > https://elixir.bootlin.com/linux/v6.8-rc5/source/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
> > >
> > > You will need a similar file like
> > > Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml
> > > then to describe the child nodes.
> > I can do it.
> > >
> > > Socionext may not be the best example to follow. I generally try to
> > > avoid syscon and simply put #reset-cells and #clock-cells in the node
> > If I remove syscon I can't use syscon_node_to_regmap function, What
> > should I use If I remove syscon? auxiliary bus? something else?
> > > for the device. You can use the auxiliary bus to register drivers for
> > > clk and reset and put them into the resepective driver directories.
> > I little bit confused, what is an auxiliary bus to register drivers,
> > can you provide me an example?
> > > Avoid syscon means random drivers can't reach into the device with a
> > > regmap handle and read/write registers that they're not supposed to.
> > Indeed, but the drivers could use the reset and clock memory map only
> > if the module is also a child node.
> >
> > Please let me know what is your preferred way to handle it:
> > 1. stick with syscon and upstream-defined documentation for the rst clk syscon.
> > 2. avoid syscon and use an auxiliary bus, appreciate if you could give
> > me an example of how it should be done.
> > 3. Avoid sycon and handle it differently.
> > >
> > > > >
> > > > > > +       struct clk_hw_onecell_data *npcm8xx_clk_data;
> > > > > > +       struct device *dev = &pdev->dev;
> > > > > > +       struct regmap *clk_regmap;
> > > > > > +       struct clk_hw *hw;
> > > > > > +       unsigned int i;
> > > > > > +
> > > > > > +       npcm8xx_clk_data = devm_kzalloc(dev, struct_size(npcm8xx_clk_data, hws,
> > > > > > +                                                        NPCM8XX_NUM_CLOCKS),
> > > > > > +                                       GFP_KERNEL);
> > > > > > +       if (!npcm8xx_clk_data)
> > > > > > +               return -ENOMEM;
> > > > > > +
> > > > > > +       clk_regmap = syscon_node_to_regmap(parent_np);
> > > > > > +       of_node_put(parent_np);
> > > > >
> > > > > Is there another binding update that is going to move this node to be a
> > > > > child of the syscon?
> > > > >
> > > > >                 gcr: system-controller@...00000 {
> > > > >                         compatible = "nuvoton,npcm845-gcr", "syscon";
> > > > >                         reg = <0x0 0xf0800000 0x0 0x1000>;
> > > > >                 };
> > > > No, sorry but I'm not going to use the GCR node the handle the clock
> > > > and reset modules, the GCR has different memory space.
> > > > the clock driver will have the following device tree
> > >
> > > What does the reset driver use the CGR node for? The driver looks like
> > > it's using it to control USB phy resets.
> > Yes, the USB PHY reset is handled through the GCR registers.
> > >
> > > >                sysctrl: system-controller@...01000 {
> > > >                         compatible = "syscon", "simple-mfd";
> > > >                         reg = <0x0 0xf0801000 0x0 0x1000>;
> > > >
> > > >                         rstc: reset-controller {
> > > >                                 compatible = "nuvoton,npcm845-reset";
> > > >                                 reg = <0x0 0xf0801000 0x0 0xC4>;
> > >
> > > This isn't a valid reg property for a child node like this.
> > O.K.
> > >
> > > >                                 #reset-cells = <2>;
> > > >                                 nuvoton,sysgcr = <&gcr>;
> > > >                         };
> > > >
> > > >                         clk: clock-controller {
> > > >                                 compatible = "nuvoton,npcm845-clk";
> > > >                                 #clock-cells = <1>;
> > > >                                 clocks = <&refclk>;
> > > >                                 clock-names = "refclk";
> > > >                         };
> > > >                 };
> >
> > Appreciate your guidance!
> >
> > Thanks,
> >
> > Tomer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ