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

[Moritz Fischer]

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@xxxxxxxxxx> 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@xxxxxxxxx>
> > > > Signed-off-by: Russ Weight <russell.h.weight@xxxxxxxxx>
> > > > ---
> > > > 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@xxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxxx/
> 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