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

2017-05-22 Thread Laurentiu Tudor 


> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Monday, May 22, 2017 12:06 PM
> To: Laurentiu Tudor 
> 
> On 22/05/17 09:42, Laurentiu Tudor wrote:
> > Hi Marc,
> >
> >> -Original Message-
> >> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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:

[snip]

> >>> 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.
> 
> I think it would make a lot more sense to drop anything that is not 
> implemented
> by the current code. Once you have patches that implement this userspace
> interface, they can be reviewed together with the corresponding
> documentation.

Ok, sounds good. I'll respin the patch series. 

> >> 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].
> 
> Ah, I missed it. It would be good to mention it in the documentation as well.

Good point. I'll add a reference in the next respin.

> > [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. :-(
> 
> I understand this is not your job ;-). But maybe making people inside NXP 
> aware
> of the issue would help... Oh well.

I'll make sure your comments will reach our guys and in the meantime push to 
get the docs on github.

---
Thanks & Best Regards, Laurentiu

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

2017-05-22 Thread Laurentiu Tudor 


> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Monday, May 22, 2017 12:06 PM
> To: Laurentiu Tudor 
> 
> On 22/05/17 09:42, Laurentiu Tudor wrote:
> > Hi Marc,
> >
> >> -Original Message-
> >> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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:

[snip]

> >>> 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.
> 
> I think it would make a lot more sense to drop anything that is not 
> implemented
> by the current code. Once you have patches that implement this userspace
> interface, they can be reviewed together with the corresponding
> documentation.

Ok, sounds good. I'll respin the patch series. 

> >> 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].
> 
> Ah, I missed it. It would be good to mention it in the documentation as well.

Good point. I'll add a reference in the next respin.

> > [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. :-(
> 
> I understand this is not your job ;-). But maybe making people inside NXP 
> aware
> of the issue would help... Oh well.

I'll make sure your comments will reach our guys and in the meantime push to 
get the docs on github.

---
Thanks & Best Regards, Laurentiu

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

2017-05-22 Thread Marc Zyngier 
On 22/05/17 09:42, Laurentiu Tudor wrote:
> Hi Marc,
> 
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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=01%7C01%7Claurentiu.tudor%4
>>>
>> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
>> cd99c
>>>
>> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
>> %3D
>>> 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.

I think it would make a lot more sense to drop anything that is not
implemented by the current code. Once you have patches that implement
this userspace interface, they can be reviewed together with the
corresponding documentation.

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

Ah, I missed it. It would be good to mention it in the documentation as
well.

> [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. :-( 

I understand this is not your job ;-). But maybe making people inside
NXP aware of the issue would help... Oh well.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

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

2017-05-22 Thread Marc Zyngier 
On 22/05/17 09:42, Laurentiu Tudor wrote:
> Hi Marc,
> 
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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=01%7C01%7Claurentiu.tudor%4
>>>
>> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
>> cd99c
>>>
>> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
>> %3D
>>> 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.

I think it would make a lot more sense to drop anything that is not
implemented by the current code. Once you have patches that implement
this userspace interface, they can be reviewed together with the
corresponding documentation.

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

Ah, I missed it. It would be good to mention it in the documentation as
well.

> [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. :-( 

I understand this is not your job ;-). But maybe making people inside
NXP aware of the issue would help... Oh well.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

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

2017-05-22 Thread Laurentiu Tudor 
Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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=01%7C01%7Claurentiu.tudor%4
> >
> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
> cd99c
> >
> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
> %3D
> > 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

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

2017-05-22 Thread Laurentiu Tudor 
Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@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.zyng...@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.tu...@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=01%7C01%7Claurentiu.tudor%4
> >
> 0nxp.com%7Cd3c05908969d499cd4a008d4a0e5eaae%7C686ea1d3bc2b4c6fa92
> cd99c
> >
> 5c301635%7C0=2sEXCZ%2BAFlTtle8N3yWJPsGRve8cXMRPzyumlwqOhbg
> %3D
> > 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

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

2017-05-22 Thread Marc Zyngier 
On Mon, May 22 2017 at  7:12:39 am GMT, Laurentiu Tudor 
<laurentiu.tu...@nxp.com> wrote:

Hi Laurentiu,

> Hi Marc,
>
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Saturday, May 20, 2017 9:43 AM
>> To: Matthias Brugger <matthias@gmail.com>
>> Cc: Laurentiu Tudor <laurentiu.tu...@nxp.com>; gre...@linuxfoundation.org;
>> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
>> Ioana Radulescu <ruxandra.radule...@nxp.com>; Stuart Yoder
>> <stuart.yo...@nxp.com>; Roy Pledge <roy.ple...@nxp.com>; linux-
>> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
>> <catalin.horghi...@nxp.com>; Ioana Ciornei <ioana.cior...@nxp.com>;
>> Thomas Gleixner <t...@linutronix.de>; Leo Li <leoyang...@nxp.com>; Bharat
>> Bhushan <bharat.bhus...@nxp.com>; Jason Cooper <ja...@lakedaemon.net>;
>> linux-arm-ker...@lists.infradead.org; Rob Herring <robh...@kernel.org>
>> 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@gmail.com> wrote:
>> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
>> >> From: Stuart Yoder <stuart.yo...@nxp.com>
>> >>
>> >> 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.

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

2017-05-22 Thread Marc Zyngier 
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.zyng...@arm.com]
>> Sent: Saturday, May 20, 2017 9:43 AM
>> To: Matthias Brugger 
>> Cc: Laurentiu Tudor ; gre...@linuxfoundation.org;
>> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
>> Ioana Radulescu ; Stuart Yoder
>> ; Roy Pledge ; linux-
>> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
>> ; Ioana Ciornei ;
>> Thomas Gleixner ; Leo Li ; Bharat
>> Bhushan ; Jason Cooper ;
>> linux-arm-ker...@lists.infradead.org; Rob Herring 
>> 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
>>  wrote:
>> > On 19/05/17 15:13, laurentiu.tu...@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://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.

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

2017-05-22 Thread Laurentiu Tudor 
Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Saturday, May 20, 2017 9:43 AM
> To: Matthias Brugger <matthias@gmail.com>
> Cc: Laurentiu Tudor <laurentiu.tu...@nxp.com>; gre...@linuxfoundation.org;
> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
> Ioana Radulescu <ruxandra.radule...@nxp.com>; Stuart Yoder
> <stuart.yo...@nxp.com>; Roy Pledge <roy.ple...@nxp.com>; linux-
> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
> <catalin.horghi...@nxp.com>; Ioana Ciornei <ioana.cior...@nxp.com>;
> Thomas Gleixner <t...@linutronix.de>; Leo Li <leoyang...@nxp.com>; Bharat
> Bhushan <bharat.bhus...@nxp.com>; Jason Cooper <ja...@lakedaemon.net>;
> linux-arm-ker...@lists.infradead.org; Rob Herring <robh...@kernel.org>
> 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@gmail.com> wrote:
> > On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
> >> From: Stuart Yoder <stuart.yo...@nxp.com>
> >>
> >> 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.

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.

---
Thanks & Best Regards, Laurentiu

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

2017-05-22 Thread Laurentiu Tudor 
Hi Marc,

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Saturday, May 20, 2017 9:43 AM
> To: Matthias Brugger 
> Cc: Laurentiu Tudor ; gre...@linuxfoundation.org;
> stuyo...@gmail.com; de...@driverdev.osuosl.org; a...@arndb.de; Ruxandra
> Ioana Radulescu ; Stuart Yoder
> ; Roy Pledge ; linux-
> ker...@vger.kernel.org; ag...@suse.de; Catalin Horghidan
> ; Ioana Ciornei ;
> Thomas Gleixner ; Leo Li ; Bharat
> Bhushan ; Jason Cooper ;
> linux-arm-ker...@lists.infradead.org; Rob Herring 
> 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
>  wrote:
> > On 19/05/17 15:13, laurentiu.tu...@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://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.

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.

---
Thanks & Best Regards, Laurentiu

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

2017-05-20 Thread Marc Zyngier 
On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger  
wrote:
> On 19/05/17 15:13, laurentiu.tu...@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?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

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

2017-05-20 Thread Marc Zyngier 
On Fri, May 19 2017 at 02:41:43 PM, Matthias Brugger  
wrote:
> On 19/05/17 15:13, laurentiu.tu...@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?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

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

2017-05-19 Thread Stuart Yoder 
On Fri, May 19, 2017 at 8:41 AM, Matthias Brugger
 wrote:
>
>
> On 19/05/17 15:13, laurentiu.tu...@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.

Matthias, can you be more specific as to what your concern is?

The fsl-mc bus needs to implement bus specific gic-v3 MSI support just
like the other
bus types.  See:
   drivers/irqchip/irq-gic-v3-its-pci-msi.c
   drivers/irqchip/irq-gic-v3-its-platform-msi.c

You will see that the PCI and platform bus types also find the gic-v3 node by
compatible string.

The bus specific gic-v3 support for fsl-mc is implemented in a
completely standard way.

Thanks,
Stuart

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

2017-05-19 Thread Stuart Yoder 
On Fri, May 19, 2017 at 8:41 AM, Matthias Brugger
 wrote:
>
>
> On 19/05/17 15:13, laurentiu.tu...@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.

Matthias, can you be more specific as to what your concern is?

The fsl-mc bus needs to implement bus specific gic-v3 MSI support just
like the other
bus types.  See:
   drivers/irqchip/irq-gic-v3-its-pci-msi.c
   drivers/irqchip/irq-gic-v3-its-platform-msi.c

You will see that the PCI and platform bus types also find the gic-v3 node by
compatible string.

The bus specific gic-v3 support for fsl-mc is implemented in a
completely standard way.

Thanks,
Stuart

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

2017-05-19 Thread Matthias Brugger 



On 19/05/17 15:13, laurentiu.tu...@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.


Regards,
Matthias


   -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
   -README.txt, providing and overview of DPAA goes to
Documentation/dpaa2/overview.txt

Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
Update dpaa2_eth and dpio staging drivers.

Signed-off-by: Stuart Yoder 
Signed-off-by: Laurentiu Tudor 
[Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
---

Notes:
 -v4
   -rebased
   -update existing dpaa2 drivers to work with the bus out of staging
 -v3
   -no changes
 -v2
   -updated MAINTAINERS with new location

  .../README.txt => Documentation/dpaa2/overview.txt|  0
  MAINTAINERS   |  2 +-
  drivers/bus/Kconfig   |  2 ++
  drivers/bus/Makefile  |  3 +++
  drivers/bus/fsl-mc/Kconfig| 17 +
  drivers/bus/fsl-mc/Makefile   | 19 +++
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h |  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h|  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c|  4 ++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h|  0
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h|  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c|  6 +++---
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h |  0
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c  |  4 ++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c |  6 +++---
  .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c  |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c   |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c   |  5 +++--
  .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h|  2 +-
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-io.c|  5 +++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-sys.c   |  6 +++---
  drivers/irqchip/Makefile  |  1 +
  .../bus => irqchip}/irq-gic-v3-its-fsl-mc-msi.c   |  3 +--
  drivers/staging/fsl-dpaa2/ethernet/README |  2 +-
  drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c|  4 ++--
  drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h|  2 +-
  drivers/staging/fsl-dpaa2/ethernet/dpni.c |  4 ++--
  drivers/staging/fsl-mc/TODO   | 18 --
  drivers/staging/fsl-mc/bus/Kconfig| 10 --
  drivers/staging/fsl-mc/bus/Makefile   | 15 +--
  drivers/staging/fsl-mc/bus/dpcon.c|  8 
  drivers/staging/fsl-mc/bus/dpio/dpio-driver.c |  2 +-
  drivers/staging/fsl-mc/bus/dpio/dpio-service.c|  2 +-
  drivers/staging/fsl-mc/bus/dpio/dpio.c|  4 ++--
  .../fsl-mc/include => include/linux/fsl}/dpbp.h   |  0
  .../fsl-mc/bus => include/linux/fsl}/dpcon-cmd.h  |  0
  .../fsl-mc/include => include/linux/fsl}/dpmng.h  |  0
  .../fsl-mc/include => include/linux/fsl}/dprc.h   |  1 -
  .../fsl-mc/include => include/linux/fsl}/mc-bus.h |  2 +-
  .../fsl-mc/include => include/linux/fsl}/mc-cmd.h |  0
  .../fsl-mc/include => include/linux/fsl}/mc-sys.h |  0
  .../staging/fsl-mc/include => include/linux/fsl}/mc.h |  2 +-
  43 files changed, 90 insertions(+), 89 deletions(-)
  rename drivers/staging/fsl-mc/README.txt => Documentation/dpaa2/overview.txt 
(100%)
  create mode 100644 drivers/bus/fsl-mc/Kconfig
  create mode 100644 drivers/bus/fsl-mc/Makefile
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c (98%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c (98%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c (96%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c (99%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c (99%)
  rename

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

2017-05-19 Thread Matthias Brugger 



On 19/05/17 15:13, laurentiu.tu...@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.


Regards,
Matthias


   -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
   -README.txt, providing and overview of DPAA goes to
Documentation/dpaa2/overview.txt

Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
Update dpaa2_eth and dpio staging drivers.

Signed-off-by: Stuart Yoder 
Signed-off-by: Laurentiu Tudor 
[Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
---

Notes:
 -v4
   -rebased
   -update existing dpaa2 drivers to work with the bus out of staging
 -v3
   -no changes
 -v2
   -updated MAINTAINERS with new location

  .../README.txt => Documentation/dpaa2/overview.txt|  0
  MAINTAINERS   |  2 +-
  drivers/bus/Kconfig   |  2 ++
  drivers/bus/Makefile  |  3 +++
  drivers/bus/fsl-mc/Kconfig| 17 +
  drivers/bus/fsl-mc/Makefile   | 19 +++
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h |  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h|  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c|  4 ++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h|  0
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h|  0
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c|  6 +++---
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h |  0
  .../{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c  |  4 ++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c |  6 +++---
  .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c  |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c   |  6 +++---
  .../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c   |  5 +++--
  .../fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h|  2 +-
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-io.c|  5 +++--
  drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-sys.c   |  6 +++---
  drivers/irqchip/Makefile  |  1 +
  .../bus => irqchip}/irq-gic-v3-its-fsl-mc-msi.c   |  3 +--
  drivers/staging/fsl-dpaa2/ethernet/README |  2 +-
  drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c|  4 ++--
  drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h|  2 +-
  drivers/staging/fsl-dpaa2/ethernet/dpni.c |  4 ++--
  drivers/staging/fsl-mc/TODO   | 18 --
  drivers/staging/fsl-mc/bus/Kconfig| 10 --
  drivers/staging/fsl-mc/bus/Makefile   | 15 +--
  drivers/staging/fsl-mc/bus/dpcon.c|  8 
  drivers/staging/fsl-mc/bus/dpio/dpio-driver.c |  2 +-
  drivers/staging/fsl-mc/bus/dpio/dpio-service.c|  2 +-
  drivers/staging/fsl-mc/bus/dpio/dpio.c|  4 ++--
  .../fsl-mc/include => include/linux/fsl}/dpbp.h   |  0
  .../fsl-mc/bus => include/linux/fsl}/dpcon-cmd.h  |  0
  .../fsl-mc/include => include/linux/fsl}/dpmng.h  |  0
  .../fsl-mc/include => include/linux/fsl}/dprc.h   |  1 -
  .../fsl-mc/include => include/linux/fsl}/mc-bus.h |  2 +-
  .../fsl-mc/include => include/linux/fsl}/mc-cmd.h |  0
  .../fsl-mc/include => include/linux/fsl}/mc-sys.h |  0
  .../staging/fsl-mc/include => include/linux/fsl}/mc.h |  2 +-
  43 files changed, 90 insertions(+), 89 deletions(-)
  rename drivers/staging/fsl-mc/README.txt => Documentation/dpaa2/overview.txt 
(100%)
  create mode 100644 drivers/bus/fsl-mc/Kconfig
  create mode 100644 drivers/bus/fsl-mc/Makefile
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c (98%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c (98%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c (96%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h (100%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c (99%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c (99%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c (99%)
  rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c (99%)
  rename