* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-30 8:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <jeir95j21k.fsf@sykes.suse.de>
Andreas Schwab writes:
> Is your assembler older than 4 years?
No, well, at least not unless Debian sid is seriously behind the
times. It's version 2.17 from the Debian binutils 2.17-3 package.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Andreas Schwab @ 2007-06-30 8:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <18053.65260.136499.154352@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Andreas Schwab writes:
>
>> The assembler should be called with -a64, which has the effect of
>> defaulting to -mppc64.
>
> Yes, the assembler is called with -a64, but that doesn't appear to
> have the effect of defaulting to -mppc64.
Is your assembler older than 4 years?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Michael Ellerman @ 2007-06-30 7:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183128867.1170.341.camel@pmac.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > + remain in bug-fix only mode until it's scheduled removal. Platforms
>
> http://www.angryflower.com/itsits.gif
Hahaha. Is there one for your as well?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-30 6:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Arnd Bergmann, amodra
In-Reply-To: <jelke2ss3n.fsf@sykes.suse.de>
Andreas Schwab writes:
> The assembler should be called with -a64, which has the effect of
> defaulting to -mppc64.
Yes, the assembler is called with -a64, but that doesn't appear to
have the effect of defaulting to -mppc64.
[Alan: this thread is about the fact that compiling C code with "gcc
-m64 -mcpu=powerpc64" will give assembler errors, complaining about
instructions like sldi, whereas compiling with "gcc -m64" doesn't.]
Paul.
^ permalink raw reply
* current-speed property in serial devices causes kernel panic
From: Timur Tabi @ 2007-06-30 4:26 UTC (permalink / raw)
To: linuxppc-dev list
I see this code in function of_platform_serial_setup():
static int __devinit of_platform_serial_setup(struct of_device *ofdev,
int type, struct uart_port *port)
{
struct resource resource;
struct device_node *np = ofdev->node;
const unsigned int *clk, *spd;
int ret;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
...
port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
There is no check in this code to make sure spd is not null. And sure enough, in most DTS files, current-speed does not exist. So whenever this function is called on a node like this, the kernel panics.
I'm adding support for a new 86xx platform, and I'm also creating a driver for a new SOC device. In my platform driver, I have this code:
static struct of_device_id mpc86xx_ids[] = {
{ .type = "soc", },
{}
};
static int __init mpc86xx_declare_of_platform_devices(void)
{
printk(KERN_ALERT "%s\n", __FUNCTION__);
if (!machine_is(mpc86xx_hpcn))
return 0;
of_platform_bus_probe(NULL, mpc86xx_ids, NULL);
return 0;
}
device_initcall(mpc86xx_declare_of_platform_devices);
The kernel panic occurs only if I call of_platform_bus_probe().
If you look at the code for the 836x platform, you'll see that it also has serial SOC devices and it also calls of_platform_bus_probe(), but it doesn't experience kernel panics.
Is the call to of_platform_bus_probe() effectively trying to probe the serial devices twice? I just don't understand why this code isn't working.
^ permalink raw reply
* A question about map_page
From: kang shuo @ 2007-06-30 3:31 UTC (permalink / raw)
To: linuxppc-embedded
hi:
I had read some ppc code in linux-2.6.20. There is a question
about map_page function. map_page seems to implement the map between
virtual address and physical address. But I can not understand how the
tlb entry operation is done in the code in map_page. The map_page is
as the following:
int
map_page(unsigned long va, phys_addr_t pa, int flags)
{
pmd_t *pd;
pte_t *pg;
int err = -ENOMEM;
/* Use upper 10 bits of VA to index the first level map */
pd = pmd_offset(pgd_offset_k(va), va);
/* Use middle 10 bits of VA to index the second-level map */
pg = pte_alloc_kernel(pd, va);
if (pg != 0) {
err = 0;
set_pte_at(&init_mm, va, pg, pfn_pte(pa >> PAGE_SHIFT,
__pgprot(flags)));
if (mem_init_done)
flush_HPTE(0, va, pmd_val(*pd));
}
return err;
}
Could anyone give me some hints about where and when tlb entry
is setup according to map_page function. That is very appreciate.
-- Thanks
-- Michael.Kang
^ permalink raw reply
* a question for ac97 driver interrupt
From: silicom @ 2007-06-30 1:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 254 bytes --]
Hi
I'm just adding interrupt function for my ac97 driver,but I don't know how to clear interrupt status in the interrupt handler,so it will cause nesting interrupt,can any one give me some advice about the structure of interrupt handle function?
[-- Attachment #2: Type: text/html, Size: 636 bytes --]
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Andy Fleming @ 2007-06-30 0:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <66B07304-BE33-4A9E-8C9C-BEC0BCEC79F8@kernel.crashing.org>
On Jun 27, 2007, at 17:51, Kumar Gala wrote:
>
>>>> What is the relationship between (in the example) the address
>>>> ranges x'f800_0000+1000 and x'f800_1000+ff000?
>>>
>>> uugh, not sure what that's all about.
>>
>> Reading back I see that the CCSR region is 1MB, and only the
>> first 4kB are for this PHB. What is the rest of this range
>> used for -- devices on this PCI bus, other SoC devices, ...?
>
> No, the first 4kB are SOC/platform level config registers (high
> level window setup, CCSR location, etc).
>
> The PHB registers are somewhere in the middle (0x8000, I think).
> All the children devices (enet, PHBs, etc) live in the 1M block.
>
> I think my original idea was the reg property on the SOC node was
> for the first 4k block that held the SOC config registers. I think
> what Wade did is correct since the reg property on the SOC node
> isnt going to get translated through the ranges property and that
> they should be mutually exclusive.
Ok, I'm thinking we don't need the reg property at all, or that it
can be of size 0 or 4 (the CCSRBAR, itself). If we need to access
registers in the first 4k, we can define reg properties for the
submodules which are in the CCSR space.
My issue with the submitted option is that the first 4k don't really
belong to an SOC "device", they are just the first 4k of registers.
In this case, they are the Local Access Window registers. It sort of
feels like we're arbitrarily deciding assigning the first 4k to the
"SOC". If that's what we want to do, I'd like if we put it in
booting-without-of.txt. Actually, it should go there, anyway.
Andy
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Andy Fleming @ 2007-06-29 23:54 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <1183116892.20673.66.camel@gentoo-jocke.transmode.se>
On Jun 29, 2007, at 06:34, Joakim Tjernlund wrote:
> mdio@2320 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2320 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> phy1: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <12 2>; //EXT IRQ2
> reg = <0>; // 0
> device_type = "ethernet-phy";
> interface = <3>; //ENET_100_MII
> };
>
> Now the things is that the IRQ works with and without the
> /* All external IRQs + Generic timer IRQs must be initialized by
> BSP */
> const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78,
> 84, 72};
> for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq = irq_create_mapping(NULL, bsp_irqs[i]);
This isn't how to use the device tree. That is, you *aren't* using
the device tree. You want to read the node of every device you want
to set up, and create the mapping. Look at irq_of_parse_and_map().
Look in include/asm-powerpc/prom.h, at of_irq_to_resource(), which
maps an irq in the device tree.
Andy
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-06-29 23:14 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <46853CA2.2040203@genesi-usa.com>
> Define "legacy device"? What should that entail? You mean like mapping
> most of those registers to the first couple of kilobytes of "IO"?
Anything that hard-decodes IOs in the low ISA range yes. That includes
VGA video cards.
> If they're just left as their own on their own as PCI devices, why would
> it matter what the window was?
Because quite a few of those things hard decodes (can't be moved around,
so -have- to be able to generate cycles to those low addresses to hit
them) and sometimes don't even fully decode the 32 bits addresses
(though that's more rare).
For example, a VGA video card in text mode hard decodes both IO and
Memory at the legacy VGA ranges.
Ben.
^ permalink raw reply
* Re: [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Segher Boessenkool @ 2007-06-29 22:45 UTC (permalink / raw)
To: will_schmidt; +Cc: willschm, LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1183150190.22547.62.camel@farscape.rchland.ibm.com>
> The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527
> for
> fixing problems with NULL gettimeofday input mistakenly checks for a
> null tz field twice, when it should be checking for null tz once, and
> null tv once; by way of a r10/r11 typo.
>
> Any application calling gettimeofday(&tv,NULL) will "fail".
>
> This corrects that typo, and makes my G5 happy.
>
> tested on G5.
>
>
> Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Obviously correct, how could we all have missed this :-(
Thanks Will.
Segher
^ permalink raw reply
* [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Will Schmidt @ 2007-06-29 20:49 UTC (permalink / raw)
To: willschm; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1183149584.22547.51.camel@farscape.rchland.ibm.com>
The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527 for
fixing problems with NULL gettimeofday input mistakenly checks for a
null tz field twice, when it should be checking for null tz once, and
null tv once; by way of a r10/r11 typo.
Any application calling gettimeofday(&tv,NULL) will "fail".
This corrects that typo, and makes my G5 happy.
tested on G5.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
cc: Tony Breeds <tony@bakeyournoodle.com>
cc: Ben Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S
index 2d7a510..c6401f9 100644
--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
@@ -31,7 +31,7 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
mr r11,r3 /* r11 holds tv */
mr r10,r4 /* r10 holds tz */
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
- cmpldi r10,0 /* check if tv is NULL */
+ cmpldi r11,0 /* check if tv is NULL */
beq 2f
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
^ permalink raw reply related
* Re: 2.6.22-rc6-mm1
From: Andrew Morton @ 2007-06-29 20:47 UTC (permalink / raw)
To: Mariusz Kozlowski, Jason Wessel, Michal Marek
Cc: xfs-masters, xfs, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <200706291432.10128.m.kozlowski@tuxland.pl>
On Fri, 29 Jun 2007 14:32:09 +0200
Mariusz Kozlowski <m.kozlowski@tuxland.pl> wrote:
> Hello,
>
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
>
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
> in .config. Unselect one of them.
> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
Jason cc'ed
> anyway after unselecting XMON we can see:
>
> CC [M] fs/xfs/linux-2.6/xfs_ioctl32.o
> fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat'
> undeclared (first use in this function)
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is
> reported only once
> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
> make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
> make[1]: *** [fs/xfs] Blad 2
>
> This is just allmodconfig - not a .config that's used daily by users but I'm
> used to compiling the kernel using it anyway 8)
>
Michal cc'ed. I think this is the one which was already reported but
I haven't seen a fix yet?
^ permalink raw reply
* Re: [PATCH v2] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Will Schmidt @ 2007-06-29 20:39 UTC (permalink / raw)
To: Tony Breeds, will_schmidt; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20070625235032.GH9768@bakeyournoodle.com>
On Tue, 2007-06-26 at 09:50 +1000, Tony Breeds wrote:
> Updated to include feedback from Ben and Segher, also reposition the
> compare in the 64bit VDSO to catch all the references to tv.
> --- working.orig/arch/powerpc/kernel/vdso64/gettimeofday.S
> +++ working/arch/powerpc/kernel/vdso64/gettimeofday.S
<snippage>
> @@ -32,6 +31,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> mr r11,r3 /* r11 holds tv */
> mr r10,r4 /* r10 holds tz */
> bl V_LOCAL_FUNC(__get_datapage) /* get data page */
> + cmpldi r10,0 /* check if tv is NULL */
Whoops! r10 holds tz value, not tv. This should be r11.
As is, a (64-bit) userspace app calling gettimeofday(&tv,NULL); will
"silently fail", and the application is left using whatever old data
happens to be in the tv structure.
This affected my G5 (gentoo), most noticable when apps like 'ping' and
nfs-mounts quit working properly. :-)
patch follows momentarily...
> + beq 2f
> bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
> lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
> ori r7,r7,16960
> @@ -43,8 +44,8 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> * XSEC_PER_SEC
> */
> rldicl r0,r0,44,20
> - cmpldi cr0,r10,0 /* check if tz is NULL */
> std r0,TVAL64_TV_USEC(r11) /* store usec in tv */
> +2: cmpldi r10,0 /* check if tz is NULL */
> beq 1f
> lwz r4,CFG_TZ_MINUTEWEST(r3)/* fill tz */
> lwz r5,CFG_TZ_DSTTIME(r3)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-29 19:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18051.22185.374607.755419@cargo.ozlabs.ibm.com>
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> Looks OK, but the first of those two patches doesn't have a
> Signed-off-by: line, and the description is not suitable.
>
> Please repost that patch with a nice description that describes what
> the patch does and why, without references to other web pages. You
> don't need to describe what is different from previous patches or who
> suggested those changes.
Ok, just reposted. I even used the original subject line and the
description from Scott's email. I also removed the part for
drivers/i2c/busses/i2c-mpc.c - it is a separate patch
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036079.html and I hope
it'll make it in either via ppc or via i2c tree (it was cc'ed) as well as
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html (sorry,
Paul, for links again).
Speaking about i2c@lm-sensors.org - which way should these patches go? Is
it the usual separation drivers/i2c goes via i2c and arch/powerpc via ppc?
Or should I also email i2c folks to tell them not to use the original
patch from Scott?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-06-29 19:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Add of_register_i2c_devices(), which scans the children of the specified
I2C adapter node, and registers them with the I2C code.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..9caf96d 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -1067,3 +1067,49 @@ void __iomem *of_iomap(struct device_node *np, int index)
return ioremap(res.start, 1 + res.end - res.start);
}
EXPORT_SYMBOL(of_iomap);
+
+#ifdef CONFIG_I2C
+#include <linux/i2c.h>
+
+void of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *name, *model;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ name = of_get_property(node, "compatible", NULL);
+ if (!name)
+ name = node->name;
+ if (!name)
+ continue;
+
+ model = of_get_property(node, "model", NULL);
+ if (!model)
+ model = name;
+
+ /* FIXME: the i2c code should allow drivers to specify
+ * multiple match names; board code shouldn't need to
+ * know what driver will handle a given type.
+ */
+
+ snprintf(info.driver_name, KOBJ_NAME_LEN, name);
+ snprintf(info.type, KOBJ_NAME_LEN, model);
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+#endif /* CONFIG_I2C */
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..ed085e1 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -305,6 +305,7 @@ extern int of_irq_map_raw(struct device_node *parent, const u32 *intspec,
u32 ointsize, const u32 *addr,
struct of_irq *out_irq);
+void of_register_i2c_devices(struct device_node *adap_node, int bus_num);
/**
* of_irq_map_one - Resolve an interrupt for a device
^ permalink raw reply related
* [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-06-29 18:49 UTC (permalink / raw)
To: 'linuxppc-dev Development', Netdev, Li Yang-r58472
This patch makes the PHY optional for ucc_geth.c ethernet driver.
This is useful to support a direct mii to mii connection to, for example,
a onboard swicth.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
----
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2273,7 +2273,8 @@ static void ucc_geth_stop(struct ucc_geth_private *ugeth)
ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
/* Tell the kernel the link is down */
- phy_stop(phydev);
+ if (phydev)
+ phy_stop(phydev);
/* Mask all interrupts */
out_be32(ugeth->uccf->p_ucce, 0x00000000);
@@ -3687,14 +3688,16 @@ static int ucc_geth_open(struct net_device *dev)
dev->dev_addr[5],
&ugeth->ug_regs->macstnaddr1,
&ugeth->ug_regs->macstnaddr2);
-
- err = init_phy(dev);
+ err = 0;
+ if (ugeth->ug_info->mdio_bus != ~0)
+ err = init_phy(dev);
if (err) {
ugeth_err("%s: Cannot initialize PHY, aborting.", dev->name);
return err;
}
- phy_start(ugeth->phydev);
+ if (ugeth->phydev)
+ phy_start(ugeth->phydev);
err =
request_irq(ugeth->ug_info->uf_info.irq, ucc_geth_irq_handler, 0,
@@ -3726,8 +3729,9 @@ static int ucc_geth_close(struct net_device *dev)
ugeth_vdbg("%s: IN", __FUNCTION__);
ucc_geth_stop(ugeth);
-
- phy_disconnect(ugeth->phydev);
+
+ if (ugeth->phydev)
+ phy_disconnect(ugeth->phydev);
ugeth->phydev = NULL;
netif_stop_queue(dev);
@@ -3807,17 +3811,16 @@ 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);
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
-
- if (phy == NULL)
- return -ENODEV;
-
- /* set the PHY address */
- prop = of_get_property(phy, "reg", NULL);
- if (prop == NULL)
- return -1;
- ug_info->phy_address = *prop;
-
+ if (ph != NULL) {
+ phy = of_find_node_by_phandle(*ph);
+ if (phy == NULL)
+ return -ENODEV;
+ /* set the PHY address */
+ prop = of_get_property(phy, "reg", NULL);
+ if (prop == NULL)
+ return -1;
+ ug_info->phy_address = *prop;
+ }
/* get the phy interface type, or default to MII */
prop = of_get_property(np, "phy-connection-type", NULL);
if (!prop) {
@@ -3857,19 +3860,22 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.utftt = UCC_GETH_UTFTT_GIGA_INIT;
}
- /* Set the bus id */
- mdio = of_get_parent(phy);
+ ug_info->mdio_bus = ~0; /* Means no MDIO bus */
+ if (ph) {
+ /* Set the bus id */
+ mdio = of_get_parent(phy);
- if (mdio == NULL)
- return -1;
+ if (mdio == NULL)
+ return -1;
- err = of_address_to_resource(mdio, 0, &res);
- of_node_put(mdio);
+ err = of_address_to_resource(mdio, 0, &res);
+ of_node_put(mdio);
- if (err)
- return -1;
+ if (err)
+ return -1;
- ug_info->mdio_bus = res.start;
+ ug_info->mdio_bus = res.start;
+ }
printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq = %d) \n",
ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
^ permalink raw reply related
* Re: for-2.6.23 branch in powerpc.git created
From: Scott Wood @ 2007-06-29 17:35 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706282058100.5368@poirot.grange>
On Thu, Jun 28, 2007 at 09:01:58PM +0200, Guennadi Liakhovetski wrote:
> Sure, no problem, will repost with a description and a Signed-off-by...
> but, not giving Scott Wood credit for that patch doesn't seem right.
> Scott, is it ok with you if I repost that patch with your "Signed-off-by"
> first and mine second?
Sure.
-Scott
^ permalink raw reply
* Re: [PATCH] Schedule removal of arch/ppc
From: Mark A. Greer @ 2007-06-29 17:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183130082.1170.344.camel@pmac.infradead.org>
On Fri, Jun 29, 2007 at 04:14:42PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> > That's it? I'm scheduling the demise of an entire architecture
> > sub-tree and the only comment you can make is about a superfluous
> > apostrophe? ;)
>
> Sorry, allow me to rephrase...
>
> http://www.angryflower.com/itsits.gif
> DIE arch/ppc DIE!
I second that motion. ;)
^ permalink raw reply
* Re: PCI IO range limitation
From: Matt Sealey @ 2007-06-29 17:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <1183075997.5521.292.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>>>> Hi,
>>>>
>>>> Trying to change PCI IO window base for 52xx target I found that
>>>> we are pretty much limited to a "0" offset only.
>>> We just fixed that for 64 bits but 32 bits still has the limitation.
>>> Note that it's not a very good idea to have your IO range at !0 if
>>> you're going to use anything ISA-like, such as a VGA video card or other
>>> legacy devices behind a PCI southbridge or SuperIO.
>> The chances of that on an MPC52xx platform are practically zero, aren't
>> they?
>
> Euh... don't you use VGA video cards on Efika ? :-)
Define "legacy device"? What should that entail? You mean like mapping
most of those registers to the first couple of kilobytes of "IO"?
If they're just left as their own on their own as PCI devices, why would
it matter what the window was?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* RE: mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-06-29 16:54 UTC (permalink / raw)
To: Muruga Ganapathy, Pradyumna Sampath, linuxppc-embedded
In-Reply-To: <200706291648.l5TGmSS17074@sierra.gdatech.com>
Thanks for the reply.
I believe that the EEPROM is programmed correctly. At lease the driver
seems to think so. I am still leaning towards the interrupts not being
properly initialized on the PCI bus. I am currently trying to track
this down. =20
Here's the output of what I have for one of the Ethernet controllers.
# cat /proc/interrupts
CPU0 =20
20: 0 CPM2 SIU Level eth0
24: 0 CPM2 SIU Level PQ2 PCI cascade
40: 154 CPM2 SIU Level cpm_uart
BAD: 0
# lspci -vvv
00:12.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast
Ethernet Controller (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=3Dmedium =
>TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min, 14000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 20
Region 0: Memory at 00000000affff000 (32-bit, non-prefetchable)
[size=3D4K]
Region 1: I/O ports at 1ffffc0 [size=3D64]
Region 2: Memory at 00000000affc0000 (32-bit, non-prefetchable)
[size=3D128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=3D0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=3D0 DScale=3D2 PME-
ethtool -e eth0
Offset Values
------ ------
0x0000 00 50 c2 70 7a 01 80 a1 ff ff 01 02 01 47 ff ff=20
0x0010 ff ff ff ff a0 d0 00 00 00 00 ff ff ff ff ff ff=20
0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff=20
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 92 3d=20
Thanks again,
-Nick
-----Original Message-----
From: Muruga Ganapathy [mailto:gmuruga@gdatech.com]=20
Sent: Friday, June 29, 2007 12:48 PM
To: Pradyumna Sampath; Nicholas Hickman; linuxppc-embedded@ozlabs.org
Subject: Re: mpc8270 & Intel 82551ER on 2.6.17.14
1. You may want to check whether the device is configured properly by
enabling the debug statements or using the lspci command. I mean the=20
BAR registers.
2. Also check whether correct the interrupt is assigned to the=20
device using cat /proc/interrupts command under linux.=20
3. As far as the EEPROM is concerned, you need to enable debug to check=20
whether there is any check sum error. If there is a check sum error=20
in EEPROM, the device may not come up too. As you are using it in=20
powerpc platform, you need to take care of the endianess while=20
writing to the EEPROM.
Hope this helps!
Thanks
G.Muruganandam
> Hi Nicholas,
>=20
> On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
> >
> >
> > I am having trouble getting two 82551ER Ethernet controllers
running in
> > Linux. I am able to scan the PCI bus and see the devices and I was
even
> > able to program the EEPROM from U-boot.
> >
> > In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. =20
I've been
> > using the e100 drive that comes with the 2.6.17.14 kernel and have
also
> > tried the driver directly from Intel. Both give the same results. =20
The PCI
> > scan shows the correct output for how the device should be
configured.
> <snip..>
>=20
> I have the same, exact same problem. But there are some of the=20
> differences with the setup though. I have an MPC5200B and the other=20
> difference is that I have a 2.6.21-rt3. However its the same ethernet=20
> controller.
>=20
> I am trying out a few things here, some of them being complete=20
> guesses. But if I hit something, I will let this list know. Anyone=20
> else had similar issues ? Request you to please holler.
>=20
> regards
> prady
> --
> htp://prady.livejournal.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
*************************************************************
GDA Technologies, Inc. =09
1010 Rincon Circle
San Jose CA, 95131
Phone (408) 432-3090
Fax (408) 432-3091
Accelerate Your Innovation=09
**************************************************************
=3D=3D=3D=3D=3D
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the sender
immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
=3D=3D=3D=3D
^ permalink raw reply
* Re: 83xx: requesting external interrupts
From: Ben Warren @ 2007-06-29 16:43 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <1183116892.20673.66.camel@gentoo-jocke.transmode.se>
Hi Jocke,
On Fri, 2007-06-29 at 13:34 +0200, Joakim Tjernlund wrote:
<snip>
> I too am adding such a IRQ for my PHY connected to external IRQ2.
> The PHY is connetced to UCC2.
> I have this in my DTS for the PHY:
> mdio@2320 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2320 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> phy1: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <12 2>; //EXT IRQ2
> reg = <0>; // 0
> device_type = "ethernet-phy";
> interface = <3>; //ENET_100_MII
> };
>
> Now the things is that the IRQ works with and without the
> /* All external IRQs + Generic timer IRQs must be initialized by BSP */
> const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, 72};
> for (i=0;i<sizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
> virq = irq_create_mapping(NULL, bsp_irqs[i]);
> code in my bsp. There is one difference though.
> Printing the irq num in phy_interrupt:
> static irqreturn_t phy_interrupt(int irq, void *dev_id)
> {
> struct net_device *dev = (struct net_device *)dev_id;
> struct ucc_geth_private *ugeth = netdev_priv(dev);
>
> ugeth_vdbg("%s: IN", __FUNCTION__);
> printk(KERN_ERR "PHY IRQ:%d \n", irq);
>
> Shows a difference:
> with the bsp code added it prints:
> PHY IRQ:18
> and when I remove the bsp code it prints:
> PHY IRQ:19
>
> So what is correct, should I add the bsp code or not?
>
> Jocke
I had to add this board initialization code because on my CPU (8349),
certain interrupts weren't automatically mapped by built-in kernel code.
Interrupts simply weren't firing, because they hadn't been enabled in
the IPIC. Your case is different, because the MDIO device tree entry is
parsed by common code (arch/powerpc/sysdev/something).
You probably don't need to explicitly map IRQs unless they're being used
by custom device drivers. I don't know why you'd get a different
virtual mapping, though. I guess you're effectively mapping the same
IRQ twice, and I don't know what that does. Part of me wants to say "if
it works properly, who cares", but that's how we get into trouble...
Somebody like Kumar Gala could probably provide a real answer.
regards,
Ben
^ permalink raw reply
* Re: mpc8270 & Intel 82551ER on 2.6.17.14
From: Muruga Ganapathy @ 2007-06-29 16:48 UTC (permalink / raw)
To: Pradyumna Sampath, Nicholas Hickman, linuxppc-embedded
1. You may want to check whether the device is configured properly by
enabling the debug statements or using the lspci command. I mean the
BAR registers.
2. Also check whether correct the interrupt is assigned to the
device using cat /proc/interrupts command under linux.
3. As far as the EEPROM is concerned, you need to enable debug to check
whether there is any check sum error. If there is a check sum error
in EEPROM, the device may not come up too. As you are using it in
powerpc platform, you need to take care of the endianess while
writing to the EEPROM.
Hope this helps!
Thanks
G.Muruganandam
> Hi Nicholas,
>
> On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
> >
> >
> > I am having trouble getting two 82551ER Ethernet controllers
running in
> > Linux. I am able to scan the PCI bus and see the devices and I was
even
> > able to program the EEPROM from U-boot.
> >
> > In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c.
I've been
> > using the e100 drive that comes with the 2.6.17.14 kernel and have
also
> > tried the driver directly from Intel. Both give the same results.
The PCI
> > scan shows the correct output for how the device should be
configured.
> <snip..>
>
> I have the same, exact same problem. But there are some of the
> differences with the setup though. I have an MPC5200B and the other
> difference is that I have a 2.6.21-rt3. However its the same ethernet
> controller.
>
> I am trying out a few things here, some of them being complete
> guesses. But if I hit something, I will let this list know. Anyone
> else had similar issues ? Request you to please holler.
>
> regards
> prady
> --
> htp://prady.livejournal.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
*************************************************************
GDA Technologies, Inc.
1010 Rincon Circle
San Jose CA, 95131
Phone (408) 432-3090
Fax (408) 432-3091
Accelerate Your Innovation
**************************************************************
=====
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the
sender immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
====
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 16:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200706291805.42528.arnd@arndb.de>
On Jun 29, 2007, at 11:05 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Kumar Gala wrote:
>>> Would it work reliably if we switch the arguments to
>>> '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
>>> might be better than taking it out entirely.
>>
>> Is there a reason you didn't use -mcpu=power3 and -mcpu=rs64 for
>> those to CPU options?
>
> Not an important one. From looking at gcc source, it seemed to
> me that power3, rs64 and powerpc64 all specify the same instruction
> set, so I went for the most generic one.
>
> I guess we could always pass -mcpu=power3 instead of -mcpu=powerpc64
> if that solves the problem.
Also, Paul asked for some Kconfig help to be added to
PPC_CPU_SELECTION & CPU_DEFAULT
- k
^ permalink raw reply
* Re: [patch] powerpc: sysfs fix compiler warning
From: Christian Krafft @ 2007-06-29 16:10 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200706291657.20942.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]
On Fri, 29 Jun 2007 16:57:20 +0200
Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
> > From: Christian Krafft <krafft@de.ibm.com>
> >
> > This patch fixes the following compiler warning:
> > arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> > `sysfs_create_group',
> >
> > Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> >
> > --- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
> > +++ linux-2.6/arch/powerpc/kernel/sysfs.c
> > @@ -380,16 +380,25 @@ int cpu_add_sysdev_attr_group(struct att
> > {
> > int cpu;
> > struct sys_device *sysdev;
> > + int error = 0;
> >
> > mutex_lock(&cpu_mutex);
> >
> > for_each_possible_cpu(cpu) {
> > sysdev = get_cpu_sysdev(cpu);
> > - sysfs_create_group(&sysdev->kobj, attrs);
> > + error = sysfs_create_group(&sysdev->kobj, attrs);
> > +
> > + if (error) {
> > + for_each_possible_cpu(cpu) {
> > + sysdev = get_cpu_sysdev(cpu);
> > + sysfs_remove_group(&sysdev->kobj, attrs);
>
> Is sysfs_remove_group() safe to call on kobjs for which
> we did not call sysfs_create_group()?
I only looked into it a little and haven't seen a problem.
From the interface point of view I would say it would be a bug, if it's not safe.
But I will do a short test on this.
>
> > + }
> > + break;
> > + }
> > }
> >
> > mutex_unlock(&cpu_mutex);
> > - return 0;
> > + return error;
> > }
> > EXPORT_SYMBOL_GPL(cpu_add_sysdev_attr_group);
> >
> >
> >
>
>
>
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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