* Re: DTC sources move
From: Jon Loeliger @ 2009-03-27 18:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, monstr, devicetree-discuss, David Gibson
In-Reply-To: <fa686aa40903270857g7f1a3b64y93067cba5a7a6a28@mail.gmail.com>
> On Fri, Mar 27, 2009 at 8:16 AM, Michal Simek <monstr@monstr.eu> wrote:
> > Hi Ben,
> >
> > could you please move DTC to any generic location. I would like to use it f
> or Microblaze cpu too.
>
> Michal,
>
> David Gibson is the one responsible for the in-tree dtc source, not
> Ben, and you should prepare the patches yourself to move dtc.
And, I might add, please update it from its main repo in the process...
jdl
^ permalink raw reply
* Re: Chipselect in SPI binding with mpc5200-psc-spi
From: Yann Pelletier @ 2009-03-27 21:14 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]
I'm trying to do the same sort of thing
On Fri, Feb 13, 2009 at 3:40 AM, Henk Stegeman <henk.stegeman at gmail.com<https://ozlabs.org/mailman/listinfo/linuxppc-dev>> wrote:
> I'm busy adding support for slave deviced behind mpc52xx-psc-spi.
> One complication I have is that my SPI slave device has an interrupt output
> to the CPU.
> My idea is to add it as a gpios property in the slave device's
> configuration:
>
> spi at 2400<https://ozlabs.org/mailman/listinfo/linuxppc-dev> { // PSC3 (SPI IF to the IO-controller )
> device_type = "spi";
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mpc5200-psc-spi","fsl,mpc5200b-psc-spi";
> cell-index = <2>;
> reg = <0x2400 0x100>;
> interrupts = <2 3 0>;
> interrupt-parent = <&mpc5200_pic>;
> gpios = <&gpt4 0 0>;
>
> io-controller at 0<https://ozlabs.org/mailman/listinfo/linuxppc-dev> {
> compatible = "microkey,smc4000io";
> spi-max-frequency = <1000000>;
> reg = <0>;
> // gpios: first is IRQ to cpu
> gpios = <&gpt6 0 0>;
> };
There is a better way to do this, and driver support for it is
currently merged into Ben Herrenschmidt's -next tree.
Do this instead:
io-controller at 0<https://ozlabs.org/mailman/listinfo/linuxppc-dev> {
compatible = "microkey,smc4000io";
spi-max-frequency = <1000000>;
reg = <0>;
interrupt-controller = < &gpt6 >; // Use GPT6 as
the IRQ controller
interrupts = < 1 >; // And make it rising edge.
};
Then add these two properties to the GPT node:
interrupt-controller;
#interrupt-cells = <1>;
Then you can use normal irq_of_parse_and_map() to set up your handler.
> How should I then register my spi slave driver? My smc4000io_probe function
> gets called correctly by of_spi support but when I register as follows:
>
> static struct spi_driver smc4000io_driver = {
> .driver = {
> .name = "smc4000io",
> .bus = &spi_bus_type,
> .owner = THIS_MODULE,
> },
> .probe = smc4000io_probe,
> .remove = __devexit_p(smc4000io_remove),
> };
>
> static int __init smc4000io_init(void)
> {
> return spi_register_driver(&smc4000io_driver);
> }
>
> static void __exit smc4000io_exit(void)
> {
> spi_unregister_driver(&smc4000io_driver);
> }
>
> module_init(smc4000io_init);
Yes, this is right. The psc_spi driver automatically registers all
spi children that it finds in the device tree onto the SPI bus.
Therefore registering an spi_driver() is the right thing to do.
> But when I do:
>
> static struct of_platform_driver smc4000_spi_of_driver = {
> .name = "smc4000io",
> .match_table = smc4000io_of_match,
> .probe = smc4000io_of_probe,
> .remove = __devexit_p(smc4000io_of_remove),
> };
>
> static int __init smc4000io_init(void)
> {
> return of_register_platform_driver(&smc4000_spi_of_driver);
> }
> module_init(smc4000io_init);
>
> Then my smc4000io_of_probe function never gets called.
Correct. of_platform_driver isn't useful in this case because the
device cannot exist independently of the SPI bus. Plus an
of_platform_device doesn't provide any information about the SPI bus
itself.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[-- Attachment #2: Type: text/html, Size: 28370 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI context.
From: David Miller @ 2009-03-27 21:55 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-dev, leoli, pku.leo, netdev
In-Reply-To: <OF073D5C49.F0D791DE-ONC1257586.0040163D-C1257586.00413F47@transmode.se>
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Fri, 27 Mar 2009 12:52:41 +0100
> pku.leo@gmail.com wrote on 27/03/2009 11:50:09:
> > It doesn't make sense to have larger napi budget than the size of RX
> > BD ring. You can't have more BDs than RX_BD_RING_LEN in backlog for
> > napi_poll to process. Increase the RX_BD_RING_LEN if you want to
> > increase UCC_GETH_DEV_WEIGHT. However please also provide the
> > performance comparison for this kind of change. Thanks
>
> Bring it up with David Miller.
Right I told him to make this very change.
Pretty soon the driver's won't be able to select this value
and it will default to 64 everwhere anyways.
"performance comparison"? He can't do that unless he tests
performance with two active NAPI devices on the same exact
cpu as the weight value is for fairness between devices.
So you don't tweak "weight" to make one device perform better,
you tweak it to eliminate unfairness between multiple devices.
And the only way to achieve that is to use similar values
across all devices, perhaps link-speed rated which we can't
do just yet, and that's why I told him to use 64 just like
every other driver basically does.
^ permalink raw reply
* Re: Q: define i2c nodes in device tree?
From: Timur Tabi @ 2009-03-27 22:07 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <17008330.1238159104446.JavaMail.ngmail@webmail11.arcor-online.net>
On Fri, Mar 27, 2009 at 8:05 AM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> Now the driver is called, but complains that no platform data is present.=
=A0Still have to figure out how to pass that... :-/
I believe there was code added recently to i2c-mpc.c to put DTS
properties into the platform device, but I don't see it right now.
> # ls -al /sys/devices/f0000000.soc5200/f0003d40.i2c/i2c-adapter/i2c-1/
> drwxr-xr-x =A0 =A06 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 .
> drwxr-xr-x =A0 =A03 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 ..
> drwxr-xr-x =A0 =A02 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 1-0020
> drwxr-xr-x =A0 =A02 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 1-0021
> drwxr-xr-x =A0 =A02 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 1-0022
> [...]
>
> Is this the intended behaviour?
I think the entries in /sys/devices/f0000000.soc5200 are from the
device tree directly. They're not related to any device driver. I
believe you'll find those entries still there even if your driver
isn't loaded at all.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Please pull from 'next' branch
From: Kumar Gala @ 2009-03-27 22:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 68 -
arch/powerpc/boot/dts/asp834x-redboot.dts | 82 -
arch/powerpc/boot/dts/gef_ppc9a.dts | 39
arch/powerpc/boot/dts/gef_sbc310.dts | 39
arch/powerpc/boot/dts/gef_sbc610.dts | 39
arch/powerpc/boot/dts/ksi8560.dts | 79 -
arch/powerpc/boot/dts/mpc8313erdb.dts | 11
arch/powerpc/boot/dts/mpc8315erdb.dts | 80 -
arch/powerpc/boot/dts/mpc8349emitx.dts | 69 -
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 42
arch/powerpc/boot/dts/mpc834x_mds.dts | 81 -
arch/powerpc/boot/dts/mpc8377_mds.dts | 148 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 165 +-
arch/powerpc/boot/dts/mpc8378_mds.dts | 146 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 165 +-
arch/powerpc/boot/dts/mpc8379_mds.dts | 147 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 164 +-
arch/powerpc/boot/dts/mpc8536ds.dts | 78 -
arch/powerpc/boot/dts/mpc8540ads.dts | 117 +
arch/powerpc/boot/dts/mpc8541cds.dts | 78 -
arch/powerpc/boot/dts/mpc8544ds.dts | 81 -
arch/powerpc/boot/dts/mpc8548cds.dts | 156 +-
arch/powerpc/boot/dts/mpc8555cds.dts | 78 -
arch/powerpc/boot/dts/mpc8560ads.dts | 102 -
arch/powerpc/boot/dts/mpc8568mds.dts | 102 -
arch/powerpc/boot/dts/mpc8572ds.dts | 150 +-
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 150 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 39
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 157 +-
arch/powerpc/boot/dts/sbc8349.dts | 80 -
arch/powerpc/boot/dts/sbc8548.dts | 78 -
arch/powerpc/boot/dts/sbc8560.dts | 100 -
arch/powerpc/boot/dts/sbc8641d.dts | 156 +-
arch/powerpc/boot/dts/socrates.dts | 338 +++++
arch/powerpc/boot/dts/stx_gp3_8560.dts | 78 -
arch/powerpc/boot/dts/tqm8540.dts | 117 +
arch/powerpc/boot/dts/tqm8541.dts | 90 -
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 168 +-
arch/powerpc/boot/dts/tqm8548.dts | 168 +-
arch/powerpc/boot/dts/tqm8555.dts | 90 -
arch/powerpc/boot/dts/tqm8560.dts | 90 -
arch/powerpc/configs/85xx/socrates_defconfig | 1410 ++++++++++++++++++++++++
arch/powerpc/platforms/83xx/asp834x.c | 1
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1
arch/powerpc/platforms/83xx/mpc837x_mds.c | 1
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1
arch/powerpc/platforms/83xx/sbc834x.c | 1
arch/powerpc/platforms/85xx/Kconfig | 6
arch/powerpc/platforms/85xx/Makefile | 1
arch/powerpc/platforms/85xx/ksi8560.c | 1
arch/powerpc/platforms/85xx/mpc8536_ds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 1
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1
arch/powerpc/platforms/85xx/sbc8548.c | 1
arch/powerpc/platforms/85xx/sbc8560.c | 1
arch/powerpc/platforms/85xx/socrates.c | 133 ++
arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 327 +++++
arch/powerpc/platforms/85xx/socrates_fpga_pic.h | 16
arch/powerpc/platforms/85xx/stx_gp3.c | 1
arch/powerpc/platforms/85xx/tqm85xx.c | 1
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1
arch/powerpc/platforms/86xx/gef_sbc310.c | 1
arch/powerpc/platforms/86xx/gef_sbc610.c | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1
arch/powerpc/platforms/86xx/sbc8641d.c | 1
69 files changed, 4507 insertions(+), 1813 deletions(-)
Anton Vorontsov (4):
powerpc/83xx: Add power management support for MPC837x boards
powerpc/83xx: Move gianfar mdio nodes under the ethernet nodes
powerpc/85xx: Move gianfar mdio nodes under the ethernet nodes
powerpc/86xx: Move gianfar mdio nodes under the ethernet nodes
Kumar Gala (1):
powerpc/83xx: Update ranges in gianfar node to match other dts
Timur Tabi (1):
powerpc: clean up ssi.txt, add definition for fsl,ssi-asynchronous
Wolfgang Grandegger (1):
powerpc/85xx: Add support for the "socrates" board (MPC8544).
^ permalink raw reply
* Re: [PATCH] ucc_geth: Fix three oopses in PHY {de,}initialization code
From: David Miller @ 2009-03-27 23:00 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, leoli, Joakim.Tjernlund, linuxppc-dev
In-Reply-To: <20090327174047.GA23111@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Fri, 27 Mar 2009 20:40:47 +0300
> When there are no free snums, UCC ethernet should gracefully fail, but
> currently it oopses this way:
...
> Also, when device tree specifies fixed-link, and CONFIG_FIXED_PHY
> is disabled, we'll get this oops:
...
> This patch fixes all three oopses simply by rearranging some code:
>
> - In ucc_geth_open(): move init_phy() call to the beginning, so
> that we only call ucc_geth_stop() with a PHY attached;
> - Move phy_disconnect() call from ucc_geth_close() to
> ucc_geth_stop(), so that we'll always disconnect the PHY.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks Anton.
^ permalink raw reply
* Re: CONFIG_DEBUG_PAGEALLOC generates WARN_ON() in ppc32 hash
From: Benjamin Herrenschmidt @ 2009-03-27 23:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC Mailing List
In-Reply-To: <765C1EA1-93F7-4FEF-930B-78E2B3DEB4FA@kernel.crashing.org>
On Fri, 2009-03-27 at 06:56 -0500, Kumar Gala wrote:
> Ben,
>
> If we have CONFIG_DEBUG_PAGEALLOC enabled we end up hitting the
> WARN_ON() in set_pte_at() when we boot. This appears because we've
> already setup pte's via mapin_ram() after which we end up calling
> kernel_map_pages().
>
> So I'm not sure if __change_page_attr() should be doing something
> different or if the WARN_ON() should be conditional on !
> CONFIG_DEBUG_PAGEALLOC
Or use __set_pte_at() ?
Note that C_D_P doesn't work on hash32 anyway...
Ben.
^ permalink raw reply
* Re: Q: define i2c nodes in device tree?
From: David Gibson @ 2009-03-27 23:06 UTC (permalink / raw)
To: Albrecht Dre�; +Cc: linuxppc-dev
In-Reply-To: <17008330.1238159104446.JavaMail.ngmail@webmail11.arcor-online.net>
On Fri, Mar 27, 2009 at 02:05:04PM +0100, Albrecht Dre� wrote:
> Hi Timur:
>
> > You need to have a "gpio I2C" device driver that registers the same name as what's in the DTS, like this:
>
> Thanks, that did the trick; a proper naming is apparently
>
> pca8575:gpio@20 {
> compatible = "nxp,pca8575";
> device_type = "gpio";
There shouldn't be device_type here, though.
> reg = <0x20 1>;
> };
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DTC sources move
From: David Gibson @ 2009-03-27 23:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, monstr
In-Reply-To: <fa686aa40903270857g7f1a3b64y93067cba5a7a6a28@mail.gmail.com>
On Fri, Mar 27, 2009 at 09:57:25AM -0600, Grant Likely wrote:
> On Fri, Mar 27, 2009 at 8:16 AM, Michal Simek <monstr@monstr.eu> wrote:
> > Hi Ben,
> >
> > could you please move DTC to any generic location. I would like to use it for Microblaze cpu too.
>
> Michal,
>
> David Gibson is the one responsible for the in-tree dtc source, not
> Ben, and you should prepare the patches yourself to move dtc.
No, I'll do it myself. As Jon says, we should update to a more recent
upstream dtc at the same time and in any case I'll need to update my
scripts for importing dtc into the kernel tree.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Anton Vorontsov @ 2009-03-28 10:48 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <1237607369.17367.7.camel@localhost.localdomain>
On Fri, Mar 20, 2009 at 11:49:29PM -0400, Steven Rostedt wrote:
> Ben,
>
> Can you ACK this patch? Or even take it in your tree?
Benjamin, have you had a chance to look into this? Sam, could
you also take a look?
Thanks!
> On Fri, 2009-03-20 at 19:44 +0300, Anton Vorontsov wrote:
> > 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
>
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: Joakim Tjernlund @ 2009-03-28 11:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: netdev, linuxppc-dev, timur.tabi, leoli, David Miller
In-Reply-To: <ed82fe3e0903271150v34fc18cbua6bb7918a3a71c71@mail.gmail.com>
timur.tabi@gmail.com wrote on 27/03/2009 19:50:30:
>
> On Tue, Mar 24, 2009 at 6:08 PM, Joakim Tjernlund
> <Joakim.Tjernlund@transmode.se> wrote:
>
> > + .ndo_change_mtu = eth_change_mtu,
>
> I have an old patch for change_mtu support for ucc_geth which I've
> been meaning to push upstream. This patch uses this function instead
> of eth_change_mtu():
>
> +static int ucc_geth_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + int max_rx_buf_length;
> + struct ucc_geth_private *ugeth = netdev_priv(dev);
> + int frame_size = new_mtu + 18;
> + struct ucc_geth_info *ug_info;
> + struct ucc_fast_info *uf_info;
> +
> + if (ugeth->p_rx_glbl_pram) {
> + printk("%s: Interface is active!\n", __FUNCTION__);
> + } else {
> +
> + ug_info = ugeth->ug_info;
> + uf_info = &ug_info->uf_info;
> +
> + if ((frame_size < 64) || (frame_size > JUMBO_FRAME_SIZE)) {
> + printk(KERN_ERR "%s: Invalid MTU setting\n", dev->name);
> + return -EINVAL;
> + }
> +
> + max_rx_buf_length =
> + (frame_size & ~(UCC_GETH_MRBLR_ALIGNMENT - 1)) +
> + UCC_GETH_MRBLR_ALIGNMENT;
> +
> + ugeth->ug_info->uf_info.max_rx_buf_length = max_rx_buf_length;
> + dev->mtu = new_mtu;
> +
> + /* Set the max. rx buffer size (MRBLR) */
> + uf_info->max_rx_buf_length = max_rx_buf_length;
> +
> + /* set the max. frame length (MFLR) */
> + ug_info->maxFrameLength = frame_size;
> +
> + ugeth_info("%s: MTU = %d (frame size=%d)\n", dev->name,
> + dev->mtu, frame_size);
> + }
> + return 0;
> +}
>
> Do you think this is how it should be done? I don't know enough about
> ucc_geth and MTUs to know off-hand.
Not quite so. I don't think you can support JUMBO frames with just one big
RX buffer.
Also, maxframe & RX buffer should be somewhat bigger than the actual mtu
so you can
support VLAN(4) and PPPOE(8) = 12 bytes.
You need to add 12 bytes to the default values too.
Jocke
^ permalink raw reply
* KGDB8250 on PowerPC-440 does not hit KGDB breakpoint
From: srikanth krishnakar @ 2009-03-28 11:27 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
Hi all,
I am using KGDB on powerpc-440. This is tested on* Linux-2.6.27*, the
following arguments to KGDB showing init_delay of 8250 as shown below:
Target Side :
-----------------------------
Linux/PowerPC load: console=ttyS0 ip=bootp root=/dev/nfs rw
kgdb8250=ttyS0,9600 kgdbwait
Finalizing device tree... flat tree at
0x5ad300
*kgdb8250: ttyS0 init delayed, use io/mmio/mbase syntax for early init.
*
.....
.....
.......
......
......
.......
......
console [ttyS0] enabled
kgdb: Registered I/O driver kgdb8250.
Stops here ->
-------------------------------
Host Side:
(gdb) target remote
/dev/ttyS0
Remote debugging using
/dev/ttyS0
0xc01a760c in mem_serial_in (p=0xc036e050, offset=<value optimized
out>)
at
/opt/XILINX-MVL6/SUNDAY-March-28/linux-2.6.29/arch/powerpc/include/asm/io.h:153
153 DEF_MMIO_IN_BE(in_8, 8, lbz);
(gdb) info threads
14 Thread 109 (nfsiod) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
13 Thread 108 (aio/0) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
12 Thread 107 (kswapd0) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
11 Thread 106 (pdflush) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
10 Thread 105 (pdflush) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
********************
But when I say Continue -> <Got the Error as below >
(gdb) c
Continuing.
*warning: Remote failure reply: E22 *
------------------------
Can anybody correct me, where I am going wrong. I am not able to hit KGDB
breakpoint. ?
--
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 2549 bytes --]
^ permalink raw reply
* Re: DTC sources move
From: Michal Simek @ 2009-03-28 11:02 UTC (permalink / raw)
To: Grant Likely, monstr, linuxppc-dev
In-Reply-To: <20090327231818.GD20387@yookeroo.seuss>
David Gibson wrote:
> On Fri, Mar 27, 2009 at 09:57:25AM -0600, Grant Likely wrote:
>> On Fri, Mar 27, 2009 at 8:16 AM, Michal Simek <monstr@monstr.eu> wrote:
>>> Hi Ben,
>>>
>>> could you please move DTC to any generic location. I would like to use it for Microblaze cpu too.
>> Michal,
>>
>> David Gibson is the one responsible for the in-tree dtc source, not
>> Ben, and you should prepare the patches yourself to move dtc.
>
> No, I'll do it myself. As Jon says, we should update to a more recent
> upstream dtc at the same time and in any case I'll need to update my
> scripts for importing dtc into the kernel tree.
Ok. Thanks.
Michal
^ permalink raw reply
* KGDB8250 doesn't hit KGDB breakpoint in PowerPC-440
From: srikanth krishnakar @ 2009-03-28 15:10 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]
Hi all,
I am using KGDB on powerpc-440. This is tested on* Linux-2.6.27*, the
following arguments to KGDB showing init_delay of 8250 as shown below:
Target Side :
-----------------------------
Linux/PowerPC load: console=ttyS0 ip=bootp root=/dev/nfs rw
kgdb8250=ttyS0,9600 kgdbwait
Finalizing device tree... flat tree at 0x5ad300
*kgdb8250: ttyS0 init delayed, use io/mmio/mbase syntax for early init.
*
.....
.....
.......
......
......
.......
......
console [ttyS0] enabled
kgdb: Registered I/O driver kgdb8250.
Stops here ->
-------------------------------
Host Side:
(gdb) target remote
/dev/ttyS0
Remote debugging using
/dev/ttyS0
0xc01a760c in mem_serial_in (p=0xc036e050, offset=<value optimized
out>)
at /opt/linux-2.6.29/arch/powerpc/include/asm/io.h:153
153 DEF_MMIO_IN_BE(in_8, 8, lbz);
(gdb) info threads
14 Thread 109 (nfsiod) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
13 Thread 108 (aio/0) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
12 Thread 107 (kswapd0) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
11 Thread 106 (pdflush) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
10 Thread 105 (pdflush) __switch_to (prev=<value optimized out>,
new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
********************
But when I say Continue -> <Got the Error as below >
(gdb) c
Continuing.
*warning: Remote failure reply: E22 *
------------------------
Can anybody correct me, where I am going wrong. I am not able to hit KGDB
breakpoint. ?
--
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 2614 bytes --]
^ permalink raw reply
* Re: KGDB8250 doesn't hit KGDB breakpoint in PowerPC-440
From: srikanth krishnakar @ 2009-03-28 15:30 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <6213bc560903280810t73f821ceufb7711a70619d396@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]
Hi,
The simple" config is deprecated , when the MMIO support was added
to the KGDB 8250 driver. I have to use the syntax:
kgdb8250=<io or mmio>,<address>,<baud rate>,<irq>
Thanks
Srikanth
On Sat, Mar 28, 2009 at 8:40 PM, srikanth krishnakar
<skrishnakar@gmail.com>wrote:
> Hi all,
>
> I am using KGDB on powerpc-440. This is tested on* Linux-2.6.27*, the
> following arguments to KGDB showing init_delay of 8250 as shown below:
>
> Target Side :
>
> -----------------------------
>
> Linux/PowerPC load: console=ttyS0 ip=bootp root=/dev/nfs rw
> kgdb8250=ttyS0,9600 kgdbwait
> Finalizing device tree... flat tree at 0x5ad300
>
> *kgdb8250: ttyS0 init delayed, use io/mmio/mbase syntax for early
> init. *
> .....
> .....
> .......
> ......
> ......
> .......
> ......
> console [ttyS0] enabled
> kgdb: Registered I/O driver kgdb8250.
>
> Stops here ->
> -------------------------------
>
> Host Side:
>
> (gdb) target remote
> /dev/ttyS0
> Remote debugging using
> /dev/ttyS0
> 0xc01a760c in mem_serial_in (p=0xc036e050, offset=<value optimized
> out>)
> at /opt/linux-2.6.29/arch/powerpc/include/asm/io.h:153
> 153 DEF_MMIO_IN_BE(in_8, 8, lbz);
>
> (gdb) info threads
> 14 Thread 109 (nfsiod) __switch_to (prev=<value optimized out>,
> new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
> 13 Thread 108 (aio/0) __switch_to (prev=<value optimized out>,
> new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
> 12 Thread 107 (kswapd0) __switch_to (prev=<value optimized out>,
> new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
> 11 Thread 106 (pdflush) __switch_to (prev=<value optimized out>,
> new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
> 10 Thread 105 (pdflush) __switch_to (prev=<value optimized out>,
> new=0xcf8227f0) at arch/powerpc/kernel/process.c:412
>
>
> ********************
> But when I say Continue -> <Got the Error as below >
>
> (gdb) c
> Continuing.
> *warning: Remote failure reply: E22 *
>
> ------------------------
>
> Can anybody correct me, where I am going wrong. I am not able to hit KGDB
> breakpoint. ?
>
>
>
> --
> Regards
> Srikanth Krishnakar
> **********************
>
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 3350 bytes --]
^ permalink raw reply
* Re: sata device failed to IDENTIFY...
From: rizwan ahmad @ 2009-03-28 15:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <22655709.post@talk.nabble.com>
i am using VIA VT6421 PCI Cards and data types in the sata driver which is
sata_via.c is okey i mean it is unsigned long long and interrupt number is
also okey.
--
View this message in context: http://www.nabble.com/sata-device-failed-to-IDENTIFY...-tp22655709p22758040.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: CONFIG_DEBUG_PAGEALLOC generates WARN_ON() in ppc32 hash
From: Kumar Gala @ 2009-03-28 16:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC Mailing List
In-Reply-To: <1238195157.20197.81.camel@pasglop>
On Mar 27, 2009, at 6:05 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-03-27 at 06:56 -0500, Kumar Gala wrote:
>> Ben,
>>
>> If we have CONFIG_DEBUG_PAGEALLOC enabled we end up hitting the
>> WARN_ON() in set_pte_at() when we boot. This appears because we've
>> already setup pte's via mapin_ram() after which we end up calling
>> kernel_map_pages().
>>
>> So I'm not sure if __change_page_attr() should be doing something
>> different or if the WARN_ON() should be conditional on !
>> CONFIG_DEBUG_PAGEALLOC
>
> Or use __set_pte_at() ?
>
> Note that C_D_P doesn't work on hash32 anyway...
really, what mmu config does it work on ? just hash64?
- k
^ permalink raw reply
* Re: [PATCH v2 03/13] phylib: rework to prepare for OF registration of PHYs
From: Grant Likely @ 2009-03-28 16:41 UTC (permalink / raw)
To: linuxppc-dev, netdev, olof; +Cc: afleming, davem
In-Reply-To: <20090321222827.20493.18983.stgit@localhost.localdomain>
Andy, can you please make comment on patch 3, 4 and 5 of this series?
I think they are ready to merge and the driver changes can be applied
any time after the phylib changes.
g.
On Sat, Mar 21, 2009 at 4:28 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch makes changes in preparation for supporting open firmware
> device tree descriptions of MDIO busses. =A0Changes include:
> - Cleanup handling of phy_map[] entries; they are already NULLed when
> =A0registering and so don't need to be re-cleared, and it is good practic=
e
> =A0to clear them out when unregistering.
> - Split phy_device registration out into a new function so that the
> =A0OF helpers can do two stage registration (separate allocation and
> =A0registration steps).
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: linuxppc-dev@ozlabs.org
> CC: netdev@vger.kernel.org
> CC: Andy Fleming <afleming@freescale.com>
> ---
>
> =A0drivers/net/phy/mdio_bus.c =A0 | =A0 29 +++------------------------
> =A0drivers/net/phy/phy_device.c | =A0 45 ++++++++++++++++++++++++++++++++=
++++++----
> =A0include/linux/phy.h =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A03 files changed, 45 insertions(+), 30 deletions(-)
>
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 811a637..3c39c7b 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -112,7 +112,6 @@ int mdiobus_register(struct mii_bus *bus)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bus->reset(bus);
>
> =A0 =A0 =A0 =A0for (i =3D 0; i < PHY_MAX_ADDR; i++) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus->phy_map[i] =3D NULL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((bus->phy_mask & (1 << i)) =3D=3D 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct phy_device *phydev;
>
> @@ -149,6 +148,7 @@ void mdiobus_unregister(struct mii_bus *bus)
> =A0 =A0 =A0 =A0for (i =3D 0; i < PHY_MAX_ADDR; i++) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (bus->phy_map[i])
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_unregister(&bus->ph=
y_map[i]->dev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus->phy_map[i] =3D NULL;
> =A0 =A0 =A0 =A0}
> =A0}
> =A0EXPORT_SYMBOL(mdiobus_unregister);
> @@ -187,35 +187,12 @@ struct phy_device *mdiobus_scan(struct mii_bus *bus=
, int addr)
> =A0 =A0 =A0 =A0if (IS_ERR(phydev) || phydev =3D=3D NULL)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return phydev;
>
> - =A0 =A0 =A0 /* There's a PHY at this address
> - =A0 =A0 =A0 =A0* We need to set:
> - =A0 =A0 =A0 =A0* 1) IRQ
> - =A0 =A0 =A0 =A0* 2) bus_id
> - =A0 =A0 =A0 =A0* 3) parent
> - =A0 =A0 =A0 =A0* 4) bus
> - =A0 =A0 =A0 =A0* 5) mii_bus
> - =A0 =A0 =A0 =A0* And, we need to register it */
> -
> - =A0 =A0 =A0 phydev->irq =3D bus->irq !=3D NULL ? bus->irq[addr] : PHY_P=
OLL;
> -
> - =A0 =A0 =A0 phydev->dev.parent =3D bus->parent;
> - =A0 =A0 =A0 phydev->dev.bus =3D &mdio_bus_type;
> - =A0 =A0 =A0 dev_set_name(&phydev->dev, PHY_ID_FMT, bus->id, addr);
> -
> - =A0 =A0 =A0 phydev->bus =3D bus;
> -
> - =A0 =A0 =A0 /* Run all of the fixups for this PHY */
> - =A0 =A0 =A0 phy_scan_fixups(phydev);
> -
> - =A0 =A0 =A0 err =3D device_register(&phydev->dev);
> + =A0 =A0 =A0 err =3D phy_device_register(phydev);
> =A0 =A0 =A0 =A0if (err) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "phy %d failed to register\=
n", addr);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phy_device_free(phydev);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 phydev =3D NULL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 bus->phy_map[addr] =3D phydev;
> -
> =A0 =A0 =A0 =A0return phydev;
> =A0}
> =A0EXPORT_SYMBOL(mdiobus_scan);
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 0a06e4f..9352ca8 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -39,20 +39,21 @@ MODULE_DESCRIPTION("PHY library");
> =A0MODULE_AUTHOR("Andy Fleming");
> =A0MODULE_LICENSE("GPL");
>
> -static struct phy_driver genphy_driver;
> -extern int mdio_bus_init(void);
> -extern void mdio_bus_exit(void);
> -
> =A0void phy_device_free(struct phy_device *phydev)
> =A0{
> =A0 =A0 =A0 =A0kfree(phydev);
> =A0}
> +EXPORT_SYMBOL(phy_device_free);
>
> =A0static void phy_device_release(struct device *dev)
> =A0{
> =A0 =A0 =A0 =A0phy_device_free(to_phy_device(dev));
> =A0}
>
> +static struct phy_driver genphy_driver;
> +extern int mdio_bus_init(void);
> +extern void mdio_bus_exit(void);
> +
> =A0static LIST_HEAD(phy_fixup_list);
> =A0static DEFINE_MUTEX(phy_fixup_lock);
>
> @@ -166,6 +167,10 @@ struct phy_device* phy_device_create(struct mii_bus =
*bus, int addr, int phy_id)
> =A0 =A0 =A0 =A0dev->addr =3D addr;
> =A0 =A0 =A0 =A0dev->phy_id =3D phy_id;
> =A0 =A0 =A0 =A0dev->bus =3D bus;
> + =A0 =A0 =A0 dev->dev.parent =3D bus->parent;
> + =A0 =A0 =A0 dev->dev.bus =3D &mdio_bus_type;
> + =A0 =A0 =A0 dev->irq =3D bus->irq !=3D NULL ? bus->irq[addr] : PHY_POLL=
;
> + =A0 =A0 =A0 dev_set_name(&dev->dev, PHY_ID_FMT, bus->id, addr);
>
> =A0 =A0 =A0 =A0dev->state =3D PHY_DOWN;
>
> @@ -235,6 +240,38 @@ struct phy_device * get_phy_device(struct mii_bus *b=
us, int addr)
>
> =A0 =A0 =A0 =A0return dev;
> =A0}
> +EXPORT_SYMBOL(get_phy_device);
> +
> +/**
> + * phy_device_register - Register the phy device on the MDIO bus
> + * @phy_device: phy_device structure to be added to the MDIO bus
> + */
> +int phy_device_register(struct phy_device *phydev)
> +{
> + =A0 =A0 =A0 int err;
> +
> + =A0 =A0 =A0 /* Don't register a phy if one is already registered at thi=
s
> + =A0 =A0 =A0 =A0* address */
> + =A0 =A0 =A0 if (phydev->bus->phy_map[phydev->addr])
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 phydev->bus->phy_map[phydev->addr] =3D phydev;
> +
> + =A0 =A0 =A0 /* Run all of the fixups for this PHY */
> + =A0 =A0 =A0 phy_scan_fixups(phydev);
> +
> + =A0 =A0 =A0 err =3D device_register(&phydev->dev);
> + =A0 =A0 =A0 if (err) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("phy %d failed to register\n", phyde=
v->addr);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +
> + out:
> + =A0 =A0 =A0 phydev->bus->phy_map[phydev->addr] =3D NULL;
> + =A0 =A0 =A0 return err;
> +}
> +EXPORT_SYMBOL(phy_device_register);
>
> =A0/**
> =A0* phy_prepare_link - prepares the PHY layer to monitor link status
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index d7e54d9..a47d64f 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -439,6 +439,7 @@ static inline int phy_write(struct phy_device *phydev=
, u16 regnum, u16 val)
>
> =A0int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id);
> =A0struct phy_device* get_phy_device(struct mii_bus *bus, int addr);
> +int phy_device_register(struct phy_device *phy);
> =A0int phy_clear_interrupt(struct phy_device *phydev);
> =A0int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
> =A0struct phy_device * phy_attach(struct net_device *dev,
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* BUS_ID_SIZE is going away
From: Kay Sievers @ 2009-03-28 19:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Greg Kroah-Hartmann
Hey,
care to replace:
bus_id[BUS_ID_SIZE];
in:
include/linux/fsl_devices.h
with a locally defined limit, or whatever fits your needs? Or let me
know how you like it to be converted, and I can make a patch, and we
can push it through the driver-core tree.
The driver core and kobjects have no longer a limit on the device
names. We want to remove BUS_ID_SIZE from the driver core header in
the current 2.6.30 timeframe.
Thanks,
Kay
^ permalink raw reply
* Re: BUS_ID_SIZE is going away
From: Grant Likely @ 2009-03-28 20:52 UTC (permalink / raw)
To: Kay Sievers; +Cc: linuxppc-dev, Greg Kroah-Hartmann
In-Reply-To: <ac3eb2510903281210w689a48dcsa04d67392de06801@mail.gmail.com>
On Sat, Mar 28, 2009 at 1:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Hey,
> care to replace:
> =A0bus_id[BUS_ID_SIZE];
> in:
> =A0include/linux/fsl_devices.h
> with a locally defined limit, or whatever fits your needs? Or let me
> know how you like it to be converted, and I can make a patch, and we
> can push it through the driver-core tree.
gianfar_platform_data and several other symbols in that file are
actually obsolete and unused. They can be removed entirely from
include/linux/fsl_devices.h. I'll prepare a patch.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc: Remove unused symbols from fsl_devices.h
From: Grant Likely @ 2009-03-28 21:07 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Greg Kroah-Hartmann, Kay Sievers
From: Grant Likely <grant.likely@secretlab.ca>
Remove old artifacts leftover from the platform driver gianfar and
fsl_i2c drivers. These symbols became unused when the drivers
were migrated over to use the of_platform bus.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
include/linux/fsl_devices.h | 22 ----------------------
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index d9051d7..4953709 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -18,7 +18,6 @@
#define _FSL_DEVICE_H_
#include <linux/types.h>
-#include <linux/phy.h>
/*
* Some conventions on how we handle peripherals on Freescale chips
@@ -44,27 +43,6 @@
*
*/
-struct gianfar_platform_data {
- /* device specific information */
- u32 device_flags;
- char bus_id[BUS_ID_SIZE];
- phy_interface_t interface;
-};
-
-struct gianfar_mdio_data {
- /* board specific information */
- int irq[32];
-};
-
-/* Flags in gianfar_platform_data */
-#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x00000001 /* set or use a timer */
-#define FSL_GIANFAR_BRD_IS_REDUCED 0x00000002 /* Set if RGMII, RMII */
-
-struct fsl_i2c_platform_data {
- /* device specific information */
- u32 device_flags;
-};
-
/* Flags related to I2C device features */
#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
#define FSL_I2C_DEV_CLOCK_5200 0x00000002
^ permalink raw reply related
* Re: CONFIG_DEBUG_PAGEALLOC generates WARN_ON() in ppc32 hash
From: Benjamin Herrenschmidt @ 2009-03-28 21:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC Mailing List
In-Reply-To: <B8DDC536-3E6B-4857-B3B0-B8DE15D24A96@kernel.crashing.org>
> > Note that C_D_P doesn't work on hash32 anyway...
>
> really, what mmu config does it work on ? just hash64?
Pretty much :-) It's implemented for hash32 but there are issues
with the BAT mapping that were never quite resolved.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] Fix ptrace compat wrapper for fpu register access
From: Andreas Schwab @ 2009-03-29 17:56 UTC (permalink / raw)
To: linuxppc-dev
The ptrace compat wrapper mishandles access to the fpu registers. The
PTRACE_PEEKUSR and PTRACE_POKEUSR requests miscalculate the index into
the fpr array due to the broken FPINDEX macro. The
PPC_PTRACE_PEEKUSR_3264 request needs to use the same formula that the
native ptrace interface uses when operating on the register number (as
opposed to the 4-byte offset). The PPC_PTRACE_POKEUSR_3264 request
didn't take TS_FPRWIDTH into account.
This was tested with the gdb testsuite on a G5.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index 197d49c..f992eaf 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -67,7 +67,7 @@ static long compat_ptrace_old(struct task_struct *child, long request,
/* Macros to workout the correct index for the FPR in the thread struct */
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
-#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) + FPRHALF(i)
+#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i)
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
@@ -169,7 +169,7 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
if (numReg >= PT_FPR0) {
flush_fp_to_thread(child);
tmp = ((unsigned long int *)child->thread.fpr)
- [FPRINDEX(numReg)];
+ [TS_FPRWIDTH * (numReg - PT_FPR0)];
} else { /* register within PT_REGS struct */
tmp = ptrace_get_reg(child, numReg);
}
@@ -263,7 +263,8 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
ret = ptrace_put_reg(child, numReg, freg);
} else {
flush_fp_to_thread(child);
- ((unsigned int *)child->thread.regs)[index] = data;
+ ((unsigned int *)child->thread.regs)
+ [FPRINDEX(index)] = data;
ret = 0;
}
break;
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Benjamin Herrenschmidt @ 2009-03-29 22:54 UTC (permalink / raw)
To: avorontsov
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Ingo Molnar, Sam Ravnborg
In-Reply-To: <20090328104857.GA10897@oksana.dev.rtsoft.ru>
On Sat, 2009-03-28 at 13:48 +0300, Anton Vorontsov wrote:
> On Fri, Mar 20, 2009 at 11:49:29PM -0400, Steven Rostedt wrote:
> > Ben,
> >
> > Can you ACK this patch? Or even take it in your tree?
>
> Benjamin, have you had a chance to look into this? Sam, could
> you also take a look?
Those patches look ok. I'm a little bit surprised that -mno-sched-epilog
isn't needed, gcc weirdness never ceases to amaze me, but the
Makefile/Kconfig churning isn't for me to judge. If Sam is happy, then
let's merge it.
Ben.
> Thanks!
>
> > On Fri, 2009-03-20 at 19:44 +0300, Anton Vorontsov wrote:
> > > 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
> >
>
^ permalink raw reply
* Re: [PATCH] Fix ptrace compat wrapper for fpu register access
From: Michael Neuling @ 2009-03-29 23:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2k568xlfg.fsf@igel.home>
> The ptrace compat wrapper mishandles access to the fpu registers. The
> PTRACE_PEEKUSR and PTRACE_POKEUSR requests miscalculate the index into
> the fpr array due to the broken FPINDEX macro. The
> PPC_PTRACE_PEEKUSR_3264 request needs to use the same formula that the
> native ptrace interface uses when operating on the register number (as
> opposed to the 4-byte offset). The PPC_PTRACE_POKEUSR_3264 request
> didn't take TS_FPRWIDTH into account.
>
> This was tested with the gdb testsuite on a G5.
So if you're looking fixing 32 bit apps ptracing 64 bit apps, does that
mean we can get a single 32 bit GDB that'll ptrace both 64 and 32 bit
apps?
I'd been looking for a ptrace test suite... thanks!
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
>
> ---
> diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
> index 197d49c..f992eaf 100644
> --- a/arch/powerpc/kernel/ptrace32.c
> +++ b/arch/powerpc/kernel/ptrace32.c
> @@ -67,7 +67,7 @@ static long compat_ptrace_old(struct task_struct *child, lo
ng request,
> /* Macros to workout the correct index for the FPR in the thread struct */
> #define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
> #define FPRHALF(i) (((i) - PT_FPR0) & 1)
> -#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) + FPRHALF(i)
> +#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i)
ACK, I have the same patch here:
http://patchwork.ozlabs.org/patch/24940/
>
> long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
> compat_ulong_t caddr, compat_ulong_t cdata)
> @@ -169,7 +169,7 @@ long compat_arch_ptrace(struct task_struct *child, compat
_long_t request,
> if (numReg >= PT_FPR0) {
> flush_fp_to_thread(child);
> tmp = ((unsigned long int *)child->thread.fpr)
> - [FPRINDEX(numReg)];
> + [TS_FPRWIDTH * (numReg - PT_FPR0)];
> } else { /* register within PT_REGS struct */
> tmp = ptrace_get_reg(child, numReg);
> }
> @@ -263,7 +263,8 @@ long compat_arch_ptrace(struct task_struct *child, compat
_long_t request,
> ret = ptrace_put_reg(child, numReg, freg);
> } else {
> flush_fp_to_thread(child);
> - ((unsigned int *)child->thread.regs)[index] = data;
> + ((unsigned int *)child->thread.regs)
> + [FPRINDEX(index)] = data;
This index is into the ptregs structure not the fpr. I'm not sure the
FPRINDEX macro is applicable here.
Mikey
> ret = 0;
> }
> break;
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox