* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: Scott Wood @ 2009-12-07 18:05 UTC (permalink / raw)
To: 林志平; +Cc: linuxppc-dev
In-Reply-To: <8148211e0912061953n59dfbe4fsea033494ad8b6fcc@mail.gmail.com>
On Mon, Dec 07, 2009 at 11:53:22AM +0800, 林志平 wrote:
> Does dtc1.2.0 can compile dts files under linux2.6.23?
Probably not -- 2.6.23 is very old, and I think newer dtcs only support the
newer dts syntax.
> Another question is that I found linux2.6.31 does not support
> board mpc8544ds,
It should. What problems do you see?
> And I never boot linux-2.6.31 on my board, why linux-2.6.31 doesnot
> provide a config file like mpc8544_ds_defconfig?
Does mpc85xx_defconfig not work?
-Scott
^ permalink raw reply
* Re: dts file for MPC8343EA
From: Scott Wood @ 2009-12-07 18:07 UTC (permalink / raw)
To: ajijuni; +Cc: Linuxppc-dev
In-Reply-To: <7675847.584551260168085277.JavaMail.nabble@isper.nabble.com>
On Sun, Dec 06, 2009 at 10:41:25PM -0800, ajijuni@gmail.com wrote:
> Hi
>
> We have an MPC8343EA based custom board.
>
> I am not able to get Linux up and running in this. No serial output to debug further.
> U-boot shows correct 'bdinfo' & 'clocks' output.
> inux hangs at machine_probe.
Check that the platform file you're intending to use matches the compatible
field in the root node of the device tree -- and that said platform file is
actually being built.
-Scott
^ permalink raw reply
* Re: ZILOG serial port broken in 2.6.32
From: Rob Landley @ 2009-12-07 20:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev
In-Reply-To: <1260148248.2076.1348.camel@pasglop>
On Sunday 06 December 2009 19:10:48 Benjamin Herrenschmidt wrote:
> On Sun, 2009-12-06 at 01:01 -0600, Rob Landley wrote:
> > Trying again with a few likely-looking cc's from the MAINTAINERS file:
> >
> > Summary:
> >
> > The PMACZILOG serial driver last worked in 2.6.28. It was broken by
> > commit f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits
> > of the tty layer dynamically allocated. The PMACZILOG driver wasn't
> > properly converted, it works with interrupts disabled (for boot
> > messages), but as soon as interrupts are enabled (PID 1 spawns) the next
> > write to the serial console panics the kernel.
>
> Ah looks like I missed that... I'll dig. Thanks for the report.
Ooh, thanks!
I've been digging into it myself this weekend, but I don't understand any of
this code, so it's going slowly...
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* Re: [PATCH] powerpc: stop_this_cpu: remove the cpu from the online map.
From: Valentine @ 2009-12-07 21:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20091125214852.GA7912@ru.mvista.com>
Ben, is this OK?
Other architectures do the same thing.
Thanks,
Val.
Valentine Barshak wrote:
> Remove the CPU from the online map to prevent smp_call_function
> from sending messages to a stopped CPU.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/kernel/smp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff -pruN linux-2.6.orig/arch/powerpc/kernel/smp.c linux-2.6/arch/powerpc/kernel/smp.c
> --- linux-2.6.orig/arch/powerpc/kernel/smp.c 2009-11-26 00:22:15.000000000 +0300
> +++ linux-2.6/arch/powerpc/kernel/smp.c 2009-11-26 00:26:48.000000000 +0300
> @@ -218,6 +218,9 @@ void crash_send_ipi(void (*crash_ipi_cal
>
> static void stop_this_cpu(void *dummy)
> {
> + /* Remove this CPU */
> + set_cpu_online(smp_processor_id(), false);
> +
> local_irq_disable();
> while (1)
> ;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* patch status
From: Tirumala Reddy Marri @ 2009-12-07 22:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
Hi Ben,
Did you get the chance to review the patch I sent it on Dec-1 2009
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.html
Regards,
MArri
[-- Attachment #2: Type: text/html, Size: 2030 bytes --]
^ permalink raw reply
* [PATCH] powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
From: Anton Vorontsov @ 2009-12-07 22:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, B.J. Buchalter
It appears that we wrongly calculate dev_base for type1 config cycles.
The thing is: we shouldn't subtract hose->first_busno because PCI core
sets PCI primary, secondary and subordinate bus numbers, and PCIe
controller actually takes the registers into account. So we should use
just bus->number.
Also, according to MPC8315 reference manual, primary bus number should
always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk
in indirect_pci.c, but since 83xx is somewhat special, it doesn't use
indirect_pci.c routines, so we have to implement the quirk specifically
for 83xx PCIe controllers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
This fixes the issue similar to http://www.pubbs.net/linuxppc/200908/22024/
i.e. lspci reports:
0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
0002:04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
0002:04:01.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
0002:04:02.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
...
While it should be:
0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
0002:04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
arch/powerpc/sysdev/fsl_pci.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ae88b14..0c11aa6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -450,8 +450,7 @@ static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus,
{
struct pci_controller *hose = pci_bus_to_host(bus);
struct mpc83xx_pcie_priv *pcie = hose->dn->data;
- u8 bus_no = bus->number - hose->first_busno;
- u32 dev_base = bus_no << 24 | devfn << 16;
+ u32 dev_base = bus->number << 24 | devfn << 16;
int ret;
ret = mpc83xx_pcie_exclude_device(bus, devfn);
@@ -501,12 +500,17 @@ static int mpc83xx_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
static int mpc83xx_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 val)
{
+ struct pci_controller *hose = pci_bus_to_host(bus);
void __iomem *cfg_addr;
cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
if (!cfg_addr)
return PCIBIOS_DEVICE_NOT_FOUND;
+ /* PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS */
+ if (offset == PCI_PRIMARY_BUS && bus->number == hose->first_busno)
+ val &= 0xffffff00;
+
switch (len) {
case 1:
out_8(cfg_addr, val);
--
1.6.3.3
^ permalink raw reply related
* Re: patch status
From: Josh Boyer @ 2009-12-08 0:52 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C0872CE8B@SDCEXCHANGE01.ad.amcc.com>
On Mon, Dec 07, 2009 at 02:01:58PM -0800, Tirumala Reddy Marri wrote:
>Hi Ben,
>
> Did you get the chance to review the patch I sent it on Dec-1 2009
>
>
>
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.html
Ben has to review lots of patches. Please be patient. Also, your patch is
tracked via patchwork here:
http://patchwork.ozlabs.org/patch/39865/
so you can see the state as it progresses.
Further, it would have been helpful to CC the maintainer of the 4xx sub-arch
(me) since it impacts that platform and you could have gotten some review more
quickly. I didn't notice it until this afternoon.
Lastly, your patch has lots of magical values in it. While I have no doubt
they are correct, I can't find any documentation for 460SX on the AMCC website
aside from some small product briefs. Perhaps I've overlooked the CPU manual,
but since I don't have such a board or the manual for it, it would be nice to
know what kind of testing has been done with this patch. A simple statement
such as "tested on kernel <version> with a <network, raid, whatever> pci-e
card successfully" would go a long way.
This is not a rant or complaint about the code. Just a reminder that the
community doesn't always move at the pace we would all like :). I'll try and
look over the patch more carefully tomorrow.
josh
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Sean MacLennan @ 2009-12-08 0:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259925535.2076.1275.camel@pasglop>
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
I have not been able to reproduce the problem :( I haven't had a lot of
time to run tests... but every once in a while I have been firing off
test runs.
Maybe writing this email will get it to crash ;)
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Michael Ellerman @ 2009-12-08 1:27 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20091207034714.GC3421@kryten>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Mon, 2009-12-07 at 14:47 +1100, Anton Blanchard wrote:
> The pseries and ppc64 defconfigs have drifted apart over the years. Reduce
> some of the differences while still keeping the idea that the ppc64 defconfig
> is cross platform but enables fewer features than pseries, eg:
>
> - NR_CPUS is lower
> - No NUMA support
Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
thought.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Benjamin Herrenschmidt @ 2009-12-08 1:32 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1260235641.4668.1.camel@concordia>
On Tue, 2009-12-08 at 12:27 +1100, Michael Ellerman wrote:
> > The pseries and ppc64 defconfigs have drifted apart over the years.
> Reduce
> > some of the differences while still keeping the idea that the ppc64
> defconfig
> > is cross platform but enables fewer features than pseries, eg:
> >
> > - NR_CPUS is lower
> > - No NUMA support
>
> Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
> thought.
Also no NUMA is going to hurt Cell too. I think we should leave that in.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Michael Ellerman @ 2009-12-08 1:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1260235944.10809.23.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Tue, 2009-12-08 at 12:32 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-08 at 12:27 +1100, Michael Ellerman wrote:
> > > The pseries and ppc64 defconfigs have drifted apart over the years.
> > Reduce
> > > some of the differences while still keeping the idea that the ppc64
> > defconfig
> > > is cross platform but enables fewer features than pseries, eg:
> > >
> > > - NR_CPUS is lower
> > > - No NUMA support
> >
> > Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
> > thought.
>
> Also no NUMA is going to hurt Cell too. I think we should leave that in.
It wasn't in, but maybe we should put it in.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Anton Blanchard @ 2009-12-08 1:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260235944.10809.23.camel@pasglop>
Hi,
> Also no NUMA is going to hurt Cell too. I think we should leave that in.
It was never enabled in the ppc64 defconfig :) I'm happy to turn it on though.
Anton
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Benjamin Herrenschmidt @ 2009-12-08 1:39 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20091208013528.GA2716@kryten>
On Tue, 2009-12-08 at 12:35 +1100, Anton Blanchard wrote:
> It was never enabled in the ppc64 defconfig :) I'm happy to turn it on
> though.
Yeah please.
Cheers,
Ben.
^ permalink raw reply
* RE: patch status
From: Tirumala Reddy Marri @ 2009-12-08 1:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20091208005257.GL2937@zod.rchland.ibm.com>
Josh,
Sorry for my ignorance that I did not copy you first. From now on I
will make sure you are cc'ed . I will send you the copy of user manual
which is available on external website.=20
Should I send new patch with what is tested with this change or is it
enough to write in email ?
Regards,
Marri
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]=20
Sent: Monday, December 07, 2009 4:53 PM
To: Tirumala Reddy Marri
Cc: benh@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: patch status
On Mon, Dec 07, 2009 at 02:01:58PM -0800, Tirumala Reddy Marri wrote:
>Hi Ben,
>
> Did you get the chance to review the patch I sent it on Dec-1 2009
>
>=20
>
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.htm
l
Ben has to review lots of patches. Please be patient. Also, your patch
is
tracked via patchwork here:
http://patchwork.ozlabs.org/patch/39865/
so you can see the state as it progresses.
Further, it would have been helpful to CC the maintainer of the 4xx
sub-arch
(me) since it impacts that platform and you could have gotten some
review more
quickly. I didn't notice it until this afternoon.
Lastly, your patch has lots of magical values in it. While I have no
doubt
they are correct, I can't find any documentation for 460SX on the AMCC
website
aside from some small product briefs. Perhaps I've overlooked the CPU
manual,
but since I don't have such a board or the manual for it, it would be
nice to
know what kind of testing has been done with this patch. A simple
statement
such as "tested on kernel <version> with a <network, raid, whatever>
pci-e
card successfully" would go a long way.
This is not a rant or complaint about the code. Just a reminder that
the
community doesn't always move at the pace we would all like :). I'll
try and
look over the patch more carefully tomorrow.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
From: Anton Vorontsov @ 2009-12-08 2:16 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1260202998.23828.13344.camel@localhost.localdomain>
On Mon, Dec 07, 2009 at 10:23:18AM -0600, Peter Tyser wrote:
[...]
> > Yes, badly designed hardware deserves ugly hacks in the platform
> > code. ;-) So for this problem, just request these gpios in the
> > platform code.
>
> I'd wager lots of boards have GPIO pins that a user shouldn't play
> around with once Linux boots up. Like GPIO pins used to program an
> FPGA,
What if I do want to program/upgrade an FPGA, say from the userspace?
[...]
> In any case, my high-level thought process is:
> 1. Currently, the "ngpio" value is wrong for some processors and should
> be fixed.
> 2. Adding a new "fsl,gpio-mask" gpio solves #1, and has the benefit of
> allowing the device tree to easily reserve GPIO pins which should not be
> used in Linux.
OK, if you're so eager to fix this... I'd suggest to not put this
stuff into device tree. We have compatible property that describes
the device.
So, in the driver, you can just do
if (of_device_is_compatible("fsl,foo-gpiochip"))
mask = ...;
else if (of_device_is_compatible("fsl,bar-gpiochip"))
mask = ...;
If you want to solve "dangerous" GPIOs problem, then I'd say
chosen {
linux,dangerous-gpios = <&pio1 0 0 &pio1 1 0
&pio2 4 0 &pio1 5 0>;
};
And then you can have a generic driver that looks for
linux,dangerous-gpios and requests them at boot.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: 林志平 @ 2009-12-08 2:25 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20091207180511.GA8914@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
2009/12/8 Scott Wood <scottwood@freescale.com>
> On Mon, Dec 07, 2009 at 11:53:22AM +0800, 林志平 wrote:
> > Does dtc1.2.0 can compile dts files under linux2.6.23?
>
> Probably not -- 2.6.23 is very old, and I think newer dtcs only support the
> newer dts syntax.
>
> > Another question is that I found linux2.6.31 does not support
> > board mpc8544ds,
>
> It should. What problems do you see?
=> bootm 0x1000000 0x1800000 0x800000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-2.6.31
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2185099 Bytes = 2.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01800000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1859256 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00800000
Booting using the fdt blob at 0x800000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
booting kernel using flat tree
It then stops and never print any more, I use mpc85xx_defconfig, I select
mpc85xxds in the menuconfig and deselect other options like mpc8540ads etc.
>
> > And I never boot linux-2.6.31 on my board, why linux-2.6.31 doesnot
> > provide a config file like mpc8544_ds_defconfig?
>
> Does mpc85xx_defconfig not work?
>
Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the menuconfig,
but no mpc8544ds. And when I down load the generated uImage, It does not
work.
> -Scott
>
[-- Attachment #2: Type: text/html, Size: 2692 bytes --]
^ permalink raw reply
* Re: using different format for hugetlbfs
From: David Gibson @ 2009-12-08 2:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc list
In-Reply-To: <1260147877.2076.1346.camel@pasglop>
On Mon, Dec 07, 2009 at 12:04:37PM +1100, Benjamin Herrenschmidt wrote:
>
> >
> > Even than, does that preclude the format I suggested? I'm assuming
> > that pgd_t/pud_t/pmd_t are always a double word so the low order 4-
> > bits should be 0 (on 64-bit),
Double word alignment only gives us 3 low bits.
> so using the lsb as the flag between
> > hugetlb and normal pointer should still work.
>
> Might do, depends if David has enough bits ... David ?
Well, the flag can go at the bottom, but that will mean grabbing more
bits at the bottom. At the moment to cover all the page table sizes
that are wanted on the various setups we have, I need 5 bits, this
would push it to 6. At present, I just force up the minimum alignment
of any page directory (even if it's natural alignment is smaller) so
as to make sure I have those bits. That's pretty easy to adjust, but
pushing it up too high will start wasting memory, of course.
If we move to a variable sized encoding, as Ben and I have discussed
on a couple of occasions, I think we could do this though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: patch status
From: Josh Boyer @ 2009-12-08 2:59 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C0872CF47@SDCEXCHANGE01.ad.amcc.com>
On Mon, Dec 07, 2009 at 05:41:35PM -0800, Tirumala Reddy Marri wrote:
>Josh,
> Sorry for my ignorance that I did not copy you first. From now on I
No reason to apologize. Working with the Linux community is a learning
process.
>will make sure you are cc'ed . I will send you the copy of user manual
>which is available on external website.
A URL to it would be fine. I still haven't managed to find it, but perhaps
the 'ALL available documents/types listed' link on this page:
http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_detail.jsp?productID=PPC460SX
doesn't really mean all?
>
> Should I send new patch with what is tested with this change or is it
>enough to write in email ?
Just reply to the patch is fine. No need to send a new one if there are no
code changes.
josh
^ permalink raw reply
* Re: + iseries-convert-to-proc_fops.patch added to -mm tree
From: Benjamin Herrenschmidt @ 2009-12-08 4:42 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, adobriyan
In-Reply-To: <200912012205.nB1M5Z3n025210@imap1.linux-foundation.org>
On Tue, 2009-12-01 at 14:05 -0800, akpm@linux-foundation.org wrote:
> The patch titled
> iseries: convert to proc_fops
> has been added to the -mm tree. Its filename is
> iseries-convert-to-proc_fops.patch
I was looking at that patch since It was in my queue, and while I
have no firm objection, I started wondering what was the point :-)
IE. What does seq_file buys us here since the conversion adds more
code than it removes and adds a hope via kmalloc that isn't necessary
before the said conversion ?
Those files are only ever one line long (and one of them is only one
character) so the seq_file doesn't really gets us any benefit does it ?
Cheers,
Ben.
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> out what to do about this
>
> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
>
> ------------------------------------------------------
> Subject: iseries: convert to proc_fops
> From: Alexey Dobriyan <adobriyan@gmail.com>
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> arch/powerpc/platforms/iseries/mf.c | 147 ++++++++++++++------------
> 1 file changed, 83 insertions(+), 64 deletions(-)
>
> diff -puN arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops arch/powerpc/platforms/iseries/mf.c
> --- a/arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops
> +++ a/arch/powerpc/platforms/iseries/mf.c
> @@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_ti
> }
>
> #ifdef CONFIG_PROC_FS
> -
> -static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_cmdline_proc_show(struct seq_file *m, void *v)
> {
> - int len;
> - char *p;
> + char *page, *p;
> struct vsp_cmd_data vsp_cmd;
> int rc;
> dma_addr_t dma_addr;
>
> /* The HV appears to return no more than 256 bytes of command line */
> - if (off >= 256)
> - return 0;
> - if ((off + count) > 256)
> - count = 256 - off;
> + page = kmalloc(256, GFP_KERNEL);
> + if (!page)
> + return -ENOMEM;
>
> - dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
> - if (dma_addr == DMA_ERROR_CODE)
> + dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
> + if (dma_addr == DMA_ERROR_CODE) {
> + kfree(page);
> return -ENOMEM;
> - memset(page, 0, off + count);
> + }
> + memset(page, 0, 256);
> memset(&vsp_cmd, 0, sizeof(vsp_cmd));
> vsp_cmd.cmd = 33;
> vsp_cmd.sub_data.kern.token = dma_addr;
> vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
> - vsp_cmd.sub_data.kern.side = (u64)data;
> - vsp_cmd.sub_data.kern.length = off + count;
> + vsp_cmd.sub_data.kern.side = (u64)m->private;
> + vsp_cmd.sub_data.kern.length = 256;
> mb();
> rc = signal_vsp_instruction(&vsp_cmd);
> - iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
> - if (rc)
> + iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
> + if (rc) {
> + kfree(page);
> return rc;
> - if (vsp_cmd.result_code != 0)
> + }
> + if (vsp_cmd.result_code != 0) {
> + kfree(page);
> return -ENOMEM;
> + }
> p = page;
> - len = 0;
> - while (len < (off + count)) {
> - if ((*p == '\0') || (*p == '\n')) {
> - if (*p == '\0')
> - *p = '\n';
> - p++;
> - len++;
> - *eof = 1;
> + while (p - page < 256) {
> + if (*p == '\0' || *p == '\n') {
> + *p = '\n';
> break;
> }
> p++;
> - len++;
> - }
>
> - if (len < off) {
> - *eof = 1;
> - len = 0;
> }
> - return len;
> + seq_write(m, page, p - page);
> + kfree(page);
> + return 0;
> +}
> +
> +static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
> }
>
> #if 0
> @@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *pa
> }
> #endif
>
> -static int proc_mf_dump_side(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_side_proc_show(struct seq_file *m, void *v)
> {
> - int len;
> char mf_current_side = ' ';
> struct vsp_cmd_data vsp_cmd;
>
> @@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page,
> }
> }
>
> - len = sprintf(page, "%c\n", mf_current_side);
> + seq_printf(m, "%c\n", mf_current_side);
> + return 0;
> +}
>
> - if (len <= (off + count))
> - *eof = 1;
> - *start = page + off;
> - len -= off;
> - if (len > count)
> - len = count;
> - if (len < 0)
> - len = 0;
> - return len;
> +static int mf_side_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_side_proc_show, NULL);
> }
>
> -static int proc_mf_change_side(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> char side;
> u64 newSide;
> @@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct fi
> return count;
> }
>
> +static const struct file_operations mf_side_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_side_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_side_proc_write,
> +};
> +
> #if 0
> static void mf_getSrcHistory(char *buffer, int size)
> {
> @@ -1087,8 +1089,7 @@ static void mf_getSrcHistory(char *buffe
> }
> #endif
>
> -static int proc_mf_dump_src(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_src_proc_show(struct seq_file *m, void *v)
> {
> #if 0
> int len;
> @@ -1109,8 +1110,13 @@ static int proc_mf_dump_src(char *page,
> #endif
> }
>
> -static int proc_mf_change_src(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static int mf_src_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_src_proc_show, NULL);
> +}
> +
> +static ssize_t mf_src_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> char stkbuf[10];
>
> @@ -1135,9 +1141,19 @@ static int proc_mf_change_src(struct fil
> return count;
> }
>
> -static int proc_mf_change_cmdline(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static const struct file_operations mf_src_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_src_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_src_proc_write,
> +};
> +
> +static ssize_t mf_cmdline_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> + void *data = PDE(file->f_path.dentry->d_inode)->data;
> struct vsp_cmd_data vsp_cmd;
> dma_addr_t dma_addr;
> char *page;
> @@ -1172,6 +1188,15 @@ out:
> return ret;
> }
>
> +static const struct file_operations mf_cmdline_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_cmdline_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_cmdline_proc_write,
> +};
> +
> static ssize_t proc_mf_change_vmlinux(struct file *file,
> const char __user *buf,
> size_t count, loff_t *ppos)
> @@ -1246,12 +1271,10 @@ static int __init mf_proc_init(void)
> if (!mf)
> return 1;
>
> - ent = create_proc_entry("cmdline", S_IFREG|S_IRUSR|S_IWUSR, mf);
> + ent = proc_create_data("cmdline", S_IRUSR|S_IWUSR, mf,
> + &mf_cmdline_proc_fops, (void *)(long)i);
> if (!ent)
> return 1;
> - ent->data = (void *)(long)i;
> - ent->read_proc = proc_mf_dump_cmdline;
> - ent->write_proc = proc_mf_change_cmdline;
>
> if (i == 3) /* no vmlinux entry for 'D' */
> continue;
> @@ -1263,19 +1286,15 @@ static int __init mf_proc_init(void)
> return 1;
> }
>
> - ent = create_proc_entry("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
> + ent = proc_create("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
> + &mf_side_proc_fops);
> if (!ent)
> return 1;
> - ent->data = (void *)0;
> - ent->read_proc = proc_mf_dump_side;
> - ent->write_proc = proc_mf_change_side;
>
> - ent = create_proc_entry("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
> + ent = proc_create("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
> + &mf_src_proc_fops);
> if (!ent)
> return 1;
> - ent->data = (void *)0;
> - ent->read_proc = proc_mf_dump_src;
> - ent->write_proc = proc_mf_change_src;
>
> return 0;
> }
> _
>
> Patches currently in -mm which might be from adobriyan@gmail.com are
>
> linux-next.patch
> thinkpad_acpi-convert-to-seq_file.patch
> asus_acpi-convert-to-seq_file.patch
> toshiba_acpi-convert-to-seq_file.patch
> arm-convert-proc-cpu-aligment-to-seq_file.patch
> proc_fops-convert-av7110.patch
> proc_fops-convert-cpia.patch
> proc_fops-convert-drivers-isdn-to-seq_file.patch
> proc_fops-convert-drivers-isdn-to-seq_file-fix.patch
> mpt-fusion-convert-to-seq_file.patch
> const-constify-remaining-dev_pm_ops.patch
> uml-irq-register-race-condition.patch
> make-debug_bugverbose-default-to-y.patch
> proc-rename-de_get-to-pde_get-and-inline-it.patch
> pnpbios-convert-to-seq_file.patch
> const-constify-remaining-pipe_buf_operations.patch
> ufs-pass-qstr-instead-of-dentry-where-necessary-for-nfs.patch
> ufs-nfs-support.patch
> reiserfs-remove-proc-fs-reiserfs-version.patch
> reiserfs-dont-compile-procfso-at-all-if-no-support.patch
> uml-convert-to-seq_file-proc_fops.patch
> alpha-convert-srm-code-to-seq_file.patch
> iseries-convert-to-proc_fops.patch
> clps711xfb-convert-to-proc_fops.patch
> parisc-convert-proc-pdc-lcdled-to-seq_file.patch
> via-pmu-convert-to-proc_fops-seq_file.patch
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Benjamin Herrenschmidt @ 2009-12-08 4:56 UTC (permalink / raw)
To: Joe Perches
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Jean Delvare,
Darrick J. Wong
In-Reply-To: <1259947019.22783.116.camel@Joe-Laptop.home>
On Fri, 2009-12-04 at 09:16 -0800, Joe Perches wrote:
> On Fri, 2009-12-04 at 20:59 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-12-04 at 10:34 +0100, Jean Delvare wrote:
> > > I've sent it to linuxppc-dev@ozlabs.org on October 14th. This is the
> > > address which is listed 22 times in MAINTAINERS. If it isn't correct,
> > > then please update MAINTAINERS.
> > No it's fine both shoul work. Your patches are there, just waiting for
> > me to pick them up, I was just firing a reminder to the rest of the CC
> > list :-) (and I do remember fwd'ing a couple of your patches to the
> > list, for some reason they didn't make it to patchwork back then, that
> > was a few month ago).
> > Anyways, I've been stretched thin with all sort of stuff lately, so bear
> > with me if I'm a bit slow at taking or testing stuff, I'm doing my best.
>
> Adding patterns to the PowerPC sections of MAINTAINERS is useful.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Are you going to submit that yourself or do you want me to carry it in
the powerpc tree ?
Cheers,
Ben.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4f96ac8..c7f8e5a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3193,6 +3193,7 @@ LINUX FOR IBM pSERIES (RS/6000)
> M: Paul Mackerras <paulus@au.ibm.com>
> W: http://www.ibm.com/linux/ltc/projects/ppc
> S: Supported
> +F: arch/powerpc/boot/rs6000.h
>
> LINUX FOR POWERPC (32-BIT AND 64-BIT)
> M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> @@ -3201,18 +3202,24 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> S: Supported
> +F: Documentation/powerpc/
> +F: arch/powerpc/
>
> LINUX FOR POWER MACINTOSH
> M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> +F: arch/powerpc/platforms/powermac/
> +F: drivers/macintosh/
>
> LINUX FOR POWERPC EMBEDDED MPC5XXX
> M: Grant Likely <grant.likely@secretlab.ca>
> L: linuxppc-dev@ozlabs.org
> T: git git://git.secretlab.ca/git/linux-2.6.git
> S: Maintained
> +F: arch/powerpc/platforms/512x/
> +F: arch/powerpc/platforms/52xx/
>
> LINUX FOR POWERPC EMBEDDED PPC4XX
> M: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> @@ -3221,6 +3228,8 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
> S: Maintained
> +F: arch/powerpc/platforms/40x/
> +F: arch/powerpc/platforms/44x/
>
> LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
> M: Grant Likely <grant.likely@secretlab.ca>
> @@ -3228,6 +3237,8 @@ W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
> L: linuxppc-dev@ozlabs.org
> T: git git://git.secretlab.ca/git/linux-2.6.git
> S: Maintained
> +F: arch/powerpc/*/*virtex*
> +F: arch/powerpc/*/*/*virtex*
>
> LINUX FOR POWERPC EMBEDDED PPC8XX
> M: Vitaly Bordug <vitb@kernel.crashing.org>
> @@ -3241,12 +3252,16 @@ M: Kumar Gala <galak@kernel.crashing.org>
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> +F: arch/powerpc/platforms/83xx/
>
> LINUX FOR POWERPC PA SEMI PWRFICIENT
> M: Olof Johansson <olof@lixom.net>
> W: http://www.pasemi.com/
> L: linuxppc-dev@ozlabs.org
> S: Supported
> +F: arch/powerpc/platforms/pasemi/
> +F: drivers/*/*pasemi*
> +F: drivers/*/*/*pasemi*
>
> LINUX SECURITY MODULE (LSM) FRAMEWORK
> M: Chris Wright <chrisw@sous-sol.org>
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Joe Perches @ 2009-12-08 5:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Jean Delvare,
Darrick J. Wong
In-Reply-To: <1260248197.10809.32.camel@pasglop>
On Tue, 2009-12-08 at 15:56 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-04 at 09:16 -0800, Joe Perches wrote:
> > Adding patterns to the PowerPC sections of MAINTAINERS is useful.
> > Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Are you going to submit that yourself or do you want me to carry it in
> the powerpc tree ?
It'd be better if you carry it.
cheers, Joe
^ permalink raw reply
* Build failure with fsl_msi.c
From: Benjamin Herrenschmidt @ 2009-12-08 6:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
The ppc64e_defconfig gives me that:
No big deal since nothing currently uses Book3E HW with fsl_msi but
probably something you should fix.
cc1: warnings being treated as errors
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c: In function ‘fsl_msi_cascade’:
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c:189: error: cast from pointer to integer of different size
LDS arch/powerpc/kernel/vdso32/vdso32.lds
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c: In function ‘fsl_of_msi_probe’:
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c:307: error: cast to pointer from integer of different size
make[2]: *** [arch/powerpc/sysdev/fsl_msi.o] Error 1
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v6 0/2] pseries: Add cede support for cpu-offline
From: Benjamin Herrenschmidt @ 2009-12-08 6:14 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: Peter Zijlstra, Gautham R Shenoy, linux-kernel, Arun R Bharadwaj,
Andrew Morton, linuxppc-dev, Ingo Molnar
In-Reply-To: <20091126195121.29159.66098.stgit@drishya>
Some of these patches (Gautham or Nathan, I haven't bisected) break
pseries build without CONFIG_SMP. I'll apply them anyways for now
to next and push them out today since nobody ever builds pseries without
CONFIG_SMP but I would appreciate if you could send a fix regardless.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] powerpc/pseries: Track previous CPPR values to correctly EOI interrupts
From: Mark Nelson @ 2009-12-08 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200912031607.50465.markn@au1.ibm.com>
At the moment when we EOI an interrupt we set the CPPR back to 0xFF
regardless of its previous value. This could lead to problems if we
take an interrupt with a priority of 5, but before EOIing it we get
an IPI which has a priority of 4. The problem is that at the moment
when we EOI the IPI we will set the CPPR to 0xFF, but it should
really be set back to 5 (the previous priority).
To keep track of the previous CPPR values we create the xics_cppr
structure that has an array for CPPR values and an index pointing
to the current priority. This can easily grow if new priorities get
added in the future.
This will also be useful because the partition adjunct option of
upcoming machines will update the H_XIRR hcall to accept the CPPR
as a parameter.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
changes since v1:
* simplified function names to push_cppr() and pop_cppr()
* added checking for empty and full stack of cppr
* make sure to set cpu priority only when we're not already taking an interrupt
arch/powerpc/platforms/pseries/xics.c | 56 ++++++++++++++++++++++++++++++----
1 file changed, 51 insertions(+), 5 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/xics.c
+++ upstream/arch/powerpc/platforms/pseries/xics.c
@@ -20,6 +20,7 @@
#include <linux/cpu.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/percpu.h>
#include <asm/firmware.h>
#include <asm/io.h>
@@ -46,6 +47,12 @@ static struct irq_host *xics_host;
*/
#define IPI_PRIORITY 4
+/* The least favored priority */
+#define LOWEST_PRIORITY 0xFF
+
+/* The number of priorities defined above */
+#define MAX_NUM_PRIORITIES 3
+
static unsigned int default_server = 0xFF;
static unsigned int default_distrib_server = 0;
static unsigned int interrupt_server_size = 8;
@@ -56,6 +63,12 @@ static int ibm_set_xive;
static int ibm_int_on;
static int ibm_int_off;
+struct xics_cppr {
+ unsigned char stack[MAX_NUM_PRIORITIES];
+ int index;
+};
+
+static DEFINE_PER_CPU(struct xics_cppr, xics_cppr);
/* Direct hardware low level accessors */
@@ -284,6 +297,19 @@ static inline unsigned int xics_xirr_vec
return xirr & 0x00ffffff;
}
+static void push_cppr(unsigned int vec)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ if (WARN_ON(os_cppr->index >= MAX_NUM_PRIORITIES - 1))
+ return;
+
+ if (vec == XICS_IPI)
+ os_cppr->stack[++os_cppr->index] = IPI_PRIORITY;
+ else
+ os_cppr->stack[++os_cppr->index] = DEFAULT_PRIORITY;
+}
+
static unsigned int xics_get_irq_direct(void)
{
unsigned int xirr = direct_xirr_info_get();
@@ -294,8 +320,10 @@ static unsigned int xics_get_irq_direct(
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ push_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have rtas mask it. */
xics_mask_unknown_vec(vec);
@@ -315,8 +343,10 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ push_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have RTAS mask it. */
xics_mask_unknown_vec(vec);
@@ -326,12 +356,22 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
}
+static unsigned char pop_cppr(void)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ if (WARN_ON(os_cppr->index < 1))
+ return LOWEST_PRIORITY;
+
+ return os_cppr->stack[--os_cppr->index];
+}
+
static void xics_eoi_direct(unsigned int virq)
{
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- direct_xirr_info_set((0xff << 24) | irq);
+ direct_xirr_info_set((pop_cppr() << 24) | irq);
}
static void xics_eoi_lpar(unsigned int virq)
@@ -339,7 +379,7 @@ static void xics_eoi_lpar(unsigned int v
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- lpar_xirr_info_set((0xff << 24) | irq);
+ lpar_xirr_info_set((pop_cppr() << 24) | irq);
}
static int xics_set_affinity(unsigned int virq, const struct cpumask *cpumask)
@@ -746,6 +786,12 @@ void __init xics_init_IRQ(void)
static void xics_set_cpu_priority(unsigned char cppr)
{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ BUG_ON(os_cppr->index != 0);
+
+ os_cppr->stack[os_cppr->index] = cppr;
+
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_cppr_info(cppr);
else
@@ -772,7 +818,7 @@ static void xics_set_cpu_giq(unsigned in
void xics_setup_cpu(void)
{
- xics_set_cpu_priority(0xff);
+ xics_set_cpu_priority(LOWEST_PRIORITY);
xics_set_cpu_giq(default_distrib_server, 1);
}
^ permalink raw reply
* Re: + iseries-convert-to-proc_fops.patch added to -mm tree
From: Andrew Morton @ 2009-12-08 6:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, adobriyan
In-Reply-To: <1260247339.10809.31.camel@pasglop>
On Tue, 08 Dec 2009 15:42:19 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Tue, 2009-12-01 at 14:05 -0800, akpm@linux-foundation.org wrote:
> > The patch titled
> > iseries: convert to proc_fops
> > has been added to the -mm tree. Its filename is
> > iseries-convert-to-proc_fops.patch
>
> I was looking at that patch since It was in my queue, and while I
> have no firm objection, I started wondering what was the point :-)
>
> IE. What does seq_file buys us here since the conversion adds more
> code than it removes and adds a hope via kmalloc that isn't necessary
> before the said conversion ?
>
> Those files are only ever one line long (and one of them is only one
> character) so the seq_file doesn't really gets us any benefit does it ?
Might be related to this:
: Convert code away from ->read_proc/->write_proc interfaces. Switch to
: proc_create()/proc_create_data() which make addition of proc entries
: reliable wrt NULL ->proc_fops, NULL ->data and so on.
:
: Problem with ->read_proc et al is described here commit
: 786d7e1612f0b0adb6046f19b906609e4fe8b1ba "Fix rmmod/read/write races in
: /proc entries"
but the real answer is: I have no idea.
Hopefully Andrey is now cured of his tendency to send unchangelogged
patches.
Andrey, please send along changelogs for
iseries-convert-to-proc_fops.patch
via-pmu-convert-to-proc_fops-seq_file.patch
proc_fops-convert-av7110.patch
proc_fops-convert-cpia.patch
proc_fops-convert-drivers-isdn-to-seq_file.patch
uml-convert-to-seq_file-proc_fops.patch
clps711xfb-convert-to-proc_fops.patch
^ 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