* [PATCH] powerpc: Fix build failure
From: Pranith Kumar @ 2014-08-21 13:04 UTC (permalink / raw)
To: Alistair Popple, Matt Porter, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, open list:LINUX FOR POWERPC...,
open list
Fix the following build failure
drivers/built-in.o: In function `nhi_init':
nhi.c:(.init.text+0x63390): undefined reference to `ehci_init_driver'
by adding a dependency on USB_EHCI_HCD which supplies the ehci_init_driver().
Also we need to depend on USB_OHCI_HCD similarly
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
arch/powerpc/platforms/44x/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 4d88f6a..3e7deb2 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -216,8 +216,8 @@ config AKEBONO
select IBM_EMAC_EMAC4
select IBM_EMAC_RGMII_WOL
select USB
- select USB_OHCI_HCD_PLATFORM
- select USB_EHCI_HCD_PLATFORM
+ select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
+ select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
select MMC_SDHCI
select MMC_SDHCI_PLTFM
select MMC_SDHCI_OF_476GTR
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc: Fix build failure when CONFIG_USB=y
From: Pranith Kumar @ 2014-08-21 13:16 UTC (permalink / raw)
To: Alistair Popple, Matt Porter, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, open list:LINUX FOR POWERPC...,
open list
We are enabling USB unconditionally which results in following build failure
drivers/built-in.o: In function `tb_drom_read':
(.text+0x1b62b70): undefined reference to `usb_speed_string'
make: *** [vmlinux] Error
Enable USB only if USB_SUPPORT is set to avoid such failures
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
arch/powerpc/platforms/44x/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 3e7deb2..82f2da2 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -215,7 +215,7 @@ config AKEBONO
select NET_VENDOR_IBM
select IBM_EMAC_EMAC4
select IBM_EMAC_RGMII_WOL
- select USB
+ select USB if USB_SUPPORT
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
select MMC_SDHCI
--
1.9.1
^ permalink raw reply related
* Re: [RFC PATCH powerpc] Fix warning reported by verify_cpu_node_mapping()
From: Nishanth Aravamudan @ 2014-08-21 15:45 UTC (permalink / raw)
To: Li Zhong; +Cc: Michael Ellerman, PowerPC email list, Paul Mackerras
In-Reply-To: <1408608842.3003.20.camel@TP420>
On 21.08.2014 [16:14:02 +0800], Li Zhong wrote:
> With commit 2fabf084b, during boottime, cpu_numa_callback() is called
> earlier(before their online) for each cpu, and verify_cpu_node_mapping()
> uses cpu_to_node() to check whether siblings are in the same node.
>
> It skips the checking for siblings that are not online yet. So the only
> check done here is for the bootcpu, which is online at that time. But
> the per-cpu numa_node cpu_to_node() uses hasn't been set up yet (which
> will be set up in smp_prepare_cpus()).
>
> So I could see something like following reported:
> [ 0.000000] CPU thread siblings 1/2/3 and 0 don't belong to the same
> node!
You mean you did see this, right? (as opposed to "could" based upon code
inspection or something)
>
> As we don't actually do the checking during this early stage, so maybe
> we could directly call numa_setup_cpu() in do_init_bootmem()?
>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index d7737a5..9918c02 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1128,8 +1128,7 @@ void __init do_init_bootmem(void)
> * early in boot, cf. smp_prepare_cpus().
> */
> for_each_possible_cpu(cpu) {
> - cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
> - (void *)(unsigned long)cpu);
> + numa_setup_cpu((unsigned long)cpu);
This is a good change, thanks for catching it. I must have glossed over
those messages in my testing, my apologies!
-Nish
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Drop unnecessary continue
From: Robert Jennings @ 2014-08-21 15:51 UTC (permalink / raw)
To: Michael Ellerman, Himangi Saraogi
Cc: linux-kernel, Julia Lawall, Paul Mackerras, Brian King,
linuxppc-dev
In-Reply-To: <1408596086.9307.3.camel@concordia>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 08/20/2014 11:41 PM, Michael Ellerman wrote:
> On Wed, 2014-08-13 at 14:48 +0530, Himangi Saraogi wrote:
>> Continue is not needed at the bottom of a loop.
>
> True.
>
> I wonder though, is the code trying to continue to the outer loop?
> I stared at it for a minute but it wasn't obvious.
>
> I wonder if Robert still remembers?
I don't recall what the intent was here. Can't believe that it's been
almost 5 years since I wrote this. I wish I had left a few more
comments in the code for me to go on.
Obviously the continue should be removed since it's not doing
anything. I don't believe that we'd want a continue statement in
there to get outer loop. That would change the current cmm_page_array
pointer (pa_curr) to the next in the list after it may have just been
reassigned to pa_last->next.
It may be the case that an earlier version of the code had statements
in the inner loop after that continue that I wanted to skip, or I just
did something silly.
- --Rob
> cheers
>
>> diff --git a/arch/powerpc/platforms/pseries/cmm.c
>> b/arch/powerpc/platforms/pseries/cmm.c index 2d8bf15..fc44ad0
>> 100644 --- a/arch/powerpc/platforms/pseries/cmm.c +++
>> b/arch/powerpc/platforms/pseries/cmm.c @@ -555,7 +555,6 @@ static
>> int cmm_mem_going_offline(void *arg) pa_last = pa_last->next;
>> free_page((unsigned long)cmm_page_list); cmm_page_list =
>> pa_last; - continue; } } pa_curr = pa_curr->next;
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJT9hV/AAoJEHQMPZ7t8u1zkNIP/1UMhxuNOHaYucs6nuiKT+HY
i0fDGKAluFrF7pv1Onon9LPUEPSL4Smr7l+FoSSJOP59vHg7F3HnkMu43GQi9X9o
KTQTzt5v0XjKeoKaZcgRD5wIp2J9Rz7CVd3RuYrXZGbIo5WC793Ko+8bEMQkSZv3
75e15WuK1J37e7RHIEmj82oeNj8HAWphkS2+c4JyBWCwVABNLOmC9oY0H2UjPQKe
IOsd8GfHMc4ML+Mrfe14ejsNl7XAfy+Q+Mvot/tuZqSq6G1YiX6MQAXk2yW7QAvE
7tfKZvyPVHylERs5Otk4wwh1YmA0RMTjbf3rkPUyUQs14esOa9aOiVDbFci++C/t
m8c3bF3RbdlWaygnDAodWMH4IP7q9mmLMgk6TZ0LNypOUsqedblHrsNKKnC3jm/y
ju/PzLeU5vJ5UoKF+X6jKpHJB5pLh6v4PVWixXKc0nMiGsg/U/RLDxgow+aA2tfx
psttc5DsxucUqlt1X7Y3yUULOI5mNx4tB/Pd37vTG+KJ16UOzAwuc8oQ/9ulVIj0
omW1+qW0MzXQ0Mezt1iqtN8bqarkj3z/aLZ6vjetnDg60JNlEofpSnJb6ANixJlj
PL/nk3LZjjY6UW79ttikrSnsp6fAUIv8ykxukGZLdO/tUj4pUA5H/2Ab5P1SR0Cx
4M1e9AUR+xvU7KDfYryr
=9qwq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression
From: Scott Wood @ 2014-08-21 21:19 UTC (permalink / raw)
To: Aaron Sierra; +Cc: Minghuan Lian, linuxppc-dev
In-Reply-To: <1335064415.96829.1408578704825.JavaMail.zimbra@xes-inc.com>
On Wed, 2014-08-20 at 18:51 -0500, Aaron Sierra wrote:
> @@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev, int is_primary)
> goto no_bridge;
>
> } else {
> - /* For PCI read PROG to identify controller mode */
> - early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
> - if ((progif & 1) == 1)
> + u16 master;
> +
> + /*
> + * If the controller is PCI-X, then Host mode refers to a
> + * bridge that drives the PCI-X initialization pattern to
> + * indicate bus operating mode/frequency to devices on the bus.
> + * Some hardware (specifically PrPMC modules) are Agents, since
> + * the mezzanine carrier is responsible for driving the
> + * pattern, but they still may perform bus enumeration.
> + *
> + * Allow the bridge to be used for enumeration, if hardware
> + * strapping (Host mode) or firmware (Agent mode) has enabled
> + * bus mastering.
> + */
> + early_read_config_word(hose, 0, 0, PCI_COMMAND, &master);
> + if (!(master & PCI_COMMAND_MASTER))
> goto no_bridge;
> }
Why wouldn't a normal PCI agent be able to bus master?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression
From: Aaron Sierra @ 2014-08-21 21:54 UTC (permalink / raw)
To: Scott Wood; +Cc: Minghuan Lian, linuxppc-dev
In-Reply-To: <1408655996.2395.7.camel@snotra.buserror.net>
----- Original Message -----
> From: "Scott Wood" <scottwood@freescale.com>
> Sent: Thursday, August 21, 2014 4:19:56 PM
>
> On Wed, 2014-08-20 at 18:51 -0500, Aaron Sierra wrote:
> > @@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev, int
> > is_primary)
> > goto no_bridge;
> >
> > } else {
> > - /* For PCI read PROG to identify controller mode */
> > - early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
> > - if ((progif & 1) == 1)
> > + u16 master;
> > +
> > + /*
> > + * If the controller is PCI-X, then Host mode refers to a
> > + * bridge that drives the PCI-X initialization pattern to
> > + * indicate bus operating mode/frequency to devices on the bus.
> > + * Some hardware (specifically PrPMC modules) are Agents, since
> > + * the mezzanine carrier is responsible for driving the
> > + * pattern, but they still may perform bus enumeration.
> > + *
> > + * Allow the bridge to be used for enumeration, if hardware
> > + * strapping (Host mode) or firmware (Agent mode) has enabled
> > + * bus mastering.
> > + */
> > + early_read_config_word(hose, 0, 0, PCI_COMMAND, &master);
> > + if (!(master & PCI_COMMAND_MASTER))
> > goto no_bridge;
> > }
>
> Why wouldn't a normal PCI agent be able to bus master?
>
> -Scott
>
Short answer:
Simply because the hardware strapping for Host/Agent determines the
default state of the Bus Master bit in the Command register. Without
that bit being set, an Agent won't be able to send the PCI cycles
necessary to enumerate the bus.
Long answer:
I think there was an assumption in the patch that introduced the
regression that Host and Agent in conventional PCI and PCI-X are more
equivalent to PCIe Root Complex and Endpoint than they really are.
I think the purpose of Minghuan's patch was to not attempt to enumerate
the bus with a bridge that simply cannot do it. A PCIe Endpoint cannot
enumerate the bus and a PCI/PCI-X device that cannot master cycles on the
bus will not be able to enumerate the bus either.
The hardware strapping for Host/Agent mode determines the default state
of the Bus Master bit in the Command register.
In our more specialized, but still industry standardized, environment our
firmware must detect whether our board should be the bus's sole enumerator
and set the Bus Master bit accordingly.
My comment in the code still mentions Host and Agent mode, simply because
the code it is replacing based its decision on the mode.
-Aaron
^ permalink raw reply
* Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression
From: Scott Wood @ 2014-08-21 22:01 UTC (permalink / raw)
To: Aaron Sierra; +Cc: Minghuan Lian, linuxppc-dev
In-Reply-To: <529271512.72955.1408658076028.JavaMail.zimbra@xes-inc.com>
On Thu, 2014-08-21 at 16:54 -0500, Aaron Sierra wrote:
> ----- Original Message -----
> > From: "Scott Wood" <scottwood@freescale.com>
> > Sent: Thursday, August 21, 2014 4:19:56 PM
> >
> > On Wed, 2014-08-20 at 18:51 -0500, Aaron Sierra wrote:
> > > @@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev, int
> > > is_primary)
> > > goto no_bridge;
> > >
> > > } else {
> > > - /* For PCI read PROG to identify controller mode */
> > > - early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
> > > - if ((progif & 1) == 1)
> > > + u16 master;
> > > +
> > > + /*
> > > + * If the controller is PCI-X, then Host mode refers to a
> > > + * bridge that drives the PCI-X initialization pattern to
> > > + * indicate bus operating mode/frequency to devices on the bus.
> > > + * Some hardware (specifically PrPMC modules) are Agents, since
> > > + * the mezzanine carrier is responsible for driving the
> > > + * pattern, but they still may perform bus enumeration.
> > > + *
> > > + * Allow the bridge to be used for enumeration, if hardware
> > > + * strapping (Host mode) or firmware (Agent mode) has enabled
> > > + * bus mastering.
> > > + */
> > > + early_read_config_word(hose, 0, 0, PCI_COMMAND, &master);
> > > + if (!(master & PCI_COMMAND_MASTER))
> > > goto no_bridge;
> > > }
> >
> > Why wouldn't a normal PCI agent be able to bus master?
> >
> > -Scott
> >
>
> Short answer:
>
> Simply because the hardware strapping for Host/Agent determines the
> default state of the Bus Master bit in the Command register. Without
> that bit being set, an Agent won't be able to send the PCI cycles
> necessary to enumerate the bus.
But what if the host has already set that bit before Linux boots?
> Long answer:
>
> I think there was an assumption in the patch that introduced the
> regression that Host and Agent in conventional PCI and PCI-X are more
> equivalent to PCIe Root Complex and Endpoint than they really are.
>
> I think the purpose of Minghuan's patch was to not attempt to enumerate
> the bus with a bridge that simply cannot do it. A PCIe Endpoint cannot
> enumerate the bus and a PCI/PCI-X device that cannot master cycles on the
> bus will not be able to enumerate the bus either.
No, the point is also to not enumerate the bus in cases where we
shouldn't. We don't want to step on the host's toes.
> The hardware strapping for Host/Agent mode determines the default state
> of the Bus Master bit in the Command register.
>
> In our more specialized, but still industry standardized, environment our
> firmware must detect whether our board should be the bus's sole enumerator
> and set the Bus Master bit accordingly.
>
> My comment in the code still mentions Host and Agent mode, simply because
> the code it is replacing based its decision on the mode.
I understand why you need to do this -- I just don't think this is a
reliable way of detecting that you're in that situation. How about a
kernel command line setting?
-Scott
^ permalink raw reply
* Re: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
From: Scott Wood @ 2014-08-21 22:22 UTC (permalink / raw)
To: Nikhil Badola; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1408612727-6774-1-git-send-email-nikhil.badola@freescale.com>
On Thu, 2014-08-21 at 14:48 +0530, Nikhil Badola wrote:
> Document compatible string containing IP version in USB device tree node
>
> Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
> ---
> Documentation/devicetree/bindings/usb/fsl-usb.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Please CC devicetree@vger.kernel.org on all device tree patches (in
addition to linuxppc-dev).
>
> diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> index 4779c02..5a3a0a8 100644
> --- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> @@ -10,7 +10,10 @@ Required properties :
> controllers, or "fsl-usb2-dr" for dual role USB controllers
> or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121.
> Wherever applicable, the IP version of the USB controller should
> - also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
> + also be mentioned in another string.
> + For multi port host USB controller with IP version <IP_Ver>, it should be
> + "fsl-usb2-mph-<IP_Ver>". For dual role USB controller with IP version
> + <IP_Ver>, it should be "fsl-usb2-dr-<IP_Ver>".
It was documented before -- this is just making it more explicit, right?
FWIW, the version number can be read out of a USB register, so I'd
rather remove the suggestion to specify the version number and replace
it with a reference to the ID register.
> - phy_type : For multi port host USB controllers, should be one of
> "ulpi", or "serial". For dual role USB controllers, should be
> one of "ulpi", "utmi", "utmi_wide", or "serial".
> @@ -42,9 +45,9 @@ Optional properties :
> - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
> the PWR_FAULT signal polarity is inverted.
>
> -Example multi port host USB controller device node :
> +Example multi port host USB controller version 2.5 device node :
> usb@22000 {
> - compatible = "fsl-usb2-mph";
> + compatible = "fsl-usb2-mph-v2.5", "fsl-usb2-mph";
> reg = <22000 1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -55,9 +58,9 @@ Example multi port host USB controller device node :
> port1;
> };
>
> -Example dual role USB controller device node :
> +Example dual role USB controller version 2.5 device node :
> usb@23000 {
> - compatible = "fsl-usb2-dr";
> + compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> reg = <23000 1000>;
> #address-cells = <1>;
> #size-cells = <0>;
This example doesn't correspond to any device tree I see. Even after
your next patch that sets t2080's USB to v2.5, the addresses are
different.
Also, if you're going to update the example, please also update it to be
modern in other respects, such as using 0x for hex numbers (outside the
unit address).
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: dts: t208x: Change T208x USB controller version
From: Scott Wood @ 2014-08-21 22:36 UTC (permalink / raw)
To: Nikhil Badola; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1408617090-29692-1-git-send-email-nikhil.badola@freescale.com>
On Thu, 2014-08-21 at 16:01 +0530, Nikhil Badola wrote:
> Change USB controller version to 2.5 in compatible string for T2080/T2081
>
> Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
> ---
> Checkpatch warnings handled by commit 61a8c2c6fe71082de3ea8629589dcdd0cc5c3f02
That checkpatch warning is known to have false positives in cases where
the binding says "<CHIPNAME>-device" or "device-<VERSION>". If you want
to update the binding to give an example with a version, that's fine,
but checkpatch shouldn't be why. We're not going to update the binding
example again to match a different version the next time one is added to
a device tree...
> Documentation: dts: fsl-usb: Document USB node compatible string for IP version
>
> arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
> index 97479f0..aecee96 100644
> --- a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
> @@ -410,7 +410,7 @@
> /include/ "qoriq-gpio-3.dtsi"
> /include/ "qoriq-usb2-mph-0.dtsi"
> usb0: usb@210000 {
> - compatible = "fsl-usb2-mph-v2.4", "fsl-usb2-mph";
> + compatible = "fsl-usb2-mph-v2.5", "fsl-usb2-mph";
This is an example of why it's better to rely on version registers when
present.
-Scott
^ permalink raw reply
* Re: [RFC PATCH 0/4] Improve slab consumption with memoryless nodes
From: Nishanth Aravamudan @ 2014-08-22 1:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Han Pingtian, Matt Mackall, David Rientjes, Pekka Enberg,
Linux Memory Management List, Paul Mackerras, Tejun Heo,
Joonsoo Kim, linuxppc-dev, Christoph Lameter, Wanpeng Li,
Anton Blanchard
In-Reply-To: <20140814001301.GI11121@linux.vnet.ibm.com>
On 13.08.2014 [17:13:01 -0700], Nishanth Aravamudan wrote:
> Anton noticed (http://www.spinics.net/lists/linux-mm/msg67489.html) that
> on ppc LPARs with memoryless nodes, a large amount of memory was
> consumed by slabs and was marked unreclaimable. He tracked it down to
> slab deactivations in the SLUB core when we allocate remotely, leading
> to poor efficiency always when memoryless nodes are present.
>
> After much discussion, Joonsoo provided a few patches that help
> significantly. They don't resolve the problem altogether:
>
> - memory hotplug still needs testing, that is when a memoryless node
> becomes memory-ful, we want to dtrt
> - there are other reasons for going off-node than memoryless nodes,
> e.g., fully exhausted local nodes
>
> Neither case is resolved with this series, but I don't think that should
> block their acceptance, as they can be explored/resolved with follow-on
> patches.
>
> The series consists of:
>
> [1/4] topology: add support for node_to_mem_node() to determine the fallback node
> [2/4] slub: fallback to node_to_mem_node() node if allocating on memoryless node
>
> - Joonsoo's patches to cache the nearest node with memory for each
> NUMA node
>
> [3/4] Partial revert of 81c98869faa5 (""kthread: ensure locality of task_struct allocations")
>
> - At Tejun's request, keep the knowledge of memoryless node fallback to
> the allocator core.
>
> [4/4] powerpc: reorder per-cpu NUMA information's initialization
>
> - Fix what appears to be a bug with when the NUMA topology information
> is stored in the powerpc initialization code.
Andrew & others,
I know kernel summit is going on, so I'll be patient, but was just
curious if anyone had any further comments other than Christoph's on the
naming.
Thanks,
Nish
>
> arch/powerpc/kernel/smp.c | 12 ++++++------
> arch/powerpc/mm/numa.c | 13 ++++++++++---
> include/linux/topology.h | 17 +++++++++++++++++
> kernel/kthread.c | 2 +-
> mm/page_alloc.c | 1 +
> mm/slub.c | 24 ++++++++++++++++++------
> 6 files changed, 53 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH] ibmveth: Fix endian issues with rx_no_buffer statistic
From: Anton Blanchard @ 2014-08-22 1:36 UTC (permalink / raw)
To: santil, paulus; +Cc: netdev, linuxppc-dev
Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.
Since we do this in multiple places, create a helper function with a
comment explaining what is going on.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
---
Index: b/drivers/net/ethernet/ibm/ibmveth.c
===================================================================
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -292,6 +292,18 @@ failure:
atomic_add(buffers_added, &(pool->available));
}
+/*
+ * The final 8 bytes of the buffer list is a counter of frames dropped
+ * because there was not a buffer in the buffer list capable of holding
+ * the frame.
+ */
+static void ibmveth_update_rx_no_buffer(struct ibmveth_adapter *adapter)
+{
+ __be64 *p = adapter->buffer_list_addr + 4096 - 8;
+
+ adapter->rx_no_buffer = be64_to_cpup(p);
+}
+
/* replenish routine */
static void ibmveth_replenish_task(struct ibmveth_adapter *adapter)
{
@@ -307,8 +319,7 @@ static void ibmveth_replenish_task(struc
ibmveth_replenish_buffer_pool(adapter, pool);
}
- adapter->rx_no_buffer = *(u64 *)(((char*)adapter->buffer_list_addr) +
- 4096 - 8);
+ ibmveth_update_rx_no_buffer(adapter);
}
/* empty and free ana buffer pool - also used to do cleanup in error paths */
@@ -698,8 +709,7 @@ static int ibmveth_close(struct net_devi
free_irq(netdev->irq, netdev);
- adapter->rx_no_buffer = *(u64 *)(((char *)adapter->buffer_list_addr) +
- 4096 - 8);
+ ibmveth_update_rx_no_buffer(adapter);
ibmveth_cleanup(adapter);
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix warning reported by verify_cpu_node_mapping()
From: Li Zhong @ 2014-08-22 2:12 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: Michael Ellerman, PowerPC email list, Paul Mackerras
In-Reply-To: <20140821154529.GB10478@linux.vnet.ibm.com>
On 四, 2014-08-21 at 08:45 -0700, Nishanth Aravamudan wrote:
> On 21.08.2014 [16:14:02 +0800], Li Zhong wrote:
> > With commit 2fabf084b, during boottime, cpu_numa_callback() is called
> > earlier(before their online) for each cpu, and verify_cpu_node_mapping()
> > uses cpu_to_node() to check whether siblings are in the same node.
> >
> > It skips the checking for siblings that are not online yet. So the only
> > check done here is for the bootcpu, which is online at that time. But
> > the per-cpu numa_node cpu_to_node() uses hasn't been set up yet (which
> > will be set up in smp_prepare_cpus()).
> >
> > So I could see something like following reported:
> > [ 0.000000] CPU thread siblings 1/2/3 and 0 don't belong to the same
> > node!
>
> You mean you did see this, right? (as opposed to "could" based upon code
> inspection or something)
Yes, I did see the warnings. Seems I didn't express it precisely in
English ...
>
> >
> > As we don't actually do the checking during this early stage, so maybe
> > we could directly call numa_setup_cpu() in do_init_bootmem()?
> >
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
>
> Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Thank you for the review,
Zhong
>
> > ---
> > arch/powerpc/mm/numa.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > index d7737a5..9918c02 100644
> > --- a/arch/powerpc/mm/numa.c
> > +++ b/arch/powerpc/mm/numa.c
> > @@ -1128,8 +1128,7 @@ void __init do_init_bootmem(void)
> > * early in boot, cf. smp_prepare_cpus().
> > */
> > for_each_possible_cpu(cpu) {
> > - cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
> > - (void *)(unsigned long)cpu);
> > + numa_setup_cpu((unsigned long)cpu);
>
> This is a good change, thanks for catching it. I must have glossed over
> those messages in my testing, my apologies!
>
> -Nish
^ permalink raw reply
* [PATCH] powerpc: edac: Fix build error
From: Pranith Kumar @ 2014-08-22 2:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Doug Thompson, Borislav Petkov, Mauro Carvalho Chehab,
open list:LINUX FOR POWERPC..., open list, open list:EDAC-CORE
Cc: Andrew Morton
Fix the following build error:
drivers/edac/ppc4xx_edac.c: In function 'mfsdram':
drivers/edac/ppc4xx_edac.c:249: error: implicit declaration of function
'__mfdcri'
drivers/edac/ppc4xx_edac.c: In function 'mtsdram':
drivers/edac/ppc4xx_edac.c:266: error: implicit declaration of function
'__mtdcri'
drivers/edac/ppc4xx_edac.c:269: warning: 'return' with a value, in function
returning void
drivers/edac/ppc4xx_edac.c: In function 'ppc4xx_edac_init_csrows':
drivers/edac/ppc4xx_edac.c:924: warning: initialization from incompatible
pointer type
drivers/edac/ppc4xx_edac.c:977: error: request for member 'dimm' in something
not a structure or union
drivers/edac/ppc4xx_edac.c: In function 'ppc4xx_edac_map_dcrs':
drivers/edac/ppc4xx_edac.c:1209: warning: passing argument 1 of 'dcr_map_mmio'
discards qualifiers from pointer target type
This driver depends on PPC_DCR_NATIVE to be set for the relevant headers to be
included. Also if PPC_DCR_MMIO=n the build fails. So make PPC_DCR depend on both
these options.
This is compile tested only.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/Kconfig | 6 +++---
drivers/edac/ppc4xx_edac.c | 8 ++++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4bc7b62..9b90c1c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -233,15 +233,15 @@ config ARCH_SUSPEND_POSSIBLE
config PPC_DCR_NATIVE
bool
- default n
+ default y
config PPC_DCR_MMIO
bool
- default n
+ default y
config PPC_DCR
bool
- depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
+ depends on PPC_DCR_NATIVE && PPC_DCR_MMIO
default y
config PPC_OF_PLATFORM_PCI
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index ef6b7e0..8725b73 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -246,8 +246,8 @@ static const char * const ppc4xx_plb_masters[9] = {
static inline u32
mfsdram(const dcr_host_t *dcr_host, unsigned int idcr_n)
{
- return __mfdcri(dcr_host->base + SDRAM_DCR_ADDR_OFFSET,
- dcr_host->base + SDRAM_DCR_DATA_OFFSET,
+ return __mfdcri(dcr_host->host.native.base + SDRAM_DCR_ADDR_OFFSET,
+ dcr_host->host.native.base + SDRAM_DCR_DATA_OFFSET,
idcr_n);
}
@@ -263,8 +263,8 @@ mfsdram(const dcr_host_t *dcr_host, unsigned int idcr_n)
static inline void
mtsdram(const dcr_host_t *dcr_host, unsigned int idcr_n, u32 value)
{
- return __mtdcri(dcr_host->base + SDRAM_DCR_ADDR_OFFSET,
- dcr_host->base + SDRAM_DCR_DATA_OFFSET,
+ return __mtdcri(dcr_host->host.native.base + SDRAM_DCR_ADDR_OFFSET,
+ dcr_host->host.native.base + SDRAM_DCR_DATA_OFFSET,
idcr_n,
value);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] cpufreq: powernv: Register the driver with reboot notifier
From: Preeti U Murthy @ 2014-08-22 2:48 UTC (permalink / raw)
To: Viresh Kumar, Shilpasri G Bhat, Rafael J. Wysocki
Cc: linuxppc-dev@lists.ozlabs.org, Rafael J. Wysocki,
Linux Kernel Mailing List, Shilpasri G Bhat,
linux-pm@vger.kernel.org
In-Reply-To: <CAKohpon8ANWoy52B=_nSuNyHALrsQOLX4cA+690E=CifnVRFtg@mail.gmail.com>
Hi Viresh,
On 08/21/2014 11:56 AM, Viresh Kumar wrote:
> On 21 August 2014 10:36, Shilpasri G Bhat <shilpabhatppc@gmail.com> wrote:
>> The intention here is stop the cpufreq governor and then to set the cpus to
>> nominal frequency so as to ensure that the frequency won't be changed later.
>>
>> The .suspend callback of the driver is not called during reboot/kexec.
>> So we need an explicit reboot notifier to call cpufreq-suspend() to
>> suffice the requirement.
>
> Hi Shilpa,
>
> No, we can't allow any platform driver to misuse cpufreq_suspend().
> Platform drivers aren't *allowed* to call this routine.
At the moment this looks like the best way forward. We need to do this
cleanly by ensuring that we stop the governors and then call into the
driver to deal with the cpu frequency in its own way during reboot. The
best way to do this would be by calling this routine. Either this or
cpufreq_suspend() should be called in the reboot path generically. The
latter might not be an enticing option for other platforms.
Regards
Preeti U Murthy
>
> Now the deal is how do we move to nominal frequency on reboot..
> @Rafael: Any suggestions? How do we ensure that governors
> are stopped on these notifiers, or if there is some other solution here?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/85xx: Change vendor prefix for Intersil Corporation to isil
From: Rob Herring @ 2014-08-22 3:12 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, devicetree@vger.kernel.org, Alessandro Zummo,
Russell King, Pawel Moll, Ian Campbell, Rob Herring,
Paul Mackerras, Kumar Gala, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1408524184-31928-5-git-send-email-p.zabel@pengutronix.de>
On Wed, Aug 20, 2014 at 3:43 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Currently there is a wild mixture of isl, isil, and intersil
> compatibles in the kernel. At this point, changing the vendor
> symbol to the most often used variant, which is equal to the
> NASDAQ symbol, isil, should not hurt, since the isl1208 driver
> doesn't care either way.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> arch/powerpc/boot/dts/ppa8548.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/ppa8548.dts b/arch/powerpc/boot/dts/ppa8548.dts
> index 27b0699..000262b 100644
> --- a/arch/powerpc/boot/dts/ppa8548.dts
> +++ b/arch/powerpc/boot/dts/ppa8548.dts
> @@ -89,7 +89,7 @@
> &soc {
> i2c@3000 {
> rtc@6f {
> - compatible = "intersil,isl1208";
> + compatible = "isil,isl1208";
This is a mature platform. You cannot change it. You can add the new
string, but the dts and kernel need both strings.
I would just leave it all alone and add the new prefix and mark the
others deprecated.
Rob
> reg = <0x6f>;
> };
> };
> --
> 2.1.0.rc1
>
^ permalink raw reply
* RE: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
From: nikhil.badola @ 2014-08-22 4:48 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Ramneek Mehresh
In-Reply-To: <1408659774.2395.21.camel@snotra.buserror.net>
QWRkaW5nIFJhbW5lZWsNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBX
b29kIFNjb3R0LUIwNzQyMQ0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAyMiwgMjAxNCAzOjUzIEFN
DQo+IFRvOiBCYWRvbGEgTmlraGlsLUI0NjE3Mg0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFU
Q0hdIERvY3VtZW50YXRpb246IGR0czogZnNsLXVzYjogRG9jdW1lbnQgVVNCIG5vZGUNCj4gY29t
cGF0aWJsZSBzdHJpbmcgZm9yIElQIHZlcnNpb24NCj4gDQo+IE9uIFRodSwgMjAxNC0wOC0yMSBh
dCAxNDo0OCArMDUzMCwgTmlraGlsIEJhZG9sYSB3cm90ZToNCj4gPiBEb2N1bWVudCBjb21wYXRp
YmxlIHN0cmluZyBjb250YWluaW5nIElQIHZlcnNpb24gaW4gVVNCIGRldmljZSB0cmVlDQo+ID4g
bm9kZQ0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogTmlraGlsIEJhZG9sYSA8bmlraGlsLmJhZG9s
YUBmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUv
YmluZGluZ3MvdXNiL2ZzbC11c2IudHh0IHwgMTMgKysrKysrKystLS0tLQ0KPiA+ICAxIGZpbGUg
Y2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQ0KPiANCj4gUGxlYXNlIEND
IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnIG9uIGFsbCBkZXZpY2UgdHJlZSBwYXRjaGVzIChp
biBhZGRpdGlvbiB0bw0KPiBsaW51eHBwYy1kZXYpLg0KPiANCj4gPg0KPiA+IGRpZmYgLS1naXQg
YS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0DQo+ID4g
Yi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0DQo+ID4g
aW5kZXggNDc3OWMwMi4uNWEzYTBhOCAxMDA2NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2Rl
dmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlv
bi9kZXZpY2V0cmVlL2JpbmRpbmdzL3VzYi9mc2wtdXNiLnR4dA0KPiA+IEBAIC0xMCw3ICsxMCwx
MCBAQCBSZXF1aXJlZCBwcm9wZXJ0aWVzIDoNCj4gPiAgICAgY29udHJvbGxlcnMsIG9yICJmc2wt
dXNiMi1kciIgZm9yIGR1YWwgcm9sZSBVU0IgY29udHJvbGxlcnMNCj4gPiAgICAgb3IgImZzbCxt
cGM1MTIxLXVzYjItZHIiIGZvciBkdWFsIHJvbGUgVVNCIGNvbnRyb2xsZXJzIG9mIE1QQzUxMjEu
DQo+ID4gICAgIFdoZXJldmVyIGFwcGxpY2FibGUsIHRoZSBJUCB2ZXJzaW9uIG9mIHRoZSBVU0Ig
Y29udHJvbGxlciBzaG91bGQNCj4gPiAtICAgYWxzbyBiZSBtZW50aW9uZWQgKGZvciBlZy4gZnNs
LXVzYjItZHItdjIuMiBmb3IgYnNjOTEzMikuDQo+ID4gKyAgIGFsc28gYmUgbWVudGlvbmVkIGlu
IGFub3RoZXIgc3RyaW5nLg0KPiA+ICsgICBGb3IgbXVsdGkgcG9ydCBob3N0IFVTQiBjb250cm9s
bGVyIHdpdGggSVAgdmVyc2lvbiA8SVBfVmVyPiwgaXQgc2hvdWxkIGJlDQo+ID4gKyAgICJmc2wt
dXNiMi1tcGgtPElQX1Zlcj4iLiBGb3IgZHVhbCByb2xlIFVTQiBjb250cm9sbGVyIHdpdGggSVAg
dmVyc2lvbg0KPiA+ICsgICA8SVBfVmVyPiwgaXQgc2hvdWxkIGJlICJmc2wtdXNiMi1kci08SVBf
VmVyPiIuDQo+IA0KPiBJdCB3YXMgZG9jdW1lbnRlZCBiZWZvcmUgLS0gdGhpcyBpcyBqdXN0IG1h
a2luZyBpdCBtb3JlIGV4cGxpY2l0LCByaWdodD8NCj4gDQo+IEZXSVcsIHRoZSB2ZXJzaW9uIG51
bWJlciBjYW4gYmUgcmVhZCBvdXQgb2YgYSBVU0IgcmVnaXN0ZXIsIHNvIEknZCByYXRoZXINCj4g
cmVtb3ZlIHRoZSBzdWdnZXN0aW9uIHRvIHNwZWNpZnkgdGhlIHZlcnNpb24gbnVtYmVyIGFuZCBy
ZXBsYWNlIGl0IHdpdGggYQ0KPiByZWZlcmVuY2UgdG8gdGhlIElEIHJlZ2lzdGVyLg0KPiANCj4g
PiAgIC0gcGh5X3R5cGUgOiBGb3IgbXVsdGkgcG9ydCBob3N0IFVTQiBjb250cm9sbGVycywgc2hv
dWxkIGJlIG9uZSBvZg0KPiA+ICAgICAidWxwaSIsIG9yICJzZXJpYWwiLiBGb3IgZHVhbCByb2xl
IFVTQiBjb250cm9sbGVycywgc2hvdWxkIGJlDQo+ID4gICAgIG9uZSBvZiAidWxwaSIsICJ1dG1p
IiwgInV0bWlfd2lkZSIsIG9yICJzZXJpYWwiLg0KPiA+IEBAIC00Miw5ICs0NSw5IEBAIE9wdGlv
bmFsIHByb3BlcnRpZXMgOg0KPiA+ICAgLSBmc2wsaW52ZXJ0LXB3ci1mYXVsdCA6IGJvb2xlYW47
IGZvciBNUEM1MTIxIFVTQjAgb25seS4gSW5kaWNhdGVzDQo+ID4gICAgIHRoZSBQV1JfRkFVTFQg
c2lnbmFsIHBvbGFyaXR5IGlzIGludmVydGVkLg0KPiA+DQo+ID4gLUV4YW1wbGUgbXVsdGkgcG9y
dCBob3N0IFVTQiBjb250cm9sbGVyIGRldmljZSBub2RlIDoNCj4gPiArRXhhbXBsZSBtdWx0aSBw
b3J0IGhvc3QgVVNCIGNvbnRyb2xsZXIgdmVyc2lvbiAyLjUgZGV2aWNlIG5vZGUgOg0KPiA+ICAJ
dXNiQDIyMDAwIHsNCj4gPiAtCQljb21wYXRpYmxlID0gImZzbC11c2IyLW1waCI7DQo+ID4gKwkJ
Y29tcGF0aWJsZSA9ICJmc2wtdXNiMi1tcGgtdjIuNSIsICJmc2wtdXNiMi1tcGgiOw0KPiA+ICAJ
CXJlZyA9IDwyMjAwMCAxMDAwPjsNCj4gPiAgCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiAg
CQkjc2l6ZS1jZWxscyA9IDwwPjsNCj4gPiBAQCAtNTUsOSArNTgsOSBAQCBFeGFtcGxlIG11bHRp
IHBvcnQgaG9zdCBVU0IgY29udHJvbGxlciBkZXZpY2Ugbm9kZSA6DQo+ID4gIAkJcG9ydDE7DQo+
ID4gIAl9Ow0KPiA+DQo+ID4gLUV4YW1wbGUgZHVhbCByb2xlIFVTQiBjb250cm9sbGVyIGRldmlj
ZSBub2RlIDoNCj4gPiArRXhhbXBsZSBkdWFsIHJvbGUgVVNCIGNvbnRyb2xsZXIgdmVyc2lvbiAy
LjUgZGV2aWNlIG5vZGUgOg0KPiA+ICAJdXNiQDIzMDAwIHsNCj4gPiAtCQljb21wYXRpYmxlID0g
ImZzbC11c2IyLWRyIjsNCj4gPiArCQljb21wYXRpYmxlID0gImZzbC11c2IyLWRyLXYyLjUiLCAi
ZnNsLXVzYjItZHIiOw0KPiA+ICAJCXJlZyA9IDwyMzAwMCAxMDAwPjsNCj4gPiAgCQkjYWRkcmVz
cy1jZWxscyA9IDwxPjsNCj4gPiAgCQkjc2l6ZS1jZWxscyA9IDwwPjsNCj4gDQo+IFRoaXMgZXhh
bXBsZSBkb2Vzbid0IGNvcnJlc3BvbmQgdG8gYW55IGRldmljZSB0cmVlIEkgc2VlLiAgRXZlbiBh
ZnRlciB5b3VyIG5leHQNCj4gcGF0Y2ggdGhhdCBzZXRzIHQyMDgwJ3MgVVNCIHRvIHYyLjUsIHRo
ZSBhZGRyZXNzZXMgYXJlIGRpZmZlcmVudC4NCj4gDQo+IEFsc28sIGlmIHlvdSdyZSBnb2luZyB0
byB1cGRhdGUgdGhlIGV4YW1wbGUsIHBsZWFzZSBhbHNvIHVwZGF0ZSBpdCB0byBiZSBtb2Rlcm4N
Cj4gaW4gb3RoZXIgcmVzcGVjdHMsIHN1Y2ggYXMgdXNpbmcgMHggZm9yIGhleCBudW1iZXJzIChv
dXRzaWRlIHRoZSB1bml0IGFkZHJlc3MpLg0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* [PATCH] powerpc/book3s: Deliver machine check with MSR(RI=0) to guest as MCE
From: Mahesh J Salgaonkar @ 2014-08-22 4:53 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: Aravinda Prasad, Paul Mackerras
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
For machine check occurring while in guest, KVM layer tries recovery
and deliver MCE to guest if recovery is failed. For recovered errors
we just go back to normal functioning of guest. But there are cases
where we may hit MCE in guest with MSR(RI=0), which means MCE interrupt is
not recoverable and guest can not function normally it should go down to
panic path. The current implementation does not have check for MSR(RI=0)
which can cause guest to crash with Bad kernel stack pointer instead of
machine check oops message.
[26281.490060] Bad kernel stack pointer 3fff9ccce5b0 at c00000000000490c
[26281.490434] Oops: Bad kernel stack pointer, sig: 6 [#1]
[26281.490472] SMP NR_CPUS=2048 NUMA pSeries
This patch fixes this issue by checking MSR(RI=0) in KVM layer and forwarding
unrecoverable interrupt to guest which then panics with proper machine check
Oops message.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f0c4db7..b6844fb 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2275,7 +2275,6 @@ machine_check_realmode:
mr r3, r9 /* get vcpu pointer */
bl kvmppc_realmode_machine_check
nop
- cmpdi r3, 0 /* Did we handle MCE ? */
ld r9, HSTATE_KVM_VCPU(r13)
li r12, BOOK3S_INTERRUPT_MACHINE_CHECK
/*
@@ -2288,13 +2287,18 @@ machine_check_realmode:
* The old code used to return to host for unhandled errors which
* was causing guest to hang with soft lockups inside guest and
* makes it difficult to recover guest instance.
+ *
+ * if we receive machine check with MSR(RI=0) then deliver it to
+ * guest as machine check causing guest to crash.
*/
- ld r10, VCPU_PC(r9)
ld r11, VCPU_MSR(r9)
+ andi. r10, r11, MSR_RI /* check for unrecoverable exception */
+ beq 1f /* Deliver a machine check to guest */
+ ld r10, VCPU_PC(r9)
+ cmpdi r3, 0 /* Did we handle MCE ? */
bne 2f /* Continue guest execution. */
/* If not, deliver a machine check. SRR0/1 are already set */
- li r10, BOOK3S_INTERRUPT_MACHINE_CHECK
- ld r11, VCPU_MSR(r9)
+1: li r10, BOOK3S_INTERRUPT_MACHINE_CHECK
bl kvmppc_msr_interrupt
2: b fast_interrupt_c_return
^ permalink raw reply related
* Re: [PATCH] powerpc: edac: Fix build error
From: Borislav Petkov @ 2014-08-22 5:07 UTC (permalink / raw)
To: Pranith Kumar, Grant Erickson
Cc: open list, Paul Mackerras, Doug Thompson, Andrew Morton,
open list:EDAC-CORE, open list:LINUX FOR POWERPC...,
Mauro Carvalho Chehab
In-Reply-To: <1408673991-17892-1-git-send-email-bobby.prani@gmail.com>
On Thu, Aug 21, 2014 at 10:19:51PM -0400, Pranith Kumar wrote:
> Fix the following build error:
>
> drivers/edac/ppc4xx_edac.c: In function 'mfsdram':
> drivers/edac/ppc4xx_edac.c:249: error: implicit declaration of function
> '__mfdcri'
> drivers/edac/ppc4xx_edac.c: In function 'mtsdram':
> drivers/edac/ppc4xx_edac.c:266: error: implicit declaration of function
> '__mtdcri'
> drivers/edac/ppc4xx_edac.c:269: warning: 'return' with a value, in function
> returning void
> drivers/edac/ppc4xx_edac.c: In function 'ppc4xx_edac_init_csrows':
> drivers/edac/ppc4xx_edac.c:924: warning: initialization from incompatible
> pointer type
> drivers/edac/ppc4xx_edac.c:977: error: request for member 'dimm' in something
> not a structure or union
> drivers/edac/ppc4xx_edac.c: In function 'ppc4xx_edac_map_dcrs':
> drivers/edac/ppc4xx_edac.c:1209: warning: passing argument 1 of 'dcr_map_mmio'
> discards qualifiers from pointer target type
>
> This driver depends on PPC_DCR_NATIVE to be set for the relevant headers to be
> included. Also if PPC_DCR_MMIO=n the build fails. So make PPC_DCR depend on both
> these options.
>
> This is compile tested only.
This driver has been carried through the years from misc people after
its initial drop in 2009. And frankly, I'd prefer if someone with the
hardware could actually test it before we break it any further.
Alternatively, if it is obsolete and no one uses it, we could very well
delete it instead. Initial commit talks about the hw it supports:
dba7a77c0e40 ("edac: new ppc4xx driver module")
So it would be good if we got some opinions from the PPC crowd. Who are
on CC.
(leaving in the rest for context).
>
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> ---
> arch/powerpc/Kconfig | 6 +++---
> drivers/edac/ppc4xx_edac.c | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 4bc7b62..9b90c1c 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -233,15 +233,15 @@ config ARCH_SUSPEND_POSSIBLE
>
> config PPC_DCR_NATIVE
> bool
> - default n
> + default y
>
> config PPC_DCR_MMIO
> bool
> - default n
> + default y
>
> config PPC_DCR
> bool
> - depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
> + depends on PPC_DCR_NATIVE && PPC_DCR_MMIO
> default y
>
> config PPC_OF_PLATFORM_PCI
> diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
> index ef6b7e0..8725b73 100644
> --- a/drivers/edac/ppc4xx_edac.c
> +++ b/drivers/edac/ppc4xx_edac.c
> @@ -246,8 +246,8 @@ static const char * const ppc4xx_plb_masters[9] = {
> static inline u32
> mfsdram(const dcr_host_t *dcr_host, unsigned int idcr_n)
> {
> - return __mfdcri(dcr_host->base + SDRAM_DCR_ADDR_OFFSET,
> - dcr_host->base + SDRAM_DCR_DATA_OFFSET,
> + return __mfdcri(dcr_host->host.native.base + SDRAM_DCR_ADDR_OFFSET,
> + dcr_host->host.native.base + SDRAM_DCR_DATA_OFFSET,
> idcr_n);
> }
>
> @@ -263,8 +263,8 @@ mfsdram(const dcr_host_t *dcr_host, unsigned int idcr_n)
> static inline void
> mtsdram(const dcr_host_t *dcr_host, unsigned int idcr_n, u32 value)
> {
> - return __mtdcri(dcr_host->base + SDRAM_DCR_ADDR_OFFSET,
> - dcr_host->base + SDRAM_DCR_DATA_OFFSET,
> + return __mtdcri(dcr_host->host.native.base + SDRAM_DCR_ADDR_OFFSET,
> + dcr_host->host.native.base + SDRAM_DCR_DATA_OFFSET,
> idcr_n,
> value);
> }
> --
> 1.9.1
>
>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* RE: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
From: Ramneek Mehresh @ 2014-08-22 5:05 UTC (permalink / raw)
To: nikhil.badola@freescale.com, Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <af7cc70458bf471cb20938ce6498ccfe@BN1PR0301MB0593.namprd03.prod.outlook.com>
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYWRvbGEgTmlraGlsLUI0NjE3
MiANClNlbnQ6IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDEwOjE4IEFNDQpUbzogV29vZCBTY290
dC1CMDc0MjENCkNjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgZGV2aWNldHJlZUB2
Z2VyLmtlcm5lbC5vcmc7IE1laHJlc2ggUmFtbmVlay1CMzEzODMNClN1YmplY3Q6IFJFOiBbUEFU
Q0hdIERvY3VtZW50YXRpb246IGR0czogZnNsLXVzYjogRG9jdW1lbnQgVVNCIG5vZGUgY29tcGF0
aWJsZSBzdHJpbmcgZm9yIElQIHZlcnNpb24NCg0KQWRkaW5nIFJhbW5lZWsNCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiBTZW50OiBG
cmlkYXksIEF1Z3VzdCAyMiwgMjAxNCAzOjUzIEFNDQo+IFRvOiBCYWRvbGEgTmlraGlsLUI0NjE3
Mg0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGRldmljZXRyZWVAdmdlci5r
ZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIERvY3VtZW50YXRpb246IGR0czogZnNs
LXVzYjogRG9jdW1lbnQgVVNCIG5vZGUgDQo+IGNvbXBhdGlibGUgc3RyaW5nIGZvciBJUCB2ZXJz
aW9uDQo+IA0KPiBPbiBUaHUsIDIwMTQtMDgtMjEgYXQgMTQ6NDggKzA1MzAsIE5pa2hpbCBCYWRv
bGEgd3JvdGU6DQo+ID4gRG9jdW1lbnQgY29tcGF0aWJsZSBzdHJpbmcgY29udGFpbmluZyBJUCB2
ZXJzaW9uIGluIFVTQiBkZXZpY2UgdHJlZSANCj4gPiBub2RlDQo+ID4NCj4gPiBTaWduZWQtb2Zm
LWJ5OiBOaWtoaWwgQmFkb2xhIDxuaWtoaWwuYmFkb2xhQGZyZWVzY2FsZS5jb20+DQo+ID4gLS0t
DQo+ID4gIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91c2IvZnNsLXVzYi50eHQg
fCAxMyANCj4gPiArKysrKysrKy0tLS0tDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2VydGlv
bnMoKyksIDUgZGVsZXRpb25zKC0pDQo+IA0KPiBQbGVhc2UgQ0MgZGV2aWNldHJlZUB2Z2VyLmtl
cm5lbC5vcmcgb24gYWxsIGRldmljZSB0cmVlIHBhdGNoZXMgKGluIA0KPiBhZGRpdGlvbiB0byBs
aW51eHBwYy1kZXYpLg0KPiANCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2Rl
dmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0DQo+ID4gYi9Eb2N1bWVudGF0aW9uL2Rl
dmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0DQo+ID4gaW5kZXggNDc3OWMwMi4uNWEz
YTBhOCAxMDA2NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3Mv
dXNiL2ZzbC11c2IudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRp
bmdzL3VzYi9mc2wtdXNiLnR4dA0KPiA+IEBAIC0xMCw3ICsxMCwxMCBAQCBSZXF1aXJlZCBwcm9w
ZXJ0aWVzIDoNCj4gPiAgICAgY29udHJvbGxlcnMsIG9yICJmc2wtdXNiMi1kciIgZm9yIGR1YWwg
cm9sZSBVU0IgY29udHJvbGxlcnMNCj4gPiAgICAgb3IgImZzbCxtcGM1MTIxLXVzYjItZHIiIGZv
ciBkdWFsIHJvbGUgVVNCIGNvbnRyb2xsZXJzIG9mIE1QQzUxMjEuDQo+ID4gICAgIFdoZXJldmVy
IGFwcGxpY2FibGUsIHRoZSBJUCB2ZXJzaW9uIG9mIHRoZSBVU0IgY29udHJvbGxlciBzaG91bGQN
Cj4gPiAtICAgYWxzbyBiZSBtZW50aW9uZWQgKGZvciBlZy4gZnNsLXVzYjItZHItdjIuMiBmb3Ig
YnNjOTEzMikuDQo+ID4gKyAgIGFsc28gYmUgbWVudGlvbmVkIGluIGFub3RoZXIgc3RyaW5nLg0K
PiA+ICsgICBGb3IgbXVsdGkgcG9ydCBob3N0IFVTQiBjb250cm9sbGVyIHdpdGggSVAgdmVyc2lv
biA8SVBfVmVyPiwgaXQgc2hvdWxkIGJlDQo+ID4gKyAgICJmc2wtdXNiMi1tcGgtPElQX1Zlcj4i
LiBGb3IgZHVhbCByb2xlIFVTQiBjb250cm9sbGVyIHdpdGggSVAgdmVyc2lvbg0KPiA+ICsgICA8
SVBfVmVyPiwgaXQgc2hvdWxkIGJlICJmc2wtdXNiMi1kci08SVBfVmVyPiIuDQo+IA0KPiBJdCB3
YXMgZG9jdW1lbnRlZCBiZWZvcmUgLS0gdGhpcyBpcyBqdXN0IG1ha2luZyBpdCBtb3JlIGV4cGxp
Y2l0LCByaWdodD8NCj4gDQo+IEZXSVcsIHRoZSB2ZXJzaW9uIG51bWJlciBjYW4gYmUgcmVhZCBv
dXQgb2YgYSBVU0IgcmVnaXN0ZXIsIHNvIEknZCANCj4gcmF0aGVyIHJlbW92ZSB0aGUgc3VnZ2Vz
dGlvbiB0byBzcGVjaWZ5IHRoZSB2ZXJzaW9uIG51bWJlciBhbmQgcmVwbGFjZSANCj4gaXQgd2l0
aCBhIHJlZmVyZW5jZSB0byB0aGUgSUQgcmVnaXN0ZXIuDQp3ZSBoYXZlIGZvbGxvd2luZyB0d28g
aXNzdWVzIC0NCihhKSBvdXIgVVNCSVAgdmVyc2lvbiByZWdpc3RlciBkb2Vzbid0IGhhdmUgY29u
c2lzdGVudCAidmVyc2lvbiBmaWVsZCBzaXplIiBvdmVyIA0KbXVsdGlwbGUgdmVyc2lvbihzKS4g
VGhpcyBpcyB3aHkgd2UgY291bGRuJ3QgdXNlIGl0IGZvciByZWFkaW5nIHZlcnNpb24gaW5mbyBh
Y3Jvc3MNCnZhcmlvdXMgSVAgdmVyc2lvbnMNCihiKSB0aGlzIHJlZ2lzdGVyIGlzIG5vdCBleHBv
c2VkIGluIGFsbCBTb0MgUk1zIChwcm9iYWJseSBiZWNhdXNlIG9mIGFib3ZlIHJlYXNvbikNCj4g
DQo+ID4gICAtIHBoeV90eXBlIDogRm9yIG11bHRpIHBvcnQgaG9zdCBVU0IgY29udHJvbGxlcnMs
IHNob3VsZCBiZSBvbmUgb2YNCj4gPiAgICAgInVscGkiLCBvciAic2VyaWFsIi4gRm9yIGR1YWwg
cm9sZSBVU0IgY29udHJvbGxlcnMsIHNob3VsZCBiZQ0KPiA+ICAgICBvbmUgb2YgInVscGkiLCAi
dXRtaSIsICJ1dG1pX3dpZGUiLCBvciAic2VyaWFsIi4NCj4gPiBAQCAtNDIsOSArNDUsOSBAQCBP
cHRpb25hbCBwcm9wZXJ0aWVzIDoNCj4gPiAgIC0gZnNsLGludmVydC1wd3ItZmF1bHQgOiBib29s
ZWFuOyBmb3IgTVBDNTEyMSBVU0IwIG9ubHkuIEluZGljYXRlcw0KPiA+ICAgICB0aGUgUFdSX0ZB
VUxUIHNpZ25hbCBwb2xhcml0eSBpcyBpbnZlcnRlZC4NCj4gPg0KPiA+IC1FeGFtcGxlIG11bHRp
IHBvcnQgaG9zdCBVU0IgY29udHJvbGxlciBkZXZpY2Ugbm9kZSA6DQo+ID4gK0V4YW1wbGUgbXVs
dGkgcG9ydCBob3N0IFVTQiBjb250cm9sbGVyIHZlcnNpb24gMi41IGRldmljZSBub2RlIDoNCj4g
PiAgCXVzYkAyMjAwMCB7DQo+ID4gLQkJY29tcGF0aWJsZSA9ICJmc2wtdXNiMi1tcGgiOw0KPiA+
ICsJCWNvbXBhdGlibGUgPSAiZnNsLXVzYjItbXBoLXYyLjUiLCAiZnNsLXVzYjItbXBoIjsNCj4g
PiAgCQlyZWcgPSA8MjIwMDAgMTAwMD47DQo+ID4gIAkJI2FkZHJlc3MtY2VsbHMgPSA8MT47DQo+
ID4gIAkJI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gQEAgLTU1LDkgKzU4LDkgQEAgRXhhbXBsZSBt
dWx0aSBwb3J0IGhvc3QgVVNCIGNvbnRyb2xsZXIgZGV2aWNlIG5vZGUgOg0KPiA+ICAJCXBvcnQx
Ow0KPiA+ICAJfTsNCj4gPg0KPiA+IC1FeGFtcGxlIGR1YWwgcm9sZSBVU0IgY29udHJvbGxlciBk
ZXZpY2Ugbm9kZSA6DQo+ID4gK0V4YW1wbGUgZHVhbCByb2xlIFVTQiBjb250cm9sbGVyIHZlcnNp
b24gMi41IGRldmljZSBub2RlIDoNCj4gPiAgCXVzYkAyMzAwMCB7DQo+ID4gLQkJY29tcGF0aWJs
ZSA9ICJmc2wtdXNiMi1kciI7DQo+ID4gKwkJY29tcGF0aWJsZSA9ICJmc2wtdXNiMi1kci12Mi41
IiwgImZzbC11c2IyLWRyIjsNCj4gPiAgCQlyZWcgPSA8MjMwMDAgMTAwMD47DQo+ID4gIAkJI2Fk
ZHJlc3MtY2VsbHMgPSA8MT47DQo+ID4gIAkJI3NpemUtY2VsbHMgPSA8MD47DQo+IA0KPiBUaGlz
IGV4YW1wbGUgZG9lc24ndCBjb3JyZXNwb25kIHRvIGFueSBkZXZpY2UgdHJlZSBJIHNlZS4gIEV2
ZW4gYWZ0ZXIgDQo+IHlvdXIgbmV4dCBwYXRjaCB0aGF0IHNldHMgdDIwODAncyBVU0IgdG8gdjIu
NSwgdGhlIGFkZHJlc3NlcyBhcmUgZGlmZmVyZW50Lg0KPiANCkkgcmVja29uIHRoYXQgdGhlIGV4
YW1wbGUgZW1waGFzaXplcyBvbiBzaG93aW5nIGhvdyBJUCB2ZXJzaW9uIGluZm9ybWF0aW9uIGlz
DQp0byBiZSBzdG9yZWQgaW4gImNvbXBhdGlibGUgc3RyaW5nIi4gSXMgaXQgbmVjZXNzYXJ5IHRv
IG1ha2Ugc3VyZSB0aGF0IHdlIHNob3VsZCANCmFsd2F5cyBzaXRlIGFjdHVhbCB2YWx1ZXMgYWxy
ZWFkeSB1c2VkPw0KPiBBbHNvLCBpZiB5b3UncmUgZ29pbmcgdG8gdXBkYXRlIHRoZSBleGFtcGxl
LCBwbGVhc2UgYWxzbyB1cGRhdGUgaXQgdG8gDQo+IGJlIG1vZGVybiBpbiBvdGhlciByZXNwZWN0
cywgc3VjaCBhcyB1c2luZyAweCBmb3IgaGV4IG51bWJlcnMgKG91dHNpZGUgdGhlIHVuaXQgYWRk
cmVzcykuDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* [PATCH v2 5/5] MSI: Use __read_msi_msg() instead of read_msi_msg()
From: Yijing Wang @ 2014-08-22 8:08 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Yijing Wang, linux-pci, linuxppc-dev
In-Reply-To: <1408694880-8260-1-git-send-email-wangyijing@huawei.com>
Read_msi_msg() only be called in rtas_setup_msi_irqs(),
use __read_msi_msg() instead of read_msi_msg for
simplification. And rename __read_msi_msg() to
read_msi_msg().
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/pseries/msi.c | 2 +-
arch/x86/pci/xen.c | 2 +-
drivers/pci/msi.c | 9 +--------
include/linux/msi.h | 3 +--
4 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
index 18ff462..7e87878 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -485,7 +485,7 @@ again:
irq_set_msi_desc(virq, entry);
/* Read config space back so we can restore after reset */
- read_msi_msg(virq, &msg);
+ read_msi_msg(entry, &msg);
entry->msg = msg;
}
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4..ad03739 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -229,7 +229,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
return 1;
list_for_each_entry(msidesc, &dev->msi_list, list) {
- __read_msi_msg(msidesc, &msg);
+ read_msi_msg(msidesc, &msg);
pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
if (msg.data != XEN_PIRQ_MSI_DATA ||
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 8746ecd..aff384a 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -259,7 +259,7 @@ void default_restore_msi_irqs(struct pci_dev *dev)
}
}
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
BUG_ON(entry->dev->current_state != PCI_D0);
@@ -289,13 +289,6 @@ void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
}
}
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
-{
- struct msi_desc *entry = irq_get_msi_desc(irq);
-
- __read_msi_msg(entry, msg);
-}
-
void get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
/* Assert that the cache is valid, assuming that
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 329ec73..6be66f4 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -15,10 +15,9 @@ struct irq_data;
struct msi_desc;
void mask_msi_irq(struct irq_data *data);
void unmask_msi_irq(struct irq_data *data);
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void read_msi_msg(unsigned int irq, struct msi_msg *msg);
void write_msi_msg(unsigned int irq, struct msi_msg *msg);
struct msi_desc {
--
1.7.1
^ permalink raw reply related
* Re: [RFC PATCH 5/6] rtc: rtc-isl12022: Change vendor prefix for Intersil Corporation to isil
From: Philipp Zabel @ 2014-08-22 8:57 UTC (permalink / raw)
To: devicetree
Cc: Mark Rutland, Alessandro Zummo, Russell King, Pawel Moll,
Ian Campbell, Wolfram Sang, Rob Herring, Paul Mackerras,
Kumar Gala, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1408524184-31928-6-git-send-email-p.zabel@pengutronix.de>
Am Mittwoch, den 20.08.2014, 10:43 +0200 schrieb Philipp Zabel:
> Currently there is a wild mixture of isl, isil, and intersil
> compatibles in the kernel. At this point, changing the vendor
> symbol to the most often used variant, which is equal to the
> NASDAQ symbol, isil, should not hurt, since the isl1208 driver
> doesn't care either way.
> Patch db04d6284e2a added device tree support using the then
> documented isl vendor prefix, so we keep that around for
> backwards compatibility.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/rtc/rtc-isl12022.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
> index aa55f08..df20f18 100644
> --- a/drivers/rtc/rtc-isl12022.c
> +++ b/drivers/rtc/rtc-isl12022.c
> @@ -275,7 +275,8 @@ static int isl12022_probe(struct i2c_client *client,
>
> #ifdef CONFIG_OF
> static struct of_device_id isl12022_dt_match[] = {
> - { .compatible = "isl,isl12022" },
> + { .compatible = "isil,isl12022" },
> + { .compatible = "isl,isl12022" }, /* for backwards compatibility */
Actually, is it even necessary to keep this around in here?
If of_driver_match_device fails, i2c_device_match will continue to try
i2c_match_id if driver->id_table is set, which matches against the
result of of_modalias_node (dropping the vendor prefix altogether).
regards
Philipp
^ permalink raw reply
* [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
From: Jingchang Lu @ 2014-08-22 9:34 UTC (permalink / raw)
To: mturquette; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel, Jingchang Lu
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
drivers/clk/Kconfig | 7 ++++---
drivers/clk/clk-ppc-corenet.c | 5 +++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cfd3af7..8784704 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -82,11 +82,12 @@ config COMMON_CLK_AXI_CLKGEN
FPGAs. It is commonly used in Analog Devices' reference designs.
config CLK_PPC_CORENET
- bool "Clock driver for PowerPC corenet platforms"
- depends on PPC_E500MC && OF
+ bool "Clock driver for PowerPC corenet and compatible ARM-based platforms"
+ depends on (PPC_E500MC || ARM) && OF
---help---
This adds the clock driver support for Freescale PowerPC corenet
- platforms using common clock framework.
+ platforms and compatible Freescale ARM based platforms using common
+ clock framework.
config COMMON_CLK_XGENE
bool "Clock driver for APM XGene SoC"
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index 8e58edf..7692cac 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -305,3 +305,8 @@ static int __init ppc_corenet_clk_init(void)
return platform_driver_register(&ppc_corenet_clk_driver);
}
subsys_initcall(ppc_corenet_clk_init);
+
+CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0", core_pll_init);
+CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0", core_pll_init);
+CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0", core_mux_init);
+CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0", core_mux_init);
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects
From: Prabhakar Kushwaha @ 2014-08-22 14:37 UTC (permalink / raw)
To: Scott Wood; +Cc: Greg Kroah-Hartman, Aaron Sierra, linuxppc-dev, Arnd Bergmann
In-Reply-To: <1408576886.4058.73.camel@snotra.buserror.net>
Sorry Scott for late reply,
Please find my reply in-lined
On 8/21/2014 4:51 AM, Scott Wood wrote:
> On Wed, 2014-08-20 at 09:05 +0530, Prabhakar Kushwaha wrote:
>> On 8/20/2014 5:38 AM, Scott Wood wrote:
>>> On Fri, 2014-08-15 at 16:07 -0500, Aaron Sierra wrote:
>>>> Freescale's QorIQ T Series processors support 8 IFC chip selects
>>>> within a memory map backward compatible with previous P Series
>>>> processors which supported only 4 chip selects.
>>>>
>>>> Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
>>>> ---
>>>> include/linux/fsl_ifc.h | 10 +++++-----
>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
>>>> index 84d60cb..62762ff 100644
>>>> --- a/include/linux/fsl_ifc.h
>>>> +++ b/include/linux/fsl_ifc.h
>>>> @@ -29,7 +29,7 @@
>>>> #include <linux/of_platform.h>
>>>> #include <linux/interrupt.h>
>>>>
>>>> -#define FSL_IFC_BANK_COUNT 4
>>>> +#define FSL_IFC_BANK_COUNT 8
>>> First please modify fsl_ifc_nand.c to limit itself to the number of
>>> banks it dynamically determines are present based on the IFC version.
>>>
>>>
>> Number of available bank/chip select are defined by SoC and it is
>> independent of SoC.
> Do you mean defined by the SoC and independent of the IFC version?
IFC v 1.0.0 supports 4 Chip Select.
IFC v 1.1.0 onwards, IFC supports 8 chip select.
But SoC finally defines number of chip select coming out of SoC. Like
LS1021A with IFC ver 1.4.0 have only 7 Chip Select.
>> It should be fix in following way
>>
>> Option 1:
>> u-boot: fix device tree with number of available chip select. It may
>> require IFC binding change
>> Linux: Read device tree and determine the Chip Selects
> If we do this then it will need to be an optional property that defaults
> to the current assumption being made (4).
Yes, I agree with you.
> In the future we really ought to check whether there are integration
> parameters when coming up with the initial binding for a hardware
> block...
True.
>> Option 2:
>> Make it static because any way IFC NAND driver polls to
>> FSL_IFC_BANK_COUNT to know NAND flash chip select. This patch is doing same.
> I don't understand what you're saying here. The driver does not know at
> compile time how many there are. What this patch does is assume it's OK
> to access non-existent registers in the rare case that there's no match
> in the registers that exist.
in case of P1010, If we run loop for 8 times,
we are accessing reserved memory, that's why it may work. In Ideal
scenario, we should not access the reserved memory.
> Aaron tested this on P1010 and it seemed to work, though I'm not
> generally fond of relying on such things.
>
yes, I agree.
If I conclude ==> We should go with option 1. Am I correct?
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH 6/6] powerpc: Separate ppc32 symbol exports into ppc_ksyms_32.c
From: Stephen Rothwell @ 2014-08-22 15:25 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <1408485605-10490-6-git-send-email-anton@samba.org>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Hi Anton,
On Wed, 20 Aug 2014 08:00:05 +1000 Anton Blanchard <anton@samba.org> wrote:
>
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index aba41f3..c4dfff6 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -1,135 +1,42 @@
> -#include <linux/export.h>
You removed export.h ...
> +EXPORT_SYMBOL(flush_dcache_range);
> +EXPORT_SYMBOL(flush_icache_range);
But still use EXPORT_SYMBOL ...
Or did I miss something?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Move htab_remove_mapping function prototype into header file
From: Stephen Rothwell @ 2014-08-22 15:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <1408488921-19187-4-git-send-email-anton@samba.org>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
Hi Anton,
On Wed, 20 Aug 2014 08:55:21 +1000 Anton Blanchard <anton@samba.org> wrote:
>
> A recent patch added a function prototype for htab_remove_mapping in
> c code. Fix it.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 2 ++
> arch/powerpc/mm/init_64.c | 3 ---
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index d765144..92bc3a6 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -342,6 +342,8 @@ extern void hash_failure_debug(unsigned long ea, unsigned long access,
> extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
> unsigned long pstart, unsigned long prot,
> int psize, int ssize);
> +int htab_remove_mapping(unsigned long vstart, unsigned long vend,
> + int psize, int ssize);
Please be consistent about "extern" use (unless this file is already
inconsistent, I guess). (I know that the current trend is to remove
"extern" in header files - I just happen to disagree with that
trend. :-))
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 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