* Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-20 13:19 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284706869-12555-2-git-send-email-tie-fei.zang@freescale.com>
On Fri, Sep 17, 2010 at 03:01:08PM +0800, Roy Zang wrote:
[...]
> +static struct mutex fsl_elbc_nand_mutex;
> +
> +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + struct fsl_lbc_regs __iomem *lbc;
> struct fsl_elbc_mtd *priv;
> struct resource res;
> + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
No need for = NULL.
[...]
> - ctrl->chips[bank] = priv;
> + mutex_init(&fsl_elbc_nand_mutex);
This may cause all sorts of misbehaviours, e.g.
A: mutex_init(foo)
A: mutex_lock(foo)
B: mutex_init(foo) <- destroyed "A"-context mutex.
A: mutex_unlock(foo) <- oops
Instead of dynamically initializing the mutex, just define it
with DEFINE_MUTEX() above.
(Btw, #include <linux/mutex.h> is needed.)
> +
> + mutex_lock(&fsl_elbc_nand_mutex);
[...]
> -static int __devinit fsl_elbc_ctrl_init(struct fsl_elbc_ctrl *ctrl)
> +static int fsl_elbc_nand_remove(struct platform_device *dev)
[...]
> + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
[...]
> + if (elbc_fcm_ctrl->chips[i])
> + fsl_elbc_chip_remove(elbc_fcm_ctrl->chips[i]);
[...]
> + fsl_lbc_ctrl_dev->nand = NULL;
> + kfree(elbc_fcm_ctrl);
Will cause NULL dereference and/or use-after-free for other
elbc nand instances. To avoid that, reference counting for
elbc_fcm_ctrl is required.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
From: Jan-Bernd Themann @ 2010-09-20 14:26 UTC (permalink / raw)
To: Milton Miller
Cc: linux-kernel-owner, Darren Hart, dvhltc, linux-kernel,
Milton Miller, Will Schmidt, Brian King, niv, Thomas Gleixner,
Doug Maxey, linuxppc-dev
In-Reply-To: <1274433481_6943@mail4.comsite.net>
Hi Milton,
sorry for the delayed answer, was on vacation.
linux-kernel-owner@vger.kernel.org wrote on 21.05.2010 11:18:01:
> linux-kernel-owner@vger.kernel.org
>
> On Thu, 20 May 2010 at 10:21:36 +0200 (CEST) Thomas Gleixner wrote:
> > On Thu, 20 May 2010, Michael Ellerman wrote:
> > > On Wed, 2010-05-19 at 16:38 +0200, Thomas Gleixner wrote:
> > > > On Wed, 19 May 2010, Darren Hart wrote:
> > > >
> > > > > On 05/18/2010 06:25 PM, Michael Ellerman wrote:
> > > > > > On Tue, 2010-05-18 at 15:22 -0700, Darren Hart wrote:
> > >
> > > > > > The result of the discussion about two years ago on this was
that we
> > > > > > needed a custom flow handler for XICS on RT.
> > > > >
> > > > > I'm still not clear on why the ultimate solution wasn't to
> have XICS report
> > > > > edge triggered as edge triggered. Probably some complexity
> of the entire power
> > > > > stack that I am ignorant of.
> > > > >
> > > > > > Apart from the issue of loosing interrupts there is also
> the fact that
> > > > > > masking on the XICS requires an RTAS call which takes a global
lock.
> > > >
> > > > Right, I'd love to avoid that but with real level interrupts we'd
run
> > > > into an interrupt storm. Though another solution would be to issue
the
> > > > EOI after the threaded handler finished, that'd work as well, but
> > > > needs testing.
> > >
> > > Yeah I think that was the idea for the custom flow handler. We'd
reset
> > > the processor priority so we can take other interrupts (which the EOI
> > > usually does for you), then do the actual EOI after the handler
> > > finished.
> >
> > That only works when the card does not issue new interrupts until the
> > EOI happens. If the EOI is only relevant for the interrupt controller,
> > then you are going to lose any edge which comes in before the EOI as
> > well.
>
> Well, the real MSIs have an extra bit to allow the eoi to dally behind
> the mmio on another path and that should cover this race when the irq
> is left enabled.
>
> Jan-Bernd HEA has that change, right?
I don't now. We never hit problems so we did not look very deep into this
area.
We probably have to talk to the HEA HW developers to be sure.
Regards,
Jan-Bernd
^ permalink raw reply
* RE: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-09-20 14:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100914151219.5d92c6f9.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>=20
> > @@ -219,6 +219,7 @@ struct rio_net {
> > /**
> > * struct rio_switch - RIO switch info
> > * @node: Node in global list of switches
> > + * @rdev: Associated RIO device structure
> > * @switchid: Switch ID that is unique across a network
> > * @hopcount: Hopcount to this switch
> > * @destid: Associated destid in the path
> > @@ -234,6 +235,7 @@ struct rio_net {
> > */
> > struct rio_switch {
> > struct list_head node;
> > + struct rio_dev *rdev;
> > u16 switchid;
> > u16 hopcount;
> > u16 destid;
>=20
> What is the locking for rdev?
This question prompted me consider the following change:
Because the rio_switch structure (in current implementation) is a
dynamically allocated part of rio_dev, I think it may be simpler to
combine them into single allocation by using zero length array
declaration:
struct rio_dev {
struct list_head global_list;
struct list_head net_list;
.....
..... rest of rio_dev
.....
struct rio_switch switch[0];
}
This will remove extra memory allocation, remove overlapping structure
members and clean code sections like one shown below:
u8 hopcount =3D 0xff;
u16 destid =3D rdev->destid;
if (rdev->rswitch) {
destid =3D rdev->rswitch->destid;
hopcount =3D rdev->rswitch->hopcount;
} =20
And this looks better aligned with RapidIO definitions - both: endpoints
and switches are RIO devices. The current implementation of rio_dev
somewhat separates rio_switch from its common part (this is why I have
added that link into rio_switch). We may keep using the pointer to
associated rio_dev, but reworking the rio_dev structure seems better way
to me.
Please, let me know what do you think about this conversion. And if
there are no objections I will make a patch.
Alex.
=20
^ permalink raw reply
* Re: [PATCH 1/2]: Powerpc: Fix EHCA driver on relocatable kernel
From: Alexander Schmidt @ 2010-09-20 14:41 UTC (permalink / raw)
To: Sonny Rao; +Cc: linux-rdma, fenkes, linuxppc-dev, raisch
In-Reply-To: <20100820040809.GS16505@us.ibm.com>
On Thu, 19 Aug 2010 23:08:09 -0500
Sonny Rao <sonnyrao@us.ibm.com> wrote:
> Some modules (like eHCA) want to map all of kernel memory, for this to
> work with a relocated kernel, we need to export kernstart_addr so
> modules can use PHYSICAL_START and memstart_addr so they could use
> MEMORY_START. Note that the 32bit code already exports these symbols.
>
> Signed-off-By: Sonny Rao <sonnyrao@us.ibm.com>
Acked-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
> Index: common/arch/powerpc/mm/init_64.c
> ===================================================================
> --- common.orig/arch/powerpc/mm/init_64.c 2010-08-16 02:38:33.000000000 -0500
> +++ common/arch/powerpc/mm/init_64.c 2010-08-16 02:39:25.000000000 -0500
> @@ -79,7 +79,9 @@
> #endif /* CONFIG_PPC_STD_MMU_64 */
>
> phys_addr_t memstart_addr = ~0;
> +EXPORT_SYMBOL(memstart_addr);
> phys_addr_t kernstart_addr;
> +EXPORT_SYMBOL(kernstart_addr);
>
> void free_initmem(void)
> {
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-20 15:37 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284706869-12555-1-git-send-email-tie-fei.zang@freescale.com>
On Fri, Sep 17, 2010 at 03:01:07PM +0800, Roy Zang wrote:
[...]
> +struct fsl_lbc_ctrl {
> + /* device info */
> + struct device *dev;
Forward declaration for struct device is needed (and enough).
> + struct fsl_lbc_regs __iomem *regs;
> + int irq;
> + wait_queue_head_t irq_wait;
#include <linux/wait.h> is needed for this.
> + spinlock_t lock;
#include <linux/spinlock.h>
[...]
> diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
> index dceb8d1..4920cd3 100644
> --- a/arch/powerpc/sysdev/fsl_lbc.c
> +++ b/arch/powerpc/sysdev/fsl_lbc.c
[...]
> +#include <linux/slab.h>
> +#include <linux/of_platform.h>
I guess of_platform.h is not needed any longer.
> +#include <linux/platform_device.h>
> +#include <linux/interrupt.h>
>
[...]
> default:
> return -EINVAL;
> @@ -143,14 +130,18 @@ EXPORT_SYMBOL(fsl_upm_find);
> * thus UPM pattern actually executed. Note that mar usage depends on the
> * pre-programmed AMX bits in the UPM RAM.
> */
> +
No need for this empty line.
> int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
> {
> int ret = 0;
> unsigned long flags;
[...]
> +static int __devinit fsl_lbc_ctrl_probe(struct platform_device *dev)
> +{
> + int ret;
> +
> + if (!dev->dev.of_node) {
> + dev_err(&dev->dev, "Device OF-Node is NULL");
> + return -EFAULT;
> + }
> + fsl_lbc_ctrl_dev = kzalloc(sizeof(*fsl_lbc_ctrl_dev), GFP_KERNEL);
Btw, the code in the NAND driver checks for !fsl_lbc_ctrl_dev.
So it might make sense to assign the global variable after the
struct is fully initialized.
> + if (!fsl_lbc_ctrl_dev)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&dev->dev, fsl_lbc_ctrl_dev);
> +
> + spin_lock_init(&fsl_lbc_ctrl_dev->lock);
> + init_waitqueue_head(&fsl_lbc_ctrl_dev->irq_wait);
> +
> + fsl_lbc_ctrl_dev->regs = of_iomap(dev->dev.of_node, 0);
> + if (!fsl_lbc_ctrl_dev->regs) {
> + dev_err(&dev->dev, "failed to get memory region\n");
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + fsl_lbc_ctrl_dev->irq = irq_of_parse_and_map(dev->dev.of_node, 0);
> + if (fsl_lbc_ctrl_dev->irq == NO_IRQ) {
> + dev_err(&dev->dev, "failed to get irq resource\n");
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + fsl_lbc_ctrl_dev->dev = &dev->dev;
> +
> + ret = fsl_lbc_ctrl_init(fsl_lbc_ctrl_dev);
> + if (ret < 0)
> + goto err;
> +
> + ret = request_irq(fsl_lbc_ctrl_dev->irq, fsl_lbc_ctrl_irq, 0,
> + "fsl-lbc", fsl_lbc_ctrl_dev);
> + if (ret != 0) {
> + dev_err(&dev->dev, "failed to install irq (%d)\n",
> + fsl_lbc_ctrl_dev->irq);
> + ret = fsl_lbc_ctrl_dev->irq;
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + iounmap(fsl_lbc_ctrl_dev->regs);
> + kfree(fsl_lbc_ctrl_dev);
> + return ret;
> +}
> +
> +static const struct of_device_id fsl_lbc_match[] = {
#include <linux/mod_devicetable.h> is needed for this.
Plus, I think the patch is not runtime bisectable (i.e. you
now do request_irq() here, but not removing it from the nand
driver, so nand will fail to probe).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Generating elf kernel ?
From: Scott Wood @ 2010-09-20 15:43 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <4C9569FF.6090807@windriver.com>
On Sun, 19 Sep 2010 09:40:15 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:
> Scott Wood wrote:
> > On Fri, 17 Sep 2010 09:58:41 +0800
> > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> >
> >> Scott Wood wrote:
> >>> The guest OS *is* the same as native Linux, as far as TLB handling is
> >>> concerned.
> >> Looks you means the TLB exception handler should be same between the native and
> >> the guest OS. Right?
> >
> > Yes.
>
> I don't think so. The HY should assist the guest OS on MMU since I already point
> the guest OS have no authority to create a real TLB directly as I previously said.
Of course the hypervisor assists, when a trap is taken. That doesn't
mean the code is any different in the guest.
> > Yes, of course. But that's not the point. I was just using it as a
> > convenient example because that's what I've recently done ELF loading
> > with... There's no reason U-Boot couldn't do the same if its ELF
> > loader were updated to support device trees. Currently U-Boot loads
> > bootwrapperless uImages to physical address zero.
>
> I never doubt the U-boot can do this for uImage. But I think we're always
> talking about vmlinux, a bare Image.
uImage is pretty much a bare image. It just has a header with a
checksum and some info like OS/architecture, kernel version, build
date, etc.
There would be *no* problem doing this with vmlinux in U-Boot if
someone put in the code to pass a device tree.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 15:51 UTC (permalink / raw)
To: Josh Boyer; +Cc: kumar.gala, linux-watchdog, linuxppc-dev
In-Reply-To: <AANLkTi=Ks7hkDq1g1SyHLf4Lf8tsew-KnvKOgyQxjcWQ@mail.gmail.com>
On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> =A0config BOOKE_WDT
>> - =A0 =A0 =A0 bool "PowerPC Book-E Watchdog Timer"
>> + =A0 =A0 =A0 tristate "PowerPC Book-E Watchdog Timer"
>> =A0 =A0 =A0 =A0depends on BOOKE || 4xx
>> =A0 =A0 =A0 =A0---help---
>> + =A0 =A0 =A0 =A0 Watchdog driver for PowerPC e500 chips, such as the Fr=
eescale
>> + =A0 =A0 =A0 =A0 MPC85xx SOCs.
>> +
>
> Again, used for more than e500. =A0That || 4xx in the depends statement
> right above your addition isn't there for fun :).
Does this mean that this comment which is already in the driver is
wrong? It alludes that "Book-E" is synonymous with "e500".
/* If the kernel parameter wdt=3D1, the watchdog will be enabled at boot.
* Also, the wdt_period sets the watchdog timer period timeout.
* For E500 cpus the wdt_period sets which bit changing from 0->1 will
* trigger a watchog timeout. This watchdog timeout will occur 3 times, the
* first time nothing will happen, the second time a watchdog exception wil=
l
* occur, and the final time the board will reset.
*/
#ifdef CONFIG_FSL_BOOKE
#define WDT_PERIOD_DEFAULT 38 /* Ex. wdt_period=3D28 bus=3D333Mhz,reset=3D~=
40sec */
#else
#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
#endif /* for timing information */
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Timur Tabi @ 2010-09-20 16:23 UTC (permalink / raw)
To: benh, linuxppc-dev, kumar.gala, linux-watchdog, jwboyer
Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
to a GPL-only export. This is okay, because any module that needs this symbol
should be an actual Linux driver, which must be GPL-licensed.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This export is necessary for the Book-E watchdog driver to be compiled as a
module.
arch/powerpc/kernel/time.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 8533b3b..0c0c241 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -161,8 +161,9 @@ extern struct timezone sys_tz;
static long timezone_offset;
unsigned long ppc_proc_freq;
-EXPORT_SYMBOL(ppc_proc_freq);
+EXPORT_SYMBOL_GPL(ppc_proc_freq);
unsigned long ppc_tb_freq;
+EXPORT_SYMBOL_GPL(ppc_tb_freq);
static DEFINE_PER_CPU(u64, last_jiffy);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] [v2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 16:23 UTC (permalink / raw)
To: benh, linuxppc-dev, kumar.gala, linux-watchdog, jwboyer
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
Register the __init and __exit functions in the PowerPC e500 watchdog driver
as module entry/exit functions, and modify the Kconfig entry.
Add a .release method for the PowerPC e500 watchdog driver, so that the
watchdog is disabled when the driver is closed.
Loosely based on original code from Jiang Yutang <b14898@freescale.com>.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch requires:
powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
drivers/watchdog/Kconfig | 5 ++++-
drivers/watchdog/booke_wdt.c | 39 +++++++++++++++++++++++++++++++++++++--
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 24efd8e..a6812eb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -957,9 +957,12 @@ config PIKA_WDT
the Warp platform.
config BOOKE_WDT
- bool "PowerPC Book-E Watchdog Timer"
+ tristate "PowerPC Book-E Watchdog Timer"
depends on BOOKE || 4xx
---help---
+ Watchdog driver for PowerPC Book-E chips, such as the Freescale
+ MPC85xx SOCs and the IBM PowerPC 440.
+
Please see Documentation/watchdog/watchdog-api.txt for
more information.
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3d49671..a989998 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -4,7 +4,7 @@
* Author: Matthew McClintock
* Maintainer: Kumar Gala <galak@kernel.crashing.org>
*
- * Copyright 2005, 2008 Freescale Semiconductor Inc.
+ * Copyright 2005, 2008, 2010 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -114,6 +114,27 @@ static void __booke_wdt_enable(void *data)
mtspr(SPRN_TCR, val);
}
+/**
+ * booke_wdt_disable - disable the watchdog on the given CPU
+ *
+ * This function is called on each CPU. It disables the watchdog on that CPU.
+ *
+ * TCR[WRC] cannot be changed once it has been set to non-zero, but we can
+ * effectively disable the watchdog by setting its period to the maximum value.
+ */
+static void __booke_wdt_disable(void *data)
+{
+ u32 val;
+
+ val = mfspr(SPRN_TCR);
+ val &= ~(TCR_WIE | WDTP_MASK);
+ mtspr(SPRN_TCR, val);
+
+ /* clear status to make sure nothing is pending */
+ __booke_wdt_ping(NULL);
+
+}
+
static ssize_t booke_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -193,12 +214,21 @@ static int booke_wdt_open(struct inode *inode, struct file *file)
return nonseekable_open(inode, file);
}
+static int booke_wdt_release(struct inode *inode, struct file *file)
+{
+ on_each_cpu(__booke_wdt_disable, NULL, 0);
+ booke_wdt_enabled = 0;
+
+ return 0;
+}
+
static const struct file_operations booke_wdt_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
.write = booke_wdt_write,
.unlocked_ioctl = booke_wdt_ioctl,
.open = booke_wdt_open,
+ .release = booke_wdt_release,
};
static struct miscdevice booke_wdt_miscdev = {
@@ -237,4 +267,9 @@ static int __init booke_wdt_init(void)
return ret;
}
-device_initcall(booke_wdt_init);
+
+module_init(booke_wdt_init);
+module_exit(booke_wdt_exit);
+
+MODULE_DESCRIPTION("PowerPC Book-E watchdog driver");
+MODULE_LICENSE("GPL");
--
1.7.2.3
^ permalink raw reply related
* Re: cuImage and multi image?
From: Shawn Jin @ 2010-09-20 17:52 UTC (permalink / raw)
To: tiejun.chen; +Cc: ppcdev, uboot
In-Reply-To: <4C91C77B.8080501@windriver.com>
>> I have a cuImage kernel in order to support legacy u-boot and a
>> ramdisk image. Kernel boots fine if these two images are separate and
>> "bootm $kernel $ramdisk" is used. But I can not make it to work using
>> a single multi image that contains the kernel and ramdisk images. Is
>> it even technically possible to boot a multi-image with cuboot
>> wrapper?
>
> Try the following steps:
> ------
> 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.<your target>
>
> You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
A follow up question. With this method, the total image size
(uncompressed) is limited to the 4MB (the link address of the boot
wrapper)?
Thanks,
-Shawn.
^ permalink raw reply
* RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Tirumala Marri @ 2010-09-20 18:00 UTC (permalink / raw)
To: Wolfgang Denk
Cc: neilb, yur, linux-raid, herbert, linux-crypto, dan.j.williams,
linuxppc-dev
In-Reply-To: <20100918210920.E05AE157D71@gemini.denx.de>
Mr. Wolfgang
>
> Will this driver ever include any 40x processors? If not, you probably
> should use "44x" instead (here and everywhere in the rest of the
> code).
[Marri] Yes there is 40x based DMA engine we planned to include in the
future.
> > +/* Pointer to DMA0, DMA1 CP/CS FIFO */
> > +static void *ppc440spe_dma_fifo_buf;
>
> Seems this should go into "ppc440spe-dma.h"?
>
>
> > +/* This array is used in data-check operations for storing a pattern
> */
> > +static char ppc440spe_qword[16];
> > +
> > +static atomic_t ppc4xx_adma_err_irq_ref;
> > +static dcr_host_t ppc440spe_mq_dcr_host;
> > +static unsigned int ppc440spe_mq_dcr_len;
>
> Ditto?
>
> > +static unsigned long ppc440spe_rxor_state;
> > +
> > +static struct page *ppc440spe_rxor_srcs[32];
>
> And here again - please check globally!
>
>
> > +/**
> > + * ppc440spe_can_rxor - check if the operands may be processed with
> RXOR
> > + */
> > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> size_t len)
>
> Again, should this then not be in ppc440spe specific files?
>
>
> It seems the split / generalization is highly incomplete yet.
[Marri] Some of the stuff can go into ppc440spe-dma.h. This is just
Beginning to add more new DMA engines support. I expect more changes to
come in.
Regards,
Marri
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
From: Scott Wood @ 2010-09-20 18:51 UTC (permalink / raw)
To: Josh Boyer
Cc: linuxppc-dev, Gala Kumar-B11780, Tabi Timur-B04825,
linux-watchdog
In-Reply-To: <AANLkTi=RXjc=GZ+RRsKjL3qdYFayXOCX0s1SU5jojeXg@mail.gmail.com>
On Sat, 18 Sep 2010 14:22:12 -0400
Josh Boyer <jwboyer@gmail.com> wrote:
> Capitalizing? The patch you posted that uses this symbol is for a GPL
> driver so you gain or lose nothing by having this symbol be
> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
> of gain by allowing non-GPL modules? If so, I find that unfortunate.
> If not, then I guess I don't understand what you mean by capitalizing.
One can dislike DRM (even a very weak form such as this) without having
a particular desire to go outside the bounds of what it allows.
I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
symbols whose use is likely to be indicitave of code that is, in some
copyright-meaningful way, derived from GPL code? I have a hard time
seeing that being the case here. If every symbol is made GPL-only,
then that just gives the binary-only people[1] more incentive to
circumvent the entire mechanism. It loses its meaning.
Documentation/DocBook/kernel-hacking.tmpl says, "It implies that the
function is considered an internal implementation issue, and not really
an interface."
-Scott
[1] Plus anyone who might want to make a kernel module out of code
which is open source, but not under a license the GPLv2 is compatible
with.
^ permalink raw reply
* Re: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Andrew Morton @ 2010-09-20 19:17 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201303D0E@CORPEXCH1.na.ads.idt.com>
On Mon, 20 Sep 2010 07:31:22 -0700
"Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > @@ -219,6 +219,7 @@ struct rio_net {
> > > /**
> > > * struct rio_switch - RIO switch info
> > > * @node: Node in global list of switches
> > > + * @rdev: Associated RIO device structure
> > > * @switchid: Switch ID that is unique across a network
> > > * @hopcount: Hopcount to this switch
> > > * @destid: Associated destid in the path
> > > @@ -234,6 +235,7 @@ struct rio_net {
> > > */
> > > struct rio_switch {
> > > struct list_head node;
> > > + struct rio_dev *rdev;
> > > u16 switchid;
> > > u16 hopcount;
> > > u16 destid;
> >
> > What is the locking for rdev?
>
> This question prompted me consider the following change:
>
> Because the rio_switch structure (in current implementation) is a
> dynamically allocated part of rio_dev, I think it may be simpler to
> combine them into single allocation by using zero length array
> declaration:
>
> struct rio_dev {
> struct list_head global_list;
> struct list_head net_list;
> .....
> ..... rest of rio_dev
> .....
> struct rio_switch switch[0];
> }
>
> This will remove extra memory allocation, remove overlapping structure
> members and clean code sections like one shown below:
>
> u8 hopcount = 0xff;
> u16 destid = rdev->destid;
>
> if (rdev->rswitch) {
> destid = rdev->rswitch->destid;
> hopcount = rdev->rswitch->hopcount;
> }
>
> And this looks better aligned with RapidIO definitions - both: endpoints
> and switches are RIO devices. The current implementation of rio_dev
> somewhat separates rio_switch from its common part (this is why I have
> added that link into rio_switch). We may keep using the pointer to
> associated rio_dev, but reworking the rio_dev structure seems better way
> to me.
>
> Please, let me know what do you think about this conversion. And if
> there are no objections I will make a patch.
>
If you say so ;)
The "variable length array at the end of the struct" thing is pretty
commonly used and works well. As long as we never want to change the
number of switches on the fly (hotplug?).
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <AANLkTimp-0zdw-fAaX8qCwHW0NMn--6RK0_USDGOSe47@mail.gmail.com>
On Mon, Sep 20, 2010 at 10:51:37AM -0500, Timur Tabi wrote:
>On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> config BOOKE_WDT
>>> - bool "PowerPC Book-E Watchdog Timer"
>>> + tristate "PowerPC Book-E Watchdog Timer"
>>> depends on BOOKE || 4xx
>>> ---help---
>>> + Watchdog driver for PowerPC e500 chips, such as the Freescale
>>> + MPC85xx SOCs.
>>> +
>>
>> Again, used for more than e500. That || 4xx in the depends statement
>> right above your addition isn't there for fun :).
>
>Does this mean that this comment which is already in the driver is
>wrong? It alludes that "Book-E" is synonymous with "e500".
>
>/* If the kernel parameter wdt=1, the watchdog will be enabled at boot.
> * Also, the wdt_period sets the watchdog timer period timeout.
> * For E500 cpus the wdt_period sets which bit changing from 0->1 will
> * trigger a watchog timeout. This watchdog timeout will occur 3 times, the
> * first time nothing will happen, the second time a watchdog exception will
> * occur, and the final time the board will reset.
> */
I guess I don't see what you mean. It talks about e500 but it doesn't
say "Book-E" anywhere in that comment. (Though I'm pretty sure that
comment does apply to 4xx.)
>
>#ifdef CONFIG_FSL_BOOKE
>#define WDT_PERIOD_DEFAULT 38 /* Ex. wdt_period=28 bus=333Mhz,reset=~40sec */
>#else
>#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
>#endif /* for timing information */
And this bit is marked as "FSL_BOOKE" vs. 40x and 44x.
josh
^ permalink raw reply
* Re: [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: kumar.gala, linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
On Mon, Sep 20, 2010 at 11:23:41AM -0500, Timur Tabi wrote:
>Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
>watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
>to a GPL-only export. This is okay, because any module that needs this symbol
>should be an actual Linux driver, which must be GPL-licensed.
>
>Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>---
>
>This export is necessary for the Book-E watchdog driver to be compiled as a
>module.
>
> arch/powerpc/kernel/time.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>index 8533b3b..0c0c241 100644
>--- a/arch/powerpc/kernel/time.c
>+++ b/arch/powerpc/kernel/time.c
>@@ -161,8 +161,9 @@ extern struct timezone sys_tz;
> static long timezone_offset;
>
> unsigned long ppc_proc_freq;
>-EXPORT_SYMBOL(ppc_proc_freq);
>+EXPORT_SYMBOL_GPL(ppc_proc_freq);
> unsigned long ppc_tb_freq;
>+EXPORT_SYMBOL_GPL(ppc_tb_freq);
>
> static DEFINE_PER_CPU(u64, last_jiffy);
>
>--
>1.7.2.3
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-09-20 19:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100920121725.66bb96d0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>=20
> The "variable length array at the end of the struct" thing is pretty
> commonly used and works well. As long as we never want to change the
> number of switches on the fly (hotplug?).
This is expected to be a "strange" array - its size can be 0 or 1 only.
No number of switches in that array should be changed on the fly.
In the hotplug situation entire rio_dev structure should be added (or
removed).
RIO device can be endpoint or switch. If a RIO device is a switch - the
rio_switch
structure will be added at the end.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 19:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <20100920193016.GA3845@zod.rchland.ibm.com>
Josh Boyer wrote:
> I guess I don't see what you mean. It talks about e500 but it doesn't
> say "Book-E" anywhere in that comment. (Though I'm pretty sure that
> comment does apply to 4xx.)
That was my point. The comment says e500, but the code is also intended for
4xx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Micha Nelissen @ 2010-09-20 20:40 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, Andrew Morton, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201303D0E@CORPEXCH1.na.ads.idt.com>
Hi Alex,
Bounine, Alexandre wrote:
> struct rio_dev {
> struct list_head global_list;
> struct list_head net_list;
> .....
> ..... rest of rio_dev
> .....
> struct rio_switch switch[0];
> }
It makes sense to let rio_dev structures point to the switch they are
attached to. That can be useful in various situations, but is not
possible with this setup.
If a rio_dev is a switch then rdev->rswitch->rdev == rdev holds.
> This will remove extra memory allocation, remove overlapping structure
> members and clean code sections like one shown below:
>
> u8 hopcount = 0xff;
> u16 destid = rdev->destid;
>
> if (rdev->rswitch) {
> destid = rdev->rswitch->destid;
> hopcount = rdev->rswitch->hopcount;
> }
Note that it is possible for rdev->destid to differ from
rdev->rswitch->destid even if rswitch->rdev == rdev (for non-hosts i.e.
agents). rswitch->destid is the destid by which we discovered the switch
(and can reach it) but rdev->destid is the actual id given to the switch.
Micha
^ permalink raw reply
* Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Wolfgang Denk @ 2010-09-20 21:31 UTC (permalink / raw)
To: Tirumala Marri
Cc: neilb, yur, linux-raid, herbert, linux-crypto, dan.j.williams,
linuxppc-dev
In-Reply-To: <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com>
Dear Tirumala Marri,
In message <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com> you wrote:
>
> > > +/**
> > > + * ppc440spe_can_rxor - check if the operands may be processed with RXOR
> > > + */
> > > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> > size_t len)
> >
> > Again, should this then not be in ppc440spe specific files?
> >
> >
> > It seems the split / generalization is highly incomplete yet.
>
> [Marri] Some of the stuff can go into ppc440spe-dma.h. This is just
> Beginning to add more new DMA engines support. I expect more changes to
> come in.
Why would that go into a header file? This is source code, not header
stuff. It should stay in a .c file! [Note that Ilya asked the same
question.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Intel's new motto: United we stand. Divided we fall!
^ permalink raw reply
* RE: Generating elf kernel ?
From: Chen, Tiejun @ 2010-09-21 1:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <20100920104353.5dbd9201@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Monday, September 20, 2010 11:44 PM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>=20
> On Sun, 19 Sep 2010 09:40:15 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>=20
> > Scott Wood wrote:
> > > On Fri, 17 Sep 2010 09:58:41 +0800
> > > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> > >=20
> > >> Scott Wood wrote:
> > >>> The guest OS *is* the same as native Linux, as far as=20
> TLB handling=20
> > >>> is concerned.
> > >> Looks you means the TLB exception handler should be same between=20
> > >> the native and the guest OS. Right?
> > >=20
> > > Yes.
> >=20
> > I don't think so. The HY should assist the guest OS on MMU since I=20
> > already point the guest OS have no authority to create a=20
> real TLB directly as I previously said.
>=20
> Of course the hypervisor assists, when a trap is taken. That=20
> doesn't mean the code is any different in the guest.
This should be depend on the hypervisor design implementation. I think
your=20
option should be based on the Freescale hypervisor.
>=20
> > > Yes, of course. But that's not the point. I was just=20
> using it as a=20
> > > convenient example because that's what I've recently done ELF=20
> > > loading with... There's no reason U-Boot couldn't do the same if=20
> > > its ELF loader were updated to support device trees. Currently=20
> > > U-Boot loads bootwrapperless uImages to physical address zero.
> >=20
> > I never doubt the U-boot can do this for uImage. But I think we're=20
> > always talking about vmlinux, a bare Image.
>=20
> uImage is pretty much a bare image. It just has a header=20
> with a checksum and some info like OS/architecture, kernel=20
> version, build date, etc.
Yes. But it also inlcude load address and entry point used to u-boot.
>=20
> There would be *no* problem doing this with vmlinux in U-Boot=20
> if someone put in the code to pass a device tree.
This is just I always emphasize previously.
Cheers
Tiejun
>=20
> -Scott
>=20
>=20
^ permalink raw reply
* RE: cuImage and multi image?
From: Chen, Tiejun @ 2010-09-21 1:03 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev, uboot
In-Reply-To: <AANLkTikrYdi=V6jM4HS3V4XzMutGdkPA2qHRBgviKHM8@mail.gmail.com>
> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Tuesday, September 21, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: cuImage and multi image?
>=20
> >> I have a cuImage kernel in order to support legacy u-boot and a=20
> >> ramdisk image. Kernel boots fine if these two images are=20
> separate and=20
> >> "bootm $kernel $ramdisk" is used. But I can not make it to=20
> work using=20
> >> a single multi image that contains the kernel and ramdisk=20
> images. Is=20
> >> it even technically possible to boot a multi-image with cuboot=20
> >> wrapper?
> >
> > Try the following steps:
> > ------
> > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > 2. make cuImage.initrd.<your target>
> >
> > You can get one Image, cuImage.initrd.<your target>,=20
> including kernel and ramdisk.
>=20
> A follow up question. With this method, the total image size
> (uncompressed) is limited to the 4MB (the link address of the=20
> boot wrapper)?
No.
Cheers
Tiejun
>=20
> Thanks,
> -Shawn.
>=20
^ permalink raw reply
* Dual ethernet attachment with single FEC
From: LEROY Christophe @ 2010-09-21 7:30 UTC (permalink / raw)
To: LinuxPPC-dev, netdev
Hello,
I have a board with 2 PHYs attached to one FEC ethernet controler on
powerpc.
I want to implement some kind of main-standby attachment to LAN by
setting the ISOLATE bit on one on the two PHYs then monitoring the link
status and switch to the other PHY when the link status goes down.
I see this behaviour is implemented in the sis900 driver, but it doesn't
use the standard PHY layer as the Freescale FEC driver does.
What would be the most proper way to implement this functionality ?
* Modify FEC driver to manage that ?
* Implement a virtual PHY driver that would manage that ?
* Other solution ?
Best regards
C. Leroy
^ permalink raw reply
* [PATCH] fsldma: add support to 36-bit physical address
From: Li Yang @ 2010-09-21 10:57 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/dma/fsldma.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index cea08be..9163552 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1,7 +1,7 @@
/*
* Freescale MPC85xx, MPC83xx DMA Engine support
*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
*
* Author:
* Zhang Wei <wei.zhang@freescale.com>, Jul 2007
@@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct platform_device *op,
fdev->common.device_control = fsl_dma_device_control;
fdev->common.dev = &op->dev;
+ dma_set_mask(&op->dev, DMA_BIT_MASK(36));
dev_set_drvdata(&op->dev, fdev);
/*
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
From: Detlev Zundel @ 2010-09-21 12:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20100920135136.04ceb772__36164.799918379$1285008751$gmane$org@udp111988uds.am.freescale.net>
Hi Scott,
> On Sat, 18 Sep 2010 14:22:12 -0400
> Josh Boyer <jwboyer@gmail.com> wrote:
>
>> Capitalizing? The patch you posted that uses this symbol is for a GPL
>> driver so you gain or lose nothing by having this symbol be
>> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
>> of gain by allowing non-GPL modules? If so, I find that unfortunate.
>> If not, then I guess I don't understand what you mean by capitalizing.
>
> One can dislike DRM (even a very weak form such as this) without having
> a particular desire to go outside the bounds of what it allows.
>
> I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
> symbols whose use is likely to be indicitave of code that is, in some
> copyright-meaningful way, derived from GPL code?
Google finds this, which coincides with what I remmber[1]:
EXPORT_SYMBOL_GPL
Some kernel developers are unhappy with providing external interfaces to
their code, only to see those interfaces being used by binary only
modules. They view it as their work being appropriated. Whether you
agree with that view or not is completely irrelevant, the person who
owns the copyright decides how their work can be used.
EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
available to modules with a GPL compatible license. This is independent
of the kernel tainting, but obviously takes advantage of
MODULE_LICENSE() strings.
EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has
spoken. I believe the phrase involved killer penguins with chainsaws for
anybody who changed existing exported interfaces.
Cheers
Detlev
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0369.html
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Kumar Gala @ 2010-09-21 12:55 UTC (permalink / raw)
To: Li Yang; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <1285066638-7473-1-git-send-email-leoli@freescale.com>
On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
We really should have a sentence about how or why this works to address =
36-bit addressing.
> drivers/dma/fsldma.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index cea08be..9163552 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1,7 +1,7 @@
> /*
> * Freescale MPC85xx, MPC83xx DMA Engine support
> *
> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights =
reserved.
> + * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights =
reserved.
> *
> * Author:
> * Zhang Wei <wei.zhang@freescale.com>, Jul 2007
> @@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct =
platform_device *op,
> fdev->common.device_control =3D fsl_dma_device_control;
> fdev->common.dev =3D &op->dev;
>=20
> + dma_set_mask(&op->dev, DMA_BIT_MASK(36));
> dev_set_drvdata(&op->dev, fdev);
>=20
> /*
> --=20
> 1.6.6-rc1.GIT
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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