Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 06:49 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename 
>> patch
>> here. I'll post the rest of EP series before the next merge 
>> window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW 
> after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the 
 PCI Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit 
>>> long
>>> and while I suppose it technically does include the concept of the 
>>> PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first 
>>> place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 
>> Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use 
>> mass_storage and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci 
>> and the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the 
> specific vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root 
 complex and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also 
>>> common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>>   

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 06:49 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename 
>> patch
>> here. I'll post the rest of EP series before the next merge 
>> window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW 
> after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the 
 PCI Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit 
>>> long
>>> and while I suppose it technically does include the concept of the 
>>> PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first 
>>> place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 
>> Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use 
>> mass_storage and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci 
>> and the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the 
> specific vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root 
 complex and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also 
>>> common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>>   

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hi,

Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
 Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
 wrote:
> As discussed during our LPC discussions, I'm posting the rename 
> patch
> here. I'll post the rest of EP series before the next merge 
> window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the 
>>> PCI Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the 
>> PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 
> Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve 
>>> identifying all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use 
> mass_storage and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and 
> the host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific 
> vendor drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN 
> controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
> endpoint ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root 
>>> complex and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also 
>> common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hi,

Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
 Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
 wrote:
> As discussed during our LPC discussions, I'm posting the rename 
> patch
> here. I'll post the rest of EP series before the next merge 
> window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the 
>>> PCI Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the 
>> PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 
> Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve 
>>> identifying all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use 
> mass_storage and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and 
> the host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific 
> vendor drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN 
> controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
> endpoint ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root 
>>> complex and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also 
>> common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
 Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
 wrote:
> As discussed during our LPC discussions, I'm posting the rename 
> patch
> here. I'll post the rest of EP series before the next merge 
> window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the 
>>> PCI Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the 
>> PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 
> Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve 
>>> identifying all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use 
> mass_storage and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and 
> the host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific 
> vendor drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN 
> controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
> endpoint ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root 
>>> complex and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also 
>> common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 12:20 PM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
>> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
 Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
 wrote:
> As discussed during our LPC discussions, I'm posting the rename 
> patch
> here. I'll post the rest of EP series before the next merge 
> window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the 
>>> PCI Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the 
>> PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 
> Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve 
>>> identifying all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use 
> mass_storage and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and 
> the host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific 
> vendor drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN 
> controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
> endpoint ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root 
>>> complex and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also 
>> common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
>>> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>
> Hi,
>
> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
 Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
>>> wrote:
 As discussed during our LPC discussions, I'm posting the rename 
 patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
>
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
>>
>> right.
>
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
>
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
>

 The usb/host contains the implemnentations by the spec of the several
 *hci (USB Host) and then you can have for example the USB 3.0 
 Designware
 Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>
>> right, each IP have a separate directory in USB. I thought of doing 
>> something
>> similar for PCI but decided against it since that would involve 
>> identifying all
>> the PCI IPs used and eventually result in more directories.
 For device purposes it uses the core/ and then some of the device 
 functions
 are extended from the gadget/ package in which you can use 
 mass_storage and
 other types of functions.
>>
>> That would be similar for PCI endpoint. All endpoint specific core
>> functionality will be added in drivers/pci/endpoint (see RFC [1]).

 In our case in PCI we have the core functions inside /drivers/pci and 
 the host
 mangled inside host. I suggest:

 drivers/pci
  drivers/pci/core/
  drivers/pci/core/hotplug
  drivers/pci/core/pcie
  drivers/pci/core/
  drivers/pci/host
  drivers/pci/dwc -> here would be pcie-designware and the specific 
 vendor drivers
>>>
>>> Correction:
>>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>>> vendor
>>> drivers
>>>
  drivers/pci/ -> here would be the drivers for vendorN 
 controller
>>>
>>> Correction:
>>> drivers/pci/host/ -> here would be the drivers for vendorN 
>>> controller
>>>
  drivers/pci/endpoint -> common code
  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
 endpoint ops
  drivers/pci/ -> implementation of other vendors specific 
 endpoint ops
>>
>> There are some parts of the dwc driver that is common to both root 
>> complex and
>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>> common
>> piece in both root complex and endpoint.
>
> You are right, the config space is almost the same and some ops also 
> common.
> I would suggest:
>
> drivers/pci
>   drivers/pci/core/
> drivers/pci/core/hotplug
> drivers/pci/core/pcie
> drivers/pci/core/
>   drivers/pci/dwc
> drivers/pci/dwc/common.c -> common ops and registers between RC and 
> endpoint
> drivers/pci/dwc/host/
> drivers/pci/dwc/endpoint/
>
> What do you think?

 I don't think we should have sub-directories within dwc (USB too doesn't 
 have
 sub-directories). Where should the 

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 05:38 PM, Joao Pinto wrote:
> Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
>>> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>
> Hi,
>
> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
 Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
>>> wrote:
 As discussed during our LPC discussions, I'm posting the rename 
 patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
>
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
>>
>> right.
>
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
>
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
>

 The usb/host contains the implemnentations by the spec of the several
 *hci (USB Host) and then you can have for example the USB 3.0 
 Designware
 Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>
>> right, each IP have a separate directory in USB. I thought of doing 
>> something
>> similar for PCI but decided against it since that would involve 
>> identifying all
>> the PCI IPs used and eventually result in more directories.
 For device purposes it uses the core/ and then some of the device 
 functions
 are extended from the gadget/ package in which you can use 
 mass_storage and
 other types of functions.
>>
>> That would be similar for PCI endpoint. All endpoint specific core
>> functionality will be added in drivers/pci/endpoint (see RFC [1]).

 In our case in PCI we have the core functions inside /drivers/pci and 
 the host
 mangled inside host. I suggest:

 drivers/pci
  drivers/pci/core/
  drivers/pci/core/hotplug
  drivers/pci/core/pcie
  drivers/pci/core/
  drivers/pci/host
  drivers/pci/dwc -> here would be pcie-designware and the specific 
 vendor drivers
>>>
>>> Correction:
>>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>>> vendor
>>> drivers
>>>
  drivers/pci/ -> here would be the drivers for vendorN 
 controller
>>>
>>> Correction:
>>> drivers/pci/host/ -> here would be the drivers for vendorN 
>>> controller
>>>
  drivers/pci/endpoint -> common code
  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
 endpoint ops
  drivers/pci/ -> implementation of other vendors specific 
 endpoint ops
>>
>> There are some parts of the dwc driver that is common to both root 
>> complex and
>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>> common
>> piece in both root complex and endpoint.
>
> You are right, the config space is almost the same and some ops also 
> common.
> I would suggest:
>
> drivers/pci
>   drivers/pci/core/
> drivers/pci/core/hotplug
> drivers/pci/core/pcie
> drivers/pci/core/
>   drivers/pci/dwc
> drivers/pci/dwc/common.c -> common ops and registers between RC and 
> endpoint
> drivers/pci/dwc/host/
> drivers/pci/dwc/endpoint/
>
> What do you think?

 I don't think we should have sub-directories within dwc (USB too doesn't 
 have
 sub-directories). Where should the 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
>> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:

 Hi,

 Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
 On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
>> wrote:
>>> As discussed during our LPC discussions, I'm posting the rename 
>>> patch
>>> here. I'll post the rest of EP series before the next merge window.
>>>
>>> There might be hiccups because of this renaming but feel this is
>>> necessary for long-term maintenance.
>>
>> if we do this rename it would be great to get it to Linus NOW after
>> -rc1 as that minimizes the impact on the 4.11 merge window.
>
> Rename it to controller is a bit vague I thing since we have the PCI 
> Endpoint IP
> also. Wouldn't be better to name it rc_controller?

 I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
 neutral name that can cover both RC and Endpoint.
>
> right.

 I'm not a huge fan of "controller" because it feels a little bit long
 and while I suppose it technically does include the concept of the PCI
 interface of an endpoint, it still suggests more of the host side to
 me.

 Doesn't USB have a similar situation?  I see there's a
 drivers/usb/host/ (probably where we copied from in the first place).
 Is a USB gadget the USB analog of what you're doing?  How do they
 share code between the master/slave sides?

>>>
>>> The usb/host contains the implemnentations by the spec of the several
>>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>
> right, each IP have a separate directory in USB. I thought of doing 
> something
> similar for PCI but decided against it since that would involve 
> identifying all
> the PCI IPs used and eventually result in more directories.
>>> For device purposes it uses the core/ and then some of the device 
>>> functions
>>> are extended from the gadget/ package in which you can use mass_storage 
>>> and
>>> other types of functions.
>
> That would be similar for PCI endpoint. All endpoint specific core
> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>>
>>> In our case in PCI we have the core functions inside /drivers/pci and 
>>> the host
>>> mangled inside host. I suggest:
>>>
>>> drivers/pci
>>>  drivers/pci/core/
>>>  drivers/pci/core/hotplug
>>>  drivers/pci/core/pcie
>>>  drivers/pci/core/
>>>  drivers/pci/host
>>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>>> vendor drivers
>>
>> Correction:
>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>> vendor
>> drivers
>>
>>>  drivers/pci/ -> here would be the drivers for vendorN 
>>> controller
>>
>> Correction:
>> drivers/pci/host/ -> here would be the drivers for vendorN 
>> controller
>>
>>>  drivers/pci/endpoint -> common code
>>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>>> endpoint ops
>>>  drivers/pci/ -> implementation of other vendors specific 
>>> endpoint ops
>
> There are some parts of the dwc driver that is common to both root 
> complex and
> endpoint. Where should that be? I'm sure no one wants to duplicate the 
> common
> piece in both root complex and endpoint.

 You are right, the config space is almost the same and some ops also 
 common.
 I would suggest:

 drivers/pci
   drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
   drivers/pci/dwc
 drivers/pci/dwc/common.c -> common ops and registers between RC and 
 endpoint
 drivers/pci/dwc/host/
 drivers/pci/dwc/endpoint/

 What do you think?
>>>
>>> I don't think we should have sub-directories within dwc (USB too doesn't 
>>> have
>>> sub-directories). Where should the platform specific driver be kept? For
>>> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but 
>>> the
>>> changes are so minimal that splitting the file won't make much sense.

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 11:58 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
>> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:

 Hi,

 Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
 On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
>> wrote:
>>> As discussed during our LPC discussions, I'm posting the rename 
>>> patch
>>> here. I'll post the rest of EP series before the next merge window.
>>>
>>> There might be hiccups because of this renaming but feel this is
>>> necessary for long-term maintenance.
>>
>> if we do this rename it would be great to get it to Linus NOW after
>> -rc1 as that minimizes the impact on the 4.11 merge window.
>
> Rename it to controller is a bit vague I thing since we have the PCI 
> Endpoint IP
> also. Wouldn't be better to name it rc_controller?

 I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
 neutral name that can cover both RC and Endpoint.
>
> right.

 I'm not a huge fan of "controller" because it feels a little bit long
 and while I suppose it technically does include the concept of the PCI
 interface of an endpoint, it still suggests more of the host side to
 me.

 Doesn't USB have a similar situation?  I see there's a
 drivers/usb/host/ (probably where we copied from in the first place).
 Is a USB gadget the USB analog of what you're doing?  How do they
 share code between the master/slave sides?

>>>
>>> The usb/host contains the implemnentations by the spec of the several
>>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>
> right, each IP have a separate directory in USB. I thought of doing 
> something
> similar for PCI but decided against it since that would involve 
> identifying all
> the PCI IPs used and eventually result in more directories.
>>> For device purposes it uses the core/ and then some of the device 
>>> functions
>>> are extended from the gadget/ package in which you can use mass_storage 
>>> and
>>> other types of functions.
>
> That would be similar for PCI endpoint. All endpoint specific core
> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>>
>>> In our case in PCI we have the core functions inside /drivers/pci and 
>>> the host
>>> mangled inside host. I suggest:
>>>
>>> drivers/pci
>>>  drivers/pci/core/
>>>  drivers/pci/core/hotplug
>>>  drivers/pci/core/pcie
>>>  drivers/pci/core/
>>>  drivers/pci/host
>>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>>> vendor drivers
>>
>> Correction:
>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>> vendor
>> drivers
>>
>>>  drivers/pci/ -> here would be the drivers for vendorN 
>>> controller
>>
>> Correction:
>> drivers/pci/host/ -> here would be the drivers for vendorN 
>> controller
>>
>>>  drivers/pci/endpoint -> common code
>>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>>> endpoint ops
>>>  drivers/pci/ -> implementation of other vendors specific 
>>> endpoint ops
>
> There are some parts of the dwc driver that is common to both root 
> complex and
> endpoint. Where should that be? I'm sure no one wants to duplicate the 
> common
> piece in both root complex and endpoint.

 You are right, the config space is almost the same and some ops also 
 common.
 I would suggest:

 drivers/pci
   drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
   drivers/pci/dwc
 drivers/pci/dwc/common.c -> common ops and registers between RC and 
 endpoint
 drivers/pci/dwc/host/
 drivers/pci/dwc/endpoint/

 What do you think?
>>>
>>> I don't think we should have sub-directories within dwc (USB too doesn't 
>>> have
>>> sub-directories). Where should the platform specific driver be kept? For
>>> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but 
>>> the
>>> changes are so minimal that splitting the file won't make much sense.

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
 Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
 As discussed during our LPC discussions, I'm posting the rename patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
>
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
>>
>> right.
>
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
>
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
>

 The usb/host contains the implemnentations by the spec of the several
 *hci (USB Host) and then you can have for example the USB 3.0 Designware
 Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>
>> right, each IP have a separate directory in USB. I thought of doing something
>> similar for PCI but decided against it since that would involve identifying 
>> all
>> the PCI IPs used and eventually result in more directories.
 For device purposes it uses the core/ and then some of the device functions
 are extended from the gadget/ package in which you can use mass_storage and
 other types of functions.
>>
>> That would be similar for PCI endpoint. All endpoint specific core
>> functionality will be added in drivers/pci/endpoint (see RFC [1]).

 In our case in PCI we have the core functions inside /drivers/pci and the 
 host
 mangled inside host. I suggest:

 drivers/pci
  drivers/pci/core/
  drivers/pci/core/hotplug
  drivers/pci/core/pcie
  drivers/pci/core/
  drivers/pci/host
  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
 drivers
>>>
>>> Correction:
>>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>>> vendor
>>> drivers
>>>
  drivers/pci/ -> here would be the drivers for vendorN controller
>>>
>>> Correction:
>>> drivers/pci/host/ -> here would be the drivers for vendorN 
>>> controller
>>>
  drivers/pci/endpoint -> common code
  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
 ops
  drivers/pci/ -> implementation of other vendors specific 
 endpoint ops
>>
>> There are some parts of the dwc driver that is common to both root complex 
>> and
>> endpoint. Where should that be? I'm sure no one wants to duplicate the common
>> piece in both root complex and endpoint.
> 
> You are right, the config space is almost the same and some ops also common.
> I would suggest:
> 
> drivers/pci
>   drivers/pci/core/
> drivers/pci/core/hotplug
> drivers/pci/core/pcie
> drivers/pci/core/
>   drivers/pci/dwc
> drivers/pci/dwc/common.c -> common ops and registers between RC and 
> endpoint
> drivers/pci/dwc/host/
> drivers/pci/dwc/endpoint/
> 
> What do you think?

I don't think we should have sub-directories within dwc (USB too doesn't have
sub-directories). Where should the platform specific driver be kept? For
example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but the
changes are so minimal that splitting the file won't make much sense.

And such a change would also mean we create a separate directory for every
other driver present right now in pci/host.

Thanks
Kishon

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
> 
> Hi,
> 
> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
 Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
 As discussed during our LPC discussions, I'm posting the rename patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
>
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
>>
>> right.
>
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
>
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
>

 The usb/host contains the implemnentations by the spec of the several
 *hci (USB Host) and then you can have for example the USB 3.0 Designware
 Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>
>> right, each IP have a separate directory in USB. I thought of doing something
>> similar for PCI but decided against it since that would involve identifying 
>> all
>> the PCI IPs used and eventually result in more directories.
 For device purposes it uses the core/ and then some of the device functions
 are extended from the gadget/ package in which you can use mass_storage and
 other types of functions.
>>
>> That would be similar for PCI endpoint. All endpoint specific core
>> functionality will be added in drivers/pci/endpoint (see RFC [1]).

 In our case in PCI we have the core functions inside /drivers/pci and the 
 host
 mangled inside host. I suggest:

 drivers/pci
  drivers/pci/core/
  drivers/pci/core/hotplug
  drivers/pci/core/pcie
  drivers/pci/core/
  drivers/pci/host
  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
 drivers
>>>
>>> Correction:
>>> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
>>> vendor
>>> drivers
>>>
  drivers/pci/ -> here would be the drivers for vendorN controller
>>>
>>> Correction:
>>> drivers/pci/host/ -> here would be the drivers for vendorN 
>>> controller
>>>
  drivers/pci/endpoint -> common code
  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
 ops
  drivers/pci/ -> implementation of other vendors specific 
 endpoint ops
>>
>> There are some parts of the dwc driver that is common to both root complex 
>> and
>> endpoint. Where should that be? I'm sure no one wants to duplicate the common
>> piece in both root complex and endpoint.
> 
> You are right, the config space is almost the same and some ops also common.
> I would suggest:
> 
> drivers/pci
>   drivers/pci/core/
> drivers/pci/core/hotplug
> drivers/pci/core/pcie
> drivers/pci/core/
>   drivers/pci/dwc
> drivers/pci/dwc/common.c -> common ops and registers between RC and 
> endpoint
> drivers/pci/dwc/host/
> drivers/pci/dwc/endpoint/
> 
> What do you think?

I don't think we should have sub-directories within dwc (USB too doesn't have
sub-directories). Where should the platform specific driver be kept? For
example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but the
changes are so minimal that splitting the file won't make much sense.

And such a change would also mean we create a separate directory for every
other driver present right now in pci/host.

Thanks
Kishon

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the PCI 
 Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit long
>>> and while I suppose it technically does include the concept of the PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use mass_storage 
>> and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci and 
>> the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
> vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root complex 
 and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>> drivers/pci/core/hotplug
>>> drivers/pci/core/pcie
>>> drivers/pci/core/
>>>   drivers/pci/dwc
>>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>>> endpoint
>>> drivers/pci/dwc/host/
>>> drivers/pci/dwc/endpoint/
>>>
>>> What do you think?
>>
>> I don't think we should have sub-directories within dwc (USB too doesn't have
>> sub-directories). Where should the platform specific driver be kept? For
>> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but 
>> the
>> changes are so minimal that splitting the file won't make much sense.
>>
>> And such a change would also mean we create a separate directory for every
>> other driver present right now in pci/host.
> 
> I understand you idea. We can simplify it this way:
> 
>  drivers/pci
>

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 December 2016 05:23 PM, Joao Pinto wrote:
> Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>> Hi,
>>
>> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>>
>>> Hi,
>>>
>>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
 Hi,

 On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I 
> wrote:
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the PCI 
 Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

 right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit long
>>> and while I suppose it technically does include the concept of the PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

 right, each IP have a separate directory in USB. I thought of doing 
 something
 similar for PCI but decided against it since that would involve 
 identifying all
 the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device 
>> functions
>> are extended from the gadget/ package in which you can use mass_storage 
>> and
>> other types of functions.

 That would be similar for PCI endpoint. All endpoint specific core
 functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci and 
>> the host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific 
>> vendor drivers
>
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the specific 
> vendor
> drivers
>
>>  drivers/pci/ -> here would be the drivers for vendorN 
>> controller
>
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN 
> controller
>
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific 
>> endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific 
>> endpoint ops

 There are some parts of the dwc driver that is common to both root complex 
 and
 endpoint. Where should that be? I'm sure no one wants to duplicate the 
 common
 piece in both root complex and endpoint.
>>>
>>> You are right, the config space is almost the same and some ops also common.
>>> I would suggest:
>>>
>>> drivers/pci
>>>   drivers/pci/core/
>>> drivers/pci/core/hotplug
>>> drivers/pci/core/pcie
>>> drivers/pci/core/
>>>   drivers/pci/dwc
>>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>>> endpoint
>>> drivers/pci/dwc/host/
>>> drivers/pci/dwc/endpoint/
>>>
>>> What do you think?
>>
>> I don't think we should have sub-directories within dwc (USB too doesn't have
>> sub-directories). Where should the platform specific driver be kept? For
>> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but 
>> the
>> changes are so minimal that splitting the file won't make much sense.
>>
>> And such a change would also mean we create a separate directory for every
>> other driver present right now in pci/host.
> 
> I understand you idea. We can simplify it this way:
> 
>  drivers/pci
>

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the PCI 
>>> Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve identifying 
>>> all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use mass_storage 
> and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and the 
> host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
> drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
> ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root complex 
>>> and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> drivers/pci/dwc/host/
>> drivers/pci/dwc/endpoint/
>>
>> What do you think?
> 
> I don't think we should have sub-directories within dwc (USB too doesn't have
> sub-directories). Where should the platform specific driver be kept? For
> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but the
> changes are so minimal that splitting the file won't make much sense.
> 
> And such a change would also mean we create a separate directory for every
> other driver present right now in pci/host.

I understand you idea. We can simplify it this way:

 drivers/pci
   drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
 drivers/pci/dwc -> Common files (RC and EP), specific vendor drivers for EP
and EP

BTW dwc states for DesigWare 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 11:48 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Thursday 29 December 2016 04:08 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
>>> Hi,
>>>
>>> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
 Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the PCI 
>>> Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>>
>>> right.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
>
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
>>>
>>> right, each IP have a separate directory in USB. I thought of doing 
>>> something
>>> similar for PCI but decided against it since that would involve identifying 
>>> all
>>> the PCI IPs used and eventually result in more directories.
> For device purposes it uses the core/ and then some of the device 
> functions
> are extended from the gadget/ package in which you can use mass_storage 
> and
> other types of functions.
>>>
>>> That would be similar for PCI endpoint. All endpoint specific core
>>> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>
> In our case in PCI we have the core functions inside /drivers/pci and the 
> host
> mangled inside host. I suggest:
>
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
> drivers

 Correction:
 drivers/pci/host/dwc -> here would be pcie-designware and the specific 
 vendor
 drivers

>  drivers/pci/ -> here would be the drivers for vendorN controller

 Correction:
 drivers/pci/host/ -> here would be the drivers for vendorN 
 controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
> ops
>  drivers/pci/ -> implementation of other vendors specific 
> endpoint ops
>>>
>>> There are some parts of the dwc driver that is common to both root complex 
>>> and
>>> endpoint. Where should that be? I'm sure no one wants to duplicate the 
>>> common
>>> piece in both root complex and endpoint.
>>
>> You are right, the config space is almost the same and some ops also common.
>> I would suggest:
>>
>> drivers/pci
>>   drivers/pci/core/
>> drivers/pci/core/hotplug
>> drivers/pci/core/pcie
>> drivers/pci/core/
>>   drivers/pci/dwc
>> drivers/pci/dwc/common.c -> common ops and registers between RC and 
>> endpoint
>> drivers/pci/dwc/host/
>> drivers/pci/dwc/endpoint/
>>
>> What do you think?
> 
> I don't think we should have sub-directories within dwc (USB too doesn't have
> sub-directories). Where should the platform specific driver be kept? For
> example pci-dra7xx.c (which use dwc) has both rc and ep specific parts but the
> changes are so minimal that splitting the file won't make much sense.
> 
> And such a change would also mean we create a separate directory for every
> other driver present right now in pci/host.

I understand you idea. We can simplify it this way:

 drivers/pci
   drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
 drivers/pci/dwc -> Common files (RC and EP), specific vendor drivers for EP
and EP

BTW dwc states for DesigWare 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hi,

Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
 On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>>> As discussed during our LPC discussions, I'm posting the rename patch
>>> here. I'll post the rest of EP series before the next merge window.
>>>
>>> There might be hiccups because of this renaming but feel this is
>>> necessary for long-term maintenance.
>>
>> if we do this rename it would be great to get it to Linus NOW after
>> -rc1 as that minimizes the impact on the 4.11 merge window.
>
> Rename it to controller is a bit vague I thing since we have the PCI 
> Endpoint IP
> also. Wouldn't be better to name it rc_controller?

 I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
 neutral name that can cover both RC and Endpoint.
> 
> right.

 I'm not a huge fan of "controller" because it feels a little bit long
 and while I suppose it technically does include the concept of the PCI
 interface of an endpoint, it still suggests more of the host side to
 me.

 Doesn't USB have a similar situation?  I see there's a
 drivers/usb/host/ (probably where we copied from in the first place).
 Is a USB gadget the USB analog of what you're doing?  How do they
 share code between the master/slave sides?

>>>
>>> The usb/host contains the implemnentations by the spec of the several
>>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
> 
> right, each IP have a separate directory in USB. I thought of doing something
> similar for PCI but decided against it since that would involve identifying 
> all
> the PCI IPs used and eventually result in more directories.
>>> For device purposes it uses the core/ and then some of the device functions
>>> are extended from the gadget/ package in which you can use mass_storage and
>>> other types of functions.
> 
> That would be similar for PCI endpoint. All endpoint specific core
> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>>
>>> In our case in PCI we have the core functions inside /drivers/pci and the 
>>> host
>>> mangled inside host. I suggest:
>>>
>>> drivers/pci
>>>  drivers/pci/core/
>>>  drivers/pci/core/hotplug
>>>  drivers/pci/core/pcie
>>>  drivers/pci/core/
>>>  drivers/pci/host
>>>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
>>> drivers
>>
>> Correction:
>> drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
>> drivers
>>
>>>  drivers/pci/ -> here would be the drivers for vendorN controller
>>
>> Correction:
>> drivers/pci/host/ -> here would be the drivers for vendorN 
>> controller
>>
>>>  drivers/pci/endpoint -> common code
>>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
>>> ops
>>>  drivers/pci/ -> implementation of other vendors specific endpoint 
>>> ops
> 
> There are some parts of the dwc driver that is common to both root complex and
> endpoint. Where should that be? I'm sure no one wants to duplicate the common
> piece in both root complex and endpoint.

You are right, the config space is almost the same and some ops also common.
I would suggest:

drivers/pci
  drivers/pci/core/
drivers/pci/core/hotplug
drivers/pci/core/pcie
drivers/pci/core/
  drivers/pci/dwc
drivers/pci/dwc/common.c -> common ops and registers between RC and endpoint
drivers/pci/dwc/host/
drivers/pci/dwc/endpoint/

What do you think?

Thanks.

> 
> [1] -> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2016_9_14_27=DgID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=E9ExIpzr6vIxD1dZDQcUzR5Y-MLqjT1aO_A96qhd_Dk=9vvw2jAdXsYlzu0KriDWnmdHa3H_GPFP5Ti2dbM865A=
>  
> 
> Thanks
> Kishon
> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hi,

Às 5:46 AM de 12/29/2016, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
>> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
 On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>>> As discussed during our LPC discussions, I'm posting the rename patch
>>> here. I'll post the rest of EP series before the next merge window.
>>>
>>> There might be hiccups because of this renaming but feel this is
>>> necessary for long-term maintenance.
>>
>> if we do this rename it would be great to get it to Linus NOW after
>> -rc1 as that minimizes the impact on the 4.11 merge window.
>
> Rename it to controller is a bit vague I thing since we have the PCI 
> Endpoint IP
> also. Wouldn't be better to name it rc_controller?

 I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
 neutral name that can cover both RC and Endpoint.
> 
> right.

 I'm not a huge fan of "controller" because it feels a little bit long
 and while I suppose it technically does include the concept of the PCI
 interface of an endpoint, it still suggests more of the host side to
 me.

 Doesn't USB have a similar situation?  I see there's a
 drivers/usb/host/ (probably where we copied from in the first place).
 Is a USB gadget the USB analog of what you're doing?  How do they
 share code between the master/slave sides?

>>>
>>> The usb/host contains the implemnentations by the spec of the several
>>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
> 
> right, each IP have a separate directory in USB. I thought of doing something
> similar for PCI but decided against it since that would involve identifying 
> all
> the PCI IPs used and eventually result in more directories.
>>> For device purposes it uses the core/ and then some of the device functions
>>> are extended from the gadget/ package in which you can use mass_storage and
>>> other types of functions.
> 
> That would be similar for PCI endpoint. All endpoint specific core
> functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>>
>>> In our case in PCI we have the core functions inside /drivers/pci and the 
>>> host
>>> mangled inside host. I suggest:
>>>
>>> drivers/pci
>>>  drivers/pci/core/
>>>  drivers/pci/core/hotplug
>>>  drivers/pci/core/pcie
>>>  drivers/pci/core/
>>>  drivers/pci/host
>>>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
>>> drivers
>>
>> Correction:
>> drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
>> drivers
>>
>>>  drivers/pci/ -> here would be the drivers for vendorN controller
>>
>> Correction:
>> drivers/pci/host/ -> here would be the drivers for vendorN 
>> controller
>>
>>>  drivers/pci/endpoint -> common code
>>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint 
>>> ops
>>>  drivers/pci/ -> implementation of other vendors specific endpoint 
>>> ops
> 
> There are some parts of the dwc driver that is common to both root complex and
> endpoint. Where should that be? I'm sure no one wants to duplicate the common
> piece in both root complex and endpoint.

You are right, the config space is almost the same and some ops also common.
I would suggest:

drivers/pci
  drivers/pci/core/
drivers/pci/core/hotplug
drivers/pci/core/pcie
drivers/pci/core/
  drivers/pci/dwc
drivers/pci/dwc/common.c -> common ops and registers between RC and endpoint
drivers/pci/dwc/host/
drivers/pci/dwc/endpoint/

What do you think?

Thanks.

> 
> [1] -> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2016_9_14_27=DgID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=E9ExIpzr6vIxD1dZDQcUzR5Y-MLqjT1aO_A96qhd_Dk=9vvw2jAdXsYlzu0KriDWnmdHa3H_GPFP5Ti2dbM865A=
>  
> 
> Thanks
> Kishon
> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the PCI 
 Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit long
>>> and while I suppose it technically does include the concept of the PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

right, each IP have a separate directory in USB. I thought of doing something
similar for PCI but decided against it since that would involve identifying all
the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device functions
>> are extended from the gadget/ package in which you can use mass_storage and
>> other types of functions.

That would be similar for PCI endpoint. All endpoint specific core
functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci and the 
>> host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
>> drivers
> 
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
> drivers
> 
>>  drivers/pci/ -> here would be the drivers for vendorN controller
> 
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN controller
> 
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific endpoint 
>> ops

There are some parts of the dwc driver that is common to both root complex and
endpoint. Where should that be? I'm sure no one wants to duplicate the common
piece in both root complex and endpoint.

[1] -> https://lkml.org/lkml/2016/9/14/27

Thanks
Kishon

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

Hi,

On Wednesday 28 December 2016 10:50 PM, Joao Pinto wrote:
> Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
>> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
 Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
>
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

 Rename it to controller is a bit vague I thing since we have the PCI 
 Endpoint IP
 also. Wouldn't be better to name it rc_controller?
>>>
>>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>>> neutral name that can cover both RC and Endpoint.

right.
>>>
>>> I'm not a huge fan of "controller" because it feels a little bit long
>>> and while I suppose it technically does include the concept of the PCI
>>> interface of an endpoint, it still suggests more of the host side to
>>> me.
>>>
>>> Doesn't USB have a similar situation?  I see there's a
>>> drivers/usb/host/ (probably where we copied from in the first place).
>>> Is a USB gadget the USB analog of what you're doing?  How do they
>>> share code between the master/slave sides?
>>>
>>
>> The usb/host contains the implemnentations by the spec of the several
>> *hci (USB Host) and then you can have for example the USB 3.0 Designware
>> Host specific ops in dwc3 and for USB 2.0 in dwc2/.

right, each IP have a separate directory in USB. I thought of doing something
similar for PCI but decided against it since that would involve identifying all
the PCI IPs used and eventually result in more directories.
>> For device purposes it uses the core/ and then some of the device functions
>> are extended from the gadget/ package in which you can use mass_storage and
>> other types of functions.

That would be similar for PCI endpoint. All endpoint specific core
functionality will be added in drivers/pci/endpoint (see RFC [1]).
>>
>> In our case in PCI we have the core functions inside /drivers/pci and the 
>> host
>> mangled inside host. I suggest:
>>
>> drivers/pci
>>  drivers/pci/core/
>>  drivers/pci/core/hotplug
>>  drivers/pci/core/pcie
>>  drivers/pci/core/
>>  drivers/pci/host
>>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
>> drivers
> 
> Correction:
> drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
> drivers
> 
>>  drivers/pci/ -> here would be the drivers for vendorN controller
> 
> Correction:
> drivers/pci/host/ -> here would be the drivers for vendorN controller
> 
>>  drivers/pci/endpoint -> common code
>>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
>>  drivers/pci/ -> implementation of other vendors specific endpoint 
>> ops

There are some parts of the dwc driver that is common to both root complex and
endpoint. Where should that be? I'm sure no one wants to duplicate the common
piece in both root complex and endpoint.

[1] -> https://lkml.org/lkml/2016/9/14/27

Thanks
Kishon

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the PCI 
>>> Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
> 
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
> For device purposes it uses the core/ and then some of the device functions
> are extended from the gadget/ package in which you can use mass_storage and
> other types of functions.
> 
> In our case in PCI we have the core functions inside /drivers/pci and the host
> mangled inside host. I suggest:
> 
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
> drivers

Correction:
drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
drivers

>  drivers/pci/ -> here would be the drivers for vendorN controller

Correction:
drivers/pci/host/ -> here would be the drivers for vendorN controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
>  drivers/pci/ -> implementation of other vendors specific endpoint 
> ops
> 

Thanks

> Joao
> 
>> There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
>> but it's short and it at least conveys the idea that this code is
>> hardware-specific, not generic.
>>
>  drivers/pci/{host => controller}/Kconfig   |0
>  drivers/pci/{host => controller}/Makefile  |0
>  drivers/pci/{host => controller}/pci-aardvark.c|0
>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
> ...
> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 5:17 PM de 12/28/2016, Joao Pinto escreveu:
> Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
>> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
 On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
>
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

 if we do this rename it would be great to get it to Linus NOW after
 -rc1 as that minimizes the impact on the 4.11 merge window.
>>>
>>> Rename it to controller is a bit vague I thing since we have the PCI 
>>> Endpoint IP
>>> also. Wouldn't be better to name it rc_controller?
>>
>> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
>> neutral name that can cover both RC and Endpoint.
>>
>> I'm not a huge fan of "controller" because it feels a little bit long
>> and while I suppose it technically does include the concept of the PCI
>> interface of an endpoint, it still suggests more of the host side to
>> me.
>>
>> Doesn't USB have a similar situation?  I see there's a
>> drivers/usb/host/ (probably where we copied from in the first place).
>> Is a USB gadget the USB analog of what you're doing?  How do they
>> share code between the master/slave sides?
>>
> 
> The usb/host contains the implemnentations by the spec of the several
> *hci (USB Host) and then you can have for example the USB 3.0 Designware
> Host specific ops in dwc3 and for USB 2.0 in dwc2/.
> For device purposes it uses the core/ and then some of the device functions
> are extended from the gadget/ package in which you can use mass_storage and
> other types of functions.
> 
> In our case in PCI we have the core functions inside /drivers/pci and the host
> mangled inside host. I suggest:
> 
> drivers/pci
>  drivers/pci/core/
>  drivers/pci/core/hotplug
>  drivers/pci/core/pcie
>  drivers/pci/core/
>  drivers/pci/host
>  drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
> drivers

Correction:
drivers/pci/host/dwc -> here would be pcie-designware and the specific vendor
drivers

>  drivers/pci/ -> here would be the drivers for vendorN controller

Correction:
drivers/pci/host/ -> here would be the drivers for vendorN controller

>  drivers/pci/endpoint -> common code
>  drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
>  drivers/pci/ -> implementation of other vendors specific endpoint 
> ops
> 

Thanks

> Joao
> 
>> There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
>> but it's short and it at least conveys the idea that this code is
>> hardware-specific, not generic.
>>
>  drivers/pci/{host => controller}/Kconfig   |0
>  drivers/pci/{host => controller}/Makefile  |0
>  drivers/pci/{host => controller}/pci-aardvark.c|0
>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
> ...
> 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
 As discussed during our LPC discussions, I'm posting the rename patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
> 
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
> 
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
> 
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
> 

The usb/host contains the implemnentations by the spec of the several
*hci (USB Host) and then you can have for example the USB 3.0 Designware
Host specific ops in dwc3 and for USB 2.0 in dwc2/.
For device purposes it uses the core/ and then some of the device functions
are extended from the gadget/ package in which you can use mass_storage and
other types of functions.

In our case in PCI we have the core functions inside /drivers/pci and the host
mangled inside host. I suggest:

drivers/pci
 drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
 drivers/pci/host
 drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
drivers
 drivers/pci/ -> here would be the drivers for vendorN controller
 drivers/pci/endpoint -> common code
 drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
 drivers/pci/ -> implementation of other vendors specific endpoint ops

Joao

> There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
> but it's short and it at least conveys the idea that this code is
> hardware-specific, not generic.
> 
  drivers/pci/{host => controller}/Kconfig   |0
  drivers/pci/{host => controller}/Makefile  |0
  drivers/pci/{host => controller}/pci-aardvark.c|0
  drivers/pci/{host => controller}/pci-dra7xx.c  |0
 ...

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Às 4:41 PM de 12/28/2016, Bjorn Helgaas escreveu:
> On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
>> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
>>> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
 As discussed during our LPC discussions, I'm posting the rename patch
 here. I'll post the rest of EP series before the next merge window.

 There might be hiccups because of this renaming but feel this is
 necessary for long-term maintenance.
>>>
>>> if we do this rename it would be great to get it to Linus NOW after
>>> -rc1 as that minimizes the impact on the 4.11 merge window.
>>
>> Rename it to controller is a bit vague I thing since we have the PCI 
>> Endpoint IP
>> also. Wouldn't be better to name it rc_controller?
> 
> I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
> neutral name that can cover both RC and Endpoint.
> 
> I'm not a huge fan of "controller" because it feels a little bit long
> and while I suppose it technically does include the concept of the PCI
> interface of an endpoint, it still suggests more of the host side to
> me.
> 
> Doesn't USB have a similar situation?  I see there's a
> drivers/usb/host/ (probably where we copied from in the first place).
> Is a USB gadget the USB analog of what you're doing?  How do they
> share code between the master/slave sides?
> 

The usb/host contains the implemnentations by the spec of the several
*hci (USB Host) and then you can have for example the USB 3.0 Designware
Host specific ops in dwc3 and for USB 2.0 in dwc2/.
For device purposes it uses the core/ and then some of the device functions
are extended from the gadget/ package in which you can use mass_storage and
other types of functions.

In our case in PCI we have the core functions inside /drivers/pci and the host
mangled inside host. I suggest:

drivers/pci
 drivers/pci/core/
 drivers/pci/core/hotplug
 drivers/pci/core/pcie
 drivers/pci/core/
 drivers/pci/host
 drivers/pci/dwc -> here would be pcie-designware and the specific vendor 
drivers
 drivers/pci/ -> here would be the drivers for vendorN controller
 drivers/pci/endpoint -> common code
 drivers/pci/endpoint/dwc -> implementation of Synopsys specific endpoint ops
 drivers/pci/ -> implementation of other vendors specific endpoint ops

Joao

> There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
> but it's short and it at least conveys the idea that this code is
> hardware-specific, not generic.
> 
  drivers/pci/{host => controller}/Kconfig   |0
  drivers/pci/{host => controller}/Makefile  |0
  drivers/pci/{host => controller}/pci-aardvark.c|0
  drivers/pci/{host => controller}/pci-dra7xx.c  |0
 ...

Re: [PATCH] pci: rename *host* directory to *controller*

[Bjorn Helgaas]

On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> > On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> >> As discussed during our LPC discussions, I'm posting the rename patch
> >> here. I'll post the rest of EP series before the next merge window.
> >>
> >> There might be hiccups because of this renaming but feel this is
> >> necessary for long-term maintenance.
> > 
> > if we do this rename it would be great to get it to Linus NOW after
> > -rc1 as that minimizes the impact on the 4.11 merge window.
> 
> Rename it to controller is a bit vague I thing since we have the PCI Endpoint 
> IP
> also. Wouldn't be better to name it rc_controller?

I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
neutral name that can cover both RC and Endpoint.

I'm not a huge fan of "controller" because it feels a little bit long
and while I suppose it technically does include the concept of the PCI
interface of an endpoint, it still suggests more of the host side to
me.

Doesn't USB have a similar situation?  I see there's a
drivers/usb/host/ (probably where we copied from in the first place).
Is a USB gadget the USB analog of what you're doing?  How do they
share code between the master/slave sides?

There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
but it's short and it at least conveys the idea that this code is
hardware-specific, not generic.

> >>  drivers/pci/{host => controller}/Kconfig   |0
> >>  drivers/pci/{host => controller}/Makefile  |0
> >>  drivers/pci/{host => controller}/pci-aardvark.c|0
> >>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
> >> ...

Re: [PATCH] pci: rename *host* directory to *controller*

[Bjorn Helgaas]

On Wed, Dec 28, 2016 at 01:57:13PM +, Joao Pinto wrote:
> Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> > On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> >> As discussed during our LPC discussions, I'm posting the rename patch
> >> here. I'll post the rest of EP series before the next merge window.
> >>
> >> There might be hiccups because of this renaming but feel this is
> >> necessary for long-term maintenance.
> > 
> > if we do this rename it would be great to get it to Linus NOW after
> > -rc1 as that minimizes the impact on the 4.11 merge window.
> 
> Rename it to controller is a bit vague I thing since we have the PCI Endpoint 
> IP
> also. Wouldn't be better to name it rc_controller?

I think Kishon's whole goal is to add PCI Endpoint IP, so he wants a
neutral name that can cover both RC and Endpoint.

I'm not a huge fan of "controller" because it feels a little bit long
and while I suppose it technically does include the concept of the PCI
interface of an endpoint, it still suggests more of the host side to
me.

Doesn't USB have a similar situation?  I see there's a
drivers/usb/host/ (probably where we copied from in the first place).
Is a USB gadget the USB analog of what you're doing?  How do they
share code between the master/slave sides?

There's a drivers/ntb/hw/.  I don't know if "hw" is the *best* name,
but it's short and it at least conveys the idea that this code is
hardware-specific, not generic.

> >>  drivers/pci/{host => controller}/Kconfig   |0
> >>  drivers/pci/{host => controller}/Makefile  |0
> >>  drivers/pci/{host => controller}/pci-aardvark.c|0
> >>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
> >> ...

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hello,

Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Bjorn,
>>
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
> 
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

Rename it to controller is a bit vague I thing since we have the PCI Endpoint IP
also. Wouldn't be better to name it rc_controller?

> 
>>
>> Thanks
>> Kishon
>>
>>  MAINTAINERS|   52 
>> ++--
>>  drivers/pci/Kconfig|2 +-
>>  drivers/pci/Makefile   |2 +-
>>  drivers/pci/{host => controller}/Kconfig   |0
>>  drivers/pci/{host => controller}/Makefile  |0
>>  drivers/pci/{host => controller}/pci-aardvark.c|0
>>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>>  drivers/pci/{host => controller}/pci-exynos.c  |0
>>  drivers/pci/{host => controller}/pci-host-common.c |0
>>  .../pci/{host => controller}/pci-host-generic.c|0
>>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>>  drivers/pci/{host => controller}/pci-imx6.c|0
>>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>>  drivers/pci/{host => controller}/pci-keystone.c|0
>>  drivers/pci/{host => controller}/pci-keystone.h|0
>>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>>  drivers/pci/{host => controller}/pci-tegra.c   |0
>>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>>  drivers/pci/{host => controller}/pci-versatile.c   |0
>>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>>  drivers/pci/{host => controller}/pci-xgene.c   |0
>>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>>  drivers/pci/{host => controller}/pcie-altera.c |0
>>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>>  .../{host => controller}/pcie-designware-plat.c|0
>>  drivers/pci/{host => controller}/pcie-designware.c |0
>>  drivers/pci/{host => controller}/pcie-designware.h |0
>>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>>  drivers/pci/{host => controller}/vmd.c |0
>>  44 files changed, 28 insertions(+), 28 deletions(-)
>>  rename drivers/pci/{host => controller}/Kconfig (100%)
>>  rename drivers/pci/{host => controller}/Makefile (100%)
>>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>>  rename drivers/pci/{host => 

Re: [PATCH] pci: rename *host* directory to *controller*

[Joao Pinto]

Hello,

Às 9:22 AM de 12/28/2016, Christoph Hellwig escreveu:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Bjorn,
>>
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
> 
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

Rename it to controller is a bit vague I thing since we have the PCI Endpoint IP
also. Wouldn't be better to name it rc_controller?

> 
>>
>> Thanks
>> Kishon
>>
>>  MAINTAINERS|   52 
>> ++--
>>  drivers/pci/Kconfig|2 +-
>>  drivers/pci/Makefile   |2 +-
>>  drivers/pci/{host => controller}/Kconfig   |0
>>  drivers/pci/{host => controller}/Makefile  |0
>>  drivers/pci/{host => controller}/pci-aardvark.c|0
>>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>>  drivers/pci/{host => controller}/pci-exynos.c  |0
>>  drivers/pci/{host => controller}/pci-host-common.c |0
>>  .../pci/{host => controller}/pci-host-generic.c|0
>>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>>  drivers/pci/{host => controller}/pci-imx6.c|0
>>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>>  drivers/pci/{host => controller}/pci-keystone.c|0
>>  drivers/pci/{host => controller}/pci-keystone.h|0
>>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>>  drivers/pci/{host => controller}/pci-tegra.c   |0
>>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>>  drivers/pci/{host => controller}/pci-versatile.c   |0
>>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>>  drivers/pci/{host => controller}/pci-xgene.c   |0
>>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>>  drivers/pci/{host => controller}/pcie-altera.c |0
>>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>>  .../{host => controller}/pcie-designware-plat.c|0
>>  drivers/pci/{host => controller}/pcie-designware.c |0
>>  drivers/pci/{host => controller}/pcie-designware.h |0
>>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>>  drivers/pci/{host => controller}/vmd.c |0
>>  44 files changed, 28 insertions(+), 28 deletions(-)
>>  rename drivers/pci/{host => controller}/Kconfig (100%)
>>  rename drivers/pci/{host => controller}/Makefile (100%)
>>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>>  rename drivers/pci/{host => 

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

On Wednesday 28 December 2016 02:52 PM, Christoph Hellwig wrote:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Bjorn,
>>
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
> 
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

+1
> 
>>
>> Thanks
>> Kishon
>>
>>  MAINTAINERS|   52 
>> ++--
>>  drivers/pci/Kconfig|2 +-
>>  drivers/pci/Makefile   |2 +-
>>  drivers/pci/{host => controller}/Kconfig   |0
>>  drivers/pci/{host => controller}/Makefile  |0
>>  drivers/pci/{host => controller}/pci-aardvark.c|0
>>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>>  drivers/pci/{host => controller}/pci-exynos.c  |0
>>  drivers/pci/{host => controller}/pci-host-common.c |0
>>  .../pci/{host => controller}/pci-host-generic.c|0
>>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>>  drivers/pci/{host => controller}/pci-imx6.c|0
>>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>>  drivers/pci/{host => controller}/pci-keystone.c|0
>>  drivers/pci/{host => controller}/pci-keystone.h|0
>>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>>  drivers/pci/{host => controller}/pci-tegra.c   |0
>>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>>  drivers/pci/{host => controller}/pci-versatile.c   |0
>>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>>  drivers/pci/{host => controller}/pci-xgene.c   |0
>>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>>  drivers/pci/{host => controller}/pcie-altera.c |0
>>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>>  .../{host => controller}/pcie-designware-plat.c|0
>>  drivers/pci/{host => controller}/pcie-designware.c |0
>>  drivers/pci/{host => controller}/pcie-designware.h |0
>>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>>  drivers/pci/{host => controller}/vmd.c |0
>>  44 files changed, 28 insertions(+), 28 deletions(-)
>>  rename drivers/pci/{host => controller}/Kconfig (100%)
>>  rename drivers/pci/{host => controller}/Makefile (100%)
>>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
>>  rename 

Re: [PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

On Wednesday 28 December 2016 02:52 PM, Christoph Hellwig wrote:
> On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Bjorn,
>>
>> As discussed during our LPC discussions, I'm posting the rename patch
>> here. I'll post the rest of EP series before the next merge window.
>>
>> There might be hiccups because of this renaming but feel this is
>> necessary for long-term maintenance.
> 
> if we do this rename it would be great to get it to Linus NOW after
> -rc1 as that minimizes the impact on the 4.11 merge window.

+1
> 
>>
>> Thanks
>> Kishon
>>
>>  MAINTAINERS|   52 
>> ++--
>>  drivers/pci/Kconfig|2 +-
>>  drivers/pci/Makefile   |2 +-
>>  drivers/pci/{host => controller}/Kconfig   |0
>>  drivers/pci/{host => controller}/Makefile  |0
>>  drivers/pci/{host => controller}/pci-aardvark.c|0
>>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>>  drivers/pci/{host => controller}/pci-exynos.c  |0
>>  drivers/pci/{host => controller}/pci-host-common.c |0
>>  .../pci/{host => controller}/pci-host-generic.c|0
>>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>>  drivers/pci/{host => controller}/pci-imx6.c|0
>>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>>  drivers/pci/{host => controller}/pci-keystone.c|0
>>  drivers/pci/{host => controller}/pci-keystone.h|0
>>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>>  drivers/pci/{host => controller}/pci-tegra.c   |0
>>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>>  drivers/pci/{host => controller}/pci-versatile.c   |0
>>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>>  drivers/pci/{host => controller}/pci-xgene.c   |0
>>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>>  drivers/pci/{host => controller}/pcie-altera.c |0
>>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>>  .../{host => controller}/pcie-designware-plat.c|0
>>  drivers/pci/{host => controller}/pcie-designware.c |0
>>  drivers/pci/{host => controller}/pcie-designware.h |0
>>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>>  drivers/pci/{host => controller}/vmd.c |0
>>  44 files changed, 28 insertions(+), 28 deletions(-)
>>  rename drivers/pci/{host => controller}/Kconfig (100%)
>>  rename drivers/pci/{host => controller}/Makefile (100%)
>>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-altera.c (100%)
>>  rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
>>  rename 

Re: [PATCH] pci: rename *host* directory to *controller*

[Christoph Hellwig]

On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
> 
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

if we do this rename it would be great to get it to Linus NOW after
-rc1 as that minimizes the impact on the 4.11 merge window.

> 
> Thanks
> Kishon
> 
>  MAINTAINERS|   52 
> ++--
>  drivers/pci/Kconfig|2 +-
>  drivers/pci/Makefile   |2 +-
>  drivers/pci/{host => controller}/Kconfig   |0
>  drivers/pci/{host => controller}/Makefile  |0
>  drivers/pci/{host => controller}/pci-aardvark.c|0
>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>  drivers/pci/{host => controller}/pci-exynos.c  |0
>  drivers/pci/{host => controller}/pci-host-common.c |0
>  .../pci/{host => controller}/pci-host-generic.c|0
>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>  drivers/pci/{host => controller}/pci-imx6.c|0
>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>  drivers/pci/{host => controller}/pci-keystone.c|0
>  drivers/pci/{host => controller}/pci-keystone.h|0
>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>  drivers/pci/{host => controller}/pci-tegra.c   |0
>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>  drivers/pci/{host => controller}/pci-versatile.c   |0
>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>  drivers/pci/{host => controller}/pci-xgene.c   |0
>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>  drivers/pci/{host => controller}/pcie-altera.c |0
>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>  .../{host => controller}/pcie-designware-plat.c|0
>  drivers/pci/{host => controller}/pcie-designware.c |0
>  drivers/pci/{host => controller}/pcie-designware.h |0
>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>  drivers/pci/{host => controller}/vmd.c |0
>  44 files changed, 28 insertions(+), 28 deletions(-)
>  rename drivers/pci/{host => controller}/Kconfig (100%)
>  rename drivers/pci/{host => controller}/Makefile (100%)
>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>  rename drivers/pci/{host => controller}/pcie-altera.c (100%)
>  rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
>  rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
>  rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
>  rename drivers/pci/{host => 

Re: [PATCH] pci: rename *host* directory to *controller*

[Christoph Hellwig]

On Wed, Dec 28, 2016 at 01:39:37PM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> As discussed during our LPC discussions, I'm posting the rename patch
> here. I'll post the rest of EP series before the next merge window.
> 
> There might be hiccups because of this renaming but feel this is
> necessary for long-term maintenance.

if we do this rename it would be great to get it to Linus NOW after
-rc1 as that minimizes the impact on the 4.11 merge window.

> 
> Thanks
> Kishon
> 
>  MAINTAINERS|   52 
> ++--
>  drivers/pci/Kconfig|2 +-
>  drivers/pci/Makefile   |2 +-
>  drivers/pci/{host => controller}/Kconfig   |0
>  drivers/pci/{host => controller}/Makefile  |0
>  drivers/pci/{host => controller}/pci-aardvark.c|0
>  drivers/pci/{host => controller}/pci-dra7xx.c  |0
>  drivers/pci/{host => controller}/pci-exynos.c  |0
>  drivers/pci/{host => controller}/pci-host-common.c |0
>  .../pci/{host => controller}/pci-host-generic.c|0
>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>  drivers/pci/{host => controller}/pci-imx6.c|0
>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>  drivers/pci/{host => controller}/pci-keystone.c|0
>  drivers/pci/{host => controller}/pci-keystone.h|0
>  drivers/pci/{host => controller}/pci-layerscape.c  |0
>  drivers/pci/{host => controller}/pci-mvebu.c   |0
>  drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
>  drivers/pci/{host => controller}/pci-tegra.c   |0
>  .../pci/{host => controller}/pci-thunder-ecam.c|0
>  drivers/pci/{host => controller}/pci-thunder-pem.c |0
>  drivers/pci/{host => controller}/pci-versatile.c   |0
>  drivers/pci/{host => controller}/pci-xgene-msi.c   |0
>  drivers/pci/{host => controller}/pci-xgene.c   |0
>  drivers/pci/{host => controller}/pcie-altera-msi.c |0
>  drivers/pci/{host => controller}/pcie-altera.c |0
>  drivers/pci/{host => controller}/pcie-armada8k.c   |0
>  drivers/pci/{host => controller}/pcie-artpec6.c|0
>  .../{host => controller}/pcie-designware-plat.c|0
>  drivers/pci/{host => controller}/pcie-designware.c |0
>  drivers/pci/{host => controller}/pcie-designware.h |0
>  drivers/pci/{host => controller}/pcie-hisi.c   |0
>  drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
>  drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
>  .../pci/{host => controller}/pcie-iproc-platform.c |0
>  drivers/pci/{host => controller}/pcie-iproc.c  |0
>  drivers/pci/{host => controller}/pcie-iproc.h  |0
>  drivers/pci/{host => controller}/pcie-qcom.c   |0
>  drivers/pci/{host => controller}/pcie-rcar.c   |0
>  drivers/pci/{host => controller}/pcie-rockchip.c   |0
>  drivers/pci/{host => controller}/pcie-spear13xx.c  |0
>  drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
>  drivers/pci/{host => controller}/pcie-xilinx.c |0
>  drivers/pci/{host => controller}/vmd.c |0
>  44 files changed, 28 insertions(+), 28 deletions(-)
>  rename drivers/pci/{host => controller}/Kconfig (100%)
>  rename drivers/pci/{host => controller}/Makefile (100%)
>  rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
>  rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
>  rename drivers/pci/{host => controller}/pci-exynos.c (100%)
>  rename drivers/pci/{host => controller}/pci-host-common.c (100%)
>  rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
>  rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
>  rename drivers/pci/{host => controller}/pci-imx6.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone.c (100%)
>  rename drivers/pci/{host => controller}/pci-keystone.h (100%)
>  rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
>  rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
>  rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
>  rename drivers/pci/{host => controller}/pci-tegra.c (100%)
>  rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
>  rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
>  rename drivers/pci/{host => controller}/pci-versatile.c (100%)
>  rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
>  rename drivers/pci/{host => controller}/pci-xgene.c (100%)
>  rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
>  rename drivers/pci/{host => controller}/pcie-altera.c (100%)
>  rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
>  rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
>  rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
>  rename drivers/pci/{host => 

[PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

No functional change. Renamed the *host* directory present inside
drivers/pci to *controller*. Some of the controllers present in
drivers/pci/host is capable of operating in endpoint mode.
So having these drivers in *host* directory might not be appropriate.
This is in preparation for adding endpoint mode support for some of
controller drivers present here.

Signed-off-by: Kishon Vijay Abraham I 
---
Hi Bjorn,

As discussed during our LPC discussions, I'm posting the rename patch
here. I'll post the rest of EP series before the next merge window.

There might be hiccups because of this renaming but feel this is
necessary for long-term maintenance.

Thanks
Kishon

 MAINTAINERS|   52 ++--
 drivers/pci/Kconfig|2 +-
 drivers/pci/Makefile   |2 +-
 drivers/pci/{host => controller}/Kconfig   |0
 drivers/pci/{host => controller}/Makefile  |0
 drivers/pci/{host => controller}/pci-aardvark.c|0
 drivers/pci/{host => controller}/pci-dra7xx.c  |0
 drivers/pci/{host => controller}/pci-exynos.c  |0
 drivers/pci/{host => controller}/pci-host-common.c |0
 .../pci/{host => controller}/pci-host-generic.c|0
 drivers/pci/{host => controller}/pci-hyperv.c  |0
 drivers/pci/{host => controller}/pci-imx6.c|0
 drivers/pci/{host => controller}/pci-keystone-dw.c |0
 drivers/pci/{host => controller}/pci-keystone.c|0
 drivers/pci/{host => controller}/pci-keystone.h|0
 drivers/pci/{host => controller}/pci-layerscape.c  |0
 drivers/pci/{host => controller}/pci-mvebu.c   |0
 drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
 drivers/pci/{host => controller}/pci-tegra.c   |0
 .../pci/{host => controller}/pci-thunder-ecam.c|0
 drivers/pci/{host => controller}/pci-thunder-pem.c |0
 drivers/pci/{host => controller}/pci-versatile.c   |0
 drivers/pci/{host => controller}/pci-xgene-msi.c   |0
 drivers/pci/{host => controller}/pci-xgene.c   |0
 drivers/pci/{host => controller}/pcie-altera-msi.c |0
 drivers/pci/{host => controller}/pcie-altera.c |0
 drivers/pci/{host => controller}/pcie-armada8k.c   |0
 drivers/pci/{host => controller}/pcie-artpec6.c|0
 .../{host => controller}/pcie-designware-plat.c|0
 drivers/pci/{host => controller}/pcie-designware.c |0
 drivers/pci/{host => controller}/pcie-designware.h |0
 drivers/pci/{host => controller}/pcie-hisi.c   |0
 drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
 drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
 .../pci/{host => controller}/pcie-iproc-platform.c |0
 drivers/pci/{host => controller}/pcie-iproc.c  |0
 drivers/pci/{host => controller}/pcie-iproc.h  |0
 drivers/pci/{host => controller}/pcie-qcom.c   |0
 drivers/pci/{host => controller}/pcie-rcar.c   |0
 drivers/pci/{host => controller}/pcie-rockchip.c   |0
 drivers/pci/{host => controller}/pcie-spear13xx.c  |0
 drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
 drivers/pci/{host => controller}/pcie-xilinx.c |0
 drivers/pci/{host => controller}/vmd.c |0
 44 files changed, 28 insertions(+), 28 deletions(-)
 rename drivers/pci/{host => controller}/Kconfig (100%)
 rename drivers/pci/{host => controller}/Makefile (100%)
 rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
 rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
 rename drivers/pci/{host => controller}/pci-exynos.c (100%)
 rename drivers/pci/{host => controller}/pci-host-common.c (100%)
 rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
 rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
 rename drivers/pci/{host => controller}/pci-imx6.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.h (100%)
 rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
 rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
 rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
 rename drivers/pci/{host => controller}/pci-tegra.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
 rename drivers/pci/{host => controller}/pci-versatile.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera.c (100%)
 rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
 rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware-plat.c 

[PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

No functional change. Renamed the *host* directory present inside
drivers/pci to *controller*. Some of the controllers present in
drivers/pci/host is capable of operating in endpoint mode.
So having these drivers in *host* directory might not be appropriate.
This is in preparation for adding endpoint mode support for some of
controller drivers present here.

Signed-off-by: Kishon Vijay Abraham I 
---
Hi Bjorn,

As discussed during our LPC discussions, I'm posting the rename patch
here. I'll post the rest of EP series before the next merge window.

There might be hiccups because of this renaming but feel this is
necessary for long-term maintenance.

Thanks
Kishon

 MAINTAINERS|   52 ++--
 drivers/pci/Kconfig|2 +-
 drivers/pci/Makefile   |2 +-
 drivers/pci/{host => controller}/Kconfig   |0
 drivers/pci/{host => controller}/Makefile  |0
 drivers/pci/{host => controller}/pci-aardvark.c|0
 drivers/pci/{host => controller}/pci-dra7xx.c  |0
 drivers/pci/{host => controller}/pci-exynos.c  |0
 drivers/pci/{host => controller}/pci-host-common.c |0
 .../pci/{host => controller}/pci-host-generic.c|0
 drivers/pci/{host => controller}/pci-hyperv.c  |0
 drivers/pci/{host => controller}/pci-imx6.c|0
 drivers/pci/{host => controller}/pci-keystone-dw.c |0
 drivers/pci/{host => controller}/pci-keystone.c|0
 drivers/pci/{host => controller}/pci-keystone.h|0
 drivers/pci/{host => controller}/pci-layerscape.c  |0
 drivers/pci/{host => controller}/pci-mvebu.c   |0
 drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
 drivers/pci/{host => controller}/pci-tegra.c   |0
 .../pci/{host => controller}/pci-thunder-ecam.c|0
 drivers/pci/{host => controller}/pci-thunder-pem.c |0
 drivers/pci/{host => controller}/pci-versatile.c   |0
 drivers/pci/{host => controller}/pci-xgene-msi.c   |0
 drivers/pci/{host => controller}/pci-xgene.c   |0
 drivers/pci/{host => controller}/pcie-altera-msi.c |0
 drivers/pci/{host => controller}/pcie-altera.c |0
 drivers/pci/{host => controller}/pcie-armada8k.c   |0
 drivers/pci/{host => controller}/pcie-artpec6.c|0
 .../{host => controller}/pcie-designware-plat.c|0
 drivers/pci/{host => controller}/pcie-designware.c |0
 drivers/pci/{host => controller}/pcie-designware.h |0
 drivers/pci/{host => controller}/pcie-hisi.c   |0
 drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
 drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
 .../pci/{host => controller}/pcie-iproc-platform.c |0
 drivers/pci/{host => controller}/pcie-iproc.c  |0
 drivers/pci/{host => controller}/pcie-iproc.h  |0
 drivers/pci/{host => controller}/pcie-qcom.c   |0
 drivers/pci/{host => controller}/pcie-rcar.c   |0
 drivers/pci/{host => controller}/pcie-rockchip.c   |0
 drivers/pci/{host => controller}/pcie-spear13xx.c  |0
 drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
 drivers/pci/{host => controller}/pcie-xilinx.c |0
 drivers/pci/{host => controller}/vmd.c |0
 44 files changed, 28 insertions(+), 28 deletions(-)
 rename drivers/pci/{host => controller}/Kconfig (100%)
 rename drivers/pci/{host => controller}/Makefile (100%)
 rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
 rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
 rename drivers/pci/{host => controller}/pci-exynos.c (100%)
 rename drivers/pci/{host => controller}/pci-host-common.c (100%)
 rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
 rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
 rename drivers/pci/{host => controller}/pci-imx6.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.h (100%)
 rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
 rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
 rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
 rename drivers/pci/{host => controller}/pci-tegra.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
 rename drivers/pci/{host => controller}/pci-versatile.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera.c (100%)
 rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
 rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
 rename 

[RFC PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

No functional change. Renamed the *host* directory present inside
drivers/pci to *controller*. Some of the controllers present in
drivers/pci/host is capable of operating in endpoint mode.
So having these drivers in *host* directory might not be appropriate.
This is in preparation for adding endpoint mode support for some of
controller drivers present here.

Signed-off-by: Kishon Vijay Abraham I 
---
 MAINTAINERS|   50 ++--
 drivers/Makefile   |3 ++
 drivers/pci/Kconfig|2 +-
 drivers/pci/Makefile   |3 --
 drivers/pci/{host => controller}/Kconfig   |   35 +-
 drivers/pci/{host => controller}/Makefile  |0
 drivers/pci/{host => controller}/pci-aardvark.c|0
 drivers/pci/{host => controller}/pci-dra7xx.c  |0
 drivers/pci/{host => controller}/pci-exynos.c  |0
 drivers/pci/{host => controller}/pci-host-common.c |0
 .../pci/{host => controller}/pci-host-generic.c|0
 drivers/pci/{host => controller}/pci-hyperv.c  |0
 drivers/pci/{host => controller}/pci-imx6.c|0
 drivers/pci/{host => controller}/pci-keystone-dw.c |0
 drivers/pci/{host => controller}/pci-keystone.c|0
 drivers/pci/{host => controller}/pci-keystone.h|0
 drivers/pci/{host => controller}/pci-layerscape.c  |0
 drivers/pci/{host => controller}/pci-mvebu.c   |0
 drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
 drivers/pci/{host => controller}/pci-tegra.c   |0
 .../pci/{host => controller}/pci-thunder-ecam.c|0
 drivers/pci/{host => controller}/pci-thunder-pem.c |0
 drivers/pci/{host => controller}/pci-versatile.c   |0
 drivers/pci/{host => controller}/pci-xgene-msi.c   |0
 drivers/pci/{host => controller}/pci-xgene.c   |0
 drivers/pci/{host => controller}/pcie-altera-msi.c |0
 drivers/pci/{host => controller}/pcie-altera.c |0
 drivers/pci/{host => controller}/pcie-armada8k.c   |0
 drivers/pci/{host => controller}/pcie-artpec6.c|0
 .../{host => controller}/pcie-designware-plat.c|0
 drivers/pci/{host => controller}/pcie-designware.c |0
 drivers/pci/{host => controller}/pcie-designware.h |0
 drivers/pci/{host => controller}/pcie-hisi.c   |0
 drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
 drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
 .../pci/{host => controller}/pcie-iproc-platform.c |0
 drivers/pci/{host => controller}/pcie-iproc.c  |0
 drivers/pci/{host => controller}/pcie-iproc.h  |0
 drivers/pci/{host => controller}/pcie-qcom.c   |0
 drivers/pci/{host => controller}/pcie-rcar.c   |0
 drivers/pci/{host => controller}/pcie-spear13xx.c  |0
 drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
 drivers/pci/{host => controller}/pcie-xilinx.c |0
 43 files changed, 62 insertions(+), 31 deletions(-)
 rename drivers/pci/{host => controller}/Kconfig (93%)
 rename drivers/pci/{host => controller}/Makefile (100%)
 rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
 rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
 rename drivers/pci/{host => controller}/pci-exynos.c (100%)
 rename drivers/pci/{host => controller}/pci-host-common.c (100%)
 rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
 rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
 rename drivers/pci/{host => controller}/pci-imx6.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.h (100%)
 rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
 rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
 rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
 rename drivers/pci/{host => controller}/pci-tegra.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
 rename drivers/pci/{host => controller}/pci-versatile.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera.c (100%)
 rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
 rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.h (100%)
 rename drivers/pci/{host => controller}/pcie-hisi.c (100%)
 rename drivers/pci/{host => controller}/pcie-iproc-bcma.c (100%)
 rename drivers/pci/{host => 

[RFC PATCH] pci: rename *host* directory to *controller*

[Kishon Vijay Abraham I]

No functional change. Renamed the *host* directory present inside
drivers/pci to *controller*. Some of the controllers present in
drivers/pci/host is capable of operating in endpoint mode.
So having these drivers in *host* directory might not be appropriate.
This is in preparation for adding endpoint mode support for some of
controller drivers present here.

Signed-off-by: Kishon Vijay Abraham I 
---
 MAINTAINERS|   50 ++--
 drivers/Makefile   |3 ++
 drivers/pci/Kconfig|2 +-
 drivers/pci/Makefile   |3 --
 drivers/pci/{host => controller}/Kconfig   |   35 +-
 drivers/pci/{host => controller}/Makefile  |0
 drivers/pci/{host => controller}/pci-aardvark.c|0
 drivers/pci/{host => controller}/pci-dra7xx.c  |0
 drivers/pci/{host => controller}/pci-exynos.c  |0
 drivers/pci/{host => controller}/pci-host-common.c |0
 .../pci/{host => controller}/pci-host-generic.c|0
 drivers/pci/{host => controller}/pci-hyperv.c  |0
 drivers/pci/{host => controller}/pci-imx6.c|0
 drivers/pci/{host => controller}/pci-keystone-dw.c |0
 drivers/pci/{host => controller}/pci-keystone.c|0
 drivers/pci/{host => controller}/pci-keystone.h|0
 drivers/pci/{host => controller}/pci-layerscape.c  |0
 drivers/pci/{host => controller}/pci-mvebu.c   |0
 drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
 drivers/pci/{host => controller}/pci-tegra.c   |0
 .../pci/{host => controller}/pci-thunder-ecam.c|0
 drivers/pci/{host => controller}/pci-thunder-pem.c |0
 drivers/pci/{host => controller}/pci-versatile.c   |0
 drivers/pci/{host => controller}/pci-xgene-msi.c   |0
 drivers/pci/{host => controller}/pci-xgene.c   |0
 drivers/pci/{host => controller}/pcie-altera-msi.c |0
 drivers/pci/{host => controller}/pcie-altera.c |0
 drivers/pci/{host => controller}/pcie-armada8k.c   |0
 drivers/pci/{host => controller}/pcie-artpec6.c|0
 .../{host => controller}/pcie-designware-plat.c|0
 drivers/pci/{host => controller}/pcie-designware.c |0
 drivers/pci/{host => controller}/pcie-designware.h |0
 drivers/pci/{host => controller}/pcie-hisi.c   |0
 drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
 drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
 .../pci/{host => controller}/pcie-iproc-platform.c |0
 drivers/pci/{host => controller}/pcie-iproc.c  |0
 drivers/pci/{host => controller}/pcie-iproc.h  |0
 drivers/pci/{host => controller}/pcie-qcom.c   |0
 drivers/pci/{host => controller}/pcie-rcar.c   |0
 drivers/pci/{host => controller}/pcie-spear13xx.c  |0
 drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
 drivers/pci/{host => controller}/pcie-xilinx.c |0
 43 files changed, 62 insertions(+), 31 deletions(-)
 rename drivers/pci/{host => controller}/Kconfig (93%)
 rename drivers/pci/{host => controller}/Makefile (100%)
 rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
 rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
 rename drivers/pci/{host => controller}/pci-exynos.c (100%)
 rename drivers/pci/{host => controller}/pci-host-common.c (100%)
 rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
 rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
 rename drivers/pci/{host => controller}/pci-imx6.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.h (100%)
 rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
 rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
 rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
 rename drivers/pci/{host => controller}/pci-tegra.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
 rename drivers/pci/{host => controller}/pci-versatile.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera.c (100%)
 rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
 rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.h (100%)
 rename drivers/pci/{host => controller}/pcie-hisi.c (100%)
 rename drivers/pci/{host => controller}/pcie-iproc-bcma.c (100%)
 rename drivers/pci/{host => controller}/pcie-iproc-msi.c