* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-04-01 7:36 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <20090331155443.GA28242@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
> [...]
>>>>>>> + soc8544@e0000000 {
>>>>>>> + #address-cells = <1>;
>>>>>>> + #size-cells = <1>;
>>>>>>> + device_type = "soc";
>>>>>> Drop device_type here too.
>>>>> Grrr, I just realized that removing the devices type "soc" has broken
>>>>> fsl_get_sys_freq(). See:
>>>>>
>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>
>>>>> We need a quick fix and we could take the occasion to establish a common
>>>>> function for the MPC52xx as well, but it's not obvious to me how to find
>>>>> the SOC node without the device type property.
>>>> SoC node should have a compatible property, just like everything else.
>>>>
>>>> compatible = "fsl,mpc8544-immr"; (immr == Internally Memory Mapped Registers)
>>>>
>>>> Many other boards already do this.
>>> Yes, it does, but searching for the SOC node is not straight-forward
>>> because there is no common compatibility string but many CPU-specific
>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I missed
>>> something?
>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly what it
>> means, and add add it to the end of the compatible list.
>
> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
> parts. There it's called CCSR.
>
> See this thread:
>
> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>
> I still think that
> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
> and
> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>
> would be OK, at least to start with. We can always deprecate "fsl,soc"
> compatible in favour of something more elegant, but "fsl,soc" should be
> just fine to replace device_type = "soc".
>
> Also, there is another good thing about "fsl,soc" -- U-Boot already
> finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type "soc". It
will break compatibility with U-Boot for many boards. Is it worth it?
Wolfgang.
^ permalink raw reply
* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: Wolfgang Grandegger @ 2009-04-01 7:31 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev, devicetree-discuss
In-Reply-To: <20090331230451.GA23304@yookeroo.seuss>
Hi David,
this patch went out by mistake, sorry.
David Gibson wrote:
> On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
>> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
>> ===================================================================
>> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
>> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
>> @@ -52,6 +52,7 @@
>> soc8544@e0000000 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> + device_type = "soc";
>
> You should not be adding device_type to a new board's dts. You
> *especially* shouldn't be doing that with no patch comment explaining
> why.
In the final patch I have removed the device_type = "soc", but it makes
trouble as some mpc85xx rely on it. Removing it would also break U-Boot
compatibility. Is it worth that? The issue is discussed on the thread
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070020.html.
Wolfgang.
^ permalink raw reply
* Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
From: Sachin Sant @ 2009-04-01 6:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1238539469.17330.70.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote:
>
>> While executing CPU HotPlug[1] tests i observed that during
>> every cpu offline process an exception is thrown.
>>
>
> Looks like a BUG_ON() to me... can you look at what other
> messages just before that ?
>
I don't get any other messages when the problem occurs. Infact
if i don't have xmon enabled the machine just hangs without
any messages on the console. I extracted the dmesg log
(attached in my previous mail) through xmon. Here are last few
related messages from 2.6.29-git8 kernel during problem recreation.
<4>IRQ 18 affinity broken off cpu 2
<4>cpu 2 (hwid 2) Ready to die....
<7>CPU0 attaching NULL sched-domain..
<7>CPU1 attaching NULL sched-domain..
<7>CPU2 attaching NULL sched-domain..
<7>CPU3 attaching NULL sched-domain..
<7>CPU0 attaching sched-domain:.
<7> domain 0: span 0-1 level SIBLING.
<7> groups: 0 1.
<7> domain 1: span 0-1,3 level CPU.
<7> groups: 0-1 3.
<7> domain 2: span 0-1,3 level NODE
<7> groups: 0-1,3.
<7>CPU1 attaching sched-domain:.
<7> domain 0: span 0-1 level SIBLING.
<7> groups: 1 0.
<7> domain 1: span 0-1,3 level CPU.
<7> groups: 0-1 3.
<7> domain 2: span 0-1,3 level NODE.
<7> groups: 0-1,3.
<7>CPU3 attaching sched-domain:.
<7> domain 0: span 0-1,3 level CPU.
<7> groups: 3 0-1.
<7> domain 1: span 0-1,3 level NODE.
<7> groups: 0-1,3...
> That or lookup where the PC and LR values are in System.map
> and maybe get us a backtrace from xmon ?
>
> (You seem to have no symbols, have you built with kallsyms ?)
I have kallsyms and debug info options enabled.
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_DEBUG_INFO=y
Here is the related information from 2.6.29-git8 kernel.
llm62 login: cpu 0x2: Vector: 700 (Program Check) at [c0000000074c7ca0]
pc: 00000000007b6640
lr: 000000000079ddc0
sp: c0000000074c7f20
msr: 8000000000081002
current = 0xc0000000fe1c8580
paca = 0xc000000000ab2800
pid = 0, comm = swapper
enter ? for help
[c0000000074c7f20] 0000000000018694 (unreliable)
[c0000000074c7f90] 0000000000008278
SP (4f00000003) is in userspace
2:mon> la %pc
00000000007b6640
2:mon> la c0000000007b6640
c0000000007b6640: .kmem_cache_init+0x2d8/0x528
2:mon> la %lr
000000000079ddc0
2:mon> la c00000000079ddc0
c00000000079ddc0: .mem_init+0x150/0x22c
2:mon>
Regards
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH 3/3] net/fec_mpc52xx: Don't dereference phy_device if it is NULL
From: Grant Likely @ 2009-04-01 6:17 UTC (permalink / raw)
To: netdev, linuxppc-dev, David Miller
In-Reply-To: <20090401060117.8641.32252.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
The FEC Ethernet device isn't always attached to a phy. Be careful
not to dereference phy_device if it is NULL. Also eliminates an
unnecessary extra function from the ioctl path.
Reported-by: Henk Stegeman <henk.stegeman@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fec_mpc52xx.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index e4355d4..8bbe7f6 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -271,15 +271,6 @@ static void mpc52xx_fec_phy_stop(struct net_device *dev)
phy_write(priv->phydev, MII_BMCR, BMCR_PDOWN);
}
-static int mpc52xx_fec_phy_mii_ioctl(struct mpc52xx_fec_priv *priv,
- struct mii_ioctl_data *mii_data, int cmd)
-{
- if (!priv->phydev)
- return -ENOTSUPP;
-
- return phy_mii_ioctl(priv->phydev, mii_data, cmd);
-}
-
static void mpc52xx_fec_phy_hw_init(struct mpc52xx_fec_priv *priv)
{
struct mpc52xx_fec __iomem *fec = priv->fec;
@@ -852,12 +843,20 @@ static void mpc52xx_fec_get_drvinfo(struct net_device *dev,
static int mpc52xx_fec_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(priv->phydev, cmd);
}
static int mpc52xx_fec_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ if (!priv->phydev)
+ return -ENODEV;
+
return phy_ethtool_sset(priv->phydev, cmd);
}
@@ -887,7 +886,10 @@ static int mpc52xx_fec_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
- return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
+ if (!priv->phydev)
+ return -ENOTSUPP;
+
+ return phy_mii_ioctl(priv->phydev, if_mii(rq), cmd);
}
static const struct net_device_ops mpc52xx_fec_netdev_ops = {
^ permalink raw reply related
* [PATCH 2/3] net/fec_mpc52xx: Migrate to net_device_ops.
From: Grant Likely @ 2009-04-01 6:16 UTC (permalink / raw)
To: netdev, linuxppc-dev, David Miller
In-Reply-To: <20090401060117.8641.32252.stgit@localhost.localdomain>
From: Henk Stegeman <henk.stegeman@gmail.com>
Since not using net_device_ops gets you shunned out the cool crowd,
this patch modifies the fec_mpc52xx Ethernet driver to provide the
management hooks via a struct net_device_ops.
Reported-by: Henk Stegeman <henk.stegeman@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fec_mpc52xx.c | 36 ++++++++++++++++++++----------------
1 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index f99463f..e4355d4 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -371,7 +371,7 @@ static int mpc52xx_fec_close(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct bcom_fec_bd *bd;
@@ -379,7 +379,7 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct net_device *d
if (bcom_queue_full(priv->tx_dmatsk)) {
if (net_ratelimit())
dev_err(&dev->dev, "transmit queue overrun\n");
- return 1;
+ return NETDEV_TX_BUSY;
}
spin_lock_irq(&priv->lock);
@@ -400,7 +400,7 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct net_device *d
spin_unlock_irq(&priv->lock);
- return 0;
+ return NETDEV_TX_OK;
}
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -890,6 +890,22 @@ static int mpc52xx_fec_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
return mpc52xx_fec_phy_mii_ioctl(priv, if_mii(rq), cmd);
}
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+ .ndo_open = mpc52xx_fec_open,
+ .ndo_stop = mpc52xx_fec_close,
+ .ndo_start_xmit = mpc52xx_fec_start_xmit,
+ .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+ .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_do_ioctl = mpc52xx_fec_ioctl,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
+ .ndo_get_stats = mpc52xx_fec_get_stats,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = mpc52xx_fec_poll_controller,
+#endif
+};
+
/* ======================================================================== */
/* OF Driver */
/* ======================================================================== */
@@ -934,22 +950,10 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
return -EBUSY;
/* Init ether ndev with what we have */
- ndev->open = mpc52xx_fec_open;
- ndev->stop = mpc52xx_fec_close;
- ndev->hard_start_xmit = mpc52xx_fec_hard_start_xmit;
- ndev->do_ioctl = mpc52xx_fec_ioctl;
+ ndev->netdev_ops = &mpc52xx_fec_netdev_ops;
ndev->ethtool_ops = &mpc52xx_fec_ethtool_ops;
- ndev->get_stats = mpc52xx_fec_get_stats;
- ndev->set_mac_address = mpc52xx_fec_set_mac_address;
- ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
- ndev->tx_timeout = mpc52xx_fec_tx_timeout;
ndev->watchdog_timeo = FEC_WATCHDOG_TIMEOUT;
ndev->base_addr = mem.start;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev->poll_controller = mpc52xx_fec_poll_controller;
-#endif
-
- priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */
spin_lock_init(&priv->lock);
^ permalink raw reply related
* [PATCH 1/3] net/fec_mpc52xx: fix BUG on missing dma_ops
From: Grant Likely @ 2009-04-01 6:16 UTC (permalink / raw)
To: netdev, linuxppc-dev, David Miller
In-Reply-To: <20090401060117.8641.32252.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
The driver triggers a BUG_ON() when allocating DMA buffers because the
arch/powerpc dma_ops aren't in the net_device's struct device. This
patch fixes the problem by using the parent of_device which does have
the correct dma_ops set.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Reviewed-by: Becky Bruce <beckyb@kernel.crashing.org>
---
drivers/net/fec_mpc52xx.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 049b0a7..f99463f 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -129,7 +129,8 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
struct sk_buff *skb;
skb = bcom_retrieve_buffer(s, NULL, (struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
+ dma_unmap_single(dev->dev.parent, bd->skb_pa, skb->len,
+ DMA_FROM_DEVICE);
kfree_skb(skb);
}
}
@@ -150,7 +151,7 @@ static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task
bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, skb->data,
+ bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(rxtsk, skb);
@@ -388,7 +389,8 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff *skb, struct net_device *d
bcom_prepare_next_buffer(priv->tx_dmatsk);
bd->status = skb->len | BCOM_FEC_TX_BD_TFD | BCOM_FEC_TX_BD_TC;
- bd->skb_pa = dma_map_single(&dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
+ bd->skb_pa = dma_map_single(dev->dev.parent, skb->data, skb->len,
+ DMA_TO_DEVICE);
bcom_submit_next_buffer(priv->tx_dmatsk, skb);
@@ -430,7 +432,8 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
struct bcom_fec_bd *bd;
skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL,
(struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_TO_DEVICE);
+ dma_unmap_single(dev->dev.parent, bd->skb_pa, skb->len,
+ DMA_TO_DEVICE);
dev_kfree_skb_irq(skb);
}
@@ -455,7 +458,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
+ dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
+ DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -464,7 +468,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
+ bd->skb_pa = dma_map_single(dev->dev.parent,
+ rskb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
@@ -499,7 +504,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, skb->data,
+ bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
^ permalink raw reply related
* [PATCH 0/3] Series short description
From: Grant Likely @ 2009-04-01 6:16 UTC (permalink / raw)
To: netdev, linuxppc-dev, David Miller
Hi David,
Here are the fec_mpc52xx patches which should be picked up for 2.6.29.
Patch #1 fixes a dma related BUG_ON() discovered after the merge window
opened. #2 & #3 were original a single patch posted prior to the merge
window, but not having a s-o-b line from the original author held them up.
In the end I rewrote it from scratch as two patches just so I can get
them merged. #2 makes the driver use net_device_ops, and #3 fixes a NULL
dereference.
I've tested these patches on several MPC5200 platforms.
drivers/net/fec_mpc52xx.c | 77 +++++++++++++++++++++++++-------------------
1 files changed, 44 insertions(+), 33 deletions(-)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* powerpc: Enable relay in pseries_defconfig
From: Anton Blanchard @ 2009-04-01 6:14 UTC (permalink / raw)
To: linuxppc-dev
Enable relay in pseries config, ppc64_defconfig had it enabled but pseries
did not.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 61b1008..f1889ab 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -95,7 +95,7 @@ CONFIG_CGROUP_CPUACCT=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_PROC_PID_CPUSET=y
-# CONFIG_RELAY is not set
+CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
^ permalink raw reply related
* powerpc: Fix ibm,client-architecture comment
From: Anton Blanchard @ 2009-04-01 6:14 UTC (permalink / raw)
To: linuxppc-dev
We specify a 64MB RMO, but the comment says 128MB.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7f1b33d..ddd9561 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -614,7 +614,7 @@ static unsigned char ibm_architecture_vec[] = {
W(0xffffffff), /* virt_base */
W(0xffffffff), /* virt_size */
W(0xffffffff), /* load_base */
- W(64), /* 128MB min RMA */
+ W(64), /* 64MB min RMA */
W(0xffffffff), /* full client load */
0, /* min RMA percentage of total RAM */
48, /* max log_2(hash table size) */
^ permalink raw reply related
* powerpc: Scan for all events in rtasd
From: Anton Blanchard @ 2009-04-01 6:13 UTC (permalink / raw)
To: linuxppc-dev
Instead of checking for known events, pass in all 1s so we handle future
event types. We were currently missing the IO event type.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 0aa0315..01c1233 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -68,7 +68,8 @@ struct rtas_t {
#define RTAS_EPOW_WARNING 0x40000000 /* set bit 1 */
#define RTAS_POWERMGM_EVENTS 0x20000000 /* set bit 2 */
#define RTAS_HOTPLUG_EVENTS 0x10000000 /* set bit 3 */
-#define RTAS_EVENT_SCAN_ALL_EVENTS 0xf0000000
+#define RTAS_IO_EVENTS 0x08000000 /* set bit 4 */
+#define RTAS_EVENT_SCAN_ALL_EVENTS 0xffffffff
/* RTAS event severity */
#define RTAS_SEVERITY_FATAL 0x5
^ permalink raw reply related
* powerpc: Add dispatch diversion statistics
From: Anton Blanchard @ 2009-04-01 6:12 UTC (permalink / raw)
To: linuxppc-dev
PHYP tells us how often a shared processor dispatch changed physical cpus.
This can highlight performance problems caused by the hypervisor.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/include/asm/lppaca.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/lppaca.h 2009-02-28 18:37:02.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/lppaca.h 2009-02-28 18:37:07.000000000 +1100
@@ -125,7 +125,7 @@
// NOTE: This value will ALWAYS be zero for dedicated processors and
// will NEVER be zero for shared processors (ie, initialized to a 1).
volatile u32 yield_count; // PLIC increments each dispatchx00-x03
- u32 reserved6;
+ volatile u32 dispersion_count; // dispatch changed phys cpu x04-x07
volatile u64 cmo_faults; // CMO page fault count x08-x0F
volatile u64 cmo_fault_time; // CMO page fault time x10-x17
u8 reserved7[104]; // Reserved x18-x7F
Index: linux-2.6/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/lparcfg.c 2009-02-28 18:37:02.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/lparcfg.c 2009-02-28 18:38:50.000000000 +1100
@@ -434,6 +434,21 @@
seq_printf(m, "cmo_page_size=%lu\n", cmo_get_page_size());
}
+static void splpar_dispatch_data(struct seq_file *m)
+{
+ int cpu;
+ unsigned long dispatches = 0;
+ unsigned long dispatch_dispersions = 0;
+
+ for_each_possible_cpu(cpu) {
+ dispatches += lppaca[cpu].yield_count;
+ dispatch_dispersions += lppaca[cpu].dispersion_count;
+ }
+
+ seq_printf(m, "dispatches=%lu\n", dispatches);
+ seq_printf(m, "dispatch_dispersions=%lu\n", dispatch_dispersions);
+}
+
static int pseries_lparcfg_data(struct seq_file *m, void *v)
{
int partition_potential_processors;
@@ -460,6 +475,7 @@
parse_ppp_data(m);
parse_mpp_data(m);
pseries_cmo_data(m);
+ splpar_dispatch_data(m);
seq_printf(m, "purr=%ld\n", get_purr());
} else { /* non SPLPAR case */
^ permalink raw reply
* [patch 2/2] powerpc: Clean up some prom printouts
From: anton @ 2009-04-01 6:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090401060613.377489909@samba.org>
Make all messages consistent, some have spaces before the "...", some do not.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/prom_init.c 2009-04-01 16:19:01.000000000 +1100
+++ linux-2.6/arch/powerpc/kernel/prom_init.c 2009-04-01 16:19:03.000000000 +1100
@@ -1085,7 +1085,7 @@
return;
}
- prom_printf("instantiating rtas at 0x%x ...", base);
+ prom_printf("instantiating rtas at 0x%x...", base);
if (call_prom_ret("call-method", 3, 2, &entry,
ADDR("instantiate-rtas"),
@@ -1564,7 +1564,7 @@
if (call_prom("package-to-path", 3, 1, node, path,
PROM_SCRATCH_SIZE-10) == PROM_ERROR)
continue;
- prom_printf("found display : %s, opening ... ", path);
+ prom_printf("found display : %s, opening... ", path);
ih = call_prom("open", 1, 1, path);
if (ih == 0) {
@@ -2389,7 +2389,7 @@
/*
* Now finally create the flattened device-tree
*/
- prom_printf("copying OF device tree ...\n");
+ prom_printf("copying OF device tree...\n");
flatten_device_tree();
/*
@@ -2404,7 +2404,7 @@
* Call OF "quiesce" method to shut down pending DMA's from
* devices etc...
*/
- prom_printf("Calling quiesce ...\n");
+ prom_printf("Calling quiesce...\n");
call_prom("quiesce", 0, 0);
/*
--
^ permalink raw reply
* [patch 1/2] powerpc: Print progress of ibm, client-architecture method
From: anton @ 2009-04-01 6:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090401060613.377489909@samba.org>
The ibm,client-architecture method will often cause a reconfiguration reboot.
When this happens the last thing we see is:
Hypertas detected, assuming LPAR !
Which doesn't explain what just happened. Wrap the ibm,client-architecture
so it's clear what is going on:
Calling ibm,client-architecture... done
In order to maintain the law of conservation of screen real estate, downgrade
two other messages to debug.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7f1b33d..d5414fe 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -732,15 +732,17 @@ static void __init prom_send_capabilities(void)
root = call_prom("open", 1, 1, ADDR("/"));
if (root != 0) {
/* try calling the ibm,client-architecture-support method */
+ prom_printf("Calling ibm,client-architecture...");
if (call_prom_ret("call-method", 3, 2, &ret,
ADDR("ibm,client-architecture-support"),
root,
ADDR(ibm_architecture_vec)) == 0) {
/* the call exists... */
if (ret)
- prom_printf("WARNING: ibm,client-architecture"
+ prom_printf("\nWARNING: ibm,client-architecture"
"-support call FAILED!\n");
call_prom("close", 1, 0, root);
+ prom_printf(" done\n");
return;
}
call_prom("close", 1, 0, root);
@@ -1495,7 +1497,7 @@ static int __init prom_find_machine_type(void)
return PLATFORM_GENERIC;
x = prom_getproplen(rtas, "ibm,hypertas-functions");
if (x != PROM_ERROR) {
- prom_printf("Hypertas detected, assuming LPAR !\n");
+ prom_debug("Hypertas detected, assuming LPAR !\n");
return PLATFORM_PSERIES_LPAR;
}
return PLATFORM_PSERIES;
@@ -1544,7 +1546,7 @@ static void __init prom_check_displays(void)
};
const unsigned char *clut;
- prom_printf("Looking for displays\n");
+ prom_debug("Looking for displays\n");
for (node = 0; prom_next_node(&node); ) {
memset(type, 0, sizeof(type));
prom_getprop(node, "device_type", type, sizeof(type));
--
^ permalink raw reply related
* [patch 0/2] Some prom_init cleanups
From: anton @ 2009-04-01 6:06 UTC (permalink / raw)
To: linuxppc-dev
Some patches to make the ibm,client-architecture behaviour more obvious
as well as small formatting fixes.
^ permalink raw reply
* Broken CONFIG_HIGHPTE
From: Benjamin Herrenschmidt @ 2009-04-01 5:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
Hi !
Just noticed... And I'll be travelling for a while so with no much
time to look at it.
Your changes to use the PTE page free batch via RCU on ppc32 broke
CONFIG_HIGHPTE for hash32...
You rely on passing a page_address() of the PTE page down to the
freeing layer. That doesn't work for highmem pages. That needs to
be changes to a struct page * on 32-bit (not on 64-bit where we
are using slabs though)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: Grant Likely @ 2009-04-01 5:21 UTC (permalink / raw)
To: David Miller; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <20090331.221601.114102644.davem@davemloft.net>
On Tue, Mar 31, 2009 at 11:16 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 31 Mar 2009 22:56:38 -0600
>
>> At the very least, please consider picking up patches 2 & 3. =A0They
>> address a real bug (unrelated to the MDIO rework), and only touch the
>> MPC5200 FEC driver.
>
> Please submit them seperately, and I will look them over.\
Will do.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: David Miller @ 2009-04-01 5:16 UTC (permalink / raw)
To: grant.likely; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <fa686aa40903312156m2aad029i7dc27700bc9418fb@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 31 Mar 2009 22:56:38 -0600
> At the very least, please consider picking up patches 2 & 3. They
> address a real bug (unrelated to the MDIO rework), and only touch the
> MPC5200 FEC driver.
Please submit them seperately, and I will look them over.
Thanks.
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: Grant Likely @ 2009-04-01 4:56 UTC (permalink / raw)
To: David Miller; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <20090331.203855.96368726.davem@davemloft.net>
On Tue, Mar 31, 2009 at 9:38 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 31 Mar 2009 19:45:02 -0600
>
>> Dammit. =A0Why did you have to go and sound so reasonable when I was all
>> geared up for a pointless flame war.
>>
>> well... alright... but I reserve the right to be grumpy and surly for
>> a few days.
>
> :-)
>
> Just in case you decided to continue, I did cover my ass by
> making an explicit posting explaining the policy and the
> intent on netdev last week:
>
> http://marc.info/?l=3Dlinux-netdev&m=3D123814105015481&w=3D2
At the very least, please consider picking up patches 2 & 3. They
address a real bug (unrelated to the MDIO rework), and only touch the
MPC5200 FEC driver.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 8641D with linux 2.6.29 did'n show second cpu
From: Kumar Gala @ 2009-04-01 4:10 UTC (permalink / raw)
To: Eduard Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200903311706.55478.edfuchs@uni-kassel.de>
On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote:
> Hi,
>
> Am Dienstag 31 M=E4rz 2009 15:20:21 schrieb Kumar Gala:
>> On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote:
>>> Hi,
>>>
>>> I'm testing the evaluation board from freescale (MPC8641DHPCN) with
>>> the latest
>>> linux kernel (2.6.29) and the second core seems disabled. CONFIG_SPM
>>> is
>>> enabled but the /proc/cpuinfo shows only one cpu. With original
>>> 2.6.27 kernel
>>> both cpu cores appears in /proc/cpuinfo.
>>>
>>> Has anyone an idea how can i enable the second core?
>>
>> Are you using u-boot? I can't remember if you need a newer u-boot to
>> deal with changes in how we bring up the second core.
>
> Yes. My u-boot version is 2009.03. Are there some additional config =20=
> keys for
> SMP support in u-boot?
It appears we introduced a bug in v2009.03 of u-boot.
- k=
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: David Miller @ 2009-04-01 3:38 UTC (permalink / raw)
To: grant.likely; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <fa686aa40903311845v54ddfb91u56dd11eff64140d4@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 31 Mar 2009 19:45:02 -0600
> Dammit. Why did you have to go and sound so reasonable when I was all
> geared up for a pointless flame war.
>
> well... alright... but I reserve the right to be grumpy and surly for
> a few days.
:-)
Just in case you decided to continue, I did cover my ass by
making an explicit posting explaining the policy and the
intent on netdev last week:
http://marc.info/?l=linux-netdev&m=123814105015481&w=2
^ permalink raw reply
* Re: Problem with module_init?
From: Sean MacLennan @ 2009-04-01 3:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090331143742.083c6cb0@lappy.seanm.ca>
8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5 is first bad commit
commit 8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Mar 19 19:34:08 2009 +0000
powerpc/mm: Tweak PTE bit combination definitions
This patch tweaks the way some PTE bit combinations are defined, in
such a way that the 32 and 64-bit variant become almost identical
and that will make it easier to bring in a new common pte-* file
for the new variant of the Book3-E support.
The combination of bits defining access to kernel pages are now
clearly separated from the combination used by userspace and the
core VM. The resulting generated code should remain identical
unless I made a mistake.
Note: While at it, I removed a non-sensical statement related to
CONFIG_KGDB in ppc_mmu_32.c which could cause kernel mappings to be
user accessible when that option is enabled. Probably something
that bitrot.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
:040000 040000 c105fb9641b078f1a8a60c2a7900ca2dd088b364
e90678246962d7a455aa27ba12814c11cd9b3c22 M arch
^ permalink raw reply
* RE: PowerPC 460EX AD7416 Temperature Sensor
From: Tirumala Reddy Marri @ 2009-04-01 2:10 UTC (permalink / raw)
To: Henry Bausley, linuxppc-dev
In-Reply-To: <04bf01c9b262$95478040$0109220a@deltatau.local>
[-- Attachment #1: Type: text/plain, Size: 10152 bytes --]
Did you have dts entries for IIC in device tree ? also did you have I2C enabled in "make menuconfig"
"device drivers -> i2c support --> I2C bus support -> IBM ppc 4xx On chip I2C support " selected. Then you should i2c see an entry /proc/devices . Use that major address and create a device node "mknode /dev/i2c-0 c 89 0" .
Write a user level program to access this device. Here is an example user code.
----------
cat fan.c
/* This program is an example of writing and reading an EEPROM device via
SMBus on a GE Fanuc Embedded Systems, Inc. VMIVME-7809 Single Board
Computer.
To compile this program:
gcc -O vmieep.c -o vmieep
Before running this program, log in as root, then load the following
modules using:
/sbin/modprobe i2c-core
/sbin/modprobe i2c-dev
/sbin/modprobe i2c-i801
Loading the i2c-i801 module will create /dev/i2c-0, with
permissions = CRW- --- ---. Either run the vmieep program as root,
or change the permissions to CRW- RW- RW- as shown:
chmod 666 /dev/i2c-0
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
//#include <linux/i2c.h>
//#include <linux/i2c-dev.h>
#include <sys/time.h>
/* The inline smbus function definitions may or may not be in i2c-dev.h,
depending on the Linux distribution. Comment or uncomment the following
#include as necessary. */
#include "i2c-dev.h" /* Use the file of lm_sensors */
#define EEPROM_SIZE 256 /* Adjust for actual number of bytes in EEPROM */
#define EEPROM_SMBUS_ADDR 0x90 /* Do NOT change! */
int gef_eeprom_read(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen);
int gef_eeprom_write(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen);
void gef_msec_delay(unsigned int msecs);
int main(int argc, char *argv[])
{
int fd; /* File descriptor initialized with open() */
int adapter_num = 0;
int status;
char filename[20]; /* Name of special device file */
int i2c_addr = EEPROM_SMBUS_ADDR; /* SMBus address of EEPROM */
unsigned short offset; /* Which byte to access in the EEPROM */
unsigned char rbuffer; /* Data read from EEPROM */
if ((argc < 3) || (argc > 4))
{
printf("Usage: fan read <addr> or fan write <addr> <data>\n");
return 0;
}
/* Open the special device file for the SMBus */
sprintf(filename, "/dev/i2c-%d", adapter_num);
fd = open(filename, O_RDWR);
if (fd < 0)
{
printf("ERROR: open(%s) failed\n", filename);
printf("errno = %d, %s\n", errno, strerror(errno));
return -1;
}
//printf("SUCCESS: open(%s) passed\n", filename);
/* Specify the EEPROM as the device we want to access.
*** IMPORTANT ***
The address is actually in the 7 LSBs, so shift
i2c_addr one bit to the right.*/
status = ioctl(fd, I2C_SLAVE, i2c_addr>>1);
if (status < 0)
{
printf("ERROR: ioctl(fd, I2C_SLAVE, 0x%02X) failed\n", i2c_addr);
printf("errno = %d, %s\n", errno, strerror(errno));
close(fd);
return -1;
}
//printf("SUCCESS: ioctl(fd, I2C_SLAVE, 0x%02X>>1) passed\n", i2c_addr);
if (strcmp(argv[1],"read") == 0)
{
offset = atoi(argv[2]);
gef_eeprom_read(fd, offset, &rbuffer, 1);
printf("Offset: %d Data: %d\n", offset, rbuffer);
}
if (strcmp(argv[1],"write") == 0)
{
offset = (unsigned char)(atoi(argv[2]));
rbuffer =(unsigned char)(atoi(argv[3]));
gef_eeprom_write(fd, offset, &rbuffer, 1);
printf("Offset: %d Data: %d\n", offset, rbuffer);
}
/* Close the special device file */
close(fd);
return 0;
}
//////////////////////////////////////////////////////////////////////////////
//
// Function name : gef_eeprom_read
//
// Description : Read buflen bytes from the EEPROM beginning at start_offset
//
// Return type : 0 for success, -1 for failure
//
// Argument : int fd : File descriptor returned by open()
// Argument : unsigned char start_offset : Read bytes starting at this
// offset in the EEPROM. The sum of buflen and
// start_offset must not exceed the maximum size in bytes
// of the EEPROM
// Argument : unsigned char *buffer : Where to store the bytes read
// from the EEPROM. The buffer must be large enough
// to store buflen bytes read from the EEPROM.
// Argument : unsigned short buflen : The size in bytes of buffer, or
// how many bytes to read from the EEPROM. The sum of
// buflen and start_offset must not exceed the maximum
// size in bytes of the EEPROM.
//
int gef_eeprom_read(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen)
{
int offset, index;
int data;
for (index=0, offset=start_offset; index<buflen &&
offset<EEPROM_SIZE; index++, offset++)
{
data = i2c_smbus_read_byte_data(fd, offset);
if (data == -1)
{
printf("ERROR: i2c_smbus_read_byte_data(fd, 0x%02X) failed\n",
offset);
printf("errno = %d, %s\n", errno, strerror(errno));
return -1;
}
buffer[index] = (unsigned char) (data);
}
return 0;
}
//////////////////////////////////////////////////////////////////////////////
//
// Function name : gef_eeprom_write
//
// Description : Write buflen bytes to the EEPROM beginning at start_offset
//
// Return type : 0 for success, -1 for failure
//
// Argument : int fd : File descriptor returned by open()
// Argument : unsigned char start_offset : Write bytes starting at this
// offset in the EEPROM. The sum of buflen and
// start_offset must not exceed the maximum size in bytes
// of the EEPROM
// Argument : unsigned char *buffer : Where to get the bytes to write
// to the EEPROM.
// Argument : unsigned short buflen : The size in bytes of buffer.
// The sum of buflen and start_offset must not exceed the
// maximum size in bytes of the EEPROM.
//
int gef_eeprom_write(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen)
{
int offset, index;
int status;
for (index=0, offset=start_offset; index<buflen &&
offset<EEPROM_SIZE; index++, offset++)
{
status = i2c_smbus_write_byte_data(fd, offset, buffer[index]);
if (status < 0)
{
printf("ERROR: i2c_smbus_write_byte_data(fd, 0x%02X, 0x%02X) failed\n",
offset, buffer[index]);
printf("errno = %d, %s\n", errno, strerror(errno));
return -1;
}
/* Delay while the byte write completes */
gef_msec_delay(10);
}
return 0;
}
//////////////////////////////////////////////////////////////////////////////
//
// Function name : gef_msec_delay
//
// Description : Delay for a number of milliseconds before returning
//
// Return type : void
//
// Argument : unsigned int msecs : The number of milliseconds to delay
//
void gef_msec_delay(unsigned int msecs)
{
struct timeval s_current, s_start;
struct timezone tz;
unsigned int current, start;
/* Get initial time */
gettimeofday(&s_start, &tz);
start = s_start.tv_sec*1000000 + s_start.tv_usec;
/* Loop until msecs time have elapsed */
do
{
gettimeofday(&s_current, &tz);
current = s_current.tv_sec*1000000 + s_current.tv_usec;
} while ((current-start) < (msecs*1000));
}
-------------
________________________________
From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org on behalf of Henry Bausley
Sent: Tue 3/31/2009 5:41 PM
To: linuxppc-dev@ozlabs.org
Subject: PowerPC 460EX AD7416 Temperature Sensor
Does anyone know if the I2C temperature sensor is functioning on the AMCC
460EX?
When I do a cat /proc/ad7416 I get the following crash.
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc02cbe28
Oops: Kernel access of bad area, sig: 11 [#1]
PowerPC 44x Platform
NIP: c02cbe28 LR: c023cec8 CTR: c023d314
REGS: ef107d90 TRAP: 0300 Not tainted (2.6.28.7)
MSR: 00029000 <EE,ME> CR: 88000444 XER: 00000000
DEAR: 00000000, ESR: 00000000
TASK = ef8590c0[2611] 'cat' THREAD: ef106000
GPR00: 00000000 ef107e40 ef8590c0 00000000 ef107e9c 00000000 00000c00
ef107e98
GPR08: 00000000 c0330000 ffffffff c0330000 48000448 1001cb7c 100042bc
100df49c
GPR16: 00000002 00000400 c032f014 c032efe4 ef107e9c ef107e98 bfffffff
efb43a00
GPR24: ef61d000 00000000 ef107f20 ef107e98 00000c00 c0400000 00001000
efb43a00
NIP [c02cbe28] mutex_lock+0x0/0x1c
LR [c023cec8] ad7416_read_temp+0x24/0x80
Call Trace:
[ef107e40] [00000400] 0x400 (unreliable)
[ef107e70] [c023d334] i2c_ad7416_read_proc+0x20/0x70
[ef107e90] [c00e8018] proc_file_read+0x108/0x334
[ef107ee0] [c00e2d3c] proc_reg_read+0x4c/0x70
[ef107ef0] [c00a54e8] vfs_read+0xb4/0x16c
[ef107f10] [c00a58e0] sys_read+0x4c/0x90
[ef107f40] [c000ea88] ret_from_syscall+0x0/0x3c
Instruction dump:
90010014 38000001 90030000 85230004 7f891800 419e000c 80690008 4bd50779
80010014 38210010 7c0803a6 4e800020 <7c001828> 3000ffff 7c00192d 40a2fff4
---[ end trace 774db769c3754abe ]---
**********************************************************
Outbound scan for Spam or Virus by Barracuda at Delta Tau
**********************************************************
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 17110 bytes --]
^ permalink raw reply
* Re: [PATCH 00/14] Add common OF device tree support for MDIO busses
From: Grant Likely @ 2009-04-01 1:45 UTC (permalink / raw)
To: David Miller; +Cc: Joakim.Tjernlund, netdev, linuxppc-dev, afleming, olof
In-Reply-To: <20090331.152237.210090951.davem@davemloft.net>
On Tue, Mar 31, 2009 at 4:22 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 31 Mar 2009 16:19:42 -0600
>
>> On Tue, Mar 31, 2009 at 3:57 PM, David Miller <davem@davemloft.net> wrot=
e:
>> > It therefore didn't get any -next exposure, so it's unreasonable to
>> > merge this stuff now.
>>
>> Since when has sitting in a -next tree been a requirement for merging
>> when the series has been kept up to date and tested? =A0I purposefully
>> kept it out of -next to ensure that when it was applied for real to a
>> -next tree it would be as complete, bug free, and bisectable as
>> possible since once it hits a signed-off -next branch the individual
>> commit cannot be modified.
>
> I know your pissed off, but take a deep breath and consider this
> from my position.
>
> If I don't put a line in the sand somewhere, everyone can say
> "I've been working so hard, I posted it to the lists a thousand
> times, I have tons of testers" and I have to put the change in.
>
> That doesn't work, so please wait until the next release to get
> your changes in. =A0And get them into a tree that gets exposure
> in linux-next. =A0Then you have nothing to worry about.
Dammit. Why did you have to go and sound so reasonable when I was all
geared up for a pointless flame war.
well... alright... but I reserve the right to be grumpy and surly for
a few days.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: kexec: proc/device-tree/chosen/linux,kernel-end: No such file or directory
From: Geoff Levand @ 2009-04-01 0:45 UTC (permalink / raw)
To: michael; +Cc: Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <1238543571.6522.12.camel@localhost>
On 03/31/2009 04:52 PM, Michael Ellerman wrote:
> On Tue, 2009-03-31 at 18:25 +0200, Geert Uytterhoeven wrote:
>> With today's kernel, I can no longer kexec any kernel on PS3:
>>
>> | /proc/device-tree/chosen/linux,kernel-end: No such file or directory
>> | Could not get memory layout
>>
>> Today's bad version: 15f7176eb1cccec0a332541285ee752b935c1c85
>> Yesterday's good version: 0d34fb8e93ceba7b6dad0062dbb4a0813bacd75b
>>
>> Before I start bisecting (tomorrow or the day thereafter), anyone with an idea?
>
> Hmm, not really.
>
> Looking at the code the only obvious way you could end up without that
> property is if you didn't have a /chosen?
We got one, but linux,kernel-end isn't there anymore. Was before.
# ls /proc/device-tree/chosen/
name
#
^ permalink raw reply
* Re: Add hvc_console to MAINTAINERS
From: Josh Boyer @ 2009-04-01 0:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, roel.kluin, linux-kernel
In-Reply-To: <1238545250.6522.17.camel@localhost>
On Wed, Apr 01, 2009 at 11:20:50AM +1100, Michael Ellerman wrote:
>Add a MAINTAINERS entry for the hypervisor virtual console driver.
>
>Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>---
> MAINTAINERS | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
>How about this?
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 1c2ca1d..854437a 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -1918,6 +1918,12 @@ L: lm-sensors@lm-sensors.org
> W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
> S: Maintained
>
>+HYPERVISOR VIRTUAL CONSOLE DRIVER
>+L: linuxppc-dev@ozlabs.org
>+L: linux-kernel@vger.kernel.org
>+S: Odd Fixes
>+F: drivers/char/hvc_*
>+
> GSPCA FINEPIX SUBDRIVER
> P: Frank Zago
> M: frank@zago.net
>--
>1.6.1.2
>
>
>
^ 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