[PATCH] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

CI_DOMAINS selection to the sub-arch Kconfig entries, therefore fixing the build regression. Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test coverage") Link: https://lkml.kernel.org/r/20180612170229.ga10...@roeck-us.net Reported-by: Guenter Roeck Signed-off-by: Lorenzo

[PATCH] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

CI_DOMAINS selection to the sub-arch Kconfig entries, therefore fixing the build regression. Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test coverage") Link: https://lkml.kernel.org/r/20180612170229.ga10...@roeck-us.net Reported-by: Guenter Roeck Signed-off-by: Lorenzo

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Thu, May 24, 2018 at 11:55:35PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > > Sent: Thursday, May 24, 2018 05:41 > > On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > > > > > Before the guest finishes

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Thu, May 24, 2018 at 11:55:35PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi > > Sent: Thursday, May 24, 2018 05:41 > > On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > > > > > Before the guest finishes the device initialization, the

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

On Wed, May 23, 2018 at 11:44:25AM +0100, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

On Wed, May 23, 2018 at 11:44:25AM +0100, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote: > On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang > > > > Using irq_chip solution to setup IRQs in order to consist > > with IRQ framework. > > > >

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote: > On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang > > > > Using irq_chip solution to setup IRQs in order to consist > > with IRQ framework. > > > > Signed-off-by: Honghui Zhang >

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[+Robin] On Fri, May 18, 2018 at 12:48:28PM -0700, Ray Jui wrote: > Hi Lorenzo, > > On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote: > >On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: > >>On 2018-05-17 22:51, Ray Jui wrote: > >>>The i

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[+Robin] On Fri, May 18, 2018 at 12:48:28PM -0700, Ray Jui wrote: > Hi Lorenzo, > > On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote: > >On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: > >>On 2018-05-17 22:51, Ray Jui wrote: > >>>The i

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote: > On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang > > > > Using irq_chip solution to setup IRQs in order to consist > > with IRQ framework. > > > >

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote: > On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > > From: Honghui Zhang > > > > Using irq_chip solution to setup IRQs in order to consist > > with IRQ framework. > > > > Signed-off-by: Honghui Zhang >

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote: > > Hi Kishon, Gustavo, > > > > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > >> In

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote: > > Hi Kishon, Gustavo, > > > > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > >> In

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

Hi Kishon, Gustavo, On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > In order to be able to provide correct driver_data for pci_epf device, > a separate configfs entry for each pci_epf_device_id table entry in > pci_epf_driver is required. > > Add support to create

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

Hi Kishon, Gustavo, On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > In order to be able to provide correct driver_data for pci_epf device, > a separate configfs entry for each pci_epf_device_id table entry in > pci_epf_driver is required. > > Add support to create

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: > On 2018-05-17 22:51, Ray Jui wrote: > >The internal MSI parsing logic in certain revisions of PAXC root > >complexes does not work properly and can casue corruptions on the > >writes. They need to be disabled > > >

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: > On 2018-05-17 22:51, Ray Jui wrote: > >The internal MSI parsing logic in certain revisions of PAXC root > >complexes does not work properly and can casue corruptions on the > >writes. They need to be disabled > > >

Re: [PATCH v4] PCI: kirin: Add MSI support

On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote: > From: Yao Chen > > Add support for MSI. > > Signed-off-by: Yao Chen > Cc: Xiaowei Song > --- > drivers/pci/dwc/pcie-kirin.c | 51 >

Re: [PATCH v4] PCI: kirin: Add MSI support

On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote: > From: Yao Chen > > Add support for MSI. > > Signed-off-by: Yao Chen > Cc: Xiaowei Song > --- > drivers/pci/dwc/pcie-kirin.c | 51 > > 1 file changed, 51 insertions(+) > > diff --git

Re: [PATCH] pci: cadence: Host and EP driver updates for PHY and power management

On Wed, May 16, 2018 at 01:06:05PM +, Alan Douglas wrote: > From: Alan Douglas > > This patch is based on next branch in Bjorn Helgaas' linux-pci git repository. This sentence does not belong in a commit log and you should not be basing patches on top of Bjorn's next

Re: [PATCH] pci: cadence: Host and EP driver updates for PHY and power management

On Wed, May 16, 2018 at 01:06:05PM +, Alan Douglas wrote: > From: Alan Douglas > > This patch is based on next branch in Bjorn Helgaas' linux-pci git repository. This sentence does not belong in a commit log and you should not be basing patches on top of Bjorn's next branch, use v4.17-rc1,

Re: [PATCH v2 0/4] Add DesignWare EP support

On Tue, May 15, 2018 at 03:41:40PM +0100, Gustavo Pimentel wrote: > Patch set was made against the Lorenzo's pci/dwc branch. > > The PCIe controller dual mode is capable of operating in RC mode as well > as EP mode by configuration option. Till now only RC mode was supported, > with this patch is

Re: [PATCH v2 0/4] Add DesignWare EP support

On Tue, May 15, 2018 at 03:41:40PM +0100, Gustavo Pimentel wrote: > Patch set was made against the Lorenzo's pci/dwc branch. > > The PCIe controller dual mode is capable of operating in RC mode as well > as EP mode by configuration option. Till now only RC mode was supported, > with this patch is

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

ingoo Han <jingooh...@gmail.com> > > CC: Joao Pinto <joao.pi...@synopsys.com> > > CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> > > Acked-by: Jingoo Han <jingoo1...@gmail.com> &g

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

On Thu, May 03, 2018 at 10:18:24AM +0300, Vladimir Zapolskiy wrote: > Hi Jan, > > On 04/30/2018 08:48 AM, Jan Kiszka wrote: > > From: Jan Kiszka > > > > Straightforward for all of them, no more leaks afterwards. > > > > CC: Jingoo Han > > CC: Joao

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote: > pci_epf_test_write() is never called in atomic context. > > The call chain ending up at pci_epf_test_write() is: > [1] pci_epf_test_write() <- pci_epf_test_cmd_handler() > > pci_epf_test_cmd_handler() is set as a parameter of

Re: [PATCH v7 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

On Fri, May 04, 2018 at 01:47:31PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > Two fixups for mediatek's host bridge: > The first patch fixup class type and vendor ID for MT7622. > The second patch fixup the IRQ handle routine by using irq_chip

Re: [PATCH v7 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

On Fri, May 04, 2018 at 01:47:31PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > Two fixups for mediatek's host bridge: > The first patch fixup class type and vendor ID for MT7622. > The second patch fixup the IRQ handle routine by using irq_chip solution > to avoid IRQ

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Fri, May 04, 2018 at 11:28:58AM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Thursday 03 May 2018 07:46 PM, Lorenzo Pieralisi wrote: > > On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote: > > > > [...] > > > >>

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Fri, May 04, 2018 at 11:28:58AM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Thursday 03 May 2018 07:46 PM, Lorenzo Pieralisi wrote: > > On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote: > > > > [...] > > > >>

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote: [...] > >> Since the linkup notifier and BAR index (where auxiliary registers are > >> located) may be configurable and is something platform dependent, > >> perhaps the configuration of this variables should be done by

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote: [...] > >> Since the linkup notifier and BAR index (where auxiliary registers are > >> located) may be configurable and is something platform dependent, > >> perhaps the configuration of this variables should be done by

Re: [PATCH v8] PCI: hv: Make sure the bus domain is really unique

I removed this last paragraph, the information is in the stable tag below. > Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") > Signed-off-by: Sridhar Pitchai <sridhar.pitc...@microsoft.com> > Cc: sta...@vger.kernel.org # v4.14+ > Reviewed-by: Bjorn

Re: [PATCH v8] PCI: hv: Make sure the bus domain is really unique

I removed this last paragraph, the information is in the stable tag below. > Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") > Signed-off-by: Sridhar Pitchai > Cc: sta...@vger.kernel.org # v4.14+ > Reviewed-by: Bjorn Helgaas > > --- >

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Wed, May 02, 2018 at 11:39:00AM +0100, Gustavo Pimentel wrote: > Hi Lorenzo, > > On 01/05/2018 15:26, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> On Tuesday 01

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Wed, May 02, 2018 at 11:39:00AM +0100, Gustavo Pimentel wrote: > Hi Lorenzo, > > On 01/05/2018 15:26, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> On Tuesday 01

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> O

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote: > > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Lorenzo, > >> > >> O

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote: > > On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote: > >> Adds a seconds entry on the pci_epf_test_ids

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote: > > On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote: > >> Adds a seconds entry on the pci_epf_test_ids

Re: [PATCH v8 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Fri, Apr 27, 2018 at 12:59:58PM +0100, Gustavo Pimentel wrote: > Add a seconds entry on the pci_epf_test_ids structure that disables the "Add a second entry..." > linkup_notifier parameter on driver for the DesignWare EP. > > Allow DesignWare EPs that doesn't have linkup notification signal

Re: [PATCH v8 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Fri, Apr 27, 2018 at 12:59:58PM +0100, Gustavo Pimentel wrote: > Add a seconds entry on the pci_epf_test_ids structure that disables the "Add a second entry..." > linkup_notifier parameter on driver for the DesignWare EP. > > Allow DesignWare EPs that doesn't have linkup notification signal

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

odes instead of > >disabling them" Yes, I think that's the best course of action and it was the outcome of that email thread. Lorenzo > Thanks > Rohit > > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Sent: Thursday, April

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

odes instead of > >disabling them" Yes, I think that's the best course of action and it was the outcome of that email thread. Lorenzo > Thanks > Rohit > > From: Lorenzo Pieralisi > Sent: Thursday, April 26, 2018 3:18 AM > To: Catalin Mar

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote: > Adds a seconds entry on the pci_epf_test_ids structure that disables the "Add a second entry to..." > linkup_notifier parameter on driver for the designware EP. > > This allows designware EPs that doesn't have linkup

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote: > Adds a seconds entry on the pci_epf_test_ids structure that disables the "Add a second entry to..." > linkup_notifier parameter on driver for the designware EP. > > This allows designware EPs that doesn't have linkup

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote: > On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote: > > Adding few other folks. > > It looks fine to me but cc'ing Mark and Lorenzo (and it should have been > posted on linux-arm-ker...@lists.infradead.org). > > > From:

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote: > On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote: > > Adding few other folks. > > It looks fine to me but cc'ing Mark and Lorenzo (and it should have been > posted on linux-arm-ker...@lists.infradead.org). > > > From:

Re: [PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

On Tue, Apr 24, 2018 at 05:13:42PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > Required when running over Jailhouse, and there is already a physical > host controller that Jailhouse does not intercept and rather adds a > virtual one. That is the case for the Tegra

Re: [PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

On Tue, Apr 24, 2018 at 05:13:42PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > Required when running over Jailhouse, and there is already a physical > host controller that Jailhouse does not intercept and rather adds a > virtual one. That is the case for the Tegra TK1, e.g. > >

Re: [PATCH 1/6] PCI: Make pci_get_new_domain_nr static

pci.h | 3 --- > 2 files changed, 2 insertions(+), 7 deletions(-) Acked-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e597655a5643..695c2bb4e853 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c &

Re: [PATCH 1/6] PCI: Make pci_get_new_domain_nr static

compilation unit, pci_get_new_domain_nr() can be made static, which also simplifies preprocessor conditionals. No functional change intended." > Signed-off-by: Jan Kiszka > --- > drivers/pci/pci.c | 6 ++ > include/linux/pci.h | 3 --- > 2 files changed, 2 insertions(+), 7 dele

Re: [RFC 5/5] PCI: tegra: use seq_open_data

On Wed, Mar 07, 2018 at 12:41:05PM +, Lorenzo Pieralisi wrote: > On Fri, Mar 02, 2018 at 11:42:07AM +0100, Thierry Reding wrote: > > On Fri, Mar 02, 2018 at 12:37:24AM +0100, Rasmus Villemoes wrote: > > > Simplify the code slightly by having seq_open_data do the ->pri

Re: [RFC 5/5] PCI: tegra: use seq_open_data

On Wed, Mar 07, 2018 at 12:41:05PM +, Lorenzo Pieralisi wrote: > On Fri, Mar 02, 2018 at 11:42:07AM +0100, Thierry Reding wrote: > > On Fri, Mar 02, 2018 at 12:37:24AM +0100, Rasmus Villemoes wrote: > > > Simplify the code slightly by having seq_open_data do the ->pri

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Tue, Apr 17, 2018 at 09:17:36AM +0200, Daniel Lezcano wrote: [...] > Actually there is no impact with the change Sudeep is referring to. It > is for ACPI, we are DT based. Confirmed with Jeremy. > > So AFAICT, it is not a problem. > >>> > >>> It is a problem - DT or ACPI

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Tue, Apr 17, 2018 at 09:17:36AM +0200, Daniel Lezcano wrote: [...] > Actually there is no impact with the change Sudeep is referring to. It > is for ACPI, we are DT based. Confirmed with Jeremy. > > So AFAICT, it is not a problem. > >>> > >>> It is a problem - DT or ACPI

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Mon, Apr 16, 2018 at 03:57:03PM +0200, Daniel Lezcano wrote: > On 16/04/2018 14:30, Lorenzo Pieralisi wrote: > > On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote: > >> On 16/04/2018 12:10, Viresh Kumar wrote: > >>> On 16-04-18, 12:03, Daniel Lezcano

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Mon, Apr 16, 2018 at 03:57:03PM +0200, Daniel Lezcano wrote: > On 16/04/2018 14:30, Lorenzo Pieralisi wrote: > > On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote: > >> On 16/04/2018 12:10, Viresh Kumar wrote: > >>> On 16-04-18, 12:03, Daniel Lezcano

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote: > On 16/04/2018 12:10, Viresh Kumar wrote: > > On 16-04-18, 12:03, Daniel Lezcano wrote: > >> On 16/04/2018 11:50, Viresh Kumar wrote: > >>> On 16-04-18, 11:45, Daniel Lezcano wrote: > Can you elaborate a bit ? I'm not sure to

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote: > On 16/04/2018 12:10, Viresh Kumar wrote: > > On 16-04-18, 12:03, Daniel Lezcano wrote: > >> On 16/04/2018 11:50, Viresh Kumar wrote: > >>> On 16-04-18, 11:45, Daniel Lezcano wrote: > Can you elaborate a bit ? I'm not sure to

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

On Thu, Apr 12, 2018 at 03:56:42PM +, Sridhar Pitchai wrote: > > > > >> I am still not happy with this patch. > > >> > > >> - You do not explain at all the dependency on commit > 0c195567a8f6 and > > >>you should because that's fundamental, if that

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

On Thu, Apr 12, 2018 at 03:56:42PM +, Sridhar Pitchai wrote: > > > > >> I am still not happy with this patch. > > >> > > >> - You do not explain at all the dependency on commit > 0c195567a8f6 and > > >>you should because that's fundamental, if that

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

On Thu, Apr 12, 2018 at 02:44:42AM +, Sridhar Pitchai wrote: > When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI > bus to the guest, Hyper-V always provides unique PCI domain. > > commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") > overrode unique

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

On Thu, Apr 12, 2018 at 02:44:42AM +, Sridhar Pitchai wrote: > When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI > bus to the guest, Hyper-V always provides unique PCI domain. > > commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") > overrode unique

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

On Tue, Apr 10, 2018 at 08:59:30AM +0100, Gustavo Pimentel wrote: > Hi Lorenzo, > > On 09/04/2018 17:03, Lorenzo Pieralisi wrote: > > On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote: > >> Adds a callback that defines the maximum number of vectors that can

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

On Tue, Apr 10, 2018 at 08:59:30AM +0100, Gustavo Pimentel wrote: > Hi Lorenzo, > > On 09/04/2018 17:03, Lorenzo Pieralisi wrote: > > On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote: > >> Adds a callback that defines the maximum number of vectors that can

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote: > Adds a callback that defines the maximum number of vectors that can be use > by the Root Complex. > > Since this is a parameter associated to each SoC IP setting, makes sense to > be configurable and easily visible to future

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote: > Adds a callback that defines the maximum number of vectors that can be use > by the Root Complex. > > Since this is a parameter associated to each SoC IP setting, makes sense to > be configurable and easily visible to future

Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[+cc Robin] On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote: > If SMMU probe failed, master should use swiotlb as dma ops. > SMMU may probe failed with specified environment, so there > are not any iommu resources in iommu_device_list. > > The master will always get EPROBE_DEFER

Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[+cc Robin] On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote: > If SMMU probe failed, master should use swiotlb as dma ops. > SMMU may probe failed with specified environment, so there > are not any iommu resources in iommu_device_list. > > The master will always get EPROBE_DEFER

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

On Wed, Mar 28, 2018 at 12:38:33PM +0100, Gustavo Pimentel wrote: Please always write a commit log even if it is trivial. Thanks, Lorenzo > Signed-off-by: Gustavo Pimentel > --- > Documentation/devicetree/bindings/pci/designware-pcie.txt | 13 + > 1

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

On Wed, Mar 28, 2018 at 12:38:33PM +0100, Gustavo Pimentel wrote: Please always write a commit log even if it is trivial. Thanks, Lorenzo > Signed-off-by: Gustavo Pimentel > --- > Documentation/devicetree/bindings/pci/designware-pcie.txt | 13 + > 1 file changed, 13 insertions(+)

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

On Tue, Apr 03, 2018 at 09:15:11AM +0800, Hanjun Guo wrote: > [+Cc Lorenzo] > > Hi Neil, > > On 2018/4/3 1:59, Neil Leeder wrote: > > Hi Hanjun, > > > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > > > >> > >> I think we need to wait for the new version of IORT spec, > >> which includes the fix

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

On Tue, Apr 03, 2018 at 09:15:11AM +0800, Hanjun Guo wrote: > [+Cc Lorenzo] > > Hi Neil, > > On 2018/4/3 1:59, Neil Leeder wrote: > > Hi Hanjun, > > > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > > > >> > >> I think we need to wait for the new version of IORT spec, > >> which includes the fix

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote: > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: > > > Since a 64-bit BAR consists of a BAR pair, we need to write to both > > > BARs

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote: > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: > > > Since a 64-bit BAR consists of a BAR pair, we need to write to both > > > BARs

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

s, that's why I asked and I will ask again, are you sure you won't trigger a regression by sending this fix to stable ? I assume the bond driver mechanism is now done and dusted. Thanks, Lorenzo > Thanks, > Sridhar > > On 3/20/18, 11:32 AM, "Lorenzo Pieralisi" <lorenzo.pie

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

s, that's why I asked and I will ask again, are you sure you won't trigger a regression by sending this fix to stable ? I assume the bond driver mechanism is now done and dusted. Thanks, Lorenzo > Thanks, > Sridhar > > On 3/20/18, 11:32 AM, "Lorenzo Pieralisi" wrote:

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote: > Hi Lorenzo, > Are we good with the explanation? Can I send the patch with the > updated commit comments? Almost. [...] > Since we have the transparent SRIOV mode now, the short VF device name > is no longer needed. Can

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote: > Hi Lorenzo, > Are we good with the explanation? Can I send the patch with the > updated commit comments? Almost. [...] > Since we have the transparent SRIOV mode now, the short VF device name > is no longer needed. Can

Re: [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes

On Thu, Mar 08, 2018 at 02:33:25PM +0100, Niklas Cassel wrote: > PCI endpoint fixes to improve the way 64-bit BARs are handled. > > > There are still future improvements that could be made: > > pci-epf-test.c always allocates space for > 6 BARs, even when using 64-bit BARs (which > really only

Re: [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes

On Thu, Mar 08, 2018 at 02:33:25PM +0100, Niklas Cassel wrote: > PCI endpoint fixes to improve the way 64-bit BARs are handled. > > > There are still future improvements that could be made: > > pci-epf-test.c always allocates space for > 6 BARs, even when using 64-bit BARs (which > really only

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Sat, Mar 17, 2018 at 01:55:13AM +0100, Niklas Cassel wrote: > On Fri, Mar 16, 2018 at 06:02:20PM +0000, Lorenzo Pieralisi wrote: > > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > > > If a BAR supports 64-bit width or not depends on the hardware, >

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Sat, Mar 17, 2018 at 01:55:13AM +0100, Niklas Cassel wrote: > On Fri, Mar 16, 2018 at 06:02:20PM +0000, Lorenzo Pieralisi wrote: > > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > > > If a BAR supports 64-bit width or not depends on the hardware, >

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > > Sent: Friday, March 16, 2018 03:54 > > ... > > Dexuan, > > while applying/updating these patches I notice this one may be squashed > >

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi > > Sent: Friday, March 16, 2018 03:54 > > ... > > Dexuan, > > while applying/updating these patches I notice this one may be squashed > > into: https://patchwork.ozl

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > If a BAR supports 64-bit width or not depends on the hardware, > and should thus not depend on sizeof(dma_addr_t). > > Since this driver is generic, default to always using BAR width > of 32-bits. 64-bit BARs can easily be tested by

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > If a BAR supports 64-bit width or not depends on the hardware, > and should thus not depend on sizeof(dma_addr_t). > > Since this driver is generic, default to always using BAR width > of 32-bits. 64-bit BARs can easily be tested by

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

On Wed, Jan 03, 2018 at 02:39:04PM +0800, Honghui Zhang wrote: > On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote: > > On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote: > > > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote: > > > > On W

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

On Wed, Jan 03, 2018 at 02:39:04PM +0800, Honghui Zhang wrote: > On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote: > > On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote: > > > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote: > > > > On W

<    6   7   8   9   10   11   12   13   14   15   >