* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-26 21:37 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld
In-Reply-To: <12801701823001-git-send-email-fchen@apm.com>
On Mon, Jul 26, 2010 at 11:49:41AM -0700, Fushen Chen wrote:
> This adds support for the USB host controller on APM SoC using
> Synopsys Designware IP.
>
> Signed-off-by: Fushen Chen <fchen@apm.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
Can I get some acks from the other developers who have worked on this
driver to verify that this version does indeed work, and that their work
has been integrated properly into the driver?
> --- /dev/null
> +++ b/drivers/usb/dwc_otg/dwc_otg_apmppc.c
> @@ -0,0 +1,408 @@
> +/*
> + * DesignWare HS OTG controller driver
> + *
> + * Author: Mark Miesfeld <mmiesfeld@apm.com>
> + *
> + * Based on versions provided by APM and Synopsis which are:
> + * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
> + * Modified by Stefan Roese <sr@denx.de>, DENX Software Engineering
> + *
> + * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
> + * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
> + * otherwise expressly agreed to in writing between Synopsys and you.
WTF?
Um, I think someone needs to rethink this submission, as this really
doesn't look like GPL code...
Oh, and where do I go get that "writing" between me and Synopsys to fix
this up? :)
> + * The Software IS NOT an item of Licensed Software or Licensed Product under
> + * any End User Software License Agreement or Agreement for Licensed Product
> + * with Synopsys or any supplement thereto. You are permitted to use and
> + * redistribute this Software in source and binary forms, with or without
> + * modification, provided that redistributions of source code must retain this
> + * notice. You may not view, use, disclose, copy or distribute this file or
> + * any information contained herein except pursuant to this license grant from
> + * Synopsys. If you do not agree with this notice, including the disclaimer
> + * below, then you are not authorized to use the Software.
Same here, what is going on?
Has someone run this through the proper legal approval to make public?
If so, someone needs to go kick a lawyer. If not, they just got in big
trouble...
> + * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
> + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> + * DAMAGE.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + * for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software Foundation,
> + * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
It's fun to just tack on the GPL boilerplate on a file, but when it
conflicts with other stuff in the same file, it kind of just makes us
all go crazy.
I can't take this at all, please go clean it up.
ick,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: David Daney @ 2010-07-26 21:55 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, Fushen Chen
In-Reply-To: <20100726213704.GA16268@suse.de>
On 07/26/2010 02:37 PM, Greg KH wrote:
[...]
>> +/*
>> + * DesignWare HS OTG controller driver
>> + *
>> + * Author: Mark Miesfeld<mmiesfeld@apm.com>
>> + *
>> + * Based on versions provided by APM and Synopsis which are:
>> + * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
>> + * Modified by Stefan Roese<sr@denx.de>, DENX Software Engineering
>> + *
>> + * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
>> + * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
>> + * otherwise expressly agreed to in writing between Synopsys and you.
>
> WTF?
>
I was not involved with this version of the patch, but is it really that
bad?
> Um, I think someone needs to rethink this submission, as this really
> doesn't look like GPL code...
>
> Oh, and where do I go get that "writing" between me and Synopsys to fix
> this up? :)
>
>> + * The Software IS NOT an item of Licensed Software or Licensed Product under
>> + * any End User Software License Agreement or Agreement for Licensed Product
>> + * with Synopsys or any supplement thereto. You are permitted to use and
>> + * redistribute this Software in source and binary forms, with or without
>> + * modification, provided that redistributions of source code must retain this
>> + * notice. You may not view, use, disclose, copy or distribute this file or
>> + * any information contained herein except pursuant to this license grant from
>> + * Synopsys. If you do not agree with this notice, including the disclaimer
>> + * below, then you are not authorized to use the Software.
>
> Same here, what is going on?
First of all, I am not a Lawyer, so take this with a grain of salt if
you wish.
How is this different than a 3-clause BSD License? There are other
instances of BSD Licensed code in the kernel (see include/linux/quota.h
for example).
>
> Has someone run this through the proper legal approval to make public?
> If so, someone needs to go kick a lawyer. If not, they just got in big
> trouble...
>
>> + * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
>> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
>> + * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
>> + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
>> + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
>> + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>> + * DAMAGE.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>> + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
>> + * for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software Foundation,
>> + * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>
>
> It's fun to just tack on the GPL boilerplate on a file, but when it
> conflicts with other stuff in the same file, it kind of just makes us
> all go crazy.
>
Indeed that part does seem questionable. Could it be used with the
original Synopsys license, without tacking on this GPL bit?
David Daney
^ permalink raw reply
* [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Grant Likely @ 2010-07-26 22:04 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
of_node_to_nid() is only relevant in a few architectures. Don't force
everyone to implement it anyway. This patch also adds asm-generic/of.h
which will be used to contain other overrideable symbols.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Changes in v3: don't use asm-generic, just keep macros in of.h
Changes in v2: address comments from sfr, add asm-generic/of.h
arch/microblaze/include/asm/topology.h | 10 ----------
arch/powerpc/include/asm/prom.h | 5 +++++
arch/powerpc/include/asm/topology.h | 7 -------
arch/sparc/include/asm/prom.h | 1 +
include/linux/of.h | 5 +++++
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/arch/microblaze/include/asm/topology.h b/arch/microblaze/include/asm/topology.h
index 96bcea5..5428f33 100644
--- a/arch/microblaze/include/asm/topology.h
+++ b/arch/microblaze/include/asm/topology.h
@@ -1,11 +1 @@
#include <asm-generic/topology.h>
-
-#ifndef _ASM_MICROBLAZE_TOPOLOGY_H
-#define _ASM_MICROBLAZE_TOPOLOGY_H
-
-struct device_node;
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-#endif /* _ASM_MICROBLAZE_TOPOLOGY_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index da7dd63..dca25a5 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -103,6 +103,11 @@ struct device_node *of_find_next_cache_node(struct device_node *np);
/* Get the MAC address */
extern const void *of_get_mac_address(struct device_node *np);
+#ifdef CONFIG_NUMA
+extern int of_node_to_nid(struct device_node *device);
+#define of_node_to_nid of_node_to_nid
+#endif
+
/**
* of_irq_map_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 32adf72..09dd38c 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -41,8 +41,6 @@ static inline int cpu_to_node(int cpu)
cpu_all_mask : \
node_to_cpumask_map[node])
-int of_node_to_nid(struct device_node *device);
-
struct pci_bus;
#ifdef CONFIG_PCI
extern int pcibus_to_node(struct pci_bus *bus);
@@ -94,11 +92,6 @@ extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
#else
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-
static inline void dump_numa_cpu_topology(void) {}
static inline int sysfs_add_device_to_node(struct sys_device *dev, int nid)
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index c82a7da..73befa5 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -43,6 +43,7 @@ extern int of_getintprop_default(struct device_node *np,
extern int of_find_in_proplist(const char *list, const char *match, int len);
#ifdef CONFIG_NUMA
extern int of_node_to_nid(struct device_node *dp);
+#define of_node_to_nid of_node_to_nid
#else
#define of_node_to_nid(dp) (-1)
#endif
diff --git a/include/linux/of.h b/include/linux/of.h
index b0756f3..cc936ca 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
#define OF_BAD_ADDR ((u64)-1)
+#ifndef of_node_to_nid
+static inline int of_node_to_nid(struct device_node *np) { return 0; }
+#define of_node_to_nid of_node_to_nid
+#endif
+
extern struct device_node *of_find_node_by_name(struct device_node *from,
const char *name);
#define for_each_node_by_name(dn, name) \
^ permalink raw reply related
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Grant Likely @ 2010-07-26 22:05 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
In-Reply-To: <20100726220405.1550.63442.stgit@angua>
On Mon, Jul 26, 2010 at 4:04 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> of_node_to_nid() is only relevant in a few architectures. =A0Don't force
> everyone to implement it anyway. =A0This patch also adds asm-generic/of.h
> which will be used to contain other overrideable symbols.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Oops. The patch subject I will change before mergine.
g.
> ---
>
> Changes in v3: don't use asm-generic, just keep macros in of.h
> Changes in v2: address comments from sfr, add asm-generic/of.h
>
> =A0arch/microblaze/include/asm/topology.h | =A0 10 ----------
> =A0arch/powerpc/include/asm/prom.h =A0 =A0 =A0 =A0| =A0 =A05 +++++
> =A0arch/powerpc/include/asm/topology.h =A0 =A0| =A0 =A07 -------
> =A0arch/sparc/include/asm/prom.h =A0 =A0 =A0 =A0 =A0| =A0 =A01 +
> =A0include/linux/of.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A05 =
+++++
> =A05 files changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/topology.h b/arch/microblaze/inc=
lude/asm/topology.h
> index 96bcea5..5428f33 100644
> --- a/arch/microblaze/include/asm/topology.h
> +++ b/arch/microblaze/include/asm/topology.h
> @@ -1,11 +1 @@
> =A0#include <asm-generic/topology.h>
> -
> -#ifndef _ASM_MICROBLAZE_TOPOLOGY_H
> -#define _ASM_MICROBLAZE_TOPOLOGY_H
> -
> -struct device_node;
> -static inline int of_node_to_nid(struct device_node *device)
> -{
> - =A0 =A0 =A0 return 0;
> -}
> -#endif /* _ASM_MICROBLAZE_TOPOLOGY_H */
> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/p=
rom.h
> index da7dd63..dca25a5 100644
> --- a/arch/powerpc/include/asm/prom.h
> +++ b/arch/powerpc/include/asm/prom.h
> @@ -103,6 +103,11 @@ struct device_node *of_find_next_cache_node(struct d=
evice_node *np);
> =A0/* Get the MAC address */
> =A0extern const void *of_get_mac_address(struct device_node *np);
>
> +#ifdef CONFIG_NUMA
> +extern int of_node_to_nid(struct device_node *device);
> +#define of_node_to_nid of_node_to_nid
> +#endif
> +
> =A0/**
> =A0* of_irq_map_pci - Resolve the interrupt for a PCI device
> =A0* @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/a=
sm/topology.h
> index 32adf72..09dd38c 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -41,8 +41,6 @@ static inline int cpu_to_node(int cpu)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu_all_mask =
: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 node_to_cpuma=
sk_map[node])
>
> -int of_node_to_nid(struct device_node *device);
> -
> =A0struct pci_bus;
> =A0#ifdef CONFIG_PCI
> =A0extern int pcibus_to_node(struct pci_bus *bus);
> @@ -94,11 +92,6 @@ extern void sysfs_remove_device_from_node(struct sys_d=
evice *dev, int nid);
>
> =A0#else
>
> -static inline int of_node_to_nid(struct device_node *device)
> -{
> - =A0 =A0 =A0 return 0;
> -}
> -
> =A0static inline void dump_numa_cpu_topology(void) {}
>
> =A0static inline int sysfs_add_device_to_node(struct sys_device *dev, int=
nid)
> diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.=
h
> index c82a7da..73befa5 100644
> --- a/arch/sparc/include/asm/prom.h
> +++ b/arch/sparc/include/asm/prom.h
> @@ -43,6 +43,7 @@ extern int of_getintprop_default(struct device_node *np=
,
> =A0extern int of_find_in_proplist(const char *list, const char *match, in=
t len);
> =A0#ifdef CONFIG_NUMA
> =A0extern int of_node_to_nid(struct device_node *dp);
> +#define of_node_to_nid of_node_to_nid
> =A0#else
> =A0#define of_node_to_nid(dp) =A0 =A0 (-1)
> =A0#endif
> diff --git a/include/linux/of.h b/include/linux/of.h
> index b0756f3..cc936ca 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __be=
32 *cell, int size)
>
> =A0#define OF_BAD_ADDR =A0 =A0((u64)-1)
>
> +#ifndef of_node_to_nid
> +static inline int of_node_to_nid(struct device_node *np) { return 0; }
> +#define of_node_to_nid of_node_to_nid
> +#endif
> +
> =A0extern struct device_node *of_find_node_by_name(struct device_node *fr=
om,
> =A0 =A0 =A0 =A0const char *name);
> =A0#define for_each_node_by_name(dn, name) \
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-26 22:05 UTC (permalink / raw)
To: David Daney; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, Fushen Chen
In-Reply-To: <4C4E0449.2070108@caviumnetworks.com>
On Mon, Jul 26, 2010 at 02:55:21PM -0700, David Daney wrote:
> On 07/26/2010 02:37 PM, Greg KH wrote:
> [...]
> >>+/*
> >>+ * DesignWare HS OTG controller driver
> >>+ *
> >>+ * Author: Mark Miesfeld<mmiesfeld@apm.com>
> >>+ *
> >>+ * Based on versions provided by APM and Synopsis which are:
> >>+ * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
> >>+ * Modified by Stefan Roese<sr@denx.de>, DENX Software Engineering
> >>+ *
> >>+ * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
> >>+ * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
> >>+ * otherwise expressly agreed to in writing between Synopsys and you.
> >
> >WTF?
> >
>
> I was not involved with this version of the patch, but is it really
> that bad?
You tell me, how does that interact with the GPL?
Do you want to be in charge of getting that "approval in writing" from
every single user of Linux and Synopsys so that this is somehow not a
"proprietary work of Synopsys, Inc."?
> >Um, I think someone needs to rethink this submission, as this really
> >doesn't look like GPL code...
> >
> >Oh, and where do I go get that "writing" between me and Synopsys to fix
> >this up? :)
> >
> >>+ * The Software IS NOT an item of Licensed Software or Licensed Product under
> >>+ * any End User Software License Agreement or Agreement for Licensed Product
> >>+ * with Synopsys or any supplement thereto. You are permitted to use and
> >>+ * redistribute this Software in source and binary forms, with or without
> >>+ * modification, provided that redistributions of source code must retain this
> >>+ * notice. You may not view, use, disclose, copy or distribute this file or
> >>+ * any information contained herein except pursuant to this license grant from
> >>+ * Synopsys. If you do not agree with this notice, including the disclaimer
> >>+ * below, then you are not authorized to use the Software.
> >
> >Same here, what is going on?
>
> First of all, I am not a Lawyer, so take this with a grain of salt
> if you wish.
>
> How is this different than a 3-clause BSD License? There are other
> instances of BSD Licensed code in the kernel (see
> include/linux/quota.h for example).
That's wonderful, then license it under the 3-clause BSD license. Don't
make up something else :)
If that's what is happening here, then document it as such.
> >Has someone run this through the proper legal approval to make public?
> >If so, someone needs to go kick a lawyer. If not, they just got in big
> >trouble...
> >
> >>+ * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
> >>+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> >>+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> >>+ * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
> >>+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> >>+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> >>+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> >>+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> >>+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> >>+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> >>+ * DAMAGE.
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+ *
> >>+ * This program is distributed in the hope that it will be useful, but
> >>+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> >>+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> >>+ * for more details.
> >>+ *
> >>+ * You should have received a copy of the GNU General Public License
> >>+ * along with this program; if not, write to the Free Software Foundation,
> >>+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> >
> >
> >It's fun to just tack on the GPL boilerplate on a file, but when it
> >conflicts with other stuff in the same file, it kind of just makes us
> >all go crazy.
> >
>
> Indeed that part does seem questionable. Could it be used with the
> original Synopsys license, without tacking on this GPL bit?
Um, no.
Please, someone needs to go run this past the Synopsys lawyers (yeah,
sorry, that's horrible to do, but it needs to be done to get it
correct.)
Because of this, I'd like to get a lawyer's signed-off-by on the code as
well just to verify that it's all ok.
Yes, that's a pain, but we gotta make sure that everyone involved knows
_exactly_ what is going on here, and this mess of header garbage shows
that no one knows what is happening.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-26 22:08 UTC (permalink / raw)
To: David Daney; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, Fushen Chen
In-Reply-To: <20100726220513.GA9671@suse.de>
On Mon, Jul 26, 2010 at 03:05:13PM -0700, Greg KH wrote:
> Please, someone needs to go run this past the Synopsys lawyers (yeah,
> sorry, that's horrible to do, but it needs to be done to get it
> correct.)
>
> Because of this, I'd like to get a lawyer's signed-off-by on the code as
> well just to verify that it's all ok.
Or someone with the legal authority to verify that this is an action
that Synopsys agrees with the license of the code now. This usually
means a VP or some such person that can act publicly for the company.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Sam Ravnborg @ 2010-07-26 22:26 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, davem
In-Reply-To: <20100726220405.1550.63442.stgit@angua>
On Mon, Jul 26, 2010 at 04:04:55PM -0600, Grant Likely wrote:
> of_node_to_nid() is only relevant in a few architectures. Don't force
> everyone to implement it anyway. This patch also adds asm-generic/of.h
> which will be used to contain other overrideable symbols.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Changes in v3: don't use asm-generic, just keep macros in of.h
> Changes in v2: address comments from sfr, add asm-generic/of.h
The use of asm-generic makes perfect sense.
This is how we usually deal with arch specific stuff.
With v3 of your patch we have a different result depending
on if we do:
#include <linux/of.h>
or we do:
#include <asm/prom.h>
This is undesireable.
I suggest to go back to v2 of your patch where you use asm-generic/of.h.
linux/of.h shall include asm/of.h
Then all archs shall have a of.h that may
include the asm-generic variant.
One patch to introduce of.h all over.
And a second patch to do the of_node_to_nid stuff would be appropriate.
> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
> index da7dd63..dca25a5 100644
> --- a/arch/powerpc/include/asm/prom.h
> +++ b/arch/powerpc/include/asm/prom.h
> @@ -103,6 +103,11 @@ struct device_node *of_find_next_cache_node(struct device_node *np);
> /* Get the MAC address */
> extern const void *of_get_mac_address(struct device_node *np);
>
This shall go in asm/of.h
> +#ifdef CONFIG_NUMA
> +extern int of_node_to_nid(struct device_node *device);
> +#define of_node_to_nid of_node_to_nid
This define is used to tell asm-generic/of.h that the arch has
a local definition - OK.
> +#endif
> +
> /**
> * of_irq_map_pci - Resolve the interrupt for a PCI device
> * @pdev: the device whose interrupt is to be resolved
> diff --git a/include/linux/of.h b/include/linux/of.h
> index b0756f3..cc936ca 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
>
> #define OF_BAD_ADDR ((u64)-1)
>
> +#ifndef of_node_to_nid
> +static inline int of_node_to_nid(struct device_node *np) { return 0; }
> +#define of_node_to_nid of_node_to_nid
But I fail to see the purpose of this define.
Sam
^ permalink raw reply
* Re: [RFC][PATCH] kconfig: implement select with values
From: Sam Ravnborg @ 2010-07-26 22:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Marek, Francis Galiegue, Andi Kleen, Catalin Marinas,
linux-kbuild, ppc-dev, Li Zefan, LKML, Steven Rostedt,
Josh Triplett, Vadim Bendebury, Nir Tzachar, Trevor Keith,
Jiri Kosina, Andrew Morton, Linus, Cheng Renquan
In-Reply-To: <20100720043706.3813715a.sfr@canb.auug.org.au>
On Tue, Jul 20, 2010 at 04:37:06AM +1000, Stephen Rothwell wrote:
> This is a fairly brute force approach to allowing a Kconfig "select"
> to specify an excplicit value for the selected config sybmol.
>
> The syntax of select is changed to:
>
> "select" <symbol> [<expr>] ["if" expr]
>
> The approach taken is to add a list of <value, dependency expression>
> pairs to the symbol and check them whenever the reverse depends (from
> a current-style select) are checked.
I do not see the need for this feature.
I have read most of the postings in the defconfig battle and
I saw Linus' select suggestion.
But we can do almost all of this today (or tomorrow).
Consider following Kconfig file:
config USB_SUPPORT
def_bool n
config NET
def_bool y
source arch/x86/Kconfig
We use the feature that we can specify the same
config option several times.
And the first default value that is "visible"
will be used.
So it allows us to enable and disable any option.
And if we for example want to set a specific LOG_BUF_SHIFT
we use the same trick:
config LOG_BUF_SHIFT
int
default 14
Now in the original suggestion of Linus he used:
KBUILD_KCONFIG=Mykconfig make allnoconfig
And "allnoconfig" would make the modified defaults useless.
But the soon-to-be-introduced alldefconfig is more sensible.
alldefconfig uses default values for everything.
So with alldefconfig I think we have all the features we need
to create sensible default configs in the Kconfig language.
And therefore I do not see the need for the extension to select.
For the same reason I did not look closer at the implementation.
Sam
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Grant Likely @ 2010-07-26 22:42 UTC (permalink / raw)
To: Sam Ravnborg
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, davem
In-Reply-To: <20100726222627.GA23501@merkur.ravnborg.org>
On Mon, Jul 26, 2010 at 4:26 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Mon, Jul 26, 2010 at 04:04:55PM -0600, Grant Likely wrote:
>> of_node_to_nid() is only relevant in a few architectures. =A0Don't force
>> everyone to implement it anyway. =A0This patch also adds asm-generic/of.=
h
>> which will be used to contain other overrideable symbols.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> Changes in v3: don't use asm-generic, just keep macros in of.h
>> Changes in v2: address comments from sfr, add asm-generic/of.h
>
> The use of asm-generic makes perfect sense.
> This is how we usually deal with arch specific stuff.
>
> With v3 of your patch we have a different result depending
> on if we do:
> #include <linux/of.h>
>
> or we do:
> #include <asm/prom.h>
>
> This is undesireable.
The patch does maintain consistency. Including only asm/prom.h may
mean that of_node_to_nid is undefined, but it will never result in a
different definition. linux/of.h includes asm/prom.h before doing the
#ifdef test.
> I suggest to go back to v2 of your patch where you use asm-generic/of.h.
Stephen suggested dropping asm-generic/of.h. I'm happy to do it either way=
.
> linux/of.h shall include asm/of.h
> Then all archs shall have a of.h that may
> include the asm-generic variant.
>
>
> One patch to introduce of.h all over.
> And a second patch to do the of_node_to_nid stuff would be appropriate.
>
>
>> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/=
prom.h
>> index da7dd63..dca25a5 100644
>> --- a/arch/powerpc/include/asm/prom.h
>> +++ b/arch/powerpc/include/asm/prom.h
>> @@ -103,6 +103,11 @@ struct device_node *of_find_next_cache_node(struct =
device_node *np);
>> =A0/* Get the MAC address */
>> =A0extern const void *of_get_mac_address(struct device_node *np);
>>
>
> This shall go in asm/of.h
>> +#ifdef CONFIG_NUMA
>> +extern int of_node_to_nid(struct device_node *device);
>> +#define of_node_to_nid of_node_to_nid
>
> This define is used to tell asm-generic/of.h that the arch has
> a local definition - OK.
>
>> +#endif
>> +
>> =A0/**
>> =A0 * of_irq_map_pci - Resolve the interrupt for a PCI device
>> =A0 * @pdev: =A0 =A0the device whose interrupt is to be resolved
>
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index b0756f3..cc936ca 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __b=
e32 *cell, int size)
>>
>> =A0#define OF_BAD_ADDR =A0((u64)-1)
>>
>> +#ifndef of_node_to_nid
>> +static inline int of_node_to_nid(struct device_node *np) { return 0; }
>> +#define of_node_to_nid of_node_to_nid
>
> But I fail to see the purpose of this define.
It protects against some later include file doing a #define
of_node_to_nid and thus resulting in an inconsistent definition. If
some code tries to do this then the preprocessor will complain. This
is the pattern that Stephen suggested.
g.
^ permalink raw reply
* Re: [RFC][PATCH] kconfig: implement select with values
From: Grant Likely @ 2010-07-26 22:47 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Michal Marek, Stephen Rothwell, Andi Kleen, Catalin Marinas,
linux-kbuild, Linus, Li Zefan, LKML, Steven Rostedt,
Josh Triplett, Vadim Bendebury, Nir Tzachar, Francis Galiegue,
Trevor Keith, Jiri Kosina, Andrew Morton, ppc-dev, Cheng Renquan
In-Reply-To: <20100726221717.GA22439@merkur.ravnborg.org>
Hi Sam,
On Mon, Jul 26, 2010 at 4:17 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Tue, Jul 20, 2010 at 04:37:06AM +1000, Stephen Rothwell wrote:
>> This is a fairly brute force approach to allowing a Kconfig "select"
>> to specify an excplicit value for the selected config sybmol.
>>
>> The syntax of select is changed to:
>>
>> =A0 =A0 =A0 "select" <symbol> [<expr>] ["if" expr]
>>
>> The approach taken is to add a list of <value, dependency expression>
>> pairs to the symbol and check them whenever the reverse depends (from
>> a current-style select) are checked.
>
> I do not see the need for this feature.
> I have read most of the postings in the defconfig battle and
> I saw Linus' select suggestion.
>
> But we can do almost all of this today (or tomorrow).
>
> Consider following Kconfig file:
>
> =A0 =A0config USB_SUPPORT
> =A0 =A0 =A0 =A0 =A0 =A0def_bool n
>
> =A0 =A0config NET
> =A0 =A0 =A0 =A0 =A0 =A0def_bool y
>
> =A0 =A0source arch/x86/Kconfig
>
> We use the feature that we can specify the same
> config option several times.
> And the first default value that is "visible"
> will be used.
>
> So it allows us to enable and disable any option.
>
> And if we for example want to set a specific LOG_BUF_SHIFT
> we use the same trick:
>
> =A0 =A0config LOG_BUF_SHIFT
> =A0 =A0 =A0 =A0 =A0 =A0int
> =A0 =A0 =A0 =A0 =A0 =A0default 14
Cute. I didn't know this was possible. I'll give it a try and see
how it works for me. Do override config options also pickup
select/depends constraints applied by later definitions? I think that
would be necessary to kick out warnings when a defconfig selection
isn't actually achievable.
g.
>
>
> Now in the original suggestion of Linus he used:
>
> =A0 =A0KBUILD_KCONFIG=3DMykconfig make allnoconfig
>
> And "allnoconfig" would make the modified defaults useless.
>
> But the soon-to-be-introduced alldefconfig is more sensible.
>
> alldefconfig uses default values for everything.
I basically used defconfig in the prototype that I posted. I think it
works well for me, and I've got it integrated into the build targets
(just like Stephen's earlier patch) without having to do a
KBUILD_KCONFIG trick.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: David Miller @ 2010-07-26 22:48 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, sam
In-Reply-To: <AANLkTikcV3jJUm_My-oK-drudSDz3M2iH1cWhxdt+W1s@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Mon, 26 Jul 2010 16:42:20 -0600
> It protects against some later include file doing a #define
> of_node_to_nid and thus resulting in an inconsistent definition. If
> some code tries to do this then the preprocessor will complain. This
> is the pattern that Stephen suggested.
Also, it would be nice to unravel the "0" vs. "-1" default
inconsistency.
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Grant Likely @ 2010-07-26 22:51 UTC (permalink / raw)
To: David Miller
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, sam
In-Reply-To: <20100726.154854.35052662.davem@davemloft.net>
On Mon, Jul 26, 2010 at 4:48 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Mon, 26 Jul 2010 16:42:20 -0600
>
>> It protects against some later include file doing a #define
>> of_node_to_nid and thus resulting in an inconsistent definition. =A0If
>> some code tries to do this then the preprocessor will complain. =A0This
>> is the pattern that Stephen suggested.
>
> Also, it would be nice to unravel the "0" vs. "-1" default
> inconsistency.
Indeed. I looked at it briefly, but it wasn't immediately clear what
the impact would be to switch powerpc over to -1, and it looked to me
like sparc depends on -1 to signify no node association.
g.
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-26 23:05 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, David Daney, Fushen Chen
In-Reply-To: <20100726220809.GA9784@suse.de>
Hi Greg:
We are having our legal revisit this again. What would you advise us
to do at this
point? Disclose the agreement or have someone with legal authority
reply this thread.
Perhaps something in the header that states Applied Micro verified
with Synopsys
to use this code for GPL purpose.
Feng Kan
On Mon, Jul 26, 2010 at 3:08 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jul 26, 2010 at 03:05:13PM -0700, Greg KH wrote:
>> Please, someone needs to go run this past the Synopsys lawyers (yeah,
>> sorry, that's horrible to do, but it needs to be done to get it
>> correct.)
>>
>> Because of this, I'd like to get a lawyer's signed-off-by on the code as
>> well just to verify that it's all ok.
>
> Or someone with the legal authority to verify that this is an action
> that Synopsys agrees with the license of the code now. =C2=A0This usually
> means a VP or some such person that can act publicly for the company.
>
> thanks,
>
> greg k-h
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-26 23:16 UTC (permalink / raw)
To: Feng Kan; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, David Daney, Fushen Chen
In-Reply-To: <AANLkTinbTnrr9DCiSgKngAjaak=U0qDYcCxbNZR4Nm3D@mail.gmail.com>
On Mon, Jul 26, 2010 at 04:05:49PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We are having our legal revisit this again. What would you advise us
> to do at this point?
I thought I was very clear below as to what is needed.
> Disclose the agreement or have someone with legal authority reply this
> thread.
Neither will resolve the end issue, right?
> Perhaps something in the header that states Applied Micro verified
> with Synopsys to use this code for GPL purpose.
No, that will just make it messier. Someone needs to delete all of the
mess in the file, put the proper license information for what the code
is being licensed under (whatever it is), and provide a signed-off-by
from a person from Synopsys and APM that can speak for the company that
they agree that the code can properly be placed into the Linux kernel.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: David Miller @ 2010-07-27 1:38 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, sam
In-Reply-To: <AANLkTikpON7WUkTLrnW4y2kghM=H8cLCAFst08S3cL_Z@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Mon, 26 Jul 2010 16:51:01 -0600
> Indeed. I looked at it briefly, but it wasn't immediately clear what
> the impact would be to switch powerpc over to -1, and it looked to me
> like sparc depends on -1 to signify no node association.
Kernel wide, NUMA interfaces tend to take "-1" to mean "any node."
I had looked over the powerpc cases, and besides 1 or 2 strange
locations the powerpc call sites were ready to handle -1.
^ permalink raw reply
* Re: [PATCH v3] of: Create asm-generic/of.h and provide default of_node_to_nid()
From: Grant Likely @ 2010-07-27 1:57 UTC (permalink / raw)
To: David Miller
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux, sam
In-Reply-To: <20100726.183808.15223674.davem@davemloft.net>
On Mon, Jul 26, 2010 at 7:38 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Mon, 26 Jul 2010 16:51:01 -0600
>
>> Indeed. =A0I looked at it briefly, but it wasn't immediately clear what
>> the impact would be to switch powerpc over to -1, and it looked to me
>> like sparc depends on -1 to signify no node association.
>
> Kernel wide, NUMA interfaces tend to take "-1" to mean "any node."
>
> I had looked over the powerpc cases, and besides 1 or 2 strange
> locations the powerpc call sites were ready to handle -1.
Okay, well let me rework the patch to make -1 the default and let
powerpc override it. A follow-on patch can fix up the powerpc usage
of 0.
g.
^ permalink raw reply
* Re: [PATCH 4/8] v3 Allow memory_block to span multiple memory sections
From: Dave Hansen @ 2010-07-27 2:36 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, greg, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <4C4A5985.6000206@austin.ibm.com>
On Fri, 2010-07-23 at 22:09 -0500, Nathan Fontenot wrote:
> If we add a lock should I submit it as part of this patchset? or
> submit it
> as a follow-on?
It should probably be at the beginning of the patch set. We don't want
to have a case where your set introduces races that we _need_ a later
patch to fix.
-- Dave
^ permalink raw reply
* Where are logical memory block regions setup?
From: Rick Ramstetter @ 2010-07-27 2:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
Hi all,
Where can I find the code that sets values in lmb.reserved.region[i]?
This is in reference to 2.6.27's arch/powerpc/mm/mem.c and
include/linux/lmb.h
I'm looking specifically for code that sets lmb_region's region.size and
region.base.
Thank you,
-Rick
--
J. Rick Ramstetter
[-- Attachment #2: Type: text/html, Size: 352 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32
From: Simon Horman @ 2010-07-27 2:55 UTC (permalink / raw)
To: Matthew McClintock; +Cc: muvarov, linuxppc-dev, sebastian, kexec
In-Reply-To: <1279687384-9770-1-git-send-email-msm@freescale.com>
[Cced linuxppc-dev]
On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> This patch series adds full support for booting with a flat device tree
> with either uImage or elf file formats. Kexec and Kdump should work, and
> you should also be able to use ramdisks or reuse your current ramdisk as well
>
> This patch series was tested on an mpc85xx system with a kernel version
> 2.6.35-rc3
>
> v1: Initial version
>
> v2: Added support for fs2dt (file system to device tree)
>
> v3: Fix some misc. git problems I had and other code cleanups
Hi Matthew,
I'm a little concerned that these changes are non trivial and haven't had
much review. But I am prepared to put them into my tree once 2.0.2 is
released - perhaps that way they will get some test coverage. Does
that work for you?
>
> Matthew McClintock (7):
> Restore kexec uImage-ppc to working state
> Fix case where phys_addr_t != unsigned long when reading proc entries
> Update uImage to support crash kernel and misc fixes
> Update Elf-ppc to support crash kernel and misc fixes
> Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
> Add support for reworking flat device tree support
> Add documentation/howto for mpc85xx systems
>
> doc/mpc85xx.txt | 190 +++++++++++++++++++++
> kexec/arch/ppc/Makefile | 1 +
> kexec/arch/ppc/fixup_dtb.c | 298 ++++++++++++++++++++++++++++++++-
> kexec/arch/ppc/fixup_dtb.h | 6 +-
> kexec/arch/ppc/include/arch/options.h | 3 +
> kexec/arch/ppc/kexec-elf-ppc.c | 186 +++++++++------------
> kexec/arch/ppc/kexec-ppc.c | 262 +++++++++++++++++------------
> kexec/arch/ppc/kexec-ppc.h | 3 +
> kexec/arch/ppc/kexec-uImage-ppc.c | 136 ++++++++++++---
> kexec/arch/ppc/ops.h | 1 -
> purgatory/arch/ppc/purgatory-ppc.c | 5 +
> 11 files changed, 852 insertions(+), 239 deletions(-)
> create mode 100644 doc/mpc85xx.txt
>
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32
From: Maxim Uvarov @ 2010-07-27 3:59 UTC (permalink / raw)
To: Simon Horman; +Cc: Matthew McClintock, sebastian, kexec, linuxppc-dev
In-Reply-To: <20100727025506.GA1944@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]
2010/7/27 Simon Horman <horms@verge.net.au>
> [Cced linuxppc-dev]
>
> On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> > This patch series adds full support for booting with a flat device tree
> > with either uImage or elf file formats. Kexec and Kdump should work, and
> > you should also be able to use ramdisks or reuse your current ramdisk as
> well
> >
> > This patch series was tested on an mpc85xx system with a kernel version
> > 2.6.35-rc3
> >
> > v1: Initial version
> >
> > v2: Added support for fs2dt (file system to device tree)
> >
> > v3: Fix some misc. git problems I had and other code cleanups
>
> Hi Matthew,
>
> I'm a little concerned that these changes are non trivial and haven't had
> much review. But I am prepared to put them into my tree once 2.0.2 is
> released - perhaps that way they will get some test coverage. Does
> that work for you?
>
> Actually Matthew did that did not work before. Like kdump for booke. But
because kernel patches are not already in it's not urgent to commit it right
now.
> >
> > Matthew McClintock (7):
> > Restore kexec uImage-ppc to working state
> > Fix case where phys_addr_t != unsigned long when reading proc entries
> > Update uImage to support crash kernel and misc fixes
> > Update Elf-ppc to support crash kernel and misc fixes
> > Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
> > Add support for reworking flat device tree support
> > Add documentation/howto for mpc85xx systems
> >
> > doc/mpc85xx.txt | 190 +++++++++++++++++++++
> > kexec/arch/ppc/Makefile | 1 +
> > kexec/arch/ppc/fixup_dtb.c | 298
> ++++++++++++++++++++++++++++++++-
> > kexec/arch/ppc/fixup_dtb.h | 6 +-
> > kexec/arch/ppc/include/arch/options.h | 3 +
> > kexec/arch/ppc/kexec-elf-ppc.c | 186 +++++++++------------
> > kexec/arch/ppc/kexec-ppc.c | 262
> +++++++++++++++++------------
> > kexec/arch/ppc/kexec-ppc.h | 3 +
> > kexec/arch/ppc/kexec-uImage-ppc.c | 136 ++++++++++++---
> > kexec/arch/ppc/ops.h | 1 -
> > purgatory/arch/ppc/purgatory-ppc.c | 5 +
> > 11 files changed, 852 insertions(+), 239 deletions(-)
> > create mode 100644 doc/mpc85xx.txt
> >
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
--
Best regards,
Maxim Uvarov
[-- Attachment #2: Type: text/html, Size: 3428 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32
From: Matthew McClintock @ 2010-07-27 4:22 UTC (permalink / raw)
To: Simon Horman; +Cc: muvarov, linuxppc-dev, sebastian, kexec
In-Reply-To: <20100727025506.GA1944@verge.net.au>
On Jul 26, 2010, at 9:55 PM, Simon Horman wrote:
> [Cced linuxppc-dev]
>=20
> On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
>> This patch series adds full support for booting with a flat device =
tree
>> with either uImage or elf file formats. Kexec and Kdump should work, =
and
>> you should also be able to use ramdisks or reuse your current ramdisk =
as well
>>=20
>> This patch series was tested on an mpc85xx system with a kernel =
version
>> 2.6.35-rc3
>>=20
>> v1: Initial version
>>=20
>> v2: Added support for fs2dt (file system to device tree)
>>=20
>> v3: Fix some misc. git problems I had and other code cleanups
>=20
> Hi Matthew,
>=20
> I'm a little concerned that these changes are non trivial and haven't =
had
> much review. But I am prepared to put them into my tree once 2.0.2 is
> released - perhaps that way they will get some test coverage. Does
> that work for you?
Either way works for me. I know they could use more review, however as =
Maxim said the current tree does not work AFAIK. Either way, I'm willing =
to keeping addressing everyones concerns and wait or move forward and =
make some quick fixes as well.
-M
>=20
>>=20
>> Matthew McClintock (7):
>> Restore kexec uImage-ppc to working state
>> Fix case where phys_addr_t !=3D unsigned long when reading proc =
entries
>> Update uImage to support crash kernel and misc fixes
>> Update Elf-ppc to support crash kernel and misc fixes
>> Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
>> Add support for reworking flat device tree support
>> Add documentation/howto for mpc85xx systems
>>=20
>> doc/mpc85xx.txt | 190 +++++++++++++++++++++
>> kexec/arch/ppc/Makefile | 1 +
>> kexec/arch/ppc/fixup_dtb.c | 298 =
++++++++++++++++++++++++++++++++-
>> kexec/arch/ppc/fixup_dtb.h | 6 +-
>> kexec/arch/ppc/include/arch/options.h | 3 +
>> kexec/arch/ppc/kexec-elf-ppc.c | 186 +++++++++------------
>> kexec/arch/ppc/kexec-ppc.c | 262 =
+++++++++++++++++------------
>> kexec/arch/ppc/kexec-ppc.h | 3 +
>> kexec/arch/ppc/kexec-uImage-ppc.c | 136 ++++++++++++---
>> kexec/arch/ppc/ops.h | 1 -
>> purgatory/arch/ppc/purgatory-ppc.c | 5 +
>> 11 files changed, 852 insertions(+), 239 deletions(-)
>> create mode 100644 doc/mpc85xx.txt
>>=20
>>=20
>>=20
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>=20
^ permalink raw reply
* Memory Mapping DMA Buffers in User Space
From: Ravi Gupta @ 2010-07-27 6:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Hi,
I am new to linux device driver development and I'm trying to learn the
memory mapping. Currently I am trying to memory map a dma buffer allocated
using pci_alloc_consistent() function.
Now what exactly I want is that whenever I map a char device from user space
program, let say /dev/test, internally that DMA buffer gets memory mapped to
the user space? Also what should I pass as the length parameter in the
mmap() function?
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 505 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] kconfig: implement select with values
From: Sam Ravnborg @ 2010-07-27 6:45 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Marek, Stephen Rothwell, Andi Kleen, Catalin Marinas,
linux-kbuild, Linus, Li Zefan, LKML, Steven Rostedt,
Josh Triplett, Vadim Bendebury, Nir Tzachar, Francis Galiegue,
Trevor Keith, Jiri Kosina, Andrew Morton, ppc-dev, Cheng Renquan
In-Reply-To: <AANLkTikP3nZd-LionO27vsinjXz=upKbDZeErSD4CAfz@mail.gmail.com>
>
> Cute. I didn't know this was possible. I'll give it a try and see
> how it works for me. Do override config options also pickup
> select/depends constraints applied by later definitions? I think that
> would be necessary to kick out warnings when a defconfig selection
> isn't actually achievable.
kconfig allows one to add more properties to a config
symbol by defining the symbol again.
So:
config FOO
bool
prompt "foo prompt"
default y
help
Help text
Is the same as:
config FOO
bool
config FOO
prompt "foo prompt"
config FOO
default y
config FOO
help
help text
The abvoe four lines can be located in different files.
And likewise kconfig allows the same property to be
specified twice or more.
So it is OK to say:
config BAR
tristate "bar prompt"
default m
default y
Here kconfig just picks the first default is see.
And the example in my original mail uses the feature
that we can specify several defaults - and kconfig uses the first.
For choices the same is possible but then you need to use
a named choice - something that no one does today in the kernel.
choice CHOICE_X86_CPU
default M386
endchoice
Here we change the default to M386 which becomes the
selected if we use "alldefconfig".
[Note: It does not work until we use named choices in arch/x86/Kconfig.cpu]
>
> > Now in the original suggestion of Linus he used:
> >
> > KBUILD_KCONFIG=Mykconfig make allnoconfig
> >
> > And "allnoconfig" would make the modified defaults useless.
> >
> > But the soon-to-be-introduced alldefconfig is more sensible.
> >
> > alldefconfig uses default values for everything.
>
> I basically used defconfig in the prototype that I posted. I think it
> works well for me, and I've got it integrated into the build targets
> (just like Stephen's earlier patch) without having to do a
> KBUILD_KCONFIG trick.
"defconfig" with an empty file gives same config as "alldefconfig" so
it makes sense. But we wanted to drop the use of defconfig files
in favour of files with Kconfig syntax.
So alldefconfig is just a better fit here.
[The above btw. also makes "savedefconfig" less usefull].
Sam
^ permalink raw reply
* Re: Memory Mapping a char array in User Space
From: Ravi Gupta @ 2010-07-27 7:04 UTC (permalink / raw)
To: David Howells; +Cc: linuxppc-dev
In-Reply-To: <918.1280173321@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
Hi David,
Thanks for the quick reply. One more thing, in the end I have to memory map
a DMA buffer allocated using pci_alloc_consisten() function to user space.
*> I think you should be leaving the mapping to the core VM routines.*
*> Furthermore, I don't think *you* should be calling remap_pfn_range().*
Let say I have allocated a page using __get_free_pages(). But how would the
core VM routines knows that which page I want to memory map? If possible,
please explain with example.
[-- Attachment #2: Type: text/html, Size: 573 bytes --]
^ permalink raw reply
* [PATCH] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-27 7:54 UTC (permalink / raw)
To: linuxppc-dev
When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed. The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck. On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
This patch kicks each present offline CPU awake before the kexec, so that
none are lost to these assumptions in the subsequent kernel.
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/kernel/machine_kexec_64.c | 42 +++++++++++++++++++++++++++----
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 4fbb3be..c2fd914 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,8 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -181,7 +183,7 @@ static void kexec_prepare_cpus_wait(int wait_state)
int my_cpu, i, notified=-1;
my_cpu = get_cpu();
- /* Make sure each CPU has atleast made it to the state we need */
+ /* Make sure each CPU has at least made it to the state we need. */
for_each_online_cpu(i) {
if (i == my_cpu)
continue;
@@ -189,9 +191,9 @@ static void kexec_prepare_cpus_wait(int wait_state)
while (paca[i].kexec_state < wait_state) {
barrier();
if (i != notified) {
- printk( "kexec: waiting for cpu %d (physical"
- " %d) to enter %i state\n",
- i, paca[i].hw_cpu_id, wait_state);
+ printk(KERN_INFO "kexec: waiting for cpu %d "
+ "(physical %d) to enter %i state\n",
+ i, paca[i].hw_cpu_id, wait_state);
notified = i;
}
}
@@ -199,9 +201,32 @@ static void kexec_prepare_cpus_wait(int wait_state)
mb();
}
-static void kexec_prepare_cpus(void)
+/*
+ * We need to make sure each present CPU is online. The next kernel will scan
+ * the device tree and assume primary threads are online and query secondary
+ * threads via RTAS to online them if required. If we don't online primary
+ * threads, they will be stuck. However, we also online secondary threads as we
+ * may be using 'cede offline'. In this case RTAS doesn't see the secondary
+ * threads as offline -- and again, these CPUs will be stuck.
+ *
+ * So, we online all CPUs that should be running, including secondary threads.
+ */
+static void wake_offline_cpus(void)
{
+ int cpu = 0;
+ for_each_present_cpu(cpu) {
+ if (!cpu_online(cpu)) {
+ printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
+ cpu);
+ cpu_up(cpu);
+ }
+ }
+}
+
+static void kexec_prepare_cpus(void)
+{
+ wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
@@ -215,7 +240,10 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
- /* Before removing MMU mapings make sure all CPUs have entered real mode */
+ /*
+ * Before removing MMU mappings make sure all CPUs have entered real
+ * mode:
+ */
kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
put_cpu();
@@ -284,6 +312,8 @@ void default_machine_kexec(struct kimage *image)
if (crashing_cpu == -1)
kexec_prepare_cpus();
+ pr_debug("kexec: Starting switchover sequence.\n");
+
/* switch to a staticly allocated stack. Based on irq stack code.
* XXX: the task struct will likely be invalid once we do the copy!
*/
--
1.6.3.3
^ 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