* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-24 15:48 UTC (permalink / raw)
To: key
Cc: rcj, linux-kernel, James Morris, linux-security-module,
tpmdd-devel, adlai, Ashley Lai, linuxppc-dev
In-Reply-To: <20120924141041.GA2741@ennui.austin.ibm.com>
On Mon, Sep 24, 2012 at 09:10:41AM -0500, key@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > On Wed, 12 Sep 2012, Ashley Lai wrote:
> >
> > > This patch removed the tasklet and moved the wait queue into the
> > > private structure. It also cleaned up the response CRQ path.
> > >
> > > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
> >
> >
> > Kent: any comment on this? You should probably push this to me via your
> > tree.
>
> Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> this to you today.
Ashley tells me Ben's review is in the works, so I'll send once we
have it.
Kent
>
> Kent
>
^ permalink raw reply
* Re: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
From: Greg KH @ 2012-09-24 17:27 UTC (permalink / raw)
To: Liu Shengzhou-B36685
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F453DDFF675A64A89321A1F352810217FFC51@039-SN1MPN1-004.039d.mgd.msft.net>
On Mon, Sep 24, 2012 at 02:44:19PM +0000, Liu Shengzhou-B36685 wrote:
>
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: 2012年9月22日 22:49
> > To: Kumar Gala
> > Cc: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org; linux-
> > usb@vger.kernel.org
> > Subject: Re: [PATCH v3] powerpc/usb: fix bug of CPU hang when missing
> > USB PHY clock
> >
> > On Sat, Sep 22, 2012 at 09:39:15AM -0500, Kumar Gala wrote:
> > >
> > > On Sep 21, 2012, at 11:43 AM, Greg KH wrote:
> > >
> > > > On Tue, Sep 18, 2012 at 04:52:39PM +0800, Shengzhou Liu wrote:
> > > >> when missing USB PHY clock, kernel booting up will hang during USB
> > > >> initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
> > > >> CPU hanging in this case.
> > > >>
> > > >> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > > >> ---
> > > >> v3 change: no check for UTMI PHY.
> > > >> v2 change: use spin_event_timeout() instead.
> > > >>
> > > >> drivers/usb/host/ehci-fsl.c | 57 +++++++++++++++++++++++++++++--
> > -----------
> > > >> drivers/usb/host/ehci-fsl.h | 1 +
> > > >> include/linux/fsl_devices.h | 1 +
> > > >> 3 files changed, 41 insertions(+), 18 deletions(-)
> > > >
> > > > This is already applied, right?
> > > >
> > > > greg k-h
> > >
> > > It appears that v2 of the patch is applied to your usb-next branch.
> > >
> > > in drivers/usb/host/ehci-fsl.c
> > >
> > > V2:
> > > @@ -262,23 +266,34 @@ static void ehci_fsl_setup_phy(struct usb_hcd
> > *hcd,
> > > case FSL_USB2_PHY_NONE:
> > > break;
> > > }
> > > +
> > > + if ((pdata->controller_ver) && ((phy_mode ==
> > FSL_USB2_PHY_ULPI) ||
> > > + (phy_mode == FSL_USB2_PHY_UTMI))) {
> > >
> > > V3:
> > >
> > > @@ -262,23 +266,33 @@ static void ehci_fsl_setup_phy(struct usb_hcd
> > *hcd,
> > >
> > > case FSL_USB2_PHY_NONE:
> > > break;
> > > }
> > >
> > > +
> > > + if (pdata->controller_ver && (phy_mode == FSL_USB2_PHY_ULPI)) {
> > > + /* check PHY_CLK_VALID to get phy clk valid */
> >
> > Ok, can someone please make the incremental patch that I need to apply
> > here and send it to me?
> >
> > thanks,
> >
> > greg k-h
>
> Hi greg,
>
> I have sent the below incremental patch to you, please squash it into the previous patch v2, which had been applied in your usb-next branch.
> http://patchwork.ozlabs.org/patch/186443/
Given that this is a git tree, "squashing" patches does not work at all.
I'll just apply it as-is.
thanks,
greg k-h
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-24 20:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKpAL0nk-5zz2zht6suNx+BVCQtkxPFPL33uZFSuGpxT8YFFqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6633 bytes --]
Here are the settings for PCI we currently have in uboot:
#define CONFIG_PCI 1 /* Enable PCI/PCIE */
#define CONFIG_PCIE1 1 /* PCIE controler 1
(slot 1) */
#define CONFIG_PCIE2 1 /* PCIE controler 2
(slot 2) */
#define CONFIG_FSL_PCI_INIT 1 /* Use common FSL init code
*/
#define CONFIG_FSL_PCIE_RESET 1 /* need PCIe reset errata */
#define CONFIG_FSL_LAW 1 /* Use common FSL init code
*/
#define CONFIG_SYS_PCIE1_ADDR (CONFIG_SYS_CCSRBAR+0x9000)
#define CONFIG_SYS_PCIE2_ADDR (CONFIG_SYS_CCSRBAR+0xa000)
/*
* General PCI
*/
#define CONFIG_SYS_PCIE1_MEM_VIRT 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_BUS 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_PHYS 0xA0000000
#define CONFIG_SYS_PCIE1_MEM_SIZE 0x10000000
#define CONFIG_SYS_PCIE1_IO_VIRT 0xFFC10000
#define CONFIG_SYS_PCIE1_IO_BUS 0x00000000
#define CONFIG_SYS_PCIE1_IO_PHYS 0xFFC10000
#define CONFIG_SYS_PCIE1_IO_SIZE 0x00010000 /* 64k */
#define CONFIG_SYS_PCIE2_MEM_VIRT 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_BUS 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_PHYS 0xB0000000
#define CONFIG_SYS_PCIE2_MEM_SIZE 0x10000000
#define CONFIG_SYS_PCIE2_IO_VIRT 0xFFC00000
#define CONFIG_SYS_PCIE2_IO_BUS 0x00000000
#define CONFIG_SYS_PCIE2_IO_PHYS 0xFFC00000
#define CONFIG_SYS_PCIE2_IO_SIZE 0x00010000 /* 64k */
I'd really appreciate I you could take a look at it
Thanx alot in advance
Davide
2012/9/24 Davide Viti <zinosat@tiscali.it>
> Hi,
> does the output I've included show anything wrong or should I post
> something else to help identifying the cause of the problem?
>
> thank you in advance,
> Davide
>
> 2012/9/21 Davide Viti <zinosat@tiscali.it>
>
>> I mean there are two controllers and both of them have a device
>> "subtended" (both 0x1b65:0xabba).
>> u-boot can see both devices, linux detects only the device attached to
>> the first controller.
>>
>> Here's the output of lspci and /proc/iomem :
>>
>> root@(none):/# lspci -v
>>
>> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>>
>> Flags: bus master, fast devsel, latency 0
>>
>> Memory at <ignored> (32-bit, non-prefetchable)
>>
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>
>> I/O behind bridge: 00000000-00000fff
>>
>> Memory behind bridge: a0000000-afffffff
>>
>> Capabilities: [44] Power Management version 2
>>
>> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>>
>> Capabilities: [100] Advanced Error Reporting
>>
>>
>>
>> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>>
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>>
>> Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
>>
>> Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
>>
>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>> Capabilities: [78] Power Management version 3
>>
>> Capabilities: [80] Express Endpoint, MSI 00
>>
>> Capabilities: [100] Virtual Channel <?>
>>
>> Capabilities: [800] Advanced Error Reporting
>>
>>
>>
>> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>>
>> Flags: bus master, fast devsel, latency 0
>>
>> Memory at <ignored> (32-bit, non-prefetchable)
>>
>> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>>
>> I/O behind bridge: 00000000-00000fff
>>
>> Memory behind bridge: b0000000-bfffffff
>>
>> Capabilities: [44] Power Management version 2
>>
>> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>>
>> Capabilities: [100] Advanced Error Reporting
>>
>>
>> root@(none):/# cat /proc/iomem
>>
>> a0000000-afffffff : /pcie@ffe09000
>>
>> a0000000-afffffff : PCI Bus 0000:01
>>
>> a0000000-a00003ff : 0000:01:00.0
>>
>> a0010000-a001ffff : 0000:01:00.0
>>
>> b0000000-bfffffff : /pcie@ffe0a000
>>
>> b0000000-bfffffff : PCI Bus 0001:03
>>
>> ef000000-efffffff : ef000000.nor
>>
>> ffe04500-ffe04507 : serial
>>
>> ffe04600-ffe04607 : serial
>>
>>
>> thanx for your help,
>>
>> Davide
>>
>>
>> I mean that the kernel detects the first controller and the device
>> attached to it, plus the second controller: the device on the second
>> controller is not detected (same device as the one detected on the first
>> controller)
>>
>> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>>
>>>
>>> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>>>
>>> > Hi,
>>> > I'm working on a custom board based on P1020 with two (identical) PCI
>>> devices attached;
>>> > The work is derived from another board with a single instance of that
>>> device.
>>> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
>>> >
>>> > The "pci" command on u-boot, shows me both the PCI controllers and
>>> > the attached devices:
>>> >
>>> > Scanning PCI devices on bus 0
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 00.00.00 0x1957 0x0100 Processor 0x20
>>> >
>>> > Scanning PCI devices on bus 1
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 01.00.00 0x1b65 0xabba Network controller 0x80
>>> >
>>> > Scanning PCI devices on bus 2
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 02.00.00 0x1957 0x0100 Processor 0x20
>>> >
>>> > Scanning PCI devices on bus 3
>>> > BusDevFun VendorId DeviceId Device Class Sub-Class
>>> > _____________________________________________________________
>>> > 03.00.00 0x1b65 0xabba Network controller 0x80
>>> >
>>> > The kernel detects only the first instance of the device.
>>>
>>> What do you mean by first instance of the device ?
>>>
>>> > Didn't get very far while looking at dts file and kernel logs, so I'm
>>> > asking for some help on narrowing down the problem.
>>> >
>>> > I'm wondering if I can assume that the problem is restricted to
>>> > kernel/dts and avoid concentrating on uboot.
>>> > I can provide any log (didn't want to post tons of details on the first
>>> > message)
>>>
>>> Probably a dts issue.
>>>
>>> What does lspci in linux say?
>>>
>>> - k
>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 12562 bytes --]
^ permalink raw reply
* [PATCH] powerpc/pcm030: add pcm030-audio-fabric to dts
From: Eric Millbrandt @ 2012-09-24 22:16 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, devicetree-discuss, Eric Millbrandt
Add a node for the pcm030-audio-fabric ASoC driver
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
arch/powerpc/boot/dts/pcm030.dts | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 9e35499..96512c0 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -59,7 +59,7 @@
#gpio-cells = <2>;
};
- psc@2000 { /* PSC1 in ac97 mode */
+ audioplatform: psc@2000 { /* PSC1 in ac97 mode */
compatible = "mpc5200b-psc-ac97","fsl,mpc5200b-psc-ac97";
cell-index = <0>;
};
@@ -134,4 +134,9 @@
localbus {
status = "disabled";
};
+
+ sound {
+ compatible = "phytec,pcm030-audio-fabric";
+ asoc-platform = <&audioplatform>;
+ };
};
--
1.7.2.5
^ permalink raw reply related
* Re: Probing for native availability of isel from userspace
From: Scott Wood @ 2012-09-24 23:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <35A5B006-1E4E-4355-A6A4-CA5F7371D21C@kernel.crashing.org>
On 09/22/2012 08:46:06 PM, Segher Boessenkool wrote:
>>> Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ =20
>>> then?
>>=20
>> Userspace should *NEVER* rely on the content of debugfs, it will =20
>> change
>> with time, it is not a guaranteed ABI, it's purely for people to look
>> at... for debugging.
>=20
> malc didn't say what he wants it for... People are in userspace as
> well ;-)
>=20
>> At this stage I would recommend using arch 2.06 as your key/trigger =20
>> and
>> either add a handful of known PVR values (mfpvr is emulated) for =20
>> other
>> CPUs you know support it (there shouldn't be that many), or just do =20
>> the
>> heuristic :-(
The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there =20
any 2.06 chips that don't have it?
> That's for 64-bit; another good option for 64-bit is to just never use
> isel, it hardly ever buys you anything. It is much more useful on the
> (older) 32-bit cores that support it.
Why is it more useful on 32-bit? If you're referring to the =20
performance of specific cores rather than some architectural thing, =20
maybe that's true with some chips, but on the Freescale side I'd be =20
surprised if e5500 were much different from e500v2 in that regard.
-Scott=
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-25 0:32 UTC (permalink / raw)
To: Scott Wood; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348530909.25867.29@snotra>
On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there
> any 2.06 chips that don't have it?
I believe "malc" is interested in knowing about pre-2.06 chips that have
it.
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Scott Wood @ 2012-09-25 0:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348533123.1132.102.camel@pasglop>
On 09/24/2012 07:32:03 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
> there
> > any 2.06 chips that don't have it?
>=20
> I believe "malc" is interested in knowing about pre-2.06 chips that =20
> have
> it.
You said to key off of 2.06 plus a PVR whitelist for pre-2.06 chips =20
that have it. Wouldn't you also need a PVR blacklist for 2.06 chips =20
that don't have it (unless there are no such things)? Or if one is =20
only interested in pre-2.06 chips, why check for 2.06 at all?
-Scott=
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: malc @ 2012-09-25 0:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, hollis
In-Reply-To: <1348533123.1132.102.camel@pasglop>
On Tue, 25 Sep 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there
> > any 2.06 chips that don't have it?
>
> I believe "malc" is interested in knowing about pre-2.06 chips that have
> it.
>
That too, but also what 's' prefix means.
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Scott Wood @ 2012-09-25 0:50 UTC (permalink / raw)
To: malc; +Cc: linuxppc-dev, hollis
In-Reply-To: <alpine.LNX.2.00.1209250446300.9670@linmac>
On 09/24/2012 07:47:28 PM, malc wrote:
> On Tue, 25 Sep 2012, Benjamin Herrenschmidt wrote:
>=20
> > On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
> there
> > > any 2.06 chips that don't have it?
> >
> > I believe "malc" is interested in knowing about pre-2.06 chips that =20
> have
> > it.
> >
>=20
> That too, but also what 's' prefix means.
I think it's trying to say that it's phased-in for server but mandatory =20
for embedded, though I don't see that exact notation used anywhere else =20
in the document.
-Scott=
^ permalink raw reply
* Re: powerpc/perf: hw breakpoints return ENOSPC
From: Michael Neuling @ 2012-09-25 7:10 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Ingo Molnar, linuxppc-dev, K Prasad, linux-kernel, Peter Zijlstra
In-Reply-To: <11821.1345240695@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
> > > Hi,
> > >
> > > I've been trying to get hardware breakpoints with perf to work on POWER7
> > > but I'm getting the following:
> > >
> > > % perf record -e mem:0x10000000 true
> > >
> > > Error: sys_perf_event_open() syscall returned with 28 (No space left on device). /bin/dmesg may provide additional information.
> > >
> > > Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
> > >
> > > true: Terminated
> > >
> > > (FWIW adding -a and it works fine)
> > >
> > > Debugging it seems that __reserve_bp_slot() is returning ENOSPC because
> > > it thinks there are no free breakpoint slots on this CPU.
> > >
> > > I have a 2 CPUs, so perf userspace is doing two perf_event_open syscalls
> > > to add a counter to each CPU [1]. The first syscall succeeds but the
> > > second is failing.
> > >
> > > On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
> > > despite there being no breakpoint on this CPU. This is because the call
> > > the task_bp_pinned, checks all CPUs, rather than just the current CPU.
> > > POWER7 only has one hardware breakpoint per CPU (ie. HBP_NUM=1), so we
> > > return ENOSPC.
> > >
> > > The following patch fixes this by checking the associated CPU for each
> > > breakpoint in task_bp_pinned. I'm not familiar with this code, so it's
> > > provided as a reference to the above issue.
> > >
> > > Mikey
> > >
> > > 1. not sure why it doesn't just do one syscall and specify all CPUs, but
> > > that's another issue. Using two syscalls should work.
> >
> > This patch seems to make sense. I'll try it and run some tests.
> > Can I have your Signed-off-by ?
Frederic,
Did you ever get to testing or integrating this patch?
Mikey
> Of course...
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
^ permalink raw reply
* [PATCH 27/29] PCI, powerpc: kill pci_root_buses in resources reservations
From: Yinghai Lu @ 2012-09-25 8:26 UTC (permalink / raw)
To: Bjorn Helgaas, Len Brown
Cc: linux-pci, Yinghai Lu, linuxppc-dev, Paul Mackerras
In-Reply-To: <1348561590-28067-1-git-send-email-yinghai@kernel.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 13 ++++++-------
arch/powerpc/kernel/pci_64.c | 7 ++++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 43fea54..1e13133 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1390,11 +1390,11 @@ static void __init pcibios_reserve_legacy_regions(struct pci_bus *bus)
void __init pcibios_resource_survey(void)
{
- struct pci_bus *b;
+ struct pci_host_bridge *host_bridge = NULL;
/* Allocate and assign resources */
- list_for_each_entry(b, &pci_root_buses, node)
- pcibios_allocate_bus_resources(b);
+ for_each_pci_host_bridge(host_bridge)
+ pcibios_allocate_bus_resources(host_bridge->bus);
pcibios_allocate_resources(0);
pcibios_allocate_resources(1);
@@ -1402,10 +1402,9 @@ void __init pcibios_resource_survey(void)
* the low IO area and the VGA memory area if they intersect the
* bus available resources to avoid allocating things on top of them
*/
- if (!pci_has_flag(PCI_PROBE_ONLY)) {
- list_for_each_entry(b, &pci_root_buses, node)
- pcibios_reserve_legacy_regions(b);
- }
+ if (!pci_has_flag(PCI_PROBE_ONLY))
+ for_each_pci_host_bridge(host_bridge)
+ pcibios_reserve_legacy_regions(host_bridge);
/* Now, if the platform didn't decide to blindly trust the firmware,
* we proceed to assigning things that were left unassigned
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 4ff190f..dafa7c5 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -213,8 +213,9 @@ long sys_pciconfig_iobase(long which, unsigned long in_bus,
{
struct pci_controller* hose;
struct list_head *ln;
- struct pci_bus *bus = NULL;
+ struct pci_bus *bus;
struct device_node *hose_node;
+ struct pci_host_bridge *host_bridge = NULL;
/* Argh ! Please forgive me for that hack, but that's the
* simplest way to get existing XFree to not lockup on some
@@ -234,8 +235,8 @@ long sys_pciconfig_iobase(long which, unsigned long in_bus,
* used on pre-domains setup. We return the first match
*/
- for (ln = pci_root_buses.next; ln != &pci_root_buses; ln = ln->next) {
- bus = pci_bus_b(ln);
+ for_each_pci_host_bridge(host_bridge) {
+ bus = host_bridge->bus;
if (in_bus >= bus->number && in_bus <= bus->busn_res.end)
break;
bus = NULL;
--
1.7.7
^ permalink raw reply related
* /dev/port under powerpc
From: Serge Teodori @ 2012-09-25 12:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 224 bytes --]
Hello,
I am curently doing some cleanup, and noticed 'arch_has_dev_port()' could
be omitted if 'arch/powerpc/configs/*' would be update with
'CONFIG_DEVPORT'. My question is, which ones have or have not an 'isa pci
bridge'.
[-- Attachment #2: Type: text/html, Size: 268 bytes --]
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Segher Boessenkool @ 2012-09-25 13:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348479715.1132.91.camel@pasglop>
>> Fine. But I believe that mfpvr emulation came first, which is the
>> point
>> I object to (see the mess that the fact that CPUID is available to
>> applications made to x86 when SSE registers were added).
>
> Heh, possibly, I don't remember... I added the cputable, I think we
> added mfpvr because we didn't have anything, then I added cputable
> which
> got us the HW caps, but some old stuff still relied on mfpvr so we
> couldn't completely remove it.
If I have my history right end up, MFPVR emulation was added for MoL.
Which is funny (if you like that kind of thing) because it now hurts
all other "hypervisor in userspace" kind of things, that might want
to lie in their emulated PVR...
Segher
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Segher Boessenkool @ 2012-09-25 13:31 UTC (permalink / raw)
To: Scott Wood; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <1348530909.25867.29@snotra>
>> That's for 64-bit; another good option for 64-bit is to just never
>> use
>> isel, it hardly ever buys you anything. It is much more useful on
>> the
>> (older) 32-bit cores that support it.
>
> Why is it more useful on 32-bit? If you're referring to the
> performance of specific cores rather than some architectural thing,
> maybe that's true with some chips, but on the Freescale side I'd be
> surprised if e5500 were much different from e500v2 in that regard.
Yes, I was talking about the older cores. I'd be surprised if ISEL is
often a win on e5500, but I don't really know. I forgot about that chip
to tell you the truth :-)
Segher
^ permalink raw reply
* Re: [PATCH v4 0/8] Avoid cache trashing on clearing huge/gigantic page
From: Kirill A. Shutemov @ 2012-09-25 14:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Jan Beulich, linux-mm, H. Peter Anvin,
sparclinux, Andrea Arcangeli, Andi Kleen, Robert Richter, x86,
Hugh Dickins, Ingo Molnar, Mel Gorman, Alex Shi, Thomas Gleixner,
KAMEZAWA Hiroyuki, Tim Chen, linux-kernel, Andy Lutomirski,
Johannes Weiner, Andrew Morton, linuxppc-dev
In-Reply-To: <20120914055210.GC9043@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
On Fri, Sep 14, 2012 at 07:52:10AM +0200, Ingo Molnar wrote:
> Without repeatable hard numbers such code just gets into the
> kernel and bitrots there as new CPU generations come in - a few
> years down the line the original decisions often degrade to pure
> noise. We've been there, we've done that, we don't want to
> repeat it.
<sorry, for late answer..>
Hard numbers are hard.
I've checked some workloads: Mosbench, NPB, specjvm2008. Most of time the
patchset doesn't show any difference (within run-to-run deviation).
On NPB it recovers THP regression, but it's probably not enough to make
decision.
It would be nice if somebody test the patchset on other system or
workload. Especially, if the configuration shows regression with
THP enabled.
--
Kirill A. Shutemov
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/8] Avoid cache trashing on clearing huge/gigantic page
From: Andrea Arcangeli @ 2012-09-25 19:33 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-mips, linux-sh, Jan Beulich, linux-mm, H. Peter Anvin,
sparclinux, Ingo Molnar, Andi Kleen, Robert Richter, x86,
Hugh Dickins, Ingo Molnar, Mel Gorman, Alex Shi, Thomas Gleixner,
KAMEZAWA Hiroyuki, Tim Chen, linux-kernel, Andy Lutomirski,
Johannes Weiner, Andrew Morton, linuxppc-dev
In-Reply-To: <20120925142703.GA1598@otc-wbsnb-06>
Hi Kirill,
On Tue, Sep 25, 2012 at 05:27:03PM +0300, Kirill A. Shutemov wrote:
> On Fri, Sep 14, 2012 at 07:52:10AM +0200, Ingo Molnar wrote:
> > Without repeatable hard numbers such code just gets into the
> > kernel and bitrots there as new CPU generations come in - a few
> > years down the line the original decisions often degrade to pure
> > noise. We've been there, we've done that, we don't want to
> > repeat it.
>
> <sorry, for late answer..>
>
> Hard numbers are hard.
> I've checked some workloads: Mosbench, NPB, specjvm2008. Most of time the
> patchset doesn't show any difference (within run-to-run deviation).
> On NPB it recovers THP regression, but it's probably not enough to make
> decision.
>
> It would be nice if somebody test the patchset on other system or
> workload. Especially, if the configuration shows regression with
> THP enabled.
If the only workload that gets a benefit is NPB then we've the proof
this is too hardware dependend to be a conclusive result.
It may have been slower by an accident, things like cache
associativity off by one bit, combined with the implicit coloring
provided to the lowest 512 colors could hurts more if the cache
associativity is low.
I'm saying this because NPB on a thinkpad (Intel CPU I assume) is the
benchmark that shows the most benefit among all benchmarks run on that
hardware.
http://www.phoronix.com/scan.php?page=article&item=linux_transparent_hugepages&num=2
I've once seen certain computations that run much slower with perfect
cache coloring but most others runs much faster with the page
coloring. Doesn't mean page coloring is bad per se. So the NPB on that
specific hardware may have been the exception and not the interesting
case. Especially considering the effect of cache-copying is opposite
on slightly different hw.
I think the the static_key should be off by default whenever the CPU
L2 cache size is >= the size of the copy (2*HPAGE_PMD_SIZE). Now the
cache does random replacement so maybe we could also allow cache
copies for twice the size of the copy (L2size >=
4*HPAGE_PMD_SIZE). Current CPUs have caches much larger than 2*2MB...
It would make a whole lot more sense for hugetlbfs giga pages than for
THP (unlike for THP, cache trashing with giga pages is guaranteed),
but even with giga pages, it's not like they're allocated frequently
(maybe once per OS reboot) so that's also sure totally lost in the
noise as it only saves a few accesses after the cache copy is
finished.
It's good to have tested it though.
Thanks,
Andrea
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Benjamin Herrenschmidt @ 2012-09-25 20:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: malc, linuxppc-dev, hollis
In-Reply-To: <CA1BC0F6-577D-4CEF-85C9-599774B176C9@kernel.crashing.org>
On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
> >> Fine. But I believe that mfpvr emulation came first, which is the
> >> point
> >> I object to (see the mess that the fact that CPUID is available to
> >> applications made to x86 when SSE registers were added).
> >
> > Heh, possibly, I don't remember... I added the cputable, I think we
> > added mfpvr because we didn't have anything, then I added cputable
> > which
> > got us the HW caps, but some old stuff still relied on mfpvr so we
> > couldn't completely remove it.
>
> If I have my history right end up, MFPVR emulation was added for MoL.
> Which is funny (if you like that kind of thing) because it now hurts
> all other "hypervisor in userspace" kind of things, that might want
> to lie in their emulated PVR...
Are you sure ? MOL had a kernel module, it wouldn't have needed that...
Cheers,
Ben.
^ permalink raw reply
* Re: Probing for native availability of isel from userspace
From: Kumar Gala @ 2012-09-26 0:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, malc, hollis
In-Reply-To: <1348606771.7937.8.camel@pasglop>
On Sep 25, 2012, at 3:59 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
>>>> Fine. But I believe that mfpvr emulation came first, which is the =20=
>>>> point
>>>> I object to (see the mess that the fact that CPUID is available to
>>>> applications made to x86 when SSE registers were added).
>>>=20
>>> Heh, possibly, I don't remember... I added the cputable, I think we
>>> added mfpvr because we didn't have anything, then I added cputable =20=
>>> which
>>> got us the HW caps, but some old stuff still relied on mfpvr so we
>>> couldn't completely remove it.
>>=20
>> If I have my history right end up, MFPVR emulation was added for MoL.
>> Which is funny (if you like that kind of thing) because it now hurts
>> all other "hypervisor in userspace" kind of things, that might want
>> to lie in their emulated PVR...
>=20
> Are you sure ? MOL had a kernel module, it wouldn't have needed =
that...
I feel like there was some JVMs (IBMs?) that used MFPVR to determine =
some things.
- k=
^ permalink raw reply
* Re: [PATCH] driver/mtd:IFC NAND:Initialise internal SRAM before any write
From: Prabhakar Kushwaha @ 2012-09-26 4:45 UTC (permalink / raw)
To: dedekind1; +Cc: scottwood, linuxppc-dev, linux-mtd
In-Reply-To: <68738277-B1F2-4455-B8FD-67F2DD9E1310@kernel.crashing.org>
On 09/13/2012 06:23 PM, Kumar Gala wrote:
> On Sep 13, 2012, at 3:54 AM, Prabhakar Kushwaha wrote:
>
>> IFC-1.1.0 uses 28nm techenology for SRAM. This tech has known limitaion for
>> SRAM i.e. "byte select" is not supported. Hence Read Modify Write is
>> implemented in IFC for any "system side write" into sram buffer. Reading an
>> uninitialized memory results in ECC Error from sram wrapper.
>>
>> Hence we must initialize/prefill SRAM buffer by any data before writing
>> anything in SRAM from system side. To initialize SRAM user can use "READID"
>> NAND command with read bytes equal to SRAM size. It will be a one time
>> activity post boot.
>>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
>> ---
>> Based upon git://git.infradead.org/linux-mtd.git branch master
>> The compilation of this patch depends upon following patch.
>> http://patchwork.ozlabs.org/patch/177893/
>> This patch is currently applied on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
>> branch next and status is "Awaiting Upstream"
>>
>>
>> drivers/mtd/nand/fsl_ifc_nand.c | 56 ++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 55 insertions(+), 1 deletion(-)
> If MTD maintainers ack, I'm happy to pull this in via PPC tree.
Hi Artem,
Can you please ACK this patch so that it can be pulled via PPC tree.
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH] driver/mtd:IFC NAND:Initialise internal SRAM before any write
From: Artem Bityutskiy @ 2012-09-26 9:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: scottwood, linuxppc-dev, linux-mtd, Prabhakar Kushwaha
In-Reply-To: <68738277-B1F2-4455-B8FD-67F2DD9E1310@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Thu, 2012-09-13 at 07:53 -0500, Kumar Gala wrote:
> > drivers/mtd/nand/fsl_ifc_nand.c | 56 ++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 55 insertions(+), 1 deletion(-)
>
> If MTD maintainers ack, I'm happy to pull this in via PPC tree.
Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a lazy irq related WARING in arch_local_irq_restore()
From: Li Zhong @ 2012-09-26 10:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1348464657.1132.86.camel@pasglop>
On Mon, 2012-09-24 at 15:30 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 11:56 +0800, Li Zhong wrote:
> > This patch tries to fix a WARNING in irq.c(below), when doing cpu offline/online.
> >
> > The reason is that if the preferred offline state is CPU_STATE_INACTIVE, when
> > cpu offline, pseries_mach_cpu_die() calls extended_cede_processor() to cede
> > the processor. After the hv call returns, the MSR_EE is enabled, while
> > the irq_happened in paca should already be set as PACA_IRQ_HARD_DIS.
> >
> > Then when the cpu is put online again, the warning is reported when
> > start_secondary() tries to enable irq. [ Sometimes, we don't see this warning,
> > that's because when we come to local_irq_enable(), there might already have been
> > some interrupts occurred, e.g. PACA_IRQ_DEC is already set. ]
> >
> > The patch tries to clear MSR_EE by calling __hard_irq_disable() after cede
> > returns, and before calling start_secondary_resume().
>
> Is that enough ? Do we know for sure we won't get a stray IPI or
> interrupt which then will reach us with an inconsistent HW/SW enable
> state ?
>
> We might need to "sanitize" the enable state in the PACA before we
> actually enter NAP or in the return from NAP code, like we do for normal
> idle code...
Hi Ben,
After some further reading of the code, I updated the code as following,
but I'm not very sure, and guess it most probably has some issues ...
Could you please help to review and give your comments?
In extended_cede_processor(), if there is still lazy irq pending, I used
local_irq_enable() to make sure the irq replayed and flags cleared, but
I'm not sure whether it is a proper way.
In pseries_mach_cpu_die(), I added local_irq_disable() after cede, and
prepare for the start_secondary_resume(), but I'm not sure whether we
also need a hard_irq_disable() here.
I'm still a little confused by the meaning of PACA_IRQ_HARD_DIS in
irq_happened. From the checking at the warning point, it seems only
irq_happened equaling 0x1(PACA_IRQ_HARD_DIS) means hard irqs are
disabled.
Is it possible to set this bit at anyplace the hard irqs are disabled,
so then we could check whether this bit is set to know whether hard irqs
are disabled? Then it seems that in MASKED_INTERRUPT, we need set this
bit where MSR_EE is cleared for something other than decrementer. Maybe
I missed too much things?
Thanks, Zhong
===================
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 64c97d8..b5f7597 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -130,6 +130,8 @@ static void pseries_mach_cpu_die(void)
extended_cede_processor(cede_latency_hint);
}
+ local_irq_disable();
+
if (!get_lppaca()->shared_proc)
get_lppaca()->donate_dedicated_cpu = 0;
get_lppaca()->idle = 0;
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index 13e8cc4..07560d8 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -2,6 +2,7 @@
#define _PSERIES_PLPAR_WRAPPERS_H
#include <linux/string.h>
+#include <linux/irqflags.h>
#include <asm/hvcall.h>
#include <asm/paca.h>
@@ -41,7 +42,19 @@ static inline long extended_cede_processor(unsigned long latency_hint)
u8 old_latency_hint = get_cede_latency_hint();
set_cede_latency_hint(latency_hint);
+
+ while (!prep_irq_for_idle()) {
+ local_irq_enable();
+ local_irq_disable();
+ }
+
rc = cede_processor();
+#ifdef CONFIG_TRACE_IRQFLAGS
+ /* Ensure that H_CEDE returns with IRQs on */
+ if (WARN_ON(!(mfmsr() & MSR_EE)))
+ __hard_irq_enable();
+#endif
+
set_cede_latency_hint(old_latency_hint);
return rc;
===================
>
> Cheers,
> Ben.
>
> > [ 56.618846] WARNING: at arch/powerpc/kernel/irq.c:240
> > [ 56.618851] Modules linked in: rcutorture ipv6 dm_mod ext3 jbd mbcache sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt ibmveth
> > [ 56.618883] NIP: c00000000000ff94 LR: c00000000067a5e0 CTR: 0000000000000001
> > [ 56.618889] REGS: c0000001fef6bbe0 TRAP: 0700 Not tainted (3.6.0-rc1-autokern1)
> > [ 56.618894] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 42000082 XER: 20000000
> > [ 56.618913] SOFTE: 1
> > [ 56.618916] CFAR: c00000000067a5dc
> > [ 56.618920] TASK = c0000001feed79a0[0] 'swapper/5' THREAD: c0000001fef68000 CPU: 5
> > GPR00: 0000000000000001 c0000001fef6be60 c000000000f9ca08 0000000000000001
> > GPR04: 0000000000000001 0000000000000008 0000000000000001 0000000000000000
> > GPR08: 0000000000000000 c0000001feed79a0 0008a80000000000 0000000000000000
> > GPR12: 0000000022000082 c00000000f330f00 c0000001fef6bf90 000000000f394b4c
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR24: c000000000fe8f80 0000000000000008 0000000000000028 0000000000000000
> > GPR28: 0000000000000000 0000000000000020 c000000000f1ab40 0000000000000001
> > [ 56.619014] NIP [c00000000000ff94] .arch_local_irq_restore+0x34/0xa0
> > [ 56.619020] LR [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619025] Call Trace:
> > [ 56.619030] [c0000001fef6be60] [c000000001ba0500] 0xc000000001ba0500 (unreliable)
> > [ 56.619038] [c0000001fef6bed0] [c00000000067a5e0] .start_secondary+0x368/0x37c
> > [ 56.619046] [c0000001fef6bf90] [c000000000009380] .start_secondary_resume+0x10/0x14
> > [ 56.619052] Instruction dump:
> > [ 56.619056] f8010010 f821ff91 986d022a 2fa30000 419e0054 880d022b 78000621 41820048
> > [ 56.619071] 2f800001 40de0064 7c0000a6 78008fe2 <0b000000> 2fa00000 40de0050 38000000
> > [ 56.619088] ---[ end trace 0199c0d783d7f9ba ]---
> >
> > Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > index 64c97d8..8de539a 100644
> > --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> > @@ -137,6 +137,8 @@ static void pseries_mach_cpu_die(void)
> > if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
> > unregister_slb_shadow(hwcpu);
> >
> > + __hard_irq_disable();
> > +
> > /*
> > * Call to start_secondary_resume() will not return.
> > * Kernel stack will be reset and start_secondary()
>
>
^ permalink raw reply related
* enabling suspend-to-ram for a headless powerpc g4 mac mini
From: Jon Dowland @ 2012-09-26 9:27 UTC (permalink / raw)
To: linuxppc-dev
Hi folks,
I'm aware that suspend to ram is not enabled for g4 mac minis, due to
lack of support for waking up the video chipset¹.
I use a headless mac mini as a NAS device and so working video is not
important to me. That prior thread on the topic gives me enough of a
clue to enable support but not to give up attempting to restore the
video.
Can anyone give me some hints/pointers on how to configure or hack the
kernel so that video is simply ignored?
Thank you very much for any help.
¹ https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-January/088159.html
^ permalink raw reply
* Re: PCI device not working
From: Kumar Gala @ 2012-09-26 13:44 UTC (permalink / raw)
To: Davide Viti; +Cc: linuxppc-dev
In-Reply-To: <CAKpAL0m2Df6JZ=vYvhfEY5jYH9qOdMmrdmw2u2tcWAAFGv04+Q@mail.gmail.com>
> 2012/9/24 Davide Viti <zinosat@tiscali.it>
> Hi,
> does the output I've included show anything wrong or should I post =
something else to help identifying the cause of the problem?
>=20
> thank you in advance,
> Davide
>=20
> 2012/9/21 Davide Viti <zinosat@tiscali.it>
> I mean there are two controllers and both of them have a device =
"subtended" (both 0x1b65:0xabba).
> u-boot can see both devices, linux detects only the device attached to =
the first controller.
>=20
> Here's the output of lspci and /proc/iomem :
>=20
> root@(none):/# lspci -v
>=20
> 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
>=20
> Flags: bus master, fast devsel, latency 0
>=20
> Memory at <ignored> (32-bit, non-prefetchable)
>=20
> Bus: primary=3D00, secondary=3D01, subordinate=3D01, =
sec-latency=3D0
>=20
> I/O behind bridge: 00000000-00000fff
>=20
> Memory behind bridge: a0000000-afffffff
>=20
> Capabilities: [44] Power Management version 2
>=20
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>=20
> Capabilities: [100] Advanced Error Reporting
>=20
> =20
> 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
>=20
> Flags: bus master, fast devsel, latency 0, IRQ 16
>=20
> Memory at a0000000 (32-bit, non-prefetchable) [size=3D1K]
>=20
> Memory at a0010000 (32-bit, non-prefetchable) [size=3D64K]
>=20
> Capabilities: [50] MSI: Enable- Count=3D1/1 Maskable- 64bit+
>=20
> Capabilities: [78] Power Management version 3
>=20
> Capabilities: [80] Express Endpoint, MSI 00
>=20
> Capabilities: [100] Virtual Channel <?>
>=20
> Capabilities: [800] Advanced Error Reporting
>=20
> =20
> 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
>=20
> Flags: bus master, fast devsel, latency 0
>=20
> Memory at <ignored> (32-bit, non-prefetchable)
>=20
> Bus: primary=3D00, secondary=3D03, subordinate=3D03, =
sec-latency=3D0
>=20
> I/O behind bridge: 00000000-00000fff
>=20
> Memory behind bridge: b0000000-bfffffff
>=20
> Capabilities: [44] Power Management version 2
>=20
> Capabilities: [4c] Express Root Port (Slot-), MSI 00
>=20
> Capabilities: [100] Advanced Error Reporting
Its possible that in linux the 2nd controller does not believe it has =
link status. Can you see if there is a function like =
fsl_pcie_check_link() in your kernel. If so maybe add a printk debug =
message there and see what gets return.
Also helpful to post a full boot log.
>=20
>=20
>=20
>=20
> root@(none):/# cat /proc/iomem
>=20
> a0000000-afffffff : /pcie@ffe09000
>=20
> a0000000-afffffff : PCI Bus 0000:01
>=20
> a0000000-a00003ff : 0000:01:00.0
>=20
> a0010000-a001ffff : 0000:01:00.0
>=20
> b0000000-bfffffff : /pcie@ffe0a000
>=20
> b0000000-bfffffff : PCI Bus 0001:03
>=20
> ef000000-efffffff : ef000000.nor
>=20
> ffe04500-ffe04507 : serial
>=20
> ffe04600-ffe04607 : serial
>=20
>=20
>=20
> thanx for your help,
>=20
> Davide
>=20
>=20
>=20
>=20
> I mean that the kernel detects the first controller and the device =
attached to it, plus the second controller: the device on the second =
controller is not detected (same device as the one detected on the first =
controller)
>=20
> 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
>=20
> On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
>=20
> > Hi,
> > I'm working on a custom board based on P1020 with two (identical) =
PCI devices attached;
> > The work is derived from another board with a single instance of =
that device.
> > The system is based on u-boot-2009.11 and Linux 2.6.34.6
> >
> > The "pci" command on u-boot, shows me both the PCI controllers and
> > the attached devices:
> >
> > Scanning PCI devices on bus 0
> > BusDevFun VendorId DeviceId Device Class Sub-Class
> > _____________________________________________________________
> > 00.00.00 0x1957 0x0100 Processor 0x20
> >
> > Scanning PCI devices on bus 1
> > BusDevFun VendorId DeviceId Device Class Sub-Class
> > _____________________________________________________________
> > 01.00.00 0x1b65 0xabba Network controller 0x80
> >
> > Scanning PCI devices on bus 2
> > BusDevFun VendorId DeviceId Device Class Sub-Class
> > _____________________________________________________________
> > 02.00.00 0x1957 0x0100 Processor 0x20
> >
> > Scanning PCI devices on bus 3
> > BusDevFun VendorId DeviceId Device Class Sub-Class
> > _____________________________________________________________
> > 03.00.00 0x1b65 0xabba Network controller 0x80
> >
> > The kernel detects only the first instance of the device.
>=20
> What do you mean by first instance of the device ?
>=20
> > Didn't get very far while looking at dts file and kernel logs, so =
I'm
> > asking for some help on narrowing down the problem.
> >
> > I'm wondering if I can assume that the problem is restricted to
> > kernel/dts and avoid concentrating on uboot.
> > I can provide any log (didn't want to post tons of details on the =
first
> > message)
>=20
> Probably a dts issue.
>=20
> What does lspci in linux say?
>=20
> - k
>=20
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: key @ 2012-09-26 13:55 UTC (permalink / raw)
To: benh
Cc: rcj, linux-kernel, James Morris, linux-security-module,
tpmdd-devel, adlai, key, Ashley Lai, linuxppc-dev
In-Reply-To: <20120924154821.GA16007@ennui.austin.ibm.com>
On Mon, Sep 24, 2012 at 10:48:21AM -0500, key@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 09:10:41AM -0500, key@linux.vnet.ibm.com wrote:
> > On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > > On Wed, 12 Sep 2012, Ashley Lai wrote:
> > >
> > > > This patch removed the tasklet and moved the wait queue into the
> > > > private structure. It also cleaned up the response CRQ path.
> > > >
> > > > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
> > >
> > >
> > > Kent: any comment on this? You should probably push this to me via your
> > > tree.
> >
> > Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> > this to you today.
>
> Ashley tells me Ben's review is in the works, so I'll send once we
> have it.
Ben - any status here?
Kent
>
> Kent
>
> >
> > Kent
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: PCI device not working
From: Davide Viti @ 2012-09-26 15:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <609C9A31-395A-4CB9-98BB-354E57E6658E@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 15755 bytes --]
Hi,
as you've suggested, I've added a printout inside fsl_pcie_check_link()
which is called twice and returns 0 both times.
Here follows the PCI-related part of dmesg with some extra printouts
enabled.
thank you,
Davide
...
Adding PCI host bridge /pcie@ffe09000
*** [/pcie@ffe09000] fsl_pcie_check_link() val=0x16 => return 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->255
->Hose at 0xc05a2000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000afffffff -> 0x00000000a0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000010000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base
0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0a000
*** [/pcie@ffe0a000] fsl_pcie_check_link() val=0x16 => return 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->255
->Hose at 0xc05a20e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x00000000b0000000..0x00000000bfffffff -> 0x00000000b0000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000b0000000, size 0x0000000010000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base
0x00000000ffc00000.
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
...
PCI: Probing PCI hardware
PCI: Scanning PHB /pcie@ffe09000
PCI: PHB IO resource = 00000000ff7ed000-00000000ff7fcfff [100]
PCI: PHB MEM resource 0 = 00000000a0000000-00000000afffffff [200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = ff7ed000
probe mode: 0
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: found [1957:0100] class 000b20 header type 01
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x54
pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x19c
pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x50
pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1a8
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
PCI: Fixup bus devices 0 (PHB)
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
result is /pcie@ffe09000/pcie@0
PCI: Try to map irq for 0000:00:00.0...
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
result is /pcie@ffe09000/pcie@0
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: found [1b65:abba] class 000280 header type 00
pci 0000:01:00.0: reg 10: [mem 0xa0000000-0xa00003ff]
pci 0000:01:00.0: reg 14: [mem 0xa0010000-0xa001ffff]
pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0x19c
PCI:0000:01:00.0 Resource 0 00000000a0000000-00000000a00003ff [40200]
fixup...
PCI:0000:01:00.0 00000000a0000000-00000000a00003ff
PCI:0000:01:00.0 Resource 1 00000000a0010000-00000000a001ffff [40200]
fixup...
PCI:0000:01:00.0 00000000a0010000-00000000a001ffff
pci 0000:01:00.0: calling quirk_resource_alignment+0x0/0x1a8
pci_bus 0000:01: fixups for bus
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xa00fffff]
pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref]
(disabled)
PCI:0000:00:00.0 Bus rsrc 1 00000000a0000000-00000000a00fffff [200] fixup...
PCI:0000:00:00.0 00000000a0000000-00000000a00fffff
PCI: Fixup bus devices 1 (0000:00:00.0)
pci_busdev_to_OF_node(1,0x0)
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
parent is /pcie@ffe09000/pcie@0
result is <NULL>
PCI: Try to map irq for 0000:01:00.0...
pci_busdev_to_OF_node(1,0x0)
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
parent is /pcie@ffe09000/pcie@0
result is <NULL>
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
result is /pcie@ffe09000/pcie@0
Got one, spec 1 cells (0x00000001 0xffffffff...) on /soc@ffe00000/pic@40000
alloc irq_desc for 16 on node 0
alloc kstat_irqs on node 0
irq: irq 1 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
Mapped to linux irq 16
pci_bus 0000:01: bus scan returning with max=01
pci_bus 0000:00: bus scan returning with max=01
PCI: Scanning PHB /pcie@ffe0a000
PCI: PHB IO resource = 00000000ff7db000-00000000ff7eafff [100]
PCI: PHB MEM resource 0 = 00000000b0000000-00000000bfffffff [200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = ff7db000
probe mode: 0
pci_bus 0001:02: scanning bus
pci 0001:02:00.0: found [1957:0100] class 000b20 header type 01
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: calling fixup_hide_host_resource_fsl+0x0/0x54
pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x19c
pci 0001:02:00.0: calling quirk_fsl_pcie_header+0x0/0x50
pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1a8
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
pci_bus 0001:02: fixups for bus
PCI: Fixup bus devices 2 (PHB)
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
result is /pcie@ffe0a000/pcie@0
PCI: Try to map irq for 0001:02:00.0...
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
*** scan_OF_for_pci_dev() reg[0]: 0x0 psize:0x14 devfn:0x0
result is /pcie@ffe0a000/pcie@0
pci 0001:02:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0001:02:00.0: bus configuration invalid, reconfiguring
pci 0001:02:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:03: scanning bus
pci_bus 0001:03: fixups for bus
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0001:02:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:02:00.0: bridge window [mem 0xb0000000-0xb00fffff]
pci 0001:02:00.0: bridge window [mem 0x10000000-0x000fffff pref]
(disabled)
PCI:0001:02:00.0 Bus rsrc 1 00000000b0000000-00000000b00fffff [200] fixup...
PCI:0001:02:00.0 00000000b0000000-00000000b00fffff
PCI: Fixup bus devices 3 (0001:02:00.0)
pci_bus 0001:03: bus scan returning with max=03
pci_bus 0001:02: bus scan returning with max=03
PCI->OF bus map (pci_bus_count=4):
0 -> 0
2 -> 0
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff [0x100],
parent c04cd81c (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 00000000a0000000-00000000afffffff [0x200],
parent c04cd800 (PCI mem)
PCI: Allocating bus resources for 0000:01...
PCI: 0000:00:00.0 (bus 1) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff
[0x100], parent c05a204c (/pcie@ffe09000)
PCI: 0000:00:00.0 (bus 1) bridge rsrc 1: 00000000a0000000-00000000afffffff
[0x200], parent c05a2068 (/pcie@ffe09000)
PCI: Allocating bus resources for 0001:02...
PCI: PHB (bus 2) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff [0x100],
parent c04cd81c (PCI IO)
PCI: PHB (bus 2) bridge rsrc 1: 00000000b0000000-00000000bfffffff [0x200],
parent c04cd800 (PCI mem)
PCI: Allocating bus resources for 0001:03...
PCI: 0001:02:00.0 (bus 3) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff
[0x100], parent c05a212c (/pcie@ffe0a000)
PCI: 0001:02:00.0 (bus 3) bridge rsrc 1: 00000000b0000000-00000000bfffffff
[0x200], parent c05a2148 (/pcie@ffe0a000)
PCI: Allocating 0000:01:00.0: Resource 0:
00000000a0000000..00000000a00003ff [40200]
PCI: Allocating 0000:01:00.0: Resource 1:
00000000a0010000..00000000a001ffff [40200]
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0xff7ed000-0xff7edfff]
PCI 0000:00 Cannot reserve Legacy IO [io 0xff7ed000-0xff7edfff]
hose mem offset: 0000000000000000
hose mem res: [mem 0xa0000000-0xafffffff]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0xff7db000-0xff7dbfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xff7db000-0xff7dbfff]
hose mem offset: 0000000000000000
hose mem res: [mem 0xb0000000-0xbfffffff]
PCI: Assigning unassigned resources...
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xff7ed000-0xff7fcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xafffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xff7db000-0xff7eafff]
pci 0001:02:00.0: bridge window [mem 0xb0000000-0xbfffffff]
pci 0001:02:00.0: bridge window [mem pref disabled]
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xafffffff]
pci_bus 0000:01: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xafffffff]
pci_bus 0001:02: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:02: resource 1 [mem 0xb0000000-0xbfffffff]
pci_bus 0001:03: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:03: resource 1 [mem 0xb0000000-0xbfffffff]
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
Freescale Elo / Elo Plus DMA driver
Switching to clocksource timebase
NET: Registered protocol family 2
pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x50
pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x6ac
pci 0000:01:00.0: calling quirk_cardbus_legacy+0x0/0x50
pci 0000:01:00.0: calling quirk_usb_early_handoff+0x0/0x6ac
pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x50
pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x6ac
2012/9/26 Kumar Gala <galak@kernel.crashing.org>
>
> > 2012/9/24 Davide Viti <zinosat@tiscali.it>
> > Hi,
> > does the output I've included show anything wrong or should I post
> something else to help identifying the cause of the problem?
> >
> > thank you in advance,
> > Davide
> >
> > 2012/9/21 Davide Viti <zinosat@tiscali.it>
> > I mean there are two controllers and both of them have a device
> "subtended" (both 0x1b65:0xabba).
> > u-boot can see both devices, linux detects only the device attached to
> the first controller.
> >
> > Here's the output of lspci and /proc/iomem :
> >
> > root@(none):/# lspci -v
> >
> > 0000:00:00.0 Class 0604: Device 1957:0100 (rev 11)
> >
> > Flags: bus master, fast devsel, latency 0
> >
> > Memory at <ignored> (32-bit, non-prefetchable)
> >
> > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> >
> > I/O behind bridge: 00000000-00000fff
> >
> > Memory behind bridge: a0000000-afffffff
> >
> > Capabilities: [44] Power Management version 2
> >
> > Capabilities: [4c] Express Root Port (Slot-), MSI 00
> >
> > Capabilities: [100] Advanced Error Reporting
> >
> >
> > 0000:01:00.0 Class 0280: Device 1b65:abba (rev 01)
> >
> > Flags: bus master, fast devsel, latency 0, IRQ 16
> >
> > Memory at a0000000 (32-bit, non-prefetchable) [size=1K]
> >
> > Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
> >
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> >
> > Capabilities: [78] Power Management version 3
> >
> > Capabilities: [80] Express Endpoint, MSI 00
> >
> > Capabilities: [100] Virtual Channel <?>
> >
> > Capabilities: [800] Advanced Error Reporting
> >
> >
> > 0001:02:00.0 Class 0604: Device 1957:0100 (rev 11)
> >
> > Flags: bus master, fast devsel, latency 0
> >
> > Memory at <ignored> (32-bit, non-prefetchable)
> >
> > Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> >
> > I/O behind bridge: 00000000-00000fff
> >
> > Memory behind bridge: b0000000-bfffffff
> >
> > Capabilities: [44] Power Management version 2
> >
> > Capabilities: [4c] Express Root Port (Slot-), MSI 00
> >
> > Capabilities: [100] Advanced Error Reporting
>
> Its possible that in linux the 2nd controller does not believe it has link
> status. Can you see if there is a function like fsl_pcie_check_link() in
> your kernel. If so maybe add a printk debug message there and see what
> gets return.
>
> Also helpful to post a full boot log.
>
> >
> >
> >
> >
> > root@(none):/# cat /proc/iomem
> >
> > a0000000-afffffff : /pcie@ffe09000
> >
> > a0000000-afffffff : PCI Bus 0000:01
> >
> > a0000000-a00003ff : 0000:01:00.0
> >
> > a0010000-a001ffff : 0000:01:00.0
> >
> > b0000000-bfffffff : /pcie@ffe0a000
> >
> > b0000000-bfffffff : PCI Bus 0001:03
> >
> > ef000000-efffffff : ef000000.nor
> >
> > ffe04500-ffe04507 : serial
> >
> > ffe04600-ffe04607 : serial
> >
> >
> >
> > thanx for your help,
> >
> > Davide
> >
> >
> >
> >
> > I mean that the kernel detects the first controller and the device
> attached to it, plus the second controller: the device on the second
> controller is not detected (same device as the one detected on the first
> controller)
> >
> > 2012/9/21 Kumar Gala <galak@kernel.crashing.org>
> >
> > On Sep 21, 2012, at 6:33 AM, Davide Viti wrote:
> >
> > > Hi,
> > > I'm working on a custom board based on P1020 with two (identical) PCI
> devices attached;
> > > The work is derived from another board with a single instance of that
> device.
> > > The system is based on u-boot-2009.11 and Linux 2.6.34.6
> > >
> > > The "pci" command on u-boot, shows me both the PCI controllers and
> > > the attached devices:
> > >
> > > Scanning PCI devices on bus 0
> > > BusDevFun VendorId DeviceId Device Class Sub-Class
> > > _____________________________________________________________
> > > 00.00.00 0x1957 0x0100 Processor 0x20
> > >
> > > Scanning PCI devices on bus 1
> > > BusDevFun VendorId DeviceId Device Class Sub-Class
> > > _____________________________________________________________
> > > 01.00.00 0x1b65 0xabba Network controller 0x80
> > >
> > > Scanning PCI devices on bus 2
> > > BusDevFun VendorId DeviceId Device Class Sub-Class
> > > _____________________________________________________________
> > > 02.00.00 0x1957 0x0100 Processor 0x20
> > >
> > > Scanning PCI devices on bus 3
> > > BusDevFun VendorId DeviceId Device Class Sub-Class
> > > _____________________________________________________________
> > > 03.00.00 0x1b65 0xabba Network controller 0x80
> > >
> > > The kernel detects only the first instance of the device.
> >
> > What do you mean by first instance of the device ?
> >
> > > Didn't get very far while looking at dts file and kernel logs, so I'm
> > > asking for some help on narrowing down the problem.
> > >
> > > I'm wondering if I can assume that the problem is restricted to
> > > kernel/dts and avoid concentrating on uboot.
> > > I can provide any log (didn't want to post tons of details on the first
> > > message)
> >
> > Probably a dts issue.
> >
> > What does lspci in linux say?
> >
> > - k
> >
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 19779 bytes --]
^ permalink raw reply
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