* Re: can't flush tlb on e500
From: Benjamin Herrenschmidt @ 2009-05-22 9:42 UTC (permalink / raw)
To: Saito Hideo; +Cc: linuxppc-dev list, linux-kernel, Kumar Gala
In-Reply-To: <1242984470.26104.29.camel@pasglop>
On Fri, 2009-05-22 at 19:27 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-20 at 19:12 +0900, Saito Hideo wrote:
>
> > I think that the tlb should be cleared before mm->context.id is set
> > MMU_NO_CONTEXT.
>
> You are right, this definitely looks like a bug on platforms that have
> HW support for the tlbil instruction (and thus care about the PID for
> flushing) which afaik is only the case of recent freescale chips.
In fact, you are doubly right in that it also happens on other platforms
because local_flush_tlb_mm() will check if the PID is MMU_NO_CONTEXT
regardless of what tlbilx supports.. oops
Looks like I only ran my context torture test with CONFIG_SMP enabled.
Shame on me.
> Have you verified that this change fixes your problem ?
>
> Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along with
> proper changeset comment and signed-off-by: line ?
>
> Cheers,
> Ben.
>
> > --- arch/powerpc/mm/mmu_context_nohash.c.orig 2009-03-24
> > 08:12:14.000000000 +0900
> > +++ arch/powerpc/mm/mmu_context_nohash.c 2009-05-20 18:33:53.000000000 +0900
> > @@ -122,22 +122,22 @@ static unsigned int steal_context_up(uns
> > struct mm_struct *mm;
> > int cpu = smp_processor_id();
> >
> > /* Pick up the victim mm */
> > mm = context_mm[id];
> >
> > pr_debug("[%d] steal context %d from mm @%p\n", cpu, id, mm);
> >
> > - /* Mark this mm has having no context anymore */
> > - mm->context.id = MMU_NO_CONTEXT;
> > -
> > /* Flush the TLB for that context */
> > local_flush_tlb_mm(mm);
> >
> > + /* Mark this mm has having no context anymore */
> > + mm->context.id = MMU_NO_CONTEXT;
> > +
> > /* XXX This clear should ultimately be part of local_flush_tlb_mm */
> > __clear_bit(id, stale_map[cpu]);
> >
> > return id;
> > }
> >
> > #ifdef DEBUG_MAP_CONSISTENCY
> > static void context_check_map(void)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: can't flush tlb on e500
From: Benjamin Herrenschmidt @ 2009-05-22 9:27 UTC (permalink / raw)
To: Saito Hideo; +Cc: linuxppc-dev list, linux-kernel, Kumar Gala
In-Reply-To: <d50492d40905200312r729608a3nf244b153892ac257@mail.gmail.com>
On Wed, 2009-05-20 at 19:12 +0900, Saito Hideo wrote:
> I think that the tlb should be cleared before mm->context.id is set
> MMU_NO_CONTEXT.
You are right, this definitely looks like a bug on platforms that have
HW support for the tlbil instruction (and thus care about the PID for
flushing) which afaik is only the case of recent freescale chips.
Have you verified that this change fixes your problem ?
Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along with
proper changeset comment and signed-off-by: line ?
Cheers,
Ben.
> --- arch/powerpc/mm/mmu_context_nohash.c.orig 2009-03-24
> 08:12:14.000000000 +0900
> +++ arch/powerpc/mm/mmu_context_nohash.c 2009-05-20 18:33:53.000000000 +0900
> @@ -122,22 +122,22 @@ static unsigned int steal_context_up(uns
> struct mm_struct *mm;
> int cpu = smp_processor_id();
>
> /* Pick up the victim mm */
> mm = context_mm[id];
>
> pr_debug("[%d] steal context %d from mm @%p\n", cpu, id, mm);
>
> - /* Mark this mm has having no context anymore */
> - mm->context.id = MMU_NO_CONTEXT;
> -
> /* Flush the TLB for that context */
> local_flush_tlb_mm(mm);
>
> + /* Mark this mm has having no context anymore */
> + mm->context.id = MMU_NO_CONTEXT;
> +
> /* XXX This clear should ultimately be part of local_flush_tlb_mm */
> __clear_bit(id, stale_map[cpu]);
>
> return id;
> }
>
> #ifdef DEBUG_MAP_CONSISTENCY
> static void context_check_map(void)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* to access web server on PowerPC from system outside the local network
From: patel rajendra @ 2009-05-22 8:10 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi,
I have made web server on PowerPC and it runs nicely. Currently it is on internal network.
I want to access it from any system outside the local network.
Can any one let me know what is the procedure for that?
Thanks for your time....
Raj
Cricket on your mind? Visit the ultimate cricket website. Enter http://beta.cricket.yahoo.com
[-- Attachment #2: Type: text/html, Size: 624 bytes --]
^ permalink raw reply
* Re: [PATCH] freescale: beyond ARRAY_SIZE of fdev->chan
From: Li Yang @ 2009-05-22 8:03 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, lkml
In-Reply-To: <4A133DEF.6080604@gmail.com>
On Wed, May 20, 2009 at 7:17 AM, Roel Kluin <roel.kluin@gmail.com> wrote:
> Do not go beyond ARRAY_SIZE of fdev->chan
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Indeed, thanks.
But I would like the title and description of this patch be changed to
like this:
fsldma: fix check on potential fdev->chan[] overflow
Fix the check of potential array overflow when using corrupted channel
device tree nodes.
> ---
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index da8a8ed..391b1bd 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -830,7 +830,7 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dm=
a_device *fdev,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0new_fsl_chan->reg.end - new_fsl_chan->reg.start + 1);
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0new_fsl_chan->id =3D ((new_fsl_chan->reg.start=
- 0x100) & 0xfff) >> 7;
> - =C2=A0 =C2=A0 =C2=A0 if (new_fsl_chan->id > FSL_DMA_MAX_CHANS_PER_DEVIC=
E) {
> + =C2=A0 =C2=A0 =C2=A0 if (new_fsl_chan->id >=3D FSL_DMA_MAX_CHANS_PER_DE=
VICE) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dev_err(fdev->dev,=
"There is no %d channel!\n",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new_fsl_chan->id);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D -EINVAL;
^ permalink raw reply
* Re: [net-next-2.6 PATCH] can: SJA1000: generic OF platform bus driver
From: David Miller @ 2009-05-22 6:31 UTC (permalink / raw)
To: grant.likely; +Cc: netdev, devicetree-discuss, Linuxppc-dev
In-Reply-To: <fa686aa40905212142n4a8c3caamb2f28eef036e3922@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Thu, 21 May 2009 22:42:07 -0600
> On Wed, May 20, 2009 at 11:06 AM, Wolfgang Grandegger <wg@grandegger.=
com> wrote:
>> This patch adds a generic driver for SJA1000 chips on the OpenFirmwa=
re
>> platform bus found on embedded PowerPC systems. You need a SJA1000 n=
ode
>> definition in your flattened device tree source (DTS) file similar t=
o:
>>
>> =A0 can@3,100 {
>> =A0 =A0 =A0 =A0 =A0 compatible =3D "philips,sja1000";
>> =A0 =A0 =A0 =A0 =A0 reg =3D <3 0x100 0x80>;
>> =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <8000000>;
>> =A0 =A0 =A0 =A0 =A0 cdr-reg =3D <0x48>;
>> =A0 =A0 =A0 =A0 =A0 ocr-reg =3D <0x0a>;
>> =A0 =A0 =A0 =A0 =A0 interrupts =3D <2 0>;
>> =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&mpic>;
>> =A0 };
> =
> This new binding must be documented in Documentation/powerpc/dts-bind=
ings
Wolfgang, please add this documentation and resubmit your patch.
Thanks!
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-05-22 6:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a small fix for .30 that works around a regression caused by
enabling MSI support in the IPR driver.
Cheers,
Ben.
The following changes since commit 5805977e63a36ad56594a623f3bd2bebcb7db233:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/drm-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Michael Ellerman (1):
powerpc/maple: Add a quirk to disable MSI for IPR on Bimini
arch/powerpc/platforms/maple/pci.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc/maple: Add a quirk to disable MSI for IPR on Bimini
From: Benjamin Herrenschmidt @ 2009-05-22 5:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: James.Bottomley, linuxppc-dev, brking, wayneb
In-Reply-To: <ddac4814a020b7d4248834f846d7a7afe1ce1567.1242968955.git.michael@ellerman.id.au>
On Fri, 2009-05-22 at 15:10 +1000, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/platforms/maple/pci.c | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
>
> It's getting late in the cycle, so until we can work out what's wrong
> with IPR + MSI on Bimini, add a quirk to disable MSI for IPR.
Thanks, I'll send that to Linus for 2.6.30
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
> index 3018552..04296ff 100644
> --- a/arch/powerpc/platforms/maple/pci.c
> +++ b/arch/powerpc/platforms/maple/pci.c
> @@ -592,3 +592,17 @@ int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int channel)
> }
> return irq;
> }
> +
> +static void __devinit quirk_ipr_msi(struct pci_dev *dev)
> +{
> + /* Something prevents MSIs from the IPR from working on Bimini,
> + * and the driver has no smarts to recover. So disable MSI
> + * on it for now. */
> +
> + if (machine_is(maple)) {
> + dev->no_msi = 1;
> + dev_info(&dev->dev, "Quirk disabled MSI\n");
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
> + quirk_ipr_msi);
^ permalink raw reply
* Re: problem in registering the device while inserting the kernel module
From: Grant Likely @ 2009-05-22 5:25 UTC (permalink / raw)
To: patel rajendra; +Cc: linuxppc-dev
In-Reply-To: <601801.28414.qm@web94805.mail.in2.yahoo.com>
On Thu, May 21, 2009 at 12:20 AM, patel rajendra <rdpatel55@yahoo.co.in> wrote:
> Hi Members of linuxppc,
>
> I'm working on XUPV2P board with Virtex II Pro FPGA device.
>
> I written a kernel module for LED device. I got that module run successfuly
> on ML403 board having Virtex 4 FPGA.I have not make any change in my source
> code for XUP board, because I don't feel any change is required.
What kernel version are you using?
Are you using arch/ppc or arch/powerpc?
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/maple: Add a quirk to disable MSI for IPR on Bimini
From: Michael Ellerman @ 2009-05-22 5:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: James.Bottomley, brking, wayneb
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/maple/pci.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
It's getting late in the cycle, so until we can work out what's wrong
with IPR + MSI on Bimini, add a quirk to disable MSI for IPR.
diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
index 3018552..04296ff 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -592,3 +592,17 @@ int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int channel)
}
return irq;
}
+
+static void __devinit quirk_ipr_msi(struct pci_dev *dev)
+{
+ /* Something prevents MSIs from the IPR from working on Bimini,
+ * and the driver has no smarts to recover. So disable MSI
+ * on it for now. */
+
+ if (machine_is(maple)) {
+ dev->no_msi = 1;
+ dev_info(&dev->dev, "Quirk disabled MSI\n");
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
+ quirk_ipr_msi);
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] mpc52xx_psc_spi: Convert to cs_control callback
From: Grant Likely @ 2009-05-22 5:07 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Andrew Morton, David Brownell, spi-devel-general
In-Reply-To: <20090430223114.GA12571@oksana.dev.rtsoft.ru>
On Thu, Apr 30, 2009 at 4:31 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> mpc52xx_psc_spi driver is the last user of the legacy activate_cs
> and deactivate_cs callbacks, so convert the driver to the cs_control
> hook and remove the legacy callbacks from fsl_spi_platform_data
> struct.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
David, will you pick this one up, or can I put it into Ben's powerpc
-next tree (since it is a powerpc-only device driver).
g.
> ---
> =A0drivers/spi/mpc52xx_psc_spi.c | =A0 22 +++++++++-------------
> =A0include/linux/fsl_devices.h =A0 | =A0 =A04 ----
> =A02 files changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.=
c
> index 68c77a9..e1901fd 100644
> --- a/drivers/spi/mpc52xx_psc_spi.c
> +++ b/drivers/spi/mpc52xx_psc_spi.c
> @@ -13,6 +13,7 @@
>
> =A0#include <linux/module.h>
> =A0#include <linux/init.h>
> +#include <linux/types.h>
> =A0#include <linux/errno.h>
> =A0#include <linux/interrupt.h>
> =A0#include <linux/of_platform.h>
> @@ -30,8 +31,7 @@
>
> =A0struct mpc52xx_psc_spi {
> =A0 =A0 =A0 =A0/* fsl_spi_platform data */
> - =A0 =A0 =A0 void (*activate_cs)(u8, u8);
> - =A0 =A0 =A0 void (*deactivate_cs)(u8, u8);
> + =A0 =A0 =A0 void (*cs_control)(struct spi_device *spi, bool on);
> =A0 =A0 =A0 =A0u32 sysclk;
>
> =A0 =A0 =A0 =A0/* driver internal data */
> @@ -111,18 +111,16 @@ static void mpc52xx_psc_spi_activate_cs(struct spi_=
device *spi)
> =A0 =A0 =A0 =A0out_be16((u16 __iomem *)&psc->ccr, ccr);
> =A0 =A0 =A0 =A0mps->bits_per_word =3D cs->bits_per_word;
>
> - =A0 =A0 =A0 if (mps->activate_cs)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->activate_cs(spi->chip_select,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (spi->mode =
& SPI_CS_HIGH) ? 1 : 0);
> + =A0 =A0 =A0 if (mps->cs_control)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->cs_control(spi, (spi->mode & SPI_CS_HI=
GH) ? 1 : 0);
> =A0}
>
> =A0static void mpc52xx_psc_spi_deactivate_cs(struct spi_device *spi)
> =A0{
> =A0 =A0 =A0 =A0struct mpc52xx_psc_spi *mps =3D spi_master_get_devdata(spi=
->master);
>
> - =A0 =A0 =A0 if (mps->deactivate_cs)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->deactivate_cs(spi->chip_select,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (spi->mode =
& SPI_CS_HIGH) ? 1 : 0);
> + =A0 =A0 =A0 if (mps->cs_control)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->cs_control(spi, (spi->mode & SPI_CS_HI=
GH) ? 0 : 1);
> =A0}
>
> =A0#define MPC52xx_PSC_BUFSIZE (MPC52xx_PSC_RFNUM_MASK + 1)
> @@ -388,15 +386,13 @@ static int __init mpc52xx_psc_spi_do_probe(struct d=
evice *dev, u32 regaddr,
> =A0 =A0 =A0 =A0mps->irq =3D irq;
> =A0 =A0 =A0 =A0if (pdata =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_warn(dev, "probe called without platfo=
rm data, no "
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "(de)activa=
te_cs function will be called\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->activate_cs =3D NULL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->deactivate_cs =3D NULL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "cs_control=
function will be called\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->cs_control =3D NULL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mps->sysclk =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master->bus_num =3D bus_num;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master->num_chipselect =3D 255;
> =A0 =A0 =A0 =A0} else {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->activate_cs =3D pdata->activate_cs;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->deactivate_cs =3D pdata->deactivate_cs=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mps->cs_control =3D pdata->cs_control;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mps->sysclk =3D pdata->sysclk;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master->bus_num =3D pdata->bus_num;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master->num_chipselect =3D pdata->max_chip=
select;
> diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
> index 244677c..43fc95d 100644
> --- a/include/linux/fsl_devices.h
> +++ b/include/linux/fsl_devices.h
> @@ -79,10 +79,6 @@ struct fsl_spi_platform_data {
> =A0 =A0 =A0 =A0u16 =A0 =A0 max_chipselect;
> =A0 =A0 =A0 =A0void =A0 =A0(*cs_control)(struct spi_device *spi, bool on)=
;
> =A0 =A0 =A0 =A0u32 =A0 =A0 sysclk;
> -
> - =A0 =A0 =A0 /* Legacy hooks, used by mpc52xx_psc_spi driver. */
> - =A0 =A0 =A0 void =A0 =A0(*activate_cs)(u8 cs, u8 polarity);
> - =A0 =A0 =A0 void =A0 =A0(*deactivate_cs)(u8 cs, u8 polarity);
> =A0};
>
> =A0struct mpc8xx_pcmcia_ops {
> --
> 1.6.2.2
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] can: SJA1000: generic OF platform bus driver
From: Grant Likely @ 2009-05-22 4:42 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linux Netdev List, devicetree-discuss, linuxppc-dev
In-Reply-To: <4A143896.7050200@grandegger.com>
On Wed, May 20, 2009 at 11:06 AM, Wolfgang Grandegger <wg@grandegger.com> w=
rote:
> This patch adds a generic driver for SJA1000 chips on the OpenFirmware
> platform bus found on embedded PowerPC systems. You need a SJA1000 node
> definition in your flattened device tree source (DTS) file similar to:
>
> =A0 can@3,100 {
> =A0 =A0 =A0 =A0 =A0 compatible =3D "philips,sja1000";
> =A0 =A0 =A0 =A0 =A0 reg =3D <3 0x100 0x80>;
> =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <8000000>;
> =A0 =A0 =A0 =A0 =A0 cdr-reg =3D <0x48>;
> =A0 =A0 =A0 =A0 =A0 ocr-reg =3D <0x0a>;
> =A0 =A0 =A0 =A0 =A0 interrupts =3D <2 0>;
> =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&mpic>;
> =A0 };
This new binding must be documented in Documentation/powerpc/dts-bindings
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Audio and mpc5200 bestcomm tasks
From: Grant Likely @ 2009-05-22 4:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910905211152x6ded5c9tadc085bc4bc800e3@mail.gmail.com>
On Thu, May 21, 2009 at 12:52 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> ALSA really wants to dynamically know the address of the current DMA
> location while transfers are active. This is an important piece of
> implementing pause/resume. Pause doesn't work too well if there is 2s
> of music already queued. The work around is to know the sample rate
> and use the jiffy count to estimate how far into the buffer DMA has
> progressed. But that's not as accurate as just asking the DMA
> hardware.
>
> I poked around in the SRAM data and couldn't find the address. Is it
> there or can the Bestcomm tasks be modified to leave it somewhere
> visible?
It may be possible, but I haven't made any attempts at writing
bestcomm task code. I've got no idea how difficult it would be.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 1/1] Remove __devinit annotation from pcibios_claim_one_bus()
From: Tony Breeds @ 2009-05-22 3:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
pcibios_finish_adding_to_bus() is NOT annotated __devinit but it calls
pcibios_claim_one_bus(). pcibios_finish_adding_to_bus() is called from
at least the rpadlpar code which also is NOT annotated __devinit.
The annotation seems bogus so remove it.
Found by Jeremy Huddleston a reported at:
http://bugzilla.kernel.org/show_bug.cgi?id=13228
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/pci-common.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0f41812..a9f988f 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1469,7 +1469,7 @@ void __init pcibios_resource_survey(void)
* rest of the code later, for now, keep it as-is as our main
* resource allocation function doesn't deal with sub-trees yet.
*/
-void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
+void pcibios_claim_one_bus(struct pci_bus *bus)
{
struct pci_dev *dev;
struct pci_bus *child_bus;
--
1.6.0.6
^ permalink raw reply related
* Re: question : DMA of PCI bridge
From: Sauce.Cheng @ 2009-05-22 3:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A14D12D.4050302@ovro.caltech.edu>
>
> in the manual reference charpter 9.13 DMA, source and destination address
> If you are DMAing from an internal peripheral, then it's
> width will be hard-coded and can be read from the user-manual.
you mean it will be set by hard circuit ? maybe i should talk with your hard
engineer.
but as you say, the width will be hard-coded, mean that the width can not be
changed ?
it can fetch 16 bits to 32bits, can not tetch 16bits to 16bits ?
i am sorry about my poor English, i am not sure if i expressed clearly
> If you are DMAing from a local bus then the local bus definition
> should determine what happens. For example, on the MPC8349, you
> can put 16-bit flash on the local bus, and configure the local
> bus controller to know that it is 16-bits wide. A 32-bit access
> by the CPU or DMA controller will generate two reads on the
> local bus.
that's right, BRx and ORx should be configured for setting width, but that
is bus width, not data width. or bus width should be equal to data width
what fetch from the bus ?
> You can investigate to see whether the MPC8247 works similarly.
all right, i will , thanks a lot
--
View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23663840.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-05-22 1:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, linux-next, Paul Mackerras,
Vinay Sridhar
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
Hi Ben,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
arch/powerpc/xmon/xmon.c: In function 'dump_log_buf':
arch/powerpc/xmon/xmon.c:2133: warning: unused variable 'i'
Introduced by commit f312deb4cd0c88196edf6dab192b7d42514398d6
("powerpc/xmon: Add dl command to dump contents of __log_buf").
[As an aside, that commit contains this:
Signed-off-by: Michael Ellerman <michael at ellerman.id.au>
but we use real email addresses normally]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-05-22 1:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, linux-next,
Paul Mackerras, Jan Blunck
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Hi Ben,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_create':
arch/powerpc/platforms/cell/spufs/inode.c:647: warning: label 'out_dput' defined but not used
Introduced by commit 45db9240890d9343c934db1fe82d6e68ac2d28da
("powerpc/spufs: Remove double check for non-negative dentry").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc:beyond ARRAY_SIZE of args.args
From: Paul Mackerras @ 2009-05-21 23:10 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, paulmck
In-Reply-To: <4A15AF33.60100@gmail.com>
Roel Kluin writes:
> Do not go beyond ARRAY_SIZE of args.args
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> I'm quite sure the first is correct, but should maybe `args.nret'
> and `nargs + args.nret' also be `>= ARRAY_SIZE(args.args)'?
I don't think this change is needed, and it changes a user-visible
API, so I'm nacking it unless you can convince me there's really a
problem.
If nargs == ARRAY_SIZE(args.args), then args.nret must be zero, so
nothing will access *(args.rets).
Paul.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-21 22:08 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4A15B72E.2070202@goop.org>
On Thu, 2009-05-21 at 16:18 -0400, Jeremy Fitzhardinge wrote:
> I guess the test is checking for a bad implementation of map_single().
More importantly the io_tlb_overflow_buffer is basically a second chance
if you exhaust the swiotlb pool. The check seems to be there to ensure
that the second chance memory is suitable for the device (it's hard to
imagine, but possible I suppose, that it wouldn't be), a bad
implementation of map_single() is a secondary concern I suspect.
If all the callers of map_page did proper error handling this would all
be unnecessary. I guess someone was worried, at least at one point, that
they didn't. The failure case could possibly be scribbling into a random
memory location or more worryingly sprinkling random memory locations
onto your disk or whatever. That said I'd imagine that map_page
returning NULL would cause an oops long before anything tried to DMA
anything and the second chance probably doesn't buy us much in practice.
Ian.
^ permalink raw reply
* Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Roderick Colenbrander @ 2009-05-21 20:31 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20090521165008.A020D710053@mail54-sin.bigfish.com>
Hi Stephen,
Grant forgot to attach the dts file (but a next patch will add it).
The dts file contains some lines for the pci bus mapping. The lines
are attached below. For pci support I'm using the reference bsb with
pci 'ML510 BSB1 Pcores Design' for PowerPC at:
http://www.xilinx.com/products/boards/ml510/ml510_10.1_3_1/bsb.htm.
The patch also contains a tutorial on how to add pci yourself.
As I mention in the comment of the plbv46_pci stuff C_IPIFBAR2PCIBAR_0
is not set correctly. Benjamin Herrenschmidt told me that inbound and
outbound pci transactions shouldn't overlap. With the value at ipif
plb 0xa0000000 maps to 0 on the pci side while the pci soft-core also
thinks that 0 maps to address 0 of the system memory. Setting
C_IPIFBAR2PCIBAR_0 to e.g. 0xa0000000 like I'm doing maps ipif plb
0xa0000000 to 0xa0000000 on the pci side and prevents this confusion.
The same is also wrong in the guides for the ml410.
Could you forward it to the right people so that this can get fixed?
No other changes are needed except for this one.
Roderick
+ plbv46_pci_0: plbv46-pci@85e00000 {
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "xlnx,plbv46-pci-1.03.a";
+ device_type = "pci";
+ reg = < 0x85e00000 0x10000 >;
+ /* The default ML510 BSB has
C_IPIFBAR2PCIBAR_0 set to 0 which means that a read/write to
+ * the memory mapped i/o region (which starts
at 0xa0000000) for pci bar 0 on the plb side
+ * translates to 0.
+ * It is important to this value to
0xa0000000, so that inbound and outbound pci transactions
+ * work properly including DMA.
+ */
+ ranges = <0x02000000 0x00000000 0xa0000000
0xa0000000 0x00000000 0x20000000
+ 0x01000000 0x00000000 0x00000000
0xf0000000 0x00000000 0x00010000>;
+
+ #interrupt-cells = <1>;
+ interrupt-parent = <&xps_intc_0>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IRQ mapping for pci slots and ALI
M1533 periperhals. In total there are
+ * 5 interrupt lines connected to a
xps_intc controller. Four of them are PCI
+ * IRQ A, B, C, D and which correspond
to respectively xpx_intc 5, 4, 3 and 2.
+ * The fifth interrupt line is
connected to the south bridge and this one
+ * uses irq 1 and is active high
instead of active low.
+ *
+ * The M1533 contains various
peripherals including AC97 audio, a modem, USB,
+ * IDE and some power management
stuff. The modem isn't connected on the ML510
+ * and the power management core also
isn't used.
+ */
+
+ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+ 0x3000 0 0 1 &xps_intc_0 3 2
+ 0x3000 0 0 2 &xps_intc_0 2 2
+ 0x3000 0 0 3 &xps_intc_0 5 2
+ 0x3000 0 0 4 &xps_intc_0 4 2
+
+ /* IDSEL 0x13 / dev=3, bus=1 / PCI slot 4 */
+ /*
+ 0x11800 0 0 1 &xps_intc_0 5 0 2
+ 0x11800 0 0 2 &xps_intc_0 4 0 2
+ 0x11800 0 0 3 &xps_intc_0 3 0 2
+ 0x11800 0 0 4 &xps_intc_0 2 0 2
+ */
+
+ /* According to the datasheet +
schematic ABCD [FPGA] of slot 5 is mapped to DABC.
+ * Testing showed that at least A maps
to B, the mapping of the other pins is a guess
+ * and for that reason the lines have
been commented.
+ */
+ /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+ 0x2800 0 0 1 &xps_intc_0 4 2
+ /*
+ 0x2800 0 0 2 &xps_intc_0 3 2
+ 0x2800 0 0 3 &xps_intc_0 2 2
+ 0x2800 0 0 4 &xps_intc_0 5 2
+ */
+
+ /* IDSEL 0x12 / dev=2, bus=1 / PCI slot 6 */
+ /*
+ 0x11000 0 0 1 &xps_intc_0 4 0 2
+ 0x11000 0 0 2 &xps_intc_0 3 0 2
+ 0x11000 0 0 3 &xps_intc_0 2 0 2
+ 0x11000 0 0 4 &xps_intc_0 5 0 2
+ */
+
+ /* IDSEL 0x11 / dev=1, bus=0 / AC97 audio */
+ 0x0800 0 0 1 &i8259 7 2
+
+ /* IDSEL 0x1b / dev=11, bus=0 / IDE */
+ 0x5800 0 0 1 &i8259 14 2
+
+ /* IDSEL 0x1f / dev 15, bus=0 / 2x USB 1.1 */
+ 0x7800 0 0 1 &i8259 7 2
+ >;
+ ali_m1533 {
+ #size-cells = <1>;
+ #address-cells = <2>;
+ i8259: interrupt-controller@20 {
+ reg = <1 0x20 2
+ 1 0xa0 2
+ 1 0x4d0 2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+
+ /* The south bridge connection
is active high */
+ interrupts = <1 3>;
+ interrupt-parent = <&xps_intc_0>;
+ };
+ };
+ } ;
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Jeremy Fitzhardinge @ 2009-05-21 20:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, Ian Campbell
In-Reply-To: <E6DAA792-9923-4B76-9759-6955AABE3EAB@kernel.crashing.org>
Becky Bruce wrote:
> I can work with that, but it's going to be a bit inefficient, as I
> actually need the dma_addr_t, not the phys_addr_t, so I'll have to
> convert. In every case, this is a conversion I've already done and
> that I need in the calling code as well. Can we pass in both the
> phys_addr_t and the dma_addr_t?
The Xen implementation would needs to do the phys to bus conversion page
by page anyway, so it wouldn't help much. But it also wouldn't hurt.
How expensive is the phys-to-bus conversion on power? Is it worth
making the interface more complex for? Would passing phys+bus mean that
we wouldn't also need to pass dev?
> We have both in every case but one, which is in swiotlb_map_page where
> we call address_needs_mapping() without calling range_needs_mapping.
> It's not actually clear to me that we need that check, though. Can
> someone explain what case that was designed to catch?
It called them together a little earlier in the function, and the phys
address is still available.
I guess the test is checking for a bad implementation of map_single().
I found a single instance of someone reporting the message (in 2.6.11,
when swiotlb was ia64-specific: http://lkml.org/lkml/2008/3/3/249).
panic() is an odd way to handle an error (even an one which is an
implementation bug), but I guess it's better than scribbling on the
wrong memory.
J
^ permalink raw reply
* Re: ipr boot failure caused by MSI (2.6.30-rc1+)
From: James Bottomley @ 2009-05-21 19:51 UTC (permalink / raw)
To: Brian King; +Cc: ppc-dev, Wayne Boyer, linux-scsi
In-Reply-To: <4A15A1B2.8060609@linux.vnet.ibm.com>
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
> cc'ing linuxppc-dev...
>
> -Brian
>
>
> James Bottomley wrote:
> > Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr
> > just times out and refuses to probe devices. If I let it drop into the
> > initramfs system, this is what the interrupts shows:
> >
> > (initramfs) cat /proc/interrupts
> > CPU0 CPU1 CPU2 CPU3
> > 16: 20 10 13 11 MPIC Level pata_amd
> > 20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2
> > 21: 0 0 0 0 MPIC-U3MSI Edge ipr
> > 68: 37 37 48 37 MPIC Edge serial
> > 251: 10 71 69 72 MPIC Edge ipi call function
> > 252: 1555 1779 1372 1155 MPIC Edge ipi reschedule
> > 253: 0 0 0 0 MPIC Edge ipi call function single
> > 254: 0 0 0 0 MPIC Edge ipi debugger
> > BAD: 416
> >
> > So you see the IPR is the only device not receiving them.
> >
> > I can fix the boot hang by reverting
> >
> > commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32
> > Author: Wayne Boyer <wayneb@linux.vnet.ibm.com>
> > Date: Fri Jan 23 09:17:35 2009 -0800
> >
> > [SCSI] ipr: add MSI support
> >
> > The system in question is:
> >
> > SYSTEM INFORMATION
> > Processor = PowerPC,970MP @ 2500 MHz
> > I/O Bridge = U4 (4.4)
> > SMP Size = 4 (#0 #1 #2 #3)
> > Boot-Date = 2009-04-21 17:13:36
> > Memory = 2 GB of RAM @ 666 MHz
> > Board Type = Bimini (7047191/0000000/1)
> > MFG Date = 1608
> > Part No. = 10N8748
> > FRU No. = 10N7182
> > FRU Serial = YL30W8106038
> > UUID = 00000000000000000000000000000000
> > Flashside = 1 (temporary)
> > Version = HEAD
> > Build Date = 12-04-2008 16:13
OK, so as an update, I booted to the initrd and inserted the network
modules, which are also MSI enabled and this is what I get:
(initramfs) cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 14 11 11 18 MPIC Level pata_amd
20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2
21: 0 0 0 0 MPIC-U3MSI Edge ipr
22: 1 0 1 0 MPIC-U3MSI Edge eth0
23: 0 2 1 0 MPIC-U3MSI Edge eth1
68: 193 166 113 177 MPIC Edge serial
251: 16 65 71 70 MPIC Edge ipi call function
252: 1574 1804 1346 1289 MPIC Edge ipi reschedule
253: 0 0 0 0 MPIC Edge ipi call function single
254: 0 0 0 0 MPIC Edge ipi debugger
BAD: 1866
So clearly the MSI interrupts to the network cards are working and it
looks like just a local problem with the ipr rather than a platform
problem with MSI.
James
^ permalink raw reply
* Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
From: Grant Likely @ 2009-05-21 19:58 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090521165008.A020D710053@mail54-sin.bigfish.com>
On Thu, May 21, 2009 at 10:50 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig
>> index 0d83a6a..af1c51d 100644
>> --- a/arch/powerpc/platforms/44x/Kconfig
>> +++ b/arch/powerpc/platforms/44x/Kconfig
>> @@ -156,7 +156,7 @@ config YOSEMITE
>> =A0# =A0 =A0 =A0This option enables support for the IBM PPC440GX evaluat=
ion
> board.
>>
>> =A0config XILINX_VIRTEX440_GENERIC_BOARD
>> - =A0 =A0 bool "Generic Xilinx Virtex 440 board"
>> + =A0 =A0 bool "Xilinx Virtex 5 support"
>
> 'Virtex 5' is a little ambiguous.. =A0I'd suggest keeping the old wording=
,
> or saying 'Virtex 5 FXT support'. =A0Even then it's somewhat ambiguous,
> since you could conceivably run linux on microblaze on V5FXT and use the
> powerpc for something else..
Considering that this option only appears when AMCC 44x is selected, I
think the ambiguity is minimal. :-)
I'll add the FXT though.
>> diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c
> b/arch/powerpc/platforms/44x/virtex_ml510.c
>> new file mode 100644
>> index 0000000..ba4a6e3
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/44x/virtex_ml510.c
>> @@ -0,0 +1,29 @@
>> +#include <asm/i8259.h>
>> +#include <linux/pci.h>
>> +#include "44x.h"
>> +
>> +/**
>> + * ml510_ail_quirk
>
> Tpyo, but is the comment even necessary if it doesn't say anything
> useful?
Oops; I started writing a comment and then never completed it.
Roderick; care to contribute some lines as to the purpose of this
block?
>> diff --git a/arch/powerpc/sysdev/xilinx_intc.c
> b/arch/powerpc/sysdev/xilinx_intc.c
>> index 90b5772..3ee1fd3 100644
>> --- a/arch/powerpc/sysdev/xilinx_intc.c
>> +++ b/arch/powerpc/sysdev/xilinx_intc.c
>> @@ -257,6 +257,11 @@ static void __init
> xilinx_i8259_setup_cascade(void)
>> =A0 =A0 =A0 i8259_init(cascade_node, 0);
>> =A0 =A0 =A0 set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
>>
>> + =A0 =A0 /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive *=
/
>> + =A0 =A0 /* This looks like a dirty hack to me --gcl */
>> + =A0 =A0 outb(0xc0, 0x4d0);
>> + =A0 =A0 outb(0xc0, 0x4d1);
>> +
>
> Yeow... I agree about the dirty hack part... =A0shouldn't this be in the
> device tree somewhere, or in the ali driver?
Chatting with Roderick on IRC today, it may be that these two lines
aren't even necessary. They come from an old guide for porting Linux
to the ml410 in the pre-arch/powerpc days. Now that IRQ sense is
encoded into the device tree, this probably isn't needed.
> I'm curious if this works on ml410 as well.. =A0(Yes, I know, does this
> really matter much? =A0But there are still a bunch of them floating aroun=
d
> in universities.)
It should do (at least I hope it does). If I get my hands on an
ML410, then I'll try it out.
> =A0It may be nice to factor this out so ml410/ppc405 and
> microblaze can get it as well.
indeed.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] KVM: powerpc: beyond ARRAY_SIZE of vcpu->arch.guest_tlb
From: Roel Kluin @ 2009-05-21 19:53 UTC (permalink / raw)
To: avi, paulmck; +Cc: linuxppc-dev, Andrew Morton, kvm
Do not go beyond ARRAY_SIZE of vcpu->arch.guest_tlb
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 0fce4fb..c2cfd46 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -125,7 +125,7 @@ static int kvmppc_emul_tlbwe(struct kvm_vcpu *vcpu, u32 inst)
ws = get_ws(inst);
index = vcpu->arch.gpr[ra];
- if (index > PPC44x_TLB_SIZE) {
+ if (index >= PPC44x_TLB_SIZE) {
printk("%s: index %d\n", __func__, index);
kvmppc_dump_vcpu(vcpu);
return EMULATE_FAIL;
^ permalink raw reply related
* [PATCH] powerpc:beyond ARRAY_SIZE of args.args
From: Roel Kluin @ 2009-05-21 19:44 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev, Andrew Morton
Do not go beyond ARRAY_SIZE of args.args
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
I'm quite sure the first is correct, but should maybe `args.nret'
and `nargs + args.nret' also be `>= ARRAY_SIZE(args.args)'?
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 1f8505c..c94ab76 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -779,7 +779,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
return -EFAULT;
nargs = args.nargs;
- if (nargs > ARRAY_SIZE(args.args)
+ if (nargs >= ARRAY_SIZE(args.args)
|| args.nret > ARRAY_SIZE(args.args)
|| nargs + args.nret > ARRAY_SIZE(args.args))
return -EINVAL;
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-21 19:01 UTC (permalink / raw)
To: Becky Bruce
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org, Jeremy Fitzhardinge,
linux-kernel@vger.kernel.org
In-Reply-To: <E6DAA792-9923-4B76-9759-6955AABE3EAB@kernel.crashing.org>
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
> We have both in every case but one,
> which is in swiotlb_map_page where we call address_needs_mapping()
> without calling range_needs_mapping.
The reason it calls address_needs_mapping without range_needs_mapping is
that in the swiotlb_force=1 case it would trigger every time. If
address_needs_mapping and range_needs_mapping are merged as proposed and
they do not subsume the swiotlb_force check (and I don't think they
would) then I think this will work fine.
> It's not actually clear to me that we need that check, though. Can
> someone explain what case that was designed to catch?
If map_single fails and returns NULL then we try to use
io_tlb_overflow_buffer, if that is somehow not DMA-able (for the
particular device) then the check will trigger. I would have thought we
could arrange that the overflow buffer is always OK and really if
map_page is failing we must be close the edge already.
Ian.
^ 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