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:   Fri, 1 Apr 2022 09:47:48 +0000
From:   qinjian[覃健] <qinjian@...lus1.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        "Stephen Boyd" <sboyd@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Russell King - ARM Linux" <linux@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>
Subject: RE: [PATCH v12 5/9] clk: Add Sunplus SP7021 clock driver

> 
> > +static int sp_pll_enable(struct clk_hw *hw)
> > +{
> > +       struct sp_pll *clk = to_sp_pll(hw);
> > +       unsigned long flags;
> > +
> > +       spin_lock_irqsave(clk->lock, flags);
> > +       writel(BIT(clk->pd_bit + 16) | BIT(clk->pd_bit), clk->reg); /* power up */
> > +       spin_unlock_irqrestore(clk->lock, flags);
> > +
> > +       return 0;
> > +}
> > +
> > +static void sp_pll_disable(struct clk_hw *hw)
> > +{
> > +       struct sp_pll *clk = to_sp_pll(hw);
> > +       unsigned long flags;
> > +
> > +       spin_lock_irqsave(clk->lock, flags);
> > +       writel(BIT(clk->pd_bit + 16), clk->reg); /* power down */
> > +       spin_unlock_irqrestore(clk->lock, flags);
> > +}
> 
> What does the spinlock actually protect here? As writel() is posted, it
> can already leak of of the lock, and the inputs would appear to be
> constant.
> 

These code is refered from other clk driver.
But, other driver need read then write, so need lock protected.
Our  HW is HIWORD_MASKED_REG, means modify bits no need to read, just 1 write only.
So, the lock is useless.
Did I right?

> > +       /* This memory region include multi HW regs in discontinuous order.
> > +        * clk driver used some discontinuous areas in the memory region.
> > +        * Using devm_platform_ioremap_resource() would conflicted with other drivers.
> > +        */
> > +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +       sp_clk_base = devm_ioremap(dev, res->start, resource_size(res));
> > +       if (!sp_clk_base)
> > +               return -ENXIO;
> 
> Can you explain this comment in more detail? Generally, the 'reg' properties
> of drivers should not overlap, so it is supposed to be safe to call
> devm_platform_ioremap_resource() here.
> 
> We discussed this in the context of the iop driver that did have overlapping
> registers with this driver, and that was incorrect. Are there any other drivers
> that conflict with the clk driver?
> 
>       Arnd

I means, I must split up the origin reg region into 4 small pieces,
and call devm_platform_ioremap_resource() 4 times.
Did I should follow this way?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ