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
