Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging

[Marc Zyngier]

On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor <laurentiu.tudor@xxxxxxx> wrote:

Hi Laurentiu,

> Hi Marc,
>
>> -----Original Message-----
>> From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx]
>> Sent: Saturday, May 20, 2017 9:43 AM
>> To: Matthias Brugger <matthias.bgg@xxxxxxxxx>
>> Cc: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx;
>> stuyoder@xxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx; arnd@xxxxxxxx; Ruxandra
>> Ioana Radulescu <ruxandra.radulescu@xxxxxxx>; Stuart Yoder
>> <stuart.yoder@xxxxxxx>; Roy Pledge <roy.pledge@xxxxxxx>; linux-
>> kernel@xxxxxxxxxxxxxxx; agraf@xxxxxxx; Catalin Horghidan
>> <catalin.horghidan@xxxxxxx>; Ioana Ciornei <ioana.ciornei@xxxxxxx>;
>> Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Leo Li <leoyang.li@xxxxxxx>; Bharat
>> Bhushan <bharat.bhushan@xxxxxxx>; Jason Cooper <jason@xxxxxxxxxxxxxx>;
>> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Rob Herring <robh+dt@xxxxxxxxxx>
>> Subject: Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging
>> Importance: High
>> 
>> On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger
>> <matthias.bgg@xxxxxxxxx> wrote:
>> > On 19/05/17 15:13, laurentiu.tudor@xxxxxxx wrote:
>> >> From: Stuart Yoder <stuart.yoder@xxxxxxx>
>> >>
>> >> 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://github.com/qoriq-open-source/restool
>
> 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. 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.

>
> The reference manual documenting the ABI can be found here
> (registration required):
>
> https://freescale.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-53BEBDD8-1A5E-4DD0-8354-A9647AD35755
>
> Click on the DPAA2 user manual link.
>
> 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...

Thanks,

	M.
-- 
Jazz is not dead, it just smell funny.