Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
On Thu, Sep 06, 2012 at 09:46:50AM +0200, Paolo Bonzini wrote: > VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a > "negative" feature: it tells you that silent defalte is not supported. > Right now, QEMU refuses migration if the target does not support all the > features that were negotiated. But then: > > - a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed, > which is wrong; > > - a migration from MUST_TELL_HOST to non-MUST_TELL_HOST will fail, which > is useless. > > Add instead a new feature VIRTIO_BALLOON_F_SILENT_DEFLATE, and deprecate > VIRTIO_BALLOON_F_MUST_TELL_HOST since it is never actually used. > > Signed-off-by: Paolo Bonzini Frankly I think it's a qemu migration bug. I don't see why we need to tweak spec: just teach qemu to be smarter during migration. Can you show a scenario with old driver/new hypervisor or new driver/old hypervisor that fails? > --- > virtio-spec.lyx | 36 +--- > 1 file modificato, 33 inserzioni(+), 3 rimozioni(-) > > diff --git a/virtio-spec.lyx b/virtio-spec.lyx > index 7a073f4..1a25a18 100644 > --- a/virtio-spec.lyx > +++ b/virtio-spec.lyx > @@ -6238,6 +6238,8 @@ bits > > \begin_deeper > \begin_layout Description > + > +\change_deleted 1531152142 1346917221 > VIRTIO_BALLOON_F_MUST_TELL_HOST > \begin_inset space ~ > \end_inset > @@ -6251,6 +6253,20 @@ VIRTIO_BALLOON_F_STATS_VQ > \end_inset > > (1) A virtqueue for reporting guest memory statistics is present. > +\change_inserted 1531152142 1346917193 > + > +\end_layout > + > +\begin_layout Description > + > +\change_inserted 1531152142 1346917219 > +VIRTIO_BALLOON_F_SILENT_DEFLATE > +\begin_inset space ~ > +\end_inset > + > +(2) Host does not need to be told before pages from the balloon are used. > +\change_unchanged > + > \end_layout > > \end_deeper > @@ -6401,9 +6417,23 @@ The driver constructs an array of addresses of memory > pages it has previously > \end_layout > > \begin_layout Enumerate > -If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is set, the guest may not > - use these requested pages until that descriptor in the deflateq has been > - used by the device. > +If the VIRTIO_BALLOON_F_ > +\change_deleted 1531152142 1346917234 > +MUST_TELL_HOST > +\change_inserted 1531152142 1346917237 > +SILENT_DEFLATE > +\change_unchanged > + feature is > +\change_inserted 1531152142 1346917241 > +not > +\change_unchanged > +set, the guest may not use these requested pages until that descriptor in > + the deflateq has been used by the device. > + > +\change_inserted 1531152142 1346917253 > + If it is set, the guest may choose to not use the deflateq at all. > +\change_unchanged > + > \end_layout > > \begin_layout Enumerate > -- > 1.7.11.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 2/2] virtio-ring: Allocate indirect buffers from cache when possible
On Thu, Sep 06, 2012 at 05:27:23PM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" writes: > > Yes without checksum net core always linearizes packets, so yes it is > > screwed. > > For -net, skb always allocates space for 17 frags + linear part so > > it seems sane to do same in virtio core, and allocate, for -net, > > up to max_frags + 1 from cache. > > We can adjust it: no _SG -> 2 otherwise 18. > > But I thought it used individual buffers these days? Yes for receive, no for transmit. That's probably why we should have the threshold per vq, not per device, BTW. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, Sep 6, 2012 at 1:21 PM, NeilBrown wrote: > On Thu, 6 Sep 2012 12:57:46 +0530 "Shilimkar, Santosh" > wrote: > >> On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote: >> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh" >> > wrote: >> > >> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote: >> >> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh" >> >> > wrote: >> > >> >> >> After thinking bit more on this, the problem seems to be coming >> >> >> mainly because the gpio device is runtime suspended bit early than >> >> >> it should be. Similar issue seen with i2c driver as well. The i2c issue >> >> >> was discussed with Rafael at LPC last week. The idea is to move >> >> >> the pm_runtime_enable/disable() calls entirely up to the >> >> >> _late/_early stage of device suspend/resume. >> >> >> Will update this thread once I have further update. >> >> > >> >> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after >> >> > all >> >> > the _late callbacks have been called. >> >> > I, too, spoke to Rafael about this in San Diego. He seemed to agree >> >> > with me >> >> > that the interrupt needs to be masked in the ->suspend callback. any >> >> > later >> >> > is too late. >> >> > >> >> Thanks for information about your discussion. Will wait for the patch >> >> then. >> >> >> >> Regards >> >> santosh >> > >> > I already sent a patch - that is what started this thread :-) >> > >> > I include it below. >> > You said "The patch doesn't seems to be correct" but didn't expand on why. >> > Do you still think it is not correct? I wouldn't be surprised if there is >> > some case that it doesn't handle quite right, but it seems right to me. >> > >> Sorry I though you were talking about moving the "Checking wakeup interrupts" >> bit early as discussed on the follow up of alternate suggested patch to make >> use of IRQCHIP_MASK_ON_SUSPEND. >> >> I think we need to fix the issue seen with ' IRQCHIP_MASK_ON_SUSPEND' >> patch. That is at least the expected way to manage suspend and wakeup >> irq masks for a IRQCHIP. > > That is what I thought at first too. But when talking to Rafael he said that > IRQCHIP_MASK_ON_SUSPEND was intended mainly for clock interrupts. For other > less fundamental interrupts, doing the mask/unmask in suspend/resume > callbacks is sufficient and simpler... and actually works. > That is not the how I undetand IRQCHIP_MASK_ON_SUSPEND use. I thought it can be used for any IRQ chip for masking or setting wakeup on interrupts lines managed by that chip for suspend. May be I am wrong. > IRQCHIP_MASK_ON_SUSPEND is currently used by precisely two drivers: > >arch/arm/mach-omap2/omap-wakeupgen.c > and >drivers/mfd/pm8xxx-irq.c > > which suggests that it isn't widely used and quite possibly doesn't actually > work in general. I have seen lot more platforms use in downstream kernels. Also seen recently patches on the linux-arm list for couple of platforms. > > Maybe we need to start a new thread and pester Rafael or Thomas Gleixner > to either explain what is intended for this case, or to fix > IRQCHIP_MASK_ON_SUSPEND so that it can be used in general. > Sounds a good idea. Since you already had discussion with Rafael, probably you can describe the issue better. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-blk: Fix kconfig option
On Thu, Sep 06, 2012 at 12:41:13AM -0700, Kent Overstreet wrote: > On Tue, Sep 04, 2012 at 03:53:53PM +0930, Rusty Russell wrote: > > Kent Overstreet writes: > > > > > CONFIG_VIRTIO isn't exposed, everything else is supposed to select it > > > instead. > > > > This is a slight mis-understanding. It's supposed to be selected by > > the particular driver, probably virtio_pci in your case. > > So are you saying virtio-blk depends on virtio-pci? If so, the kconfig > should have that. > > As is, VIRTIO_BLK just has: > depends on EXPERIMENTAL && VIRTIO > > which is flat out broken. I don't think anything is broken. Can you show an example of a broken configuration? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/media/platform/s5p-tv/sdo_drv.c: fix error return code
From: Peter Senna Tschudin
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Peter Senna Tschudin
---
drivers/media/platform/s5p-tv/sdo_drv.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
b/drivers/media/platform/s5p-tv/sdo_drv.c
index ad68bbe..58cf56d 100644
--- a/drivers/media/platform/s5p-tv/sdo_drv.c
+++ b/drivers/media/platform/s5p-tv/sdo_drv.c
@@ -369,6 +369,7 @@ static int __devinit sdo_probe(struct platform_device *pdev)
sdev->fout_vpll = clk_get(dev, "fout_vpll");
if (IS_ERR_OR_NULL(sdev->fout_vpll)) {
dev_err(dev, "failed to get clock 'fout_vpll'\n");
+ ret = -ENXIO;
goto fail_dacphy;
}
dev_info(dev, "fout_vpll.rate = %lu\n", clk_get_rate(sclk_vpll));
@@ -377,11 +378,13 @@ static int __devinit sdo_probe(struct platform_device
*pdev)
sdev->vdac = devm_regulator_get(dev, "vdd33a_dac");
if (IS_ERR_OR_NULL(sdev->vdac)) {
dev_err(dev, "failed to get regulator 'vdac'\n");
+ ret = -ENXIO;
goto fail_fout_vpll;
}
sdev->vdet = devm_regulator_get(dev, "vdet");
if (IS_ERR_OR_NULL(sdev->vdet)) {
dev_err(dev, "failed to get regulator 'vdet'\n");
+ ret = -ENXIO;
goto fail_fout_vpll;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/31] arm64: User access library function
On Wed, Sep 05, 2012 at 10:05:34PM +0100, Russell King - ARM Linux wrote: > On Wed, Sep 05, 2012 at 10:01:37PM +0100, Catalin Marinas wrote: > > There are indeed a few KB gain in code size but that's probably coming > > from the exception table since otherwise you just replace a bl with > > ldrt. It depends on what the compiler does as well, the arm code has > > some carefully chosen registers when calling the __get_user_x function. > > It's more than that - it's not just the ldr but also a zeroing of a > temporary register to hold the error code should the instruction fault. > So it's not only the exception tables but also an increase in the > main path - and that's where you benefit from having it out of line and > thereby a hotter i-cache. On 32-bit we have __get_user() inline and get_user() out of line. What was the history behind this? > > If you do the access_ok inline and the __get_user_x separately, the size > > increase is even greater (at least in the arm64 case it can get to over > > 20KB). I think x86 does the access_ok check out of line. > > Please talk to Will about get_user() and put_user(). Afterwards you > will definitely want to keep them out of line on 64-bit ARM. As I said, I already made the change to always inline get_user/put_user with some penalty in the Image size but it makes the code cleaner. I'm not entirely convinced of the performance gain/loss especially on ARMv8 cores with physically tagged caches. There is room for optimisation when I get real silicon. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] unicore32: Add common clock support
> This commit adds support for the common clock framework to the Unicore32
> architecture.
>
> Signed-off-by: Thierry Reding
This patch can't work.
Could you disintegrate it into several small patches, so I could check it
out.
Thanks,
Guan Xuetao
> ---
> arch/unicore32/Kconfig | 1 +
> arch/unicore32/include/asm/clkdev.h | 26 ++
> arch/unicore32/kernel/clock.c | 560
>
> 3 files changed, 339 insertions(+), 248 deletions(-)
> create mode 100644 arch/unicore32/include/asm/clkdev.h
>
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index b0a4743..46b3a15 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -14,6 +14,7 @@ config UNICORE32
> select GENERIC_IRQ_SHOW
> select ARCH_WANT_FRAME_POINTERS
> select GENERIC_IOMAP
> + select COMMON_CLK
> help
> UniCore-32 is 32-bit Instruction Set Architecture,
> including a series of low-power-consumption RISC chip
> diff --git a/arch/unicore32/include/asm/clkdev.h
> b/arch/unicore32/include/asm/clkdev.h
> new file mode 100644
> index 000..201645d
> --- /dev/null
> +++ b/arch/unicore32/include/asm/clkdev.h
> @@ -0,0 +1,26 @@
> +/*
> + * based on arch/arm/include/asm/clkdev.h
> + *
> + * Copyright (C) 2008 Russell King.
> + *
> + * 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.
> + *
> + * Helper for the clk API to assist looking up a struct clk.
> + */
> +
> +#ifndef __ASM_CLKDEV_H
> +#define __ASM_CLKDEV_H
> +
> +#include
> +
> +#define __clk_get(clk) ({ 1; })
> +#define __clk_put(clk) do { } while (0)
> +
> +static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
> +{
> + return kzalloc(size, GFP_KERNEL);
> +}
> +
> +#endif
> diff --git a/arch/unicore32/kernel/clock.c b/arch/unicore32/kernel/clock.c
> index 18d4563..197f885 100644
> --- a/arch/unicore32/kernel/clock.c
> +++ b/arch/unicore32/kernel/clock.c
> @@ -17,223 +17,50 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> +#include
>
> #include
>
> -/*
> - * Very simple clock implementation
> - */
> -struct clk {
> - struct list_headnode;
> - unsigned long rate;
> - const char *name;
> -};
> -
> -static struct clk clk_ost_clk = {
> - .name = "OST_CLK",
> - .rate = CLOCK_TICK_RATE,
> -};
> -
> -static struct clk clk_mclk_clk = {
> - .name = "MAIN_CLK",
> -};
> -
> -static struct clk clk_bclk32_clk = {
> - .name = "BUS32_CLK",
> +struct clk_uc {
> + struct clk_hw hw;
> };
>
> -static struct clk clk_ddr_clk = {
> - .name = "DDR_CLK",
> -};
> -
> -static struct clk clk_vga_clk = {
> - .name = "VGA_CLK",
> -};
> -
> -static LIST_HEAD(clocks);
> -static DEFINE_MUTEX(clocks_mutex);
> -
> -struct clk *clk_get(struct device *dev, const char *id)
> -{
> - struct clk *p, *clk = ERR_PTR(-ENOENT);
> -
> - mutex_lock(_mutex);
> - list_for_each_entry(p, , node) {
> - if (strcmp(id, p->name) == 0) {
> - clk = p;
> - break;
> - }
> - }
> - mutex_unlock(_mutex);
> -
> - return clk;
> -}
> -EXPORT_SYMBOL(clk_get);
> -
> -void clk_put(struct clk *clk)
> -{
> -}
> -EXPORT_SYMBOL(clk_put);
> -
> -int clk_enable(struct clk *clk)
> -{
> - return 0;
> -}
> -EXPORT_SYMBOL(clk_enable);
> -
> -void clk_disable(struct clk *clk)
> +static inline struct clk_uc *to_clk_uc(struct clk_hw *hw)
> {
> + return container_of(hw, struct clk_uc, hw);
> }
> -EXPORT_SYMBOL(clk_disable);
> -
> -unsigned long clk_get_rate(struct clk *clk)
> -{
> - return clk->rate;
> -}
> -EXPORT_SYMBOL(clk_get_rate);
> -
> -struct {
> - unsigned long rate;
> - unsigned long cfg;
> - unsigned long div;
> -} vga_clk_table[] = {
> - {.rate = 25175000, .cfg = 0x2001, .div = 0x9},
> - {.rate = 3150, .cfg = 0x2001, .div = 0x7},
> - {.rate = 4000, .cfg = 0x3801, .div = 0x9},
> - {.rate = 4950, .cfg = 0x3801, .div = 0x7},
> - {.rate = 6500, .cfg = 0x2c01, .div = 0x4},
> - {.rate = 7875, .cfg = 0x2400, .div = 0x7},
> - {.rate = 10800, .cfg = 0x2c01, .div = 0x2},
> - {.rate = 10650, .cfg = 0x3c01, .div = 0x3},
> - {.rate = 5065, .cfg = 0x00106400, .div = 0x9},
> - {.rate = 6150, .cfg = 0x00106400, .div = 0xa},
> - {.rate = 8550, .cfg = 0x2800, .div = 0x6},
> -};
> -
> -struct {
> - unsigned long mrate;
> - unsigned long prate;
> -} mclk_clk_table[] = {
> - {.mrate = 5, .prate = 0x00109801},
> - {.mrate = 52500, .prate = 0x00104C00},
> - {.mrate = 55000, .prate = 0x00105000},
> - {.mrate = 57500,
Re: [RFC v9 PATCH 20/21] memory-hotplug: clear hwpoisoned flag when onlining pages
At 09/06/2012 03:27 PM, andywu106建国 Wrote:
> 2012/9/5
>>
>> From: Wen Congyang
>>
>> hwpoisoned may set when we offline a page by the sysfs interface
>> /sys/devices/system/memory/soft_offline_page or
>> /sys/devices/system/memory/hard_offline_page. If we don't clear
>> this flag when onlining pages, this page can't be freed, and will
>> not in free list. So we can't offline these pages again. So we
>> should clear this flag when onlining pages.
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Benjamin Herrenschmidt
>> CC: Paul Mackerras
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> CC: Yasuaki Ishimatsu
>> Signed-off-by: Wen Congyang
>> ---
>> mm/memory_hotplug.c |5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 270c249..140c080 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -661,6 +661,11 @@ EXPORT_SYMBOL_GPL(__online_page_increment_counters);
>>
>> void __online_page_free(struct page *page)
>> {
>> +#ifdef CONFIG_MEMORY_FAILURE
>> + /* The page may be marked HWPoisoned by soft/hard offline page */
>> + ClearPageHWPoison(page);
>
> Hi Congyang,
> I think you should decrease mce_bad_pages counter her
> atomic_long_sub(1, _bad_pages);
Yes, thanks for pointing it out.
Thanks
Wen Congyang
>
>>
>> +#endif
>> +
>> ClearPageReserved(page);
>> init_page_count(page);
>> __free_page(page);
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] unicore32: pwm: Properly remap memory-mapped registers
> Instead of writing to the timer controller registers by dereferencing a
> pointer to the memory location, properly remap the memory region with a
> call to ioremap_nocache() and access the registers using writel().
>
> Signed-off-by: Thierry Reding
> ---
> arch/unicore32/kernel/pwm.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/unicore32/kernel/pwm.c b/arch/unicore32/kernel/pwm.c
> index 4615d51..410b786 100644
> --- a/arch/unicore32/kernel/pwm.c
> +++ b/arch/unicore32/kernel/pwm.c
> @@ -23,10 +23,16 @@
> #include
> #include
>
> +#define PWCR 0x00
> +#define DCCR 0x04
> +#define PCR 0x08
I think old register names could be used here by some small modifications.
Please see arch/unicore32/include/mach/regs-ost.h
We can avoid ioremap and use writel/readl directly on these registers.
Guan
> +
> struct pwm_device {
> struct list_headnode;
> struct platform_device *pdev;
>
> + void __iomem*base;
> +
> const char *label;
> struct clk *clk;
> int clk_enabled;
> @@ -69,9 +75,11 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int
> period_ns)
>* before writing to the registers
>*/
> clk_enable(pwm->clk);
> - OST_PWMPWCR = prescale;
> - OST_PWMDCCR = pv - dc;
> - OST_PWMPCR = pv;
> +
> + writel(prescale, pwm->base + PWCR);
> + writel(pv - dc, pwm->base + DCCR);
> + writel(pv, pwm->base + PCR);
> +
> clk_disable(pwm->clk);
>
> return 0;
> @@ -190,10 +198,19 @@ static struct pwm_device *pwm_probe(struct
> platform_device *pdev,
> goto err_free_clk;
> }
>
> + pwm->base = ioremap_nocache(r->start, resource_size(r));
> + if (pwm->base == NULL) {
> + dev_err(>dev, "failed to remap memory resource\n");
> + ret = -EADDRNOTAVAIL;
> + goto err_release_mem;
> + }
> +
> __add_pwm(pwm);
> platform_set_drvdata(pdev, pwm);
> return pwm;
>
> +err_release_mem:
> + release_mem_region(r->start, resource_size(r));
> err_free_clk:
> clk_put(pwm->clk);
> err_free:
> @@ -224,6 +241,8 @@ static int __devexit pwm_remove(struct platform_device
> *pdev)
> list_del(>node);
> mutex_unlock(_lock);
>
> + iounmap(pwm->base);
> +
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(r->start, resource_size(r));
>
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Hi, 2012/9/6 Paul Menzel : > Dear Inki Dae, > > > Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > >> 2012/9/6 Mandeep Singh Baines : >> > The double invocations are incorrect but seem to be safe so I don't >> > think this will fix any bugs. >> > >> > Before: >> > >> > [7.639366] drm_prime_init_file ee3675d0 >> > [7.639377] drm_prime_init_file ee3675d0 >> > [7.639507] drm_prime_destroy_file ee3675d0 >> > [7.639518] drm_prime_destroy_file ee3675d0 >> > [7.639802] drm_prime_init_file ee372390 >> > [7.639810] drm_prime_init_file ee372390 >> > [8.473316] drm_prime_init_file ee356390 >> > [8.473331] drm_prime_init_file ee356390 >> > >> > After: >> > >> > [6.363842] drm_prime_init_file edc2e5d0 >> > [6.363994] drm_prime_destroy_file edc2e5d0 >> > [6.364260] drm_prime_init_file edc2e750 >> > [8.004837] drm_prime_init_file ee36ded0 >> > >> > Signed-off-by: Mandeep Singh Baines >> > CC: Stéphane Marchesin >> > CC: Pawel Osciak >> > CC: Inki Dae >> > CC: Joonyoung Shim >> > CC: Seung-Woo Kim >> > CC: Kyungmin Park >> > CC: David Airlie >> > CC: dri-de...@lists.freedesktop.org >> >> remove all CCs > > I guess they were generated by some script. So they should be fine, no? > > Mandeep, if you put CC in here those people should be CCed in real. `git > send-email` should take care of that but I do not see everyone in the CC > field. Or does `git send-email` use blind carbon copy (BCC) field? > >> and can you send it again using text mode? > > At least to the list it was send in plain text mode. > >> your patch is messed up when I try to get patch file. > > Everything is fine on my side. Especially since Mandeep used `git > send-email` which should do everything correctly. > your patch was encoded with 'Content-Transfer-Encoding: base64' so please use 7bit ascii like 'Content-Transfer-Encoding: 7bit' >> Thanks. >> Inki Dae > > In your From address your name is written InKi with capital K. Which one > is correct? > Inki is correct :) Thanks. Inki Dae > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: support MIGRATE_DISCARD
On Thu, Sep 06, 2012 at 02:31:12PM +0900, Minchan Kim wrote: > Hi Mel, > > On Wed, Sep 05, 2012 at 11:56:11AM +0100, Mel Gorman wrote: > > On Wed, Sep 05, 2012 at 05:11:13PM +0900, Minchan Kim wrote: > > > This patch introudes MIGRATE_DISCARD mode in migration. > > > It drops *clean cache pages* instead of migration so that > > > migration latency could be reduced by avoiding (memcpy + page remapping). > > > It's useful for CMA because latency of migration is very important rather > > > than eviction of background processes's workingset. In addition, it needs > > > less free pages for migration targets so it could avoid memory reclaiming > > > to get free pages, which is another factor increase latency. > > > > > > > Bah, this was released while I was reviewing the older version. I did > > not read this one as closely but I see the enum problems have gone away > > at least. I'd still prefer if CMA had an additional helper to discard > > some pages with shrink_page_list() and migrate the remaining pages with > > migrate_pages(). That would remove the need to add a MIGRATE_DISCARD > > migrate mode at all. > > I am not convinced with your point. What's the benefit on separating > reclaim and migration? For just removing MIGRATE_DISCARD mode? Maintainability. There are reclaim functions and there are migration functions. Your patch takes migrate_pages() and makes it partially a reclaim function mixing up the responsibilities of migrate.c and vmscan.c. > I don't think it's not bad because my implementation is very simple(maybe > it's much simpler than separating reclaim and migration) and > could be used by others like memory-hotplug in future. They could also have used the helper function from CMA that takes a list of pages, reclaims some and migrates other. > If you're not strong against with me, I would like to insist on my > implementation. > I'm not very strongly against it but I'm also very unhappy. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: snd-usb: "delay: estimated 0, actual 352"
At Thu, 06 Sep 2012 09:35:26 +0200,
Takashi Iwai wrote:
>
> At Thu, 6 Sep 2012 09:17:57 +0200,
> Markus Trippelsdorf wrote:
> >
> > On 2012.09.06 at 09:08 +0200, Daniel Mack wrote:
> > > On 06.09.2012 08:53, Markus Trippelsdorf wrote:
> > > > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote:
> > > >> At Thu, 06 Sep 2012 08:33:30 +0200,
> > > >> Daniel Mack wrote:
> > > >>>
> > > >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> > > >
> > > > Sound fixes for 3.6-rc5
> > > >
> > > > There are nothing scaring, contains only small fixes for HD-audio
> > > > and
> > > > USB-audio:
> > > > - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> > > > - A series of USB-audio regression fixes that are found since 3.5
> > > > kernel
> > > >
> > > >
> > > > Daniel Mack (4):
> > > > ALSA: snd-usb: Fix URB cancellation at stream start
> > > > ALSA: snd-usb: restore delay information
> > >
> > > The commit fbcfbf5f above causes the following lines to be printed
> > > whenever I start a new song:
> > > >>>
> > > >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
> > > >>> patch (fbcfbf5f) brings back now.
> > > >>>
> > > delay: estimated 0, actual 352
> > > delay: estimated 353, actual 705
> > >
> > > (44.1 * 8 = 352.8)
> > >
> > > This happens with an USB-DAC that identifies itself as "C-Media USB
> > > Headphone Set".
> > > >>>
> > > >>> And you didn't you see these lines with 3.4?
> > > >>
> > > >> Maybe the difference of start condition?
> > > >>
> > > >> Markus, does the patch below fix anything?
> > > >
> > > > Unfortunately no.
> > > > However reverting the following fixes the problem:
> > > >
> > > > commit 245baf983cc39524cce39c24d01b276e6e653c9e
> > > > Author: Daniel Mack
> > > > Date: Thu Aug 30 18:52:30 2012 +0200
> > > >
> > > > ALSA: snd-usb: fix calls to next_packet_size
> > > >
> > >
> > > No, this one certainly fixes a problem and does the right thing by
> > > restoring the original code.
> > >
> > > If you wouldn't state that you didn't see the same effect with 3.4(!),
> > > before the refactoring done in 3.5, I would believe the device is simply
> > > slightly off in its feedback rate and the tighter delay code complains
> > > about it while compensating, just as it did before.
> > >
> > > Are there any more than these two lines? And is audio working at all? Is
> > > it distorted in any way?
> >
> > There are only these two lines (printed whenever sound starts). Audio is
> > working just fine with no distortions.
> >
> > I did see similar lines before when the system load was very high
> > (happend during "make check" when building glibc).
> >
> > Here is what Pierre-Louis wrote in November 2011:
> >
> > »This was supposed to be an informational message, I thought it was only
> > enabled for debug. Regular users don't really need to know.«
>
> I guess the problem is that the new endpoint scheme doesn't count the
> last_delay update unless the stream is triggered. In the old code,
> retire_playback_urb is always called even before the trigger(START) is
> set. And, there retire_playback_urb() does nothing but updating the
> delay information.
>
> In the new code, retire_playback_urb is set only at
> snd_usb_substream_playback_trigger(). Thus at the very first shot,
> the delay account got confused.
In short, a patch like below may fix the issue (note: completely
untested!)
Takashi
---
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index fd5e982..928a4f7 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -528,6 +528,9 @@ static int snd_usb_hw_free(struct snd_pcm_substream
*substream)
return snd_pcm_lib_free_vmalloc_buffer(substream);
}
+static void retire_playback_urb(struct snd_usb_substream *subs,
+ struct urb *urb);
+
/*
* prepare callback
*
@@ -561,8 +564,10 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream
*substream)
/* for playback, submit the URBs now; otherwise, the first hwptr_done
* updates for all URBs would happen at the same time when starting */
- if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK)
+ if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ subs->data_endpoint->retire_data_urb = retire_playback_urb;
return start_endpoints(subs, 1);
+ }
return 0;
}
@@ -1190,7 +1195,6 @@ static int snd_usb_substream_playback_trigger(struct
snd_pcm_substream *substrea
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
subs->data_endpoint->prepare_data_urb = prepare_playback_urb;
-
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Thu, Sep 06, 2012 at 05:11:53PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> In file included from drivers/atm/fore200e.c:70:0:
> drivers/atm/fore200e.h:263:3: error: redefinition of typedef 'opcode_t' with
> different type
> arch/powerpc/include/asm/probes.h:25:13: note: previous declaration of
> 'opcode_t' was here
>
> Caused by commit 7118e7e648e0 ("powerpc: Consolidate {k,u}probe
> definitions") from the powerpc tree.
>
> I have reverted that commit (and the two following:
> 41ab5266c362 "powerpc: Add trap_nr to thread_struct"
> 8b7b80b9ebb4 "powerpc: Uprobes port to powerpc")
> for today.
Hi Stephen,
I have just posted a patch [1] to fix the issue.
Ananth
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/100813.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pwm i.MX: add devicetree support
On Wed, Sep 05, 2012 at 03:35:19PM +0200, Sascha Hauer wrote: > > Changes since v1: > > - Add devicetree binding documentation > - Merge 5/9 and 9/9 > - fix #pwm-cells (must be 2 instead of 3) > - fix wrong name in MODULE_DEVICE_TABLE > - drop platform based probing while introducing devicetree based probe > > > Philipp Zabel (2): > pwm i.MX: add devicetree support > pwm i.MX: fix clock lookup > > Sascha Hauer (6): > pwm i.MX: factor out SoC specific functions > pwm i.MX: remove unnecessary if in pwm_[en|dis]able > pwm i.MX: add functions to enable/disable pwm. > pwm i.MX: Use module_platform_driver > pwm i.MX: use per clock unconditionally > ARM i.MX53: Add pwm support > For the series, Reviewed-by: Shawn Guo > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 17 ++ > arch/arm/boot/dts/imx53.dtsi | 14 ++ > arch/arm/mach-imx/clk-imx51-imx53.c |4 + > drivers/pwm/pwm-imx.c | 275 > ++--- > 4 files changed, 214 insertions(+), 96 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.txt > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2] memory-hotplug: remove MIGRATE_ISOLATE from free_area->free_list
Hello Lai,
On Thu, Sep 06, 2012 at 04:14:51PM +0800, Lai Jiangshan wrote:
> On 09/06/2012 10:53 AM, Minchan Kim wrote:
> > Normally, MIGRATE_ISOLATE type is used for memory-hotplug.
> > But it's irony type because the pages isolated would exist
> > as free page in free_area->free_list[MIGRATE_ISOLATE] so people
> > can think of it as allocatable pages but it is *never* allocatable.
> > It ends up confusing NR_FREE_PAGES vmstat so it would be
> > totally not accurate so some of place which depend on such vmstat
> > could reach wrong decision by the context.
> >
> > There were already report about it.[1]
> > [1] 702d1a6e, memory-hotplug: fix kswapd looping forever problem
> >
> > Then, there was other report which is other problem.[2]
> > [2] http://www.spinics.net/lists/linux-mm/msg41251.html
> >
> > I believe it can make problems in future, too.
> > So I hope removing such irony type by another design.
> >
> > I hope this patch solves it and let's revert [1] and doesn't need [2].
> >
> > * Changelog v1
> > * Fix from Michal's many suggestion
> >
> > Cc: Michal Nazarewicz
> > Cc: Mel Gorman
> > Cc: Kamezawa Hiroyuki
> > Cc: Yasuaki Ishimatsu
> > Cc: Wen Congyang
> > Cc: Konrad Rzeszutek Wilk
> > Signed-off-by: Minchan Kim
> > ---
>
> > @@ -180,30 +287,35 @@ int undo_isolate_page_range(unsigned long start_pfn,
> > unsigned long end_pfn,
> > * all pages in [start_pfn...end_pfn) must be in the same zone.
> > * zone->lock must be held before call this.
> > *
> > - * Returns 1 if all pages in the range are isolated.
> > + * Returns true if all pages in the range are isolated.
> > */
> > -static int
> > -__test_page_isolated_in_pageblock(unsigned long pfn, unsigned long end_pfn)
> > +static bool
> > +__test_page_isolated_in_pageblock(unsigned long start_pfn, unsigned long
> > end_pfn)
> > {
> > + unsigned long pfn, next_pfn;
> > struct page *page;
> >
> > - while (pfn < end_pfn) {
> > - if (!pfn_valid_within(pfn)) {
> > - pfn++;
> > - continue;
> > - }
> > - page = pfn_to_page(pfn);
> > - if (PageBuddy(page))
> > - pfn += 1 << page_order(page);
> > - else if (page_count(page) == 0 &&
> > - page_private(page) == MIGRATE_ISOLATE)
> > - pfn += 1;
> > - else
> > - break;
> > + list_for_each_entry(page, _pages, lru) {
>
> > + if (>lru == _pages)
> > + return false;
>
> what's the mean of this line?
I just copied it from Michal's code but It seem to be not needed.
I will remove it in next spin.
>
> > + pfn = page_to_pfn(page);
> > + if (pfn >= end_pfn)
> > + return false;
> > + if (pfn >= start_pfn)
> > + goto found;
> > + }
> > + return false;
> > +
> > + list_for_each_entry_continue(page, _pages, lru) {
> > + if (page_to_pfn(page) != next_pfn)
> > + return false;
>
> where is next_pfn init-ed?
by "goto found"
>
> > +found:
> > + pfn = page_to_pfn(page);
> > + next_pfn = pfn + (1UL << page_order(page));
> > + if (next_pfn >= end_pfn)
> > + return true;
> > }
> > - if (pfn < end_pfn)
> > - return 0;
> > - return 1;
> > + return false;
> > }
> >
> > int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
> > @@ -211,7 +323,7 @@ int test_pages_isolated(unsigned long start_pfn,
> > unsigned long end_pfn)
> > unsigned long pfn, flags;
> > struct page *page;
> > struct zone *zone;
> > - int ret;
> > + bool ret;
> >
> > /*
> > * Note: pageblock_nr_page != MAX_ORDER. Then, chunks of free page
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index df7a674..bb59ff7 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -616,7 +616,6 @@ static char * const migratetype_names[MIGRATE_TYPES] = {
> > #ifdef CONFIG_CMA
> > "CMA",
> > #endif
> > - "Isolate",
> > };
> >
> > static void *frag_start(struct seq_file *m, loff_t *pos)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2] memory-hotplug: remove MIGRATE_ISOLATE from free_area->free_list
On 09/06/2012 10:53 AM, Minchan Kim wrote:
> Normally, MIGRATE_ISOLATE type is used for memory-hotplug.
> But it's irony type because the pages isolated would exist
> as free page in free_area->free_list[MIGRATE_ISOLATE] so people
> can think of it as allocatable pages but it is *never* allocatable.
> It ends up confusing NR_FREE_PAGES vmstat so it would be
> totally not accurate so some of place which depend on such vmstat
> could reach wrong decision by the context.
>
> There were already report about it.[1]
> [1] 702d1a6e, memory-hotplug: fix kswapd looping forever problem
>
> Then, there was other report which is other problem.[2]
> [2] http://www.spinics.net/lists/linux-mm/msg41251.html
>
> I believe it can make problems in future, too.
> So I hope removing such irony type by another design.
>
> I hope this patch solves it and let's revert [1] and doesn't need [2].
>
> * Changelog v1
> * Fix from Michal's many suggestion
>
> Cc: Michal Nazarewicz
> Cc: Mel Gorman
> Cc: Kamezawa Hiroyuki
> Cc: Yasuaki Ishimatsu
> Cc: Wen Congyang
> Cc: Konrad Rzeszutek Wilk
> Signed-off-by: Minchan Kim
> ---
> @@ -180,30 +287,35 @@ int undo_isolate_page_range(unsigned long start_pfn,
> unsigned long end_pfn,
> * all pages in [start_pfn...end_pfn) must be in the same zone.
> * zone->lock must be held before call this.
> *
> - * Returns 1 if all pages in the range are isolated.
> + * Returns true if all pages in the range are isolated.
> */
> -static int
> -__test_page_isolated_in_pageblock(unsigned long pfn, unsigned long end_pfn)
> +static bool
> +__test_page_isolated_in_pageblock(unsigned long start_pfn, unsigned long
> end_pfn)
> {
> + unsigned long pfn, next_pfn;
> struct page *page;
>
> - while (pfn < end_pfn) {
> - if (!pfn_valid_within(pfn)) {
> - pfn++;
> - continue;
> - }
> - page = pfn_to_page(pfn);
> - if (PageBuddy(page))
> - pfn += 1 << page_order(page);
> - else if (page_count(page) == 0 &&
> - page_private(page) == MIGRATE_ISOLATE)
> - pfn += 1;
> - else
> - break;
> + list_for_each_entry(page, _pages, lru) {
> + if (>lru == _pages)
> + return false;
what's the mean of this line?
> + pfn = page_to_pfn(page);
> + if (pfn >= end_pfn)
> + return false;
> + if (pfn >= start_pfn)
> + goto found;
> + }
> + return false;
> +
> + list_for_each_entry_continue(page, _pages, lru) {
> + if (page_to_pfn(page) != next_pfn)
> + return false;
where is next_pfn init-ed?
> +found:
> + pfn = page_to_pfn(page);
> + next_pfn = pfn + (1UL << page_order(page));
> + if (next_pfn >= end_pfn)
> + return true;
> }
> - if (pfn < end_pfn)
> - return 0;
> - return 1;
> + return false;
> }
>
> int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
> @@ -211,7 +323,7 @@ int test_pages_isolated(unsigned long start_pfn, unsigned
> long end_pfn)
> unsigned long pfn, flags;
> struct page *page;
> struct zone *zone;
> - int ret;
> + bool ret;
>
> /*
>* Note: pageblock_nr_page != MAX_ORDER. Then, chunks of free page
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index df7a674..bb59ff7 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -616,7 +616,6 @@ static char * const migratetype_names[MIGRATE_TYPES] = {
> #ifdef CONFIG_CMA
> "CMA",
> #endif
> - "Isolate",
> };
>
> static void *frag_start(struct seq_file *m, loff_t *pos)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: VMX: invalidate vpid for invlpg instruction
On 09/06/2012 12:54 AM, Davidlohr Bueso wrote: > On Mon, 2012-09-03 at 12:11 +0300, Avi Kivity wrote: >> On 09/03/2012 02:27 AM, Davidlohr Bueso wrote: >> > On Fri, 2012-08-31 at 14:37 -0300, Marcelo Tosatti wrote: >> >> On Fri, Aug 31, 2012 at 06:10:48PM +0200, Davidlohr Bueso wrote: >> >> > For processors that support VPIDs we should invalidate the page table >> >> > entry >> >> > specified by the lineal address. For this purpose add support for >> >> > individual >> >> > address invalidations. >> >> >> >> Not necessary - a single context invalidation is performed through >> >> KVM_REQ_TLB_FLUSH. >> > >> > Since vpid_sync_context() supports both single and all-context vpid >> > invalidations, wouldn't it make sense to also add individual address >> > ones as well, supporting further granularity? >> >> It might. Do you have benchmarks supporting this? >> > > I ran two benchmarks: Java Dacapo[1] Sunflow (renders a set of images > using ray tracing) and a vanilla 3.2 kernel build (with 1 job and -j8). > > The host configuration is an Intel i7-2635QM (4 cores + HT) with 4Gb RAM > running Linus's latest and only running standard system daemons. For KVM > I disabled EPT. That's not very interesting. In all real machines, if you have VPID you also have EPT. Intel are unlikely to produce a processor without EPT. > The guest configuration is a 64bit 4 core 4Gb RAM, running Linux 3.2 > (debian) and only running the benchmark. > > All results represent the mean of 5 runs, with time(1). The results are impressive, but lack real-world relevance. Individual-address invalidation isn't very useful with EPT, since we let the guest issue INVLPG itself and otherwise don't bother with guest page tables. Individual-address INVEPT would probably be more useful, but there is no such instruction variant. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/2] virtio-ring: Allocate indirect buffers from cache when possible
"Michael S. Tsirkin" writes: > Yes without checksum net core always linearizes packets, so yes it is > screwed. > For -net, skb always allocates space for 17 frags + linear part so > it seems sane to do same in virtio core, and allocate, for -net, > up to max_frags + 1 from cache. > We can adjust it: no _SG -> 2 otherwise 18. But I thought it used individual buffers these days? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: signature infrastructure
Lucas De Marchi writes:
> Sorry to come up with this suggestion only now (and after you have
> already talked to me at LPC). Only after seeing this implementation I
> thought about the implications of having the module signed in this
> format.
...
> I'm worried about performance here. Module loading can take a fair
> amount of boot time. It may not be critical for servers or desktops
> that we rarely boot, but it is for embedded uses.
...
> Letting it in be32 is the simplest solution IMO. it's way simpler then
> the loop above.
...
>> Scanning the module is the least of our issues since we've just copied
>> it and we're about to SHA it.
>
> Yeah, but I don't think we need to scan it one more time. On every
> boot. For every module
Regretfully, I don't have Linus' talent for flamage.
There's no measurable performance impact. Scanning 1k takes about
5usec; we've wasted about enough time on this subject to load a billion
kernel modules.
I know this. Not because I'm brilliant, but because I *measured* it. I
even pulled out my original module signature signing check code, and
that was both faster and simpler. See below.
Your assertion that the length-prepended version is "way simpler" is
wrong. Again, I know this because I *read the code*:
https://git.kernel.org/?p=linux/kernel/git/kasatkin/linux-digsig.git;a=commitdiff;h=19eef6e4e529ccf2b3a6ab5c19dd40f2eaf8fcaf
Don't send any more lazy, unthoughtful mails to the list. It's
disrespectful and makes me grumpy.
Rusty.
PS. Pushed updated version to my kernel.org linux.git/module-signing branch.
#ifdef CONFIG_MODULE_SIG
static int module_sig_check(struct load_info *info,
const void *mod, unsigned long *len)
{
int err = 0;
const unsigned long markerlen = strlen(MODULE_SIG_STRING);
const void *p = mod, *end = mod + *len;
/* Poor man's memmem. */
while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
if (p + markerlen > end)
break;
if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
const void *sig = p + markerlen;
/* Truncate module up to signature. */
*len = p - mod;
err = mod_verify_sig(mod, *len,
sig, end - sig,
>sig_ok);
break;
}
p++;
}
/* Not having a signature is only an error if we're strict. */
if (!err && !info->sig_ok && sig_enforce)
err = -EKEYREJECTED;
return err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote: > I see your point, however for now I can see no better way of referencing > the data (of type struct snd_soc_card) then passing it to > snd_soc_register_card(). But for this to work, I would have to register > successfully an ams-delta specific platform device first, not the soc- > audio. This, even if still done from the sound/soc/omap/ams-delta.c, not > from an arch board file, would require now not existing ams-delta ASoC > platform driver probe/remove callbacks at least. I'm still not convinced > if such modification would be acceptable in the middle of the rc cycle. > If there is a simpler, less intrusive way to do this, then sorry, I > still can't see it. Like I already said just make it a static variable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, 6 Sep 2012 12:57:46 +0530 "Shilimkar, Santosh" wrote: > On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote: > > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh" > > wrote: > > > >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote: > >> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh" > >> > wrote: > > > >> >> After thinking bit more on this, the problem seems to be coming > >> >> mainly because the gpio device is runtime suspended bit early than > >> >> it should be. Similar issue seen with i2c driver as well. The i2c issue > >> >> was discussed with Rafael at LPC last week. The idea is to move > >> >> the pm_runtime_enable/disable() calls entirely up to the > >> >> _late/_early stage of device suspend/resume. > >> >> Will update this thread once I have further update. > >> > > >> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after > >> > all > >> > the _late callbacks have been called. > >> > I, too, spoke to Rafael about this in San Diego. He seemed to agree > >> > with me > >> > that the interrupt needs to be masked in the ->suspend callback. any > >> > later > >> > is too late. > >> > > >> Thanks for information about your discussion. Will wait for the patch then. > >> > >> Regards > >> santosh > > > > I already sent a patch - that is what started this thread :-) > > > > I include it below. > > You said "The patch doesn't seems to be correct" but didn't expand on why. > > Do you still think it is not correct? I wouldn't be surprised if there is > > some case that it doesn't handle quite right, but it seems right to me. > > > Sorry I though you were talking about moving the "Checking wakeup interrupts" > bit early as discussed on the follow up of alternate suggested patch to make > use of IRQCHIP_MASK_ON_SUSPEND. > > I think we need to fix the issue seen with ' IRQCHIP_MASK_ON_SUSPEND' > patch. That is at least the expected way to manage suspend and wakeup > irq masks for a IRQCHIP. That is what I thought at first too. But when talking to Rafael he said that IRQCHIP_MASK_ON_SUSPEND was intended mainly for clock interrupts. For other less fundamental interrupts, doing the mask/unmask in suspend/resume callbacks is sufficient and simpler... and actually works. IRQCHIP_MASK_ON_SUSPEND is currently used by precisely two drivers: arch/arm/mach-omap2/omap-wakeupgen.c and drivers/mfd/pm8xxx-irq.c which suggests that it isn't widely used and quite possibly doesn't actually work in general. The pm8xxx-irq doesn't seem to do runtime pm, so maybe it manages to work for that reason. The omap-wakeupgen code is beyond my current understanding, but it seems like it might be the sort of special case that IRQCHIP_MASK_ON_SUSPEND is intended for... Maybe we need to start a new thread and pester Rafael or Thomas Gleixner to either explain what is intended for this case, or to fix IRQCHIP_MASK_ON_SUSPEND so that it can be used in general. NeilBrown signature.asc Description: PGP signature
Re: [PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Dear Inki Dae, Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > 2012/9/6 Mandeep Singh Baines : > > The double invocations are incorrect but seem to be safe so I don't > > think this will fix any bugs. > > > > Before: > > > > [7.639366] drm_prime_init_file ee3675d0 > > [7.639377] drm_prime_init_file ee3675d0 > > [7.639507] drm_prime_destroy_file ee3675d0 > > [7.639518] drm_prime_destroy_file ee3675d0 > > [7.639802] drm_prime_init_file ee372390 > > [7.639810] drm_prime_init_file ee372390 > > [8.473316] drm_prime_init_file ee356390 > > [8.473331] drm_prime_init_file ee356390 > > > > After: > > > > [6.363842] drm_prime_init_file edc2e5d0 > > [6.363994] drm_prime_destroy_file edc2e5d0 > > [6.364260] drm_prime_init_file edc2e750 > > [8.004837] drm_prime_init_file ee36ded0 > > > > Signed-off-by: Mandeep Singh Baines > > CC: Stéphane Marchesin > > CC: Pawel Osciak > > CC: Inki Dae > > CC: Joonyoung Shim > > CC: Seung-Woo Kim > > CC: Kyungmin Park > > CC: David Airlie > > CC: dri-de...@lists.freedesktop.org > > remove all CCs I guess they were generated by some script. So they should be fine, no? Mandeep, if you put CC in here those people should be CCed in real. `git send-email` should take care of that but I do not see everyone in the CC field. Or does `git send-email` use blind carbon copy (BCC) field? > and can you send it again using text mode? At least to the list it was send in plain text mode. > your patch is messed up when I try to get patch file. Everything is fine on my side. Especially since Mandeep used `git send-email` which should do everything correctly. > Thanks. > Inki Dae In your From address your name is written InKi with capital K. Which one is correct? Thanks, Paul signature.asc Description: This is a digitally signed message part
[PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a "negative" feature: it tells you that silent defalte is not supported. Right now, QEMU refuses migration if the target does not support all the features that were negotiated. But then: - a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed, which is wrong; - a migration from MUST_TELL_HOST to non-MUST_TELL_HOST will fail, which is useless. Add instead a new feature VIRTIO_BALLOON_F_SILENT_DEFLATE, and deprecate VIRTIO_BALLOON_F_MUST_TELL_HOST since it is never actually used. Signed-off-by: Paolo Bonzini --- virtio-spec.lyx | 36 +--- 1 file modificato, 33 inserzioni(+), 3 rimozioni(-) diff --git a/virtio-spec.lyx b/virtio-spec.lyx index 7a073f4..1a25a18 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -6238,6 +6238,8 @@ bits \begin_deeper \begin_layout Description + +\change_deleted 1531152142 1346917221 VIRTIO_BALLOON_F_MUST_TELL_HOST \begin_inset space ~ \end_inset @@ -6251,6 +6253,20 @@ VIRTIO_BALLOON_F_STATS_VQ \end_inset (1) A virtqueue for reporting guest memory statistics is present. +\change_inserted 1531152142 1346917193 + +\end_layout + +\begin_layout Description + +\change_inserted 1531152142 1346917219 +VIRTIO_BALLOON_F_SILENT_DEFLATE +\begin_inset space ~ +\end_inset + +(2) Host does not need to be told before pages from the balloon are used. +\change_unchanged + \end_layout \end_deeper @@ -6401,9 +6417,23 @@ The driver constructs an array of addresses of memory pages it has previously \end_layout \begin_layout Enumerate -If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is set, the guest may not - use these requested pages until that descriptor in the deflateq has been - used by the device. +If the VIRTIO_BALLOON_F_ +\change_deleted 1531152142 1346917234 +MUST_TELL_HOST +\change_inserted 1531152142 1346917237 +SILENT_DEFLATE +\change_unchanged + feature is +\change_inserted 1531152142 1346917241 +not +\change_unchanged +set, the guest may not use these requested pages until that descriptor in + the deflateq has been used by the device. + +\change_inserted 1531152142 1346917253 + If it is set, the guest may choose to not use the deflateq at all. +\change_unchanged + \end_layout \begin_layout Enumerate -- 1.7.11.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] virtio-blk: Fix kconfig option
On Tue, Sep 04, 2012 at 03:53:53PM +0930, Rusty Russell wrote: > Kent Overstreet writes: > > > CONFIG_VIRTIO isn't exposed, everything else is supposed to select it > > instead. > > This is a slight mis-understanding. It's supposed to be selected by > the particular driver, probably virtio_pci in your case. So are you saying virtio-blk depends on virtio-pci? If so, the kconfig should have that. As is, VIRTIO_BLK just has: depends on EXPERIMENTAL && VIRTIO which is flat out broken. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio-ich: Add missing spinlock init
As reported by CONFIG_DEBUG_SPINLOCK=y. Signed-off-by: Jean Delvare Cc: Peter Tyser Cc: Grant Likely Cc: Linus Walleij Cc: sta...@vger.kernel.org [v3.5+] --- drivers/gpio/gpio-ich.c |1 + 1 file changed, 1 insertion(+) --- linux-3.6-rc4.orig/drivers/gpio/gpio-ich.c 2012-09-04 13:34:03.0 +0200 +++ linux-3.6-rc4/drivers/gpio/gpio-ich.c 2012-09-06 08:08:57.571210424 +0200 @@ -390,6 +390,7 @@ static int __devinit ichx_gpio_probe(str return -ENODEV; } + spin_lock_init(_priv.lock); res_base = platform_get_resource(pdev, IORESOURCE_IO, ICH_RES_GPIO); ichx_priv.use_gpio = ich_info->use_gpio; err = ichx_gpio_request_regions(res_base, pdev->name, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 0/1]drm_irq: Introducing the irq_thread support
On Thu, Sep 06, 2012 at 12:42:05AM +, Liu, Chuansheng wrote:
> > This possibly ought to be submitted in parallel with the code that uses it
> > so that
> > the whole proposal can be evaluated as one thing ?
> >
> > Alan
>
> Patch is here, thanks.
>
> From: liu chuansheng
> Subject: [PATCH] drm_irq: Introducing the irq_thread support
>
> For some GPUs, the irq handler need >1ms to handle the irq action.
> And it will delay the whole system irq handler.
>
> This patch is adding the irq thread support, it will make the drm_irq
> interface more flexible.
>
> The changes include:
> 1/ Change the request_irq to request_thread_irq, and add new callback
>irq_handler_t;
> 2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
>this option in drm_irq;
>
> Cc: Shi Yang
> Signed-off-by: liu chuansheng
Nacked-by: Daniel Vetter
I _really_ hate when we add random special cases for random strange
drivers to core code - the usual end result is that in a few years we'll
have a maze of special-cases only used by one driver each. And nope,
cleaning that up isn't _that_ much fun ...
So just do all this in your own driver's code (and maybe set
dev->irq_enabled ourselve so that wait_vblank still works).
Yours, Daniel
> ---
> drivers/gpu/drm/drm_irq.c |8 ++--
> include/drm/drmP.h|2 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 03f16f3..bc105fe 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
> sh_flags = IRQF_SHARED;
>
> + if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
> + sh_flags |= IRQF_ONESHOT;
> +
> if (dev->devname)
> irqname = dev->devname;
> else
> irqname = dev->driver->name;
>
> - ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
> - sh_flags, irqname, dev);
> + ret = request_threaded_irq(drm_dev_to_irq(dev),
> + dev->driver->irq_handler, dev->driver->irq_handler_t,
> + sh_flags, irqname, dev);
>
> if (ret < 0) {
> mutex_lock(>struct_mutex);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index d6b67bb..b28be4b 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
> #define DRIVER_GEM 0x1000
> #define DRIVER_MODESET 0x2000
> #define DRIVER_PRIME 0x4000
> +#define DRIVER_IRQ_ONESHOT 0x8000
>
> #define DRIVER_BUS_PCI 0x1
> #define DRIVER_BUS_PLATFORM 0x2
> @@ -872,6 +873,7 @@ struct drm_driver {
> /* these have to be filled in */
>
> irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
> + irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
> void (*irq_preinstall) (struct drm_device *dev);
> int (*irq_postinstall) (struct drm_device *dev);
> void (*irq_uninstall) (struct drm_device *dev);
> --
> 1.7.0.4
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: snd-usb: "delay: estimated 0, actual 352"
At Thu, 6 Sep 2012 09:17:57 +0200, Markus Trippelsdorf wrote: > > On 2012.09.06 at 09:08 +0200, Daniel Mack wrote: > > On 06.09.2012 08:53, Markus Trippelsdorf wrote: > > > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: > > >> At Thu, 06 Sep 2012 08:33:30 +0200, > > >> Daniel Mack wrote: > > >>> > > >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > > > > > Sound fixes for 3.6-rc5 > > > > > > There are nothing scaring, contains only small fixes for HD-audio and > > > USB-audio: > > > - EPSS regression fix and GPIO fix for HD-audio IDT codecs > > > - A series of USB-audio regression fixes that are found since 3.5 > > > kernel > > > > > > > > > Daniel Mack (4): > > > ALSA: snd-usb: Fix URB cancellation at stream start > > > ALSA: snd-usb: restore delay information > > > > The commit fbcfbf5f above causes the following lines to be printed > > whenever I start a new song: > > >>> > > >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > > >>> patch (fbcfbf5f) brings back now. > > >>> > > delay: estimated 0, actual 352 > > delay: estimated 353, actual 705 > > > > (44.1 * 8 = 352.8) > > > > This happens with an USB-DAC that identifies itself as "C-Media USB > > Headphone Set". > > >>> > > >>> And you didn't you see these lines with 3.4? > > >> > > >> Maybe the difference of start condition? > > >> > > >> Markus, does the patch below fix anything? > > > > > > Unfortunately no. > > > However reverting the following fixes the problem: > > > > > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > > > Author: Daniel Mack > > > Date: Thu Aug 30 18:52:30 2012 +0200 > > > > > > ALSA: snd-usb: fix calls to next_packet_size > > > > > > > No, this one certainly fixes a problem and does the right thing by > > restoring the original code. > > > > If you wouldn't state that you didn't see the same effect with 3.4(!), > > before the refactoring done in 3.5, I would believe the device is simply > > slightly off in its feedback rate and the tighter delay code complains > > about it while compensating, just as it did before. > > > > Are there any more than these two lines? And is audio working at all? Is > > it distorted in any way? > > There are only these two lines (printed whenever sound starts). Audio is > working just fine with no distortions. > > I did see similar lines before when the system load was very high > (happend during "make check" when building glibc). > > Here is what Pierre-Louis wrote in November 2011: > > »This was supposed to be an informational message, I thought it was only > enabled for debug. Regular users don't really need to know.« I guess the problem is that the new endpoint scheme doesn't count the last_delay update unless the stream is triggered. In the old code, retire_playback_urb is always called even before the trigger(START) is set. And, there retire_playback_urb() does nothing but updating the delay information. In the new code, retire_playback_urb is set only at snd_usb_substream_playback_trigger(). Thus at the very first shot, the delay account got confused. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] JFS: use list_move instead of list_del/list_add
From: Wei Yongjun Using list_move() instead of list_del() + list_add(). spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun --- fs/jfs/jfs_txnmgr.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c index bb8b661..5fcc02e 100644 --- a/fs/jfs/jfs_txnmgr.c +++ b/fs/jfs/jfs_txnmgr.c @@ -2977,12 +2977,9 @@ int jfs_sync(void *arg) * put back on the anon_list. */ - /* Take off anon_list */ - list_del(_ip->anon_inode_list); - - /* Put on anon_list2 */ - list_add(_ip->anon_inode_list, -_list2); + /* Move from anon_list to anon_list2 */ + list_move(_ip->anon_inode_list, + _list2); TXN_UNLOCK(); iput(ip); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] memory-hotplug: bug fix race between isolation and allocation
Hello Yasuaki,
On Thu, Sep 06, 2012 at 04:17:54PM +0900, Yasuaki Ishimatsu wrote:
> Hi Minchan,
>
> 2012/09/06 14:16, Minchan Kim wrote:
> > Like below, memory-hotplug makes race between page-isolation
> > and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
> >
> > CPU A CPU B
> >
> > start_isolate_page_range
> > set_migratetype_isolate
> > spin_lock_irqsave(zone->lock)
> >
> > free_hot_cold_page(Page A)
> > /* without zone->lock */
> > migratetype = get_pageblock_migratetype(Page A);
> > /*
> > * Page could be moved into MIGRATE_MOVABLE
> > * of per_cpu_pages
> > */
> > list_add_tail(>lru,
> > >lists[migratetype]);
> >
> > set_pageblock_isolate
> > move_freepages_block
> > drain_all_pages
> >
> > /* Page A could be in MIGRATE_MOVABLE of
> > free_list. */
> >
> > check_pages_isolated
> > __test_page_isolated_in_pageblock
> > /*
> > * We can't catch freed page which
> > * is free_list[MIGRATE_MOVABLE]
> > */
> > if (PageBuddy(page A))
> > pfn += 1 << page_order(page A);
> >
> > /* So, Page A could be allocated */
> >
> > __offline_isolated_pages
> > /*
> > * BUG_ON hit or offline page
> > * which is used by someone
> > */
> > BUG_ON(!PageBuddy(page A));
> >
> > This patch checks page's migratetype in freelist in
> > __test_page_isolated_in_pageblock.
> > So now __test_page_isolated_in_pageblock can check the page caused by above
> > race and
> > can fail of memory offlining.
> >
> > Signed-off-by: Minchan Kim
> > ---
> > mm/page_isolation.c |5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index 87a7929..7ba7405 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -193,8 +193,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> > unsigned long end_pfn)
> > continue;
> > }
> > page = pfn_to_page(pfn);
> > - if (PageBuddy(page))
> > + if (PageBuddy(page)) {
> > + if (get_freepage_migratetype(page) != MIGRATE_ISOLATE)
> > + break;
> > pfn += 1 << page_order(page);
> > + }
>
> > else if (page_count(page) == 0 &&
> > get_freepage_migratetype(page) == MIGRATE_ISOLATE)
>
> When do the if statement, the page may be used by someone.
I can't understand your point.
We already hold zone->lock so that allocator and this function should be atomic
when the page is in free_list.
If I miss something, could you elaborate it more?
> In this case, page->index may have some number. If the number is same as
> MIGRATE_ISOLATE, the code goes worng.
>
> Thanks,
> Yasuaki Ishimatsu
>
> > pfn += 1;
> >
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote: > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh" > wrote: > >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote: >> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh" >> > wrote: > >> >> After thinking bit more on this, the problem seems to be coming >> >> mainly because the gpio device is runtime suspended bit early than >> >> it should be. Similar issue seen with i2c driver as well. The i2c issue >> >> was discussed with Rafael at LPC last week. The idea is to move >> >> the pm_runtime_enable/disable() calls entirely up to the >> >> _late/_early stage of device suspend/resume. >> >> Will update this thread once I have further update. >> > >> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all >> > the _late callbacks have been called. >> > I, too, spoke to Rafael about this in San Diego. He seemed to agree with >> > me >> > that the interrupt needs to be masked in the ->suspend callback. any later >> > is too late. >> > >> Thanks for information about your discussion. Will wait for the patch then. >> >> Regards >> santosh > > I already sent a patch - that is what started this thread :-) > > I include it below. > You said "The patch doesn't seems to be correct" but didn't expand on why. > Do you still think it is not correct? I wouldn't be surprised if there is > some case that it doesn't handle quite right, but it seems right to me. > Sorry I though you were talking about moving the "Checking wakeup interrupts" bit early as discussed on the follow up of alternate suggested patch to make use of IRQCHIP_MASK_ON_SUSPEND. I think we need to fix the issue seen with ' IRQCHIP_MASK_ON_SUSPEND' patch. That is at least the expected way to manage suspend and wakeup irq masks for a IRQCHIP. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 PATCH 20/21] memory-hotplug: clear hwpoisoned flag when onlining pages
2012/9/5
>
> From: Wen Congyang
>
> hwpoisoned may set when we offline a page by the sysfs interface
> /sys/devices/system/memory/soft_offline_page or
> /sys/devices/system/memory/hard_offline_page. If we don't clear
> this flag when onlining pages, this page can't be freed, and will
> not in free list. So we can't offline these pages again. So we
> should clear this flag when onlining pages.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signed-off-by: Wen Congyang
> ---
> mm/memory_hotplug.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 270c249..140c080 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -661,6 +661,11 @@ EXPORT_SYMBOL_GPL(__online_page_increment_counters);
>
> void __online_page_free(struct page *page)
> {
> +#ifdef CONFIG_MEMORY_FAILURE
> + /* The page may be marked HWPoisoned by soft/hard offline page */
> + ClearPageHWPoison(page);
Hi Congyang,
I think you should decrease mce_bad_pages counter her
atomic_long_sub(1, _bad_pages);
>
> +#endif
> +
> ClearPageReserved(page);
> init_page_count(page);
> __free_page(page);
> --
> 1.7.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: sx150x: Use irq_data_get_irq_chip_data() at appropriate places
On Tue, Sep 4, 2012 at 4:06 PM, Axel Lin wrote: > Signed-off-by: Axel Lin Thanks, applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Chinese translation of Documentation/gpio.txt
2012/9/5 Dong Aisheng : Thanks for your help Dong, Wei can you please check Dong's comments and submit a version with his ACK, and I'll apply it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sept 6
Hi all, Changes since 20120905: New tree: arm64 The powerpc tree gained a build failure for which I reverted 3 commits. The net-next tree lost its build failure. The trivial tree gained a conflict against the powerpc tree. The spi-mb tree gained a build failure so I used the version from next-20120905. The driver-core tree gained a build failure (form an interaction with the workqueues tree) for which I applied a merge fix patch. The tty tree gained a build failure for which I applied a patch. The staging tree lost its build failure. The arm-soc tree gained a conflict against the usb tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 196 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (5b716ac Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (6c7080a firmware: fix directory creation rule matching with make 3.82) Merging arm-current/fixes (36418c5 ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM) Merging m68k-current/for-linus (3be7184 m68k: Add missing RCU idle APIs on idle loop) Merging powerpc-merge/merge (636802e powerpc: Don't use __put_user() in patch_instruction) Merging sparc/master (6dab7ed Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm) Merging net/master (d90c92f ibmveth: Fix alignment of rx queue bug) Merging sound-current/for-linus (2e4a263 ALSA: snd-usb: fix cross-interface streaming devices) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (f107238 libertas sdio: fix suspend when interface is down) Merging driver-core.current/driver-core-linus (fea7a08 Linux 3.6-rc3) Merging tty.current/tty-linus (7be0670 tty: serial: imx: don't reinit clock in imx_setup_ufcr()) Merging usb.current/usb-linus (92fc7a8 USB: add device quirk for Joss Optical touchboard) Merging staging.current/staging-linus (6d7d979 staging: zcache: fix cleancache race condition with shrinker) Merging char-misc.current/char-misc-linus (fea7a08 Linux 3.6-rc3) Merging input-current/for-linus (6f4d038 Input: wacom - add support for EMR on Cintiq 24HD touch) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (ce026cb crypto: caam - fix possible deadlock condition) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging
Re: [PATCH 1/3] w1: mxc_w1: Adapt the clock name to the new clock framework
Hi Fabio,
On Wed, Sep 05, 2012 at 07:01:18PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> With the new i.mx clock framework the mxc_w1 clock is registered as:
>
> clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1.0"
>
> So we do not need to pass "owire" string and can use NULL instead.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/w1/masters/mxc_w1.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
> index 1cc61a7..14f0f66 100644
> --- a/drivers/w1/masters/mxc_w1.c
> +++ b/drivers/w1/masters/mxc_w1.c
> @@ -117,7 +117,7 @@ static int __devinit mxc_w1_probe(struct platform_device
> *pdev)
> if (!mdev)
> return -ENOMEM;
>
> - mdev->clk = clk_get(>dev, "owire");
> + mdev->clk = clk_get(>dev, NULL);
> if (!mdev->clk) {
You can sell this patch better if you fix the wrong error check here and
'by the way' adjust the lookup string.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/14] x86, mm: Map ISA area with connected ram range at the same time
On Wed, Sep 5, 2012 at 1:02 AM, Pekka Enberg wrote: > > How significant is the speed gain? The "isa_done" flag makes code flow > > more difficult to follow. On Wed, 5 Sep 2012, Yinghai Lu wrote: > Not really much. > > when booting system: > memmap=16m$128m memmap=16m$512m memmap=16m$256m memmap=16m$768m > memmap=16m$1024m > > with the patch > [0.00] init_memory_mapping: [mem 0x-0x07ff] > [0.00] [mem 0x-0x07ff] page 2M > [0.00] init_memory_mapping: [mem 0x0900-0x0fff] > [0.00] [mem 0x0900-0x0fff] page 2M > [0.00] init_memory_mapping: [mem 0x1100-0x1fff] > [0.00] [mem 0x1100-0x1fff] page 2M > [0.00] init_memory_mapping: [mem 0x2100-0x2fff] > [0.00] [mem 0x2100-0x2fff] page 2M > [0.00] init_memory_mapping: [mem 0x3100-0x3fff] > [0.00] [mem 0x3100-0x3fff] page 2M > [0.00] init_memory_mapping: [mem 0x4100-0x7fffdfff] > [0.00] [mem 0x4100-0x7fdf] page 2M > [0.00] [mem 0x7fe0-0x7fffdfff] page 4k > > otherwise will have > > [0.00] init_memory_mapping: [mem 0x-0x000f] > [0.00] [mem 0x-0x000f] page 4k > [0.00] init_memory_mapping: [mem 0x0010-0x07ff] > [0.00] [mem 0x0010-0x001f] page 4k > [0.00] [mem 0x0020-0x07ff] page 2M > [0.00] init_memory_mapping: [mem 0x0900-0x0fff] > [0.00] [mem 0x0900-0x0fff] page 2M > [0.00] init_memory_mapping: [mem 0x1100-0x1fff] > [0.00] [mem 0x1100-0x1fff] page 2M > [0.00] init_memory_mapping: [mem 0x2100-0x2fff] > [0.00] [mem 0x2100-0x2fff] page 2M > [0.00] init_memory_mapping: [mem 0x3100-0x3fff] > [0.00] [mem 0x3100-0x3fff] page 2M > [0.00] init_memory_mapping: [mem 0x4100-0x7fffdfff] > [0.00] [mem 0x4100-0x7fdf] page 2M > [0.00] [mem 0x7fe0-0x7fffdfff] page 4k OK. Is there any other reason than performance to do this? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: ipu: Drop unused spinlock
I was checking why this spinlock was never initialized, but it turns
out it's not used anywhere, so we can drop it.
Signed-off-by: Jean Delvare
Cc: Vinod Koul
Cc: Dan Williams
---
I can't even build-test this.
drivers/dma/ipu/ipu_irq.c |1 -
1 file changed, 1 deletion(-)
--- linux-3.6-rc4.orig/drivers/dma/ipu/ipu_irq.c2012-08-04
21:49:26.0 +0200
+++ linux-3.6-rc4/drivers/dma/ipu/ipu_irq.c 2012-09-06 09:13:31.034228670
+0200
@@ -45,7 +45,6 @@ static void ipu_write_reg(struct ipu *ip
struct ipu_irq_bank {
unsigned intcontrol;
unsigned intstatus;
- spinlock_t lock;
struct ipu *ipu;
};
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] arm/dts: AM33XX: Add SPI device tree data
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash
---
Resenting patch because ARM & OMAP mailing list was not copied.
:100644 100644 bb31bff... 6b469bd... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..6b469bd 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,30 @@
interrupt-parent = <>;
interrupts = <91>;
};
+
+ spi0: spi@4803 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x483 0x400>;
+ interrupt-parent = <>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+
+ };
+
+ spi1: spi@481a {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a 0x400>;
+ interrupt-parent = <>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: em: Use irq_data_get_irq_chip_data() at appropriate places
On Tue, Sep 4, 2012 at 3:58 PM, Axel Lin wrote: > Then we can remove irq_to_priv() function. > > Signed-off-by: Axel Lin Thanks, applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] memory-hotplug: bug fix race between isolation and allocation
Hi Minchan,
2012/09/06 14:16, Minchan Kim wrote:
> Like below, memory-hotplug makes race between page-isolation
> and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
>
> CPU A CPU B
>
> start_isolate_page_range
> set_migratetype_isolate
> spin_lock_irqsave(zone->lock)
>
> free_hot_cold_page(Page A)
> /* without zone->lock */
> migratetype = get_pageblock_migratetype(Page A);
> /*
>* Page could be moved into MIGRATE_MOVABLE
>* of per_cpu_pages
>*/
> list_add_tail(>lru,
> >lists[migratetype]);
>
> set_pageblock_isolate
> move_freepages_block
> drain_all_pages
>
> /* Page A could be in MIGRATE_MOVABLE of
> free_list. */
>
> check_pages_isolated
> __test_page_isolated_in_pageblock
> /*
> * We can't catch freed page which
> * is free_list[MIGRATE_MOVABLE]
> */
> if (PageBuddy(page A))
> pfn += 1 << page_order(page A);
>
> /* So, Page A could be allocated */
>
> __offline_isolated_pages
> /*
> * BUG_ON hit or offline page
> * which is used by someone
> */
> BUG_ON(!PageBuddy(page A));
>
> This patch checks page's migratetype in freelist in
> __test_page_isolated_in_pageblock.
> So now __test_page_isolated_in_pageblock can check the page caused by above
> race and
> can fail of memory offlining.
>
> Signed-off-by: Minchan Kim
> ---
> mm/page_isolation.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 87a7929..7ba7405 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -193,8 +193,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> unsigned long end_pfn)
> continue;
> }
> page = pfn_to_page(pfn);
> - if (PageBuddy(page))
> + if (PageBuddy(page)) {
> + if (get_freepage_migratetype(page) != MIGRATE_ISOLATE)
> + break;
> pfn += 1 << page_order(page);
> + }
> else if (page_count(page) == 0 &&
> get_freepage_migratetype(page) == MIGRATE_ISOLATE)
When do the if statement, the page may be used by someone.
In this case, page->index may have some number. If the number is same as
MIGRATE_ISOLATE, the code goes worng.
Thanks,
Yasuaki Ishimatsu
> pfn += 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 RESEND]mm/ia64: fix a node distance bug
From: Jianguo Wu In arch ia64, has following definition: extern u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES]; #define node_distance(from,to) (numa_slit[(from) * num_online_nodes() + (to)]) num_online_nodes() is a variable value, it can be changed after hot-remove/add a node. I my practice, I found node distance is wrong after offline a node in IA64 platform. For example system has 4 nodes: node distances: node 0 1 2 3 0: 10 21 21 32 1: 21 10 32 21 2: 21 32 10 21 3: 32 21 21 10 linux-drf:/sys/devices/system/node/node0 # cat distance 10 21 21 32 linux-drf:/sys/devices/system/node/node1 # cat distance 21 10 32 21 After offline node2: linux-drf:/sys/devices/system/node/node0 # cat distance 10 21 32 linux-drf:/sys/devices/system/node/node1 # cat distance 32 21 32->expected value is: 21 10 21 Signed-off-by: Jianguo Wu Signed-off-by: Jiang Liu --- arch/ia64/include/asm/numa.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h index 6a8a27c..2e27ef1 100644 --- a/arch/ia64/include/asm/numa.h +++ b/arch/ia64/include/asm/numa.h @@ -59,7 +59,7 @@ extern struct node_cpuid_s node_cpuid[NR_CPUS]; */ extern u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES]; -#define node_distance(from,to) (numa_slit[(from) * num_online_nodes() + (to)]) +#define node_distance(from,to) (numa_slit[(from) * MAX_NUMNODES + (to)]) extern int paddr_to_nid(unsigned long paddr); -- 1.7.6.1 . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: snd-usb: "delay: estimated 0, actual 352"
On 2012.09.06 at 09:08 +0200, Daniel Mack wrote: > On 06.09.2012 08:53, Markus Trippelsdorf wrote: > > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: > >> At Thu, 06 Sep 2012 08:33:30 +0200, > >> Daniel Mack wrote: > >>> > >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > > > Sound fixes for 3.6-rc5 > > > > There are nothing scaring, contains only small fixes for HD-audio and > > USB-audio: > > - EPSS regression fix and GPIO fix for HD-audio IDT codecs > > - A series of USB-audio regression fixes that are found since 3.5 kernel > > > > > > Daniel Mack (4): > > ALSA: snd-usb: Fix URB cancellation at stream start > > ALSA: snd-usb: restore delay information > > The commit fbcfbf5f above causes the following lines to be printed > whenever I start a new song: > >>> > >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > >>> patch (fbcfbf5f) brings back now. > >>> > delay: estimated 0, actual 352 > delay: estimated 353, actual 705 > > (44.1 * 8 = 352.8) > > This happens with an USB-DAC that identifies itself as "C-Media USB > Headphone Set". > >>> > >>> And you didn't you see these lines with 3.4? > >> > >> Maybe the difference of start condition? > >> > >> Markus, does the patch below fix anything? > > > > Unfortunately no. > > However reverting the following fixes the problem: > > > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > > Author: Daniel Mack > > Date: Thu Aug 30 18:52:30 2012 +0200 > > > > ALSA: snd-usb: fix calls to next_packet_size > > > > No, this one certainly fixes a problem and does the right thing by > restoring the original code. > > If you wouldn't state that you didn't see the same effect with 3.4(!), > before the refactoring done in 3.5, I would believe the device is simply > slightly off in its feedback rate and the tighter delay code complains > about it while compensating, just as it did before. > > Are there any more than these two lines? And is audio working at all? Is > it distorted in any way? There are only these two lines (printed whenever sound starts). Audio is working just fine with no distortions. I did see similar lines before when the system load was very high (happend during "make check" when building glibc). Here is what Pierre-Louis wrote in November 2011: »This was supposed to be an informational message, I thought it was only enabled for debug. Regular users don't really need to know.« -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm i.MX: fix clock lookup
On Wed, Sep 05, 2012 at 11:48:51PM +0200, Benoît Thébaudeau wrote:
> >
> > - c = clk_get_rate(imx->clk);
> > + c = clk_get_rate(imx->clk_per);
> > c = c * period_ns;
> > do_div(c, 10);
> > period_cycles = c;
> > @@ -160,8 +161,15 @@ static int imx_pwm_config(struct pwm_chip *chip,
> > struct pwm_device *pwm, int duty_ns, int period_ns)
> > {
> > struct imx_chip *imx = to_imx_chip(chip);
> > + int ret;
> >
> > - return imx->config(chip, pwm, duty_ns, period_ns);
> > + clk_prepare_enable(imx->clk_ipg);
>
> Why don't you test the return value like in imx_pwm_enable()?
Will do next time.
Sascha
>
> I have reviewed the whole series. Apart from the comments I made, it looks
> good
> to me.
Thanks. I can take this as a reviewed-by, right?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
In file included from drivers/atm/fore200e.c:70:0:
drivers/atm/fore200e.h:263:3: error: redefinition of typedef 'opcode_t' with
different type
arch/powerpc/include/asm/probes.h:25:13: note: previous declaration of
'opcode_t' was here
Caused by commit 7118e7e648e0 ("powerpc: Consolidate {k,u}probe
definitions") from the powerpc tree.
I have reverted that commit (and the two following:
41ab5266c362"powerpc: Add trap_nr to thread_struct"
8b7b80b9ebb4"powerpc: Uprobes port to powerpc")
for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQQY9eQRlrC.pgp
Description: PGP signature
Re: snd-usb: "delay: estimated 0, actual 352"
On 06.09.2012 08:53, Markus Trippelsdorf wrote: > On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: >> At Thu, 06 Sep 2012 08:33:30 +0200, >> Daniel Mack wrote: >>> >>> On 06.09.2012 08:02, Markus Trippelsdorf wrote: On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > Sound fixes for 3.6-rc5 > > There are nothing scaring, contains only small fixes for HD-audio and > USB-audio: > - EPSS regression fix and GPIO fix for HD-audio IDT codecs > - A series of USB-audio regression fixes that are found since 3.5 kernel > > > Daniel Mack (4): > ALSA: snd-usb: Fix URB cancellation at stream start > ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: >>> >>> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this >>> patch (fbcfbf5f) brings back now. >>> delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as "C-Media USB Headphone Set". >>> >>> And you didn't you see these lines with 3.4? >> >> Maybe the difference of start condition? >> >> Markus, does the patch below fix anything? > > Unfortunately no. > However reverting the following fixes the problem: > > commit 245baf983cc39524cce39c24d01b276e6e653c9e > Author: Daniel Mack > Date: Thu Aug 30 18:52:30 2012 +0200 > > ALSA: snd-usb: fix calls to next_packet_size > No, this one certainly fixes a problem and does the right thing by restoring the original code. If you wouldn't state that you didn't see the same effect with 3.4(!), before the refactoring done in 3.5, I would believe the device is simply slightly off in its feedback rate and the tighter delay code complains about it while compensating, just as it did before. Are there any more than these two lines? And is audio working at all? Is it distorted in any way? Pierre-Louis, could you check whether I did the right thing when I ported over your delay bits to the new endpoint logic? Maybe I'm missing something here, but I currently don't see it. Thanks, 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/
Re: [PATCH] serial_core: fix sizeof(pointer)
On Thu, Sep 06, 2012 at 08:59:00AM +0200, Jiri Slaby wrote:
> On 09/06/2012 04:27 AM, Fengguang Wu wrote:
> > sizeof when applied to a pointer typed expression gives the
> > size of the pointer.
> >
> > Generated by: scripts/coccinelle/misc/noderef.cocci
> >
> > Signed-off-by: Fengguang Wu
> > ---
> >
> > cocci-output-38612-39d907-serial_core.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -640,7 +640,7 @@ static void uart_get_info(struct tty_por
> > {
> > struct uart_port *uport = state->uart_port;
> >
> > - memset(retinfo, 0, sizeof(retinfo));
> > + memset(retinfo, 0, sizeof(*retinfo));
>
> Hmm, what tree is this against? I have:
It's the tty:tty-next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
> memset(, 0, sizeof(tmp));
Oh I didn't know it's a new bug introduced by commit
commit 7ba2e769825fef035a943ed74d90379245508764
Author: Alan Cox
AuthorDate: Tue Sep 4 16:34:45 2012 +0100
Commit: Greg Kroah-Hartman
CommitDate: Wed Sep 5 13:11:03 2012 -0700
tty: Split the serial_core helpers for setserial into two
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V6 10/19] memory-hotplug: add memory_block_release
On 2012-8-3 15:49, we...@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu
>
> When calling remove_memory_block(), the function shows following message at
> device_release().
>
> Device 'memory528' does not have a release() function, it is broken and must
> be fixed.
>
I found this warning too when doing memory-hotplug,
why not send as a bug fix patch?
The same as [RFC PATCH V6 18/19] memory-hotplug: add node_device_release
> remove_memory_block() calls kfree(mem). I think it shouled be called from
> device_release(). So the patch implements memory_block_release()
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
> ---
> drivers/base/memory.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 038be73..1cd3ef3 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -109,6 +109,15 @@ bool is_memblk_offline(unsigned long start, unsigned
> long size)
> }
> EXPORT_SYMBOL(is_memblk_offline);
>
> +#define to_memory_block(device) container_of(device, struct memory_block,
> dev)
> +
> +static void release_memory_block(struct device *dev)
> +{
> + struct memory_block *mem = to_memory_block(dev);
> +
> + kfree(mem);
> +}
> +
> /*
> * register_memory - Setup a sysfs device for a memory block
> */
> @@ -119,6 +128,7 @@ int register_memory(struct memory_block *memory)
>
> memory->dev.bus = _subsys;
> memory->dev.id = memory->start_section_nr / sections_per_block;
> + memory->dev.release = release_memory_block;
>
> error = device_register(>dev);
> return error;
> @@ -674,7 +684,6 @@ int remove_memory_block(unsigned long node_id, struct
> mem_section *section,
> mem_remove_simple_file(mem, phys_device);
> mem_remove_simple_file(mem, removable);
> unregister_memory(mem);
> - kfree(mem);
> } else
> kobject_put(>dev.kobj);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
wrote:
> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > wrote:
> >> After thinking bit more on this, the problem seems to be coming
> >> mainly because the gpio device is runtime suspended bit early than
> >> it should be. Similar issue seen with i2c driver as well. The i2c issue
> >> was discussed with Rafael at LPC last week. The idea is to move
> >> the pm_runtime_enable/disable() calls entirely up to the
> >> _late/_early stage of device suspend/resume.
> >> Will update this thread once I have further update.
> >
> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all
> > the _late callbacks have been called.
> > I, too, spoke to Rafael about this in San Diego. He seemed to agree with me
> > that the interrupt needs to be masked in the ->suspend callback. any later
> > is too late.
> >
> Thanks for information about your discussion. Will wait for the patch then.
>
> Regards
> santosh
I already sent a patch - that is what started this thread :-)
I include it below.
You said "The patch doesn't seems to be correct" but didn't expand on why.
Do you still think it is not correct? I wouldn't be surprised if there is
some case that it doesn't handle quite right, but it seems right to me.
Thanks,
NeilBrown
From: NeilBrown
Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for "GPIO
should wake from deep idle" and "GPIO should wake from suspend".
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Cousson Benoit
Cc: Grant Likely
Cc: Tarun Kanti DebBarma
Cc: Felipe Balbi
Cc: Govindraj.R
Signed-off-by: NeilBrown
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4fbc208..fdbad70 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,6 +57,7 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
+ u32 suspend_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(>lock, flags);
if (enable)
- bank->context.wake_en |= gpio_bit;
+ bank->suspend_wakeup |= gpio_bit;
else
- bank->context.wake_en &= ~gpio_bit;
+ bank->suspend_wakeup &= ~gpio_bit;
- __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
+ if (!bank->loses_context)
+ __raw_writel(bank->suspend_wakeup, bank->base +
bank->regs->wkup_en);
spin_unlock_irqrestore(>lock, flags);
return 0;
@@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM_RUNTIME)
+
+#if defined(CONFIG_PM_SLEEP)
+static int omap_gpio_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank->base;
+ unsigned long flags;
+
+ if (!bank->mod_usage || !bank->loses_context)
+ return 0;
+
+ if (!bank->regs->wkup_en || !bank->context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(>lock, flags);
+ _gpio_rmw(base, bank->regs->wkup_en, 0x, 0);
+ _gpio_rmw(base, bank->regs->wkup_en, bank->suspend_wakeup, 1);
+ spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
+}
+
+static int omap_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank->base;
+ unsigned long flags;
+
+ if (!bank->mod_usage || !bank->loses_context)
+ return 0;
+
+ if (!bank->regs->wkup_en || !bank->context.wake_en)
+
Re: [PATCH] serial_core: fix sizeof(pointer)
On 09/06/2012 04:27 AM, Fengguang Wu wrote:
> sizeof when applied to a pointer typed expression gives the
> size of the pointer.
>
> Generated by: scripts/coccinelle/misc/noderef.cocci
>
> Signed-off-by: Fengguang Wu
> ---
>
> cocci-output-38612-39d907-serial_core.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -640,7 +640,7 @@ static void uart_get_info(struct tty_por
> {
> struct uart_port *uport = state->uart_port;
>
> - memset(retinfo, 0, sizeof(retinfo));
> + memset(retinfo, 0, sizeof(*retinfo));
Hmm, what tree is this against? I have:
memset(, 0, sizeof(tmp));
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] pwm i.MX: add devicetree support
On Wed, Sep 05, 2012 at 11:42:34PM +0200, Benoît Thébaudeau wrote: > > Since this is supposed to remove platform-based support, why don't you also > remove the PWM stuff from arch/arm/plat-mxc and > arch/arm/mach-imx/devices-imx*.h? Simple answer: I was too lazy yesterday. I will include it in the next round. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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:
On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: > At Thu, 06 Sep 2012 08:33:30 +0200, > Daniel Mack wrote: > > > > On 06.09.2012 08:02, Markus Trippelsdorf wrote: > > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > >> > > >> Sound fixes for 3.6-rc5 > > >> > > >> There are nothing scaring, contains only small fixes for HD-audio and > > >> USB-audio: > > >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs > > >> - A series of USB-audio regression fixes that are found since 3.5 kernel > > >> > > >> > > >> Daniel Mack (4): > > >> ALSA: snd-usb: Fix URB cancellation at stream start > > >> ALSA: snd-usb: restore delay information > > > > > > The commit fbcfbf5f above causes the following lines to be printed > > > whenever I start a new song: > > > > Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > > patch (fbcfbf5f) brings back now. > > > > > delay: estimated 0, actual 352 > > > delay: estimated 353, actual 705 > > > > > > (44.1 * 8 = 352.8) > > > > > > This happens with an USB-DAC that identifies itself as "C-Media USB > > > Headphone Set". > > > > And you didn't you see these lines with 3.4? > > Maybe the difference of start condition? > > Markus, does the patch below fix anything? Unfortunately no. However reverting the following fixes the problem: commit 245baf983cc39524cce39c24d01b276e6e653c9e Author: Daniel Mack Date: Thu Aug 30 18:52:30 2012 +0200 ALSA: snd-usb: fix calls to next_packet_size -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm: pwm-tiecap: Disable APWM mode after configure
Hi Thierry,
If you do not have any comments, could you please accept it?
Thanks
Avinash
On Thu, Aug 23, 2012 at 12:29:46, Philip, Avinash wrote:
> APWM mode is enabled while configuring PWM device. This was done to
> handle shadow & immediate mode update of period and compare registers.
> However, leaving it enabled after configuring will cause APWM output on
> PWM pin even before enabling PWM device.
> Fix the same by disabling APWM mode after configuring if PWM device is
> not running.
>
> Signed-off-by: Philip, Avinash
> ---
> :100644 100644 0b66d0f... 4b66889... Mdrivers/pwm/pwm-tiecap.c
> drivers/pwm/pwm-tiecap.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
> index 0b66d0f..4b66889 100644
> --- a/drivers/pwm/pwm-tiecap.c
> +++ b/drivers/pwm/pwm-tiecap.c
> @@ -100,6 +100,13 @@ static int ecap_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> writel(period_cycles, pc->mmio_base + CAP3);
> }
>
> + if (!test_bit(PWMF_ENABLED, >flags)) {
> + reg_val = readw(pc->mmio_base + ECCTL2);
> + /* Disable APWM mode to put APWM output Low */
> + reg_val &= ~ECCTL2_APWM_MODE;
> + writew(reg_val, pc->mmio_base + ECCTL2);
> + }
> +
> pm_runtime_put_sync(pc->chip.dev);
> return 0;
> }
> --
> 1.7.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86/mce: Pack boolean MCE flags into a structure
On 09/06/2012 12:26 AM, Tony Luck wrote: On Wed, Sep 5, 2012 at 3:22 AM, Naveen N. Rao wrote: Many MCE flags are boolean in nature, but are declared as integers currently. We can pack these into a bitfield to save some space. Before this patch: size arch/x86/kernel/cpu/mcheck/mce.o text data bss dec hex filename 18946 4930 776 24652604c arch/x86/kernel/cpu/mcheck/mce.o After: size arch/x86/kernel/cpu/mcheck/mce.o text data bss dec hex filename 19335 4890 776 2500161a9 arch/x86/kernel/cpu/mcheck/mce.o So we do indeed see "data" reduced by 40 bytes. But "text" is up by 389. This seems to be because you have another change, not described in the commit log, buried in part 2 to add get_dont_log_ce(), set_dont_log_ce() etc. Compiler version: gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) I know I'm contradicting the feedback you got from Borislav here, but is this code churn really worth it to save 40 bytes? I don't think so. Hmm.. I think I agree. I don't see a good way to get rid of the individual getters and setters without adding some more code churn. I guess using boolean would be better. Boris? Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
At Thu, 06 Sep 2012 08:33:30 +0200, Daniel Mack wrote: > > On 06.09.2012 08:02, Markus Trippelsdorf wrote: > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > >> > >> Sound fixes for 3.6-rc5 > >> > >> There are nothing scaring, contains only small fixes for HD-audio and > >> USB-audio: > >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs > >> - A series of USB-audio regression fixes that are found since 3.5 kernel > >> > >> > >> Daniel Mack (4): > >> ALSA: snd-usb: Fix URB cancellation at stream start > >> ALSA: snd-usb: restore delay information > > > > The commit fbcfbf5f above causes the following lines to be printed > > whenever I start a new song: > > Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > patch (fbcfbf5f) brings back now. > > > delay: estimated 0, actual 352 > > delay: estimated 353, actual 705 > > > > (44.1 * 8 = 352.8) > > > > This happens with an USB-DAC that identifies itself as "C-Media USB > > Headphone Set". > > And you didn't you see these lines with 3.4? Maybe the difference of start condition? Markus, does the patch below fix anything? Takashi --- diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index fd5e982..0ff9f1a 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -556,7 +556,7 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->hwptr_done = 0; subs->transfer_done = 0; subs->last_delay = 0; - subs->last_frame_number = 0; + subs->last_frame_number = snd_usb_pcm_delay(subs, runtime->rate); runtime->delay = 0; /* for playback, submit the URBs now; otherwise, the first hwptr_done -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] fat: allocate persistent inode numbers
2012/9/5 OGAWA Hirofumi : > Namjae Jeon writes: > >> In this long discusstion about the FAT acceptance over NFS, our belief >> is still that the objective should be to reduce errors as much as >> possible and then if there are certain scenarios - at least that could >> be highlighted as a limitation in Documentation instead of completely >> discarding the usage of FAT over NFS. So how about puttting rename >> scenario as a limitation ? In ideal scenario how many times this is >> going to happen ? > > My understanding of your patches is to introduce the silent corruption > bug by getting wrong location via ino on some cases, instead of > ESTALE. And make surprise to userland by change ino. > > Why is it safe to change ino? If you are saying to remove the changing > ino on rename, how handle the case of collision? Yes, agreed this would lead to collision. So, If we are choosing 'i_pos' as inode number, We need to have a mechanism to avoid this 'i_pos' being reused. We can have one thing over here. As a part of avoidance for such scenarios - We can return EBUSY for this rename operation. i.e., If the inode is being referenced then in such cases it makes sense to return EBUSY over NFS and forcus on the large part of the solution which is making FAT stable. Let me know your opinion. Thanks OGAWA. > -- > OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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:
On 2012.09.06 at 08:33 +0200, Daniel Mack wrote: > On 06.09.2012 08:02, Markus Trippelsdorf wrote: > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > >> > >> Sound fixes for 3.6-rc5 > >> > >> There are nothing scaring, contains only small fixes for HD-audio and > >> USB-audio: > >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs > >> - A series of USB-audio regression fixes that are found since 3.5 kernel > >> > >> > >> Daniel Mack (4): > >> ALSA: snd-usb: Fix URB cancellation at stream start > >> ALSA: snd-usb: restore delay information > > > > The commit fbcfbf5f above causes the following lines to be printed > > whenever I start a new song: > > Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this > patch (fbcfbf5f) brings back now. > > > delay: estimated 0, actual 352 > > delay: estimated 353, actual 705 > > > > (44.1 * 8 = 352.8) > > > > This happens with an USB-DAC that identifies itself as "C-Media USB > > Headphone Set". > > And you didn't you see these lines with 3.4? No. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [mcelog] Start using the new sysfs tunables location
On 09/06/2012 12:39 AM, Tony Luck wrote: On Wed, Sep 5, 2012 at 11:47 AM, Andi Kleen wrote: On Wed, Sep 05, 2012 at 04:02:37PM +0530, Naveen N. Rao wrote: All the current mce tunables are now available under /sys/devices/system/machinecheck. Start using this new location, but fall back to the older per-cpu location so that we continue working with older kernels. Who did that change in the kernel? That breaks Linus rule that the kernel should not break userland. Kernel needs to fix that. The change is still under discussion. Stage one is to add the new global pathnames in addition to keeping the old per-cpu ones. Also fix all utilities (just mcelog(8) as far as we know) to prefer the new paths. After some time[1] ... delete the old paths. This is allowable under Linus' modified edict that you can change ABI "if nobody complains". If we wait long enough that the new mcelog is widely deployed, then nobody should complain. -Tony [1] several years - not just a kernel release or two. Tony, Thanks for clarifying. I should have mentioned in the patch description that this is indeed subject to the original patch making it into the kernel. On a related topic. I recently noticed that we don't have an entry for machinecheck in Documentation/ABI/. Should we add an entry in there? We could perhaps add the existing entries under obsolete/ and the new location under testing/? - Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 3/3] btrfs: set extent-tree.c/add_excluded_extent as void
The memory allocation failure will be catched in set_extent_bits.
Always return 0 is useless for its callers.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent-tree.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 9b9a6fa..3a295ff 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -209,7 +209,7 @@ block_group_cache_tree_search(struct btrfs_fs_info *info,
u64 bytenr,
return ret;
}
-static int add_excluded_extent(struct btrfs_root *root,
+static void add_excluded_extent(struct btrfs_root *root,
u64 start, u64 num_bytes)
{
u64 end = start + num_bytes - 1;
@@ -217,7 +217,6 @@ static int add_excluded_extent(struct btrfs_root *root,
start, end, EXTENT_UPTODATE, GFP_NOFS);
set_extent_bits(>fs_info->freed_extents[1],
start, end, EXTENT_UPTODATE, GFP_NOFS);
- return 0;
}
static void free_excluded_extents(struct btrfs_root *root,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/btrfs_alloc_logged_file_extent
The memory allocation failure is BUG_ON in add_excluded_extent
(following the code path). No need to BUG_ON -ENOMEM inside
btrfs_alloc_logged_file_extent.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent-tree.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 95492cc..9b9a6fa 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6207,8 +6207,7 @@ int btrfs_alloc_logged_file_extent(struct
btrfs_trans_handle *trans,
mutex_lock(_ctl->mutex);
if (start >= caching_ctl->progress) {
- ret = add_excluded_extent(root, start, num_bytes);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, start, num_bytes);
} else if (start + num_bytes <= caching_ctl->progress) {
ret = btrfs_remove_free_space(block_group,
start, num_bytes);
@@ -6222,8 +6221,7 @@ int btrfs_alloc_logged_file_extent(struct
btrfs_trans_handle *trans,
start = caching_ctl->progress;
num_bytes = ins->objectid + ins->offset -
caching_ctl->progress;
- ret = add_excluded_extent(root, start, num_bytes);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, start, num_bytes);
}
mutex_unlock(_ctl->mutex);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/exclude_super_stripes
The memory allocation failure is BUG_ON in add_excluded_extent (following
the code path) and btrfs_rmap_block. No need to BUG_ON -ENOMEM inside
exclude_super_stripes itself.
Its return value is always 0, and useless for its callers. Set it as void
instead 0-returned.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent-tree.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ba58024..95492cc 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -234,39 +234,33 @@ static void free_excluded_extents(struct btrfs_root *root,
start, end, EXTENT_UPTODATE, GFP_NOFS);
}
-static int exclude_super_stripes(struct btrfs_root *root,
+static void exclude_super_stripes(struct btrfs_root *root,
struct btrfs_block_group_cache *cache)
{
u64 bytenr;
u64 *logical;
int stripe_len;
- int i, nr, ret;
+ int i, nr;
if (cache->key.objectid < BTRFS_SUPER_INFO_OFFSET) {
stripe_len = BTRFS_SUPER_INFO_OFFSET - cache->key.objectid;
cache->bytes_super += stripe_len;
- ret = add_excluded_extent(root, cache->key.objectid,
- stripe_len);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, cache->key.objectid, stripe_len);
}
for (i = 0; i < BTRFS_SUPER_MIRROR_MAX; i++) {
bytenr = btrfs_sb_offset(i);
- ret = btrfs_rmap_block(>fs_info->mapping_tree,
- cache->key.objectid, bytenr,
- 0, , , _len);
- BUG_ON(ret); /* -ENOMEM */
+ btrfs_rmap_block(>fs_info->mapping_tree,
+cache->key.objectid, bytenr,
+0, , , _len);
while (nr--) {
cache->bytes_super += stripe_len;
- ret = add_excluded_extent(root, logical[nr],
- stripe_len);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, logical[nr], stripe_len);
}
kfree(logical);
}
- return 0;
}
static struct btrfs_caching_control *
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re:
On 06.09.2012 08:02, Markus Trippelsdorf wrote: > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: >> >> Sound fixes for 3.6-rc5 >> >> There are nothing scaring, contains only small fixes for HD-audio and >> USB-audio: >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs >> - A series of USB-audio regression fixes that are found since 3.5 kernel >> >> >> Daniel Mack (4): >> ALSA: snd-usb: Fix URB cancellation at stream start >> ALSA: snd-usb: restore delay information > > The commit fbcfbf5f above causes the following lines to be printed > whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. > delay: estimated 0, actual 352 > delay: estimated 353, actual 705 > > (44.1 * 8 = 352.8) > > This happens with an USB-DAC that identifies itself as "C-Media USB > Headphone Set". And you didn't you see these lines with 3.4? 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/
Re: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO
Il 05/09/2012 22:18, Ric Wheeler ha scritto: >> > > Hi Paolo, > > Both of these commands are destructive. WRITE_SAME (if done without the > discard bits set) can also take a very long time to be destructive and > tie up the storage. FORMAT_UNIT has the same characteristics and yet it is allowed (btw, I don't think WRITE SAME slowness is limited to the case where a real write is requested; discarding can be just as slow). Also, the two new commands are anyway restricted to programs that have write access to the disk. If you have read-only access, you won't be able to issue any destructive command (there is one exception, START STOP UNIT is allowed even with read-only capability and is somewhat destructive). Honestly, the only reason why these two commands weren't included, is that the current whitelist is heavily tailored towards CD/DVD burning. > I think that restricting them to CAP_SYS_RAWIO seems reasonable - better > to vet and give the appropriate apps the needed capability than to > widely open up the safety check? CAP_SYS_RAWIO is so wide in its scope, that anything that requires it is insecure. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Linux kernel contribution count script
Ooops, Please forget about this. It's intended for an internal use only :-/ Sorry for the noise. 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 v2 4/5] fat: eliminate orphaned inode number allocation
2012/9/5 OGAWA Hirofumi : > Namjae Jeon writes: > >> 2012/9/5, OGAWA Hirofumi : >>> OGAWA Hirofumi writes: >>> Namjae Jeon writes: > From: Namjae Jeon > > Maintain a list of inode(i_pos) numbers of orphaned inodes (i.e the > inodes that have been unlinked but still having open file > descriptors).At file/directory creation time, skip using such i_pos > values.Removal of the i_pos from the list is done during inode eviction. What happens if the directory (has busy entries) was completely removed? >> Hi OGAWA. >> There are 2 cases: >> 1. The cluster can be used as a data cluster of a file - In which case >> we can write >> normally into it. >> 2. The cluster can be allocated to a new directory. In this case, the busy >> i_pos >> locations can not be used to create new entries until the correspnding >> inodes are >> evicted. > > In the (2) case, it has problem. Directory must not have de->name[0] == 0 > in middle of entires. "0" means the end of directory. Good point! I will fix it on next version of patches. Thanks. > -- > OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the spi-mb tree with the mmc tree
On 09/05/2012 06:15 AM, Stephen Rothwell wrote:
Hi Mark,
Today's linux-next merge of the spi-mb tree got a conflict in
drivers/mmc/host/mxs-mmc.c between commit fc108d24d3a6 ("mmc: mxs-mmc:
fix deadlock caused by recursion loop") from the mmc tree and commit
829c1bf40b92 ("mmc: spi: Pull out parts shared between MMC and SPI") from
the spi-mb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Reviewed and tested. Looks good.
Lauri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Linux kernel contribution count script
From: Namhyung Kim
$ ./contrib-count.sh
Usage: ./contrib-count.sh [ ]
$ ./contrib-count.sh Namhyung
Signed-off: 125
Reviewed: 3
Acked: 1
Tested: 0
$ ./contrib-count.sh Minchan 2012
Signed-off: 20
Reviewed: 32
Acked: 10
Tested: 1
Signed-off-by: Namhyung Kim
---
contrib-count.sh | 27 +++
1 file changed, 27 insertions(+)
create mode 100755 contrib-count.sh
diff --git a/contrib-count.sh b/contrib-count.sh
new file mode 100755
index ..4d246db5735d
--- /dev/null
+++ b/contrib-count.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# Linux kernel contiribution counter.
+# It actually can be used on any git-managed projects.
+#
+
+if [ $# -eq 0 ]; then
+echo "Usage: $0 [ ]"
+exit 1
+fi
+
+NAME=$1
+
+# defaults to current year in format
+YEAR=$(date +"%Y")
+
+if [ $# -ge 2 ]; then
+YEAR=$2
+fi
+
+for TAG in "Signed-off" "Reviewed" "Acked" "Tested";
+do
+echo -n "$TAG: "
+git log --grep="$TAG-by: $NAME" --since "$YEAR-01-01" --until
"$YEAR-12-31" origin/master | \
+ git shortlog -sn | \
+ awk 'BEGIN { count = 0; } { count += $1; } END { print count; }'
+done
--
1.7.11.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 v2 3/3] memory-hotplug: bug fix race between isolation and allocation
(2012/09/06 14:16), Minchan Kim wrote:
> Like below, memory-hotplug makes race between page-isolation
> and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
>
> CPU A CPU B
>
> start_isolate_page_range
> set_migratetype_isolate
> spin_lock_irqsave(zone->lock)
>
> free_hot_cold_page(Page A)
> /* without zone->lock */
> migratetype = get_pageblock_migratetype(Page A);
> /*
>* Page could be moved into MIGRATE_MOVABLE
>* of per_cpu_pages
>*/
> list_add_tail(>lru,
> >lists[migratetype]);
>
> set_pageblock_isolate
> move_freepages_block
> drain_all_pages
>
> /* Page A could be in MIGRATE_MOVABLE of
> free_list. */
>
> check_pages_isolated
> __test_page_isolated_in_pageblock
> /*
> * We can't catch freed page which
> * is free_list[MIGRATE_MOVABLE]
> */
> if (PageBuddy(page A))
> pfn += 1 << page_order(page A);
>
> /* So, Page A could be allocated */
>
> __offline_isolated_pages
> /*
> * BUG_ON hit or offline page
> * which is used by someone
> */
> BUG_ON(!PageBuddy(page A));
>
> This patch checks page's migratetype in freelist in
> __test_page_isolated_in_pageblock.
> So now __test_page_isolated_in_pageblock can check the page caused by above
> race and
> can fail of memory offlining.
>
> Signed-off-by: Minchan Kim
I agree this fix.
Maybe we (fujitsu) should revisit these logics around and make it cleaner
Anyway, thank you!
Acked-by: KAMEZAWA Hiroyuki
> ---
> mm/page_isolation.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 87a7929..7ba7405 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -193,8 +193,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
> unsigned long end_pfn)
> continue;
> }
> page = pfn_to_page(pfn);
> - if (PageBuddy(page))
> + if (PageBuddy(page)) {
> + if (get_freepage_migratetype(page) != MIGRATE_ISOLATE)
> + break;
> pfn += 1 << page_order(page);
> + }
> else if (page_count(page) == 0 &&
> get_freepage_migratetype(page) == MIGRATE_ISOLATE)
> pfn += 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/
[RFC,PATCH v2] efi: Add support for a UEFI variable filesystem
From: Matthew Garrett
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI specification,
but was removed before any full releases. Since variables can now be
larger than a single page, sysfs isn't the best interface for this. So,
instead, let's add a filesystem. Variables can be read, written and
created, with the first 4 bytes of each variable representing its UEFI
attributes. The create() method doesn't actually commit to flash since
zero-length variables can't exist per-spec.
Updates from Jeremy Kerr .
Signed-off-by: Matthew Garrett
Signed-off-by: Jeremy Kerr
---
v2: Add check for < 4-byte writes
---
drivers/firmware/efivars.c | 384 -
include/linux/efi.h|5
2 files changed, 383 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 47408e8..1e1aad0 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -80,6 +80,10 @@
#include
#include
+#include
+#include
+#include
+
#include
#define EFIVARS_VERSION "0.08"
@@ -91,6 +95,7 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(EFIVARS_VERSION);
#define DUMP_NAME_LEN 52
+#define GUID_LEN 37
/*
* The maximum size of VariableName + Data = 1024
@@ -108,7 +113,6 @@ struct efi_variable {
__u32 Attributes;
} __attribute__((packed));
-
struct efivar_entry {
struct efivars *efivars;
struct efi_variable var;
@@ -122,6 +126,9 @@ struct efivar_attribute {
ssize_t (*store)(struct efivar_entry *entry, const char *buf, size_t
count);
};
+static struct efivars __efivars;
+static struct efivar_operations ops;
+
#define PSTORE_EFI_ATTRIBUTES \
(EFI_VARIABLE_NON_VOLATILE | \
EFI_VARIABLE_BOOTSERVICE_ACCESS | \
@@ -618,14 +625,380 @@ static struct kobj_type efivar_ktype = {
.default_attrs = def_attrs,
};
-static struct pstore_info efi_pstore_info;
-
static inline void
efivar_unregister(struct efivar_entry *var)
{
kobject_put(>kobj);
}
+static int efivars_file_open(struct inode *inode, struct file *file)
+{
+ file->private_data = inode->i_private;
+ return 0;
+}
+
+static ssize_t efivars_file_write(struct file *file, const char __user
*userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct efivar_entry *var = file->private_data;
+ struct efivars *efivars;
+ efi_status_t status;
+ void *data;
+ u32 attributes;
+ struct inode *inode = file->f_mapping->host;
+ int datasize = count - sizeof(attributes);
+
+ if (count < sizeof(attributes))
+ return -EINVAL;
+
+ data = kmalloc(datasize, GFP_KERNEL);
+
+ if (!data)
+ return -ENOMEM;
+
+ efivars = var->efivars;
+
+ if (copy_from_user(, userbuf, sizeof(attributes))) {
+ count = -EFAULT;
+ goto out;
+ }
+
+ if (attributes & ~(EFI_VARIABLE_MASK)) {
+ count = -EINVAL;
+ goto out;
+ }
+
+ if (copy_from_user(data, userbuf + sizeof(attributes), datasize)) {
+ count = -EFAULT;
+ goto out;
+ }
+
+ if (validate_var(>var, data, datasize) == false) {
+ count = -EINVAL;
+ goto out;
+ }
+
+ status = efivars->ops->set_variable(var->var.VariableName,
+ >var.VendorGuid,
+ attributes, datasize,
+ data);
+
+ switch (status) {
+ case EFI_SUCCESS:
+ mutex_lock(>i_mutex);
+ i_size_write(inode, count);
+ mutex_unlock(>i_mutex);
+ break;
+ case EFI_INVALID_PARAMETER:
+ count = -EINVAL;
+ break;
+ case EFI_OUT_OF_RESOURCES:
+ count = -ENOSPC;
+ break;
+ case EFI_DEVICE_ERROR:
+ count = -EIO;
+ break;
+ case EFI_WRITE_PROTECTED:
+ count = -EROFS;
+ break;
+ case EFI_SECURITY_VIOLATION:
+ count = -EACCES;
+ break;
+ case EFI_NOT_FOUND:
+ count = -ENOENT;
+ break;
+ default:
+ count = -EINVAL;
+ break;
+ }
+out:
+ kfree(data);
+
+ return count;
+}
+
+static ssize_t efivars_file_read(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+ struct efivar_entry *var = file->private_data;
+ struct efivars *efivars = var->efivars;
+ efi_status_t status;
+ unsigned long datasize = 0;
+ u32 attributes;
+ void *data;
+ ssize_t size;
+
+ status = efivars->ops->get_variable(var->var.VariableName,
+
Re: [PATCH v2 2/3] mm: remain migratetype in freed page
(2012/09/06 14:16), Minchan Kim wrote:
> The page allocator caches the pageblock information in page->private while
> it is in the PCP freelists but this is overwritten with the order of the
> page when freed to the buddy allocator. This patch stores the migratetype
> of the page in the page->index field so that it is available at all times
> when the page remain in free_list.
>
sounds reasonable.
> This patch adds a new call site in __free_pages_ok so it might be
> overhead a bit but it's for high order allocation.
> So I believe damage isn't hurt.
>
> * from v1
>* Fix move_freepages's migratetype - Mel
>* Add more kind explanation in description - Mel
>
> Signed-off-by: Minchan Kim
Hmm, page->index is valid only when the page is the head of buddy chunk ?
Anyway,
Acked-by: KAMEZAWA Hiroyuki
> ---
> include/linux/mm.h |4 ++--
> mm/page_alloc.c|7 +--
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 84d1663f..68f9e8d 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -240,13 +240,13 @@ struct inode;
> /* It's valid only if the page is free path or free_list */
> static inline void set_freepage_migratetype(struct page *page, int
> migratetype)
> {
> - set_page_private(page, migratetype);
> + page->index = migratetype;
> }
>
> /* It's valid only if the page is free path or free_list */
> static inline int get_freepage_migratetype(struct page *page)
> {
> - return page_private(page);
> + return page->index;
> }
>
> /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f5ba236..8531fa3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -723,6 +723,7 @@ static void __free_pages_ok(struct page *page, unsigned
> int order)
> {
> unsigned long flags;
> int wasMlocked = __TestClearPageMlocked(page);
> + int migratetype;
>
> if (!free_pages_prepare(page, order))
> return;
> @@ -731,8 +732,9 @@ static void __free_pages_ok(struct page *page, unsigned
> int order)
> if (unlikely(wasMlocked))
> free_page_mlock(page);
> __count_vm_events(PGFREE, 1 << order);
> - free_one_page(page_zone(page), page, order,
> - get_pageblock_migratetype(page));
> + migratetype = get_pageblock_migratetype(page);
> + set_freepage_migratetype(page, migratetype);
> + free_one_page(page_zone(page), page, order, migratetype);
> local_irq_restore(flags);
> }
>
> @@ -952,6 +954,7 @@ static int move_freepages(struct zone *zone,
> order = page_order(page);
> list_move(>lru,
> >free_area[order].free_list[migratetype]);
> + set_freepage_migratetype(page, migratetype);
> page += 1 << order;
> pages_moved += 1 << order;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] use get_page_migratetype instead of page_private
(2012/09/06 14:16), Minchan Kim wrote: > page allocator uses set_page_private and page_private for handling > migratetype when it frees page. Let's replace them with [set|get] > _freepage_migratetype to make it more clear. > > * from v1 >* Change set_page_migratetype with set_freepage_migratetype >* Add comment on set_freepage_migratetype > > Signed-off-by: Minchan Kim seems good to me. Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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:
On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: > > Sound fixes for 3.6-rc5 > > There are nothing scaring, contains only small fixes for HD-audio and > USB-audio: > - EPSS regression fix and GPIO fix for HD-audio IDT codecs > - A series of USB-audio regression fixes that are found since 3.5 kernel > > > Daniel Mack (4): > ALSA: snd-usb: Fix URB cancellation at stream start > ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as "C-Media USB Headphone Set". -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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:
On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: Sound fixes for 3.6-rc5 There are nothing scaring, contains only small fixes for HD-audio and USB-audio: - EPSS regression fix and GPIO fix for HD-audio IDT codecs - A series of USB-audio regression fixes that are found since 3.5 kernel Daniel Mack (4): ALSA: snd-usb: Fix URB cancellation at stream start ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as C-Media USB Headphone Set. -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] use get_page_migratetype instead of page_private
(2012/09/06 14:16), Minchan Kim wrote: page allocator uses set_page_private and page_private for handling migratetype when it frees page. Let's replace them with [set|get] _freepage_migratetype to make it more clear. * from v1 * Change set_page_migratetype with set_freepage_migratetype * Add comment on set_freepage_migratetype Signed-off-by: Minchan Kim minc...@kernel.org seems good to me. Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mm: remain migratetype in freed page
(2012/09/06 14:16), Minchan Kim wrote:
The page allocator caches the pageblock information in page-private while
it is in the PCP freelists but this is overwritten with the order of the
page when freed to the buddy allocator. This patch stores the migratetype
of the page in the page-index field so that it is available at all times
when the page remain in free_list.
sounds reasonable.
This patch adds a new call site in __free_pages_ok so it might be
overhead a bit but it's for high order allocation.
So I believe damage isn't hurt.
* from v1
* Fix move_freepages's migratetype - Mel
* Add more kind explanation in description - Mel
Signed-off-by: Minchan Kim minc...@kernel.org
Hmm, page-index is valid only when the page is the head of buddy chunk ?
Anyway,
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
include/linux/mm.h |4 ++--
mm/page_alloc.c|7 +--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 84d1663f..68f9e8d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -240,13 +240,13 @@ struct inode;
/* It's valid only if the page is free path or free_list */
static inline void set_freepage_migratetype(struct page *page, int
migratetype)
{
- set_page_private(page, migratetype);
+ page-index = migratetype;
}
/* It's valid only if the page is free path or free_list */
static inline int get_freepage_migratetype(struct page *page)
{
- return page_private(page);
+ return page-index;
}
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f5ba236..8531fa3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -723,6 +723,7 @@ static void __free_pages_ok(struct page *page, unsigned
int order)
{
unsigned long flags;
int wasMlocked = __TestClearPageMlocked(page);
+ int migratetype;
if (!free_pages_prepare(page, order))
return;
@@ -731,8 +732,9 @@ static void __free_pages_ok(struct page *page, unsigned
int order)
if (unlikely(wasMlocked))
free_page_mlock(page);
__count_vm_events(PGFREE, 1 order);
- free_one_page(page_zone(page), page, order,
- get_pageblock_migratetype(page));
+ migratetype = get_pageblock_migratetype(page);
+ set_freepage_migratetype(page, migratetype);
+ free_one_page(page_zone(page), page, order, migratetype);
local_irq_restore(flags);
}
@@ -952,6 +954,7 @@ static int move_freepages(struct zone *zone,
order = page_order(page);
list_move(page-lru,
zone-free_area[order].free_list[migratetype]);
+ set_freepage_migratetype(page, migratetype);
page += 1 order;
pages_moved += 1 order;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v2] efi: Add support for a UEFI variable filesystem
From: Matthew Garrett m...@redhat.com
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI specification,
but was removed before any full releases. Since variables can now be
larger than a single page, sysfs isn't the best interface for this. So,
instead, let's add a filesystem. Variables can be read, written and
created, with the first 4 bytes of each variable representing its UEFI
attributes. The create() method doesn't actually commit to flash since
zero-length variables can't exist per-spec.
Updates from Jeremy Kerr jeremy.k...@canonical.com.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Jeremy Kerr jeremy.k...@canonical.com
---
v2: Add check for 4-byte writes
---
drivers/firmware/efivars.c | 384 -
include/linux/efi.h|5
2 files changed, 383 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 47408e8..1e1aad0 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -80,6 +80,10 @@
#include linux/slab.h
#include linux/pstore.h
+#include linux/fs.h
+#include linux/ramfs.h
+#include linux/pagemap.h
+
#include asm/uaccess.h
#define EFIVARS_VERSION 0.08
@@ -91,6 +95,7 @@ MODULE_LICENSE(GPL);
MODULE_VERSION(EFIVARS_VERSION);
#define DUMP_NAME_LEN 52
+#define GUID_LEN 37
/*
* The maximum size of VariableName + Data = 1024
@@ -108,7 +113,6 @@ struct efi_variable {
__u32 Attributes;
} __attribute__((packed));
-
struct efivar_entry {
struct efivars *efivars;
struct efi_variable var;
@@ -122,6 +126,9 @@ struct efivar_attribute {
ssize_t (*store)(struct efivar_entry *entry, const char *buf, size_t
count);
};
+static struct efivars __efivars;
+static struct efivar_operations ops;
+
#define PSTORE_EFI_ATTRIBUTES \
(EFI_VARIABLE_NON_VOLATILE | \
EFI_VARIABLE_BOOTSERVICE_ACCESS | \
@@ -618,14 +625,380 @@ static struct kobj_type efivar_ktype = {
.default_attrs = def_attrs,
};
-static struct pstore_info efi_pstore_info;
-
static inline void
efivar_unregister(struct efivar_entry *var)
{
kobject_put(var-kobj);
}
+static int efivars_file_open(struct inode *inode, struct file *file)
+{
+ file-private_data = inode-i_private;
+ return 0;
+}
+
+static ssize_t efivars_file_write(struct file *file, const char __user
*userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct efivar_entry *var = file-private_data;
+ struct efivars *efivars;
+ efi_status_t status;
+ void *data;
+ u32 attributes;
+ struct inode *inode = file-f_mapping-host;
+ int datasize = count - sizeof(attributes);
+
+ if (count sizeof(attributes))
+ return -EINVAL;
+
+ data = kmalloc(datasize, GFP_KERNEL);
+
+ if (!data)
+ return -ENOMEM;
+
+ efivars = var-efivars;
+
+ if (copy_from_user(attributes, userbuf, sizeof(attributes))) {
+ count = -EFAULT;
+ goto out;
+ }
+
+ if (attributes ~(EFI_VARIABLE_MASK)) {
+ count = -EINVAL;
+ goto out;
+ }
+
+ if (copy_from_user(data, userbuf + sizeof(attributes), datasize)) {
+ count = -EFAULT;
+ goto out;
+ }
+
+ if (validate_var(var-var, data, datasize) == false) {
+ count = -EINVAL;
+ goto out;
+ }
+
+ status = efivars-ops-set_variable(var-var.VariableName,
+ var-var.VendorGuid,
+ attributes, datasize,
+ data);
+
+ switch (status) {
+ case EFI_SUCCESS:
+ mutex_lock(inode-i_mutex);
+ i_size_write(inode, count);
+ mutex_unlock(inode-i_mutex);
+ break;
+ case EFI_INVALID_PARAMETER:
+ count = -EINVAL;
+ break;
+ case EFI_OUT_OF_RESOURCES:
+ count = -ENOSPC;
+ break;
+ case EFI_DEVICE_ERROR:
+ count = -EIO;
+ break;
+ case EFI_WRITE_PROTECTED:
+ count = -EROFS;
+ break;
+ case EFI_SECURITY_VIOLATION:
+ count = -EACCES;
+ break;
+ case EFI_NOT_FOUND:
+ count = -ENOENT;
+ break;
+ default:
+ count = -EINVAL;
+ break;
+ }
+out:
+ kfree(data);
+
+ return count;
+}
+
+static ssize_t efivars_file_read(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+ struct efivar_entry *var = file-private_data;
+ struct efivars *efivars = var-efivars;
+ efi_status_t status;
+ unsigned long datasize = 0;
+
Re: [PATCH v2 3/3] memory-hotplug: bug fix race between isolation and allocation
(2012/09/06 14:16), Minchan Kim wrote:
Like below, memory-hotplug makes race between page-isolation
and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
CPU A CPU B
start_isolate_page_range
set_migratetype_isolate
spin_lock_irqsave(zone-lock)
free_hot_cold_page(Page A)
/* without zone-lock */
migratetype = get_pageblock_migratetype(Page A);
/*
* Page could be moved into MIGRATE_MOVABLE
* of per_cpu_pages
*/
list_add_tail(page-lru,
pcp-lists[migratetype]);
set_pageblock_isolate
move_freepages_block
drain_all_pages
/* Page A could be in MIGRATE_MOVABLE of
free_list. */
check_pages_isolated
__test_page_isolated_in_pageblock
/*
* We can't catch freed page which
* is free_list[MIGRATE_MOVABLE]
*/
if (PageBuddy(page A))
pfn += 1 page_order(page A);
/* So, Page A could be allocated */
__offline_isolated_pages
/*
* BUG_ON hit or offline page
* which is used by someone
*/
BUG_ON(!PageBuddy(page A));
This patch checks page's migratetype in freelist in
__test_page_isolated_in_pageblock.
So now __test_page_isolated_in_pageblock can check the page caused by above
race and
can fail of memory offlining.
Signed-off-by: Minchan Kim minc...@kernel.org
I agree this fix.
Maybe we (fujitsu) should revisit these logics around and make it cleaner
Anyway, thank you!
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/page_isolation.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 87a7929..7ba7405 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -193,8 +193,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
unsigned long end_pfn)
continue;
}
page = pfn_to_page(pfn);
- if (PageBuddy(page))
+ if (PageBuddy(page)) {
+ if (get_freepage_migratetype(page) != MIGRATE_ISOLATE)
+ break;
pfn += 1 page_order(page);
+ }
else if (page_count(page) == 0
get_freepage_migratetype(page) == MIGRATE_ISOLATE)
pfn += 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] Linux kernel contribution count script
From: Namhyung Kim namhyung@lge.com
$ ./contrib-count.sh
Usage: ./contrib-count.sh Name [ Year ]
$ ./contrib-count.sh Namhyung
Signed-off: 125
Reviewed: 3
Acked: 1
Tested: 0
$ ./contrib-count.sh Minchan 2012
Signed-off: 20
Reviewed: 32
Acked: 10
Tested: 1
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
contrib-count.sh | 27 +++
1 file changed, 27 insertions(+)
create mode 100755 contrib-count.sh
diff --git a/contrib-count.sh b/contrib-count.sh
new file mode 100755
index ..4d246db5735d
--- /dev/null
+++ b/contrib-count.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# Linux kernel contiribution counter.
+# It actually can be used on any git-managed projects.
+#
+
+if [ $# -eq 0 ]; then
+echo Usage: $0 Name [ Year ]
+exit 1
+fi
+
+NAME=$1
+
+# defaults to current year in format
+YEAR=$(date +%Y)
+
+if [ $# -ge 2 ]; then
+YEAR=$2
+fi
+
+for TAG in Signed-off Reviewed Acked Tested;
+do
+echo -n $TAG:
+git log --grep=$TAG-by: $NAME --since $YEAR-01-01 --until
$YEAR-12-31 origin/master | \
+ git shortlog -sn | \
+ awk 'BEGIN { count = 0; } { count += $1; } END { print count; }'
+done
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the spi-mb tree with the mmc tree
On 09/05/2012 06:15 AM, Stephen Rothwell wrote: Hi Mark, Today's linux-next merge of the spi-mb tree got a conflict in drivers/mmc/host/mxs-mmc.c between commit fc108d24d3a6 (mmc: mxs-mmc: fix deadlock caused by recursion loop) from the mmc tree and commit 829c1bf40b92 (mmc: spi: Pull out parts shared between MMC and SPI) from the spi-mb tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Reviewed and tested. Looks good. Lauri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 4/5] fat: eliminate orphaned inode number allocation
2012/9/5 OGAWA Hirofumi hirof...@mail.parknet.co.jp: Namjae Jeon linkinj...@gmail.com writes: 2012/9/5, OGAWA Hirofumi hirof...@mail.parknet.co.jp: OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Namjae Jeon linkinj...@gmail.com writes: From: Namjae Jeon namjae.j...@samsung.com Maintain a list of inode(i_pos) numbers of orphaned inodes (i.e the inodes that have been unlinked but still having open file descriptors).At file/directory creation time, skip using such i_pos values.Removal of the i_pos from the list is done during inode eviction. What happens if the directory (has busy entries) was completely removed? Hi OGAWA. There are 2 cases: 1. The cluster can be used as a data cluster of a file - In which case we can write normally into it. 2. The cluster can be allocated to a new directory. In this case, the busy i_pos locations can not be used to create new entries until the correspnding inodes are evicted. In the (2) case, it has problem. Directory must not have de-name[0] == 0 in middle of entires. 0 means the end of directory. Good point! I will fix it on next version of patches. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Linux kernel contribution count script
Ooops, Please forget about this. It's intended for an internal use only :-/ Sorry for the noise. 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: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO
Il 05/09/2012 22:18, Ric Wheeler ha scritto: Hi Paolo, Both of these commands are destructive. WRITE_SAME (if done without the discard bits set) can also take a very long time to be destructive and tie up the storage. FORMAT_UNIT has the same characteristics and yet it is allowed (btw, I don't think WRITE SAME slowness is limited to the case where a real write is requested; discarding can be just as slow). Also, the two new commands are anyway restricted to programs that have write access to the disk. If you have read-only access, you won't be able to issue any destructive command (there is one exception, START STOP UNIT is allowed even with read-only capability and is somewhat destructive). Honestly, the only reason why these two commands weren't included, is that the current whitelist is heavily tailored towards CD/DVD burning. I think that restricting them to CAP_SYS_RAWIO seems reasonable - better to vet and give the appropriate apps the needed capability than to widely open up the safety check? CAP_SYS_RAWIO is so wide in its scope, that anything that requires it is insecure. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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:
On 06.09.2012 08:02, Markus Trippelsdorf wrote: On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: Sound fixes for 3.6-rc5 There are nothing scaring, contains only small fixes for HD-audio and USB-audio: - EPSS regression fix and GPIO fix for HD-audio IDT codecs - A series of USB-audio regression fixes that are found since 3.5 kernel Daniel Mack (4): ALSA: snd-usb: Fix URB cancellation at stream start ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as C-Media USB Headphone Set. And you didn't you see these lines with 3.4? 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/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/exclude_super_stripes
The memory allocation failure is BUG_ON in add_excluded_extent (following
the code path) and btrfs_rmap_block. No need to BUG_ON -ENOMEM inside
exclude_super_stripes itself.
Its return value is always 0, and useless for its callers. Set it as void
instead 0-returned.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ba58024..95492cc 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -234,39 +234,33 @@ static void free_excluded_extents(struct btrfs_root *root,
start, end, EXTENT_UPTODATE, GFP_NOFS);
}
-static int exclude_super_stripes(struct btrfs_root *root,
+static void exclude_super_stripes(struct btrfs_root *root,
struct btrfs_block_group_cache *cache)
{
u64 bytenr;
u64 *logical;
int stripe_len;
- int i, nr, ret;
+ int i, nr;
if (cache-key.objectid BTRFS_SUPER_INFO_OFFSET) {
stripe_len = BTRFS_SUPER_INFO_OFFSET - cache-key.objectid;
cache-bytes_super += stripe_len;
- ret = add_excluded_extent(root, cache-key.objectid,
- stripe_len);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, cache-key.objectid, stripe_len);
}
for (i = 0; i BTRFS_SUPER_MIRROR_MAX; i++) {
bytenr = btrfs_sb_offset(i);
- ret = btrfs_rmap_block(root-fs_info-mapping_tree,
- cache-key.objectid, bytenr,
- 0, logical, nr, stripe_len);
- BUG_ON(ret); /* -ENOMEM */
+ btrfs_rmap_block(root-fs_info-mapping_tree,
+cache-key.objectid, bytenr,
+0, logical, nr, stripe_len);
while (nr--) {
cache-bytes_super += stripe_len;
- ret = add_excluded_extent(root, logical[nr],
- stripe_len);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, logical[nr], stripe_len);
}
kfree(logical);
}
- return 0;
}
static struct btrfs_caching_control *
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/btrfs_alloc_logged_file_extent
The memory allocation failure is BUG_ON in add_excluded_extent
(following the code path). No need to BUG_ON -ENOMEM inside
btrfs_alloc_logged_file_extent.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 95492cc..9b9a6fa 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6207,8 +6207,7 @@ int btrfs_alloc_logged_file_extent(struct
btrfs_trans_handle *trans,
mutex_lock(caching_ctl-mutex);
if (start = caching_ctl-progress) {
- ret = add_excluded_extent(root, start, num_bytes);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, start, num_bytes);
} else if (start + num_bytes = caching_ctl-progress) {
ret = btrfs_remove_free_space(block_group,
start, num_bytes);
@@ -6222,8 +6221,7 @@ int btrfs_alloc_logged_file_extent(struct
btrfs_trans_handle *trans,
start = caching_ctl-progress;
num_bytes = ins-objectid + ins-offset -
caching_ctl-progress;
- ret = add_excluded_extent(root, start, num_bytes);
- BUG_ON(ret); /* -ENOMEM */
+ add_excluded_extent(root, start, num_bytes);
}
mutex_unlock(caching_ctl-mutex);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH 3/3] btrfs: set extent-tree.c/add_excluded_extent as void
The memory allocation failure will be catched in set_extent_bits.
Always return 0 is useless for its callers.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 9b9a6fa..3a295ff 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -209,7 +209,7 @@ block_group_cache_tree_search(struct btrfs_fs_info *info,
u64 bytenr,
return ret;
}
-static int add_excluded_extent(struct btrfs_root *root,
+static void add_excluded_extent(struct btrfs_root *root,
u64 start, u64 num_bytes)
{
u64 end = start + num_bytes - 1;
@@ -217,7 +217,6 @@ static int add_excluded_extent(struct btrfs_root *root,
start, end, EXTENT_UPTODATE, GFP_NOFS);
set_extent_bits(root-fs_info-freed_extents[1],
start, end, EXTENT_UPTODATE, GFP_NOFS);
- return 0;
}
static void free_excluded_extents(struct btrfs_root *root,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [mcelog] Start using the new sysfs tunables location
On 09/06/2012 12:39 AM, Tony Luck wrote: On Wed, Sep 5, 2012 at 11:47 AM, Andi Kleen a...@firstfloor.org wrote: On Wed, Sep 05, 2012 at 04:02:37PM +0530, Naveen N. Rao wrote: All the current mce tunables are now available under /sys/devices/system/machinecheck. Start using this new location, but fall back to the older per-cpu location so that we continue working with older kernels. Who did that change in the kernel? That breaks Linus rule that the kernel should not break userland. Kernel needs to fix that. The change is still under discussion. Stage one is to add the new global pathnames in addition to keeping the old per-cpu ones. Also fix all utilities (just mcelog(8) as far as we know) to prefer the new paths. After some time[1] ... delete the old paths. This is allowable under Linus' modified edict that you can change ABI if nobody complains. If we wait long enough that the new mcelog is widely deployed, then nobody should complain. -Tony [1] several years - not just a kernel release or two. Tony, Thanks for clarifying. I should have mentioned in the patch description that this is indeed subject to the original patch making it into the kernel. On a related topic. I recently noticed that we don't have an entry for machinecheck in Documentation/ABI/. Should we add an entry in there? We could perhaps add the existing entries under obsolete/ and the new location under testing/? - Naveen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
On 2012.09.06 at 08:33 +0200, Daniel Mack wrote: On 06.09.2012 08:02, Markus Trippelsdorf wrote: On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: Sound fixes for 3.6-rc5 There are nothing scaring, contains only small fixes for HD-audio and USB-audio: - EPSS regression fix and GPIO fix for HD-audio IDT codecs - A series of USB-audio regression fixes that are found since 3.5 kernel Daniel Mack (4): ALSA: snd-usb: Fix URB cancellation at stream start ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as C-Media USB Headphone Set. And you didn't you see these lines with 3.4? No. -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/5] fat: allocate persistent inode numbers
2012/9/5 OGAWA Hirofumi hirof...@mail.parknet.co.jp: Namjae Jeon linkinj...@gmail.com writes: In this long discusstion about the FAT acceptance over NFS, our belief is still that the objective should be to reduce errors as much as possible and then if there are certain scenarios - at least that could be highlighted as a limitation in Documentation instead of completely discarding the usage of FAT over NFS. So how about puttting rename scenario as a limitation ? In ideal scenario how many times this is going to happen ? My understanding of your patches is to introduce the silent corruption bug by getting wrong location via ino on some cases, instead of ESTALE. And make surprise to userland by change ino. Why is it safe to change ino? If you are saying to remove the changing ino on rename, how handle the case of collision? Yes, agreed this would lead to collision. So, If we are choosing 'i_pos' as inode number, We need to have a mechanism to avoid this 'i_pos' being reused. We can have one thing over here. As a part of avoidance for such scenarios - We can return EBUSY for this rename operation. i.e., If the inode is being referenced then in such cases it makes sense to return EBUSY over NFS and forcus on the large part of the solution which is making FAT stable. Let me know your opinion. Thanks OGAWA. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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:
At Thu, 06 Sep 2012 08:33:30 +0200, Daniel Mack wrote: On 06.09.2012 08:02, Markus Trippelsdorf wrote: On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: Sound fixes for 3.6-rc5 There are nothing scaring, contains only small fixes for HD-audio and USB-audio: - EPSS regression fix and GPIO fix for HD-audio IDT codecs - A series of USB-audio regression fixes that are found since 3.5 kernel Daniel Mack (4): ALSA: snd-usb: Fix URB cancellation at stream start ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as C-Media USB Headphone Set. And you didn't you see these lines with 3.4? Maybe the difference of start condition? Markus, does the patch below fix anything? Takashi --- diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index fd5e982..0ff9f1a 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -556,7 +556,7 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs-hwptr_done = 0; subs-transfer_done = 0; subs-last_delay = 0; - subs-last_frame_number = 0; + subs-last_frame_number = snd_usb_pcm_delay(subs, runtime-rate); runtime-delay = 0; /* for playback, submit the URBs now; otherwise, the first hwptr_done -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86/mce: Pack boolean MCE flags into a structure
On 09/06/2012 12:26 AM, Tony Luck wrote: On Wed, Sep 5, 2012 at 3:22 AM, Naveen N. Rao naveen.n@linux.vnet.ibm.com wrote: Many MCE flags are boolean in nature, but are declared as integers currently. We can pack these into a bitfield to save some space. Before this patch: size arch/x86/kernel/cpu/mcheck/mce.o text data bss dec hex filename 18946 4930 776 24652604c arch/x86/kernel/cpu/mcheck/mce.o After: size arch/x86/kernel/cpu/mcheck/mce.o text data bss dec hex filename 19335 4890 776 2500161a9 arch/x86/kernel/cpu/mcheck/mce.o So we do indeed see data reduced by 40 bytes. But text is up by 389. This seems to be because you have another change, not described in the commit log, buried in part 2 to add get_dont_log_ce(), set_dont_log_ce() etc. Compiler version: gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) I know I'm contradicting the feedback you got from Borislav here, but is this code churn really worth it to save 40 bytes? I don't think so. Hmm.. I think I agree. I don't see a good way to get rid of the individual getters and setters without adding some more code churn. I guess using boolean would be better. Boris? Thanks, Naveen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm: pwm-tiecap: Disable APWM mode after configure
Hi Thierry,
If you do not have any comments, could you please accept it?
Thanks
Avinash
On Thu, Aug 23, 2012 at 12:29:46, Philip, Avinash wrote:
APWM mode is enabled while configuring PWM device. This was done to
handle shadow immediate mode update of period and compare registers.
However, leaving it enabled after configuring will cause APWM output on
PWM pin even before enabling PWM device.
Fix the same by disabling APWM mode after configuring if PWM device is
not running.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 0b66d0f... 4b66889... Mdrivers/pwm/pwm-tiecap.c
drivers/pwm/pwm-tiecap.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 0b66d0f..4b66889 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -100,6 +100,13 @@ static int ecap_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
writel(period_cycles, pc-mmio_base + CAP3);
}
+ if (!test_bit(PWMF_ENABLED, pwm-flags)) {
+ reg_val = readw(pc-mmio_base + ECCTL2);
+ /* Disable APWM mode to put APWM output Low */
+ reg_val = ~ECCTL2_APWM_MODE;
+ writew(reg_val, pc-mmio_base + ECCTL2);
+ }
+
pm_runtime_put_sync(pc-chip.dev);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re:
On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote:
At Thu, 06 Sep 2012 08:33:30 +0200,
Daniel Mack wrote:
On 06.09.2012 08:02, Markus Trippelsdorf wrote:
On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
Sound fixes for 3.6-rc5
There are nothing scaring, contains only small fixes for HD-audio and
USB-audio:
- EPSS regression fix and GPIO fix for HD-audio IDT codecs
- A series of USB-audio regression fixes that are found since 3.5 kernel
Daniel Mack (4):
ALSA: snd-usb: Fix URB cancellation at stream start
ALSA: snd-usb: restore delay information
The commit fbcfbf5f above causes the following lines to be printed
whenever I start a new song:
Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
patch (fbcfbf5f) brings back now.
delay: estimated 0, actual 352
delay: estimated 353, actual 705
(44.1 * 8 = 352.8)
This happens with an USB-DAC that identifies itself as C-Media USB
Headphone Set.
And you didn't you see these lines with 3.4?
Maybe the difference of start condition?
Markus, does the patch below fix anything?
Unfortunately no.
However reverting the following fixes the problem:
commit 245baf983cc39524cce39c24d01b276e6e653c9e
Author: Daniel Mack zon...@gmail.com
Date: Thu Aug 30 18:52:30 2012 +0200
ALSA: snd-usb: fix calls to next_packet_size
--
Markus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] pwm i.MX: add devicetree support
On Wed, Sep 05, 2012 at 11:42:34PM +0200, Benoît Thébaudeau wrote: Since this is supposed to remove platform-based support, why don't you also remove the PWM stuff from arch/arm/plat-mxc and arch/arm/mach-imx/devices-imx*.h? Simple answer: I was too lazy yesterday. I will include it in the next round. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] serial_core: fix sizeof(pointer)
On 09/06/2012 04:27 AM, Fengguang Wu wrote:
sizeof when applied to a pointer typed expression gives the
size of the pointer.
Generated by: scripts/coccinelle/misc/noderef.cocci
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
cocci-output-38612-39d907-serial_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -640,7 +640,7 @@ static void uart_get_info(struct tty_por
{
struct uart_port *uport = state-uart_port;
- memset(retinfo, 0, sizeof(retinfo));
+ memset(retinfo, 0, sizeof(*retinfo));
Hmm, what tree is this against? I have:
memset(tmp, 0, sizeof(tmp));
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, 6 Sep 2012 11:18:09 +0530 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown ne...@suse.de wrote:
On Mon, 3 Sep 2012 22:59:06 -0700 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
After thinking bit more on this, the problem seems to be coming
mainly because the gpio device is runtime suspended bit early than
it should be. Similar issue seen with i2c driver as well. The i2c issue
was discussed with Rafael at LPC last week. The idea is to move
the pm_runtime_enable/disable() calls entirely up to the
_late/_early stage of device suspend/resume.
Will update this thread once I have further update.
This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all
the _late callbacks have been called.
I, too, spoke to Rafael about this in San Diego. He seemed to agree with me
that the interrupt needs to be masked in the -suspend callback. any later
is too late.
Thanks for information about your discussion. Will wait for the patch then.
Regards
santosh
I already sent a patch - that is what started this thread :-)
I include it below.
You said The patch doesn't seems to be correct but didn't expand on why.
Do you still think it is not correct? I wouldn't be surprised if there is
some case that it doesn't handle quite right, but it seems right to me.
Thanks,
NeilBrown
From: NeilBrown ne...@suse.de
Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4fbc208..fdbad70 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,6 +57,7 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
+ u32 suspend_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(bank-lock, flags);
if (enable)
- bank-context.wake_en |= gpio_bit;
+ bank-suspend_wakeup |= gpio_bit;
else
- bank-context.wake_en = ~gpio_bit;
+ bank-suspend_wakeup = ~gpio_bit;
- __raw_writel(bank-context.wake_en, bank-base + bank-regs-wkup_en);
+ if (!bank-loses_context)
+ __raw_writel(bank-suspend_wakeup, bank-base +
bank-regs-wkup_en);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM_RUNTIME)
+
+#if defined(CONFIG_PM_SLEEP)
+static int omap_gpio_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
+
+ if (!bank-mod_usage || !bank-loses_context)
+ return 0;
+
+ if (!bank-regs-wkup_en || !bank-context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ return 0;
+}
+
+static int omap_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned
Re: [RFC PATCH V6 10/19] memory-hotplug: add memory_block_release
On 2012-8-3 15:49, we...@cn.fujitsu.com wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
When calling remove_memory_block(), the function shows following message at
device_release().
Device 'memory528' does not have a release() function, it is broken and must
be fixed.
I found this warning too when doing memory-hotplug,
why not send as a bug fix patch?
The same as [RFC PATCH V6 18/19] memory-hotplug: add node_device_release
remove_memory_block() calls kfree(mem). I think it shouled be called from
device_release(). So the patch implements memory_block_release()
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
drivers/base/memory.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 038be73..1cd3ef3 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -109,6 +109,15 @@ bool is_memblk_offline(unsigned long start, unsigned
long size)
}
EXPORT_SYMBOL(is_memblk_offline);
+#define to_memory_block(device) container_of(device, struct memory_block,
dev)
+
+static void release_memory_block(struct device *dev)
+{
+ struct memory_block *mem = to_memory_block(dev);
+
+ kfree(mem);
+}
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -119,6 +128,7 @@ int register_memory(struct memory_block *memory)
memory-dev.bus = memory_subsys;
memory-dev.id = memory-start_section_nr / sections_per_block;
+ memory-dev.release = release_memory_block;
error = device_register(memory-dev);
return error;
@@ -674,7 +684,6 @@ int remove_memory_block(unsigned long node_id, struct
mem_section *section,
mem_remove_simple_file(mem, phys_device);
mem_remove_simple_file(mem, removable);
unregister_memory(mem);
- kfree(mem);
} else
kobject_put(mem-dev.kobj);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] serial_core: fix sizeof(pointer)
On Thu, Sep 06, 2012 at 08:59:00AM +0200, Jiri Slaby wrote:
On 09/06/2012 04:27 AM, Fengguang Wu wrote:
sizeof when applied to a pointer typed expression gives the
size of the pointer.
Generated by: scripts/coccinelle/misc/noderef.cocci
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
cocci-output-38612-39d907-serial_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -640,7 +640,7 @@ static void uart_get_info(struct tty_por
{
struct uart_port *uport = state-uart_port;
- memset(retinfo, 0, sizeof(retinfo));
+ memset(retinfo, 0, sizeof(*retinfo));
Hmm, what tree is this against? I have:
It's the tty:tty-next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
memset(tmp, 0, sizeof(tmp));
Oh I didn't know it's a new bug introduced by commit
commit 7ba2e769825fef035a943ed74d90379245508764
Author: Alan Cox a...@linux.intel.com
AuthorDate: Tue Sep 4 16:34:45 2012 +0100
Commit: Greg Kroah-Hartman gre...@linuxfoundation.org
CommitDate: Wed Sep 5 13:11:03 2012 -0700
tty: Split the serial_core helpers for setserial into two
Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: snd-usb: delay: estimated 0, actual 352
On 06.09.2012 08:53, Markus Trippelsdorf wrote: On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote: At Thu, 06 Sep 2012 08:33:30 +0200, Daniel Mack wrote: On 06.09.2012 08:02, Markus Trippelsdorf wrote: On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote: Sound fixes for 3.6-rc5 There are nothing scaring, contains only small fixes for HD-audio and USB-audio: - EPSS regression fix and GPIO fix for HD-audio IDT codecs - A series of USB-audio regression fixes that are found since 3.5 kernel Daniel Mack (4): ALSA: snd-usb: Fix URB cancellation at stream start ALSA: snd-usb: restore delay information The commit fbcfbf5f above causes the following lines to be printed whenever I start a new song: Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this patch (fbcfbf5f) brings back now. delay: estimated 0, actual 352 delay: estimated 353, actual 705 (44.1 * 8 = 352.8) This happens with an USB-DAC that identifies itself as C-Media USB Headphone Set. And you didn't you see these lines with 3.4? Maybe the difference of start condition? Markus, does the patch below fix anything? Unfortunately no. However reverting the following fixes the problem: commit 245baf983cc39524cce39c24d01b276e6e653c9e Author: Daniel Mack zon...@gmail.com Date: Thu Aug 30 18:52:30 2012 +0200 ALSA: snd-usb: fix calls to next_packet_size No, this one certainly fixes a problem and does the right thing by restoring the original code. If you wouldn't state that you didn't see the same effect with 3.4(!), before the refactoring done in 3.5, I would believe the device is simply slightly off in its feedback rate and the tighter delay code complains about it while compensating, just as it did before. Are there any more than these two lines? And is audio working at all? Is it distorted in any way? Pierre-Louis, could you check whether I did the right thing when I ported over your delay bits to the new endpoint logic? Maybe I'm missing something here, but I currently don't see it. Thanks, 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/
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
In file included from drivers/atm/fore200e.c:70:0:
drivers/atm/fore200e.h:263:3: error: redefinition of typedef 'opcode_t' with
different type
arch/powerpc/include/asm/probes.h:25:13: note: previous declaration of
'opcode_t' was here
Caused by commit 7118e7e648e0 (powerpc: Consolidate {k,u}probe
definitions) from the powerpc tree.
I have reverted that commit (and the two following:
41ab5266c362powerpc: Add trap_nr to thread_struct
8b7b80b9ebb4powerpc: Uprobes port to powerpc)
for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQQY9eQRlrC.pgp
Description: PGP signature
Re: [PATCH 7/8] pwm i.MX: fix clock lookup
On Wed, Sep 05, 2012 at 11:48:51PM +0200, Benoît Thébaudeau wrote:
- c = clk_get_rate(imx-clk);
+ c = clk_get_rate(imx-clk_per);
c = c * period_ns;
do_div(c, 10);
period_cycles = c;
@@ -160,8 +161,15 @@ static int imx_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
{
struct imx_chip *imx = to_imx_chip(chip);
+ int ret;
- return imx-config(chip, pwm, duty_ns, period_ns);
+ clk_prepare_enable(imx-clk_ipg);
Why don't you test the return value like in imx_pwm_enable()?
Will do next time.
Sascha
I have reviewed the whole series. Apart from the comments I made, it looks
good
to me.
Thanks. I can take this as a reviewed-by, right?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
