* Re: [PATCH] add MPC837x MDS board default device tree
From: Kumar Gala @ 2008-01-08 5:46 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev list, David Gibson
In-Reply-To: <4A496992-9B46-427D-8F40-447E92F8CA3D@kernel.crashing.org>
On Dec 14, 2007, at 2:12 AM, Kumar Gala wrote:
>
> On Dec 6, 2007, at 8:01 PM, David Gibson wrote:
>
>> On Wed, Dec 05, 2007 at 06:37:53PM +0800, Li Yang wrote:
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> Update SATA nodes; remove serdes nodes; add aliases and labels.
>>>
>>> arch/powerpc/boot/dts/mpc8377_mds.dts | 270 +++++++++++++++++++++++
>>> ++++++++
>>> arch/powerpc/boot/dts/mpc8378_mds.dts | 256 +++++++++++++++++++++++
>>> ++++++
>>> arch/powerpc/boot/dts/mpc8379_mds.dts | 284 +++++++++++++++++++++++
>>> ++++++++++
>>> 3 files changed, 810 insertions(+), 0 deletions(-)
>>> create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts
>>> create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
>>> create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>>>
>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
>>> boot/dts/mpc8377_mds.dts
>>> new file mode 100644
>>> index 0000000..919ffd0
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
>> [snip]
>>> + aliases {
>>> + ethernet0 = "/soc@e0000000/ethernet@24000";
>>> + ethernet1 = "/soc@e0000000/ethernet@25000";
>>> + serial0 = "/soc@e0000000/serial@4500";
>>> + serial1 = "/soc@e0000000/serial@4600";
>>> + pci0 = "/pci@e0008500";
>>
>> You can use path references for these now.
>>
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + PowerPC,837x@0 {
>>
>> This should absolutely not have a "x" in it. Either have an exact
>> model, or just use "cpu@9" (in which case you can put the model in
>> "compatible").
>>
>> [snip]
>>> + i2c@3000 {
>>> + device_type = "i2c";
>>
>> Drop the device_type. No "i2c" device_type class is defined.
>>
>> [snip]
>>> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
>>> + usb@23000 {
>>> + device_type = "usb";
>>
>> Drop device_type here too.
>>
>>> + compatible = "fsl-usb2-dr";
>>> + reg = <23000 1000>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + interrupt-parent = < &ipic >;
>>> + interrupts = <26 8>;
>>> + phy_type = "utmi_wide";
>>> + };
>>> +
>>> + mdio@24520 {
>>> + device_type = "mdio";
>>> + compatible = "gianfar";
>>
>> Grr... not your fault, but this crap in the gianfar driver where it
>> uses the same compatible property for the mdio and MAC has to be
>> fixed.
>
> I've fixed this now. Look at my tree/patch.
>
>> [snip]
>>
>>> + serial1:serial@4600 {
>>
>> Standard style puts a space after the colon.
>>
>>> + device_type = "serial";
>>> + compatible = "ns16550";
>>> + reg = <4600 100>;
>>> + clock-frequency = <0>;
>>> + interrupts = <a 8>;
>>> + interrupt-parent = < &ipic >;
>>> + };
>>> +
>>> + crypto@30000 {
>>> + model = "SEC3";
>>> + compatible = "talitos";
>>
>> This driver, also, needs fixing to recognize a better formatted
>> compatible property.
>
> Can you respin with David's changes as well as mirror my cleanup of
> the other 83xx/85xx .dts
Any updates on new versions of the .dts for mpc837x?
- k
^ permalink raw reply
* [PATCH/RFC] mpc83xx/85xx SysRQ/brk over 8250 console
From: Paul Gortmaker @ 2008-01-08 5:27 UTC (permalink / raw)
To: Linuxppc-dev
It seems that if a break is rec'd on the serial console (as per SysRQ
or similar) on some 83xx and 85xx processors, then a pulse of IRQs is
generated which makes the use of SysRQ itself about 99% impossible. I
experimented with trying several ACK strategies, but in the end the
thing which worked best was just to wait for the surge of events to pass
(a fraction of a second). The number of events can be on the order of
1000 (as reported by /proc/interrupts)
I really dislike seeing board specific ifdefs within what should be
board independent code, so I'm hoping that once the problem is known,
that a more elegant solution will pop into someone's head. Or at least
this will hopefully save someone the grief of re-investigating the source
and start a discussion.
I've seen this on two different 834x boards and also an 8548 based
board. At this point, it is not clear to me if the problem extends
beyond these CPU/soc to all with UARTs at 4500/4600.
While less than ideal, the work-around below which simply ignores the
events does allow a person to use SysRQ on such platforms.
The definition of the RFE bit (Rx FIFO error) can be found in pretty
much any of the MPC CPU PDFs (for those with 4500/4600 16550s).
Paul.
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..2761c64 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1426,6 +1426,24 @@ serial8250_handle_port(struct uart_8250_port *up)
status = serial_inp(up, UART_LSR);
+#if defined(CONFIG_MPC834x) || defined(CONFIG_MPC8540)
+ /*
+ * There appears to be a quirk in the implementation on some 8xxx
+ * where after a break is rec'd (UART_LSR_BI), the UART generates
+ * a short duration burst of bogus IRQ events with the signature
+ * of RFE set (along with "normal" bits set) in the LSR.
+ */
+
+#define RFE_8xxx_ERR_BITS ( UART_LSR_RFE | UART_LSR_TEMT | \
+ UART_LSR_THRE | UART_LSR_BI | \
+ UART_LSR_DR )
+
+ if (status == RFE_8xxx_ERR_BITS) {
+ spin_unlock_irqrestore(&up->port.lock, flags);
+ return;
+ }
+#endif
+
DEBUG_INTR("status = %x...", status);
if (status & UART_LSR_DR)
diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index 96c0d93..1ea6436 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -111,6 +111,7 @@
#define UART_MCR_DTR 0x01 /* DTR complement */
#define UART_LSR 5 /* In: Line Status Register */
+#define UART_LSR_RFE 0x80 /* Rx FIFO Error (BE, FE, or PE) */
#define UART_LSR_TEMT 0x40 /* Transmitter empty */
#define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
#define UART_LSR_BI 0x10 /* Break interrupt indicator */
^ permalink raw reply related
* Re: [PATCH] i2c-ibm_iic driver - new patch
From: Stephen Rothwell @ 2008-01-08 4:52 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese, Arnd Bergmann
In-Reply-To: <4782D9E0.4070600@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]
Hi Sean,
On Mon, 07 Jan 2008 21:03:12 -0500 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
Please don't post patches as attachments.
> +static int __devinit iic_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
Indenting could be better.
> +{
> + if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
Please split the assignments from the tests. Here and elsewhere.
> + printk(KERN_CRIT "ibm-iic: failed to allocate device data\n");
I am not sure that these messages are necessary and, even if so, not KERN_CRIT.
> + if(iic_force_poll)
Space after "if"
> + if (dev->irq != NO_IRQ) {
.
.
> + }
> +
> + if (dev->irq == NO_IRQ)
else instead?
> + printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
> + dev->idx);
> +static int __devexit iic_remove(struct of_device *ofdev)
> +{
> + struct ibm_iic_private* dev = (struct ibm_iic_private*)dev_get_drvdata(&ofdev->dev);
Unnecessary cast.
> + if (i2c_del_adapter(&dev->adap)){
> + printk(KERN_CRIT "ibm-iic%d: failed to delete i2c adapter :(\n",
> + dev->idx);
This is not a KERN_CRIT situation ...
> + /* That's *very* bad, just shutdown IRQ ... */
> + if (dev->irq >= 0){
What is that testing? For NO_IRQ as below?
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + dev->irq = -1;
NO_IRQ?
> + }
> + } else {
> + if (dev->irq != NO_IRQ){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + }
> + iounmap(dev->vaddr);
> + kfree(dev);
Should these last two be after the below brace?
> + }
> +
> + return 0;
> +}
> +
> +
> +static struct of_device_id ibm_iic_match[] =
This should be const.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to write a device driver in such a fashion .????
From: Misbah khan @ 2008-01-08 4:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <14660018.post@talk.nabble.com>
using mmap() in application to access the h/w is only possible if the device
memory is mapped in the kernel virtual memory how come we directly map to
the physical memory to virtual from user space ???
----Misbah
Misbah khan wrote:
>
> Hi all ....
>
> I need your suggession to write a driver with such requirements :-
>
> On Initiation by the application of which key is pressed driver should
> perform the task accordingly. There are 7 keys so seven different task the
> driver will perform.
>
> 1 . I do not want to use any entry point such as read/write/ioctl. In such
> a case how to access the driver.
> 2. We dont want to implement this as a chracrter driver.
> 3. The driver shall look pretty much like an application where in
> asscssing the H/W memory map .
>
> Hence no entry point and no registeration but an application could be able
> to communicate ....
>
> I need your suggession in this regard .....
>
> -----Misbah
>
--
View this message in context: http://www.nabble.com/How-to-write-a-device-driver-in-such-a-fashion-.-----tp14660018p14682271.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 7/8] pseries: phyp dump: Unregister and print dump areas.
From: Stephen Rothwell @ 2008-01-08 4:25 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C5CB.4080802@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
Hi Manish,
Just more trivial stuff.
On Mon, 07 Jan 2008 18:37:31 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
> {
> int rc;
> - ph->cpu_data.destination_address += addr;
> - ph->hpte_data.destination_address += addr;
> - ph->kernel_data.destination_address += addr;
>
> + /* Add addr value if not initialized before */
> + if (ph->cpu_data.destination_address == 0) {
> + ph->cpu_data.destination_address += addr;
Could be just '=' like further down, right?
> +static void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
> +{
> + if (rc)
> + {
We prefer
if (rc) {
> +static void unregister_dump_area(struct phyp_dump_header *ph)
> +{
> + if (rc)
> + {
And again.
> static ssize_t
> show_release_region(struct kset * kset, char *buf)
We normally put the function name on the same line as the type.
> {
> - return sprintf(buf, "ola\n");
> + u64 second_addr_range;
> +
> + /* total reserved size - start of scratch area */
> + second_addr_range = phdr.cpu_data.destination_address -
> + phyp_dump_info->init_reserve_size;
> + return sprintf(buf, "CPU:0x%lx-0x%lx: HPTE:0x%lx-0x%lx:"
> + " DUMP:0x%lx-0x%lx, 0x%lx-0x%lx:\n",
> + phdr.cpu_data.destination_address, phdr.cpu_data.length_copied,
> + phdr.hpte_data.destination_address, phdr.hpte_data.length_copied,
> + phdr.kernel_data.destination_address, phdr.kernel_data.length_copied,
> + phyp_dump_info->init_reserve_start, second_addr_range);
This indentation should be (probably) two tabs.
> + /* re-register the dump area, if old dump was invalid */
> + if ((dump_header) && (dump_header->status & DUMP_ERROR_FLAG)) {
^ ^
Extra parentheses.
> + invalidate_last_dump (&phdr, dump_area_start);
> + register_dump_area (&phdr, dump_area_start);
No spaces after function names.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] pseries: phyp dump: debugging print routines.
From: Stephen Rothwell @ 2008-01-08 4:03 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C53D.4060506@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hi Manish,
Just a trivial comment.
On Mon, 07 Jan 2008 18:35:09 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> + printk(KERN_INFO "dump disk section = %d\n",ph->dump_disk_section);
Please put a space after the ','. Here and later.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH][POWERPC] Workaround for iommu page alignment (#2)
From: Benjamin Herrenschmidt @ 2008-01-08 4:02 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
In-Reply-To: <20080108034824.GA7983@lixom.net>
> And sloppy of me to not catch it. Anyway:
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
> I wonder how long until there's a device that has some other < PAGE_SIZE
> alignment bug^Wrequirement that we'll need to meet too. :(
Yeah, it's a worry...
Ben.
^ permalink raw reply
* Re: [PATCH 5/8] pseries: phyp dump: register dump area.
From: Stephen Rothwell @ 2008-01-08 3:59 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C3AE.8060202@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
Hi Manish,
On Mon, 07 Jan 2008 18:28:30 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> +++ linux-2.6.24-rc3-git1/arch/powerpc/platforms/pseries/phyp_dump.c 2007-11-21 16:06:52.000000000 -0600
> +static unsigned long init_dump_header(struct phyp_dump_header *ph)
> +{
> + /* Get the required dump region sizes */
> + rtas = of_find_node_by_path("/rtas");
You need to of_node_put(rtas) somewhere.
> + if (sizes[0] == 1)
> + cpu_state_size = *((unsigned long *) &sizes[1]);
We normally don't put spaces after casts.
> + ph->first_offset_section =
> + (u32) &(((struct phyp_dump_header *) 0)->cpu_data);
(u32)offsetof(struct phyp_dump_header, cpu_data);
> +static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
> +{
> + if (rc)
> + {
> + printk (KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
> + }
The braces are not needed.
> +
> + dump_area_length = init_dump_header (&phdr);
We don't put spaces after function names.
> + free_area_length = phyp_dump_info->init_reserve_size - dump_area_length;
> + dump_area_start = phyp_dump_info->init_reserve_start + free_area_length;
> + dump_area_start = dump_area_start & PAGE_MASK; /* align down */
> + free_area_length = dump_area_start - phyp_dump_info->init_reserve_start;
> +
> if (dump_header == NULL) {
> - release_all();
> - return 0;
> + register_dump_area (&phdr, dump_area_start);
Ditto.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] pseries: phyp dump: use sysfs to release reserved mem
From: Stephen Rothwell @ 2008-01-08 3:45 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C225.3060305@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
On Mon, 07 Jan 2008 18:21:57 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> +static int __init phyp_dump_setup(void)
> +{
>
> + /* Is there dump data waiting for us? */
> + rtas = of_find_node_by_path("/rtas");
> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
^^^^^^^^^^^
You could pass NULL here as header_len appears to be unused. Also you
need "of_node_put(rtas)" somewhere (probably just here would do).
> + if (dump_header == NULL) {
> + release_all();
> + return 0;
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH][POWERPC] Workaround for iommu page alignment (#2)
From: Olof Johansson @ 2008-01-08 3:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
In-Reply-To: <1199748862.6734.20.camel@pasglop>
On Tue, Jan 08, 2008 at 10:34:22AM +1100, Benjamin Herrenschmidt wrote:
> powerpc: Workaround for iommu page alignment
>
> Our iommu page size is currently always 4K. That means with our current
> code, drivers may do a dma_map_sg() of a 64K page and obtain a dma_addr_t
> that is only 4K aligned.
>
> This works fine in most cases except some infiniband HW it seems, where
> they tell the HW about the page size and it ignores the low bits of the
> DMA address.
>
> This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
> for mappings of objects that are page aligned in the first place and whose
> size is larger or equal to a page.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> And this version actually does what the comment says (I had forgotten
> to quilt ref... a common mistake).
And sloppy of me to not catch it. Anyway:
Acked-by: Olof Johansson <olof@lixom.net>
I wonder how long until there's a device that has some other < PAGE_SIZE
alignment bug^Wrequirement that we'll need to meet too. :(
-Olof
^ permalink raw reply
* RE: [PATCH 3/3] USB device tree cleanups
From: Li Yang @ 2008-01-08 3:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080108101028.db21d18a.sfr@canb.auug.org.au>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Stephen Rothwell
> Sent: Tuesday, January 08, 2008 7:10 AM
> To: Li Yang
> Cc: linuxppc-dev@ozlabs.org; paulus@samba.org
> Subject: Re: [PATCH 3/3] USB device tree cleanups
>=20
> On Mon, 7 Jan 2008 20:03:20 +0800 Li Yang=20
> <leoli@freescale.com> wrote:
> >
> > +++ b/arch/powerpc/sysdev/fsl_soc.c
> > @@ -533,9 +533,7 @@ static int __init fsl_usb_of_init(void)
> > *usb_dev_dr_client =3D NULL;
> > int ret;
> > =20
> > - for (np =3D NULL, i =3D 0;
> > - (np =3D of_find_compatible_node(np, "usb",=20
> "fsl-usb2-mph")) !=3D NULL;
> > - i++) {
> > + for_each_compatible_node(np, NULL, "fsl-usb2-mph") {
>=20
> 'i' is no longer being updated (or indeed set to anything)=20
> but is still used in the loop - at least in Paulus' current tree).
Good catch. My careless mistake. Thanks.
- Leo
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: config file
From: Stephen Rothwell @ 2008-01-08 3:18 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C0C8.2050702@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On Mon, 07 Jan 2008 18:16:08 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
>
> Add hypervisor-assisted dump to kernel config
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
This patch should probably come last in the series so that all the code
is there before some bisecting autobuilder tries to configure it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Stephen Rothwell @ 2008-01-08 3:16 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C2FB.7020105@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
Hi Manish,
Just some trivial things ...
On Mon, 07 Jan 2008 18:25:31 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
>
> +++ linux-2.6.24-rc2-git4/include/asm-powerpc/phyp_dump.h 2007-11-19 17:44:21.000000000 -0600
> +#ifndef _PPC64_PHYP_DUMP_H
We more usually use _ASM_POWERPC_PHYP_DUMP_H
> +#define _PPC64_PHYP_DUMP_H
> +
> +#ifdef CONFIG_PHYP_DUMP
Do these things really need protecting by this CONFIG variable? i.e. does
anything change depending on the visibility of these various symbols?
> +++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/phyp_dump.c 2007-11-19 19:07:49.000000000 -0600
> @@ -0,0 +1,71 @@
> +/*
> + * Hypervisor-assisted dump
> + *
> + * Linas Vepstas, Manish Ahuja 2007
> + * Copyrhgit (c) 2007 IBM Corp.
^^^^^^^^^
typo. and you should really be using '©' in new copyright notices (or
nothing).
> +/**
> + * release_memory_range -- release memory previously lmb_reserved
> + * @start_pfn: starting physical frame number
> + * @nr_pages: number of pages to free.
> + *
> + * This routine will release memory that had been previously
> + * lmb_reserved in early boot. The released memory becomes
> + * available for genreal use.
^^^^^^^
typo.
> +release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +{
> + struct page *rpage;
> + unsigned long end_pfn;
> + long i;
> +
> + end_pfn = start_pfn + nr_pages;
> +
> + for (i=start_pfn; i <= end_pfn; i++) {
spaces around '='
> +static int __init phyp_dump_setup(void)
> +{
> +}
> +
> +subsys_initcall(phyp_dump_setup);
Normally we don't leave a blank line here.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v6] qe: add ability to upload QE firmware
From: Stephen Rothwell @ 2008-01-08 2:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11997441442105-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On Mon, 7 Jan 2008 16:15:44 -0600 Timur Tabi <timur@freescale.com> wrote:
>
> +struct qe_firmware_info *qe_get_firmware_info(void)
> +{
> + /* Find the 'firmware' child node */
> + while ((fw = of_get_next_child(qe, fw)))
If you use:
for_each_child_of_node(qe, fw)
You don't need to initialise 'fw' in its declararion.
> + /* Did we find the 'firmware' node? */
> + if (!fw) {
> + of_node_put(fw);
This of_node_put is not necessary (as fw is NULL);
> + prop = of_find_property(fw, "extended-modes", NULL);
> + if (prop && (prop->length == sizeof(u64))) {
> + const u64 *iprop = prop->value;
> +
> + qe_firmware_info.extended_modes = *iprop;
> + }
Why not:
const u64 *iprop;
int len;
iprop = of_get_property(fs, "extended-modes", &len);
if (iprop && (len == sizeof(u64))
qe_firmware_info.extended_modes = *iprop;
> + prop = of_find_property(fw, "virtual-traps", NULL);
> + if (prop && (prop->length == 32)) {
> + const u32 *iprop = prop->value;
> +
> + for (i = 0; i < ARRAY_SIZE(qe_firmware_info.vtraps); i++)
> + qe_firmware_info.vtraps[i] = iprop[i];
> + }
And similarly?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* How complete should the DTS be?
From: Sean MacLennan @ 2008-01-08 2:07 UTC (permalink / raw)
To: linuxppc-dev
Just a general question about DTS "completeness". Like all 440EP
processors, the taco has two i2c buses. However, only one bus has
anything connected to it.
Should I show both bus entries in the DTS, or only the one that is used?
I have generally only been showing the devices that are present. i.e.
Only one emac, only one serial port.
Is there a convention for this?
Cheers,
Sean
^ permalink raw reply
* [PATCH] i2c-ibm_iic driver - new patch
From: Sean MacLennan @ 2008-01-08 2:03 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev, Stefan Roese
In-Reply-To: <20080106001238.GI4326@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
Second attempt. I think I have covered all the comments. It now should
work with both ppc and powerpc architectures.
You can now specify fast-mode in the .dts file.
You can now specify an index for each entry. If you don't I try to
chose reasonable defaults. i.e. I keep a static int that is incremented.
If you mix index entries with non-index entries, you are on your own.
Below is the example for the taco, I have shown fast-mode set in IIC1 as
an example:
IIC0: i2c@ef600700 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
index = <0>;
};
IIC1: i2c@ef600800 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
index = <1>;
fast-mode;
};
Cheers,
Sean
[-- Attachment #2: i2c-patch --]
[-- Type: text/plain, Size: 6512 bytes --]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c466c6c..e9e1493 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 9b43ff7..0b10bb1 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -6,7 +6,10 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
- * Based on original work by
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
* Matt Porter <mporter@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -657,6 +665,7 @@ static inline u8 iic_clckdiv(unsigned int opb)
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -831,3 +840,192 @@ static void __exit iic_exit(void)
module_init(iic_init);
module_exit(iic_exit);
+#else
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ static int index = 0;
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private* dev;
+ struct i2c_adapter* adap;
+ const u32 *addrp, *freq;
+ u64 addr;
+ int ret;
+
+ if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
+ printk(KERN_CRIT "ibm-iic: failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ /* This assumes we don't mix index and non-index entries. */
+ if((addrp = of_get_property(np, "index", NULL)))
+ dev->idx = *addrp;
+ else
+ dev->idx = index++;
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
+ (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
+ printk(KERN_CRIT "ibm-iic%d: Unable to get iic address\n",
+ dev->idx);
+ ret = -EBUSY;
+ goto fail1;
+ }
+
+ if (!(dev->vaddr = ioremap(addr, sizeof(struct iic_regs)))){
+ printk(KERN_CRIT "ibm-iic%d: failed to ioremap device registers\n",
+ dev->idx);
+ ret = -ENXIO;
+ goto fail1;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ if(iic_force_poll)
+ dev->irq = NO_IRQ;
+ else if((dev->irq = irq_of_parse_and_map(np, 0)) == NO_IRQ)
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+
+ if (dev->irq != NO_IRQ) {
+ /* Disable interrupts until we finish initialization,
+ assumes level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if(request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)){
+ printk(KERN_ERR "ibm-iic%d: request_irq %d failed\n",
+ dev->idx, dev->irq);
+ /* Fallback to the polling mode */
+ dev->irq = NO_IRQ;
+ }
+ }
+
+ if (dev->irq == NO_IRQ)
+ printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
+ dev->idx);
+
+ /* Board specific settings */
+ if(iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+ else
+ dev->fast_mode = 0;
+
+ /* clckdiv is the same for *all* IIC interfaces, but I'd rather
+ * make a copy than introduce another global. --ebs
+ */
+ if((freq = of_get_property(np, "clock-frequency", NULL)) == NULL &&
+ (freq = of_get_property(np->parent, "clock-frequency", NULL)) == NULL) {
+ printk(KERN_CRIT "ibm-iic%d: Unable to get bus frequency\n", dev->idx);
+ ret = -EBUSY;
+ goto fail;
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ DBG("%d: clckdiv = %d\n", dev->idx, dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strcpy(adap->name, "IBM IIC");
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->client_register = NULL;
+ adap->client_unregister = NULL;
+ adap->timeout = 1;
+ adap->retries = 1;
+ adap->nr = dev->idx;
+
+ if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
+ printk(KERN_CRIT "ibm-iic%d: failed to register i2c adapter\n",
+ dev->idx);
+ goto fail;
+ }
+
+ printk(KERN_INFO "ibm-iic%d: using %s mode\n", dev->idx,
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+fail:
+ if (dev->irq != NO_IRQ){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+fail1:
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private* dev = (struct ibm_iic_private*)dev_get_drvdata(&ofdev->dev);
+
+ BUG_ON(dev == NULL);
+ if (i2c_del_adapter(&dev->adap)){
+ printk(KERN_CRIT "ibm-iic%d: failed to delete i2c adapter :(\n",
+ dev->idx);
+ /* That's *very* bad, just shutdown IRQ ... */
+ if (dev->irq >= 0){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ dev->irq = -1;
+ }
+ } else {
+ if (dev->irq != NO_IRQ){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+ iounmap(dev->vaddr);
+ kfree(dev);
+ }
+
+ return 0;
+}
+
+
+static struct of_device_id ibm_iic_match[] =
+{
+ { .type = "i2c", .compatible = "ibm,iic-405ex", },
+ { .type = "i2c", .compatible = "ibm,iic-405gp", },
+ { .type = "i2c", .compatible = "ibm,iic-440gp", },
+ { .type = "i2c", .compatible = "ibm,iic-440gpx", },
+ { .type = "i2c", .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver =
+{
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = iic_remove,
+};
+
+static int __init ibm_iic_init(void)
+{
+ printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+module_init(ibm_iic_init);
+
+static void __exit ibm_iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+module_exit(ibm_iic_exit);
+#endif
+
^ permalink raw reply related
* Re: How to config linux kernel(ARCH=powerpc)?
From: Josh Boyer @ 2008-01-08 1:55 UTC (permalink / raw)
To: tony, jie han; +Cc: linuxppc-embedded
In-Reply-To: <200801080918222817608@163.com>
On Tue, 8 Jan 2008 09:18:23 +0800
"tony" <hangtoo@163.com> wrote:
> hi Jie
> maybe you should try it like this:
> linux-2.6-denx->make ARCH=ppc CROSS_COMPILE=ppc_4xx- pasemi_defconfig
> make sure you have installed the ppc_4xx- tools.
Um.. no. pasemi is a 64bit CPU. Get the powerpc tree from kernel.org,
make sure you have a PowerPC 64bit toolchain, and try with make
ARCH=powerpc
josh
^ permalink raw reply
* Re:How to config linux kernel(ARCH=powerpc)?
From: tony @ 2008-01-08 1:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
hi Jie
maybe you should try it like this:
linux-2.6-denx->make ARCH=ppc CROSS_COMPILE=ppc_4xx- pasemi_defconfig
make sure you have installed the ppc_4xx- tools.
good luck
tony
[-- Attachment #2: Type: text/html, Size: 945 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-08 1:16 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200801051224.52693.arnd@arndb.de>
Arnd Bergmann wrote:
> If there is a good reason to specify fast or slow mode per board, you may want
> to make that a property in the device node.
>
I tried to add fast_mode to the .dts file and failed.
IIC1: i2c@ef600800 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
fast-mode = <0>;
};
As soon as a I add the fast-mode line I get the following error on boot:
fdt_wrapper_setprop():105 FDT_ERR_NOSPACE
Remove the line and I boot. Any ideas?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-01-08 1:13 UTC (permalink / raw)
To: linasvepstas; +Cc: mahuja, linuxppc-dev, lkessler, strosake, Arnd Bergmann
In-Reply-To: <3ae3aa420801071649w6a8d3939y176dc389d68f4870@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
On Mon, 2008-01-07 at 18:49 -0600, Linas Vepstas wrote:
> On 07/01/2008, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 08 January 2008, Manish Ahuja wrote:
> >
> > > Initial patch for reserving memory in early boot, and freeing it later.
> > > If the previous boot had ended with a crash, the reserved memory would contain
> > > a copy of the crashed kernel data.
> > >
> > > Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> > > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> >
> > I think the signed-off-by chain needs to be modified. The way it appears,
> > you handled the patch first, then sent it to Linas, who forwarded it
> > to whoever will take the patches from the list.
> > This obviously isn't true, since you are actually the one who is sending
> > out the patches. Moreover, I believe that the linas@austin.ibm.com
> > address is now dead, and shouldn't be used for this any more.
>
> Hmm. I wanted to indicate that the work was done while I was at IBM;
> clearly, no one is going through git and changing old, expired email
> addrs, and so submission based on the old addr seemed appropriate.
>
> I'm taking the Signed-off-by line as a quasi-legal thing: a fancy ID string,
> identifying the author(s), rather than a new way to manage email
> address books.
No one's changing the git history (you can't), but it seems silly to
submit a patch with an address that is already dead. There is a general
expectation that if/when someone finds a bug in the code they can email
the signed-off-by addresses and get a real person.
As far as indicating it was written at IBM, that should be covered by
the copyright notices.
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: [RFC 1/2] mpc5200: Add common clock setting routine mpc52xx_set_psc_clkdiv()
From: Stephen Rothwell @ 2008-01-08 1:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, dragos.carp
In-Reply-To: <20080107190335.13535.29837.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On Mon, 07 Jan 2008 12:03:59 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
>
> -static struct of_device_id __init mpc52xx_ids[] = {
Why not just leave this here and mark in __initdata?
> +/**
> + * mpc52xx_declare_of_platform_devices: register internal devices and children
> + * of the localplus bus to the of_platform
> + * bus.
> + */
> void __init
> mpc52xx_declare_of_platform_devices(void)
> {
> + const static struct of_device_id mpc52xx_bus_ids[] = {
Or just mark it __initdata instead of const?
> + { .compatible = "fsl,mpc5200-immr", },
> + { .compatible = "fsl,lpb", },
> + { .type = "builtin", .compatible = "mpc5200", }, /* efika */
> + { .type = "soc", .compatible = "mpc5200", }, /* old */
And you lost the comment about the last two being deprecated mates.
> +mpc52xx_map_common_devices(void)
> {
> struct device_node *np;
> - struct of_device_id gpt_ids[] = {
> + const static struct of_device_id gpt_ids[] = {
Again __initdata?
> + const static struct of_device_id cdm_ids[] = {
And again?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] Update MPC8610 HPCD to support audio drivers
From: Stephen Rothwell @ 2008-01-08 0:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: liam.girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <1199732204578-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
Hi Timur,
On Mon, 7 Jan 2008 12:56:43 -0600 Timur Tabi <timur@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> @@ -34,9 +34,27 @@
>
> #include <asm/mpic.h>
>
> +#include <linux/of_platform.h>
> #include <sysdev/fsl_pci.h>
> #include <sysdev/fsl_soc.h>
>
> +static struct of_device_id mpc8610_ids[] = {
__initdata
> + { .compatible = "fsl,mpc8610", },
> + {}
> +};
> +
> +static int __init mpc8610_declare_of_platform_devices(void)
> +{
> + if (!machine_is(mpc86xx_hpcd))
> + return 0;
> +
> + /* Without this call, the SSI device driver won't get probed. */
> + of_platform_bus_probe(NULL, mpc8610_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc8610_declare_of_platform_devices);
We have machine_device_initcall for this now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] pseries: phyp dump: debugging print routines.
From: Arnd Bergmann @ 2008-01-08 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mahuja, lkessler, linasvepstas, strosake
In-Reply-To: <4782C53D.4060506@austin.ibm.com>
On Tuesday 08 January 2008, Manish Ahuja wrote:
> +#ifdef DEBUG
> +static void print_dump_header(const struct phyp_dump_header *ph)
> +{
> +=A0=A0=A0=A0=A0=A0=A0printk(KERN_INFO "dump header:\n");
> ...
> +=A0=A0=A0=A0=A0=A0=A0printk(KERN_INFO "SRSD length_copied =3D%lx\n",ph->=
kernel_data.length_copied);
> +}
> +#endif
> +
If you move the #if to inside of the function,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk (KERN_ERR "phyp-du=
mp: unexpected error (%d) on register\n", rc);
> +#ifdef DEBUG
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0print_dump_header (ph);
> +#endif
> =A0=A0=A0=A0=A0=A0=A0=A0}
> =A0=A0=A0=A0=A0=A0=A0=A0}
> +#ifdef DEBUG
> +=A0=A0=A0=A0=A0=A0=A0print_dump_header (dump_header);
> +#endif
you don't need the #ifdefs here.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-01-08 0:50 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <200801080126.51897.arnd@arndb.de>
Arnd,
Sorry this patch ended up out of sequence. I reposted it properly again in the other thread.
We did talk about using gmail address, but Linas was more comfortable using this as this is
where he was, when we did this. Hence the use of Austin address with gmail being on the cc list.
I am sure he will chime in with more details about it when he gets the opportunity.
Thanks,
Manish
Arnd Bergmann wrote:
> On Tuesday 08 January 2008, Manish Ahuja wrote:
>
>> Initial patch for reserving memory in early boot, and freeing it later.
>> If the previous boot had ended with a crash, the reserved memory would contain
>> a copy of the crashed kernel data.
>>
>> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
>> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> I think the signed-off-by chain needs to be modified. The way it appears,
> you handled the patch first, then sent it to Linas, who forwarded it
> to whoever will take the patches from the list.
>
> This obviously isn't true, since you are actually the one who is sending
> out the patches. Moreover, I believe that the linas@austin.ibm.com
> address is now dead, and shouldn't be used for this any more.
>
> So, depending on which of you two wrote the majority of a patch, I think
> it should be either
>
> | Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> | Acked-by: Linas Vepstas <linasvepstas@gmail.com>
>
> or
>
> | From: Linas Vepstas <linasvepstas@gmail.com>
> | Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
>
> Arnd <><
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Linas Vepstas @ 2008-01-08 0:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: mahuja, linuxppc-dev, lkessler, strosake
In-Reply-To: <200801080126.51897.arnd@arndb.de>
On 07/01/2008, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 08 January 2008, Manish Ahuja wrote:
>
> > Initial patch for reserving memory in early boot, and freeing it later.
> > If the previous boot had ended with a crash, the reserved memory would contain
> > a copy of the crashed kernel data.
> >
> > Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> I think the signed-off-by chain needs to be modified. The way it appears,
> you handled the patch first, then sent it to Linas, who forwarded it
> to whoever will take the patches from the list.
Well,
-- there was dual authorship. I remangled the patches while Manish wrote
code & tested. And I'd mailed them out the first time around, so you could
say I forwarded after heavy editing.
> This obviously isn't true, since you are actually the one who is sending
> out the patches. Moreover, I believe that the linas@austin.ibm.com
> address is now dead, and shouldn't be used for this any more.
Hmm. I wanted to indicate that the work was done while I was at IBM;
clearly, no one is going through git and changing old, expired email
addrs, and so submission based on the old addr seemed appropriate.
I'm taking the Signed-off-by line as a quasi-legal thing: a fancy ID string,
identifying the author(s), rather than a new way to manage email
address books.
> So, depending on which of you two wrote the majority of a patch, I think
> it should be either
I'm not sure there was a clear majority. I think Manish did more work
in general, but we hacked this together side by side. I got him to create
working tested code; I busted it up into individual, clean, documented,
mailing-list ready chunks.
--linas
^ 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