* [patch 37/43] powerpc: Remove extra semicolon in fsl_soc.c
From: Greg KH @ 2009-03-20 22:28 UTC (permalink / raw)
To: linux-kernel, stable, greg
Cc: Theodore Ts'o, Zwane Mwaikambo, Johns Daniel, Eugene Teo,
Justin Forbes, Domenico Andreoli, Chris Wedgwood, Jake Edge,
linuxppc-dev, Randy Dunlap, Michael Krufky, alan, Chuck Ebbert,
Dave Jones, Chuck Wolber, akpm, afleming, torvalds, Willy Tarreau,
Rodrigo Rubira Branco
In-Reply-To: <20090320232116.GA3375@kroah.com>
2.6.28-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johns Daniel <jdaniel@computer.org>
TSEC/MDIO will not work with older device trees because of a semicolon
at the end of a macro resulting in an empty for loop body.
This fix only applies to 2.6.28; this code is gone in 2.6.29, according
to Grant Likely!
Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/sysdev/fsl_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -257,7 +257,7 @@ static int __init gfar_mdio_of_init(void
gfar_mdio_of_init_one(np);
/* try the deprecated version */
- for_each_compatible_node(np, "mdio", "gianfar");
+ for_each_compatible_node(np, "mdio", "gianfar")
gfar_mdio_of_init_one(np);
return 0;
^ permalink raw reply
* [patch 19/32] powerpc: Remove extra semicolon in fsl_soc.c
From: Greg KH @ 2009-03-20 22:26 UTC (permalink / raw)
To: linux-kernel, stable, greg
Cc: Theodore Ts'o, Zwane Mwaikambo, Johns Daniel, Eugene Teo,
Justin Forbes, Domenico Andreoli, Chris Wedgwood, Jake Edge,
linuxppc-dev, Randy Dunlap, Michael Krufky, alan, Chuck Ebbert,
Dave Jones, Chuck Wolber, akpm, afleming, torvalds, Willy Tarreau,
Rodrigo Rubira Branco
In-Reply-To: <20090320231037.GA2732@kroah.com>
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johns Daniel <jdaniel@computer.org>
TSEC/MDIO will not work with older device trees because of a semicolon
at the end of a macro resulting in an empty for loop body.
This fix only applies to 2.6.28; this code is gone in 2.6.29, according
to Grant Likely!
Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/sysdev/fsl_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -255,7 +255,7 @@ static int __init gfar_mdio_of_init(void
gfar_mdio_of_init_one(np);
/* try the deprecated version */
- for_each_compatible_node(np, "mdio", "gianfar");
+ for_each_compatible_node(np, "mdio", "gianfar")
gfar_mdio_of_init_one(np);
return 0;
^ permalink raw reply
* Re: [PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver
From: Anton Vorontsov @ 2009-03-20 22:43 UTC (permalink / raw)
To: yamazaki
Cc: sdhci-devel, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
Ben Dooks, Pierre Ossman
In-Reply-To: <200903192328.AA00740@cj3020122-b.jcom.home.ne.jp>
Hi!
On Fri, Mar 20, 2009 at 08:28:39AM +0900, yamazaki wrote:
> Hi all,
>
> I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
> I have to write the driver of SDHCI driver(using R5C807 RICOH).
RICOH? It should be a PCI SD/MMC controller, so you even don't
need any patches to make it work in 2.6.28.7. Just make sure your
.config file has following symbols enabled:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y
CONFIG_MMC_RICOH_MMC=y
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 2.6.29] ucc_geth: Fix oops when using fixed-link support
From: Anton Vorontsov @ 2009-03-20 22:34 UTC (permalink / raw)
To: David Miller
Cc: linuxppc-dev, netdev, Li Yang, Joakim Tjernlund, Haiying Wang
commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4 ("ucc_geth: Change
uec phy id to the same format as gianfar's") introduced a regression
in the ucc_geth driver that causes this oops when fixed-link is used:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0151270
Oops: Kernel access of bad area, sig: 11 [#1]
TMCUTU
NIP: c0151270 LR: c0151270 CTR: c0017760
REGS: cf81fa60 TRAP: 0300 Not tainted (2.6.29-rc8)
MSR: 00009032 <EE,ME,IR,DR> CR: 24024042 XER: 20000000
DAR: 00000000, DSISR: 20000000
TASK = cf81cba0[1] 'swapper' THREAD: cf81e000
GPR00: c0151270 cf81fb10 cf81cba0 00000000 c0272e20 c025f354 00001e80
cf86b08c
GPR08: d1068200 cffffb74 06000000 d106c200 42024042 10085148 0fffd000
0ffc81a0
GPR16: 00000001 00000001 00000000 007ffeb0 00000000 0000c000 cf83f36c
cf83f000
GPR24: 00000030 cf83f360 cf81fb20 00000000 d106c200 20000000 00001e80
cf83f360
NIP [c0151270] ucc_geth_open+0x330/0x1efc
LR [c0151270] ucc_geth_open+0x330/0x1efc
Call Trace:
[cf81fb10] [c0151270] ucc_geth_open+0x330/0x1efc (unreliable)
[cf81fba0] [c0187638] dev_open+0xbc/0x12c
[cf81fbc0] [c0187e38] dev_change_flags+0x8c/0x1b0
This patch fixes the issue by removing offending (and somewhat
duplicate) code from init_phy() routine, and changes _probe()
function to use uec_mdio_bus_name().
Also, since we fully construct phy_bus_id in the _probe() routine,
we no longer need ->phy_address and ->mdio_bus fields in
ucc_geth_info structure.
I wish the patch would be a bit shorter, but it seems like the only
way to fix the issue in a sane way. Luckily, the patch has been
tested with real PHYs and fixed-link, so no further regressions
expected.
Reported-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
On Fri, Mar 20, 2009 at 09:46:13PM +0100, Joakim Tjernlund wrote:
[...]
> > I would suggest something along these lines (unfortunately
> > right now I can't test it on real HW, only compile-tested):
>
> Tested here, works fine for fixed-link PHYs, thanks.
> I left the
> priv->oldlink = 0;
> priv->oldspeed = 0;
> priv->oldduplex = -1;
> in though. Seemed like a good idea.
Yeah, good catch.
> Tested By: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Thanks!
I found a QE board to test this patch, so now we have real PHY
and fixed-links known to work.
drivers/net/ucc_geth.c | 34 ++++++++++------------------------
drivers/net/ucc_geth.h | 3 +--
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e879868..1f61e42 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,32 +1536,15 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
- struct device_node *np = priv->node;
- struct device_node *phy, *mdio;
- const phandle *ph;
- char bus_name[MII_BUS_ID_SIZE];
- const unsigned int *id;
+ struct ucc_geth_info *ug_info = priv->ug_info;
struct phy_device *phydev;
- char phy_id[BUS_ID_SIZE];
priv->oldlink = 0;
priv->oldspeed = 0;
priv->oldduplex = -1;
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
-
- id = of_get_property(phy, "reg", NULL);
-
- of_node_put(phy);
- of_node_put(mdio);
-
- uec_mdio_bus_name(bus_name, mdio);
- snprintf(phy_id, sizeof(phy_id), "%s:%02x",
- bus_name, *id);
-
- phydev = phy_connect(dev, phy_id, &adjust_link, 0, priv->phy_interface);
+ phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
+ priv->phy_interface);
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
@@ -3629,10 +3612,12 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
fixed_link = of_get_property(np, "fixed-link", NULL);
if (fixed_link) {
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "0");
- ug_info->phy_address = fixed_link[0];
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+ PHY_ID_FMT, "0", fixed_link[0]);
phy = NULL;
} else {
+ char bus_name[MII_BUS_ID_SIZE];
+
ph = of_get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
@@ -3643,7 +3628,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
prop = of_get_property(phy, "reg", NULL);
if (prop == NULL)
return -1;
- ug_info->phy_address = *prop;
/* Set the bus id */
mdio = of_get_parent(phy);
@@ -3657,7 +3641,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
if (err)
return -1;
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "%x", res.start);
+ uec_mdio_bus_name(bus_name, mdio);
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+ "%s:%02x", bus_name, *prop);
}
/* get the phy interface type, or default to MII */
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 16cbe42..611bdef 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1091,8 +1091,7 @@ struct ucc_geth_info {
u32 eventRegMask;
u16 pausePeriod;
u16 extensionField;
- u8 phy_address;
- char mdio_bus[MII_BUS_ID_SIZE];
+ char phy_bus_id[BUS_ID_SIZE];
u8 weightfactor[NUM_TX_QUEUES];
u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2] powerpc: Add support for CoreInt delivery of interrupts on MPIC
From: Benjamin Herrenschmidt @ 2009-03-20 22:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <051D5D14-4CD9-4138-879A-23DA2B02AB7F@kernel.crashing.org>
On Fri, 2009-03-20 at 06:47 -0500, Kumar Gala wrote:
> On Mar 20, 2009, at 12:48 AM, Benjamin Herrenschmidt wrote:
>
> > On Wed, 2009-03-11 at 10:18 -0500, Kumar Gala wrote:
> >> CoreInt provides a mechansim to deliver the IRQ vector directly
> >> into the core on an interrupt (via the SPR EPR) rather than having
> >> to go IACK on the PIC. This is suppose to provide an improvment
> >> in interrupt latency by reducing the time to get the IRQ vector.
> >>
> >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >> ---
> >> * Fixed MPIC_GREG_GCONF_COREINT flag to be 0x60000000 as per spec
> >> and pointed about by Dave
> >
> > Are you sure ? That's 2 bits ...
>
> Yeah. We expanded the mode field to two bits (mask would be 0x60000000)
>
> 0x00 = pass through (interrupts routed to IRQ0)
> 0x01 = Mixed mode
> 0x10 = reserved
> 0x11 = External proxy / coreint
Ah ok, that's a bit funny but should do. Maybe worth a comment though.
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-03-20 22:02 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev
In-Reply-To: <20090320041022.GB30527@yookeroo.seuss>
David Gibson wrote:
> On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
>> This patch adds support for the "socrates" board based on the MPC8544.
>> Supported are Ethernet, serial console, I2C, I2C-based RTC and
>> temperature sensors, NOR and NAND flash, PCI, USB, CAN and Lime
>> display controller.
>>
>> The multiplexing of FPGA interrupts onto PowerPC interrupt lines is
>> supported through our own fpga_pic interrupt controller driver.
>>
>> For example the SJA1000 controller is level low sensitive connected to
>> fpga_pic line 2 and is routed to the second (of three) irq lines to
>> the CPU:
>
> A few minor device tree nits.
>
>> + soc8544@e0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> +
>> + ranges = <0x00000000 0xe0000000 0x00100000>;
>> + reg = <0xe0000000 0x00001000>; // CCSRBAR 1M
>> + bus-frequency = <0>; // Filled in by U-Boot
>> + compatible = "fsl,socrates-immr", "simple-bus";
>
> This should probably refer to 8544 instead of socrates. Unless you
> really do have a board-specific version of the SoC...
OK, that should then be:
+ compatible = "fsl,mpc8544-immr", "simple-bus";
It should always be with the prefix "mpc", I guess. But some of the
following compatible names are without that prefix:
$ grep -h '\-l2-cache-controller' *
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,mpc8536-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8541-l2-cache-controller";
compatible = "fsl,8544-l2-cache-controller";
compatible = "fsl,8548-l2-cache-controller";
compatible = "fsl,8555-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8568-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,mpc8572-l2-cache-controller";
compatible = "fsl,8548-l2-cache-controller";
compatible = "fsl,8560-l2-cache-controller";
compatible = "fsl,mpc8544-l2-cache-controller";
compatible = "fsl,mpc8544-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,mpc8548-l2-cache-controller";
compatible = "fsl,mpc8548-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
compatible = "fsl,8540-l2-cache-controller";
That's confusing.
Wolfgang.
^ permalink raw reply
* Re: Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
From: Joakim Tjernlund @ 2009-03-20 20:46 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090320200740.GA32082@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> wrote on 20/03/2009 21:07:40:
>
> On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote:
> > hmm, this mail didn't seem to reach the lists. Resending
> >
> > Jocke
> > ----- Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42
-----
> >
> > From:
> > Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > To:
> > leoli@freescale.com, netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
> > Cc:
> > Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date:
> > 20/03/2009 18:01
> > Subject:
> > [PATCH] ucc_geth: Correct fixed_link OOPS.
> >
> >
> >
> > fixed_link(PHY less) mode will get you an NULL
> > deference as it does not have a phy-handle.
> > Correct by using already probed information.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> >
> > The below fixes the problem and seems like the right thing to do.
> > Can we have this in 2.6.29?
> >
> > drivers/net/ucc_geth.c | 17 +----------------
> > 1 files changed, 1 insertions(+), 16 deletions(-)
[SNIP]
>
> This effectivly breaks boards where Gianfar is using UCC's MDIO
> bus (i.e. breaks commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4,
> which is the cause of fixed-link breakage, btw). And, your patch
> is line-wrapped and tabs are substituted by white spaces...
Yes, I noticed that afterwards. It is our "great" new mailsystem
that gets in the way. I really need to find another mailsystem as
Lotus/Domino gets in my way too often :(
>
> I would suggest something along these lines (unfortunately
> right now I can't test it on real HW, only compile-tested):
Tested here, works fine for fixed-link PHYs, thanks.
I left the
priv->oldlink = 0;
priv->oldspeed = 0;
priv->oldduplex = -1;
in though. Seemed like a good idea.
Tested By: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Jocke
^ permalink raw reply
* Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
From: Anton Vorontsov @ 2009-03-20 20:22 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20090320195743.GA25147@elte.hu>
On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
>
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> > >
> > > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > >
> > > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > > > up menu"), despite the "clean up" in its purpose, introduced
> > > > behavioural change for Kconfig symbols: we no longer able to
> > > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > > > yet implemented).
> > >
> > > Could you please solve this by implementing proper
> > > irqflag-tracing support? It's been available upstream for almost
> > > three years. It's needed for lockdep support as well, etc.
> >
> > Breaking things via clean up patches is an interesting method of
> > encouraging something to implement. ;-)
> >
> > Surely I'll look into implementing irqflags tracing, but
> > considering that no one ever needed this for almost three years,
> > [...]
>
> Weird, there's no lockdep support?
*ashamed*: apparently no such support currently exist for PPC32. ;-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-03-20 20:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <734DA8C3-EADB-4426-BD18-AC190918CD7E@kernel.crashing.org>
Hi Kumar,
Kumar Gala wrote:
>
> On Mar 19, 2009, at 10:26 AM, Wolfgang Grandegger wrote:
>
>> + mdio@24520 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,gianfar-mdio";
>> + reg = <0x24520 0x20>;
>> +
>> + phy0: ethernet-phy@0 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <0 1>;
>> + reg = <0>;
>> + device_type = "ethernet-phy";
>> + };
>> + phy1: ethernet-phy@1 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <0 1>;
>> + reg = <1>;
>> + device_type = "ethernet-phy";
>> + };
>> + tbi0: tbi-phy@11 {
>> + reg = <0x11>;
>> + device_type = "tbi-phy";
>> + };
>> + };
>> +
>> + mdio@26520 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,gianfar-tbi";
>> + reg = <0x26520 0x20>;
>> +
>> + tbi1: tbi-phy@11 {
>> + reg = <0x11>;
>> + device_type = "tbi-phy";
>> + };
>> + };
>> +
>> + enet0: ethernet@24000 {
>> + cell-index = <0>;
>> + device_type = "network";
>> + model = "eTSEC";
>> + compatible = "gianfar";
>> + reg = <0x24000 0x1000>;
>> + local-mac-address = [ 00 00 00 00 00 00 ];
>> + interrupts = <29 2 30 2 34 2>;
>> + interrupt-parent = <&mpic>;
>> + phy-handle = <&phy0>;
>> + tbi-handle = <&tbi0>;
>> + phy-connection-type = "rgmii-id";
>> + };
>> +
>
> See Anton's recent post in moving the mdio node under the ethernet.
> Please match.
I have fixed it for the socrates board. Is there a GIT tree with that
modifications which I can base my patches on, also for the one for the
TQM8548 posted recently:
http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069364.html
Wolfgang.
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-03-20 20:12 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev
In-Reply-To: <20090320041022.GB30527@yookeroo.seuss>
David Gibson wrote:
> On Thu, Mar 19, 2009 at 04:26:44PM +0100, Wolfgang Grandegger wrote:
[snip]
> [snip[
>> + display@2,0 {
>> + compatible = "fujitsu,lime";
>
> This compat string looks slightly worryingly non-specific.
The node is for the Lime graphic controller from Fujitsu. What does
worry you?
Wolfgang.
^ permalink raw reply
* Re: Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
From: Anton Vorontsov @ 2009-03-20 20:07 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, leoli, linuxppc-dev
In-Reply-To: <OF20EA88BB.017079CD-ONC125757F.006C40A2-C125757F.006C646E@transmode.se>
On Fri, Mar 20, 2009 at 08:43:56PM +0100, Joakim Tjernlund wrote:
> hmm, this mail didn't seem to reach the lists. Resending
>
> Jocke
> ----- Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -----
>
> From:
> Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> To:
> leoli@freescale.com, netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
> Cc:
> Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date:
> 20/03/2009 18:01
> Subject:
> [PATCH] ucc_geth: Correct fixed_link OOPS.
>
>
>
> fixed_link(PHY less) mode will get you an NULL
> deference as it does not have a phy-handle.
> Correct by using already probed information.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
>
> The below fixes the problem and seems like the right thing to do.
> Can we have this in 2.6.29?
>
> drivers/net/ucc_geth.c | 17 +----------------
> 1 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index dc2f8f2..12e5c3d 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -1536,11 +1536,6 @@ static void adjust_link(struct net_device *dev)
> static int init_phy(struct net_device *dev)
> {
> struct ucc_geth_private *priv = netdev_priv(dev);
> - struct device_node *np = priv->node;
> - struct device_node *phy, *mdio;
> - const phandle *ph;
> - char bus_name[MII_BUS_ID_SIZE];
> - const unsigned int *id;
> struct phy_device *phydev;
> char phy_id[BUS_ID_SIZE];
>
> @@ -1548,18 +1543,8 @@ static int init_phy(struct net_device *dev)
> priv->oldspeed = 0;
> priv->oldduplex = -1;
>
> - ph = of_get_property(np, "phy-handle", NULL);
> - phy = of_find_node_by_phandle(*ph);
> - mdio = of_get_parent(phy);
> -
> - id = of_get_property(phy, "reg", NULL);
> -
> - of_node_put(phy);
> - of_node_put(mdio);
> -
> - uec_mdio_bus_name(bus_name, mdio);
> snprintf(phy_id, sizeof(phy_id), "%s:%02x",
> - bus_name, *id);
> + priv->ug_info->mdio_bus,
> priv->ug_info->phy_address);
>
> phydev = phy_connect(dev, phy_id, &adjust_link, 0,
> priv->phy_interface);
This effectivly breaks boards where Gianfar is using UCC's MDIO
bus (i.e. breaks commit b1c4a9dddf09fe99b8f88252718ac5b357363dc4,
which is the cause of fixed-link breakage, btw). And, your patch
is line-wrapped and tabs are substituted by white spaces...
I would suggest something along these lines (unfortunately
right now I can't test it on real HW, only compile-tested):
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e879868..58b78ed 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,32 +1536,11 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
- struct device_node *np = priv->node;
- struct device_node *phy, *mdio;
- const phandle *ph;
- char bus_name[MII_BUS_ID_SIZE];
- const unsigned int *id;
+ struct ucc_geth_info *ug_info = priv->ug_info;
struct phy_device *phydev;
- char phy_id[BUS_ID_SIZE];
-
- priv->oldlink = 0;
- priv->oldspeed = 0;
- priv->oldduplex = -1;
-
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
-
- id = of_get_property(phy, "reg", NULL);
- of_node_put(phy);
- of_node_put(mdio);
-
- uec_mdio_bus_name(bus_name, mdio);
- snprintf(phy_id, sizeof(phy_id), "%s:%02x",
- bus_name, *id);
-
- phydev = phy_connect(dev, phy_id, &adjust_link, 0, priv->phy_interface);
+ phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
+ priv->phy_interface);
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
@@ -3629,10 +3608,12 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
fixed_link = of_get_property(np, "fixed-link", NULL);
if (fixed_link) {
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "0");
- ug_info->phy_address = fixed_link[0];
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+ PHY_ID_FMT, "0", fixed_link[0]);
phy = NULL;
} else {
+ char bus_name[MII_BUS_ID_SIZE];
+
ph = of_get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
@@ -3643,7 +3624,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
prop = of_get_property(phy, "reg", NULL);
if (prop == NULL)
return -1;
- ug_info->phy_address = *prop;
/* Set the bus id */
mdio = of_get_parent(phy);
@@ -3657,7 +3637,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
if (err)
return -1;
- snprintf(ug_info->mdio_bus, MII_BUS_ID_SIZE, "%x", res.start);
+ uec_mdio_bus_name(bus_name, mdio);
+ snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
+ "%s:%02x", bus_name, *prop);
}
/* get the phy interface type, or default to MII */
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 16cbe42..611bdef 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1091,8 +1091,7 @@ struct ucc_geth_info {
u32 eventRegMask;
u16 pausePeriod;
u16 extensionField;
- u8 phy_address;
- char mdio_bus[MII_BUS_ID_SIZE];
+ char phy_bus_id[BUS_ID_SIZE];
u8 weightfactor[NUM_TX_QUEUES];
u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
^ permalink raw reply related
* Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
From: Ingo Molnar @ 2009-03-20 19:57 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20090320193904.GA13707@oksana.dev.rtsoft.ru>
* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
> >
> > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > > up menu"), despite the "clean up" in its purpose, introduced
> > > behavioural change for Kconfig symbols: we no longer able to
> > > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > > yet implemented).
> >
> > Could you please solve this by implementing proper
> > irqflag-tracing support? It's been available upstream for almost
> > three years. It's needed for lockdep support as well, etc.
>
> Breaking things via clean up patches is an interesting method of
> encouraging something to implement. ;-)
>
> Surely I'll look into implementing irqflags tracing, but
> considering that no one ever needed this for almost three years,
> [...]
Weird, there's no lockdep support?
Ingo
^ permalink raw reply
* Fw: [PATCH] ucc_geth: Correct fixed_link OOPS.
From: Joakim Tjernlund @ 2009-03-20 19:43 UTC (permalink / raw)
To: leoli, netdev, linuxppc-dev
hmm, this mail didn't seem to reach the lists. Resending
Jocke
----- Forwarded by Joakim Tjernlund/Transmode on 20/03/2009 20:42 -----
From:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
To:
leoli@freescale.com, netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Cc:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date:
20/03/2009 18:01
Subject:
[PATCH] ucc_geth: Correct fixed_link OOPS.
fixed_link(PHY less) mode will get you an NULL
deference as it does not have a phy-handle.
Correct by using already probed information.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
The below fixes the problem and seems like the right thing to do.
Can we have this in 2.6.29?
drivers/net/ucc_geth.c | 17 +----------------
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index dc2f8f2..12e5c3d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,11 +1536,6 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
- struct device_node *np = priv->node;
- struct device_node *phy, *mdio;
- const phandle *ph;
- char bus_name[MII_BUS_ID_SIZE];
- const unsigned int *id;
struct phy_device *phydev;
char phy_id[BUS_ID_SIZE];
@@ -1548,18 +1543,8 @@ static int init_phy(struct net_device *dev)
priv->oldspeed = 0;
priv->oldduplex = -1;
- ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
-
- id = of_get_property(phy, "reg", NULL);
-
- of_node_put(phy);
- of_node_put(mdio);
-
- uec_mdio_bus_name(bus_name, mdio);
snprintf(phy_id, sizeof(phy_id), "%s:%02x",
- bus_name, *id);
+ priv->ug_info->mdio_bus,
priv->ug_info->phy_address);
phydev = phy_connect(dev, phy_id, &adjust_link, 0,
priv->phy_interface);
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
From: Anton Vorontsov @ 2009-03-20 19:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20090320190428.GD6224@elte.hu>
On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
>
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> > up menu"), despite the "clean up" in its purpose, introduced
> > behavioural change for Kconfig symbols: we no longer able to
> > select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> > yet implemented).
>
> Could you please solve this by implementing proper irqflag-tracing
> support? It's been available upstream for almost three years. It's
> needed for lockdep support as well, etc.
Breaking things via clean up patches is an interesting method of
encouraging something to implement. ;-)
Surely I'll look into implementing irqflags tracing, but considering
that no one ever needed this for almost three years, and that we
explicitly have the code to deal with tracing-w/o-irqflags, can we
please restore the old behaviour?
At least for 2.6.30, because I don't think I'll have enough time to
implement/test/push irqflags tracing support in time for 2.6.30-rc1.
Thanks,
p.s.
It would make more sense if 40ada30f's commit message would state
that tracing w/o irqflags is now obsolete, or better, if it was
discussed on some mailinglist, so that we'd have some time to
adapt the architecture-specific code.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Fix for __div64_32 locks when using some 64 bit numbers
From: davidastro @ 2009-03-20 19:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1237330984.25062.164.camel@pasglop>
Hi Ben:
I was wondering if you have any change to look into and test the propose fix
I suggested in my previous post.
I'd like to know if the fix is correct.
Thanks for your attention,
Benjamin Herrenschmidt wrote:
>
> On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote:
>> I found a bug when using the function __div64_32 in assembly in a 32 bit
>> ppc
>> architecture unit.
>>
>> I tried the numbers 55834565048000000 for the dividend and 4294967079 for
>> the divisor. When passing these two numbers to the function __div64_32,
>> I
>> had a software lock. I searched for possible patches online and in
>> different
>> forums but I could not find anything related to the assembly
>> implementation
>> to this function (I would have to apologize if somebody already found a
>> fix
>> :-) ).
>>
>> Anyway, when analyzing the assembly code, I found out with gdb the
>> problem.
>> I am not an expert in ppc architecture but I read the documentation and I
>> am
>> pretty sure I solved the issue (I have been testing for couple of days
>> using
>> random 64 to 32 number combinations with good results).
>>
>> Who or Where should I post the fix to be reviewed.
>
> Here is fine :-)
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/Fix-for-__div64_32-locks-when-using-some-64-bit-numbers-tp22567864p22627440.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency
From: Ingo Molnar @ 2009-03-20 19:04 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20090320150914.GA22769@oksana.dev.rtsoft.ru>
* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean
> up menu"), despite the "clean up" in its purpose, introduced
> behavioural change for Kconfig symbols: we no longer able to
> select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't
> yet implemented).
Could you please solve this by implementing proper irqflag-tracing
support? It's been available upstream for almost three years. It's
needed for lockdep support as well, etc.
Ingo
^ permalink raw reply
* Re: [PATCH v4 0/3] Tracers vs. CALLER_ADDR on PowerPC
From: Anton Vorontsov @ 2009-03-20 16:52 UTC (permalink / raw)
To: Ingo Molnar
Cc: linuxppc-dev, Steven Rostedt, Paul Mackerras, linux-kernel,
Sam Ravnborg
In-Reply-To: <20090320164404.GA19933@oksana.dev.rtsoft.ru>
On Fri, Mar 20, 2009 at 07:44:04PM +0300, Anton Vorontsov wrote:
> Hi all,
>
> Here is another approach to fixing tracers vs. CALLER_ADDR problem
> on PowerPC.
>
> Preface for those who don't know or forgot what the problem is:
>
> Gcc frame pointers do nothing useful on PowerPC (they're harmful,
> actually), and thus lib/Kconfig.debug makes CONFIG_FRAME_POINTER
> unselectable on PPC targets, but CALLER_ADDR macros are available
> only with CONFIG_FRAME_POINTER, therefore tracing is completely
> useless on PowerPC:
>
> [...]
> <idle>-0 0X.h3 2us+: 0:140:R + [000] 1733:120:S mvtsd
> <idle>-0 0X.h3 9us+: 0 (0)
> <idle>-0 0X..3 72us : 0 (0)
> <idle>-0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd
>
> While it should look like this:
>
> [...]
> <idle>-0 0X.h3 2us+: 0:140:R + [000] 1740:120:S mvtsd
> <idle>-0 0X.h3 9us+: hrtimer_wakeup (__run_hrtimer)
> <idle>-0 0X..3 87us : cpu_idle (__got2_end)
> <idle>-0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd
>
> I've tried to fix the issue via expanding the #ifdef in the ftrace.h:
> http://lkml.org/lkml/2009/1/31/141
>
> Then Steven Rostedt suggested to implement something more generic,
> i.e. HAVE_NORMAL_FRAME_POINTERS Kconfig symbol.
>
> I found a way to solve the problem w/o additional symbols, but
> with some Makefile magic (http://lkml.org/lkml/2009/2/4/273).
> But because of top-level Makefile issues on other arches
> (http://lkml.org/lkml/2009/2/14/89) I had to abandon the approach.
Oh, and btw, I'm aware of
commit c79a61f55773d2519fd0525bf58385f7d20752d3
Author: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Date: Fri Feb 27 21:30:03 2009 +0100
tracing: make CALLER_ADDRx overwriteable
But I think the patch set is still applicable, considering that
it removes gcc bug workaround in a nice way, and makes
CONFIG_FRAME_POINTER available on PowerPC, thus other code
can rely on that.
If not, I can just fill-in the asm/ftrace.h for PowerPC.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
From: Anton Vorontsov @ 2009-03-20 16:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <20090320164404.GA19933@oksana.dev.rtsoft.ru>
Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they
should select FRAME_POINTER. Otherwise traces are meaningless.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
kernel/trace/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 774aba7..9fc98a7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -107,6 +107,7 @@ config IRQSOFF_TRACER
select TRACE_IRQFLAGS
select TRACING
select TRACER_MAX_TRACE
+ select FRAME_POINTER
help
This option measures the time spent in irqs-off critical
sections, with microsecond accuracy.
@@ -128,6 +129,7 @@ config PREEMPT_TRACER
depends on PREEMPT
select TRACING
select TRACER_MAX_TRACE
+ select FRAME_POINTER
help
This option measures the time spent in preemption off critical
sections, with microsecond accuracy.
@@ -156,6 +158,7 @@ config SCHED_TRACER
select TRACING
select CONTEXT_SWITCH_TRACER
select TRACER_MAX_TRACE
+ select FRAME_POINTER
help
This tracer tracks the latency of the highest priority task
to be scheduled in, starting from the point it has woken up.
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/3] powerpc: Remove -fno-omit-frame-pointer workarounds
From: Anton Vorontsov @ 2009-03-20 16:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <20090320164404.GA19933@oksana.dev.rtsoft.ru>
The workarounds aren't needed any longer since the top level Makefile
doesn't pass -fno-omit-frame-pointer cflag for PowerPC.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/Makefile | 5 -----
arch/powerpc/kernel/Makefile | 12 ++++++------
arch/powerpc/platforms/powermac/Makefile | 2 +-
lib/Kconfig.debug | 6 +++---
4 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 551fc58..1dd7748 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -120,11 +120,6 @@ ifeq ($(CONFIG_6xx),y)
KBUILD_CFLAGS += -mcpu=powerpc
endif
-# Work around a gcc code-gen bug with -fno-omit-frame-pointer.
-ifeq ($(CONFIG_FUNCTION_TRACER),y)
-KBUILD_CFLAGS += -mno-sched-epilog
-endif
-
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index dfec3d2..f86caeb 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -14,14 +14,14 @@ endif
ifdef CONFIG_FUNCTION_TRACER
# Do not trace early boot code
-CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_cputable.o = -pg
+CFLAGS_REMOVE_prom_init.o = -pg
+CFLAGS_REMOVE_btext.o = -pg
+CFLAGS_REMOVE_prom.o = -pg
# do not trace tracer code
-CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_ftrace.o = -pg
# timers used by tracing
-CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_time.o = -pg
endif
obj-y := cputable.o ptrace.o syscalls.o \
diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile
index 50f1693..0eb8781 100644
--- a/arch/powerpc/platforms/powermac/Makefile
+++ b/arch/powerpc/platforms/powermac/Makefile
@@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC
ifdef CONFIG_FUNCTION_TRACER
# Do not trace early boot code
-CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_bootx_init.o = -pg
endif
obj-y += pic.o setup.o time.o feature.o pci.o \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index fc8cd1f..713620d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -493,7 +493,7 @@ config LOCKDEP
bool
depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
select STACKTRACE
- select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND
+ select FRAME_POINTER if !MIPS && !ARM_UNWIND
select KALLSYMS
select KALLSYMS_ALL
@@ -866,13 +866,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER
depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
- select FRAME_POINTER if !PPC
+ select FRAME_POINTER
help
Provide stacktrace filter for fault-injection capabilities
config LATENCYTOP
bool "Latency measuring infrastructure"
- select FRAME_POINTER if !MIPS && !PPC
+ select FRAME_POINTER if !MIPS
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Anton Vorontsov @ 2009-03-20 16:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <20090320164404.GA19933@oksana.dev.rtsoft.ru>
This patch introduces ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol.
When defined, the top level Makefile won't add -fno-omit-frame-pointer
cflag (the flag is useless in PowerPC kernels, and also makes gcc
generate wrong code).
Also move ARCH_WANT_FRAME_POINTERS's help text.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Makefile | 7 +++++--
arch/powerpc/Kconfig | 1 +
lib/Kconfig.debug | 16 ++++++++++------
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 46c04c5..bf41b05 100644
--- a/Makefile
+++ b/Makefile
@@ -538,9 +538,12 @@ KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
endif
ifdef CONFIG_FRAME_POINTER
-KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
+ KBUILD_CFLAGS += -fno-optimize-sibling-calls
+ ifndef ARCH_HAS_NORMAL_FRAME_POINTERS
+ KBUILD_CFLAGS += -fno-omit-frame-pointer
+ endif
else
-KBUILD_CFLAGS += -fomit-frame-pointer
+ KBUILD_CFLAGS += -fomit-frame-pointer
endif
ifdef CONFIG_DEBUG_INFO
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 97f9a64..4587e66 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,6 +113,7 @@ config PPC
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARCH_HAS_NORMAL_FRAME_POINTERS
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_EFFICIENT_UNALIGNED_ACCESS
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4b63b6b..fc8cd1f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -661,20 +661,24 @@ config DEBUG_NOTIFIERS
This is a relatively cheap check but if you care about maximum
performance, say N.
-#
-# Select this config option from the architecture Kconfig, if it
-# it is preferred to always offer frame pointers as a config
-# option on the architecture (regardless of KERNEL_DEBUG):
-#
config ARCH_WANT_FRAME_POINTERS
bool
help
+ Select this config option from the architecture Kconfig, if it
+ it is preferred to always offer frame pointers as a config
+ option on the architecture (regardless of KERNEL_DEBUG).
+
+config ARCH_HAS_NORMAL_FRAME_POINTERS
+ bool
+ help
+ Architectures should select this symbol if their ABI implies
+ having a frame pointer.
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && \
(CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
- AVR32 || SUPERH || BLACKFIN || MN10300) || \
+ AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \
ARCH_WANT_FRAME_POINTERS
default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
help
--
1.5.6.5
^ permalink raw reply related
* [PATCH v4 0/3] Tracers vs. CALLER_ADDR on PowerPC
From: Anton Vorontsov @ 2009-03-20 16:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Sam Ravnborg
Hi all,
Here is another approach to fixing tracers vs. CALLER_ADDR problem
on PowerPC.
Preface for those who don't know or forgot what the problem is:
Gcc frame pointers do nothing useful on PowerPC (they're harmful,
actually), and thus lib/Kconfig.debug makes CONFIG_FRAME_POINTER
unselectable on PPC targets, but CALLER_ADDR macros are available
only with CONFIG_FRAME_POINTER, therefore tracing is completely
useless on PowerPC:
[...]
<idle>-0 0X.h3 2us+: 0:140:R + [000] 1733:120:S mvtsd
<idle>-0 0X.h3 9us+: 0 (0)
<idle>-0 0X..3 72us : 0 (0)
<idle>-0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd
While it should look like this:
[...]
<idle>-0 0X.h3 2us+: 0:140:R + [000] 1740:120:S mvtsd
<idle>-0 0X.h3 9us+: hrtimer_wakeup (__run_hrtimer)
<idle>-0 0X..3 87us : cpu_idle (__got2_end)
<idle>-0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd
I've tried to fix the issue via expanding the #ifdef in the ftrace.h:
http://lkml.org/lkml/2009/1/31/141
Then Steven Rostedt suggested to implement something more generic,
i.e. HAVE_NORMAL_FRAME_POINTERS Kconfig symbol.
I found a way to solve the problem w/o additional symbols, but
with some Makefile magic (http://lkml.org/lkml/2009/2/4/273).
But because of top-level Makefile issues on other arches
(http://lkml.org/lkml/2009/2/14/89) I had to abandon the approach.
So, this patch set combines Steven Rostedt's idea and a small
Makefile change, so that now only top-level Makefile has to know
about the new symbol, and the rest of the kernel can stay with
using CONFIG_FRAME_POINTER.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* ucc_geth broken w.r.t fixed_link PHY
From: Joakim Tjernlund @ 2009-03-20 16:06 UTC (permalink / raw)
To: linuxppc-dev
Trying to upgrade to latest linus latest just to see if it still works I
get this:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0151270
Oops: Kernel access of bad area, sig: 11 [#1]
TMCUTU
NIP: c0151270 LR: c0151270 CTR: c0017760
REGS: cf81fa60 TRAP: 0300 Not tainted (2.6.29-rc8)
MSR: 00009032 <EE,ME,IR,DR> CR: 24024042 XER: 20000000
DAR: 00000000, DSISR: 20000000
TASK = cf81cba0[1] 'swapper' THREAD: cf81e000
GPR00: c0151270 cf81fb10 cf81cba0 00000000 c0272e20 c025f354 00001e80
cf86b08c
GPR08: d1068200 cffffb74 06000000 d106c200 42024042 10085148 0fffd000
0ffc81a0
GPR16: 00000001 00000001 00000000 007ffeb0 00000000 0000c000 cf83f36c
cf83f000
GPR24: 00000030 cf83f360 cf81fb20 00000000 d106c200 20000000 00001e80
cf83f360
NIP [c0151270] ucc_geth_open+0x330/0x1efc
LR [c0151270] ucc_geth_open+0x330/0x1efc
Call Trace:
[cf81fb10] [c0151270] ucc_geth_open+0x330/0x1efc (unreliable)
[cf81fba0] [c0187638] dev_open+0xbc/0x12c
[cf81fbc0] [c0187e38] dev_change_flags+0x8c/0x1b0
[cf81fbe0] [c02a5e94] tm_icn_address+0x5f0/0x1038
[cf81fd70] [c00038b0] do_one_initcall+0x34/0x1dc
[cf81ffd0] [c02887dc] kernel_init+0x90/0x10c
[cf81fff0] [c00106a4] kernel_thread+0x4c/0x68
Instruction dump:
7c0004ac 914b0144 3800ffff 807f02b4 3c80c027 901f02ac 38842e20 38a00000
937f02a8 3b410010 937f02b0 48022ef9 <80630000> 4bebc8c9 7c7d1b78 48023155
---[ end trace 5e5a8c89939b0ba3 ]---
gdb vmlinux shows:
(gdb) list *0xc0151270
0xc0151270 is in ucc_geth_open (drivers/net/ucc_geth.c:1552).
1547 priv->oldlink = 0;
1548 priv->oldspeed = 0;
1549 priv->oldduplex = -1;
1550
1551 ph = of_get_property(np, "phy-handle", NULL);
1552 phy = of_find_node_by_phandle(*ph);
1553 mdio = of_get_parent(phy);
1554
1555 id = of_get_property(phy, "reg", NULL);
1556
Tunrsn out that my fixed_link PHY doesn't work anymore. I don't have a
phy-handle in
in my of tree. Instead I got fixed-link:
enet2: ucc@3200 { //UCC4
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <4>;
cell-index = <4>;
reg = <3200 200>;
interrupts = <23>;
interrupt-parent = <&qeic>;
mac-address = [ 00 11 22 33 44 99 ];
rx-clock = <17>; //CLK7, 23
tx-clock = <18>; //CLK8, 24
fixed-link = <19 1 1 100 0 0>;
phy-connection-type = "mii";
pio-handle = <&pio4>;
};
So what is broken, ucc_geth or my OF tree?
Jocke
^ permalink raw reply
* Re: Problem with radeonfb on PowerPC 7448&MV64560
From: Eduard Fuchs @ 2009-03-20 15:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <m2bprw79i8.fsf@ohwell.denx.de>
Am Freitag 20 M=C3=A4rz 2009 11:51:11 schrieb Detlev Zundel:
> Hi Eduard,
>
> > Am Mittwoch 18 M=C3=A4rz 2009 00:05:00 schrieb Benjamin Herrenschmidt:
> >> On Tue, 2009-03-17 at 16:30 +0100, Eduard Fuchs wrote:
> >> > Hi all,
> >> >
> >> > since several days I'm trying to run an ATI 9250 (PCI) graphic card
> >> > under Linux Kernel 2.6.27.19. Nevertheless without success. The kern=
el
> >> > shows the following message:
> >> >
> >> > videoboot: Booting PCI video card bus 0, function 0, device 7
> >> > biosEmu: undefined interrupt 15h called!
> >> > biosEmu/bios.int42: unknown function AH=3D0x0, AL=3D0x7, BL=3D0x0
> >>
> >> The above comes from some patches you added to the kernel ? You should
> >> probably do the softboot in the firmware instead...
> >
> > Yes. I'm using the videoboot-2.6x.patch (this patch contain also the
> > xf86emu from www.scitechsoft.com). With this pach the radeon card work
> > properly with 2.6.12 kernel version. On the 2.6.27 kernel the "videoboo=
t"
> > fetch the bios from the video card and start them in the xf86emu.
> >
> > Can I initialize the video card in uboot too?
>
> Yes, indeed you can. In a recent version of U-Boot, search for
> 'CONFIG_BIOSEMU' in include/configs/*. We tested this on a sequoia
> board, so include/configs/sequoia.h should be a good start for this.
Thanks.
I tried to include BIOSEMU and RADEON_FB in my u-boot. Bios emulator seems =
to=20
be properly loaded, but when u-boot attempt to read or write Radeon's=20
registers, the board freezes.
What means exactly the value of "VIDEO_IO_OFFSET" in the config file?=20
There is a u-boot's output when I init the VIDEO_IO_OFFSET with PCI's I/O b=
ase=20
address:
INFO : PCI0_IO : base - 0xd8000000 size - 1M bytes
INFO : PCI0_MEM0: base - 0x80000000 size - 1024M bytes
INFO : PCI0_MEM1: base - 0xc0000000 size - 128M bytes
INFO : PCI0_MEM2: base - 0xc8000000 size - 128M bytes
INFO : PCI0_MEM3: base - 0xd0000000 size - 128M bytes
=2E....
PCI Scan: Found Bus 0, Device 7, Function 0
PCI Scan: Found Bus 0, Device 7, Function 1
PCI Scan: Found Bus 0, Device 9, Function 0
PCI Scan: Found Bus 0, Device 10, Function 0
Video: ATI Radeon video card (1002, 5960) found @(0:7:0)
videoboot: Booting PCI video card bus 0, function 0, device 7
E 0000 0 F00P0F000NI00PMS0EG 0F00
and after that follows board reset.
Best regards.
Eduard Fuchs
^ permalink raw reply
* [PATCH] tracing: Fix TRACING_SUPPORT dependency
From: Anton Vorontsov @ 2009-03-20 15:09 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar; +Cc: linuxppc-dev, linux-kernel
commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean up
menu"), despite the "clean up" in its purpose, introduced behavioural
change for Kconfig symbols: we no longer able to select tracing
support on PPC32 (because IRQFLAGS_SUPPORT isn't yet implemented).
The IRQFLAGS_SUPPORT is not mandatory for most tracers, tracing core
has a special case for platforms w/o irqflags (which, by the way, has
become useless as of the commit above).
This patch restores the old behaviour, and thus brings the tracing
back on PPC32.
p.s.
The IRQSOFF_TRACER (which is the only tracer that requires IRQFLAGS
support) still depends on TRACE_IRQFLAGS_SUPPORT Kconfig symbol.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
kernel/trace/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ee70841..774aba7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -63,7 +63,6 @@ config TRACING
#
config TRACING_SUPPORT
bool
- depends on TRACE_IRQFLAGS_SUPPORT
depends on STACKTRACE_SUPPORT
default y
--
1.5.6.5
^ permalink raw reply related
* Re: suspend-to-mem on the mpc8349e-mitx-gp?
From: Scott Wood @ 2009-03-20 14:41 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev, Soohyung Cho
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED29EB95@zch01exm26.fsl.freescale.net>
Li Yang-R58472 wrote:
>> However, the code should treat "mem" as "standby" on chips
>> that don't support deep sleep. What does the device tree
>
> Well, shouldn't the valid() callback reject unsupported states instead
> of covering up?
I don't think so, in this case. The user is not asking for "sleep" or
deep sleep"; they are asking for a power state that meets the definition
of "standby" (which sleep does) or which meets the definition of "mem"
(which both sleep and deep sleep do). When the user asks for "mem", we
provide the lowest power mode that qualifies.
I'm willing to change it if there's substantial existing practice to the
contrary, though.
-Scott
^ 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