From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755885AbaLHRQE (ORCPT ); Mon, 8 Dec 2014 12:16:04 -0500 Received: from mail-wi0-f172.google.com ([209.85.212.172]:41079 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbaLHRQB (ORCPT ); Mon, 8 Dec 2014 12:16:01 -0500 MIME-Version: 1.0 In-Reply-To: References: <1416220572-13381-1-git-send-email-ankit.jindal@linaro.org> <2279061.naADrHDgyn@wuerfel> <1503477.DVdkExccIe@wuerfel> From: Rob Herring Date: Mon, 8 Dec 2014 11:15:39 -0600 Message-ID: Subject: Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver To: Ankit Jindal Cc: Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Varka Bhadram , Russell King - ARM Linux , Greg Kroah-Hartman , Anup Patel , Guenter Roeck , "patches@apm.com" , Rob Herring , "Hans J. Koch" , Tushar Jagad , Kumar Gala , =?UTF-8?Q?Andreas_F=C3=A4rber?= Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal wrote: > On 18 November 2014 at 18:40, Arnd Bergmann wrote: >> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote: >>> On 17 November 2014 16:47, Arnd Bergmann wrote: >>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote: >>> >> + >>> >> + qmtm1_uio: qmtm_uio@1f200000 { >>> >> + compatible = "apm,xgene-qmtm"; >>> >> + status = "disabled"; >>> >> + reg = <0x0 0x1f200000 0x0 0x10000>, >>> >> + <0x0 0x1b000000 0x0 0x400000>; >>> >> + reg-names = "csr", "fabric"; >>> >> + qpool-memory = <&qmtm1_uio_qpool>; >>> >> + clocks = <&qmtm1clk 0>; >>> >> + num-queues = <0x400>; >>> >> + devid = <1>; >>> >> + }; >>> >> + >>> > >>> > To make my previous review comments clearer: >>> > >>> > NAK >>> > >>> > Do not create device nodes that are meant for a specific use case in >>> > software and that are not usable for the common case. I don't think >>> > it makes any sense to keep on submitting a UIO driver for this until >>> > we have a proper network driver that uses this so we can make sure we >>> > have a working binding. +1 >>> The dataplane frameworks like OpenDataPlane etc, need to have access >>> to complete subsystem from the user space. Hence, we would like to >>> have this driver and some other UIO drivers to be the part of kernel >>> to have data plane frameworks working on our platform. >> >> Please work with the people that do the in-kernel QMTM driver to come >> up with a common binding then. > Thanks Arnd, I have synced with them, and in future our dt bindings > for this device is going to be inline with the one mentioned in the > patchset. What does "in the future" mean? Is there already a QMTM binding? If so, you need to figure out how to either align with it or deprecate it. This patch at a minimum needs to be fixed to not refer to UIO. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: robherring2@gmail.com (Rob Herring) Date: Mon, 8 Dec 2014 11:15:39 -0600 Subject: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver In-Reply-To: References: <1416220572-13381-1-git-send-email-ankit.jindal@linaro.org> <2279061.naADrHDgyn@wuerfel> <1503477.DVdkExccIe@wuerfel> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal wrote: > On 18 November 2014 at 18:40, Arnd Bergmann wrote: >> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote: >>> On 17 November 2014 16:47, Arnd Bergmann wrote: >>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote: >>> >> + >>> >> + qmtm1_uio: qmtm_uio at 1f200000 { >>> >> + compatible = "apm,xgene-qmtm"; >>> >> + status = "disabled"; >>> >> + reg = <0x0 0x1f200000 0x0 0x10000>, >>> >> + <0x0 0x1b000000 0x0 0x400000>; >>> >> + reg-names = "csr", "fabric"; >>> >> + qpool-memory = <&qmtm1_uio_qpool>; >>> >> + clocks = <&qmtm1clk 0>; >>> >> + num-queues = <0x400>; >>> >> + devid = <1>; >>> >> + }; >>> >> + >>> > >>> > To make my previous review comments clearer: >>> > >>> > NAK >>> > >>> > Do not create device nodes that are meant for a specific use case in >>> > software and that are not usable for the common case. I don't think >>> > it makes any sense to keep on submitting a UIO driver for this until >>> > we have a proper network driver that uses this so we can make sure we >>> > have a working binding. +1 >>> The dataplane frameworks like OpenDataPlane etc, need to have access >>> to complete subsystem from the user space. Hence, we would like to >>> have this driver and some other UIO drivers to be the part of kernel >>> to have data plane frameworks working on our platform. >> >> Please work with the people that do the in-kernel QMTM driver to come >> up with a common binding then. > Thanks Arnd, I have synced with them, and in future our dt bindings > for this device is going to be inline with the one mentioned in the > patchset. What does "in the future" mean? Is there already a QMTM binding? If so, you need to figure out how to either align with it or deprecate it. This patch at a minimum needs to be fixed to not refer to UIO. Rob