[{"id":1756993,"web_url":"http://patchwork.ozlabs.org/comment/1756993/","msgid":"<87efs0uxj4.fsf@concordia.ellerman.id.au>","date":"2017-08-25T03:38:39","subject":"Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO\n\tregions","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Hi Suka,\n\nComments inline.\n\nSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n> diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> index 6156fbe..a3a705a 100644\n> --- a/arch/powerpc/platforms/powernv/vas-window.c\n> +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> @@ -9,9 +9,182 @@\n>  \n>  #include <linux/types.h>\n>  #include <linux/mutex.h>\n> +#include <linux/slab.h>\n> +#include <linux/io.h>\n>  \n>  #include \"vas.h\"\n>  \n> +/*\n> + * Compute the paste address region for the window @window using the\n> + * ->paste_base_addr and ->paste_win_id_shift we got from device tree.\n> + */\n> +void compute_paste_address(struct vas_window *window, uint64_t *addr, int *len)\n> +{\n> +\tuint64_t base, shift;\n\nPlease use the kernel types, so u64 here.\n\n> +\tint winid;\n> +\n> +\tbase = window->vinst->paste_base_addr;\n> +\tshift = window->vinst->paste_win_id_shift;\n> +\twinid = window->winid;\n> +\n> +\t*addr  = base + (winid << shift);\n> +\tif (len)\n> +\t\t*len = PAGE_SIZE;\n\nHaving multiple output parameters makes for a pretty awkward API. Is it\nreally necesssary given len is a constant PAGE_SIZE anyway.\n\nIf you didn't return len, then you could just make the function return\nthe addr, and you wouldn't need any output parameters.\n\nOne of the callers that passes len is unmap_paste_region(), but that\nis a bit odd. It would be more natural I think if once a window is\nmapped it knows its size. Or if the mapping will always just be one page\nthen we can just know that.\n\n> +\n> +\tpr_debug(\"Txwin #%d: Paste addr 0x%llx\\n\", winid, *addr);\n> +}\n> +\n> +static inline void get_hvwc_mmio_bar(struct vas_window *window,\n> +\t\t\tuint64_t *start, int *len)\n> +{\n> +\tuint64_t pbaddr;\n> +\n> +\tpbaddr = window->vinst->hvwc_bar_start;\n> +\t*start = pbaddr + window->winid * VAS_HVWC_SIZE;\n> +\t*len = VAS_HVWC_SIZE;\n\nThis is:\n\n#define VAS_HVWC_SIZE\t\t\t512\n\nBut then we map it, which will round up to a page anyway. So again I\ndon't see the point of having the len returned form this helper.\n\n> +}\n> +\n> +static inline void get_uwc_mmio_bar(struct vas_window *window,\n> +\t\t\tuint64_t *start, int *len)\n> +{\n> +\tuint64_t pbaddr;\n> +\n> +\tpbaddr = window->vinst->uwc_bar_start;\n> +\t*start = pbaddr + window->winid * VAS_UWC_SIZE;\n> +\t*len = VAS_UWC_SIZE;\n> +}\n> +\n> +/*\n> + * Map the paste bus address of the given send window into kernel address\n> + * space. Unlike MMIO regions (map_mmio_region() below), paste region must\n> + * be mapped cache-able and is only applicable to send windows.\n> + */\n> +void *map_paste_region(struct vas_window *txwin)\n> +{\n> +\tint rc, len;\n> +\tvoid *map;\n> +\tchar *name;\n> +\tuint64_t start;\n> +\n> +\trc = -ENOMEM;\n\nYou don't need that.\n\n> +\tname = kasprintf(GFP_KERNEL, \"window-v%d-w%d\", txwin->vinst->vas_id,\n> +\t\t\t\ttxwin->winid);\n> +\tif (!name)\n> +\t\treturn ERR_PTR(rc);\n\nThat can goto free_name;\n\n> +\n> +\ttxwin->paste_addr_name = name;\n> +\tcompute_paste_address(txwin, &start, &len);\n> +\n> +\tif (!request_mem_region(start, len, name)) {\n> +\t\tpr_devel(\"%s(): request_mem_region(0x%llx, %d) failed\\n\",\n> +\t\t\t\t__func__, start, len);\n> +\t\tgoto free_name;\n> +\t}\n> +\n> +\tmap = ioremap_cache(start, len);\n> +\tif (!map) {\n> +\t\tpr_devel(\"%s(): ioremap_cache(0x%llx, %d) failed\\n\", __func__,\n> +\t\t\t\tstart, len);\n> +\t\tgoto free_name;\n> +\t}\n> +\n> +\tpr_devel(\"VAS: mapped paste addr 0x%llx to kaddr 0x%p\\n\", start, map);\n> +\treturn map;\n> +\n> +free_name:\n> +\tkfree(name);\n\nBecause kfree(NULL) is fine.\n\n> +\treturn ERR_PTR(rc);\n\nAnd that can just return ERR_PTR(-ENOMEM);\n\n> +}\n\ncheers","headers":{"Return-Path":"<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xdn3Q4qlgz9t4B\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 25 Aug 2017 13:39:46 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xdn3Q3gPyzDrM7\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 25 Aug 2017 13:39:46 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xdn2B10zYzDrJy\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tFri, 25 Aug 2017 13:38:42 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xdn2B0B3rz9t4X; Fri, 25 Aug 2017 13:38:42 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3xdn296WDqz9t4B;\n\tFri, 25 Aug 2017 13:38:41 +1000 (AEST)"],"From":"Michael Ellerman <mpe@ellerman.id.au>","To":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>","Subject":"Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO\n\tregions","In-Reply-To":"<1503556688-15412-5-git-send-email-sukadev@linux.vnet.ibm.com>","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-5-git-send-email-sukadev@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Fri, 25 Aug 2017 13:38:39 +1000","Message-ID":"<87efs0uxj4.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t<linuxppc-dev.lists.ozlabs.org>","List-Unsubscribe":"<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>","List-Archive":"<http://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>","List-Subscribe":"<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>","Cc":"stewart@linux.vnet.ibm.com, mikey@neuling.org, linuxppc-dev@ozlabs.org, \n\tlinux-kernel@vger.kernel.org, apopple@au1.ibm.com, oohall@gmail.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>"}},{"id":1758356,"web_url":"http://patchwork.ozlabs.org/comment/1758356/","msgid":"<20170828043607.GB12907@us.ibm.com>","date":"2017-08-28T04:36:07","subject":"Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO\n\tregions","submitter":{"id":984,"url":"http://patchwork.ozlabs.org/api/people/984/","name":"Sukadev Bhattiprolu","email":"sukadev@linux.vnet.ibm.com"},"content":"Michael Ellerman [mpe@ellerman.id.au] wrote:\n> Hi Suka,\n> \n> Comments inline.\n> \n> Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n> > diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> > index 6156fbe..a3a705a 100644\n> > --- a/arch/powerpc/platforms/powernv/vas-window.c\n> > +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> > @@ -9,9 +9,182 @@\n> >  \n> >  #include <linux/types.h>\n> >  #include <linux/mutex.h>\n> > +#include <linux/slab.h>\n> > +#include <linux/io.h>\n> >  \n> >  #include \"vas.h\"\n> >  \n> > +/*\n> > + * Compute the paste address region for the window @window using the\n> > + * ->paste_base_addr and ->paste_win_id_shift we got from device tree.\n> > + */\n> > +void compute_paste_address(struct vas_window *window, uint64_t *addr, int *len)\n> > +{\n> > +\tuint64_t base, shift;\n> \n> Please use the kernel types, so u64 here.\n\nOk.\n\n> \n> > +\tint winid;\n> > +\n> > +\tbase = window->vinst->paste_base_addr;\n> > +\tshift = window->vinst->paste_win_id_shift;\n> > +\twinid = window->winid;\n> > +\n> > +\t*addr  = base + (winid << shift);\n> > +\tif (len)\n> > +\t\t*len = PAGE_SIZE;\n> \n> Having multiple output parameters makes for a pretty awkward API. Is it\n> really necesssary given len is a constant PAGE_SIZE anyway.\n> \n> If you didn't return len, then you could just make the function return\n> the addr, and you wouldn't need any output parameters.\n\nI agree, I went back and forth on it. I was trying to avoid callers\nmaking assumptions on the size. But since there are just a couple\nof places, I guess we could have them assume PAGE_SIZE.\n\n> \n> One of the callers that passes len is unmap_paste_region(), but that\n> is a bit odd. It would be more natural I think if once a window is\n> mapped it knows its size. Or if the mapping will always just be one page\n> then we can just know that.\n\nAgree, since the len values are constant I was trying to avoid saving\nthem in each of the 64K windows - so the compute during unmap. Will change\nto assume  PAGE_SIZE.\n\nAlso agree with other comments here.","headers":{"Return-Path":"<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xgfBR4p7Sz9ryT\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 14:37:19 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xgfBR3yxDzDqYx\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 14:37:19 +1000 (AEST)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xgf9D3tSszDqD0\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tMon, 28 Aug 2017 14:36:16 +1000 (AEST)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\tby bilbo.ozlabs.org (Postfix) with ESMTP id 3xgf9D3H47z8t8Q\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tMon, 28 Aug 2017 14:36:16 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xgf9D2z4Vz9t1t; Mon, 28 Aug 2017 14:36:16 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xgf9D0D6nz9sPk\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 14:36:15 +1000 (AEST)","from pps.filterd (m0098410.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7S4ZpAm088435\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 00:36:13 -0400","from e18.ny.us.ibm.com (e18.ny.us.ibm.com [129.33.205.208])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cm2rpj09b-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 00:36:13 -0400","from localhost\n\tby e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor <linuxppc-dev@ozlabs.org> from <sukadev@linux.vnet.ibm.com>;\n\tMon, 28 Aug 2017 00:36:12 -0400","from b01cxnp22036.gho.pok.ibm.com (9.57.198.26)\n\tby e18.ny.us.ibm.com (146.89.104.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 28 Aug 2017 00:36:09 -0400","from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com\n\t[9.57.199.108])\n\tby b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v7S4a97e31653934; Mon, 28 Aug 2017 04:36:09 GMT","from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 35858B2056;\n\tMon, 28 Aug 2017 00:33:33 -0400 (EDT)","from suka-w540.localdomain (unknown [9.70.94.25])\n\tby b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id F0D22B2054;\n\tMon, 28 Aug 2017 00:33:32 -0400 (EDT)","by suka-w540.localdomain (Postfix, from userid 1000)\n\tid 6ED77229282; Sun, 27 Aug 2017 21:36:07 -0700 (PDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=sukadev@linux.vnet.ibm.com; receiver=<UNKNOWN>)","Date":"Sun, 27 Aug 2017 21:36:07 -0700","From":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>","To":"Michael Ellerman <mpe@ellerman.id.au>","Subject":"Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO\n\tregions","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-5-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<87efs0uxj4.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87efs0uxj4.fsf@concordia.ellerman.id.au>","X-Operating-System":"Linux 2.0.32 on an i486","User-Agent":"Mutt/1.7.1 (2016-10-04)","X-TM-AS-GCONF":"00","x-cbid":"17082804-0044-0000-0000-000003840072","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007625; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000225; SDB=6.00908645; UDB=6.00455613;\n\tIPR=6.00688886; \n\tBA=6.00005555; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016893;\n\tXFM=3.00000015; UTC=2017-08-28 04:36:11","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17082804-0045-0000-0000-000007B218C4","Message-Id":"<20170828043607.GB12907@us.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-08-28_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1708280073","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t<linuxppc-dev.lists.ozlabs.org>","List-Unsubscribe":"<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>","List-Archive":"<http://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>","List-Subscribe":"<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>","Cc":"stewart@linux.vnet.ibm.com, mikey@neuling.org, linuxppc-dev@ozlabs.org, \n\tlinux-kernel@vger.kernel.org, apopple@au1.ibm.com, oohall@gmail.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>"}}]