Re: [PATCH] v4l2: Change call of function in videobuf2-core.c
> > Dave, > I understand your issues with my programming. I need to try and > understand the kernel first before programming > for it. Why do you insist on sending more patches then, every day you try and send another one or two, despite been told multiple times to a) understand what you are writing, b) build test, c) actual test on hw or in a VM if applicable. Frankly I think you are taking the piss, probably writing some stupid Uni thesis on how to subvert the kernel development model by trolling it with broken patches. Dave. -- 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] v4l2: Change call of function in videobuf2-core.c
On Mon, Aug 4, 2014 at 1:43 AM, Nick Krause wrote: > On Mon, Aug 4, 2014 at 1:38 AM, Dave Airlie wrote: >> On 4 August 2014 15:03, Hans Verkuil wrote: >>> On 08/04/2014 05:25 AM, Nicholas Krause wrote: This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR. Signed-off-by: Nicholas Krause >>> >>> Dunno what's going on here after reading Dave Airlie's reply, but: >>> >> >> Nick has decided he wants to be a kernel developer, a laudable goal. >> >> He however has decided not to take any advice given to me by a number of >> other >> kernel developers on how to work on the kernel. So instead he sends random >> broken patches to random subsystems in the hope that one will slip past a >> sleepy >> maintainer and end up in the kernel. >> >> He isn't willing to spend his own time learning anything, he is >> expecting that kernel >> developers want to spoon feed someone who sends them broken patches. >> >> We've asked him to stop, he keeps doing it, then when caught out apologizes >> with something along the lines, of I'm trying to learn, "idiot >> mistake", despite having >> been told to take a step back and try and learn how the kernel works. >> >> Now we have to waste more maintainer time making sure nobody accidentally >> merges anything he sends. >> >> Dave. > All of my merges are not in the main kernel and have been revoked. > Cheers Nick Dave, I understand your issues with my programming. I need to try and understand the kernel first before programming for it. Regards Nick -- 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/
...l2
I need your respond back to me if you are the owner of this email address. I, Liliane authenticate this email, you can read about me on: http://www.en.wikipedia.org/wiki/Liliane_Bettencourt I write to you because I intend to give to you a portion of my Net-worth which I have been banking. I want to cede it out as gift hoping it would be of help to you and others too. Good luck, Mrs Liliane Bettencourt. This message was sent using IMP, the Internet Messaging Program. -- 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] v4l2: Change call of function in videobuf2-core.c
On Mon, Aug 4, 2014 at 1:38 AM, Dave Airlie wrote: > On 4 August 2014 15:03, Hans Verkuil wrote: >> On 08/04/2014 05:25 AM, Nicholas Krause wrote: >>> This patch changes the call of vb2_buffer_core to use >>> VB2_BUFFER_STATE_ACTIVE >>> inside the for instead of not setting in correctly to >>> VB2_BUFFER_STATE_ERROR. >>> >>> Signed-off-by: Nicholas Krause >> >> Dunno what's going on here after reading Dave Airlie's reply, but: >> > > Nick has decided he wants to be a kernel developer, a laudable goal. > > He however has decided not to take any advice given to me by a number of other > kernel developers on how to work on the kernel. So instead he sends random > broken patches to random subsystems in the hope that one will slip past a > sleepy > maintainer and end up in the kernel. > > He isn't willing to spend his own time learning anything, he is > expecting that kernel > developers want to spoon feed someone who sends them broken patches. > > We've asked him to stop, he keeps doing it, then when caught out apologizes > with something along the lines, of I'm trying to learn, "idiot > mistake", despite having > been told to take a step back and try and learn how the kernel works. > > Now we have to waste more maintainer time making sure nobody accidentally > merges anything he sends. > > Dave. All of my merges are not in the main kernel and have been revoked. Cheers Nick -- 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: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch? Do you have any other doubts? Br White Ding -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi Brain, >> Do nand reset before write protect check If we want to check the WP# >> low or high through STATUS READ and check bit 7, we must reset the >> device, other operation (eg.erase/program a locked block) can also >> clear the bit 7 of status register. >This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. >First of all, where is the 'lock' sequence specified? I see the commit that >introduced nand_lock() (without any users) which says Micron parts support it, >but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 > Author: Vimal Singh > Date: Mon Feb 8 15:50:49 2010 +0530 > mtd: nand: add lock/unlock routines >Now, supposing this is documented somewhere, are you seeing some kind >of out-of-spec behavior? Is this a controller quirk you're seeing? Why >should I need to reset the chip? I would presume that > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); >would refresh the status properly. Is that not the case? chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: > Do nand reset before write protect check If we want to check the WP# > low or high through STATUS READ and check bit 7, we must reset the > device, other operation (eg.erase/program a locked block) can also > clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? > Signed-off-by: White Ding > --- > drivers/mtd/nand/nand_base.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/mtd/nand/nand_base.c > b/drivers/mtd/nand/nand_base.c index 41167e9..22dd3aa 100644 > --- a/drivers/mtd/nand/nand_base.c > +++
Re: [PATCH] v4l2: Change call of function in videobuf2-core.c
On 4 August 2014 15:03, Hans Verkuil wrote: > On 08/04/2014 05:25 AM, Nicholas Krause wrote: >> This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE >> inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR. >> >> Signed-off-by: Nicholas Krause > > Dunno what's going on here after reading Dave Airlie's reply, but: > Nick has decided he wants to be a kernel developer, a laudable goal. He however has decided not to take any advice given to me by a number of other kernel developers on how to work on the kernel. So instead he sends random broken patches to random subsystems in the hope that one will slip past a sleepy maintainer and end up in the kernel. He isn't willing to spend his own time learning anything, he is expecting that kernel developers want to spoon feed someone who sends them broken patches. We've asked him to stop, he keeps doing it, then when caught out apologizes with something along the lines, of I'm trying to learn, "idiot mistake", despite having been told to take a step back and try and learn how the kernel works. Now we have to waste more maintainer time making sure nobody accidentally merges anything he sends. Dave. -- 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] v4l2: Change call of function in videobuf2-core.c
On Mon, Aug 4, 2014 at 1:03 AM, Hans Verkuil wrote:
> On 08/04/2014 05:25 AM, Nicholas Krause wrote:
>> This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE
>> inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR.
>>
>> Signed-off-by: Nicholas Krause
>
> Dunno what's going on here after reading Dave Airlie's reply, but:
>
> Nacked-by: Hans Verkuil
>
> It's clearly wrong and if you get here at all you have a driver bug anyway.
> That
> WARN_ON is there for a reason. Your driver isn't returning buffers correctly
> in
> stop_streaming or in start_streaming if start_streaming fails with an error.
>
> Regards,
>
> Hans
>
>> ---
>> drivers/media/v4l2-core/videobuf2-core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 7c4489c..08e478b 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -2115,7 +2115,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
>> if (WARN_ON(atomic_read(>owned_by_drv_count))) {
>> for (i = 0; i < q->num_buffers; ++i)
>> if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
>> - vb2_buffer_done(q->bufs[i],
>> VB2_BUF_STATE_ERROR);
>> + vb2_buffer_done(q->bufs[i],
>> VB2_BUF_STATE_ACTIVE);
>> /* Must be zero now */
>> WARN_ON(atomic_read(>owned_by_drv_count));
>> }
>>
>
Yes ,
That was an idiot mistake. So sorry about that would someone mind as a
big help a list of
common debugging macros or a link to somewhere I can read them. I want
to apologize
sincerely for my bad mistakes. I do want to help out and by helping me
sand out my
mistakes and learn from them I can help much better. I do want to help
and if people
are willing to get me grow like this I will continue to try and help.
Regards Nick
--
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] gpio: add flags argument to gpiod_get*() functions
On Thu, Jul 31, 2014 at 12:43 PM, Alexandre Courbot wrote: > On Mon, Jul 28, 2014 at 7:30 PM, Linus Walleij > wrote: >> On Fri, Jul 25, 2014 at 4:38 PM, Alexandre Courbot >> wrote: >> >>> The huge majority of GPIOs have their direction and initial value set >>> right after being obtained by one of the gpiod_get() functions. The >>> integer GPIO API had gpio_request_one() that took a convenience flags >>> parameter allowing to specify an direction and value applied to the >>> returned GPIO. This feature greatly simplifies client code and ensures >>> errors are always handled properly. >>> >>> A similar feature has been requested for the gpiod API. Since setting >>> the direction of a GPIO is so often the very next action done after >>> obtaining its descriptor, we prefer to extend the existing functions >>> instead of introducing new functions that would raise the >>> number of gpiod getters to 16 (!). >>> >>> The drawback of this approach is that all gpiod clients need to be >>> updated. To limit the pain, temporary macros are introduced that allow >>> gpiod_get*() to be called with or without the extra flags argument. They >>> will be removed once all consumer code has been updated. >>> >>> Signed-off-by: Alexandre Courbot >>> --- >>> This dude can be applied harmlessly to the GPIO tree - then I will go >>> after every gpiod user to update the calls to gpiod_get*() before >>> removing the macros in consumer.h. >> >> OK I trust you. Patch applied with Broonie's review tag. > > Thanks! Unfortunately it is still not in -next due to a build error... > >> Just so we don't forget how we should move forward: Alex what do >> you think about adding a drivers/gpio/TODO.TXT file outlining the >> overall plan of the gpiod refactoring and clean-up work? > > I have such a file locally - I'm not sure if checking it into the > kernel tree is relevant though. Sounds more like the task of a wiki > page. FWIW I have posted a small list of stuff I intent to do shortly: https://gist.github.com/Gnurou/a62915acbfe0d0d4a671 -- 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] v4l2: Change call of function in videobuf2-core.c
On 08/04/2014 05:25 AM, Nicholas Krause wrote:
> This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE
> inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR.
>
> Signed-off-by: Nicholas Krause
Dunno what's going on here after reading Dave Airlie's reply, but:
Nacked-by: Hans Verkuil
It's clearly wrong and if you get here at all you have a driver bug anyway. That
WARN_ON is there for a reason. Your driver isn't returning buffers correctly in
stop_streaming or in start_streaming if start_streaming fails with an error.
Regards,
Hans
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 7c4489c..08e478b 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2115,7 +2115,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
> if (WARN_ON(atomic_read(>owned_by_drv_count))) {
> for (i = 0; i < q->num_buffers; ++i)
> if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
> - vb2_buffer_done(q->bufs[i],
> VB2_BUF_STATE_ERROR);
> + vb2_buffer_done(q->bufs[i],
> VB2_BUF_STATE_ACTIVE);
> /* Must be zero now */
> WARN_ON(atomic_read(>owned_by_drv_count));
> }
>
--
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 9/9] drm: add Rockchip Soc rk3288 edp connector
Signed-off-by: mark yao
---
drivers/gpu/drm/rockchip/connector/Kconfig |9 +
drivers/gpu/drm/rockchip/connector/Makefile|1 +
.../gpu/drm/rockchip/connector/rk3288_dp_core.c| 586 ++
.../gpu/drm/rockchip/connector/rk3288_dp_core.h| 355 ++
drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.c | 1192
drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.h | 378 +++
drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 13 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h|3 +
8 files changed, 2537 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_core.h
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.c
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.h
diff --git a/drivers/gpu/drm/rockchip/connector/Kconfig
b/drivers/gpu/drm/rockchip/connector/Kconfig
index 248942f..caffc5b 100644
--- a/drivers/gpu/drm/rockchip/connector/Kconfig
+++ b/drivers/gpu/drm/rockchip/connector/Kconfig
@@ -6,3 +6,12 @@ config RK3288_LVDS
rk3288 lvds transmitter support ttl rgb, lvds and dual lvds
mode, dual lvds mode is support for the plane which need dual
lvds channels.
+
+config RK3288_DP
+ bool "RK3288 edp connector support"
+ depends on DRM_ROCKCHIP_CONNECTOR
+ help
+ Choose this option if you have a rk32xx eDP connector.
+ Rockchip rk3288 SoC has eDP TX Controller can be used.
+ If you have an Embedded DisplayPort Panel, say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/connector/Makefile
b/drivers/gpu/drm/rockchip/connector/Makefile
index dcfbdef..4be77ea 100644
--- a/drivers/gpu/drm/rockchip/connector/Makefile
+++ b/drivers/gpu/drm/rockchip/connector/Makefile
@@ -2,3 +2,4 @@
# Makefile for display connector like lvds edp mipi
#
obj-$(CONFIG_RK3288_LVDS) += rk3288_lvds.o
+obj-$(CONFIG_RK3288_DP)+= rk3288_dp_core.o rk3288_dp_reg.o
diff --git a/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
b/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
new file mode 100644
index 000..3756383
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
@@ -0,0 +1,586 @@
+/*
+* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+* Author:
+* yxj
+* cym
+*
+* based on exynos_dp_core.c
+*
+* 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rk3288_dp_core.h"
+
+static int rk3288_edp_clk_enable(struct rk3288_edp *edp)
+{
+ int ret = 0;
+
+ if (!edp->clk_on) {
+ ret = clk_prepare_enable(edp->pclk);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable edp pclk %d\n", ret);
+ goto err_pclk;
+ }
+
+ ret = clk_prepare_enable(edp->clk_edp);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable clk_edp %d\n", ret);
+ goto err_clk_edp;
+ }
+
+ ret = clk_set_parent(edp->clk_24m, edp->clk_24m_parent);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot set edp clk_24m parent %d\n",
+ ret);
+ goto err_clk_24m;
+ }
+
+ ret = clk_prepare_enable(edp->clk_24m);
+ if (ret < 0) {
+ dev_err(edp->dev, "cannot enable edp clk_24m %d\n",
+ ret);
+ goto err_clk_24m;
+ }
+
+ edp->clk_on = true;
+ }
+
+ return 0;
+
+err_clk_24m:
+ clk_disable_unprepare(edp->clk_edp);
+err_clk_edp:
+ clk_disable_unprepare(edp->pclk);
+err_pclk:
+ edp->clk_on = false;
+
+ return ret;
+}
+
+static int rk3288_edp_clk_disable(struct rk3288_edp *edp)
+{
+ if (edp->clk_on) {
+ clk_disable_unprepare(edp->pclk);
+ clk_disable_unprepare(edp->clk_edp);
+ clk_disable_unprepare(edp->clk_24m);
+ edp->clk_on = false;
+ }
+
+ return 0;
+}
+
+static int rk3288_edp_pre_init(struct rk3288_edp *edp)
+{
+ u32 val;
+ int ret = 0;
+
+ val = GRF_EDP_REF_CLK_SEL_INTER | (GRF_EDP_REF_CLK_SEL_INTER << 16);
+ ret = regmap_write(edp->grf, edp->soc_data->grf_soc_con12, val);
+ if (ret != 0) {
+ dev_err(edp->dev, "Could not write to GRF: %d\n", ret);
+ return ret;
+ }
+
+
[PATCH 8/9] Add devicetree bindings for Rockchip Soc EDP
Signed-off-by: mark yao
---
.../devicetree/bindings/video/rockchip-panel.txt | 34
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
index f599806..f6d80f6 100644
--- a/Documentation/devicetree/bindings/video/rockchip-panel.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -80,3 +80,37 @@ Example:
rockchip,data-width = <24>;
rockchip,panel = <>;
};
+
+Rockchip RK3288 EDP interface
+
+Required properties:
+-compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "clk_edp"
+ "clk_edp_24m"
+ "clk_edp_24m_parent"
+ "pclk_edp"
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - edp
+- rockchip,panel: required a panel node
+
+Example:
+ edp: edp@ff97 {
+ compatible = "rockchip,rk3288-edp";
+reg = <0xff97 0x4000>;
+interrupts = ;
+clocks = < SCLK_EDP>, < SCLK_EDP_24M>, <
PCLK_EDP_CTRL>, <>;
+clock-names = "clk_edp", "clk_edp_24m", "pclk_edp",
"clk_edp_24m_parent";
+
+rockchip,grf = <>;
+resets = < 111>;
+reset-names = "edp";
+ rockchip,panel = <>;
+ };
--
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 7/9] drm: add Rockchip Soc rk3288 lvds connector
Signed-off-by: mark yao
---
drivers/gpu/drm/rockchip/Kconfig |1 +
drivers/gpu/drm/rockchip/Makefile|2 +-
drivers/gpu/drm/rockchip/connector/Kconfig |8 +
drivers/gpu/drm/rockchip/connector/Makefile |4 +
drivers/gpu/drm/rockchip/connector/rk3288_lvds.c | 332 ++
drivers/gpu/drm/rockchip/connector/rk3288_lvds.h | 50
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 13 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +
8 files changed, 412 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/rockchip/connector/Kconfig
create mode 100644 drivers/gpu/drm/rockchip/connector/Makefile
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_lvds.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ccce827..407cbb6 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -40,3 +40,4 @@ config DRM_ROCKCHIP_CONNECTOR
such as lcd plane, lvds, edp , mipi, etc.
source "drivers/gpu/drm/rockchip/lcdc/Kconfig"
+source "drivers/gpu/drm/rockchip/connector/Kconfig"
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 6d49edc..7d5877a 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,6 +8,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_panel.o
-obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
+obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o connector/
obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o lcdc/
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/connector/Kconfig
b/drivers/gpu/drm/rockchip/connector/Kconfig
new file mode 100644
index 000..248942f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/Kconfig
@@ -0,0 +1,8 @@
+config RK3288_LVDS
+ bool "RK3288 lvds connector support"
+ depends on DRM_ROCKCHIP_CONNECTOR
+ help
+ Choose this option if you have a rk3288 lvds connector.
+ rk3288 lvds transmitter support ttl rgb, lvds and dual lvds
+ mode, dual lvds mode is support for the plane which need dual
+ lvds channels.
diff --git a/drivers/gpu/drm/rockchip/connector/Makefile
b/drivers/gpu/drm/rockchip/connector/Makefile
new file mode 100644
index 000..dcfbdef
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for display connector like lvds edp mipi
+#
+obj-$(CONFIG_RK3288_LVDS) += rk3288_lvds.o
diff --git a/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
b/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
new file mode 100644
index 000..3ca4c6f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ * hjc
+ * mark yao
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
+
+#include
+
+#include "../rockchip_drm_connector.h"
+#include "../rockchip_drm_lcdc.h"
+#include "rk3288_lvds.h"
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
+ */
+struct rk3288_lvds_soc_data {
+ int grf_gpio1d_iomux;
+ int grf_soc_con6;
+ int grf_soc_con7;
+};
+
+struct rk3288_lvds {
+ void *base;
+ int format;
+ struct drm_display_mode mode;
+ struct device *dev;
+ void __iomem *regs;
+ struct regmap *grf;
+ struct rk3288_lvds_soc_data *soc_data;
+ struct clk *pclk;
+ bool standby;
+};
+
+static inline void lvds_writel(struct rk3288_lvds *lvds, u32 offset, u32 val)
+{
+ writel_relaxed(val, lvds->regs + offset);
+ writel_relaxed(val, lvds->regs + offset + 0x100);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+ if (!s)
+ return 0;
+
+ if (strncmp(s, "jeida", 6) == 0)
+ return LVDS_FORMAT_JEIDA;
+ else if (strncmp(s, "vesa", 6) == 0)
+ return LVDS_FORMAT_VESA;
+
+ return 0;
+}
+
+static void rk3288_lvds_disable(struct rockchip_connector *conn)
+{
+ struct rk3288_lvds *lvds = conn->priv;
+ int ret = 0;
+
+ if (lvds->standby)
+
[PATCH 1/9] drm: Add drm driver for Rockchip Socs
This patch is a DRM Driver for Rockchip Socs, driver provides an abstraction for the graphics hardware, such as lcd controller and connector interface. Signed-off-by: mark yao --- drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/rockchip/Kconfig | 40 ++ drivers/gpu/drm/rockchip/Makefile | 12 + drivers/gpu/drm/rockchip/rockchip_drm_connector.c | 412 drivers/gpu/drm/rockchip/rockchip_drm_connector.h | 36 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 600 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 128 drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 48 ++ drivers/gpu/drm/rockchip/rockchip_drm_fb.h| 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 63 ++ drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 24 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 163 + drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 40 ++ drivers/gpu/drm/rockchip/rockchip_drm_lcdc.c | 720 + drivers/gpu/drm/rockchip/rockchip_drm_lcdc.h | 131 include/uapi/drm/rockchip_drm.h | 110 17 files changed, 2558 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/Kconfig create mode 100644 drivers/gpu/drm/rockchip/Makefile create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.h create mode 100644 include/uapi/drm/rockchip_drm.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index f512004..5951c2c 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -170,6 +170,8 @@ config DRM_SAVAGE source "drivers/gpu/drm/exynos/Kconfig" +source "drivers/gpu/drm/rockchip/Kconfig" + source "drivers/gpu/drm/vmwgfx/Kconfig" source "drivers/gpu/drm/gma500/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index dd2ba42..40babd2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ obj-$(CONFIG_DRM_VIA) +=via/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig new file mode 100644 index 000..592e999 --- /dev/null +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -0,0 +1,40 @@ +config DRM_ROCKCHIP + tristate "DRM Support for Rockchip" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select DRM_PANEL + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE + select VIDEOMODE_HELPERS + select OF + help + Choose this option if you have a Rockchip soc chipset. + This driver provides kernel mode setting and buffer + management to userspace. This driver does not provides + 2D or 3D acceleration; acceleration is performed by other + IP found on the SoC. + +config DRM_ROCKCHIP_LCDC + bool "ROCKCHIP DRM LCDC" + depends on DRM_ROCKCHIP + select FB_MODE_HELPERS + help + Choose this option if you want to use Rockchip lcdc for DRM. + The driver provides an abstraction for Rockchip lcd controller, + lcd controller is the display interface from memory frame buffer + to display device. + +config DRM_ROCKCHIP_CONNECTOR + bool "ROCKCHIP DRM CONNECTOR" + depends on OF && DRM_ROCKCHIP && DRM_ROCKCHIP_LCDC + select FB_MODE_HELPERS + select VIDEOMODE_HELPERS + help + Choose this option if you want to use Rockchip Primary DISPLAY. + The driver provides an abstraction for Rockchip display devices, + such as lcd plane, lvds, edp , mipi, etc. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile new file mode 100644 index 000..45c9d50 --- /dev/null +++ b/drivers/gpu/drm/rockchip/Makefile @@
[PATCH 6/9] Add devicetree bindings for Rockchip Soc LVDS
Signed-off-by: mark yao
---
.../devicetree/bindings/video/rockchip-panel.txt | 30
1 file changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
index 9fc200a..f599806 100644
--- a/Documentation/devicetree/bindings/video/rockchip-panel.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -50,3 +50,33 @@ Example:
};
};
+
+Rockchip RK3288 LVDS interface
+
+Required properties:
+-compatible: "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding: Shall be "pclk_lvds".
+ pclk_lvds: for power domain, if it disable soc will power down
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- rockchip,data-mapping: should be "vesa" or "jeida"
+ This describes how the color bits are laid out in the
+ serialized LVDS signal.
+- rockchip,data-width: should be <18> or <24>
+- rockchip,panel: required a panel node
+
+Example:
+ lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ reg = <0xff96c000 0x4000>;
+ clocks = < PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+
+ rockchip,grf = <>;
+ rockchip,data-mapping = "jeida";
+ rockchip,data-width = <24>;
+ rockchip,panel = <>;
+ };
--
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 5/9] drm: add Rockchip rk3288 lcd controller driver
Signed-off-by: mark yao
---
drivers/gpu/drm/rockchip/Kconfig|2 +
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/lcdc/Kconfig |9 +
drivers/gpu/drm/rockchip/lcdc/Makefile |4 +
drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c | 819 ++
drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.h | 1202 +++
6 files changed, 2037 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/rockchip/lcdc/Kconfig
create mode 100644 drivers/gpu/drm/rockchip/lcdc/Makefile
create mode 100644 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
create mode 100644 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 592e999..ccce827 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -38,3 +38,5 @@ config DRM_ROCKCHIP_CONNECTOR
Choose this option if you want to use Rockchip Primary DISPLAY.
The driver provides an abstraction for Rockchip display devices,
such as lcd plane, lvds, edp , mipi, etc.
+
+source "drivers/gpu/drm/rockchip/lcdc/Kconfig"
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a5e5132..6d49edc 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,5 +9,5 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
rockchip_panel.o
obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
-obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o
+obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o lcdc/
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/lcdc/Kconfig
b/drivers/gpu/drm/rockchip/lcdc/Kconfig
new file mode 100644
index 000..2b94057
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/Kconfig
@@ -0,0 +1,9 @@
+config LCDC_RK3288
+bool "rk3288 lcdc support"
+depends on DRM_ROCKCHIP_LCDC
+help
+ Choose this option if you have a rk3288 lcd controller.
+ rk3288 lcdc is the display interface from memory frame buffer
+ to display device. There are two lcd controllers on rk3288,
+ They have same regs setting, can use same drivers. We use the
+ lcdc id distinguish between them
diff --git a/drivers/gpu/drm/rockchip/lcdc/Makefile
b/drivers/gpu/drm/rockchip/lcdc/Makefile
new file mode 100644
index 000..943dcd6
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the lcd control device driver.
+
+obj-$(CONFIG_LCDC_RK3288) += rk3288_lcdc.o
diff --git a/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
b/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
new file mode 100644
index 000..f1b016c
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
@@ -0,0 +1,819 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ * hjc
+ * mark yao
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
+
+#ifdef CONFIG_OF
+#include
+#include
+#endif
+
+#include "../rockchip_drm_lcdc.h"
+#include "rk3288_lcdc.h"
+
+#define RK3288_LCDC_BIG_BASE 0xff93
+#define RK3288_LCDC_LIT_BASE 0xff94
+
+static struct lcdc_win_data lcdc_win[] = {
+ [0] = {
+ .id = 0,
+ .zpos = ZPOS_DEFAULT_WIN,
+ .fmt_10 = 0,
+ .win_lb_mode = 0x4,
+ .swap_rb = 0,
+ },
+ [1] = {
+ .id = 1,
+ .zpos = ZPOS_UNUSED_WIN,
+ .fmt_10 = 0,
+ .win_lb_mode = 0x4,
+ .swap_rb = 0,
+ },
+ [2] = {
+ .id = 2,
+ .zpos = ZPOS_CURSOR_WIN,
+ .fmt_10 = 0,
+ .win_lb_mode = 0x4,
+ .swap_rb = 0,
+ },
+ [3] = {
+ .id = 3,
+ .zpos = ZPOS_UNUSED_WIN,
+ },
+};
+
+static void rk3288_lcdc_win_commit(struct lcdc_driver *lcdc_drv,
+ struct lcdc_win_data *win);
+static void rk3288_lcdc_dpms(struct lcdc_driver *lcdc_drv, int mode);
+
+static int rk3288_lcdc_get_id(u32 phy_base)
+{
+ if (phy_base == RK3288_LCDC_BIG_BASE)
+ return 0;
+ else if (phy_base == RK3288_LCDC_LIT_BASE)
+ return 1;
+ else
+ return -EINVAL;
+}
+
+static int rk3288_lcdc_clk_enable(struct lcdc_device *lcdc_dev)
+{
+ int
[PATCH 4/9] Add devicetree bindings for Rockchip lcd controller
Signed-off-by: mark yao
---
.../devicetree/bindings/video/rockchip-lcdc.txt| 33
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/rockchip-lcdc.txt
diff --git a/Documentation/devicetree/bindings/video/rockchip-lcdc.txt
b/Documentation/devicetree/bindings/video/rockchip-lcdc.txt
new file mode 100644
index 000..7fb2b73
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-lcdc.txt
@@ -0,0 +1,33 @@
+Device-Tree bindings for Rockchip SoC display controller (LCDC)
+
+LCDC (LCD Controller) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3066-lcdc";
+ "rockchip,rk3188-lcdc";
+ "rockchip,rk3288-lcdc";
+
+- interrupts: should contain a list of all LCDC IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: Must contain
+ aclk_lcdc: for ddr buffer transfer.
+ hclk_lcdc: for ahb bus to R/W the phy regs.
+ dclk_lcdc: pixel clock.
+
+Example:
+SoC specific DT entry:
+ lcdc1: lcdc@ff94 {
+ compatible = "rockchip,rk3288-lcdc";
+ reg = <0xff94 0x19c>;
+ interrupts = ;
+ clocks = < ACLK_LCDC1>, < DCLK_LCDC1>, <
HCLK_LCDC1>;
+ clock-names = "aclk_lcdc", "dclk_lcdc", "hclk_lcdc";
+ };
--
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 3/9] drm: add driver for panels used by the Rockchip DRM
Signed-off-by: mark yao
---
drivers/gpu/drm/rockchip/Makefile |3 +-
drivers/gpu/drm/rockchip/rockchip_panel.c | 297 +
2 files changed, 299 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_panel.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 45c9d50..a5e5132 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -5,7 +5,8 @@
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
- rockchip_drm_fb.o rockchip_drm_fbdev.o
+ rockchip_drm_fb.o rockchip_drm_fbdev.o \
+ rockchip_panel.o
obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_panel.c
b/drivers/gpu/drm/rockchip/rockchip_panel.c
new file mode 100644
index 000..87401a2
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_panel.c
@@ -0,0 +1,297 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:mark yao
+ *
+ * based on panel-simple.c
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 "rockchip_drm_drv.h"
+
+/* TODO: convert to gpiod_*() API once it's been merged */
+#define GPIO_ACTIVE_LOW(1 << 0)
+
+struct pwr_gpio {
+ struct list_head head;
+ unsigned long enable_gpio_flags;
+ int enable_gpio;
+};
+
+struct rockchip_panel {
+ struct drm_panel base;
+ bool enabled;
+
+ struct drm_display_mode mode;
+ struct rockchip_panel_special priv;
+
+ struct list_head pwrlist;
+};
+
+static inline struct rockchip_panel *to_rockchip_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rockchip_panel, base);
+}
+
+static int rockchip_panel_disable(struct drm_panel *panel)
+{
+ struct rockchip_panel *p = to_rockchip_panel(panel);
+ struct pwr_gpio *pwr;
+ struct list_head *pos;
+
+ if (!p->enabled)
+ return 0;
+
+ list_for_each(pos, >pwrlist) {
+ pwr = list_entry(pos, struct pwr_gpio, head);
+ if (gpio_is_valid(pwr->enable_gpio)) {
+ if (pwr->enable_gpio_flags & GPIO_ACTIVE_LOW)
+ gpio_set_value(pwr->enable_gpio, 1);
+ else
+ gpio_set_value(pwr->enable_gpio, 0);
+ }
+ }
+
+ p->enabled = false;
+
+ return 0;
+}
+
+static int rockchip_panel_enable(struct drm_panel *panel)
+{
+ struct rockchip_panel *p = to_rockchip_panel(panel);
+ struct pwr_gpio *pwr;
+ struct list_head *pos;
+
+ if (p->enabled)
+ return 0;
+
+ list_for_each(pos, >pwrlist) {
+ pwr = list_entry(pos, struct pwr_gpio, head);
+ if (gpio_is_valid(pwr->enable_gpio)) {
+ if (pwr->enable_gpio_flags & GPIO_ACTIVE_LOW)
+ gpio_set_value(pwr->enable_gpio, 0);
+ else
+ gpio_set_value(pwr->enable_gpio, 1);
+ }
+ }
+
+ p->enabled = true;
+
+ return 0;
+}
+
+static int rockchip_panel_get_modes(struct drm_panel *panel)
+{
+ struct rockchip_panel *p = to_rockchip_panel(panel);
+ struct drm_device *drm = panel->drm;
+ struct drm_connector *connector = panel->connector;
+ const struct drm_display_mode *m = >mode;
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(drm, m);
+ if (!mode) {
+ dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
+ return 0;
+ }
+
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+
+ return 1;
+}
+
+static const struct drm_panel_funcs rockchip_panel_funcs = {
+ .disable = rockchip_panel_disable,
+ .enable = rockchip_panel_enable,
+ .get_modes = rockchip_panel_get_modes,
+};
+
+static int rockchip_name_to_face(const char *s)
+{
+ if (!s)
+ return 0;
+
+ if (strncmp(s, "r8g8b8", 6) == 0)
+ return ROCKCHIP_OUTFACE_P888;
+ else if (strncmp(s, "r6g6b6", 6) == 0)
+ return ROCKCHIP_OUTFACE_P666;
+ else if
[PATCH 2/9] Add devicetree bindings for panels used by the Rockchip DRM
Signed-off-by: mark yao
---
.../devicetree/bindings/video/rockchip-panel.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/rockchip-panel.txt
diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
new file mode 100644
index 000..9fc200a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -0,0 +1,52 @@
+Rockchip LCD Display interface
+
+Required properties:
+-compatible: "rockchip,rockchip-panel";
+
+- rockchip,output-face: lcdc display mode value should set as following
+ "r8g8b8": 24bit display port, R8 G8 B8
+ "r6g6b6": 18bit display port, R6 G6 B6
+ "r5g6b5": 16bit display port, R5 G6 B5
+
+Optional properties:
+- display-timings: timings for the connected panel as described by
+ Documentation/devicetree/bindings/video/display-timing.txt
+Optional properties:
+- rockchip,power-gpios: gpio to power on or off the LCD (as many as needed)
+- lcdc-vcc18: Defined if power supply of lcd controller is 1.8v,
+ Not defined if power supply of lcd controller is 3.3v.
+- output-dither: support dithering the output color.
+- color-swap-rb: swap R and B color per pixel.
+- color-swap-rg: swap R and G color per pixel.
+- color-swap-bg: swap B and G color per pixel.
+
+Example:
+ panel {
+ compatible = "rockchip,rockchip-panel";
+ rockchip,output-face = "r6g6b6";
+
+ enable-gpios = < 3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH>;
+ output-dither;
+
+ display-timings {
+ native-mode = <_disp0>;
+
+ timing_disp0: 1280x800 {
+ clock-frequency = <7100>;
+ hactive = <1280>;
+ vactive = <800>;
+ hback-porch = <100>;
+ hfront-porch = <18>;
+ vback-porch = <8>;
+ vfront-porch = <6>;
+ hsync-len = <10>;
+ vsync-len = <2>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <0>;
+ pixelclk-active = <0>;
+ };
+ };
+
+ };
--
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 0/9] Add drm driver for Rockchip Socs
From: mark yao This a series of patches is a DRM Driver for Rockchip Socs, driver provides an abstraction for the graphics hardware, as lcd controller and connector interface. add rk3288 lcd controller. add rk3288 lvds and rk3288 edp connector. Tested on rk3288 sdk board, use lvds or edp connector, boot and display OK mark yao (9): drm: Add drm driver for Rockchip Socs Add devicetree bindings for panels used by the Rockchip DRM drm: add driver for panels used by the Rockchip DRM Add devicetree bindings for Rockchip lcd controller drm: add Rockchip rk3288 lcd controller driver Add devicetree bindings for Rockchip Soc LVDS drm: add Rockchip Soc rk3288 lvds connector Add devicetree bindings for Rockchip Soc EDP drm: add Rockchip Soc rk3288 edp connector -- 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 V2 0/1] irqchip: GIC: check and clear GIC interupt active state
For this version of GIC codes, kernel assumes that all the interrupt status of GIC is inactive. So the kernel does not check this when booting. This is no problem on must sitations. But when kdump is deplayed. And a panic occurs when an interrupt is being handled (may be PPI ). We have no chance to write relative bit to GICC_EOIR. So this interrupt remains active. And GIC will not deliver this type interrupt to cpu interface. And the capture kernel may fail to boot becase of lacking of certain interrupt (such as timer interupt). I have test this patch on arma9el(GIC v1), arma15el and arma15eb(GIC v2) platforms. And the tests passed. changes from V1: - used for_each_set_bit instead of find_next_bit - removed the GIC version indentifying codes. - used one way to inactive GIC interupt states for all GIC version Liu Hua (1): GIC: introduce method to deactive interupts drivers/irqchip/irq-gic.c | 26 ++ 1 file changed, 26 insertions(+) -- 1.9.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: linux-next: build failure after merge of the gpio tree
Hi Alexandre, On Mon, 4 Aug 2014 13:10:14 +0900 Alexandre Courbot wrote: > > I have sent a patch to fix this. In the meantime, if the merge > conflict of the GPIO tree on board-paz00.c is solved by taking the > GPIO version, there is no build error. > > There are a few important patches pending in the GPIO tree that should > undergo testing - Stephen, do you think you could resolve the conflict > that way to enable the latest GPIO tree to be tested again? No, but I will apply that fix patch in my merge of the gpio tree - just make sure it is applied to the gpio tree before Linus (Torvalds) is asked to pull it. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH V2 1/1] GIC: introduce method to deactive interupts
When using kdump on ARM platform, if kernel panics in interrupt handler
(maybe PPI), the capture kernel can not recive certain interrupt, and
fails to boot.
On this situation, We have read register GICC_IAR. But we have no chance
to write relative bit to register GICC_EOIR (kernel paniced before). So
the state of this type interrupt remains active. And that makes gic not
deliver this type interrupt to cpu interface.
So we should not assume that all interrut states of GIC are inactive when
kernel inittailize the GIC. This patch will identify these type interrupts
and deactive them
Signed-off-by: Liu Hua
---
drivers/irqchip/irq-gic.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index b2648fc..7708df1 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -351,12 +351,37 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
return mask;
}
+void gic_eois(u32 active, int irq_off, void __iomem *cpu_base)
+{
+ int bit = -1;
+
+ for_each_set_bit(bit, (unsigned long *), 32)
+ writel_relaxed(bit + irq_off, cpu_base + GIC_CPU_EOI);
+}
+
+void gic_dist_clear_active(void __iomem *dist_base,
+ void __iomem *cpu_base, int gic_irqs)
+{
+ int irq, offset;
+ u32 active;
+
+ for (irq = 0; irq < gic_irqs; irq += 32) {
+ offset = GIC_DIST_ACTIVE_SET + irq * 4 / 32;
+ active = readl_relaxed(dist_base + offset);
+ if (!active)
+ continue;
+ gic_eois(active, irq, cpu_base);
+ }
+}
+
+
static void __init gic_dist_init(struct gic_chip_data *gic)
{
unsigned int i;
u32 cpumask;
unsigned int gic_irqs = gic->gic_irqs;
void __iomem *base = gic_data_dist_base(gic);
+ void __iomem *cpu_base = gic_data_cpu_base(gic);
writel_relaxed(0, base + GIC_DIST_CTRL);
@@ -371,6 +396,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
gic_dist_config(base, gic_irqs, NULL);
+ gic_dist_clear_active(base, cpu_base, gic_irqs);
writel_relaxed(1, base + GIC_DIST_CTRL);
}
--
1.9.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 V3] Save command pool address of Scsi_Host
From: Juergen Gross
If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's
private command pool is needed. scsi_find_host_cmd_pool() will locate it, but
scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template.
This will result in an access error when the host is removed.
Avoid the problem by saving the address of a new allocated command pool where
it is expected and delete it again when the pool is destroyed.
Signed-off-by: Juergen Gross
---
drivers/scsi/scsi.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..11ea502 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -351,11 +351,12 @@ scsi_find_host_cmd_pool(struct Scsi_Host *shost)
}
static void
-scsi_free_host_cmd_pool(struct scsi_host_cmd_pool *pool)
+scsi_free_host_cmd_pool(struct scsi_host_cmd_pool **pool)
{
- kfree(pool->sense_name);
- kfree(pool->cmd_name);
- kfree(pool);
+ kfree(pool[0]->sense_name);
+ kfree(pool[0]->cmd_name);
+ kfree(pool[0]);
+ pool[0] = NULL;
}
static struct scsi_host_cmd_pool *
@@ -371,7 +372,7 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->name);
if (!pool->cmd_name || !pool->sense_name) {
- scsi_free_host_cmd_pool(pool);
+ scsi_free_host_cmd_pool();
return NULL;
}
@@ -380,6 +381,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -425,7 +430,7 @@ out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ scsi_free_host_cmd_pool(>cmd_pool);
goto out;
}
@@ -448,7 +453,7 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
if (hostt->cmd_size)
- scsi_free_host_cmd_pool(pool);
+ scsi_free_host_cmd_pool(>cmd_pool);
}
mutex_unlock(_cmd_pool_mutex);
}
--
1.8.4.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 0/7] locking/rwsem: enable reader opt-spinning & writer respin
On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote: > This patch set improves upon the rwsem optimistic spinning patch set > from Davidlohr to enable better performing rwsem and more aggressive > use of optimistic spinning. > > By using a microbenchmark running 1 million lock-unlock operations per > thread on a 4-socket 40-core Westmere-EX x86-64 test machine running > 3.16-rc7 based kernels, the following table shows the execution times > with 2/10 threads running on different CPUs on the same socket where > load is the number of pause instructions in the critical section: > > lock/r:w ratio # of threads Load:Execution Time (ms) > -- > mutex 2 1:530.7, 5:406.0, 10:472.7 > mutex10 1:1848 , 5:2046 , 10:4394 > > Before patch: > rwsem/0:1 2 1:339.4, 5:368.9, 10:394.0 > rwsem/1:1 2 1:2915 , 5:2621 , 10:2764 > rwsem/10:12 1:891.2, 5:779.2, 10:827.2 > rwsem/0:110 1:5618 , 5:5722 , 10:5683 > rwsem/1:110 1:14562, 5:14561, 10:14770 > rwsem/10:1 10 1:5914 , 5:5971 , 10:5912 > > After patch: > rwsem/0:12 1:161.1, 5:244.4, 10:271.4 > rwsem/1:12 1:188.8, 5:212.4, 10:312.9 > rwsem/10:1 2 1:168.8, 5:179.5, 10:209.8 > rwsem/0:1 10 1:1306 , 5:1733 , 10:1998 > rwsem/1:1 10 1:1512 , 5:1602 , 10:2093 > rwsem/10:1 10 1:1267 , 5:1458 , 10:2233 > > % Change: > rwsem/0:12 1:-52.5%, 5:-33.7%, 10:-31.1% > rwsem/1:12 1:-93.5%, 5:-91.9%, 10:-88.7% > rwsem/10:1 2 1:-81.1%, 5:-77.0%, 10:-74.6% > rwsem/0:1 10 1:-76.8%, 5:-69.7%, 10:-64.8% > rwsem/1:1 10 1:-89.6%, 5:-89.0%, 10:-85.8% > rwsem/10:1 10 1:-78.6%, 5:-75.6%, 10:-62.2% So at a very low level you see nicer results, which aren't really translating to much of a significant impact at a higher level (aim7). > It can be seen that there is dramatic reduction in the execution > times. The new rwsem is now even faster than mutex whether it is all > writers or a mixture of writers and readers. > > Running the AIM7 benchmarks on the same 40-core system (HT off), > the performance improvements on some of the workloads were as follows: > > Workload Before Patch After Patch % Change > --- > custom (200-1000) 446135477404 +7.0% > custom (1100-2000) 449665484734 +7.8% > high_systime152437154217 +1.2% >(200-1000) > high_systime269695278942 +3.4% >(1100-2000) I worry about complicating rwsems even _more_ than they are, specially for such a marginal gain. You might want to try other workloads -- ie: postgresql (pgbench), I normally get pretty useful data when dealing with rwsems. -- 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] Save command pool address of Scsi_Host
On 08/01/2014 10:24 PM, James Bottomley wrote: On Fri, 2014-08-01 at 05:03 -0700, Christoph Hellwig wrote: On Fri, Aug 01, 2014 at 08:27:05AM +0200, jgr...@suse.com wrote: From: Juergen Gross If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's private command pool is needed. scsi_find_host_cmd_pool() will locate it, but scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template. This will result in an access error when the host is removed. Avoid the problem by saving the address of a new allocated command pool where it is expected. Signed-off-by: Juergen Gross Looks good, but minor nitpick below: + if (shost->hostt->cmd_size) + shost->hostt->cmd_pool = pool; + We already have a local hostt variable for the host template in this function, please use it. Wait, that's not right at all. There looks to be a thinko in the command pool handling code. We have both a cmd_pool in the host structure and in the host template structure, but there's confusion about which one we're supposed to be using. The origin of confusion seems to be the reference counting in the pool itself ... you want the same pool for all hosts, since they can only have one cmd_size, but you want it created on first host use and destroyed again on the last one. If you take this patch, a host that attached, detaches and then attaches a host will panic because it will use a freed pool structure. Indeed. This whole mess is created by the attempt to refcount the pools. What's wrong with simply creating the pool at init time and deleting it again at module removal ... that way no refcounting and no bogus problems like this (and we can delete the cmd_pool from the host). The restriction this would give is that cmd_size can only be set in the template, but that seems to be the only safe use anyway, since any driver trying to vary this in its host add routines will get unexpected results. OTOH it would be possible to just delete .cmd_pool in the template when deleting the pool. I'll send a patch doing this and you can decide whether to take it or to use the other solution. I'm not sure which to prefer: the init/remove version is simple, while the dynamic version requires no changes in the driver's source and the pool's resources are allocated only when really needed. Juergen -- 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] gpiolib: Don't allow drivers to specify a base with DT
On Thu, Jul 31, 2014 at 9:07 PM, Mark Brown wrote:
> From: Mark Brown
>
> DT based systems should have no reason to use fixed GPIO numbers but some
> drivers that work on both DT and non-DT platforms specify them anyway. In
> order to improve robustness in cases where drivers use gpio_is_valid() to
> check for a valid GPIO on data initialized to zero as a default and avoid
> bugs due to assuptions about fixed numbers creeping in ignore any specified
> base when DT is in use.
I agree that DT users should not use the base number at all - but the
fact is some of them are doing it. Aren't we going to break some
user-space users that will expect to find a GPIO under a given number?
Also, how is this going to help with gpio_is_valid() against
zero-initialized data?
>
> Signed-off-by: Mark Brown
> ---
> drivers/gpio/gpiolib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 768f0831db18..11d3cf1cbca7 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -234,7 +234,7 @@ int gpiochip_add(struct gpio_chip *chip)
>
> spin_lock_irqsave(_lock, flags);
>
> - if (base < 0) {
> + if (base < 0 || of_have_populated_dt()) {
> base = gpiochip_find_base(chip->ngpio);
> if (base < 0) {
> status = base;
> --
> 2.0.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/
linux-next: build failure after merge of the drm-tegra tree
Hi Thierry,
After merging the drm-tegra tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/asm-generic/bug.h:13:0,
from arch/arm/include/asm/bug.h:61,
from include/linux/bug.h:4,
from include/linux/scatterlist.h:5,
from include/linux/dma-buf.h:29,
from drivers/gpu/drm/tegra/gem.c:16:
drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_dumb_create':
drivers/gpu/drm/tegra/gem.c:265:39: error: dereferencing pointer to incomplete
type
min_pitch = round_up(min_pitch, tegra->pitch_align);
^
include/linux/kernel.h:62:46: note: in definition of macro '__round_mask'
#define __round_mask(x, y) ((__typeof__(x))((y)-1))
^
drivers/gpu/drm/tegra/gem.c:265:14: note: in expansion of macro 'round_up'
min_pitch = round_up(min_pitch, tegra->pitch_align);
^
drivers/gpu/drm/tegra/dc.c: In function 'tegra_dc_init':
drivers/gpu/drm/tegra/dc.c:1300:29: error: 'tegra' undeclared (first use in
this function)
if (dc->soc->pitch_align > tegra->pitch_align)
^
drivers/gpu/drm/tegra/dc.c:1300:29: note: each undeclared identifier is
reported only once for each function it appears in
Caused by commit 26861f43da4e ("drm/tegra: Properly align stride for
framebuffers").
I have used the drm-tegra tree from next-20140801 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH 1/2] ASoC: fsl_sarc_dma: Check pair before using it
The patch 3117bb3109dc: "ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and
platform drivers" from Jul 29, 2014, leads to the following Smatch
complaint:
sound/soc/fsl/fsl_asrc_dma.c:304 fsl_asrc_dma_shutdown()
warn: variable dereferenced before check 'pair' (see line 302)
sound/soc/fsl/fsl_asrc_dma.c
301 struct fsl_asrc_pair *pair = runtime->private_data;
302 struct fsl_asrc *asrc_priv = pair->asrc_priv;
^^^
Dereference.
303
304 if (pair && asrc_priv->pair[pair->index] == pair)
Check.
305 asrc_priv->pair[pair->index] = NULL;
306
So we just let the driver check pair before using it.
Reported-by: Dan Carpenter
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc_dma.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index 5b1e73e..ffc000b 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -299,9 +299,14 @@ static int fsl_asrc_dma_shutdown(struct snd_pcm_substream
*substream)
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct fsl_asrc_pair *pair = runtime->private_data;
- struct fsl_asrc *asrc_priv = pair->asrc_priv;
+ struct fsl_asrc *asrc_priv;
+
+ if (!pair)
+ return 0;
+
+ asrc_priv = pair->asrc_priv;
- if (pair && asrc_priv->pair[pair->index] == pair)
+ if (asrc_priv->pair[pair->index] == pair)
asrc_priv->pair[pair->index] = NULL;
kfree(pair);
--
1.8.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 2/2] ASoC: fsl_asrc: Don't access members of config before checking it
sound/soc/fsl/fsl_asrc.c:250 fsl_asrc_config_pair()
warn: variable dereferenced before check 'config' (see line 243)
git remote add next
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git remote update next
git checkout 3117bb3109dc223e186302f5dc8ce9ed04adca90
vim +/config +250 sound/soc/fsl/fsl_asrc.c
237 */
238 static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
239 {
240 struct asrc_config *config = pair->config;
241 struct fsl_asrc *asrc_priv = pair->asrc_priv;
242 enum asrc_pair_index index = pair->index;
@243 u32 inrate = config->input_sample_rate, indiv;
244 u32 outrate = config->output_sample_rate, outdiv;
245 bool ideal = config->inclk == INCLK_NONE;
246 u32 clk_index[2], div[2];
247 int in, out, channels;
248 struct clk *clk;
249
@250 if (!config) {
251 pair_err("invalid pair config\n");
252 return -EINVAL;
253 }
Reported-by: Dan Carpenter
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 06a96f3..86f45a1 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -240,12 +240,11 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair
*pair)
struct asrc_config *config = pair->config;
struct fsl_asrc *asrc_priv = pair->asrc_priv;
enum asrc_pair_index index = pair->index;
- u32 inrate = config->input_sample_rate, indiv;
- u32 outrate = config->output_sample_rate, outdiv;
- bool ideal = config->inclk == INCLK_NONE;
+ u32 inrate, outrate, indiv, outdiv;
u32 clk_index[2], div[2];
int in, out, channels;
struct clk *clk;
+ bool ideal;
if (!config) {
pair_err("invalid pair config\n");
@@ -264,6 +263,10 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
return -EINVAL;
}
+ inrate = config->input_sample_rate;
+ outrate = config->output_sample_rate;
+ ideal = config->inclk == INCLK_NONE;
+
/* Validate input and output sample rates */
for (in = 0; in < ARRAY_SIZE(supported_input_rate); in++)
if (inrate == supported_input_rate[in])
--
1.8.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 0/2] ASoC: fsl_asrc: Fix two dereferenced variable before check
These two patches fixes two warning of dereferenced variable reported by Dan Carpenter Nicolin Chen (2): ASoC: fsl_sarc_dma: Check pair before using it ASoC: fsl_asrc: Don't access members of config before checking it sound/soc/fsl/fsl_asrc.c | 9 ++--- sound/soc/fsl/fsl_asrc_dma.c | 9 +++-- 2 files changed, 13 insertions(+), 5 deletions(-) -- 1.8.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/
Re: linux-next: build failure after merge of the gpio tree
I have sent a patch to fix this. In the meantime, if the merge
conflict of the GPIO tree on board-paz00.c is solved by taking the
GPIO version, there is no build error.
There are a few important patches pending in the GPIO tree that should
undergo testing - Stephen, do you think you could resolve the conflict
that way to enable the latest GPIO tree to be tested again?
Thanks,
Alex.
On Tue, Jul 29, 2014 at 5:42 PM, Thierry Reding wrote:
> On Tue, Jul 29, 2014 at 10:31:53AM +0200, Stephen Rothwell wrote:
>> * PGP Signed by an unknown key
>>
>> Hi Linus,
>>
>> After merging the gpio tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> In file included from arch/arm/mach-tegra/board-paz00.c:20:0:
>> include/linux/gpio/machine.h:24:2: error: unknown type name 'u16'
>> u16 chip_hwnum;
>> ^
>> include/linux/gpio/machine.h:31:19: error: field 'list' has incomplete type
>> struct list_head list;
>>^
>>
>> Caused by commit 0a6d315827ee ("gpio: split gpiod board registration
>> into machine header") or an interaction of that with commit
>> a0524acc94c9 ("ARM: tegra: Sort includes alphabetically") from the
>> arm-soc tree.
>>
>> linux/gpio/machine.h needs to include some of the same files that
>> linux/gpio/driver.h does. See Rule 1 in Documentation/SubmitChecklist.
>>
>> I have used the version of the gpio tree from next-20140728 for today.
>
> I think linux/gpio/machine.h needs at least linux/types.h (for u16,
> though I guess that "dependency" could be removed by simply making
> gpiod_lookup.chip_hwnum an unsigned int) and linux/list.h for struct
> list_head.
>
> Thierry
--
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/7] locking/rwsem: more aggressive use of optimistic spinning
On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote:
> The rwsem_can_spin_on_owner() function currently allows optimistic
> spinning only if the owner field is defined and is running. That is
> too conservative as it will cause some tasks to miss the opportunity
> of doing spinning in case the owner hasn't been able to set the owner
> field in time or the lock has just become available.
>
> This patch enables more aggressive use of optimistic spinning by
> assuming that the lock is spinnable unless proved otherwise.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index d058946..dce22b8 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -285,7 +285,7 @@ static inline bool rwsem_try_write_lock_unqueued(struct
> rw_semaphore *sem)
> static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
> {
> struct task_struct *owner;
> - bool on_cpu = false;
> + bool on_cpu = true; /* Assume spinnable unless proved not to be */
Hi,
So "on_cpu = true" was recently converted to "on_cpu = false" in order
to address issues such as a 5x performance regression in the xfs_repair
workload that was caused by the original rwsem optimistic spinning code.
However, patch 4 in this patchset does address some of the problems with
spinning when there are readers. CC'ing Dave Chinner, who did the
testing with the xfs_repair workload.
--
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/7] locking/rwsem: more aggressive use of optimistic spinning
On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote:
> The rwsem_can_spin_on_owner() function currently allows optimistic
> spinning only if the owner field is defined and is running. That is
> too conservative as it will cause some tasks to miss the opportunity
> of doing spinning in case the owner hasn't been able to set the owner
> field in time or the lock has just become available.
>
> This patch enables more aggressive use of optimistic spinning by
> assuming that the lock is spinnable unless proved otherwise.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index d058946..dce22b8 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -285,7 +285,7 @@ static inline bool rwsem_try_write_lock_unqueued(struct
> rw_semaphore *sem)
> static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
> {
> struct task_struct *owner;
> - bool on_cpu = false;
> + bool on_cpu = true; /* Assume spinnable unless proved not to be */
Nope, unfortunately we need as it fixes some pretty bad regressions when
dealing with multiple readers -- as readers do not deal with lock
ownership, so another thread can spin for too long in !owner. See commit
37e95624.
--
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] v4l2: Change call of function in videobuf2-core.c
On 4 August 2014 13:25, Nicholas Krause wrote: > This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE > inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR. > Please go back and read every mail sent to you in the last few weeks. then read them again, go nuts read them again. Still wondering where I'm going with this? read them again. then understand that I mean this in the nicest way possible. "please fuck off." you are wasting developers time. Dave. -- 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] MAINTAINERS: update GPIO include files
Files under include/linux/gpio/ were not reported as part of the GPIO subsystem. Fix this. Signed-off-by: Alexandre Courbot --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5e0d24dcb122..d9ca71a31101 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4031,7 +4031,8 @@ T:git git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git S: Maintained F: Documentation/gpio/ F: drivers/gpio/ -F: include/linux/gpio* +F: include/linux/gpio/ +F: include/linux/gpio.h F: include/asm-generic/gpio.h GRE DEMULTIPLEXER DRIVER -- 2.0.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] gpio: add missing includes in machine.h
linux/types.h and linux/list.h should be included so the typed used in
the header file are always properly declared.
Reported-by: Stephen Rothwell
Reported-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
include/linux/gpio/machine.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index b8ad87fab4ce..e2706140eaff 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -1,6 +1,9 @@
#ifndef __LINUX_GPIO_MACHINE_H
#define __LINUX_GPIO_MACHINE_H
+#include
+#include
+
enum gpio_lookup_flags {
GPIO_ACTIVE_HIGH = (0 << 0),
GPIO_ACTIVE_LOW = (1 << 0),
--
2.0.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/
linux-next: manual merge of the infiniband tree with the net-next tree
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
include/linux/mlx4/device.h between commit 2599d8580f93
("net/mlx4_core: Use low memory profile on kdump kernel") from the
net-next tree and commit e630664c8383 ("mlx4_core: Add helper functions
to support MR re-registration") from the infiniband tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/mlx4/device.h
index e15b1544ea83,bac002167ace..
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@@ -1254,11 -1244,19 +1255,26 @@@ int mlx4_vf_smi_enabled(struct mlx4_de
int mlx4_vf_get_enable_smi_admin(struct mlx4_dev *dev, int slave, int port);
int mlx4_vf_set_enable_smi_admin(struct mlx4_dev *dev, int slave, int port,
int enable);
+ int mlx4_mr_hw_get_mpt(struct mlx4_dev *dev, struct mlx4_mr *mmr,
+ struct mlx4_mpt_entry ***mpt_entry);
+ int mlx4_mr_hw_write_mpt(struct mlx4_dev *dev, struct mlx4_mr *mmr,
+struct mlx4_mpt_entry **mpt_entry);
+ int mlx4_mr_hw_change_pd(struct mlx4_dev *dev, struct mlx4_mpt_entry
*mpt_entry,
+u32 pdn);
+ int mlx4_mr_hw_change_access(struct mlx4_dev *dev,
+struct mlx4_mpt_entry *mpt_entry,
+u32 access);
+ void mlx4_mr_hw_put_mpt(struct mlx4_dev *dev,
+ struct mlx4_mpt_entry **mpt_entry);
+ void mlx4_mr_rereg_mem_cleanup(struct mlx4_dev *dev, struct mlx4_mr *mr);
+ int mlx4_mr_rereg_mem_write(struct mlx4_dev *dev, struct mlx4_mr *mr,
+ u64 iova, u64 size, int npages,
+ int page_shift, struct mlx4_mpt_entry *mpt_entry);
+
+/* Returns true if running in low memory profile (kdump kernel) */
+static inline bool mlx4_low_memory_profile(void)
+{
+ return reset_devices;
+}
+
#endif /* MLX4_DEVICE_H */
signature.asc
Description: PGP signature
Re: [PATCH v1.3 4/18] arcmsr: limit max. number of SCSI command request
On Fri, 2014-08-01 at 05:35 -0700, Christoph Hellwig wrote: > > @@ -2220,8 +2220,7 @@ static int arcmsr_queue_command_lck(stru > > arcmsr_handle_virtual_command(acb, cmd); > > return 0; > > } > > - if (atomic_read(>ccboutstandingcount) >= > > - ARCMSR_MAX_OUTSTANDING_CMD) > > + if (atomic_read(>ccboutstandingcount) >= acb->maxOutstanding) > > return SCSI_MLQUEUE_HOST_BUSY; > > The scsi midlayer already takes care of this check for you. > Hello Christoph, We have 4 types of Adapter that some adpaters have command queue less than ARCMSR_MAX_OUTSTANDING_CMD. So we have to check outstanding command number here. Thanks for your comment. Ching -- 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 2/18] arcmsr: Add code to support MSI-X, MSI interrupt
From: Ching Huang
Changes in v2 of 2/18:
* remove the checking of capability of MSI-X, MSI.
* correct the wrong IRQ vector of request_irq failed.
* replace pci_enable_msi_range() by pci_enable_msi_exact().
Signed-off-by: Ching Huang
---
Thanks for Dan's advice.
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-04-28 16:02:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:24:36.0 +0800
@@ -64,6 +64,7 @@ struct device_attribute;
#define ARCMSR_MAX_HBB_POSTQUEUE
264
#define ARCMSR_MAX_XFER_LEN
0x26000 /* 152K */
#define ARCMSR_CDB_SG_PAGE_LENGTH
256
+#define ARCMST_NUM_MSIX_VECTORS4
#ifndef PCI_DEVICE_ID_ARECA_1880
#define PCI_DEVICE_ID_ARECA_1880 0x1880
#endif
@@ -508,6 +509,7 @@ struct AdapterControlBlock
struct pci_dev *pdev;
struct Scsi_Host * host;
unsigned long vir2phy_offset;
+ struct msix_entry entries[ARCMST_NUM_MSIX_VECTORS];
/* Offset is used in making arc cdb physical to virtual calculations */
uint32_toutbound_int_enable;
uint32_tcdb_phyaddr_hi32;
@@ -544,6 +546,8 @@ struct AdapterControlBlock
/* iop init */
#define ACB_F_ABORT 0x0200
#define ACB_F_FIRMWARE_TRAP 0x0400
+ #define ACB_F_MSI_ENABLED 0x1000
+ #define ACB_F_MSIX_ENABLED 0x2000
struct CommandControlBlock *
pccb_pool[ARCMSR_MAX_FREECCB_NUM];
/* used for memory free */
struct list_headccb_free_list;
@@ -594,6 +598,7 @@ struct AdapterControlBlock
#define FW_DEADLOCK 0x0010
atomic_trq_map_token;
atomic_tante_token_value;
+ int msix_vector_count;
};/* HW_DEVICE_EXTENSION */
/*
***
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-01 11:02:44.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-01 17:54:46.0 +0800
@@ -603,6 +603,56 @@ static void arcmsr_message_isr_bh_fn(str
}
}
+static int
+arcmsr_request_irq(struct pci_dev *pdev, struct AdapterControlBlock *acb)
+{
+ int i, j, r;
+ struct msix_entry entries[ARCMST_NUM_MSIX_VECTORS];
+
+ for (i = 0; i < ARCMST_NUM_MSIX_VECTORS; i++)
+ entries[i].entry = i;
+ r = pci_enable_msix_range(pdev, entries, 1, ARCMST_NUM_MSIX_VECTORS);
+ if (r < 0)
+ goto msi_int;
+ acb->msix_vector_count = r;
+ for (i = 0; i < r; i++) {
+ if (request_irq(entries[i].vector,
+ arcmsr_do_interrupt, 0, "arcmsr", acb)) {
+ pr_warn("arcmsr%d: request_irq =%d failed!\n",
+ acb->host->host_no, entries[i].vector);
+ for (j = 0 ; j < i ; j++)
+ free_irq(entries[j].vector, acb);
+ pci_disable_msix(pdev);
+ goto msi_int;
+ }
+ acb->entries[i] = entries[i];
+ }
+ acb->acb_flags |= ACB_F_MSIX_ENABLED;
+ pr_info("arcmsr%d: msi-x enabled\n", acb->host->host_no);
+ return SUCCESS;
+msi_int:
+ if (pci_enable_msi_exact(pdev, 1) < 0)
+ goto legacy_int;
+ if (request_irq(pdev->irq, arcmsr_do_interrupt,
+ IRQF_SHARED, "arcmsr", acb)) {
+ pr_warn("arcmsr%d: request_irq =%d failed!\n",
+ acb->host->host_no, pdev->irq);
+ pci_disable_msi(pdev);
+ goto legacy_int;
+ }
+ acb->acb_flags |= ACB_F_MSI_ENABLED;
+ pr_info("arcmsr%d: msi enabled\n", acb->host->host_no);
+ return SUCCESS;
+legacy_int:
+ if (request_irq(pdev->irq, arcmsr_do_interrupt,
+ IRQF_SHARED, "arcmsr", acb)) {
+ pr_warn("arcmsr%d: request_irq = %d failed!\n",
+ acb->host->host_no, pdev->irq);
+ return FAILED;
+ }
+ return SUCCESS;
+}
+
static int arcmsr_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct Scsi_Host *host;
@@ -667,16 +717,13 @@ static int arcmsr_probe(struct pci_dev *
if(error){
goto free_hbb_mu;
}
- arcmsr_iop_init(acb);
error = scsi_add_host(host, >dev);
if(error){
goto RAID_controller_stop;
}
- error = request_irq(pdev->irq, arcmsr_do_interrupt,
Re: [PATCH] checkpatch: Add test for printf formats with 0x that emit decimal
On Sun, 2014-08-03 at 20:03 -0700, Hans Wennborg wrote:
> On 08/03/2014 07:50 PM, Joe Perches wrote:
> > 0x% should be used to emit hexadecimal values.
> >
> > Uses of 0x%[udi] emit decimal values but these should
> > probably instead use 0x%x variants.
> >
> > Warn on these uses.
>
> Good idea!
[]
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> > @@ -4985,6 +4985,10 @@ sub process {
> > while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) {
> > $string = substr($rawline, $-[1], $+[1] - $-[1]);
> > $string =~ s/%%/__/g;
> > + if ($string =~
> > /(0x(?
> Maybe the regex should have a \b to check for a word boundary before the
> 0 to avoid matching things like "800x%d"? (I don't know if that occurs
> in the kernel, but I've seen it elsewhere.)
Maybe.
Code it to do the appropriate thing and test it too.
See if there any other cases that should be emitted.
cheers, 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: [PATCH v1] MIPS:KDUMP: set a right value to kexec_indirection_page variable
ping.
BR,
Wei
On 07/31/2014 07:42 PM, wei.y...@windriver.com wrote:
From: Yang Wei
Since there is not indirection page in crash type, so the vaule of the head
field of kimage structure is not equal to the address of indirection page but
IND_DONE. so we have to set kexec_indirection_page variable to the address of
the head field of image structure.
Signed-off-by: Yang Wei
Hi Ralf,
Please help me take a look at this patch, I have already
verified it on Cavium 6100EVB board.
Thanks
Wei
---
arch/mips/kernel/machine_kexec.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c
index 992e184..531b70d 100644
--- a/arch/mips/kernel/machine_kexec.c
+++ b/arch/mips/kernel/machine_kexec.c
@@ -71,8 +71,13 @@ machine_kexec(struct kimage *image)
kexec_start_address =
(unsigned long) phys_to_virt(image->start);
- kexec_indirection_page =
- (unsigned long) phys_to_virt(image->head & PAGE_MASK);
+ if (image->type == KEXEC_TYPE_DEFAULT) {
+ kexec_indirection_page =
+ (unsigned long) phys_to_virt(image->head & PAGE_MASK);
+ } else {
+ kexec_indirection_page = (unsigned long)>head;
+ }
+
memcpy((void*)reboot_code_buffer, relocate_new_kernel,
relocate_new_kernel_size);
--
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] bridge:Add rcu read lock when delete br port
From: Chunhe Li
In the br_hanle_frame function has a bug, when the bridge receive packets
which go througth the br_handle_frame, get the net_bridge_port pointer "p",
but don't check NULL pointer to use it. If somebody delete the bridge port
at the same time, will call a NULL pointer, trigger kernel panic. I see the
del_nbp comments, call del_nbp should via RCU, but the caller don't do this.
following steps will make bug happened
1.start vm and add the vm interface to a bridge br0,for example,
brctl addbr br0 tap0
2.configuer vm interface and br0 same ip subnet, vm ping br0.
3.add and delete the vm interface port for endless loop.
Signed-off-by: Chunhe Li
---
net/bridge/br_if.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 3eca3fd..91c611d 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -274,9 +274,11 @@ void br_dev_delete(struct net_device *dev, struct
list_head *head)
struct net_bridge *br = netdev_priv(dev);
struct net_bridge_port *p, *n;
+ rcu_read_lock();
list_for_each_entry_safe(p, n, >port_list, list) {
del_nbp(p);
}
+ rcu_read_unlock();
br_fdb_delete_by_port(br, NULL, 1);
@@ -550,7 +552,9 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
* there still maybe an alternate path for netconsole to use;
* therefore there is no reason for a NETDEV_RELEASE event.
*/
+ rcu_read_lock();
del_nbp(p);
+ rcu_read_unlock();
spin_lock_bh(>lock);
changed_addr = br_stp_recalculate_bridge_id(br);
--
1.9.2.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 00/11] Refactor MSI to support Non-PCI device
On 2014/8/1 21:16, Arnd Bergmann wrote: > On Wednesday 30 July 2014, Yijing Wang wrote: > > The other part I'm not completely sure about is how you want to > have MSIs map into normal IRQ descriptors. At the moment, all > MSI users are based on IRQ numbers, but this has known scalability > problems. Hmmm, I still use the IRQ number to map the MSIs to IRQ description. I'm sorry, I don't understand you meaning. What are the scalability problems you mentioned ? >>> We have soft limitation of nr_irqs or hard limitation NR_IRQS, >>> we couldn't allocate as much irq number as we need in some cases, >>> such as to support MSI-x. >> >> Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) > > This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ > and the number of interrupts is not limited in any form. > > My point was more that the device driver should not need to care about > the interrupt number: it gets made up on the spot when the MSI is > needed, and then it is only used to request the IRQ. This can be > simplified into one interface at the device driver level, even though > the internal still use numbers somewhere. If we ever remove IRQ numbers > from the driver API, this part doesn't need to get touched again. > Hi Arnd, I have another question is some drivers will request more than one MSI/MSI-X IRQ, and the driver will use them to process different things. Eg. network driver generally uses one of them to process trivial network thins, and others to transmit/receive data. So, in this case, it seems to driver need to touch the IRQ numbers. wr-linux:~ # cat /proc/interrupts CPU0 CPU1 CPU2 CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 .. 100: 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 101: 2 0 0 0 0 0 302830488 0 0 0 IR-PCI-MSI-edge eth0-TxRx-0 102:110 0 0 0 0 360675897 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-1 103:109 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-2 104:107 0 0 9678933 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-3 105:107 0 0 0 357838258 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-4 106:115 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-5 107:114 0 0 0 0 0 0 337866096 0 0 IR-PCI-MSI-edge eth0-TxRx-6 108: 373801199 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-7 Thanks! Yijing. > > . > -- Thanks! Yijing -- 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: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/sysctl_net_ipv6.c between commit 166bd890a3d8 ("ipv6: data of
fwmark_reflect sysctl needs to be updated on netns construction") from
the net tree and commit cb1ce2ef387b ("ipv6: Implement automatic flow
label generation on transmit") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/ipv6/sysctl_net_ipv6.c
index 818334619abb,5bf7b61f8ae8..
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@@ -74,7 -81,7 +81,8 @@@ static int __net_init ipv6_sysctl_net_i
ipv6_table[0].data = >ipv6.sysctl.bindv6only;
ipv6_table[1].data = >ipv6.sysctl.anycast_src_echo_reply;
ipv6_table[2].data = >ipv6.sysctl.flowlabel_consistency;
- ipv6_table[3].data = >ipv6.sysctl.fwmark_reflect;
+ ipv6_table[3].data = >ipv6.sysctl.auto_flowlabels;
++ ipv6_table[4].data = >ipv6.sysctl.fwmark_reflect;
ipv6_route_table = ipv6_route_sysctl_init(net);
if (!ipv6_route_table)
signature.asc
Description: PGP signature
[PATCH] v4l2: Change call of function in videobuf2-core.c
This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE
inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR.
Signed-off-by: Nicholas Krause
---
drivers/media/v4l2-core/videobuf2-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c4489c..08e478b 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2115,7 +2115,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
if (WARN_ON(atomic_read(>owned_by_drv_count))) {
for (i = 0; i < q->num_buffers; ++i)
if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
- vb2_buffer_done(q->bufs[i],
VB2_BUF_STATE_ERROR);
+ vb2_buffer_done(q->bufs[i],
VB2_BUF_STATE_ACTIVE);
/* Must be zero now */
WARN_ON(atomic_read(>owned_by_drv_count));
}
--
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: 3.15.6 USB issue with pwc cam
On Sun, Aug 3, 2014 at 3:59 PM, Nick Krause wrote: > On Sat, Aug 2, 2014 at 9:10 AM, Udo van den Heuvel wrote: >> Hello, >> >> I moved a PWC webcam to a USB3 port, and this happened: >> >> [53008.911811] usb 5-2: new full-speed USB device number 2 using xhci_hcd >> [53009.213504] usb 5-2: New USB device found, idVendor=0471, idProduct=0311 >> [53009.213514] usb 5-2: New USB device strings: Mfr=0, Product=0, >> SerialNumber=1 >> [53009.213519] usb 5-2: SerialNumber: 0169A500 >> [53009.215547] pwc: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) >> USB webcam detected. >> [53009.846698] pwc: Registered as video0. >> [53009.846814] input: PWC snapshot button as >> /devices/pci:00/:00:07.0/:02:00.0/usb5/5-2/input/input7 >> [53009.847233] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53009.847242] usb 5-2: Not enough bandwidth for altsetting 1 >> [53009.847275] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53009.847285] usb 5-2: Not enough bandwidth for altsetting 2 >> [53009.847317] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53009.847323] usb 5-2: Not enough bandwidth for altsetting 3 >> [53009.847355] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53009.847360] usb 5-2: Not enough bandwidth for altsetting 4 >> [53010.004876] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.004890] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.004896] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.004960] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.004988] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.004992] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.005066] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.005075] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.005079] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.005530] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.005540] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.005544] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.006438] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.006446] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.006450] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.007453] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.007461] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.007465] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.007567] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.007574] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.007578] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.007681] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.007689] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.007695] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.008126] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.008135] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.008140] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.008798] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.008808] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.008812] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.009576] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.009583] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.009588] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.009680] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.009689] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.009697] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.009978] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.009986] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.009990] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.010705] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.010716] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.010725] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.011350] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.011360] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.011366] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.012643] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >> [53010.012655] usb 5-2: Not enough bandwidth for altsetting 1 >> [53010.012660] usb 5-2: 2:1: usb_set_interface failed (-22) >> [53010.012758] xhci_hcd :02:00.0: ERROR: unexpected command >> completion code 0x11. >>
Re: scheduler crash on Power
On Fri, 2014-08-01 at 14:24 -0700, Sukadev Bhattiprolu wrote:
> Dietmar Eggemann [dietmar.eggem...@arm.com] wrote:
> | > ltcbrazos2-lp07 login: [ 181.915974] [ cut here ]
> | > [ 181.915991] WARNING: at ../kernel/sched/core.c:5881
> |
> | This warning indicates the problem. One of the struct sched_domains does
> | not have it's groups member set.
> |
> | And its happening during a rebuild of the sched domain hierarchy, not
> | during the initial build.
> |
> | You could run your system with the following patch-let (on top of
> | https://lkml.org/lkml/2014/7/17/288) w/ and w/o the perf related
> | patches (w/ CONFIG_SCHED_DEBUG enabled).
> |
> | @@ -5882,6 +5882,9 @@ static void init_sched_groups_capacity(int cpu,
> | struct sched_domain *sd)
> | {
> | struct sched_group *sg = sd->groups;
> |
> | +#ifdef CONFIG_SCHED_DEBUG
> | + printk("sd name: %s span: %pc\n", sd->name, sd->span);
> | +#endif
> | WARN_ON(!sg);
> |
> | do {
> |
> | This will show if the rebuild of the sched domain hierarchy happens on
> | both systems and hopefully indicate for which sched_domain the
> | sd->groups is not set.
>
> Thanks for the patch. It appears that the NUMA sched domain does not
> have the sd->groups set - snippet of the error (with your patch and
> Peter's patch)
>
> [ 181.914494] build_sched_groups: got group c6da with cpus:
> [ 181.914498] build_sched_groups: got group c000dd83 with cpus:
> [ 181.915234] sd name: SMT span: 8-15
> [ 181.915239] sd name: DIE span: 0-7
> [ 181.915242] sd name: NUMA span: 0-15
> [ 181.915250] [ cut here ]
> [ 181.915253] WARNING: at ../kernel/sched/core.c:5891
>
> Patched code:
>
> 5884 static void init_sched_groups_capacity(int cpu, struct
> sched_domain *sd)
> 5885 {
> 5886 struct sched_group *sg = sd->groups;
> 5887
> 5888 #ifdef CONFIG_SCHED_DEBUG
> 5889 printk("sd name: %s span: %pc\n", sd->name, sd->span);
> 5890 #endif
> 5891 WARN_ON(!sg);
>
> Complete log below.
>
> I was able to bisect it down to this patch in the 24x7 patchset
>
> https://lkml.org/lkml/2014/5/27/804
>
> I replaced the kfree(page) calls in the patch with
> kmem_cache_free(hv_page_cache, page).
>
> The problem sems to disappear if the call to create_events_from_catalog()
> in hv_24x7_init() is skipped. I am continuing to debug the 24x7 patch.
Is that patch just clobbering memory it doesn't own and corrupting the
scheduler data structures?
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 1/3] irq / PM: New driver interface for wakeup interruptsn
On Sunday, August 03, 2014 03:42:49 PM Rafael J. Wysocki wrote:
> On Saturday, August 02, 2014 03:31:01 AM Rafael J. Wysocki wrote:
> > On Friday, August 01, 2014 04:29:40 PM Rafael J. Wysocki wrote:
> > > On Friday, August 01, 2014 03:43:21 PM Thomas Gleixner wrote:
> > > > On Fri, 1 Aug 2014, Rafael J. Wysocki wrote:
> > > > > OK, I guess "IRQ_HANDLED from a wakeup interrupt" may be interpreted
> > > > > as
> > > > > IRQ_HANDLED_PMWAKE. On the other hand, if that's going to be handled
> > > > > in
> > > > > handle_irq_event_percpu(), then using a special return code would
> > > > > save us
> > > > > a brach for IRQ_HANDLED interrupts. We could convert it to
> > > > > IRQ_HANDLED
> > > > > immediately then.
> > > >
> > > > We can handle it at the end of the function by calling
> > > > note_interrupt() unconditionally do the following there:
> > > >
> > > > if (suspended) {
> > > > if (ret == IRQ_NONE) {
> > > > if (shared)
> > > >yell_and_abort_or_resume();
> > > > } else {
> > > > abort_or_resume();
> > > > }
> > > > }
> > > > if (noirqdebug)
> > > > return;
> > >
> > > I see.
> > >
> > > > > OK, I'll take a stab at the IRQF_SHARED thing if you don't mind.
> > > >
> > > > Definitely not :)
> > > >
> > > > > Here's my current understanding of what can be done for
> > > > > IRQF_NO_SUSPEND.
> > > > >
> > > > > In suspend_device_irqs():
> > > > >
> > > > > (1) If all actions in the list have the same setting (eg.
> > > > > IRQF_NO_SUSPEND unset),
> > > > > keep the current behavior.
> > > > > (2) If the actions have different settings:
> > > > > - Actions with IRQF_NO_SUSPEND set are not modified.
> > > > > - Actions with IRQF_NO_SUSPEND unset are switched over to a stub
> > > > > handler.
> > > > > - IRQS_SUSPEND_MODE (new flag) is set for the IRQ.
> > > >
> > > > Can we please do that in setup_irq() and let the shared ones always
> > > > run through the stub? That keeps suspend/resume_device_irqs() simple.
> > >
> > > OK
> >
> > I've tried to do that, but encountered a problem. The stub handler is
> > called
> > with irq, dev_id as arguments and for the "interrupts are not suspended"
> > case
> > (common) it has to use irq to find the irq_desc and then it has to use
> > dev_id
> > to find the irqaction to call the original handler from there. That seemed
> > to
> > be a bit too much of a penalty to me. Especially for people who never
> > suspend
> > their machines. :-)
> >
> > For this reason, I went for changing handlers in suspend_device_irqs() and
> > back in resume_device_irqs(). That's not terribly complicated (the
> > restoration
> > in particular is pretty simple) and it should be easily reusable for the
> > wakeup
> > interrupts case. resume_device_irqs() wouldn't need any more changes for
> > that,
> > for example. It minimally affects systems that don't suspend too.
> >
> > I also ended up adding a new interrupt handler return code (IRQ_SUSPENDED).
> > I could add a new irq_desc flag instead, but then the new code in
> > suspend_device_irqs()
> > and the new check in note_interrupt() would need to be slightly more
> > complicated.
>
> Actually, if we have a global irqs_suspended state variable, it will be much
> simpler to handle wakeup interrupts going forward, because in that case we'll
> be able to keep their original interrupt handlers and IRQ_HANDLED from them
> will be interpreted as a wakeup event automatically.
I realized that with this, suspend_device_irqs() will be racy, because it
switches handlers and modifies irqs_suspended at different times then.
I'm not sure how much of a problem that would be, but it's better to
ensure that both the handler and note_interrupt() will be "switched" at
the same time, which means addin a wrapper handler at the __setup_irq()
time, after all.
To avoid the problem mentioned above, I'm using dev_id to store the action's
address and an additional "real dev_id" field to store the original value.
This version seems to work.
Rafael
---
drivers/base/power/main.c |1
drivers/base/power/wakeup.c | 20
include/linux/interrupt.h |4 +++
include/linux/irqdesc.h |1
include/linux/suspend.h |3 ++
kernel/irq/handle.c |3 --
kernel/irq/internals.h |3 ++
kernel/irq/manage.c | 53 ++--
kernel/irq/pm.c | 10
kernel/irq/spurious.c | 13 ++
10 files changed, 103 insertions(+), 8 deletions(-)
Index: linux-pm/kernel/irq/manage.c
===
--- linux-pm.orig/kernel/irq/manage.c
+++ linux-pm/kernel/irq/manage.c
@@ -385,7 +385,7 @@ setup_affinity(unsigned int irq, struct
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action ||
[PATCH net/net-next] bonding:Don't received packets if bonding is not up
From: Chunhe Li
If the bonding device is down, it should not receive packets
to network stack or other upper flow stack.
Signed-off-by: Chunhe Li
---
drivers/net/bonding/bond_main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 701f86c..48a127b 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1110,6 +1110,12 @@ static rx_handler_result_t bond_handle_frame(struct
sk_buff **pskb)
int (*recv_probe)(const struct sk_buff *, struct bonding *,
struct slave *);
int ret = RX_HANDLER_ANOTHER;
+
+ slave = bond_slave_get_rcu(skb->dev);
+ bond = slave->bond;
+
+ if (unlikely(!(bond->dev->flags & IFF_UP)))
+ return RX_HANDLER_PASS;
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
@@ -1117,9 +1123,6 @@ static rx_handler_result_t bond_handle_frame(struct
sk_buff **pskb)
*pskb = skb;
- slave = bond_slave_get_rcu(skb->dev);
- bond = slave->bond;
-
recv_probe = ACCESS_ONCE(bond->recv_probe);
if (recv_probe) {
ret = recv_probe(skb, bond, slave);
--
1.9.2.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 -tip v2] [BUGFIX] kprobes: Skip kretprobe hit in NMI context to avoid deadlock
Skip kretprobe hit in NMI context, because if an NMI happens
inside the critical section protected by kretprobe_table.lock
and another(or same) kretprobe hit, pre_kretprobe_handler
tries to lock kretprobe_table.lock again.
Normal interrupts have no problem because they are disabled
with the lock.
Changes in v2:
- Add unlikely for in_nmi.
- Add a comment for nmissed counter.
Signed-off-by: Masami Hiramatsu
Acked-by: Ananth N Mavinakayanahalli
Cc: Ingo Molnar
Cc: "David S. Miller"
---
kernel/kprobes.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 734e9a7..138219b 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1778,6 +1778,16 @@ static int pre_handler_kretprobe(struct kprobe *p,
struct pt_regs *regs)
unsigned long hash, flags = 0;
struct kretprobe_instance *ri;
+ /* To avoid deadlock, prohibit return probing in NMI context */
+ if (unlikely(in_nmi())) {
+ /*
+* Do not get a lock. nmissed is not accurate.
+* This just informs user some misses are happened.
+*/
+ rp->nmissed++;
+ return 0;
+ }
+
/*TODO: consider to only swap the RA after the last pre_handler fired */
hash = hash_ptr(current, KPROBE_HASH_BITS);
raw_spin_lock_irqsave(>lock, flags);
--
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 00/11] Refactor MSI to support Non-PCI device
>> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes >> are bonding with PCI device. Because MSI has a lot advantages in design. >> More and more non-PCI devices want to use MSI as their default interrupt. >> The existing MSI device include HPET. HPET driver provide its own MSI >> code to initialize and process MSI interrupts. In the latest GIC v3 spec, >> legacy device can deliver MSI by the help of a relay device named >> consolidator. >> Consolidator can translate the legacy interrupts connected to it to >> MSI/MSI-X. And new non-PCI device will be designed to support MSI in >> future. So make the MSI driver code be generic will help the non-PCI >> device use MSI more simply. > > As per my understanding the GICv3 provides a service that will convert writes > to a specified address to IRQs delivered to the core and as you mention above > MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices > to want MSI like functionality without being fully compliant with the > requirements of the MSI spec. In GICv3, MBI is named for the service, but there is no more detailed information about it, only we can know is MBI is analogous to MSI, MBI devices must have address/data registers, but other registers like enable/mask/ctrl are not mandatory requirement. I don't know whether the MBI spec will be release, but anyway I think MSI refactoring is make sense, there are some existing Non-PCI MSI device like hpet, dmar. For simplicity, let name MSI and MBI to MSI temporarily. > > My question is do we necessarily want to rework so much of the PCI-MSI layer > to support non PCI devices? Or will it be sufficient to create a framework to > allow non PCI devices to hook up with a device that can convert their writes > to an IRQ to the core. > > As I understand it, the msi_chip is (almost) such a framework. The only > problem being that it makes some PCI specific assumptions (such as PCI > specific writes from within msi_chip functions). Won't it be sufficient to > make the msi_chip framework generic enough to be used by non-PCI devices and > let each bus/device manage any additional requirements (such as configuration > flow, bit definitions etc) that it places on message based interrupts? msi_chip framework is important to support that, but I think maybe it's not enough, msi_chip is only responsible for IRQ allocation, teardown, etc.. The key difference between PCI device and Non-PCI MSI is the interfaces to access hardware MSI registers. for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure the MSI address/data registers, so we need to provide device specific write_msi_msg() interface, then when we call msi_chip->setup_irq(), the device MSI registers can be configured appropriately. My patchset is just a RFC draft, I will update it later, all we want to do is make kernel support Non-PCI MSI devices. Thanks! Yijing. > > Thanks > Arnab > -- > 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/ > > . > -- Thanks! Yijing -- 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 4/5] x86: entry_64.S: always allocate complete "struct pt_regs"
On Sat, Aug 2, 2014 at 1:19 AM, Frederic Weisbecker wrote: > On Fri, Aug 01, 2014 at 04:48:17PM +0200, Denys Vlasenko wrote: >> >> /* 0(%rsp): ~(interrupt number) */ >> .macro interrupt func >> - /* reserve pt_regs for scratch regs and rbp */ >> - subq $ORIG_RAX-RBP, %rsp >> - CFI_ADJUST_CFA_OFFSET ORIG_RAX-RBP >> - cld >> - /* start from rbp in pt_regs and jump over */ >> - movq_cfi rdi, (RDI-RBP) >> - movq_cfi rsi, (RSI-RBP) >> - movq_cfi rdx, (RDX-RBP) >> - movq_cfi rcx, (RCX-RBP) >> - movq_cfi rax, (RAX-RBP) >> - movq_cfi r8, (R8-RBP) >> - movq_cfi r9, (R9-RBP) >> - movq_cfi r10, (R10-RBP) >> - movq_cfi r11, (R11-RBP) >> - >> - /* Save rbp so that we can unwind from get_irq_regs() */ >> - movq_cfi rbp, 0 > > Hmm SAVEE_C_REGS below doesn't seem to save rbp like we did before. > Perhaps it's implicitely saved somewhere? > >> - >> - /* Save previous stack value */ >> - movq %rsp, %rsi > > Also rsp isn't saved in %rsi like before. Maybe > that's because we already save it in rdi? Makes sense since > now arg1 == rsp. More on that later. > >> - >> - leaq -RBP(%rsp),%rdi/* arg1 for handler */ >> - testl $3, CS-RBP(%rsi) >> + ALLOC_PTREGS_ON_STACK >> + SAVE_C_REGS >> + movq %rsp, %rdi /* arg1 for handler */ >> + testl $3, CS(%rsp) >> je 1f >> SWAPGS >> - /* >> +1: /* >>* irq_count is used to check if a CPU is already on an interrupt stack >>* or not. While this is essentially redundant with preempt_count it is >>* a little cheaper to use a separate counter in the PDA (short of >>* moving irq_enter into assembly, which would be too much work) >>*/ >> -1: incl PER_CPU_VAR(irq_count) >> + incl PER_CPU_VAR(irq_count) >> cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp >> - CFI_DEF_CFA_REGISTERrsi >> + CFI_DEF_CFA_REGISTERrdi >> >> /* Store previous stack value */ >> - pushq %rsi >> + pushq %rdi > > So you push rdi instead... > >> CFI_ESCAPE 0x0f /* DW_CFA_def_cfa_expression */, 6, \ >> 0x77 /* DW_OP_breg7 */, 0, \ >> 0x06 /* DW_OP_deref */, \ >> - 0x08 /* DW_OP_const1u */, SS+8-RBP, \ >> + 0x08 /* DW_OP_const1u */, SS+8, \ >> 0x22 /* DW_OP_plus */ >> /* We entered an interrupt context - irqs are off: */ >> TRACE_IRQS_OFF >> - >> call \func >> .endm >> >> @@ -749,10 +719,9 @@ ret_from_intr: >> >> /* Restore saved previous stack */ >> popq %rsi > > And then you pop to rsi. Ok that indeed works but perhaps we should keep it > symetrical > just for clarity? Any reason why we can't reuse rdi here? I changed this entire area in v2: basically, I will not change the logic, but will add comments explaining what are we doing here, and why. (Some minor code changes will be done, not affecting the logic). While we are at it, what this CFI_ESCAPE thing does here? As usual, it has no comment :/ -- vda -- 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] checkpatch: Add test for printf formats with 0x that emit decimal
On 08/03/2014 07:50 PM, Joe Perches wrote:
0x% should be used to emit hexadecimal values.
Uses of 0x%[udi] emit decimal values but these should
probably instead use 0x%x variants.
Warn on these uses.
Good idea!
Signed-off-by: Joe Perches
Noticed-by: Hans Wennborg
---
scripts/checkpatch.pl | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index da74e65..0178fe0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4985,6 +4985,10 @@ sub process {
while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) {
$string = substr($rawline, $-[1], $+[1] - $-[1]);
$string =~ s/%%/__/g;
+ if ($string =~
/(0x(?
Maybe the regex should have a \b to check for a word boundary before the
0 to avoid matching things like "800x%d"? (I don't know if that occurs
in the kernel, but I've seen it elsewhere.)
- Hans
--
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/
kernel: smp: WARNING at kernel/smp.c:673
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel, I've stumbled on the following spew: [ 1226.701012] WARNING: CPU: 6 PID: 8624 at kernel/smp.c:673 on_each_cpu_cond+0x27f/0x2f0() [ 1226.703128] Modules linked in: [ 1226.703955] CPU: 6 PID: 8624 Comm: trinity-c26 Tainted: GW 3.16.0-rc7-next-20140801-sasha-00047-gd6ce559 #991 [ 1226.706792] 881b2e8a3000 23830039 881b2e8a3000 [ 1226.708179] 881ada5b3978 a1ee96b4 881ada5b39b8 [ 1226.709610] 9d1ce5ba 9d2c0ddf 001b 8807d7608000 [ 1226.710966] Call Trace: [ 1226.711417] dump_stack (lib/dump_stack.c:52) [ 1226.712311] warn_slowpath_common (kernel/panic.c:432) [ 1226.715425] warn_slowpath_null (kernel/panic.c:466) [ 1226.716436] on_each_cpu_cond (kernel/smp.c:673 (discriminator 3)) [ 1226.720821] __kmem_cache_shrink (mm/slub.c:3420) [ 1226.722711] slab_memory_callback (mm/slub.c:3464 mm/slub.c:3556) [ 1226.723925] notifier_call_chain (kernel/notifier.c:93) [ 1226.725244] __blocking_notifier_call_chain (kernel/notifier.c:319) [ 1226.726310] blocking_notifier_call_chain (kernel/notifier.c:329) [ 1226.727263] memory_notify (drivers/base/memory.c:177) [ 1226.728210] __offline_pages.constprop.23 (include/linux/notifier.h:179 mm/memory_hotplug.c:1682) [ 1226.731896] offline_pages (mm/memory_hotplug.c:1787) [ 1226.733095] memory_subsys_offline (drivers/base/memory.c:267 drivers/base/memory.c:304) [ 1226.735208] device_offline (drivers/base/core.c:1428) [ 1226.736966] online_store (drivers/base/core.c:451 (discriminator 2)) [ 1226.737720] dev_attr_store (drivers/base/core.c:138) [ 1226.739986] sysfs_kf_write (fs/sysfs/file.c:116) [ 1226.742105] kernfs_fop_write (fs/kernfs/file.c:308) [ 1226.743058] do_loop_readv_writev (fs/read_write.c:708) [ 1226.745095] do_readv_writev (fs/read_write.c:840) [ 1226.752769] vfs_writev (fs/read_write.c:879) [ 1226.753755] SyS_writev (fs/read_write.c:911 fs/read_write.c:903) [ 1226.754660] tracesys (arch/x86/kernel/entry_64.S:541) No time to dig too much into this today, will work on it tomorrow. Thanks, Sasha -- 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] checkpatch: Add test for printf formats with 0x that emit decimal
0x% should be used to emit hexadecimal values.
Uses of 0x%[udi] emit decimal values but these should
probably instead use 0x%x variants.
Warn on these uses.
Signed-off-by: Joe Perches
Noticed-by: Hans Wennborg
---
scripts/checkpatch.pl | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index da74e65..0178fe0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4985,6 +4985,10 @@ sub process {
while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) {
$string = substr($rawline, $-[1], $+[1] - $-[1]);
$string =~ s/%%/__/g;
+ if ($string =~
/(0x(?http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] locking/rwsem: don't resched at the end of optimistic spinning
For a fully preemptive kernel, a call to preempt_enable() could potentially trigger a task rescheduling event. In the case of rwsem optimistic spinning, the task has either gotten the lock or is going to sleep soon. So there is no point to do rescheduling here. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c index a2391ac..d058946 100644 --- a/kernel/locking/rwsem-xadd.c +++ b/kernel/locking/rwsem-xadd.c @@ -385,7 +385,11 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem) } osq_unlock(>osq); done: - preempt_enable(); + /* +* Don't need to do rescheduling here as we either got the lock or +* is going to sleep soon. +*/ + preempt_enable_no_resched(); return taken; } -- 1.7.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/
[PATCH 2/7] locking/rwsem: more aggressive use of optimistic spinning
The rwsem_can_spin_on_owner() function currently allows optimistic
spinning only if the owner field is defined and is running. That is
too conservative as it will cause some tasks to miss the opportunity
of doing spinning in case the owner hasn't been able to set the owner
field in time or the lock has just become available.
This patch enables more aggressive use of optimistic spinning by
assuming that the lock is spinnable unless proved otherwise.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index d058946..dce22b8 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -285,7 +285,7 @@ static inline bool rwsem_try_write_lock_unqueued(struct
rw_semaphore *sem)
static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
{
struct task_struct *owner;
- bool on_cpu = false;
+ bool on_cpu = true; /* Assume spinnable unless proved not to be */
if (need_resched())
return false;
--
1.7.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/
[PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin
This patch set improves upon the rwsem optimistic spinning patch set
from Davidlohr to enable better performing rwsem and more aggressive
use of optimistic spinning.
By using a microbenchmark running 1 million lock-unlock operations per
thread on a 4-socket 40-core Westmere-EX x86-64 test machine running
3.16-rc7 based kernels, the following table shows the execution times
with 2/10 threads running on different CPUs on the same socket where
load is the number of pause instructions in the critical section:
lock/r:w ratio # of threads Load:Execution Time (ms)
--
mutex 2 1:530.7, 5:406.0, 10:472.7
mutex 10 1:1848 , 5:2046 , 10:4394
Before patch:
rwsem/0:1 2 1:339.4, 5:368.9, 10:394.0
rwsem/1:1 2 1:2915 , 5:2621 , 10:2764
rwsem/10:1 2 1:891.2, 5:779.2, 10:827.2
rwsem/0:1 10 1:5618 , 5:5722 , 10:5683
rwsem/1:1 10 1:14562, 5:14561, 10:14770
rwsem/10:1 10 1:5914 , 5:5971 , 10:5912
After patch:
rwsem/0:1 2 1:161.1, 5:244.4, 10:271.4
rwsem/1:1 2 1:188.8, 5:212.4, 10:312.9
rwsem/10:1 2 1:168.8, 5:179.5, 10:209.8
rwsem/0:1 10 1:1306 , 5:1733 , 10:1998
rwsem/1:1 10 1:1512 , 5:1602 , 10:2093
rwsem/10:110 1:1267 , 5:1458 , 10:2233
% Change:
rwsem/0:1 2 1:-52.5%, 5:-33.7%, 10:-31.1%
rwsem/1:1 2 1:-93.5%, 5:-91.9%, 10:-88.7%
rwsem/10:1 2 1:-81.1%, 5:-77.0%, 10:-74.6%
rwsem/0:1 10 1:-76.8%, 5:-69.7%, 10:-64.8%
rwsem/1:1 10 1:-89.6%, 5:-89.0%, 10:-85.8%
rwsem/10:110 1:-78.6%, 5:-75.6%, 10:-62.2%
It can be seen that there is dramatic reduction in the execution
times. The new rwsem is now even faster than mutex whether it is all
writers or a mixture of writers and readers.
Running the AIM7 benchmarks on the same 40-core system (HT off),
the performance improvements on some of the workloads were as follows:
Workload Before Patch After Patch % Change
---
custom (200-1000) 446135477404 +7.0%
custom (1100-2000)449665484734 +7.8%
high_systime 152437154217 +1.2%
(200-1000)
high_systime 269695278942 +3.4%
(1100-2000)
Waiman Long (7):
locking/rwsem: don't resched at the end of optimistic spinning
locking/rwsem: more aggressive use of optimistic spinning
locking/rwsem: check for active writer/spinner before wakeup
locking/rwsem: threshold limited spinning for active readers
locking/rwsem: move down rwsem_down_read_failed function
locking/rwsem: enables optimistic spinning for readers
locking/rwsem: allow waiting writers to go back to optimistic spinning
include/linux/osq_lock.h|5 +
include/linux/rwsem.h |7 +
kernel/locking/rwsem-xadd.c | 328 ++-
kernel/locking/rwsem.c | 17 ++-
4 files changed, 288 insertions(+), 69 deletions(-)
--
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 4/7] locking/rwsem: threshold limited spinning for active readers
Even thought only the writers can perform optimistic spinning, there
is still a chance that readers may take the lock before a spinning
writer can get it. In that case, the owner field will be NULL and the
spinning writer can spin indefinitely until its time quantum expires
when some lock owning readers are not running.
This patch tries to handle this special case by:
1) setting the owner field to a special value RWSEM_READ_OWNED
to indicate that the current or last owner is a reader.
2) seting a threshold on how many times (currently 100) spinning will
be done with active readers before giving up as there is no easy
way to determine if all of them are currently running.
By doing so, it tries to strike a balance between giving up too early
and losing potential performance gain and wasting too many precious
CPU cycles when some lock owning readers are not running.
Signed-off-by: Waiman Long
---
include/linux/rwsem.h |7 +++
kernel/locking/rwsem-xadd.c | 23 ---
kernel/locking/rwsem.c | 17 -
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 035d3c5..48e1e31 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -66,6 +66,13 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
#endif
#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
+/*
+ * The owner field is set to RWSEM_READ_OWNED if the last owner(s) are
+ * readers. It is not reset until a writer takes over and set it to its
+ * task structure pointer or NULL when it frees the lock. So a value
+ * of RWSEM_READ_OWNED doesn't mean it currently has active readers.
+ */
+#define RWSEM_READ_OWNED ((struct task_struct *)-1)
#define __RWSEM_OPT_INIT(lockname) , .osq = OSQ_LOCK_UNLOCKED, .owner = NULL
#else
#define __RWSEM_OPT_INIT(lockname)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 9f71a67..576d4cd 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -304,6 +304,11 @@ static inline bool rwsem_try_write_lock(long count, struct
rw_semaphore *sem)
#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
/*
+ * Threshold for optimistic spinning on readers
+ */
+#define RWSEM_READ_SPIN_THRESHOLD 100
+
+/*
* Try to acquire write lock before the writer has been put on wait queue.
*/
static inline bool rwsem_try_write_lock_unqueued(struct rw_semaphore *sem)
@@ -332,7 +337,7 @@ static inline bool rwsem_can_spin_on_owner(struct
rw_semaphore *sem)
rcu_read_lock();
owner = ACCESS_ONCE(sem->owner);
- if (owner)
+ if (owner && (owner != RWSEM_READ_OWNED))
on_cpu = owner->on_cpu;
rcu_read_unlock();
@@ -381,10 +386,17 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct
task_struct *owner)
return sem->owner == NULL;
}
+/*
+ * With active writer, spinning is done by checking if that writer is on
+ * CPU. With active readers, there is no easy way to determine if all of
+ * them are active. So it fall back to spin a certain number of them
+ * RWSEM_READ_SPIN_THRESHOLD before giving up.
+ */
static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
{
struct task_struct *owner;
bool taken = false;
+ int read_spincnt = 0;
preempt_disable();
@@ -397,8 +409,12 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
while (true) {
owner = ACCESS_ONCE(sem->owner);
- if (owner && !rwsem_spin_on_owner(sem, owner))
+ if (owner == RWSEM_READ_OWNED) {
+ if (++read_spincnt > RWSEM_READ_SPIN_THRESHOLD)
+ break;
+ } else if (owner && !rwsem_spin_on_owner(sem, owner)) {
break;
+ }
/* wait_lock will be acquired if write_lock is obtained */
if (rwsem_try_write_lock_unqueued(sem)) {
@@ -412,7 +428,8 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
* we're an RT task that will live-lock because we won't let
* the owner complete.
*/
- if (!owner && (need_resched() || rt_task(current)))
+ if ((!owner || (owner == RWSEM_READ_OWNED)) &&
+ (need_resched() || rt_task(current)))
break;
/*
diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
index e2d3bc7..9770439 100644
--- a/kernel/locking/rwsem.c
+++ b/kernel/locking/rwsem.c
@@ -18,6 +18,11 @@ static inline void rwsem_set_owner(struct rw_semaphore *sem)
sem->owner = current;
}
+static inline void rwsem_set_owner_read(struct rw_semaphore *sem)
+{
+ sem->owner = RWSEM_READ_OWNED;
+}
+
static inline void rwsem_clear_owner(struct rw_semaphore *sem)
{
sem->owner = NULL;
@@ -28,6 +33,10 @@ static inline void rwsem_set_owner(struct rw_semaphore *sem)
{
}
[PATCH 6/7] locking/rwsem: enables optimistic spinning for readers
This patch enables readers to go into the optimistic spinning loop
so that both the readers and writers can spin together. This could
speed up workloads that use both readers and writers.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 124 +--
1 files changed, 108 insertions(+), 16 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 86618ea..aafc9f0 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -279,6 +279,81 @@ static inline bool rwsem_try_write_lock_unqueued(struct
rw_semaphore *sem)
}
}
+/*
+ * Try to acquire read lock
+ *
+ * There is ambiguity when RWSEM_WAITING_BIAS < count < 0 as a writer may
+ * be active instead of having waiters. So we need to recheck the count
+ * under wait_lock to be sure.
+ */
+static inline bool rwsem_try_read_lock_unqueued(struct rw_semaphore *sem)
+{
+ long old, count = ACCESS_ONCE(sem->count);
+ bool taken = false; /* True if lock taken */
+
+ while (!taken) {
+ if (count < RWSEM_WAITING_BIAS)
+ break; /* Have writer and waiter */
+
+ old = count;
+ if (count >= 0 || count == RWSEM_WAITING_BIAS) {
+ count = cmpxchg(>count, old,
+ old + RWSEM_ACTIVE_READ_BIAS);
+ if (count == old) {
+ /* Got the read lock */
+ ACCESS_ONCE(sem->owner) = RWSEM_READ_OWNED;
+ taken = true;
+ /*
+* Try to wake up readers if lock is free
+*/
+ if ((count == RWSEM_WAITING_BIAS) &&
+ raw_spin_trylock_irq(>wait_lock)) {
+ if (!list_empty(>wait_list))
+ goto wake_readers;
+ raw_spin_unlock_irq(>wait_lock);
+ }
+ }
+ } else if (ACCESS_ONCE(sem->owner) == RWSEM_READ_OWNED) {
+ long threshold;
+
+ /*
+* RWSEM_WAITING_BIAS < count < 0
+*/
+ raw_spin_lock_irq(>wait_lock);
+ threshold = list_empty(>wait_list)
+ ? 0 : RWSEM_WAITING_BIAS;
+ count = ACCESS_ONCE(sem->count);
+ if (count < threshold) {
+ raw_spin_unlock_irq(>wait_lock);
+ break;
+ }
+ old = count;
+ count = cmpxchg(>count, old,
+ old + RWSEM_ACTIVE_READ_BIAS);
+ if (count == old) {
+ taken = true;
+ ACCESS_ONCE(sem->owner) = RWSEM_READ_OWNED;
+ /*
+* Wake up pending readers, if any,
+* while holding the lock.
+*/
+ if (threshold)
+ goto wake_readers;
+ }
+ raw_spin_unlock_irq(>wait_lock);
+ } else {
+ break;
+ }
+ }
+ return taken;
+
+wake_readers:
+ __rwsem_do_wake(sem, RWSEM_WAKE_READ_OWNED);
+ raw_spin_unlock_irq(>wait_lock);
+ return true;
+
+}
+
static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
{
struct task_struct *owner;
@@ -344,7 +419,8 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct
task_struct *owner)
* them are active. So it fall back to spin a certain number of them
* RWSEM_READ_SPIN_THRESHOLD before giving up.
*/
-static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
+static bool rwsem_optimistic_spin(struct rw_semaphore *sem,
+ enum rwsem_waiter_type type)
{
struct task_struct *owner;
bool taken = false;
@@ -368,11 +444,11 @@ static bool rwsem_optimistic_spin(struct rw_semaphore
*sem)
break;
}
- /* wait_lock will be acquired if write_lock is obtained */
- if (rwsem_try_write_lock_unqueued(sem)) {
- taken = true;
+ taken = (type == RWSEM_WAITING_FOR_WRITE)
+ ? rwsem_try_write_lock_unqueued(sem)
+ : rwsem_try_read_lock_unqueued(sem);
+ if (taken)
break;
- }
/*
* When there's no owner, we might have
[PATCH 3/7] locking/rwsem: check for active writer/spinner before wakeup
On a highly contended rwsem, spinlock contention due to the slow
rwsem_wake() call can be a significant portion of the total CPU cycles
used. With writer lock stealing and writer optimistic spinning, there
is also a pretty good chance that the lock may have been stolen
before the waker wakes up the waiters. The woken tasks, if any,
will have to go back to sleep again.
This patch adds checking code at the beginning of the rwsem_wake()
and __rwsem_do_wake() function to look for spinner and active
writer respectively. The presence of an active writer will abort the
wakeup operation. The presence of a spinner will still allow wakeup
operation to proceed as long as the trylock operation succeeds. This
strikes a good balance between excessive spinlock contention especially
when there are a lot of active readers and a lot of failed fastpath
operations because there are tasks waiting in the queue.
Signed-off-by: Waiman Long
---
include/linux/osq_lock.h|5
kernel/locking/rwsem-xadd.c | 57 ++-
2 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/include/linux/osq_lock.h b/include/linux/osq_lock.h
index 90230d5..79db546 100644
--- a/include/linux/osq_lock.h
+++ b/include/linux/osq_lock.h
@@ -24,4 +24,9 @@ static inline void osq_lock_init(struct optimistic_spin_queue
*lock)
atomic_set(>tail, OSQ_UNLOCKED_VAL);
}
+static inline bool osq_has_spinner(struct optimistic_spin_queue *lock)
+{
+ return atomic_read(>tail) != OSQ_UNLOCKED_VAL;
+}
+
#endif
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index dce22b8..9f71a67 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -107,6 +107,37 @@ enum rwsem_wake_type {
RWSEM_WAKE_READ_OWNED /* Waker thread holds the read lock */
};
+#ifdef CONFIG_RWSEM_SPIN_ON_OWNER
+/*
+ * return true if there is an active writer by checking the owner field which
+ * should be set (not RWSEM_READ_OWNED) if there is one.
+ */
+static inline bool rwsem_has_active_writer(struct rw_semaphore *sem)
+{
+ struct task_struct *owner = ACCESS_ONCE(sem->owner);
+
+ return owner && (owner != RWSEM_READ_OWNED);
+}
+
+/*
+ * Return true if the rwsem has active spinner
+ */
+static inline bool rwsem_has_spinner(struct rw_semaphore *sem)
+{
+ return osq_has_spinner(>osq);
+}
+#else /* CONFIG_RWSEM_SPIN_ON_OWNER */
+static inline bool rwsem_has_active_writer(struct rw_semaphore *sem)
+{
+ return false; /* Assume it has no active writer */
+}
+
+static inline bool rwsem_has_spinner(struct rw_semaphore *sem)
+{
+ return false;
+}
+#endif /* CONFIG_RWSEM_SPIN_ON_OWNER */
+
/*
* handle the lock release when processes blocked on it that can now run
* - if we come here from up_(), then:
@@ -125,6 +156,15 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
rwsem_wake_type wake_type)
struct list_head *next;
long oldcount, woken, loop, adjustment;
+ /*
+* Abort the wakeup operation if there is an active writer as the
+* lock was stolen. up_write() should have cleared the owner field
+* before calling this function. If that field is now set, there must
+* be an active writer present.
+*/
+ if (rwsem_has_active_writer(sem))
+ goto out;
+
waiter = list_entry(sem->wait_list.next, struct rwsem_waiter, list);
if (waiter->type == RWSEM_WAITING_FOR_WRITE) {
if (wake_type == RWSEM_WAKE_ANY)
@@ -479,7 +519,22 @@ struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
{
unsigned long flags;
- raw_spin_lock_irqsave(>wait_lock, flags);
+ /*
+* If a spinner is present, it is not necessary to do the wakeup.
+* Try to do wakeup when the trylock succeeds to avoid potential
+* spinlock contention which may introduce too much delay in the
+* unlock operation.
+*
+* In case the spinning writer is just going to break out of the loop,
+* it will still do a trylock in rwsem_down_write_failed() before
+* sleeping.
+*/
+ if (rwsem_has_spinner(sem)) {
+ if (!raw_spin_trylock_irqsave(>wait_lock, flags))
+ return sem;
+ } else {
+ raw_spin_lock_irqsave(>wait_lock, flags);
+ }
/* do nothing if list empty */
if (!list_empty(>wait_list))
--
1.7.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/
[PATCH 5/7] locking/rwsem: move down rwsem_down_read_failed function
Move the rwsem_down_read_failed() function down to below the optimistic
spinning section before enabling optimistic spinning for the readers.
There is no change in code.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 96 +-
1 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 576d4cd..86618ea 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -239,54 +239,6 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
rwsem_wake_type wake_type)
return sem;
}
-/*
- * Wait for the read lock to be granted
- */
-__visible
-struct rw_semaphore __sched *rwsem_down_read_failed(struct rw_semaphore *sem)
-{
- long count, adjustment = -RWSEM_ACTIVE_READ_BIAS;
- struct rwsem_waiter waiter;
- struct task_struct *tsk = current;
-
- /* set up my own style of waitqueue */
- waiter.task = tsk;
- waiter.type = RWSEM_WAITING_FOR_READ;
- get_task_struct(tsk);
-
- raw_spin_lock_irq(>wait_lock);
- if (list_empty(>wait_list))
- adjustment += RWSEM_WAITING_BIAS;
- list_add_tail(, >wait_list);
-
- /* we're now waiting on the lock, but no longer actively locking */
- count = rwsem_atomic_update(adjustment, sem);
-
- /* If there are no active locks, wake the front queued process(es).
-*
-* If there are no writers and we are first in the queue,
-* wake our own waiter to join the existing active readers !
-*/
- if (count == RWSEM_WAITING_BIAS ||
- (count > RWSEM_WAITING_BIAS &&
-adjustment != -RWSEM_ACTIVE_READ_BIAS))
- sem = __rwsem_do_wake(sem, RWSEM_WAKE_ANY);
-
- raw_spin_unlock_irq(>wait_lock);
-
- /* wait to be given the lock */
- while (true) {
- set_task_state(tsk, TASK_UNINTERRUPTIBLE);
- if (!waiter.task)
- break;
- schedule();
- }
-
- tsk->state = TASK_RUNNING;
-
- return sem;
-}
-
static inline bool rwsem_try_write_lock(long count, struct rw_semaphore *sem)
{
if (!(count & RWSEM_ACTIVE_MASK)) {
@@ -458,6 +410,54 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
#endif
/*
+ * Wait for the read lock to be granted
+ */
+__visible
+struct rw_semaphore __sched * rwsem_down_read_failed(struct rw_semaphore *sem)
+{
+ long count, adjustment = -RWSEM_ACTIVE_READ_BIAS;
+ struct rwsem_waiter waiter;
+ struct task_struct *tsk = current;
+
+ /* set up my own style of waitqueue */
+ waiter.task = tsk;
+ waiter.type = RWSEM_WAITING_FOR_READ;
+ get_task_struct(tsk);
+
+ raw_spin_lock_irq(>wait_lock);
+ if (list_empty(>wait_list))
+ adjustment += RWSEM_WAITING_BIAS;
+ list_add_tail(, >wait_list);
+
+ /* we're now waiting on the lock, but no longer actively locking */
+ count = rwsem_atomic_update(adjustment, sem);
+
+ /* If there are no active locks, wake the front queued process(es).
+*
+* If there are no writers and we are first in the queue,
+* wake our own waiter to join the existing active readers !
+*/
+ if (count == RWSEM_WAITING_BIAS ||
+ (count > RWSEM_WAITING_BIAS &&
+adjustment != -RWSEM_ACTIVE_READ_BIAS))
+ sem = __rwsem_do_wake(sem, RWSEM_WAKE_ANY);
+
+ raw_spin_unlock_irq(>wait_lock);
+
+ /* wait to be given the lock */
+ while (true) {
+ set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+ if (!waiter.task)
+ break;
+ schedule();
+ }
+
+ tsk->state = TASK_RUNNING;
+
+ return sem;
+}
+
+/*
* Wait until we successfully acquire the write lock
*/
__visible
--
1.7.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/
[PATCH 7/7] locking/rwsem: allow waiting writers to go back to optimistic spinning
More aggressive use of optimistic spinning and enabling readers to
participate in spinning may make tasks waiting in the queue harder
to get access to the semaphore, especially for writers who need
exclusive access.
This patch enables a waking writer to go back to the optimistic
spinning loop as long as the owner is running. This allows waiting
writers better access to the semaphore as well as reduce the size
of the waiting queue.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index aafc9f0..94b0124 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -484,6 +484,11 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem,
{
return false;
}
+
+static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
+{
+ return false;
+}
#endif
/*
@@ -553,12 +558,14 @@ __visible
struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
{
long count;
- bool waiting = true; /* any queued threads before us */
+ bool waiting; /* any queued threads before us */
+ bool respin;
struct rwsem_waiter waiter;
/* undo write bias from down_write operation, stop active locking */
count = rwsem_atomic_update(-RWSEM_ACTIVE_WRITE_BIAS, sem);
+optspin:
/* do optimistic spinning and steal lock if possible */
if (rwsem_optimistic_spin(sem, RWSEM_WAITING_FOR_WRITE))
return sem;
@@ -573,8 +580,7 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct
rw_semaphore *sem)
raw_spin_lock_irq(>wait_lock);
/* account for this before adding a new element to the list */
- if (list_empty(>wait_list))
- waiting = false;
+ waiting = !list_empty(>wait_list);
list_add_tail(, >wait_list);
@@ -595,23 +601,41 @@ struct rw_semaphore __sched
*rwsem_down_write_failed(struct rw_semaphore *sem)
/* wait until we successfully acquire the lock */
set_current_state(TASK_UNINTERRUPTIBLE);
- while (true) {
+ respin = false;
+ while (!respin) {
if (rwsem_try_write_lock(count, sem))
break;
raw_spin_unlock_irq(>wait_lock);
- /* Block until there are no active lockers. */
- do {
+ /*
+* Block until there are no active lockers or optimistic
+* spinning is possible.
+*/
+ while (true) {
schedule();
set_current_state(TASK_UNINTERRUPTIBLE);
- } while ((count = sem->count) & RWSEM_ACTIVE_MASK);
+ count = ACCESS_ONCE(sem->count);
+ if (!(count & RWSEM_ACTIVE_MASK))
+ break;
+ /*
+* Go back to optimistic spinning if possible
+*/
+ if (rwsem_can_spin_on_owner(sem)) {
+ respin = true;
+ break;
+ }
+ }
raw_spin_lock_irq(>wait_lock);
}
__set_current_state(TASK_RUNNING);
list_del();
+ if (respin && list_empty(>wait_list))
+ rwsem_atomic_update(-RWSEM_WAITING_BIAS, sem);
raw_spin_unlock_irq(>wait_lock);
+ if (respin)
+ goto optspin;
return sem;
}
--
1.7.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: [f2fs-dev] [PATCH] f2fs: reduce competition among node page writes
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, July 31, 2014 2:45 PM
> To: Chao Yu
> Cc: 'Changman Lee'; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: reduce competition among node page
> writes
>
> On Thu, Jul 31, 2014 at 01:31:46PM +0800, Chao Yu wrote:
> > Hi Changman,
> >
> > > -Original Message-
> > > From: Changman Lee [mailto:cm224@samsung.com]
> > > Sent: Thursday, July 31, 2014 10:07 AM
> > > To: Chao Yu
> > > Cc: 'Jaegeuk Kim'; linux-fsde...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Subject: Re: [f2fs-dev] [PATCH] f2fs: reduce competition among node page
> > > writes
> > >
> > > Hi Chao,
> > >
> > > On Wed, Jul 30, 2014 at 09:07:49PM +0800, Chao Yu wrote:
> > > > Hi Jaegeuk Changman,
> > > >
> > > > > -Original Message-
> > > > > From: Chao Yu [mailto:chao2...@samsung.com]
> > > > > Sent: Thursday, July 03, 2014 6:59 PM
> > > > > To: Jaegeuk Kim; Changman Lee
> > > > > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > linux-f2fs-de...@lists.sourceforge.net
> > > > > Subject: [f2fs-dev] [PATCH] f2fs: reduce competition among node page
> > > > > writes
> > > > >
> > > > > We do not need to block on ->node_write among different node page
> > > > > writers e.g.
> > > > > fsync/flush, unless we have a node page writer from write_checkpoint.
> > > > > So it's better use rw_semaphore instead of mutex type for
> > > > > ->node_write to
> > > > > promote performance.
> > > >
> > > > If you could have time to help explaining the problem of this patch, I
> > > > will be
> > > > appreciated for that.
> > >
> > > I have no clue. Except checkpoint, I don't know why need to block to
> > > write node page.
> > > Do you have any problem when you test with this patch?
> >
> > I don't have.
> > I send this patch about one month ago, but got no respond.
> > So I want to ask if any problem in this patch or forget to look at this
> > patch?
> >
> > To Jaegeuk:
> > Any idea about this patch?
>
> Oh, I forgot to send an email for this.
> At that time, when I looked at a glance, I thought that it was not clear why
> this should be merged.
>
> But, when I contemplate again, it seems that several fsync threads could
> produce
> multiple node writers, resulting in some mutex contention.
> Just for sure, can you verify that?
Yes, node sync in cp could encounter competition of the same op in
fsync/flush/gc
thread. Here we use rwlock to increase concurrent of these thread hence we could
gain better performance of checkpoint.
Thanks,
Yu
>
> Nevertheless, I think there would be no problem to merge this patch now.
> Merged.
>
> >
> > >
> > > >
> > > > Another question is what is ->writepages in sbi used for? I'm not quite
> > > > clear.
> > > >
> > >
> > > I remember it is for writing data pages per thread as much as possible.
> > > When multi-threads write some files simultaneously, multi-threads
> > > contended with
> > > each other to allocate a block. So block allocation was interleaved
> > > across threads. It makes fragmentation of file.
>
> Good. :)
>
> >
> > Thank you for the explanation! :)
> > I think what you say is reasonable.
> >
> > Previously I tested without this lock, although I found that the blocks
> > written
> > _almost_ were continuous in each '->writepages()'. Still I think we can
> > gain more
> > from readahead continuous block when using this lock, rather than remove it
> > for
> > promoting concurrent of writers.
> >
> > Thanks,
> > Yu
> >
> > >
> > > Thanks,
> > >
> > > > Thanks,
> > > >
> > > > >
> > > > > Signed-off-by: Chao Yu
> > > > > ---
> > > > > fs/f2fs/checkpoint.c |6 +++---
> > > > > fs/f2fs/f2fs.h |2 +-
> > > > > fs/f2fs/node.c |4 ++--
> > > > > fs/f2fs/super.c |2 +-
> > > > > 4 files changed, 7 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > > > > index 0b4710c..eec406b 100644
> > > > > --- a/fs/f2fs/checkpoint.c
> > > > > +++ b/fs/f2fs/checkpoint.c
> > > > > @@ -714,10 +714,10 @@ retry_flush_dents:
> > > > >* until finishing nat/sit flush.
> > > > >*/
> > > > > retry_flush_nodes:
> > > > > - mutex_lock(>node_write);
> > > > > + down_write(>node_write);
> > > > >
> > > > > if (get_pages(sbi, F2FS_DIRTY_NODES)) {
> > > > > - mutex_unlock(>node_write);
> > > > > + up_write(>node_write);
> > > > > sync_node_pages(sbi, 0, );
> > > > > goto retry_flush_nodes;
> > > > > }
> > > > > @@ -726,7 +726,7 @@ retry_flush_nodes:
> > > > >
> > > > > static void unblock_operations(struct f2fs_sb_info *sbi)
> > > > > {
> > > > > - mutex_unlock(>node_write);
> > > > > + up_write(>node_write);
> > > > >
[f2fs-dev][PATCH 2/2] f2fs: add f2fs_balance_fs for expand_inode_data
This patch adds f2fs_balance_fs in expand_inode_data to avoid allocation failure with segment. Signed-off-by: Chao Yu --- fs/f2fs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 9550135..5d3b779 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -671,6 +671,8 @@ static int expand_inode_data(struct inode *inode, loff_t offset, loff_t off_start, off_end; int ret = 0; + f2fs_balance_fs(sbi); + ret = inode_newsize_ok(inode, (len + offset)); if (ret) return ret; -- 2.0.0.421.g786a89d -- 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/
[f2fs-dev][PATCH 1/2] f2fs: use for_each_set_bit to simplify the code
This patch uses for_each_set_bit to simplify some codes in f2fs.
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 7 ++-
fs/f2fs/segment.c | 13 -
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b90dbe5..d7947d9 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -186,7 +186,6 @@ static unsigned int get_max_cost(struct f2fs_sb_info *sbi,
static unsigned int check_bg_victims(struct f2fs_sb_info *sbi)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
- unsigned int hint = 0;
unsigned int secno;
/*
@@ -194,11 +193,9 @@ static unsigned int check_bg_victims(struct f2fs_sb_info
*sbi)
* selected by background GC before.
* Those segments guarantee they have small valid blocks.
*/
-next:
- secno = find_next_bit(dirty_i->victim_secmap, TOTAL_SECS(sbi), hint++);
- if (secno < TOTAL_SECS(sbi)) {
+ for_each_set_bit(secno, dirty_i->victim_secmap, TOTAL_SECS(sbi)) {
if (sec_usage_check(sbi, secno))
- goto next;
+ continue;
clear_bit(secno, dirty_i->victim_secmap);
return secno * sbi->segs_per_sec;
}
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c3b76d0..0dfeeba 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -439,17 +439,12 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi,
static void set_prefree_as_free_segments(struct f2fs_sb_info *sbi)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
- unsigned int segno = -1;
+ unsigned int segno;
unsigned int total_segs = TOTAL_SEGS(sbi);
mutex_lock(_i->seglist_lock);
- while (1) {
- segno = find_next_bit(dirty_i->dirty_segmap[PRE], total_segs,
- segno + 1);
- if (segno >= total_segs)
- break;
+ for_each_set_bit(segno, dirty_i->dirty_segmap[PRE], total_segs)
__set_test_and_free(sbi, segno);
- }
mutex_unlock(_i->seglist_lock);
}
@@ -1531,7 +1526,7 @@ void flush_sit_entries(struct f2fs_sb_info *sbi)
struct page *page = NULL;
struct f2fs_sit_block *raw_sit = NULL;
unsigned int start = 0, end = 0;
- unsigned int segno = -1;
+ unsigned int segno;
bool flushed;
mutex_lock(>curseg_mutex);
@@ -1543,7 +1538,7 @@ void flush_sit_entries(struct f2fs_sb_info *sbi)
*/
flushed = flush_sits_in_journal(sbi);
- while ((segno = find_next_bit(bitmap, nsegs, segno + 1)) < nsegs) {
+ for_each_set_bit(segno, bitmap, nsegs) {
struct seg_entry *se = get_seg_entry(sbi, segno);
int sit_offset, offset;
--
2.0.0.421.g786a89d
--
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] KVM: nVMX: fix acknowledge interrupt on exit when APICv is in use
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
> On Behalf Of Wanpeng Li
> Sent: Friday, August 01, 2014 4:12 PM
> To: Paolo Bonzini; Jan Kiszka
> Cc: Marcelo Tosatti; Gleb Natapov; Bandan Das; Zhang, Yang Z;
> k...@vger.kernel.org; linux-kernel@vger.kernel.org; Wanpeng Li
> Subject: [PATCH 2/2] KVM: nVMX: fix acknowledge interrupt on exit when
> APICv is in use
>
> After commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info if
> L1 asks us to), "Acknowledge interrupt on exit" behavior can be emulated. To
> do so, KVM will ask the APIC for the interrupt vector if during a nested
> vmexit if VM_EXIT_ACK_INTR_ON_EXIT is set. With APICv,
> kvm_get_apic_interrupt would return -1 and give the following WARNING:
>
> Call Trace:
> [] dump_stack+0x49/0x5e []
> warn_slowpath_common+0x7c/0x96 [] ?
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel] []
> warn_slowpath_null+0x15/0x17 []
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] ?
> nested_vmx_exit_handled+0x6a/0x39e [kvm_intel] [] ?
> kvm_apic_has_interrupt+0x80/0xd5 [kvm] []
> vmx_check_nested_events+0xc3/0xd3 [kvm_intel] []
> inject_pending_event+0xd0/0x16e [kvm] []
> vcpu_enter_guest+0x319/0x704 [kvm]
>
> If enabling APIC-v, all interrupts to L1 are delivered through APIC-v.
> But when L2 is running, external interrupt will casue L1 vmexit with reason
> external interrupt. Then L1 will pick up the interrupt through vmcs12. when
> L1 ack the interrupt, since the APIC-v is enabled when
> L1 is running, so APIC-v hardware still will do vEOI updating. The problem is
> that the interrupt is delivered not through APIC-v hardware, this means
> SVI/RVI/vPPR are not setting, but hardware required them when doing vEOI
> updating. The solution is that, when L1 tried to pick up the interrupt from
> vmcs12, then hypervisor will help to update the SVI/RVI/vPPR to make sure
> the following vEOI updating and vPPR updating corrently.
>
> Also, since interrupt is delivered through vmcs12, so APIC-v hardware will not
> cleare vIRR and hypervisor need to clear it before L1 running.
>
> Suggested-by: Paolo Bonzini
> Suggested-by: "Zhang, Yang Z"
> Signed-off-by: Wanpeng Li
Tested-by: Liu, RongrongX
> ---
> arch/x86/kvm/lapic.c | 18 ++ arch/x86/kvm/lapic.h | 1
> +
> arch/x86/kvm/vmx.c | 10 ++
> 3 files changed, 29 insertions(+)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
> 3855103..06942b9 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -534,6 +534,24 @@ static void apic_set_tpr(struct kvm_lapic *apic, u32
> tpr)
> apic_update_ppr(apic);
> }
>
> +int kvm_lapic_ack_apicv(struct kvm_vcpu *vcpu) {
> + struct kvm_lapic *apic = vcpu->arch.apic;
> + int vec;
> +
> + vec = kvm_apic_has_interrupt(vcpu);
> +
> + if (vec == -1)
> + return vec;
> +
> + apic_set_vector(vec, apic->regs + APIC_ISR);
> + apic_update_ppr(apic);
> + apic_clear_vector(vec, apic->regs + APIC_IRR);
> +
> + return vec;
> +}
> +EXPORT_SYMBOL_GPL(kvm_lapic_ack_apicv);
> +
> int kvm_apic_match_physical_addr(struct kvm_lapic *apic, u16 dest) {
> return dest == 0xff || kvm_apic_id(apic) == dest; diff --git
> a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h index 6a11845..ead1392
> 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -169,5 +169,6 @@ static inline bool kvm_apic_has_events(struct
> kvm_vcpu *vcpu) }
>
> bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector);
> +int kvm_lapic_ack_apicv(struct kvm_vcpu *vcpu);
>
> #endif
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
> b8122b3..c604f3c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -8766,6 +8766,16 @@ static void nested_vmx_vmexit(struct kvm_vcpu
> *vcpu, u32 exit_reason,
> if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> && nested_exit_intr_ack_set(vcpu)) {
> int irq = kvm_cpu_get_interrupt(vcpu);
> +
> + if (irq < 0 && kvm_apic_vid_enabled(vcpu->kvm)) {
> + irq = kvm_lapic_ack_apicv(vcpu);
> + if (irq >= 0) {
> + vmx_hwapic_isr_update(vcpu->kvm, irq);
> + /* try to update RVI */
> + kvm_make_request(KVM_REQ_EVENT,
> vcpu);
> + }
> + }
> +
> WARN_ON(irq < 0);
> vmcs12->vm_exit_intr_info = irq |
> INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in the body of
> a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
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
RE: [PATCH 1/2] KVM: nVMX: Fix nested vmexit ack intr before load vmcs01
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
> On Behalf Of Wanpeng Li
> Sent: Friday, August 01, 2014 4:12 PM
> To: Paolo Bonzini; Jan Kiszka
> Cc: Marcelo Tosatti; Gleb Natapov; Bandan Das; Zhang, Yang Z;
> k...@vger.kernel.org; linux-kernel@vger.kernel.org; Wanpeng Li
> Subject: [PATCH 1/2] KVM: nVMX: Fix nested vmexit ack intr before load
> vmcs01
>
> External interrupt will cause L1 vmexit w/ reason external interrupt when L2
> is running. Then L1 will pick up the interrupt through vmcs12 if L1 set the
> ack
> interrupt bit. Commit 77b0f5d (KVM: nVMX: Ack and write vector info to
> intr_info if L1 asks us to) get intr that belongs to L1 before load vmcs01
> which
> is wrong, especially this lead to the obvious L1 ack APICv behavior weired
> since APICv is for L1 instead of L2. This patch fix it by ack intr after load
> vmcs01.
>
> Signed-off-by: Wanpeng Li
Tested-by: Liu, RongrongX
> ---
> arch/x86/kvm/vmx.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
> e618f34..b8122b3 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -8754,14 +8754,6 @@ static void nested_vmx_vmexit(struct kvm_vcpu
> *vcpu, u32 exit_reason,
> prepare_vmcs12(vcpu, vmcs12, exit_reason, exit_intr_info,
> exit_qualification);
>
> - if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> - && nested_exit_intr_ack_set(vcpu)) {
> - int irq = kvm_cpu_get_interrupt(vcpu);
> - WARN_ON(irq < 0);
> - vmcs12->vm_exit_intr_info = irq |
> - INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
> - }
> -
> trace_kvm_nested_vmexit_inject(vmcs12->vm_exit_reason,
> vmcs12->exit_qualification,
> vmcs12->idt_vectoring_info_field, @@ -
> 8771,6 +8763,14 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu,
> u32 exit_reason,
>
> vmx_load_vmcs01(vcpu);
>
> + if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> + && nested_exit_intr_ack_set(vcpu)) {
> + int irq = kvm_cpu_get_interrupt(vcpu);
> + WARN_ON(irq < 0);
> + vmcs12->vm_exit_intr_info = irq |
> + INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
> + }
> +
> vm_entry_controls_init(vmx, vmcs_read32(VM_ENTRY_CONTROLS));
> vm_exit_controls_init(vmx, vmcs_read32(VM_EXIT_CONTROLS));
> vmx_segment_cache_clear(vmx);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in the body of
> a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
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/
[f2fs-dev][PATCH 2/2 v2] f2fs: invalidate xattr node page when evict inode
When inode is evicted, all the page cache belong to this inode should be
released including the xattr node page. But previously we didn't do this, this
patch fixed this issue.
v2:
o reposition invalidate_mapping_pages() to the right place suggested by
Jaegeuk Kim.
Signed-off-by: Chao Yu
---
fs/f2fs/inode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 0e69aa9..2c3 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -267,6 +267,7 @@ int f2fs_write_inode(struct inode *inode, struct
writeback_control *wbc)
void f2fs_evict_inode(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
+ nid_t xnid = F2FS_I(inode)->i_xattr_nid;
trace_f2fs_evict_inode(inode);
truncate_inode_pages_final(>i_data);
@@ -296,6 +297,8 @@ void f2fs_evict_inode(struct inode *inode)
sb_end_intwrite(inode->i_sb);
no_delete:
invalidate_mapping_pages(NODE_MAPPING(sbi), inode->i_ino, inode->i_ino);
+ if (xnid)
+ invalidate_mapping_pages(NODE_MAPPING(sbi), xnid, xnid);
if (is_inode_flag_set(F2FS_I(inode), FI_APPEND_WRITE))
add_dirty_inode(sbi, inode->i_ino, APPEND_INO);
if (is_inode_flag_set(F2FS_I(inode), FI_UPDATE_WRITE))
--
2.0.1.474.g72c7794
--
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] minix zmap block counts calculation fix
Hello,
The original Linus' minix zmap blocks calculation was correct, in the
formula of: sbi->s_nzones - sbi->s_firstdatazone + 1. It is (sp->s_zones
- (sp->s_firstdatazone - 1) in the minix3 source code.
But a later patch (fs/minix: Verify bitmap block counts before mounting)
has changed it unfortunately as:
sbi->s_nzones - (sbi->s_firstdatazone + 1).
This would show free blocks one block less than the real when the total
data blocks are in "full zmap blocks plus one".
commit 016e8d44bc06dd3322f26712bdd3f3a6973592d0
Author: Josh Boyer
Date: Fri Aug 19 14:50:26 2011 -0400
This patch corrects that zmap blocks calculation and tidy a printk
message while at it.
Signed-off-by: Qi Yong
--
Qi Yong
diff --git a/fs/minix/bitmap.c b/fs/minix/bitmap.c
index 4bc50da..742942a 100644
--- a/fs/minix/bitmap.c
+++ b/fs/minix/bitmap.c
@@ -96,7 +96,7 @@ int minix_new_block(struct inode * inode)
unsigned long minix_count_free_blocks(struct super_block *sb)
{
struct minix_sb_info *sbi = minix_sb(sb);
- u32 bits = sbi->s_nzones - (sbi->s_firstdatazone + 1);
+ u32 bits = sbi->s_nzones - sbi->s_firstdatazone + 1;
return (count_free(sbi->s_zmap, sb->s_blocksize, bits)
<< sbi->s_log_zone_size);
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index f007a33..3f57af1 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -267,12 +267,12 @@ static int minix_fill_super(struct super_block *s, void
*data, int silent)
block = minix_blocks_needed(sbi->s_ninodes, s->s_blocksize);
if (sbi->s_imap_blocks < block) {
printk("MINIX-fs: file system does not have enough "
- "imap blocks allocated. Refusing to mount\n");
+ "imap blocks allocated. Refusing to mount.\n");
goto out_no_bitmap;
}
block = minix_blocks_needed(
- (sbi->s_nzones - (sbi->s_firstdatazone + 1)),
+ (sbi->s_nzones - sbi->s_firstdatazone + 1),
s->s_blocksize);
if (sbi->s_zmap_blocks < block) {
printk("MINIX-fs: file system does not have enough "
[PATCH] drivers/bluetooth/: Toshiba Qualcomm AR9565 (ath3k) bluetooth fix
From: Vincent Elger Zwanenburg
Date: Mon Aug 4 01:34:27 2014 +0100
Fixes bluetooth support on Toshiba C55-B-138 notebooks by 1) adding an ignore
line into btusb.c for its PID/VID combination and 2) assigning the VID/PID
combination in ath3k.c to load the BTUSB_ATH3012 driver.
Signed-off-by: Vincent Elger Zwanenburg
---
diff -uprN -X linux-3.16-rc7-vanilla/Documentation/dontdiff linux-3.16-rc7-
vanilla/drivers/bluetooth/ath3k.c /usr/src/linux-
mine/drivers/bluetooth/ath3k.c
--- linux-3.16-rc7-vanilla/drivers/bluetooth/ath3k.c2014-07-27
20:41:55.0 +0100
+++ /usr/src/linux-mine/drivers/bluetooth/ath3k.c 2014-08-03
04:24:37.449746557 +0100
@@ -75,6 +75,7 @@ static const struct usb_device_id ath3k_
/* Atheros AR3012 with sflash firmware*/
{ USB_DEVICE(0x0489, 0xe04d) },
{ USB_DEVICE(0x0489, 0xe04e) },
+ { USB_DEVICE(0x0930, 0x0227) },
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x0489, 0xe056) },
{ USB_DEVICE(0x0489, 0xe05f) },
@@ -123,6 +124,7 @@ static const struct usb_device_id ath3k_
/* Atheros AR3012 with sflash firmware*/
{ USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
diff -uprN -X linux-3.16-rc7-vanilla/Documentation/dontdiff linux-3.16-rc7-
vanilla/drivers/bluetooth/btusb.c /usr/src/linux-
mine/drivers/bluetooth/btusb.c
--- linux-3.16-rc7-vanilla/drivers/bluetooth/btusb.c2014-07-27
20:41:55.0 +0100
+++ /usr/src/linux-mine/drivers/bluetooth/btusb.c 2014-08-03
04:12:09.386738905 +0100
@@ -158,6 +158,7 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
--
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: [f2fs-dev][PATCH 2/2] f2fs: invalidate xattr node page when evict inode
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Saturday, August 02, 2014 10:42 PM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev][PATCH 2/2] f2fs: invalidate xattr node page when
> evict inode
>
> Hi Chao,
>
> On Thu, Jul 31, 2014 at 09:13:11PM +0800, Chao Yu wrote:
> > When inode is evicted, all the page cache belong to this inode should be
> > released including the xattr node page. But previously we didn't do this,
> > this
> > patch fixed this issue.
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/inode.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> > index 0e69aa9..8a5403b 100644
> > --- a/fs/f2fs/inode.c
> > +++ b/fs/f2fs/inode.c
> > @@ -267,10 +267,16 @@ int f2fs_write_inode(struct inode *inode, struct
> > writeback_control *wbc)
> > void f2fs_evict_inode(struct inode *inode)
> > {
> > struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> > + struct f2fs_inode_info *fi = F2FS_I(inode);
> >
> > trace_f2fs_evict_inode(inode);
> > +
> > truncate_inode_pages_final(>i_data);
> >
> > + if (fi->i_xattr_nid)
> > + invalidate_mapping_pages(NODE_MAPPING(sbi),
> > + fi->i_xattr_nid, fi->i_xattr_nid);
>
> It would be good to place this below with invalidate_mapping_paages(ino).
> Since, in the case of deletion, we need to get the xattr node page again
> on the remove_inode_page call path.
Yes, IMO, it will be OK now when using above implementation because we will
invalidate this xattr page in truncate_node(), but I'd like use your method
because it's better to guarantee invalidating xattr page by evict_inode itself.
I will send a v2 patch, and thanks for your suggestion.
Regards,
Yu
>
> Thanks,
>
> > +
> > if (inode->i_ino == F2FS_NODE_INO(sbi) ||
> > inode->i_ino == F2FS_META_INO(sbi))
> > goto out_clear;
> > --
> > 2.0.1.474.g72c7794
--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()
On 08/01/2014 05:55 AM, Paul E. McKenney wrote:
> + rcu_read_lock();
> + for_each_process_thread(g, t) {
> + if (t != current && ACCESS_ONCE(t->on_rq) &&
> + !is_idle_task(t)) {
> + get_task_struct(t);
> + t->rcu_tasks_nvcsw = ACCESS_ONCE(t->nvcsw);
> + ACCESS_ONCE(t->rcu_tasks_holdout) = 1;
> + list_add(>rcu_tasks_holdout_list,
> + _tasks_holdouts);
This loop will collect all the runnable tasks. It is too much tasks.
Is it possible to collect only on_cpu tasks or PREEMPT_ACTIVE tasks?
It seems hard to achieve it.
--
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 3/4] Staging: rts5208: Use dev_dbg and %*phspecifiertodump memory
On 08/02/2014 01:55 AM, Fabio Falzoi wrote: On Wed, Jul 30, 2014 at 09:52:35AM +0800, micky wrote: Documentation/printk-formats.txt Raw buffer as a hex string: %*ph00 01 02 ... 3f %*phC 00:01:02: ... :3f %*phD 00-01-02- ... -3f %*phN 000102 ... 3f For printing a small buffers (up to 64 bytes long) as a hex string with certain separator. For the larger buffers consider to use print_hex_dump(). Since we can't make sure the cnt value, it is not good use "%*ph", because it must make cnt <= 64. dw_len * 4 <= 64 ? Hi Micky, I think that in these two cases we can rely on print_hex_dump_bytes that doesn't have the dev_dbg limit on buffer size. Let me know what you think about it. If you agree, I can send a new version for patches 3/4 and 4/4, since the first two have already been merged in the linux-next tree by Greg. Hi Fabio, I think it is good, Thanks. Best Regards, micky Regards, Fabio . -- 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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()
On Mon, Aug 04, 2014 at 08:37:37AM +0800, Lai Jiangshan wrote:
> On 08/04/2014 06:05 AM, Paul E. McKenney wrote:
> > On Sun, Aug 03, 2014 at 03:33:18PM +0200, Oleg Nesterov wrote:
> >> On 08/02, Paul E. McKenney wrote:
> >>>
> >>> On Sat, Aug 02, 2014 at 04:56:16PM +0200, Oleg Nesterov wrote:
> On 07/31, Paul E. McKenney wrote:
> >
> > + rcu_read_lock();
> > + for_each_process_thread(g, t) {
> > + if (t != current && ACCESS_ONCE(t->on_rq) &&
> > + !is_idle_task(t)) {
>
> I didn't notice this check before, but it is not needed.
> for_each_process()
> can see the idle threads, there are not on process/thread lists.
> >> ^^^
> >>
> >> argh, I mean't "can't see" of course...
> >>
> >>> Good to know. Any other important tasks I am missing?
> >>
> >> Nothing else.
> >
> > Whew! ;-)
> >
> >>> I am guessing that I need to do something like this:
> >>>
> >>> for_each_process(g) {
> >>> /* Do build step. */
> >>> for_each_thread(g, t) {
> >>> if (g == t)
> >>> continue;
> >>> /* Do build step. */
> >>> }
> >>> }
> >>
> >> Sorry, I don't understand... This is equivalent to
> >>
> >>for_each_process_thread(g, t) {
> >>/* Do build step. */
> >>}
> >
> > OK, got it.
> >
> >>> Your point about exiting tasks I get, and I believe I can solve it.
> >>> I am hoping that the above sort of construction takes care of the
> >>> idle threads.
> >>
> >> It is simple to find the idle threads, just
> >>
> >>for_each_cpu(cpu) {
> >>do_something(cpu_rq(cpu)->idle);
> >>}
> >>
> >> but it is not clear to me what else you need to do with the idle threads.
> >> Probably not too much, they mostly run under preempt_disable().
> >
> > OK, looks easy enough. And yes, one good question is what, if anything,
> > we need to do with the idle threads.
> >
> >>> I might also need to do something to handle changes in
> >>> process/thread hierarchy -- but hopefully without having to read-acquire
> >>> the task-list lock.
> >>
> >> It seems that you need another global list, a task should be visible on
> >> that
> >> list until exit_rcu().
> >
> > As in create another global list that all tasks are added to when created
> > and then remved from when they exit?
>
> An alternative solution:
> srcu_read_lock() before exit_notify(), srcu_read_unlock() after the last
> preempt_disable()
> in the do_exit, and synchronize_srcu() in rcu_tasks_kthread().
That is a good way to synchronize with the exiting tasks, and I will
probably that that approach.
I -thought- that Oleg was concerned about safely building the list to
start with, though.
Thanx, Paul
--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()
On 08/04/2014 06:05 AM, Paul E. McKenney wrote:
> On Sun, Aug 03, 2014 at 03:33:18PM +0200, Oleg Nesterov wrote:
>> On 08/02, Paul E. McKenney wrote:
>>>
>>> On Sat, Aug 02, 2014 at 04:56:16PM +0200, Oleg Nesterov wrote:
On 07/31, Paul E. McKenney wrote:
>
> + rcu_read_lock();
> + for_each_process_thread(g, t) {
> + if (t != current && ACCESS_ONCE(t->on_rq) &&
> + !is_idle_task(t)) {
I didn't notice this check before, but it is not needed. for_each_process()
can see the idle threads, there are not on process/thread lists.
>> ^^^
>>
>> argh, I mean't "can't see" of course...
>>
>>> Good to know. Any other important tasks I am missing?
>>
>> Nothing else.
>
> Whew! ;-)
>
>>> I am guessing that I need to do something like this:
>>>
>>> for_each_process(g) {
>>> /* Do build step. */
>>> for_each_thread(g, t) {
>>> if (g == t)
>>> continue;
>>> /* Do build step. */
>>> }
>>> }
>>
>> Sorry, I don't understand... This is equivalent to
>>
>> for_each_process_thread(g, t) {
>> /* Do build step. */
>> }
>
> OK, got it.
>
>>> Your point about exiting tasks I get, and I believe I can solve it.
>>> I am hoping that the above sort of construction takes care of the
>>> idle threads.
>>
>> It is simple to find the idle threads, just
>>
>> for_each_cpu(cpu) {
>> do_something(cpu_rq(cpu)->idle);
>> }
>>
>> but it is not clear to me what else you need to do with the idle threads.
>> Probably not too much, they mostly run under preempt_disable().
>
> OK, looks easy enough. And yes, one good question is what, if anything,
> we need to do with the idle threads.
>
>>> I might also need to do something to handle changes in
>>> process/thread hierarchy -- but hopefully without having to read-acquire
>>> the task-list lock.
>>
>> It seems that you need another global list, a task should be visible on that
>> list until exit_rcu().
>
> As in create another global list that all tasks are added to when created
> and then remved from when they exit?
An alternative solution:
srcu_read_lock() before exit_notify(), srcu_read_unlock() after the last
preempt_disable()
in the do_exit, and synchronize_srcu() in rcu_tasks_kthread().
--
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/1] cris: fix %d confusingly prefixed with 0x in format string
On Sun, 2014-08-03 at 17:25 -0700, Hans Wennborg wrote:
> On 08/02/2014 11:10 PM, Joe Perches wrote:
> > On Sat, 2014-08-02 at 18:19 -0700, Hans Wennborg wrote:
> >> Yes, I have a patch for a bunch of these, but I figured it would be
> >> easier to get it merged if I split it up. (Complete kernel newbie here.)
> >
> > You as a kernel newbie did good, thanks.
> >
> > A small tip would be to do all of them in a single series
> > cc'ing each individual patch to the appropriate maintainers
> > and mailing lists.
>
> Thanks for the advice! I have split up and sent out the big patch as a
> series, with hopefully the right folks CC'd.
Another nice thing to do is to use git format-patch --cover-letter
so that you can use a [PATCH 0/n] introductory description too.
Other than that, nice job, thanks.
Perhaps now you can do the "0x%u" variants.
$ /usr/bin/git grep -P
'0x\%(?!ullx\b|ullX\b|llux\b|lux\b|ulx\b|ulX\b|lx\b|lluX\b|luX\b|lX\b)[ul]*[u]'
drivers/iommu/arm-smmu.c: "Unexpected context
fault (fsr 0x%u)\n",
drivers/net/vmxnet3/vmxnet3_drv.c: "txd[%u]:
0x%llu %u %u\n",
drivers/net/wireless/mwifiex/cfg80211.c:wiphy_dbg(wiphy, "info:
ongoing ROC, cookie = 0x%llu\n",
drivers/pinctrl/pinctrl-at91.c: dev_dbg(dev, "pio%c%d configured as
periph%c with conf = 0x%lu\n",
drivers/pinctrl/pinctrl-at91.c: dev_dbg(dev, "pio%c%d configured as
gpio with conf = 0x%lu\n",
drivers/scsi/cxgbi/libcxgbi.c: "csk 0x%p,%u,0x%lu,%u, seq %u, wup %u,
thre %u, %u.\n",
drivers/scsi/qla2xxx/qla_target.c: "dif check TGT cdb 0x%x lba 0x%llu:
[Actual|Expected] Ref Tag[0x%x|0x%x], App Tag [0x%x|0x%x], Guard [0x%x|0x%x]\n",
drivers/usb/musb/ux500_dma.c: "packet_sz=%d, mode=%d,
dma_addr=0x%llu, len=%d is_tx=%d\n",
fs/exofs/dir.c: "offset=%lu, inode=0x%llu, rec_len=%d, name_len=%d\n",
fs/xfs/xfs_discard.c:"discard failed for extent [0x%llu,%u], error %d",
sound/soc/atmel/atmel_ssc_dai.c:pr_debug("atmel_ssc_startup:
SSC_SR=0x%u\n",
There are some more with specific format lengths too:
arch/sparc/kernel/smp_32.c: printk(KERN_NOTICE "No MID found for
CPU%d at node 0x%08d", id, cpu_node);
drivers/mfd/rtsx_usb.c: dev_dbg(>dev, "%s called with pm message
0x%04u\n",
drivers/net/wireless/rtlwifi/rtl8192de/fw.c: "Polling FW ready
fail!! REG_MCUFWDL:0x%08ul\n",
drivers/tty/moxa.c: printk(KERN_INFO "MOXA isa board found
at 0x%.8lu and "
cheers, 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: [PATCH 1/1] cris: fix %d confusingly prefixed with 0x in format string
On 08/02/2014 11:10 PM, Joe Perches wrote: On Sat, 2014-08-02 at 18:19 -0700, Hans Wennborg wrote: Yes, I have a patch for a bunch of these, but I figured it would be easier to get it merged if I split it up. (Complete kernel newbie here.) You as a kernel newbie did good, thanks. A small tip would be to do all of them in a single series cc'ing each individual patch to the appropriate maintainers and mailing lists. Thanks for the advice! I have split up and sent out the big patch as a series, with hopefully the right folks CC'd. - Hans -- 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 19/19] alsa: riptide: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
sound/firewire/fireworks/fireworks_proc.c | 4 ++--
sound/pci/riptide/riptide.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/firewire/fireworks/fireworks_proc.c
b/sound/firewire/fireworks/fireworks_proc.c
index 02bf394..23bb274 100644
--- a/sound/firewire/fireworks/fireworks_proc.c
+++ b/sound/firewire/fireworks/fireworks_proc.c
@@ -64,7 +64,7 @@ proc_read_hwinfo(struct snd_info_entry *entry, struct
snd_info_buffer *buffer)
hwinfo->phys_in_grp_count);
for (i = 0; i < hwinfo->phys_in_grp_count; i++) {
snd_iprintf(buffer,
- "phys in grp[0x%d]: type 0x%d, count 0x%x\n",
+ "phys in grp[0x%x]: type 0x%x, count 0x%x\n",
i, hwinfo->phys_out_grps[i].type,
hwinfo->phys_out_grps[i].count);
}
@@ -73,7 +73,7 @@ proc_read_hwinfo(struct snd_info_entry *entry, struct
snd_info_buffer *buffer)
hwinfo->phys_out_grp_count);
for (i = 0; i < hwinfo->phys_out_grp_count; i++) {
snd_iprintf(buffer,
- "phys out grps[0x%d]: type 0x%d, count 0x%x\n",
+ "phys out grps[0x%x]: type 0x%x, count 0x%x\n",
i, hwinfo->phys_out_grps[i].type,
hwinfo->phys_out_grps[i].count);
}
diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c
index b4a8278..f0315c3 100644
--- a/sound/pci/riptide/riptide.c
+++ b/sound/pci/riptide/riptide.c
@@ -941,7 +941,7 @@ setmixer(struct cmdif *cif, short num, unsigned short rval,
unsigned short lval)
union cmdret rptr = CMDRET_ZERO;
int i = 0;
- snd_printdd("sent mixer %d: 0x%d 0x%d\n", num, rval, lval);
+ snd_printdd("sent mixer %d: 0x%x 0x%x\n", num, rval, lval);
do {
SEND_SDGV(cif, num, num, rval, lval);
SEND_RDGV(cif, num, num, );
@@ -1080,7 +1080,7 @@ getmixer(struct cmdif *cif, short num, unsigned short
*rval,
return -EIO;
*rval = rptr.retwords[0];
*lval = rptr.retwords[1];
- snd_printdd("got mixer %d: 0x%d 0x%d\n", num, *rval, *lval);
+ snd_printdd("got mixer %d: 0x%x 0x%x\n", num, *rval, *lval);
return 0;
}
--
2.0.0.526.g5318336
--
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 17/19] staging: rtl8821ae: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/staging/rtl8821ae/pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8821ae/pci.c b/drivers/staging/rtl8821ae/pci.c
index 26d7b2f..b818788 100644
--- a/drivers/staging/rtl8821ae/pci.c
+++ b/drivers/staging/rtl8821ae/pci.c
@@ -662,7 +662,7 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
prio)
RT_TRACE(COMP_ERR, DBG_LOUD,
("more desc left, wake"
"skb_queue@%d,ring->idx = %d,"
-"skb_queue_len = 0x%d\n",
+"skb_queue_len = 0x%x\n",
prio, ring->idx,
skb_queue_len(>queue)));
@@ -1650,7 +1650,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
if ((own == 1) && (hw_queue != BEACON_QUEUE)) {
RT_TRACE(COMP_ERR, DBG_WARNING,
("No more TX desc@%d, ring->idx = %d,"
- "idx = %d, skb_queue_len = 0x%d\n",
+ "idx = %d, skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue)));
@@ -1695,7 +1695,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
RT_TRACE(COMP_ERR, DBG_LOUD,
("less desc left, stop skb_queue@%d, "
"ring->idx = %d,"
- "idx = %d, skb_queue_len = 0x%d\n",
+ "idx = %d, skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue)));
--
2.0.0.526.g5318336
--
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 18/19] sound: fireworks: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
sound/firewire/fireworks/fireworks_proc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/firewire/fireworks/fireworks_proc.c
b/sound/firewire/fireworks/fireworks_proc.c
index f29d4aa..02bf394 100644
--- a/sound/firewire/fireworks/fireworks_proc.c
+++ b/sound/firewire/fireworks/fireworks_proc.c
@@ -64,7 +64,7 @@ proc_read_hwinfo(struct snd_info_entry *entry, struct
snd_info_buffer *buffer)
hwinfo->phys_in_grp_count);
for (i = 0; i < hwinfo->phys_in_grp_count; i++) {
snd_iprintf(buffer,
- "phys in grp[0x%d]: type 0x%d, count 0x%d\n",
+ "phys in grp[0x%d]: type 0x%d, count 0x%x\n",
i, hwinfo->phys_out_grps[i].type,
hwinfo->phys_out_grps[i].count);
}
@@ -73,7 +73,7 @@ proc_read_hwinfo(struct snd_info_entry *entry, struct
snd_info_buffer *buffer)
hwinfo->phys_out_grp_count);
for (i = 0; i < hwinfo->phys_out_grp_count; i++) {
snd_iprintf(buffer,
- "phys out grps[0x%d]: type 0x%d, count 0x%d\n",
+ "phys out grps[0x%d]: type 0x%d, count 0x%x\n",
i, hwinfo->phys_out_grps[i].type,
hwinfo->phys_out_grps[i].count);
}
--
2.0.0.526.g5318336
--
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 15/19] staging: nokia_h4p: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg
---
drivers/staging/nokia_h4p/nokia_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/nokia_h4p/nokia_core.c
b/drivers/staging/nokia_h4p/nokia_core.c
index 775e1d0..240da0c 100644
--- a/drivers/staging/nokia_h4p/nokia_core.c
+++ b/drivers/staging/nokia_h4p/nokia_core.c
@@ -1113,7 +1113,7 @@ static int hci_h4p_probe(struct platform_device *pdev)
GPIOF_OUT_INIT_LOW, "bt_wakeup");
if (err < 0) {
- dev_err(info->dev, "Cannot get GPIO line 0x%d",
+ dev_err(info->dev, "Cannot get GPIO line 0x%x",
info->bt_wakeup_gpio);
return err;
}
--
2.0.0.526.g5318336
--
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 16/19] staging: rtl8192ee: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/staging/rtl8192ee/pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192ee/pci.c b/drivers/staging/rtl8192ee/pci.c
index 0215aef..349e636 100644
--- a/drivers/staging/rtl8192ee/pci.c
+++ b/drivers/staging/rtl8192ee/pci.c
@@ -649,7 +649,7 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
prio)
if ((ring->entries - skb_queue_len(>queue)) == 2) {
RT_TRACE(COMP_ERR, DBG_LOUD,
-("more desc left, wake skb_queue@%d,ring->idx
= %d, skb_queue_len = 0x%d\n",
+("more desc left, wake skb_queue@%d,ring->idx
= %d, skb_queue_len = 0x%x\n",
prio, ring->idx,
skb_queue_len(>queue)));
@@ -1628,7 +1628,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
if ((own == 1) && (hw_queue != BEACON_QUEUE)) {
RT_TRACE(COMP_ERR, DBG_WARNING,
-("No more TX desc@%d, ring->idx = %d, idx =
%d, skb_queue_len = 0x%d\n",
+("No more TX desc@%d, ring->idx = %d, idx =
%d, skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue)));
@@ -1670,7 +1670,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
if ((ring->entries - skb_queue_len(>queue)) < 2 &&
hw_queue != BEACON_QUEUE) {
RT_TRACE(COMP_ERR, DBG_LOUD,
-("less desc left, stop skb_queue@%d, ring->idx = %d,
idx = %d, skb_queue_len = 0x%d\n",
+("less desc left, stop skb_queue@%d, ring->idx = %d,
idx = %d, skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue)));
--
2.0.0.526.g5318336
--
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 11/19] iwl4965: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg
---
drivers/net/wireless/iwlegacy/4965-mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c
b/drivers/net/wireless/iwlegacy/4965-mac.c
index c159c05..7d6fd59 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -4633,7 +4633,7 @@ il4965_store_tx_power(struct device *d, struct
device_attribute *attr,
else {
ret = il_set_tx_power(il, val, false);
if (ret)
- IL_ERR("failed setting tx power (0x%d).\n", ret);
+ IL_ERR("failed setting tx power (0x%x).\n", ret);
else
ret = count;
}
--
2.0.0.526.g5318336
--
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 13/19] drivers: parisc: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg
---
drivers/parisc/dino.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/parisc/dino.c b/drivers/parisc/dino.c
index 9eae983..a0580af 100644
--- a/drivers/parisc/dino.c
+++ b/drivers/parisc/dino.c
@@ -913,7 +913,7 @@ static int __init dino_probe(struct parisc_device *dev)
printk("%s version %s found at 0x%lx\n", name, version, hpa);
if (!request_mem_region(hpa, PAGE_SIZE, name)) {
- printk(KERN_ERR "DINO: Hey! Someone took my MMIO space
(0x%ld)!\n",
+ printk(KERN_ERR "DINO: Hey! Someone took my MMIO space
(0x%lx)!\n",
hpa);
return 1;
}
--
2.0.0.526.g5318336
--
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 12/19] rtlwifi: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/net/wireless/rtlwifi/pci.c | 6 +++---
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index 67d1ee6..74a8ba4 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -646,7 +646,7 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
prio)
== 2) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
-"more desc left, wake skb_queue@%d, ring->idx
= %d, skb_queue_len = 0x%d\n",
+"more desc left, wake skb_queue@%d, ring->idx
= %d, skb_queue_len = 0x%x\n",
prio, ring->idx,
skb_queue_len(>queue));
@@ -1469,7 +1469,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
if ((own == 1) && (hw_queue != BEACON_QUEUE)) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
-"No more TX desc@%d, ring->idx = %d, idx = %d,
skb_queue_len = 0x%d\n",
+"No more TX desc@%d, ring->idx = %d, idx = %d,
skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue));
@@ -1511,7 +1511,7 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
if ((ring->entries - skb_queue_len(>queue)) < 2 &&
hw_queue != BEACON_QUEUE) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
-"less desc left, stop skb_queue@%d, ring->idx = %d,
idx = %d, skb_queue_len = 0x%d\n",
+"less desc left, stop skb_queue@%d, ring->idx = %d,
idx = %d, skb_queue_len = 0x%x\n",
hw_queue, ring->idx, idx,
skb_queue_len(>queue));
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 592125a..7cfdfc9 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -677,7 +677,7 @@ static void _rtl92d_store_pwrindex_diffrate_offset(struct
ieee80211_hw *hw,
rtlphy->mcs_offset[rtlphy->pwrgroup_cnt][index] = data;
RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
-"MCSTxPowerLevelOriginalOffset[%d][%d] = 0x%ulx\n",
+"MCSTxPowerLevelOriginalOffset[%d][%d] = 0x%lx\n",
rtlphy->pwrgroup_cnt, index,
rtlphy->mcs_offset[rtlphy->pwrgroup_cnt][index]);
if (index == 13)
@@ -2531,7 +2531,7 @@ static void _rtl92d_phy_reload_lck_setting(struct
ieee80211_hw *hw,
if (rtlpriv->rtlhal.current_bandtype == BAND_ON_5G) {/* Path-A for 5G */
u4tmp = curveindex_5g[channel-1];
RTPRINT(rtlpriv, FINIT, INIT_IQK,
- "ver 1 set RF-A, 5G,0x28 = 0x%ulx !!\n", u4tmp);
+ "ver 1 set RF-A, 5G,0x28 = 0x%lx !!\n", u4tmp);
if (rtlpriv->rtlhal.macphymode == DUALMAC_DUALPHY &&
rtlpriv->rtlhal.interfaceindex == 1) {
bneed_powerdown_radio =
@@ -2550,7 +2550,7 @@ static void _rtl92d_phy_reload_lck_setting(struct
ieee80211_hw *hw,
} else if (rtlpriv->rtlhal.current_bandtype == BAND_ON_2_4G) {
u4tmp = curveindex_2g[channel-1];
RTPRINT(rtlpriv, FINIT, INIT_IQK,
- "ver 3 set RF-B, 2G, 0x28 = 0x%ulx !!\n", u4tmp);
+ "ver 3 set RF-B, 2G, 0x28 = 0x%lx !!\n", u4tmp);
if (rtlpriv->rtlhal.macphymode == DUALMAC_DUALPHY &&
rtlpriv->rtlhal.interfaceindex == 0) {
bneed_powerdown_radio =
@@ -2562,7 +2562,7 @@ static void _rtl92d_phy_reload_lck_setting(struct
ieee80211_hw *hw,
}
rtl_set_rfreg(hw, erfpath, RF_SYN_G4, 0x3f800, u4tmp);
RTPRINT(rtlpriv, FINIT, INIT_IQK,
- "ver 3 set RF-B, 2G, 0x28 = 0x%ulx !!\n",
+ "ver 3 set RF-B, 2G, 0x28 = 0x%lx !!\n",
rtl_get_rfreg(hw, erfpath, RF_SYN_G4, 0x3f800));
if (bneed_powerdown_radio)
_rtl92d_phy_restore_rf_env(hw, erfpath, );
--
2.0.0.526.g5318336
--
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 09/19] net: smc911x: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/net/ethernet/smsc/smc911x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c index 1c44e67..9778cba 100644 --- a/drivers/net/ethernet/smsc/smc911x.c +++ b/drivers/net/ethernet/smsc/smc911x.c @@ -730,7 +730,7 @@ static void smc911x_phy_detect(struct net_device *dev) lp->phy_type = id1 << 16 | id2; } - DBG(SMC_DEBUG_MISC, dev, "phy_id1=0x%x, phy_id2=0x%x phyaddr=0x%d\n", + DBG(SMC_DEBUG_MISC, dev, "phy_id1=0x%x, phy_id2=0x%x phyaddr=0x%x\n", id1, id2, lp->mii.phy_id); } -- 2.0.0.526.g5318336 -- 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 14/19] hpsa: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/scsi/hpsa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 6b35d0d..47358b5 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -6088,7 +6088,7 @@ static void print_cfg_table(struct device *dev, struct CfgTable *tb) readl(&(tb->HostWrite.CoalIntDelay))); dev_info(dev, " Coalesce Interrupt Count = 0x%x\n", readl(&(tb->HostWrite.CoalIntCount))); - dev_info(dev, " Max outstanding commands = 0x%d\n", + dev_info(dev, " Max outstanding commands = 0x%x\n", readl(&(tb->CmdsOutMax))); dev_info(dev, " Bus Types = 0x%x\n", readl(&(tb->BusTypes))); for (i = 0; i < 16; i++) -- 2.0.0.526.g5318336 -- 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 10/19] ath6kl: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/net/wireless/ath/ath6kl/init.c | 2 +-
drivers/net/wireless/ath/ath6kl/main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c
b/drivers/net/wireless/ath/ath6kl/init.c
index fffd523..91af845 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1049,7 +1049,7 @@ static int ath6kl_fetch_fw_apin(struct ath6kl *ar, const
char *name)
ar->hw.reserved_ram_size = le32_to_cpup(val);
ath6kl_dbg(ATH6KL_DBG_BOOT,
- "found reserved ram size ie 0x%d\n",
+ "found reserved ram size ie 0x%x\n",
ar->hw.reserved_ram_size);
break;
case ATH6KL_FW_IE_CAPABILITIES:
diff --git a/drivers/net/wireless/ath/ath6kl/main.c
b/drivers/net/wireless/ath/ath6kl/main.c
index 21516bc..933aef0 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -225,7 +225,7 @@ int ath6kl_diag_write32(struct ath6kl *ar, u32 address,
__le32 value)
ret = ath6kl_hif_diag_write32(ar, address, value);
if (ret) {
- ath6kl_err("failed to write 0x%x during diagnose window to
0x%d\n",
+ ath6kl_err("failed to write 0x%x during diagnose window to
0x%x\n",
address, value);
return ret;
}
--
2.0.0.526.g5318336
--
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 07/19] mfd: omap-usb-host: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/mfd/omap-usb-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 33a9234..83dab2f 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -647,7 +647,7 @@ static int usbhs_omap_probe(struct platform_device *pdev) default: omap->nports = OMAP3_HS_USB_PORTS; dev_dbg(dev, -"USB HOST Rev:0x%d not recognized, assuming %d ports\n", +"USB HOST Rev:0x%x not recognized, assuming %d ports\n", omap->usbhs_rev, omap->nports); break; } -- 2.0.0.526.g5318336 -- 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 08/19] gru: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/misc/sgi-gru/grumain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/sgi-gru/grumain.c b/drivers/misc/sgi-gru/grumain.c index ae16c8c..a1ce324 100644 --- a/drivers/misc/sgi-gru/grumain.c +++ b/drivers/misc/sgi-gru/grumain.c @@ -283,7 +283,7 @@ static void gru_unload_mm_tracker(struct gru_state *gru, spin_lock(>gs_asid_lock); BUG_ON((asids->mt_ctxbitmap & ctxbitmap) != ctxbitmap); asids->mt_ctxbitmap ^= ctxbitmap; - gru_dbg(grudev, "gid %d, gts %p, gms %p, ctxnum 0x%d, asidmap 0x%lx\n", + gru_dbg(grudev, "gid %d, gts %p, gms %p, ctxnum 0x%x, asidmap 0x%lx\n", gru->gs_gid, gts, gms, gts->ts_ctxnum, gms->ms_asidmap[0]); spin_unlock(>gs_asid_lock); spin_unlock(>ms_asid_lock); -- 2.0.0.526.g5318336 -- 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 05/19] media: s5p-mfs: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c index c1c12f8..e9175ab 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c @@ -525,7 +525,7 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct s5p_mfc_ctx *ctx, WRITEL(addr, mfc_regs->e_stream_buffer_addr); /* 16B align */ WRITEL(size, mfc_regs->e_stream_buffer_size); - mfc_debug(2, "stream buf addr: 0x%08lx, size: 0x%d\n", + mfc_debug(2, "stream buf addr: 0x%08lx, size: 0x%x\n", addr, size); return 0; -- 2.0.0.526.g5318336 -- 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 06/19] mfd: htc-i2cpld: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg --- drivers/mfd/htc-i2cpld.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/htc-i2cpld.c b/drivers/mfd/htc-i2cpld.c index b44f020..6bdb78c 100644 --- a/drivers/mfd/htc-i2cpld.c +++ b/drivers/mfd/htc-i2cpld.c @@ -404,7 +404,7 @@ static int htcpld_register_chip_i2c( } i2c_set_clientdata(client, chip); - snprintf(client->name, I2C_NAME_SIZE, "Chip_0x%d", client->addr); + snprintf(client->name, I2C_NAME_SIZE, "Chip_0x%x", client->addr); chip->client = client; /* Reset the chip */ -- 2.0.0.526.g5318336 -- 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 04/19] drivers: cciss: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg --- drivers/block/cciss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index ff20f19..99f778d 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -3838,7 +3838,7 @@ static void print_cfg_table(ctlr_info_t *h) readl(&(tb->HostWrite.CoalIntDelay))); dev_dbg(>pdev->dev, " Coalesce Interrupt Count = 0x%x\n", readl(&(tb->HostWrite.CoalIntCount))); - dev_dbg(>pdev->dev, " Max outstanding commands = 0x%d\n", + dev_dbg(>pdev->dev, " Max outstanding commands = 0x%x\n", readl(&(tb->CmdsOutMax))); dev_dbg(>pdev->dev, " Bus Types = 0x%x\n", readl(&(tb->BusTypes))); -- 2.0.0.526.g5318336 -- 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 03/19] drivers: DAC960 fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/block/DAC960.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index 811e11c..d9b32f2 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -2954,7 +2954,7 @@ DAC960_DetectController(struct pci_dev *PCI_Device,
case DAC960_PD_Controller:
if (!request_region(Controller->IO_Address, 0x80,
Controller->FullModelName)) {
- DAC960_Error("IO port 0x%d busy for Controller at\n",
+ DAC960_Error("IO port 0x%x busy for Controller at\n",
Controller, Controller->IO_Address);
goto Failure;
}
@@ -2990,7 +2990,7 @@ DAC960_DetectController(struct pci_dev *PCI_Device,
case DAC960_P_Controller:
if (!request_region(Controller->IO_Address, 0x80,
Controller->FullModelName)){
- DAC960_Error("IO port 0x%d busy for Controller at\n",
+ DAC960_Error("IO port 0x%x busy for Controller at\n",
Controller, Controller->IO_Address);
goto Failure;
}
--
2.0.0.526.g5318336
--
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 02/19] drivers: atm: fix %d confusingly prefixed with 0x in format strings
Signed-off-by: Hans Wennborg
---
drivers/atm/eni.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index b1955ba..d65975a 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -2155,7 +2155,7 @@ static int eni_proc_read(struct atm_dev *dev,loff_t
*pos,char *page)
if (!tx->send) continue;
if (!--left) {
- return sprintf(page,"tx[%d]:0x%ld-0x%ld "
+ return sprintf(page, "tx[%d]:0x%lx-0x%lx "
"(%6ld bytes), rsv %d cps, shp %d cps%s\n",i,
(unsigned long) (tx->send - eni_dev->ram),
tx->send-eni_dev->ram+tx->words*4-1,tx->words*4,
@@ -2181,7 +2181,7 @@ static int eni_proc_read(struct atm_dev *dev,loff_t
*pos,char *page)
if (--left) continue;
length = sprintf(page,"vcc %4d: ",vcc->vci);
if (eni_vcc->rx) {
- length += sprintf(page+length,"0x%ld-0x%ld "
+ length += sprintf(page+length, "0x%lx-0x%lx "
"(%6ld bytes)",
(unsigned long) (eni_vcc->recv -
eni_dev->ram),
eni_vcc->recv-eni_dev->ram+eni_vcc->words*4-1,
--
2.0.0.526.g5318336
--
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 01/19] ARM: OMAP: fix %d confusingly prefixed with 0x in format string
Signed-off-by: Hans Wennborg
---
arch/arm/mach-omap2/id.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d42022f..53841de 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -663,7 +663,7 @@ void __init dra7xxx_check_revision(void)
default:
/* Unknown default to latest silicon rev as default*/
- pr_warn("%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%d)\n",
+ pr_warn("%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%x)\n",
__func__, idcode, hawkeye, rev);
omap_revision = DRA752_REV_ES1_1;
}
--
2.0.0.526.g5318336
--
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 3.8 107/116] hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry
On Wed, 2014-07-23 at 17:07 -0700, Hugh Dickins wrote: > On Wed, 23 Jul 2014, Kamal Mostafa wrote: > > On Tue, 2014-07-22 at 16:08 -0700, Hugh Dickins wrote: > > > On Tue, 22 Jul 2014, Kamal Mostafa wrote: > > > > > > > 3.8.13.27 -stable review patch. If anyone has any objections, please > > > > let me know. > > > > > > > > -- > > > > > > > > From: Naoya Horiguchi > > > > > > > > commit 4a705fef986231a3e7a6b1a6d3c37025f021f49f upstream. > > > > > > > > There's a race between fork() and hugepage migration, as a result we try > > > > [...] > > > > > > Please drop this one for now: other -stables have carried it, but it > > > was found last week to contain a bug of its own, arguably worse than > > > what it's fixing. Naoya-san has done the fix for that, it's in mmotm > > > and should make its way to Linus probably this week: so please hold > > > this back until that can join it - thanks. > > > > > > Hugh > > > > OK, I've dropped it from the 3.8-stable queue, and will watch for the > > fix to land. Thanks very much, Hugh! > > commit 0253d634e0803a8376a0d88efee0bf523d8673f9 > Author: Naoya Horiguchi > Date: Wed Jul 23 14:00:19 2014 -0700 > mm: hugetlb: fix copy_hugetlb_page_range() > > is now in Linus's tree: so the original patch is good to go into > your -stables, so long as you add 0253d634e080 on top. I've now queued up "mm: hugetlb: fix copy_hugetlb_page_range()" for 3.2. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Re: Linux 3.4.95 breaks LZO tests (additional pull needed)
On Thu, 2014-07-17 at 20:57 -0700, Derrick Pallas wrote: > An LZO update was backported in Linux 3.4.95 but fails to work if > crypto tests are enabled. It turns out that > 0ec7382036922be063b515b2a3f1d6 > f7a607392c, which updates the test vectors, did not come along for the > ride. Thanks, ~Derrick As this is also true of 3.2.61, I've queued it up for the next update to 3.2. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Linux 3.16
So nothing particularly exciting happened this week, and 3.16 is out there. And as usual (previous release being the exception) that means that the merge window for 3.17 is obviously open. And for the third time in a row, the timing sucks for me, as I have travel coming up the second week of the merge window. Many other core developers will be traveling too, since it's just before the kernel summit in Chicago. So we'll see how the next merge window goes, but I'm not going to worry about it overmuch. If I end up not having time to do all the merges, I might delay things into the week of the kernel summit, but I'll hope to get most of the big merging done this upcoming week before any travel takes place, so maybe it won't come to that. So this is just a heads-up that the merge window *might* be extended. Anyway, back to the changes since -rc7: it's really fairly small stuff randomly all over, with a third being architecture updates, a third drivers, and a third "misc" (mainly mm and networking). The architecture stuff is small ARM updates (mostly DT), some x86 Xen fixups, some random small powerpc things. The shortlog gives a good idea of what kind of stuff it all is, but it's really just 83 commits (plus merges and the release commit) and about a third of them are marked for stable. So while 3.16 looked a bit iffy for a while, things cleared up nicely, and there was no reason to do extra release candidates like I feared just a couple of weeks ago. Linus --- Alexandre Bounine (1): rapidio/tsi721_dma: fix failure to obtain transaction descriptor Alexey Khoroshilov (1): isdn/bas_gigaset: fix a leak on failure path in gigaset_probe() Andreas Färber (1): MAINTAINERS: Update Tegra Git URL Andrey Ryabinin (2): net: sendmsg: fix NULL pointer dereference mm: debugfs: move rounddown_pow_of_two() out from do_fault path Andy Lutomirski (1): x86_64/entry/xen: Do not invoke espfix64 on Xen Anssi Hannula (1): dm cache: fix race affecting dirty block count Atsushi Kumagai (1): kexec: export free_huge_page to VMCOREINFO Christoph Fritz (1): ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable() Christoph Hellwig (1): direct-io: fix AIO regression Daniel Borkmann (1): net: sctp: inherit auth_capable on INIT collisions David Howells (1): AFS: Correctly assemble the client UUID David L Stevens (1): sunvnet: only use connected ports when sending David Rientjes (2): mm, thp: do not allow thp faults to avoid cpuset restrictions kexec: fix build error when hugetlbfs is disabled David Vrabel (1): x86/xen: safely map and unmap grant frames when in atomic context Dmitry Kravkov (1): bnx2x: fix crash during TSO tunneling Eliad Peller (2): cfg80211: fix mic_failure tracing iwlwifi: mvm: pass beacons from foreign APs Emmanuel Grumbach (1): iwlwifi: mvm: fix merge damage Eric Biggers (1): vfs: fix check for fallocate on active swapfile Eric Dumazet (1): ip: make IP identifiers less predictable Ezequiel Garcia (2): net: phy: Set the driver when registering an MDIO bus device net: phy: Ensure the MDIO bus module is held Felix Fietkau (2): mac80211: fix crash on getting sta info with uninitialized rate control ath9k: fix aggregation session lockup Florian Fainelli (2): net: bcmgenet: correctly pad short packets net: phy: re-apply PHY fixups during phy_register_device George Cherian (1): can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource() Greg Thelen (1): dm bufio: fully initialize shrinker Haojian Zhuang (1): ARM: dts: fix L2 address in Hi3620 James Bottomley (1): scsi: handle flush errors properly Jan Kara (1): timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks Jes Sorensen (1): staging: rtl8723au: rtw_resume(): release semaphore before exit on error Johannes Berg (1): Revert "mac80211: move "bufferable MMPDU" check to fix AP mode scan" Josh Triplett (1): Josh has moved Julian Anastasov (1): ipvs: avoid netns exit crash on ip_vs_conn_drop_conntrack Jun Zhao (1): neighbour : fix ndm_type type error issue Konstantin Khlebnikov (1): ARM: 8115/1: LPAE: reduce damage caused by idmap to virtual memory layout Lars-Peter Clausen (1): iio: buffer: Fix demux table creation Laura Abbott (3): of: Split early_init_dt_scan into two parts of: Add memory limiting function for flattened devicetrees arm: Add devicetree fixup machine function Linus Torvalds (2): Revert "cdc_subset: deal with a device that needs reset for timeout" Linux 3.16 Linus Walleij (1): ARM: nomadik: fix up double inversion in DT Malcolm Priestley (2): staging: vt6655: Fix Warning on boot handle_irq_event_percpu. staging: vt6655: Fix disassociated messages every 10 seconds Maxim Patlasov (1):
