Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754222AbbBZUc7 (ORCPT ); Thu, 26 Feb 2015 15:32:59 -0500 Received: from mail-bn1bon0147.outbound.protection.outlook.com ([157.56.111.147]:36736 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753747AbbBZUc5 convert rfc822-to-8bit (ORCPT ); Thu, 26 Feb 2015 15:32:57 -0500 From: Stuart Yoder To: Alexander Graf , "arnd@arndb.de" CC: Jose Rivera , "linux-kernel@vger.kernel.org" , "gregkh@linuxfoundation.org" Subject: RE: [PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus driver patch series Thread-Topic: [PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus driver patch series Thread-Index: AQHQMfGjrcNvsyPegk6kHUFBdNRjCpzUEwHAgC8raICAAGIGcA== Date: Thu, 26 Feb 2015 20:32:53 +0000 Message-ID: References: <1421456477-27041-1-git-send-email-German.Rivera@freescale.com> <54EF2EA9.8080107@suse.de> In-Reply-To: <54EF2EA9.8080107@suse.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.168.50] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stuart.yoder@freescale.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1308; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(189002)(164054003)(51704005)(13464003)(24454002)(199003)(377454003)(50986999)(77156002)(68736005)(76576001)(15975445007)(102836002)(2950100001)(33656002)(2501003)(76176999)(2900100001)(62966003)(54356999)(46102003)(92566002)(97736003)(101416001)(19580395003)(122556002)(40100003)(5890100001)(19580405001)(86362001)(106116001)(99286002)(2656002)(87936001)(105586002)(66066001)(106356001)(74316001)(64706001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0301MB1308;H:CY1PR0301MB0748.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 20:32:53.6291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB1308 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2263 Lines: 67 > -----Original Message----- > From: Alexander Graf [mailto:agraf@suse.de] > Sent: Thursday, February 26, 2015 8:33 AM > To: Yoder Stuart-B08248; arnd@arndb.de > Cc: Rivera Jose-B46482; linux-kernel@vger.kernel.org; gregkh@linuxfoundation.org > Subject: Re: [PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus driver patch series > > > > On 27.01.15 15:35, Stuart Yoder wrote: > > Hi Arnd/Alex, > > > > German has posted an example driver for the fsl-mc bus in his RFC > > "[RFC PATCH 1/1] drivers/bus: fsl-mc object allocator driver". > > > > In addition I have made available the skeleton for a driver for > > one of the objects/devices (crypto) that will be discovered on > > the bus: > > https://github.com/stuyoder/linux > > branch: fsl-ms-bus > > > > ...it is not functional yet, but shows how a driver registers with > > the bus, get's probed, performs initialization. > > Ok, so if I grasp this correctly the idea is that we have a driver > attaching to an individual device on the fsl-mc bus. Yes. > That driver then > goes and allocates / blocks more devices from that bus as it initializes. Yes, there are certain devices/objects on the bus that by themselves are not standalone, functional devices. An example is a "buffer pool". Network interface drivers, crypto driver, decompression driver, etc need one or more hardware buffer pools. There is a buffer depletion interrupt associated with the device. The buffer pools itself binds to a resource allocation driver in the kernel, which then can hand out buffer pools as required by other drivers. > Is that model always possible? Yes, why would it not be? > Which device would a NIC bind to for > example? Network interface / Ethernet driver requires some number of buffer pools, plus a management complex portal device (DPMCP) used for sending commands to manage the hardware. > I merely want to make sure we're not running ourselves into a > bad corner ;). If we are, I would like to understand it. :) Thanks, Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/