From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0495121173C8B for ; Sun, 14 Oct 2018 17:55:09 -0700 (PDT) From: Michael Ellerman Subject: Re: [PATCH 2/2] powerpc/pseries: Add driver for PAPR SCM regions In-Reply-To: References: <20181010060812.20068-1-oohall@gmail.com> <20181010060812.20068-3-oohall@gmail.com> <87h8hq122t.fsf@concordia.ellerman.id.au> Date: Mon, 15 Oct 2018 11:55:05 +1100 Message-ID: <874ldo111y.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Nathan Fontenot , linuxppc-dev , linux-nvdimm List-ID: Dan Williams writes: > On Sat, Oct 13, 2018 at 5:08 AM Michael Ellerman wrote: >> >> Dan Williams writes: >> > On Tue, Oct 9, 2018 at 11:21 PM Oliver O'Halloran wrote: >> >> >> >> Adds a driver that implements support for enabling and accessing PAPR >> >> SCM regions. Unfortunately due to how the PAPR interface works we can't >> >> use the existing of_pmem driver (yet) because: >> >> >> ... >> >> + >> >> +static int papr_scm_nvdimm_init(struct papr_scm_priv *p) >> >> +{ >> >> + struct device *dev = &p->pdev->dev; >> >> + struct nd_mapping_desc mapping; >> >> + struct nd_region_desc ndr_desc; >> >> + unsigned long dimm_flags; >> >> + >> >> + p->bus_desc.ndctl = papr_scm_ndctl; >> >> + p->bus_desc.module = THIS_MODULE; >> >> + p->bus_desc.of_node = p->pdev->dev.of_node; >> >> + p->bus_desc.attr_groups = bus_attr_groups; >> >> + p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL); >> >> + >> >> + if (!p->bus_desc.provider_name) >> >> + return -ENOMEM; >> >> + >> >> + p->bus = nvdimm_bus_register(NULL, &p->bus_desc); >> >> + if (!p->bus) { >> >> + dev_err(dev, "Error creating nvdimm bus %pOF\n", p->dn); >> >> + return -ENXIO; >> >> + } >> >> + >> >> + dimm_flags = 0; >> >> + set_bit(NDD_ALIASING, &dimm_flags); >> >> + >> >> + p->nvdimm = nvdimm_create(p->bus, p, papr_scm_dimm_groups, >> >> + dimm_flags, PAPR_SCM_DIMM_CMD_MASK, 0, NULL); >> > >> > Looks good, although I'm just about to push out commits that change >> > this function signature to take a 'security_ops' pointer. If you need >> > a stable branch to base this on, let me know. >> ... >> > >> > Other than that looks ok to me: >> > >> > Acked-by: Dan Williams >> > >> > ...just the matter of what to do about function signature change. >> >> Yeah that's a bit of a bother. >> >> The ideal for me would be that you put the commit that changes the >> signature by itself in a branch based on 4.19-rc3 (or earlier), and then >> we could both just merge that. >> >> But not sure if that will work with whatever else you're trying to sync >> up with. > > How about this, I'll move the new signature to an 'advanced': > > __nvdimm_create() > > ...and make the existing: > > nvdimm_create() > > ...a simple wrapper around the new functionality. That way no matter > what merge order we should be ok. Yep that's much easier, thanks. cheers _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm