Re: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
Benjamin Herrenschmidt writes: > What if you just comment out the tickle code ? I haven't tried it yet, but I suspect it won't tickle the fcu any more since wf_control_set avoids writing an unchanged value (unlike the old driver). 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: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
On Thu, 2012-04-26 at 11:13 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > What if you just comment out the tickle code ? > > I haven't tried it yet, but I suspect it won't tickle the fcu any more > since wf_control_set avoids writing an unchanged value (unlike the old > driver). Sure, the question is whether that fixes the "annoyance" :-) I don't think we really need to tickle the FCU as long as we have that #define set in windfarm_fcu to use the actual fan values rather than the programmed one. In fact, can you change that define around and see if it makes it behave more like therm_pm72 overall ? IE That's the only -known- difference between the old and new driver (+/- a bug / typo / etc..) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Enable MTD/NOR/NAND options by default in defconfig
Enable MTD/NOR/NAND options by default in mpc85xx_defconfig and mpc85xx_smp_defconfig to support NOR, NAND flash. Signed-off-by: Shengzhou Liu --- based on master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git arch/powerpc/configs/mpc85xx_defconfig | 26 ++ arch/powerpc/configs/mpc85xx_smp_defconfig | 25 + 2 files changed, 51 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index d6b6df5..a42304d 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -39,6 +39,7 @@ CONFIG_TQM8560=y CONFIG_SBC8548=y CONFIG_QUICC_ENGINE=y CONFIG_QE_GPIO=y +CONFIG_MPC8xxx_GPIO=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y @@ -74,6 +75,31 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_VERIFY_WRITE=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 5b0e292..31ef74f 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -76,6 +76,31 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_VERIFY_WRITE=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/85xx: Enable MTD/NOR/NAND options by default in defconfig
Enable MTD/NOR/NAND options by default in mpc85xx_defconfig and mpc85xx_smp_defconfig to support NOR, NAND flash. Signed-off-by: Shengzhou Liu --- based on master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git changes of v2: remove typo "CONFIG_MPC8xxx_GPIO=y" compared with v1. arch/powerpc/configs/mpc85xx_defconfig | 25 + arch/powerpc/configs/mpc85xx_smp_defconfig | 25 + 2 files changed, 50 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index d6b6df5..0f55408 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -74,6 +74,31 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_VERIFY_WRITE=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 5b0e292..31ef74f 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -76,6 +76,31 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_VERIFY_WRITE=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
Benjamin Herrenschmidt writes: > In fact, can you change that define around and see if it makes it behave > more like therm_pm72 overall ? IE That's the only -known- difference > between the old and new driver (+/- a bug / typo / etc..) Yes, that's make the difference for the cpu fan control. Note that MacOS (at least 10.3, which is the only one I have) drives the fans the same way as the old driver. 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: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
Benjamin Herrenschmidt writes: > On Thu, 2012-04-26 at 11:13 +0200, Andreas Schwab wrote: >> Benjamin Herrenschmidt writes: >> >> > What if you just comment out the tickle code ? >> >> I haven't tried it yet, but I suspect it won't tickle the fcu any more >> since wf_control_set avoids writing an unchanged value (unlike the old >> driver). > > Sure, the question is whether that fixes the "annoyance" :-) Removing the tickling removes much of the annoyance. 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: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
Benjamin Herrenschmidt writes: > Darwin has an algorithm for it based on getting some data from the video > driver in the AGP slot, but I don't have that. Perhaps the slots fan should be programmable from user space. For my use case I'm pretty sure I would never need to set it to more than the minimum speed. 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: [EDAC PATCH v13 2/7] edac: move dimm properties to struct dimm_info
On Mon, Apr 16, 2012 at 05:12:08PM -0300, Mauro Carvalho Chehab wrote: > On systems based on chip select rows, all channels need to use memories > with the same properties, otherwise the memories on channels A and B > won't be recognized. > > However, such assumption is not true for all types of memory > controllers. > > Controllers for FB-DIMM's don't have such requirements. > > Also, modern Intel controllers seem to be capable of handling such > differences. > > So, we need to get rid of storing the DIMM information into a per-csrow > data, storing it, instead at the right place. > > The first step is to move grain, mtype, dtype and edac_mode to the > per-dimm struct. > > Reviewed-by: Aristeu Rozanski > Cc: Doug Thompson > Cc: Borislav Petkov > Cc: Mark Gross > Cc: Jason Uhlenkott > Cc: Tim Small > Cc: Ranganathan Desikan > Cc: "Arvind R." > Cc: Olof Johansson > Cc: Egor Martovetsky > Cc: Chris Metcalf > Cc: Michal Marek > Cc: Jiri Kosina > Cc: Joe Perches > Cc: Dmitry Eremin-Solenikov > Cc: Benjamin Herrenschmidt > Cc: Hitoshi Mitake > Cc: Andrew Morton > Cc: James Bottomley > Cc: "Niklas Söderlund" > Cc: Shaohui Xie > Cc: Josh Boyer > Cc: Mike Williams > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Mauro Carvalho Chehab For the amd64_edac and core changes: Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][2/3][RFC] TDM Framework
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Wednesday, April 25, 2012 11:20 AM To: Aggrwal Poonam-B10812 Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400 Subject: Re: [PATCH][2/3][RFC] TDM Framework On Sat, 2012-03-10 at 18:27 +0530, Poonam Aggrwal wrote: > From: Sandeep Singh > > TDM Framework is an attempt to provide a platform independent layer > which can offer a standard interface for TDM access to different client > modules. > Beneath, the framework layer can house different types of TDM drivers > to handle various TDM devices, the hardware intricacies of the devices > being completely taken care by TDM drivers. Neither the changeset comment, the code, not the Documentation file (which are non-existent, at least in this patch, though mentioned), define what "TDM" actually is :-) [Sandeep] Thanks for your comments. Documentation for TDM is present in the following patch: http://patchwork.ozlabs.org/patch/145857/ Regards, Sandeep Cheers, Ben. > This framework layer will allow any type of TDM device to hook with it. > For example Freescale controller as on MPC8315, UCC based TDM > controller, or any other controller. > > The main functions of this Framework are: > - provides interface to TDM clients to access TDM functionalities. > - provides standard interface for TDM drivers to hook with the framework. > - handles various data handling stuff and buffer management. > > In future this Framework will be extended to provide Interface for > Line control devices also. For example SLIC, E1/T1 Framers etc. > > Limitations/Future Work > --- > 1. Presently the framework supports only Single Port channelised mode. > 2. Also the configurability options are limited which will be extended later > on. > 3. Only kernel mode TDM clients are supported currently. Support for > User mode clients will be added later. > > Signed-off-by: Sandeep Singh > Signed-off-by: Poonam Aggrwal > --- > A couple of todos' are left in the patch, we are working on it and > will be addressed in the updated patch set. > drivers/Kconfig |1 + > drivers/Makefile|1 + > drivers/tdm/Kconfig | 25 + > drivers/tdm/tdm-core.c | 1146 > +++ > include/linux/mod_devicetable.h | 11 + > include/linux/tdm.h | 347 > 6 files changed, 1531 insertions(+), 0 deletions(-) create mode > 100644 drivers/tdm/Kconfig create mode 100644 drivers/tdm/tdm-core.c > create mode 100644 include/linux/tdm.h > > diff --git a/drivers/Kconfig b/drivers/Kconfig index ad6c1eb..25f7f5b > 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -130,4 +130,5 @@ source "drivers/virt/Kconfig" > > source "drivers/net/dpa/NetCommSw/Kconfig" > > +source "drivers/tdm/Kconfig" > endmenu > diff --git a/drivers/Makefile b/drivers/Makefile index > cd546eb..362b5ed 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -102,6 +102,7 @@ obj-$(CONFIG_INFINIBAND) += infiniband/ > obj-$(CONFIG_SGI_SN) += sn/ > obj-y+= firmware/ > obj-$(CONFIG_CRYPTO) += crypto/ > +obj-$(CONFIG_TDM)+= tdm/ > obj-$(CONFIG_SUPERH) += sh/ > obj-$(CONFIG_ARCH_SHMOBILE) += sh/ > ifndef CONFIG_ARCH_USES_GETTIMEOFFSET diff --git > a/drivers/tdm/Kconfig b/drivers/tdm/Kconfig new file mode 100644 index > 000..8db2b05 > --- /dev/null > +++ b/drivers/tdm/Kconfig > @@ -0,0 +1,25 @@ > +# > +# TDM subsystem configuration > +# > + > +menuconfig TDM > + tristate "TDM support" > + ---help--- > + More information is contained in the directory > , > + especially in the file called "summary" there. > + If you want TDM support, you should say Y here and also to the > + specific driver for your bus adapter(s) below. > + > + This TDM support can also be built as a module. If so, the module > + will be called tdm-core. > + > +if TDM > + > +config TDM_DEBUG_CORE > + bool "TDM Core debugging messages" > + help > + Say Y here if you want the TDM core to produce a bunch of debug > + messages to the system log. Select this if you are having a > + problem with TDM support and want to see more of what is going on. > + > +endif # TDM > diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file > mode 100644 index 000..cdda260 > --- /dev/null > +++ b/drivers/tdm/tdm-core.c > @@ -0,0 +1,1146 @@ > +/* driver/tdm/tdm-core.c > + * > + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved. > + * > + * TDM core is the interface between TDM clients and TDM devices. > + * It is also intended to serve as an interface for line controld > + * devices later on. > + * > + * Author:Hemant Agrawal > + * Rajesh Gumasta > + * > + * Modified by Sandeep Kr Singh > + * Poonam Aggarwal > + * 1. Added
[PATCH 3/3][RFC] ftrace/ppc: Use patch_instruction instead of probe_kernel_write()
From: Steven Rostedt
The patch_instruction() interface is made to modify kernel text. It is
safer to use that then the probe_kernel_write() when modifying kernel
code.
Signed-off-by: Steven Rostedt
---
arch/powerpc/kernel/ftrace.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 84a5ddd..4e376bc 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -63,11 +63,9 @@ ftrace_modify_code(unsigned long ip, unsigned int old,
unsigned int new)
return -EINVAL;
/* replace the text with the new text */
- if (probe_kernel_write((void *)ip, &new, MCOUNT_INSN_SIZE))
+ if (patch_instruction((unsigned int *)ip, new))
return -EPERM;
- flush_icache_range(ip, ip + 8);
-
return 0;
}
@@ -212,12 +210,9 @@ __ftrace_make_nop(struct module *mod,
*/
op = 0x4808;/* b +8 */
- if (probe_kernel_write((void *)ip, &op, MCOUNT_INSN_SIZE))
+ if (patch_instruction((unsigned int *)ip, op))
return -EPERM;
-
- flush_icache_range(ip, ip + 8);
-
return 0;
}
@@ -286,11 +281,9 @@ __ftrace_make_nop(struct module *mod,
op = PPC_INST_NOP;
- if (probe_kernel_write((void *)ip, &op, MCOUNT_INSN_SIZE))
+ if (patch_instruction((unsigned int *)ip, op))
return -EPERM;
- flush_icache_range(ip, ip + 8);
-
return 0;
}
#endif /* PPC64 */
@@ -426,11 +419,9 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long
addr)
pr_devel("write to %lx\n", rec->ip);
- if (probe_kernel_write((void *)ip, &op, MCOUNT_INSN_SIZE))
+ if (patch_instruction((unsigned int *)ip, op))
return -EPERM;
- flush_icache_range(ip, ip + 8);
-
return 0;
}
#endif /* CONFIG_PPC64 */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3][RFC] powerpc: Have patch_instruction detect faults
From: Steven Rostedt
For ftrace to use the patch_instruction code, it needs to check for
faults on write. Ftrace updates code all over the kernel, and we need to
know if code is updated or not due to protections that are placed on
some portions of the kernel. If ftrace does not detect a fault, it will
error later on, and it will be much more difficult to find the problem.
By changing patch_instruction() to detect faults, then ftrace will be
able to make use of it too.
Signed-off-by: Steven Rostedt
---
arch/powerpc/include/asm/code-patching.h |4 ++--
arch/powerpc/lib/code-patching.c | 14 ++
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 37c32aba..a6f8c7a 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -26,8 +26,8 @@ unsigned int create_branch(const unsigned int *addr,
unsigned long target, int flags);
unsigned int create_cond_branch(const unsigned int *addr,
unsigned long target, int flags);
-void patch_branch(unsigned int *addr, unsigned long target, int flags);
-void patch_instruction(unsigned int *addr, unsigned int instr);
+int patch_branch(unsigned int *addr, unsigned long target, int flags);
+int patch_instruction(unsigned int *addr, unsigned int instr);
int instr_is_relative_branch(unsigned int instr);
int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 7c975d4..dd223b3 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -13,17 +13,23 @@
#include
#include
#include
+#include
-void patch_instruction(unsigned int *addr, unsigned int instr)
+int patch_instruction(unsigned int *addr, unsigned int instr)
{
- *addr = instr;
+ int err;
+
+ err = __put_user(instr, addr);
+ if (err)
+ return err;
asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync" : : "r" (addr));
+ return 0;
}
-void patch_branch(unsigned int *addr, unsigned long target, int flags)
+int patch_branch(unsigned int *addr, unsigned long target, int flags)
{
- patch_instruction(addr, create_branch(addr, target, flags));
+ return patch_instruction(addr, create_branch(addr, target, flags));
}
unsigned int create_branch(const unsigned int *addr,
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3][RFC] powerpc/ftrace: Removal of stop machine (and other goodies)
Benjamin, You once told me on IRC that powerpc has no problem with modifying code on one CPU that may be executing on another CPU. With the tests I made on my PPC64 (2 CPUs) box, it seems to be the case. The first patch removes stop_machine from powerpc. The other patches add some error handling if ftrace detects an update didn't occur with 'patch_instruction'. This is just an RFC, but if it's fine, feel free to pull them into your tree. -- Steve Steven Rostedt (3): ftrace/ppc: Have PPC skip updating with stop_machine() powerpc: Have patch_instruction detect faults ftrace/ppc: Use patch_instruction instead of probe_kernel_write() arch/powerpc/include/asm/code-patching.h |4 +- arch/powerpc/kernel/ftrace.c | 69 -- arch/powerpc/lib/code-patching.c | 14 -- 3 files changed, 68 insertions(+), 19 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3][RFC] ftrace/ppc: Have PPC skip updating with stop_machine()
From: Steven Rostedt
PPC does not have the synchronization issues that x86 has with
modifying code on one CPU while another CPU is executing it.
The other CPU will either see the old or new code without any
issues, unlike x86 which may issue a GPF.
Instead of calling the heavy stop_machine, just update the code.
Signed-off-by: Steven Rostedt
---
arch/powerpc/kernel/ftrace.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index bf99cfa..84a5ddd 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -484,6 +484,58 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
return ret;
}
+static int __ftrace_replace_code(struct dyn_ftrace *rec, int enable)
+{
+ unsigned long ftrace_addr = (unsigned long)FTRACE_ADDR;
+ int ret;
+
+ ret = ftrace_update_record(rec, enable);
+
+ switch (ret) {
+ case FTRACE_UPDATE_IGNORE:
+ return 0;
+ case FTRACE_UPDATE_MAKE_CALL:
+ return ftrace_make_call(rec, ftrace_addr);
+ case FTRACE_UPDATE_MAKE_NOP:
+ return ftrace_make_nop(NULL, rec, ftrace_addr);
+ }
+
+ return 0;
+}
+
+static void ftrace_replace_code(int enable)
+{
+ struct ftrace_rec_iter *iter;
+ struct dyn_ftrace *rec;
+ int ret;
+
+ for (iter = ftrace_rec_iter_start(); iter;
+iter = ftrace_rec_iter_next(iter)) {
+ rec = ftrace_rec_iter_record(iter);
+ ret = __ftrace_replace_code(rec, enable);
+ if (ret) {
+ ftrace_bug(ret, rec->ip);
+ return;
+ }
+ }
+}
+
+void arch_ftrace_update_code(int command)
+{
+ if (command & FTRACE_UPDATE_CALLS)
+ ftrace_replace_code(1);
+ else if (command & FTRACE_DISABLE_CALLS)
+ ftrace_replace_code(0);
+
+ if (command & FTRACE_UPDATE_TRACE_FUNC)
+ ftrace_update_ftrace_func(ftrace_trace_function);
+
+ if (command & FTRACE_START_FUNC_RET)
+ ftrace_enable_ftrace_graph_caller();
+ else if (command & FTRACE_STOP_FUNC_RET)
+ ftrace_disable_ftrace_graph_caller();
+}
+
int __init ftrace_dyn_arch_init(void *data)
{
/* caller expects data to be zero */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/85xx: Enable MTD/NOR/NAND options by default in defconfig
On 04/26/2012 05:43 AM, Shengzhou Liu wrote: > +CONFIG_MTD_NAND_VERIFY_WRITE=y I don't think we want this on by default. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
On Thu, 2012-04-26 at 13:41 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > In fact, can you change that define around and see if it makes it behave > > more like therm_pm72 overall ? IE That's the only -known- difference > > between the old and new driver (+/- a bug / typo / etc..) > > Yes, that's make the difference for the cpu fan control. Note that > MacOS (at least 10.3, which is the only one I have) drives the fans the > same way as the old driver. Ok, I'll switch that back then. It seemed more sensible to read the actual fan values rather than the programmed ones (in fact I wonder if I can just skip the read alltogether then and use a cached value but that means I won't be able to detect failed fans...), but if you say it behaves better, let's keep it the way it was. As for the tickle, I'm not sure yet how to proceed. I'll look into it, try various things. We can maybe just remove the tickle but that means that a completely idle machine might start ramping up as the FCU times out. Finally, setting the slot fan from sysfs should be doable reasonably easily. Stay tuned and thanks a lot for testing ! :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] cpu: Introduce clear_tasks_mm_cpumask() helper
On Mon, 23 Apr 2012 00:07:36 -0700
Anton Vorontsov wrote:
> Many architectures clear tasks' mm_cpumask like this:
>
> read_lock(&tasklist_lock);
> for_each_process(p) {
> if (p->mm)
> cpumask_clear_cpu(cpu, mm_cpumask(p->mm));
> }
> read_unlock(&tasklist_lock);
>
> Depending on the context, the code above may have several problems,
> such as:
>
> 1. Working with task->mm w/o getting mm or grabing the task lock is
>dangerous as ->mm might disappear (exit_mm() assigns NULL under
>task_lock(), so tasklist lock is not enough).
>
> 2. Checking for process->mm is not enough because process' main
>thread may exit or detach its mm via use_mm(), but other threads
>may still have a valid mm.
>
> This patch implements a small helper function that does things
> correctly, i.e.:
>
> 1. We take the task's lock while whe handle its mm (we can't use
>get_task_mm()/mmput() pair as mmput() might sleep);
>
> 2. To catch exited main thread case, we use find_lock_task_mm(),
>which walks up all threads and returns an appropriate task
>(with task lock held).
>
> Also, Per Peter Zijlstra's idea, now we don't grab tasklist_lock in
> the new helper, instead we take the rcu read lock. We can do this
> because the function is called after the cpu is taken down and marked
> offline, so no new tasks will get this cpu set in their mm mask.
>
Seems reasonable.
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -179,6 +179,7 @@ extern void put_online_cpus(void);
> #define hotcpu_notifier(fn, pri) cpu_notifier(fn, pri)
> #define register_hotcpu_notifier(nb) register_cpu_notifier(nb)
> #define unregister_hotcpu_notifier(nb) unregister_cpu_notifier(nb)
> +void clear_tasks_mm_cpumask(int cpu);
> int cpu_down(unsigned int cpu);
>
> #ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 2060c6e..ecdf499 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -10,6 +10,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -171,6 +173,30 @@ void __ref unregister_cpu_notifier(struct notifier_block
> *nb)
> }
> EXPORT_SYMBOL(unregister_cpu_notifier);
>
> +void clear_tasks_mm_cpumask(int cpu)
The operation of this function was presumably obvious to you at the
time you wrote it, but that isn't true of other people at later times.
Please document it?
> +{
> + struct task_struct *p;
> +
> + /*
> + * This function is called after the cpu is taken down and marked
> + * offline,
hm, well. Who said that this function will only ever be called
after that CPU was taken down? There is nothing in the function name
nor in the (absent) documentation which enforces this precondition.
If someone tries to use this function for a different purpose, or
copies-and-modifies it for a different purpose, we just shot them in
the foot.
They'd be pretty dumb to do that without reading the local comment,
but still...
>so its not like new tasks will ever get this cpu set in
> + * their mm mask. -- Peter Zijlstra
> + * Thus, we may use rcu_read_lock() here, instead of grabbing
> + * full-fledged tasklist_lock.
> + */
> + rcu_read_lock();
> + for_each_process(p) {
> + struct task_struct *t;
> +
> + t = find_lock_task_mm(p);
> + if (!t)
> + continue;
> + cpumask_clear_cpu(cpu, mm_cpumask(t->mm));
> + task_unlock(t);
> + }
> + rcu_read_unlock();
> +}
It is good that this code exists under CONFIG_HOTPLUG_CPU. Did you
check that everything works correctly with CONFIG_HOTPLUG_CPU=n?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][2/3][RFC] TDM Framework
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, April 24, 2012 6:05 AM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400
> Subject: Re: [PATCH][2/3][RFC] TDM Framework
>
Thanks Scott for the comments, we will incorporate them and send the next
version.
Regards
Poonam
> On 03/10/2012 06:57 AM, Poonam Aggrwal wrote:
> > diff --git a/drivers/Kconfig b/drivers/Kconfig index ad6c1eb..25f7f5b
> > 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -130,4 +130,5 @@ source "drivers/virt/Kconfig"
> >
> > source "drivers/net/dpa/NetCommSw/Kconfig"
> >
> > +source "drivers/tdm/Kconfig"
> > endmenu
>
> When posting patches to this list, please ensure that they are based on
> an upstream Linux kernel and not a Freescale BSP kernel.
Sure, but this was RFC patch set where the primary intention was to get design
level comments.
But we will send the updated patches rebased on upstream head.
>
> > +if TDM
> > +
> > +config TDM_DEBUG_CORE
> > + bool "TDM Core debugging messages"
> > + help
> > + Say Y here if you want the TDM core to produce a bunch of debug
> > + messages to the system log. Select this if you are having a
> > + problem with TDM support and want to see more of what is going
> on.
> > +
> > +endif # TDM
>
> Please use the normal kernel mechanisms for controlling debug messages.
>
okay
> > diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file
> > mode 100644 index 000..cdda260
> > --- /dev/null
> > +++ b/drivers/tdm/tdm-core.c
> > @@ -0,0 +1,1146 @@
> > +/* driver/tdm/tdm-core.c
> > + *
> > + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights
> reserved.
> > + *
> > + * TDM core is the interface between TDM clients and TDM devices.
> > + * It is also intended to serve as an interface for line controld
> > + * devices later on.
> > + *
> > + * Author:Hemant Agrawal
> > + * Rajesh Gumasta
> > + *
> > + * Modified by Sandeep Kr Singh
> > + * Poonam Aggarwal
> > + * 1. Added framework based initialization of device.
> > + * 2. All the init/run time configuration is now done by framework.
> > + * 3. Added channel level operations.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify it
> > + * under the terms of the GNU General Public License as published
> > +by the
> > + * Free Software Foundation; either version 2 of the License, or
> > +(at your
> > + * option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > +but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > +along
> > + * with this program; if not, write to the Free Software Foundation,
> > +Inc.,
> > + * 675 Mass Ave, Cambridge, MA 02139, USA.
> > + */
> > +
> > +/* if read write debug required */
> > +#undef TDM_CORE_DEBUG
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "device/tdm_fsl.h"
>
> What is a reference to tdm_fsl.h doing in the presumably hardware-
> independent tdm-core.c?
Need to check that, ideally this include should not be required
>
> > +static DEFINE_MUTEX(tdm_core_lock);
> > +static DEFINE_IDR(tdm_adapter_idr);
> > +/* List of TDM adapters registered with TDM framework */
> > +LIST_HEAD(adapter_list);
> > +
> > +/* List of TDM clients registered with TDM framework */
> > +LIST_HEAD(driver_list);
> > +
> > +/* In case the previous data is not fetched by the client driver, the
> > + * de-interleaving function will discard the old data and rewrite
> > +the
> > + * new data */
> > +static int use_latest_tdm_data = 1;
>
> Describe when one would want to change this, and provide a better way to
> change it (e.g. module parameter or sysfs knob).
>
Ok, description can be added.
Will also explore the sysfs knob option.
> /*
> * Linux kernel
> * multi-line comment style
> * is like this.
> */
>
Sure
> > +/* this tasklet is created for each adapter instance */ static void
> > +tdm_data_tasklet_fn(unsigned long);
> > +
> > +/* tries to match client driver with the adapter */ static int
> > +tdm_device_match(struct tdm_driver *driver, struct tdm_adapter *adap)
> > +{
> > + /* match on an id table if there is one */
> > + if (driver->id_table && driver->id_table->name[0]) {
> > + if (!(strcmp(driver->id_table->name, adap->name)))
> > + return (int)driver->id_table;
> > + }
> > +
[PATCH v3] powerpc/85xx: Enable MTD/NOR/NAND options by default in defconfig
Enable MTD/NOR/NAND options by default in mpc85xx_defconfig and mpc85xx_smp_defconfig to support NOR, NAND flash. Signed-off-by: Shengzhou Liu --- based on master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git tree. v3: remove "CONFIG_MTD_NAND_VERIFY_WRITE=y" v2: remove typo "CONFIG_MPC8xxx_GPIO=y" arch/powerpc/configs/mpc85xx_defconfig | 24 arch/powerpc/configs/mpc85xx_smp_defconfig | 24 2 files changed, 48 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index d6b6df5..8c3da78 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -74,6 +74,30 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 5b0e292..575c410 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -76,6 +76,30 @@ CONFIG_INET_ESP=y CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_FTL=y +CONFIG_MTD_GEN_PROBE=y +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_FSL_ELBC=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
