linux-kernel - Re: [PATCH v3] memory: dfl-emif: add the DFL EMIF private feature driver

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] [day] [month] [year] [list]

Message-ID: <20200922031736.GA55292@archbook>
Date:   Mon, 21 Sep 2020 20:17:36 -0700
From:   Moritz Fischer <mdf@...nel.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Moritz Fischer <mdf@...nel.org>, Xu Yilun <yilun.xu@...el.com>,
        linux-fpga@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        trix@...hat.com, lgoncalv@...hat.com,
        Russ Weight <russell.h.weight@...el.com>
Subject: Re: [PATCH v3] memory: dfl-emif: add the DFL EMIF private feature
 driver

Hi Krzysztof,

On Mon, Sep 21, 2020 at 10:46:45PM +0200, Krzysztof Kozlowski wrote:
> WhOn Mon, 21 Sep 2020 at 22:31, Moritz Fischer <mdf@...nel.org> wrote:
> >
> > Hi Krzysztof,
> >
> > On Mon, Sep 21, 2020 at 09:23:11AM +0200, Krzysztof Kozlowski wrote:
> > > On Mon, Sep 21, 2020 at 01:31:20PM +0800, Xu Yilun wrote:
> > > > This driver is for the EMIF private feature implemented under FPGA
> > > > Device Feature List (DFL) framework. It is used to expose memory
> > > > interface status information as well as memory clearing control.
> > > >
> > > > The purpose of memory clearing block is to zero out all private memory
> > > > when FPGA is to be reprogrammed. This gives users a reliable method to
> > > > prevent potential data leakage.
> > > >
> > > > Signed-off-by: Xu Yilun <yilun.xu@...el.com>
> > > > Signed-off-by: Russ Weight <russell.h.weight@...el.com>
> > > > ---
> > > > v2: Adjust the position of this driver in Kconfig.
> > > >     Improves the name of the Kconfig option.
> > > >     Change the include dfl-bus.h to dfl.h, cause the previous patchset
> > > >      renames the file.
> > > >     Some minor fixes and comment improvement.
> > > > v3: Adjust the position of the driver in Makefile.
> > > > ---
> > > >  .../ABI/testing/sysfs-bus-dfl-devices-emif         |  25 +++
> > > >  drivers/memory/Kconfig                             |   9 +
> > > >  drivers/memory/Makefile                            |   2 +
> > > >  drivers/memory/dfl-emif.c                          | 207 +++++++++++++++++++++
> > > >  4 files changed, 243 insertions(+)
> > > >  create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices-emif
> > > >  create mode 100644 drivers/memory/dfl-emif.c
> > > >
> > >
> > > Hi Moritz,
> > >
> > > Since this depends on dfl patches, I would need a stable tag with them
> > > or you can take it directly:
> > > Acked-by: Krzysztof Kozlowski <krzk@...nel.org>
> > >
> > > Best regards,
> > > Krzysztof
> >
> > The FPGA patches go through Greg's tree. For the time being it's
> > probably easiest if I take the changes through my tree once Greg pulled
> > my tree.
> 
> Yes.
> 
> >
> > Do you have any feedback to better handle this sort of subsystem
> > spanning changesets for me?
> 
> The easiest through a separate branch. Assuming that such need for
> sharing patches is known.
> 
> If the patches touch generic things, which could be used by other
> drivers/subsystems, or if it is known that there will be someone
> depending on them, the easiest is to put them on separate branch which
> you later merge into your for-next. You send to Greg your for-next. If
> these patches are needed by someone else, e.g. me, you prepare a tag
> on them and send a pull request with that tag. I pull it and send
> these (and only these!) along with other patches. No duplication of
> commits, only two merges.
> 
> Recent example was here:
> https://lore.kernel.org/lkml/20200819191722.GA38371@sirena.org.uk/
> where Mark Brown wanted these through his tree, but later work on
> Samsung ARM depended on them.
> 
> Best regards,
> Krzysztof

Appreciate the explanation, that makes sense. Thanks for taking the
time. I'll do this moving forward.

Cheers,
Moritz