From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757401AbdEVInD (ORCPT ); Mon, 22 May 2017 04:43:03 -0400 Received: from mail-he1eur01on0067.outbound.protection.outlook.com ([104.47.0.67]:11675 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757381AbdEVInA (ORCPT ); Mon, 22 May 2017 04:43:00 -0400 From: Laurentiu Tudor To: Marc Zyngier CC: Matthias Brugger , "gregkh@linuxfoundation.org" , "stuyoder@gmail.com" , "devel@driverdev.osuosl.org" , "arnd@arndb.de" , Ruxandra Ioana Radulescu , "Roy Pledge" , "linux-kernel@vger.kernel.org" , "agraf@suse.de" , "Catalin Horghidan" , Ioana Ciornei , Thomas Gleixner , Leo Li , "Bharat Bhushan" , Jason Cooper , "linux-arm-kernel@lists.infradead.org" , Rob Herring Subject: RE: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging Thread-Topic: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging Thread-Index: AQHS0KHBEOWIF8ox+0mrH5YUYvPKY6H7qgmAgAEdnR6AAyv9EIAACKwEgAAOxyA= Date: Mon, 22 May 2017 08:42:54 +0000 Message-ID: References: <20170519131305.5068-1-laurentiu.tudor@nxp.com> <20170519131305.5068-4-laurentiu.tudor@nxp.com> <86tw4g6nb0.fsf@arm.com> <878tlpmj9l.fsf@arm.com> In-Reply-To: <878tlpmj9l.fsf@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [192.88.146.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0401MB1727;7:Mz20hCelqA4vmwWjM2tkBdzbed1cx5NHWT4MiKiHH5JNWEnsr+LxjOcjttF2b98UjqQzpBEBsXUUBij/bBeMw1oJtdlUzA5/uM++R22K0l0QV7JP7LD36inf/1lVtjkiddv7pbj2ATLtL+y0mnXfyu/8Yfdj49WDudztGjO8LyB3uiNJKi/G1PKr1u0AtOq7L9abVjKi8WLhxdwFPxJiHZZ5+4xujV6tkLNMtptvgryprtxh0Aq/JSjmzIg6AvkQ/mFU+JRvN3AH/ajVPtoAPPA0RFLdPYaGRZzmgJgc7aTupj/e+nN1KgWMJwLlZ7ZosXpmmHlla4E/nTl8saGbKA== x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(39450400003)(13464003)(54094003)(377454003)(24454002)(54356999)(50986999)(76176999)(122556002)(93886004)(5660300001)(74316002)(45080400002)(229853002)(2906002)(7416002)(3660700001)(966005)(39060400002)(2900100001)(3280700002)(66066001)(53936002)(6306002)(54906002)(9686003)(7696004)(305945005)(6436002)(77096006)(53546009)(6246003)(8936002)(2950100002)(6916009)(189998001)(55016002)(478600001)(575784001)(4326008)(102836003)(86362001)(3846002)(33656002)(25786009)(6116002)(38730400002)(110136004)(99286003)(81166006)(7736002)(6506006)(8676002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB1727;H:VI1PR0401MB1856.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-traffictypediagnostic: VI1PR0401MB1727: x-ms-office365-filtering-correlation-id: 9c1d1854-3066-4688-ce33-08d4a0ee8a49 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:VI1PR0401MB1727; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(189930954265078)(185117386973197)(84791874153150)(45079756050767); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148);SRVR:VI1PR0401MB1727;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB1727; x-forefront-prvs: 03152A99FF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 08:42:54.7273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB1727 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v4M8hZQI019710 Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:marc.zyngier@arm.com] > Sent: Monday, May 22, 2017 10:41 AM > > On Mon, May 22 2017 at 7:12:39 am GMT, Laurentiu Tudor > wrote: > > Hi Laurentiu, > > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Zyngier [mailto:marc.zyngier@arm.com] > >> Sent: Saturday, May 20, 2017 9:43 AM > >> To: Matthias Brugger > >> > >> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger > >> wrote: > >> > On 19/05/17 15:13, laurentiu.tudor@nxp.com wrote: > >> >> From: Stuart Yoder > >> >> > >> >> Move the source files out of staging into their final locations: > >> >> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl > >> >> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip > >> > > >> > This driver has as compatible "arm,gic-v3-its". I wonder if this is > >> > correct and if it should be moved like this out of staging. > >> > >> This is no different from the way we handle *any* bus that uses the > >> GICv3 ITS as an MSI controller. Each bus provides its glue code that > >> latches onto the ITS node, and calls into the generic code. > >> > >> Now, when it comes to moving this out of staging, here is my concern: > >> There is mention of a userspace tool (restool) used to control the > >> HW. Where is this tool? Where is the user ABI documented? > > > > The tool is published here: > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fqoriq-open- > source%2Frestool&data=01%7C01%7Claurentiu.tudor%4 > > > 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92 > cd99c > > > 5c301635%7C0&sdata=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg > %3D&re > > served=0 > > > > There are two ways of configuring the mc-bus: > > - a static one, through a FDT based configuration file (we call it > > DPL), documented in the refman linked below, chapter 22. > > - a dynamic one, using this restool utility. > > Please note the usage of restool is optional. > > Optional or not, it still is a userspace ABI, and while I can see restool issuing ioctl > system calls to configure the HW, I cannot see the corresponding code in the > kernel tree. So how does it work? > If the syscall interface is not present in the mainline kernel, drop the reference > to it in the documentation. If it is there (and I obviously missed it), document it, > and get it reviewed. Our original plan was to first get the bus out of staging and after that submit the restool support ASAP (patches are done - so I'm thinking at few days timeframe). if this is not acceptable, I can drop the restool reference from the README and resubmit the patch series. We'll re-add the reference together with the restool support patches. > If there are associated DT bindings to the kernel code, they > must be documented (and reviewed) as part of the device-tree documentation, > and not in some obscure, hard to access document. There's only one binding involved and it's already accepted [1]. [snip] > > > > We're also working on publishing the docs on github so that they're > > more accessible. > > That'd be great, because the way the registration process is presented, I'd have > to agree to the Access Agreement *before* having a chance to read it. Not > going to happen... Sorry about that. Not much I can do. :-( [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt --- Best Regards, Laurentiu From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurentiu.tudor@nxp.com (Laurentiu Tudor) Date: Mon, 22 May 2017 08:42:54 +0000 Subject: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging In-Reply-To: <878tlpmj9l.fsf@arm.com> References: <20170519131305.5068-1-laurentiu.tudor@nxp.com> <20170519131305.5068-4-laurentiu.tudor@nxp.com> <86tw4g6nb0.fsf@arm.com> <878tlpmj9l.fsf@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:marc.zyngier at arm.com] > Sent: Monday, May 22, 2017 10:41 AM > > On Mon, May 22 2017 at 7:12:39 am GMT, Laurentiu Tudor > wrote: > > Hi Laurentiu, > > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Zyngier [mailto:marc.zyngier at arm.com] > >> Sent: Saturday, May 20, 2017 9:43 AM > >> To: Matthias Brugger > >> > >> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger > >> wrote: > >> > On 19/05/17 15:13, laurentiu.tudor at nxp.com wrote: > >> >> From: Stuart Yoder > >> >> > >> >> Move the source files out of staging into their final locations: > >> >> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl > >> >> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip > >> > > >> > This driver has as compatible "arm,gic-v3-its". I wonder if this is > >> > correct and if it should be moved like this out of staging. > >> > >> This is no different from the way we handle *any* bus that uses the > >> GICv3 ITS as an MSI controller. Each bus provides its glue code that > >> latches onto the ITS node, and calls into the generic code. > >> > >> Now, when it comes to moving this out of staging, here is my concern: > >> There is mention of a userspace tool (restool) used to control the > >> HW. Where is this tool? Where is the user ABI documented? > > > > The tool is published here: > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fqoriq-open- > source%2Frestool&data=01%7C01%7Claurentiu.tudor%4 > > > 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92 > cd99c > > > 5c301635%7C0&sdata=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg > %3D&re > > served=0 > > > > There are two ways of configuring the mc-bus: > > - a static one, through a FDT based configuration file (we call it > > DPL), documented in the refman linked below, chapter 22. > > - a dynamic one, using this restool utility. > > Please note the usage of restool is optional. > > Optional or not, it still is a userspace ABI, and while I can see restool issuing ioctl > system calls to configure the HW, I cannot see the corresponding code in the > kernel tree. So how does it work? > If the syscall interface is not present in the mainline kernel, drop the reference > to it in the documentation. If it is there (and I obviously missed it), document it, > and get it reviewed. Our original plan was to first get the bus out of staging and after that submit the restool support ASAP (patches are done - so I'm thinking at few days timeframe). if this is not acceptable, I can drop the restool reference from the README and resubmit the patch series. We'll re-add the reference together with the restool support patches. > If there are associated DT bindings to the kernel code, they > must be documented (and reviewed) as part of the device-tree documentation, > and not in some obscure, hard to access document. There's only one binding involved and it's already accepted [1]. [snip] > > > > We're also working on publishing the docs on github so that they're > > more accessible. > > That'd be great, because the way the registration process is presented, I'd have > to agree to the Access Agreement *before* having a chance to read it. Not > going to happen... Sorry about that. Not much I can do. :-( [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt --- Best Regards, Laurentiu