* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 10:12 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <200802111049.05478.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> are you the right person to address this patch to?
You might want to check the top of the file. ;)
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_register(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(register_memory_notifier);
>
> void unregister_memory_notifier(struct notifier_block *nb)
> {
> blocking_notifier_chain_unregister(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(unregister_memory_notifier);
Is there a particular reason these can't be GPL?
-- Dave
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Geert Uytterhoeven @ 2008-02-11 10:36 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: linux-kernel, linuxppc-dev, Paul Jackson, paulus, akpm,
Linus Torvalds, tglx
In-Reply-To: <1202495464.6722.13.camel@odie.local>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1496 bytes --]
On Fri, 8 Feb 2008, Simon Holm Thøgersen wrote:
> fre, 08 02 2008 kl. 12:06 -0600, skrev Paul Jackson:
> > Linus wrote:
> > > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > > ...
> > > without _requiring_ people to be git users to get the gist of the
> > > matter, ok?
> >
> >
> > Thanks for sticking up for us git-challenged contributors.
> >
> > Can anyone point me at instructions providing the shortest
> > path for getting from one of those git hex numbers to the
> > log or change it represents, for non-git users?
>
> Use gitweb [1], Linus' tree is here [2]. Just search for the hex.
>
> [1] http://git.kernel.org/
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
As the IDs are supposed to be unique, it doesn't matter where you look it up,
as long as the tree has that commit ;-)
BTW, time for Google to start handling git IDs?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 10:47 UTC (permalink / raw)
To: Dave Hansen
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <1202724743.8276.2.camel@nimitz.home.sr71.net>
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > {
> > return blocking_notifier_chain_register(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(register_memory_notifier);
> >
> > void unregister_memory_notifier(struct notifier_block *nb)
> > {
> > blocking_notifier_chain_unregister(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(unregister_memory_notifier);
>
> Is there a particular reason these can't be GPL?
>
I don't object to make them GPL. Greg, what do you think?
Regards,
Jan-Bernd
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: A. Nolson @ 2008-02-11 11:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40802081132h22b91464xd150e0671ca4fc34@mail.gmail.com>
I have been checking and it seems that the APU FPU patches will give
some headaches now, so I will probably wait until they merge them with
the official GCC release. In any case, it seems that the FPU restricts
the PowerPC and bus frequencies to a max of 200/100.
Anyway, thanks for the info. I will try to keep track of this in case of
an update.
Grant Likely wrote:
> On Feb 8, 2008 11:51 AM, A. Nolson <alohanono@gmail.com> wrote:
>
>> Hi,
>>
>> I have just heard that Xilinx has freed the FPU module for the PPC
>> architecture in EDK9.2i. WIll I be able to make it work with my
>> Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
>> Will it be just a matter of integrating it with the XPS BSP?I make an
>> extensive use of floating point in my applications and this will be
>> really useful.
>>
>
> It's been 2 years since I last played with the FPU core. At the time
> it wasn't a complete FPU so the eldk 4xxfp toolchain would not work.
> I had to build my own. I don't know if the new core is a complete
> implementation.
>
> Cheers,
> g.
>
>
>
^ permalink raw reply
* External interrupts with UIO framework on mpc8313e
From: Frank Prepelica @ 2008-02-11 11:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone!
I'm trying to receive external interrupts on the mpc8313erdb board.
I'm also using the UIO framework to register the interrupt handler.=20
It works for me when I register the interrupt handler for external =
interrupt IRQ4 (irq =3D 20)
But when I'm trying the register the handler for IRQ0(48)-IRQ3(17-19) it =
doesn't.=20
I'm using following simple code:
---snip---
static irqreturn_t intHandler(int irq, struct uio_info *dev_info)
{
printk("name: %s\n", dev_info->name);
return IRQ_HANDLED
}
static struct uio_info myinfo =3D {
.name =3D "IRQ4 Kernel Driver",
.version =3D "1.0.0",
.irq =3D 20,
.irq_flags =3D IRQF_SHARED | IRQF_DISABLED,
.handler =3D intHandler,
};
static int uio_probe(struct device *dev)
{
if(uio_register_device(dev,&myinfo))
{
return -ENODEV;
}
else
{
return 0;
}
}
---snip---
After booting the kernel, the driver (for IRQ4) appears correct in =
/proc/interrups and can be triggered.
I guess, this should also work for IRQ0-IRQ3 but it won't. IRQ0 cannot =
registered to 48 at all and the
other ones appear in /proc/interruts but they cannot be triggered (BUT =
shared with serial or i2c).=20
I also checked the value of the SEMSR register and see that IRQ4 is set =
correctly.
Okay, I thought when I set the SEMSR register manually e.g. IRQ2 to "1" =
and trigger the correct interrupt signal I could see in /proc/stat a =
counting value. Nothing happened. But the BAD counter in =
/proc/interrupts is rising.=20
Furthermore there's a mapping issue between the interrupt id number from =
the board manual
(page 8-10) and the output of /proc/interrupts. The kernel registers the =
i2c devices to=20
ID 16 and 17 although the manual says they are mapped to 14 and 15.
Any hint is appreciate!=20
Best regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 58
Fax:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 99
Email:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frank.prepelica@ubidyne.com
Homepage:=A0=A0=A0=A0=A0=A0 www.ubidyne.com
=A0
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat M=FCller
Dr. Clemens Rheinfelder
^ permalink raw reply
* Re: Ebony development board
From: Josh Boyer @ 2008-02-11 12:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200802110720.12842.sr@denx.de>
On Mon, 11 Feb 2008 07:20:12 +0100
Stefan Roese <sr@denx.de> wrote:
> Hi Zoltan,
>
> On Saturday 09 February 2008, Zoltan HERPAI wrote:
> > I've recently got an Ebony board (440GP) with the original bootloader
> > (440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is
> > there a way to boot an U-boot image via TFTP to replace the bootloader,
> > or is it possible only with using a JTAG? I've googled through the
> > mailing list, but most of the related hits are dated back in 2004-2005,
> > they say no, one have to use JTAG, but some time passed since then, and
> > I would like to know if there is a way for this.
>
> Does the original ROM monitor support writing to onboard FLASH? If yes, it
> should be possible.
It doesn't. Theoretically, you can boot Linux and use MTD on the flash
to load U-Boot. I wouldn't recommend it without a JTAG debugger around
to fix things in case they get screwed up.
josh
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Anton Vorontsov @ 2008-02-11 13:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20080201135640.GA10966@localhost.localdomain>
On Fri, Feb 01, 2008 at 04:56:40PM +0300, Anton Vorontsov wrote:
> This is new board made by Freescale Semiconductor Inc. and
> Logic Product Development.
>
> Currently supported:
> 1. UEC{1,2,7,4};
> 2. I2C;
> 3. SPI;
> 4. NS16550 serial;
> 5. PCI and miniPCI;
> 6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
> 7. Graphics controller, Fujitsu MB86277.
>
> Not supported so far:
> 1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM patches);
> 2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
> unknown, yet);
> 3. ADC AD7843 (tested to work, but support via device tree depends on
> major SPI rework, GPIO API, etc);
> 4. FHCI USB (will send RFC patches soon).
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Hello Kumar,
>
> It would be great if we can get this into the 2.6.25.
Is there any chance this will hit 2.6.25?..
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] Fix for Freescale ppc cores: major revision detection
From: Kumar Gala @ 2008-02-11 15:01 UTC (permalink / raw)
To: Martin Langer; +Cc: linuxppc-dev
In-Reply-To: <20080209174748.GA3245@tuba>
On Feb 9, 2008, at 11:47 AM, Martin Langer wrote:
> Ppc cores by Freescale are using the configuration field instead of
> the
> major revision field for their major revision number. Those field
> definitions come from include/asm-powerpc/reg.h.
>
> Look at the pdf below and you will see that PVR_MAJ() does a wrong
> shift
> for ppc cores by Freescale. This patch fixes it.
>
> http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf
This doc doesn't encompass the e500/book-e cores that don't follow the
same pattern.
The code should probably be something like:
#ifdef CONFIG_FSL_BOOKE
maj = PVR_MAJ(pvr);
#else
maj = (pvr >> 8) & 0xff;
#endif
>
>
>
> Signed-Off-By: Martin Langer <martin-langer@gmx.de>
>
>
> --- arch/powerpc/kernel/setup-common.c.ORIGINAL 2008-02-08
> 22:22:56.000000000 +0100
> +++ arch/powerpc/kernel/setup-common.c 2008-02-09 18:18:36.000000000
> +0100
> @@ -241,7 +241,7 @@
> /* If we are a Freescale core do a simple check so
> * we dont have to keep adding cases in the future */
> if (PVR_VER(pvr) & 0x8000) {
> - maj = PVR_MAJ(pvr);
> + maj = (pvr >> 8) & 0xF;
> min = PVR_MIN(pvr);
> } else {
> switch (PVR_VER(pvr)) {
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/5] Tsi108_eth: add missing linking to driver data
From: Jeff Garzik @ 2008-02-11 15:28 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <1B5F013528140F45B5C671039279CA5702A9609F@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> Bug fix for tsi108_eth network driver.
> This patch adds missing linking to driver data.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 14:30:04.000000000 -0500
> @@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
> goto register_fail;
> }
>
> + platform_set_drvdata(pdev, dev);
> printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
ACK, but your patches are unusable because they are word-wrapped
^ permalink raw reply
* [PATCH] [POWERPC] Remove generated files on make clean
From: Kumar Gala @ 2008-02-11 15:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
vmlinux.lds and dtc-parser.tab.h get created but never cleaned up.
---
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/kernel/Makefile | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 49797a4..63d07cc 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -147,6 +147,8 @@ HOSTCFLAGS += -I$(src)/dtc-src/ -I$(src)/libfdt/
targets += dtc-src/dtc-parser.tab.c
targets += dtc-src/dtc-lexer.lex.c
+clean-files += dtc-src/dtc-parser.tab.h
+
ifdef DTC_GENPARSER
BISON = bison
FLEX = flex
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 0662ae4..c1baf9d 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -104,3 +104,5 @@ quiet_cmd_systbl_chk = CALL $<
PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
+
+clean-files := vmlinux.lds
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH v4] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Kumar Gala @ 2008-02-11 15:32 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080211130132.GA6445@localhost.localdomain>
On Feb 11, 2008, at 7:01 AM, Anton Vorontsov wrote:
> On Fri, Feb 01, 2008 at 04:56:40PM +0300, Anton Vorontsov wrote:
>> This is new board made by Freescale Semiconductor Inc. and
>> Logic Product Development.
>>
>> Currently supported:
>> 1. UEC{1,2,7,4};
>> 2. I2C;
>> 3. SPI;
>> 4. NS16550 serial;
>> 5. PCI and miniPCI;
>> 6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
>> 7. Graphics controller, Fujitsu MB86277.
>>
>> Not supported so far:
>> 1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM
>> patches);
>> 2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
>> unknown, yet);
>> 3. ADC AD7843 (tested to work, but support via device tree depends on
>> major SPI rework, GPIO API, etc);
>> 4. FHCI USB (will send RFC patches soon).
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>>
>> Hello Kumar,
>>
>> It would be great if we can get this into the 2.6.25.
>
> Is there any chance this will hit 2.6.25?..
Not really. It seemed like there were a lot of other patches this
really depend on getting so I was waiting to see how that fell out.
As Linus, just released 2.6.25-rc1 lets queue this up for 2.6.26.
- k
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Greg KH @ 2008-02-11 15:22 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, netdev, Dave Hansen, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch
In-Reply-To: <200802111147.51225.ossthema@de.ibm.com>
On Mon, Feb 11, 2008 at 11:47:50AM +0100, Jan-Bernd Themann wrote:
> On Monday 11 February 2008 11:12, Dave Hansen wrote:
> > On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > > are you the right person to address this patch to?
> >
> > You might want to check the top of the file. ;)
> >
> > > --- a/drivers/base/memory.c
> > > +++ b/drivers/base/memory.c
> > > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > > {
> > > return blocking_notifier_chain_register(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(register_memory_notifier);
> > >
> > > void unregister_memory_notifier(struct notifier_block *nb)
> > > {
> > > blocking_notifier_chain_unregister(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(unregister_memory_notifier);
> >
> > Is there a particular reason these can't be GPL?
> >
>
> I don't object to make them GPL. Greg, what do you think?
They should be _GPL to match the rest of the driver core.
Care to resend this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 15:57 UTC (permalink / raw)
To: Dave Hansen
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi,
this is the modified version with EXPORT_SYMBOL_GPL
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..f5a0bf1 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Sam Ravnborg @ 2008-02-11 16:02 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, Dave Hansen, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Greg KH
In-Reply-To: <200802111657.07534.ossthema@de.ibm.com>
On Mon, Feb 11, 2008 at 04:57:06PM +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
Can you please add proper kernel-doc formatted comments
when you export a symbol so others can get a clue
what the exported function is supposed to do.
Sam
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 16:04 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
In-Reply-To: <200802111657.07534.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 16:57 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
Could you post this with the new users as well so we can make sure
they're not abusing this in some way?
-- Dave
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Anton Vorontsov @ 2008-02-11 16:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <33A3857D-9829-40CA-9A8E-751C2C417E5E@kernel.crashing.org>
On Mon, Feb 11, 2008 at 09:32:20AM -0600, Kumar Gala wrote:
>
> On Feb 11, 2008, at 7:01 AM, Anton Vorontsov wrote:
>
> >On Fri, Feb 01, 2008 at 04:56:40PM +0300, Anton Vorontsov wrote:
> >>This is new board made by Freescale Semiconductor Inc. and
> >>Logic Product Development.
> >>
> >>Currently supported:
> >>1. UEC{1,2,7,4};
> >>2. I2C;
> >>3. SPI;
> >>4. NS16550 serial;
> >>5. PCI and miniPCI;
> >>6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
> >>7. Graphics controller, Fujitsu MB86277.
> >>
> >>Not supported so far:
> >>1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM
> >>patches);
> >>2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
> >> unknown, yet);
> >>3. ADC AD7843 (tested to work, but support via device tree depends on
> >> major SPI rework, GPIO API, etc);
> >>4. FHCI USB (will send RFC patches soon).
> >>
> >>Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >>---
> >>
> >>Hello Kumar,
> >>
> >>It would be great if we can get this into the 2.6.25.
> >
> >Is there any chance this will hit 2.6.25?..
>
> Not really. It seemed like there were a lot of other patches this
> really depend on getting so I was waiting to see how that fell out.
Hm... This particular patch doesn't depend on any other patches.
This is "basic support" patch with intent to be in time for .25.
NAND/ADC/FHCI support is .26 material, of course, and that's exactly
why "basic support" patch doesn't include these bits.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Jeff Garzik @ 2008-02-11 16:08 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, netdev, Stefan Roese
In-Reply-To: <20080206064947.7e91d833@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 6 Feb 2008 13:21:59 +0100
> Stefan Roese <sr@denx.de> wrote:
>
>> With the removal the the "rgmii-interface" device_type property from the
>> dts files, the newemac driver needs an update to only rely on compatible
>> property.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
upon further reflection, ACK, take this via ppc tree
^ permalink raw reply
* [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 16:24 UTC (permalink / raw)
To: Dave Hansen
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Patch for eHEA memory hotplug support that uses these functions:
http://www.spinics.net/lists/netdev/msg54484.html
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi,
the eHEA patch belongs to a patchset that is usually
added by Jeff Garzik once this dependency (EXPORTS)
is resolved.
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..f5a0bf1 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* [PATCH 1/5 v2] Tsi108_eth: add missing linking to driver data
From: Alexandre Bounine @ 2008-02-11 16:31 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch adds missing linking to driver data.=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
17:58:37.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
14:30:04.000000000 -0500
@@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
goto register_fail;
}
=20
+ platform_set_drvdata(pdev, dev);
printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
dev->name, print_mac(mac, dev->dev_addr));
#ifdef DEBUG
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 2/5 v2] Tsi108_eth: fix detection of 1000Mb mode
From: Alexandre Bounine @ 2008-02-11 16:31 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with detection of 1000Mb speed.=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
15:09:19.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:34:12.000000000 -0500
@@ -1287,6 +1287,7 @@ static void tsi108_init_phy(struct net_d
spin_lock_irqsave(&phy_lock, flags);
}
=20
+ data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok =3D 1;
data->init_media =3D 1;
@@ -1584,7 +1585,6 @@ tsi108_init_one(struct platform_device *
data->mii_if.phy_id =3D einfo->phy;
data->mii_if.phy_id_mask =3D 0x1f;
data->mii_if.reg_num_mask =3D 0x1f;
- data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
=20
data->phy =3D einfo->phy;
data->phy_type =3D einfo->phy_type;
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 3/5 v2] Tsi108_eth: remove not needed code
From: Alexandre Bounine @ 2008-02-11 16:32 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Code clean-up for tsi108_eth network driver.
This patch removes not needed dummy read and the corresponding comment.
The PHY logic requires two reads from the status register to get=20
current link status. This is done correctly inside mii_check_media().=20=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
15:47:35.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:54:14.000000000 -0500
@@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
u32 speed;
unsigned long flags;
=20
- /* Do a dummy read, as for some reason the first read
- * after a link becomes up returns link down, even if
- * it's been a while since the link came up.
- */
-
spin_lock_irqsave(&phy_lock, flags);
=20
if (!data->phy_ok)
goto out;
=20
- tsi108_read_mii(data, MII_BMSR);
-
duplex =3D mii_check_media(&data->mii_if, netif_msg_link(data),
data->init_media);
data->init_media =3D 0;
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 4/5 v2] Tsi108_eth: fix link recovery after disconnect
From: Alexandre Bounine @ 2008-02-11 16:32 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with link recovery after connection was lost.
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
16:16:00.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
16:57:41.000000000 -0500
@@ -338,22 +338,21 @@ static void tsi108_check_phy(struct net_
=20
TSI_WRITE(TSI108_MAC_CFG2, mac_cfg2_reg);
TSI_WRITE(TSI108_EC_PORTCTRL, portctrl_reg);
+ }
=20
- if (data->link_up =3D=3D 0) {
- /* The manual says it can take 3-4 usecs
for the speed change
- * to take effect.
- */
- udelay(5);
-
- spin_lock(&data->txlock);
- if (is_valid_ether_addr(dev->dev_addr)
&& data->txfree)
- netif_wake_queue(dev);
+ if (data->link_up =3D=3D 0) {
+ /* The manual says it can take 3-4 usecs for the
speed change
+ * to take effect.
+ */
+ udelay(5);
=20
- data->link_up =3D 1;
- spin_unlock(&data->txlock);
- }
- }
+ spin_lock(&data->txlock);
+ if (is_valid_ether_addr(dev->dev_addr) &&
data->txfree)
+ netif_wake_queue(dev);
=20
+ data->link_up =3D 1;
+ spin_unlock(&data->txlock);
+ }
} else {
if (data->link_up =3D=3D 1) {
netif_stop_queue(dev);
@@ -1267,12 +1266,11 @@ static void tsi108_init_phy(struct net_d
* PHY_STAT register before the link up status bit is set.
*/
=20
- data->link_up =3D 1;
+ data->link_up =3D 0;
=20
while (!((phyval =3D tsi108_read_mii(data, MII_BMSR)) &
BMSR_LSTATUS)) {
if (i++ > (MII_READ_DELAY / 10)) {
- data->link_up =3D 0;
break;
}
spin_unlock_irqrestore(&phy_lock, flags);
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 5/5 v2] Tsi108_eth: Add ethtool support
From: Alexandre Bounine @ 2008-02-11 16:32 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Add ethtool support to tsi108_eth network driver.
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
17:10:53.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
18:09:43.000000000 -0500
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -1519,12 +1520,46 @@ static void tsi108_init_mac(struct net_d
TSI_WRITE(TSI108_EC_INTMASK, ~0);
}
=20
+static int tsi108_get_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data =3D netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+=09
+ spin_lock_irqsave(&data->txlock, flags);
+ rc =3D mii_ethtool_gset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
+static int tsi108_set_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data =3D netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc =3D mii_ethtool_sset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+=09
+ return rc;
+}
+
static int tsi108_do_ioctl(struct net_device *dev, struct ifreq *rq,
int cmd)
{
struct tsi108_prv_data *data =3D netdev_priv(dev);
+ if (!netif_running(dev))
+ return -EINVAL;
return generic_mii_ioctl(&data->mii_if, if_mii(rq), cmd, NULL);
}
=20
+static const struct ethtool_ops tsi108_ethtool_ops =3D {
+ .get_link =3D ethtool_op_get_link,
+ .get_settings =3D tsi108_get_settings,
+ .set_settings =3D tsi108_set_settings,
+};
+
static int
tsi108_init_one(struct platform_device *pdev)
{
@@ -1589,6 +1624,7 @@ tsi108_init_one(struct platform_device *
dev->get_stats =3D tsi108_get_stats;
netif_napi_add(dev, &data->napi, tsi108_poll, 64);
dev->do_ioctl =3D tsi108_do_ioctl;
+ dev->ethtool_ops =3D &tsi108_ethtool_ops;
=20
/* Apparently, the Linux networking code won't use
scatter-gather
* if the hardware doesn't do checksums. However, it's faster
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* Re: [PATCH 1/5 v2] Tsi108_eth: add missing linking to driver data
From: Jeff Garzik @ 2008-02-11 16:40 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <1B5F013528140F45B5C671039279CA5702A9638A@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> Bug fix for tsi108_eth network driver.
> This patch adds missing linking to driver data.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 14:30:04.000000000 -0500
> @@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
> goto register_fail;
> }
>
> + platform_set_drvdata(pdev, dev);
> printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
still getting word-wrapped... even the patch header is mangled across
multiple lines
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 16:47 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Themann, Jan-Bernd, netdev, apw, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Badari Pulavarty,
Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> the eHEA patch belongs to a patchset that is usually
> added by Jeff Garzik once this dependency (EXPORTS)
> is resolved.
I know that's already in mainline but, man, that code is nasty. It has
stuff indented 7 levels or so and is virtually impossible to read.
This:
> int ehea_create_busmap(void)
> {
> u64 vaddr = EHEA_BUSMAP_START;
> unsigned long high_section_index = 0;
> int i;
>
> /*
> * Sections are not in ascending order -> Loop over all sections and
> * find the highest PFN to compute the required map size.
> */
> ehea_bmap.valid_sections = 0;
>
> for (i = 0; i < NR_MEM_SECTIONS; i++)
> if (valid_section_nr(i))
> high_section_index = i;
is also completely bogus for arch-independent code. If someone ever
wants to do ppc without sparsemem (or redoes internal sparsemem
interfaces), this code will break.
Also, keeping your own mapping of all of memory is really nasty. With
SPARSEMEM_EXTREME/VMEMMAP you can have extremely sparse physical memory,
and this:
> ehea_bmap.entries = high_section_index + 1;
> ehea_bmap.vaddr = vmalloc(ehea_bmap.entries * sizeof(*ehea_bmap.vaddr));
could theoretically consume all of memory if the sections are very sparse.
Could you please try to explain what the heck this driver is doing?
We'll try to fix up the generic interfaces so that you can deal with
things in a more generic fashion, but it can't stay this way.
Also, just ripping down and completely re-doing the entire mass of cards
every time a 16MB area of memory is added or removed seems like an
awfully big sledgehammer to me. I would *HATE* to see anybody else
using this driver as an example to work off of? Can't you just keep
track of which areas the driver is actually *USING* and only worry about
changing mappings if that intersects with an area having hotplug done on
it?
Can you please give it some CodingStyle love and make it so that it
doesn't indent so much? Something like this:
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..72c5652 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2638,38 +2638,40 @@ static void ehea_rereg_mrs(struct work_struct *work)
down(&dlpar_mem_lock);
ehea_info("LPAR memory enlarged - re-initializing driver");
- list_for_each_entry(adapter, &adapter_list, list)
- if (adapter->active_ports) {
- /* Shutdown all ports */
- for (i = 0; i < EHEA_MAX_PORTS; i++) {
- struct ehea_port *port = adapter->port[i];
-
- if (port) {
- struct net_device *dev = port->netdev;
-
- if (dev->flags & IFF_UP) {
- down(&port->port_lock);
- netif_stop_queue(dev);
- ret = ehea_stop_qps(dev);
- if (ret) {
- up(&port->port_lock);
- goto out;
- }
- port_napi_disable(port);
- up(&port->port_lock);
- }
- }
- }
-
- /* Unregister old memory region */
- ret = ehea_rem_mr(&adapter->mr);
+ list_for_each_entry(adapter, &adapter_list, list) {
+ if (!adapter->active_ports)
+ continue;
+ /* Shutdown all ports */
+ for (i = 0; i < EHEA_MAX_PORTS; i++) {
+ struct ehea_port *port = adapter->port[i];
+ struct net_device *dev;
+ if (!port)
+ continue;
+
+ dev = port->netdev;
+ if (!(dev->flags & IFF_UP))
+ continue;
+
+ down(&port->port_lock);
+ netif_stop_queue(dev);
+ ret = ehea_stop_qps(dev);
if (ret) {
- ehea_error("unregister MR failed - driver"
- " inoperable!");
+ up(&port->port_lock);
goto out;
}
+ port_napi_disable(port);
+ up(&port->port_lock);
}
+ /* Unregister old memory region */
+ ret = ehea_rem_mr(&adapter->mr);
+ if (ret) {
+ ehea_error("unregister MR failed - driver"
+ " inoperable!");
+ goto out;
+ }
+ }
+
ehea_destroy_busmap();
ret = ehea_create_busmap();
if (ret) {
-- Dave
^ permalink raw reply related
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