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

[Krzysztof Kozlowski <krzk@kernel.org>]

WhOn Mon, 21 Sep 2020 at 22:31, Moritz Fischer <mdf@kernel.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@intel.com>
> > > Signed-off-by: Russ Weight <russell.h.weight@intel.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@kernel.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