Re: [PATCH v2 0/2] cpufreq: exynos: Fixes for v3.12
Hi Rafael, > On Friday, October 11, 2013 01:22:57 PM Rafael J. Wysocki wrote: > > On Wednesday, October 09, 2013 02:08:41 PM Lukasz Majewski wrote: > > > Attached commits provide cpufreq regression fixes for Trats and > > > Trats2 Exynos4 boards. > > > Since v3.12 Exynos4 uses common clock framework for clock > > > manipulation. Those patches restore correct output for > > > cpuinfo_cur_freq [1] sysfs attribute. > > > Without them, the [1] provides default frequency (800 MHz) set at > > > driver initialization. > > > > > > > > > Lukasz Majewski (2): > > > cpufreq: exynos4x12: Use the common clock framework to set APLL > > > clock rate > > > cpufreq: exynos4210: Use the common clock framework to set APLL > > > clock rate > > > > > > drivers/cpufreq/exynos4210-cpufreq.c | 67 > > > - > > > drivers/cpufreq/exynos4x12-cpufreq.c | 69 > > > -- 2 files changed, 16 > > > insertions(+), 120 deletions(-) > > > > Can you please resend [1/2], it got lost somewhere (at least I > > can't see it now)? > > Scratch this, it's there in patchwork. > Rafael, do you need any more help with those fixes? -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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 0/5] thermal: exynos: Fixes for v3.12
Eduardo, What's your opinion on this patch set? BTW, please send me all the urgent fixes for thermal soc drivers that you think should go to 3.12. Thanks, rui > -Original Message- > From: Lukasz Majewski [mailto:l.majew...@samsung.com] > Sent: Monday, October 14, 2013 1:47 PM > To: Zhang, Rui; Eduardo Valentin; kgene@samsung.com > Cc: Lukasz Majewski; Linux PM list; Lukasz Majewski; linux-kernel; > Bartlomiej Zolnierkiewicz; devicet...@vger.kernel.org; Amit Daniel > Kachhap; linux-samsung-...@vger.kernel.org > Subject: Re: [PATCH v2 0/5] thermal: exynos: Fixes for v3.12 > Importance: High > > Hi Zhang, Eduardo, > > > This patch series is divided into two parts: > > 1. Device tree node definition and enabelement for TMU at Exynos4412 > > (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4. > > Several commits were necessary to properly fix regression for TMU > test > > MUX address setting after reset. > > > > Test HW: > > - Exynos4412 - TRATS2 board (Linux v3.12-rc4) > > SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b > > > > > > Lukasz Majewski (5): > > thermal: exynos: Remove check for thermal device pointer at > > exynos_report_trigger() > > thermal: exynos: Provide separate TMU data for Exynos4412 > > thermal: exynos: Provide initial setting for TMU's test MUX address > > at Exynos4412 > > ARM: dts: exynos4x12: Device tree node definition for TMU on > > Exynos4x12 > > ARM: dts: exynos4412-trats2: Enable TMU support at Trats2 > > > > Zhang, Eduardo - any comments? > > Would it be possible to add them to v3.12 since they do fix critical > error and regression on Exynos4412. > > > > arch/arm/boot/dts/exynos4412-trats2.dts |5 > > arch/arm/boot/dts/exynos4x12.dtsi | 10 > > drivers/thermal/samsung/exynos_thermal_common.c |2 -- > > drivers/thermal/samsung/exynos_tmu.c| 12 ++--- > > drivers/thermal/samsung/exynos_tmu.h|7 +- > > drivers/thermal/samsung/exynos_tmu_data.c | 30 > > ++- > > drivers/thermal/samsung/exynos_tmu_data.h | 13 +- 7 > > files changed, 65 insertions(+), 14 deletions(-) > > > > > > -- > Best regards, > > Lukasz Majewski > > Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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 0/5] thermal: exynos: Fixes for v3.12
Hi Zhang, Eduardo, > This patch series is divided into two parts: > 1. Device tree node definition and enabelement for TMU at Exynos4412 > (Trats2) 2. Exynos thermal subsystem regressions for v3.12-rc4. > Several commits were necessary to properly fix regression for TMU > test MUX address setting after reset. > > Test HW: > - Exynos4412 - TRATS2 board (Linux v3.12-rc4) > SHA1: 8b5ede69d24db939f52b47e2f6fe1e83e08b > > > Lukasz Majewski (5): > thermal: exynos: Remove check for thermal device pointer at > exynos_report_trigger() > thermal: exynos: Provide separate TMU data for Exynos4412 > thermal: exynos: Provide initial setting for TMU's test MUX address > at Exynos4412 > ARM: dts: exynos4x12: Device tree node definition for TMU on > Exynos4x12 > ARM: dts: exynos4412-trats2: Enable TMU support at Trats2 > Zhang, Eduardo - any comments? Would it be possible to add them to v3.12 since they do fix critical error and regression on Exynos4412. > arch/arm/boot/dts/exynos4412-trats2.dts |5 > arch/arm/boot/dts/exynos4x12.dtsi | 10 > drivers/thermal/samsung/exynos_thermal_common.c |2 -- > drivers/thermal/samsung/exynos_tmu.c| 12 ++--- > drivers/thermal/samsung/exynos_tmu.h|7 +- > drivers/thermal/samsung/exynos_tmu_data.c | 30 > ++- > drivers/thermal/samsung/exynos_tmu_data.h | 13 +- 7 > files changed, 65 insertions(+), 14 deletions(-) > -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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] ARM: at91: add ssc dma parameter for at91sam9n12
Add ssc dma parameter for at91sam9n12 Signed-off-by: Bo Shen --- arch/arm/boot/dts/at91sam9n12.dtsi |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi index 9fb7ffd..6224f9f 100644 --- a/arch/arm/boot/dts/at91sam9n12.dtsi +++ b/arch/arm/boot/dts/at91sam9n12.dtsi @@ -437,6 +437,9 @@ compatible = "atmel,at91sam9g45-ssc"; reg = <0xf001 0x4000>; interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>; + dmas = < 0 AT91_DMA_CFG_PER_ID(21)>, + < 0 AT91_DMA_CFG_PER_ID(22)>; + dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <_ssc0_tx _ssc0_rx>; status = "disabled"; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ARM: at91: enable wm8904 on at91sam9n12ek board
Enable wm8904 codec on at91sam9n12ek board, which is connect
to i2c0 bus with 0x1a as address.
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12ek.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 27a9352..1ba8def 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -41,6 +41,11 @@
i2c0: i2c@f801 {
status = "okay";
+ wm8904: codec@1a {
+ compatible = "wm8904";
+ reg = <0x1a>;
+ };
+
qt1070: keyboard@1b {
compatible = "qt1070";
reg = <0x1b>;
--
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 4/5] ARM: at91: enable ssc on at91sam9n12ek board
Enable ssc on at91sam9n12ek board
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12ek.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 1ba8def..391c532 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -38,6 +38,10 @@
status = "okay";
};
+ ssc0: ssc@f001 {
+ status = "okay";
+ };
+
i2c0: i2c@f801 {
status = "okay";
--
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 1/5] ARM: at91: add at91sam9n12 ssc clock in look up table
Add at91sam9n12 ssc clock in look up table
Signed-off-by: Bo Shen
---
arch/arm/mach-at91/at91sam9n12.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index c7d670d..2d895a2 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -169,6 +169,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("t0_clk", "f8008000.timer", _clk),
CLKDEV_CON_DEV_ID("t0_clk", "f800c000.timer", _clk),
CLKDEV_CON_DEV_ID("mci_clk", "f0008000.mmc", _clk),
+ CLKDEV_CON_DEV_ID(NULL, "f001.ssc", _clk),
CLKDEV_CON_DEV_ID("dma_clk", "ec00.dma-controller", _clk),
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", _clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", _clk),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ARM: at91: add sound support on at91sam9n12ek board
Add sound support on at91sam9n12ek board with wm8904 as codec.
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12ek.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 391c532..e9487f6 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -91,6 +91,13 @@
;
};
};
+
+ sound {
+ pinctrl_pck0_as_audio_mck:
pck0_as_audio_mck {
+ atmel,pins =
+ ;
+ };
+ };
};
spi0: spi@f000 {
@@ -151,4 +158,22 @@
gpio-key,wakeup;
};
};
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ AT91SAM9N12";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <>;
+ atmel,audio-codec = <>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] ARM:at91:enable sound on at91sam9n12ek board
This patch series enable sound on at91sam9n12ek board with wm8904 codec Bo Shen (5): ARM: at91: add at91sam9n12 ssc clock in look up table ARM: at91: add ssc dma parameter for at91sam9n12 ARM: at91: enable wm8904 on at91sam9n12ek board ARM: at91: enable ssc on at91sam9n12ek board ARM: at91: add sound support on at91sam9n12ek board arch/arm/boot/dts/at91sam9n12.dtsi |3 +++ arch/arm/boot/dts/at91sam9n12ek.dts | 34 ++ arch/arm/mach-at91/at91sam9n12.c|1 + 3 files changed, 38 insertions(+) -- 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 4/4] sound/soc/atmel: don't use devm_pinctrl_get_select_default() in probe
Hi Wolfram Sang, On 10/14/2013 00:17, Wolfram Sang wrote: Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Acked-by: Linus Walleij (personally at LCE13) Signed-off-by: Wolfram Sang --- sound/soc/atmel/atmel_wm8904.c | 8 1 file changed, 8 deletions(-) Tested OK on at91sam9n12ek and sama5d3xek board. Thanks. Acked-by: Bo Shen Best Regards, Bo Shen -- 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] max17042_battery: use SIMPLE_DEV_PM_OPS
Use the SIMPLE_DEV_PM_OPS macro to declare the driver's
pm_ops.
Signed-off-by: Manish Badarkhe
---
:100644 100644 d664ef5... bd72b0f... M drivers/power/max17042_battery.c
drivers/power/max17042_battery.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index d664ef5..bd72b0f 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -786,7 +786,7 @@ static int max17042_remove(struct i2c_client *client)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int max17042_suspend(struct device *dev)
{
struct max17042_chip *chip = dev_get_drvdata(dev);
@@ -816,17 +816,11 @@ static int max17042_resume(struct device *dev)
return 0;
}
-
-static const struct dev_pm_ops max17042_pm_ops = {
- .suspend= max17042_suspend,
- .resume = max17042_resume,
-};
-
-#define MAX17042_PM_OPS (_pm_ops)
-#else
-#define MAX17042_PM_OPS NULL
#endif
+static SIMPLE_DEV_PM_OPS(max17042_pm_ops, max17042_suspend,
+ max17042_resume);
+
#ifdef CONFIG_OF
static const struct of_device_id max17042_dt_match[] = {
{ .compatible = "maxim,max17042" },
@@ -849,7 +843,7 @@ static struct i2c_driver max17042_i2c_driver = {
.driver = {
.name = "max17042",
.of_match_table = of_match_ptr(max17042_dt_match),
- .pm = MAX17042_PM_OPS,
+ .pm = _pm_ops,
},
.probe = max17042_probe,
.remove = max17042_remove,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/9] Thermal: Check for validity before doing kfree
On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> The thermal_release function is called whenever
> any device belonging to 'thermal' class unregisters.
> This function performs kfree(cdev) without any check.
> In cases where there are more device registrations
> other than just 'thermal_zone' and 'cooling_device'
> this might accidently free memory allocated them
> silently; and cause memory errors.
>
> This patch changes this behavior by doing
> kfree(cdev) only when the device pointer belongs
> to a real cdev i.e. cooling_device.
>
> Signed-off-by: Durgadoss R
applied to thermal -next.
thanks,
rui
> ---
> drivers/thermal/thermal_core.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 1f02e8e..8c5131d 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1280,7 +1280,8 @@ static void thermal_release(struct device *dev)
>sizeof("thermal_zone") - 1)) {
> tz = to_thermal_zone(dev);
> kfree(tz);
> - } else {
> + } else if(!strncmp(dev_name(dev), "cooling_device",
> + sizeof("cooling_device") - 1)){
> cdev = to_cooling_device(dev);
> kfree(cdev);
> }
--
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/8] ACPI, APEI, CPER: Cleanup CPER memory error output format
On Fri, Oct 11, 2013 at 06:02:08PM +0200, Borislav Petkov wrote:
> Date: Fri, 11 Oct 2013 18:02:08 +0200
> From: Borislav Petkov
> To: "Chen, Gong"
> Cc: tony.l...@intel.com, linux-kernel@vger.kernel.org,
> linux-a...@vger.kernel.org
> Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output
> format
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Fri, Oct 11, 2013 at 02:32:45AM -0400, Chen, Gong wrote:
> > Keep up only the most important fields for memory error
> > reporting. The detail information will be moved to perf/trace
> > interface.
> >
> > Suggested-by: Tony Luck
> > Signed-off-by: Chen, Gong
> > ---
> > drivers/acpi/apei/cper.c | 42 ++
> > 1 file changed, 14 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> > index 2a4389f..567410e 100644
> > --- a/drivers/acpi/apei/cper.c
> > +++ b/drivers/acpi/apei/cper.c
> > @@ -206,29 +206,29 @@ static void cper_print_mem(const char *pfx, const
> > struct cper_sec_mem_err *mem)
> > printk("%s""physical_address_mask: 0x%016llx\n",
> >pfx, mem->physical_addr_mask);
> > if (mem->validation_bits & CPER_MEM_VALID_NODE)
> > - printk("%s""node: %d\n", pfx, mem->node);
> > + pr_debug("node: %d\n", mem->node);
> > if (mem->validation_bits & CPER_MEM_VALID_CARD)
> > - printk("%s""card: %d\n", pfx, mem->card);
> > + pr_debug("card: %d\n", mem->card);
> > if (mem->validation_bits & CPER_MEM_VALID_MODULE)
> > - printk("%s""module: %d\n", pfx, mem->module);
> > + pr_debug("module: %d\n", mem->module);
> > if (mem->validation_bits & CPER_MEM_VALID_RANK_NUMBER)
> > - printk("%s""rank: %d\n", pfx, mem->rank);
> > + pr_debug("rank: %d\n", mem->rank);
> > if (mem->validation_bits & CPER_MEM_VALID_BANK)
> > - printk("%s""bank: %d\n", pfx, mem->bank);
> > + pr_debug("bank: %d\n", mem->bank);
> > if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
> > - printk("%s""device: %d\n", pfx, mem->device);
> > + pr_debug("device: %d\n", mem->device);
> > if (mem->validation_bits & CPER_MEM_VALID_ROW)
> > - printk("%s""row: %d\n", pfx, mem->row);
> > + pr_debug("row: %d\n", mem->row);
> > if (mem->validation_bits & CPER_MEM_VALID_COLUMN)
> > - printk("%s""column: %d\n", pfx, mem->column);
> > + pr_debug("column: %d\n", mem->column);
> > if (mem->validation_bits & CPER_MEM_VALID_BIT_POSITION)
> > - printk("%s""bit_position: %d\n", pfx, mem->bit_pos);
> > + pr_debug("bit_position: %d\n", mem->bit_pos);
> > if (mem->validation_bits & CPER_MEM_VALID_REQUESTOR_ID)
> > - printk("%s""requestor_id: 0x%016llx\n", pfx, mem->requestor_id);
> > + pr_debug("requestor_id: 0x%016llx\n", mem->requestor_id);
> > if (mem->validation_bits & CPER_MEM_VALID_RESPONDER_ID)
> > - printk("%s""responder_id: 0x%016llx\n", pfx, mem->responder_id);
> > + pr_debug("responder_id: 0x%016llx\n", mem->responder_id);
> > if (mem->validation_bits & CPER_MEM_VALID_TARGET_ID)
> > - printk("%s""target_id: 0x%016llx\n", pfx, mem->target_id);
> > + pr_debug("target_id: 0x%016llx\n", mem->target_id);
> > if (mem->validation_bits & CPER_MEM_VALID_ERROR_TYPE) {
> > u8 etype = mem->error_type;
> > printk("%s""error_type: %d, %s\n", pfx, etype,
>
> Hmm, so this cper_print_mem is called for CPER_SEC_PLATFORM_MEM section
> type.
>
> With the change above, the other caller __ghes_print_estatus() won't see
> the error messages if they're debug. Do we want that?
>
Because most of data in CPER are empty or unimportant. To avoid too much
disturbance to end users, it is worthy to do that. Moreover, I reserve
another way via trace to show these data.
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
signature.asc
Description: Digital signature
Re: [PATCH v2 2/2] x86/efi: Add EFI framebuffer earlyprintk support
On Sat, 12 Oct, at 07:56:15PM, Ingo Molnar wrote:
> > +static void early_efi_write_char(u32 *dst, unsigned char c, unsigned int h)
> > +{
> > + const u32 color_black = 0x;
> > + const u32 color_grey = 0x00aa;
>
> I still think this should be white - that should be more visible than
> grey, especially in brightly lit places. (And I'm really sorry about nerds
> in the basement getting eye damage.)
>
> Also, what is the highest byte typically, can that ever be part of
> multiple framebuffers and can it mean an alpha channel? If yes then '0x00'
> (read: fully translucent) might not be the best of choices for console
> output. In that case -1 (0x) would work in a natural way.
>
> (If it's reserved bits then it has to be all zeroes.)
The GOP part of the spec says that the top byte is reserved, and must be
set to zero, and looking at the efifb driver it disables transparency
support when allocating the color map,
int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp)
[...]
if ((err = fb_alloc_cmap(>cmap, 256, 0)) < 0) {
printk(KERN_ERR "efifb: cannot allocate colormap\n");
goto err_unmap;
}
--
Matt Fleming, 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: [PATCH v2] tools/perf/util: Fix memory leak in trace-event-info.c
Hi Felipe,
On Thu, 10 Oct 2013 22:21:29 -0300, Felipe Pena wrote:
> Fix for a memory leak on tracing_data_get() function when returning NULL
> explicitly
>
> Signed-off-by: Felipe Pena
> ---
> tools/perf/util/trace-event-info.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/trace-event-info.c
> b/tools/perf/util/trace-event-info.c
> index f3c9e55..2a0c3c9 100644
> --- a/tools/perf/util/trace-event-info.c
> +++ b/tools/perf/util/trace-event-info.c
> @@ -518,13 +518,15 @@ struct tracing_data *tracing_data_get(struct list_head
> *pattrs,
>"/tmp/perf-XX");
> if (!mkstemp(tdata->temp_file)) {
> pr_debug("Can't make temp file");
> - return NULL;
> + err = -1;
> + goto err_tdata;
> }
>
> temp_fd = open(tdata->temp_file, O_RDWR);
> if (temp_fd < 0) {
> pr_debug("Can't read '%s'", tdata->temp_file);
> - return NULL;
> + err = -1;
> + goto err_tdata;
I'd rather initialize err to -1 at the beginning. And the malloc of
tdata should also be handled like this.
Thanks,
Namhyung
> }
>
> /*
> @@ -562,6 +564,7 @@ out:
> output_fd = fd;
> }
>
> +err_tdata:
> if (err) {
> free(tdata);
> tdata = NULL;
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mmap for /proc/vmcore broken since 3.12-rc1
(2013/10/13 5:32), Alexey Dobriyan wrote:
On Wed, Oct 09, 2013 at 07:14:55PM +0900, HATAYAMA Daisuke wrote:
Hello,
(2013/10/08 21:49), Alexey Dobriyan wrote:
On Mon, Oct 7, 2013 at 5:42 AM, HATAYAMA Daisuke
wrote:
+static unsigned long
+get_unmapped_area_vmcore(struct file *filp, unsigned long addr,
+unsigned long len, unsigned long pgoff,
+unsigned long flags)
+{
+#ifdef CONFIG_MMU
+ return current->mm->get_unmapped_area(filp, addr, len, pgoff,
flags);
+#else
+ return -EIO;
+#endif
+}
+
static const struct file_operations proc_vmcore_operations = {
.read = read_vmcore,
.llseek = default_llseek,
.mmap = mmap_vmcore,
+ .get_unmapped_area = get_unmapped_area_vmcore,
I think current->mm->get_unmapped_area should be used by core proc code.
What do you actually suggest here? You mean moving this code in proc code?
I don't think you suggest so.
Please, try this patch, I don't have kexec setup handy.
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -291,7 +291,11 @@ static unsigned long proc_reg_get_unmapped_area(struct
file *file, unsigned long
int rv = -EIO;
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
unsigned long, unsigned long, unsigned long);
if (use_pde(pde)) {
- get_unmapped_area = pde->proc_fops->get_unmapped_area;
+ get_unmapped_area = current->mm->get_unmapped_area;
+#ifdef CONFIG_MMU
+ if (pde->proc_fops->get_unmapped_area)
+ get_unmapped_area = pde->proc_fops->get_unmapped_area;
+#endif
if (get_unmapped_area)
rv = get_unmapped_area(file, orig_addr, len, pgoff,
flags);
unuse_pde(pde);
Slight modification to #ifdef ...
get_unmapped_area = NULL;
#ifdef CONFIG_MMU
get_unmapped_area = current->mm->get_unmapped_area
#endif
if (pde->proc_fops->get_unmapped_area)
get_unmapped_area = pde->proc_fops->get_unmapped_area;
And, I found the bug. The variable rv should have been defined as unsigned
long. sizeof(int) is 4 bytes but sizeof(long) is 8 bytes at least on x86_64.
The reason why returned value looked like kernel virtual address was due to
signed extension performed during conversion from negative 32-bit signed
integer to 64-bit unsigned long integer.
Hmm, I first checked signature of related functions but overlooked...
Anyway, I'll post fixing patch soon.
--
Thanks.
HATAYAMA, Daisuke
--
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: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v5)
On Sun, 13 Oct 2013 14:34:44 +0200, Jiri Olsa wrote: > I put perf archive and data output in here if you're interested: > http://people.redhat.com/jolsa/cc/ I can't download the data output (but the archive is fine). $ curl http://people.redhat.com/jolsa/cc/perf.data 403 Forbidden Forbidden You don't have permission to access /jolsa/cc/perf.data on this server. Apache Server at people.redhat.com Port 80 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: [PATCH] x86: Run checksumming in parallel accross multiple alu's
Neil Horman writes: > Sébastien Dugué reported to me that devices implementing ipoib (which don't > have > checksum offload hardware were spending a significant amount of time computing Must be an odd workload, most TCP/UDP workloads do copy-checksum anyways. I would rather investigate why that doesn't work. That said the change looks reasonable, but may not fix the root cause. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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] regmap: irq: clear status when disable irq
clear the status bit if the mask register doesn't prevent
the chip level irq from being asserted
OR in the following sequence, there will be irq storm happens:
1) interrupt is triggered;
2) another thread disables it(the mask bit is set);
3) _Then_ the interrupt thread is not ACKed(the status bit is not cleared),
and it's ignored;
4) if the irq is still asserted because of the uncleared status bit,
the irq storm happens;
Change-Id: I371201f365c5a8470073a393068cfeb4e3d14a03
Signed-off-by: Yi Zhang
---
drivers/base/regmap/regmap-irq.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index d10456f..cd655b8 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -105,6 +105,27 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
"Failed to sync wakes in %x: %d\n",
reg, ret);
}
+
+ if (!d->chip->init_ack_masked)
+ continue;
+
+ /* Ack masked but set interrupts */
+ reg = d->chip->status_base +
+ (i * map->reg_stride * d->irq_reg_stride);
+ ret = regmap_read(d->map, reg, >status_buf[i]);
+ if (ret != 0)
+ dev_err(d->map->dev, "Failed to read IRQ status: %d\n",
+ ret);
+
+ if (d->status_buf[i] && d->chip->ack_base) {
+ reg = d->chip->ack_base +
+ (i * map->reg_stride * d->irq_reg_stride);
+ ret = regmap_write(d->map, reg,
+ d->status_buf[i] & d->mask_buf[i]);
+ if (ret != 0)
+ dev_err(d->map->dev, "Failed to ack 0x%x: %d\n",
+ reg, ret);
+ }
}
if (d->chip->runtime_pm)
--
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] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On 10/14/2013 11:49 AM, Lennart Poettering wrote:
> On Mon, 14.10.13 10:36, Aaron Lu (aaron...@intel.com) wrote:
>
>>> - Backlight control doesn't work via ACPI without acpi_osi="!Windows 2012"
>>> - Backlight control doesn't work via ACPI with acpi_osi="!Windows 2012"
>>> - Backlight control doesn't work via EC commands from ideapad-laptop.c
>>>
>>> The only way backlight handling is supported on the Yoga 13 is via the
>>> intel video driver.
>>
>> Since I don't have access to the acpidump of this system, my only
>> question is, does the firmware has a _OSI("Windows 2012") query in DSDT
>> table?
>
> Yes, it appears to do that as part of _OSC.
>
> The disassembled DSDT table is here:
>
> http://0pointer.de/public/yoga13-dsdt.dsl
Thanks for the info. The firmware has a _OSI("Windows 2012") query so
should be covered by my patch.
>
>>> Or in other words: the situation for the Yoga 13 is *unrelated* to the
>>> Windows 8 issues, and your patch.
>>
>> I think they are related...
>> If the firmware is compatible to Windows 8, then my patch will disable
>> ACPI video backlight interface to prefer GPU's interface.
>
> OK, that might indeed work.
>
>>> I'll soon send another patch which also blacklists the thing in the
>>> ideapad driver, so that only the intel backlight driver is enabled on
>>> Yoga 13 systems, at which point everything will work fine.
>>
>> Right, that is needed. And if going with my patch, the ideapad driver
>> will need to be patched similarly like thinkpad_acpi to add a check of
>> acpi_video_backlight_support before it decides to register its own
>> backlight interface.
>
> The ideapad driver currently skips registration of the backlight device
> if acpi_video_backlight_support() returns true. is that all you need?
Yes, that's all.
>
> Hmm, regarding your patch series, do you plan to skip the registration
> of the acpi backlight device if the "raw" device is supported? I mean,
Yes, that's right.
> the intel driver could be compiled as a module (and generally is on the
> popular distros), so at the time the ACPI subsystem wants to register
> the backlight device and know if a raw backlight device is around it
> never will be, so what is the point of that? Or am I missing something?
For systems with Intel i915 GPU, ACPI video will wait for GPU driver to
run first, see drivers/acpi/video.c acpi_video_init, the actual
acpi_video_register function is called by i915 driver in
i915_driver_load due to operation region related stuff. Since all
problematic systems reported so far has an Intel GPU, I'm doing it this
way now. If things change, we can enhance it then.
-Aaron
--
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] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On Mon, 14.10.13 10:36, Aaron Lu (aaron...@intel.com) wrote:
> > - Backlight control doesn't work via ACPI without acpi_osi="!Windows 2012"
> > - Backlight control doesn't work via ACPI with acpi_osi="!Windows 2012"
> > - Backlight control doesn't work via EC commands from ideapad-laptop.c
> >
> > The only way backlight handling is supported on the Yoga 13 is via the
> > intel video driver.
>
> Since I don't have access to the acpidump of this system, my only
> question is, does the firmware has a _OSI("Windows 2012") query in DSDT
> table?
Yes, it appears to do that as part of _OSC.
The disassembled DSDT table is here:
http://0pointer.de/public/yoga13-dsdt.dsl
> > Or in other words: the situation for the Yoga 13 is *unrelated* to the
> > Windows 8 issues, and your patch.
>
> I think they are related...
> If the firmware is compatible to Windows 8, then my patch will disable
> ACPI video backlight interface to prefer GPU's interface.
OK, that might indeed work.
> > I'll soon send another patch which also blacklists the thing in the
> > ideapad driver, so that only the intel backlight driver is enabled on
> > Yoga 13 systems, at which point everything will work fine.
>
> Right, that is needed. And if going with my patch, the ideapad driver
> will need to be patched similarly like thinkpad_acpi to add a check of
> acpi_video_backlight_support before it decides to register its own
> backlight interface.
The ideapad driver currently skips registration of the backlight device
if acpi_video_backlight_support() returns true. is that all you need?
Hmm, regarding your patch series, do you plan to skip the registration
of the acpi backlight device if the "raw" device is supported? I mean,
the intel driver could be compiled as a module (and generally is on the
popular distros), so at the time the ACPI subsystem wants to register
the backlight device and know if a raw backlight device is around it
never will be, so what is the point of that? Or am I missing something?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] DMI: Parse memory device (type 17) in SMBIOS
On Fri, Oct 11, 2013 at 05:40:48PM +0200, Borislav Petkov wrote:
> Date: Fri, 11 Oct 2013 17:40:48 +0200
> From: Borislav Petkov
> To: "Chen, Gong"
> Cc: tony.l...@intel.com, linux-kernel@vger.kernel.org,
> linux-a...@vger.kernel.org
> Subject: Re: [PATCH 4/8] DMI: Parse memory device (type 17) in SMBIOS
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Fri, Oct 11, 2013 at 02:32:42AM -0400, Chen, Gong wrote:
> > This patch adds a new interface to decode memory device (type 17)
> > to help error reporting on DIMMs.
> >
> > Original-author: Tony Luck
> > Signed-off-by: Chen, Gong
>
> Reviewed-by: Borislav Petkov
>
> Just a question below:
>
> > ---
> > arch/ia64/kernel/setup.c| 1 +
> > arch/x86/kernel/setup.c | 1 +
> > drivers/firmware/dmi_scan.c | 60
> > +
> > include/linux/dmi.h | 5
> > 4 files changed, 67 insertions(+)
> >
>
> [ ... ]
>
> > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> > index fa0affb..ca3619d 100644
> > --- a/drivers/firmware/dmi_scan.c
> > +++ b/drivers/firmware/dmi_scan.c
> > @@ -25,6 +25,13 @@ static int dmi_initialized;
> > /* DMI system identification string used during boot */
> > static char dmi_ids_string[128] __initdata;
> >
> > +static struct dmi_memdev_info {
> > + const char *device;
> > + const char *bank;
> > + u16 handle;
> > +} *dmi_memdev;
> > +static int dmi_memdev_nr;
> > +
> > static const char * __init dmi_string_nosave(const struct dmi_header *dm,
> > u8 s)
> > {
> > const u8 *bp = ((u8 *) dm) + dm->length;
> > @@ -322,6 +329,42 @@ static void __init dmi_save_extended_devices(const
> > struct dmi_header *dm)
> > dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
> > }
> >
> > +static void __init count_mem_devices(const struct dmi_header *dm, void *v)
> > +{
> > + if (dm->type != DMI_ENTRY_MEM_DEVICE)
> > + return;
> > + dmi_memdev_nr++;
> > +}
> > +
> > +static void __init save_mem_devices(const struct dmi_header *dm, void *v)
> > +{
> > + const char *d = (const char *)dm;
> > + static int nr;
> > +
> > + if (dm->type != DMI_ENTRY_MEM_DEVICE)
> > + return;
> > + if (nr >= dmi_memdev_nr) {
> > + pr_warn_once("Too many DIMM entries in SMBIOS table\n");
> > + return;
>
> Is this and count_mem_devices() some sort of precaution against insane
> DMI tables?
>
Yes, but we highly expect BIOS manufactors to make is valid and complete.
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
signature.asc
Description: Digital signature
Re: [PATCH] dma: misc: remove deprecated IRQF_DISABLED
Hi Vinod, On 10/13/2013 04:54 PM, Vinod Koul wrote: > On Sun, Oct 13, 2013 at 07:10:51AM +0200, Michael Opdenacker wrote: >> This patch proposes to remove the use of the IRQF_DISABLED flag >> >> It's a NOOP since 2.6.35 and it will be removed one day. > Applied, thanks. Title shouldnt have misc as it doesnt convey anything. Thanks! Indeed, I sent separate patches for files which had different maintainers, and grouped the patches for files which shared the same maintainer information. I put "misc" to avoid suggesting that the patch is for everything under drivers/dma/, which is not the case. Wouldn't it have been confusing otherwise? Thanks again, Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] ACPI, x86: Extended error log driver for x86 platform
On Fri, Oct 11, 2013 at 05:24:52PM +0200, Borislav Petkov wrote: > Date: Fri, 11 Oct 2013 17:24:52 +0200 > From: Borislav Petkov > To: "Chen, Gong" > Cc: tony.l...@intel.com, linux-kernel@vger.kernel.org, > linux-a...@vger.kernel.org > Subject: Re: [PATCH 3/8] ACPI, x86: Extended error log driver for x86 > platform > User-Agent: Mutt/1.5.21 (2010-09-15) > > On Fri, Oct 11, 2013 at 02:32:41AM -0400, Chen, Gong wrote: > > This error log driver (a.k.a eMCA driver) is implemented based on > > http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html. > > After errors are captured, more valuable information can be > > got with this new enhanced error log driver. > > > > Signed-off-by: Chen, Gong > > --- > > arch/x86/include/asm/mce.h | 5 + > > arch/x86/kernel/cpu/mcheck/mce.c | 10 ++ > > drivers/acpi/Kconfig | 8 + > > drivers/acpi/Makefile| 2 + > > drivers/acpi/acpi_extlog.c | 339 > > +++ > > drivers/acpi/bus.c | 3 +- > > include/linux/acpi.h | 1 + > > 7 files changed, 367 insertions(+), 1 deletion(-) > > create mode 100644 drivers/acpi/acpi_extlog.c > > > > diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h > > index cbe6b9e..f8c33e2 100644 > > --- a/arch/x86/include/asm/mce.h > > +++ b/arch/x86/include/asm/mce.h > > @@ -12,6 +12,7 @@ > > #define MCG_CTL_P (1ULL<<8)/* MCG_CTL register available */ > > #define MCG_EXT_P (1ULL<<9)/* Extended registers available */ > > #define MCG_CMCI_P (1ULL<<10) /* CMCI supported */ > > +#define MCG_EXT_ERR_LOG(1ULL<<26) /* Extended error log > > supported */ > > #define MCG_EXT_CNT_MASK 0xff /* Number of Extended registers */ > > #define MCG_EXT_CNT_SHIFT 16 > > #define MCG_EXT_CNT(c) (((c) & MCG_EXT_CNT_MASK) >> > > MCG_EXT_CNT_SHIFT) > > Let's keep them numerically sorted by the bit numbers so put > MCG_EXT_ERR_LOG after bit 24, MCG_SER_P. > > Besides, this bit should be called MCG_ELOG_P as it is in the docs > although your name is much more descriptive than what the hw guys came > up with but I know they like to abbreviate to the lowest letter count > possible :) > > > @@ -204,6 +205,10 @@ extern void mce_disable_bank(int bank); > > * Exception handler > > */ > > > > +extern spinlock_t mce_elog_lock; > > Uuh, I don't think we want to expose the naked spinlock. Rather, we'd > need a couple of functions > > mce_elog_lock > mce_elog_unlock > > which get called by users. > > Actually, it would be even better to keep all those details private > to acpi_extlog.c and have machine_check_poll() call extlog_print() > and in the cases where there's no extlog support, you have an empty > extlog_print function. > But this driver can be loaded as a module. If this module is unloaded, extlog_print is gone. I can't keep such a pointer internally. > > +extern int (*mce_extlog_support)(void); > > Unused leftover? > Yes, it should be deleted. > > +/* Call the installed extended error log print function */ > > +extern int (*mce_ext_err_print)(const char *, int cpu, int bank); > > /* Call the installed machine check handler for this CPU setup. */ > > extern void (*machine_check_vector)(struct pt_regs *, long error_code); > > void do_machine_check(struct pt_regs *, long); > > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c > > b/arch/x86/kernel/cpu/mcheck/mce.c > > index b3218cd..6802637 100644 > > --- a/arch/x86/kernel/cpu/mcheck/mce.c > > +++ b/arch/x86/kernel/cpu/mcheck/mce.c > > @@ -48,6 +48,12 @@ > > > > #include "mce-internal.h" > > > > +DEFINE_SPINLOCK(mce_elog_lock); > > +EXPORT_SYMBOL_GPL(mce_elog_lock); > > Yeah, private to acpi_extlog and it can be simply 'elog_lock' there, > without the "mce_" prefix. > > > + > > +int (*mce_ext_err_print)(const char *, int, int) = NULL; > > +EXPORT_SYMBOL_GPL(mce_ext_err_print); > > + > > static DEFINE_MUTEX(mce_chrdev_read_mutex); > > > > #define rcu_dereference_check_mce(p) \ > > @@ -624,6 +630,10 @@ void machine_check_poll(enum mcp_flags flags, > > mce_banks_t *b) > > (m.status & (mca_cfg.ser ? MCI_STATUS_S : MCI_STATUS_UC))) > > continue; > > > > + spin_lock(_elog_lock); > > + if (mce_ext_err_print) > > + mce_ext_err_print(NULL, m.extcpu, i); > > + spin_unlock(_elog_lock); > > private to acpi_extlog.c > > > mce_read_aux(, i); > > > > if (!(flags & MCP_TIMESTAMP)) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > > index 22327e6..1465fa8 100644 > > --- a/drivers/acpi/Kconfig > > +++ b/drivers/acpi/Kconfig > > @@ -372,4 +372,12 @@ config ACPI_BGRT > > > > source "drivers/acpi/apei/Kconfig" > > > > +config ACPI_EXTLOG > > + tristate "Extended Error Log support" > > + depends on X86 && X86_MCE > > I guess we can
Re: [PATCH] acpi: update win8 OSI blacklist
On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras wrote: > More people have reported they need this for their machines to work > correctly. > > https://bugzilla.kernel.org/show_bug.cgi?id=60682 I see this was merged to the linux-next branch. Is there any reason why it's not proposed for v3.12? -- Felipe Contreras -- 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 RESEND 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
2013/10/11 Dave Chinner :
> On Thu, Oct 10, 2013 at 04:00:13PM +0900, Namjae Jeon wrote:
>> >
>> > /*
>> > * Shift extent records to the left to cover a hole.
>> > *
>> > * The maximum number of extents to be shifted in a single operation
>> > * is @count, and @current_ext keeps track of the current extent
>> > * index we have shifted. If there is no hole to shift the extents
>> > * into, then we abort immediately.
>> > */
>> Thanks for your help. I will change this comment instead of original one.
>>
>> >> +int
>> >> +xfs_bmap_shift_extents(
>> >> + struct xfs_trans*tp,
>> >> + struct xfs_inode*ip,
>> >> + int *done,
>> >> + xfs_fileoff_t start_fsb,
>> >> + xfs_fileoff_t shift,
>> >
>> > Shift means ...? Number of extents to shift, a length, a number of
>> > block, or something else?
>> Ah, yes, shift_len would be a more proper name
>
> I'm not sure that's a lot better. What are we shifting? We are
> shifting the offset of the blocks, right? And the unit is in fsb?
> So perhaps offset_shift_fsb, and add that to the description of the
> function above?
Okay, I will change it as your suggestion.
>
>> >> + /*
>> >> + * Before shifting extent into hole, make sure that the hole
>> >> + * is large enough to accomodate the shift.
>> >> + */
>> >> + if (*current_ext) {
>> >> + state |= BMAP_LEFT_VALID;
>> >> + xfs_bmbt_get_all(xfs_iext_get_ext(ifp,
>> >> + *current_ext - 1), );
>> >> +
>> >> + if (isnullstartblock(left.br_startblock))
>> >> + state |= BMAP_LEFT_DELAY;
>> >> +
>> >> + if (startoff < left.br_startoff +
>> >> left.br_blockcount)
>> >> + error = XFS_ERROR(EFSCORRUPTED);
>> >
>> > Why is the filesystem corrupted if the shift we asked for is too
>> > large for the hole in the file? I haven't seen any checks before
>> > this that guarantee that the hole is big enough for the shift...
>>
>> we call xfs_free_file_space to free enough blocks for shifting.
>> If still the space is not big enough will it be considered as fs corrupted?
>> What error could we return in this case?
>
> Hole punching rounds inwards, and the amount of rounding is not
> necessarily the nearest filesystem block. Again it's the block size
> smaller than page size case that will trip you over here, as the
> rounding when punching holes will be done to page size, not
> filesystem block size. Hence it's entirely possible that your
> calculated shift start and lengths don't match the size of the hole
> that was punched.
>
> That doesn't mean there was a corruption - just that the hole wasn't
> the size and shape that was expected
Right. I will consider your points.
Thanks very much for your valuable comments.
>
> 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: [PATCH] usb/hcd: remove unnecessary local_irq_save
Hi Alan,
On 10/13/2013 05:35 PM, Alan Stern wrote:
> On Sun, 13 Oct 2013, Michael Opdenacker wrote:
>
>> Remove the use of local_irq_save() and IRQF_DISABLED, no longer needed since
>> interrupt handlers are always run with interrupts disabled on the
>> current CPU.
>>
>> Tested successfully with 3.12.0-rc4 on my PC. Didn't find
>> any issue because of this change.
>>
>> Signed-off-by: Michael Opdenacker
>> ---
>> drivers/usb/core/hcd.c | 15 ---
>> 1 file changed, 15 deletions(-)
> How about removing all the other unnecessary usages of IRQF_DISABLED
> under drivers/usb while you're at it?
I believe I already did, through patches sent on Oct. 6:
drivers/usb/gadget/mv_u3d_core.c: IRQF_DISABLED |
IRQF_SHARED, driver_name, u3d)) {
=> Sent fix on Oct. 6, 2013
drivers/usb/host/uhci-platform.c: ret = usb_add_hcd(hcd,
pdev->resource[1].start, IRQF_DISABLED |
=> Sent fix on Oct. 6, 2013
Cheers,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
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 staging-next] staging: lustre: Use parenthesis around sizeof
Convert sizeof foo to sizeof(foo) to be more kernel style compatible.
Signed-off-by: Joe Perches
---
drivers/staging/lustre/lustre/fld/fld_cache.c | 2 +-
drivers/staging/lustre/lustre/include/cl_object.h | 12 +++
drivers/staging/lustre/lustre/include/lclient.h| 4 +--
.../lustre/lustre/include/lustre/lustre_idl.h | 42 +-
drivers/staging/lustre/lustre/include/lustre_fid.h | 2 +-
drivers/staging/lustre/lustre/include/obd.h| 2 +-
.../staging/lustre/lustre/include/obd_support.h| 18 +-
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 2 +-
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++--
.../lustre/lustre/libcfs/linux/linux-debug.c | 2 +-
drivers/staging/lustre/lustre/llite/file.c | 4 +--
drivers/staging/lustre/lustre/llite/llite_lib.c| 4 +--
drivers/staging/lustre/lustre/llite/rw.c | 2 +-
drivers/staging/lustre/lustre/lov/lov_dev.c| 8 ++---
drivers/staging/lustre/lustre/lov/lov_internal.h | 2 +-
drivers/staging/lustre/lustre/lov/lov_io.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_lock.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_object.c | 4 +--
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +-
drivers/staging/lustre/lustre/lov/lov_request.c| 4 +--
drivers/staging/lustre/lustre/obdclass/cl_io.c | 6 ++--
drivers/staging/lustre/lustre/obdclass/class_obd.c | 2 +-
drivers/staging/lustre/lustre/obdclass/llog_test.c | 6 ++--
drivers/staging/lustre/lustre/obdclass/lu_object.c | 13 +++
.../staging/lustre/lustre/obdclass/obd_config.c| 6 ++--
drivers/staging/lustre/lustre/obdclass/uuid.c | 4 +--
.../staging/lustre/lustre/obdecho/echo_client.c| 2 +-
drivers/staging/lustre/lustre/osc/osc_lock.c | 2 +-
drivers/staging/lustre/lustre/osc/osc_page.c | 2 +-
drivers/staging/lustre/lustre/osc/osc_request.c| 2 +-
drivers/staging/lustre/lustre/ptlrpc/client.c | 4 +--
drivers/staging/lustre/lustre/ptlrpc/import.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/layout.c | 2 +-
drivers/staging/lustre/lustre/ptlrpc/service.c | 8 ++---
35 files changed, 101 insertions(+), 92 deletions(-)
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 25099cb..4531510 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -267,7 +267,7 @@ void fld_cache_punch_hole(struct fld_cache *cache,
const seqno_t new_end = range->lsr_end;
struct fld_cache_entry *fldt;
- OBD_ALLOC_GFP(fldt, sizeof *fldt, GFP_ATOMIC);
+ OBD_ALLOC_GFP(fldt, sizeof(*fldt), GFP_ATOMIC);
if (!fldt) {
OBD_FREE_PTR(f_new);
/* overlap is not allowed, so dont mess up list. */
diff --git a/drivers/staging/lustre/lustre/include/cl_object.h
b/drivers/staging/lustre/lustre/include/cl_object.h
index edb40af..c485206 100644
--- a/drivers/staging/lustre/lustre/include/cl_object.h
+++ b/drivers/staging/lustre/lustre/include/cl_object.h
@@ -3096,13 +3096,13 @@ struct cl_io *cl_io_top(struct cl_io *io);
void cl_io_print(const struct lu_env *env, void *cookie,
lu_printer_t printer, const struct cl_io *io);
-#define CL_IO_SLICE_CLEAN(foo_io, base) \
-do { \
- typeof(foo_io) __foo_io = (foo_io); \
+#define CL_IO_SLICE_CLEAN(foo_io, base)
\
+do { \
+ typeof(foo_io) __foo_io = (foo_io); \
\
- CLASSERT(offsetof(typeof(*__foo_io), base) == 0); \
- memset(&__foo_io->base + 1, 0,\
- (sizeof *__foo_io) - sizeof __foo_io->base); \
+ CLASSERT(offsetof(typeof(*__foo_io), base) == 0); \
+ memset(&__foo_io->base + 1, 0, \
+ sizeof(*__foo_io) - sizeof(__foo_io->base)); \
} while (0)
/** @} cl_io */
diff --git a/drivers/staging/lustre/lustre/include/lclient.h
b/drivers/staging/lustre/lustre/include/lclient.h
index 9d4011f..27316f7 100644
--- a/drivers/staging/lustre/lustre/include/lclient.h
+++ b/drivers/staging/lustre/lustre/include/lclient.h
@@ -388,8 +388,8 @@ __u16 ll_dirent_type_get(struct lu_dirent *ent);
__u64 cl_fid_build_ino(const struct lu_fid *fid, int api32);
__u32 cl_fid_build_gen(const struct lu_fid *fid);
-# define CLOBINVRNT(env, clob, expr) \
- ((void)sizeof(env), (void)sizeof(clob), (void)sizeof !!(expr))
+# define CLOBINVRNT(env,
Re: [PATCH] clocksource: at91/tc: remove deprecated IRQF_DISABLED
Hi Boris, On 10/13/2013 11:27 AM, boris brezillon wrote: > Hello Micheal, > > This flag has been removed in a recent submission (see > https://lkml.org/lkml/2013/10/2/202), and, if I'm correct, is on his > way for mainlining. That's good news. Thank you very much! Cheers, Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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] rtc: rtc-tps65910: remove unnecessary include
Currently, driver includes 'pm_runtime.h' which is not used anywhere in code hence remove this unnecessory inclusion. Signed-off-by: Manish Badarkhe --- :100644 100644 a9caf04... 7af0020... M drivers/rtc/rtc-tps65910.c drivers/rtc/rtc-tps65910.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/rtc/rtc-tps65910.c b/drivers/rtc/rtc-tps65910.c index a9caf04..7af0020 100644 --- a/drivers/rtc/rtc-tps65910.c +++ b/drivers/rtc/rtc-tps65910.c @@ -22,7 +22,6 @@ #include #include #include -#include #include #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On 10/14/2013 10:23 AM, Lennart Poettering wrote:
> On Mon, 14.10.13 09:11, Aaron Lu (aaron...@intel.com) wrote:
>
>>> Note that this appears unrelated to the Windows 8 backlight issues tracked
>>> here:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=51231
>>> https://bugzilla.kernel.org/show_bug.cgi?id=60682
>>>
>>> The Yoga's ACPI backlight controls work neither with nor without
>>> acpi_osi="!Windows 2012" on the kernel command line. It appears that
>>> backlight control via the EC simply is not available at all, regardless
>>> whether done via ACPI or via the vendor driver.
>>
>> Just a side note, if the firmware of Yoga 13 has a _OSI("Windows 2012")
>> query, then it should be solved with the patch proposed here:
>> https://lkml.org/lkml/2013/10/11/409, Fix Win8 backlight issue.
>>
>> We are still discussing a proper default behaviour in that patchset.
>
> No.
>
> Did you actually read the commit message of the patch? Please do!
Yes I've read the commit message...
>
> The backlight for the Yoga 13 doesn't work, regardless what the _OSI
> value is. In fact, it doesn't even work by directly accessing the EC via
> the ideapad-laptop driver.
>
> So, again:
>
> - Backlight control doesn't work via ACPI without acpi_osi="!Windows 2012"
> - Backlight control doesn't work via ACPI with acpi_osi="!Windows 2012"
> - Backlight control doesn't work via EC commands from ideapad-laptop.c
>
> The only way backlight handling is supported on the Yoga 13 is via the
> intel video driver.
Since I don't have access to the acpidump of this system, my only
question is, does the firmware has a _OSI("Windows 2012") query in DSDT
table?
>
> Or in other words: the situation for the Yoga 13 is *unrelated* to the
> Windows 8 issues, and your patch.
I think they are related...
If the firmware is compatible to Windows 8, then my patch will disable
ACPI video backlight interface to prefer GPU's interface.
>
> Hence this patch I posted, which blacklists the backlight control
> entirely in the ACPI driver, since the Windows 2012 setting is
> irrelevant to it.
Yes, the Windows 2012 setting is irrelevant to ACPI's interface(with or
without it, it doesn't work), but it's relevant to my patch as that is
the condition we are using to decide if we should skip registering ACPI
video's backlight interface.
>
> I'll soon send another patch which also blacklists the thing in the
> ideapad driver, so that only the intel backlight driver is enabled on
> Yoga 13 systems, at which point everything will work fine.
Right, that is needed. And if going with my patch, the ideapad driver
will need to be patched similarly like thinkpad_acpi to add a check of
acpi_video_backlight_support before it decides to register its own
backlight interface.
-Aaron
--
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] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On Mon, 14.10.13 09:11, Aaron Lu (aaron...@intel.com) wrote:
> > Note that this appears unrelated to the Windows 8 backlight issues tracked
> > here:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=51231
> > https://bugzilla.kernel.org/show_bug.cgi?id=60682
> >
> > The Yoga's ACPI backlight controls work neither with nor without
> > acpi_osi="!Windows 2012" on the kernel command line. It appears that
> > backlight control via the EC simply is not available at all, regardless
> > whether done via ACPI or via the vendor driver.
>
> Just a side note, if the firmware of Yoga 13 has a _OSI("Windows 2012")
> query, then it should be solved with the patch proposed here:
> https://lkml.org/lkml/2013/10/11/409, Fix Win8 backlight issue.
>
> We are still discussing a proper default behaviour in that patchset.
No.
Did you actually read the commit message of the patch? Please do!
The backlight for the Yoga 13 doesn't work, regardless what the _OSI
value is. In fact, it doesn't even work by directly accessing the EC via
the ideapad-laptop driver.
So, again:
- Backlight control doesn't work via ACPI without acpi_osi="!Windows 2012"
- Backlight control doesn't work via ACPI with acpi_osi="!Windows 2012"
- Backlight control doesn't work via EC commands from ideapad-laptop.c
The only way backlight handling is supported on the Yoga 13 is via the
intel video driver.
Or in other words: the situation for the Yoga 13 is *unrelated* to the
Windows 8 issues, and your patch.
Hence this patch I posted, which blacklists the backlight control
entirely in the ACPI driver, since the Windows 2012 setting is
irrelevant to it.
I'll soon send another patch which also blacklists the thing in the
ideapad driver, so that only the intel backlight driver is enabled on
Yoga 13 systems, at which point everything will work fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
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: x86: asus-wmi: add fan control
On Sun, Oct 13, 2013 at 10:17 AM, Matthew Garrett wrote: > On Sun, Oct 13, 2013 at 04:29:34AM -0500, Felipe Contreras wrote: > >> I don't see anything in acpi_ex_system_memory_space_handler() that >> takes into consideration virtual addresses. > > The spec doesn't seem to constrain it to physical addresses (it just > refers to "Control Methods read and write data to locations in address > spaces (for example, System memory and System I/O)", so I'd lean towards > changing the behaviour of acpica rather than adding virt_to_phys(). And I assume you are not going to do that. Isn't acpica code outside of the scope of Linux kernel development? If not, how do I go about adding that capability. Also, I find it weird that this the first driver that needs this. Finally, I'm much more interested on what happens next, because I want to link this driver to the thermal framework, so when temperature gets too high, the fan gets an increased speed, because right now it seems it's always on low speed, temperature gets high, and instead the CPU gets throttled, which is not desirable. Maybe this driver should be added to the staging area. -- Felipe Contreras -- 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.12-rc4] cifs: ntstatus_to_dos_map[] is not terminated
Merged into cifs-2.6.git
(for-next and for-linus branches)
Thoughts about suitability for stable anyone?
On Sun, Oct 13, 2013 at 2:29 PM, Tim Gardner wrote:
> Functions that walk the ntstatus_to_dos_map[] array could
> run off the end. For example, ntstatus_to_dos() loops
> while ntstatus_to_dos_map[].ntstatus is not 0. Granted,
> this is mostly theoretical, but could be used as a DOS attack
> if the error code in the SMB header is bogus.
>
> Cc: Steve French
> Signed-off-by: Tim Gardner
> ---
> fs/cifs/netmisc.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
> index af847e1..651a527 100644
> --- a/fs/cifs/netmisc.c
> +++ b/fs/cifs/netmisc.c
> @@ -780,7 +780,9 @@ static const struct {
> ERRDOS, ERRnoaccess, 0xc290}, {
> ERRDOS, ERRbadfunc, 0xc29c}, {
> ERRDOS, ERRsymlink, NT_STATUS_STOPPED_ON_SYMLINK}, {
> - ERRDOS, ERRinvlevel, 0x007c0001}, };
> + ERRDOS, ERRinvlevel, 0x007c0001}, {
> + 0, 0, 0 }
> +};
>
>
> /*
> Print an error message from the status code
> --
> 1.7.9.5
>
--
Thanks,
Steve
--
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: [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf().
On 10/14/2013 09:41 AM, Chen Gang wrote: > On 10/13/2013 07:05 PM, Paul E. McKenney wrote: >> On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote: >>> Hello Maintainers: >>> >>> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will >>> not be enough. >>> >>> In rcu_torture_printk(), the 'page' maximized size is 4096, it has a >>> function pointer for printing, which not tell its maximized length. >>> >>> Welcome any additional suggestions or completions. >> >> I never have run rcutorture on a system with that many CPUs. ;-) >> > > I guess most of members (include me), never have run under that case. > > >> Given that rcutorture is not used in production, my approach would be to >> fix this when I encountered it. But what change would you suggest, and, >> more importantly, how would you go about testing it before submitting >> a patch? >> > > OK, thanks, I will/should give a fix and test. > > Hmm, In my opinion, we need: > > - let it pass LTP common simple test (so I can know how to test it). > Oh, after read "Documentation/RCU/torture.txt", it is a test module, so except related special test (e.g. shrink maximized buffer), it seems not need additional common test for it (e.g. LTP). > - intend to shrink maximized buffer (PAGE_SIZE -> 64, 256 ..) for test. > > - read your original mail again (about testing contents) as reference. > > Excuse me, I have to do some other things of company, so I will/should > try to finish it within this week (2013-10-20), if this time point is > not quite suitable, please let me know, thanks. > > >> Or if you are simply reporting this as a bug, please let me know that. >> > > I will/should do: in q4 of 2013, I will/should spend part of my time > resources on testing. > > > > Welcome any additional suggestions or completions. > > Thanks. > -- Chen Gang -- 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] Squashfs: Refactor decompressor interface and code
On Tue, Oct 08, 2013 at 03:14:10AM +0100, Phillip Lougher wrote:
> The decompressor interface and code was written from
> the point of view of single-threaded operation. In doing
> so it mixed a lot of single-threaded implementation specific
> aspects into the decompressor code and elsewhere which makes it
> difficult to seamlessly support multiple different decompressor
> implementations.
>
> This patch does the following:
>
> 1. It removes compressor_options parsing from the decompressor
> init() function. This allows the decompressor init() function
> to be dynamically called to instantiate multiple decompressors,
> without the compressor options needing to be read and parsed each
> time.
>
> 2. It moves threading and all sleeping operations out of the
> decompressors. In doing so, it makes the decompressors
> non-blocking wrappers which only deal with interfacing with
> the decompressor implementation.
>
> 3. It splits decompressor.[ch] into decompressor generic functions
>in decompressor.[ch], and moves the single threaded
>decompressor implementation into decompressor_single.c.
>
> The result of this patch is Squashfs should now be able to
> support multiple decompressors by adding new decompressor_xxx.c
> files with specialised implementations of the functions in
> decompressor_single.c
>
> This has the following functions
>
> decompressor_create()
> - Called at mount time to initialise internal decompressor state.
> - An opaque pointer to the decompressor private state is returned (or
> error).
> - The function is called with a pointer to the parsed and swapped comp_opts
> structure returned by the new decompressor comp_opts() call.
>
> decompressor_destroy()
> - Destroy all decompressor private state
> - kfree the comp_opts buffer
>
> decompress()
> - Select a decompressor or create a new decompressor
> - Call using whatever locking scheme is necessary
>
> All decompressor implementation specific private state has been moved from the
> squashfs_sb_info structure into the opaque private state returned by
> decompressor_create(). This is deliberate, now all implementation specific
> code has been moved to decompressor_xxx.c, no other code needs to/or should
> need
> to access anything within it.
>
> Signed-off-by: Phillip Lougher
> ---
> fs/squashfs/Makefile | 2 +-
> fs/squashfs/block.c | 11 ++--
> fs/squashfs/decompressor.c| 47 +++--
> fs/squashfs/decompressor.h| 21 +++-
> fs/squashfs/decompressor_single.c | 107
> ++
> fs/squashfs/lzo_wrapper.c | 24 ++---
> fs/squashfs/squashfs.h| 9 +++-
> fs/squashfs/squashfs_fs_sb.h | 3 +-
> fs/squashfs/super.c | 10 ++--
> fs/squashfs/xz_wrapper.c | 89 +--
> fs/squashfs/zlib_wrapper.c| 50 ++
> 11 files changed, 237 insertions(+), 136 deletions(-)
> create mode 100644 fs/squashfs/decompressor_single.c
>
> diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
> index 110b047..c223c84 100644
> --- a/fs/squashfs/Makefile
> +++ b/fs/squashfs/Makefile
> @@ -4,7 +4,7 @@
>
> obj-$(CONFIG_SQUASHFS) += squashfs.o
> squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
> -squashfs-y += namei.o super.o symlink.o decompressor.o
> +squashfs-y += namei.o super.o symlink.o decompressor.o decompressor_single.o
> squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
> squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
> squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
> diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
> index 41d108e..10993e9 100644
> --- a/fs/squashfs/block.c
> +++ b/fs/squashfs/block.c
> @@ -93,7 +93,7 @@ int squashfs_read_data(struct super_block *sb, void
> **buffer, u64 index,
> struct buffer_head **bh;
> int offset = index & ((1 << msblk->devblksize_log2) - 1);
> u64 cur_index = index >> msblk->devblksize_log2;
> - int bytes, compressed, b = 0, k = 0, page = 0, avail;
> + int bytes, compressed, b = 0, k = 0, page = 0, avail, i;
>
> bh = kcalloc(((srclength + msblk->devblksize - 1)
> >> msblk->devblksize_log2) + 1, sizeof(*bh), GFP_KERNEL);
> @@ -158,6 +158,12 @@ int squashfs_read_data(struct super_block *sb, void
> **buffer, u64 index,
> ll_rw_block(READ, b - 1, bh + 1);
> }
>
> +for (i = 0; i < b; i++) {
> +wait_on_buffer(bh[i]);
> +if (!buffer_uptodate(bh[i]))
> +goto block_release;
> +}
Please, use tab instead of white space.
--
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
Re: [PATCH 1/1] AHCI: disabled FBS prior to issuing software reset
Hi, > On Sat, Oct 12, 2013 at 02:56:34PM +0800, xiangliang yu wrote: >> > So it can't find the disk if FBS stays enabled? Can you please attach >> > the boot log before & after? >> >> Below is boot log: > > And it works after the patch, right? Can you please update the patch > description so that it includes what was failing before and how it was > tested? > Yes. I'll update the patch later. Thanks. -- 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 3.11.5
I'm announcing the release of the 3.11.5 kernel. All users of the 3.11 kernel series must upgrade. The updated 3.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.11.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/configs/multi_v7_defconfig|1 arch/arm/kvm/reset.c |6 arch/arm/mach-integrator/pci_v3.h |7 arch/arm/mach-tegra/Kconfig| 21 -- arch/avr32/kernel/time.c |9 arch/powerpc/kernel/iommu.c|2 arch/powerpc/kernel/sysfs.c| 18 + arch/powerpc/kernel/tm.S | 95 ++ arch/powerpc/kernel/vio.c | 12 - arch/powerpc/lib/checksum_64.S | 58 -- arch/powerpc/mm/init_64.c |4 arch/powerpc/mm/mem.c |9 arch/powerpc/perf/power8-pmu.c |5 arch/s390/kernel/entry.S |1 arch/s390/kernel/entry64.S |1 arch/sparc/kernel/ds.c |5 arch/sparc/kernel/entry.S |2 arch/sparc/kernel/ktlb.S |3 arch/sparc/kernel/syscalls.S |8 arch/sparc/kernel/trampoline_64.S |2 arch/sparc/lib/ksyms.c |9 arch/tile/include/asm/percpu.h | 34 +++ drivers/acpi/acpi_ipmi.c | 24 +- drivers/block/cciss.c |1 drivers/block/cpqarray.c |1 drivers/bluetooth/ath3k.c |2 drivers/bluetooth/btusb.c |2 drivers/dma/imx-dma.c | 31 +-- drivers/gpio/gpio-omap.c | 158 ++--- drivers/gpu/drm/nouveau/core/subdev/bios/init.c| 19 +- drivers/gpu/drm/radeon/radeon_asic.c |4 drivers/hid/Kconfig|1 drivers/hid/hid-core.c | 21 ++ drivers/hid/hid-holtek-mouse.c |4 drivers/hid/hid-ids.h |2 drivers/hid/hid-logitech-dj.c | 12 + drivers/hid/hid-picolcd_debugfs.c | 23 +- drivers/hid/hid-roccat-konepure.c |3 drivers/hid/hid-wiimote-modules.c | 40 +++- drivers/hid/hid-wiimote.h |4 drivers/hid/uhid.c |4 drivers/hid/usbhid/hid-core.c |5 drivers/infiniband/ulp/srpt/ib_srpt.c | 14 - drivers/iommu/arm-smmu.c | 13 - drivers/md/bcache/request.c|3 drivers/mmc/card/block.c |2 drivers/net/bonding/bond_main.c| 13 + drivers/net/ethernet/arc/emac_main.c |4 drivers/net/ethernet/marvell/skge.c|9 drivers/net/ethernet/realtek/r8169.c |1 drivers/net/ethernet/renesas/sh_eth.c | 12 - drivers/net/ethernet/via/via-rhine.c |9 drivers/net/ethernet/xilinx/ll_temac_main.c|6 drivers/net/ppp/pptp.c |2 drivers/net/tun.c | 11 - drivers/net/usb/dm9601.c |2 drivers/net/usb/qmi_wwan.c | 130 + drivers/net/vxlan.c| 20 +- drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 28 +-- drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h |3 drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c| 14 - drivers/net/wireless/brcm80211/brcmfmac/usb.c |2 drivers/net/wireless/mwifiex/11n_aggr.c|3 drivers/net/wireless/mwifiex/11n_aggr.h|2 drivers/net/wireless/mwifiex/cmdevt.c |5 drivers/net/wireless/mwifiex/usb.c |7 drivers/net/wireless/mwifiex/wmm.c |3 drivers/net/wireless/p54/p54usb.c |1 drivers/net/wireless/rtlwifi/wifi.h|2
Re: [PATCH 3/3] Squashfs: Directly decompress into the page cache for file data
On Fri, Oct 11, 2013 at 07:19:40AM +0100, Phillip Lougher wrote:
> This introduces an implementation of squashfs_readpage_block()
> that directly decompresses into the page cache.
>
> This uses the previously added page handler abstraction to push
> down the necessary kmap_atomic/kunmap_atomic operations on the
> page cache buffers into the decompressors. This enables
> direct copying into the page cache without using the slow
> kmap/kunmap calls.
>
> The code detects when multiple threads are racing in
> squashfs_readpage() to decompress the same block, and avoids
> this regression by falling back to using an intermediate
> buffer.
>
> This patch enhances the performance of Squashfs significantly
> when multiple processes are accessing the filesystem simultaneously
> because it not only reduces memcopying, but it more importantly
> eliminates the lock contention on the intermediate buffer.
>
> Using single-thread decompression.
>
> dd if=file1 of=/dev/null bs=4096 &
> dd if=file2 of=/dev/null bs=4096 &
> dd if=file3 of=/dev/null bs=4096 &
> dd if=file4 of=/dev/null bs=4096
>
> Before:
>
> 629145600 bytes (629 MB) copied, 45.8046 s, 13.7 MB/s
>
> After:
>
> 629145600 bytes (629 MB) copied, 9.29414 s, 67.7 MB/s
It's really nice!
Below are just nitpicks.
>
> Signed-off-by: Phillip Lougher
> ---
> fs/squashfs/Kconfig | 14
> fs/squashfs/Makefile | 7 +-
> fs/squashfs/file_direct.c | 178
> ++
> fs/squashfs/page_actor.c | 104 +++
> fs/squashfs/page_actor.h | 32 +
> 5 files changed, 334 insertions(+), 1 deletion(-)
> create mode 100644 fs/squashfs/file_direct.c
> create mode 100644 fs/squashfs/page_actor.c
>
> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
> index c70111e..8bc9e6a 100644
> --- a/fs/squashfs/Kconfig
> +++ b/fs/squashfs/Kconfig
> @@ -25,6 +25,20 @@ config SQUASHFS
>
> If unsure, say N.
>
> +config SQUASHFS_FILE_DIRECT
> + bool "Decompress files directly into the page cache"
> + depends on SQUASHFS
> + help
> + Squashfs has traditionally decompressed file data into an
> + intermediate buffer and then memcopied it into the page cache.
> +
> + Saying Y here includes support for directly decompressing
> + file data into the page cache. Doing so can significantly
> + improve performance because it eliminates a mempcpy and
> + it also removes the lock contention on the single buffer.
> +
> + If unsure, say N.
> +
> config SQUASHFS_XATTR
> bool "Squashfs XATTR support"
> depends on SQUASHFS
> diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
> index 14cfc41..deaabc5 100644
> --- a/fs/squashfs/Makefile
> +++ b/fs/squashfs/Makefile
> @@ -5,8 +5,13 @@
> obj-$(CONFIG_SQUASHFS) += squashfs.o
> squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
> squashfs-y += namei.o super.o symlink.o decompressor.o decompressor_single.o
> -squashfs-y += file_cache.o
> squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
> squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
> squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
> squashfs-$(CONFIG_SQUASHFS_ZLIB) += zlib_wrapper.o
> +
> +ifdef CONFIG_SQUASHFS_FILE_DIRECT
> +squashfs-y += file_direct.o page_actor.o
> +else
> +squashfs-y += file_cache.o
> +endif
> diff --git a/fs/squashfs/file_direct.c b/fs/squashfs/file_direct.c
> new file mode 100644
> index 000..f31298e
> --- /dev/null
> +++ b/fs/squashfs/file_direct.c
> @@ -0,0 +1,178 @@
> +/*
> + * Copyright (c) 2013
> + * Phillip Lougher
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "squashfs_fs.h"
> +#include "squashfs_fs_sb.h"
> +#include "squashfs_fs_i.h"
> +#include "squashfs.h"
> +#include "page_actor.h"
> +
> +static int squashfs_read_cache(struct page *target_page, u64 block, int
> bsize,
> + int pages, struct page **page);
> +
> +/* Read separately compressed datablock directly into page cache */
> +int squashfs_readpage_block(struct page *target_page, u64 block, int bsize)
> +
> +{
> + struct inode *inode = target_page->mapping->host;
> + struct squashfs_sb_info *msblk = inode->i_sb->s_fs_info;
> +
> + int file_end = (i_size_read(inode) - 1) >> PAGE_CACHE_SHIFT;
> + int mask = (1 << (msblk->block_log - PAGE_CACHE_SHIFT)) - 1;
> + int start_index = target_page->index & ~mask;
> + int end_index = start_index | mask;
> + int i, n, pages, missing_pages, bytes, res = -ENOMEM;
> + struct page **page;
> + struct squashfs_page_actor *actor;
> + void *pageaddr;
> +
> + if (end_index > file_end)
> + end_index = file_end;
> +
> + pages = end_index - start_index + 1;
> +
> +
Re: [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf().
On 10/13/2013 07:05 PM, Paul E. McKenney wrote: > On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote: >> Hello Maintainers: >> >> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will >> not be enough. >> >> In rcu_torture_printk(), the 'page' maximized size is 4096, it has a >> function pointer for printing, which not tell its maximized length. >> >> Welcome any additional suggestions or completions. > > I never have run rcutorture on a system with that many CPUs. ;-) > I guess most of members (include me), never have run under that case. > Given that rcutorture is not used in production, my approach would be to > fix this when I encountered it. But what change would you suggest, and, > more importantly, how would you go about testing it before submitting > a patch? > OK, thanks, I will/should give a fix and test. Hmm, In my opinion, we need: - let it pass LTP common simple test (so I can know how to test it). - intend to shrink maximized buffer (PAGE_SIZE -> 64, 256 ..) for test. - read your original mail again (about testing contents) as reference. Excuse me, I have to do some other things of company, so I will/should try to finish it within this week (2013-10-20), if this time point is not quite suitable, please let me know, thanks. > Or if you are simply reporting this as a bug, please let me know that. > I will/should do: in q4 of 2013, I will/should spend part of my time resources on testing. Welcome any additional suggestions or completions. Thanks. -- Chen Gang -- 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/
Steroid Products
Hey, We supply injectable steroid and oral steroid products. They are Nandrolone series, Boldenone series, Testosterone series, Trenbolone series, Drostanolone series and some others. Min. order quantity: As your request. Payment type: Western Union, Bank Transfer. Delivery time: within 10 working days after get payment. Shipping term: express mail (with registered tracking number, door delivery). Supplying ability: 5000 vials(bottles) per week. Return policy: we will return your money if our products don’t have good effect. You can learn the details of our products on our web: . If you are interested in our products, we are pleased to send you our price quote for them. If you have any questions, please feel free to contact us. Best Regards, Overseas Sales Division Numberone Biotech Co., Ltd.
Re: [PATCH] trace-cmd: Handle __print_hex(__get_dynamic_array(fieldname), len)
Hi Howard,
On Fri, 11 Oct 2013 10:55:49 -0400, Howard Cochran wrote:
> The kernel has a few events with a format similar to this excerpt:
> field:unsigned int len; offset:12; size:4; signed:0;
> field:__data_loc unsigned char[] data_array; offset:16; size:4;
> signed:0;
> print fmt: "%s", __print_hex(__get_dynamic_array(data_array), REC->len)
>
> trace-cmd could already parse that arg correctly, but print_str_arg()
> was unable to handle the first parameter being a dynamic array. (It
> just printed a "field not found" warning).
>
> Teach print_str_arg's PRINT_HEX case to handle the nested
> PRINT_DYNAMIC_ARRAY correctly. The output now matches the kernel's own
> formatting for this case.
It seems that it needs to be added to libtraceevent also. Could you
also send a patch against tools/lib/traceevent/event-parse.c in the
Linux kernel source?
Thanks,
Namhyung
>
> Signed-off-by: Howard Cochran
> ---
> event-parse.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/event-parse.c b/event-parse.c
> index e961553..fdb176e 100644
> --- a/event-parse.c
> +++ b/event-parse.c
> @@ -3550,15 +3550,23 @@ static void print_str_arg(struct trace_seq *s, void
> *data, int size,
> }
> break;
> case PRINT_HEX:
> - field = arg->hex.field->field.field;
> - if (!field) {
> - str = arg->hex.field->field.name;
> - field = pevent_find_any_field(event, str);
> - if (!field)
> - goto out_warning_field;
> - arg->hex.field->field.field = field;
> + if (PRINT_DYNAMIC_ARRAY == arg->hex.field->type) {
> + unsigned long offset;
> + offset = pevent_read_number(pevent,
> + data + arg->hex.field->dynarray.field->offset,
> + arg->hex.field->dynarray.field->size);
> + hex = data + (offset & 0x);
> + } else {
> + field = arg->hex.field->field.field;
> + if (!field) {
> + str = arg->hex.field->field.name;
> + field = pevent_find_any_field(event, str);
> + if (!field)
> + goto out_warning_field;
> + arg->hex.field->field.field = field;
> + }
> + hex = data + field->offset;
> }
> - hex = data + field->offset;
> len = eval_num_arg(data, size, event, arg->hex.size);
> for (i = 0; i < len; i++) {
> if (i)
--
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: support for Intel Atom based QNAP LEDs/buttons/buzzer in Linux?
On 10/13/2013 04:46 PM, Christoph Anton Mitterer wrote: Hi Greg, Guenter and Chris. Coming back to the stuff discussed previously[0]. Chris Eastwood has made most of these (i.e. LEDs and buttons, the buzzers may work on at least some of the devices via some other serial device) working (AFAIU based on the previously mentioned code at Github[1]), he told me in several iterations of private mail. I'm not sure now, whether anything based on this code would be appropriate for the mainline kernel, since Guenter mentioned he'd prefer a mfd core driver for all that... OTOH, the later may probably never happen, and Chris' work seems to already do the job. I don't know however, whether he needs to patch any other places in the kernel, but I'm sure he can show his work (and ask questions) better than I, thereby inviting him to do so. Greg you had mentioned before that you might be able to spend some time on this, so if you could help Chris, that would be great. You really have two options - either an mfd driver with client drivers for hwmon, gpio, watchdog (and possibly others), or a gpio driver which shares access to the superio control registers. Both the it87 hwmon driver and the it87 watchdog driver support the latter mechanism already, so that would be the (much) simpler option. To control the LEDs you would then simply use the leds-gpio driver. Input would need something similar - no idea if there is a generic input-gpio driver; if not it might make sense to write one. Another option there would be to have a platform driver which would tie into the gpio driver and pass the gpio pin status to the input subsystem. I had a look at Chris' driver, but in my opinion it is simply too hardware specific to be acceptable as-is. Of course, I would not make the call, so that is just my persional opinion. Thanks, Guenter -- 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 3.10.16
I'm announcing the release of the 3.10.16 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/avr32/kernel/time.c |9 arch/powerpc/kernel/iommu.c|2 arch/powerpc/kernel/sysfs.c| 18 + arch/powerpc/kernel/tm.S | 94 ++ arch/powerpc/kernel/vio.c | 12 - arch/powerpc/lib/checksum_64.S | 58 -- arch/powerpc/perf/power8-pmu.c |5 arch/s390/kernel/entry.S |1 arch/s390/kernel/entry64.S |1 arch/sparc/kernel/ds.c |5 arch/sparc/kernel/entry.S |2 arch/sparc/kernel/ktlb.S |3 arch/sparc/kernel/syscalls.S |8 arch/sparc/kernel/trampoline_64.S |2 arch/sparc/lib/ksyms.c |9 arch/tile/include/asm/percpu.h | 34 +++ drivers/acpi/acpi_ipmi.c | 24 +- drivers/block/cciss.c |1 drivers/block/cpqarray.c |1 drivers/bluetooth/ath3k.c |2 drivers/bluetooth/btusb.c |2 drivers/dma/imx-dma.c | 31 +-- drivers/gpio/gpio-omap.c | 158 ++--- drivers/gpu/drm/nouveau/core/subdev/bios/init.c| 19 +- drivers/gpu/drm/radeon/radeon_asic.c |2 drivers/hid/hid-core.c | 20 ++ drivers/hid/hid-ids.h |1 drivers/hid/hid-logitech-dj.c | 12 + drivers/hid/hid-picolcd_debugfs.c | 23 +- drivers/hid/hid-roccat-konepure.c |3 drivers/hid/uhid.c |4 drivers/hid/usbhid/hid-core.c |5 drivers/infiniband/ulp/srpt/ib_srpt.c | 14 - drivers/md/bcache/request.c|3 drivers/net/bonding/bond_main.c| 13 + drivers/net/ethernet/realtek/r8169.c |1 drivers/net/ethernet/via/via-rhine.c |9 drivers/net/ethernet/xilinx/ll_temac_main.c|6 drivers/net/ppp/pptp.c |2 drivers/net/tun.c | 11 - drivers/net/usb/dm9601.c |2 drivers/net/usb/qmi_wwan.c | 130 + drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 28 +-- drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h |3 drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c| 14 - drivers/net/wireless/brcm80211/brcmfmac/usb.c |2 drivers/net/wireless/mwifiex/11n_aggr.c|3 drivers/net/wireless/mwifiex/11n_aggr.h|2 drivers/net/wireless/mwifiex/cmdevt.c |5 drivers/net/wireless/mwifiex/main.c|5 drivers/net/wireless/mwifiex/sta_ioctl.c | 18 - drivers/net/wireless/mwifiex/usb.c |7 drivers/net/wireless/mwifiex/wmm.c |3 drivers/net/wireless/p54/p54usb.c |1 drivers/net/wireless/rtlwifi/wifi.h|2 drivers/net/xen-netback/netback.c | 94 ++ drivers/scsi/esp_scsi.c| 14 - drivers/scsi/esp_scsi.h|1 drivers/staging/comedi/drivers/ni_65xx.c | 25 +- drivers/target/iscsi/iscsi_target_util.c |4 drivers/tty/hvc/hvc_xen.c |1 drivers/usb/serial/option.c|3 fs/binfmt_elf.c| 30 +-- fs/btrfs/extent-tree.c |3 fs/btrfs/relocation.c | 14 - fs/btrfs/send.c|3 fs/fuse/file.c | 23 +- fs/nfs/nfs4filelayoutdev.c | 18 - fs/nilfs2/page.c |2
Re: [PATCH] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On 10/14/2013 08:55 AM, Lennart Poettering wrote:
> On the Yoga 13 the backlight control doesn't work via ACPI. (And doesn't
> work either with the low-level platform driver ideapad_laptop; but
> works correctly via the intel video driver). This patch hence adds the
> Yoga 13 to the ACPI video detect blacklist, to make sure the broken ACPI
> backlight device is never exposed to userspace.
>
> Note that this appears unrelated to the Windows 8 backlight issues tracked
> here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> https://bugzilla.kernel.org/show_bug.cgi?id=60682
>
> The Yoga's ACPI backlight controls work neither with nor without
> acpi_osi="!Windows 2012" on the kernel command line. It appears that
> backlight control via the EC simply is not available at all, regardless
> whether done via ACPI or via the vendor driver.
Just a side note, if the firmware of Yoga 13 has a _OSI("Windows 2012")
query, then it should be solved with the patch proposed here:
https://lkml.org/lkml/2013/10/11/409, Fix Win8 backlight issue.
We are still discussing a proper default behaviour in that patchset.
Thanks,
Aaron
>
> Signed-off-by: Lennart Poettering
> ---
> drivers/acpi/video_detect.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index 940edbf..a88e8f7 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -168,6 +168,14 @@ static struct dmi_system_id video_detect_dmi_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
> },
> },
> + {
> + .callback = video_detect_force_vendor,
> + .ident = "Lenovo Yoga 13",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo IdeaPad Yoga 13"),
> + },
> + },
> { },
> };
>
>
--
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/9] i2c: i2c-designware-platdrv: replace platform_driver_probe to support deferred probing
On Wed, Oct 9, 2013 at 4:35 AM, Wolfram Sang wrote: > Subsystems like pinctrl and gpio rightfully make use of deferred probing at > core level. Now, deferred drivers won't be retried if they don't have a .probe > function specified in the driver struct. Fix this driver to have that, so the > devices it supports won't get lost in a deferred probe. > > Signed-off-by: Wolfram Sang > Cc: Zhangfei Gao Acked-by: Zhangfei Gao Thanks -- 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: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v5)
Hi Jiri, On Sun, 13 Oct 2013 14:34:44 +0200, Jiri Olsa wrote: > On Fri, Oct 11, 2013 at 02:15:35PM +0900, Namhyung Kim wrote: >> Hello, >> >> This is a new version of callchain improvement patchset. Basically >> it's almost same as v4 but rebased on current acme/perf/core and some >> functions are renamed as Frederic requested. >> >> Now I'm hunting down a bug in 'perf report -s sym' which was found >> during the test, but I think it's not related to this change as it can >> be reproduced in earlier versions too. >> >> I put this series on 'perf/callchain-v5' branch in my tree >> >> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > hi, > while hunting another issue, I got segfault in callchains code: > > Press '?' for help on key bindings > Program received signal SIGSEGV, Segmentation fault. > 0x004dcd89 in callchain_node__init_have_children_rb_tree > (node=0x21a0330) at ui/browsers/hists.c:158 > 158 chain->ms.has_children = > chain->list.next == >val && > Missing separate debuginfos, use: debuginfo-install > audit-libs-2.2.1-1.fc16.x86_64 elfutils-libelf-0.154-2.fc16.x86_64 > elfutils-libs-0.154-2.fc16.x86_64 glibc-2.14.90-24.fc16.9.x86_64 > libunwind-0.99-2.20110424git1e10c293.fc16.x86_64 > nss-softokn-freebl-3.14.1-3.fc16.x86_64 numactl-2.0.7-2.fc16.x86_64 > perl-libs-5.14.3-205.fc16.x86_64 python-libs-2.7.3-4.fc16.x86_64 > slang-2.2.4-1.fc16.x86_64 xz-libs-5.1.1-1alpha.fc16.x86_64 > zlib-1.2.5-7.fc16.x86_64 > (gdb) bt > #0 0x004dcd89 in callchain_node__init_have_children_rb_tree > (node=0x21a0330) at ui/browsers/hists.c:158 > #1 0x004dcdf9 in callchain_node__init_have_children_rb_tree > (node=0x1fa90a0) at ui/browsers/hists.c:162 > #2 0x004dcead in callchain_node__init_have_children (node=0x1fa90a0) > at ui/browsers/hists.c:173 > #3 0x004dcf10 in callchain__init_have_children (root=0x1fa8ff8) at > ui/browsers/hists.c:182 > #4 0x004dcf97 in hist_entry__init_have_children (he=0x1fa8f00) at > ui/browsers/hists.c:190 > #5 0x004debf3 in hist_browser__show_entry (browser=0xa27010, > entry=0x1fa8f00, row=66) at ui/browsers/hists.c:739 > #6 0x004df062 in hist_browser__refresh (browser=0xa27010) at > ui/browsers/hists.c:823 > #7 0x004d8487 in __ui_browser__refresh (browser=0xa27010) at > ui/browser.c:307 > #8 0x004d8681 in ui_browser__run (browser=0xa27010, delay_secs=0) at > ui/browser.c:362 > #9 0x004dd6a7 in hist_browser__run (browser=0xa27010, > ev_name=0xa26ff0 "cycles:pp", hbt=0x0) at ui/browsers/hists.c:335 > #10 0x004e0d9b in perf_evsel__hists_browse (evsel=0xa24b60, > nr_events=1, > helpline=0x58e588 "For a higher level overview, try: perf report --sort > comm,dso", ev_name=0xa26ff0 "cycles:pp", left_exits=false, > hbt=0x0, min_pcnt=0, env=0xa23f90) at ui/browsers/hists.c:1430 > #11 0x004e2605 in perf_evlist__tui_browse_hists (evlist=0xa242e0, > help=0x58e588 "For a higher level overview, try: perf report --sort > comm,dso", hbt=0x0, min_pcnt=0, env=0xa23f90) > at ui/browsers/hists.c:1950 > #12 0x0042c3cb in __cmd_report (rep=0x7fffdf40) at > builtin-report.c:590 > #13 0x0042d84a in cmd_report (argc=0, argv=0x7fffe3a0, > prefix=0x0) at builtin-report.c:988 > #14 0x00418fed in run_builtin (p=0x803c28, argc=5, > argv=0x7fffe3a0) at perf.c:319 > #15 0x00419225 in handle_internal_command (argc=5, > argv=0x7fffe3a0) at perf.c:376 > #16 0x00419371 in run_argv (argcp=0x7fffe27c, > argv=0x7fffe270) at perf.c:420 > #17 0x00419658 in main (argc=5, argv=0x7fffe3a0) at perf.c:529 > > > I got it on the original code, so I've tried your's > perf/callchain-v5 with same result. > > I put perf archive and data output in here if you're interested: > http://people.redhat.com/jolsa/cc/ Thanks, I'll take a look at this today. 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/
[PATCH] acpi/video: Add Lenovo IdeaPad Yoga 13 to acpi video detect blacklist
On the Yoga 13 the backlight control doesn't work via ACPI. (And doesn't
work either with the low-level platform driver ideapad_laptop; but
works correctly via the intel video driver). This patch hence adds the
Yoga 13 to the ACPI video detect blacklist, to make sure the broken ACPI
backlight device is never exposed to userspace.
Note that this appears unrelated to the Windows 8 backlight issues tracked
here:
https://bugzilla.kernel.org/show_bug.cgi?id=51231
https://bugzilla.kernel.org/show_bug.cgi?id=60682
The Yoga's ACPI backlight controls work neither with nor without
acpi_osi="!Windows 2012" on the kernel command line. It appears that
backlight control via the EC simply is not available at all, regardless
whether done via ACPI or via the vendor driver.
Signed-off-by: Lennart Poettering
---
drivers/acpi/video_detect.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..a88e8f7 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -168,6 +168,14 @@ static struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+ {
+ .callback = video_detect_force_vendor,
+ .ident = "Lenovo Yoga 13",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo IdeaPad Yoga 13"),
+ },
+ },
{ },
};
--
1.8.3.1
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
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] ftrace: add set_graph_notrace filter
Hi, On Fri, 11 Oct 2013 08:31:45 -0400, Steven Rostedt wrote: > On Fri, 11 Oct 2013 17:19:46 +0900 > Namhyung Kim wrote: > >> Hi Steve, >> >> On Fri, 11 Oct 2013 00:17:17 -0400, Steven Rostedt wrote: >> > Sorry for the very late reply, finally got some time to look at other >> > peoples code. >> >> Thank you for taking your time to review this carefully. :) > > Sorry for it taking so long. Nevermind. :) > >> > I would be a bit more specific in your comment. Explain that >> > curr_ret_stack is negative when we hit a function in the >> > set_graph_notrace file. >> >> How about this: >> >> /* >> * curr_ret_stack is initialized to -1 and gets increased in >> * this function. So it can be less than -1 only if it was >> * filtered out via ftrace_graph_notrace_addr() which can be >> * set from set_graph_notrace file in debugfs by user. >> */ > > Looks good. > >> >> > >> >> + >> >> calltime = trace_clock_local(); >> >> >> >> index = ++current->curr_ret_stack; >> >> + if (ftrace_graph_notrace_addr(func)) >> >> + current->curr_ret_stack -= FTRACE_NOTRACE_DEPTH; >> > >> > I really hate this double call to ftrace_graph_notrace_addr(). The >> > first one in trace_graph_entry(), and then here too. >> > >> > Isn't there a way we could pass the state? Hmm, I think we could use >> > depth to do that. As depth is a pointer to trace.depth and not used >> > before then. We could make it negative and then check that. >> > >> > /me looks at other archs. >> > >> > Darn it, s390 calls ftrace_push_return_trace() before >> > ftrace_graph_entry(). They got fancy, as they must have noticed that >> > trace.depth is set by ftrace_push_return_trace() and they just figured >> > to let the ftrace_push_return_trace() do the work. >> >> Yes, I thought about it before but as you can see other archs go to the >> other way around so I just ended up to call it twice. >> >> > >> > Hmm, we could add a config to do the check on one side or the other >> > depending on how the arch handles it. >> > >> > It needs to be well commented though. >> >> Hmm.. maybe. But it'd better if this function call order is fixed >> IMHO. Anyway, I'll add comments. > > Well, as you probably already saw, s390 changed to help us out :-) Is > there other archs you know about. I haven't looked at all the others > yet. s390 was the first one I saw that didn't follow suit. As you can see that most other archs don't follow the ordering. > > Anyway, lets keep your double check for now. I'll look at making the > two function calls from arch into one, where we can optimize this a bit > more. Okay. > [SNIP] >> >> @@ -259,10 +272,14 @@ int trace_graph_entry(struct ftrace_graph_ent >> >> *trace) >> >> >> >> /* trace it when it is-nested-in or is a function enabled. */ >> >> if ((!(trace->depth || ftrace_graph_addr(trace->func)) || >> >> - ftrace_graph_ignore_irqs()) || >> >> + ftrace_graph_ignore_irqs()) || (trace->depth < 0) || >> >> (max_depth && trace->depth >= max_depth)) >> >> return 0; >> >> >> >> + /* need to reserve a ret_stack entry to recover the depth */ >> >> + if (ftrace_graph_notrace_addr(trace->func)) >> >> + return 1; >> >> + >> > >> > Also, I understand what you are doing here, with making curr_ret_stack >> > negative to denote we are in a state to not do tracing. But it's more >> > of a hack (not a bad one), and really needs to be documented somewhere. >> > That is, the design should be in the comments where it's used, and 5 >> > years from now, nobody will understand how the notrace works without >> > spending days trying to figure it out. Let's be nice to that poor soul, >> > and write up what is going on so they don't need to pray to the holy >> > tuna hoping to get a fish of enlightenment on how turning >> > curr_ret_stack negative magically makes the function graph tracing not >> > trace down functions, and magically starts tracing again when it comes >> > back up. >> >> Fully agreed. How about this: >> >> /* >> * The curr_ret_stack is an index to ftrace return stack of current >> * task. Its value should be in [0, FTRACE_RETFUNC_DEPTH) when the >> * function graph tracer is used. To support filtering out specific >> * functions, it makes the index negative by subtracting huge value > > s/huge/the max/ Hmm.. I introduced FTRACE_NOTRACE_DEPTH (not FTRACE_RETFUNC_DEPTH) in order to prevent possible off-by-one bug in any case. Do you think just using FTRACE_RETFUNC_DEPTH is enough? > >> * (FTRACE_NOTRACE_DEPTH) so when it sees a negative index the ftrace >> * will ignore the record. And the index gets recovered when returning >> * from the filtered function by adding the FTRACE_NOTRACE_DEPTH and >> * then it will continue to record functions normally. >> */ > > Sounds good. Thank you for the review! Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: [PATCH] ext4: fix checking on nr_to_write
On Mon, Oct 14, 2013 at 12:39 AM, Ming Lei wrote: > > On one arm A15 board(arndale) with sata 3.0 SSD(CPU: 1.5GHz dura core, RAM: > 2GB), Sorry for forgetting to mention: the sata controller is working at 3.0Gbps. Thanks, -- Ming Lei -- 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] ARM: SAMSUNG: remove IRQF_DISABLED
On Saturday, October 12, 2013 12:36 PM, Michael Opdenacker wrote: > > This patch proposes to remove the use of the IRQF_DISABLED flag > > It's a NOOP since 2.6.35 and it will be removed one day. > > Signed-off-by: Michael Opdenacker Reviewed-by: Jingoo Han Best regards, Jingoo Han > --- > arch/arm/mach-s3c24xx/dma.c | 2 +- > arch/arm/mach-s3c24xx/simtec-usb.c | 3 +-- > arch/arm/mach-s3c64xx/mach-smartq.c | 2 +- > 3 files changed, 3 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
Hello, On Sat, Oct 12, 2013 at 05:37:55PM +0800, Weijie Yang wrote: > Hi, all > > I thought out a new way to resolve this problem: use CAS instead of refcount. > > It not only resolve this problem, but also fix another issue, > can be expanded to support frontswap get_and_free mode easily. > And I use it in an zswap variant which writeback zbud page directly. > > If it is accepted, I will resent it instead of the previous refactor patch You're adding atomic operation and making code more complicated to me rather than simple get/put scheme. Please, write a good decsription why it's better, not vague words like "fix another issue, get_and_free and zswap variant". Please convince us. > > please see below, Request For Comments, Thanks. > > On Fri, Oct 11, 2013 at 3:13 PM, Minchan Kim wrote: > > On Thu, Sep 26, 2013 at 11:42:17AM +0800, Weijie Yang wrote: > > > On Tue, Sep 24, 2013 at 9:03 AM, Minchan Kim wrote: > > > > On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote: > > > > > > > > > > Modify: > > > > > - check the refcount in fail path, free memory if it is not > > > > > referenced. > > > > > > > > Hmm, I don't like this because zswap refcount routine is already mess > > > > for me. > > > > I'm not sure why it was designed from the beginning. I hope we should > > > > fix it first. > > > > > > > > 1. zswap_rb_serach could include zswap_entry_get semantic if it founds > > > > a entry from > > > >the tree. Of course, we should ranme it as find_get_zswap_entry like > > > > find_get_page. > > > > 2. zswap_entry_put could hide resource free function like > > > > zswap_free_entry so that > > > >all of caller can use it easily following pattern. > > > > > > > > find_get_zswap_entry > > > > ... > > > > ... > > > > zswap_entry_put > > > > > > > > Of course, zswap_entry_put have to check the entry is in the tree or not > > > > so if someone already removes it from the tree, it should avoid double > > > > remove. > > > > > > > > One of the concern I can think is that approach extends critical section > > > > but I think it would be no problem because more bottleneck would be > > > > [de]compress > > > > functions. If it were really problem, we can mitigate a problem with > > > > moving > > > > unnecessary functions out of zswap_free_entry because it seem to be > > > > rather > > > > over-enginnering. > > > > > > I refactor the zswap refcount routine according to Minchan's idea. > > > Here is the new patch, Any suggestion is welcomed. > > > > > > To Seth and Bob, would you please review it again? > > > > Yeah, Seth, Bob. You guys are right persons to review this because this > > scheme was suggested by me who is biased so it couldn't be a fair. ;-) > > But anyway, I will review code itself. > > Consider the following scenario: > thread 0: reclaim entry x(get refcount, but not call > zswap_get_swap_cache_page) > thread 1: call zswap_frontswap_invalidate_page to invalidate entry x. > finished, entry x and its zbud is not freed as its refcount != 0 > now, the swap_map[x] = 0 > thread 0: now call zswap_get_swap_cache_page > swapcache_prepare return -ENOENT because entry x is not used any more > zswap_get_swap_cache_page return ZSWAP_SWAPCACHE_NOMEM > zswap_writeback_entry do nothing except put refcount > Now, the memory of zswap_entry x and its zpage leak. > > Consider the another scenario: > zswap entry x with offset A is already stored in zswap backend. > thread 0: reclaim entry x(get refcount, but not call > zswap_get_swap_cache_page) > thread 1: store new page with the same offset A, alloc a new zswap entry y. > This is a duplicate store and finished. > shrink_page_list() finish, now the new page is not in swap_cache > thread 0: zswap_get_swap_cache_page get called. > old page data is added to swap_cache > Now, swap cache has old data rather than new data for offset A. > Error will happen If do_swap_page() get page from swap_cache. > > Modify: > - re-design the zswap_entry concurrent protection by using a CAS-access flag >instead of the refcount get/put semantic > > - use ZSWAP_SWAPCACHE_FAIL instead of ZSWAP_SWAPCACHE_NOMEM as the fail path >can be not only caused by nomem but also by invalidate. > > Signed-off-by: Weijie Yang > --- > mm/zswap.c | 177 > +++- > 1 file changed, 80 insertions(+), 97 deletions(-) > mode change 100644 => 100755 mm/zswap.c > > diff --git a/mm/zswap.c b/mm/zswap.c > old mode 100644 > new mode 100755 > index cbd9578..fcaaecb > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -158,21 +158,23 @@ static void zswap_comp_exit(void) > * page within zswap. > * > * rbnode - links the entry into red-black tree for the appropriate swap type > - * refcount - the number of outstanding reference to the entry. This is > needed > - *to protect against premature freeing of the entry by code > - *concurent calls
[PATCH 1/1] drivers: infiniband: ulp: Fix possible use-after-free
The tx_desc variable is being used to access its type member
after a kmem_cache_free call
Signed-off-by: Felipe Pena
---
drivers/infiniband/ulp/iser/iser_initiator.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iser_initiator.c
b/drivers/infiniband/ulp/iser/iser_initiator.c
index 5388226..15b545c 100644
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers/infiniband/ulp/iser/iser_initiator.c
@@ -610,17 +610,15 @@ void iser_snd_completion(struct iser_tx_desc *tx_desc,
ib_dma_unmap_single(device->ib_device, tx_desc->dma_addr,
ISER_HEADERS_LEN, DMA_TO_DEVICE);
kmem_cache_free(ig.desc_cache, tx_desc);
- }
-
- atomic_dec(_conn->post_send_buf_count);
-
- if (tx_desc->type == ISCSI_TX_CONTROL) {
+ } else if (tx_desc->type == ISCSI_TX_CONTROL) {
/* this arithmetic is legal by libiscsi dd_data allocation */
task = (void *) ((long)(void *)tx_desc -
sizeof(struct iscsi_task));
if (task->hdr->itt == RESERVED_ITT)
iscsi_put_task(task);
}
+
+ atomic_dec(_conn->post_send_buf_count);
}
void iser_task_rdma_init(struct iscsi_iser_task *iser_task)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: support for Intel Atom based QNAP LEDs/buttons/buzzer in Linux?
Hi Greg, Guenter and Chris. Coming back to the stuff discussed previously[0]. Chris Eastwood has made most of these (i.e. LEDs and buttons, the buzzers may work on at least some of the devices via some other serial device) working (AFAIU based on the previously mentioned code at Github[1]), he told me in several iterations of private mail. I'm not sure now, whether anything based on this code would be appropriate for the mainline kernel, since Guenter mentioned he'd prefer a mfd core driver for all that... OTOH, the later may probably never happen, and Chris' work seems to already do the job. I don't know however, whether he needs to patch any other places in the kernel, but I'm sure he can show his work (and ask questions) better than I, thereby inviting him to do so. Greg you had mentioned before that you might be able to spend some time on this, so if you could help Chris, that would be great. Cheers, Chris. [0] http://thread.gmane.org/gmane.linux.kernel/1508763/focus=1512903 [1] https://github.com/tomtastic/qnap-gpio/ PS: Sorry for having lost the message threading. -- 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] ARM: timer-sp: remove deprecated IRQF_DISABLED
If you want to either send these to the patch system, or alternatively
collect them up in a git tree somewhere for me and/or arm-soc to pull...
On Sat, Oct 12, 2013 at 04:52:02AM +0200, Michael Opdenacker wrote:
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
> ---
> arch/arm/common/timer-sp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
> index e901d0f..ce922d0 100644
> --- a/arch/arm/common/timer-sp.c
> +++ b/arch/arm/common/timer-sp.c
> @@ -175,7 +175,7 @@ static struct clock_event_device sp804_clockevent = {
>
> static struct irqaction sp804_timer_irq = {
> .name = "timer",
> - .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> .handler= sp804_timer_interrupt,
> .dev_id = _clockevent,
> };
> --
> 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/
Virtual Conference Invitation
Please resend this information to your colleagues who might be interested. We are sorry if you receive this CFP more than once. Virtual International Conferences Call For Papers The aim of the Virtual Conferences is create a space for researchers from from different scientific areas to exchange and communicate the new ideas and solutions. CURRENTLY CONFERENCES: *** HASSACC 2013 (November 18-22, 2013) Humanities Sciences at the Common Conference www.hassacc.com Registration & Submission Deadline: October 18, 2013 *** RCITD 2013 (November 18-22, 2013) International Virtual Research Conference In Technical Disciplines www.rcitd.com Registration & Submission Deadline: October 18, 2013 *** ARSA 2013 (December 2 - 6, 2013) Advanced Research in Scientific Areas www.arsa-conf.com Registration & Submission Deadline: November 4, 2013 *** QUAESTI 2013 (December 16 - 20, 2013) The 1st Virtual Multidisciplinary Conference www.quaesti.com Registration & Submission Deadline: November 18, 2013 *** We invite you to submit your research work (papers). Accepted papers will be sent for evaluation to major indexing databases as SCOPUS and GScholar. All conference participants eligible for receiving the conference materials with ISSN and ISBN, conference certificate and online entrance in to the Virtual Conference system. CORRESPONDENCE: THOMSON Ltd. Organizing Committee Univerzitna 8498/25 010 08 Zilina Slovakia E-mail: i...@the-science.com Virtual Conference portals: www.hassacc.com www.rcitd.com www.arsa-conf.com www.quaesti.com === If you are interested in receiving the latest updates from us, subscribe to our newsletter below. http://www.the-science.com/subscribe/mail_linux-ker...@vger.kernel.org/key_e10a6164f0bc200e9e9e6a735cc6a0f4 If you are not interested in receiving the latest updates from us, unsubscribe to our newsletter below. http://www.my-conf.com/unsubscribe.php?c=AhmHKgwNSgwj0qWmitAuQNJ9REgiSpAQInPEjRSfy3w= -- 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] unset twsi option3 for gconfig as well
Signed-off-by: Roel Kluin
---
drivers/pinctrl/mvebu/pinctrl-dove.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 29f7e4f..360b9b2 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -335,7 +335,7 @@ static int dove_twsi_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
gcfg1 &= ~DOVE_TWSI_ENABLE_OPTION1;
- gcfg2 &= ~(DOVE_TWSI_ENABLE_OPTION2 | DOVE_TWSI_ENABLE_OPTION2);
+ gcfg2 &= ~(DOVE_TWSI_ENABLE_OPTION2 | DOVE_TWSI_ENABLE_OPTION3);
switch (config) {
case 1:
--
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 v2 1/3] thermal: bcm281xx: Add thermal driver
On 27-09-2013 18:37, Wendy Ng wrote:
> This adds the support for reading out temperature from Broadcom bcm281xx
> SoCs.
>
> Signed-off-by: Wendy Ng
> Reviewed-by: Markus Mayer
> Reviewed-by: Christian Daudt
> ---
> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++
> drivers/thermal/Kconfig| 10 ++
> drivers/thermal/Makefile |1 +
> drivers/thermal/bcm_thermal.c | 170
>
> 4 files changed, 199 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> create mode 100644 drivers/thermal/bcm_thermal.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> new file mode 100644
> index 000..acca99e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
> @@ -0,0 +1,18 @@
> +* Broadcom Kona Thermal Management Unit
> +
> +This version is for the BCM281xx family of SoCs.
Might be worth describing the hardware a bit and also appending a link
to its documentation for further details.
> +
> +Required properties:
> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal"
> +- reg : Address range of the thermal register
> +- thermal-name: this entry must be specified and it will be passed into
> +thermal_zone_device_register(). This name will also be reported under Hwmon
> +sysfs 'name' attribute.
I guess by now you already remember my suggestion on this dt property.
If you can drop it then we could proceed with this driver. But with it
we are adding something specific to it that may be soon deprecated.
> +
> +Example:
> + thermal@34008000 {
> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal";
> + reg = <0x34008000 0x0024>;
> + thermal-name = "bcm_kona_therm";
> + status = "disabled";
> + };
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index dbfc390..6a5341c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL
> Support for the Kirkwood thermal sensor driver into the Linux thermal
> framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
>
> +config BCM_THERMAL
> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs"
> + depends on ARCH_BCM_MOBILE
Is the sensor IP used only on this Arch? No plans for re-usability?
> + default y
> + help
> + If you say yes here you get support for TMU (Thermal Management
> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal
> + monitoring of CPU clusters, graphics, and SoC glue, but does not
> + include monitoring of charger temperature.
> +
> config DOVE_THERMAL
> tristate "Temperature sensor on Marvell Dove SoCs"
> depends on ARCH_DOVE
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 584b363..3ea8c1c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
> obj-y+= samsung/
> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o
> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> diff --git a/drivers/thermal/bcm_thermal.c b/drivers/thermal/bcm_thermal.c
> new file mode 100644
> index 000..131d3c4
> --- /dev/null
> +++ b/drivers/thermal/bcm_thermal.c
> @@ -0,0 +1,170 @@
> +/*
> + * Copyright 2013 Broadcom Corporation.
> + *
> + * 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 (the "GPL").
> + *
> + * 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.
> + *
> + * A copy of the GPL is available at
> http://www.broadcom.com/licenses/GPLv2.php,
> + * or by writing to the Free Software Foundation, Inc.,
> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + */
> +
> +/**
> +* Broadcom Thermal Management Unit - bcm_tmu
> +*/
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* From TMON Register Database */
> +#define TMON_TEMP_VAL_OFFSET 0x001c
> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0
> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x03ff
> +
> +/* Broadcom Thermal Zone Device Structure */
> +struct bcm_thermal_zone_priv {
> + char
Re: Linux 3.12-rc5
Hi, On Sunday, October 13, 2013 03:52:49 PM Linus Torvalds wrote: > Things seem to be calming down nicely, and rc5 is smaller than previous rc's. > > In fact, the most excitement we had this week wasn't even a kernel > bug, it was a compiler bug wrt "asm goto" that was found because of > code that is pending to be merged in 3.13. But the (happily fairly > straightforward) workaround for the bug was merged early, because we > _do_ use asm goto, and it's unclear whether our existing use might > already trigger the bug, just not enough to be as obviously > noticeable. > > Aside from that, most of the changes here are the usual architecture > fixes (tile, arm, x86, s390) and drivers (gpu, hid, sound, i2c, > watchdog). With btrfs and the perf tool updates rounding out the rest. > And the usual random noise. > > Go forth and test, It looks like my pull request from yestarday has fallen through the cracks: http://marc.info/?l=linux-acpi=138161145214296=2 Or is there anything wrong with it? Rafael -- 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 3.4.66
diff --git a/Makefile b/Makefile
index 3a8897f..e9587ab 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 65
+SUBLEVEL = 66
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8f5813b..056cfbe 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -98,6 +98,9 @@ void show_mem(unsigned int filter)
printk("Mem-info:\n");
show_free_areas(filter);
+ if (filter & SHOW_MEM_FILTER_PAGE_COUNT)
+ return;
+
for_each_bank (i, mi) {
struct membank *bank = >bank[i];
unsigned int pfn1, pfn2;
diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index 1516d1d..f2652fc 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -47,6 +47,8 @@ void show_mem(unsigned int filter)
printk(KERN_INFO "Mem-info:\n");
show_free_areas(filter);
printk(KERN_INFO "Node memory in pages:\n");
+ if (filter & SHOW_MEM_FILTER_PAGE_COUNT)
+ return;
for_each_online_pgdat(pgdat) {
unsigned long present;
unsigned long flags;
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index c641333..2230817 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -623,6 +623,8 @@ void show_mem(unsigned int filter)
printk(KERN_INFO "Mem-info:\n");
show_free_areas(filter);
+ if (filter & SHOW_MEM_FILTER_PAGE_COUNT)
+ return;
printk(KERN_INFO "Node memory in pages:\n");
for_each_online_pgdat(pgdat) {
unsigned long present;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 82f364e..0b62162 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -685,6 +685,8 @@ void show_mem(unsigned int filter)
printk(KERN_INFO "Mem-info:\n");
show_free_areas(filter);
+ if (filter & SHOW_MEM_FILTER_PAGE_COUNT)
+ return;
#ifndef CONFIG_DISCONTIGMEM
i = max_mapnr;
while (i-- > 0) {
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 359f078..b2f4a8ed 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -501,7 +501,7 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
/* number of bytes needed for the bitmap */
sz = (tbl->it_size + 7) >> 3;
- page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
+ page = alloc_pages_node(nid, GFP_KERNEL, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
tbl->it_map = page_address(page);
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index a3a9990..cfe0069 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1341,11 +1341,15 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *attr,
const char *cp;
dn = dev->of_node;
- if (!dn)
- return -ENODEV;
+ if (!dn) {
+ strcat(buf, "\n");
+ return strlen(buf);
+ }
cp = of_get_property(dn, "compatible", NULL);
- if (!cp)
- return -ENODEV;
+ if (!cp) {
+ strcat(buf, "\n");
+ return strlen(buf);
+ }
return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
}
diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 18245af..afa2eba 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -272,8 +272,8 @@ _GLOBAL(csum_partial_copy_generic)
rldicl. r6,r3,64-1,64-2 /* r6 = (r3 & 0x3) >> 1 */
beq .Lcopy_aligned
- li r7,4
- sub r6,r7,r6
+ li r9,4
+ sub r6,r9,r6
mtctr r6
1:
diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index f445e98..cfabc3d 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -1177,7 +1177,7 @@ sys_sigreturn:
nop
callsyscall_trace
-nop
+mov1, %o1
1:
/* We don't want to muck with user registers like a
diff --git a/arch/sparc/kernel/ktlb.S b/arch/sparc/kernel/ktlb.S
index 79f3103..7c00735 100644
--- a/arch/sparc/kernel/ktlb.S
+++ b/arch/sparc/kernel/ktlb.S
@@ -25,11 +25,10 @@ kvmap_itlb:
*/
kvmap_itlb_4v:
-kvmap_itlb_nonlinear:
/* Catch kernel NULL pointer calls. */
sethi %hi(PAGE_SIZE), %g5
cmp %g4, %g5
- bleu,pn %xcc, kvmap_dtlb_longpath
+ blu,pn %xcc, kvmap_itlb_longpath
nop
KERN_TSB_LOOKUP_TL1(%g4, %g6, %g5, %g1, %g2, %g3, kvmap_itlb_load)
diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S
index 7f5f65d..817187d 100644
--- a/arch/sparc/kernel/syscalls.S
+++ b/arch/sparc/kernel/syscalls.S
@@ -147,7
Linux 3.4.66
I'm announcing the release of the 3.4.66 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 - arch/arm/mm/init.c |3 + arch/ia64/mm/contig.c |2 + arch/ia64/mm/discontig.c|2 + arch/parisc/mm/init.c |2 + arch/powerpc/kernel/iommu.c |2 - arch/powerpc/kernel/vio.c | 12 -- arch/powerpc/lib/checksum_64.S |4 +- arch/sparc/kernel/entry.S |2 - arch/sparc/kernel/ktlb.S|3 - arch/sparc/kernel/syscalls.S|8 ++-- arch/sparc/kernel/trampoline_64.S |2 - arch/sparc/lib/ksyms.c |9 arch/tile/include/asm/percpu.h | 34 - arch/unicore32/mm/init.c|3 + drivers/acpi/acpi_ipmi.c| 24 +++- drivers/block/cciss.c |1 drivers/block/cpqarray.c|1 drivers/dma/imx-dma.c | 31 +++- drivers/infiniband/ulp/srpt/ib_srpt.c | 14 +++ drivers/net/bonding/bond_main.c | 13 +- drivers/net/ethernet/freescale/gianfar.c| 11 + drivers/net/ethernet/freescale/gianfar.h| 11 + drivers/net/ethernet/via/via-rhine.c|9 +++- drivers/net/ethernet/xilinx/ll_temac_main.c |6 +++ drivers/net/ppp/pptp.c |2 - drivers/net/usb/dm9601.c|2 - drivers/net/wireless/p54/p54usb.c |1 drivers/net/wireless/rtlwifi/wifi.h |2 - drivers/scsi/esp_scsi.c | 14 --- drivers/scsi/esp_scsi.h |1 drivers/staging/comedi/drivers/ni_65xx.c| 26 + drivers/usb/serial/option.c |3 + fs/btrfs/relocation.c | 14 +++ fs/ext4/namei.c |3 + include/linux/mm.h |3 + include/net/ip.h| 12 -- include/net/ipip.h |2 - lib/show_mem.c |3 + mm/page_alloc.c |7 +++ net/bluetooth/hci_event.c |6 ++- net/bridge/br_private.h |1 net/bridge/br_stp.c | 23 net/bridge/br_stp_if.c | 12 +- net/caif/cfctrl.c |3 + net/core/flow_dissector.c |4 +- net/core/netpoll.c |9 ++-- net/ipv4/igmp.c |8 ++-- net/ipv4/inetpeer.c |4 +- net/ipv4/ip_output.c|8 ++-- net/ipv4/ipmr.c |2 - net/ipv4/raw.c |2 - net/ipv4/xfrm4_mode_tunnel.c|2 - net/ipv6/ip6_output.c | 53 +++- net/ipv6/mcast.c|4 +- net/netfilter/ipvs/ip_vs_xmit.c |2 - net/sctp/ipv6.c | 42 ++ net/sctp/socket.c |3 + sound/soc/codecs/88pm860x-codec.c |3 + sound/soc/codecs/max98095.c |4 +- 60 files changed, 297 insertions(+), 204 deletions(-) Andre Guedes (2): Bluetooth: Fix security level for peripheral role Bluetooth: Fix encryption key size for peripheral role Ansis Atteka (2): ip: use ip_hdr() in __ip_make_skb() to retrieve IP header ip: generate unique IP identificator if local fragmentation is allowed Chris Healy (1): resubmit bridge: fix message_age_timer calculation Chris Metcalf (1): tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT Christian Lamparter (1): p54usb: add USB ID for Corega WLUSB2GTST USB adapter Claudiu Manoil (1): gianfar: Change default HW Tx queue scheduling mode Dan Carpenter (4): cpqarray: fix info leak in ida_locked_ioctl() cciss: fix info leak in cciss_ioctl32_passthru() ASoC: max98095: a couple array underflows ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st() Daniel Borkmann (2): net: sctp: fix smatch warning in sctp_send_asconf_del_ip net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit Dave Jones (1): caif: Add missing braces to multiline if in cfctrl_linkup_request
Linux 3.12-rc5
Things seem to be calming down nicely, and rc5 is smaller than previous rc's. In fact, the most excitement we had this week wasn't even a kernel bug, it was a compiler bug wrt "asm goto" that was found because of code that is pending to be merged in 3.13. But the (happily fairly straightforward) workaround for the bug was merged early, because we _do_ use asm goto, and it's unclear whether our existing use might already trigger the bug, just not enough to be as obviously noticeable. Aside from that, most of the changes here are the usual architecture fixes (tile, arm, x86, s390) and drivers (gpu, hid, sound, i2c, watchdog). With btrfs and the perf tool updates rounding out the rest. And the usual random noise. Go forth and test, Linus --- Aaro Koskinen (1): ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT Alex Deucher (10): drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation drm/radeon: use 64-bit math to calculate CTS values for audio (v2) drm/radeon: fix N/CTS clock matching for audio drm/radeon: use hw generated CTS/N values for audio drm/radeon/dpm: disable multiple UVD states drm/radeon: fix typo in CP DMA register headers drm/radeon: improve soft reset on SI drm/radeon: improve soft reset on CIK drm/radeon/dpm: disable bapm on TN asics drm/radeon: re-enable sw ACR support on pre-DCE4 Anders F. U. Kiær (1): HID: add Holtek USB ID 04d9:a081 SHARKOON DarkGlider Andy Shevchenko (1): arch: tile: re-use kbasename() helper Anssi Hannula (1): ALSA: hda - hdmi: Fix channel map switch not taking effect Arnaldo Carvalho de Melo (2): perf tools: Fix libaudit test perf tools: Fix installation of libexec components Axel Lin (1): spi: clps711x: Don't call kfree() after spi_master_put/spi_unregister_master Ben Skeggs (1): drm/nouveau/mc: disable msi support by default, it's busted in tons of places Benjamin Herrenschmidt (1): powerpc/irq: Don't switch to irq stack from softirq stack Bharat Bhushan (1): kvm: ppc: booke: check range page invalidation progress on page setup Brian Norris (1): mtd: nand: fix memory leak in ONFI extended parameter page Chen Gang (1): tile: include: asm: use 'long long' instead of 'u64' for atomic64_t and its related functions Chris Metcalf (2): tile: ensure interrupts disabled for preempt_schedule_irq() tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT Chris Wilson (1): drm/i915: Only apply DPMS to the encoder if enabled Christian Borntraeger (1): s390/sclp: properly detect line mode console Dan Carpenter (4): drm/radeon: forever loop on error in radeon_do_test_moves() drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers() drm/radeon/dpm: off by one in si_set_mc_special_registers() watchdog: ts72xx_wdt: locking bug in ioctl Daniel Mack (1): ALSA: snd-usb-usx2y: remove bogus frame checks Dave Airlie (3): Revert "drm/fb-helper: don't sleep for screen unblank when an oops is in progress" Revert "drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done" Revert "i915: Update VGA arbiter support for newer devices" Dave Jones (1): ext4: fix memory leak in xattr David Ahern (1): perf tools: Add default handler for mmap2 events David Henningsson (4): ALSA: hda - Fix mono speakers and headset mic on Dell Vostro 5470 ALSA: hda - Fix microphone for Sony VAIO Pro 13 (Haswell model) ALSA: hda - Add a headset mic model for ALC269 and friends ALSA: hda - Sony VAIO Pro 13 (haswell) now has a working headset jack David Herrmann (2): HID: uhid: allocate static minor HID: wiimote: fix FF deadlock Elie De Brauwer (1): mtd: m25p80: Fix 4 byte addressing mode for Micron devices. Fengguang Wu (1): kobject: show debug info on delayed kobject release Francisco Jerez (1): drm/i915/hsw: Disable L3 caching of atomic memory operations. Geert Uytterhoeven (1): parisc: Export flush_cache_page() (needed by lustre) Geyslan G. Bem (1): dma: edma.c: remove edma_desc leakage Gleb Natapov (1): KVM: nVMX: fix shadow on EPT Heiko Carstens (1): s390/kprobes: add exrl to list of prohibited opcodes Helge Deller (4): parisc: remove unused syscall_ipi() function. parisc: mark parisc_terminate() noreturn and cold. parisc: fix interruption handler to respect pagefault_disable() parisc: let probe_kernel_read() capture access to page zero Henrik Austad (1): tile: change lock initalization in hardwall Henrik Rydberg (1): hwmon: (applesmc) Always read until end of data Imre Deak (1): drm/i915: fix rps.vlv_work initialization Ingo Molnar (1): compiler/gcc4: Add quirk for 'asm goto' miscompilation bug Ionut Nicu (2): i2c: i2c-mux-gpio: don't ignore of_get_named_gpio errors i2c:
[PATCH] set data enable logic level to low
Signed-off-by: Roel Kluin --- drivers/video/omap2/dss/display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c index fafe7c9..669a81f 100644 --- a/drivers/video/omap2/dss/display.c +++ b/drivers/video/omap2/dss/display.c @@ -266,7 +266,7 @@ void videomode_to_omap_video_timings(const struct videomode *vm, OMAPDSS_SIG_ACTIVE_LOW; ovt->de_level = vm->flags & DISPLAY_FLAGS_DE_HIGH ? OMAPDSS_SIG_ACTIVE_HIGH : - OMAPDSS_SIG_ACTIVE_HIGH; + OMAPDSS_SIG_ACTIVE_LOW; ovt->data_pclk_edge = vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE ? OMAPDSS_DRIVE_SIG_RISING_EDGE : OMAPDSS_DRIVE_SIG_FALLING_EDGE; -- 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: Linux 3.0.100
diff --git a/Makefile b/Makefile
index 0d6881a..a6ddb9d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 99
+SUBLEVEL = 100
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 961bb03..795e807 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -495,7 +495,7 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
/* number of bytes needed for the bitmap */
sz = (tbl->it_size + 7) >> 3;
- page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
+ page = alloc_pages_node(nid, GFP_KERNEL, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
tbl->it_map = page_address(page);
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 1b695fd..c9f2ac8 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1345,11 +1345,15 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *attr,
const char *cp;
dn = dev->of_node;
- if (!dn)
- return -ENODEV;
+ if (!dn) {
+ strcat(buf, "\n");
+ return strlen(buf);
+ }
cp = of_get_property(dn, "compatible", NULL);
- if (!cp)
- return -ENODEV;
+ if (!cp) {
+ strcat(buf, "\n");
+ return strlen(buf);
+ }
return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
}
diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 18245af..afa2eba 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -272,8 +272,8 @@ _GLOBAL(csum_partial_copy_generic)
rldicl. r6,r3,64-1,64-2 /* r6 = (r3 & 0x3) >> 1 */
beq .Lcopy_aligned
- li r7,4
- sub r6,r7,r6
+ li r9,4
+ sub r6,r9,r6
mtctr r6
1:
diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index f445e98..cfabc3d 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -1177,7 +1177,7 @@ sys_sigreturn:
nop
callsyscall_trace
-nop
+mov1, %o1
1:
/* We don't want to muck with user registers like a
diff --git a/arch/sparc/kernel/ktlb.S b/arch/sparc/kernel/ktlb.S
index 79f3103..7c00735 100644
--- a/arch/sparc/kernel/ktlb.S
+++ b/arch/sparc/kernel/ktlb.S
@@ -25,11 +25,10 @@ kvmap_itlb:
*/
kvmap_itlb_4v:
-kvmap_itlb_nonlinear:
/* Catch kernel NULL pointer calls. */
sethi %hi(PAGE_SIZE), %g5
cmp %g4, %g5
- bleu,pn %xcc, kvmap_dtlb_longpath
+ blu,pn %xcc, kvmap_itlb_longpath
nop
KERN_TSB_LOOKUP_TL1(%g4, %g6, %g5, %g1, %g2, %g3, kvmap_itlb_load)
diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S
index 7f5f65d..817187d 100644
--- a/arch/sparc/kernel/syscalls.S
+++ b/arch/sparc/kernel/syscalls.S
@@ -147,7 +147,7 @@ linux_syscall_trace32:
srl %i4, 0, %o4
srl %i1, 0, %o1
srl %i2, 0, %o2
- ba,pt %xcc, 2f
+ ba,pt %xcc, 5f
srl%i3, 0, %o3
linux_syscall_trace:
@@ -177,13 +177,13 @@ linux_sparc_syscall32:
srl %i1, 0, %o1 ! IEU0 Group
ldx [%g6 + TI_FLAGS], %l0 ! Load
- srl %i5, 0, %o5 ! IEU1
+ srl %i3, 0, %o3 ! IEU0
srl %i2, 0, %o2 ! IEU0 Group
andcc %l0,
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT),
%g0
bne,pn %icc, linux_syscall_trace32 ! CTI
mov%i0, %l5! IEU1
- call%l7 ! CTI Group brk forced
-srl%i3, 0, %o3 ! IEU0
+5: call%l7 ! CTI Group brk forced
+srl%i5, 0, %o5 ! IEU1
ba,a,pt %xcc, 3f
/* Linux native system calls enter here... */
diff --git a/arch/sparc/kernel/trampoline_64.S
b/arch/sparc/kernel/trampoline_64.S
index da1b781..8fa84a3 100644
--- a/arch/sparc/kernel/trampoline_64.S
+++ b/arch/sparc/kernel/trampoline_64.S
@@ -131,7 +131,6 @@ startup_continue:
clr %l5
sethi %hi(num_kernel_image_mappings), %l6
lduw[%l6 + %lo(num_kernel_image_mappings)], %l6
- add %l6, 1, %l6
mov 15, %l7
BRANCH_IF_ANY_CHEETAH(g1,g5,2f)
@@ -224,7 +223,6 @@ niagara_lock_tlb:
clr %l5
sethi %hi(num_kernel_image_mappings), %l6
lduw[%l6 + %lo(num_kernel_image_mappings)], %l6
- add
Re: [PATCH v2 3/3] ARM: bcm281xx: Add thermal driver to device tree.
On 27-09-2013 18:37, Wendy Ng wrote:
> This patch adds the device tree node for Broadcom bcm281xx SoCs thermal
> driver.
>
> Signed-off-by: Wendy Ng
> Reviewed-by: Markus Mayer
> Reviewed-by: Christian Daudt
> ---
> arch/arm/boot/dts/bcm11351-brt.dts |4 +++-
> arch/arm/boot/dts/bcm11351.dtsi|6 ++
> arch/arm/boot/dts/bcm28155-ap.dts |4
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351-brt.dts
> b/arch/arm/boot/dts/bcm11351-brt.dts
> index 9d36eb4..0771b6b 100644
> --- a/arch/arm/boot/dts/bcm11351-brt.dts
> +++ b/arch/arm/boot/dts/bcm11351-brt.dts
> @@ -43,5 +43,7 @@
> status = "okay";
> };
>
> -
> + thermal@34008000 {
> + status = "okay";
> + };
> };
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 05a5aab..aa13353 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -96,4 +96,10 @@
> status = "disabled";
> };
>
> + thermal@34008000 {
> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal";
> + reg = <0x34008000 0x0024>;
> + thermal-name = "bcm_kona_therm";
As I mentioned previously, my only concern is this thermal binding,
which is specific to your driver (BTW, you would need to do
bcm,thermal-name)
> + status = "disabled";
> + };
> };
> diff --git a/arch/arm/boot/dts/bcm28155-ap.dts
> b/arch/arm/boot/dts/bcm28155-ap.dts
> index 96ae67a..a39aa47 100644
> --- a/arch/arm/boot/dts/bcm28155-ap.dts
> +++ b/arch/arm/boot/dts/bcm28155-ap.dts
> @@ -42,4 +42,8 @@
> max-frequency = <4800>;
> status = "okay";
> };
> +
> + thermal@34008000 {
> + status = "okay";
> + };
> };
>
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Linux 3.0.100
-- NOTE! The 3.0.x kernel series will be moving to End-Of-Life soon, within a week. Please move anything that is relying on this kernel version to the other longterm kernel releases (3.4.x or 3.10.x) as soon as possible. If anyone has any questions about this, please let me know. -- I'm announcing the release of the 3.0.100 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/powerpc/kernel/iommu.c |2 arch/powerpc/kernel/vio.c| 12 +++-- arch/powerpc/lib/checksum_64.S |4 - arch/sparc/kernel/entry.S|2 arch/sparc/kernel/ktlb.S |3 - arch/sparc/kernel/syscalls.S |8 +-- arch/sparc/kernel/trampoline_64.S|2 arch/sparc/lib/ksyms.c |9 --- arch/tile/include/asm/percpu.h | 34 +- drivers/acpi/acpi_ipmi.c | 24 ++ drivers/block/cciss.c|1 drivers/block/cpqarray.c |1 drivers/net/bonding/bond_main.c | 13 - drivers/net/ll_temac_main.c |6 ++ drivers/net/pptp.c |2 drivers/net/tg3.c|7 ++- drivers/net/usb/dm9601.c |2 drivers/net/via-rhine.c |9 +++ drivers/net/wireless/p54/p54usb.c|1 drivers/net/wireless/rtlwifi/wifi.h |2 drivers/pci/intel-iommu.c| 72 +++ drivers/scsi/esp_scsi.c | 14 +++--- drivers/scsi/esp_scsi.h |1 drivers/staging/comedi/drivers/ni_65xx.c | 26 --- drivers/staging/hv/tools/hv_kvp_daemon.c | 10 +++- drivers/usb/serial/option.c |3 + fs/btrfs/relocation.c| 14 +++--- fs/ext4/namei.c |3 - include/net/ip.h | 12 +++-- include/net/ipip.h |2 net/bridge/br_private.h |1 net/bridge/br_stp.c | 23 ++--- net/bridge/br_stp_if.c | 12 - net/caif/cfctrl.c|3 - net/core/netpoll.c |9 +-- net/ipv4/igmp.c |8 +-- net/ipv4/inetpeer.c |4 - net/ipv4/ip_output.c |6 +- net/ipv4/ipmr.c |2 net/ipv4/raw.c |2 net/ipv4/xfrm4_mode_tunnel.c |2 net/ipv6/ip6_output.c| 53 +- net/ipv6/mcast.c |4 - net/netfilter/ipvs/ip_vs_xmit.c |2 net/sctp/ipv6.c | 42 +- sound/soc/codecs/88pm860x-codec.c|3 + sound/soc/codecs/max98095.c |4 - 48 files changed, 267 insertions(+), 216 deletions(-) Alex Williamson (1): intel-iommu: Fix leaks in pagetable freeing Ansis Atteka (1): ip: generate unique IP identificator if local fragmentation is allowed Chris Healy (1): resubmit bridge: fix message_age_timer calculation Chris Metcalf (1): tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT Christian Lamparter (1): p54usb: add USB ID for Corega WLUSB2GTST USB adapter Dan Carpenter (4): cpqarray: fix info leak in ida_locked_ioctl() cciss: fix info leak in cciss_ioctl32_passthru() ASoC: max98095: a couple array underflows ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st() Daniel Borkmann (1): net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit Dave Jones (1): caif: Add missing braces to multiline if in cfctrl_linkup_request David S. Miller (2): esp_scsi: Fix tag state corruption when autosensing. sparc64: Fix off by one in trampoline TLB mapping installation loop. Greg Kroah-Hartman (1): Linux 3.0.100 Hannes Frederic Sowa (1): ipv6: udp packets following an UFO enqueued packet need also be handled by UFO Herbert Xu (1): bridge: Clamp forward_delay when enabling STP Ian Abbott (1): staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice Josef Bacik (1): Btrfs: change how we queue blocks for backref checking Kees Cook (1): tg3: fix length overflow in VPD firmware parsing Kirill Tkhai (4): sparc64: Fix ITLB handler of null page sparc64: Remove RWSEM export leftovers sparc64: Fix not SRA'ed
Re: [PATCH v2 2/3] ARM: bcm281xx: Turn on Thermal and HWMON drivers.
Wendy, On 27-09-2013 18:37, Wendy Ng wrote: > This enables the thermal and HWMON drivers for Broadcom bcm281xx SoCs. > > Signed-off-by: Wendy Ng > Reviewed-by: Markus Mayer > Reviewed-by: Christian Daudt > --- > arch/arm/configs/bcm_defconfig |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig > index 6e49310..1474661 100644 > --- a/arch/arm/configs/bcm_defconfig > +++ b/arch/arm/configs/bcm_defconfig > @@ -83,7 +83,8 @@ CONFIG_SERIAL_8250_DW=y > CONFIG_HW_RANDOM=y > CONFIG_I2C=y > CONFIG_I2C_CHARDEV=y > -# CONFIG_HWMON is not set > +CONFIG_THERMAL=y Maybe you also wanted to CONFIG_BCM_THERMAL=y ? > +CONFIG_HWMON=y > CONFIG_VIDEO_OUTPUT_CONTROL=y > CONFIG_FB=y > CONFIG_BACKLIGHT_LCD_SUPPORT=y > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] thermal: st: Add support for STiH41x thermal sensors
Hello Ajit,
Sorry for the long delay answering you. I found a couple of minor points
still on this code. Can you please check them?
On 25-09-2013 07:01, Ajit Pal Singh wrote:
> Adds support for thermal sensors on STiH41x series SOCs.
> Single trip point 'THERMAL_TRIP_CRITICAL' is supported.
> STIH416 MPE sensor supports interrupt reporting when a preset
> threshold temperature is crossed.
> For rest of the thermal sensors a polling delay of 1ms is
> set.
>
> CC: Stephen Gallimore
> CC: Srinivas Kandagatla
> Signed-off-by: Ajit Pal Singh
> ---
> .../devicetree/bindings/thermal/st-thermal.txt | 22 +
> drivers/thermal/Kconfig| 11 +
> drivers/thermal/Makefile |1 +
> drivers/thermal/st_thermal.c | 632
>
> 4 files changed, 666 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/st-thermal.txt
> create mode 100644 drivers/thermal/st_thermal.c
> ---
> History
> v2: Updated with review comments from Eduardo Valentin.
>
> diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt
> b/Documentation/devicetree/bindings/thermal/st-thermal.txt
> new file mode 100644
> index 000..f127044
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/st-thermal.txt
> @@ -0,0 +1,22 @@
> +Binding for Thermal sensor driver for STMicroelectronics STiH41x series of
> SoCs.
> +
Might be worth describing the IP and giving a link to hardware
documentation.
> +Required parameters:
> +1) compatible : st,--thermal
> + Should be one of "st,stih415-sas-thermal",
> "st,stih415-mpe-thermal",
> + "st,stih416-sas-thermal" or "st,stih416-mpe-thermal" according
> to the
> + SoC type (stih415 or stih416) and module type (sas or mpe).
> +2) st,syscfg : Should be a phandle of the syscfg node.
> +3) clocks: phandle of the clock used by the thermal sensor according to
> the common
> + clock binding:
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Optional:
> +1) interrupts: Standard way to define interrupt number.
> + refer: Documentation/devicetree/bindings/resource-names.txt
> + Interrupt is mandatory to be defined when compatible is
> stih416-mpe-thermal.
> +
> +Example:
> +temp0{
> + compatible = "st,stih416-sas-thermal";
> + st,syscfg = <_front>;
> + clocks = <_C_VCC 14>;
> +}
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e988c81..158b4d8 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -180,6 +180,17 @@ config X86_PKG_TEMP_THERMAL
> two trip points which can be set by user to get notifications via
> thermal
> notification methods.
>
> +config ST_THERMAL
> + tristate "Thermal sensors on STMicroelectronics STiH41x series of SoCs"
> + depends on ARCH_STI
The IP you are adding the support is used only on ARCH_STI and there is
no plan for re-usability?
> + depends on OF
> + default y
> + help
> + Support for thermal sensors on STMicroelectronics STiH41x series of
> + SoCs. STiH415 and STiH416 SoCs have 2 thermal sensors each, one on the
> + SAS and second on the MPE module. STiH416 MPE thermal sensor supports
> + interrupt reporting when a preset thermal threshold is crossed.
> +
> menu "Texas Instruments thermal drivers"
> source "drivers/thermal/ti-soc-thermal/Kconfig"
> endmenu
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 67184a2..d0a4c86 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_DB8500_CPUFREQ_COOLING)+=
> db8500_cpufreq_cooling.o
> obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
> obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
> obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/
> +obj-$(CONFIG_ST_THERMAL) += st_thermal.o
> diff --git a/drivers/thermal/st_thermal.c b/drivers/thermal/st_thermal.c
> new file mode 100644
> index 000..dbb573e
> --- /dev/null
> +++ b/drivers/thermal/st_thermal.c
> @@ -0,0 +1,632 @@
> +/*
> + * st_thermal.c: ST Thermal Sensor Driver for STIH41x series of SoCs
> + * Author: Ajit Pal Singh
> + *
> + * Copyright (C) 2003-2013 STMicroelectronics (R) Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "st-thermal"
> +
> +/* Regfield IDs */
> +enum {
> + /*
> + * The PWR and INTerrupt threshold regfields
> + * share the same index as they are mutually
Re: [ 34/48] kernel/kmod.c: check for NULL in call_usermodehelper_exec()
On Sat, Oct 12, 2013 at 07:36:06AM +0900, Tetsuo Handa wrote:
> Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
>
> 3.4-stable doesn't need this patch because commit 264b83c07a84
> ("usermodehelper: check subprocess_info->path != NULL") already fixed it.
Thanks for pointing this out for 3.0, 3.4, and 3.10, I totally got it
wrong there, despite you telling me this before. I've now dropped it
from those three kernels.
thanks again,
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: [RFC] perf record,top: Add callchain option into .perfconfig
On Sun, Oct 13, 2013 at 11:18:05PM +0200, Jiri Olsa wrote: > On Sun, Oct 13, 2013 at 12:25:21PM +0200, Jiri Olsa wrote: > > SNIP > > > > > I'll try to come up with something later today > > > > jirka > > > hi, > here it is.. not fully tested, no doc updates, dont want > to go too far before we agreed on this ;-) I don't think that's a good idea. Still need some way to control dwarf from the command line. -Andi -- 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] perf make: Move DEBUG initialization into Makefile.perf
Adding new top level Makefile invalidated the
DEBUG variable check for "command line" origin.
Moving this check into Makefile.perf.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
---
tools/perf/Makefile| 6 +-
tools/perf/config/Makefile | 3 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 5aa3d04..db21dad 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -37,12 +37,16 @@ ifneq ($(O),)
FULL_O := $(shell readlink -f $(O))
endif
+ifeq ("$(origin DEBUG)", "command line")
+ D = $(DEBUG)
+endif
+
define print_msg
@printf ' BUILD: Doing '\''make \033[33m-j'$(JOBS)'\033[m'\'' parallel
build\n'
endef
define make
- @$(MAKE) -f Makefile.perf --no-print-directory -j$(JOBS) O=$(FULL_O) $@
+ @$(MAKE) -f Makefile.perf --no-print-directory -j$(JOBS) O=$(FULL_O)
PERF_DEBUG=$(D) $@
endef
#
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 9680424..912026a 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -66,9 +66,6 @@ ifneq ($(WERROR),0)
CFLAGS += -Werror
endif
-ifeq ("$(origin DEBUG)", "command line")
- PERF_DEBUG = $(DEBUG)
-endif
ifndef PERF_DEBUG
CFLAGS += -O6
endif
--
1.7.11.7
--
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/
[RFC] perf record,top: Add callchain option into .perfconfig
On Sun, Oct 13, 2013 at 12:25:21PM +0200, Jiri Olsa wrote:
SNIP
>
> I'll try to come up with something later today
>
> jirka
hi,
here it is.. not fully tested, no doc updates, dont want
to go too far before we agreed on this ;-)
thanks for comments,
jirka
--
The callchain option is now used only to enable
callchains. By default it's framepointer type.
If dwarf unwind is needed, following option needs
to be added into .perfconfig:
for top command:
[top]
call-graph = dwarf,8192
for record command:
[record]
call-graph = dwarf,8192
running perf with above config like this:
perf record -g ls
perf top -G
will enable dwarf unwind. The config file option
by itself does not enable the callchain, the -g/-G
option does.
TODO: doc/help needs to be updated
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-record.c | 58 ++---
tools/perf/builtin-top.c| 23 +++---
tools/perf/perf.h | 1 +
tools/perf/util/callchain.h | 4 +++-
tools/perf/util/evsel.c | 2 +-
5 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 92ca541..9b245d3 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -709,19 +709,35 @@ static int get_stack_size(char *str, unsigned long *_size)
#endif /* HAVE_LIBUNWIND_SUPPORT */
int record_parse_callchain_opt(const struct option *opt,
- const char *arg, int unset)
+ const char *arg __maybe_unused,
+ int unset)
{
struct perf_record_opts *opts = opt->value;
- char *tok, *name, *saveptr = NULL;
- char *buf;
- int ret = -1;
+
+ opts->call_graph_enabled = !unset;
/* --no-call-graph */
- if (unset)
+ if (unset) {
+ opts->call_graph = CALLCHAIN_NONE;
return 0;
+ }
+
+ if (opts->call_graph == CALLCHAIN_NONE)
+ opts->call_graph = CALLCHAIN_FP;
+
+ pr_debug("callchain: type %d\n", opts->call_graph);
+
+ if (opts->call_graph == CALLCHAIN_DWARF)
+ pr_debug("callchain: stack dump size %d\n",
+opts->stack_dump_size);
+ return 0;
+}
- /* We specified default option if none is provided. */
- BUG_ON(!arg);
+int record_parse_callchain(const char *arg, struct perf_record_opts *opts)
+{
+ char *tok, *name, *saveptr = NULL;
+ char *buf;
+ int ret = -1;
/* We need buffer that we know we can write to. */
buf = malloc(strlen(arg) + 1);
@@ -740,7 +756,7 @@ int record_parse_callchain_opt(const struct option *opt,
opts->call_graph = CALLCHAIN_FP;
ret = 0;
} else
- pr_err("callchain: No more arguments "
+ fprintf(stderr, "callchain: No more arguments "
"needed for -g fp\n");
break;
@@ -760,13 +776,9 @@ int record_parse_callchain_opt(const struct option *opt,
ret = get_stack_size(tok, );
opts->stack_dump_size = size;
}
-
- if (!ret)
- pr_debug("callchain: stack dump size %d\n",
-opts->stack_dump_size);
#endif /* HAVE_LIBUNWIND_SUPPORT */
} else {
- pr_err("callchain: Unknown -g option "
+ fprintf(stderr, "callchain: Unknown -g option "
"value: %s\n", arg);
break;
}
@@ -774,11 +786,17 @@ int record_parse_callchain_opt(const struct option *opt,
} while (0);
free(buf);
+ return ret;
+}
- if (!ret)
- pr_debug("callchain: type %d\n", opts->call_graph);
+static int perf_record_config(const char *var, const char *value, void *cb)
+{
+ struct perf_record *rec = cb;
- return ret;
+ if (!strcmp(var, "record.call-graph"))
+ return record_parse_callchain(value, >opts);
+
+ return perf_default_config(var, value, cb);
}
static const char * const record_usage[] = {
@@ -855,9 +873,9 @@ const struct option record_options[] = {
perf_evlist__parse_mmap_pages),
OPT_BOOLEAN(0, "group", ,
"put the counters into a counter group"),
- OPT_CALLBACK_DEFAULT('g', "call-graph", ,
-"mode[,dump_size]", record_callchain_help,
-_parse_callchain_opt, "fp"),
+ OPT_CALLBACK_NOOPT('g', "call-graph", ,
+ "mode[,dump_size]", record_callchain_help,
+ _parse_callchain_opt),
OPT_INCR('v',
CONFIG_SLUB/USE_SPLIT_PTLOCKS compatibility
Hello, I'm reliably getting kernel crash on xtensa when CONFIG_SLUB is selected and USE_SPLIT_PTLOCKS appears to be true (SMP=y, NR_CPUS=4, DEBUG_SPINLOCK=n, DEBUG_LOCK_ALLOC=n). This happens because spinlock_t ptl and struct page *first_page overlap in the struct page. The following call chain makes allocation of order 3 and initializes first_page pointer in its 7 tail pages: do_page_fault handle_mm_fault __pte_alloc kmem_cache_alloc __slab_alloc new_slab __alloc_pages_nodemask get_page_from_freelist prep_compound_page Later pte_offset_map_lock is called with one of these tail pages overwriting its first_page pointer: do_fork copy_process dup_mm copy_page_range copy_pte_range pte_alloc_map_lock pte_offset_map_lock Finally kmem_cache_free is called for that tail page, which calls slab_free(s, virt_to_head_page(x),... but virt_to_head_page here returns NULL, because the page's first_page pointer was overwritten earlier: exit_mmap free_pgtables free_pgd_range free_pud_range free_pmd_range free_pte_range pte_free kmem_cache_free slab_free __slab_free __slab_free touches NULL struct page, that's it. Changing allocator to SLAB or enabling DEBUG_SPINLOCK fixes that crash. My question is, is CONFIG_SLUB supposed to work with USE_SPLIT_PTLOCKS (and if yes what's wrong in my case)? -- Thanks. -- Max -- 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] x86/efi: Add EFI framebuffer earlyprintk support
On 10/12/2013 10:49 AM, Ingo Molnar wrote:
>
+static void early_efi_write_char(void *dst, char c, int h)
+{
+ const u8 *src;
+ u32 fgcolor = 0xaa;
>>>
>>> That's RGB grey, right? Why not 0xff for a very visible white?
>>
>> The VGA earlyprintk code uses the equivalent grey, AFAIK, which is why I
>> picked this value.
>
> The VGA code should be changed to white too I suspect ;-)
>
For compatibility with the classical text console we use light grey as
the default color and a double-stroked font (which was necessary on the
CGA display since it didn't have enough bandwidth to handle
single-stroked fonts well). The problem with changing that to white is
that you end up with a mismatch between the earlyprintk console and the
"real" console, *or* we change the behavior of everyone's consoles...
-hpa
--
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/
[RFC PATCH RESEND 1/2] clk: add clk accuracy retrieval support
The clock accuracy is expressed in ppb (parts per billion) and represents
the possible clock drift.
Say you have a clock (e.g. an oscillator) which provides a fixed clock of
20MHz with an accuracy of +- 20Hz. This accuracy expressed in ppb is
20Hz/20MHz = 1000 ppb (or 1 ppm).
Clock users may need the clock accuracy information in order to choose
the best clock (the one with the best accuracy) across several available
clocks.
This patch adds clk accuracy retrieval support for common clk framework by
means of a new function called clk_get_accuracy.
This function returns the given clock accuracy expressed in ppb.
In order to get the clock accuracy, this implementation adds one callback
called recalc_accuracy to the clk_ops structure.
This callback is given the parent clock accuracy (if the clock is not a
root clock) and should recalculate the given clock accuracy.
This callback is optional and may be implemented if the clock is not
a perfect clock (accuracy != 0 ppb).
Signed-off-by: Boris BREZILLON
---
Documentation/clk.txt|4 ++
drivers/clk/Kconfig |4 ++
drivers/clk/clk.c| 92 --
include/linux/clk-private.h |1 +
include/linux/clk-provider.h | 11 +
include/linux/clk.h | 17
6 files changed, 125 insertions(+), 4 deletions(-)
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 3aeb5c4..dc52da1 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -77,6 +77,8 @@ the operations defined in clk.h:
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long);
+ unsigned long (*recalc_accuracy)(struct clk_hw *hw,
+ unsigned long
parent_accuracy);
void(*init)(struct clk_hw *hw);
};
@@ -202,6 +204,8 @@ optional or must be evaluated on a case-by-case basis.
.set_parent | | | n | y | n|
.get_parent | | | n | y | n|
| | | | | |
+.recalc_rate| | | | | |
+| | | | | |
.init | | | | | |
---
[1] either one of round_rate or determine_rate is required.
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 279407a..4d12ae7 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -6,12 +6,16 @@ config CLKDEV_LOOKUP
config HAVE_CLK_PREPARE
bool
+config HAVE_CLK_GET_ACCURACY
+ bool
+
config HAVE_MACH_CLKDEV
bool
config COMMON_CLK
bool
select HAVE_CLK_PREPARE
+ select HAVE_CLK_GET_ACCURACY
select CLKDEV_LOOKUP
---help---
The common clock framework is a single definition of struct
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a004769..6a8f3ef 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -104,10 +104,11 @@ static void clk_summary_show_one(struct seq_file *s,
struct clk *c, int level)
if (!c)
return;
- seq_printf(s, "%*s%-*s %-11d %-12d %-10lu",
+ seq_printf(s, "%*s%-*s %-11d %-12d %-10lu %-11lu",
level * 3 + 1, "",
30 - level * 3, c->name,
- c->enable_count, c->prepare_count, clk_get_rate(c));
+ c->enable_count, c->prepare_count, clk_get_rate(c),
+ clk_get_accuracy(c));
seq_printf(s, "\n");
}
@@ -129,8 +130,8 @@ static int clk_summary_show(struct seq_file *s, void *data)
{
struct clk *c;
- seq_printf(s, " clockenable_cnt prepare_cnt
rate\n");
- seq_printf(s,
"-\n");
+ seq_printf(s, " clockenable_cnt prepare_cnt
rateaccuracy\n");
+ seq_printf(s,
"-\n");
clk_prepare_lock();
@@ -167,6 +168,7 @@ static void clk_dump_one(struct seq_file *s, struct clk *c,
int level)
seq_printf(s, "\"enable_count\": %d,", c->enable_count);
seq_printf(s, "\"prepare_count\": %d,", c->prepare_count);
seq_printf(s, "\"rate\": %lu", clk_get_rate(c));
+ seq_printf(s, "\"accuracy\": %lu", clk_get_accuracy(c));
}
static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
@@ -248,6 +250,11 @@ static int clk_debug_create_one(struct clk *clk, struct
dentry *pdentry)
if (!d)
goto
Re: NULL pointer dereference in autofs4_expire_wait
On 10/11/13 7:56 PM, Ian Kent wrote: So more history please, had you used 3.11 for an extended amount of time, before using the 3.12-rc? IOW what's your kernel version use history please? I think I did have a 3.11 installed, but was not doing a heavy nfs/autofs load. That started in the past week. David -- 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] firmware: wl1251 firmware binary
On Wed, 2013-10-02 at 07:55 -0500, Felipe Balbi wrote: > Hi, > > here's a pull request for wl4 firmware. I'll send a patch for wl1251 > driver updating firmware load path. > > The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db: > > linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 > 04:53:32 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git > wilink4 > > for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c: > > ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500) > > > Felipe Balbi (1): > ti-connectivity: add wl1251 firmware and license > > LICENCE.wl1251 | 59 > + > WHENCE | 18 + > ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes > ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes > 4 files changed, 77 insertions(+) > create mode 100644 LICENCE.wl1251 > create mode 100644 ti-connectivity/wl1251-fw.bin > create mode 100644 ti-connectivity/wl1251-nvs.bin Pulled, thanks. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Re: latencytop.org defunkt ?
On Sunday, October 13, 2013 07:51:50 AM Randy Dunlap wrote: > On 10/09/13 09:42, Daniel Walker wrote: > > Hi, > > > > Are you aware that http://www.latencytop.org/ is not functioning ? I was > > trying to get the update source code, but seem there is no place to do > > that. > > > Maybe Rafael would know? I have no idea. -- 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 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
On Sun, Oct 13, 2013 at 04:14:39AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 12, 2013 at 07:42:18PM +, Mathieu Desnoyers wrote:
> > - Original Message -
> > > On Sat, Oct 12, 2013 at 06:43:45PM +0200, Hannes Frederic Sowa wrote:
> > > > Regarding the volatile access, I hope that the C11 memory model
> > > > and enhancements to the compiler will some day provide a better
> > > > way to express the semantics of what is tried to express here
> > > > (__atomic_store_n/__atomic_load_n with the accompanied memory model,
> > > > which could be even weaker to what a volatile access would enfore
> > > > now and could guarantee atomic stores/loads).
> > >
> > > I just played around a bit more. Perhaps we could try to warn of silly
> > > usages of ACCESS_ONCE():
> > >
> > > --- a/include/linux/compiler.h
> > > +++ b/include/linux/compiler.h
> > > @@ -349,7 +349,11 @@ void ftrace_likely_update(struct ftrace_branch_data
> > > *f,
> > > int val, int expect);
> > > * use is to mediate communication between process-level code and irq/NMI
> > > * handlers, all running on the same CPU.
> > > */
> > > -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> > > +#define ACCESS_ONCE(x) (*({
> > > \
> > > + compiletime_assert(sizeof(typeof(x)) <= sizeof(typeof()), \
> > > +"ACCESS_ONCE likely not atomic");\
> >
> > AFAIU, ACCESS_ONCE() is not meant to ensure atomicity of load/store,
> > but rather merely ensures that the compiler will not merge nor refetch
> > accesses. I don't think the assert check you propose is appropriate with
> > respect to the ACCESS_ONCE() semantic.
>
> I am with Mathieu on this one, at least unless there is some set of actual
> bugs already in the kernel that these length checks would find.
I guess my wording of "ACCESS_ONCE likely not atomic" was misplaced. Something
like volatile access to memory larger than the processor register size is
probably not what you intended. Use atomics or proper locking. ;)
And maybe that is not even correct.
> /me wonders about structs of size 3, 5, 6, and 7...
Checked a x86_64 allyesconfig build with sizes above pointer size and odd
parity and nothing broke.
Greetings,
Hannes
--
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] cgroup: fix to break the while loop in cgroup_attach_task() correctly
On Sat, Oct 12, 2013 at 10:59:17AM +0800, Li Zefan wrote:
> From: Anjana V Kumar
>
> Both Anjana and Eunki reported a stall in the while_each_thread loop
> in cgroup_attach_task().
>
> It's because, when we attach a single thread to a cgroup, if the cgroup
> is exiting or is already in that cgroup, we won't break the loop.
>
> If the task is already in the cgroup, the bug can lead to another thread
> being attached to the cgroup unexpectedly:
>
> # echo 5207 > tasks
> # cat tasks
> 5207
> # echo 5207 > tasks
> # cat tasks
> 5207
> 5215
>
> What's worse, if the task to be attached isn't the leader of the thread
> group, we might never exit the loop, hence cpu stall. Thanks for Oleg's
> analysis.
>
> This bug was introduced by commit 081aa458c38ba576bdd4265fc807fa95b48b9e79
> ("cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()")
>
> Cc: # 3.9+
> Reported-by: Eunki Kim
> Reported-by: Anjana V Kumar
> Signed-off-by: Anjana V Kumar
> [ lizf: - fixed the first continue, pointed out by Oleg,
> - rewrote changelog. ]
> Signed-off-by: Li Zefan
Applied to cgroup/for-3.12-fixes.
Thanks.
--
tejun
--
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] net: stmmac: keep RXC running in LPI mode to avoid system overload
Hello Guiseppe, Thanks for your answer. Please find below some details and answers. > > In order to avoid system overload, the clock RXC from the Phy > > should not be > > stopped when in LPI mode. > > > > With the RTL8211E PHY which support EEE mode and with Apple Airport > > Extreme that > > supports it also, the kernel get frozen as soon as some Ethernet > > transfers are > > > hmm, I have a board with this transceiver so I could do some tests > this could take a while, unfortunately. > > > on-going. System seems to be overloaded with too many interrupts. > > The 'top' > > command reports often around ~80% irq. > > do you mean lpi mac interrupts? By disabling the LPI mode with ethtool --set-eee eth0 eee off, the interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue to put the RX path in LPI mode. Only way I found to get ride of the overload is to keep the RX_CLK running in LPI mode. In this configuration, the RX link still continue to go in LPI mode and the two above counters continue to run. > > > > By letting the RXC clock running even in LPI mode as proposed > > below, the issue > > seems solved. Is it the right way to proceed? > > For EEE capability, RX_CLK may be halted for this reason i used it as > default in the stmmac and never seen your issue. > > > > > What is the power impact to not stop RXC in LPI mode? > > I can point you to "22.2.2.8a Receive direction LPI transition" > in IEEE802-3az... where is it reported that the PHY halt the RX_CLK > in LPI mode. Actually the PHY "may" stop RX_CLK. > > May I suspect some issues on your HW? or disable it with ethtool > Yes, it could be HW issue. It would be very useful if you could reproduce the setup using a SoC with "DesignWare Cores Ethernet MAC" core, the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between the controller and the PHY. Which Ethernet switch or router did you use to test the EEE mode? I may try these equipments as well. Romain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] AHCI: disabled FBS prior to issuing software reset
Hello, On Sat, Oct 12, 2013 at 02:56:34PM +0800, xiangliang yu wrote: > > So it can't find the disk if FBS stays enabled? Can you please attach > > the boot log before & after? > > Below is boot log: And it works after the patch, right? Can you please update the patch description so that it includes what was failing before and how it was tested? Thanks. -- tejun -- 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 09/23] mm/init: Use memblock apis for early memory allocations
On Sat, Oct 12, 2013 at 05:58:52PM -0400, Santosh Shilimkar wrote: > Switch to memblock interfaces for early memory allocator When posting actual (non-RFC) patches later, please cc the maintainers of the target subsystem and briefly explain why the new interface is needed and that this doesn't change visible behavior. Thanks. -- tejun -- 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 08/23] mm/memblock: debug: don't free reserved array if !ARCH_DISCARD_MEMBLOCK
On Sat, Oct 12, 2013 at 05:58:51PM -0400, Santosh Shilimkar wrote: > From: Grygorii Strashko > > Now the Nobootmem allocator will always try to free memory allocated for > reserved memory regions (free_low_memory_core_early()) without taking > into to account current memblock debugging configuration > (CONFIG_ARCH_DISCARD_MEMBLOCK and CONFIG_DEBUG_FS state). > As result if: > - CONFIG_DEBUG_FS defined > - CONFIG_ARCH_DISCARD_MEMBLOCK not defined; > - reserved memory regions array have been resized during boot > > then: > - memory allocated for reserved memory regions array will be freed to > buddy allocator; > - debug_fs entry "sys/kernel/debug/memblock/reserved" will show garbage > instead of state of memory reservations. like: >0: 0x98393bc0..0x9a393bbf >1: 0xff12..0xff11 >2: 0x..0x > > Hence, do not free memory allocated for reserved memory regions if > defined(CONFIG_DEBUG_FS) && !defined(CONFIG_ARCH_DISCARD_MEMBLOCK). > > Cc: Yinghai Lu > Cc: Tejun Heo > Cc: Andrew Morton > > Signed-off-by: Grygorii Strashko > Signed-off-by: Santosh Shilimkar > --- > mm/memblock.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/mm/memblock.c b/mm/memblock.c > index d903138..1bb2cc0 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -169,6 +169,10 @@ phys_addr_t __init_memblock > get_allocated_memblock_reserved_regions_info( > if (memblock.reserved.regions == memblock_reserved_init_regions) > return 0; > Please add comment explaining why the following test exists. It's pretty difficult to deduce the reason only from the code. > + if (IS_ENABLED(CONFIG_DEBUG_FS) && > + !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)) > + return 0; > + Also, as this is another fix patch, can you please move this to the head of the series? Thanks. -- tejun -- 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] ipmi: remove deprecated IRQF_DISABLED
Thanks, it's in the queue.
-corey
On 10/12/2013 10:59 PM, Michael Opdenacker wrote:
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
> ---
> drivers/char/ipmi/ipmi_si_intf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 15e4a60..68c5ef5 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1358,7 +1358,7 @@ static int std_irq_setup(struct smi_info *info)
> if (info->si_type == SI_BT) {
> rv = request_irq(info->irq,
>si_bt_irq_handler,
> - IRQF_SHARED | IRQF_DISABLED,
> + IRQF_SHARED,
>DEVICE_NAME,
>info);
> if (!rv)
> @@ -1368,7 +1368,7 @@ static int std_irq_setup(struct smi_info *info)
> } else
> rv = request_irq(info->irq,
>si_irq_handler,
> - IRQF_SHARED | IRQF_DISABLED,
> + IRQF_SHARED,
>DEVICE_NAME,
>info);
> if (rv) {
--
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] staging/olpc_dcon: fix kconfig to fix build errors
From: Randy Dunlap Fix build errors when GPIO_CS5535=m and FB_OLPC_DCON=y by preventing that kconfig combination. These build errors are caused by having a kconfig bool symbol (FB_OLPC_DCON_1) that depend on a tristate symbol (GPIO_CS5535), but when the tristate symbol is =m, the bool symbol is =y. drivers/built-in.o: In function `dcon_read_status_xo_1': olpc_dcon_xo_1.c:(.text+0x359531): undefined reference to `cs5535_gpio_set' drivers/built-in.o: In function `dcon_wiggle_xo_1': olpc_dcon_xo_1.c:(.text+0x35959f): undefined reference to `cs5535_gpio_set' olpc_dcon_xo_1.c:(.text+0x359610): undefined reference to `cs5535_gpio_clear' drivers/built-in.o:olpc_dcon_xo_1.c:(.text+0x3596a1): more undefined references to `cs5535_gpio_clear' follow drivers/built-in.o: In function `dcon_wiggle_xo_1': olpc_dcon_xo_1.c:(.text+0x359708): undefined reference to `cs5535_gpio_set' drivers/built-in.o: In function `dcon_init_xo_1': olpc_dcon_xo_1.c:(.text+0x35989b): undefined reference to `cs5535_gpio_clear' olpc_dcon_xo_1.c:(.text+0x3598b5): undefined reference to `cs5535_gpio_isset' olpc_dcon_xo_1.c:(.text+0x359963): undefined reference to `cs5535_gpio_setup_event' olpc_dcon_xo_1.c:(.text+0x359980): undefined reference to `cs5535_gpio_set_irq' olpc_dcon_xo_1.c:(.text+0x359a36): undefined reference to `cs5535_gpio_set' However, adding GPIO_CS5535 to the Kconfig dependencies also creates a kconfig recursive dependency error on powerpc: drivers/i2c/Kconfig:5:error: recursive dependency detected! drivers/i2c/Kconfig:5:symbol I2C is selected by FB_OLPC_DCON drivers/staging/olpc_dcon/Kconfig:1: symbol FB_OLPC_DCON depends on GPIO_CS5535 drivers/gpio/Kconfig:577: symbol GPIO_CS5535 depends on GPIOLIB drivers/gpio/Kconfig:38: symbol GPIOLIB is selected by ARCH_REQUIRE_GPIOLIB drivers/gpio/Kconfig:23: symbol ARCH_REQUIRE_GPIOLIB is selected by MCU_MPC8349EMITX arch/powerpc/platforms/Kconfig:351: symbol MCU_MPC8349EMITX depends on I2C This is due to FB_OLPC_DCON selecting I2C instead of depending on it, so change the select to a dependency. Signed-off-by: Randy Dunlap Cc: Daniel Drake Cc: Jens Frederich Cc: Jon Nettleton --- drivers/staging/olpc_dcon/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- lnx-312-rc4.orig/drivers/staging/olpc_dcon/Kconfig +++ lnx-312-rc4/drivers/staging/olpc_dcon/Kconfig @@ -1,7 +1,8 @@ config FB_OLPC_DCON tristate "One Laptop Per Child Display CONtroller support" depends on OLPC && FB - select I2C + depends on I2C + depends on (GPIO_CS5535 || GPIO_CS5535=n) select BACKLIGHT_CLASS_DEVICE ---help--- In order to support very low power operation, the XO laptop uses a -- 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] i2c: i2c-core: fix coding style issues in i2c-core.c
On Mon, 2013-10-14 at 00:43 +0530, RAGHAVENDRA GANIGA wrote:
[]
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[]
> @@ -1737,9 +1735,10 @@ int i2c_transfer(struct i2c_adapter *adap, struct
> i2c_msg *msgs, int num)
> if (adap->algo->master_xfer) {
> #ifdef DEBUG
> for (ret = 0; ret < num; ret++) {
> - dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x, "
> - "len=%d%s\n", ret, (msgs[ret].flags & I2C_M_RD)
> - ? 'R' : 'W', msgs[ret].addr, msgs[ret].len,
> + dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x,
> len=%d%s\n",
> + ret,
> + ((msgs[ret].flags & I2C_M_RD) ? 'R' : 'W'),
> + msgs[ret].addr, msgs[ret].len,
> (msgs[ret].flags & I2C_M_RECV_LEN) ? "+" : "");
> }
You added an unnecessary set of parentheses here and
you made it different from the similar line below.
Neither test really needs any parenthesis and this
could be written as:
dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x,
len=%d%s\n",
ret,
msgs[ret].flags & I2C_M_RD ? 'R' : 'W',
msgs[ret].addr, msgs[ret].len,
msgs[ret].flags & I2C_M_RECV_LEN ? "+" : "";
> @@ -2118,7 +2120,7 @@ EXPORT_SYMBOL(i2c_smbus_read_byte);
> s32 i2c_smbus_write_byte(const struct i2c_client *client, u8 value)
> {
> return i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> - I2C_SMBUS_WRITE, value, I2C_SMBUS_BYTE, NULL);
> + I2C_SMBUS_WRITE, value, I2C_SMBUS_BYTE, NULL);
Not an improvement.
Yes, the deleted line should use tabs but
the alignment of the new line is not correct.
Please align the indentation to the open parenthesis
return i2c_smbus_xfer(client->adapter, client->addr, client->flags,
I2C_SMBUS_WRITE, value, I2C_SMBUS_BYTE, NULL);
Using maximal tabs at start of line, and up to 7 spaces
to align properly.
(using 3 tabs, 6 spaces)
--
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.12-rc4] cifs: ntstatus_to_dos_map[] is not terminated
Functions that walk the ntstatus_to_dos_map[] array could
run off the end. For example, ntstatus_to_dos() loops
while ntstatus_to_dos_map[].ntstatus is not 0. Granted,
this is mostly theoretical, but could be used as a DOS attack
if the error code in the SMB header is bogus.
Cc: Steve French
Signed-off-by: Tim Gardner
---
fs/cifs/netmisc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
index af847e1..651a527 100644
--- a/fs/cifs/netmisc.c
+++ b/fs/cifs/netmisc.c
@@ -780,7 +780,9 @@ static const struct {
ERRDOS, ERRnoaccess, 0xc290}, {
ERRDOS, ERRbadfunc, 0xc29c}, {
ERRDOS, ERRsymlink, NT_STATUS_STOPPED_ON_SYMLINK}, {
- ERRDOS, ERRinvlevel, 0x007c0001}, };
+ ERRDOS, ERRinvlevel, 0x007c0001}, {
+ 0, 0, 0 }
+};
/*
Print an error message from the status code
--
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 2/5] uprobes: Introduce __create_xol_area()
No functional changes, preparation.
Extract the code which actually allocates/installs the new area
into the new helper, __create_xol_area().
While at it remove the unnecessary "ret = ENOMEM" and "ret = 0"
in xol_add_vma(), they both have no effect.
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 49 --
1 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index db7a1dc..c09d417 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1096,17 +1096,15 @@ void uprobe_munmap(struct vm_area_struct *vma, unsigned
long start, unsigned lon
}
/* Slot allocation for XOL */
-static int xol_add_vma(struct xol_area *area)
+static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
{
- struct mm_struct *mm = current->mm;
int ret = -EALREADY;
down_write(>mmap_sem);
if (mm->uprobes_state.xol_area)
goto fail;
- ret = -ENOMEM;
- /* Try to map as high as possible, this is only a hint. */
+ /* Try to map as high as possible, this is only a hint. */
area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE,
0, 0);
if (area->vaddr & ~PAGE_MASK) {
ret = area->vaddr;
@@ -1120,28 +1118,17 @@ static int xol_add_vma(struct xol_area *area)
smp_wmb(); /* pairs with get_xol_area() */
mm->uprobes_state.xol_area = area;
- ret = 0;
fail:
up_write(>mmap_sem);
return ret;
}
-/*
- * get_xol_area - Allocate process's xol_area if necessary.
- * This area will be used for storing instructions for execution out of line.
- *
- * Returns the allocated area or NULL.
- */
-static struct xol_area *get_xol_area(void)
+static struct xol_area *__create_xol_area(void)
{
struct mm_struct *mm = current->mm;
- struct xol_area *area;
uprobe_opcode_t insn = UPROBE_SWBP_INSN;
-
- area = mm->uprobes_state.xol_area;
- if (area)
- goto ret;
+ struct xol_area *area;
area = kzalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
@@ -1155,13 +1142,13 @@ static struct xol_area *get_xol_area(void)
if (!area->page)
goto free_bitmap;
- /* allocate first slot of task's xol_area for the return probes */
+ init_waitqueue_head(>wq);
+ /* Reserve the 1st slot for get_trampoline_vaddr() */
set_bit(0, area->bitmap);
- copy_to_page(area->page, 0, , UPROBE_SWBP_INSN_SIZE);
atomic_set(>slot_count, 1);
- init_waitqueue_head(>wq);
+ copy_to_page(area->page, 0, , UPROBE_SWBP_INSN_SIZE);
- if (!xol_add_vma(area))
+ if (!xol_add_vma(mm, area))
return area;
__free_page(area->page);
@@ -1170,9 +1157,25 @@ static struct xol_area *get_xol_area(void)
free_area:
kfree(area);
out:
+ return NULL;
+}
+
+/*
+ * get_xol_area - Allocate process's xol_area if necessary.
+ * This area will be used for storing instructions for execution out of line.
+ *
+ * Returns the allocated area or NULL.
+ */
+static struct xol_area *get_xol_area(void)
+{
+ struct mm_struct *mm = current->mm;
+ struct xol_area *area;
+
+ if (!mm->uprobes_state.xol_area)
+ __create_xol_area();
+
area = mm->uprobes_state.xol_area;
- ret:
- smp_read_barrier_depends(); /* pairs with wmb in xol_add_vma() */
+ smp_read_barrier_depends(); /* pairs with wmb in xol_add_vma() */
return area;
}
--
1.5.5.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] uprobes: Change the callsite of uprobe_copy_process()
Preparation for the next patches.
Move the callsite of uprobe_copy_process() in copy_process() down
to the succesfull return. We do not care if copy_process() fails,
uprobe_free_utask() won't be called in this case so the wrong
->utask != NULL doesn't matter.
OTOH, with this change we know that copy_process() can't fail when
uprobe_copy_process() is called, the new task should either return
to user-mode or call do_exit(). This way uprobe_copy_process() can:
1. setup p->utask != NULL if necessary
2. setup uprobes_state.xol_area
3. use task_work_add(p)
Also, move the definition of uprobe_copy_process() down so that it
can see get_utask().
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 16
kernel/fork.c |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ad8e1bd..db7a1dc 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1345,14 +1345,6 @@ void uprobe_free_utask(struct task_struct *t)
}
/*
- * Called in context of a new clone/fork from copy_process.
- */
-void uprobe_copy_process(struct task_struct *t)
-{
- t->utask = NULL;
-}
-
-/*
* Allocate a uprobe_task object for the task if if necessary.
* Called when the thread hits a breakpoint.
*
@@ -1368,6 +1360,14 @@ static struct uprobe_task *get_utask(void)
}
/*
+ * Called in context of a new clone/fork from copy_process.
+ */
+void uprobe_copy_process(struct task_struct *t)
+{
+ t->utask = NULL;
+}
+
+/*
* Current area->vaddr notion assume the trampoline address is always
* equal area->vaddr.
*
diff --git a/kernel/fork.c b/kernel/fork.c
index 086fe73..d3603b8 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1373,7 +1373,6 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
INIT_LIST_HEAD(>pi_state_list);
p->pi_state_cache = NULL;
#endif
- uprobe_copy_process(p);
/*
* sigaltstack should be cleared when sharing the same VM
*/
@@ -1490,6 +1489,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
perf_event_fork(p);
trace_task_newtask(p, clone_flags);
+ uprobe_copy_process(p);
return p;
--
1.5.5.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] uprobes: Teach __create_xol_area() to accept the predefined vaddr
Currently xol_add_vma() uses get_unmapped_area() for area->vaddr,
but the next patches need to use the fixed address. So this patch
adds the new "vaddr" argument to __create_xol_area() which should
be used as area->vaddr if it is nonzero.
xol_add_vma() doesn't bother to verify that the predefined addr is
not used, insert_vm_struct() should fail if find_vma_links() detects
the overlap with the existing vma.
Also, __create_xol_area() doesn't need __GFP_ZERO to allocate area.
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c09d417..c836135 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1104,11 +1104,14 @@ static int xol_add_vma(struct mm_struct *mm, struct
xol_area *area)
if (mm->uprobes_state.xol_area)
goto fail;
+ if (!area->vaddr) {
/* Try to map as high as possible, this is only a hint. */
- area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE,
0, 0);
- if (area->vaddr & ~PAGE_MASK) {
- ret = area->vaddr;
- goto fail;
+ area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
+ PAGE_SIZE, 0, 0);
+ if (area->vaddr & ~PAGE_MASK) {
+ ret = area->vaddr;
+ goto fail;
+ }
}
ret = install_special_mapping(mm, area->vaddr, PAGE_SIZE,
@@ -1124,13 +1127,13 @@ static int xol_add_vma(struct mm_struct *mm, struct
xol_area *area)
return ret;
}
-static struct xol_area *__create_xol_area(void)
+static struct xol_area *__create_xol_area(unsigned long vaddr)
{
struct mm_struct *mm = current->mm;
uprobe_opcode_t insn = UPROBE_SWBP_INSN;
struct xol_area *area;
- area = kzalloc(sizeof(*area), GFP_KERNEL);
+ area = kmalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
goto out;
@@ -1142,6 +1145,7 @@ static struct xol_area *__create_xol_area(void)
if (!area->page)
goto free_bitmap;
+ area->vaddr = vaddr;
init_waitqueue_head(>wq);
/* Reserve the 1st slot for get_trampoline_vaddr() */
set_bit(0, area->bitmap);
@@ -1172,7 +1176,7 @@ static struct xol_area *get_xol_area(void)
struct xol_area *area;
if (!mm->uprobes_state.xol_area)
- __create_xol_area();
+ __create_xol_area(0);
area = mm->uprobes_state.xol_area;
smp_read_barrier_depends(); /* pairs with wmb in xol_add_vma() */
--
1.5.5.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] uprobes: Change uprobe_copy_process() to dup return_instances
uprobe_copy_process() assumes that the new child doesn't need
->utask, it should be allocated by demand.
But this is not true if the forking task has the pending ret-
probes, the child should report them as well and thus it needs
the copy of parent's ->return_instances chain. Otherwise the
child crashes when it returns from the probed function.
Note: this change alone doesn't fix the problem, see the next
change.
Cc: sta...@vger.kernel.org # 3.9+
Reported-by: Martin Cermak
Reported-by: David Smith
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c836135..67b65c8 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1366,12 +1366,55 @@ static struct uprobe_task *get_utask(void)
return current->utask;
}
+static int dup_utask(struct task_struct *t, struct uprobe_task *o_utask)
+{
+ struct uprobe_task *n_utask;
+ struct return_instance **p, *o, *n;
+
+ n_utask = kzalloc(sizeof(struct uprobe_task), GFP_KERNEL);
+ if (!n_utask)
+ return -ENOMEM;
+ t->utask = n_utask;
+
+ p = _utask->return_instances;
+ for (o = o_utask->return_instances; o; o = o->next) {
+ n = kmalloc(sizeof(struct return_instance), GFP_KERNEL);
+ if (!n)
+ return -ENOMEM;
+
+ *n = *o;
+ atomic_inc(>uprobe->ref);
+ n->next = NULL;
+
+ *p = n;
+ p = >next;
+ n_utask->depth++;
+ }
+
+ return 0;
+}
+
+static void uprobe_warn(struct task_struct *t, const char *msg)
+{
+ pr_warn("uprobe: %s:%d failed to %s\n",
+ current->comm, current->pid, msg);
+}
+
/*
* Called in context of a new clone/fork from copy_process.
*/
void uprobe_copy_process(struct task_struct *t)
{
+ struct uprobe_task *utask = current->utask;
+ struct mm_struct *mm = current->mm;
+
t->utask = NULL;
+
+ if (mm == t->mm || !utask || !utask->return_instances)
+ return;
+
+ if (dup_utask(t, utask))
+ return uprobe_warn(t, "dup ret instances");
}
/*
--
1.5.5.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] uprobes: fix fork() with the pending ret-probe(s)
Hello. Please review, this series fixes the serious bug reported by Martin and David and cc's stable. See the changelog in 5/5. Oleg. kernel/events/uprobes.c | 144 +++ kernel/fork.c |2 +- 2 files changed, 109 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] uprobes: Change uprobe_copy_process() to dup xol_area
This finally fixes the serious bug in uretprobes: a forked child
crashes if the parent called fork() with the pending ret probe.
Trivial test-case:
# perf probe -x /lib/libc.so.6 __fork%return
# perf record -e probe_libc:__fork perl -le 'fork || print "OK"'
(the child doesn't print "OK", it is killed by SIGSEGV)
If the child returns from the probed function it actually returns
to trampoline_vaddr, because it got the copy of parent's stack
mangled by prepare_uretprobe() when the parent entered this func.
It crashes because a) this address is not mapped and b) until the
previous change it doesn't have the proper->return_instances info.
This means that uprobe_copy_process() has to create xol_area which
has the trampoline slot, and its vaddr should be equal to parent's
xol_area->vaddr.
Unfortunately, uprobe_copy_process() can not simply do
__create_xol_area(child, xol_area->vaddr). This could actually work
but perf_event_mmap() doesn't expect the usage of foreign ->mm. So
we offload this to task_work_run(), and pass the argument via not
yet used utask->vaddr.
We know that this vaddr is fine for install_special_mapping(), the
necessary hole was recently "created" by dup_mmap() which skips the
parent's VM_DONTCOPY area, and nobody else could use the new mm.
Unfortunately, this also means that we can not handle the errors
properly, we obviously can not abort the already completed fork().
So we simply print the warning if GFP_KERNEL allocation (the only
possible reason) fails.
Cc: sta...@vger.kernel.org # 3.9+
Reported-by: Martin Cermak
Reported-by: David Smith
Signed-off-by: Oleg Nesterov
---
kernel/events/uprobes.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 67b65c8..0c5d9d4 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -35,6 +35,7 @@
#include /* notifier mechanism */
#include "../../mm/internal.h" /* munlock_vma_page */
#include
+#include
#include
@@ -1400,6 +1401,17 @@ static void uprobe_warn(struct task_struct *t, const
char *msg)
current->comm, current->pid, msg);
}
+static void dup_xol_work(struct callback_head *work)
+{
+ kfree(work);
+
+ if (current->flags & PF_EXITING)
+ return;
+
+ if (!__create_xol_area(current->utask->vaddr))
+ uprobe_warn(current, "dup xol area");
+}
+
/*
* Called in context of a new clone/fork from copy_process.
*/
@@ -1407,6 +1419,7 @@ void uprobe_copy_process(struct task_struct *t)
{
struct uprobe_task *utask = current->utask;
struct mm_struct *mm = current->mm;
+ struct callback_head *work;
t->utask = NULL;
@@ -1415,6 +1428,15 @@ void uprobe_copy_process(struct task_struct *t)
if (dup_utask(t, utask))
return uprobe_warn(t, "dup ret instances");
+
+ /* TODO: move it into the union in uprobe_task */
+ work = kmalloc(sizeof(*work), GFP_KERNEL);
+ if (!work)
+ return uprobe_warn(t, "dup xol area");
+
+ utask->vaddr = mm->uprobes_state.xol_area->vaddr;
+ init_task_work(work, dup_xol_work);
+ task_work_add(t, work, true);
}
/*
--
1.5.5.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/2] i2c: i2c-core: fix coding style issues in i2c-core.c
>From b21e6a52aa9c36e8c01173cff13bbfd2a380d0bd Mon Sep 17 00:00:00 2001
From: Raghavendra Ganiga
Date: Mon, 14 Oct 2013 00:29:08 +0530
Subject: [PATCH 2/2] i2c: i2c-core: fix coding style issues in i2c-core.c
This is a patch to the i2c-core.c file that fixes up warnings and
the code indent error reported by the checkpatch.pl tool
Signed-off-by: Raghavendra Chandra Ganiga
---
drivers/i2c/i2c-core.c | 48 +---
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b1197bb..66e38a9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -48,7 +48,7 @@
#include
#include
#include
-#include
+#include
#include "i2c-core.h"
@@ -687,8 +687,8 @@ i2c_new_device(struct i2c_adapter *adap, struct
i2c_board_info const *info)
return client;
out_err:
- dev_err(>dev, "Failed to register i2c client %s at 0x%02x "
- "(%d)\n", client->name, client->addr, status);
+ dev_err(>dev, "Failed to register i2c client %s at 0x%02x (%d)\n",
+client->name, client->addr, status);
out_err_silent:
kfree(client);
return NULL;
@@ -1158,8 +1158,7 @@ static int i2c_do_add_adapter(struct i2c_driver *driver,
if (driver->attach_adapter) {
dev_warn(>dev, "%s: attach_adapter method is
deprecated\n",
driver->driver.name);
- dev_warn(>dev, "Please use another way to instantiate "
-"your i2c_client\n");
+ dev_warn(>dev, "Please use another way to instantiate
your i2c_client\n");
/* We ignore the return code; if it fails, too bad */
driver->attach_adapter(adap);
}
@@ -1183,13 +1182,12 @@ static int i2c_register_adapter(struct i2c_adapter
*adap)
/* Sanity checks */
if (unlikely(adap->name[0] == '\0')) {
- pr_err("i2c-core: Attempt to register an adapter with "
- "no name!\n");
+ pr_err("i2c-core: Attempt to register an adapter with no
name!\n");
return -EINVAL;
}
if (unlikely(!adap->algo)) {
- pr_err("i2c-core: Attempt to register adapter '%s' with "
- "no algo!\n", adap->name);
+ pr_err("i2c-core: Attempt to register adapter '%s' with no
algo!\n",
+adap->name);
return -EINVAL;
}
@@ -1422,8 +1420,8 @@ void i2c_del_adapter(struct i2c_adapter *adap)
found = idr_find(_adapter_idr, adap->nr);
mutex_unlock(_lock);
if (found != adap) {
- pr_debug("i2c-core: attempting to delete unregistered "
-"adapter [%s]\n", adap->name);
+ pr_debug("i2c-core: attempting to delete unregistered adapter
[%s]\n",
+ adap->name);
return;
}
@@ -1737,9 +1735,10 @@ int i2c_transfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if (adap->algo->master_xfer) {
#ifdef DEBUG
for (ret = 0; ret < num; ret++) {
- dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x, "
- "len=%d%s\n", ret, (msgs[ret].flags & I2C_M_RD)
- ? 'R' : 'W', msgs[ret].addr, msgs[ret].len,
+ dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x,
len=%d%s\n",
+ ret,
+ ((msgs[ret].flags & I2C_M_RD) ? 'R' : 'W'),
+ msgs[ret].addr, msgs[ret].len,
(msgs[ret].flags & I2C_M_RECV_LEN) ? "+" : "");
}
#endif
@@ -1905,8 +1904,9 @@ static int i2c_detect_address(struct i2c_client
*temp_client,
/* Consistency check */
if (info.type[0] == '\0') {
- dev_err(>dev, "%s detection function provided "
- "no name for 0x%x\n", driver->driver.name,
+ dev_err(>dev,
+ "%s detection function provided no name for 0x%x\n",
+ driver->driver.name,
addr);
} else {
struct i2c_client *client;
@@ -1946,8 +1946,9 @@ static int i2c_detect(struct i2c_adapter *adapter, struct
i2c_driver *driver)
temp_client->adapter = adapter;
for (i = 0; address_list[i] != I2C_CLIENT_END; i += 1) {
- dev_dbg(>dev, "found normal entry for adapter %d, "
- "addr 0x%02x\n", adap_id, address_list[i]);
+ dev_dbg(>dev,
+ "found normal entry for adapter %d, addr 0x%02x\n",
+ adap_id, address_list[i]);
temp_client->addr = address_list[i];
err = i2c_detect_address(temp_client, driver);
if (unlikely(err))
@@ -1979,15 +1980,16 @@
Re: latencytop.org defunkt ?
somehow the domain no longer points to the right spot/etc my attempts to get that fixed have failed so far ;-( On Wed, Oct 9, 2013 at 9:42 AM, Daniel Walker wrote: > Hi, > > Are you aware that http://www.latencytop.org/ is not functioning ? I was > trying to get the update source code, but seem there is no place to do > that. > > Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] i2c: i2c-core: fix paranthesis coding style issue in i2c-core.c
>From 46aed97f5e5a434e8ec24c14e085a138958ba559 Mon Sep 17 00:00:00 2001 From: Raghavendra Ganiga Date: Sun, 13 Oct 2013 19:13:46 +0530 Subject: [PATCH 1/2] i2c: i2c-core: fix paranthesis coding style issue in i2c-core.c This is a patch to the i2c-core.c file that fixes the paranthesis warning found by the checkpatch.pl tool Signed-off-by: Raghavendra Chandra Ganiga --- drivers/i2c/i2c-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 29d3f04..b1197bb 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -637,7 +637,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info) struct i2c_client *client; int status; - client = kzalloc(sizeof *client, GFP_KERNEL); + client = kzalloc(sizeof(*client), GFP_KERNEL); if (!client) return NULL; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: INVESTMENT/ RELOCATION ASSISTANCE. 13th/10/2013
Dear Beloved, I am Mrs. Maryann Jamila Hussein a Teacher and a Muslim Convert here in Syria,i had sent a previous mail which i am not sure you got. I need your assistance to invest and help me relocate my 3 kids who are 17 years and below, so that they can get a better life there in your country due to the on going crises here in Syria. I need your trust, before the death of my husband we had a savings with an Indian Bank, so money is not the issue. I got your reference in my search for someone who suits my purpose.If you can help me reply, let me know. Regards, Mrs. Maryann Jamila Hussein. = -- 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 06/23] mm/memblock: Add memblock early memory allocation apis
On Sun, Oct 13, 2013 at 07:00:59PM +0100, Russell King - ARM Linux wrote: > On Sun, Oct 13, 2013 at 01:56:48PM -0400, Tejun Heo wrote: > > Hello, > > > > On Sat, Oct 12, 2013 at 05:58:49PM -0400, Santosh Shilimkar wrote: > > > Introduce memblock early memory allocation APIs which allow to support > > > LPAE extension on 32 bits archs. More over, this is the next step > > > > LPAE isn't something people outside arm circle would understand. > > Let's stick to highmem. > > LPAE != highmem. Two totally different things, unless you believe > system memory always starts at physical address zero, which is very > far from the case on the majority of ARM platforms. > > So replacing LPAE with "highmem" is pure misrepresentation and is > inaccurate. PAE might be a better term, and is also the x86 term > for this. Ah, right, forgot about the base address. Let's please spell out the requirements then. Briefly explaining both aspects (non-zero base addr & highmem) and why the existing bootmem based interfaced can't serve them would be helpful to later readers. Thanks. -- tejun -- 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 REQUEST] watchdog - v3.12-rc4 Fixes
On 10/13/2013 11:19 AM, Wim Van Sebroeck wrote: Hi Guenter, Looks like the diffs don't match the description. Are those possibly the diffs from your previous pull request ? From a 3.6 pull request to be precisely :-( I use the old mail as template and apparently forgot to change the diff... The correct diff here below. I use a template and script to generate my pull request e-mails to avoid this kind of problem. This way worst that can happen is an unexpected "rcX" in the headline ... unless the pull request itself is screwed up, which I should hopefully notice before I send it out. Guenter -- 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/
