[PATCH] dma: imx-sdma: fix indentation
Fixed a coding style error, switch and case should be at the same indent
Signed-off-by: Asaf Vertz
---
drivers/dma/imx-sdma.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 88afc48..8729877 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1301,15 +1301,15 @@ static void sdma_load_firmware(const struct firmware
*fw, void *context)
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
switch (header->version_major) {
- case 1:
- sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
- break;
- case 2:
- sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
- break;
- default:
- dev_err(sdma->dev, "unknown firmware version\n");
- goto err_firmware;
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ goto err_firmware;
}
addr = (void *)header + header->script_addrs_start;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the rcu tree
Hi Paul,
After merging the rcu tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
from arch/powerpc/kernel/setup_64.c:68:
include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
struct srcu_struct srcu;
^
include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
struct srcu_struct irq_srcu;
^
Presumably caused by commit 6e8ef258b669 ("srcu: Isolate srcu sections
using CONFIG_SRCU").
I have reverted that commit again for today - more work required ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpwRVZ0PtQG1.pgp
Description: OpenPGP digital signature
Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
Hi Michael, On Wed, Dec 10, 2014 at 1:38 PM, Michael Ellerman wrote: > usleep is a Fedoraism, it's not generally available on Debian based > systems AFAICS. > > GNU sleep accepts a floating point argument, so use that instead. I tested it on busybox not Debian, sorry. But it seems busybox's sleep doesn't support floating point argument.. / # ls -l `which sleep` lrwxrwxrwx 1 root rooot 7 May 22 2014 /bin/sleep -> busybox / # sleep 0.1 sleep: invalid number '0.1' Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the access_once tree
Hi Christian, After merging the access_once tree, today's linux-next build (powerpc ppc44x_defconfig) failed like this: In file included from /scratch/sfr/next/include/uapi/linux/stddef.h:1:0, from /scratch/sfr/next/include/linux/stddef.h:4, from /scratch/sfr/next/include/uapi/linux/posix_types.h:4, from /scratch/sfr/next/include/uapi/linux/types.h:13, from /scratch/sfr/next/include/linux/types.h:5, from /scratch/sfr/next/include/linux/smp.h:10, from /scratch/sfr/next/include/linux/kernel_stat.h:4, from /scratch/sfr/next/mm/memory.c:41: In function '__read_once_size', inlined from 'handle_pte_fault' at /scratch/sfr/next/mm/memory.c:3192:10, inlined from '__handle_mm_fault' at /scratch/sfr/next/mm/memory.c:3324:2, inlined from 'handle_mm_fault' at /scratch/sfr/next/mm/memory.c:3353:6: /scratch/sfr/next/include/linux/compiler.h:206:3: warning: call to 'data_access_exceeds_word_size' declared with attribute warning: data access exceeds word size and won't be atomic data_access_exceeds_word_size(); ^ mm/built-in.o: In function `handle_mm_fault': (.text+0x283a0): undefined reference to `data_access_exceeds_word_size' I hate dropped the access_once tree again today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpt0RMw3npzW.pgp Description: OpenPGP digital signature
Re: Fastmap update v2 (pile 1)
On Mon, Nov 24, 2014 at 2:20 PM, Richard Weinberger wrote: > Artem, > > as requested I'm resending my fastmap work in smaller pieces. > This is pile 1 of 7. > Rebasing my patches to ubifs.git was a massive PITA because the > logging style changes touched a lot of code and almost every patch > failed to apply and needed inspection by hand. > The first patches are bug fixes, the latter introduce cleanups > and new features. > After all bugfixes are mainline I'll make sure that all needed > fixes go into -stable. Artem, how shall we proceed? Currently around 45 of my patches are in flight. Some got comments, some not. If it helps I can address these comments immediately and resend the individual patches. The vast majority of all comments are trivial to fix (typos, style, etc..) Initially I hoped that all patches will get comments such that I can do a v3 which can be merged in 3.19-rc1. :-\ In my local queue even more patches wait to be submitted. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
Hi Tomasz, On Mon, Dec 1, 2014 at 9:37 PM, Tomasz Figa wrote: > Hi Vivek, > > Please see my comments below. > > 2014-11-24 22:02 GMT+09:00 Vivek Gautam : >> USB and Power regulator on Exynos7 require gpios available >> in BUS1 pin controller block. >> So adding the BUS1 pinctrl support. >> >> Signed-off-by: Naveen Krishna Ch >> Signed-off-by: Vivek Gautam >> Cc: Linus Walleij >> --- >> >> This patch was part of series: >> "[PATCH 00/11] Exynos7: Adding USB 3.0 support" >> https://lkml.org/lkml/2014/11/21/247 >> >> Changes since V1: >> - Added support for all pin banks which are part of BUS1 pin controller. >> >> drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++ >> 1 file changed, 19 insertions(+) > > I have missed this with previous patch, but DT bindings documentation > should list all aliases for all supported compatible strings, because > they are required for correct operation. There is a small section > about aliases in [1] already, so please add there information about > aliases for Exynos7 pin controllers along with their names, e.g. > > Aliases for controllers compatible with "samsung,exynos7-pinctrl": > - pinctrl0: pin controller of ALIVE block, > - pinctrl1: pin controller of BUS0 block, > [...] > - pinctrl8: pin controller of BUS1 block. > > [1] Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt > > I guess you can do this in separate patch or respin this one with this added. Sure, i will add the aliases in a separate patch. I missed to update the patch in this cycle :-( So we can queue up the reworked version for 3.20. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: kprobes: Add test cases for stack consuming instructions
Hi Tixy,
I experienced another FAIL during test:
[11567.220477] Miscellaneous instructions
[11567.265397] -
[11567.342626] mrs r0, cpsr@ e10f
[11568.612656] FAIL: registers differ
[11568.653414] FAIL: Test mrs r0, cpsr
[11568.695210] FAIL: Scenario 5
[11568.729709] initial_regs:
[11568.761083] r0 21522152 | r1 21522052 | r2 21522352 | r3 21522252
[11568.838301] r4 21522552 | r5 21522452 | r6 21522752 | r7 21522652
[11568.915526] r8 21522952 | r9 21522852 | r10 21522b52 | r11 21522a52
[11568.992748] r12 21522d52 | sp ed343cf0 | lr 21522f52 | pc bf11f590
[11569.069969] cpsr 58050013
[11569.101336] expected_regs:
[11569.133750] r0 58050013 | r1 21522052 | r2 21522352 | r3 21522252
[11569.210975] r4 21522552 | r5 21522452 | r6 21522752 | r7 21522652
[11569.288197] r8 21522952 | r9 21522852 | r10 21522b52 | r11 21522a52
[11569.365417] r12 21522d52 | sp ed343cf0 | lr 21522f52 | pc bf11f594
[11569.442634] cpsr 58050013
[11569.474010] result_regs:
[11569.504337] r0 58050113 | r1 21522052 | r2 21522352 | r3 21522252
<--- see R0 in this line
[11569.581556] r4 21522552 | r5 21522452 | r6 21522752 | r7 21522652
[11569.658776] r8 21522952 | r9 21522852 | r10 21522b52 | r11 21522a52
[11569.736000] r12 21522d52 | sp ed343cf0 | lr 21522f52 | pc bf11f594
[11569.813222] cpsr 58050013
[11569.844593] mrsplr7, cpsr@ 510f7000
[11571.842652] mrs r14, cpsr @ e10fe000
The failure is raise when testing in "mrs r0, cpsr". The added bit is
PSR_A_BIT, which
should be ignored.
So looks like this is also a problem in your test framework. If you don't have
enough time, you can give me some hints to deal with it.
On 2014/12/10 1:11, Jon Medhurst (Tixy) wrote:
> These have extra 'checker' functions associated with them so lets make
> sure those get covered by testing. As they may create uninitialised
> space on the stack we also update the test code to ensure such space is
> consistent between test runs. This is done by disabling interrupts in
> setup_test_context().
>
> Signed-off-by: Jon Medhurst
> ---
>
> Sorry for the extra noise, sent this new version to correct whitespace
> and spelling errors in previous one.
>
> arch/arm/probes/kprobes/test-arm.c | 17 +++--
> arch/arm/probes/kprobes/test-core.c | 9 +
> arch/arm/probes/kprobes/test-thumb.c | 12
> 3 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/probes/kprobes/test-arm.c
> b/arch/arm/probes/kprobes/test-arm.c
> index fdeb300..9b3b1b4 100644
> --- a/arch/arm/probes/kprobes/test-arm.c
> +++ b/arch/arm/probes/kprobes/test-arm.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "test-core.h"
>
> @@ -478,6 +479,7 @@ void kprobe_arm_test_cases(void)
> TEST_RPR( "strhr",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
> TEST_RPR( "streqh r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
> TEST_UNSUPPORTED( "streqh r14, [r13, r12]")
> + TEST_UNSUPPORTED( "streqh r14, [r12, r13]")
> TEST_RPR( "strhr",1, VAL1,", [r",2, 24,", r",3, 48,"]!")
> TEST_RPR( "strneh r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
> TEST_RPR( "strhr",2, VAL1,", [r",3, 24,"], r",4, 48,"")
> @@ -502,6 +504,9 @@ void kprobe_arm_test_cases(void)
> TEST_RP( "strplh r",12,VAL2,", [r",11,24,", #-4]!")
> TEST_RP( "strhr",2, VAL1,", [r",3, 24,"], #48")
> TEST_RP( "strhr",10,VAL2,", [r",9, 64,"], #-48")
> + TEST_RP( "strhr",3, VAL1,", [r",13,TEST_MEMORY_SIZE,",
> #-"__stringify(MAX_STACK_SIZE)"]!")
> + TEST_UNSUPPORTED("strh r3, [r13, #-"__stringify(MAX_STACK_SIZE)"-8]!")
> + TEST_RP( "strhr",4, VAL1,", [r",14,TEST_MEMORY_SIZE,",
> #-"__stringify(MAX_STACK_SIZE)"-8]!")
> TEST_UNSUPPORTED(__inst_arm(0xe1efc3b0) " @ strh r12, [pc, #48]!")
> TEST_UNSUPPORTED(__inst_arm(0xe0c9f3b0) " @ strh pc, [r9], #48")
>
> @@ -568,6 +573,7 @@ void kprobe_arm_test_cases(void)
> TEST_RPR( "strdr",0, VAL1,", [r",1, 48,", -r",2,24,"]")
> TEST_RPR( "strccd r",8, VAL2,", [r",11,0, ", r",12,48,"]")
> TEST_UNSUPPORTED( "strccd r8, [r13, r12]")
> + TEST_UNSUPPORTED( "strccd r8, [r12, r13]")
> TEST_RPR( "strdr",4, VAL1,", [r",2, 24,", r",3, 48,"]!")
> TEST_RPR( "strcsd r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
> TEST_RPR( "strdr",2, VAL1,", [r",5, 24,"], r",4,48,"")
> @@ -591,6 +597,9 @@ void kprobe_arm_test_cases(void)
> TEST_RP( "strvcd r",12,VAL2,", [r",11,24,", #-16]!")
> TEST_RP( "strdr",2, VAL1,", [r",4, 24,"], #48")
> TEST_RP( "strdr",10,VAL2,", [r",9, 64,"], #-48")
> + TEST_RP( "strdr",6, VAL1,", [r",13,TEST_MEMORY_SIZE,",
> #-"__stringify(MAX_STACK_SIZE)"]!")
> + TEST_UNSUPP
Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr
Hi Joe, On 12/10/2014 02:56 PM, Joe Perches wrote: > On Wed, 2014-12-10 at 13:36 +0800, Gu Zheng wrote: >> Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating >> cmsghdr from msghdr, just cleanup. > > This looks nicer. > Ideally this would have used: [PATCH V3] as the subject Thanks for your review. The previous v2 thread was marked as mistake, so this is the really active v2 version. Regards, Gu > >> Signed-off-by: Gu Zheng >> --- >> v2: use the lower-case macro name as Joe suggested. > > And a description of the v2->v3 change here. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 03/15] of: Add vendor prefix for Truly Semiconductors Limited
Signed-off-by: Liu Ying --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 3cee528..8257f3a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -158,6 +158,7 @@ tlm Trusted Logic Mobility toradexToradex AG toshibaToshiba Corporation toumaz Toumaz +truly Truly Semiconductors Limited usiUniversal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 01/15] clk: divider: Correct parent clk round rate if no bestdiv is normally found
If no best divider is normally found, we will try to use the maximum divider.
We should not set the parent clock rate to be 1Hz by force for being rounded.
Instead, we should take the maximum divider as a base and calculate a correct
parent clock rate for being rounded.
Signed-off-by: Liu Ying
---
drivers/clk/clk-divider.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..f641d4b 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -311,7 +311,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned
long rate,
if (!bestdiv) {
bestdiv = _get_maxdiv(divider);
- *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
1);
+ *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
+ MULT_ROUND_UP(rate, bestdiv));
}
return bestdiv;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 08/15] ARM: imx6q: clk: Add the video_27m clock
This patch supports the video_27m clock which is a fixed factor
clock of the pll3_pfd1_540m clock.
Signed-off-by: Liu Ying
---
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e79da7..9470df3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -246,6 +246,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_PLL3_60M] = imx_clk_fixed_factor("pll3_60m",
"pll3_usb_otg", 1, 8);
clk[IMX6QDL_CLK_TWD] = imx_clk_fixed_factor("twd", "arm",
1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",
1, 8);
+ clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m",
"pll3_pfd1_540m", 1, 20);
if (cpu_is_imx6dl()) {
clk[IMX6QDL_CLK_GPU2D_AXI] = imx_clk_fixed_factor("gpu2d_axi",
"mmdc_ch0_axi_podf", 1, 1);
clk[IMX6QDL_CLK_GPU3D_AXI] = imx_clk_fixed_factor("gpu3d_axi",
"mmdc_ch0_axi_podf", 1, 1);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index b690cdb..25625bf 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -248,6 +248,7 @@
#define IMX6QDL_PLL6_BYPASS235
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
-#define IMX6QDL_CLK_END238
+#define IMX6QDL_CLK_VIDEO_27M 238
+#define IMX6QDL_CLK_END239
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 15/15] ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel
This patch adds support for Himax HX8369A panel. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the Himax HX8369A panel driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 3e0e589..01b2b89 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,6 +192,7 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_PANEL_HX8369A=y CONFIG_DRM_IMX=y CONFIG_DRM_IMX_FB_HELPER=y CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/6] virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1
On Tue, 9 Dec 2014 21:40:52 +0200 "Michael S. Tsirkin" wrote: > On Tue, Dec 09, 2014 at 06:23:19PM +0100, Cornelia Huck wrote: > > On Tue, 9 Dec 2014 14:21:18 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Tue, Dec 09, 2014 at 12:01:23PM +0100, Cornelia Huck wrote: > > > > On Mon, 8 Dec 2014 15:06:03 +0200 > > > > "Michael S. Tsirkin" wrote: > > > > > > > diff --git a/drivers/s390/kvm/virtio_ccw.c > > > > > b/drivers/s390/kvm/virtio_ccw.c > > > > > index 789275f..f9f87ba 100644 > > > > > --- a/drivers/s390/kvm/virtio_ccw.c > > > > > +++ b/drivers/s390/kvm/virtio_ccw.c > > > > > @@ -758,6 +758,13 @@ static int virtio_ccw_finalize_features(struct > > > > > virtio_device *vdev) > > > > > struct virtio_feature_desc *features; > > > > > struct ccw1 *ccw; > > > > This needs > > > > + struct virtio_device *vdev = &vcdev->vdev; > > > > to make it compile :) > > In fact why does it? > vdev is a parameter. Never mind, messed up tree on my side. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RESEND 0/2] fix rculist sparse errors
When hlist_for_each_entry_continue_rcu_bh() gets "next" pointer of hlist_node structure through rcu_dereference_bh(), sparse warning appears as the "next" pointer is not annotated as __rcu. So if the "next" pointer is accessed with hlist_next_rcu() macro, the __rcu annotation will be added to the pointer. As a consequence, sparse warning is eliminated too. The similar errors also appear in hlist_for_each_entry_continue_rcu() and hlist_for_each_entry_from_rcu(). In this version, CC more people like Paul E. McKenney and lkml mail list. Ying Xue (2): tipc: fix RCU sparse error ipv6: fix sparse warning include/linux/rculist.h | 20 ++-- net/tipc/name_table.c |6 +++--- 2 files changed, 13 insertions(+), 13 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RESEND 1/2] tipc: fix RCU sparse error
The commit 97ede29e80ee ("tipc: convert name table read-write lock to
RCU") involves the following sparse when using
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
net/tipc/name_table.c:1136:17: sparse: incompatible types in comparison
expression (different address spaces)
net/tipc/name_table.c:1136:17: sparse: incompatible types in comparison
expression (different address spaces)
To silence above spare complaint, an RCU annotation should be added
to "next" pointer of hlist_node structure through hlist_next_rcu()
macro when iterating over a hlist with hlist_for_each_entry_from_rcu().
By the way, this commit also simplifies the way of dereferencing
the first element of a hlist_head list by replacing
hlist_for_each_entry_rcu() with hlist_entry_safe().
Reported-by: Kbuild test robot
Cc: Kbuild test robot
Signed-off-by: Ying Xue
---
include/linux/rculist.h |4 ++--
net/tipc/name_table.c |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index aa79b3c..866d9c9 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -549,8 +549,8 @@ static inline void hlist_add_behind_rcu(struct hlist_node
*n,
*/
#define hlist_for_each_entry_from_rcu(pos, member) \
for (; pos; \
-pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\
- typeof(*(pos)), member))
+pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member))
#endif /* __KERNEL__ */
#endif
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index c8df022..fa4341f 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -1110,7 +1110,7 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg,
u32 *last_type,
u32 *last_lower, u32 *last_publ)
{
struct hlist_head *seq_head;
- struct name_seq *seq = NULL;
+ struct name_seq *seq;
int err;
int i;
@@ -1127,8 +1127,8 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg,
u32 *last_type,
if (!seq)
return -EPIPE;
} else {
- hlist_for_each_entry_rcu(seq, seq_head, ns_list)
- break;
+ seq = hlist_entry_safe(rcu_dereference_raw(
+ hlist_first_rcu(seq_head)), struct name_seq, ns_list);
if (!seq)
continue;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Vivek Gautam
Cc: Tomasz Figa
Cc: Linus Walleij
---
Changes since V2:
- Added documentation on alias for BUS1 pin controller block.
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
.../devicetree/bindings/pinctrl/samsung-pinctrl.txt |1 +
drivers/pinctrl/samsung/pinctrl-exynos.c| 19 +++
2 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 742e472..c88ba35 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -180,6 +180,7 @@ Aliases for controllers compatible with
"samsung,exynos7-pinctrl":
- pinctrl5: pin controller of ESE block,
- pinctrl6: pin controller of FSYS0 block,
- pinctrl7: pin controller of FSYS1 block,
+- pinctrl8: pin controller of BUS1 block,
Example: A pin-controller node with pin banks:
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
};
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
+ EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
+ EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
+ EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
+};
+
const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
__initconst = {
.pin_banks = exynos7_pin_banks7,
.nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 8 BUS1 data */
+ .pin_banks = exynos7_pin_banks8,
+ .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
+ .eint_gpio_init = exynos_eint_gpio_init,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers
Adding list of aliases for supported Exynos7 pin controller blocks.
Signed-off-by: Vivek Gautam
Cc: Tomasz Figa
Cc: Linus Walleij
---
.../devicetree/bindings/pinctrl/samsung-pinctrl.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 8425838..742e472 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -171,6 +171,16 @@ Aliases:
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
+Aliases for controllers compatible with "samsung,exynos7-pinctrl":
+- pinctrl0: pin controller of ALIVE block,
+- pinctrl1: pin controller of BUS0 block,
+- pinctrl2: pin controller of NFC block,
+- pinctrl3: pin controller of TOUCH block,
+- pinctrl4: pin controller of FF block,
+- pinctrl5: pin controller of ESE block,
+- pinctrl6: pin controller of FSYS0 block,
+- pinctrl7: pin controller of FSYS1 block,
+
Example: A pin-controller node with pin banks:
pinctrl_0: pinctrl@1140 {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 00/15] Add support for i.MX MIPI DSI DRM driver
Hi, This series adds support for i.MX MIPI DSI DRM driver. Currently, the MIPI DSI driver only supports the burst with sync pulse mode. This series also includes a DRM panel driver for the Truly TFT480800-16-E panel which is driven by the Himax HX8369A driver IC. The driver IC data sheet could be found at [1]. As mentioned by the data sheet, the driver IC supports several interface modes. Currently, the DRM panel driver only supports the MIPI DSI video mode. New interface modes could be added later(perhaps, just like the way the DRM simple panel driver supports both MIPI DSI interface panels and simple(parallel) interface panels). The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD board. The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after applying this series, because the 26.4MHz pixel clock the panel requires could be derived from the IPU HSP clock(264MHz) with an integer divider. On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI displays in the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, which makes the pixel clock share the PLL5 video clock source with the LVDS and HDMI, thus, the panel cannot get the pixel clock rate it wants. Patch 01/15 is needed to get a precise pixel clock rate(26.4MHz) from the PLL5 video clock. If we don't have this patch, the pixel clock rate is about 20MHz, which causes a horitonal shift on the display image. This series can be applied on the drm-next branch. [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf Liu Ying (15): clk: divider: Correct parent clk round rate if no bestdiv is normally found of: Add vendor prefix for Himax Technologies Inc. of: Add vendor prefix for Truly Semiconductors Limited drm/dsi: Do not add DSI devices for the child nodes with input-port property ARM: dts: imx6qdl: Add input-port property to MIPI DSI node's CTRC child nodes ARM: dts: imx6q: Add MIPI DSI remote end points for IPU2 DI0/1 end points ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition ARM: imx6q: clk: Add the video_27m clock drm: imx: Add MIPI DSI host controller driver drm: panel: Add support for Himax HX8369A MIPI DSI panel ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel .../devicetree/bindings/drm/imx/mipi_dsi.txt | 81 ++ .../devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt |4 + .../devicetree/bindings/panel/himax,hx8369a.txt| 86 ++ .../devicetree/bindings/vendor-prefixes.txt|2 + arch/arm/boot/dts/imx6q.dtsi |4 + arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 41 + arch/arm/boot/dts/imx6qdl.dtsi |9 + arch/arm/configs/imx_v6_v7_defconfig | 17 +- arch/arm/mach-imx/clk-imx6q.c |1 + drivers/clk/clk-divider.c |3 +- drivers/gpu/drm/drm_mipi_dsi.c |5 +- drivers/gpu/drm/imx/Kconfig|6 + drivers/gpu/drm/imx/Makefile |1 + drivers/gpu/drm/imx/imx-mipi-dsi.c | 1017 drivers/gpu/drm/panel/Kconfig |6 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-hx8369a.c | 627 include/dt-bindings/clock/imx6qdl-clock.h |3 +- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h|1 + 19 files changed, 1903 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt create mode 100644 drivers/gpu/drm/imx/imx-mipi-dsi.c create mode 100644 drivers/gpu/drm/panel/panel-hx8369a.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next RESEND 2/2] ipv6: fix sparse warning
This fixes the following spare warning when using make C=1 CF=-D__CHECK_ENDIAN__ net/ipv6/addrconf.o net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces) net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces) net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces) net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces) To silence above spare complaint, an RCU annotation should be added to "next" pointer of hlist_node structure through hlist_next_rcu() macro when iterating over a hlist with hlist_for_each_entry_continue_rcu_bh(). By the way, this commit also resolves the same error appearing in hlist_for_each_entry_continue_rcu(). Signed-off-by: Ying Xue --- include/linux/rculist.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/linux/rculist.h b/include/linux/rculist.h index 866d9c9..32bd4ad 100644 --- a/include/linux/rculist.h +++ b/include/linux/rculist.h @@ -524,11 +524,11 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n, * @member:the name of the hlist_node within the struct. */ #define hlist_for_each_entry_continue_rcu(pos, member) \ - for (pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\ - typeof(*(pos)), member);\ + for (pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \ + &(pos)->member)), typeof(*(pos)), member); \ pos; \ -pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\ - typeof(*(pos)), member)) +pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \ + &(pos)->member)), typeof(*(pos)), member)) /** * hlist_for_each_entry_continue_rcu_bh - iterate over a hlist continuing after current point @@ -536,11 +536,11 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n, * @member:the name of the hlist_node within the struct. */ #define hlist_for_each_entry_continue_rcu_bh(pos, member) \ - for (pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\ - typeof(*(pos)), member);\ + for (pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \ + &(pos)->member)), typeof(*(pos)), member); \ pos; \ -pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\ - typeof(*(pos)), member)) +pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \ + &(pos)->member)), typeof(*(pos)), member)) /** * hlist_for_each_entry_from_rcu - iterate over a hlist continuing from current point -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" for internal shared functions using
>-Original Message- >From: Chen Gang [mailto:gang.chen.5...@gmail.com] >Sent: Sunday, November 30, 2014 8:37 AM >To: Sumit Saxena >Cc: megaraidli...@lsi.com; linux-s...@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: Re: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" >for internal shared functions using > >On 11/17/14 19:51, Sumit Saxena wrote: >>> -Original Message- >>> From: Chen Gang [mailto:gang.chen.5...@gmail.com] >>> Sent: Monday, November 17, 2014 5:17 PM >>> To: Sumit Saxena >>> Cc: megaraidli...@lsi.com; linux-s...@vger.kernel.org; linux- >>> ker...@vger.kernel.org >>> Subject: RE: [PATCH] drivers: scsi: megaraid: Add >"megaraid_sas_internal.h" >>> for internal shared functions using >>> >>> >>> OK, I will send patch v2 for it. >>> >>> I sent this patch based on Linux next tree, please tell me the tree >>> location (git >>> address) which I shall base on for sending patch v2. >> >> I posted the patch series today, once the patches make it to scsi-next >> tree, I will let you know. >> > >Is it OK? or if possible, please help rebase and send the patch for it >based on >the related branches and patches. Sorry for delay in response, patch series sent by me is accepted at upstream. Please rebase "for-next" branch of scsi.git, here is git address of tree- git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git Please sent out patch v2, I will ACK. Thanks Sumit > >Thanks. >-- >Chen Gang > >Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 05/15] ARM: dts: imx6qdl: Add input-port property to MIPI DSI node's CTRC child nodes
To phase out the MIPI DSI's child nodes which present DRM CRTCs from the
child nodes which represent MIPI DSI peripherals, we need to add input-port
property to the child nodes to be phased out.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6q.dtsi | 2 ++
arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9f3646..e6a6d90 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -294,6 +294,7 @@
&mipi_dsi {
port@2 {
reg = <2>;
+ input-port;
mipi_mux_2: endpoint {
remote-endpoint = <&ipu2_di0_mipi>;
@@ -302,6 +303,7 @@
port@3 {
reg = <3>;
+ input-port;
mipi_mux_3: endpoint {
remote-endpoint = <&ipu2_di1_mipi>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9596ed5..5d92ad7 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1011,6 +1011,7 @@
port@0 {
reg = <0>;
+ input-port;
mipi_mux_0: endpoint {
remote-endpoint =
<&ipu1_di0_mipi>;
@@ -1019,6 +1020,7 @@
port@1 {
reg = <1>;
+ input-port;
mipi_mux_1: endpoint {
remote-endpoint =
<&ipu1_di1_mipi>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Joerg, ZhenHua, This issue happens on AMD iommu too, do you have any plans or thoughts on that? Thanks Baoquan On 11/17/14 at 02:38pm, Joerg Roedel wrote: > On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: > > I am working following your directions: > > > > 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry > > table, and do NOT disable-enable iommu. Other data will be copied. > > > > 2. When a device driver issues the first dma_map command for a > > device, we assign a new and empty page-table, thus removing all > > mappings from the old kernel for the device. > > > > Please let me know if I get something wrong. > > Yes, this sounds right. Happily waiting for patches :) > > > Joerg > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 14/15] ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the MIPI DSI host controller driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0dbd0c3..3e0e589 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -199,6 +199,7 @@ CONFIG_DRM_IMX_TVE=y CONFIG_DRM_IMX_LDB=y CONFIG_DRM_IMX_IPUV3=y CONFIG_DRM_IMX_HDMI=y +CONFIG_DRM_IMX_MIPI_DSI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 11/15] ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 5d92ad7..4769767 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1006,7 +1006,14 @@
mipi_dsi: mipi@021e {
#address-cells = <1>;
#size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX6QDL_CLK_VIDEO_27M>,
+<&clks IMX6QDL_CLK_HSI_TX>,
+<&clks IMX6QDL_CLK_HSI_TX>;
+ clock-names = "pllref", "pllref_gate",
"core_cfg";
status = "disabled";
port@0 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 02/15] of: Add vendor prefix for Himax Technologies Inc.
Signed-off-by: Liu Ying --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 78efebb..3cee528 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -69,6 +69,7 @@ hannstar HannStar Display Corporation haoyu Haoyu Microelectronic Co. Ltd. hisilicon Hisilicon Limited. hitHitachi Ltd. +himax Himax Technologies, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 04/15] drm/dsi: Do not add DSI devices for the child nodes with input-port property
The MIPI DSI bus driver would try to add a DSI device for a host's every
child node which contains the reg property. Unfortunately, the existing
i.MX6Q/SDL MIPI DSI host device tree node's child nodes contain the reg
property, but the child nodes are ports pointing to dedicated CRTCs.
So, this patch phases out the child nodes with input-port property before
adding DSI devices for them and updates the MIPI DSI bus OF binding
documentation.
Signed-off-by: Liu Ying
---
Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 4
drivers/gpu/drm/drm_mipi_dsi.c | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
index 973c272..1a1d3c1 100644
--- a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
@@ -36,6 +36,10 @@ Peripherals are represented as child nodes of the DSI host's
node. Properties
described here apply to all DSI peripherals, but individual bindings may want
to define additional, device-specific properties.
+Please, do not add the input-port property to the child nodes which represent
+peripherals. Otherwise, the peripherals would be omitted by the MIPI DSI bus
+driver.
+
Required properties:
- reg: The virtual channel number of a DSI peripheral. Must be in the range
from 0 to 3.
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index c0644bb..9adacfe 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -176,8 +176,9 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
struct device_node *node;
for_each_available_child_of_node(host->dev->of_node, node) {
- /* skip nodes without reg property */
- if (!of_find_property(node, "reg", NULL))
+ /* skip nodes without reg property or with input-port property
*/
+ if (!of_find_property(node, "reg", NULL) ||
+of_find_property(node, "input-port", NULL))
continue;
of_mipi_dsi_device_add(host, node);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 10/15] drm: panel: Add support for Himax HX8369A MIPI DSI panel
This patch adds support for Himax HX8369A MIPI DSI panel.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/panel/himax,hx8369a.txt| 86 +++
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-hx8369a.c | 627 +
4 files changed, 720 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt
create mode 100644 drivers/gpu/drm/panel/panel-hx8369a.c
diff --git a/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
new file mode 100644
index 000..6fe251e
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
@@ -0,0 +1,86 @@
+Himax HX8369A WVGA 16.7M color TFT single chip driver with internal GRAM
+
+Himax HX8369A is a WVGA resolution driving controller.
+It is designed to provide a single chip solution that combines a source
+driver and power supply circuits to drive a TFT dot matrix LCD with
+480RGBx864 dots at the maximum.
+
+The HX8369A supports several interface modes, including MPU MIPI DBI Type
+A/B mode, MIPI DPI/DBI Type C mode, MIPI DSI video mode, MIPI DSI command
+mode and MDDI mode. The interface mode is selected by the external hardware
+pins BS[3:0].
+
+Currently, only the MIPI DSI video mode is supported.
+
+Required properties:
+ - compatible: "himax,hx8369a-dsi"
+ - reg: the virtual channel number of a DSI peripheral
+ - reset-gpios: a GPIO spec for the reset pin
+ - data-lanes: the data lane number of a DSI peripheral
+ - display-timings: timings for the connected panel as described by [1]
+ - bs: the interface mode number described by the following table
+--
+ | DBI_TYPE_A_8BIT | 0 |
+ | DBI_TYPE_A_9BIT | 1 |
+ | DBI_TYPE_A_16BIT| 2 |
+ | DBI_TYPE_A_18BIT| 3 |
+ | DBI_TYPE_B_8BIT | 4 |
+ | DBI_TYPE_B_9BIT | 5 |
+ | DBI_TYPE_B_16BIT| 6 |
+ | DBI_TYPE_B_18BIT| 7 |
+ | DSI_CMD_MODE| 8 |
+ | DBI_TYPE_B_24BIT| 9 |
+ | DSI_VIDEO_MODE | 10 |
+ | MDDI| 11 |
+ | DPI_DBI_TYPE_C_OPT1 | 12 |
+ | DPI_DBI_TYPE_C_OPT2 | 13 |
+ | DPI_DBI_TYPE_C_OPT3 | 14 |
+--
+
+Optional properties:
+ - power-on-delay: delay after turning regulators on [ms]
+ - reset-delay: delay after reset sequence [ms]
+ - vdd1-supply: I/O and interface power supply
+ - vdd2-supply: analog power supply
+ - vdd3-supply: logic power supply
+ - dsi-vcc-supply: DSI and MDDI power supply
+ - vpp-supply: OTP programming voltage
+ - bs0-gpios: a GPIO spec for the pin BS0
+ - bs1-gpios: a GPIO spec for the pin BS1
+ - bs2-gpios: a GPIO spec for the pin BS2
+ - bs3-gpios: a GPIO spec for the pin BS3
+ - panel-width-mm: physical panel width [mm]
+ - panel-height-mm: physical panel height [mm]
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+ panel@0 {
+ compatible = "himax,hx8369a-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mipi_panel>;
+ reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ reset-delay = <120>;
+ bs2-gpios = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ data-lanes = <2>;
+ panel-width-mm = <45>;
+ panel-height-mm = <76>;
+ bs = <10>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: truly-tft480800-16-e {
+ clock-frequency = <2640>;
+ hactive = <480>;
+ vactive = <800>;
+ hfront-porch = <8>;
+ hback-porch = <8>;
+ hsync-len = <8>;
+ vfront-porch = <6>;
+ vback-porch = <6>;
+ vsync-len = <6>;
+ };
+ };
+};
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 024e98e..f1a5b58 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -40,4 +40,10 @@ config DRM_PANEL_SHARP_LQ101R1SX01
To compile this driver as a module, choose M here: the module
will be called panel-sharp-lq101r1sx01.
+config DRM_PANEL_HX8369A
+ tristate "HX8369A panel"
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..d6768ca 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_P
[PATCH RFC 07/15] ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition
This patch adds a macro to define the GPR3 MIPI muxing control register field shift bits. Signed-off-by: Liu Ying --- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h index ff44374..3b0bed4 100644 --- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h +++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h @@ -207,6 +207,7 @@ #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU1_DI1 (0x1 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI0 (0x2 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI1 (0x3 << 6) +#define IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT 4 #define IMX6Q_GPR3_MIPI_MUX_CTL_MASK (0x3 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI0 (0x0 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI1 (0x1 << 4) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 06/15] ARM: dts: imx6q: Add MIPI DSI remote end points for IPU2 DI0/1 end points
This patch adds MIPI DSI remote end points for IPU2 DI0/1 end points.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6q.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e6a6d90..82507e7 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -185,6 +185,7 @@
};
ipu2_di0_mipi: endpoint@2 {
+ remote-endpoint = <&mipi_mux_2>;
};
ipu2_di0_lvds0: endpoint@3 {
@@ -206,6 +207,7 @@
};
ipu2_di1_mipi: endpoint@2 {
+ remote-endpoint = <&mipi_mux_3>;
};
ipu2_di1_lvds0: endpoint@3 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 12/15] ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel
The TRULY TFT480800-16-E panel is driven by the Himax HX8369A driver IC.
The driver IC supports several display/control interface modes, including
the MIPI DSI video mode and command mode.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index baf2f00..483aa5f 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -482,6 +482,13 @@
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
+
+ pinctrl_mipi_panel: mipipanelgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ >;
+ };
};
gpio_leds {
@@ -518,6 +525,40 @@
};
};
+&mipi_dsi {
+ status = "okay";
+
+ panel@0 {
+ compatible = "himax,hx8369a-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mipi_panel>;
+ reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ reset-delay = <120>;
+ bs2-gpios = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ data-lanes = <2>;
+ panel-width-mm = <45>;
+ panel-height-mm = <76>;
+ bs = <10>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: truly-tft480800-16-e {
+ clock-frequency = <2640>;
+ hactive = <480>;
+ vactive = <800>;
+ hfront-porch = <8>;
+ hback-porch = <8>;
+ hsync-len = <8>;
+ vfront-porch = <6>;
+ vback-porch = <6>;
+ vsync-len = <6>;
+ };
+ };
+ };
+};
+
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 09/15] drm: imx: Add MIPI DSI host controller driver
This patch adds i.MX MIPI DSI host controller driver support.
Currently, the driver supports the burst with sync pulses mode only.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/drm/imx/mipi_dsi.txt | 81 ++
drivers/gpu/drm/imx/Kconfig|6 +
drivers/gpu/drm/imx/Makefile |1 +
drivers/gpu/drm/imx/imx-mipi-dsi.c | 1017
4 files changed, 1105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
create mode 100644 drivers/gpu/drm/imx/imx-mipi-dsi.c
diff --git a/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
new file mode 100644
index 000..3d07fd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
@@ -0,0 +1,81 @@
+Device-Tree bindings for MIPI DSI host controller
+
+MIPI DSI host controller
+
+
+The MIPI DSI host controller is a Synopsys DesignWare IP.
+It is a digital core that implements all protocol functions defined
+in the MIPI DSI specification, providing an interface between the
+system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells : Should be <1>.
+ - #size-cells : Should be <0>.
+ - compatible : Should be "fsl,imx6q-mipi-dsi" for i.MX6q/sdl SoCs.
+ - reg : Physical base address of the controller and length of memory
+ mapped region.
+ - interrupts : The controller's interrupt number to the CPU(s).
+ - gpr : Should be <&gpr>.
+ The phandle points to the iomuxc-gpr region containing the
+ multiplexer control register for the controller.
+ - clocks, clock-names : Phandles to the controller pllref, pllref_gate
+ and core_cfg clocks, as described in [1] and [2].
+ - panel@0 : A panel node which contains a display-timings child node as
+ defined in [3].
+ - port@[0-4] : Up to four port nodes with endpoint definitions as defined
+ in [4], corresponding to the four inputs to the controller multiplexer.
+ Note that each port node should contain the input-port property to
+ distinguish it from the panel node, as described in [5].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/imx6q-clock.txt
+[3] Documentation/devicetree/bindings/video/display-timing.txt
+[4] Documentation/devicetree/bindings/media/video-interfaces.txt
+[5] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX6QDL_CLK_VIDEO_27M>,
+<&clks IMX6QDL_CLK_HSI_TX>,
+<&clks IMX6QDL_CLK_HSI_TX>;
+ clock-names = "pllref", "pllref_gate", "core_cfg";
+
+ port@0 {
+ reg = <0>;
+ input-port;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <&ipu1_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ input-port;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <&ipu1_di1_mipi>;
+ };
+ };
+
+ panel@0 {
+ compatible = "himax,hx8369a-dsi";
+ reg = <0>;
+ /* ... */
+
+ display-timings {
+ /* ... */
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 82fb758..03f04fb 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -51,3 +51,9 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
Choose this if you want to use HDMI on i.MX6.
+
+config DRM_IMX_MIPI_DSI
+ tristate "Freescale i.MX DRM MIPI DSI"
+ depends on DRM_IMX && MFD_SYSCON
+ help
+ Choose this if you want to use MIPI DSI on i.MX6.
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..4571d52 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o
obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_MIPI_DSI) += imx-mipi-dsi.o
diff --git a/drivers/gpu/drm/imx/imx-mipi-dsi.c
b/drivers/gpu/drm/imx/imx-mipi-dsi.c
[PATCH RFC 13/15] ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging
The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- arch/arm/configs/imx_v6_v7_defconfig | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 6790f1b..0dbd0c3 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,7 +192,13 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y -CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_DRM_IMX=y +CONFIG_DRM_IMX_FB_HELPER=y +CONFIG_DRM_IMX_PARALLEL_DISPLAY=y +CONFIG_DRM_IMX_TVE=y +CONFIG_DRM_IMX_LDB=y +CONFIG_DRM_IMX_IPUV3=y +CONFIG_DRM_IMX_HDMI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y @@ -249,13 +255,6 @@ CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y CONFIG_FSL_EDMA=y CONFIG_STAGING=y -CONFIG_DRM_IMX=y -CONFIG_DRM_IMX_FB_HELPER=y -CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -CONFIG_DRM_IMX_TVE=y -CONFIG_DRM_IMX_LDB=y -CONFIG_DRM_IMX_IPUV3=y -CONFIG_DRM_IMX_HDMI=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_PWM=y CONFIG_PWM_IMX=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" for internal shared functions using
On 12/10/14 16:47, Sumit Saxena wrote: >> From: Chen Gang [mailto:gang.chen.5...@gmail.com] >> Sent: Sunday, November 30, 2014 8:37 AM >> >> Is it OK? or if possible, please help rebase and send the patch for it >> based on >> the related branches and patches. > Sorry for delay in response, patch series sent by me is accepted at > upstream. Please rebase "for-next" branch of scsi.git, here is git address > of tree- > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git > > Please sent out patch v2, I will ACK. > OK, thanks, I shall try to send patch v2 within this week (2014-12-14). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/ethernet/chelsio/cxgb4vf/built-in.o:(.opd+0x630): multiple
definition of `t4_bar2_sge_qregs'
drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.opd+0x14d0): first defined here
drivers/net/ethernet/chelsio/cxgb4vf/built-in.o: In function
`.t4_bar2_sge_qregs':
(.text+0x9220): multiple definition of `.t4_bar2_sge_qregs'
drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.text+0x24e24): first defined
here
Caused by commit e85c9a7abfa4 ("cxgb4/cxgb4vf: Add code to calculate T5
BAR2 Offsets for SGE Queue Registers") which added both versions. :-(
I have applied this fir patch for today (including the subject
typo :-)):
From: Stephen Rothwell
Date: Wed, 10 Dec 2014 19:48:02 +1100
Subject: [PATCH] cxgb4/cxgb4vf: global named must be unique
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++--
drivers/net/ethernet/chelsio/cxgb4/sge.c| 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 2c37e1bf253a..a18d33fdb271 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1007,7 +1007,7 @@ int t4_prep_fw(struct adapter *adap, struct fw_info
*fw_info,
int t4_prep_adapter(struct adapter *adapter);
enum t4_bar2_qtype { T4_BAR2_QTYPE_EGRESS, T4_BAR2_QTYPE_INGRESS };
-int t4_bar2_sge_qregs(struct adapter *adapter,
+int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter,
unsigned int qid,
enum t4_bar2_qtype qtype,
u64 *pbar2_qoffset,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c8c5b3d36d4e..1645f59648f0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3815,7 +3815,7 @@ int cxgb4_bar2_sge_qregs(struct net_device *dev,
u64 *pbar2_qoffset,
unsigned int *pbar2_qid)
{
- return t4_bar2_sge_qregs(netdev2adap(dev),
+ return cxgb4_t4_bar2_sge_qregs(netdev2adap(dev),
qid,
(qtype == CXGB4_BAR2_QTYPE_EGRESS
? T4_BAR2_QTYPE_EGRESS
@@ -4011,7 +4011,7 @@ static void process_db_drop(struct work_struct *work)
unsigned int bar2_qid;
int ret;
- ret = t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
+ ret = cxgb4_t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
&bar2_qoffset, &bar2_qid);
if (ret)
dev_err(adap->pdev_dev, "doorbell drop recovery: "
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index f12debd98dac..ebf935a1e352 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2270,7 +2270,7 @@ static void __iomem *bar2_address(struct adapter *adapter,
u64 bar2_qoffset;
int ret;
- ret = t4_bar2_sge_qregs(adapter, qid, qtype,
+ ret = cxgb4_t4_bar2_sge_qregs(adapter, qid, qtype,
&bar2_qoffset, pbar2_qid);
if (ret)
return NULL;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 67345c73e570..28d04153f999 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4031,7 +4031,7 @@ int t4_prep_adapter(struct adapter *adapter)
}
/**
- * t4_bar2_sge_qregs - return BAR2 SGE Queue register information
+ * cxgb4_t4_bar2_sge_qregs - return BAR2 SGE Queue register information
* @adapter: the adapter
* @qid: the Queue ID
* @qtype: the Ingress or Egress type for @qid
@@ -4055,7 +4055,7 @@ int t4_prep_adapter(struct adapter *adapter)
* Write Combining Doorbell Buffer. If the BAR2 Queue ID is not 0,
* then these "Inferred Queue ID" register may not be used.
*/
-int t4_bar2_sge_qregs(struct adapter *adapter,
+int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter,
unsigned int qid,
enum t4_bar2_qtype qtype,
u64 *pbar2_qoffset,
--
2.1.3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpppvuyRlZio.pgp
Description: OpenPGP digital signature
Re: [PATCH v13 09/12] input: cyapa: add gen5 trackpad device firmware update function support
Dudley, On Tue, Dec 09, 2014 at 07:33:03PM -0800, Jeremiah Mahler wrote: > Dudley, > > On Tue, Dec 09, 2014 at 05:11:41PM +0800, Dudley Du wrote: > > Add firmware image update function supported for gen5 trackpad device, > > it can be used through sysfs update_fw interface. > > TEST=test on Chromebooks. > > > > Signed-off-by: Dudley Du > > --- > > drivers/input/mouse/Kconfig | 2 +- > > drivers/input/mouse/cyapa_gen5.c | 290 > > +++ > > 2 files changed, 291 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig > > index d8b46b0..63e8b40 100644 > > --- a/drivers/input/mouse/Kconfig > > +++ b/drivers/input/mouse/Kconfig > > @@ -205,7 +205,7 @@ config MOUSE_BCM5974 > > > > config MOUSE_CYAPA > > tristate "Cypress APA I2C Trackpad support" > > - depends on I2C > > + depends on I2C && CRC_ITU_T If this line is instead changed to: + depends on I2C + select CRC_ITU_T It will upgrade correctly during make oldconfig without removing MOUSE_CYAPA. And it looks like several other Kconfig files do it this way already. linux-next$ grep -r CRC_ITU_T $(find ./ -name Kconfig) > > help > > This driver adds support for Cypress All Points Addressable (APA) > > I2C Trackpads, including the ones used in 2012 Samsung Chromebooks. > > diff --git a/drivers/input/mouse/cyapa_gen5.c > > b/drivers/input/mouse/cyapa_gen5.c > > My initial config had MOUSE_CYAPA=m and CRC_ITU_T=n. > I did a 'make oldconfig', no questions were asked, but it removed > MOUSE_CYAPA since CRC_ITU_T wasn't enabled. Since the cyapa modules > were removed the touchpad no longer works. Not a very good upgrade path :-( > To fix this I have to manually enable MOUSE_CYAPA and CRC_ITU_T to get > it working again. > > [...] > > -- > - Jeremiah Mahler -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] s390 patches for the 3.19 merge window
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: The most notable change for this pull request is the ftrace rework from Heiko. It brings a small performance improvement and the ground work to support a new gcc option to replace the mcount blocks with a single nop. Two new s390 specific system calls are added to emulate user space mmio for PCI, an artifact of the how PCI memory is accessed. Two patches for the memory management with changes to common code. For KVM mm_forbids_zeropage is added which disables the empty zero page for an mm that is used by a KVM process. And an optimization, pmdp_get_and_clear_full is added analog to ptep_get_and_clear_full. Some micro optimization for the cmpxchg and the spinlock code. And as usual bug fixes and cleanups. Alexey Ishchuk (1): s390/kernel: add system calls for PCI memory access Christian Borntraeger (1): s390/debug: avoid function call for debug_sprintf_* Dominik Dingel (5): s390/mm: recfactor global pgste updates mm: introduce mm_forbids_zeropage function s390/mm: prevent and break zero page mappings in case of storage keys s390/mm: disable KSM for storage key enabled pages s390/mm: missing pte for gmap_ipte_notify should trigger a VM_BUG Frank Blaschka (1): s390/io: add ioport_map stubs Frederic Weisbecker (2): s390/idle: convert open coded idle time seqcount s390: translate cputime magic constants to macros Heiko Carstens (9): kprobes: introduce weak arch_check_ftrace_location() helper function s390/ftrace,kprobes: allow to patch first instruction s390/kprobes: make use of NOKPROBE_SYMBOL() s390/traps: print interrupt code and instruction length code s390/traps: die on translation exceptions s390/ftrace: provide working ftrace_return_address() s390: remove diag 44 calls from cpu_relax() s390/kprobes: fix instruction copy for out of line execution s390/idle: add missing irq off lockdep annotation Hendrik Brueckner (1): s390/cpum_sf: Remove initialization of PMU event index Markus Elfring (1): s390/pci: Deletion of unnecessary checks before the function call "debug_unregister" Martin Schwidefsky (12): s390/mm: pmdp_get_and_clear_full optimization s390/cmpxchg: use compiler builtins s390/pci: add sparse annotations s390/mm: use correct unlock function in gmap_ipte_notify s390/signal: add sparse annotations s390: fix ptrace of user area if the inferior uses vector registers s390/sclp_async: add Kconfig option to specify the component id s390/simd: clear vector register pointer on fork/clone s390/ptrace: always include vector registers in core files s390: use local symbol names in entry[64].S s390/mm: fix memory leak of ptlock in pmd_free_tlb s390/cputime: fix 31-bit compile Sebastian Ott (7): s390/pci: improve irq number check for msix s390/irq: use irq 0 s390/eadm: change timeout value s390/scm_block: use mempool to manage aidaw requests s390/scm_block: allocate aidaw pages only when necessary s390/scm_block: handle multiple requests in one HW request s390/scm_block: make the number of reqs per HW req configurable Stefan Haberland (4): s390/dasd: remove unused code s390/dasd: fix infinite term I/O loop s390/dasd: fix list corruption for sleep_on requests s390/dasd: retry partition detection Thomas Huth (2): s390/docs: Fix the documentation of the address spaces s390/docs: Remove sections that are not related to s390 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 8/9] ARM: SoC defconfig changes for 3.19
Hi Arnd,
On Tue, Dec 9, 2014 at 10:43 PM, Arnd Bergmann wrote:
> The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
>
> Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
> tags/defconfig-for-linus
On https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/, the
"Download" column for all tags shows "tag ...".
Clicking on any of them gives e.g.:
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tag/?id=066ae43e621090340384ab3751b68306c49cd503
Bad tag reference: 066ae43e621090340384ab3751b68306c49cd503
In other repositories
(e.g. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/), the
"Download" column for tags shows "commit ...", and the links behind
them do work.
Note that if I s/tag/commit/ in the URL, it does work.
Is this an issue with your repository? Or does cgit on kernel.org needs to
be updated for a new feature?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 0/2] Enable Quark X1000 support in gpio-sch
On Mon, Dec 8, 2014 at 6:38 PM, Chang Rebecca Swee Fun wrote: > Hi all, > > This is a revised version for enabling Quark X1000 support in gpio-sch. > This version of patch series had changed according to the feedback provided > by Alexandre and Linus. > > Change log for V5: > Patch 1: > - Change variable curr_dirs to reg_val in order to make driver code easier to > understand. > > Patch 3: > - Dropped patch 3 for now. We need to re-design the driver's IRQ > implementation. > > The patches need to be patched on top of Mika Westerberg's commit at: > gpio: sch: Consolidate core and resume banks > http://marc.info/?l=linux-kernel&m=141392647225885&w=2 > > The patches has been verifed and tested working on Galileo Board. GPIO sysfs > was able to export gpio pins and changing pin direction. GPIO values were > able to controlled. One of the GPIO pins which is connected to on-board LED > was used to test GPIO functionality. We are able to turn the LED on/off by > changing the pin direction and pin value. I think these patches are good to go, if Linus is ok with it. Nice job making this driver simpler and more legible. Looking forward to seeing the IRQ implementation! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V3 PATCH 4/4] scsi:stex.c Add S3/S4 support
On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote:
> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001
> From: Charles Chiou
> Date: Fri, 7 Nov 2014 10:15:18 +0800
> Subject: [PATCH 4/4] scsi:stex.c Add S3/S4 support
>
> Add S3/S4 support, add .suspend and .resume function in pci_driver.
>
> Pegasus need 30~40 seconds to boot up. We don't want to OS wait
> in .resume function. Create a thread to handle device boot up.
>
> +static int stex_resume(struct pci_dev *pdev)
> +{
> + struct st_hba *hba = pci_get_drvdata(pdev);
> + struct hba_handshake_workstruct *hswork;
> + int sts;
> +
> + hba->mu_status = MU_STATE_STARTING;
> + hswork = kzalloc(sizeof(struct hba_handshake_workstruct), GFP_KERNEL);
The system is coming back from sleep. You cannot swap or page out
as disks may still be asleep. GFP_KERNEL is automatically changed
to GFP_NOIO. It would be nice to outright use GFP_NOIO.
> + INIT_WORK(&hswork->handshake_work, resume_handshake);
Memory allocations can fail.
I suggest you allocate the memory in suspend(). There you can just
return -ENOMEM in the error case.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] s390 patches for the 3.19 merge window, 2nd try with diffstat
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: The most notable change for this pull request is the ftrace rework from Heiko. It brings a small performance improvement and the ground work to support a new gcc option to replace the mcount blocks with a single nop. Two new s390 specific system calls are added to emulate user space mmio for PCI, an artifact of the how PCI memory is accessed. Two patches for the memory management with changes to common code. For KVM mm_forbids_zeropage is added which disables the empty zero page for an mm that is used by a KVM process. And an optimization, pmdp_get_and_clear_full is added analog to ptep_get_and_clear_full. Some micro optimization for the cmpxchg and the spinlock code. And as usual bug fixes and cleanups. Alexey Ishchuk (1): s390/kernel: add system calls for PCI memory access Christian Borntraeger (1): s390/debug: avoid function call for debug_sprintf_* Dominik Dingel (5): s390/mm: recfactor global pgste updates mm: introduce mm_forbids_zeropage function s390/mm: prevent and break zero page mappings in case of storage keys s390/mm: disable KSM for storage key enabled pages s390/mm: missing pte for gmap_ipte_notify should trigger a VM_BUG Frank Blaschka (1): s390/io: add ioport_map stubs Frederic Weisbecker (2): s390/idle: convert open coded idle time seqcount s390: translate cputime magic constants to macros Heiko Carstens (9): kprobes: introduce weak arch_check_ftrace_location() helper function s390/ftrace,kprobes: allow to patch first instruction s390/kprobes: make use of NOKPROBE_SYMBOL() s390/traps: print interrupt code and instruction length code s390/traps: die on translation exceptions s390/ftrace: provide working ftrace_return_address() s390: remove diag 44 calls from cpu_relax() s390/kprobes: fix instruction copy for out of line execution s390/idle: add missing irq off lockdep annotation Hendrik Brueckner (1): s390/cpum_sf: Remove initialization of PMU event index Markus Elfring (1): s390/pci: Deletion of unnecessary checks before the function call "debug_unregister" Martin Schwidefsky (12): s390/mm: pmdp_get_and_clear_full optimization s390/cmpxchg: use compiler builtins s390/pci: add sparse annotations s390/mm: use correct unlock function in gmap_ipte_notify s390/signal: add sparse annotations s390: fix ptrace of user area if the inferior uses vector registers s390/sclp_async: add Kconfig option to specify the component id s390/simd: clear vector register pointer on fork/clone s390/ptrace: always include vector registers in core files s390: use local symbol names in entry[64].S s390/mm: fix memory leak of ptlock in pmd_free_tlb s390/cputime: fix 31-bit compile Sebastian Ott (7): s390/pci: improve irq number check for msix s390/irq: use irq 0 s390/eadm: change timeout value s390/scm_block: use mempool to manage aidaw requests s390/scm_block: allocate aidaw pages only when necessary s390/scm_block: handle multiple requests in one HW request s390/scm_block: make the number of reqs per HW req configurable Stefan Haberland (4): s390/dasd: remove unused code s390/dasd: fix infinite term I/O loop s390/dasd: fix list corruption for sleep_on requests s390/dasd: retry partition detection Thomas Huth (2): s390/docs: Fix the documentation of the address spaces s390/docs: Remove sections that are not related to s390 Documentation/s390/Debugging390.txt | 462 +-- arch/s390/include/asm/cmpxchg.h | 240 ++ arch/s390/include/asm/cputime.h | 46 ++-- arch/s390/include/asm/debug.h| 29 ++- arch/s390/include/asm/ftrace.h | 54 +++- arch/s390/include/asm/idle.h | 3 +- arch/s390/include/asm/io.h | 9 + arch/s390/include/asm/irq.h | 11 +- arch/s390/include/asm/kprobes.h | 1 + arch/s390/include/asm/lowcore.h | 4 +- arch/s390/include/asm/pci.h | 5 +- arch/s390/include/asm/pci_io.h | 6 +- arch/s390/include/asm/pgalloc.h | 2 - arch/s390/include/asm/pgtable.h | 33 ++- arch/s390/include/asm/processor.h| 2 - arch/s390/include/asm/spinlock.h | 9 +- arch/s390/include/asm/tlb.h | 1 + arch/s390/include/uapi/asm/unistd.h | 4 +- arch/s390/kernel/asm-offsets.c | 5 +- arch/s390/kernel/compat_signal.c | 2 +- arch/s390/kernel/compat_wrapper.c| 2 + arch/s390/kernel/debug.c | 12 +- arch/s390/kernel/dumpstack.c | 3 +- arch/s390/kernel/early.c | 4 - arch/s390/kernel/entry.S | 424 arch/s39
Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
Dexuan Cui writes: > Thanks, > -- Dexuan > >> -Original Message- >> From: Dexuan Cui >> Sent: Wednesday, December 10, 2014 15:34 PM >> To: 'Vitaly Kuznetsov' >> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- >> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; >> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang >> Subject: RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work >> >> > -Original Message- >> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> > Sent: Tuesday, December 9, 2014 21:06 PM >> > To: Dexuan Cui >> > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- >> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; >> > jasow...@redhat.com; KY Srinivasan; Haiyang Zhang >> > Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work >> > .. >> > > + * Here "dhcp_enabled" is only for IPv4 according to Hyper-V >> > > host >> > team. >> > > + * >> > > + * In the case the host only injects 1 IPv6 address: >> > > + * new_val->dhcp_enabled is true, but we can't pass >> > BOOTPROTO=dhcp to >> > > + * the script hv_set_ifconfig, because in some distros (like >> > > RHEL7) >> > > + * BOOTPROTO=dhcp has a special meaning in the config file >> > > (e.g., >> > > + * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init >> > program >> > > + * ignores any static IP addr information once there is >> > > + * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work. >> > > + * >> > > + * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't >> > > affect >> > > + * Ubuntu because it's ignored by the Ubuntu version of >> > > + * hv_set_ifconfig and it doesn't seem to have special meaning >> > > in >> > > + * Ubuntu. >> > > + */ >> > >> > I just checked and adding "IPV6ADDR=something" when >> "BOOTPROTO=dhcp" >> > works for me with both RHEL7 and Fedora21. >> It doesn't work in my side. :-( >> Running 'ifup eth0' shows some errors(I use "set -x") >> ... >> + /sbin/dhclient -H localhost -1 -q -lf >> /var/lib/dhclient/dhclient--eth0.lease -pf >> /var/run/dhclient-eth0.pid eth0 >> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied. > BTW, I run with root, and > 'chown 777 /etc/sysconfig/network-scripts/ifcfg-eth0" doesn't help. > s,chown,chmod, :-) But it won't help in case of SELinux mislabeling. > Thanks, > -- Dexuan -- Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf/powerpc/hv-24x7: Use per-cpu page buffer
On Tue, 2014-12-09 at 23:06 -0800, Sukadev Bhattiprolu wrote:
> From 470c16c8955672103a9529c78dffbb239e9e27b8 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Tue, 9 Dec 2014 22:17:46 -0500
> Subject: [PATCH 1/2] perf/poweprc/hv-24x7: Use per-cpu page buffer
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index dba3408..18e1f49 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -217,11 +217,14 @@ static bool is_physical_domain(int domain)
> domain == HV_24X7_PERF_DOMAIN_PHYSICAL_CORE;
> }
>
> +DEFINE_PER_CPU(char, hv_24x7_reqb[4096]);
> +DEFINE_PER_CPU(char, hv_24x7_resb[4096]);
Do we need it to be 4K aligned also? I would guess so.
Rather than declaring these as char arrays and then casting below, can you pull
the struct definitions up and then declare the per cpu variables with the
proper type.
> static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>u16 lpar, u64 *res,
>bool success_expected)
> {
> - unsigned long ret = -ENOMEM;
> + unsigned long ret;
>
> /*
>* request_buffer and result_buffer are not required to be 4k aligned,
> @@ -243,13 +246,11 @@ static unsigned long single_24x7_request(u8 domain, u32
> offset, u16 ix,
> BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
> BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
>
> - request_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
> - if (!request_buffer)
> - goto out;
> + request_buffer = (void *)get_cpu_var(hv_24x7_reqb);
> + result_buffer = (void *)get_cpu_var(hv_24x7_resb);
>
> - result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
> - if (!result_buffer)
> - goto out_free_request_buffer;
> + memset(request_buffer, 0, 4096);
> + memset(result_buffer, 0, 4096);
Do we have to memset them? That's not going to speed things up.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf/power/hv-24x7: Use kmem_cache_free() instead of kfree
On Tue, 2014-12-09 at 23:09 -0800, Sukadev Bhattiprolu wrote: > From 982bf5a660ae33fbe2f9187187caa6752c66783d Mon Sep 17 00:00:00 2001 > From: Sukadev Bhattiprolu > Date: Wed, 10 Dec 2014 01:43:34 -0500 > Subject: [PATCH 2/2] power/perf: hv-24x7: Use kmem_cache_free() instead of > kfree This got a bit munged, ... > Use kmem_cache_free() to free a buffer allocated with kmem_cache_alloc(). > > Signed-off-by: Sukadev Bhattiprolu > > p#set2.log .. and here too. I can fix it up this time. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/16] genirq: Introduce callback irq_chip.irq_write_msi_msg
On 2014/11/19 19:11, Thomas Gleixner wrote:
> On Wed, 19 Nov 2014, Yun Wu (Abel) wrote:
>> On 2014/11/19 1:21, Marc Zyngier wrote:
>>> This is why the framework gives you the opportunity to provide methods
>>> that:
>>> - compose the message
>>> - program the message into the device
>>>
>>> None of that has to be PCI specific, and gives you a clean
>>> abstraction. The framework only gives you a number of shortcuts for PCI
>>> MSI, because that's what most people care about.
>>>
>>
>> Indeed, and I never said Jiang's patches don't work, I was just thinking
>> that they were not that perfect.
>
> But your magic extra layer of indirection is perfect? It's not, it
> just violates sane layering in order to support braindead hardware
> designs.
>
Hi Thomas, Gerry and Marc,
I spent last two weeks implementing and testing my original idea about making
the sub domains generic, based on stacked domain feature. Now it comes real,
please see the attached patch.
With this patch applied, I think things will get easier.
For drivers of interrupt controllers, they need to implement:
a) struct irq_chip, gets associated in domain's map/alloc callback
b) struct irq_domain, with corresponding operations
c) create sub generic MBI domain of IRQ domain to deal with all MBI types.
This changes almost nothing of the current code.
For drivers of MBI-capable devices, they need to implement:
a) MBI operations, like mask/unmask or setting message.
This will remove current ugly arch-specific code by organizing the device
behavior into a generic structure used in generic MBI layer.
The MBI generic code will build the bridge between the two groups. So when a
new driver need to implement, either controller's or endpoint's, just code
the corresponding 'need' described above with no more work to do.
This patch (also with several other patches) is tested on Hisilicon ARM64 SoC,
with non PCI devices capable of message based interrupts. The PCI part is not
tested because it needs large refactoring work to do. So yes, the testing work
is not sufficient, but I think the patch is enough to present what I really
wanted to express. :)
A new term introduced by the patch named Message Based Interrupt (MBI) is used
for presenting the generic MSIs (which does help me avoid conflicting with the
existing code). Actually the new name is proposed by Marc several months ago,
suggesting that MSI implies too much about PCI. I think it's a good idea to use
MBI in generic code and make the MSI/MSI-x a wrapper of MBI inside the PCI core.
Anyway, naming is not the key point yet.
Finally, yes, my thoughts is not perfect, but I am just trying to make it
better.
Best regards and thanks,
Abel
>From 64c5440f685440bb7d92ab716013f9f54f21bca2 Mon Sep 17 00:00:00 2001
From: Yun Wu
Date: Wed, 10 Dec 2014 10:32:58 +0800
Subject: [PATCH] MBI: initial support for message based interrupts
This patch provides initial support for Message Based Interrupt (MBI),
which is a write from the device to a special address which causes an
interrupt to be received by the CPU.
MBI is a generic mechanism not specific to any architectures or any
subsystems. MSI/MSI-X defined in PCI specification are special MBIs.
Signed-off-by: Yun Wu
---
arch/arm64/Kconfig | 1 +
include/linux/device.h | 3 +
include/linux/irq.h| 22
include/linux/mbi.h| 95 ++
kernel/irq/Kconfig | 5 +
kernel/irq/Makefile| 1 +
kernel/irq/chip.c | 66
kernel/irq/mbi.c | 260 +
8 files changed, 453 insertions(+)
create mode 100644 include/linux/mbi.h
create mode 100644 kernel/irq/mbi.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f49c288..ef55541 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -13,6 +13,7 @@ config ARM64
select ARM_GIC
select AUDIT_ARCH_COMPAT_GENERIC
select ARM_GIC_V3
+ select MBI
select ARM_GIC_V3_ITS if PCI_MSI
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..e0618c2 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -715,6 +715,7 @@ struct acpi_dev_node {
* gone away. This should be set by the allocator of the
* device (i.e. the bus driver that discovered the device).
* @iommu_group: IOMMU group the device belongs to.
+ * @mbi: Pointer to the data of message based interrupts.
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
@@ -794,6 +795,8 @@ struct device {
void(*release)(struct device *dev);
struct iommu_group *iommu_group;
+ struct mbi_data *mbi;
+
booloffline_disabled:1;
booloffline:1;
};
diff --git a/include/linux/irq.h b/include/linux/irq.h
index
RE: [PATCH v13 09/12] input: cyapa: add gen5 trackpad device firmware update function support
Jeremiah, Thank you very much for the solution. I will aplly it to my local patches immediately. Do you think it is required to re-submit the patch set right now? Thanks, Dudley > -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jeremiah Mahler > Sent: 2014?12?10? 16:55 > To: Dudley Du > Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org > Subject: Re: [PATCH v13 09/12] input: cyapa: add gen5 trackpad device firmware > update function support > > Dudley, > > On Tue, Dec 09, 2014 at 07:33:03PM -0800, Jeremiah Mahler wrote: > > Dudley, > > > > On Tue, Dec 09, 2014 at 05:11:41PM +0800, Dudley Du wrote: > > > Add firmware image update function supported for gen5 trackpad device, > > > it can be used through sysfs update_fw interface. > > > TEST=test on Chromebooks. > > > > > > Signed-off-by: Dudley Du > > > --- > > > drivers/input/mouse/Kconfig | 2 +- > > > drivers/input/mouse/cyapa_gen5.c | 290 > +++ > > > 2 files changed, 291 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig > > > index d8b46b0..63e8b40 100644 > > > --- a/drivers/input/mouse/Kconfig > > > +++ b/drivers/input/mouse/Kconfig > > > @@ -205,7 +205,7 @@ config MOUSE_BCM5974 > > > > > > config MOUSE_CYAPA > > > tristate "Cypress APA I2C Trackpad support" > > > -depends on I2C > > > +depends on I2C && CRC_ITU_T > If this line is instead changed to: > > + depends on I2C > + select CRC_ITU_T > > It will upgrade correctly during make oldconfig without removing > MOUSE_CYAPA. > > And it looks like several other Kconfig files do it this way already. > > linux-next$ grep -r CRC_ITU_T $(find ./ -name Kconfig) > > > > help > > >This driver adds support for Cypress All Points Addressable (APA) > > >I2C Trackpads, including the ones used in 2012 Samsung Chromebooks. > > > diff --git a/drivers/input/mouse/cyapa_gen5.c > b/drivers/input/mouse/cyapa_gen5.c > > > > My initial config had MOUSE_CYAPA=m and CRC_ITU_T=n. > > I did a 'make oldconfig', no questions were asked, but it removed > > MOUSE_CYAPA since CRC_ITU_T wasn't enabled. Since the cyapa modules > > were removed the touchpad no longer works. Not a very good upgrade path :-( > > To fix this I have to manually enable MOUSE_CYAPA and CRC_ITU_T to get > > it working again. > > > > [...] > > > > -- > > - Jeremiah Mahler > > -- > - Jeremiah Mahler > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] clocksource: arch_timer: Fix code to use physical timers when requested
On Tue, 2014-12-09 at 16:58 +, Catalin Marinas wrote: <...> > You mix timer and counter terms here. Anyway, of we use physical timer, > you could argue that it makes sense to use the corresponding physical > counter (CNTPCT). However, on arm64 we only expose CNTVCT to user VDSO > and we want to use the same in the kernel. When booting at EL2, CNTVCT > == CNTPCT because we control CNTVOFF, that's unless we have some broken > firmware that does not restore CNTVOFF correctly. That's what we want > to spot early, hence the aim to always use the virtual counter (but not > the timer, use use the physical timer as it makes it easier for KVM). > > So the patch below, on top of linux-next, should solve the BUG(): Thanks for detail explanation and the patch. I tested it on my platform and it did solve the issue. So, Tested-by: Yingjoe Chen Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup
Dexuan Cui writes: >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Tuesday, December 9, 2014 23:48 PM >> To: KY Srinivasan >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- >> ker...@vger.kernel.org; Dexuan Cui >> Subject: [PATCH 0/5] Tools: hv: fix compiler warnings and do minor cleanup >> >> When someone does 'make' in tools/hv/ issues appear: >> - hv_fcopy_daemon is not being built; >> - lots of compiler warnings. >> >> This is just a cleanup. Compile-tested by myself on top of linux-next/master. >> >> Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant >> '/' >> in hv_start_fcopy()" >> >> Vitaly Kuznetsov (5): >> Tools: hv: add mising fcopyd to the Makefile >> Tools: hv: remove unused bytes_written from kvp_update_file() >> Tools: hv: address compiler warnings for hv_kvp_daemon.c >> Tools: hv: address compiler warnings for hv_fcopy_daemon.c >> Tools: hv: do not add redundant '/' in hv_start_fcopy() >> >> tools/hv/Makefile | 4 ++-- >> tools/hv/hv_fcopy_daemon.c | 10 ++ >> tools/hv/hv_kvp_daemon.c | 29 + >> 3 files changed, 17 insertions(+), 26 deletions(-) >> >> -- >> 1.9.3 > > Hi Vitaly, > Thanks for the patchset! > > Acked-by: Dexuan Cui > > PS, I added Greg into the TO list. > The hv code in drivers/hv/ and tools/hv/ usually has to go into > Greg's tree first. Well, I don't mind spamming Greg but he's not on the scripts/get_maintainer.pl output. In case he's not monitoring the list for patches by some other tool (patchwork?) a patch adding him to MAINTAINERS would do the job. Greg, do you want to become an official Hyper-V maintainer in MAINTAINERS? I can send a patch then :-) -- Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/16] genirq: Introduce callback irq_chip.irq_write_msi_msg
On 2014/11/19 17:20, Marc Zyngier wrote: > On Wed, Nov 19 2014 at 6:57:25 am GMT, "Yun Wu (Abel)" > wrote: >> On 2014/11/18 22:32, Thomas Gleixner wrote: >> >>> On Tue, 18 Nov 2014, Yun Wu (Abel) wrote: >>> >>> Can you please trim the messages when you're replying? >>> The above you described is absolutely right, but not the things I want to know. :) Take GICv3 ITS for example, it deals with both PCI and non PCI message interrupts. IIUC, several irq_chips need to be implemented in the ITS driver (i.e. pci_msi_chip, A_msi_chip and B_msi_chip). What should we do to the ITS driver if new MSI-capable devices come out? >>> >>> You seem to miss the stacking here >>> >>> PCI-MSI -> >>> A-MSI -> ITS -> GIC >>> B-MSI -> >>> >>> So each of the device types has its own MSI controller. Each of them >>> will have their own callbacks and are backed by the underlying ITS/GIC >>> implementation. >> >> Yes, this hits the key point. Once a new device type becomes available, >> we need to add pieces of code outside the new device's driver to make >> it work, which in my opinion is due to lack of core infrastructure. >> More specifically, the core infrastructure needs to support mechanism >> of MSI, not the various types of devices. >> >>> >>> And that's the only sensible solution. >>> >> >> It's sensible, but not perfect. >> What I suggested is to add a generic layer: >> >> PCI-MSI -> >> A-MSI-> (generic layer) -> ITS -> GICR >> B-MSI-> >> >> The PCI/A/B/... passes its hardware properties to the generic layer which >> gets configurations ready by calling ITS's domain/chip callbacks. When >> a new device type arrives, the only thing need to do is to implement the >> driver of that device, with nothing to do with the generic layer or ITS. > > I really don't get your "generic layer" story. To me, it looks like a > glorified set of function pointers. And that's exactly what stacked > domains are giving you: > > A-MSI -> ITS -> GIC > > This "A-MSI" is responsible for: > - implementing the "prepare" callback, which allocates the ITT > - implementing the "irq_compose_msi_msg" > > Hardly anything to change in the ITS driver, and I can probably make it > so that you don't even have to write a single line of code in the ITS > driver. > > If the generic MSI layer we now have is not enough for you, then please > submit detailed use cases. > Hi Marc, As I said, I never thought Gerry's patch don't work, I am just trying to make it better. :) As to the "generic layer" story, please check the following URL: https://lkml.org/lkml/2014/12/10/93 Thanks, Abel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] microblaze: Fix mmap for cache coherent memory
On 12/03/2014 04:07 PM, Lars-Peter Clausen wrote:
> When running in non-cache coherent configuration the memory that was
> allocated with dma_alloc_coherent() has a custom mapping and so there is no
> 1-to-1 relationship between the kernel virtual address and the PFN. This
> means that virt_to_pfn() will not work correctly for those addresses and the
> default mmap implementation in the form of dma_common_mmap() will map some
> random, but not the requested, memory area.
>
> Fix this by providing a custom mmap implementation that looks up the PFN
> from the page table rather than using virt_to_pfn.
>
> Signed-off-by: Lars-Peter Clausen
> ---
> arch/microblaze/include/asm/pgtable.h | 1 +
> arch/microblaze/kernel/dma.c | 26 ++
> arch/microblaze/mm/consistent.c | 23 ++-
> 3 files changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/pgtable.h
> b/arch/microblaze/include/asm/pgtable.h
> index 95cef0b..df19d0c 100644
> --- a/arch/microblaze/include/asm/pgtable.h
> +++ b/arch/microblaze/include/asm/pgtable.h
> @@ -565,6 +565,7 @@ void consistent_free(size_t size, void *vaddr);
> void consistent_sync(void *vaddr, size_t size, int direction);
> void consistent_sync_page(struct page *page, unsigned long offset,
> size_t size, int direction);
> +unsigned long consistent_virt_to_pfn(void *vaddr);
>
> void setup_memory(void);
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
> index 4633c36..4822367 100644
> --- a/arch/microblaze/kernel/dma.c
> +++ b/arch/microblaze/kernel/dma.c
> @@ -154,9 +154,35 @@ dma_direct_sync_sg_for_device(struct device *dev,
> __dma_sync(sg->dma_address, sg->length, direction);
> }
>
> +int dma_direct_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + struct dma_attrs *attrs)
> +{
> + unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> + unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> + unsigned long off = vma->vm_pgoff;
> + unsigned long pfn;
> +
> + if (!IS_ENABLED(CONFIG_MMU))
> + return -ENXIO;
> +
> + if (off >= count || user_count > (count - off))
> + return -ENXIO;
> +
> +#ifdef NOT_COHERENT_CACHE
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + pfn = consistent_virt_to_pfn(cpu_addr);
> +#else
> + pfn = virt_to_pfn(cpu_addr);
> +#endif
> + return remap_pfn_range(vma, vma->vm_start, pfn + off,
> +vma->vm_end - vma->vm_start, vma->vm_page_prot);
> +}
> +
> struct dma_map_ops dma_direct_ops = {
> .alloc = dma_direct_alloc_coherent,
> .free = dma_direct_free_coherent,
> + .mmap = dma_direct_mmap_coherent,
> .map_sg = dma_direct_map_sg,
> .dma_supported = dma_direct_dma_supported,
> .map_page = dma_direct_map_page,
> diff --git a/arch/microblaze/mm/consistent.c b/arch/microblaze/mm/consistent.c
> index e10ad93..f358cd2 100644
> --- a/arch/microblaze/mm/consistent.c
> +++ b/arch/microblaze/mm/consistent.c
> @@ -156,6 +156,23 @@ void *consistent_alloc(gfp_t gfp, size_t size,
> dma_addr_t *dma_handle)
> }
> EXPORT_SYMBOL(consistent_alloc);
>
> +static pte_t *consistent_virt_to_pte(void *vaddr)
> +{
> + unsigned long addr = (unsigned long)vaddr;
> +
> + return pte_offset_kernel(pmd_offset(pgd_offset_k(addr), addr), addr);
> +}
> +
> +unsigned long consistent_virt_to_pfn(void *vaddr)
> +{
> + pte_t *ptep = consistent_virt_to_pte(vaddr);
> +
> + if (pte_none(*ptep) || !pte_present(*ptep))
> + return 0;
> +
> + return pte_pfn(*ptep);
> +}
> +
> /*
> * free page(s) as defined by the above mapping.
> */
> @@ -181,13 +198,9 @@ void consistent_free(size_t size, void *vaddr)
> } while (size -= PAGE_SIZE);
> #else
> do {
> - pte_t *ptep;
> + pte_t *ptep = consistent_virt_to_pte(vaddr);
> unsigned long pfn;
>
> - ptep = pte_offset_kernel(pmd_offset(pgd_offset_k(
> - (unsigned int)vaddr),
> - (unsigned int)vaddr),
> - (unsigned int)vaddr);
> if (!pte_none(*ptep) && pte_present(*ptep)) {
> pfn = pte_pfn(*ptep);
> pte_clear(&init_mm, (unsigned int)vaddr, ptep);
>
Applied.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP d
Re: [PATCH v2] sound/soc/adi/axi-spdif.c: Support programmable master clock
On 12/05/2014 01:37 PM, Mike Looijmans wrote: If the master clock supports programmable rates, program it to generate the desired frequency. Only apply constraints when the clock is fixed. This allows proper clock generation for both 44100 and 48000 Hz based sampling rates if the platform supports it. The clock frequency must be set before enabling it. Enabling the clock was done in "startup", but that occurs before "hw_params" where the rate is known. Enabling a programmable clock without first setting a valid frequency may harm the system. Move the clock start to the hw_params routine, and keep track of whether the clock has been started, because shutdown may be called without having called hw_params first. Starting the clock and enabling the SPDIF output AFTER programming the dividers is a more logical order anyway. To detect if the source clock is fixed, the driver calls clk_round_rate for two frequencies. If the results are equal, or if the call returns an error, the driver assumes the clock is fixed. Signed-off-by: Mike Looijmans Hi, Sorry for the delay. [...] + /* Try to set the master clock */ + clk_set_rate(spdif->clk_ref, rate * 128); + clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(spdif->clk_ref), rate * 64 * 2) - 1; clkdiv <<= AXI_SPDIF_CTRL_CLKDIV_OFFSET; @@ -103,6 +108,14 @@ static int axi_spdif_hw_params(struct snd_pcm_substream *substream, regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL, AXI_SPDIF_CTRL_CLKDIV_MASK, clkdiv); + ret = clk_prepare_enable(spdif->clk_ref); I'm still not convinced this is the right place. I do see your point. But it just feels wrong to enable the clock in hw_params. It's a bit of a dilemma. the startup callback is to early, hw_params is the wrong place and we can't put it in the trigger callback as the trigger callback can not sleep. But in any way hwparmas can be called multiple times, so you need to handle the case where the clock is already enabled. + if (ret) + return ret; + spdif->clk_ref_running = true; + + regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL, + AXI_SPDIF_CTRL_TXEN, AXI_SPDIF_CTRL_TXEN); This should probably be moved to the trigger callback though. + return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/8] perf probe powerpc: Fix symbol fixup issues due to ELF type
On 2014/12/09 06:07PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 09, 2014 at 11:04:00PM +0530, Naveen N. Rao escreveu:
> > If using the symbol table, symbol addresses are not being fixed up
> > properly, resulting in probes being placed at wrong addresses:
> >
> > # perf probe do_fork
> > Added new event:
> > probe:do_fork(on do_fork)
> >
> > You can now use it in all perf tools, such as:
> >
> > perf record -e probe:do_fork -aR sleep 1
> >
> > # cat /sys/kernel/debug/tracing/kprobe_events
> > p:probe/do_fork _text+635952
> > # printf "%x" 635952
> > 9b430
> > # grep do_fork /boot/System.map
> > c00ab430 T .do_fork
> >
> > Fix by checking for ELF type ET_DYN used by ppc64 kernels.
>
> Are you sure this doesn't need to be enclosed in ifdef PPC64?
I felt this change is architecture-independent, though I'm actually not
sure if there are other architectures using ET_DYN for their kernel. I
can restrict this to ppc64 if you think that would be better.
- Naveen
>
> - Arnaldo
>
> > Signed-off-by: Naveen N. Rao
> > ---
> > tools/perf/util/symbol-elf.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index 1e23a5b..67e4392 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -629,7 +629,8 @@ int symsrc__init(struct symsrc *ss, struct dso *dso,
> > const char *name,
> > NULL) != NULL);
> > } else {
> > ss->adjust_symbols = ehdr.e_type == ET_EXEC ||
> > -ehdr.e_type == ET_REL;
> > +ehdr.e_type == ET_REL ||
> > +ehdr.e_type == ET_DYN;
> > }
> >
> > ss->name = strdup(name);
> > --
> > 2.1.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: > This patch add new devfreq_event class for devfreq_event device which provide > raw data (e.g., memory bus utilization/GPU utilization). This raw data from > devfreq_event data would be used for the governor of devfreq subsystem. > - devfreq_event device : Provide raw data for governor of existing devfreq > device > - devfreq device : Monitor device state and change frequency/voltage of > device > using the raw data from devfreq_event device > > The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) > for Non-CPU Devices. The devfreq device would dertermine current device state > using various governor (e.g., ondemand, performance, powersave). After > completed > determination of system state, devfreq device would change the > frequency/voltage > of devfreq device according to the result of governor. > > But, devfreq governor must need basic data which indicates current device > state. > Existing devfreq subsystem only consider devfreq device which check current > system > state and determine proper system state using basic data. There is no > subsystem > for device providing basic data to devfreq device. > > The devfreq subsystem must need devfreq_event device(data-provider device) for > existing devfreq device. So, this patch add new devfreq_event class for > devfreq_event device which read various basic data(e.g, memory bus > utilization, > GPU utilization) and provide measured data to existing devfreq device through > standard APIs of devfreq_event class. > > The following description explains the feature of two kind of devfreq class: > - devfreq class (existing) > : devfreq consumer device use raw data from devfreq_event device for >determining proper current system state and change voltage/frequency >dynamically using various governors. > > - devfreq_event class (new) > : Provide measured raw data to devfreq device for governor > > Cc: MyungJoo Ham > Cc: Kyungmin Park > Signed-off-by: Chanwoo Choi > --- > drivers/devfreq/Kconfig | 2 + > drivers/devfreq/Makefile| 5 +- > drivers/devfreq/devfreq-event.c | 302 > > drivers/devfreq/event/Makefile | 1 + > include/linux/devfreq.h | 141 +++ > 5 files changed, 450 insertions(+), 1 deletion(-) > create mode 100644 drivers/devfreq/devfreq-event.c > create mode 100644 drivers/devfreq/event/Makefile > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index faf4e70..4d15b62 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ > It reads PPMU counters of memory controllers and adjusts the > operating frequencies and voltages with OPP support. > > +comment "DEVFREQ Event Drivers" > + > endif # PM_DEVFREQ > diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile > index 16138c9..a1ffabe 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -1,4 +1,4 @@ > -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o > +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o > obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o > obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o > obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o > @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o > # DEVFREQ Drivers > obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/ > obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/ > + > +# DEVFREQ Event Drivers > +obj-$(CONFIG_PM_DEVFREQ) += event/ > diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c > new file mode 100644 > index 000..b47329f > --- /dev/null > +++ b/drivers/devfreq/devfreq-event.c > @@ -0,0 +1,302 @@ > +/* > + * devfreq-event: Generic DEVFREQ Event class driver > + * > + * Copyright (C) 2014 Samsung Electronics > + * Chanwoo Choi > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This driver is based on drivers/devfreq/devfreq.c > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "governor.h" > + > +static struct class *devfreq_event_class; > + > +/* The list of all devfreq event list */ > +static LIST_HEAD(devfreq_event_list); > +static DEFINE_MUTEX(devfreq_event_list_lock); > + > +#define to_devfreq_event(DEV) container_of(DEV, struct devfreq_event_dev, > dev) > + > +struct devfreq_event_dev *devfreq_add_event_device(struct device *dev, > + struct devfreq_e
Re: [RFC PATCH 1/8] kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2
On Tue, 2014-12-09 at 23:03 +0530, Naveen N. Rao wrote: > Currently, all non-dot symbols are being treated as function descriptors > in ABIv1. This is incorrect and is resulting in perf probe not working: I don't understand that first sentence. With ABIv1 non-dot symbols *are* function descriptors? > # perf probe do_fork > Added new event: > Failed to write event: Invalid argument > Error: Failed to add events. > # dmesg | tail -1 > [192268.073063] Could not insert probe at _text+768432: -22 > > _text is being resolved incorrectly and is resulting in the above error. > Fix this by changing how we lookup symbol addresses on ppc64. We first > check for the dot variant of a symbol and look at the non-dot variant > only if that fails. In this manner, we avoid having to look at the > function descriptor. I'm not clear that ppc_local_function_entry() makes sense. On ABIv2 you return the local entry point, which is fine. But on ABIv1 you just return the unmodified address, which will be the descriptor if you actually passed it a function pointer. I think you're assuming that you're passed the text address, but if that's the case the function is badly named at least. I also don't understand why we need to ever guess which ABI we're using. We know which ABI we're built with, so there should be no guess work required. So at the very least this needs much more explanation. But to be honest I'm not clear why it even needs a kernel change, don't we just need perf to understand dot symbols? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] ARM: socfpga: defconfig: enable fpga manager
Hi Alan, On 12/09/2014 09:14 PM, at...@opensource.altera.com wrote: > From: Alan Tull > > Enable FPGA manager for Altera socfpga. > > Signed-off-by: Alan Tull > --- > arch/arm/configs/socfpga_defconfig |4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/configs/socfpga_defconfig > b/arch/arm/configs/socfpga_defconfig > index a2956c3..2740057 100644 > --- a/arch/arm/configs/socfpga_defconfig > +++ b/arch/arm/configs/socfpga_defconfig > @@ -86,6 +86,10 @@ CONFIG_USB_DWC2=y > CONFIG_USB_DWC2_HOST=y > CONFIG_MMC=y > CONFIG_MMC_DW=y > +CONFIG_STAGING=y > +CONFIG_FPGA=y > +CONFIG_FPGA_MGR_SYSFS=y > +CONFIG_FPGA_MGR_ALTERA=y > CONFIG_EXT2_FS=y > CONFIG_EXT2_FS_XATTR=y > CONFIG_EXT2_FS_POSIX_ACL=y > This should the last patch in this series because you are changing Kconfig in 5/6 and 6/6. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] fpga manager: add sysfs interface document
Hi Greg, On 12/09/2014 09:14 PM, at...@opensource.altera.com wrote: > From: Alan Tull > > Add documentation for new fpga manager sysfs interface. > > Signed-off-by: Alan Tull > --- > Documentation/ABI/testing/sysfs-class-fpga-manager | 38 > > 1 file changed, 38 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-manager What's the rule for adding sysfs doc for driver which is added to staging? Is this location fine? Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: da9052-core: Fix platform-device id collision
On Tue, 09 Dec 2014, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Allow multiple DA9052 regulators be registered by registering with
> PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
>
> The subdevices are currently registered with PLATFORM_DEVID_NONE, which
> will cause a name collision on the platform bus when multiple regulators
> are registered:
>
> [0.128855] da9052-regulator da9052-regulator: invalid regulator ID
> specified
> [0.128973] da9052-regulator: probe of da9052-regulator failed with error
> -22
> [0.129148] [ cut here ]
> [0.129200] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
> sysfs_warn_dup+0x5c/0x7c()
> [0.129233] sysfs: cannot create duplicate filename
> '/devices/platform/soc/6000.aips/63fc8000.i2c/i2c-0/0-0048/da9052-regulator
> ...
> [0.132891] [ cut here ]
> [0.132924] WARNING: CPU: 0 PID: 1 at lib/kobject.c:240
> kobject_add_internal+0x24c/0x2cc()
> [0.132957] kobject_add_internal failed for da9052-regulator with -EEXIST,
> don't try to register things with the same name in the same directory.
> ...
> [0.137000] da9052 0-0048: mfd_add_devices failed: -17
> [0.138486] da9052: probe of 0-0048 failed with error -17
>
> Based on the fix done by Johan Hovold at commit b6684228726cc255 ("mfd:
> viperboard: Fix platform-device id collision").
>
> Tested on a imx53-qsb board, where multiple DA9053 regulators can be
> successfully probed.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/mfd/da9052-core.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied for v3.20, thanks.
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index 52a0c2f..ae498b5 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -554,7 +554,8 @@ int da9052_device_init(struct da9052 *da9052, u8 chip_id)
> return ret;
> }
>
> - ret = mfd_add_devices(da9052->dev, -1, da9052_subdev_info,
> + ret = mfd_add_devices(da9052->dev, PLATFORM_DEVID_AUTO,
> + da9052_subdev_info,
> ARRAY_SIZE(da9052_subdev_info), NULL, 0, NULL);
> if (ret) {
> dev_err(da9052->dev, "mfd_add_devices failed: %d\n", ret);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 10
Hi all, Please do not add stuff destined for v3.20 until after v3.19-rc1 is released. Changes since 20141209: Dropped tree: access_once The thermal tree lost its build failure. The net-next tree gained a conflict against the net tree and a build failure for which I applied a patch. The drm-misc tree gained conflicts against the drm tree. The security tree gained a conflict against the vfs tree. The rcu tree lost its build failure but gained another for which I reverted a commit. The usb tree still had its build failure so I used the version from next-20141128. The userns tree gained conflicts against the vfs tree. The access_once tree lost its build failure but gained another build failures, so I dropped it again. Non-merge commits (relative to Linus' tree): 10419 9481 files changed, 386763 insertions(+), 270247 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f3f62a38ceda Merge tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (f114040e3ea6 Linux 3.18-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of restarting block) Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after alloc_bootmem_pages) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (152d44a853e4 powerpc: 32 bit getcpu VDSO function uses 64 bit instructions) Merging sparc/master (0d1d9092b536 sparc: Add NOP dma_cache_sync() implementation.) Merging net/master (244d62be91dd amd-xgbe: Prevent Tx cleanup stall) Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in _decode_session6.) Merging sound-current/for-linus (bf35df66f1c6 ALSA: jack: Add dummy snd_jack_set_key() definition) Merging pci-current/for-linus (5106787a9e08 PCI: tegra: Use physical range for I/O mapping) Merging wireless/master (87141db0848a rtlwifi: rtl8192ce: Fix missing interrupt ready flag) Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4) Merging tty.current/tty-linus (009d0431c391 Linux 3.18-rc7) Merging usb.current/usb-linus (009d0431c391 Linux 3.18-rc7) Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code) Merging usb-serial-fixes/usb-linus (009d0431c391 Linux 3.18-rc7) Merging staging.current/staging-linus (009d0431c391 Linux 3.18-rc7) Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3) Merging input-current/for-linus (a1f9a4072655 Input: xpad - use proper endpoint type) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read API and fix stack corruption) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap) Merging rr-fixes/fixes (3438cf549d2f pa
Re: [RFC PATCH 2/8] perf probe powerpc: Fix symbol fixup issues due to ELF type
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote: > If using the symbol table, symbol addresses are not being fixed up > properly, resulting in probes being placed at wrong addresses: > > # perf probe do_fork > Added new event: > probe:do_fork(on do_fork) > > You can now use it in all perf tools, such as: > > perf record -e probe:do_fork -aR sleep 1 > > # cat /sys/kernel/debug/tracing/kprobe_events > p:probe/do_fork _text+635952 > # printf "%x" 635952 > 9b430 > # grep do_fork /boot/System.map > c00ab430 T .do_fork OK, but why is that happening? And why does checking for ET_DYN fix it? > Fix by checking for ELF type ET_DYN used by ppc64 kernels. We sometimes produce ET_DYN kernels, but only if CONFIG_RELOCATABLE=y. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it
On Tue, Dec 09, 2014 at 11:21:11AM -0700, Bjorn Helgaas wrote: >On Tue, Dec 9, 2014 at 12:56 AM, Wei Yang wrote: > >> As you mentioned in another thread, "5b28541552ef is taking the wrong >> approach". (http://www.spinics.net/lists/linux-pci/msg37374.html) Maybe I >> don't catch it clearly. Put a 32bit prefetchable resource in a 32bit >> non-prefetchable bridge window is a bad idea? > >A 32-bit prefetchable resource *can* be put in a 32-bit >non-prefetchable window, but the device won't perform as well as it >would if the resource were in a prefetchable window. > >What I object to is the fact that we put a 32-bit prefetchable >resource in the non-prefetchable window and leave the 64-bit >prefetchable window unused. This gives up performance for no benefit. > OK, I get your point. This is really a waste to put a 32-bit prefetchable resource in non-prefetchable window and no one use the 64-bit prefetchable window. (That's very interesting even no performance lost by doing so as mentioned in reply from Marek. Maybe the reason is the most important IO is performed in DMA.) Below is what's in my mind, if not correct please let me know. 1. Yinghai's patch needs a little modification Now back to Yinghai's patch. If this patch wants to apply this logic it should check all prefetchable resource, including M64 and non-M64 if *none* of them has M64 prefetchable resource, then clear the M64 flag in bridge. But the logic in patch is if *any* of them has non-M64 prefetchable resource, then clear the M64 flag in bridge. 2. Yes, the strategy will improve the performance in some case, but with limited case. Then suppose we use the strategy, clear the M64 flag in bridge when none of the child resource need it. I imagined this scenario: +--+ |B1| +--+---+ | Bus#1 ---+--+---+ | Bus#2 | Bus#3 +--+--++--+---+ |B2 ||B3| +-++--+ res[1] 32-bit non-pref res[1] 32-bit non-pref res[2] 64-bit pref res[2] 32-bit pref Suppose we have a PCI sub-tree like this. And suppose all the bus->resource[2] is with M64 flag before sizing. (The initial value is retrieved in enumeration stage by pci_read_bridge_bases(). This happens before sizing.) We will first size Bus#2, then Bus#3, at last Bus#1. As shown in the chart, For Bus#2, there is a 64-bit pref, so Bus#2->resource[2] with M64 flag set. For Bus#3, there is no 64-bit pref, so Bus#3->resource[2] with M64 flag cleared. Then up to Bus#1, since there is a 64-bit prefetchable resource, the Bus#1->resource[2] is with M64 flag set. The final B1's window will look like this: +--+ | B1 | | | | res[1] 32-bit non-pref | | +-+--+--+| | |B2.res[1]| B3.res[1]| B3.res[2]|| | +-+--+--+| | | | res[2] 64-bit pref | | ++ | | |B2.res[2] | | | ++ | +--+ >From the performance perspective: B3.res[2] will bring some performance improvement to those devices under it. But from its grand parent's point of view, B3.res[2] still sits under a non-prefetchable window. So the performance improvement will be limited. Hope my understanding is correct. So the best case for the performance improvement is all this PCI tree has no 64-bit prefetchable resource. >From the resource sizing/allocation perspective: B3.res[2] still contribute to the root's non-prefetchable window, once there is a 64-bit prefetchable in the PCI tree. If we don't have enough non-prefetchable window in root, we would fail. Bjorn, I agree to apply the logic you mentioned to clear the M64 flag when no child need it. But the benefits is limited. I did a grep on the lspci -vvv output and see there is no 64-bit prefetchable BAR in the system. $ grep Region lspci | grep Me Region 0: Memory at febff400 (32-bit, non-prefetchable) [size=1K] Region 0: Memory at febf8000 (64-bit, non-prefetchable) [size=16K] Region 0: Memory at febff000 (32-bit, non-prefetchable) [size=1K] Region 5: Memory at febff800 (32-bit, non-prefetchable) [size=2K] Region 0: Memory at c000 (32-bit, prefetchable) [size=256M] Region 2: Memory at fdff (32-bit, non-prefetchable) [size=64K]
Re: [PATCH 2/4] mm/page_alloc: expands broken freepage to proper buddy list when steal
On 12/10/2014 07:38 AM, Joonsoo Kim wrote: On Mon, Dec 08, 2014 at 10:29:44AM +0100, Vlastimil Babka wrote: On 12/08/2014 08:16 AM, Joonsoo Kim wrote: There is odd behaviour when we steal freepages from other migratetype buddy list. In try_to_steal_freepages(), we move all freepages in the pageblock that founded freepage is belong to to the request migratetype in order to mitigate fragmentation. If the number of moved pages are enough to change pageblock migratetype, there is no problem. If not enough, we don't change pageblock migratetype and add broken freepages to the original migratetype buddy list rather than request migratetype one. For me, this is odd, because we already moved all freepages in this pageblock to the request migratetype. This patch fixes this situation to add broken freepages to the request migratetype buddy list in this case. I'd rather split the fix from the refactoring. And maybe my description is longer, but easier to understand? (I guess somebody else should judge this) Your patch is much better to understand than mine. :) No need to judge from somebody else. After your patch is merged, I will resubmit these on top of it. Thanks. I'm doing another evaluation focusing on number of unmovable pageblocks as Mel suggested and then resubmit with tracepoint fixed. Vlastimil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] irqchip: mediatek: Use IS_ERR() instead of NULL pointer check
Beniamino reported a kernel oops caused by an invalid DT file for the
mediatek interrupt polarity extension.
The reason is that the interrupt polarity support for mediatek chips
merely checks for NULL pointer instead of a casted error return
value in mtk_sysirq_of_init() so any other casted error value passes
the NULL pointer check and causes a kernel panic when dereferenced.
Use IS_ERR() and return the error value via PTR_ERR().
Reported-and-tested-by: Beniamino Galvani
Signed-off-by: Yingjoe Chen
---
drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 7e342df..0b0d2c0 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -137,9 +137,9 @@ static int __init mtk_sysirq_of_init(struct device_node
*node,
return -ENOMEM;
chip_data->intpol_base = of_io_request_and_map(node, 0, "intpol");
- if (!chip_data->intpol_base) {
+ if (IS_ERR(chip_data->intpol_base)) {
pr_err("mtk_sysirq: unable to map sysirq register\n");
- ret = -ENOMEM;
+ ret = PTR_ERR(chip_data->intpol_base);
goto out_free;
}
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MFD for v3.19
On Tue, 09 Dec 2014, Linus Torvalds wrote:
> On Tue, Dec 9, 2014 at 2:00 AM, Johan Hovold wrote:
> >
> > Not sure what happened to the git history after your merge, though,
> > since commit
> >
> > b6684228726c ("mfd: viperboard: Fix platform-device id collision")
> >
> > no longer shows up when doing
> >
> > git log origin/master -- drivers/mfd/viperboard.c
>
> So when you do "git log" with a pathname specifier, git obviously no
> longer shows you all the history. In particular, it shows you the
> relevant history for just that file. And by "relevant", it not only
> skips commits that don't change the file, but it also does merge
> simplification: if it hits a merge, and all changes to the file came
> from one side of the merge, it will ignore the other side.
>
> And in this case, since after my merge the file was identical to your
> branch, clearly the other side didn't bring anything interesting to
> the table, and that history simplification basically means that it's
> ignoring all the changes done in the other side of the merge that got
> thrown away and aren't really relevant for the end result.
>
> You can get rid of that extra simplification with "--full-history",
> but then you'll usually also want to skip all the merges that aren't
> really intersting, so you'd usually end up doing "--full-history
> --no-merges" or something.
>
> Thenm you'll see that commit that didn't actually matter fot the end result..
Interesting. I know Git does some pretty amazing things, but I wasn't
aware it was capable of this kind of simplification when displaying
logs. I would have expected it to display all commits pertaining to a
file if you'd specified it implicitly. Thanks for clearing that up.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv2 4/7] devfreq: event: Add exynos-ppmu devfreq event driver
On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote:
> This patch add exynos-ppmu devfreq event driver to provider raw data about
> the utilization of each IP in Exynos SoC series.
>
> Cc: MyungJoo Ham
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
> ---
> drivers/devfreq/Kconfig | 9 +
> drivers/devfreq/event/Makefile | 1 +
> drivers/devfreq/event/exynos-ppmu.c | 409
>
> 3 files changed, 419 insertions(+)
> create mode 100644 drivers/devfreq/event/exynos-ppmu.c
I would rather see this as an incremental change for existing
exynos_ppmu.c file. However I do not insists on that.
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 4d15b62..d4559f7 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -89,4 +89,13 @@ config ARM_EXYNOS5_BUS_DEVFREQ
>
> comment "DEVFREQ Event Drivers"
>
> +config DEVFREQ_EVENT_EXYNOS_PPMU
> + bool "EXYNOS PPMU (Performance Profiling Monitoring Unit) DEVFREQ event
> Driver"
> + depends on ARCH_EXYNOS
> + select PM_OPP
> + help
> + This add the DEVFREQ event driver for Exynos SoC. It provides PPMU
> + (Performance Profiling Monitoring Unit) counters to estimate the
> + utilization of each module.
> +
> endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
> index dc56005..be146ea 100644
> --- a/drivers/devfreq/event/Makefile
> +++ b/drivers/devfreq/event/Makefile
> @@ -1 +1,2 @@
> # Exynos DEVFREQ Event Drivers
> +obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
> diff --git a/drivers/devfreq/event/exynos-ppmu.c
> b/drivers/devfreq/event/exynos-ppmu.c
> new file mode 100644
> index 000..2706f23
> --- /dev/null
> +++ b/drivers/devfreq/event/exynos-ppmu.c
> @@ -0,0 +1,409 @@
> +/*
> + * exynos_ppmu.c - EXYNOS PPMU (Performance Profiling Monitoring Units)
> support
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author : Chanwoo Choi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This driver is based on drivers/devfreq/exynos/exynos_ppmu.c
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PPMU_ENABLE BIT(0)
> +#define PPMU_DISABLE0x0
> +#define PPMU_CYCLE_RESETBIT(1)
> +#define PPMU_COUNTER_RESET BIT(2)
> +
> +#define PPMU_ENABLE_COUNT0 BIT(0)
> +#define PPMU_ENABLE_COUNT1 BIT(1)
> +#define PPMU_ENABLE_COUNT2 BIT(2)
> +#define PPMU_ENABLE_COUNT3 BIT(3)
> +#define PPMU_ENABLE_CYCLE BIT(31)
> +
> +#define PPMU_CNTENS 0x10
> +#define PPMU_FLAG0x50
> +#define PPMU_CCNT_OVERFLOW BIT(31)
> +#define PPMU_CCNT0x100
> +
> +#define PPMU_PMCNT0 0x110
> +#define PPMU_PMCNT_OFFSET0x10
> +#define PMCNT_OFFSET(x) (PPMU_PMCNT0 + (PPMU_PMCNT_OFFSET * x))
> +
> +#define PPMU_BEVT0SEL0x1000
> +#define PPMU_BEVTSEL_OFFSET 0x100
> +#define PPMU_BEVTSEL(x) (PPMU_BEVT0SEL + (x *
> PPMU_BEVTSEL_OFFSET))
> +
> +#define RD_DATA_COUNT0x5
> +#define WR_DATA_COUNT0x6
> +#define RDWR_DATA_COUNT 0x7
> +
> +enum ppmu_counter {
> + PPMU_PMNCNT0,
> + PPMU_PMNCNT1,
> + PPMU_PMNCNT2,
> + PPMU_PMNCNT3,
> + PPMU_PMNCNT_MAX,
> +};
> +
> +/* Platform data */
> +struct exynos_ppmu_data {
> + struct devfreq *devfreq;
Looks like not used here.
> + struct devfreq_event_dev **event_dev;
> + struct devfreq_event_desc *desc;
> + unsigned int num_events;
> +
> + struct device *dev;
> + struct clk *clk_ppmu;
> + struct mutex lock;
> +
> + struct __exynos_ppmu {
> + void __iomem *hw_base;
> + unsigned int ccnt;
> + unsigned int event[PPMU_PMNCNT_MAX];
> + unsigned int count[PPMU_PMNCNT_MAX];
> + unsigned long long ns;
> + ktime_t reset_time;
> + bool ccnt_overflow;
> + bool count_overflow[PPMU_PMNCNT_MAX];
> + } ppmu;
> +};
> +
> +struct __exynos_ppmu_events {
> + char *name;
> + int id;
> +} ppmu_events[] = {
> + { "ppmu-dmc0-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-dmc0-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-dmc0-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-dmc0-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-dmc1-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-dmc1-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-dmc1-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-dmc1-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-cpu-pmcnt0", PPMU_PMNCNT0 },
> + { "ppmu-cpu-pmcnt1", PPMU_PMNCNT1 },
> + { "ppmu-cpu-pmcnt2", PPMU_PMNCNT2 },
> + { "ppmu-cpu-pmcnt3", PPMU_PMNCNT3 },
> +
> + { "ppmu-rightbus-pmcnt0"
Re: [RFC PATCH 3/8] perf probe: Improve detection of file/function name in the probe pattern
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote: > Currently, perf probe considers patterns including a '.' to be a file. > However, this causes problems on powerpc ABIv1 where all functions have > a leading '.': > > $ perf probe -F | grep schedule_timeout_interruptible > .schedule_timeout_interruptible > $ perf probe .schedule_timeout_interruptible > Semantic error :File always requires line number or lazy pattern. > Error: Command Parse Error. > > Fix this by checking the probe pattern in more detail. > > Signed-off-by: Naveen N. Rao > --- > tools/perf/util/probe-event.c | 23 --- > 1 file changed, 20 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c > index c150ca4..c7e01ef 100644 > --- a/tools/perf/util/probe-event.c > +++ b/tools/perf/util/probe-event.c > @@ -999,6 +999,24 @@ static int parse_perf_probe_point(char *arg, struct > perf_probe_event *pev) > arg = tmp; > } > > + /* > + * Check arg is function or file name and copy it. > + * > + * We consider arg to be a file spec if and only if it satisfies > + * all of the below criteria:: > + * - it does not include any of "+@%", > + * - it includes one of ":;", and > + * - it has a period '.' in the name. I don't think we need to be this elaborate. AFAIK there are no source files in the kernel that start with '.' So if the arg starts with '.' it must be a function? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH] staging: writeboost: Add dm-writeboost
On Tue, Dec 09, 2014 at 03:12:53PM +, Joe Thornber wrote: > Writeboost is significantly slower than the spindle alone for this > very simple test. I do not understand what is causing the issue. I started doing the code review and now understand what's going on, sadly. You are splitting all bios up into 4k blocks to simplify the metadata layout, and mapping logic. This murders performance. File systems and the block layer try really hard to submit the largest bio possible for a reason. A simple dd in large chunks across your cache reveals this: raw spindle:8.9s writeboost type 0: 32.2s writeboost type 1: 71.1s dm-cache and dm-thin do also split io into blocks, but much larger, user configurable blocks. It's still a performance issue for us, which is why I'm using range locking to move away from this bio splitting (eg, recent cache discard patches). One of the main advantages of a log based metadata layout is you can cope nicely with arbitrarily sized bios. Unlike dm-cache for instance, which has to do a read from the origin if it wants to cache a write that partially covers a block (or maintain a 'valid' bit for each sector of every cached block). The writeboost target as it stands will only benefit v. small, random io. It will seriously degrade performance of any other IO profile. I'm NACKing this for upstream, and will not be spending any more time on it at this point. You've put a lot of effort into this so far, so I suggest you redesign the log metadata, and drop the io splitting; you'll end up with something far better. Sorry, - Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MFD for v3.19
On Tue, Dec 09, 2014 at 12:44:09PM -0800, Linus Torvalds wrote: > On Tue, Dec 9, 2014 at 2:00 AM, Johan Hovold wrote: > So when you do "git log" with a pathname specifier, git obviously no > longer shows you all the history. In particular, it shows you the > relevant history for just that file. And by "relevant", it not only > skips commits that don't change the file, but it also does merge > simplification: if it hits a merge, and all changes to the file came > from one side of the merge, it will ignore the other side. Thanks for the explanation. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Sakari, On 12/04/2014 12:40 PM, Jacek Anaszewski wrote: On 12/04/2014 11:07 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote: This patch adds device tree binding documentation for the flash cell of the Maxim max77693 multifunctional device. Signed-off-by: Jacek Anaszewski Signed-off-by: Andrzej Hajda Acked-by: Kyungmin Park Cc: Lee Jones Cc: Chanwoo Choi Cc: Bryan Wu Cc: Richard Purdie Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- Documentation/devicetree/bindings/mfd/max77693.txt | 89 1 file changed, 89 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..25a6e78 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,7 +41,66 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : Must be "maxim,max77693-led". + +Optional properties: +- maxim,fleds : Array of current outputs in order: fled1, fled2. +Note: both current outputs can be connected to a single led +Possible values: +MAX77693_LED_FLED_UNUSED - the output is left disconnected, +MAX77693_LED_FLED_USED - a diode is connected to the output. As you have a LED sub-nodes for each LED already, isn't this redundant? Well, it seems so :) I agreed here recklessly. This property allows to describe the situation when one LED is connected to both outputs. Single sub-node can describe two type of designs: one LED connected to a single output or one LED connected to both outputs. Therefore additional property is needed to assess what is the actual case. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/8] perf probe powerpc: Handle powerpc dot symbols
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote:
> Fix up various perf aspects related to ppc64's usage of dot functions:
> - ignore leading '.' when generating event names and when looking for
> existing events.
> - use the proper prefix when ignoring SyS symbol lookups.
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index c7e01ef..d465f7c 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2080,6 +2080,10 @@ static int get_new_event_name(char *buf, size_t len,
> const char *base,
> {
> int i, ret;
>
> + /* Skip the leading dot on powerpc */
> + if (*base == '.')
> + base++;
> +
> /* Try no suffix */
> ret = e_snprintf(buf, len, "%s", base);
> if (ret < 0) {
> @@ -2538,6 +2542,10 @@ int del_perf_probe_events(struct strlist *dellist)
> event = str;
> }
>
> + /* Skip the leading dot on powerpc */
> + if (event && *event == '.')
> + event++;
I'll defer to the perf guys, but I think you want these abstracted in an
architecture specific helper.
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 0783311..cc04475 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -137,6 +137,12 @@ static int choose_best_symbol(struct symbol *syma,
> struct symbol *symb)
> if (na >= 10 && !strncmp(syma->name, "compat_SyS", 10))
> return SYMBOL_B;
>
> + /* On powerpc, ignore the dot variants */
> + if (na >= 4 && !strncmp(syma->name, ".SyS", 4))
> + return SYMBOL_B;
> + if (na >= 11 && !strncmp(syma->name, ".compat_SyS", 11))
> + return SYMBOL_B;
And possibly this too.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 6/9] ARM: SoC DT updates for 3.19
On Tuesday 09 December 2014 15:45:58 Linus Torvalds wrote: > On Tue, Dec 9, 2014 at 1:40 PM, Arnd Bergmann wrote: > > > > ARM: SoC DT updates for 3.19 > > > > 267 files changed, 18516 insertions(+), 2823 deletions(-) > > Hmm. This is not what I get. I get > > + 297 files changed, 20490 insertions(+), 3332 deletions(-) > > largely due to > > + arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 41 +- > + arch/arm/boot/dts/omap-zoom-common.dtsi| 62 +- > + arch/arm/boot/dts/omap2420-n8x0-common.dtsi| 4 +- > + arch/arm/boot/dts/omap2420.dtsi| 1 + > + arch/arm/boot/dts/omap2430-sdp.dts | 28 +- > + arch/arm/boot/dts/omap2430.dtsi| 1 + > + arch/arm/boot/dts/omap3-cm-t3517.dts | 11 + > + arch/arm/boot/dts/omap3-cm-t3530.dts | 11 + > + arch/arm/boot/dts/omap3-cm-t3730.dts | 24 + > + arch/arm/boot/dts/omap3-cm-t3x.dtsi| 151 > + arch/arm/boot/dts/omap3-devkit8000.dts | 4 +- > + arch/arm/boot/dts/omap3-evm-37xx.dts | 5 +- > + arch/arm/boot/dts/omap3-gta04.dtsi | 86 +- > + arch/arm/boot/dts/omap3-igep.dtsi | 103 ++- > + arch/arm/boot/dts/omap3-igep0020-common.dtsi | 246 ++ > + arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 45 + > + arch/arm/boot/dts/omap3-igep0020.dts | 285 +-- > + arch/arm/boot/dts/omap3-igep0030-common.dtsi | 60 ++ > + arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 67 ++ > + arch/arm/boot/dts/omap3-igep0030.dts | 123 +-- > + arch/arm/boot/dts/omap3-ldp.dts| 3 +- > + arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 2 +- > + arch/arm/boot/dts/omap3-n900.dts | 51 +- > + arch/arm/boot/dts/omap3-n950-n9.dtsi | 4 +- > + arch/arm/boot/dts/omap3-sb-t35.dtsi| 126 ++- > + arch/arm/boot/dts/omap3-sbc-t3517.dts | 15 + > + arch/arm/boot/dts/omap3-sbc-t3530.dts | 15 + > + arch/arm/boot/dts/omap3-sbc-t3730.dts | 15 + > + arch/arm/boot/dts/omap3-tao3530.dtsi | 2 +- > + arch/arm/boot/dts/omap3.dtsi | 1 + > + arch/arm/boot/dts/omap3430-sdp.dts | 8 +- > + arch/arm/boot/dts/omap4.dtsi | 1 + > + arch/arm/boot/dts/omap5.dtsi | 1 + > > much of which seems to have come in through that > > Merge tag 'omap-for-v3.19/dt-part1' of > git://git.kernel.org/.../tmlind/linux-omap into next/dt > > but the diffstat isn't there, nor are the actual commits are mentioned > in the shortlog. > > Hmm? > > I've applied 1-5, but I'm going to stop here waiting for confirmation > of what's going on.. > Ah, sorry about that. I noticed the difference because these happened to be in both the drivers and the dt branch, and I changed the order of the branches to have dt come first so you'd see these as part of dt, not drivers. I fixed up the drivers pull request to regenerate the diffstat the way it was supposed to look like, but I couldn't easily redo the dt diffstat without merging all branches one more time into a test branch. I should probably do that next time. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Wednesday, December 10, 2014 17:08 PM > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY Srinivasan; Haiyang Zhang > Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work > > Dexuan Cui writes: > > > Thanks, > > -- Dexuan > > > >> -Original Message- > >> From: Dexuan Cui > >> Sent: Wednesday, December 10, 2014 15:34 PM > >> To: 'Vitaly Kuznetsov' > >> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- > >> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > >> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang > >> Subject: RE: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection > work > >> > >> > -Original Message- > >> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > >> > Sent: Tuesday, December 9, 2014 21:06 PM > >> > To: Dexuan Cui > >> > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > driverdev- > >> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > >> > jasow...@redhat.com; KY Srinivasan; Haiyang Zhang > >> > Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection > work > >> > .. > >> > > + * Here "dhcp_enabled" is only for IPv4 according to Hyper-V > >> > > host > >> > team. > >> > > + * > >> > > + * In the case the host only injects 1 IPv6 address: > >> > > + * new_val->dhcp_enabled is true, but we can't pass > >> > BOOTPROTO=dhcp to > >> > > + * the script hv_set_ifconfig, because in some distros (like > >> > > RHEL7) > >> > > + * BOOTPROTO=dhcp has a special meaning in the config file > >> > > (e.g., > >> > > + * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init > >> > program > >> > > + * ignores any static IP addr information once there is > >> > > + * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work. > >> > > + * > >> > > + * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't > >> > > affect > >> > > + * Ubuntu because it's ignored by the Ubuntu version of > >> > > + * hv_set_ifconfig and it doesn't seem to have special meaning > >> > > in > >> > > + * Ubuntu. > >> > > + */ > >> > > >> > I just checked and adding "IPV6ADDR=something" when > >> "BOOTPROTO=dhcp" > >> > works for me with both RHEL7 and Fedora21. > >> It doesn't work in my side. :-( > >> Running 'ifup eth0' shows some errors(I use "set -x") > >> ... > >> + /sbin/dhclient -H localhost -1 -q -lf > >> /var/lib/dhclient/dhclient--eth0.lease > -pf > >> /var/run/dhclient-eth0.pid eth0 > >> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied. > > BTW, I run with root, and > > 'chown 777 /etc/sysconfig/network-scripts/ifcfg-eth0" doesn't help. > > > > s,chown,chmod, :-) But it won't help in case of SELinux mislabeling. > > > Thanks, > > -- Dexuan > > -- > Vitaly Hi Vitally, I think you're correct: BOOTPROTO=dhcp + "no IPADDR" + IPV6ADDR in RHEL7's /etc/sysconfig/network-scripts/ifcfg-eth0 works for me too. My previous "grep: ... ifcfg-eth0: Permission denied" issue can't repro now. Maybe it's because I messed up the config file somehow(?). I'll send out a v2 patch according to your suggestion. Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/8] perf probe powerpc: Allow matching against dot symbols
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote:
> Allow perf probe to work on powerpc ABIv1 without the need to specify the
> leading dot '.' for functions. 'perf probe do_fork' works with this patch.
>
> Signed-off-by: Naveen N. Rao
> ---
> tools/perf/util/probe-event.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index d465f7c..174c22e 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2221,6 +2221,15 @@ static int probe_function_filter(struct map *map
> __maybe_unused,
> num_matched_functions++;
> return 0;
> }
> +#ifdef __powerpc64__
> + /* Allow matching against the dot variant */
> + if (sym->name[0] == '.' && looking_function_name[0] != '.' &&
> + (sym->binding == STB_GLOBAL || sym->binding == STB_LOCAL) &&
> + strcmp(looking_function_name, sym->name+1) == 0) {
> + num_matched_functions++;
> + return 0;
> + }
> +#endif
As for the previous patch, I think this should be in an arch helper.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv2 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
On wto, 2014-12-09 at 23:12 +0900, Chanwoo Choi wrote: > This patchset add new devfreq_event class to provide raw data to determine > current utilization of device which is used for devfreq governor. > > [Description of devfreq-event class] > This patchset add new devfreq_event class for devfreq_event device which > provide > raw data (e.g., memory bus utilization/GPU utilization). This raw data from > devfreq_event data would be used for the governor of devfreq subsystem. > - devfreq_event device : Provide raw data for governor of existing devfreq > device > - devfreq device : Monitor device state and change frequency/voltage of > device > using the raw data from devfreq_event device > > The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) > for Non-CPU Devices. The devfreq device would dertermine current device state > using various governor (e.g., ondemand, performance, powersave). After > completed > determination of system state, devfreq device would change the > frequency/voltage > of devfreq device according to the result of governor. > > But, devfreq governor must need basic data which indicates current device > state. > Existing devfreq subsystem only consider devfreq device which check current > system > state and determine proper system state using basic data. There is no > subsystem > for device providing basic data to devfreq device. > > The devfreq subsystem must need devfreq_event device(data-provider device) for > existing devfreq device. So, this patch add new devfreq_event class for > devfreq_event device which read various basic data(e.g, memory bus > utilization, > GPU utilization) and provide measured data to existing devfreq device through > standard APIs of devfreq_event class. > > The following description explains the feature of two kind of devfreq class: > - devfreq class (existing) > : devfreq consumer device use raw data from devfreq_event device for >determining proper current system state and change voltage/frequency >dynamically using various governors. > - devfreq_event class (new) > : Provide measured raw data to devfreq device for governor > > Also, the devfreq-event device would support various type event as following: > : DEVFREQ_EVENT_TYPE_RAW_DATA > : DEVFREQ_EVENT_TYPE_UTILIZATION > : DEVFREQ_EVENT_TYPE_BANDWIDTH > : DEVFREQ_EVENT_TYPE_LATENCY > > [For example] > If board dts includes PPMU_DMC0/DMC1/CPU event node, > would show following sysfs entry. Also devfreq driver(e.g., exynos4_bus.c) > can get the instance of devfreq-event device by using provided API and then > get raw data which reflect the current state of device. > Hi, Overall I like the idea. I understand that now devfreq devices (like exynos devfreq) should bind themselves to buses, not to PPMU. It makes sense to me because bus clock and bus voltage are properties of bus, not monitoring unit. I see that this is still a RFC so it would be hard to base current devfreq work on top of it. One more general comment: you're adding a some API which is not used by current devfreq_event user (exynos). For example the exclusive flag or event types. I think it will be simpler to stick to the basic approach (reduced API). If some other user emerges then new API will be added. Best regards, Krzysztof > -sh-3.2# pwd > /sys/class/devfreq_event > -sh-3.2# ls -al > total 0 > drwxr-xr-x 2 root root 0 Jan 7 11:10 . > drwxr-xr-x 37 root root 0 Jan 7 11:10 .. > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.0 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.0 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.1 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.1 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.2 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.2 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.3 -> > ../../devices/soc/106a.ppmu_dmc0/devfreq_event/event.3 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.4 -> > ../../devices/soc/106b.ppmu_dmc1/devfreq_event/event.4 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.5 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.5 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.6 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.6 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.7 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.7 > lrwxrwxrwx 1 root root 0 Jan 7 11:10 event.8 -> > ../../devices/soc/106c.ppmu_cpu/devfreq_event/event.8 > > Changes from v1: > - Code clean > - Add the description of devfreq-event structure > - Add 'is_enabled' function to devfreq_event_ops structure > - Add 'enable_count' field to devfreq_event_dev structure > - Check whether devfreq-event device is enabled or not > during calling devfreq_event API > - Define the type of devfreq-event device as following > : DEVFREQ_EVENT_TYPE_RAW_DATA > : DEVFREQ_EVENT_TYPE_UTILIZATION > : DEVFREQ_EVENT_TYPE_BANDWIDTH > : DEVFRE
Re: linux-next: build failure after merge of the net-next tree
On Wed, Dec 10, 2014 at 19:54:05 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/chelsio/cxgb4vf/built-in.o:(.opd+0x630): multiple
> definition of `t4_bar2_sge_qregs'
> drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.opd+0x14d0): first defined
> here
> drivers/net/ethernet/chelsio/cxgb4vf/built-in.o: In function
> `.t4_bar2_sge_qregs':
> (.text+0x9220): multiple definition of `.t4_bar2_sge_qregs'
> drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.text+0x24e24): first defined
> here
>
> Caused by commit e85c9a7abfa4 ("cxgb4/cxgb4vf: Add code to calculate T5
> BAR2 Offsets for SGE Queue Registers") which added both versions. :-(
>
> I have applied this fir patch for today (including the subject
> typo :-)):
>
My bad. Thanks for the fix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] livepatch v5: avoid race when checking for state of the patch
On Tue 2014-12-09 12:32:49, Josh Poimboeuf wrote:
> On Tue, Dec 09, 2014 at 07:05:02PM +0100, Petr Mladek wrote:
> > klp_patch_enable() and klp_patch_disable() should check the current state
> > of the patch under the klp_lock. Otherwise, it might detect that the
> > operation
> > is valid but the situation might change before it takes the lock.
>
> Hi Petr,
>
> Thanks for the patches.
>
> I don't think this patch is necessary. klp_is_enabled() doesn't check
> the state of the patch. It checks the initialization state of the core
> module (klp_root_kobj), which can only be set in klp_init(). It's not
> protected by the lock, so I don't see the point of this patch.
Ah, I have misread the name and expected that it checked whether
the patch was enabled or disabled. The original code is OK then.
Well, Jiri Kosina pointed out that the check did not make much sense.
klp_is_enabled() could not be called if the livepatch module is not
loaded. And the later check for klp_patch_is_registered() is enough
to check whether the klp_enable_patch()/klp_disable_patch() calls
are allowed or not.
So, I suggest to remove the checks at all.
Best Regards,
Petr
> >
> > Signed-off-by: Petr Mladek
> > ---
> > kernel/livepatch/core.c | 16 ++--
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index d6d0f50e81f8..b848069e44cc 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -425,11 +425,13 @@ int klp_disable_patch(struct klp_patch *patch)
> > {
> > int ret;
> >
> > - if (!klp_is_enabled())
> > - return -ENODEV;
> > -
> > mutex_lock(&klp_mutex);
> >
> > + if (!klp_is_enabled()) {
> > + ret = -ENODEV;
> > + goto err;
> > + }
> > +
> > if (!klp_patch_is_registered(patch)) {
> > ret = -EINVAL;
> > goto err;
> > @@ -489,11 +491,13 @@ int klp_enable_patch(struct klp_patch *patch)
> > {
> > int ret;
> >
> > - if (!klp_is_enabled())
> > - return -ENODEV;
> > -
> > mutex_lock(&klp_mutex);
> >
> > + if (!klp_is_enabled()) {
> > + ret = -ENODEV;
> > + goto err;
> > + }
> > +
> > if (!klp_patch_is_registered(patch)) {
> > ret = -EINVAL;
> > goto err;
> > --
> > 1.8.5.2
> >
>
> --
> Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 6/8] perf tools powerpc: Fix PPC64 ELF ABIv2 symbol decoding
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote:
> PPC64 ELF ABIv2 has a Global Entry Point (GEP) and a Local Entry Point
> (LEP). For purposes of probing, we need the LEP. Offset to the LEP is
> encoded in st_other.
>
> diff --git a/tools/perf/arch/powerpc/util/elf-sym-decode.c
> b/tools/perf/arch/powerpc/util/elf-sym-decode.c
> new file mode 100644
> index 000..7434656
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/elf-sym-decode.c
> @@ -0,0 +1,27 @@
> +/*
> + * Decode offset from Global Entry Point to Local Entry Point on PPC64
> + * ELF ABIv2.
> + *
> + * Derived from definitions in arch/powerpc/kernel/module_64.c
> + *
> + * Copyright (C) 2014 Ananth N Mavinakayanahalli, IBM Corporation.
> + *
> + * 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.
> + */
> +
> +#include
> +#include "elf_sym.h"
> +
> +/* PowerPC64 ABIv2 specific values for the ELF64_Sym st_other field. */
> +#define STO_PPC64_LOCAL_BIT 5
> +#define STO_PPC64_LOCAL_MASK (7 << STO_PPC64_LOCAL_BIT)
> +#define PPC64_LOCAL_ENTRY_OFFSET(other)
> \
> + (((1 << (((other) & STO_PPC64_LOCAL_MASK) >> STO_PPC64_LOCAL_BIT)) >> 2) <<
> 2)
You're in userspace, you should be able to get these from elf.h
> +unsigned int arch_elf_sym_decode_offset(GElf_Sym *sym)
> +{
> + return PPC64_LOCAL_ENTRY_OFFSET(sym->st_other);
What happens on ABIv1 ? We hope st_other is zero?
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index 67e4392..92a424e 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -10,6 +10,7 @@
> #include "vdso.h"
> #include
> #include "debug.h"
> +#include "elf_sym.h"
>
> #ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
> static int elf_getphdrnum(Elf *elf, size_t *dst)
> @@ -848,6 +849,13 @@ int dso__load_sym(struct dso *dso, struct map *map,
> (sym.st_value & 1))
> --sym.st_value;
>
> + /*
> + * PPC64 ELF ABIv2 encodes Local Entry Point offset in
> + * the st_other field
> + */
> + if ((map->type == MAP__FUNCTION) && sym.st_other)
> + sym.st_value += arch_elf_sym_decode_offset(&sym);
I guess no other arch has needed to do anything like this.
But if they did it's unlikely they'll want to do the exact same logic, ie.
check st_other and add some value to st_value. To make it more generically
useful you could just make it:
> + if (map->type == MAP__FUNCTION)
> + arch_elf_sym_decode(&sym);
And do any other checks in the arch routine.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: esp_scsi: make number of tags configurable
On Tue, Dec 9, 2014 at 6:36 AM, Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Commit: 3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Parent: a87bf29362c763cf35faa17154b699471a8b902e
> Refname:refs/heads/master
> Author: Hannes Reinecke
> AuthorDate: Mon Nov 24 15:37:20 2014 +0100
> Committer: Christoph Hellwig
> CommitDate: Mon Nov 24 16:10:23 2014 +0100
>
> esp_scsi: make number of tags configurable
>
> Add a field 'num_tags' to the esp structure to allow drivers
> to overwrite the number of avialable tags if required.
> Default is ESP_DEFAULT_TAGS.
>
> Reviewed-by: Paolo Bonzini
> Acked-by: David S. Miller
> Signed-off-by: Hannes Reinecke
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/esp_scsi.c | 12 ++--
> drivers/scsi/esp_scsi.h | 3 +--
> 2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 7e7687f..57ccb14 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2317,6 +2317,10 @@ int scsi_esp_register(struct esp *esp, struct device
> *dev)
> static int instance;
> int err;
>
> + if (!esp->num_tags)
> + esp->num_tags = ESP_DEFAULT_TAGS;
> + else if (esp->num_tags >= ESP_MAX_TAG)
drivers/scsi/esp_scsi.c: In function ‘scsi_esp_register’:
drivers/scsi/esp_scsi.c:2399: warning: comparison is always false due
to limited range of data type
ESP_MAX_TAG is 256, num_tags is u8.
> + esp->num_tags = ESP_MAX_TAG - 1;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 7/8] perf probe powerpc: Use DWARF info only if necessary
On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote:
> Use symbol table lookups by default if DWARF is not necessary, since
> powerpc ABIv2 encodes local entry points in the symbol table and the
> function entry address in DWARF may not be appropriate for kprobes,
> as described here:
> https://sourceware.org/bugzilla/show_bug.cgi?id=17638
Needs a better changelog.
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 174c22e..adcdbd2 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2382,6 +2382,14 @@ static int convert_to_probe_trace_events(struct
> perf_probe_event *pev,
> }
> }
>
> +#if defined(__powerpc64__) && defined(_CALL_ELF) && _CALL_ELF == 2
> + if (!perf_probe_event_need_dwarf(pev)) {
> + ret = find_probe_trace_events_from_map(pev, tevs, max_tevs,
> target);
> + if (ret > 0)
> + return ret; /* Found in symbol table */
> + }
> +#endif
And should be in an arch helper, not a big powerpc wart dropped in the middle
of the generic code.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: staging: writeboost: Add dm-writeboost
Hi, > BUT if you'd still like dm-writeboost to go into staging > _without_ any of these 5 work items being completed I'll ack it but to > be very clear: dm-writeboost will not migrate out of staging until these > items are resolved. Yes. I will go into staging. Greg, I will send you a patch with some fixes on TODO. I agree with the 5 work times to be done for md. I add some comments below, >> i) Get this test so it's performance is similar to raw spindle. Yes. >> ii) Write good documentation in Documentation/device-mapper/. eg. How >> do I remove a cache? When should I use dm-writeboost rather than >> bcache or dm-cache? >> >> iii) Provide an equivalent to the fsck tool to repair a damaged cache. OK. I took a look at tools for DM-cache. I will implement something similar. But please remember, since Writeboost is log-structured fsck tools aren't essentially needed. On power failure, some logs at the head may be half done and discarding these logs can roll the state back. > iv) perform full code review to catch various implementation issues, > any style nits, etc. > v) explore/implement read caching support (could the lack of read > caching be contributing to why the git_extract test is so poor?) This will be my first work in staging. - Akira On 12/10/14 12:48 AM, Mike Snitzer wrote: > On Tue, Dec 09 2014 at 10:12am -0500, > Joe Thornber wrote: > >> On Mon, Dec 08, 2014 at 06:04:41AM +0900, Akira Hayakawa wrote: >>> Mike and Alasdair, >>> I need your ack >> >> Hi Akira, >> >> I just spent some time playing with your latest code. On the positive >> side I am seeing some good performance with the fio tests. Which is >> great, we know your design should outperform dm-cache with small >> random io. >> >> However I'm still getting v. poor results with the git-extract test, >> which clones a linux kernel repo, and then checks out 5 revisions, all >> with drop_caches in between. > > Thanks for re-evaluating dm-writeboost performance Joe. > >> It's fine to have different benefits of the caching software depending >> on the load. But I think the worst case should always be close to the >> performance of the raw spindle device. >> >> If you get the following work items done I will ack to go upstream: >> >> i) Get this test so it's performance is similar to raw spindle. >> >> ii) Write good documentation in Documentation/device-mapper/. eg. How >> do I remove a cache? When should I use dm-writeboost rather than >> bcache or dm-cache? >> >> iii) Provide an equivalent to the fsck tool to repair a damaged cache. > > I agree with this TODO list. But I'd also add: > iv) perform full code review to catch various implementation issues, > any style nits, etc. > > v) explore/implement read caching support (could the lack of read > caching be contributing to why the git_extract test is so poor?) > > Item iv) would be a task for myself and anyone else interested in > getting dm-writeboost ready for inclusion. Akira, I can start working > on dm-writeboost code review once I complete review of the dm-dedup > target (my current priority) -- but realistically that likely won't be > until the new year. > > BTW, I'm really not seeing much point putting dm-writeboost in staging. > I'd be happy to take dm-writeboost into drivers/md/ once the above list > is resolved. BUT if you'd still like dm-writeboost to go into staging > _without_ any of these 5 work items being completed I'll ack it but to > be very clear: dm-writeboost will not migrate out of staging until these > items are resolved. > > Thanks, > Mike > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] tools: hv: kvp_daemon: make IPv6-only-injection work
In the case the host only injects an IPv6 address, the dhcp_enabled flag is
true (it's only for IPv4 according to Hyper-V host team), but we still need to
proceed to parse the IPv6 information.
Cc: Vitaly Kuznetsov
Cc: K. Y. Srinivasan
Signed-off-by: Dexuan Cui
---
v2: removed the distro-specific logic as Vitaly suggested.
tools/hv/hv_kvp_daemon.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6a6432a..4b3ee35 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1308,16 +1308,17 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
if (error)
goto setval_error;
+ /*
+* The dhcp_enabled flag is only for IPv4. In the case the host only
+* injects an IPv6 address, the flag is true, but we still need to
+* proceed to parse and pass the IPv6 information to the
+* disto-specific script hv_set_ifconfig.
+*/
if (new_val->dhcp_enabled) {
error = kvp_write_file(file, "BOOTPROTO", "", "dhcp");
if (error)
goto setval_error;
- /*
-* We are done!.
-*/
- goto setval_done;
-
} else {
error = kvp_write_file(file, "BOOTPROTO", "", "none");
if (error)
@@ -1345,7 +1346,6 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
if (error)
goto setval_error;
-setval_done:
fclose(file);
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/16] genirq: Introduce callback irq_chip.irq_write_msi_msg
On Wed, 10 Dec 2014, Yun Wu (Abel) wrote: > On 2014/11/19 19:11, Thomas Gleixner wrote: > I spent last two weeks implementing and testing my original idea about making > the sub domains generic, based on stacked domain feature. Now it comes real, > please see the attached patch. Can you please send patches inline? Attached is a pain to reply to. > With this patch applied, I think things will get easier. I don't see what gets easier. It's just another infrastructure which is painfully similar to MSI. > This patch (also with several other patches) is tested on Hisilicon ARM64 SoC, > with non PCI devices capable of message based interrupts. The PCI part is not > tested because it needs large refactoring work to do. So yes, the testing work > is not sufficient, but I think the patch is enough to present what I really > wanted to express. :) Not really. If you provide proper patches which make use of it and most important a proper refactoring of the PCI/MSI side then we can discuss that, but for now it's just handwaving. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/8] kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2
On 2014/12/10 08:37PM, Michael Ellerman wrote: > On Tue, 2014-12-09 at 23:03 +0530, Naveen N. Rao wrote: > > Currently, all non-dot symbols are being treated as function descriptors > > in ABIv1. This is incorrect and is resulting in perf probe not working: > > I don't understand that first sentence. With ABIv1 non-dot symbols *are* > function descriptors? Not always. '_text' is an example of a symbol that is not a function descriptor. However, most functions have a dot variant constituting the actual entry point and a non-dot variant constituting the function descriptor. > > > # perf probe do_fork > > Added new event: > > Failed to write event: Invalid argument > > Error: Failed to add events. > > # dmesg | tail -1 > > [192268.073063] Could not insert probe at _text+768432: -22 > > > > _text is being resolved incorrectly and is resulting in the above error. > > Fix this by changing how we lookup symbol addresses on ppc64. We first > > check for the dot variant of a symbol and look at the non-dot variant > > only if that fails. In this manner, we avoid having to look at the > > function descriptor. > > I'm not clear that ppc_local_function_entry() makes sense. On ABIv2 you return > the local entry point, which is fine. But on ABIv1 you just return the > unmodified address, which will be the descriptor if you actually passed it a > function pointer. I think you're assuming that you're passed the text address, > but if that's the case the function is badly named at least. > > I also don't understand why we need to ever guess which ABI we're using. We > know which ABI we're built with, so there should be no guess work required. > > So at the very least this needs much more explanation. > > But to be honest I'm not clear why it even needs a kernel change, don't we > just > need perf to understand dot symbols? The problem in this case is in the kernel. perf probe is now basing all probe addresses on _text and writes, for example, "p:probe/do_fork _text+768432" to /sys/kernel/debug/tracing/kprobe_events. This ends up in kprobe_lookup_name() for resolving address of _text, which invokes ppc_function_entry(), which ends up thinking _text is a function descriptor. Even though we know we are compiled for ABIv1, there is no easy way to identify if a given symbol is the actual entry point or if it is a function descriptor. To address this, my approach is to always check for a dot symbol first and if that exists, we know we have the actual function entry. If not, we know this isn't a function descriptor (since there is no related dot symbol). I agree that the function is named badly though. The real problem is that kprobe_lookup_name is a macro and I can't have a #ifdef to call ppc_function_entry() only for ABIv2. Thoughts? Suggestions? Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] livepatch v5: split init and free code that is done only for loaded modules
On Tue 2014-12-09 12:51:41, Josh Poimboeuf wrote:
> On Tue, Dec 09, 2014 at 07:05:06PM +0100, Petr Mladek wrote:
> > This patch makes it clear what initialization and freeing steps need to be
> > done
> > when an object (module) is being loaded or removed. It will help to maintain
> > the module coming and going handlers. Also it will remove duplicated
> > code from these handlers.
> >
> > Signed-off-by: Petr Mladek
> > ---
> > kernel/livepatch/core.c | 92
> > -
> > 1 file changed, 61 insertions(+), 31 deletions(-)
> >
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index 97a8d4a3d6d8..fe312b9ada78 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -590,6 +590,12 @@ static struct kobj_type klp_ktype_func = {
> > .sysfs_ops = &kobj_sysfs_ops,
> > };
> >
> > +/* Clean up when a patched object is unloaded */
> > +static void klp_free_func_loaded(struct klp_func *func)
> > +{
> > + func->old_addr = 0;
> > +}
> > +
> > /*
> > * Free all functions' kobjects in the array up to some limit. When limit
> > is
> > * NULL, all kobjects are freed.
> > @@ -603,6 +609,17 @@ static void klp_free_funcs_limited(struct klp_object
> > *obj,
> > kobject_put(&func->kobj);
> > }
> >
> > +/* Clean up when a patched object is unloaded */
> > +static void klp_free_object_loaded(struct klp_object *obj)
> > +{
> > + struct klp_func *func;
> > +
> > + obj->mod = NULL;
> > +
> > + for (func = obj->funcs; func->old_name; func++)
> > + klp_free_func_loaded(func);
> > +}
> > +
> > /*
> > * Free all objects' kobjects in the array up to some limit. When limit is
> > * NULL, all kobjects are freed.
> > @@ -626,6 +643,12 @@ static void klp_free_patch(struct klp_patch *patch)
> > kobject_put(&patch->kobj);
> > }
> >
> > +/* parts of the initialization that is done only when the object is loaded
> > */
> > +static int klp_init_func_loaded(struct klp_object *obj, struct klp_func
> > *func)
> > +{
> > + return klp_find_verify_func_addr(obj, func);
> > +}
> > +
>
> Creating a new function here for one line of code, which is only called
> once, seems excessive, and makes the code harder to understand IMO.
I see your point. Well, note that the split code is code is called
twice from klp_init_object() and klp_module_coming(), so it helps
to remove the code duplicity.
Also it clearly separates the operations that are always done
and that are done only when the object is loaded.
If you suggest to call klp_find_verify_func_addr() directly
from klp_init_object_loaded(), I am fine with it. We could always
create it later if there are more operations needed for
struct func.
> Ditto for klp_free_func_loaded.
Note that there will be two lines if we agree to add old_ip into
struct klp_func.
If it handles only old_addr, I agree with moving the one line to
klp_free_object_loaded().
Best Regards,
Petr
> > static int klp_init_func(struct klp_object *obj, struct klp_func *func)
> > {
> > struct ftrace_ops *ops;
> > @@ -633,10 +656,6 @@ static int klp_init_func(struct klp_object *obj,
> > struct klp_func *func)
> >
> > func->state = KLP_DISABLED;
> >
> > - ret = klp_find_verify_func_addr(obj, func);
> > - if (ret)
> > - return ret;
> > -
> > ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> > if (!ops)
> > ret = -ENOMEM;
> > @@ -656,6 +675,28 @@ static int klp_init_func(struct klp_object *obj,
> > struct klp_func *func)
> > return 0;
> > }
> >
> > +/* parts of the initialization that is done only when the object is loaded
> > */
> > +static int klp_init_object_loaded(struct klp_patch *patch,
> > + struct klp_object *obj)
> > +{
> > + struct klp_func *func;
> > + int ret;
> > +
> > + if (obj->relocs) {
> > + ret = klp_write_object_relocations(patch->mod, obj);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + for (func = obj->funcs; func->old_name; func++) {
> > + ret = klp_init_func_loaded(obj, func);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int klp_init_object(struct klp_patch *patch, struct klp_object *obj)
> > {
> > struct klp_func *func;
> > @@ -669,12 +710,6 @@ static int klp_init_object(struct klp_patch *patch,
> > struct klp_object *obj)
> >
> > klp_find_object_module(obj);
> >
> > - if (obj->relocs && klp_is_object_loaded(obj)) {
> > - ret = klp_write_object_relocations(patch->mod, obj);
> > - if (ret)
> > - return ret;
> > - }
> > -
> > name = klp_is_module(obj) ? obj->name : "vmlinux";
> > obj->kobj = kobject_create_and_add(name, &patch->kobj);
> > if (!obj->kobj)
> > @@ -686,6 +721,12 @@ static int klp_init_object(struct klp_patch *patch,
> > struct klp_object *obj)
> > got
Re: [PATCH 1/4] pci: iProc: define Broadcom iProc PCIe binding
Am Dienstag, den 09.12.2014, 16:04 -0800 schrieb Ray Jui:
> Document the PCIe device tree binding for Broadcom iProc family of SoCs
>
> Signed-off-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> .../devicetree/bindings/pci/brcm,iproc-pcie.txt| 62
>
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> new file mode 100644
> index 000..2467628
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> @@ -0,0 +1,62 @@
> +* Broadcom iProc PCIe controller
> +
> +Required properties:
> +- compatible: Must be "brcm,iproc-pcie"
> +- reg: base address and length of the PCIe controller and the MDIO interface
> + that controls the PCIe PHY
> +- interrupts: interrupt IDs
> +- bus-range: PCI bus numbers covered
> +- #address-cells: set to <3>
> +- #size-cells: set to <2>
> +- device_type: set to "pci"
> +- ranges: ranges for the PCI memory and I/O regions
> +- phy-addr: MDC/MDIO adddress of the PCIe PHY
> +- have-msi-inten-reg: Required for legacy iProc PCIe controllers that need
> the
> + MSI interrupt enable register to be set explicitly
> +
> +The Broadcom iProc PCie driver adapts the multi-domain structure, i.e., each
> +interface has its own domain and therefore has its own device node
> +Example:
> +
> +SoC specific DT Entry:
> +
> + pcie0: pcie@18012000 {
> + compatible = "brcm,iproc-pcie";
> + reg = <0x18012000 0x1000>,
> + <0x18002000 0x1000>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ;
This is missing the interrupt-map and interrupt-map-mask for the legacy
INTx interrupts. If you add this you don't need to have a special map
function in your driver, but can just use the standard
of_irq_parse_and_map_pci() function.
Regards,
Lucas
> + bus-range = <0x00 0xFF>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x8100 0 0 0x2800 0 0x0001 /*
> downstream I/O */
> + 0x8200 0 0x2000 0x2000 0 0x0400>; /*
> non-prefetchable memory */
> + phy-addr = <5>;
> + };
> +
> + pcie1: pcie@18013000 {
> + compatible = "brcm,iproc-pcie";
> + reg = <0x18013000 0x1000>,
> + <0x18002000 0x1000>;
> +
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + bus-range = <0x00 0xFF>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x8100 0 0 0x4800 0 0x0001 /*
> downstream I/O */
> + 0x8200 0 0x4000 0x4000 0 0x0400>; /*
> non-prefetchable memory */
> + phy-addr = <6>;
> + };
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] gpio: Cygnus: add GPIO driver
On Tue, Dec 9, 2014 at 5:41 AM, Ray Jui wrote:
> This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
> SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller, 2) the
> chipCommonG GPIO controller, and 3) the ALWAYS-ON GPIO controller
>
> Signed-off-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> drivers/gpio/Kconfig | 11 +
> drivers/gpio/Makefile |1 +
> drivers/gpio/gpio-bcm-cygnus.c | 705
>
> 3 files changed, 717 insertions(+)
> create mode 100644 drivers/gpio/gpio-bcm-cygnus.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 633ec21..3e3b0342 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -126,6 +126,17 @@ config GPIO_74XX_MMIO
> 8 bits: 74244 (Input), 74273 (Output)
> 16 bits:741624 (Input), 7416374 (Output)
>
> +config GPIO_BCM_CYGNUS
> + bool "Broadcom Cygnus GPIO support"
> + depends on ARCH_BCM_CYGNUS && OF_GPIO
> + help
> + Say yes here to turn on GPIO support for Broadcom Cygnus SoC
> +
> + The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU
> + GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and
> + the always-ON GPIO controller (CRMU). All 3 GPIO controllers are
> + supported by this driver
> +
> config GPIO_CLPS711X
> tristate "CLPS711X GPIO support"
> depends on ARCH_CLPS711X || COMPILE_TEST
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 81755f1..31eb7e0 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_GPIO_ADP5520)+= gpio-adp5520.o
> obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
> obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
> obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
> +obj-$(CONFIG_GPIO_BCM_CYGNUS) += gpio-bcm-cygnus.o
> obj-$(CONFIG_GPIO_BCM_KONA)+= gpio-bcm-kona.o
> obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
> obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
> diff --git a/drivers/gpio/gpio-bcm-cygnus.c b/drivers/gpio/gpio-bcm-cygnus.c
> new file mode 100644
> index 000..4fd9b73
> --- /dev/null
> +++ b/drivers/gpio/gpio-bcm-cygnus.c
> @@ -0,0 +1,705 @@
> +/*
> + * Copyright (C) 2014 Broadcom Corporation
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define CYGNUS_GPIO_DATA_IN_OFFSET 0x00
> +#define CYGNUS_GPIO_DATA_OUT_OFFSET 0x04
> +#define CYGNUS_GPIO_OUT_EN_OFFSET0x08
> +#define CYGNUS_GPIO_IN_TYPE_OFFSET 0x0c
> +#define CYGNUS_GPIO_INT_DE_OFFSET0x10
> +#define CYGNUS_GPIO_INT_EDGE_OFFSET 0x14
> +#define CYGNUS_GPIO_INT_MSK_OFFSET 0x18
> +#define CYGNUS_GPIO_INT_STAT_OFFSET 0x1c
> +#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20
> +#define CYGNUS_GPIO_INT_CLR_OFFSET 0x24
> +#define CYGNUS_GPIO_PAD_RES_OFFSET 0x34
> +#define CYGNUS_GPIO_RES_EN_OFFSET0x38
> +
> +/* drive strength control for ASIU GPIO */
> +#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
> +
> +/* drive strength control for CCM GPIO */
> +#define CYGNUS_GPIO_CCM_DRV0_CTRL_OFFSET 0x00
> +
> +#define GPIO_BANK_SIZE 0x200
> +#define NGPIOS_PER_BANK 32
> +#define GPIO_BIT(pin) ((pin) % NGPIOS_PER_BANK)
> +#define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK)
> +
> +#define GPIO_FLAG_BIT_MASK 0x
> +#define GPIO_PULL_BIT_SHIFT 16
> +#define GPIO_PULL_BIT_MASK 0x3
> +
> +#define GPIO_DRV_STRENGTH_BIT_SHIFT 20
> +#define GPIO_DRV_STRENGTH_BITS 3
> +#define GPIO_DRV_STRENGTH_BIT_MASK ((1 << GPIO_DRV_STRENGTH_BITS) - 1)
> +
> +/*
> + * For GPIO internal pull up/down registers
> + */
> +enum gpio_pull {
> + GPIO_PULL_NONE = 0,
> + GPIO_PULL_UP,
> + GPIO_PULL_DOWN,
> + GPIO_PULL_INVALID,
> +};
> +
> +/*
> + * GPIO drive strength
> + */
> +enum gpio_drv_strength {
> + GPIO_DRV_STRENGTH_2MA = 0,
> + GPIO_DRV_STRENGTH_4MA,
> + GPIO_DRV_STRENGTH_6MA,
> + GPIO_DRV_STRENGTH_8MA,
> + GPIO_DRV_STRENGTH_10MA,
> + GPIO_DRV_STRENGTH_12MA,
> + GPIO_DRV_STRENGTH_14MA,
> + GPIO_DRV_STRENGTH_16MA,
> + GPIO_DRV_STRENGTH_INVALID,
> +};
> +
> +struct bcm_cygnus_gpio {
> + struct device *dev;
> + void __iomem *base;
> + void __iomem *io_ctrl;
> + spinlock_t lock;
> + struct gpio_chip gc;
> + unsigned num_banks;
> + i
Re: [PATCH v8 1/4] mfd: rt5033: Add Richtek RT5033 driver core.
On 12/09/2014 11:01 PM, Lee Jones wrote:
> On Tue, 09 Dec 2014, Beomho Seo wrote:
>
>> This patch adds a new driver for Richtek RT5033 driver.
>> RT5033 is a Multifunction device which includes battery charger, fuel gauge,
>> flash LED current source, LDO and synchronous Buck converter. It is
>> interfaced
>> to host controller using I2C interface.
>>
>> Cc: Samuel Ortiz
>> Cc: Lee Jones
>> Signed-off-by: Beomho Seo
>> Acked-by: Chanwoo Choi
>> ---
>> Changes in v8
>> - Add description of hardware.
>> - Move structure.
>>
>> Changes in v7
>> - Use small description.
>> - Change some names for a variable.
>> - Revise of_device_id struct style.
>>
>> Changes in v6
>> - Fix white space issue in mfd cell struct.
>>
>> Changes in v5
>> - Change possible built as a module.
>> - Revise rt5033_dev mfd cell entry.
>> - Fix incorrect typo.
>> - Add module alias.
>>
>> Changes in v4
>> - none.
>>
>> Changes in v3
>> - Correct sentence errors.
>> - Add author information the top of each drivers.
>> - Remove unnecessary pre-initialise, struct member(rt5033->i2c) and blink.
>> - Change some return check.
>> - Use bool and of_match_ptr().
>>
>> Changes in v2
>> - Remove volatile_reg callback. Because this driver not in use regmap cache.
>> - Revmoe unnecessary subnode of_compatible.
>> - Add define for set_high impedance mode of charger.
>> ---
>> drivers/mfd/Kconfig| 12 ++
>> drivers/mfd/Makefile |1 +
>> drivers/mfd/rt5033.c | 142
>> include/linux/mfd/rt5033-private.h | 260
>>
>> include/linux/mfd/rt5033.h | 62 +
>> 5 files changed, 477 insertions(+)
>> create mode 100644 drivers/mfd/rt5033.c
>> create mode 100644 include/linux/mfd/rt5033-private.h
>> create mode 100644 include/linux/mfd/rt5033.h
>
> Much better.
>
> For my own reference:
>
> Acked-by: Lee Jones
>
> So what's the plan with this set?
>
This patch have been made on for-next-mfd branch of your git repository.
So I hope this patch to be merged at your git repository.
Another patch set(RT5033 regulator driver) have been merged on for-next branch
of regulator git repository.
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/commit/?h=for-next&id=b1917578fd5d8efa67afa05a0d6d7e323f2802da
Other patches(about charger, fuelgague and devicetree doc) will be re-sent to
each maintainers.
Thank you for response.
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 2e6b731..9cd2af6 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -623,6 +623,18 @@ config MFD_RTSX_PCI
>>types of memory cards, such as Memory Stick, Memory Stick Pro,
>>Secure Digital and MultiMediaCard.
>>
>> +config MFD_RT5033
>> +tristate "Richtek RT5033 Power Management IC"
>> +depends on I2C=y
>> +select MFD_CORE
>> +select REGMAP_I2C
>> +help
>> + This driver provides for the Richtek RT5033 Power Management IC,
>> + which includes the I2C driver and the Core APIs. This driver provides
>> + common support for accessing the device. The device supports multiple
>> + sub-devices like charger, fuel gauge, flash LED, current source,
>> + LDO and Buck.
>> +
>> config MFD_RTSX_USB
>> tristate "Realtek USB card reader"
>> depends on USB
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 53467e2..4059c24 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -176,6 +176,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
>> obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
>> obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
>> obj-$(CONFIG_MFD_DLN2) += dln2.o
>> +obj-$(CONFIG_MFD_RT5033)+= rt5033.o
>>
>> intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>> obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
>> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
>> new file mode 100644
>> index 000..db395a6
>> --- /dev/null
>> +++ b/drivers/mfd/rt5033.c
>> @@ -0,0 +1,142 @@
>> +/*
>> + * MFD core driver for the Richtek RT5033.
>> + *
>> + * RT5033 comprises multiple sub-devices switcing charger, fuel gauge,
>> + * flash LED, current source, LDO and BUCK regulators.
>> + *
>> + * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
>> + * Author: Beomho Seo
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published bythe Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static const struct regmap_irq rt5033_irqs[] = {
>> +{ .mask = RT5033_PMIC_IRQ_BUCKOCP, },
>> +{ .mask = RT5033_PMIC_IRQ_BUCKLV, },
>> +{ .mask = RT5033_PMIC_IRQ_SAFELDOLV, },
>> +{ .mask = RT5033_PMIC_IRQ_LDOLV, },
>> +{ .mask = RT5033_PMIC_IRQ
[PATCH v5 0/3] hwmon: ina2xx: new attributes
This series extends the sysfs interface to make the driver configurable at run-time. The shunt_resistor attribute allows to change the shunt resistance value at run-time in cases where ina2xx used to do the measurement isn't integrated with the shunt. The avg_rate attribute allows to increase/decrease noise reduction. v5: - avoid a "division by zero in kernel" if reading from an uninitialized register v4: https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg781119.html Bartosz Golaszewski (3): hwmon: ina2xx: make shunt resistance configurable at run-time hwmon: ina2xx: allow to change the averaging rate at run-time hwmon: ina2xx: documentation update for new sysfs attributes Documentation/hwmon/ina2xx | 10 ++- drivers/hwmon/ina2xx.c | 199 ++--- 2 files changed, 194 insertions(+), 15 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/3] hwmon: ina2xx: documentation update for new sysfs attributes
Include the rshunt and avg sysfs attributes for ina2xx in the documentation. Signed-off-by: Bartosz Golaszewski --- Documentation/hwmon/ina2xx | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx index 4223c2d..c100c24 100644 --- a/Documentation/hwmon/ina2xx +++ b/Documentation/hwmon/ina2xx @@ -44,6 +44,10 @@ The INA226 monitors both a shunt voltage drop and bus supply voltage. The INA230 is a high or low side current shunt and power monitor with an I2C interface. The INA230 monitors both a shunt voltage drop and bus supply voltage. -The shunt value in micro-ohms can be set via platform data or device tree. -Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings -if the device tree is used. +The shunt value in micro-ohms can be set via platform data or device tree in +compile-time or via the shunt_resistor attribute in sysfs in run-time. Please +refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings if +the device tree is used. + +The averaging rate of INA226 and INA230 can be changed via the avg_rate sysfs +attribute. The available rates are: 1, 4, 16, 64, 128, 256, 512 and 1024. -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/3] hwmon: ina2xx: allow to change the averaging rate at run-time
The averaging rate of ina226 is hardcoded to 16 in the driver.
Make it modifiable at run-time via a new sysfs attribute.
Signed-off-by: Bartosz Golaszewski
---
drivers/hwmon/ina2xx.c | 125 +++--
1 file changed, 122 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 6e73add..b86474e 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -67,6 +67,15 @@
/* default shunt resistance */
#define INA2XX_RSHUNT_DEFAULT 1
+/* bit masks for the averaging setting in the configuration register */
+#define INA226_AVG_RD_MASK 0x0E00
+#define INA226_AVG_WR_MASK 0xF1FF
+
+#define INA226_READ_AVG(reg) ((reg & INA226_AVG_RD_MASK) >> 9)
+
+/* common attrs, ina226 attrs and NULL */
+#define INA2XX_MAX_ATTRIBUTE_GROUPS3
+
enum ina2xx_ids { ina219, ina226 };
struct ina2xx_config {
@@ -88,6 +97,7 @@ struct ina2xx_data {
unsigned long last_updated;
int kind;
+ const struct attribute_group *groups[INA2XX_MAX_ATTRIBUTE_GROUPS];
u16 regs[INA2XX_MAX_REGISTERS];
long rshunt;
@@ -114,11 +124,43 @@ static const struct ina2xx_config ina2xx_config[] = {
},
};
+/*
+ * Available averaging rates for ina226. The indices correspond with
+ * the bit values expected by the chip (according to the ina226 datasheet,
+ * table 3 AVG bit settings, found at
+ * http://www.ti.com/lit/ds/symlink/ina226.pdf.
+ */
+static const int ina226_avg_tab[] = { 1, 4, 16, 64, 128, 256, 512, 1024 };
+
static u16 ina2xx_calibration_val(const struct ina2xx_data *data)
{
return data->config->calibration_factor / data->rshunt;
}
+static int ina226_avg_bits(int avg)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+ if (avg == ina226_avg_tab[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int ina226_avg_val(int bits)
+{
+ /*
+* Value read from the config register should be correct, but do check
+* the boundary just in case.
+*/
+ if (bits >= ARRAY_SIZE(ina226_avg_tab))
+ return -ENODEV;
+
+ return ina226_avg_tab[bits];
+}
+
static struct ina2xx_data *ina2xx_update_device(struct device *dev)
{
struct ina2xx_data *data = dev_get_drvdata(dev);
@@ -235,6 +277,63 @@ static ssize_t ina2xx_set_shunt(struct device *dev,
return count;
}
+static ssize_t ina226_show_avg(struct device *dev,
+ struct device_attribute *da, char *buf)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ int avg, i, written = 0;
+ const char *fmt;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ avg = ina226_avg_val(INA226_READ_AVG(data->regs[INA2XX_CONFIG]));
+ if (avg < 0)
+ return avg;
+
+ for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+ if (avg == ina226_avg_tab[i])
+ fmt = "\t[%d]";
+ else
+ fmt = "\t%d";
+
+ written += snprintf(buf + written, PAGE_SIZE - written,
+ fmt, ina226_avg_tab[i]);
+ }
+ written += snprintf(buf + written, PAGE_SIZE - written, "\n");
+
+ return written;
+}
+
+static ssize_t ina226_set_avg(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ long val;
+ int status, avg;
+ u16 conf;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ status = kstrtol(buf, 10, &val);
+ if (status < 0)
+ return status;
+
+ avg = ina226_avg_bits(val);
+ if (avg < 0)
+ return avg;
+
+ mutex_lock(&data->update_lock);
+ conf = (data->regs[INA2XX_CONFIG] & INA226_AVG_WR_MASK) | (avg << 9);
+ status = i2c_smbus_write_word_swapped(data->client,
+ INA2XX_CONFIG, conf);
+ mutex_unlock(&data->update_lock);
+
+ return count;
+}
+
/* shunt voltage */
static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_value, NULL,
INA2XX_SHUNT_VOLTAGE);
@@ -256,6 +355,10 @@ static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO |
S_IWUSR,
ina2xx_show_value, ina2xx_set_shunt,
INA2XX_CALIBRATION);
+/* averaging rate */
+static SENSOR_DEVICE_ATTR(avg_rate, S_IRUGO | S_IWUSR,
+ ina226_show_avg, ina226_set_avg, 0);
+
/* pointers to created device attributes */
static struct attribute *ina2xx_attrs[] = {
&sensor_dev_attr_in0_input.dev_attr.attr,
@@ -265,7 +368,19 @@ static struct attribute *ina2xx_attrs[] = {
&sensor_dev_attr_shunt_resistor.dev_attr.attr,
NULL,
};
[PATCH v5 1/3] hwmon: ina2xx: make shunt resistance configurable at run-time
The shunt resistance can only be set via platform_data or device tree. This
isn't suitable for devices in which the shunt resistance can change/isn't
known at boot-time.
Add a sysfs attribute that allows to read and set the shunt resistance.
Signed-off-by: Bartosz Golaszewski
---
drivers/hwmon/ina2xx.c | 74 --
1 file changed, 65 insertions(+), 9 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba..6e73add 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -51,7 +51,6 @@
#define INA226_ALERT_LIMIT 0x07
#define INA226_DIE_ID 0xFF
-
/* register count */
#define INA219_REGISTERS 6
#define INA226_REGISTERS 8
@@ -65,6 +64,9 @@
/* worst case is 68.10 ms (~14.6Hz, ina219) */
#define INA2XX_CONVERSION_RATE 15
+/* default shunt resistance */
+#define INA2XX_RSHUNT_DEFAULT 1
+
enum ina2xx_ids { ina219, ina226 };
struct ina2xx_config {
@@ -87,6 +89,8 @@ struct ina2xx_data {
int kind;
u16 regs[INA2XX_MAX_REGISTERS];
+
+ long rshunt;
};
static const struct ina2xx_config ina2xx_config[] = {
@@ -110,6 +114,11 @@ static const struct ina2xx_config ina2xx_config[] = {
},
};
+static u16 ina2xx_calibration_val(const struct ina2xx_data *data)
+{
+ return data->config->calibration_factor / data->rshunt;
+}
+
static struct ina2xx_data *ina2xx_update_device(struct device *dev)
{
struct ina2xx_data *data = dev_get_drvdata(dev);
@@ -164,6 +173,13 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
/* signed register, LSB=1mA (selected), in mA */
val = (s16)data->regs[reg];
break;
+ case INA2XX_CALIBRATION:
+ if (data->regs[reg] == 0)
+ val = 0;
+ else
+ val = data->config->calibration_factor
+ / data->regs[reg];
+ break;
default:
/* programmer goofed */
WARN_ON_ONCE(1);
@@ -187,6 +203,38 @@ static ssize_t ina2xx_show_value(struct device *dev,
ina2xx_get_value(data, attr->index));
}
+static ssize_t ina2xx_set_shunt(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ unsigned long val;
+ int status;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ status = kstrtoul(buf, 10, &val);
+ if (status < 0)
+ return status;
+
+ if (val == 0 ||
+ /* Values greater than the calibration factor make no sense. */
+ val > data->config->calibration_factor ||
+ val > LONG_MAX)
+ return -EINVAL;
+
+ mutex_lock(&data->update_lock);
+ data->rshunt = val;
+ status = i2c_smbus_write_word_swapped(data->client, INA2XX_CALIBRATION,
+ ina2xx_calibration_val(data));
+ mutex_unlock(&data->update_lock);
+ if (status < 0)
+ return status;
+
+ return count;
+}
+
/* shunt voltage */
static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_value, NULL,
INA2XX_SHUNT_VOLTAGE);
@@ -203,12 +251,18 @@ static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO,
ina2xx_show_value, NULL,
static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO, ina2xx_show_value, NULL,
INA2XX_POWER);
+/* shunt resistance */
+static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR,
+ ina2xx_show_value, ina2xx_set_shunt,
+ INA2XX_CALIBRATION);
+
/* pointers to created device attributes */
static struct attribute *ina2xx_attrs[] = {
&sensor_dev_attr_in0_input.dev_attr.attr,
&sensor_dev_attr_in1_input.dev_attr.attr,
&sensor_dev_attr_curr1_input.dev_attr.attr,
&sensor_dev_attr_power1_input.dev_attr.attr,
+ &sensor_dev_attr_shunt_resistor.dev_attr.attr,
NULL,
};
ATTRIBUTE_GROUPS(ina2xx);
@@ -221,7 +275,6 @@ static int ina2xx_probe(struct i2c_client *client,
struct device *dev = &client->dev;
struct ina2xx_data *data;
struct device *hwmon_dev;
- long shunt = 1; /* default shunt value 10mOhms */
u32 val;
int ret;
@@ -234,19 +287,22 @@ static int ina2xx_probe(struct i2c_client *client,
if (dev_get_platdata(dev)) {
pdata = dev_get_platdata(dev);
- shunt = pdata->shunt_uohms;
+ data->rshunt = pdata->shunt_uohms;
} else if (!of_property_read_u32(dev->of_node,
"shunt-resistor", &val)) {
- shunt = val;
+ data->rshunt = va
Re: [PATCH 1/4] gpio/xilinx: remove offset property
On Tue, Dec 9, 2014 at 12:07 AM, Ricardo Ribalda Delgado wrote: > Instead of calculating the register offset per call, pre-calculate it on > probe time. > > Signed-off-by: Ricardo Ribalda Delgado Nice optimization. Acked-by: Alexandre Courbot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Hi Romain: On 2014/12/9 18:41, Romain Perier wrote: Hi, 2014-12-09 3:43 GMT+01:00 Yunzhi Li : Changes in v3: - Use BIT macro instead of bit shift ops. - Rename the config entry to PHY_ROCKCHIP_USB. Contradiction between this , [1] and [2] drivers/phy/Kconfig| 7 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 211 + 3 files changed, 219 insertions(+) create mode 100644 drivers/phy/phy-rockchip-usb.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index ccad880..8a39d2a 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA depends on OF select GENERIC_PHY +config PHY_ROCKCHIP_USB2 + tristate "Rockchip USB2 PHY Driver" + depends on ARCH_ROCKCHIP && OF + select GENERIC_PHY + help + Enable this to support the Rockchip USB 2.0 PHY. + 1. The config entry ends by "USB2". Explain that your driver is for usb 2.0 in the description is enough, imho. config PHY_ST_SPEAR1310_MIPHY tristate "ST SPEAR1310-MIPHY driver" select GENERIC_PHY diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index aa74f96..8a13f72 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o +obj-$(CONFIG_PHY_ROCKCHIP_USB2) += phy-rockchip-usb.o 2. and... this :) So,do you mean that I should rename the C source file as phy-rockchip-usb2.c ? Romain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/8] perf probe powerpc: Fix symbol fixup issues due to ELF type
On 2014/12/10 08:50PM, Michael Ellerman wrote:
> On Tue, 2014-12-09 at 23:04 +0530, Naveen N. Rao wrote:
> > If using the symbol table, symbol addresses are not being fixed up
> > properly, resulting in probes being placed at wrong addresses:
> >
> > # perf probe do_fork
> > Added new event:
> > probe:do_fork(on do_fork)
> >
> > You can now use it in all perf tools, such as:
> >
> > perf record -e probe:do_fork -aR sleep 1
> >
> > # cat /sys/kernel/debug/tracing/kprobe_events
> > p:probe/do_fork _text+635952
> > # printf "%x" 635952
> > 9b430
> > # grep do_fork /boot/System.map
> > c00ab430 T .do_fork
>
> OK, but why is that happening? And why does checking for ET_DYN fix it?
The section header indicates 0x1 as the offset:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS c000 0001
00806678 AX 0 0 256
This is used during fixup and perf only expects this to be needed for
ET_EXEC, though we use ET_DYN on ppc64.
> > Fix by checking for ELF type ET_DYN used by ppc64 kernels.
>
> We sometimes produce ET_DYN kernels, but only if CONFIG_RELOCATABLE=y.
Ok.
- Naveen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] uml panics with "Segfault with no mm" in v3.19-rc
The guilty commit is: 00f634bc522d "asm-generic: add generic futex for !CONFIG_SMP" And the backtrace: #0 0x77866457 in kill () from /lib64/libc.so.6 #1 0x6002a454 in uml_abort () at arch/um/os-Linux/util.c:93 #2 0x6002a7e5 in os_dump_core () at arch/um/os-Linux/util.c:148 #3 0x6001b48a in panic_exit (self=, unused1=, unused2=) at arch/um/kernel/um_arch.c:240 #4 0x6004e4df in notifier_call_chain (nl=, val=6, v=0x, nr_to_call=-1, nr_calls=0x0) at kernel/notifier.c:93 #5 0x6004e558 in __atomic_notifier_call_chain (nr_calls=, nr_to_call=, v=, val=, nh=) at kernel/notifier.c:183 #6 atomic_notifier_call_chain (nh=, val=, v=) at kernel/notifier.c:193 #7 0x60238570 in panic (fmt=) at kernel/panic.c:133 #8 0x6001ad91 in segv (fi=..., ip=1610803493, is_user=, regs=0x602c1840 ) at arch/um/kernel/trap.c:218 #9 0x6001b0f8 in segv_handler (sig=, unused_si=, regs=) at arch/um/kernel/trap.c:191 #10 0x60029238 in sig_handler_common (sig=11, si=0x602c1d30 , mc=) at arch/um/os-Linux/signal.c:44 #11 0x60029304 in sig_handler (sig=, si=, mc=) at arch/um/os-Linux/signal.c:231 #12 0x60028dfd in hard_handler (sig=, si=0x6, p=) at arch/um/os-Linux/signal.c:165 #13 #14 memcpy () at arch/x86/um/../lib/memcpy_64.S:160 #15 0x6001c13d in copy_from_user (to=0x61c49e28, from=, n=) at arch/um/kernel/skas/uaccess.c:145 #16 0x60072618 in futex_atomic_cmpxchg_inatomic (newval=, oldval=, uaddr=, uval=) at include/asm-generic/futex.h:109 #17 cmpxchg_futex_value_locked (curval=0x61c49e28, uaddr=0x0, uval=, newval=) at kernel/futex.c:596 #18 0x60008b70 in futex_detect_cmpxchg () at kernel/futex.c:3020 #19 futex_init () at kernel/futex.c:3043 #20 0x600166ba in do_one_initcall (fn=0x60008adf ) at init/main.c:791 Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/5] Patches to add support for Rockchip usb PHYs.
Patches to add support for Rockchip usb phys.Add a new Rockchip usb phy driver and modify dwc2 controller driver to make dwc2 platform devices support a generic PHY framework driver. This patch set has been tested on my rk3288-evb and power off the usb phys would reduce about 60mW power budget in total during sustem suspend. Changes in v5: - Adjust entry order of example devicetree node in document. - reorder the phy dt node to a correct position. Changes in v4: - Get number of PHYs from device tree. - Model each PHY as subnode of the phy provider node. - Updata description for phy device tree subnode. - Add phy subnodes. Changes in v3: - Use BIT macro instead of bit shift ops. - Rename the config entry to PHY_ROCKCHIP_USB. - Fix coding style: both branches of the if() which only one branch of the conditional statement is a single statement should have braces. - No need to test dwc2->phy for NULL before calling generic phy APIs. Yunzhi Li (5): phy: add a driver for the Rockchip SoC internal USB2.0 PHY Documentation: bindings: add dt documentation for Rockchip usb PHY usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver. ARM: dts: rockchip: add rk3288 usb PHY ARM: dts: rockchip: Enable usb PHY on rk3288-evb board .../devicetree/bindings/phy/rockchip-usb-phy.txt | 32 arch/arm/boot/dts/rk3288-evb.dtsi | 4 + arch/arm/boot/dts/rk3288.dtsi | 27 +++ drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 211 + drivers/usb/dwc2/gadget.c | 33 ++-- drivers/usb/dwc2/platform.c| 36 +++- 8 files changed, 328 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 drivers/phy/phy-rockchip-usb.c -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Shorten efi regions output
On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: > I have same feeling with you, it is too long for most of people. > > Since the printk code are for EFI_DEBUG, they are around the #ifdef > so I would like to see a kernel param like efi_debug=on, so only > efi_debug is specified then these verbose messages are printed. > Without the param kernel can print some basic infomation about the > memory ranges. > > In arm64 code there's already a uefi_debug param it can be moved to > general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with "efi_debug=on" in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Quota improvements and minor cleanups
Hello Linus, could you please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus to get quota improvements and some minor cleanups. The main portion in the pull request are changes which move i_dquot array from struct inode into fs-private part of an inode which saves memory for filesystems which don't use VFS quotas. Top of the tree is fdf2657bc81b. The full shortlog is: Anton Blanchard (1): quota: Add log level to printk Jan Kara (12): quota: Remove const from function declarations quota: Allow each filesystem to specify which quota types it supports gfs2: Set allowed quota types xfs: Set allowed quota types quota: Use function to provide i_dquot pointers ext2: Convert to private i_dquot field ext3: Convert to private i_dquot field ext4: Convert to private i_dquot field ocfs2: Convert to private i_dquot field reiserfs: Convert to private i_dquot field jfs: Convert to private i_dquot field vfs: Remove i_dquot field from inode Markus Elfring (3): jbd: Deletion of an unnecessary check before the function call "iput" udf: Deletion of unnecessary checks before the function call "iput" udf: One function call less in udf_fill_super() after error detection The diffstat is fs/ext2/ext2.h | 3 +++ fs/ext2/super.c | 10 fs/ext3/ext3.h | 4 fs/ext3/super.c | 10 fs/ext4/ext4.h | 4 fs/ext4/super.c | 8 +++ fs/gfs2/ops_fstype.c | 1 + fs/inode.c | 3 --- fs/jbd/journal.c | 3 +-- fs/jfs/jfs_incore.h | 3 +++ fs/jfs/super.c | 9 fs/ocfs2/inode.h | 2 ++ fs/ocfs2/super.c | 8 +++ fs/quota/dquot.c | 59 ++-- fs/quota/quota.c | 13 +-- fs/reiserfs/reiserfs.h | 4 fs/reiserfs/super.c | 11 + fs/udf/super.c | 11 - fs/xfs/xfs_super.c | 1 + include/linux/fs.h | 5 ++-- include/linux/quota.h| 5 include/linux/quotaops.h | 8 +++ 22 files changed, 138 insertions(+), 47 deletions(-) Thanks Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.
Signed-off-by: Yunzhi Li
---
Changes in v5: None
Changes in v4:
- Get number of PHYs from device tree.
- Model each PHY as subnode of the phy provider node.
Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.
drivers/phy/Kconfig| 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-usb.c | 211 +
3 files changed, 219 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..8a39d2a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
+config PHY_ROCKCHIP_USB2
+ tristate "Rockchip USB2 PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip USB 2.0 PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..8a13f72 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
phy-exynos5250-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
+obj-$(CONFIG_PHY_ROCKCHIP_USB2) += phy-rockchip-usb.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 000..0317c21
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,211 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Yunzhi Li
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
+
+/*
+ * The higher 16-bit of this register is used for write protection
+ * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
+ */
+#define SIDDQ_MSK BIT(13 + 16)
+#define SIDDQ_ON BIT(13)
+#define SIDDQ_OFF (0 << 13)
+
+struct rockchip_usb_phy {
+ struct regmap *reg_base;
+ unsigned intreg_offset;
+ struct clk *clk;
+ struct phy *phy;
+ unsignedindex;
+};
+
+struct rockchip_usb_phy_priv {
+ struct rockchip_usb_phy *phys;
+ unsignednphys;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+ bool siddq)
+{
+ return regmap_write(phy->reg_base, phy->reg_offset,
+ SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ /* Power down usb phy analog blocks by set siddq 1 */
+ ret = rockchip_usb_phy_power(phy, 1);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(phy->clk);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ ret = clk_prepare_enable(phy->clk);
+ if (ret)
+ return ret;
+
+ /* Power up usb phy analog blocks by set siddq 0 */
+ ret = rockchip_usb_phy_power(phy, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static struct phy *rockchip_usb_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct rockchip_usb_phy_priv *priv = dev_get_drvdata(dev);
+ int i;
+
+ if (WARN_ON(args->args[0] >= priv->nphys))
+ return ERR_PTR(-ENODEV);
+
+ for (i = 0; i < priv->nphys; i++
Re: [BUG] uml panics with "Segfault with no mm" in v3.19-rc
Hi! Am 10.12.2014 um 11:46 schrieb Miklos Szeredi: > The guilty commit is: > > 00f634bc522d "asm-generic: add generic futex for !CONFIG_SMP" Thanks a lot Miklos! Your bisecting faster than I do. Let's dig into the issue! Thanks, //richard > And the backtrace: > > #0 0x77866457 in kill () from /lib64/libc.so.6 > #1 0x6002a454 in uml_abort () at arch/um/os-Linux/util.c:93 > #2 0x6002a7e5 in os_dump_core () at arch/um/os-Linux/util.c:148 > #3 0x6001b48a in panic_exit (self=, > unused1=, unused2=) at > arch/um/kernel/um_arch.c:240 > #4 0x6004e4df in notifier_call_chain (nl=, val=6, > v=0x, nr_to_call=-1, nr_calls=0x0) at kernel/notifier.c:93 > #5 0x6004e558 in __atomic_notifier_call_chain (nr_calls= out>, nr_to_call=, v=, val=, > nh=) at kernel/notifier.c:183 > #6 atomic_notifier_call_chain (nh=, val=, > v=) at kernel/notifier.c:193 > #7 0x60238570 in panic (fmt=) at kernel/panic.c:133 > #8 0x6001ad91 in segv (fi=..., ip=1610803493, is_user= out>, regs=0x602c1840 ) at arch/um/kernel/trap.c:218 > #9 0x6001b0f8 in segv_handler (sig=, > unused_si=, regs=) at arch/um/kernel/trap.c:191 > #10 0x60029238 in sig_handler_common (sig=11, si=0x602c1d30 > , mc=) at arch/um/os-Linux/signal.c:44 > #11 0x60029304 in sig_handler (sig=, si= out>, mc=) at arch/um/os-Linux/signal.c:231 > #12 0x60028dfd in hard_handler (sig=, si=0x6, > p=) at arch/um/os-Linux/signal.c:165 > #13 > #14 memcpy () at arch/x86/um/../lib/memcpy_64.S:160 > #15 0x6001c13d in copy_from_user (to=0x61c49e28, from= out>, n=) at arch/um/kernel/skas/uaccess.c:145 > #16 0x60072618 in futex_atomic_cmpxchg_inatomic (newval= out>, oldval=, uaddr=, uval=) at > include/asm-generic/futex.h:109 > #17 cmpxchg_futex_value_locked (curval=0x61c49e28, uaddr=0x0, uval= out>, newval=) at kernel/futex.c:596 > #18 0x60008b70 in futex_detect_cmpxchg () at kernel/futex.c:3020 > #19 futex_init () at kernel/futex.c:3043 > #20 0x600166ba in do_one_initcall (fn=0x60008adf ) at > init/main.c:791 > > Thanks, > Miklos > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/5] Documentation: bindings: add dt documentation for Rockchip usb PHY
This patch adds a binding that describes the Rockchip usb PHYs
found on Rockchip SoCs usb interface.
Signed-off-by: Yunzhi Li
---
Changes in v5:
- Adjust entry order of example devicetree node in document.
Changes in v4:
- Updata description for phy device tree subnode.
Changes in v3: None
.../devicetree/bindings/phy/rockchip-usb-phy.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 000..e9500d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,32 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+ register files"
+ - #phy-cells: should be 1
+ - #address-cells: should be 1
+ - #size-cells: should be 0
+
+Sub-nodes:
+Each PHY should be represented as a sub-node.
+
+Sub-nodes
+required properties:
+- reg: the PHY number
+ "0" - PHY connect to OTG controller
+ "1" - PHY connect to HOST0 controller
+ "2" - PHY connect to HOST1 controller
+
+Optional Properties:
+- clocks : phandle + clock specifier for the phy clocks
+
+Example:
+
+usbphy: phy {
+ compatible = "rockchip,rk3288-usb-phy";
+ rockchip,grf = <&grf>;
+ #phy-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
Dexuan Cui writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Tuesday, December 9, 2014 21:06 PM
>> To: Dexuan Cui
>> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
>> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
>> jasow...@redhat.com; KY Srinivasan; Haiyang Zhang
>> Subject: Re: [PATCH] tools: hv: kvp_daemon: make IPv6-only-injection work
>> ..
>> > + * Here "dhcp_enabled" is only for IPv4 according to Hyper-V host
>> team.
>> > + *
>> > + * In the case the host only injects 1 IPv6 address:
>> > + * new_val->dhcp_enabled is true, but we can't pass
>> BOOTPROTO=dhcp to
>> > + * the script hv_set_ifconfig, because in some distros (like RHEL7)
>> > + * BOOTPROTO=dhcp has a special meaning in the config file (e.g.,
>> > + * /etc/sysconfig/network-scripts/ifcfg-eth0): the network init
>> program
>> > + * ignores any static IP addr information once there is
>> > + * BOOTPROTO=dhcp; as a result, IPv6-only injection can't work.
>> > + *
>> > + * In the case of IPv6-only injection, BOOTPROTO=dhcp doesn't affect
>> > + * Ubuntu because it's ignored by the Ubuntu version of
>> > + * hv_set_ifconfig and it doesn't seem to have special meaning in
>> > + * Ubuntu.
>> > + */
>>
>> I just checked and adding "IPV6ADDR=something" when "BOOTPROTO=dhcp"
>> works for me with both RHEL7 and Fedora21.
> It doesn't work in my side. :-(
> Running 'ifup eth0' shows some errors(I use "set -x")
> ...
> + /sbin/dhclient -H localhost -1 -q -lf
> /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid eth0
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> grep: /etc/sysconfig/network-scripts/ifcfg-eth0: Permission dinied.
> done.
>
> I'm trying to find out the cause.
Selinux? You can try 'setenforce 0' to figure this out.
>
>> Other than that I think bringing distribution specifics into kernel.git
>> is not a good idea. /etc/sysconfig/network-scripts/ifcfg-* format is
>> distro-specific and not all Linux distros support it. Moreover,
> I agree.
>
>> different distros can treat setting differently. I think it was wrong to
>> stick to this format in kvp daemon from very beginning.
> We can also think the current format used in kvp daemon is already
> distro-agnostic -- it just happens to look like the style of network config
> file
> used in RHEL :-)
Yes, it is already there and I don't see any point in changing it.
>
>>
>> As a solution I would suggest doing the following: kvp daemon writes all
>> received request details in distro-agnostic format in some temporary
>> place and then calls distro-specific script to set things up. Actually,
>> we already have such script: tools/hv/hv_set_ifconfig.sh
> Yeah, this is exactly what we already have today.
>
>> As for this bug I propose the following: remove skipping all
>> IPADDR/MASK/... settings in case of "BOOTPROTO=dhcp" and let
>> distro-specific script deal with the rest.
>> --
>> Vitaly
> OK, so the patch would be 1-line only:
>
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index 22b0764..53fdaad 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -1314,10 +1314,8 @@ static int kvp_set_ip_info(char *if_name, struct
> hv_kvp_ipaddr_value *new_val)
> goto setval_error;
>
> /*
> -* We are done!.
> +* We are not done... TODO: add comment here.
> */
> - goto setval_done;
> -
> } else {
> error = kvp_write_file(file, "BOOTPROTO", "", "none");
> if (error)
>
> I'll send out a v2 after I resolve the "grep ... Permission dinied" issue.
>
> Thanks,
> -- Dexuan
--
Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
