* Re: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'
From: Benjamin Herrenschmidt @ 2011-02-07 1:37 UTC (permalink / raw)
To: Meador Inge; +Cc: Hollis Blanchard, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D4F4BAD.4000909@mentor.com>
On Sun, 2011-02-06 at 19:32 -0600, Meador Inge wrote:
> So barring the removal of protected sources, does the inclusion of the
> "pic-no-reset" property seem reasonable?
Sure.
Ben.
^ permalink raw reply
* Re: [PATCH 3/4]Define memory_block_size_bytes for powerpc/pseries
From: Greg KH @ 2011-02-07 1:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linux-mm, Robin Holt, linuxppc-dev,
KAMEZAWA Hiroyuki
In-Reply-To: <1297035563.14982.15.camel@pasglop>
On Mon, Feb 07, 2011 at 10:39:23AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-01-20 at 10:45 -0600, Nathan Fontenot wrote:
> > Define a version of memory_block_size_bytes() for powerpc/pseries such that
> > a memory block spans an entire lmb.
> >
> > Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
> > Reviewed-by: Robin Holt <holt@sgi.com>
>
> Hi Nathan !
>
> Is somebody from -mm picking the rest of the series ? This patch as well
> or shall I wait for the first two to go in and then pick that one in
> -powerpc ?
I took all of these in my tree already, is that ok?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc: Fix call to flush_ptrace_hw_breakpoint()
From: K.Prasad @ 2011-02-07 2:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1297032853.14982.3.camel@pasglop>
On Mon, Feb 07, 2011 at 09:54:13AM +1100, Benjamin Herrenschmidt wrote:
> A typo in the #ifdef statement makes us never call it
> in flush_thread()
>
I wish it never compiled for such typos :-)
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
> ---
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 7a1d5cb..c4e4eab 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -670,11 +670,11 @@ void flush_thread(void)
> {
> discard_lazy_cpu_state();
>
> -#ifdef CONFIG_HAVE_HW_BREAKPOINTS
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> flush_ptrace_hw_breakpoint(current);
> -#else /* CONFIG_HAVE_HW_BREAKPOINTS */
> +#else /* CONFIG_HAVE_HW_BREAKPOINT */
> set_debug_reg_defaults(¤t->thread);
> -#endif /* CONFIG_HAVE_HW_BREAKPOINTS */
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> }
>
> void
>
>
^ permalink raw reply
* Re: [PATCH -mm 2/6] powerpc: convert little-endian bitops macros to static inline functions
From: Akinobu Mita @ 2011-02-07 3:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, linuxppc-dev, akpm, Paul Mackerras, linux-kernel
In-Reply-To: <1297034086.14982.8.camel@pasglop>
2011/2/7 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Thu, 2011-01-27 at 22:56 +0900, Akinobu Mita wrote:
>> (This patch is intended to be folded into the patch in -mm:
>> powerpc-introduce-little-endian-bitops.patch)
>>
>> The little-endian bitops on powerpc are written as preprocessor
>> macros with the cast to "unsigned long *".
>> This means that even non-pointers will be accepted without an error, and
>> that is a Very Bad Thing.
>>
>> This converts the little-endian bitops macros to static inline functions
>> with proper prototypes.
>
> No objection to the powerpc variant of the patches. What is the status
> with the wholes series tho ? Does it looks like its going to be
> accepted ? Do you expect my Ack and will merge the whole thing at once ?
The whole series now seems acceptable since I fixed two issues
that Linus found annoying. (the naming and the change of prototype)
Please give your ack if it is OK.
I should have fixed them quickly so that the series went upstream
in the last merge windows. But I couldn't because I spent some time
fixing and compile testing for a bisection hole.
> Does it break bisection unless it's merged as one single giant patch ?
I think there is no known problem that breaks bisectability by
this patch series.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix call to flush_ptrace_hw_breakpoint()
From: Benjamin Herrenschmidt @ 2011-02-07 3:10 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, David Kleikamp
In-Reply-To: <20110207025643.GA12223@in.ibm.com>
On Mon, 2011-02-07 at 08:26 +0530, K.Prasad wrote:
> On Mon, Feb 07, 2011 at 09:54:13AM +1100, Benjamin Herrenschmidt wrote:
> > A typo in the #ifdef statement makes us never call it
> > in flush_thread()
> >
>
> I wish it never compiled for such typos :-)
>
>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
Interestingly, that 'fix' now breaks the build:
cc1: warnings being treated as errors
/home/benh/linux-powerpc-test/arch/powerpc/kernel/process.c:356: error:
'set_debug_reg_defaults' defined but not used
This file is is becoming an absolute mess of ifdef's in large part due
to the new BookE debug stuff and your HW breakpoint stuff... Any chance
you and Shaggy see if you can improve that situation a bit ?
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-02-07 3:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a few powerpc bug fixes for you. Mostly Anton and Jesse fixing
up the new VPNH feature (which was added this cycle) and a handful of
other fixes worth having.
Cheers,
Ben.
The following changes since commit 8dbdea8444d303a772bceb1ba963f0e3273bfc5e:
Merge branch 'ixp4xx' of git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux-2.6 (2011-02-06 12:05:58 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (6):
powerpc/numa: Only use active VPHN count fields
powerpc/numa: Check for all VPHN changes
powerpc/numa: Add length when creating OF properties via VPHN
powerpc/numa: Disable VPHN on dedicated processor partitions
powerpc/numa: Fix bug in unmap_cpu_from_node
powerpc: Fix hcall tracepoint recursion
Benjamin Herrenschmidt (2):
powerpc: Pass the right cpu_spec to ->setup_cpu() on 64-bit
powerpc: Fix some 6xx/7xxx CPU setup functions
Jesse Larrew (3):
powerpc/pseries: Fix typo in VPHN comments
powerpc/pseries: Fix brace placement in numa.c
powerpc/pseries: Remove unnecessary variable initializations in numa.c
Scott Wood (2):
powerpc: Fix pfn_valid() when memory starts at a non-zero address
powerpc/book3e: Protect complex macro args in mmu-book3e.h
arch/powerpc/include/asm/mmu-book3e.h | 8 ++--
arch/powerpc/include/asm/page.h | 2 +-
arch/powerpc/kernel/cpu_setup_6xx.S | 40 ++++++++++++------------
arch/powerpc/kernel/cputable.c | 4 +-
arch/powerpc/mm/numa.c | 55 ++++++++++++++++++---------------
arch/powerpc/platforms/pseries/lpar.c | 37 ++++++++++++++++++++++
6 files changed, 94 insertions(+), 52 deletions(-)
^ permalink raw reply
* [PATCH] powerpc/pseries: Reduce HVCS driver insanity
From: Benjamin Herrenschmidt @ 2011-02-07 4:26 UTC (permalink / raw)
To: linuxppc-dev
The HVCS driver, for those who don't know, is a driver for the "server" side
of the IBM virtual terminal mechanism allowing Linux partitions to act as
terminal servers under IBM PowerVM hypervisor. It's almost never used on
the field at the moment.
However, it's part of our configs, and in its current incarnation, will
allocate the tty driver & major (with 64 minors) and create a kernel thread
whether it's used or not, ie, whether the hypervisor did put a virtual
terminal server device node in the partition or not (or whether running on
a pseries machine or not even).
This in turns causes modern distro's udev's to start trying to open all
those 64 minors at boot, which, since they aren't linked to anything,
causes the driver to spew errors in the kernel log for each of them.
Not nice.
This moves all that initialization to a function which is now only called
the first time a terminal server virtual IO device is actually probed
(that is almost never).
There's still a _LOT_ of cleanup that can be done in this driver, some
simple (almost all printk's statements in there shall either just be
removed or in some case turned into better written & more informative
messages, including using the dev_* variants etc...). This is left as
an exercise for whoever actually cares about that driver.
One could also try to be smart and dispose of all the tty related
resources when the last instance of the VIO server device
is removed (Hotplug anybody ?).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index bedc6c1..7e315b7 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -309,6 +309,7 @@ struct hvcs_struct {
static LIST_HEAD(hvcs_structs);
static DEFINE_SPINLOCK(hvcs_structs_lock);
+static DEFINE_MUTEX(hvcs_init_mutex);
static void hvcs_unthrottle(struct tty_struct *tty);
static void hvcs_throttle(struct tty_struct *tty);
@@ -340,6 +341,7 @@ static int __devinit hvcs_probe(struct vio_dev *dev,
static int __devexit hvcs_remove(struct vio_dev *dev);
static int __init hvcs_module_init(void);
static void __exit hvcs_module_exit(void);
+static int __devinit hvcs_initialize(void);
#define HVCS_SCHED_READ 0x00000001
#define HVCS_QUICK_READ 0x00000002
@@ -762,7 +764,7 @@ static int __devinit hvcs_probe(
const struct vio_device_id *id)
{
struct hvcs_struct *hvcsd;
- int index;
+ int index, rc;
int retval;
if (!dev || !id) {
@@ -770,6 +772,13 @@ static int __devinit hvcs_probe(
return -EPERM;
}
+ /* Make sure we are properly initialized */
+ rc = hvcs_initialize();
+ if (rc) {
+ pr_err("HVCS: Failed to initialize core driver.\n");
+ return rc;
+ }
+
/* early to avoid cleanup on failure */
index = hvcs_get_index();
if (index < 0) {
@@ -1464,12 +1473,15 @@ static void hvcs_free_index_list(void)
hvcs_index_count = 0;
}
-static int __init hvcs_module_init(void)
+static int __devinit hvcs_initialize(void)
{
- int rc;
- int num_ttys_to_alloc;
+ int rc, num_ttys_to_alloc;
- printk(KERN_INFO "Initializing %s\n", hvcs_driver_string);
+ mutex_lock(&hvcs_init_mutex);
+ if (hvcs_task) {
+ mutex_unlock(&hvcs_init_mutex);
+ return 0;
+ }
/* Has the user specified an overload with an insmod param? */
if (hvcs_parm_num_devs <= 0 ||
@@ -1528,35 +1540,13 @@ static int __init hvcs_module_init(void)
hvcs_task = kthread_run(khvcsd, NULL, "khvcsd");
if (IS_ERR(hvcs_task)) {
- printk(KERN_ERR "HVCS: khvcsd creation failed. Driver not loaded.\n");
+ printk(KERN_ERR "HVCS: khvcsd creation failed.\n");
rc = -EIO;
goto kthread_fail;
}
-
- rc = vio_register_driver(&hvcs_vio_driver);
- if (rc) {
- printk(KERN_ERR "HVCS: can't register vio driver\n");
- goto vio_fail;
- }
-
- /*
- * This needs to be done AFTER the vio_register_driver() call or else
- * the kobjects won't be initialized properly.
- */
- rc = driver_create_file(&(hvcs_vio_driver.driver), &driver_attr_rescan);
- if (rc) {
- printk(KERN_ERR "HVCS: sysfs attr create failed\n");
- goto attr_fail;
- }
-
- printk(KERN_INFO "HVCS: driver module inserted.\n");
-
+ mutex_unlock(&hvcs_init_mutex);
return 0;
-attr_fail:
- vio_unregister_driver(&hvcs_vio_driver);
-vio_fail:
- kthread_stop(hvcs_task);
kthread_fail:
kfree(hvcs_pi_buff);
buff_alloc_fail:
@@ -1566,15 +1556,39 @@ register_fail:
index_fail:
put_tty_driver(hvcs_tty_driver);
hvcs_tty_driver = NULL;
+ mutex_unlock(&hvcs_init_mutex);
return rc;
}
+static int __init hvcs_module_init(void)
+{
+ int rc = vio_register_driver(&hvcs_vio_driver);
+ if (rc) {
+ printk(KERN_ERR "HVCS: can't register vio driver\n");
+ return rc;
+ }
+
+ pr_info("HVCS: Driver registered.\n");
+
+ /* This needs to be done AFTER the vio_register_driver() call or else
+ * the kobjects won't be initialized properly.
+ */
+ rc = driver_create_file(&(hvcs_vio_driver.driver), &driver_attr_rescan);
+ if (rc)
+ pr_warning(KERN_ERR "HVCS: Failed to create rescan file (err %d)\n", rc);
+
+ return 0;
+}
+
static void __exit hvcs_module_exit(void)
{
/*
* This driver receives hvcs_remove callbacks for each device upon
* module removal.
*/
+ vio_unregister_driver(&hvcs_vio_driver);
+ if (!hvcs_task)
+ return;
/*
* This synchronous operation will wake the khvcsd kthread if it is
@@ -1589,8 +1603,6 @@ static void __exit hvcs_module_exit(void)
driver_remove_file(&hvcs_vio_driver.driver, &driver_attr_rescan);
- vio_unregister_driver(&hvcs_vio_driver);
-
tty_unregister_driver(hvcs_tty_driver);
hvcs_free_index_list();
^ permalink raw reply related
* Re: [PATCH 5/6] nvram: Slim down zlib_deflate workspace when possible
From: Benjamin Herrenschmidt @ 2011-02-07 4:39 UTC (permalink / raw)
To: Jim Keniston; +Cc: linuxppc-dev
In-Reply-To: <20101114041539.9457.11974.stgit@localhost.localdomain>
On Sat, 2010-11-13 at 20:15 -0800, Jim Keniston wrote:
> Instead of always creating a huge (268K) deflate_workspace with the
> maximum compression parameters (windowBits=15, memLevel=8), allow the
> caller to obtain a smaller workspace (24K in our case) by specifying
> smaller parameter values -- via zlib_deflate_workspacesize2(). In our
> case, a small workspace is a win because our choices are to allocate
> the workspace when we need it (i.e., during an oops or panic) or
> allocate it at boot time. (We do the latter.)
>
> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com>
> ---
Can you submit that to lkml please ? CC Linus and Andrew (or send to
Andrew/Linus and CC lkml). This change shouldn't go via the powerpc tree
since it changes the generic zlib code.
I'm dropping 5/6 and 6/6 for now... still reviewing the rest.
Cheers,
Ben.
> include/linux/zlib.h | 14 ++++++++++++--
> lib/zlib_deflate/deflate.c | 33 ++++++++++++++++++++++++++++++++-
> lib/zlib_deflate/deflate_syms.c | 1 +
> lib/zlib_deflate/defutil.h | 17 +++++++++++++----
> 4 files changed, 58 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/zlib.h b/include/linux/zlib.h
> index 40c49cb..3f15036 100644
> --- a/include/linux/zlib.h
> +++ b/include/linux/zlib.h
> @@ -179,11 +179,21 @@ typedef z_stream *z_streamp;
>
> /* basic functions */
>
> +extern int zlib_deflate_workspacesize2 (int windowBits, int memLevel);
> +/*
> + Returns the number of bytes that needs to be allocated for a per-
> + stream workspace with the specified parameters. A pointer to this
> + number of bytes should be returned in stream->workspace before
> + calling zlib_deflateInit2(); and the windowBits and memLevel
> + parameters passed to zlib_deflateInit2() must not exceed those
> + passed here.
> +*/
> +
> extern int zlib_deflate_workspacesize (void);
> /*
> Returns the number of bytes that needs to be allocated for a per-
> - stream workspace. A pointer to this number of bytes should be
> - returned in stream->workspace before calling zlib_deflateInit().
> + stream workspace with the default (large) windowBits and memLevel
> + parameters.
> */
>
> /*
> diff --git a/lib/zlib_deflate/deflate.c b/lib/zlib_deflate/deflate.c
> index 46a31e5..cdb207a 100644
> --- a/lib/zlib_deflate/deflate.c
> +++ b/lib/zlib_deflate/deflate.c
> @@ -176,6 +176,7 @@ int zlib_deflateInit2(
> deflate_state *s;
> int noheader = 0;
> deflate_workspace *mem;
> + char *next;
>
> ush *overlay;
> /* We overlay pending_buf and d_buf+l_buf. This works since the average
> @@ -199,6 +200,21 @@ int zlib_deflateInit2(
> strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
> return Z_STREAM_ERROR;
> }
> +
> + /*
> + * Direct the workspace's pointers to the chunks that were allocated
> + * along with the deflate_workspace struct.
> + */
> + next = (char *) mem;
> + next += sizeof(*mem);
> + mem->window_memory = (Byte *) next;
> + next += zlib_deflate_window_memsize(windowBits);
> + mem->prev_memory = (Pos *) next;
> + next += zlib_deflate_prev_memsize(windowBits);
> + mem->head_memory = (Pos *) next;
> + next += zlib_deflate_head_memsize(memLevel);
> + mem->overlay_memory = next;
> +
> s = (deflate_state *) &(mem->deflate_memory);
> strm->state = (struct internal_state *)s;
> s->strm = strm;
> @@ -1249,5 +1265,20 @@ static block_state deflate_slow(
>
> int zlib_deflate_workspacesize(void)
> {
> - return sizeof(deflate_workspace);
> + return zlib_deflate_workspacesize2(MAX_WBITS, MAX_MEM_LEVEL);
> +}
> +
> +int zlib_deflate_workspacesize2(int windowBits, int memLevel)
> +{
> + if (windowBits < 0) /* undocumented feature: suppress zlib header */
> + windowBits = -windowBits;
> + if (memLevel < 1 || memLevel > MAX_MEM_LEVEL ||
> + windowBits < 9 || windowBits > 15)
> + return -1;
> +
> + return sizeof(deflate_workspace)
> + + zlib_deflate_window_memsize(windowBits)
> + + zlib_deflate_prev_memsize(windowBits)
> + + zlib_deflate_head_memsize(memLevel)
> + + zlib_deflate_overlay_memsize(memLevel);
> }
> diff --git a/lib/zlib_deflate/deflate_syms.c b/lib/zlib_deflate/deflate_syms.c
> index ccfe25f..cdf1cdd 100644
> --- a/lib/zlib_deflate/deflate_syms.c
> +++ b/lib/zlib_deflate/deflate_syms.c
> @@ -11,6 +11,7 @@
> #include <linux/zlib.h>
>
> EXPORT_SYMBOL(zlib_deflate_workspacesize);
> +EXPORT_SYMBOL(zlib_deflate_workspacesize2);
> EXPORT_SYMBOL(zlib_deflate);
> EXPORT_SYMBOL(zlib_deflateInit2);
> EXPORT_SYMBOL(zlib_deflateEnd);
> diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib_deflate/defutil.h
> index 6b15a90..b640b64 100644
> --- a/lib/zlib_deflate/defutil.h
> +++ b/lib/zlib_deflate/defutil.h
> @@ -241,12 +241,21 @@ typedef struct deflate_state {
> typedef struct deflate_workspace {
> /* State memory for the deflator */
> deflate_state deflate_memory;
> - Byte window_memory[2 * (1 << MAX_WBITS)];
> - Pos prev_memory[1 << MAX_WBITS];
> - Pos head_memory[1 << (MAX_MEM_LEVEL + 7)];
> - char overlay_memory[(1 << (MAX_MEM_LEVEL + 6)) * (sizeof(ush)+2)];
> + Byte *window_memory;
> + Pos *prev_memory;
> + Pos *head_memory;
> + char *overlay_memory;
> } deflate_workspace;
>
> +#define zlib_deflate_window_memsize(windowBits) \
> + (2 * (1 << (windowBits)) * sizeof(Byte))
> +#define zlib_deflate_prev_memsize(windowBits) \
> + ((1 << (windowBits)) * sizeof(Pos))
> +#define zlib_deflate_head_memsize(memLevel) \
> + ((1 << ((memLevel)+7)) * sizeof(Pos))
> +#define zlib_deflate_overlay_memsize(memLevel) \
> + ((1 << ((memLevel)+6)) * (sizeof(ush)+2))
> +
> /* Output a byte on the stream.
> * IN assertion: there is enough room in pending_buf.
> */
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: Fix call to flush_ptrace_hw_breakpoint()
From: K.Prasad @ 2011-02-07 4:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Kleikamp
In-Reply-To: <1297048239.14982.29.camel@pasglop>
On Mon, Feb 07, 2011 at 02:10:39PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2011-02-07 at 08:26 +0530, K.Prasad wrote:
> > On Mon, Feb 07, 2011 at 09:54:13AM +1100, Benjamin Herrenschmidt wrote:
> > > A typo in the #ifdef statement makes us never call it
> > > in flush_thread()
> > >
> >
> > I wish it never compiled for such typos :-)
> >
> >
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
>
> Interestingly, that 'fix' now breaks the build:
>
> cc1: warnings being treated as errors
> /home/benh/linux-powerpc-test/arch/powerpc/kernel/process.c:356: error:
> 'set_debug_reg_defaults' defined but not used
>
> This file is is becoming an absolute mess of ifdef's in large part due
> to the new BookE debug stuff and your HW breakpoint stuff... Any chance
> you and Shaggy see if you can improve that situation a bit ?
>
> Cheers,
> Ben.
>
>
Okay! Another wrapper of "#ifndef CONFIG_HAVE_HW_BREAKPOINT" around the
definition of 'set_debug_reg_defaults'.
There's indeed too much sprinkling of #ifdefs in the code, but most of
it would go away when the BookE code also uses the generic hw-breakpoint
interfaces. Given the advanced debug features that BookE supports, it's
unfortunately not that straight-forward (needs additions to generic
hw-breakpoint infrastructure).
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH 1/6] nvram: Generalize code for OS partitions in NVRAM
From: Benjamin Herrenschmidt @ 2011-02-07 4:57 UTC (permalink / raw)
To: Jim Keniston; +Cc: linuxppc-dev
In-Reply-To: <20101114041516.9457.2462.stgit@localhost.localdomain>
On Sat, 2010-11-13 at 20:15 -0800, Jim Keniston wrote:
> Adapt the functions used to create and write to the RTAS-log partition
> to work with any OS-type partition.
>
> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com>
> ---
Overall pretty good (sorry for taking that long to review, I've been
swamped down). Just a handful of minor nits:
> +/*
> + * Per the criteria passed via nvram_remove_partition(), should this
> + * partition be removed? 1=remove, 0=keep
> + */
> +static int nvram_condemn_partition(struct nvram_partition *part,
> + const char *name, int sig, const char *exceptions[])
As "fun" as this name is, it didn't help me understand what the function
was about until I read the code for the next one :-)
What about instead something like nvram_can_remove_partition() or
something a bit more explicit like that ?
"comdemn" made me thought it was a function used to "mark" partitions
to be killed later, which is not what the function does.
.../...
> +static const char *valid_os_partitions[] = {
> + "ibm,rtas-log",
> + NULL
> +};
Can you pick a name that will be less confusing in the global
symbol table ? Something like "pseries_nvram_os_partitions"
or whatever shorter you can come up with which doesn't suck ?
Also, should we move that "os partition" core out of pseries ?
Looks like it will be useful for a few other platforms, I'd like
to move that to a more generically useful location in arch/powerpc
but that's not a blocker for this series but something to do next
maybe ?
In that case "struct os_partition" should also find itself a better
name, maybe struct nvram_os_partition ?
> static ssize_t pSeries_nvram_read(char *buf, size_t count, loff_t *index)
> {
> @@ -134,7 +147,7 @@ static ssize_t pSeries_nvram_get_size(void)
> }
>
>
> -/* nvram_write_error_log
> +/* nvram_write_os_partition, nvram_write_error_log
> *
> * We need to buffer the error logs into nvram to ensure that we have
> * the failure information to decode. If we have a severe error there
> @@ -156,48 +169,55 @@ static ssize_t pSeries_nvram_get_size(void)
> * The 'data' section would look like (in bytes):
> * +--------------+------------+-----------------------------------+
> * | event_logged | sequence # | error log |
> - * |0 3|4 7|8 nvram_error_log_size-1|
> + * |0 3|4 7|8 error_log_size-1|
> * +--------------+------------+-----------------------------------+
> *
> * event_logged: 0 if event has not been logged to syslog, 1 if it has
> * sequence #: The unique sequence # for each event. (until it wraps)
> * error log: The error log from event_scan
> */
> -int nvram_write_error_log(char * buff, int length,
> +int nvram_write_os_partition(struct os_partition *part, char * buff, int length,
> unsigned int err_type, unsigned int error_log_cnt)
> {
> int rc;
> loff_t tmp_index;
> struct err_log_info info;
>
> - if (nvram_error_log_index == -1) {
> + if (part->index == -1) {
> return -ESPIPE;
> }
>
> - if (length > nvram_error_log_size) {
> - length = nvram_error_log_size;
> + if (length > part->size) {
> + length = part->size;
> }
>
> info.error_type = err_type;
> info.seq_num = error_log_cnt;
>
> - tmp_index = nvram_error_log_index;
> + tmp_index = part->index;
>
> rc = ppc_md.nvram_write((char *)&info, sizeof(struct err_log_info), &tmp_index);
> if (rc <= 0) {
> - printk(KERN_ERR "nvram_write_error_log: Failed nvram_write (%d)\n", rc);
> + printk(KERN_ERR "nvram_write_os_partition: Failed nvram_write (%d)\n", rc);
> return rc;
> }
>
> rc = ppc_md.nvram_write(buff, length, &tmp_index);
> if (rc <= 0) {
> - printk(KERN_ERR "nvram_write_error_log: Failed nvram_write (%d)\n", rc);
> + printk(KERN_ERR "nvram_write_os_partition: Failed nvram_write (%d)\n", rc);
> return rc;
> }
>
> return 0;
> }
While at it, turn these into pr_err and use __FUNCTION__ or __func__
> +int nvram_write_error_log(char * buff, int length,
> + unsigned int err_type, unsigned int error_log_cnt)
> +{
> + return nvram_write_os_partition(&rtas_log_partition, buff, length,
> + err_type, error_log_cnt);
> +}
That's a candidate for a static inline in a .h
> /* nvram_read_error_log
> *
> * Reads nvram for error log for at most 'length'
> @@ -209,13 +229,13 @@ int nvram_read_error_log(char * buff, int length,
> loff_t tmp_index;
> struct err_log_info info;
>
> - if (nvram_error_log_index == -1)
> + if (rtas_log_partition.index == -1)
> return -1;
>
> - if (length > nvram_error_log_size)
> - length = nvram_error_log_size;
> + if (length > rtas_log_partition.size)
> + length = rtas_log_partition.size;
>
> - tmp_index = nvram_error_log_index;
> + tmp_index = rtas_log_partition.index;
>
> rc = ppc_md.nvram_read((char *)&info, sizeof(struct err_log_info), &tmp_index);
> if (rc <= 0) {
> @@ -244,10 +264,10 @@ int nvram_clear_error_log(void)
> int clear_word = ERR_FLAG_ALREADY_LOGGED;
> int rc;
>
> - if (nvram_error_log_index == -1)
> + if (rtas_log_partition.index == -1)
> return -1;
>
> - tmp_index = nvram_error_log_index;
> + tmp_index = rtas_log_partition.index;
>
> rc = ppc_md.nvram_write((char *)&clear_word, sizeof(int), &tmp_index);
> if (rc <= 0) {
> @@ -258,67 +278,71 @@ int nvram_clear_error_log(void)
> return 0;
> }
>
> -/* pseries_nvram_init_log_partition
> +/* pseries_nvram_init_os_partition
> *
> - * This will setup the partition we need for buffering the
> - * error logs and cleanup partitions if needed.
> + * This set up a partition with an "OS" signature.
> *
> * The general strategy is the following:
> - * 1.) If there is log partition large enough then use it.
> - * 2.) If there is none large enough, search
> - * for a free partition that is large enough.
> - * 3.) If there is not a free partition large enough remove
> - * _all_ OS partitions and consolidate the space.
> - * 4.) Will first try getting a chunk that will satisfy the maximum
> - * error log size (NVRAM_MAX_REQ).
> - * 5.) If the max chunk cannot be allocated then try finding a chunk
> - * that will satisfy the minum needed (NVRAM_MIN_REQ).
> + * 1.) If a partition with the indicated name already exists...
> + * - If it's large enough, use it.
> + * - Otherwise, recycle it and keep going.
> + * 2.) Search for a free partition that is large enough.
> + * 3.) If there's not a free partition large enough, recycle any obsolete
> + * OS partitions and try again.
> + * 4.) Will first try getting a chunk that will satisfy the requested size.
> + * 5.) If a chunk of the requested size cannot be allocated, then try finding
> + * a chunk that will satisfy the minum needed.
> + *
> + * Returns 0 on success, else -1.
> */
> -static int __init pseries_nvram_init_log_partition(void)
> +static int __init pseries_nvram_init_os_partition(struct os_partition *part)
> {
> loff_t p;
> int size;
>
> - p = nvram_find_partition(NVRAM_LOG_PART_NAME, NVRAM_SIG_OS, &size);
> + p = nvram_find_partition(part->name, NVRAM_SIG_OS, &size);
>
> /* Found one but too small, remove it */
> - if (p && size < NVRAM_MIN_REQ) {
> - pr_info("nvram: Found too small "NVRAM_LOG_PART_NAME" partition"
> - ",removing it...");
> - nvram_remove_partition(NVRAM_LOG_PART_NAME, NVRAM_SIG_OS);
> + if (p && size < part->min_size) {
> + pr_info("nvram: Found too small %s partition,"
> + " removing it...\n", part->name);
> + nvram_remove_partition(part->name, NVRAM_SIG_OS, NULL);
> p = 0;
> }
>
> /* Create one if we didn't find */
> if (!p) {
> - p = nvram_create_partition(NVRAM_LOG_PART_NAME, NVRAM_SIG_OS,
> - NVRAM_MAX_REQ, NVRAM_MIN_REQ);
> - /* No room for it, try to get rid of any OS partition
> - * and try again
> - */
> + p = nvram_create_partition(part->name, NVRAM_SIG_OS,
> + part->req_size, part->min_size);
> if (p == -ENOSPC) {
> - pr_info("nvram: No room to create "NVRAM_LOG_PART_NAME
> - " partition, deleting all OS partitions...");
> - nvram_remove_partition(NULL, NVRAM_SIG_OS);
> - p = nvram_create_partition(NVRAM_LOG_PART_NAME,
> - NVRAM_SIG_OS, NVRAM_MAX_REQ,
> - NVRAM_MIN_REQ);
> + pr_info("nvram: No room to create %s partition, "
> + "deleting any obsolete OS partitions...\n",
> + part->name);
> + nvram_remove_partition(NULL, NVRAM_SIG_OS,
> + valid_os_partitions);
> + p = nvram_create_partition(part->name, NVRAM_SIG_OS,
> + part->req_size, part->min_size);
> }
> }
>
> if (p <= 0) {
> - pr_err("nvram: Failed to find or create "NVRAM_LOG_PART_NAME
> - " partition, err %d\n", (int)p);
> - return 0;
> + pr_err("nvram: Failed to find or create %s"
> + " partition, err %d\n", part->name, (int)p);
> + return -1;
> }
>
> - nvram_error_log_index = p;
> - nvram_error_log_size = nvram_get_partition_size(p) -
> - sizeof(struct err_log_info);
> + part->index = p;
> + part->size = nvram_get_partition_size(p) - sizeof(struct err_log_info);
>
> return 0;
> }
> -machine_late_initcall(pseries, pseries_nvram_init_log_partition);
> +
> +static int __init pseries_nvram_init_log_partitions(void)
> +{
> + (void) pseries_nvram_init_os_partition(&rtas_log_partition);
> + return 0;
> +}
> +machine_late_initcall(pseries, pseries_nvram_init_log_partitions);
>
> int __init pSeries_nvram_init(void)
> {
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2/6] nvram: Capture oops/panic reports in ibm, oops-log partition
From: Benjamin Herrenschmidt @ 2011-02-07 5:01 UTC (permalink / raw)
To: Jim Keniston; +Cc: linuxppc-dev
In-Reply-To: <20101114041521.9457.69485.stgit@localhost.localdomain>
On Sat, 2010-11-13 at 20:15 -0800, Jim Keniston wrote:
> Create the ibm,oops-log NVRAM partition, and capture the end of the printk
> buffer in it when there's an oops or panic. If we can't create the
> ibm,oops-log partition, capture the oops/panic report in ibm,rtas-log.
Won't the parsing tools choke on the oops log in the RTAS log
partition ?
Also, maybe remove the "ibm," prefix on the nvram partition, make it
"lnx," instead.
Then, if you move the rest of the code out of pseries, you can move that
out too, just make pseries platform code call the init code for it, that
way other platforms can re-use that as-is.
But that later part can wait a separate patch series, just make sure you
change the partition name now.
Cheers,
Ben.
> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com>
> ---
>
> arch/powerpc/platforms/pseries/nvram.c | 89 ++++++++++++++++++++++++++++++++
> 1 files changed, 88 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
> index 43d5c52..6c88cda 100644
> --- a/arch/powerpc/platforms/pseries/nvram.c
> +++ b/arch/powerpc/platforms/pseries/nvram.c
> @@ -16,6 +16,8 @@
> #include <linux/errno.h>
> #include <linux/init.h>
> #include <linux/spinlock.h>
> +#include <linux/slab.h>
> +#include <linux/kmsg_dump.h>
> #include <asm/uaccess.h>
> #include <asm/nvram.h>
> #include <asm/rtas.h>
> @@ -50,11 +52,32 @@ static struct os_partition rtas_log_partition = {
> .index = -1
> };
>
> +static struct os_partition oops_log_partition = {
> + .name = "ibm,oops-log",
> + .req_size = 4000,
> + .min_size = 2000,
> + .index = -1
> +};
> +
> static const char *valid_os_partitions[] = {
> "ibm,rtas-log",
> + "ibm,oops-log",
> NULL
> };
>
> +static void oops_to_nvram(struct kmsg_dumper *dumper,
> + enum kmsg_dump_reason reason,
> + const char *old_msgs, unsigned long old_len,
> + const char *new_msgs, unsigned long new_len);
> +
> +static struct kmsg_dumper nvram_kmsg_dumper = {
> + .dump = oops_to_nvram
> +};
> +
> +/* We preallocate oops_buf during init to avoid kmalloc during oops/panic. */
> +static size_t oops_buf_sz;
> +static char *oops_buf;
> +
> static ssize_t pSeries_nvram_read(char *buf, size_t count, loff_t *index)
> {
> unsigned int i;
> @@ -337,9 +360,36 @@ static int __init pseries_nvram_init_os_partition(struct os_partition *part)
> return 0;
> }
>
> +static void __init nvram_init_oops_partition(int rtas_partition_exists)
> +{
> + int rc;
> +
> + rc = pseries_nvram_init_os_partition(&oops_log_partition);
> + if (rc != 0) {
> + if (!rtas_partition_exists)
> + return;
> + pr_notice("nvram: Using %s partition to log both"
> + " RTAS errors and oops/panic reports\n",
> + rtas_log_partition.name);
> + memcpy(&oops_log_partition, &rtas_log_partition,
> + sizeof(rtas_log_partition));
> + }
> + oops_buf_sz = oops_log_partition.size - sizeof(struct err_log_info);
> + oops_buf = kmalloc(oops_buf_sz, GFP_KERNEL);
> + rc = kmsg_dump_register(&nvram_kmsg_dumper);
> + if (rc != 0) {
> + pr_err("nvram: kmsg_dump_register() failed; returned %d\n", rc);
> + kfree(oops_buf);
> + return;
> + }
> +}
> +
> static int __init pseries_nvram_init_log_partitions(void)
> {
> - (void) pseries_nvram_init_os_partition(&rtas_log_partition);
> + int rc;
> +
> + rc = pseries_nvram_init_os_partition(&rtas_log_partition);
> + nvram_init_oops_partition(rc == 0);
> return 0;
> }
> machine_late_initcall(pseries, pseries_nvram_init_log_partitions);
> @@ -373,3 +423,40 @@ int __init pSeries_nvram_init(void)
>
> return 0;
> }
> +
> +/*
> + * Try to capture the last capture_len bytes of the printk buffer. Return
> + * the amount actually captured.
> + */
> +static size_t capture_last_msgs(const char *old_msgs, size_t old_len,
> + const char *new_msgs, size_t new_len,
> + char *captured, size_t capture_len)
> +{
> + if (new_len >= capture_len) {
> + memcpy(captured, new_msgs + (new_len - capture_len),
> + capture_len);
> + return capture_len;
> + } else {
> + /* Grab the end of old_msgs. */
> + size_t old_tail_len = min(old_len, capture_len - new_len);
> + memcpy(captured, old_msgs + (old_len - old_tail_len),
> + old_tail_len);
> + memcpy(captured + old_tail_len, new_msgs, new_len);
> + return old_tail_len + new_len;
> + }
> +}
> +
> +/* our kmsg_dump callback */
> +static void oops_to_nvram(struct kmsg_dumper *dumper,
> + enum kmsg_dump_reason reason,
> + const char *old_msgs, unsigned long old_len,
> + const char *new_msgs, unsigned long new_len)
> +{
> + static unsigned int oops_count = 0;
> + size_t text_len;
> +
> + text_len = capture_last_msgs(old_msgs, old_len, new_msgs, new_len,
> + oops_buf, oops_buf_sz);
> + (void) nvram_write_os_partition(&oops_log_partition, oops_buf,
> + (int) text_len, ERR_TYPE_KERNEL_PANIC, ++oops_count);
> +}
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc: Add IO event interrupt support
From: Benjamin Herrenschmidt @ 2011-02-07 5:10 UTC (permalink / raw)
To: Tseng-Hui (Frank) Lin; +Cc: tsenglin, linuxppc-dev
In-Reply-To: <1294267483.24377.30.camel@flin.austin.ibm.com>
On Wed, 2011-01-05 at 16:44 -0600, Tseng-Hui (Frank) Lin wrote:
> This patch adds support for handling IO Event interrupts which come
> through at the /event-sources/ibm,io-events device tree node.
.../...
The previous patches regarding the error log sometimes call it error log
and sometimes event log. Can you consolidate that ?
> +int pseries_ioei_register_handler(pseries_ioei_handler_t handler)
> +{
Shouldn't we have a void * to attach with each client so it can put
its private data there and get them back in the handler ?
We are -really- re-inventing interrupts and/or notifiers here, which
I find a tad annoying..
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix call to flush_ptrace_hw_breakpoint()
From: Benjamin Herrenschmidt @ 2011-02-07 5:13 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, David Kleikamp
In-Reply-To: <20110207045230.GB4287@in.ibm.com>
On Mon, 2011-02-07 at 10:22 +0530, K.Prasad wrote:
> Okay! Another wrapper of "#ifndef CONFIG_HAVE_HW_BREAKPOINT" around
> the
> definition of 'set_debug_reg_defaults'.
Can you send a patch ?
> There's indeed too much sprinkling of #ifdefs in the code, but most of
> it would go away when the BookE code also uses the generic
> hw-breakpoint interfaces.
What's your status for those patches ?
> Given the advanced debug features that BookE supports, it's
> unfortunately not that straight-forward (needs additions to generic
> hw-breakpoint infrastructure).
Might want to move a lot of that code to a separate set of files maybe
and just call a single hook from the various process.c locations ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH V2 1/6] powerpc: Move udbg_early_init() after early_init_devtree()
From: David Gibson @ 2011-02-07 8:29 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296691225.12290.112.camel@shaggy-w500>
On Wed, Feb 02, 2011 at 06:00:25PM -0600, Dave Kleikamp wrote:
> On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
> > On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> > > so that it can use information from the device tree.
> >
> > Hrm. On the other hand this means that the early_init_devtree() code
> > can't benefit from hardcoded early debugging. Since you don't
> > actually appear to use devtree information in udbg_early_init() in the
> > latest series, I'd suggest dropping this patch.
>
> Patch 2 depends on early_init_devtree() being run. Until then, I don't
> know of a way to get at the bootargs.
Ah, yes. Drat.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems
From: David Gibson @ 2011-02-07 8:30 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296774957.14077.23.camel@shaggy-w500>
On Thu, Feb 03, 2011 at 05:15:57PM -0600, Dave Kleikamp wrote:
> On Thu, 2011-02-03 at 16:03 +1100, David Gibson wrote:
> > On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
> > > On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> > > > On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > > > > Since other OS's may be running on the other cores don't use tlbivax
> > > >
> > > > [snip]
> > > > > +#ifdef CONFIG_44x
> > > > > +void __init early_init_mmu_44x(void)
> > > > > +{
> > > > > + unsigned long root = of_get_flat_dt_root();
> > > > > + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > > > > + amp = 1;
> > > > > +}
> > > > > +#endif /* CONFIG_44x */
> > > >
> > > > A test against a hardcoded compatible string seems a nasty way to do
> > > > this. Maybe we should define a new boolean property for the root
> > > > node.
> > >
> > > I'm not crazy about this string, but I needed something in the device
> > > tree to key off of. Freescale has something similar (i.e.
> > > MPC8572DS-CAMP), so I chose to follow their example. I'd be happy to
> > > replace it with a boolean property. Any objection to just using
> > > "amp"?
> >
> > Bit too short, I think. I'd suggest either spelling out
> > 'asymmetric-multiprocessor' or 'cooperative-partition' (a more
> > accurate term, IMO).
>
> I could be wrong, but I thought the A stands for Asynchronous, not
> Asymmetric. I thought Asymmetric means that different types of tasks
> run on the secondary processors, as on the Cell.
Yeah, I thought so too, but Freescale at least seem to use it this
way. 'Asynchronous' would make even less sense.
> Anyway, going with
> 'cooperative-partition' would avoid that confusion.
>
> Shaggy
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] sched: provide scheduler_ipi() callback in response to smp_send_reschedule()
From: Peter Zijlstra @ 2011-02-07 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-sh, H. Peter Anvin,
Heiko Carstens, Paul Mackerras, Helge Deller, sparclinux,
Linux-Arch, linux-s390, Jesper Nilsson, Jeremy Fitzhardinge,
Russell King, Hirokazu Takata, x86, James E.J. Bottomley,
virtualization, Ingo Molnar, Matt Turner, Fenghua Yu,
Mike Frysinger, user-mode-linux-devel, Konrad Rzeszutek Wilk,
Jeff Dike, Chris Metcalf, xen-devel, Mikael Starvik, linux-m32r,
Ivan Kokshaysky, user-mode-linux-user, uclinux-dist-devel,
Thomas Gleixner, linux-arm-kernel, Richard Henderson, Tony Luck,
linux-parisc, linux-cris-kernel, linux-am33-list, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
Martin Schwidefsky, linux390, Koichi Yasutake, linuxppc-dev,
David S. Miller
In-Reply-To: <1297034792.14982.10.camel@pasglop>
On Mon, 2011-02-07 at 10:26 +1100, Benjamin Herrenschmidt wrote:
> You missed:
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 9813605..467d122 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -98,6 +98,7 @@ void smp_message_recv(int msg)
> break;
> case PPC_MSG_RESCHEDULE:
> /* we notice need_resched on exit */
> + scheduler_ipi();
> break;
> case PPC_MSG_CALL_FUNC_SINGLE:
> generic_smp_call_function_single_interrupt();
>
> Fold that in and add:
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Thanks Ben!
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 14:13 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev, Andrew Morton
In-Reply-To: <1297081335-13631-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
Hi Mark,
On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 2657299..99e3c52 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -1,23 +1,6 @@
> config PM
> - bool "Power Management support"
> - depends on !IA64_HP_SIM
> - ---help---
> - "Power Management" means that parts of your computer are shut
> - off or put into a power conserving "sleep" mode if they are not
> - being used. There are two competing standards for doing this: APM
> - and ACPI. If you want to use either one, say Y here and then also
> - to the requisite support below.
> -
> - Power Management is most important for battery powered laptop
> - computers; if you have a laptop, check out the Linux Laptop home
> - page on the WWW at <http://www.linux-on-laptops.com/> or
> - Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/>
> - and the Battery Powered Linux mini-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - Note that, even if you say N here, Linux on the x86 architecture
> - will issue the hlt instruction if nothing is to be done, thereby
> - sending the processor to sleep and saving power.
> + bool
> + default y if !IA64_HP_SIM
Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
server configs), so this will unexpectedly turn it on for them.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 14:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev, Andrew Morton
In-Reply-To: <20110208011324.d5371c4c.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > + bool
> > + default y if !IA64_HP_SIM
> Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
> server configs), so this will unexpectedly turn it on for them.
Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on? If the latter would you expect any
ill effects from doing so?
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 14:44 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev, Andrew Morton
In-Reply-To: <20110207141829.GK10564@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Hi Mark,
On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:
> > On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> > > + bool
> > > + default y if !IA64_HP_SIM
>
> > Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
> > server configs), so this will unexpectedly turn it on for them.
>
> Do you mean that these systems require CONFIG_PM be turned off, or just
> that people tend not to turn it on? If the latter would you expect any
> ill effects from doing so?
I don't know the answer to either question without testing. All I am
saying is that currently the default for CONFIG_PM is "off" and you are
changing it to be "on" and there may not have been any testing done of
that in some situations. We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 14:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev, Andrew Morton
In-Reply-To: <20110208014432.2c9288e4.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > Do you mean that these systems require CONFIG_PM be turned off, or just
> > that people tend not to turn it on? If the latter would you expect any
> > ill effects from doing so?
> I don't know the answer to either question without testing. All I am
> saying is that currently the default for CONFIG_PM is "off" and you are
> changing it to be "on" and there may not have been any testing done of
> that in some situations. We don't know where it was explicitly
> turned off any more since we shrank our defconfig files (which was done
> automatically) ... since it is off by default, it doesn't need to be
> mentioned in a defconfig unless it needs to be turned on.
My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Geert Uytterhoeven @ 2011-02-07 15:00 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Rothwell, linux-embedded, Len Brown, Dmitry Torokhov,
linux-kernel, Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev,
Andrew Morton
In-Reply-To: <20110207145031.GL10564@opensource.wolfsonmicro.com>
On Mon, Feb 7, 2011 at 15:50, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
>> On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfson=
micro.com> wrote:
>
>> > Do you mean that these systems require CONFIG_PM be turned off, or jus=
t
>> > that people tend not to turn it on? =C2=A0If the latter would you expe=
ct any
>> > ill effects from doing so?
>
>> I don't know the answer to either question without testing. =C2=A0All I =
am
>> saying is that currently the default for CONFIG_PM is "off" and you are
>> changing it to be "on" and there may not have been any testing done of
>> that in some situations. =C2=A0 We don't know where it was explicitly
>> turned off any more since we shrank our defconfig files (which was done
>> automatically) ... since it is off by default, it doesn't need to be
>> mentioned in a defconfig unless it needs to be turned on.
>
> My suspicion would be that it'll have been turned off by someone hitting
> return through a config upgrade rather than through deliberate effort.
> On the other hand if it is essential for some machines to have it
> disabled they probably want to have somethnig in Kconfig.
$ git grep "CONFIG_PM is not set"
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$
7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 15:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Len Brown, Dmitry Torokhov, linux-embedded, Mark Brown,
linux-kernel, Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev,
Andrew Morton
In-Reply-To: <AANLkTikw7j5Q7CGZK=Xbcgubt9LYBGiXf01wQ4nbg8NR@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Hi Geert,
On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> $ git grep "CONFIG_PM is not set"
> 7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
> 256
> $
>
> 7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
> savedefconfig, so that's a safe revision with untrimmed defconfigs.
Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
defconfigs, or just off because noone explicitly turned it on.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 15:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Len Brown, Dmitry Torokhov, linux-embedded, Mark Brown,
linux-kernel, Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev,
Andrew Morton
In-Reply-To: <20110208021045.699654ca.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Tue, 8 Feb 2011 02:10:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > $ git grep "CONFIG_PM is not set"
> > 7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
> > 256
> > $
> >
> > 7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
> > savedefconfig, so that's a safe revision with untrimmed defconfigs.
>
> Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
> defconfigs, or just off because noone explicitly turned it on.
At least some of the powerpc defconfigs were added with CONFIG_PM
disabled. I assume that was on purpose (though it may not have been).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Geert Uytterhoeven, Alan Stern, linux-pm,
ppc-dev, Andrew Morton
In-Reply-To: <20110208021916.68b33b37.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:
> At least some of the powerpc defconfigs were added with CONFIG_PM
> disabled. I assume that was on purpose (though it may not have been).
I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.
^ permalink raw reply
* Re: minimum guaranteed alignment of dma_alloc_coherent?
From: Timur Tabi @ 2011-02-07 15:13 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9E25355F-62B4-46A3-9991-FDE89FB6B862@digitaldans.com>
Dan Malek wrote:
> So, I did a little research. It appears in the case of PowerPC,
> the GFP_DMA can change the way the allocation operates.
> Since the coherent allocator works with pages of memory,
> in the case of a system with highmem, not using GFP_DMA
> could hand you a physical page out of the highmem pool.
I think that's true only if SWIOTLB is enabled. dma_direct_alloc_coherent()
does this:
/* ignore region specifiers */
flag &= ~(__GFP_HIGHMEM);
> This behavior is modified if you specify a restricted DMA
> mask for the device. In this case, dma_alloc_coherent
> will force GFP_DMA on your behalf (on PowerPC).
Isn't it required for all callers of dma_alloc_coherent to specify a mask (via
dma_set_mask) first?
--
Timur Tabi
Linux kernel developer at Freescale
--
Timur Tabi
Linux kernel developer at Freescale
^ 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