* [PATCH 23/25] powerpc/powernv: pci_domain_nr() not reliable
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
If the PE contains single PCI function, "pe->pbus" would be NULL.
It's not reliable to be used by pci_domain_nr(). We just grab the
PCI domain number from the PCI host controller (struct pci_controller)
instance.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1934327..9807341 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -673,7 +673,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
TCE_PCI_SWINV_PAIR);
}
iommu_init_table(tbl, phb->hose->node);
- iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
+ iommu_register_group(tbl, phb->hose->global_number, pe->pe_number);
if (pe->pdev)
set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
@@ -801,7 +801,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
}
iommu_init_table(tbl, phb->hose->node);
- iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
+ iommu_register_group(tbl, phb->hose->global_number, pe->pe_number);
if (pe->pdev)
set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 24/25] PCI: Fix return value from pci_user_{read, write}_config_*()
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
PCI accessors from user space pci_user_{read,write}_config_*()
return negative error number, which was introduced by commit
34e32072 ("PCI: handle positive error codes"). That patch coverts
all positive error numbers from platform specific PCI config
accessors to -EINVAL. The upper layer calling to those PCI config
accessors hardly know the specific cause from the return value
when hitting failures.
The patch fixes the issue by doing the conversion (from positive
to negative) using existing function pcibios_err_to_errno().
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/pci/access.c | 12 ++++--------
include/linux/pci.h | 6 ++++--
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 7f8b78c..8c148f3 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -148,7 +148,7 @@ static noinline void pci_wait_cfg(struct pci_dev *dev)
int pci_user_read_config_##size \
(struct pci_dev *dev, int pos, type *val) \
{ \
- int ret = 0; \
+ int ret = PCIBIOS_SUCCESSFUL; \
u32 data = -1; \
if (PCI_##size##_BAD) \
return -EINVAL; \
@@ -159,9 +159,7 @@ int pci_user_read_config_##size \
pos, sizeof(type), &data); \
raw_spin_unlock_irq(&pci_lock); \
*val = (type)data; \
- if (ret > 0) \
- ret = -EINVAL; \
- return ret; \
+ return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
@@ -170,7 +168,7 @@ EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
int pci_user_write_config_##size \
(struct pci_dev *dev, int pos, type val) \
{ \
- int ret = -EIO; \
+ int ret = PCIBIOS_SUCCESSFUL; \
if (PCI_##size##_BAD) \
return -EINVAL; \
raw_spin_lock_irq(&pci_lock); \
@@ -179,9 +177,7 @@ int pci_user_write_config_##size \
ret = dev->bus->ops->write(dev->bus, dev->devfn, \
pos, sizeof(type), val); \
raw_spin_unlock_irq(&pci_lock); \
- if (ret > 0) \
- ret = -EINVAL; \
- return ret; \
+ return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_write_config_##size);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..1682cb1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -518,7 +518,7 @@ static inline int pcibios_err_to_errno(int err)
case PCIBIOS_FUNC_NOT_SUPPORTED:
return -ENOENT;
case PCIBIOS_BAD_VENDOR_ID:
- return -EINVAL;
+ return -ENOTTY;
case PCIBIOS_DEVICE_NOT_FOUND:
return -ENODEV;
case PCIBIOS_BAD_REGISTER_NUMBER:
@@ -527,9 +527,11 @@ static inline int pcibios_err_to_errno(int err)
return -EIO;
case PCIBIOS_BUFFER_TOO_SMALL:
return -ENOSPC;
+ default:
+ return -err;
}
- return -ENOTTY;
+ return -ERANGE;
}
/* Low-level architecture-dependent routines */
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 8:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <20140423185534.GA26756@n2100.arm.linux.org.uk>
On 23 April 2014 20:55, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appears to be a hardware issue preventing it working reliably.
>
> In any case, patches 0-33 inclusive are the SDHCI clean up, based against
> v3.15-rc1. Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
> those, and 38 adds the Broadcom Wifi and BT support for CuBox.
>
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards. As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them with a view to getting them merged.
>
I have looked though the patches up until patch 33 and this is clearly
a nice piece of clean-up /fixes work for sdhci. Besides my minor
comments per patch, I don't have any objections code-review wise to
proceed merging them.
I have also tried to applied them on Chris' mmc-next branch,
unfortunate it fails at patch 23, so it would be nice to get a
re-based patchset for the mmc-next branch.
Kind regards
Ulf Hansson
> Documentation/devicetree/bindings/mmc/mmc.txt | 11 +
> arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 34 +-
> arch/arm/boot/dts/imx6qdl-microsom.dtsi | 98 ++++
> drivers/mmc/core/core.c | 42 ++
> drivers/mmc/core/host.c | 68 +++
> drivers/mmc/core/sdio_irq.c | 41 +-
> drivers/mmc/host/Kconfig | 63 +--
> drivers/mmc/host/dw_mmc.c | 2 +
> drivers/mmc/host/sdhci-acpi.c | 8 +
> drivers/mmc/host/sdhci-bcm-kona.c | 4 +
> drivers/mmc/host/sdhci-bcm2835.c | 4 +
> drivers/mmc/host/sdhci-cns3xxx.c | 13 +-
> drivers/mmc/host/sdhci-dove.c | 4 +
> drivers/mmc/host/sdhci-esdhc-imx.c | 82 +--
> drivers/mmc/host/sdhci-esdhc.h | 4 +-
> drivers/mmc/host/sdhci-of-arasan.c | 4 +
> drivers/mmc/host/sdhci-of-esdhc.c | 70 ++-
> drivers/mmc/host/sdhci-of-hlwd.c | 4 +
> drivers/mmc/host/sdhci-pci.c | 9 +-
> drivers/mmc/host/sdhci-pltfm.c | 4 +
> drivers/mmc/host/sdhci-pxav2.c | 14 +-
> drivers/mmc/host/sdhci-pxav3.c | 13 +-
> drivers/mmc/host/sdhci-s3c.c | 36 +-
> drivers/mmc/host/sdhci-sirf.c | 4 +
> drivers/mmc/host/sdhci-spear.c | 5 +-
> drivers/mmc/host/sdhci-tegra.c | 27 +-
> drivers/mmc/host/sdhci.c | 728 +++++++++++++-------------
> drivers/mmc/host/sdhci.h | 20 +-
> include/linux/mmc/host.h | 8 +
> include/linux/mmc/sdhci.h | 15 +-
> 30 files changed, 885 insertions(+), 554 deletions(-)
>
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Leif Lindholm @ 2014-04-24 9:26 UTC (permalink / raw)
To: Grant Likely, Mark Rutland
Cc: devicetree@vger.kernel.org, patches@linaro.org, Lee Jones,
linux-kernel@vger.kernel.org, Rob Herring, Geert Uytterhoeven,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140423131058.D94B6C408D2@trevor.secretlab.ca>
On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > compatible string? From grepping through the kernel I could only find a
> > model string ("IBM,LongTrail").
>
> Actually, on LongTrail this can be removed from the common code
> entirely. It has real open firmware and PowerPC already has the
> infrastructure for fixing up the device tree.
>
> Here's a draft patch that I've compile tested, but nothing else.
I would certainly be happy with that.
Consider my 3/3 withdrawn.
And if the kernel proper will stop honoring nodes with no type,
there is no need for the stub to treat those specially either.
/
Leif
> g.
>
> ---
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 078145acf7fb..18b2c3fee98f 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2587,9 +2587,18 @@ static void __init fixup_device_tree_chrp(void)
> phandle ph;
> u32 prop[6];
> u32 rloc = 0x01006000; /* IO space; PCI device = 12 */
> - char *name;
> + char *name, strprop[16];
> int rc;
>
> + /* Deal with missing device_type in LongTrail memory node */
> + name = "/memory@0";
> + ph = call_prom("finddevice", 1, 1, ADDR(name));
> + rc = prom_getprop(ph, "device_type", strprop, sizeof(strprop));
> + if (rc == PROM_ERROR || strcmp(strprop, "memory") != 0) {
> + prom_printf("Fixing up missing device_type on /memory@0 node...\n");
> + prom_setprop(ph, name, "device_type", "memory", sizeof("memory"));
> + }
> +
> name = "/pci@80000000/isa@c";
> ph = call_prom("finddevice", 1, 1, ADDR(name));
> if (!PHANDLE_VALID(ph)) {
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 7a2ef7bb8022..7cda0d279cbe 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -886,14 +886,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
> unsigned long l;
>
> /* We are scanning "memory" nodes only */
> - if (type == NULL) {
> - /*
> - * The longtrail doesn't have a device_type on the
> - * /memory node, so look for the node called /memory@0.
> - */
> - if (depth != 1 || strcmp(uname, "memory@0") != 0)
> - return 0;
> - } else if (strcmp(type, "memory") != 0)
> + if (!type || strcmp(type, "memory") != 0)
> return 0;
>
> reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
>
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-24 10:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFozP69yngKAkdwHYyyvi+pdLEm05udOmBiVshQFi4hnLQ@mail.gmail.com>
On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
>
> I have also tried to applied them on Chris' mmc-next branch,
> unfortunate it fails at patch 23, so it would be nice to get a
> re-based patchset for the mmc-next branch.
I /could/ rebase it but then I wouldn't be able to produce the patch
sets/patches for others [*] (such as the Novena project) to derive
their kernel tree from my iMX6 patch set.
What I'd prefer is to keep the patch set intact, and provide Chris
with a pull request for it up to patch 33, which would need a
conflict fixed - and this would mean that I can be sure that what
I'm testing, and what I'm distributing is what Chris will also be
submitting.
* - this currently stands at 230 patches in all - mmc + l2c + fec +
imx-drm + other iMX6 changes.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux, Chris Ball
Cc: Mark Rutland, Anton Vorontsov, linux-doc, Seungwon Jeon,
Thierry Reding, Ian Campbell, Michal Simek, Jaehoon Chung,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Pawel Moll, Stephen Warren, spear-devel, Rob Herring, Ben Dooks,
linux-tegra@vger.kernel.org, Shawn Guo, Barry Song, Randy Dunlap,
linux-mmc, Viresh Kumar, Sascha Hauer, Kumar Gala, linuxppc-dev
In-Reply-To: <20140424101726.GH26756@n2100.arm.linux.org.uk>
On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> I have looked though the patches up until patch 33 and this is clearly
>> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> comments per patch, I don't have any objections code-review wise to
>> proceed merging them.
>>
>> I have also tried to applied them on Chris' mmc-next branch,
>> unfortunate it fails at patch 23, so it would be nice to get a
>> re-based patchset for the mmc-next branch.
>
> I /could/ rebase it but then I wouldn't be able to produce the patch
> sets/patches for others [*] (such as the Novena project) to derive
> their kernel tree from my iMX6 patch set.
>
> What I'd prefer is to keep the patch set intact, and provide Chris
> with a pull request for it up to patch 33, which would need a
> conflict fixed - and this would mean that I can be sure that what
> I'm testing, and what I'm distributing is what Chris will also be
> submitting.
Whether there are more than one conflict, I don't know. I just stopped
at patch 23.
Moreover, there are other patches for sdhci that have been posted and
being discussed. In principle, we then need to put all these on hold
to prevent further conflicts. I guess that doable, as long as we don't
to that for too long. Maybe Chris have some more thoughts how to
handle this!?
Kind regards
Ulf Hansson
>
> * - this currently stands at 230 patches in all - mmc + l2c + fec +
> imx-drm + other iMX6 changes.
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-24 10:57 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFrGReKF0ucer7D195boEoQW26=4vDXT+=Wn6BO-p_B1gQ@mail.gmail.com>
On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> >> comments per patch, I don't have any objections code-review wise to
> >> proceed merging them.
> >>
> >> I have also tried to applied them on Chris' mmc-next branch,
> >> unfortunate it fails at patch 23, so it would be nice to get a
> >> re-based patchset for the mmc-next branch.
> >
> > I /could/ rebase it but then I wouldn't be able to produce the patch
> > sets/patches for others [*] (such as the Novena project) to derive
> > their kernel tree from my iMX6 patch set.
> >
> > What I'd prefer is to keep the patch set intact, and provide Chris
> > with a pull request for it up to patch 33, which would need a
> > conflict fixed - and this would mean that I can be sure that what
> > I'm testing, and what I'm distributing is what Chris will also be
> > submitting.
>
> Whether there are more than one conflict, I don't know. I just stopped
> at patch 23.
>
> Moreover, there are other patches for sdhci that have been posted and
> being discussed. In principle, we then need to put all these on hold
> to prevent further conflicts. I guess that doable, as long as we don't
> to that for too long. Maybe Chris have some more thoughts how to
> handle this!?
This is nothing new or unexpected - it was last posted back in February,
and I elected that it should be held off until after the last merge
window.
Unfortunately, I didn't have time to post it immediately after the merge
window closed, partly because it needed to be rebased on top of tglx's
IRQ changes on which it depends. I was carrying those as separate commits
to the ones Thomas was carrying in his tree - and in the event, Thomas had
modified his patches slightly between sending me copies of them and the
versions he sent during the merge window.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 11:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <20140424105745.GM26756@n2100.arm.linux.org.uk>
On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> >> I have looked though the patches up until patch 33 and this is clearly
>> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> >> comments per patch, I don't have any objections code-review wise to
>> >> proceed merging them.
>> >>
>> >> I have also tried to applied them on Chris' mmc-next branch,
>> >> unfortunate it fails at patch 23, so it would be nice to get a
>> >> re-based patchset for the mmc-next branch.
>> >
>> > I /could/ rebase it but then I wouldn't be able to produce the patch
>> > sets/patches for others [*] (such as the Novena project) to derive
>> > their kernel tree from my iMX6 patch set.
>> >
>> > What I'd prefer is to keep the patch set intact, and provide Chris
>> > with a pull request for it up to patch 33, which would need a
>> > conflict fixed - and this would mean that I can be sure that what
>> > I'm testing, and what I'm distributing is what Chris will also be
>> > submitting.
>>
>> Whether there are more than one conflict, I don't know. I just stopped
>> at patch 23.
>>
>> Moreover, there are other patches for sdhci that have been posted and
>> being discussed. In principle, we then need to put all these on hold
>> to prevent further conflicts. I guess that doable, as long as we don't
>> to that for too long. Maybe Chris have some more thoughts how to
>> handle this!?
>
> This is nothing new or unexpected - it was last posted back in February,
> and I elected that it should be held off until after the last merge
> window.
>
> Unfortunately, I didn't have time to post it immediately after the merge
> window closed, partly because it needed to be rebased on top of tglx's
> IRQ changes on which it depends. I was carrying those as separate commits
> to the ones Thomas was carrying in his tree - and in the event, Thomas had
> modified his patches slightly between sending me copies of them and the
> versions he sent during the merge window.
Okay, so let's keep up the frequency here then. I only had some minor
comments, please fix them and send a v2.
How about if I resolve the conflicts and send the pull request to
Chris? I suppose it makes life a bit easier for Chris.
Kind regards
Ulf Hansson
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-24 18:46 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <30c9d29df995426d9e01ffdf09fb1f33@BN1PR03MB188.namprd03.prod.outlook.com>
On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, April 17, 2014 3:36 AM
> > To: Wang Dongsheng-B40534
> > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > for platform
> >
> > On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, April 16, 2014 3:39 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha
> > > > Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular
> > > > initialization for platform
> > > >
> > > > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > >
> > > > > Corenet_generic is a generic platform initialization. Those based
> > > > > on the corenet_generic board maybe need a particular initialize to
> > > > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to
> > > > > solve this kind of special cases.
> > > >
> > > > I still don't understand what you mean by "fix". What are you
> > > > fixing, or what is fixed?
> > > >
> > > > There is no need for adding an infrastructure layer here. Just add
> > > > a new piece of code for t104x diu, and have it be called by an
> > > > appropriate initfunc.
> > > >
> > >
> > > "fix" is means to handle some boards those based on corenet_generic
> > > config file, But those boards may need some special handle. Perhaps
> > > these used to handle special feature codes not have an appropriate
> > > initfunc we cannot *just find* an appropriate place,
> >
> > I'm not asking you to "just find" anything. I'm asking you to add an initfunc
> > in a standalone file.
> >
> > > if more and more boards need to do this, at that time maybe *initfunc*
> > > looks very complicated.
> >
> > They would each have their own initfunc. There is no reason to tie this in with
> > anything else.
> >
>
> Sorry, if those platforms are using corenet_generic, I don’t see any standalone file
> for initfunc of platform. That's why I'm adding "fix" layer.
It's totally unnecessary.
Just do this:
t104x_diu_init(void)
{
if (t104x diu not in the device tree)
return;
...
}
early_initcall(t104x_diu_init);
> > > > > +config FIX_GENERIC_PLATFORM_INIT
> > > > > + bool "Fix Generic Initialization"
> > > > > + depends on CORENET_GENERIC
> > > >
> > > > Why does this depend on CORENET_GENERIC?
> > > >
> > >
> > > Because CORENET_GENERIC is a multiboards file, This is designed to handle this
> > situation.
> >
> > This DIU code is going to be just as applicable to a custom T104x board which
> > may or may not use CORENET_GENERIC.
> >
>
> "fix" is a middle layer, it's not only for T104xrdb-DIU.
My point is a custom t104x board might not use CORENET_GENERIC.
> > > > > + default y
> > > >
> > > > No.
> > > >
> > >
> > > Why not? This will not increase any redundant operations if there is not any
> > boards need fix.
> > > You can see my fix.c code.
> >
> > default y should not be used for hardware specific code.
> >
>
> fix.c and hardware no relationship at all. :), It's just a software layer.
No relationship to hardware, yet it depends on CORENET_GENERIC, reads a
Freescale-specific SPR, and lives in arch/powerpc/platforms/85xx. :-)
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-24 18:47 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <1398365188.7841.154.camel@snotra.buserror.net>
On Thu, 2014-04-24 at 13:46 -0500, Scott Wood wrote:
> On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Thursday, April 17, 2014 3:36 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > > for platform
> > >
> > > On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, April 16, 2014 3:39 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha
> > > > > Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular
> > > > > initialization for platform
> > > > >
> > > > > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > >
> > > > > > Corenet_generic is a generic platform initialization. Those based
> > > > > > on the corenet_generic board maybe need a particular initialize to
> > > > > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to
> > > > > > solve this kind of special cases.
> > > > >
> > > > > I still don't understand what you mean by "fix". What are you
> > > > > fixing, or what is fixed?
> > > > >
> > > > > There is no need for adding an infrastructure layer here. Just add
> > > > > a new piece of code for t104x diu, and have it be called by an
> > > > > appropriate initfunc.
> > > > >
> > > >
> > > > "fix" is means to handle some boards those based on corenet_generic
> > > > config file, But those boards may need some special handle. Perhaps
> > > > these used to handle special feature codes not have an appropriate
> > > > initfunc we cannot *just find* an appropriate place,
> > >
> > > I'm not asking you to "just find" anything. I'm asking you to add an initfunc
> > > in a standalone file.
> > >
> > > > if more and more boards need to do this, at that time maybe *initfunc*
> > > > looks very complicated.
> > >
> > > They would each have their own initfunc. There is no reason to tie this in with
> > > anything else.
> > >
> >
> > Sorry, if those platforms are using corenet_generic, I don’t see any standalone file
> > for initfunc of platform. That's why I'm adding "fix" layer.
>
> It's totally unnecessary.
>
> Just do this:
>
> t104x_diu_init(void)
> {
s/t104x_diu_init/static void t104x_diu_init/ of course.
-Scott
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-25 9:03 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFr=2=dg1NTYb1_EAgxXZq2Rd+o2Q2B5TE+GZwr8MUU1_Q@mail.gmail.com>
On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > This is nothing new or unexpected - it was last posted back in February,
> > and I elected that it should be held off until after the last merge
> > window.
> >
> > Unfortunately, I didn't have time to post it immediately after the merge
> > window closed, partly because it needed to be rebased on top of tglx's
> > IRQ changes on which it depends. I was carrying those as separate commits
> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
> > modified his patches slightly between sending me copies of them and the
> > versions he sent during the merge window.
>
> Okay, so let's keep up the frequency here then. I only had some minor
> comments, please fix them and send a v2.
Right, so I've updated the patches, and added one ack to one patch.
That seems insufficient to me - the only platform these have been
tested on is iMX6, which is sdhci-esdhc-imx.c.
They _really_ need testing elsewhere too. Or is the plan to merge
them and then see about getting people to test them and fix them up
afterwards?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* [PATCH 05/13] IA64/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/ia64/pci/fixup.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..1fe9aa5 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -49,9 +49,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
* type BRIDGE, or CARDBUS. Host to PCI controllers use
* PCI header type NORMAL.
*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
+ if (bridge && (pci_is_bridge(bridge))) {
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&config);
if (!(config & PCI_BRIDGE_CTL_VGA))
--
1.7.1
^ permalink raw reply related
* [PATCH 09/13] PCI, shpchp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/shpchp_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/shpchp_pci.c b/drivers/pci/hotplug/shpchp_pci.c
index 2bf69fe..ea8ad31 100644
--- a/drivers/pci/hotplug/shpchp_pci.c
+++ b/drivers/pci/hotplug/shpchp_pci.c
@@ -64,8 +64,7 @@ int __ref shpchp_configure_device(struct slot *p_slot)
list_for_each_entry(dev, &parent->devices, bus_list) {
if (PCI_SLOT(dev->devfn) != p_slot->device)
continue;
- if ((dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) ||
- (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS))
+ if (pci_is_bridge(dev))
pci_hp_add_bridge(dev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 11/13] PCI, acpiphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/acpiphp_glue.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index bccc27e..f1f9bd1 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -516,8 +516,7 @@ static void __ref enable_slot(struct acpiphp_slot *slot)
if (PCI_SLOT(dev->devfn) != slot->device)
continue;
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
max = pci_scan_bridge(bus, dev, max, pass);
if (pass && dev->subordinate) {
check_hotplug_bridge(slot, dev);
--
1.7.1
^ permalink raw reply related
* [PATCH 06/13] powerpc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-hotplug.c b/arch/powerpc/kernel/pci-hotplug.c
index c1e17ae..5b78917 100644
--- a/arch/powerpc/kernel/pci-hotplug.c
+++ b/arch/powerpc/kernel/pci-hotplug.c
@@ -98,8 +98,7 @@ void pcibios_add_pci_devices(struct pci_bus * bus)
max = bus->busn_res.start;
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
max = pci_scan_bridge(bus, dev,
max, pass);
}
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 83c26d8..059e244 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -362,8 +362,7 @@ static void __of_scan_bus(struct device_node *node, struct pci_bus *bus,
/* Now scan child busses */
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
of_scan_pci_bridge(dev);
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH 01/13] PCI: rename pci_is_bridge() to pci_has_subordinate()
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
pci_is_bridge() which seems to determine whether device is a bridge,
returns true only when the subordinate bus exists. This confuses
people. PCI device is a bridge means its header type(bit 0 through 6)
is 0x1(PCI bridge) or 0x2(CardBus bridge). Rename the current
pci_is_bridge() helper function to pci_has_subordinate().
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d911e0c..b7850cb 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -580,14 +580,14 @@ static void pci_pm_default_resume(struct pci_dev *pci_dev)
{
pci_fixup_device(pci_fixup_resume, pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_enable_wake(pci_dev, PCI_D0, false);
}
static void pci_pm_default_suspend(struct pci_dev *pci_dev)
{
/* Disable non-bridge devices without PM support */
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_disable_enabled_device(pci_dev);
}
@@ -717,7 +717,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
if (!pci_dev->state_saved) {
pci_save_state(pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
}
@@ -971,7 +971,7 @@ static int pci_pm_poweroff_noirq(struct device *dev)
return error;
}
- if (!pci_dev->state_saved && !pci_is_bridge(pci_dev))
+ if (!pci_dev->state_saved && !pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
/*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 6bd0822..65108fc 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -77,7 +77,7 @@ static inline void pci_wakeup_event(struct pci_dev *dev)
pm_wakeup_event(&dev->dev, 100);
}
-static inline bool pci_is_bridge(struct pci_dev *pci_dev)
+static inline bool pci_has_subordinate(struct pci_dev *pci_dev)
{
return !!(pci_dev->subordinate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 04/13] x86/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/x86/pci/fixup.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 94ae9ae..e5f000c 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -337,9 +337,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
* type BRIDGE, or CARDBUS. Host to PCI controllers use
* PCI header type NORMAL.
*/
- if (bridge
- && ((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- || (bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
+ if (bridge && (pci_is_bridge(bridge))) {
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&config);
if (!(config & PCI_BRIDGE_CTL_VGA))
--
1.7.1
^ permalink raw reply related
* [PATCH 00/13] Refactor pci_is_brdige() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev->hdr_type. The new one is more accurate. PCIe Spec define the pci
device is a bridge by the dev->hdr_type = 0x01 || 0x02.
Yijing Wang (13):
PCI: rename pci_is_bridge() to pci_has_subordinate()
PCI: Introduce new pci_is_bridge() helper function
PCI: Use new pci_is_bridge() to simplify code
x86/PCI: Use new pci_is_bridge() to simplify code
IA64/PCI: Use new pci_is_bridge() to simplify code
powerpc/PCI: Use new pci_is_bridge() to simplify code
sparc/PCI: Use new pci_is_bridge() to simplify code
PCI, rpaphp: Use new pci_is_bridge() to simplify code
PCI, shpchp: Use new pci_is_bridge() to simplify code
PCI, cpcihp: Use new pci_is_bridge() to simplify code
PCI, acpiphp: Use new pci_is_bridge() to simplify code
PCI, pcmcia: Use new pci_is_bridge() to simplify code
PCI, pciehp: Use new pci_is_bridge() to simplify code
arch/ia64/pci/fixup.c | 4 +---
arch/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
arch/sparc/kernel/pci.c | 3 +--
arch/x86/pci/fixup.c | 4 +---
drivers/pci/hotplug/acpiphp_glue.c | 3 +--
drivers/pci/hotplug/cpci_hotplug_pci.c | 3 +--
drivers/pci/hotplug/pciehp_pci.c | 3 +--
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
drivers/pci/hotplug/shpchp_pci.c | 3 +--
drivers/pci/pci-acpi.c | 8 +-------
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 3 +--
drivers/pci/setup-bus.c | 4 +---
drivers/pcmcia/cardbus.c | 3 +--
include/linux/pci.h | 6 ++++++
17 files changed, 25 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH 02/13] PCI: Introduce new pci_is_bridge() helper function
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
PCIe Spec define the PCI bridge is the PCI device
which header type(bit 0 through 6) is 0x1(PCI bridge)
or 0x2(CardBus bridge).
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
include/linux/pci.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..827077a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -477,6 +477,12 @@ static inline bool pci_is_root_bus(struct pci_bus *pbus)
return !(pbus->parent);
}
+static inline bool pci_is_bridge(struct pci_dev *dev)
+{
+ return dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
+ dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
+}
+
static inline struct pci_dev *pci_upstream_bridge(struct pci_dev *dev)
{
dev = pci_physfn(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH 10/13] PCI, cpcihp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/cpci_hotplug_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/cpci_hotplug_pci.c b/drivers/pci/hotplug/cpci_hotplug_pci.c
index 8c14648..9843371 100644
--- a/drivers/pci/hotplug/cpci_hotplug_pci.c
+++ b/drivers/pci/hotplug/cpci_hotplug_pci.c
@@ -289,8 +289,7 @@ int __ref cpci_configure_slot(struct slot *slot)
list_for_each_entry(dev, &parent->devices, bus_list)
if (PCI_SLOT(dev->devfn) != PCI_SLOT(slot->devfn))
continue;
- if ((dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) ||
- (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS))
+ if (pci_is_bridge(dev))
pci_hp_add_bridge(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH 08/13] PCI, rpaphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
index 4fcdeed..7660232 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -157,8 +157,7 @@ static void dlpar_pci_add_bus(struct device_node *dn)
}
/* Scan below the new bridge */
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
of_scan_pci_bridge(dev);
/* Map IO space for child bus, which may or may not succeed */
--
1.7.1
^ permalink raw reply related
* [PATCH 07/13] sparc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/sparc/kernel/pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 1555bbc..857ad77 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -543,8 +543,7 @@ static void pci_of_scan_bus(struct pci_pbm_info *pbm,
printk("PCI: dev header type: %x\n",
dev->hdr_type);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
of_scan_pci_bridge(pbm, child, dev);
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH 12/13] PCI, pcmcia: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pcmcia/cardbus.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
index 8bde619..4fe4cc4 100644
--- a/drivers/pcmcia/cardbus.c
+++ b/drivers/pcmcia/cardbus.c
@@ -78,8 +78,7 @@ int __ref cb_alloc(struct pcmcia_socket *s)
max = bus->busn_res.start;
for (pass = 0; pass < 2; pass++)
list_for_each_entry(dev, &bus->devices, bus_list)
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
max = pci_scan_bridge(bus, dev, max, pass);
/*
--
1.7.1
^ permalink raw reply related
* [PATCH 03/13] PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/pci-acpi.c | 8 +-------
drivers/pci/probe.c | 3 +--
drivers/pci/setup-bus.c | 4 +---
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index f49abef..ca4927b 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -309,13 +309,7 @@ static struct acpi_device *acpi_pci_find_companion(struct device *dev)
bool check_children;
u64 addr;
- /*
- * pci_is_bridge() is not suitable here, because pci_dev->subordinate
- * is set only after acpi_pci_find_device() has been called for the
- * given device.
- */
- check_children = pci_dev->hdr_type == PCI_HEADER_TYPE_BRIDGE
- || pci_dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
+ check_children = pci_is_bridge(pci_dev);
/* Please ref to ACPI spec for the syntax of _ADR */
addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn);
return acpi_find_child_device(ACPI_COMPANION(dev->parent), addr,
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef09f5f..f831dd8 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1670,8 +1670,7 @@ unsigned int pci_scan_child_bus(struct pci_bus *bus)
for (pass=0; pass < 2; pass++)
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
max = pci_scan_bridge(bus, dev, max, pass);
}
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 138bdd6..e399d00 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1629,9 +1629,7 @@ void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
down_read(&pci_bus_sem);
list_for_each_entry(dev, &bus->devices, bus_list)
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
- if (dev->subordinate)
+ if (pci_is_bridge(dev) && pci_has_subordinate(dev))
__pci_bus_size_bridges(dev->subordinate,
&add_list);
up_read(&pci_bus_sem);
--
1.7.1
^ permalink raw reply related
* [PATCH 13/13] PCI, pciehp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/pciehp_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index 1b53306..b6cb1df 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -62,8 +62,7 @@ int pciehp_configure_device(struct slot *p_slot)
}
list_for_each_entry(dev, &parent->devices, bus_list)
- if ((dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) ||
- (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS))
+ if (pci_is_bridge(dev))
pci_hp_add_bridge(dev);
pci_assign_unassigned_bridge_resources(bridge);
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox