Hi Krzysztof, On Mon, Oct 12, 2020 at 06:40:46PM +0200, Krzysztof Kozlowski wrote: > On Sat, 10 Oct 2020 at 09:15, Xu Yilun <yilun.xu@xxxxxxxxx> 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> > > Acked-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > > --- > > 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. > > v9: Add static prefix for emif attributes macro > > Update the kernel version of the sysfs interfaces in Doc. > > --- > > .../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 > > > > I am confused now. This was already taken by Moritz, wasn't it? And > the dependencies were already taken, weren't they? Previously it was > depending on "Modularization of DFL private feature drivers" and "add > dfl bus support to MODULE_DEVICE_TABLE()"... now this is here so did > the dependencies change? What is the reason to include this patch > here? It is confusing. Basically Greg had comments on the patch after I had applied it. It's going through anothe round of review. > > My ack was for the purpose of taking it via Moritz tree, because of > the dependencies. If this is not the case, then probably better to > take it via memory controllers tree to avoid any conflicts (it's not a > small change). Once it's ok I can put it on a branch with a stable tag and you can pull that in and take the patch through your tree. Does that work? Sorry for the mess, Moritz