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
