linux-kernel - Re: [PATCH 5/6] memory: renesas-rpc-if: Drop usage of RPCIF_DIRMAP

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: <CA+V-a8sZ0qudhbV7Fart-puNQO-ZHhDEG3OdRH=w_dbTHy2A7g@mail.gmail.com>
Date:   Thu, 30 Sep 2021 15:14:18 +0100
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Rob Herring <robh+dt@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Vignesh Raghavendra <vigneshr@...com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Mark Brown <broonie@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sergei Shtylyov <sergei.shtylyov@...il.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, linux-mtd@...ts.infradead.org,
        linux-spi <linux-spi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Prabhakar <prabhakar.csengg@...il.com>,
        Biju Das <biju.das.jz@...renesas.com>
Subject: Re: [PATCH 5/6] memory: renesas-rpc-if: Drop usage of
 RPCIF_DIRMAP_SIZE macro

Hi Wolfram,

Thank you for the review.

On Thu, Sep 30, 2021 at 2:55 PM Wolfram Sang
<wsa+renesas@...g-engineering.com> wrote:
>
> On Tue, Sep 28, 2021 at 03:07:20PM +0100, Lad Prabhakar wrote:
> > RPCIF_DIRMAP_SIZE may differ on various SoC's. Instead of using
> > RPCIF_DIRMAP_SIZE macro use resource size to get dirmap size
> > which is already part of struct rpcif.
> >
> > Also make sure we return error in case devm_ioremap_resource()
> > fails for dirmap.
> >
> > Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver")
> > Fixes: 59e27d7c94aa ("memory: renesas-rpc-if: fix possible NULL pointer dereference of resource")
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > Reviewed-by: Biju Das <biju.das.jz@...renesas.com>
>
> In general, all fine. I just think this should be split into two
> patches:
>
Sure will split this into two.

> > @@ -147,8 +147,6 @@
> >  #define RPCIF_PHYINT         0x0088  /* R/W */
> >  #define RPCIF_PHYINT_WPVAL   BIT(1)
> >
> > -#define RPCIF_DIRMAP_SIZE    0x4000000
> > -
> >  static const struct regmap_range rpcif_volatile_ranges[] = {
> >       regmap_reg_range(RPCIF_SMRDR0, RPCIF_SMRDR1),
> >       regmap_reg_range(RPCIF_SMWDR0, RPCIF_SMWDR1),
> > @@ -547,8 +545,8 @@ EXPORT_SYMBOL(rpcif_manual_xfer);
> >
> >  ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf)
> >  {
> > -     loff_t from = offs & (RPCIF_DIRMAP_SIZE - 1);
> > -     size_t size = RPCIF_DIRMAP_SIZE - from;
> > +     loff_t from = offs & (rpc->size - 1);
> > +     size_t size = rpc->size - from;
> >
> >       if (len > size)
> >               len = size;
>
> This is the second patch to split which fixes ca7d8b980b67.
>
Will split this change into a second patch but wont add a fixes tag see below..

>
> > @@ -244,7 +242,7 @@ int rpcif_sw_init(struct rpcif *rpc, struct device *dev)
> >       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
> >       rpc->dirmap = devm_ioremap_resource(&pdev->dev, res);
> >       if (IS_ERR(rpc->dirmap))
> > -             rpc->dirmap = NULL;
> > +             return PTR_ERR(rpc->dirmap);
> >       rpc->size = resource_size(res);
> >
> >       rpc->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
>
> This is the first patch to split which fixes 59e27d7c94aa.
>
> Makes sense?
>
Both the fixes would apply to the first patch itself i.e. when
resource_size was added in ca7d8b980b67 and later in 59e27d7c94aa
resource_size was moved online below (this would cause kernel panic
res is NULL). Do you agree?

> If you agree, you can add my tag already to the new patches:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@...g-engineering.com>
>
Sure will add your RB tag.

Cheers,
Prabhakar