[PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(name-A.attr);
(
+ sysfs_attr_init(name-A.attr);
if (device_create_file(E, name-A))
S
|
+ sysfs_attr_init(name-A.attr);
err = device_create_file(E, name-A);
)
While reviewing, I put the initialization to apropriate places.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Greg KH gre...@suse.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sujith Thomas sujith.tho...@intel.com
Cc: Matthew Garrett m...@redhat.com
---
The thermal-sys.c-part should fix bugs #15548 and #15584.
drivers/macintosh/windfarm_core.c |1 +
drivers/media/video/pvrusb2/pvrusb2-sysfs.c |8
drivers/platform/x86/intel_menlow.c |1 +
drivers/thermal/thermal_sys.c |1 +
drivers/video/fsl-diu-fb.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/windfarm_core.c
b/drivers/macintosh/windfarm_core.c
index 419795f..f447642 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -209,6 +209,7 @@ int wf_register_control(struct wf_control *new_ct)
kref_init(new_ct-ref);
list_add(new_ct-link, wf_controls);
+ sysfs_attr_init(new_ct-attr.attr);
new_ct-attr.attr.name = new_ct-name;
new_ct-attr.attr.mode = 0644;
new_ct-attr.show = wf_show_control;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 6c23456..71f5056 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -423,10 +423,12 @@ static void pvr2_sysfs_add_debugifc(struct pvr2_sysfs
*sfp)
dip = kzalloc(sizeof(*dip),GFP_KERNEL);
if (!dip) return;
+ sysfs_attr_init(dip-attr_debugcmd.attr);
dip-attr_debugcmd.attr.name = debugcmd;
dip-attr_debugcmd.attr.mode = S_IRUGO|S_IWUSR|S_IWGRP;
dip-attr_debugcmd.show = debugcmd_show;
dip-attr_debugcmd.store = debugcmd_store;
+ sysfs_attr_init(dip-attr_debuginfo.attr);
dip-attr_debuginfo.attr.name = debuginfo;
dip-attr_debuginfo.attr.mode = S_IRUGO;
dip-attr_debuginfo.show = debuginfo_show;
@@ -644,6 +646,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
return;
}
+ sysfs_attr_init(sfp-attr_v4l_minor_number.attr);
sfp-attr_v4l_minor_number.attr.name = v4l_minor_number;
sfp-attr_v4l_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_minor_number.show = v4l_minor_number_show;
@@ -658,6 +661,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_v4l_radio_minor_number.attr);
sfp-attr_v4l_radio_minor_number.attr.name = v4l_radio_minor_number;
sfp-attr_v4l_radio_minor_number.attr.mode = S_IRUGO;
sfp-attr_v4l_radio_minor_number.show = v4l_radio_minor_number_show;
@@ -672,6 +676,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-v4l_radio_minor_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_unit_number.attr);
sfp-attr_unit_number.attr.name = unit_number;
sfp-attr_unit_number.attr.mode = S_IRUGO;
sfp-attr_unit_number.show = unit_number_show;
@@ -685,6 +690,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-unit_number_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_bus_info.attr);
sfp-attr_bus_info.attr.name = bus_info_str;
sfp-attr_bus_info.attr.mode = S_IRUGO;
sfp-attr_bus_info.show = bus_info_show;
@@ -699,6 +705,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-bus_info_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_name.attr);
sfp-attr_hdw_name.attr.name = device_hardware_type;
sfp-attr_hdw_name.attr.mode = S_IRUGO;
sfp-attr_hdw_name.show = hdw_name_show;
@@ -713,6 +720,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp-hdw_name_created_ok = !0;
}
+ sysfs_attr_init(sfp-attr_hdw_desc.attr);
sfp-attr_hdw_desc.attr.name = device_hardware_description;
sfp-attr_hdw_desc.attr.mode = S_IRUGO;
sfp-attr_hdw_desc.show = hdw_desc_show;
diff --git a/drivers/platform/x86/intel_menlow.c
b/drivers/platform/x86/intel_menlow.c
index f0a90a6..90ba5d7 100644
--- a/drivers/platform/x86/intel_menlow.c
+++
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Hi Grant,
thanks for the comments, I solved some of the points you mentioned. I need some
more time to work on the others. In the meantime I send the intermediate
version.
Grant Likely wrote:
2010/3/13 Németh Márton nm...@freemail.hu:
[...]
+ mem...@4000 {
+ device_type = memory;
+ reg = 0x4000 0x1; // 32KiB internal SRAM
+ };
Oh this is the small SRAM. yeah, you should move this under the
appropriate bridge node, remove the device_type property, and add a
compatible property. Memory nodes at the root like this are used to
describe what is basically main memory (what Linux will execute out
of). You'll want a new memory node for the external ram hooked up to
the 5554.
Yes, it is the small one (actually 64KiB, I corrected the comment also).
I added the external memory of the MPC5554DEMO evaluation board which has
a size of 512KiB.
Would it be possible to program the uncompressed kernel to the FLASH so
it can run directly from there? I guess for the code and the constant sections
the FLASH could be a good place. Then cstart has to initialize the initialized
variables by copying data from FLASH to RAM and fill the BSS area with zero.
[...]
+ s...@3f89000 { // System Integration Unit
+ compatible = fsl,mpc5554-siu;
+ reg = 0x03f9 0x4000;
+ interrupts = 45 1 // External
Interrupt Overrun 0-15
+ 46 1 // External
Interrupt 0
+ 47 1 // External
Interrupt 1
+ 48 1 // External
Interrupt 2
+ 49 1 // External
Interrupt 3
+ 50 1;// External
Interrupt 4-15
+ };
This doesn't look quite right /me goes to look at the 5554
reference manual
Okay, so all the external IRQs go through the SIU then, even though
the first 4 get passed straight through to the intc? And I see that
all the level/edge sensing and masking/acknowledging is done at the
SIU level, not the intc level, correct? So, what you effectively have
is the SIU is *another* interrupt controller that is cascaded to the
intc. Therefore you need to add the following to this node:
#interrupt-cells = 2; // cell1:extirq#, cell2:level/edge flags
interrupt-controller;
Also give the node a label so that nodes for external devices can
reference it for hooking up external irqs by overriding the top-level
interrupt-parent property.
Also, it would appear that intc interrupts don't have any level/edge
configuration associated with them. They are either asserted, or they
are not, correct? At the moment you're specifying every intc
interrupt with 2 cells, and the 2nd cell is always '1'. I think you
can change #interrupt-cells to 1 in the intc node and drop the '1'
everywhere.
When you write your intc driver, you'll also need to write the
cascaded driver for the external IRQs.
I tried to solve this point but I'm not quite sure whether the SIU interrupt
numbers shall be kept on the s...@3f89000 node or not.
+ em...@3fa { // Modular Timer System
+ compatible = fsl,mpc5554-emios;
+ reg = 0x03fa 0x4000;
+ interrupts = 51 1 // Channel 0
+ 52 1 // Channel 1
+ 53 1 // Channel 2
+ 54 1 // Channel 3
+ 55 1 // Channel 4
+ 56 1 // Channel 5
+ 57 1 // Channel 6
+ 58 1 // Channel 7
+ 59 1 // Channel 8
+ 60 1 // Channel 9
+ 61 1 // Channel 10
+ 62 1 // Channel 11
+ 63 1 // Channel 12
+ 64 1 // Channel 13
+ 65 1 // Channel 14
+ 66 1 // Channel 15
+ 202 1 // Channel 16
+ 203 1 // Channel 17
+ 204 1 // Channel 18
+ 205 1 // Channel 19
+ 206 1 //
Re: [PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
Hi Wolfram,
On Mon, Mar 22, 2010 at 07:21:17AM +0100, Wolfram Sang wrote:
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(name-A.attr);
(
+ sysfs_attr_init(name-A.attr);
if (device_create_file(E, name-A))
S
|
+ sysfs_attr_init(name-A.attr);
err = device_create_file(E, name-A);
)
While reviewing, I put the initialization to apropriate places.
My standard question - are all of these need to be dynamically
allocated?
Thanks.
--
Dmitry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ppc64 sys_ipc breakage in 2.6.34-rc2
I chased down a fail on ppc64 on 2.6.34-rc2 where an application that uses
shared memory was getting a SEGV.
Commit baed7fc9b580bd3fb8252ff1d9b36eaf1f86b670 (Add generic sys_ipc wrapper)
changed the second argument from an unsigned long to an int. When we call
shmget the system call wrappers for sys_ipc will sign extend second (ie the
size) which truncates it. It took a while to track down because the call
succeeds and strace shows the untruncated size :)
The patch below changes second from an int to an unsigned long which fixes
shmget on ppc64 (and I assume s390, sparc64 and mips64).
Signed-off-by: Anton Blanchard an...@samba.org
--
I assume the function prototypes for the other IPC methods would cause us
to sign or zero extend second where appropriate (avoiding any security
issues). Come to think of it, the syscall wrappers for each method should do
that for us as well.
diff --git a/ipc/syscall.c b/ipc/syscall.c
index 355a3da..1d6f53f 100644
--- a/ipc/syscall.c
+++ b/ipc/syscall.c
@@ -13,7 +13,7 @@
#include linux/syscalls.h
#include linux/uaccess.h
-SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, int, second,
+SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, unsigned long, second,
unsigned long, third, void __user *, ptr, long, fifth)
{
int version, ret;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
On Sun, Mar 21, 2010 at 11:40:28PM -0700, Dmitry Torokhov wrote: My standard question - are all of these need to be dynamically allocated? I have my doubts for a few of them. Still, this would be a more intrusive change than just fixing the BUG appearance, so I'd like to leave that task for those having the proper setup. Regarding thermal_sys.c, which has two bug reports already, it needs to be dynamic as the attribute name depends on the device. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
On Sun, 21 Mar 2010, Yinghai Lu wrote:
From: Ian Campbell ian.campb...@citrix.com
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
Not sure about that. These functions are solely used by x86 and there
is really no need to generalize them. The problem you try to solve is
x86/xen specific and can be solved by x86_platform_ops as well w/o
adding extra function pointers to irq_chip.
arch_init_chip_data cannot be moved into struct irq_chip because
irq_desc-chip is not known at the time the irq_desc is setup. Instead
rename arch_init_chip_data to arch_init_irq_desc for PowerPC, the
only other user, whose usage better matches the new name.
To replace the x86 arch_init_chip_data functionality
irq_to_desc_alloc_node now takes a pointer to a function to allocate
the chip data. This is necessary to ensure the allocation happens
under the correct locking at the core level. On PowerPC and SH
Err, that argument is totally bogus. The calling convention of
irq_to_desc_alloc_node and arch_init_chip_data/arch_init_irq_desc is
still the same. It does not explain why the heck we need that function
pointer at all.
AFAICT the function pointer to irq_to_desc_alloc_node is completely
pointless. It just solves a Xen/x86 specific problem which can be
solved by using x86_platform_ops and keeps the churn x86 internal.
architectures (the other users of irq_to_desc_alloc_node) pass in NULL
which retains existing chip_data behaviour.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
x86_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on an 64 bit x86 system with sparse IRQ enabled
and 32 bit without, but it's not clear to me what actions I need to
take to actually exercise some of these code paths.
-v4: yinghai add irq_to_desc_alloc_node_x...
Aside of the general objection against this, please use descriptive
function names and do not distinguish functions by adding random
characters which tell us absolutely nothing about the purpose.
Thanks,
tglx
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SMU-base PowerMac and server_mode
Hi Ben, So, I'm coming back to you about setting server_mode on SMU-based PPC machines. You know, so that the machine reboots after a power failure. Would you have a little time now ? Thanks a lot ! - Romain On Tue, Oct 6, 2009 at 11:51 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2009-10-06 at 12:31 +0200, Romain Goyet wrote: Hi Benjamin ! Actually I saw a post where you mentioned this tool on Google. I then searched it for like an hour or so, but really couldn't find it. That's why I ended up posting on this mailing list. I'm really glad you're on it by the way ! Anyway, like I said : I really looked for this tool, but couldn't find it… Hrm... ok. I'll have to figure it out again. No time right now, but get back to me next month after Kernel Summit and I'll see what i can do. Cheers, Ben. Thanks a lot ! - Romain On Tue, Oct 6, 2009 at 12:11 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2009-10-06 at 11:16 +0200, Romain Goyet wrote: Hi there, I have this Quad G5 here, running GentooPPC64. Runs fine. Had a hard time getting it to boot without a screen attached, but I eventually managed to (yaboot was the culprit). However, this machine is SMU-based, and I couldn't find a way to enable the equivalent of the PMU's server_mode (i.e. automatically reboot after a power failure). Is there any known way to do that ? I'm pretty sure I reverse engineered the necessary command a while back and somebody wrote a userland tool to set it, but I can't find it anymore :-) Google may help. Let me know if you can't find it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
2010/3/22 Németh Márton nm...@freemail.hu:
Hi Grant,
thanks for the comments, I solved some of the points you mentioned. I need
some
more time to work on the others. In the meantime I send the intermediate
version.
Grant Likely wrote:
2010/3/13 Németh Márton nm...@freemail.hu:
[...]
+ mem...@4000 {
+ device_type = memory;
+ reg = 0x4000 0x1; // 32KiB internal SRAM
+ };
Oh this is the small SRAM. yeah, you should move this under the
appropriate bridge node, remove the device_type property, and add a
compatible property. Memory nodes at the root like this are used to
describe what is basically main memory (what Linux will execute out
of). You'll want a new memory node for the external ram hooked up to
the 5554.
Yes, it is the small one (actually 64KiB, I corrected the comment also).
I added the external memory of the MPC5554DEMO evaluation board which has
a size of 512KiB.
Yikes. Half a meg is tiny for running Linux.
Would it be possible to program the uncompressed kernel to the FLASH so
it can run directly from there? I guess for the code and the constant sections
the FLASH could be a good place. Then cstart has to initialize the initialized
variables by copying data from FLASH to RAM and fill the BSS area with zero.
Hmmm. I don't know if anyone has kernel execute in place (XIP)
working on PowerPC.
[...]
+ s...@3f89000 { // System Integration Unit
+ compatible = fsl,mpc5554-siu;
+ reg = 0x03f9 0x4000;
+ interrupts = 45 1 // External
Interrupt Overrun 0-15
+ 46 1 // External
Interrupt 0
+ 47 1 // External
Interrupt 1
+ 48 1 // External
Interrupt 2
+ 49 1 // External
Interrupt 3
+ 50 1; // External
Interrupt 4-15
+ };
This doesn't look quite right /me goes to look at the 5554
reference manual
Okay, so all the external IRQs go through the SIU then, even though
the first 4 get passed straight through to the intc? And I see that
all the level/edge sensing and masking/acknowledging is done at the
SIU level, not the intc level, correct? So, what you effectively have
is the SIU is *another* interrupt controller that is cascaded to the
intc. Therefore you need to add the following to this node:
#interrupt-cells = 2; // cell1:extirq#, cell2:level/edge flags
interrupt-controller;
Also give the node a label so that nodes for external devices can
reference it for hooking up external irqs by overriding the top-level
interrupt-parent property.
Also, it would appear that intc interrupts don't have any level/edge
configuration associated with them. They are either asserted, or they
are not, correct? At the moment you're specifying every intc
interrupt with 2 cells, and the 2nd cell is always '1'. I think you
can change #interrupt-cells to 1 in the intc node and drop the '1'
everywhere.
When you write your intc driver, you'll also need to write the
cascaded driver for the external IRQs.
I tried to solve this point but I'm not quite sure whether the SIU interrupt
numbers shall be kept on the s...@3f89000 node or not.
Yes, you'll want the irq numbers to remain in the siu node because
those are the 'cascade' irqs that the siu raises when the external
irqs are asserted.
+ em...@3fa { // Modular Timer System
+ compatible = fsl,mpc5554-emios;
+ reg = 0x03fa 0x4000;
+ interrupts = 51 1 // Channel 0
+ 52 1 // Channel 1
+ 53 1 // Channel 2
+ 54 1 // Channel 3
+ 55 1 // Channel 4
+ 56 1 // Channel 5
+ 57 1 // Channel 6
+ 58 1 // Channel 7
+ 59 1 // Channel 8
+ 60 1 // Channel 9
+ 61 1 // Channel 10
+ 62 1 // Channel 11
+ 63 1 // Channel 12
+ 64 1 // Channel 13
+ 65 1 // Channel 14
+ 66 1 // Channel 15
+
Re: ppc64 sys_ipc breakage in 2.6.34-rc2
Anton Blanchard an...@samba.org writes: diff --git a/ipc/syscall.c b/ipc/syscall.c index 355a3da..1d6f53f 100644 --- a/ipc/syscall.c +++ b/ipc/syscall.c @@ -13,7 +13,7 @@ #include linux/syscalls.h #include linux/uaccess.h -SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, int, second, +SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, unsigned long, second, unsigned long, third, void __user *, ptr, long, fifth) ipc/syscall.c:17: error: conflicting types for ‘sys_ipc’ include/linux/syscalls.h:691: note: previous declaration of ‘sys_ipc’ was here Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 sys_ipc breakage in 2.6.34-rc2
On Mon, 22 Mar 2010, Andreas Schwab wrote: ipc/syscall.c:17: error: conflicting types for ‘sys_ipc’ include/linux/syscalls.h:691: note: previous declaration of ‘sys_ipc’ was here Hmm. Right you are. Why don't I see this? (I already applied the patch) Ahh. Because this only triggers with __ARCH_WANT_SYS_IPC. But why didn't Anton see it then? Anyway, I assume the following fixes it. Can you verify? Linus --- include/linux/syscalls.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index f994ae5..057929b 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -688,7 +688,7 @@ asmlinkage long sys_shmat(int shmid, char __user *shmaddr, int shmflg); asmlinkage long sys_shmget(key_t key, size_t size, int flag); asmlinkage long sys_shmdt(char __user *shmaddr); asmlinkage long sys_shmctl(int shmid, int cmd, struct shmid_ds __user *buf); -asmlinkage long sys_ipc(unsigned int call, int first, int second, +asmlinkage long sys_ipc(unsigned int call, int first, unsigned long second, unsigned long third, void __user *ptr, long fifth); asmlinkage long sys_mq_open(const char __user *name, int oflag, mode_t mode, struct mq_attr __user *attr); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Virtio_console usage of early printk
Hi all,
As far as I can see, early_put_chars is not used by virtio_console
because it checks whether there is a port available before using it.
If I understand correctly, this makes it useless because once we have
a port, we can use the regular virtio transport to output things to
the console. Does the attached patch seem valid ? Feedback from s390
and powerpc users who use this functionality would be appreciated.
Thanks,
François
From 3961f380bbe84a1036ddfc823039cbee31b44dcb Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com
Date: Thu, 18 Mar 2010 14:48:20 +0100
Subject: virtio: console: Fix early_put_chars usage
Currently early_put_chars is not used by virtio_console because it can only be used once a port has been found, at which point it's too late because it is no longer needed. This patch should fix it.
---
drivers/char/virtio_console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index f404ccf..691ba21 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -645,13 +645,13 @@ static int put_chars(u32 vtermno, const char *buf, int count)
{
struct port *port;
+ if (unlikely(early_put_chars))
+ return early_put_chars(vtermno, buf, count);
+
port = find_port_by_vtermno(vtermno);
if (!port)
return 0;
- if (unlikely(early_put_chars))
- return early_put_chars(vtermno, buf, count);
-
return send_buf(port, (void *)buf, count);
}
--
1.6.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: export data from new hcall H_EM_GET_PARMS
* Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com [2010-03-10 17:49:25]:
Hi Ben,
I have cleaned up the code from the previous post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080630.html
Changes from v1:
* Removed redundant return statements and rearranged code
Description:
A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from the platform. This data can be used by user space administrative
tools for better power management.
The following patch add data from this new hcall into the lparcfg
driver and exports to user space along with other existing lpar data
in /proc/powerpc/lparcfg
Please review and include in powerpc -next tree.
Hi Ben,
Looks like you have not opened the -next tree after the merge window
yet. The current git tree status is same as -merge. Please review
and include in powerpc next tree.
Thanks,
Vaidy
---
powerpc: export data from new hcall H_EM_GET_PARMS
Add support for H_EM_GET_PARMS hcall that will return data
related to power modes from the platform. Export the data
directly to user space for administrative tools to interpret
and use.
cat /proc/powerpc/lparcfg will export power mode data
Signed-off-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/hvcall.h |1 +
arch/powerpc/kernel/lparcfg.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index f027581..ebe7493 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -228,6 +228,7 @@
#define H_JOIN 0x298
#define H_VASI_STATE0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define H_GET_EM_PARMS 0x2B8
#define H_SET_MPP0x2D0
#define H_GET_MPP0x2D4
#define MAX_HCALL_OPCODE H_GET_MPP
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d09d1c6..ff698fb 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -37,7 +37,7 @@
#include asm/vio.h
#include asm/mmu.h
-#define MODULE_VERS 1.8
+#define MODULE_VERS 1.9
#define MODULE_NAME lparcfg
/* #define LPARCFG_DEBUG */
@@ -486,6 +486,14 @@ static void splpar_dispatch_data(struct seq_file *m)
seq_printf(m, dispatch_dispersions=%lu\n, dispatch_dispersions);
}
+static void parse_em_data(struct seq_file *m)
+{
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ seq_printf(m, power_mode_data=%016lx\n, retbuf[0]);
+}
+
static int pseries_lparcfg_data(struct seq_file *m, void *v)
{
int partition_potential_processors;
@@ -540,6 +548,8 @@ static int pseries_lparcfg_data(struct seq_file *m, void
*v)
seq_printf(m, slb_size=%d\n, mmu_slb_size);
+ parse_em_data(m);
+
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 sys_ipc breakage in 2.6.34-rc2
Linus Torvalds torva...@linux-foundation.org writes: On Mon, 22 Mar 2010, Andreas Schwab wrote: ipc/syscall.c:17: error: conflicting types for ‘sys_ipc’ include/linux/syscalls.h:691: note: previous declaration of ‘sys_ipc’ was here Hmm. Right you are. Why don't I see this? (I already applied the patch) Ahh. Because this only triggers with __ARCH_WANT_SYS_IPC. But why didn't Anton see it then? Anyway, I assume the following fixes it. Can you verify? Yes, this works. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 sys_ipc breakage in 2.6.34-rc2
On Mon, Mar 22, 2010 at 05:47:59PM +1100, Anton Blanchard wrote: The patch below changes second from an int to an unsigned long which fixes shmget on ppc64 (and I assume s390, sparc64 and mips64). Looks good, except that the prototype in the header also needs to be adjusted. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 sys_ipc breakage in 2.6.34-rc2
Hi, ipc/syscall.c:17: error: conflicting types for ‘sys_ipc’ include/linux/syscalls.h:691: note: previous declaration of ‘sys_ipc’ was here Hmm. Right you are. Why don't I see this? (I already applied the patch) Ahh. Because this only triggers with __ARCH_WANT_SYS_IPC. But why didn't Anton see it then? Anyway, I assume the following fixes it. Can you verify? Sorry, I forgot to quilt add. Stupid screw up, thanks Andreas for catching it so quickly. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtio_console usage of early printk
On (Mon) Mar 22 2010 [18:45:47], François Diakhate wrote:
Hi all,
As far as I can see, early_put_chars is not used by virtio_console
because it checks whether there is a port available before using it.
If I understand correctly, this makes it useless because once we have
a port, we can use the regular virtio transport to output things to
the console. Does the attached patch seem valid ? Feedback from s390
and powerpc users who use this functionality would be appreciated.
Looks OK to me, Christian, others, could you comment on this please?
Thanks,
François
From 3961f380bbe84a1036ddfc823039cbee31b44dcb Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com
Date: Thu, 18 Mar 2010 14:48:20 +0100
Subject: virtio: console: Fix early_put_chars usage
Currently early_put_chars is not used by virtio_console because it can only
be used once a port has been found, at which point it's too late because it
is no longer needed. This patch should fix it.
---
drivers/char/virtio_console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index f404ccf..691ba21 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -645,13 +645,13 @@ static int put_chars(u32 vtermno, const char *buf, int
count)
{
struct port *port;
+ if (unlikely(early_put_chars))
+ return early_put_chars(vtermno, buf, count);
+
port = find_port_by_vtermno(vtermno);
if (!port)
return 0;
- if (unlikely(early_put_chars))
- return early_put_chars(vtermno, buf, count);
-
return send_buf(port, (void *)buf, count);
}
--
1.6.1.3
Amit
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Mon, Mar 08, 2010 at 11:44:48PM +0530, K.Prasad wrote: @@ -479,6 +483,7 @@ struct task_struct *__switch_to(struct t old_thread-accum_tb += (current_tb - start_tb); new_thread-start_tb = current_tb; } + flush_ptrace_hw_breakpoint(current); #endif local_irq_save(flags); This line should be in flush_thread(), not __switch_to(). In fact it may not be necessary at all given that flush_ptrace_hw_breakpoint() gets called in do_exit(). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Grant Likely wrote:
2010/3/22 Németh Márton nm...@freemail.hu:
Hi Grant,
thanks for the comments, I solved some of the points you mentioned. I need
some
more time to work on the others. In the meantime I send the intermediate
version.
Grant Likely wrote:
2010/3/13 Németh Márton nm...@freemail.hu:
[...]
+ mem...@4000 {
+ device_type = memory;
+ reg = 0x4000 0x1; // 32KiB internal SRAM
+ };
Oh this is the small SRAM. yeah, you should move this under the
appropriate bridge node, remove the device_type property, and add a
compatible property. Memory nodes at the root like this are used to
describe what is basically main memory (what Linux will execute out
of). You'll want a new memory node for the external ram hooked up to
the 5554.
Yes, it is the small one (actually 64KiB, I corrected the comment also).
I added the external memory of the MPC5554DEMO evaluation board which has
a size of 512KiB.
Yikes. Half a meg is tiny for running Linux.
Would it be possible to program the uncompressed kernel to the FLASH so
it can run directly from there? I guess for the code and the constant
sections
the FLASH could be a good place. Then cstart has to initialize the
initialized
variables by copying data from FLASH to RAM and fill the BSS area with zero.
Hmmm. I don't know if anyone has kernel execute in place (XIP)
working on PowerPC.
I found some promising links for XIP on PowerPC:
- XIP for PowerQUICC™I 8xx:
http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP
- XIP on Arctic III PowerPC board:
http://simplemachines.it/xip/KernelXIP.html#head-3d70ff3a6d5599f6f98f1d4b4becc9271310967d
[...]
+ s...@3f89000 { // System Integration Unit
+ compatible = fsl,mpc5554-siu;
+ reg = 0x03f9 0x4000;
+ interrupts = 45 1 // External
Interrupt Overrun 0-15
+ 46 1 // External
Interrupt 0
+ 47 1 // External
Interrupt 1
+ 48 1 // External
Interrupt 2
+ 49 1 // External
Interrupt 3
+ 50 1;// External
Interrupt 4-15
+ };
This doesn't look quite right /me goes to look at the 5554
reference manual
Okay, so all the external IRQs go through the SIU then, even though
the first 4 get passed straight through to the intc? And I see that
all the level/edge sensing and masking/acknowledging is done at the
SIU level, not the intc level, correct? So, what you effectively have
is the SIU is *another* interrupt controller that is cascaded to the
intc. Therefore you need to add the following to this node:
#interrupt-cells = 2; // cell1:extirq#, cell2:level/edge flags
interrupt-controller;
Also give the node a label so that nodes for external devices can
reference it for hooking up external irqs by overriding the top-level
interrupt-parent property.
Also, it would appear that intc interrupts don't have any level/edge
configuration associated with them. They are either asserted, or they
are not, correct? At the moment you're specifying every intc
interrupt with 2 cells, and the 2nd cell is always '1'. I think you
can change #interrupt-cells to 1 in the intc node and drop the '1'
everywhere.
When you write your intc driver, you'll also need to write the
cascaded driver for the external IRQs.
I tried to solve this point but I'm not quite sure whether the SIU interrupt
numbers shall be kept on the s...@3f89000 node or not.
Yes, you'll want the irq numbers to remain in the siu node because
those are the 'cascade' irqs that the siu raises when the external
irqs are asserted.
+ em...@3fa { // Modular Timer System
+ compatible = fsl,mpc5554-emios;
+ reg = 0x03fa 0x4000;
+ interrupts = 51 1 // Channel 0
+ 52 1 // Channel 1
+ 53 1 // Channel 2
+ 54 1 // Channel 3
+ 55 1 // Channel 4
+ 56 1 // Channel 5
+ 57 1 // Channel 6
+ 58 1 // Channel 7
+ 59 1 // Channel 8
+ 60 1 // Channel 9
+ 61 1 // Channel 10
+ 62 1 //
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Sat, 20 Mar 2010 23:05:40 + Ben Hutchings b...@decadent.org.uk wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). When you say they must now implement, I assume that you mean that they _do_ now implement, and that no additional architecture work is needed. The architecture-specific changes here are untested and need to be reviewed by architecture maintainers. That would be nice. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
