linux-kernel - Re: [PATCH 4.19 106/140] iio: ad7949: kill pointless "readback"-handling code

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: <20191216184536.GB2411653@kroah.com>
Date:   Mon, 16 Dec 2019 19:45:36 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Andrea Merello <andrea.merello@...il.com>,
        Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH 4.19 106/140] iio: ad7949: kill pointless
 "readback"-handling code

On Mon, Dec 16, 2019 at 07:31:31PM +0100, Andrea Merello wrote:
> Something nasty seems happening here: it looks like the commit message
> and the actual diff have nothing to do one wrt the other; the commit
> message is from one of my patches, the diff is against some unrelated
> file.
> 
> Il giorno lun 16 dic 2019 alle ore 19:05 Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> ha scritto:
> >
> > From: Meng Li <Meng.Li@...driver.com>
> >
> > [ Upstream commit c270bbf7bb9ddc4e2a51b3c56557c377c9ac79bc ]
> >
> > The device could be configured to spit out also the configuration word
> > while reading the AD result value (in the same SPI xfer) - this is called
> > "readback" in the device datasheet.
> >
> > The driver checks if readback is enabled and it eventually adjusts the SPI
> > xfer length and it applies proper shifts to still get the data, discarding
> > the configuration word.
> >
> > The readback option is actually never enabled (the driver disables it), so
> > the said checks do not serve for any purpose.
> >
> > Since enabling the readback option seems not to provide any advantage (the
> > driver entirely sets the configuration word without relying on any default
> > value), just kill the said, unused, code.
> >
> > Signed-off-by: Andrea Merello <andrea.merello@...il.com>
> > Reviewed-by: Alexandru Ardelean <alexandru.ardelean@...log.com>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
> > ---
> >  drivers/edac/altera_edac.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
> > index 56de378ad13dc..c9108906bcdc0 100644
> > --- a/drivers/edac/altera_edac.c
> > +++ b/drivers/edac/altera_edac.c
> > @@ -600,6 +600,7 @@ static const struct regmap_config s10_sdram_regmap_cfg = {
> >         .reg_read = s10_protected_reg_read,
> >         .reg_write = s10_protected_reg_write,
> >         .use_single_rw = true,
> > +       .fast_io = true,
> >  };
> >
> >  static int altr_s10_sdram_probe(struct platform_device *pdev)
> > --
> > 2.20.1
> >
> >
> >

Wow, something went wrong.

Sasha, can you look into this?

thanks,

greg k-h