Re: [PATCH v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
On pon, 2014-11-03 at 15:44 +, Russell King - ARM Linux wrote: > On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote: > > Bear in mind, however, that once the irq_safe flag has been set, the > > runtime PM core offers no way to turn it off again. > > Ah, I thought it did permit it to change both ways. In that case, we > don't need to validate that it doesn't change state on each call, and > we can just get away with checking its value. It cannot be unset but still it could be *set* during runtime (not only in probe). However that shouldn't happen between suspend-resume calls, so the solution of undoing suspend's work seems fine. I'll send a new patch doing this way. Without the wrapper. Best regards, Krzysztof -- 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] io: accel: kxcjk-1013: Fix iio_event_spec direction
On 18/10/14 12:57, Jonathan Cameron wrote:
> On 10/10/14 15:53, Daniel Baluta wrote:
>> Because IIO_EV_DIR_* are not bitmasks but enums,
>> IIO_EV_DIR_RISING | IIO_EV_DIR_FALLING is not equal
>> with IIO_EV_DIR_EITHER.
>>
>> This could lead to potential misformatted sysfs attributes
>> like:
>> * in_accel_x_thresh_(null)_en
>> * in_accel_x_thresh_(null)_period
>> * in_accel_x_thresh_(null)_value
>>
>> or even memory corruption.
>>
>> Fixes: b4b491c083 (iio: accel: kxcjk-1013: Support threshold)
>> Signed-off-by: Daniel Baluta
>
> Good catch. I'll have to hold this for a little until Greg takes
> my last pull request and I can bring the fixes branch up past the
> merge window.
Applied to the fixes-togreg branch of iio.git
Sorry for the delay,
Jonathan
>
>
>> ---
>> drivers/iio/accel/kxcjk-1013.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
>> index 98909a9..a23e58c 100644
>> --- a/drivers/iio/accel/kxcjk-1013.c
>> +++ b/drivers/iio/accel/kxcjk-1013.c
>> @@ -894,7 +894,7 @@ static const struct attribute_group
>> kxcjk1013_attrs_group = {
>>
>> static const struct iio_event_spec kxcjk1013_event = {
>> .type = IIO_EV_TYPE_THRESH,
>> -.dir = IIO_EV_DIR_RISING | IIO_EV_DIR_FALLING,
>> +.dir = IIO_EV_DIR_EITHER,
>> .mask_separate = BIT(IIO_EV_INFO_VALUE) |
>> BIT(IIO_EV_INFO_ENABLE) |
>> BIT(IIO_EV_INFO_PERIOD)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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/
IPC via PCIe
Hi, has anyone ever done IPC between two Nodes in a System via PICe? I know that I must set one of my nodes to PCIe endpoint mode (the PPC's PCIe controller is capable of doing this so no problem), but how will the communication be done? For AMP settings I've found the remoteproc and rpmsg frameworks and there is rionet for RapidIO, but no example of PCIe communication. Thanks, Johannes -- 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/5] clk: rockchip: change DCLK_VOP0 to use new COMPOSITE_DIVOPS
The HDMI clock is actually provide by DCLK_VOP0, so we need this
patch to handle the HDMI clock correctly
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk-rk3288.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 0151140..073a719 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -396,8 +396,10 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKSEL_CON(30), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 4, GFLAGS),
- COMPOSITE(DCLK_VOP0, "dclk_vop0", mux_pll_src_cpll_gpll_npll_p, 0,
+ COMPOSITE_DIVOPS(DCLK_VOP0, "dclk_vop0", mux_pll_src_cpll_gpll_npll_p,
+ (CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT),
RK3288_CLKSEL_CON(27), 0, 2, MFLAGS, 8, 8, DFLAGS,
+ _vop_ops,
RK3288_CLKGATE_CON(3), 1, GFLAGS),
COMPOSITE(DCLK_VOP1, "dclk_vop1", mux_pll_src_cpll_gpll_npll_p, 0,
RK3288_CLKSEL_CON(29), 6, 2, MFLAGS, 8, 8, DFLAGS,
--
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/
[PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288
we are going to make a clock usage solution for rk3288: 1. CPLL and GPLL always not change after assign init; 2. NPLL default as 500MHz, may used for most scene; 3. NPLL may be changed by VOP(HDMI) clock for some special frequency requirement. I test it with rk3288 evb on top of Heiko's clk-for-next Kever Yang (5): clk: rockchip: add some clock rate into rate table for rk3288 clk: divider: make clk_divider_recalc/set_rate available clk: rockchip: introduce the div_ops handling for composite branches clk: rockchip: add the vop_determine_rate for vop dclock clk: rockchip: change DCLK_VOP0 to use new COMPOSITE_DIVOPS drivers/clk/clk-divider.c | 4 +-- drivers/clk/rockchip/clk-rk3288.c | 76 ++- drivers/clk/rockchip/clk.c| 13 --- drivers/clk/rockchip/clk.h| 24 + include/linux/clk-provider.h | 4 +++ 5 files changed, 114 insertions(+), 7 deletions(-) -- 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/
[PATCH 2/5] clk: divider: make clk_divider_recalc/set_rate available
This patch makes these two function available for other file,
which may help to make costom usage of clock divider type.
Signed-off-by: Kever Yang
---
drivers/clk/clk-divider.c| 4 ++--
include/linux/clk-provider.h | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 18a9de2..f3f55a8 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -109,7 +109,7 @@ static unsigned int _get_val(struct clk_divider *divider,
unsigned int div)
return div - 1;
}
-static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
struct clk_divider *divider = to_clk_divider(hw);
@@ -318,7 +318,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
return DIV_ROUND_UP(*prate, div);
}
-static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
+int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct clk_divider *divider = to_clk_divider(hw);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index be21af1..7947fe9 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -555,6 +555,10 @@ struct clk *__clk_lookup(const char *name);
long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
struct clk **best_parent_p);
+unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate);
+int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate);
/*
* FIXME clock api without lock protection
--
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/
[PATCH 4/5] clk: rockchip: add the vop_determine_rate for vop dclock
Rk3288 has 5 PLLs(APLL, DPLL, CPLL, GPLL, NPLL),
APLL is for CPU clock only and DPLL is for DRAM clock only,
and other 3 PLls used for all other peripherals.
We have to make a total solution for how to campatible all
kinds of clock requirement by on chip peripheral controllers.
Some controllers like I2S and HDMI need accurate frequency while
others controllers accept clock rate with margin.
According to our experience on rk3288, we prefer to use CPLL and GPLL fixed
at 400MHz and 594MHz for general use for most peripheral.
The fraction divider should be enough for I2S controller.
The HDMI is the most diffical one if we have to support all the
resolution requirement for frequency. Most people use 720p and
1080 i/p resolution with 74.25MHz/148.5MHz, which can get clock
rate from 594MHz(maybe from GPLL). some other resolution like
640*480 will use 25.175MHz, which is hard to get from general
used PLLs.
So it is better to make HDMI controller has the right to change
the PLL frequency and get the clock rate it wants.
We set NPLL to 500MHz as default, if HDMI can get what it need
from existent clock provider, then change its divider and switch
to that parent; if not, we have to change the NPLL's output
and always make CPLL not change.
This patch add vop_determinate_rate as a div_ops to handle
the HDMI clock things.
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk-rk3288.c | 69 +++
1 file changed, 69 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 48412e9..0151140 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
enum rk3288_plls {
apll, dpll, cpll, gpll, npll,
};
+const struct clk_ops dclk_vop_ops;
struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE(220800, 1, 92, 1),
@@ -766,6 +768,73 @@ static const char *rk3288_critical_clocks[] __initconst = {
"aclk_peri",
"hclk_peri",
};
+#define DCLK_VOP_PARENT_NPLL 2
+
+long dclk_vop_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate,
+ struct clk **best_parent_p)
+{
+ struct clk *clk = hw->clk, *parent;
+ unsigned long parent_rate, best = 0;
+ int num_parents = clk->num_parents;
+ int i;
+
+ /*
+* check if one of the generic plls can provide a cleanly dividable
+* rate without changing them.
+*/
+ for (i = 0; i < (num_parents - 1); i++) {
+ parent = clk_get_parent_by_index(clk, i);
+ parent_rate = __clk_get_rate(parent);
+ if (parent_rate % rate == 0) {
+ *best_parent_p = parent;
+ *best_parent_rate = parent_rate;
+ return rate;
+ }
+ }
+
+ /* take the npll and set its rate to something suitable */
+ for (i = 0; rk3288_pll_rates[i].rate != 0; i++) {
+ if (rk3288_pll_rates[i].rate % rate == 0) {
+ *best_parent_p = clk_get_parent_by_index(clk,
+ DCLK_VOP_PARENT_NPLL);
+ *best_parent_rate = rk3288_pll_rates[i].rate;
+ return rk3288_pll_rates[i].rate;
+ }
+ }
+
+ /*
+* We were not able to find a matching rate, so falling back
+* to finding the fastest rate < rate.
+* We allow the npll to change its rate while the other plls
+* are not allowed to change.
+*/
+ for (i = 0; i < num_parents; i++) {
+ parent = clk_get_parent_by_index(clk, i);
+ if (!parent)
+ continue;
+
+ if (i == DCLK_VOP_PARENT_NPLL)
+ parent_rate = __clk_round_rate(parent, rate);
+ else
+ parent_rate = __clk_get_rate(parent);
+ if (parent_rate <= rate && parent_rate > best) {
+ int div = DIV_ROUND_UP(parent_rate, rate);
+ *best_parent_p = parent;
+ *best_parent_rate = parent_rate;
+ best = DIV_ROUND_UP(parent_rate, div);
+ }
+ }
+
+ return best;
+}
+
+
+const struct clk_ops dclk_vop_ops = {
+ .recalc_rate = clk_divider_recalc_rate,
+ .set_rate = clk_divider_set_rate,
+ .determine_rate = dclk_vop_determine_rate,
+};
static void __init rk3288_clk_init(struct device_node *np)
{
--
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/
[PATCH 1/5] clk: rockchip: add some clock rate into rate table for rk3288
We are going to support all the HDMI resolutions which need a bunch
of accurate clock rates. This patch makes the pll rate table can
provide all the option clock rate that HDMI controller may needed.
Here's what HDMI needs:
resolutions Pixel clock(Mhz)
1920x1080p 60/50148.5
1920x1080i 100/120 148.5
1920x1080i 60/5074.25
1280x720p 60/50/30/25 74.25
720x576p 50 27
720x480p 60 27
1440x480i 6027
1440x576i 5027
1680x1050 60146.25
1280x1024 60108
1280x960 60 108
1440x900 60 106.5
1280x800 60 83.5
1024x768 60 65
800x600 60 40
800x600 56 36
640x480 60 25.175
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk-rk3288.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 279a662..48412e9 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -73,6 +73,7 @@ struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE(112800, 1, 47, 1),
RK3066_PLL_RATE(110400, 1, 46, 1),
RK3066_PLL_RATE(100800, 1, 84, 2),
+ RK3066_PLL_RATE(100700, 12, 1007, 2),
RK3066_PLL_RATE( 91200, 1, 76, 2),
RK3066_PLL_RATE( 89100, 8, 594, 2),
RK3066_PLL_RATE( 88800, 1, 74, 2),
@@ -84,6 +85,7 @@ struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE( 69600, 1, 58, 2),
RK3066_PLL_RATE( 6, 1, 50, 2),
RK3066_PLL_RATE_BWADJ(59400, 1, 198, 8, 1),
+ RK3066_PLL_RATE( 58500, 4, 195, 2),
RK3066_PLL_RATE( 55200, 1, 46, 2),
RK3066_PLL_RATE( 50400, 1, 84, 4),
RK3066_PLL_RATE( 5, 3, 125, 2),
@@ -97,6 +99,7 @@ struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE( 29700, 2, 198, 8),
RK3066_PLL_RATE( 25200, 1, 84, 8),
RK3066_PLL_RATE( 21600, 1, 72, 8),
+ RK3066_PLL_RATE( 16700, 3, 167, 8),
RK3066_PLL_RATE( 14850, 2, 99, 8),
RK3066_PLL_RATE( 12600, 1, 84, 16),
RK3066_PLL_RATE( 4800, 1, 64, 32),
--
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/
[PATCH 3/5] clk: rockchip: introduce the div_ops handling for composite branches
Rockchip Socs have a lot of clock node registered as composite
branch which include mux, divider and gate, most of them use
the same ops handling callback, we still need special ops
handling for some special clock node and this patch make it
possible.
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk.c | 13 +
drivers/clk/rockchip/clk.h | 24
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 1e68bff..0917c2b 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -42,6 +42,7 @@ static struct clk *rockchip_clk_register_branch(const char
*name,
const char **parent_names, u8 num_parents, void __iomem *base,
int muxdiv_offset, u8 mux_shift, u8 mux_width, u8 mux_flags,
u8 div_shift, u8 div_width, u8 div_flags,
+ const struct clk_ops *divops,
struct clk_div_table *div_table, int gate_offset,
u8 gate_shift, u8 gate_flags, unsigned long flags,
spinlock_t *lock)
@@ -90,9 +91,12 @@ static struct clk *rockchip_clk_register_branch(const char
*name,
div->width = div_width;
div->lock = lock;
div->table = div_table;
- div_ops = (div_flags & CLK_DIVIDER_READ_ONLY)
- ? _divider_ro_ops
- : _divider_ops;
+ if (divops)
+ div_ops = divops;
+ else if (div_flags & CLK_DIVIDER_READ_ONLY)
+ div_ops = _divider_ro_ops;
+ else
+ div_ops = _divider_ops;
}
clk = clk_register_composite(NULL, name, parent_names, num_parents,
@@ -275,7 +279,8 @@ void __init rockchip_clk_register_branches(
reg_base, list->muxdiv_offset, list->mux_shift,
list->mux_width, list->mux_flags,
list->div_shift, list->div_width,
- list->div_flags, list->div_table,
+ list->div_flags,
+ list->div_ops, list->div_table,
list->gate_offset, list->gate_shift,
list->gate_flags, flags, _lock);
break;
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 6baf665..2cf263b 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -185,6 +185,7 @@ struct rockchip_clk_branch {
u8 div_shift;
u8 div_width;
u8 div_flags;
+ const struct clk_ops*div_ops;
struct clk_div_table*div_table;
int gate_offset;
u8 gate_shift;
@@ -212,6 +213,29 @@ struct rockchip_clk_branch {
.gate_flags = gf, \
}
+#define COMPOSITE_DIVOPS(_id, cname, pnames, f, mo, ms, mw, mf, \
+ ds, dw, df, dops, go, gs, gf) \
+ { \
+ .id = _id, \
+ .branch_type= branch_composite, \
+ .name = cname,\
+ .parent_names = pnames, \
+ .num_parents= ARRAY_SIZE(pnames), \
+ .flags = f,\
+ .muxdiv_offset = mo, \
+ .mux_shift = ms, \
+ .mux_width = mw, \
+ .mux_flags = mf, \
+ .div_shift = ds, \
+ .div_width = dw, \
+ .div_flags = df, \
+ .div_ops= dops, \
+ .gate_offset= go, \
+ .gate_shift = gs, \
+ .gate_flags = gf, \
+ }
+
+
#define COMPOSITE_NOMUX(_id, cname, pname, f, mo, ds, dw, df, \
go, gs, gf) \
{ \
--
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: linux-next: build failure after merge of the mfd tree
On wto, 2014-11-04 at 16:40 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mfd tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> drivers/regulator/max77686.c:432:13: warning: 'struct max77686_platform_data'
> declared inside parameter list
> struct max77686_platform_data *pdata)
> ^
> drivers/regulator/max77686.c:432:13: warning: its scope is only this
> definition or declaration, which is probably not what you want
> drivers/regulator/max77686.c: In function 'max77686_pmic_dt_parse_pdata':
> drivers/regulator/max77686.c:447:7: error: dereferencing pointer to
> incomplete type
> pdata->num_regulators = ARRAY_SIZE(regulators);
>^
> drivers/regulator/max77686.c:448:42: error: dereferencing pointer to
> incomplete type
> rdata = devm_kzalloc(>dev, sizeof(*rdata) *
> ^
> drivers/regulator/max77686.c:449:14: error: dereferencing pointer to
> incomplete type
> pdata->num_regulators, GFP_KERNEL);
> ^
> drivers/regulator/max77686.c:455:23: error: dereferencing pointer to
> incomplete type
> for (i = 0; i < pdata->num_regulators; i++) {
>^
> drivers/regulator/max77686.c:460:3: error: invalid use of undefined type
> 'struct max77686_regulator_data'
>rdata[i].initdata = rmatch.init_data;
>^
> drivers/regulator/max77686.c:460:8: error: dereferencing pointer to
> incomplete type
>rdata[i].initdata = rmatch.init_data;
> ^
> drivers/regulator/max77686.c:461:3: error: invalid use of undefined type
> 'struct max77686_regulator_data'
>rdata[i].of_node = rmatch.of_node;
>^
> drivers/regulator/max77686.c:461:8: error: dereferencing pointer to
> incomplete type
>rdata[i].of_node = rmatch.of_node;
> ^
> drivers/regulator/max77686.c:464:7: error: dereferencing pointer to
> incomplete type
> pdata->regulators = rdata;
>^
>
> And so on ...
>
> Caused by commit 9d5f4c2c748e ("mfd: max77686/802: Remove support for
> board files") from the mfd tree.
>
> I reverted that commit for today.
The commit depends on other patches from a set which hadn't been
applied. Please drop it.
Best regards,
Krzysztof
--
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/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation
Hello, On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: > On 10/16/2014 10:55 AM, Laura Abbott wrote: > >On 10/15/2014 8:35 PM, Hui Zhu wrote: > > > >It's good to see another proposal to fix CMA utilization. Do you have > >any data about the success rate of CMA contiguous allocation after > >this patch series? I played around with a similar approach of using > >CMA for MIGRATE_MOVABLE allocations and found that although utilization > >did increase, contiguous allocations failed at a higher rate and were > >much slower. I see what this series is trying to do with avoiding > >allocation from CMA pages when a contiguous allocation is progress. > >My concern is that there would still be problems with contiguous > >allocation after all the MIGRATE_MOVABLE fallback has happened. > > Hi, > > did anyone try/suggest the following idea? > > - keep CMA as fallback to MOVABLE as is is now, i.e. non-agressive > - when UNMOVABLE (RECLAIMABLE also?) allocation fails and CMA > pageblocks have space, don't OOM immediately, but first try to > migrate some MOVABLE pages to CMA pageblocks, to make space for the > UNMOVABLE allocation in non-CMA pageblocks > - this should keep CMA pageblocks free as long as possible and > useful for CMA allocations, but without restricting the non-MOVABLE > allocations even though there is free memory (but in CMA pageblocks) > - the fact that a MOVABLE page could be successfully migrated to CMA > pageblock, means it was not pinned or otherwise non-migratable, so > there's a good chance it can be migrated back again if CMA > pageblocks need to be used by CMA allocation I suggested exactly same idea long time ago. > - it's more complex, but I guess we have most of the necessary > infrastructure in compaction already :) I agree but still, it doesn't solve reclaim problem(ie, VM doesn't need to reclaim CMA pages when memory pressure of unmovable pages happens). Of course, we could make VM be aware of that via introducing new flag of __isolate_lru_page. However, I'd like to think CMA design from the beginning. It made page allocation logic complicated, even very fragile as we had recently and now we need to add new logics to migrate like you said. As well, we need to fix reclaim path, too. It makes mm complicated day by day even though it doesn't do the role enough well(ie, big latency and frequent allocation failure) so I really want to stop making the mess bloated. Long time ago, when I saw Joonsoo's CMA agressive allocation patchset (ie, roundrobin allocation between CMA and normal movable pages) it was good to me at a first glance but it needs tweak of allocation path and doesn't solve reclaim path, either. Yes, reclaim path could be solved by another patch but I want to solve it altogether. At that time, I suggested big surgery to Joonsoo in offline that let's move CMA allocation with movable zone allocation. With it, we could make allocation/reclaim path simple but thing is we should make VM be aware of overlapping MOVABLE zone which means some of pages in the zone could be part of another zones but I think we already have logics to handle it when I read comment in isolate_freepages so I think the design should work. A thing you guys might worry is bigger CMA latency because it makes CMA memory usage ratio higher than the approach you mentioned but anyone couldn't guarantee it once memory is fully utilized. In addition, we have used fair zone allocator policy so it makes round robin allocation automatically so I believe it should be way to go. > > Thoughts? > Vlastimil > > >Thanks, > >Laura > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- 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 02/14] mfd/regulator: dt-bindings: max77686: Document of_compatible for regulator
On pon, 2014-11-03 at 17:00 +, Lee Jones wrote:
> On Thu, 30 Oct 2014, Krzysztof Kozlowski wrote:
>
> > Document new required property for regulator driver: of_compatible. The
> > property allows MFD core to bind the driver to node with regulators and
> > this simplifies parsing regulators init data from DTS
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > Documentation/devicetree/bindings/mfd/max77686.txt | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
>
> I want a thumbs-up from Mark on this before applying.
I'll be resending new version, without the compatible property.
Best regards,
Krzysztof
>
> > diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
> > b/Documentation/devicetree/bindings/mfd/max77686.txt
> > index 75fdfaf41831..f4010a9f66eb 100644
> > --- a/Documentation/devicetree/bindings/mfd/max77686.txt
> > +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
> > @@ -18,8 +18,11 @@ Required properties:
> >
> > Optional node:
> > - voltage-regulators : The regulators of max77686 have to be instantiated
> > - under subnode named "voltage-regulators" using the following format.
> > + under subnode named "voltage-regulators".
> > + Required property:
> > + - compatible : Must be "maxim,max77686-pmic"
> >
> > + Optional properties: For each regulator use following format:
> > regulator_name {
> > regulator-compatible = LDOn/BUCKn
> > standard regulator constraints
> > @@ -49,6 +52,8 @@ Example:
> > reg = <0x09>;
> >
> > voltage-regulators {
> > + compatible = "maxim,max77686-pmic";
> > +
> > ldo11_reg {
> > regulator-compatible = "LDO11";
> > regulator-name = "vdd_ldo11";
>
--
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 08/14] mfd: max77686/802: Remove support for board files
On pon, 2014-11-03 at 17:01 +, Lee Jones wrote: > On Thu, 30 Oct 2014, Krzysztof Kozlowski wrote: > > > The driver is used only on Exynos based boards with DTS support. > > Convert the driver to DTS-only version. This simplifies a little the > > code: > > 1. No dead (unused) entries in platform_data structure. > > 2. More code removed. > > 3. Regulator driver does not depend on allocated memory > >from MFD driver. > > 4. It makes also easier extending the regulator driver. > > > > Add to the max77686 MFD driver dependency on CONFIG_OF because without > > DTS the regulator drivers won't bind. > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Javier Martinez Canillas > > --- > > drivers/mfd/Kconfig | 1 + > > drivers/mfd/max77686.c | 23 --- > > include/linux/mfd/max77686-private.h | 1 - > > include/linux/mfd/max77686.h | 28 > > 4 files changed, 1 insertion(+), 52 deletions(-) > > Applied, thanks. N, don't apply it. It depends on previous patches removing the board file support from regulators. If the patch looks OK, please only ack it. I would like to push everything through regulator tree. Best regards, Krzysztof -- 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] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Mon, Nov 03, 2014 at 02:40:38PM -0600, Felipe Balbi wrote: > Hi, > > On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote: > > > > > > > > > I think adding the module exit + allowing this driver to be a > > > > > > > > > module > > > > > > > > > would be a good approach. Then we don't need to force generic > > > > > > > > > x86 kernel > > > > > > > > > binaries to always have this driver. Unless Mathias or Mika > > > > > > > > > knows a > > > > > > > > > constraint to force this driver to be builtin only. > > > > > > > > > > > > > > > > It helps if I CC them when asking for feedback :) > > > > > > > > > > > > > > > > Mathias, Mika, do you know any constraint that forces > > > > > > > > pinctrl-baytrail > > > > > > > > to be bool? > > > > > > > > > > > > > > The only constraint that has been keeping this driver as bool is > > > > > > > that > > > > > > > some machines like, Asus T100, uses ACPI GPIO operation regions > > > > > > > for > > > > > > > toggling GPIOs to get things like sensor hub powered on. The GPIO > > > > > > > operation region code does not yet handle -EPROBE_DEFER so only > > > > > > > way to > > > > > > > ensure that the operation region is there is to have the driver > > > > > > > compiled > > > > > > > in to the kernel. > > > > > > > > > > > > But that's not enough excuse to have every single x86 in the market > > > > > > shipping with this driver. Think about a distro kernel, most likely > > > > > > this > > > > > > gets enabled and it's wrong in 80% of the cases. > > > > > > > > > > True, but see below. > > > > > > > > > > > It would be nicer to add EPROBE_DEFER support, convert this into > > > > > > tristate and have default = M if BAYTRAIL, or something. > > > > > > > > > > If it were simple as that we would have done that already. Please > > > > > check > > > > > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and tell me > > > > > how we can do that. > > > > > > > > Actually the above is not the problem because we already have registered > > > > the GPIO chip and hence we have the GPIO available to the firmware code. > > > > > > what happens before you registered the gpio chip ? It takes some time > > > from head.S to gpiochip_irqchip_add(). Anywhere between that time, > > > firmware could try to access gpios and the same problem would occur. > > > > The operation region is not ready and the firmware does not try to use > > it. However, the subsys_initcall() is there just to be sure that the > > GPIO driver gets loaded before anything that is going to use GPIOs from > > firmware. > > alright, so how does the firmware know that the operation region is > ready and why can't that be deferred until pinctrl-baytrail (module or > built-in) has finished probing ? That would sort both issues, would it > not ? The firmware checks the dependent object for AVBL or similar variable. If it is != 0 it assumes that the operation region is there. The problem is how can you tell the firmware that it should somehow try again? Here _DEP is the right solution as it forces the dependencies to be loaded first. > > > > The real problem is that if the ACPI GPIO operation handler is not there > > > > at the time firmware decides to do something it will just skip things > > > > that depend on the operation region. So if it has a GPIO that is used to > > > > turn on sensor hub or touch panel or whatever, this will not be done and > > > > it results that the device in question might not work properly. > > > > > > that's an issue that needs solving, but forcing every x86 kernel to ship > > > with this driver, is not a proper solution. > > > > I would rather have the driver build in to the kernel now (and btw it > > has been already in mainline quite some time so I suspect many distros > > have already enabled it), than turning it module and render some devices > > that have been working previously, fail suddenly. > > that's why I said you should default to Y if BAYTRAIL or make it > tristate and always default to M. So you are saying it is better to add config option BAYTRAIL and then make the driver Y? Well, now generic distros need to select that as Y which doesn't solve anything. -- 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] mmc: Add a quirk for AMD SDHC transfer mode register need to be cleared for cmd without data
On 30 October 2014 05:06, Vincent Wan wrote:
> SDHC controller in AMD chipsets require SDHC transfer mode
> register to be cleared for commands without data. The issue was
> uncovered during testing eMMC cards on KB/ML based platforms.
>
> Signed-off-by: Vincent Wan
> Signed-off-by: Arindam Nath
> Tested-by: Vikram B
> Tested-by: Raghavendra Swamy
Hi Vincent,
This looks good to me, but the patch has checkpatch errors.
Could you check at your side and re-send?
Kind regards
Uffe
>
> ---
> drivers/mmc/host/sdhci-pci.c | 27 +++
> drivers/mmc/host/sdhci.c | 11 ---
> include/linux/mmc/sdhci.h| 2 ++
> 3 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
> index 6119297..8f5c998 100644
> --- a/drivers/mmc/host/sdhci-pci.c
> +++ b/drivers/mmc/host/sdhci-pci.c
> @@ -645,6 +645,23 @@ static const struct sdhci_pci_fixes sdhci_rtsx = {
> .probe_slot = rtsx_probe_slot,
> };
>
> +static int amd_probe(struct sdhci_pci_chip *chip)
> +{
> + struct pci_dev *smbus_dev;
> +
> + smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
> + PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, NULL);
> +
> + if (smbus_dev && (smbus_dev->revision < 0x51))
> + chip->quirks2 |=
> SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
> +
> + return 0;
> +}
> +
> +static const struct sdhci_pci_fixes sdhci_amd = {
> + .probe = amd_probe,
> +};
> +
> static const struct pci_device_id pci_ids[] = {
> {
> .vendor = PCI_VENDOR_ID_RICOH,
> @@ -1045,6 +1062,16 @@ static const struct pci_device_id pci_ids[] = {
> .driver_data= (kernel_ulong_t)_o2,
> },
>
> + {
> + .vendor = PCI_VENDOR_ID_AMD,
> + .device = PCI_ANY_ID,
> + .class = PCI_CLASS_SYSTEM_SDHCI << 8,
> + .class_mask = 0x00,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = PCI_ANY_ID,
> + .driver_data= (kernel_ulong_t)_amd,
> + },
> +
> { /* Generic SD host controller */
> PCI_DEVICE_CLASS((PCI_CLASS_SYSTEM_SDHCI << 8), 0x00)
> },
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ada1a3e..8085f26 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -889,10 +889,15 @@ static void sdhci_set_transfer_mode(struct sdhci_host
> *host,
> struct mmc_data *data = cmd->data;
>
> if (data == NULL) {
> - /* clear Auto CMD settings for no data CMDs */
> - mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
> - sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 |
> + if (host->quirks2 &
> + SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
> + sdhci_writew(host, 0x0, SDHCI_TRANSFER_MODE);
> + } else {
> + /* clear Auto CMD settings for no data CMDs */
> + mode = sdhci_readw(host, SDHCI_TRANSFER_MODE);
> + sdhci_writew(host, mode & ~(SDHCI_TRNS_AUTO_CMD12 |
> SDHCI_TRNS_AUTO_CMD23),
> SDHCI_TRANSFER_MODE);
> + }
> return;
> }
>
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index dba793e..0a287aa 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -100,6 +100,8 @@ struct sdhci_host {
> #define SDHCI_QUIRK2_BROKEN_DDR50 (1<<7)
> /* Stop command (CMD12) can set Transfer Complete when not using
> MMC_RSP_BUSY */
> #define SDHCI_QUIRK2_STOP_WITH_TC (1<<8)
> +/* need clear transfer mode register before send cmd */
> +#define SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD (1<<9)
>
> int irq;/* Device IRQ */
> void __iomem *ioaddr; /* Mapped address */
> --
> 1.8.1.2
>
--
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 5/5] Use 2GB memory block size on large x86-64 systems
On Tue, 4 Nov 2014, Daniel J Blueman wrote:
> On 11/04/2014 07:36 AM, Thomas Gleixner wrote:
> > On Tue, 4 Nov 2014, Daniel J Blueman wrote:
> > > > > @@ -1247,9 +1246,9 @@ static unsigned long
> > > > > probe_memory_block_size(void)
> > > > > /* start from 2g */
> > > > > unsigned long bz = 1UL<<31;
> > > > >
> > > > > -#ifdef CONFIG_X86_UV
> > > > > - if (is_uv_system()) {
> > > > > - printk(KERN_INFO "UV: memory block size 2GB\n");
> > > > > +#ifdef CONFIG_X86_64
> > > >
> > > > And this brainless 's/CONFIG_X86_UV/CONFIG_X86_64/' sucks even
> > > > more. I'm sure you can figure out the WHY yourself.
> > >
> > > The benefit of this is applicable to other architectures. I'm unable to
> > > test
> > > the change, but if you agree it's conservative enough, I'll drop the
> > > ifdef?
> >
> > Which other architectures? Care to turn on your brain before replying?
>
> Clearly 64-bit architectures, including X86, MIPS, PARISC, SPARC, AArch64,
> ia64,
ROTFL
> however, I must be missing something, as a sizeof(long)/CONFIG_64BIT
> check would be redundant if we agree to drop the ifdef, as we're already
> checking the number of physical pages, which is bounded by the same limits.
# diffstat $this_patch
should precicely tell you what you're missing.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] mfd: ab8500: Decrement the power supply's device reference counter
On pon, 2014-11-03 at 18:00 +, Lee Jones wrote:
> On Mon, 03 Nov 2014, Lee Jones wrote:
>
> > On Tue, 14 Oct 2014, Krzysztof Kozlowski wrote:
> >
> > > Use power_supply_put() to decrement the power supply's device reference
> > > counter.
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > > ---
> > > drivers/mfd/ab8500-sysctrl.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > Applied, thanks.
>
> Whoops, to hasty there -- unapplied.
>
> What's going on with this set?
The set should be pulled at once (everything depends on 1st patch).
It is still waiting for reviews. I'll resend soon.
Best regards,
Krzysztof
>
> > > diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
> > > index 93b2d2c32ca3..d05a5719cfc4 100644
> > > --- a/drivers/mfd/ab8500-sysctrl.c
> > > +++ b/drivers/mfd/ab8500-sysctrl.c
> > > @@ -51,6 +51,7 @@ static void ab8500_power_off(void)
> > >
> > > ret = power_supply_get_property(psy, POWER_SUPPLY_PROP_ONLINE,
> > > );
> > > + power_supply_put(psy);
> > >
> > > if (!ret && val.intval) {
> > > charger_present = true;
> > > @@ -73,6 +74,7 @@ static void ab8500_power_off(void)
> > > pss[i]);
> > > machine_restart("charging");
> > > }
> > > + power_supply_put(psy);
> > > }
> > >
> > > shutdown:
> >
>
--
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: your patch "mm: Remove false WARN_ON from pagecache_isize_extended()"
>>> On 03.11.14 at 23:18, wrote: > On Mon, Nov 03, 2014 at 04:41:13PM +, Jan Beulich wrote: >> having run into that warning too, I looked into it a little, and now >> having found that patch am pretty uncertain: Both truncate_setsize() >> and pagecache_isize_extended() document that they want to be >> called with i_mutex held, so removing the WARN_ON() alone seems >> either incomplete or wrong. What I found to work without violating >> this documented requirement is the patch below. > > Or, just perhaps, the comments are wrong Right - that's what I was suggesting with the option of the patch being incomplete (rather than just removing the WARN_ON() it should also remove the respective comments then). Jan -- 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/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
On 10/31/2014 10:28 PM, Alan Stern wrote:
On Fri, 31 Oct 2014, Lu Baolu wrote:
xhci: clear root port wake on bits if controller isn't wake-up capable
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_pci_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-pci.c | 42 ++
drivers/usb/host/xhci.h | 6 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 280dde9..3e7441a 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -27,6 +27,8 @@
#include "xhci.h"
#include "xhci-trace.h"
+#define PORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Device for a quirk */
#define PCI_VENDOR_ID_FRESCO_LOGIC0x1b73
#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK0x1000
@@ -126,6 +128,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
*/
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
xhci->quirks |= XHCI_AVOID_BEI;
+ xhci->quirks |= XHCI_DISABLE_PORT_WOB;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI ||
@@ -279,6 +282,42 @@ static void xhci_pci_remove(struct pci_dev *dev)
}
#ifdef CONFIG_PM
+static void xhci_disable_port_wake_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(>lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(>lock, flags);
+}
+
static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
@@ -291,6 +330,9 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
+ if (xhci->quirks & XHCI_DISABLE_PORT_WOB && !do_wakeup)
+ xhci_disable_port_wake_bits(xhci);
+
return xhci_suspend(xhci);
}
There are two things wrong here. First, this should not be a quirk.
The Wake-On bits should be disabled whenever they aren't needed, on
every controller.
Second, this code (or something like it) belongs in xhci.c or
xhci-hub.c, not xhci-pci.c. This is because it should apply to all
xHCI controllers, not just the PCI-based ones.
Hi Alan,
I agree with you. I will resubmit my patches.
BR,
baolu
(In fact, instead of disabling the Wake-On bits when the controller is
suspended and do_wakeup is 0, it probably would be better to leave them
disabled normally and then _enable_ them if do_wakeup is 1.)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/8] ARM: mediatek: Add basic support for mt8127
On Tuesday 04 November 2014 14:36:45 HC Yen wrote: > > > + > > > +#include > > > +#include > > > +#include "skeleton64.dtsi" > > > > Cortex a7 is 32 bits, right? So why do you use skeleton64.dtsi? > > Cortex-A7 is 32-bit, but that doesn't mean it can only have 32-bit > physical address. With LPAE enabled, we can have physical address more > than 32 bits. > > The main difference between "skeleton64.dtsi" and "skeleton.dtsi" is > "#address-cells" property set to 2. Although there are few sources > using "skeleton64.dtsi", some of them write "#address-cells = <2>" > directly in order to have 64-bit address space. ARM's TC2 reference > platform (vexpress-v2p-ca15_a7.dts) is an example. > > Some of MediaTek ARMv7 SoCs support address space larger than 4GB. It > will be convenient to share the sources if we all use 64-bit device > tree. Right, in general, I'd use #address-cells=<2> for Cortex-A7/A15/A17. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events
Hi Hemant,
As you know, you need to keep an eye on how (kprobes) event cache
patchset from Masami settles down. For those who aren't CC'ed, please
see the link below:
https://lkml.org/lkml/2014/10/31/207
On Sun, 02 Nov 2014 16:26:28 +0530, Hemant Kumar wrote:
> This patch adds support to perf to record SDT events. When invoked,
> the SDT event is looked up in the sdt-cache. If its found, an entry is
> made silently to uprobe_events file and then recording is invoked, and
> then the entry for the SDT event in uprobe_events is silently discarded.
>
> The SDT events are already stored in a cache file
> (/var/cache/perf/perf-sdt-file.cache).
> Although the file_hash table helps in addition or deletion of SDT events
> from the cache, its not of much use when it comes to probing the actual
> SDT event, because the key to this hash list is a file name and not the
> SDT event name (which is given as an argument to perf record). So, we
> won't be able to hash into it.
It likely to be ended up with per-file or per-buildid cache files under
~/.debug directory. In this case we also need to have the (central)
event-to-cache table anyway IMHO.
>
> To avoid this problem, we can create another hash list "event_hash" list
> which will be maintained along with the file_hash list.
> Whenever a user invokes 'perf record -e %provider:event, perf should
> initialize the event_hash list and the file_hash list.
> The key to event_hash list is calculated from the event name and its
> provider name.
Isn't it enough just to use provide name? I guess the provider names
are (should be?) unique among a system although there's no absolute
guarantee for that.
>
> event_hash sdt_note
> |-|
> | | | file_ptr |==> container file_sdt_ent
> key = 129 =>| hlist ==|===|=> event_list=|==> to sdt notes hashed to
> | | | name |same entry
> |-| | provider |
> | | | note_list==|==> to other notes in the
> key = 130 =>| hlist | --- same file
> |-|
>
> The entry at that key in event_hash contains a list of SDT notes hashed to
> the same entry. It compares the name and provider to see if that is the SDT
> note we are looking for. If yes, find out the file that contains this SDT
> note. There is a file_ptr pointer embedded in this note which points to the
> struct file_sdt_ent contained in the file_hash. From "file_sdt_ent" we will
> find out the file name.
> Convert this sdt note into a perf event and then write this into
> uprobe_events file to be able to record the event.
> Then, corresponding entries are added to uprobe_events file for
> the SDT events.
> After recording is done, these events are silently deleted from uprobe_events
> file. The uprobe_events file is present in debugfs/tracing directory.
>
> To support the addition and deletion of SDT events to/from uprobe_events
> file, a record_sdt struct is maintained which has the event data.
>
> An example usage:
>
> # perf record -e %libc:setjmp -aR sleep 10
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.277 MB perf.data (~12103 samples) ]
>
> # perf report --stdio
> # To display the perf.data header info, please use --header/--header-only
> #
> # Samples: 1 of event 'libc:setjmp'
> # Event count (approx.): 1
> #
> # Overhead Command Shared Object Symbol
> # ... . ...
> #
>100.00% sleeplibc-2.16.so [.] __sigsetjmp
>
>
> Signed-off-by: Hemant Kumar
[SNIP]
> +/* Session specific to SDT tracing */
> +struct record_sdt {
> + boolsdt;/* is this SDT event tracing? */
> + char*str; /* hold the event name */
> +} rec_sdt;
> +
> +int trace_sdt_event(const char *str)
> +{
> + int ret = 0;
> +
> + rec_sdt.sdt = true;
> + rec_sdt.str = strdup(str);
> + if (!rec_sdt.str)
> + return -ENOMEM;
> + ret = event_hash_list__lookup(str);
> + return ret;
> +}
Hmm.. does it support multiple SDT events recorded in a session like:
# perf record -e %libc:setjmp -e %libc:longjmp -aR sleep 10
?
[SNIP]
> +/* Parse an SDT event */
> +static int parse_perf_sdt_event(struct perf_sdt_event *sev,
> + struct perf_probe_event *pev)
> +{
> + struct perf_probe_point *pp = >point;
> +
> + pev->uprobes = true;
> + pev->sdt = true;
> + pev->event = strdup(sev->note->name);
> + if (pev->event == NULL)
> + return -ENOMEM;
> + pev->group = strdup(sev->note->provider);
> + if (pev->event == NULL)
s/event/group/
> + return -ENOMEM;
> +
> + pp->file = strdup(sev->file_name);
> + if (pp->file == NULL)
> + return -ENOMEM;
> +
> + pp->function = strdup(sev->note->name);
Missing NULL check. Also you need to free prior allocations in case of
error.
Thanks,
[PATCH] hwmon: (ibmpowernv) Use platform 'id_table' to probe the device
The current driver probe() function assumes the sensor device to be
alwary present and gets executed every time if the driver is loaded,
but the appropriate hardware could not be present.
So, move the platform device creation as part of platform init code
and use the 'id_table' to check if the device present or not.
Signed-off-by: Neelesh Gupta
---
arch/powerpc/platforms/powernv/opal-sensor.c | 20
drivers/hwmon/ibmpowernv.c | 67 +++---
2 files changed, 39 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c
b/arch/powerpc/platforms/powernv/opal-sensor.c
index 10271ad..215c418 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -20,7 +20,9 @@
#include
#include
+#include
#include
+#include
static DEFINE_MUTEX(opal_sensor_mutex);
@@ -64,3 +66,21 @@ out:
return ret;
}
EXPORT_SYMBOL_GPL(opal_get_sensor_data);
+
+static __init int opal_sensor_init(void)
+{
+ struct platform_device *pdev;
+ struct device_node *sensor;
+
+ sensor = of_find_node_by_path("/ibm,opal/sensors");
+ if (sensor) {
+ pdev = of_platform_device_create(sensor, "opal-sensor", NULL);
+ of_node_put(sensor);
+ } else {
+ pr_info("Opal node 'sensors' not found\n");
+ return -ENODEV;
+ }
+
+ return PTR_ERR_OR_ZERO(pdev);
+}
+machine_subsys_initcall(powernv, opal_sensor_init);
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6a30eee..c7577b8 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -74,9 +74,6 @@ struct platform_data {
u32 sensors_count; /* Total count of sensors from each group */
};
-/* Platform device representing all the ibmpowernv sensors */
-static struct platform_device *pdevice;
-
static ssize_t show_sensor(struct device *dev, struct device_attribute
*devattr,
char *buf)
{
@@ -99,7 +96,7 @@ static ssize_t show_sensor(struct device *dev, struct
device_attribute *devattr,
return sprintf(buf, "%u\n", x);
}
-static int __init get_sensor_index_attr(const char *name, u32 *index,
+static int get_sensor_index_attr(const char *name, u32 *index,
char *attr)
{
char *hash_pos = strchr(name, '#');
@@ -136,7 +133,7 @@ static int __init get_sensor_index_attr(const char *name,
u32 *index,
* which need to be mapped as fan2_input, temp1_max respectively before
* populating them inside hwmon device class.
*/
-static int __init create_hwmon_attr_name(struct device *dev, enum sensors type,
+static int create_hwmon_attr_name(struct device *dev, enum sensors type,
const char *node_name,
char *hwmon_attr_name)
{
@@ -172,7 +169,7 @@ static int __init create_hwmon_attr_name(struct device
*dev, enum sensors type,
return 0;
}
-static int __init populate_attr_groups(struct platform_device *pdev)
+static int populate_attr_groups(struct platform_device *pdev)
{
struct platform_data *pdata = platform_get_drvdata(pdev);
const struct attribute_group **pgroups = pdata->attr_groups;
@@ -180,11 +177,6 @@ static int __init populate_attr_groups(struct
platform_device *pdev)
enum sensors type;
opal = of_find_node_by_path("/ibm,opal/sensors");
- if (!opal) {
- dev_dbg(>dev, "Opal node 'sensors' not found\n");
- return -ENODEV;
- }
-
for_each_child_of_node(opal, np) {
if (np->name == NULL)
continue;
@@ -221,7 +213,7 @@ static int __init populate_attr_groups(struct
platform_device *pdev)
* to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
* etc..
*/
-static int __init create_device_attrs(struct platform_device *pdev)
+static int create_device_attrs(struct platform_device *pdev)
{
struct platform_data *pdata = platform_get_drvdata(pdev);
const struct attribute_group **pgroups = pdata->attr_groups;
@@ -280,7 +272,7 @@ exit_put_node:
return err;
}
-static int __init ibmpowernv_probe(struct platform_device *pdev)
+static int ibmpowernv_probe(struct platform_device *pdev)
{
struct platform_data *pdata;
struct device *hwmon_dev;
@@ -309,52 +301,31 @@ static int __init ibmpowernv_probe(struct platform_device
*pdev)
return PTR_ERR_OR_ZERO(hwmon_dev);
}
+static const struct platform_device_id opal_sensor_driver_ids[] = {
+ {
+ .name = "opal-sensor",
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, opal_sensor_driver_ids);
+
static struct platform_driver ibmpowernv_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = DRVNAME,
+ .probe = ibmpowernv_probe,
+
"asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
Hi, With 3.18-rc3, asix on arndale (samsung exynos 5250 based board), fails to work. Interface is initialized but network traffic seem not to pass through. With kernel IP config the result looks like: [3.323275] usb 3-3.2.4: new high-speed USB device number 4 using exynos-ehci [3.419151] usb 3-3.2.4: New USB device found, idVendor=0b95, idProduct=772a [3.424735] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.432196] usb 3-3.2.4: Product: AX88772 [3.436279] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. [3.441486] usb 3-3.2.4: SerialNumber: 01 [3.447530] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): invalid hw address, using random [3.764352] asix 3-3.2.4:1.0 eth0: register 'asix' at usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, de:a2:66:bf:ca:4f [4.488773] asix 3-3.2.4:1.0 eth0: link down [5.690025] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [5.712947] Sending DHCP requests .. timed out! [ 83.165303] IP-Config: Retrying forever (NFS root)... [ 83.170397] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [ 83.192944] Sending DHCP requests . Similar results also with dhclient. Git bisect identified the breaking commit as: commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 Author: Michel Stam Date: Thu Oct 2 10:22:02 2014 +0200 asix: Don't reset PHY on if_up for ASIX 88772 Taking 3.18-rc3 and that commit reverted, network works again: [3.303500] usb 3-3.2.4: new high-speed USB device number 4 using exynos-ehci [3.399375] usb 3-3.2.4: New USB device found, idVendor=0b95, idProduct=772a [3.404963] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.412424] usb 3-3.2.4: Product: AX88772 [3.416508] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. [3.421715] usb 3-3.2.4: SerialNumber: 01 [3.427755] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): invalid hw address, using random [3.744837] asix 3-3.2.4:1.0 eth0: register 'asix' at usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, 12:59:f1:a8:43:90 [7.098998] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [7.118258] Sending DHCP requests ., OK [9.753259] IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.111 There might something wrong on the samsung platform code (I understand the USB on arndale is "funny"), but this is still an regression from 3.17. Riku -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] HID: logitech-hidpp: fix negated returns
Looks good. Thanks! regards, dan carpenter -- 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 5/5] Use 2GB memory block size on large x86-64 systems
On 11/04/2014 07:36 AM, Thomas Gleixner wrote:
On Tue, 4 Nov 2014, Daniel J Blueman wrote:
On 11/04/2014 03:38 AM, Thomas Gleixner wrote:
On Sun, 2 Nov 2014, Daniel J Blueman wrote:
On larger x64-64 systems, use a 2GB memory block size to reduce sysfs
entry creation time by 16x. Large is defined as 64GB or more memory.
This changelog sucks.
It neither tells which sysfs entries are meant nor does it explain
what the actual effect of this change is aside of speeding up some
random sysfs thingy.
How about this?
On large-memory systems of 64GB or more with memory hot-plug enabled, use a
2GB memory block size. Eg with 64GB memory, this reduces the number of
directories in /sys/devices/system/memory from 512 to 32, making it more
manageable, and reducing the creation time accordingly.
It still does not tell what the downside is of this and why you think
it does not matter.
Yes, let's make it explicit:
On large-memory systems of 64GB or more with memory hot-plug enabled,
use a 2GB memory block size. Eg with 64GB memory, this reduces the
number of directories in /sys/devices/system/memory from 512 to 32,
making it more manageable, and reducing the creation time accordingly.
This caveat is that the memory can't be offlined (for hotplug or
otherwise) with finer 128MB granularity, but this is unimportant due to
the high memory densities generally used with such large-memory systems,
where eg a single DIMM is the order of 16GB.
@@ -1247,9 +1246,9 @@ static unsigned long probe_memory_block_size(void)
/* start from 2g */
unsigned long bz = 1UL<<31;
-#ifdef CONFIG_X86_UV
- if (is_uv_system()) {
- printk(KERN_INFO "UV: memory block size 2GB\n");
+#ifdef CONFIG_X86_64
And this brainless 's/CONFIG_X86_UV/CONFIG_X86_64/' sucks even
more. I'm sure you can figure out the WHY yourself.
The benefit of this is applicable to other architectures. I'm unable to test
the change, but if you agree it's conservative enough, I'll drop the ifdef?
Which other architectures? Care to turn on your brain before replying?
Clearly 64-bit architectures, including X86, MIPS, PARISC, SPARC,
AArch64, ia64, however, I must be missing something, as a
sizeof(long)/CONFIG_64BIT check would be redundant if we agree to drop
the ifdef, as we're already checking the number of physical pages, which
is bounded by the same limits.
Thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
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: [PULL REQUEST] remove .owner for most platform_drivers
> Just to be sure, the 4 other patches you sent also need to go in here > for 3.19, right? They were not included in this pull request? Yes, they are bugfixes and should go into v3.19 IMO. I sent them as seperate patches so people could review them (which was not necessary for the patches in the pull request). Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCH v3 1/3] perf: Use monotonic clock as a source for timestamps
On Tue, Nov 04, 2014 at 12:28:36AM +, Pawel Moll wrote:
> +int sysctl_perf_sample_time_clk_id = CLOCK_MONOTONIC;
const ?
> /*
> * perf samples are done in some very critical code paths (NMIs).
> * If they take too much CPU time, the system can lock up and not
> @@ -324,7 +326,7 @@ extern __weak const char *perf_pmu_name(void)
>
> static inline u64 perf_clock(void)
> {
> - return local_clock();
> + return ktime_get_mono_fast_ns();
> }
Do we maybe want to make it boot-time switchable back to local_clock for
people with bad systems and or backwards compat issues?
Everybody using Core2 and older will very much not want to have this
unless they've got a very good reason for wanting 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: [char-misc-next V2] mei: nfc: clean nfc internal struct on host exit
> > Stable: 3.15+ > > Please read Documentation/stable_kernel_rules.txt for how to do this > properly. Oops, this is my internal tracking it should be replaced with proper cc to stable, need to fix my scripts. > Please resend, after really verifying this does need to go to the stable > trees... Ok Tomas -- 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 V6 01/17] perf, x86: Reduce lbr_sel_map size
On Tue, Nov 04, 2014 at 08:14:21AM +0100, Peter Zijlstra wrote: > On Tue, Nov 04, 2014 at 01:07:39AM +, Liang, Kan wrote: > > Hi Peter, > > > > Did you get a chance to review the rest of the patch set? > > No point in reviewing stuff I could not apply if I wanted to is there? So please (re)read Documentation/SubmittingPatches and try again. Also, you might want to not Cc Zheng on the next posting (but very much leave him attribution, just not actually send the mail to a dead email address). -- 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 V6 01/17] perf, x86: Reduce lbr_sel_map size
On Tue, Nov 04, 2014 at 01:07:39AM +, Liang, Kan wrote: > Hi Peter, > > Did you get a chance to review the rest of the patch set? No point in reviewing stuff I could not apply if I wanted to is there? -- 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] nvme: fixup compiler warning
gcc complains about a variable not initialized properly.
Cc: Matthew Wilcox
Signed-off-by: Hannes Reinecke
---
drivers/block/nvme-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index e2bb8af..ff37b9f 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -571,7 +571,7 @@ static int nvme_split_and_submit(struct bio *bio, struct
nvme_queue *nvmeq,
static int nvme_map_bio(struct nvme_queue *nvmeq, struct nvme_iod *iod,
struct bio *bio, enum dma_data_direction dma_dir, int psegs)
{
- struct bio_vec bvec, bvprv;
+ struct bio_vec bvec, bvprv = {.bv_offset = 0, .bv_len = 0};
struct bvec_iter iter;
struct scatterlist *sg = NULL;
int length = 0, nsegs = 0, split_len = bio->bi_iter.bi_size;
--
1.8.5.2
--
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.2 019/102] xfs: don't dirty buffers beyond EOF
On Sat, Nov 01, 2014 at 10:28:03PM +, Ben Hutchings wrote: > 3.2.64-rc1 review patch. If anyone has any objections, please let me know. I'm not sure it's a good idea to pull stuff like this back into really old stable kernels. This was part of a much larger series of bug fixes that were fairly carefully tested. I very much doubt that there is specific XFS test coverage on these older kernels that would determine if this has introduced problems or not > > -- > > From: Dave Chinner > > commit 22e757a49cf010703fcb9c9b4ef793248c39b0c2 upstream. > > generic/263 is failing fsx at this point with a page spanning > EOF that cannot be invalidated. The operations are: > > 1190 mapwrite 0x52c00 thru0x5e569 (0xb96a bytes) > 1191 mapread0x5c000 thru0x5d636 (0x1637 bytes) > 1192 write 0x5b600 thru0x771ff (0x1bc00 bytes) I've got no idea whether generic/263 even exposes this problem on 3.2 kernels, or whether there's a bunch of the other upstream changes that need to be added first to expose it... :/ Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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 scsi tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/2014 05:43 AM, Stephen Rothwell wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/sched.h:17:0, from
> include/linux/blkdev.h:4, from drivers/scsi/constants.c:10:
> drivers/scsi/constants.c: In function 'scsi_opcode_sa_name':
> include/linux/kernel.h:54:32: error: invalid application of
> 'sizeof' to incomplete type 'const char *[]' #define
> ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr)) ^ drivers/scsi/constants.c:300:15: note:
> in expansion of macro 'ARRAY_SIZE' if (opcode <
> ARRAY_SIZE(cdb_byte0_names)) ^
>
> Caused by 94bafab0008c ("scsi: consolidate opcode lookup in
> scsi_opcode_sa_name()"). This build does not have
> CONFIG_SCSI_CONSTANTS set.
>
> I have used the scsi tree from next-20141031 again (since
> yesterday's tree had a different build problem).
>
Sorry. Here's the patch.
Cheers,
Hannes
- --
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJUWHtHAAoJEGz4yi9OyKjPfdgP+wZweCbK1HJ7PBz8CCqT6n6d
HDOv0oX4Ia3Oo53NhdIAD9745sCWWegSBYZf7C/gTXVtmBxJ30NnuI+Cg0otaTHA
DPJZ26mBCNijYvpVGqgcSkXRdQQMiBGo6TLmsdpXxn4NFuh3IoRS+8gMgEFxpQdK
aAsHnRBTbfaeYpuNR2P5IJVc1L89rg3DkLWMw3ybSO5WzAcjg4yDiasCsGNHq/T4
e9t+V7/+YA14UOMAHfsAnD/B7UI/7B0ealDbepr/cq1NdJ1F0G7JoCS0yAExRumv
3KBznE29YMZTXCqJg6DNQqkV1xmuB2l2/eAZrM/pHTHGWBQk27WI/KsmqISt9Vb+
vmowDuJQNwZG784KSmbRcjSnuNTIltUybhgF/r+m3dNq4j+H/SroBIi5xI+5HJR+
m7G0tjQkpI3Hie3kf9Egwj09goMZ5ka8tIETMqgJFa2AZ3VpnBekxXGe1OtFgfeo
3nOCnYNNADUSIFUmGmAUusPlgFyMGoWvTHs+koYN8cS+q+X9WJgI3mihnMuiVIux
jG2W7IDCimiss/g0Bnol7M7FdL4QMVeg9/LX5wIl2G1b9Nz4ZDCSI/ooHL+xMFrm
H1wwBF9/xjpc0J6RWimkSvFa4iRCti4Ac8w41l+APwEtH2mWdrefTaadV0JXH/wh
brJGtCQhTrCLGuyLluPx
=xaoW
-END PGP SIGNATURE-
>From 355eac426aea2e1f98b99a41707b37e9ba3ef02b Mon Sep 17 00:00:00 2001
From: Hannes Reinecke
Date: Tue, 4 Nov 2014 08:06:03 +0100
Subject: [PATCH] scsi: Fixup compilation warning when SCSI_CONSTANTS is not
set
ARRAY_SIZE() requires the array to actually have a size.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/constants.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index b3cbf3a..a1a7fca 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -267,7 +267,7 @@ static struct sa_name_list sa_names_arr[] = {
};
#else /* ifndef CONFIG_SCSI_CONSTANTS */
-static const char *cdb_byte0_names[];
+static const char *cdb_byte0_names[0];
static struct sa_name_list sa_names_arr[] = {
{VARIABLE_LENGTH_CMD, NULL, 0},
--
1.8.5.2
Re: [PATCH v5 4/6] ARM: mediatek: Add sysirq interrupt polarity support
On Wed, 2014-10-29 at 18:00 +0800, Yingjoe Chen wrote:
> diff --git a/drivers/irqchip/irq-mtk-sysirq.c
> b/drivers/irqchip/irq-mtk-sysirq.c
> new file mode 100644
> index 000..4403bcf
> --- /dev/null
> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> +static int mtk_sysirq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> +unsigned int nr_irqs, void *arg)
> +{
> + int i, ret;
> + irq_hw_number_t hwirq;
> + struct of_phandle_args *irq_data = arg;
> +
> + if (irq_data->args_count < 3)
> + return -EINVAL;
> +
> + hwirq = irq_data->args[1];
> + for (i = 0; i < nr_irqs; i++)
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> + _sysirq_chip,
> + domain->host_data);
> +
> + return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> +}
(answering my own patch)
The ret is not used in this function. I'll remove it in next version.
Besides this, is there anything that should be changed in this series?
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] Add ltc3562 voltage regulator driver
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
Signed-off-by: Mike Looijmans
---
v3: Add .of_match_table and prefix lltc
Clarify why regmap cannot be used
Add lltc,operating-mode (0..3) DT property
regulator child nodes are optional
.../devicetree/bindings/regulator/ltc3562.txt | 57
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/ltc3562.c| 337
4 files changed, 402 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/ltc3562.txt
create mode 100644 drivers/regulator/ltc3562.c
diff --git a/Documentation/devicetree/bindings/regulator/ltc3562.txt
b/Documentation/devicetree/bindings/regulator/ltc3562.txt
new file mode 100644
index 000..d73c865
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3562.txt
@@ -0,0 +1,57 @@
+Linear Technology LTC3562 I2C controlled 4-output regulator
+
+Required properties:
+- compatible: "lltc,ltc3562"
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains optional regulator child nodes R400B, R600B, R400A
+ and R600A specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for R400A and R600A additionally need to specify the resistor values of
+their external feedback voltage dividers:
+
+Required properties (A-type only):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+ values R1 and R2 of the feedback voltage divider. Both values must remain in
+ the range 1..1000, only their quotient matters.
+
+Optional properties:
+- lltc,operating-mode: Operating mode as specified in table 3 of the datasheet.
+ This value is passed as the lower two bits of the first data byte, and sets
+ the operating mode: 0=Pulse-skip (default), 1=LDO, 2=Forced-burst, 3=Burst.
+
+Example:
+
+ ltc3562: ltc3562@65 {
+ compatible = "ltc3562";
+ reg = <0x65>;
+ regulators {
+ R400B_reg: R400B {
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R600B_reg: R600B {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R400A_reg: R400A {
+ regulator-min-microvolt = <425000>;
+ regulator-max-microvolt = <800>;
+ lltc,fb-voltage-divider = <1, 1>;
+ };
+ R600A_reg: R600A {
+ regulator-min-microvolt = <425000>;
+ regulator-max-microvolt = <180>;
+ lltc,fb-voltage-divider = <316, 100>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 55d7b7b..4012601 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -300,6 +300,13 @@ config REGULATOR_LP8788
help
This driver supports LP8788 voltage regulator chip.
+config REGULATOR_LTC3562
+ tristate "LCT3562 quad output voltage regulator"
+ depends on I2C
+ help
+ This enables support for the LCT3562 quad output voltage regulator
+ controlled via I2C.
+
config REGULATOR_LTC3589
tristate "LTC3589 8-output voltage regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1029ed3..9a15146 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
+obj-$(CONFIG_REGULATOR_LTC3562) += ltc3562.o
obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
obj-$(CONFIG_REGULATOR_MAX14577) += max14577.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
diff --git a/drivers/regulator/ltc3562.c b/drivers/regulator/ltc3562.c
new file mode 100644
index 000..69963f8
--- /dev/null
+++ b/drivers/regulator/ltc3562.c
@@ -0,0 +1,337 @@
+/*
+ * Regulator driver for Linear Technology LTC3562
+ *
+ * Copyright (C) 2014 Topic Embedded Products
+ *
+ * This program is free software; you can
[GIT PULL] platform-drivers-x86 for 3.18-2
Hi Linus, A short list of patches applying quirks and new DMI matches. These pass my basic build tests and have spent 4 days in linux-next. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.18-2 for you to fetch changes up to 725c7f619e20f5051bba627fca11dc107c2a93b1: quirk for Lenovo Yoga 3: no rfkill switch (2014-10-27 21:45:13 -0700) platform-drivers-x86 for 3.18-2 Quirks and DMI match additions. Aaron Lu (1): toshiba_acpi: Add Toshiba TECRA A50-A to the alt keymap dmi list Hans de Goede (2): samsung-laptop: Add broken-acpi-video quirk for NC210/NC110 acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80 Stanislaw Gruszka (1): asus-nb-wmi: Add wapf4 quirk for the X550VB Stephan Mueller (1): quirk for Lenovo Yoga 3: no rfkill switch drivers/platform/x86/acer-wmi.c | 11 +++ drivers/platform/x86/asus-nb-wmi.c| 9 + drivers/platform/x86/ideapad-laptop.c | 7 +++ drivers/platform/x86/samsung-laptop.c | 10 ++ drivers/platform/x86/toshiba_acpi.c | 6 ++ 5 files changed, 43 insertions(+) -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 4
Hi all, Changes since 20141103: The mfd tree gained a build failure for which I reverted a commit. The scsi tree lost its build failure, but gained another so I used the version from next-20141031. Non-merge commits (relative to Linus' tree): 3170 2579 files changed, 83652 insertions(+), 106096 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 227 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f4ca536f71ad Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem fast path in kmap_atomic_pfn()) Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/fixes (10ccaf178b2b powerpc: use device_online/offline() instead of cpu_up/down()) Merging sparc/master (7da89a2a3776 sparc64: Fix crashes in schizo_pcierr_intr_other().) Merging net/master (9fd3d3a43072 sfc: don't BUG_ON efx->max_channels == 0 in probe) Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes') Merging sound-current/for-linus (1df8874bfab1 ALSA: hda/realtek - Update Initial AMP for EAPD control) Merging pci-current/for-linus (d8e7d53a2fc1 PCI: Rename sysfs 'enabled' file back to 'enable') Merging wireless/master (75a916e1944f rtlwifi: rtl8192se: Fix firmware loading) Merging driver-core.current/driver-core-linus (0df1f2487d2f Linux 3.18-rc3) Merging tty.current/tty-linus (0df1f2487d2f Linux 3.18-rc3) Merging usb.current/usb-linus (0df1f2487d2f Linux 3.18-rc3) Merging usb-gadget-fixes/fixes (9599815de61d usb: dwc2: gadget: fix enumeration issues) Merging usb-serial-fixes/usb-linus (e681286de221 USB: opticon: fix non-atomic allocation in write path) Merging staging.current/staging-linus (0df1f2487d2f Linux 3.18-rc3) Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3) Merging input-current/for-linus (e55a3366984c Revert "Input: i8042 - disable active multiplexing by default") Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (09adc8789c4e crypto: qat - Enforce valid numa configuration) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL dereference in selftest removal code) Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to remove the device) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging kselftest-fixes/fixes (0df1f2487d2f Linux 3.18-rc3) Merging drm-intel-fixes/for-linux-next-fixes (0df1f2487d2f Linux 3.18-rc3) Merging asm-generic/master (f3670394c29f Revert "x86/efi: Fixup GOT in all boot code paths") Merging
Re: [PATCH 10/10] mm/hugetlb: share the i_mmap_rwsem
On Thu, 30 Oct 2014, Davidlohr Bueso wrote:
> The i_mmap_rwsem protects shared pages against races
> when doing the sharing and unsharing, ultimately
> calling huge_pmd_share/unshare() for PMD pages --
> it also needs it to avoid races when populating the pud
> for pmd allocation when looking for a shareable pmd page
> for hugetlb. Ultimately the interval tree remains intact.
>
> Signed-off-by: Davidlohr Bueso
> Acked-by: Kirill A. Shutemov
linux.intel.com
I'm uncomfortable with this one: I'm certainly not prepared to Ack it;
but that could easily be that I'm just not thinking hard enough - I'd
rather leave the heavy thinking to someone else!
The fs/hugetlbfs/inode.c part of it should be okay, but the rest is
iffy. It gets into huge page table sharing territory, which is very
tricky and surprising territory indeed (take a look at my
__unmap_hugepage_range_final() comment, for one example).
You're right that the interval tree remains intact, but I've a feeling
we end up using i_mmap_mutex for more exclusion than just that (rather
like how huge_memory.c finds anon_vma lock useful for other exclusions).
I think Mel (already Cc'ed) and Michal (adding him) both have past
experience with the shared page table (as do I, but I'm in denial).
I wonder if the huge shared page table would be a good next target
for Kirill's removal of mm nastiness. (Removing it wouldn't hurt
Google for one: we have it "#if 0"ed out, though I forget why at
this moment.)
But, returning to the fs/hugetlbfs/inode.c part of it, that reminds
me: you're missing one patch from the series, aren't you? Why no
i_mmap_lock_read() in mm/memory.c unmap_mapping_range()? I doubt
it will add much useful parallelism, but it would be correct.
Hugh
> ---
> fs/hugetlbfs/inode.c | 4 ++--
> mm/hugetlb.c | 12 ++--
> mm/memory.c | 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 5eba47f..0dca54d 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -412,10 +412,10 @@ static int hugetlb_vmtruncate(struct inode *inode,
> loff_t offset)
> pgoff = offset >> PAGE_SHIFT;
>
> i_size_write(inode, offset);
> - i_mmap_lock_write(mapping);
> + i_mmap_lock_read(mapping);
> if (!RB_EMPTY_ROOT(>i_mmap))
> hugetlb_vmtruncate_list(>i_mmap, pgoff);
> - i_mmap_unlock_write(mapping);
> + i_mmap_unlock_read(mapping);
> truncate_hugepages(inode, offset);
> return 0;
> }
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 2071cf4..80349f2 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2775,7 +2775,7 @@ static void unmap_ref_private(struct mm_struct *mm,
> struct vm_area_struct *vma,
>* this mapping should be shared between all the VMAs,
>* __unmap_hugepage_range() is called as the lock is already held
>*/
> - i_mmap_lock_write(mapping);
> + i_mmap_lock_read(mapping);
> vma_interval_tree_foreach(iter_vma, >i_mmap, pgoff, pgoff) {
> /* Do not unmap the current VMA */
> if (iter_vma == vma)
> @@ -2792,7 +2792,7 @@ static void unmap_ref_private(struct mm_struct *mm,
> struct vm_area_struct *vma,
> unmap_hugepage_range(iter_vma, address,
>address + huge_page_size(h), page);
> }
> - i_mmap_unlock_write(mapping);
> + i_mmap_unlock_read(mapping);
> }
>
> /*
> @@ -3350,7 +3350,7 @@ unsigned long hugetlb_change_protection(struct
> vm_area_struct *vma,
> flush_cache_range(vma, address, end);
>
> mmu_notifier_invalidate_range_start(mm, start, end);
> - i_mmap_lock_write(vma->vm_file->f_mapping);
> + i_mmap_lock_read(vma->vm_file->f_mapping);
> for (; address < end; address += huge_page_size(h)) {
> spinlock_t *ptl;
> ptep = huge_pte_offset(mm, address);
> @@ -3379,7 +3379,7 @@ unsigned long hugetlb_change_protection(struct
> vm_area_struct *vma,
>*/
> flush_tlb_range(vma, start, end);
> mmu_notifier_invalidate_range(mm, start, end);
> - i_mmap_unlock_write(vma->vm_file->f_mapping);
> + i_mmap_unlock_read(vma->vm_file->f_mapping);
> mmu_notifier_invalidate_range_end(mm, start, end);
>
> return pages << h->order;
> @@ -3547,7 +3547,7 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned
> long addr, pud_t *pud)
> if (!vma_shareable(vma, addr))
> return (pte_t *)pmd_alloc(mm, pud, addr);
>
> - i_mmap_lock_write(mapping);
> + i_mmap_lock_read(mapping);
> vma_interval_tree_foreach(svma, >i_mmap, idx, idx) {
> if (svma == vma)
> continue;
> @@ -3575,7 +3575,7 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned
> long addr, pud_t *pud)
> spin_unlock(ptl);
> out:
> pte = (pte_t *)pmd_alloc(mm, pud,
Re: [PATCH v3 2/3] perf: Userspace event
Hi Pawel,
On Tue, 4 Nov 2014 00:28:37 +, Pawel Moll wrote:
> + /*
> + * Data in userspace event record is transparent for the kernel
> + *
> + * Userspace perf tool code maintains a list of known types with
> + * reference implementations of parsers for the data field.
> + *
> + * Overall size of the record (including type and size fields)
> + * is always aligned to 8 bytes by adding padding after the data.
> + *
> + * struct {
> + * struct perf_event_headerheader;
> + * u32 type;
> + * u32 size;
The struct perf_event_header also has 'size' field and it has the entire
length of the record so it's redundant. Also there's 'misc' field in the
perf_event_header and I guess it can be used as 'type' info as it's
mostly for cpumode and we are in user mode by definition.
Thanks,
Namhyung
> + * chardata[size];
> + * char__padding[-size & 7];
> + * struct sample_idsample_id;
> + * };
> + */
> + PERF_RECORD_UEVENT = 11,
> +
> PERF_RECORD_MAX,/* non-ABI */
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Mon, Nov 3, 2014 at 10:04 PM, Kweh, Hock Leong wrote: >> -Original Message- >> From: Andy Lutomirski [mailto:l...@amacapital.net] >> > >> > Andy, here's the steps to load a capsule. I don't have a problem with >> > this, it's userspace driven, no "autoloading" of files in /lib/, and >> > works with sysfs. >> > >> > Have any objection to it, I don't. > > Thanks Greg for helping me on the explanation. I would like to apologize if > my cover letter/commit messages did misleading. > >> >> After reading the code, I still have objections. >> >> The full workflow seems to be, from the user's POV: >> >> 1. load the module >> >> 2. hope that there isn't a file called /lib/firmware/efi-capsule-file >> >> 3. echo 1 >.../loading >> >> 4. cat firmware >.../data >> >> 5. echo 0 >.../loading >> >> 6. efi_update_capsule gets called. The return value ends up in the kernel >> logs somewhere but doesn't seem to make it to userspace. >> >> 7. reboot(), but only if the capsule you loaded requires a reboot, which may >> or may not be detectable without the kernel's help (I'm not sure about this >> point). >> >> If you want to load a second capsule (which seems like a reasonable thing to >> do if the first capsule was the kind that is processed immediately), then >> rmmod -f the module and start over? > > You no need to do rmmod in order to upload the 2nd capsule binary. You just > need to > do the 3 steps as you mentioned in your 3, 4 and 5 for your 2nd or 3rd > capsule binaries. > Then the last, you do the reboot. OK. I missed that you request firmware again after each request finishes. > >> >> This seems like an unpleasant interface. I think that ioctl or a dedicated >> custom sysfs file would be considerably nicer. It would allow you to upload >> a >> capsule and get an indication of success or failure all at once, and it lets >> you >> load more than one capsule. >> Also, it gets rid of some of the really weird module refcounting stuff that's >> going on -- the only unusual thing the module would do would be to pin itself >> once a reboot-requiring capsule is loaded. >> >> --Andy >> > > Regarding the synchronization, it is only required for module unload. The > code is designed > in such a way that allow to be built as a kernel module or built into the > kernel. If you choose > the built in kernel method, you won't come into the module unload situation > which require > the synchronization. > It seems like a large fraction of the code in this module exists just to work around the fact that request_firmware doesn't do what you want it to do. You have code to: - Prevent the /lib/firmware mechanism from working. - Avoid a deadlock by doing strange things in the unload code. - Allow more than one capsule per module load. (Isn't this hard to use? User code will have to wait for the next firmware request before sending a second capsule.) All of this is for dubious gain. You have to do three separate opens in sysfs to upload a capsule, and there's no way to report back to userspace whether the EFI call worked and whether a reboot is needed. What's the benefit of using the firmware interface here? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] ARM: mvebu: add Device Tree description of USB cluster controller on Armada 375
On Friday 24 October 2014 08:54 PM, Gregory CLEMENT wrote:
> On Armada 375, the USB cluster allows to control the cluster composed
> of the USB2 and USB3 host controllers.
>
> Signed-off-by: Gregory CLEMENT
Acked-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/armada-375.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi
> b/arch/arm/boot/dts/armada-375.dtsi
> index de6571445cef..8f45cf5d2a50 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -342,6 +342,12 @@
> #clock-cells = <1>;
> };
>
> + usbcluster: usb-cluster@18400 {
> + compatible = "marvell,armada-375-usb-cluster";
> + reg = <0x18400 0x4>;
> + #phy-cells = <1>;
> + };
> +
> mbusc: mbus-controller@2 {
> compatible = "marvell,mbus-controller";
> reg = <0x2 0x100>, <0x20180 0x20>;
>
--
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-sunxi] [PATCH 3/6] phy: Add driver to support individual USB PHYs on sun9i
On Tue, 2014-11-04 at 12:07 +0800, Chen-Yu Tsai wrote:
> Unlike previous Allwinner SoCs, there is no central PHY control block
> on the A80. Also, OTG support is completely split off into a
> different
> controller.
>
> This adds a new driver to support the regular USB PHYs.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> .../devicetree/bindings/phy/sun9i-usb-phy.txt | 34 +++
> drivers/phy/Kconfig| 12 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-sun9i-usb.c| 227
> +
> 4 files changed, 274 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/sun9i-usb-
> phy.txt
> create mode 100644 drivers/phy/phy-sun9i-usb.c
>
> diff --git a/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
> b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
> new file mode 100644
> index 000..27a6067
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
> @@ -0,0 +1,34 @@
> +Allwinner sun9i USB PHY
> +---
> +
> +Required properties:
> +- compatible : should be one of
> + * allwinner,sun9i-a80-usb-phy
> +- reg : a list of offset + length pairs
> +- #phy-cells : from the generic phy bindings, must be 0
> +- clocks : phandle + clock specifier for the phy clocks
> +- clock-names :
> + * "phy" for normal USB
> + * "hsic_480M", "hsic_12M" for HSIC
> +- resets : a list of phandle + reset specifier pairs
> +- reset-names :
> + * "phy" for normal USB
> + * "hsic" for HSIC
> +- phy_type : "hsic" for HSIC usage;
> + other values or
> absence of this property indicates normal USB
> +
> +It is recommended to list all clocks and resets available.
> +The driver will only use those matching the phy_type.
> +
> +Example:
> + usbphy1: phy@00a01800 {
> + compatible = "allwinner,sun9i-a80-usb-phy";
> + reg = <0x00a01800 0x4>;
> + clocks = <_phy_clk 2>, <_phy_clk 10>,
> +
><_phy_clk 3>;
> + clock-names = "hsic_480M", "hsic_12M", "phy";
> + resets = <_phy_clk 18>, <_phy_clk 19>;
> + reset-names = "hsic", "phy";
> + status = "disabled";
> + #phy-cells = <0>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 2a436e6..f5b7fbb 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -153,6 +153,18 @@ config PHY_SUN4I_USB
> This driver controls the entire USB PHY
> block, both the USB OTG
> parts, as well as the 2 regular USB 2 host
> PHYs.
>
> +config PHY_SUN9I_USB
> + tristate "Allwinner sun9i SoC USB PHY driver"
Adding 'A80' to the user visible data makes things a bit easier for
end users:
"AllWinner sun9i (A80) SoC USB PHY driver"
> + depends on ARCH_SUNXI && HAS_IOMEM && OF
> + depends on RESET_CONTROLLER
> + select USB_PHY
> + select GENERIC_PHY
> + help
> + Enable this to support the transceiver that
> is part of Allwinner
> + sun9i SoCs.
And extra 'A80' here wouldn't hurt either.
> +
> + This driver controls each individual USB 2
> host PHY.
> +
> config PHY_SAMSUNG_USB2
> tristate "Samsung USB 2.0 PHY driver"
> depends on HAS_IOMEM
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index c4590fc..c3977dc 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_TWL4030_USB) += phy-
> twl4030-usb.o
> obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
> obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
> obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
> +obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
> phy-exynos-usb2-y += phy-samsung-usb2.o
> phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-
> usb2.o
> diff --git a/drivers/phy/phy-sun9i-usb.c b/drivers/phy/phy-sun9i-
> usb.c
> new file mode 100644
> index 000..f9085d9
> --- /dev/null
> +++ b/drivers/phy/phy-sun9i-usb.c
> @@ -0,0 +1,227 @@
> +/*
> + * Allwinner sun9i USB phy driver
> + *
> + * Copyright (C) 2014 Chen-Yu Tsai
> + *
> + * Based on phy-sun9i.c from
> + * Hans de Goede
> + *
> + * and code from
> + * Allwinner Technology Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even
Re: [PATCH] toshiba_acpi: Fix regression caused by backlight extra check code
On Mon, Nov 03, 2014 at 08:58:34PM -0700, Azael Avalos wrote:
> Bug 86521 uncovered that some TOS6208 devices also return
> non zero values on a write call to the backlight method,
> thus getting caught and bailed out by the extra check code.
>
> This patch makes sure that the extra check is being done
> on a TOS1900 device and then make the check for the broken
> backlight code.
>
> Signed-off-by: Azael Avalos
> ---
> drivers/platform/x86/toshiba_acpi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/toshiba_acpi.c
> b/drivers/platform/x86/toshiba_acpi.c
> index ef3a190..e3fed12 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -944,9 +944,13 @@ static int set_lcd_brightness(struct toshiba_acpi_dev
> *dev, int value)
> /* Extra check for "incomplete" backlight method, where the AML code
>* doesn't check for HCI_SET or HCI_GET and returns TOS_SUCCESS,
>* the actual brightness, and in some cases the max brightness.
> + * Use the SPFC method as an indicator that we're on a TOS1900 device,
> + * otherwise some TOS6208 devices might get bailed out, see bug 86521
This needs a clearer description here in this comment, rather than redirecting
the reader to a bug report (which may or may not exist when needed).
>*/
> - if (out[2] > 0 || out[3] == 0xE000)
> - return -ENODEV;
> + if (acpi_has_method(dev->acpi_dev->handle, "SPFC")) {
Hrm, this checking for the existence of a specific method seems suspect to me.
We would know if we are on a TOS1900 as we matches the acpi id already. Is the
SPFC significant here, or is it just a "we only see SPFC on TOS1900 so it's a
convenient test"? If the latter, it seems rather fragile and prone to other
breakage to me.
Rafael, any recommendations here?
> + if (out[2] > 0 || out[3] == 0xE000)
> + return -ENODEV;
> + }
>
> return out[0] == TOS_SUCCESS ? 0 : -EIO;
> }
> --
> 2.1.1
>
>
--
Darren Hart
Intel Open Source Technology Center
--
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] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
From: Oussama Ghorbel
The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.
Signed-off-by: Oussama Ghorbel
Tested-by: Rabin Vincent
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-omap-usb2.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 8c84298..f091576 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -258,14 +258,16 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->phy= >phy;
platform_set_drvdata(pdev, phy);
+ pm_runtime_enable(phy->dev);
generic_phy = devm_phy_create(phy->dev, NULL, , NULL);
- if (IS_ERR(generic_phy))
+ if (IS_ERR(generic_phy)) {
+ pm_runtime_disable(phy->dev);
return PTR_ERR(generic_phy);
+ }
phy_set_drvdata(generic_phy, phy);
- pm_runtime_enable(phy->dev);
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
if (IS_ERR(phy_provider)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] extcon: gpio: add DT support
Hi Felipe et al. Another series was posted by removing the platform support. https://lkml.org/lkml/2014/10/14/244 I guess I forgot to copy linux-omap. On 11/03/2014 10:02 PM, Felipe Balbi wrote: Hi, this series has been tested with v3.18-rc2 with a yet-to-be-released board (called X15). That board is DT-only and we use extcon-gpio to decide which USB mode should be used (host or peripheral). George Cherian (4): extcon: gpio: Convert the driver to use gpio desc API's extcon: gpio: Add dt support for the driver. extcon: gpio: Always use gpio_get_value_cansleep extcon: gpio: Add support for using cable names .../devicetree/bindings/extcon/extcon-gpio.txt | 23 ++ drivers/extcon/extcon-gpio.c | 93 ++ 2 files changed, 84 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 3/3] efi: Capsule update with user helper interface
> -Original Message- > From: Andy Lutomirski [mailto:l...@amacapital.net] > > > > Andy, here's the steps to load a capsule. I don't have a problem with > > this, it's userspace driven, no "autoloading" of files in /lib/, and > > works with sysfs. > > > > Have any objection to it, I don't. Thanks Greg for helping me on the explanation. I would like to apologize if my cover letter/commit messages did misleading. > > After reading the code, I still have objections. > > The full workflow seems to be, from the user's POV: > > 1. load the module > > 2. hope that there isn't a file called /lib/firmware/efi-capsule-file > > 3. echo 1 >.../loading > > 4. cat firmware >.../data > > 5. echo 0 >.../loading > > 6. efi_update_capsule gets called. The return value ends up in the kernel > logs somewhere but doesn't seem to make it to userspace. > > 7. reboot(), but only if the capsule you loaded requires a reboot, which may > or may not be detectable without the kernel's help (I'm not sure about this > point). > > If you want to load a second capsule (which seems like a reasonable thing to > do if the first capsule was the kind that is processed immediately), then > rmmod -f the module and start over? You no need to do rmmod in order to upload the 2nd capsule binary. You just need to do the 3 steps as you mentioned in your 3, 4 and 5 for your 2nd or 3rd capsule binaries. Then the last, you do the reboot. > > This seems like an unpleasant interface. I think that ioctl or a dedicated > custom sysfs file would be considerably nicer. It would allow you to upload a > capsule and get an indication of success or failure all at once, and it lets > you > load more than one capsule. > Also, it gets rid of some of the really weird module refcounting stuff that's > going on -- the only unusual thing the module would do would be to pin itself > once a reboot-requiring capsule is loaded. > > --Andy > Regarding the synchronization, it is only required for module unload. The code is designed in such a way that allow to be built as a kernel module or built into the kernel. If you choose the built in kernel method, you won't come into the module unload situation which require the synchronization. Regards, Wilson
Re: [PATCH 08/10] mm/mremap: share the i_mmap_rwsem
I'm glad to see this series back, and nicely presented: thank you.
Not worth respinning them, but consider 1,2,3,4,5,6,7 and 9 as
Acked-by: Hugh Dickins
On Thu, 30 Oct 2014, Davidlohr Bueso wrote:
> As per the comment in move_ptes(), we only require taking the
> anon vma and i_mmap locks to ensure that rmap will always observe
> either the old or new ptes, in the case of need_rmap_lock=true.
> No modifications to the tree itself, thus share the i_mmap_rwsem.
>
> Signed-off-by: Davidlohr Bueso
> Acked-by: Kirill A. Shutemov
But this one is Nacked by me. I don't understand how you and Kirill
could read Michel's painstaking comment on need_rmap_locks, then go
go ahead and remove the exclusion of rmap_walk().
I agree the code here does not modify the interval tree, but the
comment explains how we're moving a pte from one place in the tree
to another, and in some cases there's a danger that the rmap walk
might miss the pte from both places (which doesn't matter much to
most of its uses, but is critical in page migration).
Or am I the one missing something?
Hugh
> ---
> mm/mremap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index c929324..09bd644 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -119,7 +119,7 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
> *old_pmd,
> if (need_rmap_locks) {
> if (vma->vm_file) {
> mapping = vma->vm_file->f_mapping;
> - i_mmap_lock_write(mapping);
> + i_mmap_lock_read(mapping);
> }
> if (vma->anon_vma) {
> anon_vma = vma->anon_vma;
> @@ -156,7 +156,7 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t
> *old_pmd,
> if (anon_vma)
> anon_vma_unlock_read(anon_vma);
> if (mapping)
> - i_mmap_unlock_write(mapping);
> + i_mmap_unlock_read(mapping);
> }
>
> #define LATENCY_LIMIT(64 * PAGE_SIZE)
> --
> 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 v2] eeepc-laptop: clean up control flow in eeepc_acpi_notify
On Sun, Nov 02, 2014 at 10:14:58PM +0100, Frans Klaver wrote: > eeepc_acpi_notify increases the indentation level to a whopping four. If > we revise the conditions a bit, we can reduce that to a more soothing > two and satisfy the indentation guidelines in Documentation/CodingStyle. > > Remove an unwanted space while we're in the neighbourhood. > > Signed-off-by: Frans Klaver Applied, thanks. Look for this in my 3.19 pull requests along with the other cleanups. -- Darren Hart Intel Open Source Technology Center -- 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 0/4 v2] ftracetests: Add ftrace tests to ftracetests
(2014/11/04 6:27), Steven Rostedt wrote: > Second attempt. I took the advice from Masami Hiramatsu and modified > my tests. I also added some helper functions to ftracetests as well. > > I split the one function graph test into two. One to just test the > filtering of the function graph and another to test with stack tracer. This series looks good to me :) Acked-by: Masami Hiramatsu for this series. Thank you! > > Steven Rostedt (Red Hat) (4): > ftracetest: Add clear_trace() helper to reset the trace file > ftracetest: Add disable/enable_tracing() helper calls > ftracetest: Add helper reset_tracer() function > ftracetest: Add a couple of ftrace test cases > > > tools/testing/selftests/ftrace/ftracetest | 3 + > .../ftrace/test.d/ftrace/fgraph-filter-stack.tc| 94 > ++ > .../ftrace/test.d/ftrace/fgraph-filter.tc | 49 +++ > .../ftrace/test.d/ftrace/func_profiler.tc | 76 + > tools/testing/selftests/ftrace/test.d/functions| 16 > 5 files changed, 238 insertions(+) > > > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] platform: hp_accel: add a i8042 filter to remove HPQ6000 data from kb bus stream
On Sun, Nov 02, 2014 at 11:19:30PM +0100, Éric Piel wrote: > On 30-10-14 17:57, Giedrius Statkevicius wrote: > >Add a i8042 filter to hp_accel to remove accelerometer's data with acpi > >id HPQ6000 from keyboard bus stream. The codes sent by accelerometer are > >e0 25, e0 26, e0 27 and e0 28. The relevant information is already > >passed through /dev/freefall so no need to send these undocumented weird > >signals through the keyboard bus. Also, unclogs `dmesg` because atkbd > >complained about weird scan codes, saves processing power and disk > >space. > > > >Signed-off-by: Giedrius Statkevičius > >Acked-by: Dmitry Torokhov > Hi, > Looks fine with respect to the hp accel driver. If Dmitry thinks the > behaviour is fine then I've got nothing more to say :-) > > Reviewed-by: Éric Piel > > Darren, could you pick up this patch in your tree? Yes, applied. It will make my 3.18-3 series to Linus by the end of the week, I want it to spend a few days in next first. > > Cheers, > Éric > > > >--- > >Changes in v2: > >* Remove a unnecessary deletion of a blank line > >* Move #includes of i8042.h and serio.h before the relative path > > includes. > > > >First of all, any Tested-Bys are very welcome by people who also have a > >accelerometer with acpi id HPQ6000. If it happens with HPQ6007 too we > >can easily modify this to install the filter when HPQ6007 is detected. > >For the time being the filter is only installed when HPQ6000 is > >detected. > > > >Now moving to what was changed since the RFC. I reworked the filter > >function to hopefully make it more clear what it is doing. Since the > >codes sent by the accelerometer are extended then we need to filter all > >of 0xe0's and then send one 0xe0 back when the actual key isn't in the > >range of 0x25-0x28. Also, I've removed the check for errors for > >i8042_install_filter() because it's unnecessary to check if it failed. > >If multiple HPQ6000's are in the system then no issue occurs even if > >multiple i8042_install_filter() are issued because this is handled by > >i8042 and it's smart enough not to install the same filter two or more > >times. > > > >This fixes https://bugzilla.kernel.org/show_bug.cgi?id=84941. > : > -- Darren Hart Intel Open Source Technology Center -- 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: [0/3] net: Kill skb_copy_datagram_const_iovec
On Mon, Nov 03, 2014 at 03:05:53PM -0500, David Miller wrote:
> I'll see if I can make some progress converting the networking over
> to iov_iter. It can't be that difficult... albeit perhaps a little
> time consuming.
FWIW, I have a queue that got started back in April; basically, the plan
of attack was
* separate kernel-side and userland msghdr.
* localize ->msg_iov uses - most of that gets taken care of by
several new helpers, as in
new helper: skb_copy_datagram_msg()
Absolute majority of skb_copy_datagram_iovec() callers (49 out of 56)
are passing it msg->msg_iov as iovec. Provide a trivial wrapper that
takes msg as argument instead of iovec.
and several like that (the numbers in the above are probably incorrect these
days - it was done more than half a year ago).
* switch kernel-side msghdr to iov_iter. That means diverging
layouts; it's really not hard, since we have copying of msghdr from
userland already localized. Initially - just a mechanical conversion
(i.e. direct uses of iov_iter fields instead of ->msg_iov/->msg_iovlen;
note that after the introduction of wrappers the number of such places
is very much reduced).
* start converting those relatively few places to iov_iter primitives.
And that's where it got stalled, since we have to deal with expectations
of callers. Syscall ones are trivial; that's not a problem. Unfortunately,
there are kernel_{send,recv}msg() users, and those do care about the state the
iovec is left in. Strictly speaking, the state of iovec after e.g.
->sendmsg() is undefined. And it's not just protocol-dependent - unless
I'm seriously misreading it, tcp_sendmsg() ends up modifying iovec in case
when it hits tcp_send_rcvq(), while in the normal case it leaves iovec
unmodified. So in general you need to feed ->{send,recv}msg() a throwaway copy
of iovec. Leads to wonders like
/* NB we can't trust socket ops to either consume our iovs
* or leave them alone. */
LASSERT (niov > 0);
for (nob = i = 0; i < niov; i++) {
scratchiov[i] = iov[i];
nob += scratchiov[i].iov_len;
}
LASSERT (nob <= conn->ksnc_rx_nob_wanted);
rc = kernel_recvmsg(conn->ksnc_sock, ,
(struct kvec *)scratchiov, niov, nob, MSG_DONTWAIT);
etc. However, there are places that don't bother and do this:
while (total_rx < data) {
rx_loop = kernel_recvmsg(conn->sock, , iov_p, iov_len,
(data - total_rx), MSG_WAITALL);
if (rx_loop <= 0) {
pr_debug("rx_loop: %d total_rx: %d\n",
rx_loop, total_rx);
return rx_loop;
}
total_rx += rx_loop;
pr_debug("rx_loop: %d, total_rx: %d, data: %d\n",
rx_loop, total_rx, data);
}
(that's iscsit_do_rx_data()). Maybe it's a bug; maybe it's relying on
specific behaviour of the protocol known to be used - this code clearly
expects recvmsg to advance iovec, which seems to depend only on the
protocol. At the moment. In any case, it's very brittle...
Hell knows; I hadn't finished digging through that zoo - got sidetracked back
then. *IF* all such places either use a throwaway copy or assume that iovec
gets modified, we can do the following: switch the access to iovecs to
iov_iter primitives, with the first kind of callers creating a throwaway
iov_iter and the second just feeding the same iov_iter to e.g.
kernel_recvmsg(). iovec will remain constant, iov_iter will be advanced.
Moreover, in a lot of cases of first kind will be able to get rid of
throwaway iov_iter (and of manually advancing it), effectively converting
to the second one.
If we have places that currently rely on iovec remaining unchanged (i.e.
manually advancing it after kernel_{send,recv}msg()), the series will be
more painful ;-/ I very much hope that no such places exist...
FWIW, there is also a tactical question that needs to be dealt with. We
can, of course, start with renaming the "kernel-side" (i.e. post
copy_msghdr_from_user()/get_compat_msghdr()) to struct kmsghdr. OTOH,
that's a _lot_ of churn for very little reason - most of the instances
in the tree are of that kind. So I did it the other way round - introduced
struct user_msghdr (only in linux/socket.h; note that we do *not* have
struct msghdr in uabi/linux/socket.h, or anywhere else in uabi/*),
made the syscalls take pointers to it and (initially) rely upon the identical
layouts in copy_msghdr_from_user(); once we put iov_iter into kernel-side
msghdr, we'll just do it like get_compat_msghdr() does.
Is that acceptable? It would greatly reduce the amount of churn in net/* -
we don't need to pass iov_iter separately and most of the functions in
the middle of call chains are completely unchanged. Only the originators
of ->sendmsg()/->recvmsg()
Re: [RESUBMIT PATCH v6 7/8] regulator: sky81452: Add compatible string for device binding
On Tue, Nov 04, 2014 at 12:53:29AM +, Mark Brown wrote: > On Tue, Nov 04, 2014 at 09:43:34AM +0900, Gyungoh Yoo wrote: > > On Fri, Oct 31, 2014 at 04:44:18PM +, Mark Brown wrote: > > > > This doesn't apply against current code and depends on the MFD symbol > > > rename - can you please check what's going on here? > > > Are you talking about 'sky81452-regulator'? > > I am sorry I don't understand. Can you explain in more detail? > > No, I mean the Kconfig change. > > > > It would make sense to split the Kconfig symbol rename into a separate > > > patch to ease merging, it doesn't seem obviously related to the driver > > > change and should probably be in the same patch as the MFD symbol rename > > > for bisetion. > > > becuase the symbol in the modfied MFD does not match with the > > merged regulator driver, it was hard to split the patch. > > I'm having a hard time understanding why it is difficult to split the > two changes - they are in completely separate files. I am sorry for the hard time. That was because the symbol changes had a dependency with 1/8. In this case, Should Kconfig symbol change back from MFD_SKY81452 to SKY81452 in this patch series? And then should I submit to change to MFD_SKY81452 with seperate patch? -- 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: Re: [PATCH perf/core 0/6] perf-probe: Bugfix and add new options for cache
(2014/11/04 12:14), Namhyung Kim wrote: > Hi Masami, > > On Fri, 31 Oct 2014 14:51:29 -0400, Masami Hiramatsu wrote: >> Hi, >> >> Here is a sereis of patches for enabling "event cache" feature >> to perf probe. Brendan gives me this cool idea, thanks! :) >> >> In this series, I added following options/features; >> - --output option >>We can save the probe definition command for given probe-event >>instead of setting up the local tracing/kprobe_events. >> >> - --no-inlines option >>We can avoid searching the inline functions in debuginfo. Usually >>useful with wildcards since the wildcards will hit a huge amount >>of probe-points. >> >> - $params special probe argument >>$params is expanded to function parameters only, no locally defined >>variables. This is useful for function-call tracing. >> >> - wildcard support for function name >>Wildcard support is the key feature for this idea. Now we can use >>'*foo*' for function name to define the probe-point. >> >> So by using all of them, we can make an "event cache" file on all >> functions (except for inlined functions) as below. >> >> # perf probe --max-probes=10 --no-inlines -a '* $params' -o event.cache >> >> builds "event.cache" file in which event settings for >> all function entries, like below; >> >> p:probe/reset_early_page_tables _text+12980741 >> p:probe/copy_bootdata _text+12980830 real_mode_data=%di:u64 >> p:probe/exit_amd_microcode _text+14692680 >> p:probe/early_make_pgtable _text+12981274 address=%di:u64 >> p:probe/x86_64_start_reservations _text+12981700 real_mode_data=%di:u64 >> p:probe/x86_64_start_kernel _text+12981744 real_mode_data=%di:u64 >> p:probe/reserve_ebda_region _text+12982117 > > Does this event cache support kernel modules too? AFAIK it can have a > different address whenever loaded even on a same kernel. Yes, for the modules perf probe uses target function symbol directly instead of _text. perf probe -m xfs -o - -q -a xfs_acl_exists p:probe/xfs_acl_exists xfs:xfs_acl_exists+0 >> This event.cache file will be big (but much smaller than native >> debuginfo :) ) if your kernel have many option embedded. >> Anyway, you can compress it too. >> >> # wc -l event.cache >> 33813 event.cache >> # ls -sh event.cache >> 2.3M event.cache >> # ls -sh event.cache.gz >> 464K event.cache.gz >> >> For setting up a probe event, you can grep the function name >> and write it to tracing/kprobe_events, as below; >> >> # zcat event.cache.gz | \ >> grep probe/vfs_symlink > /sys/kernel/debug/tracing/kprobe_events >> >> This can be applied for the remote machine only if the machine >> runs on completely same kernel binary. Perhaps, we need some >> helper tool to check it. > > While it's useful for "agent-less" systems, I think we also need to have > a simple way to apply it with perf tools. Yeah, I see. As I've sent a reply to Arnaldo, I'd like to add --query for cached event definition by checking a build id. In that case, you just need to run perf-archive and send it to remote, then you can run perf-probe --query-set "event" on the machine. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/8] ARM: mediatek: add dts for 8127 Moose board
On Mon, 2014-11-03 at 18:55 +0100, Matthias Brugger wrote:
> 2014-10-22 12:29 GMT+02:00 Joe.C :
> > From: "Joe.C"
> >
> > Moose is a tablet evalutation board based on MT8127 SoC.
> >
> > Signed-off-by: Joe.C
> > ---
> > arch/arm/boot/dts/mt8127-moose.dts | 24
> > 1 file changed, 24 insertions(+)
> > create mode 100644 arch/arm/boot/dts/mt8127-moose.dts
> >
> > diff --git a/arch/arm/boot/dts/mt8127-moose.dts
> > b/arch/arm/boot/dts/mt8127-moose.dts
> > new file mode 100644
> > index 000..602e2f0
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mt8127-moose.dts
> > @@ -0,0 +1,24 @@
> > +/*
> > + * Copyright (c) 2014 MediaTek Inc.
> > + * Author: Joe.C
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This 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.
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8127.dtsi"
> > +
> > +/ {
> > + model = "mediatek,mt8127-moose", "mediatek,mt8127";
>
> The model should be a string that identifies the board, e.g. "Moose".
> Please add the compatible property.
Thanks for catching this. I just note we have warning on this line.
Will fix in next version.
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: alloc_contig_range: demote pages busy message from warn to info
Hello,
On Mon, Nov 03, 2014 at 05:57:53PM +0100, Michal Nazarewicz wrote:
> Having test_pages_isolated failure message as a warning confuses
> users into thinking that it is more serious than it really is. In
> reality, if called via CMA, allocation will be retried so a single
> test_pages_isolated failure does not prevent allocation from
> succeeding.
>
> Demote the warning message to an info message and reformat it such
> that the text “failed” does not appear and instead a less worrying
> “PFNS busy” is used.
What do you expect from this message? Please describe it so that we can
review below message helps your goal.
>
> Signed-off-by: Michal Nazarewicz
> ---
> mm/page_alloc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 372e3f3..e2731eb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6431,13 +6431,12 @@ int alloc_contig_range(unsigned long start, unsigned
> long end,
>
> /* Make sure the range is really isolated. */
> if (test_pages_isolated(outer_start, end, false)) {
> - pr_warn("alloc_contig_range test_pages_isolated(%lx, %lx)
> failed\n",
> -outer_start, end);
> + pr_info("%s: [%lx, %lx) PFNs busy\n",
> + __func__, outer_start, end);
> ret = -EBUSY;
> goto done;
> }
>
> -
> /* Grab isolated pages from freelists. */
> outer_end = isolate_freepages_range(, outer_start, end);
> if (!outer_end) {
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
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] perf tools: perf diff for different binaries
Hi kan, On Fri, 31 Oct 2014 05:06:12 -0700, kan liang wrote: > From: Kan Liang > > perf diff can display the differential profile between two perf.data > files. However, the perf.data files have to come from same binaries. > > The patch introduced a key "symbol_name" for --sort option, so the user > can compare the perf.data files from different binaries, even different > kernel version. If symbol_name is set, perf diff display the > differential profile of functions. > It could help the user quickly locate the scaling regression caused by > new binaries/kernels. > > Here is an example. I have two version of binaries. One is running on > kernel 3.16. The other is running on kernel 3.17. > > Using perf record, I got two perf.data files, v1_1_6perf.data (version > one in 3.16) and v2_1_7perf.data (version two in 3.17). > > If I run old perf diff with --sort dso,symbol, we cannot get any useful > information for the user space binary. Furthermore, it failed to compare > the kernel function. E.g. native_write_msr_safe. > > perf diff -s dso,symbol --compute ratio v1_1_6perf.data v2_1_7perf.data > > Event 'cycles' > > Baseline Ratio Shared Object Symbol > .. . > > > [kernel.kallsyms] [k] > __update_entity_load_avg_contrib > [kernel.kallsyms] [k] _raw_spin_lock > [kernel.kallsyms] [k] apic_timer_interrupt > [kernel.kallsyms] [k] hrtimer_interrupt > 0.01% [kernel.kallsyms] [k] native_write_msr_safe > [kernel.kallsyms] [k] native_write_msr_safe > 0.01% [kernel.kallsyms] [k] notifier_call_chain > 0.01% [kernel.kallsyms] [k] perf_event_task_tick > 0.01% [kernel.kallsyms] [k] run_posix_cpu_timers > 0.01% [kernel.kallsyms] [k] run_timer_softirq > 0.01% [kernel.kallsyms] [k] trigger_load_balance > 0.01% [kernel.kallsyms] [k] update_vsyscall > 0.05% [unknown] [.] 0x00400540 > 0.04% [unknown] [.] 0x00400541 > 0.03% [unknown] [.] 0x0040054b > 0.04% [unknown] [.] 0x00400552 > 33.55% [unknown] [.] 0x00400554 > 1.22% [unknown] [.] 0x0040055a > 8.00% [unknown] [.] 0x0040055e > 0.02% [unknown] [.] 0x00400562 > 8.41% [unknown] [.] 0x00400564 > 48.13% [unknown] [.] 0x0040056b > 0.16% [unknown] [.] 0x00400570 > 0.17% [unknown] [.] 0x00400571 > [unknown] [.] 0x00400580 > [unknown] [.] 0x00400581 > 0.01% [unknown] [.] 0x00400583 > 0.01% [unknown] [.] 0x00400588 > [unknown] [.] 0x0040058b > 0.01% 1240.990221 [unknown] [.] 0x0040058d > [unknown] [.] 0x00400590 > 0.06% [unknown] [.] 0x00400591 > [unknown] [.] 0x00400593 > 0.04% [unknown] [.] 0x00400595 > 0.01% 1240.603148 [unknown] [.] 0x00400597 > [unknown] [.] 0x0040059b > [unknown] [.] 0x0040059d > [unknown] [.] 0x004005a1 > [unknown] [.] 0x004005a5 > [unknown] [.] 0x004005a7 > [unknown] [.] 0x004005a8 > [unknown] [.] 0x004005aa > [unknown] [.] 0x004005ba > [unknown] [.] 0x004005bf > [unknown] [.] 0x004005c4 > [unknown] [.] 0x004005c9 > [unknown] [.] 0x004005ce > [unknown] [.] 0x004005d2 > [unknown] [.] 0x004005d6 > [unknown] [.] 0x004005d8 > [unknown] [.] 0x004005f5 > > With the key
linux-next: build failure after merge of the mfd tree
Hi all,
After merging the mfd tree, today's linux-next build (powerpc allyesconfig)
failed like this:
drivers/regulator/max77686.c:432:13: warning: 'struct max77686_platform_data'
declared inside parameter list
struct max77686_platform_data *pdata)
^
drivers/regulator/max77686.c:432:13: warning: its scope is only this definition
or declaration, which is probably not what you want
drivers/regulator/max77686.c: In function 'max77686_pmic_dt_parse_pdata':
drivers/regulator/max77686.c:447:7: error: dereferencing pointer to incomplete
type
pdata->num_regulators = ARRAY_SIZE(regulators);
^
drivers/regulator/max77686.c:448:42: error: dereferencing pointer to incomplete
type
rdata = devm_kzalloc(>dev, sizeof(*rdata) *
^
drivers/regulator/max77686.c:449:14: error: dereferencing pointer to incomplete
type
pdata->num_regulators, GFP_KERNEL);
^
drivers/regulator/max77686.c:455:23: error: dereferencing pointer to incomplete
type
for (i = 0; i < pdata->num_regulators; i++) {
^
drivers/regulator/max77686.c:460:3: error: invalid use of undefined type
'struct max77686_regulator_data'
rdata[i].initdata = rmatch.init_data;
^
drivers/regulator/max77686.c:460:8: error: dereferencing pointer to incomplete
type
rdata[i].initdata = rmatch.init_data;
^
drivers/regulator/max77686.c:461:3: error: invalid use of undefined type
'struct max77686_regulator_data'
rdata[i].of_node = rmatch.of_node;
^
drivers/regulator/max77686.c:461:8: error: dereferencing pointer to incomplete
type
rdata[i].of_node = rmatch.of_node;
^
drivers/regulator/max77686.c:464:7: error: dereferencing pointer to incomplete
type
pdata->regulators = rdata;
^
And so on ...
Caused by commit 9d5f4c2c748e ("mfd: max77686/802: Remove support for
board files") from the mfd tree.
I reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpY9szjVEzM8.pgp
Description: OpenPGP digital signature
[PATCH] sched/fair: fix use stale overloaded status to find busiest group
Commit caeb178c60f4 ("sched/fair: Make update_sd_pick_busiest() return
'true' on a busier sd") makes groups are ranked in the order overloaded >
imbalance > other and busiest group is picked according to this order.
sgs->group_capacity_factor is used to check if group is overloaded. In
the case of the child domain prefers tasks go to siblings first, the
sgs->group_capacity_factor will be set lower to one in order to move all
the excess tasks away. However, group overloaded status is not updated
in the case of sgs->group_capacity_factor be set lower to one which
leads to miss find the busiest group. This patch fix it by updating
group overloaded status in the case of sg capacity factor is set to
one in order to find busiest group accurately.
Signed-off-by: Wanpeng Li
---
kernel/sched/fair.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ec32c26d..c603e50 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6344,8 +6344,10 @@ static inline void update_sd_lb_stats(struct lb_env
*env, struct sd_lb_stats *sd
* with a large weight task outweighs the tasks on the system).
*/
if (prefer_sibling && sds->local &&
- sds->local_stat.group_has_free_capacity)
+ sds->local_stat.group_has_free_capacity) {
sgs->group_capacity_factor =
min(sgs->group_capacity_factor, 1U);
+ sgs->group_type = group_classify(sg, sgs);
+ }
if (update_sd_pick_busiest(env, sds, sg, sgs)) {
sds->busiest = sg;
--
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/
[PATCH v2 2/3] ARM: mediatek: Add I2C node for mt8135 and mt8127
Add I2C node to mt8135.dtsi and mt8127.dtsi
Signed-off-by: Xudong Chen
---
arch/arm/boot/dts/mt8127.dtsi | 27 +
arch/arm/boot/dts/mt8135.dtsi | 90 +++
2 files changed, 117 insertions(+)
diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index 25c9f69..60d7685e 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -89,5 +89,32 @@
<0 0x10214000 0 0x2000>,
<0 0x10216000 0 0x2000>;
};
+
+ i2c0: i2c@11007000 {
+ compatible = "mediatek,mt8127-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11007000 0 0x70>,
+ <0 0x11000200 0 0x80>;
+ interrupts = ;
+ mediatek,have-dcm;
+ };
+
+ i2c1: i2c@11008000 {
+ compatible = "mediatek,mt8127-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11008000 0 0x70>,
+ <0 0x11000280 0 0x80>;
+ interrupts = ;
+ mediatek,have-dcm;
+ };
+
+ i2c2: i2c@11009000 {
+ compatible = "mediatek,mt8127-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11009000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = ;
+ mediatek,have-dcm;
+ };
};
};
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 221ce09..cb32350 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -119,7 +119,97 @@
<0 0x1020C000 0 0x1000>;
gpio-controller;
#gpio-cells = <2>;
+
+ i2c0_pins_a: i2c0@0 {
+ mediatek,pins = ,
+ ;
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ mediatek,pins = ,
+ ;
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ mediatek,pins = ,
+ ;
+ };
+
+ i2c3_pins_a: i2c3@0 {
+ mediatek,pins = ,
+ ;
+ };
+
+ i2c4_pins_a: i2c4@0 {
+ mediatek,pins =
,
+
;
+ };
+
+ i2c5_pins_a: i2c5@0 {
+ mediatek,pins =
,
+
;
+ };
+
+ i2c6_pins_a: i2c6@0 {
+ mediatek,pins =
,
+
;
+ };
};
+ i2c0: i2c@1100d000 {
+ compatible = "mediatek,mt8135-i2c",
+ "mediatek,mt6589-i2c";
+ reg = <0 0x1100d000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = ;
+ };
+
+ i2c1: i2c@1100e000 {
+ compatible = "mediatek,mt8135-i2c",
+ "mediatek,mt6589-i2c";
+ reg = <0 0x1100e000 0 0x70>,
+ <0 0x11000380 0 0x80>;
+ interrupts = ;
+ };
+
+ i2c2: i2c@1100f000 {
+ compatible = "mediatek,mt8135-i2c",
+ "mediatek,mt6589-i2c";
+ reg = <0 0x1100f000 0 0x70>,
+ <0 0x11000400 0 0x80>;
+ interrupts = ;
+ };
+
+ i2c3: i2c@1101 {
+ compatible = "mediatek,mt8135-i2c",
+ "mediatek,mt6589-i2c";
+ reg = <0 0x1101 0 0x70>,
+ <0 0x11000480 0 0x80>;
+ interrupts = ;
+ };
+
+ i2c4: i2c@11011000 {
+ compatible = "mediatek,mt8135-i2c",
+ "mediatek,mt6589-i2c";
+ reg = <0 0x11011000 0 0x70>,
+ <0 0x11000500 0 0x80>;
+ interrupts = ;
+ };
+
+ i2c5: i2c@11012000 {
+ compatible = "mediatek,mt8135-i2c",
+
[PATCH v2 3/3] I2C: mediatek: Add driver for MediaTek I2C controller
The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.
Signed-off-by: Xudong Chen
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 742
3 files changed, 752 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-mt65xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..0d7d0a4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -564,6 +564,15 @@ config I2C_MPC
This driver can also be built as a module. If so, the module
will be called i2c-mpc.
+config I2C_MT65XX
+ tristate "MediaTek I2C adapter"
+ depends on ARCH_MEDIATEK
+ help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..7a9f0f3 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o
obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..4a0f4b0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,742 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This 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
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_HS_NACKERR (1 << 2)
+#define I2C_ACKERR (1 << 1)
+#define I2C_TRANSAC_COMP (1 << 0)
+#define I2C_TRANSAC_START (1 << 0)
+#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
+#define I2C_TIMING_DATA_READ_MASK (0x7 << 12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST 0x0001
+#define I2C_FIFO_ADDR_CLR 0x0001
+#define I2C_DELAY_LEN 0x0002
+#define I2C_ST_START_CON 0x8001
+#define I2C_FS_START_CON 0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_FS_TIME_INIT_VALUE 0x1303
+#define I2C_WRRD_TRANAC_VALUE 0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN 0x0001
+#define I2C_DMA_INT_FLAG_NONE 0x
+#define I2C_DMA_CLR_FLAG 0x
+
+#define I2C_DEFAUT_SPEED 10 /* hz */
+#define MAX_FS_MODE_SPEED 40
+#define MAX_HS_MODE_SPEED 340
+#define MAX_DMA_TRANS_SIZE 255
+#define MAX_WRRD_TRANS_SIZE32
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV 64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS (0x1 << 1)
+#define I2C_CONTROL_DMA_EN (0x1 << 2)
+#define I2C_CONTROL_CLK_EXT_EN (0x1 << 3)
+#define I2C_CONTROL_DIR_CHANGE (0x1 << 4)
+#define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_WRAPPER (0x1 << 0)
+
+#define COMPAT_MT6577 (0x1 << 0)
+#define COMPAT_MT6589 (0x1 << 1)
+
+#define I2C_DRV_NAME "mt-i2c"
+
+enum DMA_REGS_OFFSET {
+ OFFSET_INT_FLAG = 0x0,
+ OFFSET_INT_EN = 0x04,
+ OFFSET_EN = 0x08,
+ OFFSET_CON = 0x18,
+
[PATCH v2 0/3] ARM: mediatek: Add driver for Mediatek I2C controller
This series is the second version of Mediatek SoCs I2C controller common bus driver. Compared to the first version, 1. Add comment for feature have-pmic in dt-bindings file i2c-mt6577.txt. 2. Add notes for I2C4/5/6 in mt8135.dtsi. 3. Add check compatible for the feature have-pmic in i2c-mt65xx.c, if set have-pmic for the compatible mt6577 the driver will return error. Because the clock driver for mediatek SoC is not ready yet(still work in progress), so I delete the related clock code in dtsi file for now. This driver is based on 3.18-rc1 & Hongzhou's gpio patch. MTK I2C HW has some limitation. 1. If the i2c_msg number is more than one, STOP will be issued instead of RS(Repeat Start) between each message. Such as: "START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ..." 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. Ex: W/R/R, driver will combine first W/R and then R. The data series will be: "START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + DATA + STOP". 3. Due to HW limitation, in this version the max transfer data length is 255 in one message. If want to transfer more than 255 bytes, HW needs the SW driver to split the data. Take 600 bytes for example, the data need to be divided into 3 parts 255 + 255 + 90. The data series will be: "START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP" instead of "START + ADDR + DATA_900 + STOP". We haven't implement this yet, we will do this in the separate patch. MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. For example, If want to use I2C4/5/6 pins on MT8135 just need to enable the pinmux, else if want to use I2C pins on PMIC(MT6397) just need to add "mediatek,have-pmic" property in the .dts file of each platform. Xudong Chen (3): dt-bindings: Add I2C bindings for mt65xx/mt81xx. ARM: mediatek: Add I2C node for mt8135 and mt8127 I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 39 ++ arch/arm/boot/dts/mt8127.dtsi | 27 + arch/arm/boot/dts/mt8135.dtsi | 90 +++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-mt65xx.c| 742 + 6 files changed, 908 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.
Add devicetree bindings for Mediatek Soc I2C driver.
Signed-off-by: Xudong Chen
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..733e65e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,39 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+ - compatible: value should be either of the following.
+ (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+ (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+ (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+ (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+ - reg: physical base address of the controller and dma base, length of
memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+ - clock-div: the fixed value for frequency divider of clock source in i2c
module.
+Each IC may be different.
+ - clocks: clock name from clock manager
+ - clock-names: clock name used in i2c driver probe
+
+Optional properties:
+ - clock-frequency: Frequency in Hz of the bus when transfer, the default
value is 10.
+ - mediatek,have-pmic: platform can control i2c form special pmic side.
+Only mt6589 and mt8135 support this feature.
+ - mediatek,have-dcm: platform has DCM(hardware digital clock manager)
property.
+ - mediatek,use-push-pull: IO use push-pull mode.
+
+Example:
+
+ i2c0: i2c@1100d000 {
+ compatible = "mediatek,mt6577-i2c";
+ reg = <0x1100d000 0x70>,
+ <0x11000300 0x80>;
+ interrupts = ;
+ clock-frequency = <10>;
+ mediatek,have-pmic;
+ clock-div = <16>;
+ clocks = <_ck>, <_dma_ck>;
+ clock-names = "main", "dma";
+ };
+
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression with commit 52221610d
On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot wrote:
> Hi guys,
>
> On the NVIDIA shield (tegra114-roth) platform, I have noticed that MMC
> stopped working completely on recent kernels. MMC devices will not show up
> and the message "mmc1: Controller never released inhibit bit(s)." shows up
> repeatedly in the console.
>
> After bisecting I tracked commit 52221610dd84dc3e9196554f0292ca9e8ab3541d
> ("mmc: sdhci: Improve external VDD regulator support") as the one that
> introduced this issue, which seems somehow surprising to me since it has
> been around for a while and nobody else complained about this AFAICT.
I'm not too familiar with the Nvidia Shield so can you please confirm
the following?
The controller in the Tegra114 is SDHCI compliant and as such
sdhci_tegra_probe calls sdhci_add_host. External regulators are
sought in sdhci_add_host with a call to mmc_regulator_get_supply.
Since no external regulators are specified in tegra114.dtsi or
tegra114-roth.dts, mmc->supply.vmmc and mmc->supply.vqmmc are set to
-ENODEV.
> The following diff solves the issue for me, however I don't know whether it
> also reverts the intended purpose of the initial patch:
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ada1a3ea3a87..615701bb8ea3 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1235,13 +1235,6 @@ static void sdhci_set_power(struct sdhci_host *host,
> unsigned char mode,
> struct mmc_host *mmc = host->mmc;
> u8 pwr = 0;
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(>lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(>lock);
> - return;
> - }
> -
> if (mode != MMC_POWER_OFF) {
> switch (1 << vdd) {
> case MMC_VDD_165_195:
> @@ -1300,6 +1293,12 @@ static void sdhci_set_power(struct sdhci_host *host,
> unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(>lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(>lock);
> + }
> }
>
> Does this look like the right approach? If not, would you have any
> suggestion as to how to solve this problem?
The patch you proposed would break Exynos4210 so I don't think it is
appropriate.
Do you understand why this code block is executed on your hardware? I
wouldn't expect it.
Can you provide the relevant parts of the log before the problem occurs?
Thanks,
Tim Kryger
--
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: [char-misc-next V3] mei: add reference counting for me clients
> > On Mon, Nov 03, 2014 at 10:42:05AM +0200, Tomas Winkler wrote: > > To support dynamic addition/remove we add reference > > counter. > > What is keeping two different threads / cpus from grabbing a reference > at the same time the other one is dropping it? > > You have a list here, with no locking, right? You also don't have any > locking for your kref, which isn't good at all... > > Please audit and fix up. Of course there is a lock, it wouldn't work at all. It is not explicit but we run under device_lock mutex. Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Mon, Nov 3, 2014 at 8:32 PM, Greg Kroah-Hartman wrote: > On Mon, Nov 03, 2014 at 11:07:10AM +0800, Kweh Hock Leong wrote: >> From: "Kweh, Hock Leong" >> >> Introducing a kernel module to expose user helper interface for >> user to upload capsule binaries. This module leverage the >> request_firmware_nowait() to expose an interface to user. >> >> Example steps to load the capsule binary: >> 1.) echo 1 > /sys/class/firmware/efi-capsule-file/loading >> 2.) cat capsule.bin > /sys/class/firmware/efi-capsule-file/data >> 3.) echo 0 > /sys/class/firmware/efi-capsule-file/loading >> >> Whereas, this module does not allow the capsule binaries to be >> obtained from the request_firmware library search path. If any >> capsule binary loaded from firmware seach path, the module will >> stop functioning. >> >> Besides the request_firmware user helper interface, this module >> also expose a 'capsule_loaded' file note for user to verify >> the number of successfully uploaded capsule binaries. This >> file note has the read only attribute. > > Andy, here's the steps to load a capsule. I don't have a problem with > this, it's userspace driven, no "autoloading" of files in /lib/, and > works with sysfs. > > Have any objection to it, I don't. After reading the code, I still have objections. The full workflow seems to be, from the user's POV: 1. load the module 2. hope that there isn't a file called /lib/firmware/efi-capsule-file 3. echo 1 >.../loading 4. cat firmware >.../data 5. echo 0 >.../loading 6. efi_update_capsule gets called. The return value ends up in the kernel logs somewhere but doesn't seem to make it to userspace. 7. reboot(), but only if the capsule you loaded requires a reboot, which may or may not be detectable without the kernel's help (I'm not sure about this point). If you want to load a second capsule (which seems like a reasonable thing to do if the first capsule was the kind that is processed immediately), then rmmod -f the module and start over? This seems like an unpleasant interface. I think that ioctl or a dedicated custom sysfs file would be considerably nicer. It would allow you to upload a capsule and get an indication of success or failure all at once, and it lets you load more than one capsule. Also, it gets rid of some of the really weird module refcounting stuff that's going on -- the only unusual thing the module would do would be to pin itself once a reboot-requiring capsule is loaded. --Andy > > Full patch left below... > >> >> Cc: Matt Fleming >> Signed-off-by: Kweh, Hock Leong >> --- >> drivers/firmware/efi/Kconfig | 13 ++ >> drivers/firmware/efi/Makefile |1 + >> drivers/firmware/efi/efi-capsule-user-helper.c | 246 >> >> 3 files changed, 260 insertions(+) >> create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c >> >> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig >> index f712d47..7dc814e 100644 >> --- a/drivers/firmware/efi/Kconfig >> +++ b/drivers/firmware/efi/Kconfig >> @@ -60,6 +60,19 @@ config EFI_RUNTIME_WRAPPERS >> config EFI_ARMSTUB >> bool >> >> +config EFI_CAPSULE_USER_HELPER >> + tristate "EFI capsule user mode helper" >> + depends on EFI >> + select FW_LOADER >> + select FW_LOADER_USER_HELPER >> + help >> + This option exposes the user mode helper interface for user to load >> + EFI capsule binary and update the EFI firmware after system reboot. >> + This feature does not support auto locating capsule binaries at the >> + firmware lib search path. >> + >> + If unsure, say N. >> + >> endmenu >> >> config UEFI_CPER >> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile >> index 698846e..63f6910 100644 >> --- a/drivers/firmware/efi/Makefile >> +++ b/drivers/firmware/efi/Makefile >> @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o >> obj-$(CONFIG_EFI_RUNTIME_MAP)+= runtime-map.o >> obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o >> obj-$(CONFIG_EFI_STUB) += libstub/ >> +obj-$(CONFIG_EFI_CAPSULE_USER_HELPER)+= efi-capsule-user-helper.o >> diff --git a/drivers/firmware/efi/efi-capsule-user-helper.c >> b/drivers/firmware/efi/efi-capsule-user-helper.c >> new file mode 100644 >> index 000..84a1628 >> --- /dev/null >> +++ b/drivers/firmware/efi/efi-capsule-user-helper.c >> @@ -0,0 +1,246 @@ >> +/* >> + * EFI capsule user mode helper interface driver. >> + * >> + * Copyright 2014 Intel Corporation >> + * >> + * This file is part of the Linux kernel, and is made available under >> + * the terms of the GNU General Public License version 2. >> + */ >> + >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define CAPSULE_NAME
Re: [PATCH perf/core 0/6] perf-probe: Bugfix and add new options for cache
Hi Arnaldo and Masami, On Mon, 3 Nov 2014 14:19:00 -0200, Arnaldo Carvalho de Melo wrote: > [root@zoo ~]# perf buildid-cache --hell > Error: unknown option `hell' > > usage: perf buildid-cache [] > > -a, --add > file(s) to add > -k, --kcore kcore file to add > -r, --remove > file(s) to remove > -M, --missing to find missing build ids in the cache > -f, --force don't complain, do it > -u, --update > file(s) to update > -v, --verbose be more verbose > > [root@zoo ~]# > > Already has support for yet another of content: kcore files, its just a > matter of adding > one more: > >perf buildid-cache --probe But it deals with binaries, and what we need is probe points. So maybe it's worth add a new command like: perf probe-cache [add|del|enable|disable] [] [|] ... or perf probe-cache list [] This way we can handle both of kprobes and uprobes (so SDTs). What do you think? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On Tue, Oct 21, 2014 at 08:15:04PM +0200, Robert Richter wrote: > Arnd, > > On 05.09.14 08:48:06, Robert Richter wrote: > > From: Robert Richter > > > > For arm64 we want to put dts files into vendor's subdirectories from > > the beginning. This patch set implements this. As this is a generic > > kbuild implementation, vendor subdirs will be also available for > > arch/arm and other architectures. The subdirectory tree is also > > reflected in the install path. > > > > A new makefile variable dts-dirs is introduced to point to dts > > subdirs. This variable is used by kbuild for building and installation > > of dtb files. > > > > A dts Makefile looks now as follows: > > > > > > dtb-$(CONFIG_...) += some_file_1.dtb > > dtb-$(CONFIG_...) += some_file_2.dtb > > > > dts-dirs += dir_vendor_a > > dts-dirs += dir_vendor_b > > > > # come always afterwards: > > always := $(dtb-y) > > subdir-y := $(dts-dirs) > > clean-files:= *.dtb > > > > > > This patches also introduces the dtbs_install make target for > > arm64. Install rules are moved to Makefile.dtbinst using the same > > style and calling convention like for modinst and fwinst. > > > > Robert Richter (6): > > dts, arm64: Add dtbs_install make target > > dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst > > dts, arm/arm64: Remove dtbs build rules in sub-makes > > dts, kbuild: Implement support for dtb vendor subdirs > > dts, arm64: Move dts files to vendor subdirs > > dts, arm: Remove $(MACHINE) variable from dtbs make recipes > > please pull this series for inclusion into v3.19 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > dts-subdirs-for-arm-soc-v3.19 > > I have updated and rebased the patches to v3.18-rc1. No changes except > conflict resolution of patch 5/6. Pulled, and I added the description from 0/6 as the merge text -- feel free to add it to the tag if you do something like this in the future. -Olof -- 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 scsi tree
Hi James,
After merging the scsi tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/sched.h:17:0,
from include/linux/blkdev.h:4,
from drivers/scsi/constants.c:10:
drivers/scsi/constants.c: In function 'scsi_opcode_sa_name':
include/linux/kernel.h:54:32: error: invalid application of 'sizeof' to
incomplete type 'const char *[]'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
drivers/scsi/constants.c:300:15: note: in expansion of macro 'ARRAY_SIZE'
if (opcode < ARRAY_SIZE(cdb_byte0_names))
^
Caused by 94bafab0008c ("scsi: consolidate opcode lookup in
scsi_opcode_sa_name()"). This build does not have
CONFIG_SCSI_CONSTANTS set.
I have used the scsi tree from next-20141031 again (since yesterday's
tree had a different build problem).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp8NKTZ61UVm.pgp
Description: OpenPGP digital signature
[git pull] Please pull mpe.git for-linus branch (for powerpc)
Hi Linus, Some more powerpc fixes if you please. cheers The following changes since commit d506aa68c23db708ad45ca8c17f0d7f5d7029a37: Merge branch 'for-linus' of git://git.kernel.dk/linux-block (2014-10-29 11:57:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git for-linus for you to fetch changes up to 10ccaf178b2b961d8bca252d647ed7ed8aae2a20: powerpc: use device_online/offline() instead of cpu_up/down() (2014-11-02 10:55:56 +1100) Anton Blanchard (1): powerpc: do_notify_resume can be called with bad thread_info flags argument Benjamin Herrenschmidt (1): powerpc/powernv: Properly fix LPC debugfs endianness Dan Streetman (1): powerpc: use device_online/offline() instead of cpu_up/down() Fabian Frederick (1): powerpc: Fix section mismatch warning Hari Bathini (1): powerpc/fadump: Fix endianess issues in firmware assisted dump handling arch/powerpc/include/asm/fadump.h | 52 +++--- arch/powerpc/kernel/entry_64.S| 6 ++ arch/powerpc/kernel/fadump.c | 114 +++--- arch/powerpc/mm/init_32.c | 2 +- arch/powerpc/platforms/powernv/opal-lpc.c | 59 arch/powerpc/platforms/pseries/dlpar.c| 4 +- arch/powerpc/platforms/pseries/lpar.c | 14 +++- 7 files changed, 163 insertions(+), 88 deletions(-) signature.asc Description: This is a digitally signed message part
Re: Re: Re: [PATCH perf/core 0/6] perf-probe: Bugfix and add new options for cache
(2014/11/04 1:19), Arnaldo Carvalho de Melo wrote: > Em Mon, Nov 03, 2014 at 09:11:18PM +0900, Masami Hiramatsu escreveu: >> (2014/10/31 21:13), Arnaldo Carvalho de Melo wrote: >>> Em Fri, Oct 31, 2014 at 02:51:29PM -0400, Masami Hiramatsu escreveu: p:probe/reset_early_page_tables _text+12980741 p:probe/copy_bootdata _text+12980830 real_mode_data=%di:u64 p:probe/exit_amd_microcode _text+14692680 p:probe/early_make_pgtable _text+12981274 address=%di:u64 p:probe/x86_64_start_reservations _text+12981700 real_mode_data=%di:u64 p:probe/x86_64_start_kernel _text+12981744 real_mode_data=%di:u64 p:probe/reserve_ebda_region _text+12982117 > This event.cache file will be big (but much smaller than native debuginfo :) ) if your kernel have many option embedded. Anyway, you can compress it too. > >>> How do you validate that the cache can be used against some kernel? I.e. >>> is this that the user has to do? Isn't this prone to errors? > >> Actually, kprobe event itself can reject command if the given address >> is not in the kernel text nor instruction boundary (perhaps, uprobes >> may have a problem...), so for the kernel level, it is safe. > > No, it is not necessarily safe. > > What if you specify function foo() that has address 0x1234 for kernel > v3.16 and then run the cached probe on kernel v3.18 and on that kernel > the function foo() maps to address 0x2345 and function bar() instead > maps to address 0x1234? Oops. In that case user just trace bar() instead of foo(). Of course it's not correct, but shouldn't break the kernel (if the kernel is broken, it is a bug of kprobes). > The build-id was designed to uniquely identify a DSO, we need to use it. > > I think that at some point not using it should be left to a, in > systemtap parlance, "guru" mode, with tooling warning profusely when > build ids are not available and requiring even more forcing when it > doesn't matches. But it is not necessarily everyone uses perf probe to set up the probe events(because it is a part of ftrace), as we can see in the Brendan's scripts. I think, at least what we need is clarifying how can they ensure build-id before setting the probe events. I'd like to give them options with knowledge instead of forcing by tools. >>> Perhaps you could pick the build-id and store it into the event cache >>> file, in the first lines, somethings like: > >> Agreed, build-id should be the best way to check that. > >> For kprobes, user can easy to get and compare it with local one as below :) >> >> RLOGIN=root@$REMOTE >> rid=`ssh $RLOGIN "od -j16 -w48 -An -t x1 /sys/kernel/notes | tr -d ' '"` >> lid=`od -j16 -w48 -An -t x1 /sys/kernel/notes | tr -d ' '` >> if [ $rid != $lid ]; then >> echo "Error: Build-id mis-matched!" >> exit 1; >> fi >> echo "Setting up $EVENTNAME at $REMOTE" >> zcat event.cache.gz | grep $EVENTNAME |\ >> ssh $RLOGIN "tee -a /sys/kernel/debug/tracing/kprobe_events" >> echo "Done" >> > >> With this script, you don't need to install perf at remote hosts. >> (This is what enterprise people called "agent-less") > > This is only sufficient (and a cool feature!) if you will immediataly use the > cached info (i.e. using just two systems: one development machine, with all > debugging info, devel tools, etc, and the other the machine to observe, that > is > bare bones, no debugging info, etc)), but the moment you store that > event.cache.gz (that has no build id embedded from what I can see from the > above example) then you lose the build id for those cached events. Right, in this case, it should be stored with build-id, like below :) lid=`od -j16 -w48 -An -t x1 /sys/kernel/notes | tr -d ' '` perf probe -o - --max-probes=1 --no-inlines -a '* $params' | \ gzip -c - > $lid.gz Anyway, this is just a workaround by operation. > You need to tightly associate whatever symbol resolution is done with > the build id, at symbol resolution/caching time. Agreed, > > Then, before using the cached symbol resolution, we need to check if the > target > kernel/DSO build id is the same as the cached symbol kernel/DSO build id. Yeah, but again, some users may not like to install perf to the target system (like embedded system etc.) and also, I, personally, like to avoid introducing server-client networking feature for perftools, since it may open another pandora-box of security... I'd like to use it combining with other tools, like ssh or something like that. > > Right, what is in ~/.debug/ may be used by multiple tools, just like > debuginfo files are, by keying the content by its build id. > > And also by having separate subdirectory trees for different kinds of > symbol information, i.e. the ~/.debug/.build-id/ links may point to > either ELF files or to kallsyms data. What we are discussing here is to > make it also point to the [ku]probes_tracer cached probes files. > > The way that DSO files are cached may by
Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Mon, Nov 03, 2014 at 11:07:10AM +0800, Kweh Hock Leong wrote:
> From: "Kweh, Hock Leong"
>
> Introducing a kernel module to expose user helper interface for
> user to upload capsule binaries. This module leverage the
> request_firmware_nowait() to expose an interface to user.
>
> Example steps to load the capsule binary:
> 1.) echo 1 > /sys/class/firmware/efi-capsule-file/loading
> 2.) cat capsule.bin > /sys/class/firmware/efi-capsule-file/data
> 3.) echo 0 > /sys/class/firmware/efi-capsule-file/loading
>
> Whereas, this module does not allow the capsule binaries to be
> obtained from the request_firmware library search path. If any
> capsule binary loaded from firmware seach path, the module will
> stop functioning.
>
> Besides the request_firmware user helper interface, this module
> also expose a 'capsule_loaded' file note for user to verify
> the number of successfully uploaded capsule binaries. This
> file note has the read only attribute.
Andy, here's the steps to load a capsule. I don't have a problem with
this, it's userspace driven, no "autoloading" of files in /lib/, and
works with sysfs.
Have any objection to it, I don't.
Full patch left below...
>
> Cc: Matt Fleming
> Signed-off-by: Kweh, Hock Leong
> ---
> drivers/firmware/efi/Kconfig | 13 ++
> drivers/firmware/efi/Makefile |1 +
> drivers/firmware/efi/efi-capsule-user-helper.c | 246
>
> 3 files changed, 260 insertions(+)
> create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index f712d47..7dc814e 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -60,6 +60,19 @@ config EFI_RUNTIME_WRAPPERS
> config EFI_ARMSTUB
> bool
>
> +config EFI_CAPSULE_USER_HELPER
> + tristate "EFI capsule user mode helper"
> + depends on EFI
> + select FW_LOADER
> + select FW_LOADER_USER_HELPER
> + help
> + This option exposes the user mode helper interface for user to load
> + EFI capsule binary and update the EFI firmware after system reboot.
> + This feature does not support auto locating capsule binaries at the
> + firmware lib search path.
> +
> + If unsure, say N.
> +
> endmenu
>
> config UEFI_CPER
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 698846e..63f6910 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
> obj-$(CONFIG_EFI_RUNTIME_MAP)+= runtime-map.o
> obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
> obj-$(CONFIG_EFI_STUB) += libstub/
> +obj-$(CONFIG_EFI_CAPSULE_USER_HELPER)+= efi-capsule-user-helper.o
> diff --git a/drivers/firmware/efi/efi-capsule-user-helper.c
> b/drivers/firmware/efi/efi-capsule-user-helper.c
> new file mode 100644
> index 000..84a1628
> --- /dev/null
> +++ b/drivers/firmware/efi/efi-capsule-user-helper.c
> @@ -0,0 +1,246 @@
> +/*
> + * EFI capsule user mode helper interface driver.
> + *
> + * Copyright 2014 Intel Corporation
> + *
> + * This file is part of the Linux kernel, and is made available under
> + * the terms of the GNU General Public License version 2.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define CAPSULE_NAME "efi-capsule-file"
> +#define DEV_NAME "efi_capsule_user_helper"
> +#define STRING_INTEGER_MAX_LENGTH 13
> +
> +static DEFINE_MUTEX(user_helper_lock);
> +static int capsule_count;
> +static int stop_request;
> +static struct platform_device *efi_capsule_pdev;
> +
> +/*
> + * This function will store the capsule binary and pass it to
> + * efi_capsule_update() API in capsule.c
> + */
> +static int efi_capsule_store(const struct firmware *fw)
> +{
> + int i;
> + int ret;
> + int count = fw->size;
> + int copy_size = (fw->size > PAGE_SIZE) ? PAGE_SIZE : fw->size;
> + int pages_needed = ALIGN(fw->size, PAGE_SIZE) >> PAGE_SHIFT;
> + struct page **pages;
> + void *page_data;
> + efi_capsule_header_t *capsule = NULL;
> +
> + pages = kmalloc_array(pages_needed, sizeof(void *), GFP_KERNEL);
> + if (!pages) {
> + pr_err("%s: kmalloc_array() failed\n", __func__);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < pages_needed; i++) {
> + pages[i] = alloc_page(GFP_KERNEL);
> + if (!pages[i]) {
> + pr_err("%s: alloc_page() failed\n", __func__);
> + --i;
> + ret = -ENOMEM;
> + goto failed;
> + }
> + }
> +
> + for (i = 0; i < pages_needed; i++) {
> + page_data = kmap(pages[i]);
> +
Re: [3.16 stable PATCH 0/2] virtio-rng: two backports to fix stuck
On Sat, Oct 11, 2014 at 06:51:47AM +0800, Amos Kong wrote: > I received two mails about faile to apply patches to 3.16-stable tree: > > FAILED: patch "[PATCH] virtio-rng: skip reading when we start to remove the > device" failed to apply to 3.16-stable tree > FAILED: patch "[PATCH] virtio-rng: fix stuck of hot-unplugging busy device" > failed to apply to 3.16-stable tree > > Amit already backported two patches for 3.16-stable, then cherry-pick > of my two patches works. > > Thanks. Ping Greg, thanks. > Amos Kong (2): > virtio-rng: fix stuck of hot-unplugging busy device > virtio-rng: skip reading when we start to remove the device > > drivers/char/hw_random/virtio-rng.c | 7 +++ > 1 file changed, 7 insertions(+) > > -- > 1.9.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/ -- Amos. -- 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/
[LKP] [sched/fair] 83a0a96a5f2: -19.9% unixbench.score
FYI, we noticed the below changes on
commit 83a0a96a5f26d974580fd7251043ff70c8f1823d ("sched/fair: Leverage the idle
state info when choosing the "idlest" cpu")
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510 testbox/testcase/testparams
-- ---
%stddev %change %stddev
\ |\
883 ± 2% -19.9%706 ± 0% ivb42/unixbench/performance-execl
883 -19.9%706GEO-MEAN unixbench.score
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
562 ± 15%+572.8% 3786 ± 8% ivb42/unixbench/performance-execl
562 +572.8% 3786GEO-MEAN
sched_debug.cpu#28.ttwu_count
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
127 ± 38% +1135.4% 1576 ± 16% ivb42/unixbench/performance-execl
127 +1135.4% 1576GEO-MEAN
sched_debug.cfs_rq[47]:/.avg->runnable_avg_sum
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
207 ± 25% +1868.9% 4075 ± 6% ivb42/unixbench/performance-execl
206 +1868.9% 4075GEO-MEAN
sched_debug.cpu#47.ttwu_count
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
158 ± 25% +3096.7% 5076 ± 14% ivb42/unixbench/performance-execl
158 +3096.7% 5076GEO-MEAN
sched_debug.cpu#47.sched_goidle
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
349 ± 25% +3878.9% 13886 ± 10% ivb42/unixbench/performance-execl
348 +3878.9% 13886GEO-MEAN
sched_debug.cpu#47.nr_switches
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
160.41 ± 42%+510.9% 980.00 ± 14% ivb42/unixbench/performance-execl
160.41 +510.9% 980.00GEO-MEAN
sched_debug.cfs_rq[22]:/.exec_clock
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
24065 ± 18% -86.2% 3331 ± 32%
client7/autotest/performance-unixbench
24064 -86.2% 3331GEO-MEAN
proc-vmstat.numa_hint_faults
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
18054 ± 16% -83.7% 2939 ± 26%
client7/autotest/performance-unixbench
18054 -83.7% 2939GEO-MEAN
proc-vmstat.numa_hint_faults_local
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
143 ± 36%+824.1% 1327 ± 18% ivb42/unixbench/performance-execl
143 +824.1% 1326GEO-MEAN
sched_debug.cfs_rq[46]:/.avg->runnable_avg_sum
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
2 ± 39%+961.5% 27 ± 18% ivb42/unixbench/performance-execl
2 +961.5% 27GEO-MEAN
sched_debug.cfs_rq[46]:/.tg_runnable_contrib
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
279 ± 46%+754.8% 2384 ± 12% ivb42/unixbench/performance-execl
278 +754.8% 2384GEO-MEAN
sched_debug.cpu#22.ttwu_local
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
24 ± 31% +13712.4% 3342 ± 13% ivb42/unixbench/performance-execl
24+13712.4% 3342GEO-MEAN
sched_debug.cpu#46.ttwu_local
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
44.55 ± 20% +2597.5%1201.85 ± 11% ivb42/unixbench/performance-execl
44.55 +2597.5%1201.85GEO-MEAN
sched_debug.cfs_rq[45]:/.exec_clock
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
28 ± 33% +11224.6% 3216 ± 8% ivb42/unixbench/performance-execl
28+11224.6% 3216GEO-MEAN
sched_debug.cpu#45.ttwu_local
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
129 ± 37% +3211.6% 4291 ± 14% ivb42/unixbench/performance-execl
129 +3211.6% 4291GEO-MEAN
sched_debug.cpu#45.sched_goidle
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
178 ± 7%+425.4%937 ± 18% ivb42/unixbench/performance-execl
178 +425.4%937GEO-MEAN
sched_debug.cfs_rq[22]:/.avg->runnable_avg_sum
442bf3aaf55a91eb 83a0a96a5f26d974580fd72510
--
285 ± 35% +4047.2% 11852 ± 13%
[LKP] [sched] kernel BUG at kernel/smpboot.c:134!
FYI, we noticed the below changes on
git://bee.sh.intel.com/git/ydu19/linux for-lkp
commit 6fe1f1b9b13f9fd76d1230944482ee5bf2832252 ("sched: Remove task and group
entity load_avg when they are dead")
+---+++
| | a1ec4288c6 |
6fe1f1b9b1 |
+---+++
| boot_successes| 10 |
71 |
| early-boot-hang | 1 |
|
| boot_failures | 0 |
9 |
| kernel_BUG_at_kernel/smpboot.c| 0 |
5 |
| invalid_opcode| 0 |
5 |
| RIP:smpboot_thread_fn | 0 |
5 |
| Kernel_panic-not_syncing:Fatal_exception | 0 |
5 |
| Kernel_panic-not_syncing:Watchdog_detected_hard_LOCKUP_on_cpu | 0 |
1 |
| backtrace:cpu_up | 0 |
1 |
| backtrace:smp_init| 0 |
1 |
| backtrace:kernel_init_freeable| 0 |
1 |
| BUG:kernel_test_crashed | 0 |
3 |
+---+++
[3.205664] masked ExtINT on CPU#98
[3.205664] CPU98: Thermal LVT vector (0xfa) already installed
[3.234545] [ cut here ]
[3.235000] kernel BUG at kernel/smpboot.c:134!
[3.235000] invalid opcode: [#1] SMP
[3.235000] Modules linked in:
[3.235000] CPU: 0 PID: 789 Comm: watchdog/98 Not tainted
3.17.0-rc7-g6fe1f1b #7
[3.235000] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BKLDSDP1.86B.0031.R01.1304221600 04/22/2013
[3.235000] task: 881853ed8000 ti: 881853ee task.ti:
881853ee
[3.235000] RIP: 0010:[] []
smpboot_thread_fn+0x180/0x200
[3.235000] RSP: :881853ee3e88 EFLAGS: 00010202
[3.235000] RAX: RBX: 881853ed8000 RCX:
[3.235000] RDX: 881853ee3fd8 RSI: 881853ed8000 RDI: 0062
[3.235000] RBP: 881853ee3ec8 R08: 881853ee R09:
[3.235000] R10: 0001 R11: 0001 R12: 88185458e3e0
[3.235000] R13: 81cc6640 R14: 881853ed8000 R15: 881853ed8000
[3.235000] FS: () GS:88085f80()
knlGS:
[3.235000] CS: 0010 DS: ES: CR0: 80050033
[3.235000] CR2: 88207f174000 CR3: 00207ec38000 CR4: 001407f0
[3.235000] Stack:
[3.235000] 881853ee3ea0 81858ff9
881853cfbe40
[3.235000] 88185458e3e0 81091f40
[3.235000] 881853ee3f48 8108e1ab 0001
0062
[3.235000] Call Trace:
[3.235000] [] ? schedule+0x29/0x70
[3.235000] [] ? SyS_setgroups+0x180/0x180
[3.235000] [] kthread+0xdb/0x100
[3.235000] [] ? kthread_create_on_node+0x180/0x180
[3.235000] [] ret_from_fork+0x7c/0xb0
[3.235000] [] ? kthread_create_on_node+0x180/0x180
[3.235000] Code: 44 00 00 41 8b 3c 24 65 8b 14 25 2c b0 00 00 39 d7 0f 85
84 00 00 00 ff d0 41 c7 44 24 04 02 00 00 00 e9 1d ff ff ff 0f 1f 40 00 <0f> 0b
66 0f 1f 44 00 00 48 c7 45 c8 00 00 00 00 48 8b 45 c8 65
[3.235000] RIP [] smpboot_thread_fn+0x180/0x200
[3.235000] RSP
[3.235033] ---[ end trace c537e15456e615c3 ]---
[3.236004] Kernel panic - not syncing: Fatal exception
Thanks,
Fengguang
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.17.0-rc7-g6fe1f1b (kbuild@roam) (gcc version
4.9.1 (Debian 4.9.1-11) ) #7 SMP Sat Oct 11 17:57:44 CST 2014
[0.00] Command line: user=lkp
job=/lkp/scheduled/brickland1/lkp_will-it-scale-readseek-x86_64-rhel-HEAD-6fe1f1b9b13f9fd76d1230944482ee5bf2832252-1.yaml
ARCH=x86_64
BOOT_IMAGE=/kernel/x86_64-rhel/6fe1f1b9b13f9fd76d1230944482ee5bf2832252/vmlinuz-3.17.0-rc7-g6fe1f1b
kconfig=x86_64-rhel commit=6fe1f1b9b13f9fd76d1230944482ee5bf2832252
branch=yuyang/for-lkp root=/dev/ram0 max_uptime=1500
RESULT_ROOT=/result/brickland1/will-it-scale/readseek/debian-x86_64.cgz/x86_64-rhel/6fe1f1b9b13f9fd76d1230944482ee5bf2832252/0
ip=brickland1::dhcp ipmi_si.tryacpi=0 ipmi_watchdog.start_now=1
earlyprintk=ttyS0,115200 debug apic=debug
[LKP] [mm] aabfb57296e: -14.0% time.system_time
FYI, we noticed the below changes on
commit aabfb57296e3dd9761e47736ec69305c95461d7d ("mm: memcontrol: do not kill
uncharge batching in free_pages_and_swap_cache")
01c2965f0723a252 aabfb57296e3dd9761e47736ec testbox/testcase/testparams
-- ---
%stddev %change %stddev
\ |\
2017 ± 3% -14.0% 1735 ± 2%
lkp-hsw01/vm-scalability/performance-300s-16G-shm-pread-rand
2017 -14.0% 1735GEO-MEAN time.system_time
01c2965f0723a252 aabfb57296e3dd9761e47736ec
--
332 ± 0% -1.3%328 ± 0%
lkp-hsw01/vm-scalability/performance-300s-16G-shm-pread-rand
332-1.3%328GEO-MEAN time.elapsed_time
time.elapsed_time
334 +++
*..*.. .*.*.. .*..*.*..*.*.*..*. |
333 ++*..** * *..*.*.*..*..*.. .*..* |
| *..**.* + .* |
332 ++ *. |
| |
331 ++|
| |
330 ++|
| |
329 ++|
|O O O O O O O O O O O O |
328 O+O O O O O O O O O O O O O
| O OO O |
327 +++
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Fengguang
---
testcase: vm-scalability
default_monitors:
wait: pre-test
uptime:
iostat:
vmstat:
numa-numastat:
numa-vmstat:
numa-meminfo:
proc-vmstat:
proc-stat:
meminfo:
slabinfo:
interrupts:
lock_stat:
latency_stats:
softirqs:
bdi_dev_mapping:
diskstats:
energy:
cpuidle:
cpufreq:
turbostat:
sched_debug:
interval: 10
pmeter:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor:
- performance
commit: f114040e3ea6e07372334ade75d1ee0775c355e1
model: Grantley Haswell-EP
nr_cpu: 56
memory: 64G
hdd_partitions:
swap_partitions:
rootfs_partition:
perf-profile:
runtime: 300s
size: 16G
vm-scalability:
test:
- shm-pread-rand
enqueue_time: 2014-10-20 23:45:27.303040617 +08:00
testbox: lkp-hsw01
tbox_group: lkp-hsw01
kconfig: x86_64-rhel
head_commit: 34295884f135c1d9f34936a39b87741cdb04c492
base_commit: f114040e3ea6e07372334ade75d1ee0775c355e1
branch: linux-devel/devel-hourly-2014102109
kernel:
"/kernel/x86_64-rhel/f114040e3ea6e07372334ade75d1ee0775c355e1/vmlinuz-3.18.0-rc1-gf114040"
user: lkp
queue: cyclic
result_root:
"/result/lkp-hsw01/vm-scalability/performance-300s-16G-shm-pread-rand/debian-x86_64.cgz/x86_64-rhel/f114040e3ea6e07372334ade75d1ee0775c355e1/0"
job_file:
"/lkp/scheduled/lkp-hsw01/cyclic_vm-scalability-performance-300s-16G-shm-pread-rand-x86_64-rhel-BASE-f114040e3ea6e07372334ade75d1ee0775c355e1-0.yaml"
dequeue_time: 2014-10-21 10:08:31.140512609 +08:00
job_state: finished
loadavg: 51.25 36.48 16.41 1/451 11058
start_time: '1413857358'
end_time: '1413857686'
version: "/lkp/lkp/.src-20141020-230438"
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
echo performance >
[PATCH 3/6] phy: Add driver to support individual USB PHYs on sun9i
Unlike previous Allwinner SoCs, there is no central PHY control block
on the A80. Also, OTG support is completely split off into a different
controller.
This adds a new driver to support the regular USB PHYs.
Signed-off-by: Chen-Yu Tsai
---
.../devicetree/bindings/phy/sun9i-usb-phy.txt | 34 +++
drivers/phy/Kconfig| 12 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun9i-usb.c| 227 +
4 files changed, 274 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun9i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
new file mode 100644
index 000..27a6067
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt
@@ -0,0 +1,34 @@
+Allwinner sun9i USB PHY
+---
+
+Required properties:
+- compatible : should be one of
+ * allwinner,sun9i-a80-usb-phy
+- reg : a list of offset + length pairs
+- #phy-cells : from the generic phy bindings, must be 0
+- clocks : phandle + clock specifier for the phy clocks
+- clock-names :
+ * "phy" for normal USB
+ * "hsic_480M", "hsic_12M" for HSIC
+- resets : a list of phandle + reset specifier pairs
+- reset-names :
+ * "phy" for normal USB
+ * "hsic" for HSIC
+- phy_type : "hsic" for HSIC usage;
+other values or absence of this property indicates normal USB
+
+It is recommended to list all clocks and resets available.
+The driver will only use those matching the phy_type.
+
+Example:
+ usbphy1: phy@00a01800 {
+ compatible = "allwinner,sun9i-a80-usb-phy";
+ reg = <0x00a01800 0x4>;
+ clocks = <_phy_clk 2>, <_phy_clk 10>,
+ <_phy_clk 3>;
+ clock-names = "hsic_480M", "hsic_12M", "phy";
+ resets = <_phy_clk 18>, <_phy_clk 19>;
+ reset-names = "hsic", "phy";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..f5b7fbb 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -153,6 +153,18 @@ config PHY_SUN4I_USB
This driver controls the entire USB PHY block, both the USB OTG
parts, as well as the 2 regular USB 2 host PHYs.
+config PHY_SUN9I_USB
+ tristate "Allwinner sun9i SoC USB PHY driver"
+ depends on ARCH_SUNXI && HAS_IOMEM && OF
+ depends on RESET_CONTROLLER
+ select USB_PHY
+ select GENERIC_PHY
+ help
+ Enable this to support the transceiver that is part of Allwinner
+ sun9i SoCs.
+
+ This driver controls each individual USB 2 host PHY.
+
config PHY_SAMSUNG_USB2
tristate "Samsung USB 2.0 PHY driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c4590fc..c3977dc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
+obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
phy-exynos-usb2-y += phy-samsung-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
diff --git a/drivers/phy/phy-sun9i-usb.c b/drivers/phy/phy-sun9i-usb.c
new file mode 100644
index 000..f9085d9
--- /dev/null
+++ b/drivers/phy/phy-sun9i-usb.c
@@ -0,0 +1,227 @@
+/*
+ * Allwinner sun9i USB phy driver
+ *
+ * Copyright (C) 2014 Chen-Yu Tsai
+ *
+ * Based on phy-sun9i.c from
+ * Hans de Goede
+ *
+ * and code from
+ * Allwinner Technology Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_AHB_ICHR8_EN BIT(10)
+#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
+#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
+#define SUNXI_ULPI_BYPASS_EN BIT(0)
+
+struct sun9i_usb_phy {
+ struct phy *phy;
+ void __iomem *pmu;
+ struct regulator *vbus;
+ struct reset_control *reset;
+ struct clk *clk;
+ struct
[PATCH 1/6] clk: sunxi: Add support for sun9i a80 usb clocks and resets
The USB controller/phy clocks and reset controls are in a separate
address block, unlike previous SoCs where they were in the clock
controller.
This patch copies the original gates clk functions used for usb
clocks into a separate file, and renames them to *_usb_*. Also
add a per-gate parent index, so we can set different parents for
each gate.
In time we may move the other usb clock drivers to this file.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/clock/sunxi.txt | 5 +
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk-usb.c | 192 ++
3 files changed, 198 insertions(+)
create mode 100644 drivers/clk/sunxi/clk-usb.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0455cb9..b953fe5 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -66,6 +66,8 @@ Required properties:
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
"allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
+ "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
+ "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -82,6 +84,9 @@ Required properties for all clocks:
And "allwinner,*-usb-clk" clocks also require:
- reset-cells : shall be set to 1
+"allwinner,sun9i-a80-usb-*-clk" clocks require:
+- clocks : shall be the usb hci ahb1 gate and peripheral pll clocks
+
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index a66953c..f19ce54 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -8,6 +8,7 @@ obj-y += clk-a20-gmac.o
obj-y += clk-mod0.o
obj-y += clk-sun8i-mbus.o
obj-y += clk-sun9i-core.o
+obj-y += clk-usb.o
obj-$(CONFIG_MFD_SUN6I_PRCM) += \
clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
diff --git a/drivers/clk/sunxi/clk-usb.c b/drivers/clk/sunxi/clk-usb.c
new file mode 100644
index 000..d92ee36
--- /dev/null
+++ b/drivers/clk/sunxi/clk-usb.c
@@ -0,0 +1,192 @@
+/*
+ * Copyright 2013 Emilio López
+ *
+ * Emilio López
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/**
+ * sunxi_usb_reset... - reset bits in usb clk registers handling
+ */
+
+struct usb_reset_data {
+ void __iomem*reg;
+ spinlock_t *lock;
+ struct reset_controller_dev rcdev;
+};
+
+static int sunxi_usb_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct usb_reset_data *data = container_of(rcdev,
+ struct usb_reset_data,
+ rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg & ~BIT(id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sunxi_usb_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct usb_reset_data *data = container_of(rcdev,
+struct usb_reset_data,
+rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg | BIT(id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops sunxi_usb_reset_ops = {
+ .assert = sunxi_usb_reset_assert,
+ .deassert = sunxi_usb_reset_deassert,
+};
+
+/**
+ * sunxi_usb_clk_setup() - Setup function for usb gate clocks
+ */
+
+#define SUNXI_USB_MAX_SIZE 32
+
+struct usb_clk_data {
+ u32 clk_mask;
+ u32 reset_mask;
+ /* which parent to use, should match clock-output-names */
+ char parents[SUNXI_USB_MAX_SIZE];
+};
+
+static void __init
[PATCH 0/6] ARM: sun9i: Add USB host controller support for A80
Hi everyone, This series adds USB host controller (EHCI/OHCI) support for the Allwinner A80 SoC. The A80 has 3 pairs of host controllers and USB PHYs. The PHYs, unlike in previous SoCs, do not have low level control registers anymore. As such, this series forgoes the original phy-sun4i-usb driver, and adds a new, simpler driver for the USB PHYs. It may be possible to merge the two, but given that work is being done on the OTG front for the earlier SoCs, it may be better to merge them after support is complete. USB0 corresponds to USB1 DP/DM pins; USB1 only has HSIC support; USB2 is USB2 DP/DM externally. External pins labeled USB0 are for the USB 3.0 OTG controller. Patch 1 adds a80 specific support for usb-related clocks and resets. Patch 2 adds the device tree nodes for the usb clocks. Patch 3 adds a new generic phy driver for a80 usb phys. This has some code that is the same as the original phy-sun4i-usb driver, but is simpler. Patch 4 adds the 3 USB PHY nodes to the a80 dtsi. Patch 5 adds the USB host controller nodes to the a80 dtsi. Patch 6 adds the vbus regulator nodes and enables USB on the A80 Optimus board. Chen-Yu Tsai (6): clk: sunxi: Add support for sun9i a80 usb clocks and resets ARM: dts: sun9i: Add usb clock nodes to a80 dtsi phy: Add driver to support individual USB PHYs on sun9i ARM: dts: sun9i: Add usb phy nodes to a80 dtsi ARM: dts: sun9i: Add USB host controller nodes to a80 dtsi ARM: dts: sun9i: Enable USB support on A80 Optimus board Documentation/devicetree/bindings/clock/sunxi.txt | 5 + .../devicetree/bindings/phy/sun9i-usb-phy.txt | 34 +++ arch/arm/boot/dts/sun9i-a80-optimus.dts| 72 +++ arch/arm/boot/dts/sun9i-a80.dtsi | 129 drivers/clk/sunxi/Makefile | 1 + drivers/clk/sunxi/clk-usb.c| 192 + drivers/phy/Kconfig| 12 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-sun9i-usb.c| 227 + 9 files changed, 673 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/sun9i-usb-phy.txt create mode 100644 drivers/clk/sunxi/clk-usb.c create mode 100644 drivers/phy/phy-sun9i-usb.c -- 2.1.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 6/6] ARM: dts: sun9i: Enable USB support on A80 Optimus board
Signed-off-by: Chen-Yu Tsai
---
This patch does not use sunxi-common-regulators.dtsi, but adds the
regulators directly. To use the common regulators file, we would
need to use phandles and switch to preprocessor includes to support
that.
---
arch/arm/boot/dts/sun9i-a80-optimus.dts | 72 +
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 506948f..31010c1 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -59,6 +59,40 @@
};
soc {
+ ehci0: usb@00a0 {
+ status = "okay";
+ };
+
+ ohci0: usb@00a00400 {
+ status = "okay";
+ };
+
+ usbphy0: phy@00a00800 {
+ vbus-supply = <_usb0_vbus>;
+ status = "okay";
+ };
+
+ ehci1: usb@00a01000 {
+ status = "okay";
+ };
+
+ usbphy1: phy@00a01800 {
+ status = "okay";
+ };
+
+ ehci2: usb@00a02000 {
+ status = "okay";
+ };
+
+ ohci2: usb@00a02400 {
+ status = "okay";
+ };
+
+ usbphy2: phy@00a02800 {
+ vbus-supply = <_usb2_vbus>;
+ status = "okay";
+ };
+
pio: pinctrl@06000800 {
i2c3_pins_a: i2c3@0 {
/* Enable internal pull-up */
@@ -76,6 +110,20 @@
/* Enable internal pull-up */
allwinner,pull = <1>;
};
+
+ usb0_vbus_pin_optimus: usb0_vbus_pin@1 {
+ allwinner,pins = "PH4";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ usb2_vbus_pin_optimus: usb2_vbus_pin@1 {
+ allwinner,pins = "PH5";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
uart0: serial@0700 {
@@ -116,4 +164,28 @@
gpios = < 7 0 0>;
};
};
+
+ reg_usb0_vbus: usb0-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_vbus_pin_optimus>;
+ regulator-name = "usb0-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = < 7 4 0>; /* PH4 */
+ status = "okay";
+ };
+
+ reg_usb2_vbus: usb2-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_vbus_pin_optimus>;
+ regulator-name = "usb2-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = < 7 5 0>; /* PH5 */
+ status = "okay";
+ };
};
--
2.1.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/6] ARM: dts: sun9i: Add usb clock nodes to a80 dtsi
The USB controller and phy clocks and resets have a separate address
block and driver. Add the nodes to represent them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 494714f..3c25030 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -143,6 +143,28 @@
clock-output-names = "osc32k";
};
+ usb_mod_clk: clk@00a08000 {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun9i-a80-usb-mod-clk";
+ reg = <0x00a08000 0x4>;
+ clocks = <_gates 1>, <>;
+ clock-output-names = "usb0_ahb", "usb_ohci0",
+"usb1_ahb", "usb_ohci1",
+"usb2_ahb", "usb_ohci2";
+ };
+
+ usb_phy_clk: clk@00a08004 {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun9i-a80-usb-phy-clk";
+ reg = <0x00a08004 0x4>;
+ clocks = <_gates 1>, <>;
+ clock-output-names = "usb_phy0", "usb_hsic1_480M",
+"usb_phy1", "usb_hsic2_480M",
+"usb_phy2", "usb_hsic_12M";
+ };
+
pll4: clk@060c {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-pll4-clk";
--
2.1.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 4/6] ARM: dts: sun9i: Add usb phy nodes to a80 dtsi
On sun9i, there are 3 independent usb phys. Add device nodes for them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 3c25030..1a80e09 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -305,6 +305,43 @@
*/
ranges = <0 0 0 0x2000>;
+ usbphy0: phy@00a00800 {
+ compatible = "allwinner,sun9i-a80-usb-phy";
+ reg = <0x00a00800 0x4>;
+ clocks = <_phy_clk 1>;
+ clock-names = "phy";
+ resets = <_phy_clk 17>;
+ reset-names = "phy";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usbphy1: phy@00a01800 {
+ compatible = "allwinner,sun9i-a80-usb-phy";
+ reg = <0x00a01800 0x4>;
+ clocks = <_phy_clk 2>, <_phy_clk 10>,
+<_phy_clk 3>;
+ clock-names = "hsic_480M", "hsic_12M", "phy";
+ resets = <_phy_clk 18>, <_phy_clk 19>;
+ reset-names = "hsic", "phy";
+ status = "disabled";
+ #phy-cells = <0>;
+ /* usb1 is always used with HSIC */
+ phy_type = "hsic";
+ };
+
+ usbphy2: phy@00a02800 {
+ compatible = "allwinner,sun9i-a80-usb-phy";
+ reg = <0x00a02800 0x4>;
+ clocks = <_phy_clk 4>, <_phy_clk 10>,
+<_phy_clk 5>;
+ clock-names = "hsic_480M", "hsic_12M", "phy";
+ resets = <_phy_clk 20>, <_phy_clk 21>;
+ reset-names = "hsic", "phy";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
gic: interrupt-controller@01c41000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c41000 0x1000>,
--
2.1.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/6] ARM: dts: sun9i: Add USB host controller nodes to a80 dtsi
The A80 has 3 EHCI/OHCI USB controllers.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun9i-a80.dtsi | 70
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 1a80e09..b6f344f 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -305,6 +305,28 @@
*/
ranges = <0 0 0 0x2000>;
+ ehci0: usb@00a0 {
+ compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
+ reg = <0x00a0 0x100>;
+ interrupts = <0 72 4>;
+ clocks = <_mod_clk 1>;
+ resets = <_mod_clk 17>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci0: usb@00a00400 {
+ compatible = "allwinner,sun9i-a80-ohci", "generic-ohci";
+ reg = <0x00a00400 0x100>;
+ interrupts = <0 73 4>;
+ clocks = <_mod_clk 1>, <_mod_clk 2>;
+ resets = <_mod_clk 17>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
usbphy0: phy@00a00800 {
compatible = "allwinner,sun9i-a80-usb-phy";
reg = <0x00a00800 0x4>;
@@ -316,6 +338,32 @@
#phy-cells = <0>;
};
+ ehci1: usb@00a01000 {
+ compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
+ reg = <0x00a01000 0x100>;
+ interrupts = <0 74 4>;
+ clocks = <_mod_clk 3>;
+ resets = <_mod_clk 18>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ /*
+* Even though ohci1 exists, it is never used as
+* usb1 only has HSIC pins routed externally
+*/
+ ohci1: usb@00a01400 {
+ compatible = "allwinner,sun9i-a80-ohci", "generic-ohci";
+ reg = <0x00a01400 0x100>;
+ interrupts = <0 75 4>;
+ clocks = <_mod_clk 3>, <_mod_clk 4>;
+ resets = <_mod_clk 18>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
usbphy1: phy@00a01800 {
compatible = "allwinner,sun9i-a80-usb-phy";
reg = <0x00a01800 0x4>;
@@ -330,6 +378,28 @@
phy_type = "hsic";
};
+ ehci2: usb@00a02000 {
+ compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
+ reg = <0x00a02000 0x100>;
+ interrupts = <0 76 4>;
+ clocks = <_mod_clk 5>;
+ resets = <_mod_clk 19>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci2: usb@00a02400 {
+ compatible = "allwinner,sun9i-a80-ohci", "generic-ohci";
+ reg = <0x00a02400 0x100>;
+ interrupts = <0 77 4>;
+ clocks = <_mod_clk 5>, <_mod_clk 6>;
+ resets = <_mod_clk 19>;
+ phys = <>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
usbphy2: phy@00a02800 {
compatible = "allwinner,sun9i-a80-usb-phy";
reg = <0x00a02800 0x4>;
--
2.1.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] fs: quota: Use quota_err and use %pf to reduce code size
Use more standard logging style and remove __func__ passed
to quota_err.
Remove the quota_error macro, rename __quota_error to quota_err.
Add %pf and __builtin_return_address(0) instead of __func__
Add terminating newlines to formats.
$ size fs/quota/built-in.o*
textdata bss dec hex filename
47145 24751 18428 90324 160d4 fs/quota/built-in.o.new
47747 24751 18428 90926 1632e fs/quota/built-in.o.old
Signed-off-by: Joe Perches
---
fs/quota/dquot.c | 24 ++---
fs/quota/quota_tree.c| 92 +++-
fs/quota/quota_v1.c | 2 +-
fs/quota/quota_v2.c | 8 ++---
include/linux/quotaops.h | 8 ++---
5 files changed, 62 insertions(+), 72 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index 6b45272..682175f 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -129,8 +129,7 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(dq_data_lock);
EXPORT_SYMBOL(dq_data_lock);
DEFINE_STATIC_SRCU(dquot_srcu);
-void __quota_error(struct super_block *sb, const char *func,
- const char *fmt, ...)
+void quota_err(struct super_block *sb, const char *fmt, ...)
{
if (printk_ratelimit()) {
va_list args;
@@ -141,13 +140,13 @@ void __quota_error(struct super_block *sb, const char
*func,
vaf.fmt = fmt;
vaf.va =
- printk(KERN_ERR "Quota error (device %s): %s: %pV\n",
- sb->s_id, func, );
+ printk(KERN_ERR "Quota error (device %s): %pf: %pV\n",
+ sb->s_id, __builtin_return_address(0), );
va_end(args);
}
}
-EXPORT_SYMBOL(__quota_error);
+EXPORT_SYMBOL(quota_err);
#if defined(CONFIG_QUOTA_DEBUG) || defined(CONFIG_PRINT_QUOTA_WARNING)
static char *quotatypes[] = INITQFNAMES;
@@ -739,9 +738,9 @@ void dqput(struct dquot *dquot)
return;
#ifdef CONFIG_QUOTA_DEBUG
if (!atomic_read(>dq_count)) {
- quota_error(dquot->dq_sb, "trying to free free dquot of %s %d",
- quotatypes[dquot->dq_id.type],
- from_kqid(_user_ns, dquot->dq_id));
+ quota_err(dquot->dq_sb, "trying to free free dquot of %s %d\n",
+ quotatypes[dquot->dq_id.type],
+ from_kqid(_user_ns, dquot->dq_id));
BUG();
}
#endif
@@ -764,9 +763,8 @@ we_slept:
/* Commit dquot before releasing */
ret = dquot->dq_sb->dq_op->write_dquot(dquot);
if (ret < 0) {
- quota_error(dquot->dq_sb, "Can't write quota structure"
- " (error %d). Quota may get out of sync!",
- ret);
+ quota_err(dquot->dq_sb, "Can't write quota structure
(error %d). Quota may get out of sync!\n",
+ ret);
/*
* We clear dirty bit anyway, so that we avoid
* infinite loop here
@@ -951,9 +949,7 @@ static void add_dquot_ref(struct super_block *sb, int type)
#ifdef CONFIG_QUOTA_DEBUG
if (reserved) {
- quota_error(sb, "Writes happened before quota was turned on "
- "thus quota information is probably inconsistent. "
- "Please run quotacheck(8)");
+ quota_err(sb, "Writes happened before quota was turned on thus
quota information is probably inconsistent. Please run quotacheck(8)\n");
}
#endif
}
diff --git a/fs/quota/quota_tree.c b/fs/quota/quota_tree.c
index d65877f..ba7d5de 100644
--- a/fs/quota/quota_tree.c
+++ b/fs/quota/quota_tree.c
@@ -66,7 +66,7 @@ static ssize_t write_blk(struct qtree_mem_dqinfo *info, uint
blk, char *buf)
ret = sb->s_op->quota_write(sb, info->dqi_type, buf,
info->dqi_usable_bs, blk << info->dqi_blocksize_bits);
if (ret != info->dqi_usable_bs) {
- quota_error(sb, "dquota write failed");
+ quota_err(sb, "dquota write failed\n");
if (ret >= 0)
ret = -EIO;
}
@@ -160,8 +160,8 @@ static int remove_free_dqentry(struct qtree_mem_dqinfo
*info, char *buf,
dh->dqdh_next_free = dh->dqdh_prev_free = cpu_to_le32(0);
/* No matter whether write succeeds block is out of list */
if (write_blk(info, blk, buf) < 0)
- quota_error(info->dqi_sb, "Can't write block (%u) "
- "with free entries", blk);
+ quota_err(info->dqi_sb, "Can't write block (%u) with free
entries\n",
+ blk);
return 0;
out_buf:
kfree(tmpbuf);
@@ -251,8 +251,8 @@ static uint find_free_dqentry(struct qtree_mem_dqinfo *info,
if (le16_to_cpu(dh->dqdh_entries) + 1 >= qtree_dqstr_in_blk(info)) {
*err
[PATCH] toshiba_acpi: Fix regression caused by backlight extra check code
Bug 86521 uncovered that some TOS6208 devices also return
non zero values on a write call to the backlight method,
thus getting caught and bailed out by the extra check code.
This patch makes sure that the extra check is being done
on a TOS1900 device and then make the check for the broken
backlight code.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index ef3a190..e3fed12 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -944,9 +944,13 @@ static int set_lcd_brightness(struct toshiba_acpi_dev
*dev, int value)
/* Extra check for "incomplete" backlight method, where the AML code
* doesn't check for HCI_SET or HCI_GET and returns TOS_SUCCESS,
* the actual brightness, and in some cases the max brightness.
+* Use the SPFC method as an indicator that we're on a TOS1900 device,
+* otherwise some TOS6208 devices might get bailed out, see bug 86521
*/
- if (out[2] > 0 || out[3] == 0xE000)
- return -ENODEV;
+ if (acpi_has_method(dev->acpi_dev->handle, "SPFC")) {
+ if (out[2] > 0 || out[3] == 0xE000)
+ return -ENODEV;
+ }
return out[0] == TOS_SUCCESS ? 0 : -EIO;
}
--
2.1.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: [PULL REQUEST] remove .owner for most platform_drivers
On Tue, Oct 21, 2014 at 06:54:41PM +0200, Wolfram Sang wrote: > Hi Greg, > > as discussed at ELCE, here is my pull request for cleaning up all unneeded > assignment of .owner for platform drivers. I used the following semantic patch > to check that it only removes it when .owner gets initialized by the call to > register the driver: I've pulled this, and pushed it out in my driver-core-testing branch to make sure nothing breaks. Just to be sure, the 4 other patches you sent also need to go in here for 3.19, right? They were not included in this pull request? thanks, greg k-h -- 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: [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
On 11/3/2014 4:51 PM, Thomas Gleixner wrote:
On Mon, 3 Nov 2014, suravee.suthikulpa...@amd.com wrote:
+static void gicv2m_teardown_msi_irq(struct msi_chip *chip, unsigned int irq)
+{
+ int pos;
+ struct v2m_data *v2m = container_of(chip, struct v2m_data, msi_chip);
+
+ spin_lock(>msi_cnt_lock);
Why do you need an extra lock here? Is that stuff not serialized from
the msi_chip layer already?
If not, why don't we have the serialization there instead of forcing
every callback to implement its own?
From the following call paths:
|--> pci_enable_msi_range
|--> msi_capability_init
|--> arch_setup_msi_irqs
|--> arch_setup_msi_irq
and
|--> pci_enable_msix
|--> msix_capability_init
|--> arch_setup_msi_irqs
|--> arch_setup_msi_irq
It serialize when a PCI device driver tries to allocate multiple
interrupts. However, AFAICT, it would not serialize the allocation when
multiple drivers trying to setup MSI irqs at the same time. I needed
that to protect the bitmap structure. I also noticed the same in other
drivers as well.
I can look into this more to see where would be a good point.
+ pos = irq - v2m->spi_start;
So this assumes that @irq is the hwirq number, right? How does the
calling function know about that? It should only have knowledge about
the virq number if I'm not missing something.
And if I'm missing something, then that msi_chip stuff is seriously
broken.
It works this way because of the direct mapping (as you noticed). But I
am planning to change that. See below.
+ if (pos >= 0 && pos < v2m->nr_spis)
So you simply avoid the clear bitmap instead of yelling loudly about
being called with completely wrong data?
I'll provide appropriate warnings.
I would not be surprised if that is related to my question above.
Not quite sure which of the above questions.
+ spin_lock(>msi_cnt_lock);
+ offset = bitmap_find_free_region(v2m->bm, v2m->nr_spis, 0);
+ spin_unlock(>msi_cnt_lock);
+ if (offset < 0)
+ return offset;
+
+ hwirq = v2m->spi_start + offset;
+ virq = __irq_domain_alloc_irqs(v2m->domain, hwirq,
+ 1, NUMA_NO_NODE, v2m, true);
+ if (virq < 0) {
+ gicv2m_teardown_msi_irq(chip, hwirq);
+ return virq;
+ }
+
+ irq_domain_set_hwirq_and_chip(v2m->domain, virq, hwirq,
+ _chip, v2m);
+
+ irq_set_msi_desc(hwirq, desc);
+ irq_set_irq_type(hwirq, IRQ_TYPE_EDGE_RISING);
Sure both calls work perfectly fine as long as virq == hwirq, right?
I was running into an issue when calling the
irq_domain_alloc_irq_parent(), it requires of_phandle_args pointer to be
passed in. However, this does not work for GICv2m since it does not have
interrupt information in the device tree. So, I decided at first to use
direct (virq == hwirq) mapping, which simplifies the code a bit, but
might not be ideal solution, as you pointed out.
An alternative would be to create a temporary struct of_phandle_args,
and populate it with the interrupt information for the requested MSI.
Then pass it to:
--> irq_domain_alloc_irq_parent
|--> gic_irq_domain_alloc
|--> gic_irq_domain_xlate
|--> gic_irq_domain_map
However, this would still not be ideal if we want to support ACPI.
Another alternative would be coming up with a dedicate structure to be
used here. I noticed on X86, it uses struct irq_alloc_info. May be
that's what we also need here.
[...]
I do not care at all how YOU waste your time. But I care very much
about the fact that YOU are wasting MY precious time by exposing me to
your patch trainwrecks.
I don't intend to waste yours or anybody's precious time. Sorry if it
takes a couple iterations to work out the issues. Also, I will try to
put more comment in my code to make it more clear. Let me know what
works best for you to work out the issues.
Thanks,
Suravee
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [0/3] net: Kill skb_copy_datagram_const_iovec
On Mon, Nov 03, 2014 at 03:05:53PM -0500, David Miller wrote: > > I'll see if I can make some progress converting the networking over > to iov_iter. It can't be that difficult... albeit perhaps a little > time consuming. OK great. I'll try to convert tun/macvtap over to iov_iter. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: CMA: test_pages_isolated failures in alloc_contig_range
On 10/28/2014 12:57 PM, Michal Nazarewicz wrote: >> On 10/28/2014 08:38 AM, Michal Nazarewicz wrote: >>> Like Laura wrote, the message is not (should not be) a problem in >>> itself: >> >> [...] >> >>> So as you can see cma_alloc will try another part of the cma region if >>> test_pages_isolated fails. >>> >>> Obviously, if CMA region is fragmented or there's enough space for only >>> one allocation of required size isolation failures will cause allocation >>> failures, so it's best to avoid them, but they are not always avoidable. >>> >>> To debug you would probably want to add more debug information about the >>> page (i.e. data from struct page) that failed isolation after the >>> pr_warn in alloc_contig_range. > > On Tue, Oct 28 2014, Peter Hurley wrote: >> If the message does not indicate an actual problem, then its printk level is >> too high. These messages have been reported when using 3.16+ distro kernels. > > I think it could be argued both ways. The condition is not an error, > since in many cases cma_alloc will be able to continue, but it *is* an > undesired state. As such it's not an error but feels to me a bit more > then just information, hence a warning. I don't care either way, though. This "undesired state" is trivially reproducible on 3.16.y on the x86 arch; a smattering of these will show up just building a distro kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 4/7] x86, mm, pat: Add pgprot_writethrough() for WT
> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Monday, November 03, 2014 5:01 PM
> To: Thomas Gleixner
> Cc: Kani, Toshimitsu; Elliott, Robert (Server Storage); h...@zytor.com;
> mi...@redhat.com; a...@linux-foundation.org; a...@arndb.de; linux-
> m...@kvack.org; linux-kernel@vger.kernel.org; jgr...@suse.com;
> stefan.ba...@canonical.com; h...@hmh.eng.br; yi...@plexistor.com;
> konrad.w...@oracle.com
> Subject: Re: [PATCH v4 4/7] x86, mm, pat: Add pgprot_writethrough() for
> WT
>
> On Mon, Nov 3, 2014 at 2:53 PM, Thomas Gleixner
> wrote:
...
> On the other hand, I thought that _GPL was supposed to be more about
> whether the thing using it is inherently a derived work of the Linux
> kernel. Since WT is an Intel concept, not a Linux concept, then I
> think that this is a hard argument to make.
IBM System/360 Model 85 (1968) had write-through (i.e., store-through)
caching. Intel might claim Write Combining, though.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v8 08/10] sched: add SD_PREFER_SIBLING for SMT level
Hi Vincent,
On 14/10/31 下午4:47, Vincent Guittot wrote:
Add the SD_PREFER_SIBLING flag for SMT level in order to ensure that
the scheduler will put at least 1 task per core.
What's the behavior before this patch?
Regards,
Wanpeng Li
Signed-off-by: Vincent Guittot
Reviewed-by: Preeti U. Murthy
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 37fb92c..731f2ad 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6165,6 +6165,7 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
*/
if (sd->flags & SD_SHARE_CPUCAPACITY) {
+ sd->flags |= SD_PREFER_SIBLING;
sd->imbalance_pct = 110;
sd->smt_gain = 1178; /* ~15% */
--
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/
Badge factory
Hello Sirs/Madam, We are the one of gifts factory in China .doing all kinds of Festival gifts ,activtity gifs ,promtional gifts ,like Christmas pins /keychains with photos ,lanyard ect . Any demand or inquiry ,please feel free to contact me (Ms.Joan Wong）. Wish we could have coopration opportunity with you . Looking forwarder to your response . Best regards, Joan Wong Mainland office(Skype : joanwang18) Sonier Pins Co.,Ltd Address : No.2, JiXi ShunCheng Center ,Xiaolan Town ,Zhongshan City 528415,Guangdong ,China . Tel：（86 -760）22123680 Fax：（86 -760）22122916 Email: j...@sonier-pins.com Website: sonier-pins.com
Re: [PATCH perf/core 0/6] perf-probe: Bugfix and add new options for cache
Hi Masami, On Fri, 31 Oct 2014 14:51:29 -0400, Masami Hiramatsu wrote: > Hi, > > Here is a sereis of patches for enabling "event cache" feature > to perf probe. Brendan gives me this cool idea, thanks! :) > > In this series, I added following options/features; > - --output option >We can save the probe definition command for given probe-event >instead of setting up the local tracing/kprobe_events. > > - --no-inlines option >We can avoid searching the inline functions in debuginfo. Usually >useful with wildcards since the wildcards will hit a huge amount >of probe-points. > > - $params special probe argument >$params is expanded to function parameters only, no locally defined >variables. This is useful for function-call tracing. > > - wildcard support for function name >Wildcard support is the key feature for this idea. Now we can use >'*foo*' for function name to define the probe-point. > > So by using all of them, we can make an "event cache" file on all > functions (except for inlined functions) as below. > > # perf probe --max-probes=10 --no-inlines -a '* $params' -o event.cache > > builds "event.cache" file in which event settings for > all function entries, like below; > > p:probe/reset_early_page_tables _text+12980741 > p:probe/copy_bootdata _text+12980830 real_mode_data=%di:u64 > p:probe/exit_amd_microcode _text+14692680 > p:probe/early_make_pgtable _text+12981274 address=%di:u64 > p:probe/x86_64_start_reservations _text+12981700 real_mode_data=%di:u64 > p:probe/x86_64_start_kernel _text+12981744 real_mode_data=%di:u64 > p:probe/reserve_ebda_region _text+12982117 Does this event cache support kernel modules too? AFAIK it can have a different address whenever loaded even on a same kernel. > > This event.cache file will be big (but much smaller than native > debuginfo :) ) if your kernel have many option embedded. > Anyway, you can compress it too. > > # wc -l event.cache > 33813 event.cache > # ls -sh event.cache > 2.3M event.cache > # ls -sh event.cache.gz > 464K event.cache.gz > > For setting up a probe event, you can grep the function name > and write it to tracing/kprobe_events, as below; > > # zcat event.cache.gz | \ > grep probe/vfs_symlink > /sys/kernel/debug/tracing/kprobe_events > > This can be applied for the remote machine only if the machine > runs on completely same kernel binary. Perhaps, we need some > helper tool to check it. While it's useful for "agent-less" systems, I think we also need to have a simple way to apply it with perf tools. Thanks, Namhyung > > Thank you, > > > --- > > Masami Hiramatsu (6): > [BUGFIX] perf-probe: Fix to handle optimized not-inlined but has no > instance > [DOC] perf-probe: Update perf-probe document > perf-probe: Add --output option to write commands in a standard file > perf-probe: Add --no-inlines option to avoid searching inline functions > perf-probe: Support $params special probe argument > perf-probe: Support glob wildcards for function name > > > tools/perf/Documentation/perf-probe.txt | 25 ++ > tools/perf/builtin-probe.c | 32 + > tools/perf/util/dwarf-aux.c | 31 + > tools/perf/util/dwarf-aux.h |6 +++ > tools/perf/util/probe-event.c | 73 > +++ > tools/perf/util/probe-event.h |4 +- > tools/perf/util/probe-finder.c | 74 > +++ > tools/perf/util/probe-finder.h |6 ++- > tools/perf/util/util.h |4 ++ > 9 files changed, 202 insertions(+), 53 deletions(-) > > -- > Masami HIRAMATSU > Software Platform Research Dpt. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu...@hitachi.com -- 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] leds: leds-gpio: Convert gpio_blink_set() to use GPIO descriptors
On 10/31/2014 08:40 PM, Mika Westerberg wrote:
Commit 21f2aae91e902aad ("leds: leds-gpio: Add support for GPIO
descriptors") already converted most of the driver to use GPIO descriptors.
What is still missing is the platform specific hook gpio_blink_set() and
board files which pass legacy GPIO numbers to this driver in platform data.
In this patch we handle the former and convert gpio_blink_set() to take
GPIO descriptor instead. In order to do this we convert the existing four
users to accept GPIO descriptor and translate it to legacy GPIO number in
the platform code. This effectively "pushes" legacy GPIO number usage from
the driver to platforms.
Also add comment to the remaining block describing that it is legacy code
path and we are getting rid of it eventually.
Suggested-by: Linus Walleij
Signed-off-by: Mika Westerberg
Acked-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] quota: Add log level to printk
On Tue, 2014-11-04 at 12:05 +1100, Anton Blanchard wrote:
> Signed-off-by: Anton Blanchard
> ---
>
> Index: b/fs/quota/dquot.c
> ===
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -2743,7 +2743,7 @@ static int __init dquot_init(void)
> for (i = 0; i < nr_hash; i++)
> INIT_HLIST_HEAD(dquot_hash + i);
>
> - printk("Dquot-cache hash table entries: %ld (order %ld, %ld bytes)\n",
> + pr_info("Dquot-cache hash table entries: %ld (order %ld, %ld bytes)\n",
> nr_hash, order, (PAGE_SIZE << order));
The other printks in the file have a "VFS: " prefix.
Maybe this one too?
--
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/
Possible regression with commit 52221610d
Hi guys,
On the NVIDIA shield (tegra114-roth) platform, I have noticed that MMC
stopped working completely on recent kernels. MMC devices will not show
up and the message "mmc1: Controller never released inhibit bit(s)."
shows up repeatedly in the console.
After bisecting I tracked commit
52221610dd84dc3e9196554f0292ca9e8ab3541d ("mmc: sdhci: Improve external
VDD regulator support") as the one that introduced this issue, which
seems somehow surprising to me since it has been around for a while and
nobody else complained about this AFAICT.
The following diff solves the issue for me, however I don't know whether
it also reverts the intended purpose of the initial patch:
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ada1a3ea3a87..615701bb8ea3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1235,13 +1235,6 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned char mode,
struct mmc_host *mmc = host->mmc;
u8 pwr = 0;
- if (!IS_ERR(mmc->supply.vmmc)) {
- spin_unlock_irq(>lock);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
- spin_lock_irq(>lock);
- return;
- }
-
if (mode != MMC_POWER_OFF) {
switch (1 << vdd) {
case MMC_VDD_165_195:
@@ -1300,6 +1293,12 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned char mode,
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
mdelay(10);
}
+
+ if (!IS_ERR(mmc->supply.vmmc)) {
+ spin_unlock_irq(>lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(>lock);
+ }
}
Does this look like the right approach? If not, would you have any
suggestion as to how to solve this problem?
Thanks,
Alex.
--
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] tty: serial: msm: Support sysrq on uartDM devices
On 11/3/2014 2:05 AM, Daniel Thompson wrote:
> On 31/10/14 18:08, Frank Rowand wrote:
>> On 10/31/2014 2:43 AM, Daniel Thompson wrote:
>>> On 31/10/14 06:41, Stephen Boyd wrote:
On 10/30, Daniel Thompson wrote:
> On 29/10/14 18:14, Stephen Boyd wrote:
>> +r_count = min_t(int, count, sizeof(buf));
>> +
>> +for (i = 0; i < r_count; i++) {
>> +char flag = TTY_NORMAL;
>>
>> -/* TODO: handle sysrq */
>> -tty_insert_flip_string(tport, buf, min(count, 4));
>> -count -= 4;
>> +if (msm_port->break_detected && buf[i] == 0) {
>> +port->icount.brk++;
>> +flag = TTY_BREAK;
>> +msm_port->break_detected = false;
>> +if (uart_handle_break(port))
>> +continue;
>> +}
>> +
>> +if (!(port->read_status_mask &
>> UART_SR_RX_BREAK))
>> +flag = TTY_NORMAL;
>
> flag is already known to be TTY_NORMAL.
Huh? If we detected a break we would set the flag to TTY_BREAK
and if uart_handle_break() returned 0 (perhaps sysrq config is
diasbled) then we would get down here, and then we want to reset
the flag to TTY_NORMAL if the read_status_mask bits indicate that
we want to skip checking for breaks. Otherwise we want to
indicate to the tty layer that it's a break character.
>>>
>>> Agreed. Sorry for noise.
>>>
>>> It now reaches the level of silly quibble (meaning I won't bother to
>>> raise the issue again if there is a v2 patch) but perhaps updating the
>>> flag after the continue would be easier to read.
>>>
>>>
>> +
>> +spin_unlock(>lock);
>
> Is it safe to unlock at this point? count may no longer be valid when we
> return.
Can you explain further? If it actually isn't valid something
needs to be done. I believe other serial drivers are doing this
sort of thing though so it doesn't seem that uncommon (of course
those drivers could also be broken I suppose).
>>>
>>> Calling spin_unlock() means we are allow code to alter the state of the
>>> UART. In particular the subsequent call to uart_handle_sysrq_char() can
>>> make significant changes to the FIFO state (by calling the poll_char
>>> functions). Given count is shadowing the FIFO state, when we retake the
>>> lock I think it is possible for count to no longer be valid.
>>
>> uart_handle_sysrq_char() will not _read_ from the serial port. So it will
>> not directly modify the FIFO state.
>
> poll_char does not read from the FIFO? Since when?
>
> SysRq-g will enter cause the system to enter kdb/kgdb from within
> uart_handle_sysrq_char().
Aarrgh. You are correct. I overlooked the obvious SysRq-g.
/me searches for paper bag.
-Frank
--
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 0/7] implementation of eBPF maps
Hi All,
this set of patches adds implementation of HASH and ARRAY types of eBPF maps
which were described in manpage in commit b4fc1a460f30("Merge branch
'bpf-next'")
The difference vs previous version of these patches from August:
- added 'flags' attribute to BPF_MAP_UPDATE_ELEM
- in HASH type implementation removed per-map kmem_cache.
I was doing kmem_cache_create() for every map to enable selective slub
debugging to check for overflows and leaks. Now it's not needed, so just
use normal kmalloc() for map elements.
- added ARRAY type which was mentioned in manpage, but wasn't public yet
- added map testsuite and removed temporary bits from test_stubs
Note, eBPF programs cannot be attached to events yet.
It will come in the next set.
Alexei Starovoitov (7):
bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
bpf: add hashtable type of eBPF maps
bpf: add array type of eBPF maps
bpf: fix BPF_MAP_LOOKUP_ELEM command return code
bpf: add a testsuite for eBPF maps
bpf: allow eBPF programs to use maps
bpf: remove test map scaffolding and user proper types
include/linux/bpf.h |7 +-
include/uapi/linux/bpf.h| 15 +-
kernel/bpf/Makefile |2 +-
kernel/bpf/arraymap.c | 150 ++
kernel/bpf/hashtab.c| 362 +++
kernel/bpf/helpers.c| 88 +++
kernel/bpf/syscall.c|6 +-
kernel/bpf/test_stub.c | 56 ++-
samples/bpf/Makefile|3 +-
samples/bpf/libbpf.c|3 +-
samples/bpf/libbpf.h|2 +-
samples/bpf/test_maps.c | 287 ++
samples/bpf/test_verifier.c | 14 +-
13 files changed, 932 insertions(+), 63 deletions(-)
create mode 100644 kernel/bpf/arraymap.c
create mode 100644 kernel/bpf/hashtab.c
create mode 100644 kernel/bpf/helpers.c
create mode 100644 samples/bpf/test_maps.c
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 7/7] bpf: remove test map scaffolding and use proper types
proper types and function helpers are ready. Use them in verifier testsuite.
Remove temporary stubs
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/test_stub.c | 56 +++
samples/bpf/test_verifier.c | 14 +--
2 files changed, 16 insertions(+), 54 deletions(-)
diff --git a/kernel/bpf/test_stub.c b/kernel/bpf/test_stub.c
index fcaddff4003e..0ceae1e6e8b5 100644
--- a/kernel/bpf/test_stub.c
+++ b/kernel/bpf/test_stub.c
@@ -18,26 +18,18 @@ struct bpf_context {
u64 arg2;
};
-static u64 test_func(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
-{
- return 0;
-}
-
-static struct bpf_func_proto test_funcs[] = {
- [BPF_FUNC_unspec] = {
- .func = test_func,
- .gpl_only = true,
- .ret_type = RET_PTR_TO_MAP_VALUE_OR_NULL,
- .arg1_type = ARG_CONST_MAP_PTR,
- .arg2_type = ARG_PTR_TO_MAP_KEY,
- },
-};
-
static const struct bpf_func_proto *test_func_proto(enum bpf_func_id func_id)
{
- if (func_id < 0 || func_id >= ARRAY_SIZE(test_funcs))
+ switch (func_id) {
+ case BPF_FUNC_map_lookup_elem:
+ return _map_lookup_elem_proto;
+ case BPF_FUNC_map_update_elem:
+ return _map_update_elem_proto;
+ case BPF_FUNC_map_delete_elem:
+ return _map_delete_elem_proto;
+ default:
return NULL;
- return _funcs[func_id];
+ }
}
static const struct bpf_context_access {
@@ -78,38 +70,8 @@ static struct bpf_prog_type_list tl_prog = {
.type = BPF_PROG_TYPE_UNSPEC,
};
-static struct bpf_map *test_map_alloc(union bpf_attr *attr)
-{
- struct bpf_map *map;
-
- map = kzalloc(sizeof(*map), GFP_USER);
- if (!map)
- return ERR_PTR(-ENOMEM);
-
- map->key_size = attr->key_size;
- map->value_size = attr->value_size;
- map->max_entries = attr->max_entries;
- return map;
-}
-
-static void test_map_free(struct bpf_map *map)
-{
- kfree(map);
-}
-
-static struct bpf_map_ops test_map_ops = {
- .map_alloc = test_map_alloc,
- .map_free = test_map_free,
-};
-
-static struct bpf_map_type_list tl_map = {
- .ops = _map_ops,
- .type = BPF_MAP_TYPE_UNSPEC,
-};
-
static int __init register_test_ops(void)
{
- bpf_register_map_type(_map);
bpf_register_prog_type(_prog);
return 0;
}
diff --git a/samples/bpf/test_verifier.c b/samples/bpf/test_verifier.c
index 63402742345e..b96175e90363 100644
--- a/samples/bpf/test_verifier.c
+++ b/samples/bpf/test_verifier.c
@@ -261,7 +261,7 @@ static struct bpf_test tests[] = {
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
- BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_unspec),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_lookup_elem),
BPF_EXIT_INSN(),
},
.fixup = {2},
@@ -417,7 +417,7 @@ static struct bpf_test tests[] = {
BPF_ALU64_REG(BPF_MOV, BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
- BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_unspec),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_delete_elem),
BPF_EXIT_INSN(),
},
.errstr = "fd 0 is not pointing to valid bpf_map",
@@ -430,7 +430,7 @@ static struct bpf_test tests[] = {
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
- BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_unspec),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_lookup_elem),
BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0),
BPF_EXIT_INSN(),
},
@@ -445,7 +445,7 @@ static struct bpf_test tests[] = {
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
- BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_unspec),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
BPF_EXIT_INSN(),
@@ -461,7 +461,7 @@ static struct bpf_test tests[] = {
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
[PATCH net-next 1/7] bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command
the current meaning of BPF_MAP_UPDATE_ELEM syscall command is:
either update existing map element or create a new one.
Initially the plan was to add a new command to handle the case of
'create new element if it didn't exist', but 'flags' style looks
cleaner and overall diff is much smaller (more code reused), so add 'flags'
attribute to BPF_MAP_UPDATE_ELEM command with the following meaning:
enum {
BPF_MAP_UPDATE_OR_CREATE = 0, /* add new element or update existing */
BPF_MAP_CREATE_ONLY, /* add new element if it didn't exist */
BPF_MAP_UPDATE_ONLY /* update existing element */
};
BPF_MAP_CREATE_ONLY can fail with EEXIST if element already exists.
BPF_MAP_UPDATE_ONLY can fail with ENOENT if element doesn't exist.
Userspace will call it as:
int bpf_update_elem(int fd, void *key, void *value, __u64 flags)
{
union bpf_attr attr = {
.map_fd = fd,
.key = ptr_to_u64(key),
.value = ptr_to_u64(value),
.flags = flags;
};
return bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));
}
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h |2 +-
include/uapi/linux/bpf.h | 10 +-
kernel/bpf/syscall.c |4 ++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3cf91754a957..51e9242e4803 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -22,7 +22,7 @@ struct bpf_map_ops {
/* funcs callable from userspace and from eBPF programs */
void *(*map_lookup_elem)(struct bpf_map *map, void *key);
- int (*map_update_elem)(struct bpf_map *map, void *key, void *value);
+ int (*map_update_elem)(struct bpf_map *map, void *key, void *value, u64
flags);
int (*map_delete_elem)(struct bpf_map *map, void *key);
};
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index d18316f9e9c4..19c7ae4a4dd5 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -82,7 +82,7 @@ enum bpf_cmd {
/* create or update key/value pair in a given map
* err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
-* Using attr->map_fd, attr->key, attr->value
+* Using attr->map_fd, attr->key, attr->value, attr->flags
* returns zero or negative error
*/
BPF_MAP_UPDATE_ELEM,
@@ -117,6 +117,13 @@ enum bpf_prog_type {
BPF_PROG_TYPE_UNSPEC,
};
+/* flags for BPF_MAP_UPDATE_ELEM command */
+enum bpf_map_update_flags {
+ BPF_MAP_UPDATE_OR_CREATE = 0, /* add new element or update existing */
+ BPF_MAP_CREATE_ONLY,/* add new element if it didn't exist */
+ BPF_MAP_UPDATE_ONLY /* update existing element */
+};
+
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
__u32 map_type; /* one of enum bpf_map_type */
@@ -132,6 +139,7 @@ union bpf_attr {
__aligned_u64 value;
__aligned_u64 next_key;
};
+ __u64 flags;
};
struct { /* anonymous struct used by BPF_PROG_LOAD command */
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index ba61c8c16032..c0d03bf317a2 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -190,7 +190,7 @@ err_put:
return err;
}
-#define BPF_MAP_UPDATE_ELEM_LAST_FIELD value
+#define BPF_MAP_UPDATE_ELEM_LAST_FIELD flags
static int map_update_elem(union bpf_attr *attr)
{
@@ -231,7 +231,7 @@ static int map_update_elem(union bpf_attr *attr)
* therefore all map accessors rely on this fact, so do the same here
*/
rcu_read_lock();
- err = map->ops->map_update_elem(map, key, value);
+ err = map->ops->map_update_elem(map, key, value, attr->flags);
rcu_read_unlock();
free_value:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/7] bpf: add array type of eBPF maps
add new map type BPF_MAP_TYPE_ARRAY and its implementation
- optimized for fastest possible lookup()
. in the future verifier/JIT may recognize lookup() with constant key
and optimize it into constant pointer. Can optimize non-constant
key into direct pointer arithmetic as well, since pointers and
value_size are constant for the life of the eBPF program.
In other words array_map_lookup_elem() may be 'inlined' by verifier/JIT
while preserving concurrent access to this map from user space
- two main use cases for array type:
. 'global' eBPF variables: array of 1 element with key=0 and value is a
collection of 'global' variables which programs can use to keep the state
between events
. aggregation of tracing events into fixed set of buckets
- all array elements pre-allocated and zero initialized at init time
- key as an index in array and can only be 4 byte
- map_delete_elem() returns EINVAL, since elements cannot be deleted
- map_update_elem() replaces elements in an non-atomic way
(for atomic updates hashtable type should be used instead)
Signed-off-by: Alexei Starovoitov
---
Note, from eBPF program and from user space, all map types are accessed
through the same API.
Example of using array type for 'global' variables from eBPF program:
struct globals {
u64 lat_ave;
u64 lat_sum;
u64 missed;
u64 max_lat;
int num_samples;
};
struct bpf_map_def SEC("maps") global_map = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(struct globals),
.max_entries = 1,
};
int bpf_prog(struct bpf_context *ctx)
{
...
int ind = 0;
struct globals *g = bpf_map_lookup_elem(_map, );
if (!g)
return 0;
if (g->lat_ave == 0) {
g->num_samples++;
g->lat_sum += delta;
if (g->num_samples >= 100) {
g->lat_ave = g->lat_sum / g->num_samples;
...
The future verifier/JIT optimization will replace bpf_map_lookup_elem()
call inside eBPF program with const pointer to element value of key=0,
so that eBPF program will have no penalty whatsoever to access such
'global' variables.
At the same time user space can access this 'globals' via common map API.
Full example of both kernel and user side follows in later patches.
include/uapi/linux/bpf.h |1 +
kernel/bpf/Makefile |2 +-
kernel/bpf/arraymap.c| 150 ++
3 files changed, 152 insertions(+), 1 deletion(-)
create mode 100644 kernel/bpf/arraymap.c
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c071f9e3a454..9811d012b766 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -112,6 +112,7 @@ enum bpf_cmd {
enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC,
BPF_MAP_TYPE_HASH,
+ BPF_MAP_TYPE_ARRAY,
};
enum bpf_prog_type {
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 2c0ec7f9da78..72ec98ba2d42 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -1,5 +1,5 @@
obj-y := core.o
-obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o hashtab.o
+obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o hashtab.o arraymap.o
ifdef CONFIG_TEST_BPF
obj-$(CONFIG_BPF_SYSCALL) += test_stub.o
endif
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
new file mode 100644
index ..60212672ec9c
--- /dev/null
+++ b/kernel/bpf/arraymap.c
@@ -0,0 +1,150 @@
+/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ *
+ * 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
+
+struct bpf_array {
+ struct bpf_map map;
+ u32 elem_size;
+ char value[0] __aligned(8);
+};
+
+/* Called from syscall */
+static struct bpf_map *array_map_alloc(union bpf_attr *attr)
+{
+ struct bpf_array *array;
+ u32 elem_size;
+
+ /* check sanity of attributes */
+ if (attr->max_entries == 0 || attr->key_size != 4 ||
+ attr->value_size == 0)
+ return ERR_PTR(-EINVAL);
+
+ elem_size = round_up(attr->value_size, 8);
+
+ /* allocate all map elements and zero-initialize them */
+ array = kzalloc(sizeof(*array) + attr->max_entries * elem_size,
+ GFP_USER | __GFP_NOWARN);
+ if (!array) {
+ array = vzalloc(array->map.max_entries * array->elem_size);
+ if (!array)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* copy mandatory map attributes */
+ array->map.key_size = attr->key_size;
+
