linux-kernel - Re: [PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus driver patch series

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2015 22:38:07 +0100
From:	Alexander Graf <agraf@...e.de>
To:	Stuart Yoder <stuart.yoder@...escale.com>,
	"arnd@...db.de" <arnd@...db.de>
CC:	Jose Rivera <German.Rivera@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 0/3 v6] drivers/bus: Freescale Management Complex bus
 driver patch series



On 26.02.15 21:32, Stuart Yoder wrote:
> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@...e.de]
>> Sent: Thursday, February 26, 2015 8:33 AM
>> To: Yoder Stuart-B08248; arnd@...db.de
>> Cc: Rivera Jose-B46482; linux-kernel@...r.kernel.org; gregkh@...uxfoundation.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.

Ok, so there are 2 things on the bus

  * devices
  * resources

Someone really needs to sit down and write some nice ASCII art about all
of this and include all the abbreviations in it as well, so that  anyone
not deeply involved in the architecture has the chance to grasp what
this is about.

>> 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.

Ok, so there is always one object that basically "owns" a particular
device. And then there is a cloud of resources that drivers grab as they go.

I think I got it by now and the concept makes a lot of sense. I'm not
sure whether there's any particular benefit or downside of having
resources be devices, but looking at the resource manager code it
probably doesn't hurt.


Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/