* [PATCH 2/8] net: ucc_geth: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-12 13:24 UTC (permalink / raw)
To: leoli, David Miller; +Cc: netdev, Li Zefan, linuxppc-dev, LKML
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 3c43dac..5930c39 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3911,14 +3911,12 @@ static int ucc_geth_probe(struct platform_device* ofdev)
static int ucc_geth_remove(struct platform_device* ofdev)
{
- struct device *device = &ofdev->dev;
- struct net_device *dev = dev_get_drvdata(device);
+ struct net_device *dev = platform_get_drvdata(ofdev);
struct ucc_geth_private *ugeth = netdev_priv(dev);
unregister_netdev(dev);
free_netdev(dev);
ucc_geth_memclean(ugeth);
- dev_set_drvdata(device, NULL);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 4/8] net: fs_enet: use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-12 13:24 UTC (permalink / raw)
To: pantelis.antoniou, vbordug, David Miller
Cc: netdev, Li Zefan, linuxppc-dev, LKML
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8de53a1..7e3de10 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -1122,7 +1122,6 @@ static int fs_enet_remove(struct platform_device *ofdev)
fep->ops->free_bd(ndev);
fep->ops->cleanup_data(ndev);
- dev_set_drvdata(fep->dev, NULL);
of_node_put(fep->fpi->phy_node);
free_netdev(ndev);
return 0;
--
1.7.1
^ permalink raw reply related
* use platform_{get,set}_drvdata()
From: Libo Chen @ 2013-08-12 13:24 UTC (permalink / raw)
To: David Miller
Cc: mugunthanvnm, Bill Pemberton, Greg KH, netdev, bigeasy, jg1.han,
LKML, michal.simek, prabhakar.csengg, Li Zefan, vbordug, renner,
linuxppc-dev, timur, b-liu
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Libo Chen (8):
net: fsl_pq_mdio: use platform_{get,set}_drvdata()
net: ucc_geth: use platform_{get,set}_drvdata()
net: fec_mpc52xx_phy: use platform_{get,set}_drvdata()
net: fs_enet: use platform_{get,set}_drvdata()
net: sunbmac: use platform_{get,set}_drvdata()
net: sunhme: use platform_{get,set}_drvdata()
net: xilinx_emaclite: use platform_{get,set}_drvdata()
net: davinci_mdio: use platform_{get,set}_drvdata()
drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 4 +---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 1 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 3 +--
drivers/net/ethernet/freescale/ucc_geth.c | 4 +---
drivers/net/ethernet/sun/sunbmac.c | 3 +--
drivers/net/ethernet/sun/sunhme.c | 8 +++-----
drivers/net/ethernet/ti/davinci_mdio.c | 4 +---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +---
8 files changed, 9 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: [PATCH RFC v2 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-08-12 13:37 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, linux-kernel,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1373803321-11628-3-git-send-email-gsi@denx.de>
Hello everyone!
Changes offered in this letter:
- Adding a flag "will_access_peripheral" to DMA transfer descriptor
according recommendations of Gerhard Sittig.
This flag is set in mpc_dma_prep_memcpy() and mpc_dma_prep_slave_sg()
and is evaluated in mpc_dma_execute().
- Adding locking and removing default nbytes value according
recommendations of Lars-Peter Clausen.
I tested these changes on MPC5125
with SCLPC driver (transfers between dev and mem work fine)
and dmatest module (all 64 DMA channels can perform mem-to-mem transfers
which can be chained in one DMA transaction).
2013/7/14 Gerhard Sittig <gsi@denx.de>:
> From: Alexander Popov <a13xp0p0v88@gmail.com>
>
> introduce support for slave s/g transfer preparation and the associated
> device control callback in the MPC512x DMA controller driver, which adds
> support for data transfers between memory and peripheral I/O to the
> previously supported mem-to-mem transfers
>
> refuse to prepare chunked transfers (transfers with more than one part)
> as long as proper support for scatter/gather is lacking
>
> keep MPC8308 operational by always starting transfers from software,
> this SoC appears to not have request lines for flow control when
> peripherals are involved in transfers
>
> [ introduction of slave s/g preparation and device control ]
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> [ execute() start condition, mpc8308 compat, terminate all, s/g length check, reworded commit msg ]
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/dma/mpc512x_dma.c | 168 +++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 161 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
> index 4e03f1e..55e6a87 100644
> --- a/drivers/dma/mpc512x_dma.c
> +++ b/drivers/dma/mpc512x_dma.c
> @@ -2,6 +2,7 @@
> * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
> * Copyright (C) Semihalf 2009
> * Copyright (C) Ilya Yanok, Emcraft Systems 2010
> + * Copyright (C) Alexander Popov, Promcontroller 2013
> *
> * Written by Piotr Ziecik <kosmo@semihalf.com>. Hardware description
> * (defines, structures and comments) was taken from MPC5121 DMA driver
> @@ -28,11 +29,6 @@
> * file called COPYING.
> */
>
> -/*
> - * This is initial version of MPC5121 DMA driver. Only memory to memory
> - * transfers are supported (tested using dmatest module).
> - */
> -
> #include <linux/module.h>
> #include <linux/dmaengine.h>
> #include <linux/dma-mapping.h>
> @@ -63,6 +59,7 @@ enum mpc8308_dmachan_id_t {
> MPC8308_DMACHAN_MAX = 16,
> };
> enum mpc512x_dmachan_id_t {
> + MPC512x_DMACHAN_MDDRC = 32,
> MPC512x_DMACHAN_MAX = 64,
> };
> #define MPC_DMA_CHANNELS 64
Adding the flag:
@@ -193,6 +183,7 @@ struct mpc_dma_desc {
dma_addr_t tcd_paddr;
int error;
struct list_head node;
+ int will_access_peripheral;
};
struct mpc_dma_chan {
> @@ -204,9 +201,13 @@ struct mpc_dma_chan {
> struct list_head completed;
> struct mpc_dma_tcd *tcd;
> dma_addr_t tcd_paddr;
> + u32 tcd_nunits;
>
> /* Lock for this structure */
> spinlock_t lock;
> +
> + /* Channel's peripheral fifo address */
> + dma_addr_t per_paddr;
> };
>
> struct mpc_dma {
We can't chain together descriptors of transfers which involve peripherals
because each of such transfers needs hardware initiated start.
@@ -253,10 +248,27 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
struct mpc_dma_desc *first = NULL;
struct mpc_dma_desc *prev = NULL;
struct mpc_dma_desc *mdesc;
+ int staffed = 0;
int cid = mchan->chan.chan_id;
- /* Move all queued descriptors to active list */
- list_splice_tail_init(&mchan->queued, &mchan->active);
+ /*
+ * Mem-to-mem transfers can be chained
+ * together into one transaction.
+ * But each transfer which involves peripherals
+ * must be executed separately.
+ */
+ while (!staffed) {
+ mdesc = list_first_entry(&mchan->queued,
+ struct mpc_dma_desc, node);
+
+ if (!mdesc->will_access_peripheral)
+ list_move_tail(&mdesc->node, &mchan->active);
+ else {
+ staffed = 1;
+ if (list_empty(&mchan->active))
+ list_move_tail(&mdesc->node, &mchan->active);
+ }
+ }
/* Chain descriptors into one transaction */
list_for_each_entry(mdesc, &mchan->active, node) {
> @@ -270,7 +271,12 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
>
> prev->tcd->dlast_sga = mdesc->tcd_paddr;
> prev->tcd->e_sg = 1;
> - mdesc->tcd->start = 1;
> +
> + /* software start for mem-to-mem transfers */
> + if (mdma->is_mpc8308)
> + mdesc->tcd->start = 1;
> + else if (cid == MPC512x_DMACHAN_MDDRC)
> + mdesc->tcd->start = 1;
>
> prev = mdesc;
> }
We don't need this change. Now only mem-to-mem transfers are chained:
@@ -270,6 +282,8 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
prev->tcd->dlast_sga = mdesc->tcd_paddr;
prev->tcd->e_sg = 1;
+
+ /* software start for mem-to-mem transfers */
mdesc->tcd->start = 1;
prev = mdesc;
> @@ -282,7 +288,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
>
> if (first != prev)
> mdma->tcd[cid].e_sg = 1;
> - out_8(&mdma->regs->dmassrt, cid);
> +
> + if (mdma->is_mpc8308) {
> + /* MPC8308, no request lines, software initiated start */
> + out_8(&mdma->regs->dmassrt, cid);
> + } else if (cid == MPC512x_DMACHAN_MDDRC) {
This condition should be changed to:
+ } else if (!first->will_access_peripheral) {
> + /* memory to memory transfer, software initiated start */
> + out_8(&mdma->regs->dmassrt, cid);
> + } else {
> + /* peripherals involved, use external request line */
> + out_8(&mdma->regs->dmaserq, cid);
> + }
> }
>
> /* Handle interrupt on one half of DMA controller (32 channels) */
Setting the flag:
@@ -608,6 +632,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan,
dma_addr_t dst, dma_addr_t src,
}
mdesc->error = 0;
+ mdesc->will_access_peripheral = 0;
tcd = mdesc->tcd;
/* Prepare Transfer Control Descriptor for this transaction */
> @@ -655,6 +671,141 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
> return &mdesc->desc;
> }
>
> +static struct dma_async_tx_descriptor *mpc_dma_prep_slave_sg(
> + struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction direction,
> + unsigned long flags, void *context)
> +{
> + struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
> + struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
> + struct mpc_dma_desc *mdesc = NULL;
Will be used when the spinlock is grabbed:
+ dma_addr_t per_paddr;
+ u32 tcd_nunits = 0;
> + struct mpc_dma_tcd *tcd;
> + unsigned long iflags;
> + struct scatterlist *sg;
> + size_t len;
> + int iter, i;
> +
> + if (!list_empty(&mchan->active))
> + return NULL;
> +
> + /* currently there is no proper support for scatter/gather */
> + if (sg_len > 1)
> + return NULL;
> +
> + for_each_sg(sgl, sg, sg_len, i) {
> + spin_lock_irqsave(&mchan->lock, iflags);
> +
> + mdesc = list_first_entry(&mchan->free, struct mpc_dma_desc,
> + node);
> + if (!mdesc) {
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> + /* try to free completed descriptors */
> + mpc_dma_process_completed(mdma);
> + return NULL;
> + }
> +
> + list_del(&mdesc->node);
While spinlock is grabbed:
+ per_paddr = mchan->per_paddr;
+ tcd_nunits = mchan->tcd_nunits;
> +
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> +
> + mdesc->error = 0;
Setting the flag here:
+ mdesc->will_access_peripheral = 1;
> + tcd = mdesc->tcd;
> +
> + /* Prepare Transfer Control Descriptor for this transaction */
> + memset(tcd, 0, sizeof(struct mpc_dma_tcd));
> +
> + if (!IS_ALIGNED(sg_dma_address(sg), 4))
> + return NULL;
> +
> + if (direction == DMA_DEV_TO_MEM) {
> + tcd->saddr = mchan->per_paddr;
This line should be changed to:
+ tcd->saddr = per_paddr;
> + tcd->daddr = sg_dma_address(sg);
> + tcd->soff = 0;
> + tcd->doff = 4;
> + } else if (direction == DMA_MEM_TO_DEV) {
> + tcd->saddr = sg_dma_address(sg);
> + tcd->daddr = mchan->per_paddr;
Ditto:
+ tcd->daddr = per_paddr;
> + tcd->soff = 4;
> + tcd->doff = 0;
> + } else {
> + return NULL;
> + }
> + tcd->ssize = MPC_DMA_TSIZE_4;
> + tcd->dsize = MPC_DMA_TSIZE_4;
> +
> + len = sg_dma_len(sg);
> +
> + if (mchan->tcd_nunits)
> + tcd->nbytes = mchan->tcd_nunits * 4;
> + else
> + tcd->nbytes = 64;
These 4 lines should be changed to:
+ if (tcd_nunits)
+ tcd->nbytes = tcd_nunits * 4;
+ else
+ return NULL;
The last line means that client kernel modules must set
src_maxburst and dst_maxburst fields of dma_slave_config (dmaengine.h).
> +
> + if (!IS_ALIGNED(len, tcd->nbytes))
> + return NULL;
> +
> + iter = len / tcd->nbytes;
> + if (iter > ((1 << 15) - 1)) { /* maximum biter */
> + return NULL; /* len is too big */
> + } else {
> + /* citer_linkch contains the high bits of iter */
> + tcd->biter = iter & 0x1ff;
> + tcd->biter_linkch = iter >> 9;
> + tcd->citer = tcd->biter;
> + tcd->citer_linkch = tcd->biter_linkch;
> + }
> +
> + tcd->e_sg = 0;
> + tcd->d_req = 1;
> +
> + /* Place descriptor in prepared list */
> + spin_lock_irqsave(&mchan->lock, iflags);
> + list_add_tail(&mdesc->node, &mchan->prepared);
> + spin_unlock_irqrestore(&mchan->lock, iflags);
> + }
> +
> + /* Return the last descriptor */
Offer to remove this comment.
> + return &mdesc->desc;
> +}
> +
> +static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> + unsigned long arg)
> +{
> + struct mpc_dma_chan *mchan;
> + struct mpc_dma *mdma;
> + struct dma_slave_config *cfg;
Locking:
+ unsigned long flags;
> +
> + mchan = dma_chan_to_mpc_dma_chan(chan);
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
> + /* disable channel requests */
> + mdma = dma_chan_to_mpc_dma(chan);
+ spin_lock_irqsave(&mchan->lock, flags);
> + out_8(&mdma->regs->dmacerq, chan->chan_id);
> + list_splice_tail_init(&mchan->prepared, &mchan->free);
> + list_splice_tail_init(&mchan->queued, &mchan->free);
> + list_splice_tail_init(&mchan->active, &mchan->free);
+ spin_unlock_irqrestore(&mchan->lock, flags);
> + return 0;
> + case DMA_SLAVE_CONFIG:
> + cfg = (void *)arg;
> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + return -EINVAL;
+ spin_lock_irqsave(&mchan->lock, flags);
> +
> + if (cfg->direction == DMA_DEV_TO_MEM) {
> + mchan->per_paddr = cfg->src_addr;
> + mchan->tcd_nunits = cfg->src_maxburst;
> + } else {
> + mchan->per_paddr = cfg->dst_addr;
> + mchan->tcd_nunits = cfg->dst_maxburst;
> + }
+ spin_unlock_irqrestore(&mchan->lock, flags);
> +
> + return 0;
> + default:
> + return -ENOSYS;
> + }
> +
> + return -EINVAL;
> +}
> +
> static int mpc_dma_probe(struct platform_device *op)
> {
> struct device_node *dn = op->dev.of_node;
> @@ -739,9 +890,12 @@ static int mpc_dma_probe(struct platform_device *op)
> dma->device_issue_pending = mpc_dma_issue_pending;
> dma->device_tx_status = mpc_dma_tx_status;
> dma->device_prep_dma_memcpy = mpc_dma_prep_memcpy;
> + dma->device_prep_slave_sg = mpc_dma_prep_slave_sg;
> + dma->device_control = mpc_dma_device_control;
>
> INIT_LIST_HEAD(&dma->channels);
> dma_cap_set(DMA_MEMCPY, dma->cap_mask);
> + dma_cap_set(DMA_SLAVE, dma->cap_mask);
>
> for (i = 0; i < dma->chancnt; i++) {
> mchan = &mdma->channels[i];
> --
> 1.7.10.4
>
Best regards,
Alexander.
^ permalink raw reply
* Re: [PATCH RFC v2 1/5] dma: mpc512x: re-order mpc8308 specific instructions
From: Alexander Popov @ 2013-08-12 13:38 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, linux-kernel,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1373803321-11628-2-git-send-email-gsi@denx.de>
Hello everyone!
2013/7/14 Gerhard Sittig <gsi@denx.de>:
> @@ -50,9 +50,23 @@
> #define MPC_DMA_DESCRIPTORS 64
>
> /* Macro definitions */
> -#define MPC_DMA_CHANNELS 64
> #define MPC_DMA_TCD_OFFSET 0x1000
>
> +/*
> + * the maximum channel count, and specific channels which need
> + * special processing, for individual hardware variants
> + *
> + * and the maximum channel count over all supported controllers,
> + * used for data structure sizes
> + */
> +enum mpc8308_dmachan_id_t {
> + MPC8308_DMACHAN_MAX = 16,
> +};
> +enum mpc512x_dmachan_id_t {
> + MPC512x_DMACHAN_MAX = 64,
> +};
> +#define MPC_DMA_CHANNELS 64
> +
I offer to use #define instead of enum here
since individual channels don't require special handling.
Best regards,
Alexander.
^ permalink raw reply
* Re: Powerpc: Kernel warn_on when enabling IOMMU_API
From: Alexey Kardashevskiy @ 2013-08-12 14:13 UTC (permalink / raw)
To: Bhushan Bharat-R65777; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0710DCBF@039-SN2MPN1-013.039d.mgd.msft.net>
On 08/12/2013 08:20 PM, Bhushan Bharat-R65777 wrote:
> And this simple fix work for me
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index b20ff17..8869b0d 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -48,6 +48,8 @@
> #include <asm/vio.h>
> #include <asm/tce.h>
>
> +#define DEBUG
> +
> #define DBG(...)
>
> static int novmerge;
> @@ -871,7 +873,7 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t size,
> }
> }
>
> -#ifdef CONFIG_IOMMU_API
> +#ifdef SPAPR_TCE_IOMMU
> /*
> * SPAPR TCE API
> */
> ----------------------
And with this fix, what does "ls -laR /sys/kernel/iommu_groups/" print?
--
Alexey
^ permalink raw reply
* [PATCH] powerpc: 52xx: provide a default in mpc52xx_irqhost_map()
From: Sebastian Andrzej Siewior @ 2013-08-12 14:17 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: Sebastian Andrzej Siewior, linuxppc-dev, Wolfram Sang
My gcc-4.3.5 fails to compile due to:
|cc1: warnings being treated as errors
|arch/powerpc/platforms/52xx/mpc52xx_pic.c: In function ‘mpc52xx_irqhost_map’:
|arch/powerpc/platforms/52xx/mpc52xx_pic.c:343: error: ‘irqchip’ may be used uninitialized in this function
since commit e34298c ("powerpc: 52xx: nop out unsupported critical
IRQs"). This warning is complete crap since only values 0…3 are possible
which are checked but gcc fails to understand that. I wouldn't care much
but since this is compiled with -Werror I made this patch.
While add it, I replaced the warning from l2irq to l1irq since this is
the number that is evaluated.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index b89ef65..b69221b 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -373,8 +373,9 @@ static int mpc52xx_irqhost_map(struct irq_domain *h, unsigned int virq,
case MPC52xx_IRQ_L1_PERP: irqchip = &mpc52xx_periph_irqchip; break;
case MPC52xx_IRQ_L1_SDMA: irqchip = &mpc52xx_sdma_irqchip; break;
case MPC52xx_IRQ_L1_CRIT:
+ default:
pr_warn("%s: Critical IRQ #%d is unsupported! Nopping it.\n",
- __func__, l2irq);
+ __func__, l1irq);
irq_set_chip(virq, &no_irq_chip);
return 0;
}
--
1.8.4.rc1
^ permalink raw reply related
* powerpc: Mark low level irq handlers NO_THREAD
From: Sebastian Andrzej Siewior @ 2013-08-12 14:48 UTC (permalink / raw)
To: Vitaly Bordug
Cc: Marcelo Tosatti, Thomas Gleixner, linuxppc-dev,
Sebastian Andrzej Siewior
From: Thomas Gleixner <tglx@linutronix.de>
These low level handlers cannot be threaded. Mark them NO_THREAD
Reported-by: leroy christophe <christophe.leroy@c-s.fr>
Tested-by: leroy christophe <christophe.leroy@c-s.fr>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
This patch has been posted on Feb 13, 2013 and nobody responded back then.
arch/powerpc/platforms/8xx/m8xx_setup.c | 1 +
arch/powerpc/sysdev/cpm1.c | 1 +
2 files changed, 2 insertions(+)
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -43,6 +43,7 @@ static irqreturn_t timebase_interrupt(in
static struct irqaction tbint_irqaction = {
.handler = timebase_interrupt,
+ .flags = IRQF_NO_THREAD,
.name = "tbint",
};
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -120,6 +120,7 @@ static irqreturn_t cpm_error_interrupt(i
static struct irqaction cpm_error_irqaction = {
.handler = cpm_error_interrupt,
+ .flags = IRQF_NO_THREAD,
.name = "error",
};
^ permalink raw reply
* Re: [PATCH 1/3 V2] mmc:core: parse voltage from device-tree
From: Scott Wood @ 2013-08-12 16:11 UTC (permalink / raw)
To: Zhang Haijun; +Cc: linux-mmc, cbouatmailru, cjb, linuxppc-dev, Haijun Zhang
In-Reply-To: <52084C7E.9000706@freescale.com>
On Mon, 2013-08-12 at 10:46 +0800, Zhang Haijun wrote:
> On 08/09/2013 10:48 PM, Kumar Gala wrote:
>
> > On Jul 31, 2013, at 1:25 AM, Haijun Zhang wrote:
> >
> > > Add function to support get voltage from device-tree.
> > > If there are voltage-range specified in device-tree node, this function
> > > will parse it and return the avail voltage mask.
> > >
> > > Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
> > > ---
> > > changes for v2:
> > > - Update the parameters of function
> > >
> > > drivers/mmc/core/core.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/mmc/core.h | 1 +
> > > 2 files changed, 47 insertions(+)
> > There should be a device tree binding spec update to go with this patch series.
> >
> > - k
> Hi, kumar
>
> I'll update this tree binding spec after the patch set is accept by
> Anton.
Bindings should come first (or at least, at the same time).
-Scott
^ permalink raw reply
* RE: Powerpc: Kernel warn_on when enabling IOMMU_API
From: Bhushan Bharat-R65777 @ 2013-08-12 16:14 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5208ED95.4090204@ozlabs.ru>
> -----Original Message-----
> From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
> Sent: Monday, August 12, 2013 7:44 PM
> To: Bhushan Bharat-R65777
> Cc: benh@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Powerpc: Kernel warn_on when enabling IOMMU_API
>=20
> On 08/12/2013 08:20 PM, Bhushan Bharat-R65777 wrote:
> > And this simple fix work for me
> > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> > index b20ff17..8869b0d 100644
> > --- a/arch/powerpc/kernel/iommu.c
> > +++ b/arch/powerpc/kernel/iommu.c
> > @@ -48,6 +48,8 @@
> > #include <asm/vio.h>
> > #include <asm/tce.h>
> >
> > +#define DEBUG
> > +
> > #define DBG(...)
> >
> > static int novmerge;
> > @@ -871,7 +873,7 @@ void iommu_free_coherent(struct iommu_table *tbl, s=
ize_t
> size,
> > }
> > }
> >
> > -#ifdef CONFIG_IOMMU_API
> > +#ifdef SPAPR_TCE_IOMMU
> > /*
> > * SPAPR TCE API
> > */
> > ----------------------
>=20
>=20
> And with this fix, what does "ls -laR /sys/kernel/iommu_groups/" print?
It shows the list of group id and respective devices:
root@p5040ds:~# ls -laR /sys/kernel/iommu_groups/
/sys/kernel/iommu_groups/:
total 0
drwxr-xr-x 15 root root 0 Sep 6 01:42 .
drwxr-xr-x 6 root root 0 Jan 1 1970 ..
drwxr-xr-x 3 root root 0 Sep 6 01:43 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 1
drwxr-xr-x 3 root root 0 Sep 6 01:43 10
drwxr-xr-x 3 root root 0 Sep 6 01:43 11
drwxr-xr-x 3 root root 0 Sep 6 01:43 12
drwxr-xr-x 3 root root 0 Sep 6 01:43 2
drwxr-xr-x 3 root root 0 Sep 6 01:43 3
drwxr-xr-x 3 root root 0 Sep 6 01:43 4
drwxr-xr-x 3 root root 0 Sep 6 01:43 5
drwxr-xr-x 3 root root 0 Sep 6 01:43 6
drwxr-xr-x 3 root root 0 Sep 6 01:43 7
drwxr-xr-x 3 root root 0 Sep 6 01:43 8
drwxr-xr-x 3 root root 0 Sep 6 01:43 9
/sys/kernel/iommu_groups/0:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/0/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe100300.dma -> ../../../../devices/=
ffe000000.soc/ffe100300.dma
/sys/kernel/iommu_groups/1:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/1/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe101300.dma -> ../../../../devices/=
ffe000000.soc/ffe101300.dma
/sys/kernel/iommu_groups/10:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/10/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe302000.jr -> ../../../../devices/f=
fe000000.soc/ffe300000.crypto/ffe302000.jr
/sys/kernel/iommu_groups/11:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/11/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe303000.jr -> ../../../../devices/f=
fe000000.soc/ffe300000.crypto/ffe303000.jr
/sys/kernel/iommu_groups/12:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/12/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe304000.jr -> ../../../../devices/f=
fe000000.soc/ffe300000.crypto/ffe304000.jr
/sys/kernel/iommu_groups/2:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/2/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe114000.sdhc -> ../../../../devices=
/ffe000000.soc/ffe114000.sdhc
/sys/kernel/iommu_groups/3:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/3/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe210000.usb -> ../../../../devices/=
ffe000000.soc/ffe210000.usb
/sys/kernel/iommu_groups/4:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/4/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe211000.usb -> ../../../../devices/=
ffe000000.soc/ffe211000.usb
/sys/kernel/iommu_groups/5:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/5/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe220000.sata -> ../../../../devices=
/ffe000000.soc/ffe220000.sata
/sys/kernel/iommu_groups/6:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/6/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe221000.sata -> ../../../../devices=
/ffe000000.soc/ffe221000.sata
/sys/kernel/iommu_groups/7:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/7/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 0001:00:00.0 -> ../../../../devices/f=
fe201000.pcie/pci0001:00/0001:00:00.0
lrwxrwxrwx 1 root root 0 Sep 6 01:43 0001:01:00.0 -> ../../../../devices/f=
fe201000.pcie/pci0001:00/0001:00:00.0/0001:01:00.0
/sys/kernel/iommu_groups/8:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/8/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe301000.jr -> ../../../../devices/f=
fe000000.soc/ffe300000.crypto/ffe301000.jr
/sys/kernel/iommu_groups/9:
total 0
drwxr-xr-x 3 root root 0 Sep 6 01:43 .
drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
/sys/kernel/iommu_groups/9/devices:
total 0
drwxr-xr-x 2 root root 0 Sep 6 01:43 .
drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
lrwxrwxrwx 1 root root 0 Sep 6 01:43 0000:00:00.0 -> ../../../../devices/f=
fe200000.pcie/pci0000:00/0000:00:00.0
lrwxrwxrwx 1 root root 0 Sep 6 01:43 0000:01:00.0 -> ../../../../devices/f=
fe200000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0
-Bharat
>=20
>=20
>=20
> --
> Alexey
^ permalink raw reply
* RE: Powerpc: Kernel warn_on when enabling IOMMU_API
From: Bhushan Bharat-R65777 @ 2013-08-12 16:52 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5208ED95.4090204@ozlabs.ru>
> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Monday, August 12, 2013 9:45 PM
> To: 'Alexey Kardashevskiy'
> Cc: benh@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Powerpc: Kernel warn_on when enabling IOMMU_API
>=20
>=20
>=20
> > -----Original Message-----
> > From: Alexey Kardashevskiy [mailto:aik@ozlabs.ru]
> > Sent: Monday, August 12, 2013 7:44 PM
> > To: Bhushan Bharat-R65777
> > Cc: benh@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: Powerpc: Kernel warn_on when enabling IOMMU_API
> >
> > On 08/12/2013 08:20 PM, Bhushan Bharat-R65777 wrote:
> > > And this simple fix work for me
> > > diff --git a/arch/powerpc/kernel/iommu.c
> > > b/arch/powerpc/kernel/iommu.c index b20ff17..8869b0d 100644
> > > --- a/arch/powerpc/kernel/iommu.c
> > > +++ b/arch/powerpc/kernel/iommu.c
> > > @@ -48,6 +48,8 @@
> > > #include <asm/vio.h>
> > > #include <asm/tce.h>
> > >
> > > +#define DEBUG
> > > +
> > > #define DBG(...)
> > >
> > > static int novmerge;
> > > @@ -871,7 +873,7 @@ void iommu_free_coherent(struct iommu_table
> > > *tbl, size_t
> > size,
> > > }
> > > }
> > >
> > > -#ifdef CONFIG_IOMMU_API
> > > +#ifdef SPAPR_TCE_IOMMU
> > > /*
> > > * SPAPR TCE API
> > > */
> > > ----------------------
> >
> >
> > And with this fix, what does "ls -laR /sys/kernel/iommu_groups/" print?
>=20
> It shows the list of group id and respective devices:
We uses the common iommu code to add a device with iommu_group (drivers/iom=
mu/iommu.c) using bus_set_iommu().
Also this have notifier to support hotplug-able device.
So when this initcall (in arch/powerpc/kernel/iommu.c) is called, iommu gro=
up is already setup.
So we do not this piece of code for powerpc. BTW why we need this with Powe=
r/TCE, does not the code in driver/iommu/iommu.c serve the purpose?
-Bharat
>=20
> root@p5040ds:~# ls -laR /sys/kernel/iommu_groups/
> /sys/kernel/iommu_groups/:
> total 0
> drwxr-xr-x 15 root root 0 Sep 6 01:42 .
> drwxr-xr-x 6 root root 0 Jan 1 1970 ..
> drwxr-xr-x 3 root root 0 Sep 6 01:43 0 drwxr-xr-x 3 root root 0 Sep 6=
01:43
> 1 drwxr-xr-x 3 root root 0 Sep 6 01:43 10 drwxr-xr-x 3 root root 0 Sep=
6
> 01:43 11 drwxr-xr-x 3 root root 0 Sep 6 01:43 12 drwxr-xr-x 3 root roo=
t 0 Sep
> 6 01:43 2 drwxr-xr-x 3 root root 0 Sep 6 01:43 3 drwxr-xr-x 3 root roo=
t 0 Sep
> 6 01:43 4 drwxr-xr-x 3 root root 0 Sep 6 01:43 5 drwxr-xr-x 3 root roo=
t 0 Sep
> 6 01:43 6 drwxr-xr-x 3 root root 0 Sep 6 01:43 7 drwxr-xr-x 3 root roo=
t 0 Sep
> 6 01:43 8 drwxr-xr-x 3 root root 0 Sep 6 01:43 9
>=20
> /sys/kernel/iommu_groups/0:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/0/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe100300.dma ->
> ../../../../devices/ffe000000.soc/ffe100300.dma
>=20
> /sys/kernel/iommu_groups/1:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/1/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe101300.dma ->
> ../../../../devices/ffe000000.soc/ffe101300.dma
>=20
> /sys/kernel/iommu_groups/10:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/10/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe302000.jr ->
> ../../../../devices/ffe000000.soc/ffe300000.crypto/ffe302000.jr
>=20
> /sys/kernel/iommu_groups/11:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/11/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe303000.jr ->
> ../../../../devices/ffe000000.soc/ffe300000.crypto/ffe303000.jr
>=20
> /sys/kernel/iommu_groups/12:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/12/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe304000.jr ->
> ../../../../devices/ffe000000.soc/ffe300000.crypto/ffe304000.jr
>=20
> /sys/kernel/iommu_groups/2:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/2/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe114000.sdhc ->
> ../../../../devices/ffe000000.soc/ffe114000.sdhc
>=20
> /sys/kernel/iommu_groups/3:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/3/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe210000.usb ->
> ../../../../devices/ffe000000.soc/ffe210000.usb
>=20
> /sys/kernel/iommu_groups/4:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/4/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe211000.usb ->
> ../../../../devices/ffe000000.soc/ffe211000.usb
>=20
> /sys/kernel/iommu_groups/5:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/5/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe220000.sata ->
> ../../../../devices/ffe000000.soc/ffe220000.sata
>=20
> /sys/kernel/iommu_groups/6:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/6/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe221000.sata ->
> ../../../../devices/ffe000000.soc/ffe221000.sata
>=20
> /sys/kernel/iommu_groups/7:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/7/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 0001:00:00.0 ->
> ../../../../devices/ffe201000.pcie/pci0001:00/0001:00:00.0
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 0001:01:00.0 ->
> ../../../../devices/ffe201000.pcie/pci0001:00/0001:00:00.0/0001:01:00.0
>=20
> /sys/kernel/iommu_groups/8:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/8/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 ffe301000.jr ->
> ../../../../devices/ffe000000.soc/ffe300000.crypto/ffe301000.jr
>=20
> /sys/kernel/iommu_groups/9:
> total 0
> drwxr-xr-x 3 root root 0 Sep 6 01:43 .
> drwxr-xr-x 15 root root 0 Sep 6 01:42 ..
> drwxr-xr-x 2 root root 0 Sep 6 01:43 devices
>=20
> /sys/kernel/iommu_groups/9/devices:
> total 0
> drwxr-xr-x 2 root root 0 Sep 6 01:43 .
> drwxr-xr-x 3 root root 0 Sep 6 01:43 ..
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 0000:00:00.0 ->
> ../../../../devices/ffe200000.pcie/pci0000:00/0000:00:00.0
> lrwxrwxrwx 1 root root 0 Sep 6 01:43 0000:01:00.0 ->
> ../../../../devices/ffe200000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0
>=20
> -Bharat
> >
> >
> >
> > --
> > Alexey
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-12 16:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Anatolij Gustschin, linuxppc-dev, David Hawkins
In-Reply-To: <1376274739.32100.149.camel@pasglop>
On Sun, Aug 11, 2013 at 7:32 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Do that help with e1000 as well ? IE. A bad clock might have caused
> malfunctions of the DMA for example...
No, it didn't help with the e1000. In fact, we have separate clocks
for the on-board components. This particular case was with our
expansion slot having a crappy clock buffer driving the PCI slot.
I'm still digging into the e1000 driver trying to find something. But
right now we are working on a replacement for the 82540 (which has
been EOL'd anyhow, so it needs to be done, we'd just prefer it be
later rather than sooner).
Thanks,
Pete
^ permalink raw reply
* RE: [PATCH 6/6 v3] kvm: powerpc: use caching attributes as per linux pte
From: Bhushan Bharat-R65777 @ 2013-08-12 17:14 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1376096685.15633.109.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAxMCwgMjAxMyA2OjM1IEFNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgYWdyYWZA
c3VzZS5kZTsgcGF1bHVzQHNhbWJhLm9yZzsNCj4ga3ZtQHZnZXIua2VybmVsLm9yZzsga3ZtLXBw
Y0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCA2LzYgdjNdIGt2bTogcG93
ZXJwYzogdXNlIGNhY2hpbmcgYXR0cmlidXRlcyBhcyBwZXIgbGludXgNCj4gcHRlDQo+IA0KPiBP
biBUdWUsIDIwMTMtMDgtMDYgYXQgMTc6MDEgKzA1MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0K
PiA+IEBAIC00NDksNyArNDQ2LDE2IEBAIHN0YXRpYyBpbmxpbmUgaW50IGt2bXBwY19lNTAwX3No
YWRvd19tYXAoc3RydWN0DQo+IGt2bXBwY192Y3B1X2U1MDAgKnZjcHVfZTUwMCwNCj4gPiAgCQln
dmFkZHIgJj0gfigodHNpemVfcGFnZXMgPDwgUEFHRV9TSElGVCkgLSAxKTsNCj4gPiAgCX0NCj4g
Pg0KPiA+IC0Ja3ZtcHBjX2U1MDBfcmVmX3NldHVwKHJlZiwgZ3RsYmUsIHBmbik7DQo+ID4gKwlw
Z2RpciA9IHZjcHVfZTUwMC0+dmNwdS5hcmNoLnBnZGlyOw0KPiA+ICsJcHRlcCA9IGxvb2t1cF9s
aW51eF9wdGUocGdkaXIsIGh2YSwgJnRzaXplX3BhZ2VzKTsNCj4gPiArCWlmIChwdGVfcHJlc2Vu
dCgqcHRlcCkpIHsNCj4gPiArCQl3aW1nID0gKHB0ZV92YWwoKnB0ZXApID4+IFBURV9XSU1HRV9T
SElGVCkgJiBNQVMyX1dJTUdFX01BU0s7DQo+ID4gKwl9IGVsc2Ugew0KPiA+ICsJCXByaW50ayhL
RVJOX0VSUiAicHRlIG5vdCBwcmVzZW50OiBnZm4gJWx4LCBwZm4gJWx4XG4iLA0KPiA+ICsJCQkJ
KGxvbmcpZ2ZuLCBwZm4pOw0KPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiANCj4gRG9uJ3QgbGV0
IHRoZSBndWVzdCBzcGFtIHRoZSBob3N0IGtlcm5lbCBjb25zb2xlIGJ5IHJlcGVhdGVkbHkgYWNj
ZXNzaW5nIGJhZA0KPiBtYXBwaW5ncyAoZXZlbiBpZiBpdCByZXF1aXJlcyBob3N0IHVzZXJzcGFj
ZSB0byBhc3Npc3QgYnkgcG9pbnRpbmcgYSBtZW1zbG90IGF0DQo+IGEgYmFkIGh2YSkuICBUaGlz
IHNob3VsZCBhdCBtb3N0IGJlIHByaW50a19yYXRlbGltaXRlZCgpLCBhbmQgcHJvYmFibHkganVz
dA0KPiBwcl9kZWJ1ZygpLiAgSXQgc2hvdWxkIGFsc28gaGF2ZSBfX2Z1bmNfXyBjb250ZXh0Lg0K
DQpWZXJ5IGdvb2QgcG9pbnQsIEkgd2lsbCBtYWtlIHRoaXMgcHJpbnRrX3JhdGVsaW1pdGVkKCkg
aW4gdGhpcyBwYXRjaC4gQW5kIGNvbnZlcnQgdGhpcyBhbmQgb3RoZXIgZXJyb3IgcHJpbnRzIHRv
IHByX2RlYnVnKCkgd2hlbiB3ZSB3aWxsIHNlbmQgbWFjaGluZSBjaGVjayBvbiBlcnJvciBpbiB0
aGlzIGZsb3cuDQoNCj4gDQo+IEFsc28sIEkgZG9uJ3Qgc2VlIHRoZSByZXR1cm4gdmFsdWUgZ2V0
dGluZyBjaGVja2VkICh0aGUgaW1tZWRpYXRlIGNhbGxlcnMgY2hlY2sNCj4gaXQgYW5kIHByb3Bv
Z2F0ZSB0aGUgZXJyb3IsIGJ1dCBrdm1wcGNfbW11X21hcCgpIGRvZXNuJ3QpLg0KPiBXZSB3YW50
IHRvIHNlbmQgYSBtYWNoaW5lIGNoZWNrIHRvIHRoZSBndWVzdCBpZiB0aGlzIGhhcHBlbnMgKG9y
IHBvc3NpYmx5IGV4aXQNCj4gdG8gdXNlcnNwYWNlIHNpbmNlIGl0IGluZGljYXRlcyBhIGJhZCBt
ZW1zbG90LCBub3QganVzdCBhIGd1ZXN0IGJ1ZykuICBXZSBkb24ndA0KPiB3YW50IHRvIGp1c3Qg
c2lsZW50bHkgcmV0cnkgb3ZlciBhbmQgb3Zlci4NCg0KSSBjb21wbGV0ZWx5IGFncmVlIHdpdGgg
eW91LCBidXQgdGhpcyB3YXMgc29tZXRoaW5nIGFscmVhZHkgbWlzc2luZyAoZXJyb3IgcmV0dXJu
IGJ5IHRoaXMgZnVuY3Rpb24gaXMgbm90aGluZyBuZXcgYWRkZWQgaW4gdGhpcyBwYXRjaCksIFNv
IEkgd291bGQgbGlrZSB0byB0YWtlIHRoYXQgc2VwYXJhdGVseS4NCg0KPiANCj4gT3RoZXJ3aXNl
LCB0aGlzIHNlcmllcyBsb29rcyBnb29kIHRvIG1lLg0KDQpUaGFuayB5b3UuIDopDQotQmhhcmF0
DQoNCj4gDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 4/8] net: fs_enet: use platform_{get,set}_drvdata()
From: Sergei Shtylyov @ 2013-08-12 18:16 UTC (permalink / raw)
To: Libo Chen; +Cc: netdev, LKML, Li Zefan, vbordug, linuxppc-dev, David Miller
In-Reply-To: <5208E222.60300@huawei.com>
On 08/12/2013 05:24 PM, Libo Chen wrote:
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
> Signed-off-by: Libo Chen <libo.chen@huawei.com>
> ---
> .../net/ethernet/freescale/fs_enet/fs_enet-main.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> index 8de53a1..7e3de10 100644
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -1122,7 +1122,6 @@ static int fs_enet_remove(struct platform_device *ofdev)
>
> fep->ops->free_bd(ndev);
> fep->ops->cleanup_data(ndev);
> - dev_set_drvdata(fep->dev, NULL);
> of_node_put(fep->fpi->phy_node);
> free_netdev(ndev);
> return 0;
Changelog simply doesn't match the patch.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v4 02/31] serial: mpc512x: cleanup clock API use
From: Greg Kroah-Hartman @ 2013-08-12 18:27 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Rob Herring, Mark Brown, Marc Kleine-Budde,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <1375821851-31609-3-git-send-email-gsi@denx.de>
On Tue, Aug 06, 2013 at 10:43:42PM +0200, Gerhard Sittig wrote:
> cleanup the clock API use of the UART driver which is shared among the
> MPC512x and the MPC5200 platforms
> - get, prepare, and enable the MCLK during port allocation; disable,
> unprepare and put the MCLK upon port release; hold a reference to the
> clock over the period of use; check for and propagate enable errors
> - fix a buffer overflow for clock names with two digit PSC index numbers
> - stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
> switch to a fixed string later after device tree based clock lookup
> will have become available
>
> to achieve support for MPC512x which is neutral to MPC5200, the
> modification was done as follows
> - introduce "clock alloc" and "clock release" routines in addition to
> the previous "clock enable/disable" routine in the psc_ops struct
> - make the clock allocation a part of the port request (resource
> allocation), and make clock release a part of the port release, such
> that essential resources get allocated early
> - just enable/disable the clock from within the .clock() callback
> without any allocation or preparation as the former implementation
> did, since this routine is called from within the startup and shutdown
> callbacks
> - all of the above remains a NOP for the MPC5200 platform (no callbacks
> are provided on that platform)
> - implementation note: the clock gets enabled upon allocation already
> just in case the clock is not only required for bitrate generation but
> for register access as well
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v4 21/31] serial: mpc512x: switch to CCF names in clock lookup
From: Greg Kroah-Hartman @ 2013-08-12 18:27 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Rob Herring, Mark Brown, Marc Kleine-Budde,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <1375821851-31609-22-git-send-email-gsi@denx.de>
On Tue, Aug 06, 2013 at 10:44:01PM +0200, Gerhard Sittig wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the PSC index,
> remove the "psc%d_mclk" template and unconditionally use 'mclk'
>
> acquire and release the 'ipg' clock for register access as well
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v4 23/31] serial: mpc512x: setup the PSC FIFO clock as well
From: Greg Kroah-Hartman @ 2013-08-12 18:27 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Rob Herring, Mark Brown, Marc Kleine-Budde,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <1375821851-31609-24-git-send-email-gsi@denx.de>
On Tue, Aug 06, 2013 at 10:44:03PM +0200, Gerhard Sittig wrote:
> prepare and enable the FIFO clock upon PSC FIFO initialization,
> check for and propagage errors when enabling the PSC FIFO clock,
> disable and unprepare the FIFO clock upon PSC FIFO uninitialization,
> remove the pre-enable workaround from the platform's clock driver
>
> devm_{get,put}_clk() doesn't apply here, as the SoC provides a
> single FIFO component which is shared among several PSC components,
> thus the FIFO isn't associated with a device (while the PSCs are)
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] tile: various console improvements
From: Greg Kroah-Hartman @ 2013-08-12 18:39 UTC (permalink / raw)
To: Chris Metcalf; +Cc: Jiri Slaby, linuxppc-dev, linux-kernel
In-Reply-To: <201308071458.r77EwWuV013082@farm-0012.internal.tilera.com>
On Tue, Aug 06, 2013 at 02:11:21PM -0400, Chris Metcalf wrote:
> This change improves and cleans up the tile console.
>
> - We enable HVC_IRQ support on tilegx, with the addition of a new
> Tilera hypervisor API for tilegx to allow a console IPI. If IPI
> support is not available we fall back to the previous polling mode.
>
> - We simplify the earlyprintk code to use CON_BOOT and eliminate some
> of the other supporting earlyprintk code.
>
> - A new tile_console_write() primitive is used to send output to
> the console and is factored out of the hvc_tile driver.
> This lets us support a "sim_console" boot argument to allow using
> simulator hooks to send output to the "console" as a slightly
> faster alternative to emulating the hardware more directly.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Stephen N Chivers @ 2013-08-12 21:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: paulus, linuxppc-dev, Chris Proctor
In-Reply-To: <B7B7FD2F-8272-487C-B946-154107EF7C09@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote on 08/09/2013 01:30:53 AM:
> From: Kumar Gala <galak@kernel.crashing.org>
> To: Stephen N Chivers <schivers@csc.com.au>
> Cc: benh@kernel.crashing.org, paulus@samba.org, Chris Proctor
> <cproctor@csc.com.au>, linuxppc-dev@lists.ozlabs.org
> Date: 08/09/2013 01:31 AM
> Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
>
>
> On Aug 7, 2013, at 7:03 PM, Stephen N Chivers wrote:
>
> > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> >
> > The MVME5100 is a 6U form factor VME64 computer with:
> >
> > - A single MPC7410 or MPC750 CPU
> > - A HAWK Processor Host Bridge (CPU to PCI) and
> > MultiProcessor Interrupt Controller (MPIC)
> > - Up to 500Mb of onboard memory
> > - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> > - Two 16550 compatible UARTS
> > - Two Intel E100 Fast Ethernets
> > - Two PCI Mezzanine Card (PMC) Slots
> > - PPCBug Firmware
> >
> > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> >
> > There is no onboard disk support. This is usually provided by
installing a
> > PMC
> > in first PMC slot.
> >
> > This patch revives the board support, it was present in early 2.6
> > series kernels. The board support in those days was by Matt Porter of
> > MontaVista Software.
> >
> > CSC Australia has around 31 of these boards in service. The kernel in
use
> > for the boards is based on 2.6.31. The boards are operated without
disks
> > from a file server.
> >
> > This patch is based on linux-3.11-rc4 and has been boot tested.
> >
> > Signed-off-by: Stephen Chivers <schivers@csc.com>
> > ---
> > arch/powerpc/boot/dts/mvme5100.dts | 195 ++
> > arch/powerpc/boot/mvme5100.c | 28 +
> > arch/powerpc/configs/mvme5100_defconfig | 2597
> > +++++++++++++++++++++++++
> > arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++
> > 4 files changed, 3108 insertions(+), 0 deletions(-)
>
> Please look at fixing the white space issues you seem to have
> throughout this patch.
The mailing agent is Lotus Notes. It is pathologically against tabs. I did
make best effort to ensure that tabs would not get crunched but sadly this
has failed.
>
> Also, we don't take full defconfigs in the tree, look at 'make
savedefconfig'
Ok.
>
> - k
>
^ permalink raw reply
* Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
From: Benjamin Herrenschmidt @ 2013-08-12 21:13 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-mm, linuxppc-dev
In-Reply-To: <5208DCBC.7060205@linux.vnet.ibm.com>
On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> > Can you tell me a bit more, the above makes me nervous...
>
> Ok, I agree. that message isn't quite right.
>
> What I wanted to convey is that memory hotplug is not fully supported
> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the message should read
> "Memory hotplug is not fully supported for bootmem info nodes".
>
> Thoughts?
Since SPARSE_VMEMMAP is our default and enabled in our distros, that mean
that memory hotplug isn't fully supported for us in general ?
What do you mean by "not fully supported" ? What precisely is missing ?
What will happen if one tries to plug or unplug memory?
Shouldn't we fix it ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
From: Nathan Fontenot @ 2013-08-12 21:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-mm, linuxppc-dev
In-Reply-To: <1376341985.32100.174.camel@pasglop>
On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
>>> Can you tell me a bit more, the above makes me nervous...
>>
>> Ok, I agree. that message isn't quite right.
>>
>> What I wanted to convey is that memory hotplug is not fully supported
>> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the message should read
>> "Memory hotplug is not fully supported for bootmem info nodes".
>>
>> Thoughts?
>
> Since SPARSE_VMEMMAP is our default and enabled in our distros, that mean
> that memory hotplug isn't fully supported for us in general ?
Actually... We have had the distros (at least SLES 11 and RHEL 6 releases)
disable SPARSE_VMEMMAP in their releases.
>
> What do you mean by "not fully supported" ? What precisely is missing ?
> What will happen if one tries to plug or unplug memory?
I don't know everything that is missing, but there are several routines
that need to be defined for power to support memory hotplug with SPARSE_VMEMMAP.
>
> Shouldn't we fix it ?
Working on it, but it's not there yet.
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: powerpc: Mark low level irq handlers NO_THREAD
From: Benjamin Herrenschmidt @ 2013-08-12 21:31 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Marcelo Tosatti, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1376318939-14447-1-git-send-email-bigeasy@linutronix.de>
On Mon, 2013-08-12 at 16:48 +0200, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> These low level handlers cannot be threaded. Mark them NO_THREAD
>
> Reported-by: leroy christophe <christophe.leroy@c-s.fr>
> Tested-by: leroy christophe <christophe.leroy@c-s.fr>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>
> This patch has been posted on Feb 13, 2013 and nobody responded back then.
And it was merged in 3.11 no ? :-)
Cheers,
Ben.
> arch/powerpc/platforms/8xx/m8xx_setup.c | 1 +
> arch/powerpc/sysdev/cpm1.c | 1 +
> 2 files changed, 2 insertions(+)
>
> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> @@ -43,6 +43,7 @@ static irqreturn_t timebase_interrupt(in
>
> static struct irqaction tbint_irqaction = {
> .handler = timebase_interrupt,
> + .flags = IRQF_NO_THREAD,
> .name = "tbint",
> };
>
> --- a/arch/powerpc/sysdev/cpm1.c
> +++ b/arch/powerpc/sysdev/cpm1.c
> @@ -120,6 +120,7 @@ static irqreturn_t cpm_error_interrupt(i
>
> static struct irqaction cpm_error_irqaction = {
> .handler = cpm_error_interrupt,
> + .flags = IRQF_NO_THREAD,
> .name = "error",
> };
>
^ permalink raw reply
* [PATCH] crypto: nx - fix concurrency issue
From: Marcelo Cerri @ 2013-08-12 21:49 UTC (permalink / raw)
To: herbert; +Cc: Marcelo Cerri, linuxppc-dev, linux-kernel, linux-crypto
The NX driver uses the transformation context to store several fields
containing data related to the state of the operations in progress.
Since a single tfm can be used by different kernel threads at the same
time, we need to protect the data stored into the context.
This patch makes use of spin locks to protect the data where a race
condition can happen.
Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Reviewed-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx-aes-cbc.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-ccm.c | 20 ++++++++++++++++----
drivers/crypto/nx/nx-aes-ctr.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-ecb.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-gcm.c | 4 ++++
drivers/crypto/nx/nx-aes-xcbc.c | 8 ++++++++
drivers/crypto/nx/nx-sha256.c | 16 ++++++++++++++++
drivers/crypto/nx/nx-sha512.c | 16 ++++++++++++++++
drivers/crypto/nx/nx.c | 4 ++--
drivers/crypto/nx/nx.h | 1 +
10 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 6d90808..9310982 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -70,10 +70,15 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
@@ -101,6 +106,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index ef5eae6..39d4224 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -271,10 +271,15 @@ static int ccm_nx_decrypt(struct aead_request *req,
unsigned int nbytes = req->cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
struct nx_ccm_priv *priv = &nx_ctx->priv.ccm;
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
nbytes -= authsize;
@@ -308,6 +313,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
rc = memcmp(csbcpb->cpb.aes_ccm.out_pat_or_mac, priv->oauth_tag,
authsize) ? -EBADMSG : 0;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -318,10 +324,15 @@ static int ccm_nx_encrypt(struct aead_request *req,
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
unsigned int nbytes = req->cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes,
csbcpb->cpb.aes_ccm.in_pat_or_b0);
@@ -350,6 +361,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
req->dst, nbytes, authsize,
SCATTERWALK_TO_SG);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index b6286f1..762611b 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -88,10 +88,15 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes,
csbcpb->cpb.aes_ctr.iv);
@@ -112,6 +117,7 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index 7bbc9a8..77dbe08 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -70,10 +70,15 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
@@ -98,6 +103,7 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index 6cca6c3..df90d03 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -166,8 +166,11 @@ static int gcm_aes_nx_crypt(struct aead_request *req, int enc)
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct blkcipher_desc desc;
unsigned int nbytes = req->cryptlen;
+ unsigned long irq_flags;
int rc = -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (nbytes > nx_ctx->ap->databytelen)
goto out;
@@ -255,6 +258,7 @@ static int gcm_aes_nx_crypt(struct aead_request *req, int enc)
-EBADMSG : 0;
}
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-xcbc.c b/drivers/crypto/nx/nx-aes-xcbc.c
index 93923e4..658da0f 100644
--- a/drivers/crypto/nx/nx-aes-xcbc.c
+++ b/drivers/crypto/nx/nx-aes-xcbc.c
@@ -89,8 +89,11 @@ static int nx_xcbc_update(struct shash_desc *desc,
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct nx_sg *in_sg;
u32 to_process, leftover;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously and we're updating again,
* so copy over the partial digest */
@@ -158,6 +161,7 @@ static int nx_xcbc_update(struct shash_desc *desc,
/* everything after the first update is continuation */
NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -167,8 +171,11 @@ static int nx_xcbc_final(struct shash_desc *desc, u8 *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously, now we're finalizing,
* so copy over the partial digest */
@@ -211,6 +218,7 @@ static int nx_xcbc_final(struct shash_desc *desc, u8 *out)
memcpy(out, csbcpb->cpb.aes_xcbc.out_cv_mac, AES_BLOCK_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-sha256.c b/drivers/crypto/nx/nx-sha256.c
index 254b01a..6547a71 100644
--- a/drivers/crypto/nx/nx-sha256.c
+++ b/drivers/crypto/nx/nx-sha256.c
@@ -57,8 +57,11 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data,
struct nx_sg *in_sg;
u64 to_process, leftover, total;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
/* 2 cases for total data len:
* 1: < SHA256_BLOCK_SIZE: copy into state, return 0
* 2: >= SHA256_BLOCK_SIZE: process X blocks, copy in leftover
@@ -136,6 +139,7 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data,
memcpy(sctx->buf, data, leftover);
sctx->count = leftover;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -146,8 +150,11 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
@@ -186,6 +193,7 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
&(nx_ctx->stats->sha256_bytes));
memcpy(out, csbcpb->cpb.sha256.message_digest, SHA256_DIGEST_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -195,6 +203,9 @@ static int nx_sha256_export(struct shash_desc *desc, void *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct sha256_state *octx = out;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
octx->count = sctx->count +
(csbcpb->cpb.sha256.message_bit_length / 8);
@@ -217,6 +228,7 @@ static int nx_sha256_export(struct shash_desc *desc, void *out)
octx->state[7] = SHA256_H7;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
@@ -226,6 +238,9 @@ static int nx_sha256_import(struct shash_desc *desc, const void *in)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
const struct sha256_state *ictx = in;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
memcpy(sctx->buf, ictx->buf, sizeof(ictx->buf));
@@ -240,6 +255,7 @@ static int nx_sha256_import(struct shash_desc *desc, const void *in)
NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
diff --git a/drivers/crypto/nx/nx-sha512.c b/drivers/crypto/nx/nx-sha512.c
index 2d6d913..236e6af 100644
--- a/drivers/crypto/nx/nx-sha512.c
+++ b/drivers/crypto/nx/nx-sha512.c
@@ -57,8 +57,11 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data,
struct nx_sg *in_sg;
u64 to_process, leftover, total, spbc_bits;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
/* 2 cases for total data len:
* 1: < SHA512_BLOCK_SIZE: copy into state, return 0
* 2: >= SHA512_BLOCK_SIZE: process X blocks, copy in leftover
@@ -138,6 +141,7 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data,
memcpy(sctx->buf, data, leftover);
sctx->count[0] = leftover;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -149,8 +153,11 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
struct nx_sg *in_sg, *out_sg;
u32 max_sg_len;
u64 count0;
+ unsigned long irq_flags;
int rc;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
@@ -193,6 +200,7 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
memcpy(out, csbcpb->cpb.sha512.message_digest, SHA512_DIGEST_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -202,6 +210,9 @@ static int nx_sha512_export(struct shash_desc *desc, void *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct sha512_state *octx = out;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
/* move message_bit_length (128 bits) into count and convert its value
* to bytes */
@@ -233,6 +244,7 @@ static int nx_sha512_export(struct shash_desc *desc, void *out)
octx->state[7] = SHA512_H7;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
@@ -242,6 +254,9 @@ static int nx_sha512_import(struct shash_desc *desc, const void *in)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
const struct sha512_state *ictx = in;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
memcpy(sctx->buf, ictx->buf, sizeof(ictx->buf));
sctx->count[0] = ictx->count[0] & 0x3f;
@@ -259,6 +274,7 @@ static int nx_sha512_import(struct shash_desc *desc, const void *in)
NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index ad07dc6..bdf4990 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -61,8 +61,7 @@ int nx_hcall_sync(struct nx_crypto_ctx *nx_ctx,
do {
rc = vio_h_cop_sync(viodev, op);
- } while ((rc == -EBUSY && !may_sleep && retries--) ||
- (rc == -EBUSY && may_sleep && cond_resched()));
+ } while (rc == -EBUSY && !may_sleep && retries--);
if (rc) {
dev_dbg(&viodev->dev, "vio_h_cop_sync failed: rc: %d "
@@ -251,6 +250,7 @@ int nx_build_sg_lists(struct nx_crypto_ctx *nx_ctx,
*/
void nx_ctx_init(struct nx_crypto_ctx *nx_ctx, unsigned int function)
{
+ spin_lock_init(&nx_ctx->lock);
memset(nx_ctx->kmem, 0, nx_ctx->kmem_len);
nx_ctx->csbcpb->csb.valid |= NX_CSB_VALID_BIT;
diff --git a/drivers/crypto/nx/nx.h b/drivers/crypto/nx/nx.h
index 3232b18..14bb97f 100644
--- a/drivers/crypto/nx/nx.h
+++ b/drivers/crypto/nx/nx.h
@@ -117,6 +117,7 @@ struct nx_ctr_priv {
};
struct nx_crypto_ctx {
+ spinlock_t lock; /* synchronize access to the context */
void *kmem; /* unaligned, kmalloc'd buffer */
size_t kmem_len; /* length of kmem */
struct nx_csbcpb *csbcpb; /* aligned page given to phyp @ hcall time */
--
1.7.12
^ permalink raw reply related
* Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
From: Benjamin Herrenschmidt @ 2013-08-12 21:59 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-mm, linuxppc-dev
In-Reply-To: <520952C9.3060101@linux.vnet.ibm.com>
On Mon, 2013-08-12 at 16:25 -0500, Nathan Fontenot wrote:
> On 08/12/2013 04:13 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-12 at 08:01 -0500, Nathan Fontenot wrote:
> >>> Can you tell me a bit more, the above makes me nervous...
> >>
> >> Ok, I agree. that message isn't quite right.
> >>
> >> What I wanted to convey is that memory hotplug is not fully supported
> >> on powerpc with SPARSE_VMEMMAP enabled.. Perhaps the message should read
> >> "Memory hotplug is not fully supported for bootmem info nodes".
> >>
> >> Thoughts?
> >
> > Since SPARSE_VMEMMAP is our default and enabled in our distros, that mean
> > that memory hotplug isn't fully supported for us in general ?
>
> Actually... We have had the distros (at least SLES 11 and RHEL 6 releases)
> disable SPARSE_VMEMMAP in their releases.
Yuck ! That has a significant impact on performances... Additionally our
VFIO implementation for KVM requires SPARSE_VMEMMAP. Why is it that this
was never fixed in all these years ?
> >
> > What do you mean by "not fully supported" ? What precisely is missing ?
> > What will happen if one tries to plug or unplug memory?
>
> I don't know everything that is missing, but there are several routines
> that need to be defined for power to support memory hotplug with SPARSE_VMEMMAP.
>
> >
> > Shouldn't we fix it ?
>
> Working on it, but it's not there yet.
Ok, thanks.
Cheers,
Ben.
> >
> > Cheers,
> > Ben.
> >
> >
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
From: Stephen N Chivers @ 2013-08-12 21:57 UTC (permalink / raw)
To: Scott Wood; +Cc: Chris Proctor, linuxppc-dev, paulus, Stephen N Chivers
In-Reply-To: <1375985244.4514.21.camel@snotra.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 08/09/2013 04:07:24 AM:
> From: Scott Wood <scottwood@freescale.com>
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: Stephen N Chivers <schivers@csc.com.au>, <paulus@samba.org>,
> <linuxppc-dev@lists.ozlabs.org>, Chris Proctor <cproctor@csc.com.au>
> Date: 08/09/2013 04:08 AM
> Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
>
> On Thu, 2013-08-08 at 10:30 -0500, Kumar Gala wrote:
> > On Aug 7, 2013, at 7:03 PM, Stephen N Chivers wrote:
> >
> > > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> > >
> > > The MVME5100 is a 6U form factor VME64 computer with:
> > >
> > > - A single MPC7410 or MPC750 CPU
> > > - A HAWK Processor Host Bridge (CPU to PCI) and
> > > MultiProcessor Interrupt Controller (MPIC)
> > > - Up to 500Mb of onboard memory
> > > - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> > > - Two 16550 compatible UARTS
> > > - Two Intel E100 Fast Ethernets
> > > - Two PCI Mezzanine Card (PMC) Slots
> > > - PPCBug Firmware
> > >
> > > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> > >
> > > There is no onboard disk support. This is usually provided by
> installing a
> > > PMC
> > > in first PMC slot.
> > >
> > > This patch revives the board support, it was present in early 2.6
> > > series kernels. The board support in those days was by Matt Porter
of
> > > MontaVista Software.
> > >
> > > CSC Australia has around 31 of these boards in service. The kernel
in use
> > > for the boards is based on 2.6.31. The boards are operated without
disks
> > > from a file server.
> > >
> > > This patch is based on linux-3.11-rc4 and has been boot tested.
> > >
> > > Signed-off-by: Stephen Chivers <schivers@csc.com>
> > > ---
> > > arch/powerpc/boot/dts/mvme5100.dts | 195 ++
> > > arch/powerpc/boot/mvme5100.c | 28 +
> > > arch/powerpc/configs/mvme5100_defconfig | 2597
> > > +++++++++++++++++++++++++
> > > arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++
> > > 4 files changed, 3108 insertions(+), 0 deletions(-)
> >
> > Please look at fixing the white space issues you seem to have
> throughout this patch.
> >
> > Also, we don't take full defconfigs in the tree, look at 'make
> savedefconfig'
>
> Why does this board need its own defconfig at all? Just add it to
> ppc6xx_defconfig.
The boards firmware as stated above is PPCBug. PPCBug is not Open Firmware
compatible.
There is no U-Boot support for the board.
In ppc6xx_defconfig the e100 network device and NFS support is modular and
that forces the use of an initrd.
PPCBugs network boot command takes only one file argument and so makes
it difficult to use an initrd.
So the choices are:
- Providing a defconfig for the board,
- Building the kernel with the initrd embedded in it,
- Finding an alternative boot loader,
- Doing the board support for U-Boot.
The first choice is simple and documents the configuration of the
board without mixing it into ppc6xx_defconfig.
The second choice would, I believe, fail for ppc6xx_defconfig when built
by the automaton at "kisskb". The failure would be caused by the lack of
a ramdisk in the vanilla kernel source.
For the third, I spent a lot of time over the weekend looking for an
alternative boot loader to no avail.
The last choice is possibly difficult and would take considerable time.
Other possibilities include:
- a boot script for PPCBug that loads the initrd first and
then executes the network boot command. I believe that the
initrd start and size can be specified in the dts file.
- porting the "tftplilo" program used with the ancient
MVME-167 68k SBCs. This is probably feasible as PPCBug is
a descendant of the older 167Bug. tftplilo uses the network
routines in 167Bug to do its work and similar things exist
in PPCBug.
Suggestions please.
>
> -Scott
>
>
>
Stephen Chivers.
^ 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