Guenter Roeck | 30 Sep 20:00 2014
Picon

[RFC PATCH 00/16] kernel: Add support for poweroff handler call chain

Various drivers implement architecture and/or device specific means to
remove power from the system.  For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one scheme
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means remove power, some of
which may be less desirable.  For example, some mechanisms may only
power off the CPU or the CPU card, while another may power off the
entire system.  Others may really just execute a restart sequence
or drop into the ROM monitor.  Using pm_power_off can also be racy
if the function pointer is set from a driver built as module, as the
driver may be in the process of being unloaded when pm_power_off is
called.  If there are multiple poweroff handlers in the system, removing
a module with such a handler may inadvertently reset the pointer to
pm_power_off to NULL, leaving the system with no means to remove power.

Introduce a system poweroff handler call chain to solve the described
problems.  This call chain is expected to be executed from the
architecture specific machine_power_off() function.  Drivers providing
system poweroff functionality are expected to register with this call chain.
By using the priority field in the notifier block, callers can control
poweroff handler execution sequence and thus ensure that the poweroff
handler with the optimal capabilities to remove power for a given system
is called first.

The poweroff handler is introduced in multiple steps

1) Implement poweroff handler API.
   Patch 01/16.
(Continue reading)

Nicholas Krause | 24 Sep 03:49 2014
Picon

[PATCH] parisc:Remove unnecessary FIXMES in init.c

This removes the two fixmes in the file, init.c for compiler hints
for comments related to compiler hints in linux_gateway_page_addr
and map_hpux_gateway_page to change from FIXME to HINT in order
for people reading this code to understand that these are compiler
hints.

Signed-off-by: Nicholas Krause <yocto6 <at> gmail.com>
---
 arch/parisc/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 0bef864..668102e 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
 <at>  <at>  -733,7 +733,7  <at>  <at>  static void __init pagetable_init(void)
 static void __init gateway_init(void)
 {
 	unsigned long linux_gateway_page_addr;
-	/* FIXME: This is 'const' in order to trick the compiler
+	/* HINT: This is 'const' in order to trick the compiler
 	   into not treating it as DP-relative data. */
 	extern void * const linux_gateway_page;

 <at>  <at>  -761,7 +761,7  <at>  <at>  map_hpux_gateway_page(struct task_struct *tsk, struct mm_struct *mm)
 	unsigned long start_pte;
 	unsigned long address;
 	unsigned long hpux_gw_page_addr;
-	/* FIXME: This is 'const' in order to trick the compiler
+	/* HINT: This is 'const' in order to trick the compiler
(Continue reading)

Helge Deller | 23 Sep 21:43 2014
Picon
Picon

[GIT PULL] parisc fixes for v3.17

Hi Linus,

please pull a few late fixes for the parisc architecture for kernel 3.17 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.17-7

We avoid using -mfast-indirect-calls for 64bit kernel builds to prevent
building an unbootable kernel due to latest gcc changes. In the
pdc_stable/firmware-access driver we fix a few possible stack overflows
and we now call secure_computing_strict() instead of secure_computing()
which fixes upcoming SECCOMP patches in the for-next trees.

Thanks,
Helge

----------------------------------------------------------------
Helge Deller (2):
      parisc: ptrace: use secure_computing_strict()
      parisc: pdc_stable.c: Avoid potential stack overflows

John David Anglin (1):
      parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds

Rickard Strandqvist (1):
      parisc: pdc_stable.c: Cleaning up unnecessary use of memset in conjunction with strncpy

 arch/parisc/Makefile        |  7 ++++++-
 arch/parisc/kernel/ptrace.c |  6 ++----
 drivers/parisc/pdc_stable.c | 15 +++++++++------
 3 files changed, 17 insertions(+), 11 deletions(-)
--
(Continue reading)

小孔 | 23 Sep 16:32 2014

用这个平台发短信,这就对了 x5fw3uum


  国内最好用的短信平台,选这个这就对了。正规内容都可以发,到达高,不屏蔽。咨询请加QQ193989725,可以测试哦。




























(Continue reading)

John David Anglin | 23 Sep 02:54 2014
Picon

[PATCH] parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds

In spite of what the GCC manual says, the -mfast-indirect-calls has  
never been supported in the 64-bit
parisc compiler.  Indirect calls have always been done using function  
descriptors irrespective of the
-mfast-indirect-calls option.

Recently, it was noticed that a function descriptor was always  
requested when the -mfast-indirect-calls option
was specified.  This caused problems when the option was used in  
application code and doesn't make any
sense because the whole point of the option is to avoid using a  
function descriptor for indirect calls.

Fixing this broke 64-bit kernel builds.

I will fix GCC but for now we need the attached change.  This results  
is the same kernel code as before.

Signed-of-by: John David Anglin <dave.anglin <at> bell.net>
---

diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 7187664..5db8882 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
 <at>  <at>  -48,7 +48,12  <at>  <at>  cflags-y	:= -pipe

 # These flags should be implied by an hppa-linux configuration, but they
(Continue reading)

Helge Deller | 22 Sep 20:27 2014
Picon
Picon

[PATCH] parisc: pdc_stable.c: Avoid potential stack overflows

Signed-off-by: Helge Deller <deller <at> gmx.de>

diff --git a/drivers/parisc/pdc_stable.c b/drivers/parisc/pdc_stable.c
index e4b73c2..3651c38 100644
--- a/drivers/parisc/pdc_stable.c
+++ b/drivers/parisc/pdc_stable.c
 <at>  <at>  -278,7 +278,7  <at>  <at>  pdcspath_hwpath_write(struct pdcspath_entry *entry, const char *buf, size_t coun
 {
 	struct hardware_path hwpath;
 	unsigned short i;
-	char in[count+1], *temp;
+	char in[64], *temp;
 	struct device *dev;
 	int ret;

 <at>  <at>  -286,8 +286,9  <at>  <at>  pdcspath_hwpath_write(struct pdcspath_entry *entry, const char *buf, size_t coun
 		return -EINVAL;

 	/* We'll use a local copy of buf */
-	memset(in, 0, count+1);
+	count = min_t(size_t, count, sizeof(in)-1);
 	strncpy(in, buf, count);
+	in[count] = '\0';
 	
 	/* Let's clean up the target. 0xff is a blank pattern */
 	memset(&hwpath, 0xff, sizeof(hwpath));
 <at>  <at>  -393,14 +394,15  <at>  <at>  pdcspath_layer_write(struct pdcspath_entry *entry, const char *buf, size_t count
 {
 	unsigned int layers[6]; /* device-specific info (ctlr#, unit#, ...) */
 	unsigned short i;
(Continue reading)

Benjamin Siaka | 22 Sep 03:14 2014
Picon

HOW ARE YOU?

Hello my Dear,

I will greatly appreciate my correspondence meets you in good health condition.

My name is Mr. Benjamin Siaka. I am seeking for your co-operation for investment partnership in your
Country. I shall provide the FUND for the investment. When you acknowledged the receipt of this
correspondence, thereafter I will give you the Full Details of my investment proposal.

I await your response in earliest.

My regards,
Mr. Benjamin Siaka.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Maria Caballero | 18 Sep 16:15 2014
Picon

(unknown)


Loan Offer contact us for  more details (gibonline11 <at> gmail.com<mailto:gibonline11 <at> gmail.com>)
All Details should be forward to this E-mail address for fast respond: gibonline11 <at> gmail.com<mailto:gibonline11 <at> gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fabian Frederick | 17 Sep 21:00 2014
Picon

[PATCH 0/6] video: fbdev: use container_of where possible

Small patchset using container_of instead of casting on first structure member address.

Fabian Frederick (6):
  video: fbdev: stifb.c: use container_of to resolve stifb_info from fb_info
  video: fbdev: sa1100fb.c: use container_of to resolve sa1100fb_info from fb_info
  video: fbdev: controlfb.c: use container_of to resolve fb_info_control from fb_info
  video: fbdev: cyber2000fb.c: use container_of to resolve cfb_info from fb_info
  video: fbdev: pxafb.c: use container_of to resolve pxafb_info/layer from fb_info
  video: fbdev: valkyriefb.c: use container_of to resolve fb_info_valkyrie from fb_info

 drivers/video/fbdev/controlfb.c   | 15 ++++++++++-----
 drivers/video/fbdev/cyber2000fb.c | 16 ++++++++--------
 drivers/video/fbdev/pxafb.c       | 20 ++++++++++----------
 drivers/video/fbdev/sa1100fb.c    | 18 ++++++++++++------
 drivers/video/fbdev/stifb.c       |  4 ++--
 drivers/video/fbdev/valkyriefb.c  | 12 ++++++++----
 6 files changed, 50 insertions(+), 35 deletions(-)

--

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Chuck Ebbert | 16 Sep 09:37 2014
Picon

[PATCH] Fix end_of_stack() fn and location of stack canary for archs using STACK_GROWSUP

Aaron Tomlin recently posted patches [1] to enable checking the stack canary on
every task switch. Looking at the canary code, I realized that every arch
(except ia64, which adds some space for register spill above the stack) shares a
definition of end_of_stack() that makes it the first long after the threadinfo.

For stacks that grow down, this low address is correct because the stack starts
at the end of the thread area and grows toward lower addresses. However, for
stacks that grow up, toward higher addresses, this is wrong. (The stack actually
grows away from the canary.) On these archs end_of_stack() should return the 
address of the last long, at the highest possible address for the stack.

[1] http://lkml.org/lkml/2014/9/12/293

Signed-off-by: Chuck Ebbert <cebbert.lkml <at> gmail.com>

---

Compile tested only, with Aaron's patches applied and the new option
CONFIG_SCHED_STACK_END_CHECK they add enabled. I have no way to test
this any further.

diff a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
 <at>  <at>  -2610,7 +2610,11  <at>  <at>  static inline void setup_thread_stack(struct task_struct *p, struct task_struct

 static inline unsigned long *end_of_stack(struct task_struct *p)
 {
+#ifdef CONFIG_STACK_GROWSUP
+	return (unsigned long *)((unsigned long)task_thread_info(p) + THREAD_SIZE) - 1;
(Continue reading)

Diana | 15 Sep 18:56 2014
Picon

H

Please Revert back, your assistance is needed.
---------------------------------------
The Exhibitor at innoTrans, Berlin 2014
Hall : 15.1 / Stand no : 109 
http://www.virtualmarket.innotrans.de/?Action=showCompany&id=346242
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane