Re: [PATCH v5 0/4] Fix Win8 backlight issue
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote: > If we are to use a Kconfig option, why don't we use one instead of rather than > in addition to a command line option? Say, we have > CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like > the previous version of the Aaron's patchset (the one without > video.use_native_backlight)? Doesn't this mean user will have to rebuild distro kernel in order to test behavior? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 12/15] KVM: MMU: allow locklessly access shadow page table out of vcpu thread
On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote: > On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote: > > > n_max_mmu_pages is not a suitable limit to throttle freeing of pages via > > > RCU (its too large). If the free memory watermarks are smaller than > > > n_max_mmu_pages for all guests, OOM is possible. > > > > > Ah, yes. I am not saying n_max_mmu_pages will throttle RCU, just saying > > that slab size will be bound, so hopefully shrinker will touch it > > rarely. > > > > > > > > and, in addition, page released to slab is immediately > > > > > > available for allocation, no need to wait for grace period. > > > > > > > > > > See SLAB_DESTROY_BY_RCU comment at include/linux/slab.h. > > > > > > > > > This comment is exactly what I was referring to in the code you quoted. > > > > Do > > > > you see anything problematic in what comment describes? > > > > > > "This delays freeing the SLAB page by a grace period, it does _NOT_ > > > delay object freeing." The page is not available for allocation. > > By "page" I mean "spt page" which is a slab object. So "spt page" > > AKA slab object will be available fo allocation immediately. > > The object is reusable within that SLAB cache only, not the > entire system (therefore it does not prevent OOM condition). > Since object is allocatable immediately by shadow paging code the number of SLAB objects is bound by n_max_mmu_pages. If there is no enough memory for n_max_mmu_pages OOM condition can happen anyway since shadow paging code will usually have exactly n_max_mmu_pages allocated. > OK, perhaps it is useful to use SLAB_DESTROY_BY_RCU, but throttling > is still necessary, as described in the RCU documentation. > I do not see what should be throttled if we use SLAB_DESTROY_BY_RCU. RCU comes into play only when SLAB cache is shrunk and it happens far from kvm code. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On Saturday 12 of October 2013 04:28:51 Tomasz Figa wrote:
> [Fixing incorrent mail addresses and dropping the old DT ML.]
>
> On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
> > Hi Naveen,
> >
> > On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> > > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> > > therefore is completely independent of the cpu frequency.
> > > Thus, registering for a CPU freq notifier is very wasteful.
> > >
> > > This patch modifes the code such that, i2c bus registers to
> > > cpu_freq_transition only for non Exynos SoCs.
> > >
> > > This change should save a bunch of cpufreq transitions calls
> > > which does not apply to exynos SoCs.
> >
> > The idea is fine, although...
> >
> > > Signed-off-by: Naveen Krishna Chatradhi
> > > ---
> > > drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> > > b/drivers/i2c/busses/i2c-s3c2410.c
> > > index cab1c91..d062fa7 100644
> > > --- a/drivers/i2c/busses/i2c-s3c2410.c
> > > +++ b/drivers/i2c/busses/i2c-s3c2410.c
> > > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> > > struct s3c2410_platform_i2c *pdata;
> > > int gpios[2];
> > > struct pinctrl *pctrl;
> > > -#ifdef CONFIG_CPU_FREQ
> > > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
> >
> > ...this is not a good coding practice, especially when already having
> > multiplatform kernels in sight.
> >
> > The best way would be to check on which SoC we are running at runtime,
> > but since this might need changing a lot of code, then at least I would
> > change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
> > compiled in when S3C24XX support is not enabled and if it's enabled then
> > the notifier will be registered as a safe fallback that will run correctly
> > on all platforms.
Actually you can simply check for CONFIG_CPU_FREQ_S3C24XX here.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] add maintainers for low-power Intel MID platform
From: David Cohen Hi, I'd like to add official maintainers for Intel MID platform on Linux kernel. Current Intel MID support on upstream is outdated, but we've immediate plans to update the code. The 2 persons this patch is adding as maintainers are also part of Intel's internal team responsible for it. Please, consider to apply it. This patch is meant to be merged just after renaming Moorestown code to generic up-to-date Intel MID name on this patch set: http://marc.info/?l=linux-kernel=138154934101936=2 Br, David Cohen --- David Cohen (1): MAINTAINERS: INTEL MID SOC: add maintainers MAINTAINERS | 9 + 1 file changed, 9 insertions(+) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] MAINTAINERS: INTEL MID SOC: add maintainers
This patch adds official maintainers for low-power Intel MID platform. Signed-off-by: David Cohen Cc: Kuppuswamy Sathyanarayanan --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7534a80..8ef9e65 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7570,6 +7570,15 @@ F: arch/x86/platform/sfi/ F: drivers/sfi/ F: include/linux/sfi*.h +LOW-POWER INTEL MID SOC SUPPORT +M: David Cohen +M: Kuppuswamy Sathyanarayanan +S: Supported +F: arch/x86/platform/intel-mid/ +F: arch/x86/pci/intel_mid_pci.c +F: arch/x86/include/asm/intel-mid.h +F: arch/x86/include/asm/intel_mid*.h + SIMTEC EB110ATX (Chalice CATS) P: Ben Dooks P: Vincent Sanders -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: w90x900: remove deprecated IRQF_DISABLED
2013/10/12 Michael Opdenacker :
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Acked-by: Wan zongshun
Thanks!
> ---
> arch/arm/mach-w90x900/time.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
> index 30fbca8..9230d37 100644
> --- a/arch/arm/mach-w90x900/time.c
> +++ b/arch/arm/mach-w90x900/time.c
> @@ -111,7 +111,7 @@ static irqreturn_t nuc900_timer0_interrupt(int irq, void
> *dev_id)
>
> static struct irqaction nuc900_timer0_irq = {
> .name = "nuc900-timer0",
> - .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> .handler= nuc900_timer0_interrupt,
> };
>
> --
> 1.8.1.2
>
--
Wan ZongShun.
www.mcuos.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/
[PATCH v2] writeback: fix negative bdi max pause
Toralf runs trinity on UML/i386.
After some time it hangs and the last message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large.
More than 10 pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied > 20);
BUG_ON(pages_dirtied > 10); <-
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the max_pause
calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and
the min_t(long, ...) check failed to protect it falling under 0. Fix
all of them by using "unsigned long" throughout the function.
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Cc:
Cc: Jan Kara
Cc: Richard Weinberger
Cc: Geert Uytterhoeven
Signed-off-by: Fengguang Wu
---
mm/page-writeback.c | 10 +-
mm/readahead.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
Changes since v1: Add CC list.
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f0c895..241a746 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1104,11 +1104,11 @@ static unsigned long dirty_poll_interval(unsigned long
dirty,
return 1;
}
-static long bdi_max_pause(struct backing_dev_info *bdi,
- unsigned long bdi_dirty)
+static unsigned long bdi_max_pause(struct backing_dev_info *bdi,
+ unsigned long bdi_dirty)
{
- long bw = bdi->avg_write_bandwidth;
- long t;
+ unsigned long bw = bdi->avg_write_bandwidth;
+ unsigned long t;
/*
* Limit pause time for small memory systems. If sleeping for too long
@@ -1120,7 +1120,7 @@ static long bdi_max_pause(struct backing_dev_info *bdi,
t = bdi_dirty / (1 + bw / roundup_pow_of_two(1 + HZ / 8));
t++;
- return min_t(long, t, MAX_PAUSE);
+ return min_t(unsigned long, t, MAX_PAUSE);
}
static long bdi_min_pause(struct backing_dev_info *bdi,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/bus/omap_l3_noc.c | 4 ++--
drivers/bus/omap_l3_smx.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae..6ada27a 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -187,7 +187,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-dbg-irq", l3);
+ 0, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
@@ -197,7 +197,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-app-irq", l3);
+ 0, "l3-app-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..769d64c 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -238,8 +238,7 @@ static int __init omap3_l3_probe(struct platform_device
*pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-debug-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-debug-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request debug irq\n");
goto err1;
@@ -247,8 +246,7 @@ static int __init omap3_l3_probe(struct platform_device
*pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
- "l3-app-irq", l3);
+ IRQF_TRIGGER_RISING, "l3-app-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request app irq\n");
goto err2;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mg_disk: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/mg_disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
index 77a60be..7bc363f 100644
--- a/drivers/block/mg_disk.c
+++ b/drivers/block/mg_disk.c
@@ -936,7 +936,7 @@ static int mg_probe(struct platform_device *plat_dev)
goto probe_err_3b;
}
err = request_irq(host->irq, mg_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING,
MG_DEV_NAME, host);
if (err) {
printk(KERN_ERR "%s:%d fail (request_irq err=%d)\n",
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: hd: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
This also removes a related comment which is obsolete too.
Signed-off-by: Michael Opdenacker
---
drivers/block/hd.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/block/hd.c b/drivers/block/hd.c
index bf397bf..e16985f 100644
--- a/drivers/block/hd.c
+++ b/drivers/block/hd.c
@@ -694,16 +694,6 @@ static const struct block_device_operations hd_fops = {
.getgeo = hd_getgeo,
};
-/*
- * This is the hard disk IRQ description. The IRQF_DISABLED in sa_flags
- * means we run the IRQ-handler with interrupts disabled: this is bad for
- * interrupt latency, but anything else has led to problems on some
- * machines.
- *
- * We enable interrupts in some of the routines after making sure it's
- * safe.
- */
-
static int __init hd_init(void)
{
int drive;
@@ -761,7 +751,7 @@ static int __init hd_init(void)
p->cyl, p->head, p->sect);
}
- if (request_irq(HD_IRQ, hd_interrupt, IRQF_DISABLED, "hd", NULL)) {
+ if (request_irq(HD_IRQ, hd_interrupt, 0, "hd", NULL)) {
printk("hd: unable to get IRQ%d for the hard disk driver\n",
HD_IRQ);
goto out1;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NVMe: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/nvme-core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index da52092..c6699af 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -1134,11 +1134,10 @@ static int queue_request_irq(struct nvme_dev *dev,
struct nvme_queue *nvmeq,
{
if (use_threaded_interrupts)
return request_threaded_irq(dev->entry[nvmeq->cq_vector].vector,
- nvme_irq_check, nvme_irq,
- IRQF_DISABLED | IRQF_SHARED,
+ nvme_irq_check, nvme_irq, IRQF_SHARED,
name, nvmeq);
return request_irq(dev->entry[nvmeq->cq_vector].vector, nvme_irq,
- IRQF_DISABLED | IRQF_SHARED, name, nvmeq);
+ IRQF_SHARED, name, nvmeq);
}
static void nvme_init_queue(struct nvme_queue *nvmeq, u16 qid)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rsxx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/rsxx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 6e85e21..93ecb78 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -890,7 +890,7 @@ static int rsxx_pci_probe(struct pci_dev *dev,
"Failed to enable MSI\n");
}
- st = request_irq(dev->irq, rsxx_isr, IRQF_DISABLED | IRQF_SHARED,
+ st = request_irq(dev->irq, rsxx_isr, IRQF_SHARED,
DRIVER_NAME, card);
if (st) {
dev_err(CARD_TO_DEV(card),
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpqarray: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/block/cpqarray.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
index 2b94403..370721e 100644
--- a/drivers/block/cpqarray.c
+++ b/drivers/block/cpqarray.c
@@ -406,7 +406,7 @@ static int cpqarray_register_ctlr(int i, struct pci_dev
*pdev)
}
hba[i]->access.set_intr_mask(hba[i], 0);
if (request_irq(hba[i]->intr, do_ida_intr,
- IRQF_DISABLED|IRQF_SHARED, hba[i]->devname, hba[i]))
+ IRQF_SHARED, hba[i]->devname, hba[i]))
{
printk(KERN_ERR "cpqarray: Unable to get irq %d for %s\n",
hba[i]->intr, hba[i]->devname);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] support new huawei devices in option.c
Dear Greg:
>-Original Message-
>From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
>Sent: Saturday, October 12, 2013 4:58 AM
>To: Fangxiaozhi (Franko)
>Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Heyongquan;
>Wangyuhua; Yili (Neil)
>Subject: Re: [PATCH 1/1] support new huawei devices in option.c
>
>On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
>> 1. Add new supporting declarations to option.c, to support Huawei new
>devices with new bInterfaceSubClass value.
>> Signed-off-by: fangxiaozhi
>
>In the future, can you use an email client that doesn't turn tabs into spaces,
>so I
>don't have to edit the patch by hand?
>
>Also:
>
>> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
>0x01)
>> + }, { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
>> + 0x02) },
>
>
>
>That's a huge list of ids, is there any way we can just mark all of these as
>used by
>the device in an easier manner?
-OK, I will. Thank you very much.
>
>I'll take this for now, but I have a feeling that this list is just going to
>get worse
>over time, right?
-Yes, I think so. So we are discussing about this internally, and maybe try
to optimize it later.
>
>thanks,
>
>greg k-h
Best Regards,
Franko Fang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] score: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/score/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/score/kernel/time.c b/arch/score/kernel/time.c
index f0a43aff..24770cd 100644
--- a/arch/score/kernel/time.c
+++ b/arch/score/kernel/time.c
@@ -41,7 +41,7 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction timer_irq = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.name = "timer",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m32r: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/m32r/kernel/time.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/m32r/kernel/time.c b/arch/m32r/kernel/time.c
index 1a15f81..093f276 100644
--- a/arch/m32r/kernel/time.c
+++ b/arch/m32r/kernel/time.c
@@ -134,7 +134,6 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction irq0 = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED,
.name = "MFT2",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/avr32/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/avr32/kernel/time.c b/arch/avr32/kernel/time.c
index 12f828a..d0f771b 100644
--- a/arch/avr32/kernel/time.c
+++ b/arch/avr32/kernel/time.c
@@ -59,7 +59,7 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
static struct irqaction timer_irqaction = {
.handler= timer_interrupt,
/* Oprofile uses the same irq as the timer, so allow it to be shared */
- .flags = IRQF_TIMER | IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_TIMER | IRQF_SHARED,
.name = "avr32_comparator",
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: misc: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
from miscellaneous code in mach-xxx and plat-xxx
This flag is a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ebsa110/core.c | 2 +-
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-ks8695/time.c | 2 +-
arch/arm/mach-netx/time.c| 2 +-
arch/arm/mach-rpc/dma.c | 2 +-
arch/arm/mach-rpc/time.c | 1 -
arch/arm/mach-sa1100/time.c | 2 +-
arch/arm/mach-shark/core.c | 2 +-
arch/arm/mach-u300/timer.c | 2 +-
arch/arm/plat-iop/time.c | 2 +-
arch/arm/plat-pxa/dma.c | 2 +-
11 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-ebsa110/core.c b/arch/arm/mach-ebsa110/core.c
index 68ac934..8254e71 100644
--- a/arch/arm/mach-ebsa110/core.c
+++ b/arch/arm/mach-ebsa110/core.c
@@ -206,7 +206,7 @@ ebsa110_timer_interrupt(int irq, void *dev_id)
static struct irqaction ebsa110_timer_irq = {
.name = "EBSA110 Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ebsa110_timer_interrupt,
};
diff --git a/arch/arm/mach-integrator/integrator_ap.c
b/arch/arm/mach-integrator/integrator_ap.c
index d9e95e6..b4b7683 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -368,7 +368,7 @@ static struct clock_event_device integrator_clockevent = {
static struct irqaction integrator_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= integrator_timer_interrupt,
.dev_id = _clockevent,
};
diff --git a/arch/arm/mach-ks8695/time.c b/arch/arm/mach-ks8695/time.c
index 426c976..a197874 100644
--- a/arch/arm/mach-ks8695/time.c
+++ b/arch/arm/mach-ks8695/time.c
@@ -122,7 +122,7 @@ static irqreturn_t ks8695_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ks8695_timer_irq = {
.name = "ks8695_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler= ks8695_timer_interrupt,
};
diff --git a/arch/arm/mach-netx/time.c b/arch/arm/mach-netx/time.c
index 6df42e6..3177c7a 100644
--- a/arch/arm/mach-netx/time.c
+++ b/arch/arm/mach-netx/time.c
@@ -99,7 +99,7 @@ netx_timer_interrupt(int irq, void *dev_id)
static struct irqaction netx_timer_irq = {
.name = "NetX Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= netx_timer_interrupt,
};
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index 85883b2..6d3517d 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -141,7 +141,7 @@ static int iomd_request_dma(unsigned int chan, dma_t *dma)
struct iomd_dma *idma = container_of(dma, struct iomd_dma, dma);
return request_irq(idma->irq, iomd_dma_handle,
- IRQF_DISABLED, idma->dma.device_id, idma);
+ 0, idma->dma.device_id, idma);
}
static void iomd_free_dma(unsigned int chan, dma_t *dma)
diff --git a/arch/arm/mach-rpc/time.c b/arch/arm/mach-rpc/time.c
index 9a6def1..9a51588 100644
--- a/arch/arm/mach-rpc/time.c
+++ b/arch/arm/mach-rpc/time.c
@@ -75,7 +75,6 @@ ioc_timer_interrupt(int irq, void *dev_id)
static struct irqaction ioc_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED,
.handler= ioc_timer_interrupt
};
diff --git a/arch/arm/mach-sa1100/time.c b/arch/arm/mach-sa1100/time.c
index 713c86c..a98fded 100644
--- a/arch/arm/mach-sa1100/time.c
+++ b/arch/arm/mach-sa1100/time.c
@@ -112,7 +112,7 @@ static struct clock_event_device ckevt_sa1100_osmr0 = {
static struct irqaction sa1100_timer_irq = {
.name = "ost0",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= sa1100_ost0_interrupt,
.dev_id = _sa1100_osmr0,
};
diff --git a/arch/arm/mach-shark/core.c b/arch/arm/mach-shark/core.c
index 1d32c5e..78942cd 100644
--- a/arch/arm/mach-shark/core.c
+++ b/arch/arm/mach-shark/core.c
@@ -114,7 +114,7 @@ shark_timer_interrupt(int irq, void *dev_id)
static struct irqaction shark_timer_irq = {
.name = "Shark Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= shark_timer_interrupt,
};
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index b5db207..494d978
[PATCH] arm: plat-orion: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/plat-orion/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion/time.c b/arch/arm/plat-orion/time.c
index 9d2b2ac..df671d0 100644
--- a/arch/arm/plat-orion/time.c
+++ b/arch/arm/plat-orion/time.c
@@ -174,7 +174,7 @@ static irqreturn_t orion_timer_interrupt(int irq, void
*dev_id)
static struct irqaction orion_timer_irq = {
.name = "orion_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler= orion_timer_interrupt
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: w90x900: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-w90x900/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
index 30fbca8..9230d37 100644
--- a/arch/arm/mach-w90x900/time.c
+++ b/arch/arm/mach-w90x900/time.c
@@ -111,7 +111,7 @@ static irqreturn_t nuc900_timer0_interrupt(int irq, void
*dev_id)
static struct irqaction nuc900_timer0_irq = {
.name = "nuc900-timer0",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= nuc900_timer0_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/10] intel_mid: Renamed *mrst* to *intel_mid*
From: Kuppuswamy Sathyanarayanan
mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.
This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.
To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
Documentation/kernel-parameters.txt| 6 +-
arch/x86/include/asm/intel-mid.h | 26 ++---
arch/x86/include/asm/setup.h | 4 +-
arch/x86/include/uapi/asm/bootparam.h | 2 +-
arch/x86/kernel/apb_timer.c| 8 +-
arch/x86/kernel/head32.c | 4 +-
arch/x86/kernel/rtc.c | 2 +-
arch/x86/pci/intel_mid_pci.c | 12 +--
.../platform/intel-mid/early_printk_intel_mid.c| 2 +-
arch/x86/platform/intel-mid/intel-mid.c| 109 ++---
arch/x86/platform/intel-mid/intel_mid_vrtc.c | 8 +-
drivers/platform/x86/intel_scu_ipc.c | 2 +-
drivers/watchdog/intel_scu_watchdog.c | 2 +-
13 files changed, 93 insertions(+), 94 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index fcbb736..dfaeb0c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3471,11 +3471,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
- x86_mrst_timer= [X86-32,APBT]
- Choose timer option for x86 Moorestown MID platform.
+ x86_intel_mid_timer= [X86-32,APBT]
+ Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
- x86_mrst_timer=apbt_only | lapic_and_apbt
+ x86_intel_mid_timer=apbt_only | lapic_and_apbt
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
#include
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
* we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
* identified via MSRs.
*/
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
- MRST_CPU_CHIP_PENWELL = 2,
+ INTEL_MID_CPU_CHIP_PENWELL = 2,
};
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
#ifdef CONFIG_X86_INTEL_MID
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
{
- return __mrst_cpu_chip;
+ return __intel_mid_cpu_chip;
}
#else /* !CONFIG_X86_INTEL_MID */
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
#endif /* !CONFIG_X86_INTEL_MID */
-enum mrst_timer_options {
- MRST_TIMER_DEFAULT,
- MRST_TIMER_APBT_ONLY,
- MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+ INTEL_MID_TIMER_DEFAULT,
+ INTEL_MID_TIMER_APBT_ONLY,
+ INTEL_MID_TIMER_LAPIC_APBT,
};
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
/*
* Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
#define MRST_VRTC_MAP_SZ (1024)
/*#define MRST_VRTC_PGOFFSET (0xc00) */
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3475554..59bcf4e 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -51,9 +51,9 @@ extern void i386_reserve_resources(void);
extern void setup_default_timer_irq(void);
#ifdef CONFIG_X86_INTEL_MID
-extern void x86_mrst_early_setup(void);
+extern void x86_intel_mid_early_setup(void);
#else
-static inline void x86_mrst_early_setup(void) { }
+static inline void x86_intel_mid_early_setup(void) { }
#endif
#ifdef CONFIG_X86_INTEL_CE
diff --git
[PATCH v3 00/10] rework arch/x86/platform/[mrst => intel-mid]
This patch set does initial rework from arch/x86/platform/mrst to
arch/x86/platform/intel-mid.
These changes are necessary to update the obsolete Intel Atom Moorestown code
to support the newer Atom processors of this family (called 'intel-mid').
Kuppuswamy Sathyanarayanan (10):
mrst: Fixed printk/pr_* related issues
mrst: Fixed indentation issues
mrst: Fixed checkpatch warnings
intel_mid: Renamed *mrst* to *intel_mid*
intel_mid: Renamed *mrst* to *intel_mid*
intel_mid: Refactored sfi_parse_devs() function
intel_mid: Added custom device_handler support
intel_mid: Added custom handler for ipc devices
intel_mid: Moved board related code to a new file
intel_mid: Moved SFI related code to intel_mid_sfi.c
Documentation/kernel-parameters.txt|6 +-
arch/x86/include/asm/{mrst.h => intel-mid.h} | 62 +-
.../include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} |4 +-
arch/x86/include/asm/setup.h |4 +-
arch/x86/include/uapi/asm/bootparam.h |2 +-
arch/x86/kernel/apb_timer.c| 10 +-
arch/x86/kernel/early_printk.c |2 +-
arch/x86/kernel/head32.c |4 +-
arch/x86/kernel/rtc.c |4 +-
arch/x86/pci/Makefile |2 +-
arch/x86/pci/{mrst.c => intel_mid_pci.c} | 14 +-
arch/x86/platform/Makefile |2 +-
arch/x86/platform/intel-mid/Makefile |9 +
arch/x86/platform/intel-mid/board.c| 109 ++
arch/x86/platform/intel-mid/device_libs/Makefile | 21 +
.../intel-mid/device_libs/platform_emc1403.c | 33 +
.../intel-mid/device_libs/platform_emc1403.h | 16 +
.../intel-mid/device_libs/platform_gpio_keys.c | 82 ++
.../intel-mid/device_libs/platform_gpio_keys.h | 16 +
.../platform/intel-mid/device_libs/platform_ipc.c | 59 ++
.../platform/intel-mid/device_libs/platform_ipc.h | 17 +
.../intel-mid/device_libs/platform_lis331.c| 32 +
.../intel-mid/device_libs/platform_lis331.h| 16 +
.../intel-mid/device_libs/platform_max3111.c | 28 +
.../intel-mid/device_libs/platform_max3111.h | 16 +
.../intel-mid/device_libs/platform_max7315.c | 62 ++
.../intel-mid/device_libs/platform_max7315.h | 19 +
.../intel-mid/device_libs/platform_mpu3050.c | 28 +
.../intel-mid/device_libs/platform_mpu3050.h | 16 +
.../platform/intel-mid/device_libs/platform_msic.c | 87 ++
.../platform/intel-mid/device_libs/platform_msic.h | 19 +
.../intel-mid/device_libs/platform_msic_audio.c| 36 +
.../intel-mid/device_libs/platform_msic_audio.h| 16 +
.../intel-mid/device_libs/platform_msic_battery.c | 26 +
.../intel-mid/device_libs/platform_msic_battery.h | 17 +
.../intel-mid/device_libs/platform_msic_gpio.c | 37 +
.../intel-mid/device_libs/platform_msic_gpio.h | 16 +
.../intel-mid/device_libs/platform_msic_ocd.c | 39 +
.../intel-mid/device_libs/platform_msic_ocd.h | 16 +
.../device_libs/platform_msic_power_btn.c | 25 +
.../device_libs/platform_msic_power_btn.h | 17 +
.../intel-mid/device_libs/platform_msic_thermal.c | 26 +
.../intel-mid/device_libs/platform_msic_thermal.h | 17 +
.../intel-mid/device_libs/platform_pmic_gpio.c | 36 +
.../intel-mid/device_libs/platform_pmic_gpio.h | 16 +
.../intel-mid/device_libs/platform_tc35876x.c | 29 +
.../intel-mid/device_libs/platform_tc35876x.h | 16 +
.../intel-mid/device_libs/platform_tca6416.c | 45 +
.../intel-mid/device_libs/platform_tca6416.h | 20 +
.../early_printk_intel_mid.c} | 11 +-
arch/x86/platform/intel-mid/intel-mid.c| 213
arch/x86/platform/intel-mid/intel_mid_sfi.c| 485 +
.../{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c}| 19 +-
arch/x86/platform/intel-mid/intel_mid_weak_decls.h | 15 +
arch/x86/platform/mrst/Makefile|3 -
arch/x86/platform/mrst/mrst.c | 1052
drivers/gpu/drm/gma500/mdfld_dsi_output.h |2 +-
drivers/gpu/drm/gma500/oaktrail_device.c |2 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c |2 +-
drivers/platform/x86/intel_scu_ipc.c |4 +-
drivers/rtc/rtc-mrst.c |4 +-
drivers/watchdog/intel_scu_watchdog.c |4 +-
62 files changed, 1944 insertions(+), 1123 deletions(-)
rename arch/x86/include/asm/{mrst.h => intel-mid.h} (50%)
rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (96%)
create mode 100644 arch/x86/platform/intel-mid/Makefile
create mode 100644 arch/x86/platform/intel-mid/board.c
create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
[PATCH v3 02/10] mrst: Fixed indentation issues
From: Kuppuswamy Sathyanarayanan
Fixed indentation issues reported by checkpatch script in
mrst related files.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/mrst/early_printk_mrst.c | 3 ++-
arch/x86/platform/mrst/mrst.c | 24 +---
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
}
/* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str,
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+ unsigned n)
{
int i;
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index b9aeb54..235a742 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
- pr_debug("hint taken for timer %d irq %d\n",\
+ pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return _mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
/* tc35876x DSI-LVDS bridge chip and panel platform data */
static void *tc35876x_platform_data(void *data)
{
- static struct tc35876x_platform_data pdata;
+ static struct tc35876x_platform_data pdata;
- /* gpio pins set to -1 will not be used by the driver */
- pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
- pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
- pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+ /* gpio pins set to -1 will not be used by the driver */
+ pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+ pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+ pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
- return
+ return
}
static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
static void __init intel_scu_device_register(struct platform_device *pdev)
{
- if(ipc_next_dev == MAX_IPCDEVS)
+ if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info
*spi_info)
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
- !strncmp(dev->name, spi_info->modalias,
SFI_NAME_LEN)) {
+ !strncmp(dev->name, spi_info->modalias,
+ SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
- pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
gb[i].gpio);
+ pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+ gb[i].gpio);
if (gb[i].gpio == -1)
continue;
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/10] intel_mid: Added custom device_handler support
From: Kuppuswamy Sathyanarayanan
This patch provides a means to add custom handler for
SFI devices. If you set device_handler as NULL in
device_id table standard SFI device handler will be used.
If its not NULL custom handler will be called.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/intel-mid.c | 75 ++---
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index f9c4be8..65c7bca 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -396,6 +396,9 @@ struct devs_id {
u8 type;
u8 delay;
void *(*get_platform_data)(void *info);
+ /* Custom handler for devices */
+ void (*device_handler)(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
};
/* the offset for the mapping of global gpio pin to irq */
@@ -690,27 +693,29 @@ static void *tc35876x_platform_data(void *data)
}
static const struct devs_id __initconst device_ids[] = {
- {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data},
- {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
- {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data},
- {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data},
- {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data},
- {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data},
- {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data},
+ {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+ {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
+ {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
+ {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+ {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+ {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
/* MSIC subdevices */
- {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data},
- {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
- {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data},
- {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data},
- {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data},
- {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data},
-
+ {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data,
+ NULL},
+ {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+ {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+ {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data,
+ NULL},
+ {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+ {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data,
+ NULL},
{},
};
@@ -965,20 +970,24 @@ static int __init sfi_parse_devs(struct sfi_table_header
*table)
if ((dev == NULL) || (dev->get_platform_data == NULL))
continue;
- switch (pentry->type) {
- case SFI_DEV_TYPE_IPC:
- sfi_handle_ipc_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_SPI:
- sfi_handle_spi_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_I2C:
- sfi_handle_i2c_dev(pentry, dev);
- break;
- case SFI_DEV_TYPE_UART:
- case SFI_DEV_TYPE_HSI:
- default:
- break;
+ if (dev->device_handler) {
+ dev->device_handler(pentry, dev);
+ } else {
+ switch (pentry->type) {
+ case SFI_DEV_TYPE_IPC:
+ sfi_handle_ipc_dev(pentry, dev);
+ break;
+ case SFI_DEV_TYPE_SPI:
+ sfi_handle_spi_dev(pentry, dev);
+ break;
+ case
[PATCH v3 01/10] mrst: Fixed printk/pr_* related issues
From: Kuppuswamy Sathyanarayanan
Fixed printk and pr_* related issues in mrst related files.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/mrst/early_printk_mrst.c | 2 +-
arch/x86/platform/mrst/mrst.c | 2 +-
arch/x86/platform/mrst/vrtc.c | 5 ++---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/platform/mrst/early_printk_mrst.c
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
if (!timeout)
- pr_warning("MRST earlycon: timed out\n");
+ pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
}
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 3ca5957..b9aeb54 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
- pr_warning("X86 MRST timer option %s not recognised"
+ pr_warn("X86 MRST timer option %s not recognised"
" use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index 5e355b1..ca4f7d9 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ void vrtc_get_time(struct timespec *now)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
- printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+ pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
now->tv_sec = mktime(year, mon, mday, hour, min, sec);
@@ -109,8 +109,7 @@ int vrtc_set_mmss(const struct timespec *now)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(_lock, flags);
} else {
- printk(KERN_ERR
- "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+ pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, now->tv_sec);
retval = -EINVAL;
}
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: spear: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-spear/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
index d449673..218ba5b 100644
--- a/arch/arm/mach-spear/time.c
+++ b/arch/arm/mach-spear/time.c
@@ -172,7 +172,7 @@ static irqreturn_t spear_timer_interrupt(int irq, void
*dev_id)
static struct irqaction spear_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = spear_timer_interrupt
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/10] intel_mid: Added custom handler for ipc devices
From: Kuppuswamy Sathyanarayanan
Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/intel-mid.h| 15 ++
arch/x86/platform/intel-mid/intel-mid.c | 87 +
2 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
/*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+ char name[SFI_NAME_LEN + 1];
+ u8 type;
+ u8 delay;
+ void *(*get_platform_data)(void *info);
+ /* Custom handler for devices */
+ void (*device_handler)(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
+};
+
+/*
* Medfield is the follow-up of Moorestown, it combines two chip solution into
* one. Other than that it also added always-on and constant tsc and lapic
* timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 65c7bca..3a210d9 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
EXPORT_SYMBOL_GPL(sfi_mrtc_array);
int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev);
static void intel_mid_power_off(void)
{
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
}
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
- char name[SFI_NAME_LEN + 1];
- u8 type;
- u8 delay;
- void *(*get_platform_data)(void *info);
- /* Custom handler for devices */
- void (*device_handler)(struct sfi_device_table_entry *pentry,
- struct devs_id *dev);
-};
-
/* the offset for the mapping of global gpio pin to irq */
#define INTEL_MID_IRQ_OFFSET 0x100
@@ -695,27 +682,32 @@ static void *tc35876x_platform_data(void *data)
static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
- {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+ {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+ _device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
- {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+ {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data,
+ _device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
/* MSIC subdevices */
{"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data,
- NULL},
- {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
- {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+ _device_handler},
+ {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+ _device_handler},
+ {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data,
+ _device_handler},
{"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data,
- NULL},
- {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+ _device_handler},
+ {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data,
+ _device_handler},
{"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data,
- NULL},
+ _device_handler},
{},
};
@@ -846,13 +838,6 @@
[PATCH v3 04/10] intel_mid: Renamed *mrst* to *intel_mid*
From: Kuppuswamy Sathyanarayanan
Following files contains code that is common to all intel mid
soc's. So renamed them as below.
mrst/mrst.c -> intel-mid/intel-mid.c
mrst/vrtc.c -> intel-mid/intel_mid_vrtc.c
mrst/early_printk_mrst.c -> intel-mid/intel_mid_vrtc.c
pci/mrst.c -> pci/intel_mid_pci.c
Also, renamed the corresponding header files and made changes
to the driver files that included these header files.
To ensure that there are no functional changes, I have compared
the objdump of renamed files before and after rename and found
that the only difference is file name change.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/{mrst.h => intel-mid.h} | 8
arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}| 4 ++--
arch/x86/kernel/apb_timer.c | 2 +-
arch/x86/kernel/early_printk.c| 2 +-
arch/x86/kernel/rtc.c | 2 +-
arch/x86/pci/Makefile | 2 +-
arch/x86/pci/{mrst.c => intel_mid_pci.c} | 2 +-
arch/x86/platform/Makefile| 2 +-
arch/x86/platform/intel-mid/Makefile | 3 +++
.../early_printk_intel_mid.c} | 4 ++--
arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} | 11 ++-
arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} | 6 +++---
arch/x86/platform/mrst/Makefile | 3 ---
drivers/gpu/drm/gma500/mdfld_dsi_output.h | 2 +-
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c| 2 +-
drivers/platform/x86/intel_scu_ipc.c | 2 +-
drivers/rtc/rtc-mrst.c| 4 ++--
drivers/watchdog/intel_scu_watchdog.c | 2 +-
19 files changed, 33 insertions(+), 32 deletions(-)
rename arch/x86/include/asm/{mrst.h => intel-mid.h} (93%)
rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (99%)
create mode 100644 arch/x86/platform/intel-mid/Makefile
rename arch/x86/platform/{mrst/early_printk_mrst.c =>
intel-mid/early_printk_intel_mid.c} (98%)
rename arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} (99%)
rename arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} (97%)
delete mode 100644 arch/x86/platform/mrst/Makefile
diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/intel-mid.h
similarity index 93%
rename from arch/x86/include/asm/mrst.h
rename to arch/x86/include/asm/intel-mid.h
index fc18bf3..cc79a4f 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -1,5 +1,5 @@
/*
- * mrst.h: Intel Moorestown platform specific setup code
+ * intel-mid.h: Intel MID specific setup code
*
* (C) Copyright 2009 Intel Corporation
*
@@ -8,8 +8,8 @@
* as published by the Free Software Foundation; version 2
* of the License.
*/
-#ifndef _ASM_X86_MRST_H
-#define _ASM_X86_MRST_H
+#ifndef _ASM_X86_INTEL_MID_H
+#define _ASM_X86_INTEL_MID_H
#include
@@ -78,4 +78,4 @@ extern void intel_scu_devices_destroy(void);
extern void mrst_rtc_init(void);
-#endif /* _ASM_X86_MRST_H */
+#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/mrst-vrtc.h
b/arch/x86/include/asm/intel_mid_vrtc.h
similarity index 81%
rename from arch/x86/include/asm/mrst-vrtc.h
rename to arch/x86/include/asm/intel_mid_vrtc.h
index 1e69a75..86ff468 100644
--- a/arch/x86/include/asm/mrst-vrtc.h
+++ b/arch/x86/include/asm/intel_mid_vrtc.h
@@ -1,5 +1,5 @@
-#ifndef _MRST_VRTC_H
-#define _MRST_VRTC_H
+#ifndef _INTEL_MID_VRTC_H
+#define _INTEL_MID_VRTC_H
extern unsigned char vrtc_cmos_read(unsigned char reg);
extern void vrtc_cmos_write(unsigned char val, unsigned char reg);
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..9154836 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -40,7 +40,7 @@
#include
#include
-#include
+#include
#include
#define APBT_CLOCKEVENT_RATING 110
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index d15f575..38ca398 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 0aa2939..a1b52fe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#ifdef CONFIG_X86_32
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index ee0af58..e063eed 100644
---
[PATCH v3 10/10] intel_mid: Moved SFI related code to intel_mid_sfi.c
From: Kuppuswamy Sathyanarayanan
Moved SFI specific parsing/handling code to intel_mid_sfi.c. This will enable
us to reuse our intel-mid code for platforms that supports firmware interfaces
other than SFI (like ACPI).
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/include/asm/intel-mid.h| 1 +
arch/x86/platform/intel-mid/Makefile| 5 +-
arch/x86/platform/intel-mid/intel-mid.c | 450 --
arch/x86/platform/intel-mid/intel_mid_sfi.c | 485
4 files changed, 489 insertions(+), 452 deletions(-)
create mode 100644 arch/x86/platform/intel-mid/intel_mid_sfi.c
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index afc282a..358e0d2 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -18,6 +18,7 @@ extern int intel_mid_pci_init(void);
extern int get_gpio_by_name(const char *name);
extern void intel_scu_device_register(struct platform_device *pdev);
extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
extern int sfi_mrtc_num;
extern struct sfi_rtc_table_entry sfi_mrtc_array[];
diff --git a/arch/x86/platform/intel-mid/Makefile
b/arch/x86/platform/intel-mid/Makefile
index 36323ee..9a6b6c3 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,8 +1,9 @@
obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
obj-$(CONFIG_EARLY_PRINTK_INTEL_MID) += early_printk_intel_mid.o
-
+# SFI specific code
+obj-$(CONFIG_SFI) += intel_mid_sfi.o
# BOARD files
obj-$(CONFIG_X86_INTEL_MID) += board.o
# platform configuration for board devices
-obj-y += device_libs/
\ No newline at end of file
+obj-y += device_libs/
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 0ac2bd6..a08541a 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
#include
#include
-#include
-#include
-#include
#include
#include
@@ -69,17 +59,9 @@
enum intel_mid_timer_options intel_mid_timer_options;
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
enum intel_mid_cpu_type __intel_mid_cpu_chip;
EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
-
static void intel_mid_power_off(void)
{
}
@@ -89,114 +71,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
}
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
- struct sfi_table_simple *sb;
- struct sfi_timer_table_entry *pentry;
- struct mpc_intsrc mp_irq;
- int totallen;
-
- sb = (struct sfi_table_simple *)table;
- if (!sfi_mtimer_num) {
- sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
- struct sfi_timer_table_entry);
- pentry = (struct sfi_timer_table_entry *) sb->pentry;
- totallen = sfi_mtimer_num * sizeof(*pentry);
- memcpy(sfi_mtimer_array, pentry, totallen);
- }
-
- pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
- pentry = sfi_mtimer_array;
- for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
- pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
- " irq = %d\n", totallen, (u32)pentry->phys_addr,
- pentry->freq_hz, pentry->irq);
- if (!pentry->irq)
- continue;
- mp_irq.type = MP_INTSRC;
- mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
- mp_irq.irqflag = 5;
- mp_irq.srcbus = MP_BUS_ISA;
- mp_irq.srcbusirq = pentry->irq; /* IRQ */
- mp_irq.dstapic = MP_APIC_ALL;
- mp_irq.dstirq = pentry->irq;
- mp_save_irq(_irq);
- }
-
- return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
- int i;
- if (hint < sfi_mtimer_num) {
- if (!sfi_mtimer_usage[hint]) {
- pr_debug("hint taken for timer %d irq %d\n",
- hint, sfi_mtimer_array[hint].irq);
- sfi_mtimer_usage[hint] = 1;
- return _mtimer_array[hint];
- }
- }
- /* take the
[PATCH v3 03/10] mrst: Fixed checkpatch warnings
From: Kuppuswamy Sathyanarayanan Fixed checkpatch warnings in mrst related files. Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: David Cohen --- arch/x86/platform/mrst/mrst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c index 235a742..2a45eab 100644 --- a/arch/x86/platform/mrst/mrst.c +++ b/arch/x86/platform/mrst/mrst.c @@ -977,7 +977,7 @@ static int __init sfi_parse_devs(struct sfi_table_header *table) case SFI_DEV_TYPE_UART: case SFI_DEV_TYPE_HSI: default: - ; + break; } } return 0; -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/10] intel_mid: Refactored sfi_parse_devs() function
From: Kuppuswamy Sathyanarayanan
SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/intel-mid.c | 141
1 file changed, 71 insertions(+), 70 deletions(-)
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 742b7bf..f9c4be8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct
platform_device *pdev, int irq)
platform_device_add_resources(pdev, , 1);
}
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
- while (dev->name[0]) {
- if (dev->type == SFI_DEV_TYPE_IPC &&
- !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
- pdata = dev->get_platform_data(entry);
- break;
- }
- dev++;
- }
+ pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+ pentry->name, pentry->irq);
+ pdata = dev->get_platform_data(pentry);
/*
* On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
- pdev = platform_device_alloc(entry->name, 0);
+ pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
- entry->name);
+ pentry->name);
return;
}
- install_irq_resource(pdev, entry->irq);
+ install_irq_resource(pdev, pentry->irq);
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
}
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
+ struct spi_board_info spi_info;
void *pdata = NULL;
- while (dev->name[0]) {
- if (dev->type == SFI_DEV_TYPE_SPI &&
- !strncmp(dev->name, spi_info->modalias,
- SFI_NAME_LEN)) {
- pdata = dev->get_platform_data(spi_info);
- break;
- }
- dev++;
- }
- spi_info->platform_data = pdata;
+ memset(_info, 0, sizeof(spi_info));
+ strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+ spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+ spi_info.bus_num = pentry->host_num;
+ spi_info.chip_select = pentry->addr;
+ spi_info.max_speed_hz = pentry->max_freq;
+ pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+ spi_info.bus_num,
+ spi_info.modalias,
+ spi_info.irq,
+ spi_info.max_speed_hz,
+ spi_info.chip_select);
+
+ pdata = dev->get_platform_data(_info);
+
+ spi_info.platform_data = pdata;
if (dev->delay)
- intel_scu_spi_device_register(spi_info);
+ intel_scu_spi_device_register(_info);
else
- spi_register_board_info(spi_info, 1);
+ spi_register_board_info(_info, 1);
}
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+ struct devs_id *dev)
{
- const struct devs_id *dev = device_ids;
+ struct i2c_board_info i2c_info;
void *pdata = NULL;
+ memset(_info, 0, sizeof(i2c_info));
+ strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+ i2c_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+ i2c_info.addr = pentry->addr;
+ pr_debug("I2C bus = %d, name = %16.16s, irq = 0x%2x, addr = 0x%x\n",
+ pentry->host_num,
+ i2c_info.type,
+ i2c_info.irq,
+ i2c_info.addr);
+ pdata = dev->get_platform_data(_info);
+ i2c_info.platform_data = pdata;
+
+ if (dev->delay)
+
[PATCH] ARM: SAMSUNG: remove IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-s3c24xx/dma.c | 2 +-
arch/arm/mach-s3c24xx/simtec-usb.c | 3 +--
arch/arm/mach-s3c64xx/mach-smartq.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
index 4a65cba..a8dafc1 100644
--- a/arch/arm/mach-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -742,7 +742,7 @@ int s3c2410_dma_request(enum dma_ch channel,
chan->irq_claimed = 1;
local_irq_restore(flags);
- err = request_irq(chan->irq, s3c2410_dma_irq, IRQF_DISABLED,
+ err = request_irq(chan->irq, s3c2410_dma_irq, 0,
client->name, (void *)chan);
local_irq_save(flags);
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c
b/arch/arm/mach-s3c24xx/simtec-usb.c
index 2ed2e32..bb3eac6 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -78,8 +78,7 @@ static void usb_simtec_enableoc(struct s3c2410_hcd_info
*info, int on)
if (on) {
ret = request_irq(BAST_IRQ_USBOC, usb_simtec_ocirq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB Over-current", info);
if (ret != 0) {
printk(KERN_ERR "failed to request usb oc irq\n");
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 86d980b..389cc49 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -106,7 +106,7 @@ static void smartq_usb_host_enableoc(struct
s3c2410_hcd_info *info, int on)
if (on) {
ret = request_irq(gpio_to_irq(S3C64XX_GPL(10)),
- smartq_usb_host_ocirq, IRQF_DISABLED |
+ smartq_usb_host_ocirq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"USB host overcurrent", info);
if (ret != 0)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Hi Stephan,
I haven't had a chance to look at your paper in detail, yet, but a
quick scan has found a huge red flag for me that puts the rest of your
analysis in severe doubt for me.
You say that you got really good results and perfect statistical
entropy on a number of platforms, including on an MIPS embedded
system. You also say that you are harvesting jitter by using
get_cycles() yes?
Well, on the MIPS platform, here is the definition of get_cycles:
static inline cycles_t get_cycles(void)
{
return 0;
}
So if you are getting great entropy results when in effect you
couldn't possibly be harvesting any jitter at all, then something is
really, Really, REALLY wrong with your tests.
One might be that you are just getting great statistical results
because of the whitening step. This is why I have very little faith
in statistical tests of randomness, given that they will return
perfect results for the following "random number generator"
AES_ENCRYPT(i++, NSA_KEY)
Regards,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: mmp: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-mmp/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 7ac41e8..6aacc9b 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -186,7 +186,7 @@ static void __init timer_config(void)
static struct irqaction timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= timer_interrupt,
.dev_id = ,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: fix false return check from "regulator_set_voltage"
On 09/10/2013, Manish Badarkhe wrote:
> Currently, code checks false return value from "regulator_set_voltage"
> to show failure message. Modify the code to check proper return
> value from "regulator_set_voltage".
>
> Signed-off-by: Manish Badarkhe
> ---
> Based on master branch of linux-mainline.
>
> :100644 100644 0fac344... 1537f32... Mdrivers/cpufreq/exynos-cpufreq.c
> drivers/cpufreq/exynos-cpufreq.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 0fac344..1537f32 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -141,7 +141,7 @@ post_notify:
> if ((freqs.new < freqs.old) ||
> ((freqs.new > freqs.old) && safe_arm_volt)) {
> /* down the voltage after frequency change */
> - regulator_set_voltage(arm_regulator, arm_volt,
> + ret = regulator_set_voltage(arm_regulator, arm_volt,
> arm_volt);
> if (ret) {
> pr_err("%s: failed to set cpu voltage to %d\n",
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: LPC32xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-lpc32xx/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-lpc32xx/timer.c b/arch/arm/mach-lpc32xx/timer.c
index 20eab63..4e58372 100644
--- a/arch/arm/mach-lpc32xx/timer.c
+++ b/arch/arm/mach-lpc32xx/timer.c
@@ -90,7 +90,7 @@ static irqreturn_t lpc32xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction lpc32xx_timer_irq = {
.name = "LPC32XX Timer Tick",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= lpc32xx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: IXP4xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ixp4xx/common.c| 2 +-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 3 +--
arch/arm/mach-ixp4xx/fsg-setup.c | 6 ++
arch/arm/mach-ixp4xx/nas100d-setup.c | 3 +--
arch/arm/mach-ixp4xx/nslu2-setup.c | 6 ++
5 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 5327dec..a2b21f6 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -285,7 +285,7 @@ static irqreturn_t ixp4xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ixp4xx_timer_irq = {
.name = "timer1",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ixp4xx_timer_interrupt,
.dev_id = _ixp4xx,
};
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c
b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 63de1b3..053a564 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -253,8 +253,7 @@ static void __init dsmg600_init(void)
pm_power_off = dsmg600_power_off;
if (request_irq(gpio_to_irq(DSMG600_RB_GPIO), _reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "DSM-G600 reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "DSM-G600 reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(DSMG600_RB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/fsg-setup.c b/arch/arm/mach-ixp4xx/fsg-setup.c
index 429966b7..5c4b0c4 100644
--- a/arch/arm/mach-ixp4xx/fsg-setup.c
+++ b/arch/arm/mach-ixp4xx/fsg-setup.c
@@ -208,16 +208,14 @@ static void __init fsg_init(void)
platform_add_devices(fsg_devices, ARRAY_SIZE(fsg_devices));
if (request_irq(gpio_to_irq(FSG_RB_GPIO), _reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "FSG reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "FSG reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(FSG_RB_GPIO));
}
if (request_irq(gpio_to_irq(FSG_SB_GPIO), _power_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "FSG power button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "FSG power button", NULL) < 0) {
printk(KERN_DEBUG "Power Button IRQ %d not available\n",
gpio_to_irq(FSG_SB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c
b/arch/arm/mach-ixp4xx/nas100d-setup.c
index ed667ce..008d792 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -271,8 +271,7 @@ static void __init nas100d_init(void)
pm_power_off = nas100d_power_off;
if (request_irq(gpio_to_irq(NAS100D_RB_GPIO), _reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "NAS100D reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "NAS100D reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(NAS100D_RB_GPIO));
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c
b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 7e55236..01a85e4 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -258,16 +258,14 @@ static void __init nslu2_init(void)
pm_power_off = nslu2_power_off;
if (request_irq(gpio_to_irq(NSLU2_RB_GPIO), _reset_handler,
- IRQF_DISABLED | IRQF_TRIGGER_LOW,
- "NSLU2 reset button", NULL) < 0) {
+ IRQF_TRIGGER_LOW, "NSLU2 reset button", NULL) < 0) {
printk(KERN_DEBUG "Reset Button IRQ %d not available\n",
gpio_to_irq(NSLU2_RB_GPIO));
}
if (request_irq(gpio_to_irq(NSLU2_PB_GPIO), _power_handler,
- IRQF_DISABLED | IRQF_TRIGGER_HIGH,
- "NSLU2 power button", NULL) < 0) {
+ IRQF_TRIGGER_HIGH, "NSLU2 power button", NULL) < 0) {
printk(KERN_DEBUG "Power Button IRQ %d not available\n",
gpio_to_irq(NSLU2_PB_GPIO));
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Question]should we not ignore the masked interrupt in regmap?
Hi, Mark: Sorry to trouble you, I have a question about the interrupt handling of regmap framework; in the regmap_irq_thread(), from the following code, we only handle the unmasked interrupt; 256 data->status_buf[i] &= ~data->mask_buf[i]; but in the following sequence, irq storm will happen; do you think we should do a change here to handle all the interrupt here? thanks very much; 1) interrupt is triggered; 2) a thread disables it(then the mask bit is set); 3) _Then_ the interrupt thread is executed, it _ignore _ and doesn’t handle this interrupt; because the interrupt is not ACKed, the interrupt status is not cleared; 4) in Marvell's PMIC, the interrupt line to SOC is always asserted, then irq storm happens; Yi Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: ep93xx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-ep93xx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 3f12b88..fcc965f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -136,7 +136,7 @@ static irqreturn_t ep93xx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction ep93xx_timer_irq = {
.name = "ep93xx timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= ep93xx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: cns3xxx: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/mach-cns3xxx/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index e38b279..384dc85 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -155,7 +155,7 @@ static irqreturn_t cns3xxx_timer_interrupt(int irq, void
*dev_id)
static struct irqaction cns3xxx_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= cns3xxx_timer_interrupt,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cgroup: fix to break the while loop in cgroup_attach_task() correctly
From: Anjana V Kumar
Both Anjana and Eunki reported a stall in the while_each_thread loop
in cgroup_attach_task().
It's because, when we attach a single thread to a cgroup, if the cgroup
is exiting or is already in that cgroup, we won't break the loop.
If the task is already in the cgroup, the bug can lead to another thread
being attached to the cgroup unexpectedly:
# echo 5207 > tasks
# cat tasks
5207
# echo 5207 > tasks
# cat tasks
5207
5215
What's worse, if the task to be attached isn't the leader of the thread
group, we might never exit the loop, hence cpu stall. Thanks for Oleg's
analysis.
This bug was introduced by commit 081aa458c38ba576bdd4265fc807fa95b48b9e79
("cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()")
Cc: # 3.9+
Reported-by: Eunki Kim
Reported-by: Anjana V Kumar
Signed-off-by: Anjana V Kumar
[ lizf: - fixed the first continue, pointed out by Oleg,
- rewrote changelog. ]
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5629f1..3db1d2e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2002,7 +2002,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
/* @tsk either already exited or can't exit until the end */
if (tsk->flags & PF_EXITING)
- continue;
+ goto next;
/* as per above, nr_threads may decrease, but not increase. */
BUG_ON(i >= group_size);
@@ -2010,7 +2010,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
ent.cgrp = task_cgroup_from_root(tsk, root);
/* nothing to do if this task is already in the cgroup */
if (ent.cgrp == cgrp)
- continue;
+ goto next;
/*
* saying GFP_ATOMIC has no effect here because we did prealloc
* earlier, but it's good form to communicate our expectations.
@@ -2018,7 +2018,7 @@ static int cgroup_attach_task(struct cgroup *cgrp, struct
task_struct *tsk,
retval = flex_array_put(group, i, , GFP_ATOMIC);
BUG_ON(retval != 0);
i++;
-
+next:
if (!threadgroup)
break;
} while_each_thread(leader, tsk);
--
1.8.0.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: [RFC][PATCH 3/7] sched: power: go_faster/slower power driver hints
Hi, Morten
On 10/12/2013 01:19 AM, Morten Rasmussen wrote:
[snip]
>
> @@ -5743,6 +5772,7 @@ static void run_rebalance_domains(struct softirq_action
> *h)
>*/
> nohz_idle_balance(this_cpu, idle);
>
> + inc_cpu_capacity(this_cpu);
Just wondering is this check necessary here? if rq get more tasks during
the balance, enqueue_task() should already do the check each time when
we move_task(), isn't it?
Regards,
Michael Wang
> power_late_callback(this_cpu);
> }
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 907a967..88e7968 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1367,8 +1367,26 @@ static inline u64 irq_time_read(int cpu)
>
> #ifdef CONFIG_SCHED_POWER
> extern void power_late_callback(int cpu);
> +extern int at_max_capacity(int cpu);
> +extern int go_faster(int cpu, int hint);
> +extern int go_slower(int cpu, int hint);
> #else
> static inline void power_late_callback(int cpu)
> {
> }
> +
> +static inline int at_max_capacity(int cpu)
> +{
> + return 1;
> +}
> +
> +static inline int go_faster(int cpu, int hint)
> +{
> + return 0;
> +}
> +
> +static inline int go_slower(int cpu, int hint)
> +{
> + return 0;
> +}
> #endif /* CONFIG_SCHED_POWER */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [ARM] floppy.h: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker --- arch/arm/include/asm/floppy.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/floppy.h b/arch/arm/include/asm/floppy.h index c9f03ec..f488255 100644 --- a/arch/arm/include/asm/floppy.h +++ b/arch/arm/include/asm/floppy.h @@ -25,7 +25,7 @@ #define fd_inb(port) inb((port)) #define fd_request_irq() request_irq(IRQ_FLOPPYDISK,floppy_interrupt,\ - IRQF_DISABLED,"floppy",NULL) + 0,"floppy",NULL) #define fd_free_irq() free_irq(IRQ_FLOPPYDISK,NULL) #define fd_disable_irq() disable_irq(IRQ_FLOPPYDISK) #define fd_enable_irq()enable_irq(IRQ_FLOPPYDISK) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: timer-sp: remove deprecated IRQF_DISABLED
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/arm/common/timer-sp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index e901d0f..ce922d0 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -175,7 +175,7 @@ static struct clock_event_device sp804_clockevent = {
static struct irqaction sp804_timer_irq = {
.name = "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler= sp804_timer_interrupt,
.dev_id = _clockevent,
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
On Fri, Oct 11, 2013 at 3:13 PM, Minchan Kim wrote:
> On Thu, Sep 26, 2013 at 11:42:17AM +0800, Weijie Yang wrote:
>> On Tue, Sep 24, 2013 at 9:03 AM, Minchan Kim wrote:
>> > On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote:
>> > >
>> > > Modify:
>> > > - check the refcount in fail path, free memory if it is not referenced.
>> >
>> > Hmm, I don't like this because zswap refcount routine is already mess for
>> > me.
>> > I'm not sure why it was designed from the beginning. I hope we should fix
>> > it first.
>> >
>> > 1. zswap_rb_serach could include zswap_entry_get semantic if it founds a
>> > entry from
>> >the tree. Of course, we should ranme it as find_get_zswap_entry like
>> > find_get_page.
>> > 2. zswap_entry_put could hide resource free function like zswap_free_entry
>> > so that
>> >all of caller can use it easily following pattern.
>> >
>> > find_get_zswap_entry
>> > ...
>> > ...
>> > zswap_entry_put
>> >
>> > Of course, zswap_entry_put have to check the entry is in the tree or not
>> > so if someone already removes it from the tree, it should avoid double
>> > remove.
>> >
>> > One of the concern I can think is that approach extends critical section
>> > but I think it would be no problem because more bottleneck would be
>> > [de]compress
>> > functions. If it were really problem, we can mitigate a problem with moving
>> > unnecessary functions out of zswap_free_entry because it seem to be rather
>> > over-enginnering.
>>
>> I refactor the zswap refcount routine according to Minchan's idea.
>> Here is the new patch, Any suggestion is welcomed.
>>
>> To Seth and Bob, would you please review it again?
>
> Yeah, Seth, Bob. You guys are right persons to review this because this
> scheme was suggested by me who is biased so it couldn't be a fair. ;-)
> But anyway, I will review code itself.
>
>>
>> mm/zswap.c | 116
>>
>> 1 file changed, 52 insertions(+), 64 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> old mode 100644
>> new mode 100755
>> index deda2b6..bd04910
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -217,6 +217,7 @@ static struct zswap_entry *zswap_entry_cache_alloc(gfp_t
>> gfp)
>> if (!entry)
>> return NULL;
>> entry->refcount = 1;
>> + RB_CLEAR_NODE(>rbnode);
>> return entry;
>> }
>>
>> @@ -232,10 +233,20 @@ static void zswap_entry_get(struct zswap_entry *entry)
>> }
>>
>> /* caller must hold the tree lock */
>> -static int zswap_entry_put(struct zswap_entry *entry)
>> +static int zswap_entry_put(struct zswap_tree *tree, struct zswap_entry
>> *entry)
>
> Why should we have return value? If we really need it, it mitigates
> get/put semantic's whole point so I'd like to just return void.
>
> Let me see.
>
>> {
>> - entry->refcount--;
>> - return entry->refcount;
>> + int refcount = --entry->refcount;
>> +
>> + if (refcount <= 0) {
>
> Hmm, I don't like minus refcount, really.
> I hope we could do following as
>
> BUG_ON(refcount < 0);
> if (refcount == 0) {
> ...
> }
>
>
>
>> + if (!RB_EMPTY_NODE(>rbnode)) {
>> + rb_erase(>rbnode, >rbroot);
>> + RB_CLEAR_NODE(>rbnode);
>
> Minor,
> You could make new function zswap_rb_del or zswap_rb_remove which detach the
> node
> from rb tree and clear node because we have already zswap_rb_insert.
>
>
>> + }
>> +
>> + zswap_free_entry(tree, entry);
>> + }
>> +
>> + return refcount;
>> }
>>
>> /*
>> @@ -258,6 +269,17 @@ static struct zswap_entry *zswap_rb_search(struct
>> rb_root *root, pgoff_t offset)
>> return NULL;
>> }
>>
>
> Add function description.
>
>> +static struct zswap_entry *zswap_entry_find_get(struct rb_root *root,
>> pgoff_t offset)
>> +{
>> + struct zswap_entry *entry = NULL;
>> +
>> + entry = zswap_rb_search(root, offset);
>> + if (entry)
>> + zswap_entry_get(entry);
>> +
>> + return entry;
>> +}
>> +
>> /*
>> * In the case that a entry with the same offset is found, a pointer to
>> * the existing entry is stored in dupentry and the function returns -EEXIST
>> @@ -387,7 +409,7 @@ static void zswap_free_entry(struct zswap_tree *tree,
>> struct zswap_entry *entry)
>> enum zswap_get_swap_ret {
>> ZSWAP_SWAPCACHE_NEW,
>> ZSWAP_SWAPCACHE_EXIST,
>> - ZSWAP_SWAPCACHE_NOMEM
>> + ZSWAP_SWAPCACHE_FAIL,
>> };
>>
>> /*
>> @@ -401,9 +423,9 @@ enum zswap_get_swap_ret {
>> * added to the swap cache, and returned in retpage.
>> *
>> * If success, the swap cache page is returned in retpage
>> - * Returns 0 if page was already in the swap cache, page is not locked
>> - * Returns 1 if the new page needs to be populated, page is locked
>> - * Returns <0 on error
>> + * Returns ZSWAP_SWAPCACHE_EXIST if page
Re: [PATCH] wdt: sunxi: Fix section mismatch
On 10/11/2013 12:15 PM, Maxime Ripard wrote: Hi Wim, On Sat, Oct 05, 2013 at 04:20:17PM +0200, Maxime Ripard wrote: This driver has a section mismatch, for probe and remove functions, leading to the following warning during the compilation. WARNING: drivers/watchdog/built-in.o(.data+0x24): Section mismatch in reference from the variable sunxi_wdt_driver to the function .init.text:sunxi_wdt_probe() The variable sunxi_wdt_driver references the function __init sunxi_wdt_probe() Signed-off-by: Maxime Ripard It would be great if it could go in 3.12. Hi Maxime, Just wondering - is this a nuisance or does it cause a real problem ? Do you want to take it, or can I merge it through my tree, with your Acked-by? In addition to this patch, the following two would also be good to have in 3.12. http://www.spinics.net/lists/linux-watchdog/msg02867.html http://www.spinics.net/lists/linux-watchdog/msg02950.html Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
On Thu, Sep 26, 2013 at 11:42 AM, Weijie Yang wrote: > On Tue, Sep 24, 2013 at 9:03 AM, Minchan Kim wrote: >> On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote: >> > >> > Modify: >> > - check the refcount in fail path, free memory if it is not referenced. >> >> Hmm, I don't like this because zswap refcount routine is already mess for me. >> I'm not sure why it was designed from the beginning. I hope we should fix it >> first. >> >> 1. zswap_rb_serach could include zswap_entry_get semantic if it founds a >> entry from >>the tree. Of course, we should ranme it as find_get_zswap_entry like >> find_get_page. >> 2. zswap_entry_put could hide resource free function like zswap_free_entry >> so that >>all of caller can use it easily following pattern. >> >> find_get_zswap_entry >> ... >> ... >> zswap_entry_put >> >> Of course, zswap_entry_put have to check the entry is in the tree or not >> so if someone already removes it from the tree, it should avoid double >> remove. >> >> One of the concern I can think is that approach extends critical section >> but I think it would be no problem because more bottleneck would be >> [de]compress >> functions. If it were really problem, we can mitigate a problem with moving >> unnecessary functions out of zswap_free_entry because it seem to be rather >> over-enginnering. > > I refactor the zswap refcount routine according to Minchan's idea. > Here is the new patch, Any suggestion is welcomed. > > To Seth and Bob, would you please review it again? > I have nothing in addition to Minchan's review. Since the code is a bit complex, I'd suggest you to split it into two patches. [1/2]: fix the memory leak [2/2]: clean up the entry_put And run some testing.. Thanks, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
[Fixing incorrent mail addresses and dropping the old DT ML.]
On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
> Hi Naveen,
>
> On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> > therefore is completely independent of the cpu frequency.
> > Thus, registering for a CPU freq notifier is very wasteful.
> >
> > This patch modifes the code such that, i2c bus registers to
> > cpu_freq_transition only for non Exynos SoCs.
> >
> > This change should save a bunch of cpufreq transitions calls
> > which does not apply to exynos SoCs.
>
> The idea is fine, although...
>
> > Signed-off-by: Naveen Krishna Chatradhi
> > ---
> > drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> > b/drivers/i2c/busses/i2c-s3c2410.c
> > index cab1c91..d062fa7 100644
> > --- a/drivers/i2c/busses/i2c-s3c2410.c
> > +++ b/drivers/i2c/busses/i2c-s3c2410.c
> > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> > struct s3c2410_platform_i2c *pdata;
> > int gpios[2];
> > struct pinctrl *pctrl;
> > -#ifdef CONFIG_CPU_FREQ
> > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
>
> ...this is not a good coding practice, especially when already having
> multiplatform kernels in sight.
>
> The best way would be to check on which SoC we are running at runtime,
> but since this might need changing a lot of code, then at least I would
> change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
> compiled in when S3C24XX support is not enabled and if it's enabled then
> the notifier will be registered as a safe fallback that will run correctly
> on all platforms.
>
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
On Thu, Oct 10, 2013 at 12:05:32PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 10, 2013 at 04:04:22AM +0200, Hannes Frederic Sowa wrote:
> > On Wed, Oct 09, 2013 at 05:28:33PM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 09, 2013 at 05:12:40PM -0700, Eric Dumazet wrote:
> > > > On Wed, 2013-10-09 at 16:40 -0700, Josh Triplett wrote:
> > > >
> > > > > that. Constructs like list_del_rcu are much clearer, and not
> > > > > open-coded. Open-coding synchronization code is almost always a Bad
> > > > > Idea.
> > > >
> > > > OK, so you think there is synchronization code.
> > > >
> > > > I will shut up then, no need to waste time.
> > >
> > > As you said earlier, we should at least get rid of the memory barrier
> > > as long as we are changing the code.
> >
> > Interesting thread!
> >
> > Sorry to chime in and asking a question:
> >
> > Why do we need an ACCESS_ONCE here if rcu_assign_pointer can do without one?
> > In other words I wonder why rcu_assign_pointer is not a static inline
> > function
> > to use the sequence point in argument evaluation (if I remember correctly
> > this
> > also holds for inline functions) to not allow something like this:
> >
> > E.g. we want to publish which lock to take first to prevent an ABBA problem
> > (extreme example):
> >
> > rcu_assign_pointer(lockptr, min(lptr1, lptr2));
> >
> > Couldn't a compiler spill the lockptr memory location as a temporary buffer
> > if the compiler is under register pressure? (yes, this seems unlikely if we
> > flushed out most registers to memory because of the barrier, but still...
> > ;) )
> >
> > This seems to be also the case if we publish a multi-dereferencing pointers
> > e.g. ptr->ptr->ptr.
>
> IIRC, sequence points only confine volatile accesses. For non-volatile
> accesses, the so-called "as-if rule" allows compiler writers to do some
> surprisingly global reordering.
>
> The reason that rcu_assign_pointer() isn't an inline function is because
> it needs to be type-generic, in other words, it needs to be OK to use
> it on any type of pointers as long as the C types of the two pointers
> match (the sparse types can vary a bit).
>
> One of the reasons for wanting a volatile cast in rcu_assign_pointer() is
> to prevent compiler mischief such as you described in your last two
> paragraphs. That said, it would take a very brave compiler to pull
> a pointer-referenced memory location into a register and keep it there.
> Unfortunately, increasing compiler bravery seems to be a solid long-term
> trend.
I saw your patch regarding making rcu_assign_pointer volatile and wonder if we
can still make it a bit more safe to use if we force the evaluation of the
to-be-assigned pointer before the write barrier. This is what I have in mind:
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index f1f1bc3..79eccc3 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -550,8 +550,9 @@ static inline void rcu_preempt_sleep_check(void)
})
#define __rcu_assign_pointer(p, v, space) \
do { \
+ typeof(v) ___v = (v); \
smp_wmb(); \
- (p) = (typeof(*v) __force space *)(v); \
+ (p) = (typeof(*___v) __force space *)(___v); \
} while (0)
I don't think ___v must be volatile for this case because the memory barrier
will force the evaluation of v first.
This would guard against cases where rcu_assign_pointer is used like:
rcu_assign_pointer(ptr, compute_ptr_with_side_effects());
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
Hi Naveen,
On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
> The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
> therefore is completely independent of the cpu frequency.
> Thus, registering for a CPU freq notifier is very wasteful.
>
> This patch modifes the code such that, i2c bus registers to
> cpu_freq_transition only for non Exynos SoCs.
>
> This change should save a bunch of cpufreq transitions calls
> which does not apply to exynos SoCs.
The idea is fine, although...
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index cab1c91..d062fa7 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> struct s3c2410_platform_i2c *pdata;
> int gpios[2];
> struct pinctrl *pctrl;
> -#ifdef CONFIG_CPU_FREQ
> +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
...this is not a good coding practice, especially when already having
multiplatform kernels in sight.
The best way would be to check on which SoC we are running at runtime,
but since this might need changing a lot of code, then at least I would
change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
compiled in when S3C24XX support is not enabled and if it's enabled then
the notifier will be registered as a safe fallback that will run correctly
on all platforms.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/12] EFI: Runtime services virtual mapping
CCing Peter Jones .., Peter, any idea about the grub related problem? On 10/11/13 at 09:42am, Dave Young wrote: > Matt, > > The kernel I referring is the boot kernel aka the 1st kernel, > the boot loader is grub2 from Fedora 19. > > [sorry for top reply because of using webmail] > > > - Original Message - > From: "Matt Fleming" > To: "Dave Young" > Cc: "Borislav Petkov" , "X86 ML" , "LKML" > , "Borislav Petkov" , "Matthew > Garrett" , "H. Peter Anvin" , "James > Bottomley" , "Vivek Goyal" > , linux-...@vger.kernel.org, fwts-de...@lists.ubuntu.com > Sent: Friday, October 11, 2013 6:27:06 PM > Subject: Re: [PATCH 12/12] EFI: Runtime services virtual mapping > > On Fri, 11 Oct, at 02:24:37PM, Dave Young wrote: > > For the boot efi_reserve_boot_services code, it's mainly for the > > SetVirtualAddressMap callback use, so boot regions should not be reused > > before SetVirtualAddressMap, but the overlapping happens before the > > efi_reserve_boot_services, isn't it a problem? > > Hang on, which kernel are you referring to here? The boot kernel or the > kexec'd kernel? I thought you were saying you noticed the overlap when > running in the second (kexec'd) kernel? > > The only reason that you would see this overlap in the first (boot) > kernel is if the bootloader messed up and allocated the kernel text as > EfiBootServicesCode/Data. I'd like to believe no bootloaders are still > doing that. > > -- > Matt Fleming, Intel Open Source Technology Center > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/12/2013 09:36 AM, Chen Gang wrote: > On 10/11/2013 09:03 PM, Richard Weinberger wrote: >> Am 11.10.2013 14:28, schrieb Will Deacon: >>> On Fri, Oct 11, 2013 at 01:08:17PM +0100, Richard Weinberger wrote: On Fri, Oct 11, 2013 at 1:47 PM, Chen Gang wrote: > In current kernel wide source code, except other architectures, only > s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not > support s390 drivers. > > So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h". Is it really worth removing such a primitive? If someone needs it later he has to implement it from scratch and introduces bugs... >>> >>> The version we have (on ARM64 anyway) already has bugs. Given the choice >>> between fixing code that has no callers and simply removing it, I'd go for >>> the latter. >> >> Yeah, if it's broken and has no real users, send it to hell. :) >> > > OK, thanks. > > > Hmm... at least, the original API definition is not well enough: "need > use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for the > type of parameters". > > But can we say "under arm64, it must be a bug"? (although I agree it is > very easy to let callers miss using it -- then may cause issue). > > In my opinion, it belongs to "API definition issue" not implementation > bug: "if all callers are carefully enough, it will not make issues" > (e.g. in "./kernel" sub-system, we can meet many such kinds of things). > For "./kernel" sub-system, it really it is, if necessary, I can provide 3 samples. ;-) > > > Thanks. > >> Thanks, >> //richard >> >> >> > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NULL pointer dereference in autofs4_expire_wait
On Fri, 2013-10-11 at 07:29 -0600, David Ahern wrote:
> On 10/11/13 3:55 AM, Ian Kent wrote:
> > On Fri, 2013-10-11 at 10:06 +0800, Ian Kent wrote:
> >> On Thu, 2013-10-10 at 17:22 -0600, David Ahern wrote:
> >>> Running 3.12-rc3 just hit BUG in autofs4_expire_wait
> >>
> >> It doesn't look like this could be due to Al's change to the locking in
> >> autos4_wait() and that the only change to autofs that I'm aware of.
> >>
> >> Could you do a bisect please?
> >
> > Of course that assumes it's repeatable.
> > Is it?
> >
> > Can you provide any information about the environment and activity that
> > was happening at the time of the BUG()?
>
> The system was up and running for 9 days before hitting the BUG. After
> that with 3 cpus on softlockup I had to do a reboot (forced). After the
> reboot I continued the workload again without a repeat incident (yet),
> so I am not sure bisect is going to be possible.
Yeah, it isn't repeatable.
>
> This is a corporate environment where practically everything is in an
> automount. Specific to this problem I was repeatedly building a
> workspace in one window, using cscope in another and checking code
> against a different workspace in a third -- all 3 of those were
> different automounts and different NAS servers.
>
> From objdump on vmlinux the line in question is fs/autofs4/expire.c:465
>
> if (ino->flags & AUTOFS_INF_EXPIRING) {
Right, there haven't been changes to the autofs kernel code that affect
the reference counting of dentrys so I have to conclude this is being
caused by other changes.
When walking an autofs path, the walk should always be put into refwalk
mode, so the function containing this line should always have a dentry
with a reference held. Which just means that the autofs info struct (ino
here) won't be invalid.
Now ->d_release() (which frees ino) is only called after the dentry
reference count falls to zero and the dentry is going away.
We can't check ino for NULL here because the dentry pointer to it isn't
set to NULL when it's freed in ->d_release(). Setting the dentry field
to NULL is futile because the next thing the VFS does is to free the
dentry itself. Well, it calls RCU to schedule the free anyway.
The fact that ->d_release() has been called makes me think there's a
reference counting problem somewhere in the VFS.
Al, is my thinking correct here?
There were some significant changes to this area of the VFS in 3.11 by
the look of it.
So more history please, had you used 3.11 for an extended amount of
time, before using the 3.12-rc? IOW what's your kernel version use
history please?
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/12/2013 12:55 AM, Will Deacon wrote:
> On Fri, Oct 11, 2013 at 12:47:05PM +0100, Chen Gang wrote:
>> In current kernel wide source code, except other architectures, only
>> s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not
>> support s390 drivers.
>>
>> So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h".
>
> Acked-by: Will Deacon
>
Thank you for your whole work.
> Catalin, are you happy for me to send this via the ARM tree?
>
> Will
>
Thanks.
--
Chen Gang
>>
>> Signed-off-by: Chen Gang
>> ---
>> arch/arm/include/asm/atomic.h | 24
>> arch/arm64/include/asm/atomic.h | 14 --
>> 2 files changed, 0 insertions(+), 38 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
>> index da1c77d..3b3ae49fa 100644
>> --- a/arch/arm/include/asm/atomic.h
>> +++ b/arch/arm/include/asm/atomic.h
>> @@ -134,21 +134,6 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int
>> old, int new)
>> return oldval;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long tmp, tmp2;
>> -
>> -__asm__ __volatile__("@ atomic_clear_mask\n"
>> -"1: ldrex %0, [%3]\n"
>> -" bic %0, %0, %4\n"
>> -" strex %1, %0, [%3]\n"
>> -" teq %1, #0\n"
>> -" bne 1b"
>> -: "=" (tmp), "=" (tmp2), "+Qo" (*addr)
>> -: "r" (addr), "Ir" (mask)
>> -: "cc");
>> -}
>> -
>> #else /* ARM_ARCH_6 */
>>
>> #ifdef CONFIG_SMP
>> @@ -197,15 +182,6 @@ static inline int atomic_cmpxchg(atomic_t *v, int old,
>> int new)
>> return ret;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long flags;
>> -
>> -raw_local_irq_save(flags);
>> -*addr &= ~mask;
>> -raw_local_irq_restore(flags);
>> -}
>> -
>> #endif /* __LINUX_ARM_ARCH__ */
>>
>> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>> diff --git a/arch/arm64/include/asm/atomic.h
>> b/arch/arm64/include/asm/atomic.h
>> index 8363644..01de5aa 100644
>> --- a/arch/arm64/include/asm/atomic.h
>> +++ b/arch/arm64/include/asm/atomic.h
>> @@ -126,20 +126,6 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int
>> old, int new)
>> return oldval;
>> }
>>
>> -static inline void atomic_clear_mask(unsigned long mask, unsigned long
>> *addr)
>> -{
>> -unsigned long tmp, tmp2;
>> -
>> -asm volatile("// atomic_clear_mask\n"
>> -"1: ldxr%0, %2\n"
>> -" bic %0, %0, %3\n"
>> -" stxr%w1, %0, %2\n"
>> -" cbnz%w1, 1b"
>> -: "=" (tmp), "=" (tmp2), "+Q" (*addr)
>> -: "Ir" (mask)
>> -: "cc");
>> -}
>> -
>> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>>
>> static inline int __atomic_add_unless(atomic_t *v, int a, int u)
>> --
>> 1.7.7.6
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller wrote: I like the basic idea. Here I'm alternately reading the email and the page you link to & commenting on both. A nitpick in the paper is that you cite RFC 1750. That was superceded some years back by RFC 4086 http://tools.ietf.org/html/rfc4086 (Ted's comments in the actual driver had the same problem last I looked. That is excusable since they were written long ago.) I think you may be missing some other citations that should be there, to previous work along similar lines. One is the HAVEGE work, another: McGuire, Okech & Schiesser, Analysis of inherent randomness of the Linux kernel, http://lwn.net/images/conf/rtlws11/random-hardware.pdf Paper has: " the time delta is partitioned into chunks of 1 bit starting at the lowest bit " The 64 1 bit chunks of the time value are XORed with each other to " form a 1 bit value. As I read that, you are just taking the parity. Why not use that simpler description & possibly one of several possible optimised algorithms for the task: http://graphics.stanford.edu/~seander/bithacks.html If what you are doing is not a parity computation, then you need a better description so people like me do not misread it. A bit later you have: " After obtaining the 1 bit folded and unbiased time stamp, " how is it mixed into the entropy pool? ... The 1 bit folded " value is XORed with 1 bit from the entropy pool. This appears to be missing the cryptographically strong mixing step which most RNG code includes. If that is what you are doing, you need to provide some strong arguments to justify it. Sometimes doing without is justified; for example my code along these lines ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ does more mixing than I see in yours, but probably not enough overall. That's OK because I am just feeding into /dev/random which has plenty of mixing. It is OK for your code too if you are feeding into /dev/random, but it looks problematic if your code is expected to stand alone. Ah! You talk about whitening a bit later. However, you seem to make it optional, up to the user. I cannot see that that is a good idea. At the very least I think you need something like the linear transform from the ARIA cipher -- fast and cheap, 128 bits in & 128 out and it makes every output bit depend on every input bit. That might not be enough, though. You require compilation without optimisation. How does that interact with kernel makefiles? Can you avoid undesirable optimisations in some other way, such as volatile declartions? > I am asking whether this RNG would good as an inclusion into the Linux > kernel for: > > - kernel crypto API to provide a true random number generator as part of > this API (see [2] appendix B for a description) My first reaction is no. We have /dev/random for the userspace API and there is a decent kernel API too. I may change my mind here as I look more at your appendix & maybe the code. > - inclusion into /dev/random as an entropy provider of last resort when > the entropy estimator falls low. Why only 'of last resort'? If it can provide good entropy, we should use it often. > I will present the RNG at the Linux Symposium in Ottawa this year. There > I can give a detailed description of the design and testing. I live in Ottawa, don't know if I'll make it to the Symposium this year. Ted; I saw you at one Symposium; are you coming this year? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace
ebied...@xmission.com (Eric W. Biederman) writes:
> Miklos Szeredi writes:
>
>> On Thu, Oct 10, 2013 at 1:43 PM, Eric W. Biederman
>>> Miklos if you as the fuse maintainer aren't worried about network
>>> filesystems, and multiple namespaces I won't worry either. Especially
>>> since modern versions of fuse aren't affected.
>>
>> I think the above conditions (local mount blocks unlink/rename) are
>> enough to prevent most of the problems, of which there aren't many in
>> any case.
>
> Dumb question.
>
> What prevents someone setting up a race between the fusermount
> permission checks and replacing the destination with a symlink, perhaps
> to /etc/shadow?
>
> Do we need a MS_NOFOLLOW?
Doh! mount(".",...) works just fine..
My apologies for the silly question.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h"
On 10/11/2013 09:03 PM, Richard Weinberger wrote: > Am 11.10.2013 14:28, schrieb Will Deacon: >> On Fri, Oct 11, 2013 at 01:08:17PM +0100, Richard Weinberger wrote: >>> On Fri, Oct 11, 2013 at 1:47 PM, Chen Gang wrote: In current kernel wide source code, except other architectures, only s390 scsi drivers use atomic_clear_mask(), and arm/arm64 need not support s390 drivers. So remove atomic_clear_mask() from "arm[64]/include/asm/atomic.h". >>> >>> Is it really worth removing such a primitive? >>> If someone needs it later he has to implement it from scratch and >>> introduces bugs... >> >> The version we have (on ARM64 anyway) already has bugs. Given the choice >> between fixing code that has no callers and simply removing it, I'd go for >> the latter. > > Yeah, if it's broken and has no real users, send it to hell. :) > OK, thanks. Hmm... at least, the original API definition is not well enough: "need use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for the type of parameters". But can we say "under arm64, it must be a bug"? (although I agree it is very easy to let callers miss using it -- then may cause issue). In my opinion, it belongs to "API definition issue" not implementation bug: "if all callers are carefully enough, it will not make issues" (e.g. in "./kernel" sub-system, we can meet many such kinds of things). Thanks. > Thanks, > //richard > > > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: acpi: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case
policy->cur is now set by cpufreq core when cpufreq_driver->get() is defined and
so drivers aren't required to set it. When space_id is ACPI_ADR_SPACE_SYSTEM_IO
for acpi cpufreq driver it doesn't set ->get to a valid function pointer and so
policy->cur is required to be set by driver.
This is already followed in acpi-cpufreq driver. This patch adds a comment
describing why we need to set policy->cur from driver.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
---
This change was requested by Rafael here:
http://www.spinics.net/lists/linux-acpi/msg46748.html
drivers/cpufreq/acpi-cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index a8dac7b..8ecd74e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -838,6 +838,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
switch (perf->control_register.space_id) {
case ACPI_ADR_SPACE_SYSTEM_IO:
/* Current speed is unknown and not detectable by IO port */
+ /* ->cur wouldn't be set by core as ->get() is NULL */
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: trivial: fix typos
On 10/07/13 09:23, Seth Jennings wrote:
> Fix comment typos in swapfile.c
>
> Signed-off-by: Seth Jennings
> ---
> mm/swapfile.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 3963fc2..7968c1b 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1179,7 +1179,7 @@ static int unuse_pte_range(struct vm_area_struct *vma,
> pmd_t *pmd,
>* some architectures (e.g. x86_32 with PAE) we might catch a glimpse
>* of unmatched parts which look like swp_pte, so unuse_pte must
>* recheck under pte lock. Scanning without pte lock lets it be
> - * preemptible whenever CONFIG_PREEMPT but not CONFIG_HIGHPTE.
> + * preemptable whenever CONFIG_PREEMPT but not CONFIG_HIGHPTE.
Do you have a dictionary source that backs this one up?
The kernel source uses either spelling.
dict.org doesn't find either spelling.
m-w.com doesn't find either spelling.
However, dictionary.com finds preemptible but not preemptable.
>*/
> pte = pte_offset_map(pmd, addr);
> do {
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: When USB PHY framework should be used?
> > > I think you should have a wrapper driver to EHCI/OHCI to handle this > reset. > > Thank you Kishon and Peter for the quick replies. Is there any good > example of such a wrapper driver in the kernel already? > chipidea, dwc3, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/3] vfs: Allow rmdir to remove mounts in all but the current mount namespace
Miklos Szeredi writes: > On Thu, Oct 10, 2013 at 1:43 PM, Eric W. Biederman >> Miklos if you as the fuse maintainer aren't worried about network >> filesystems, and multiple namespaces I won't worry either. Especially >> since modern versions of fuse aren't affected. > > I think the above conditions (local mount blocks unlink/rename) are > enough to prevent most of the problems, of which there aren't many in > any case. Dumb question. What prevents someone setting up a race between the fusermount permission checks and replacing the destination with a symlink, perhaps to /etc/shadow? Do we need a MS_NOFOLLOW? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] percpu_ida: add an API to return free tags
On Fri, Oct 11, 2013 at 01:35:36PM -0700, Kent Overstreet wrote: > On Fri, Oct 11, 2013 at 03:18:05PM +0800, Shaohua Li wrote: > > add an API to return free tags, blk-mq-tag will use it > > Can you explain how this is going to be used? Seems like something that > could be prone to misuse, try and convince me there isn't a better way > to do what it's for. There are two usages. One is for sysfs info output, which can be used for diagnosis. The other one is blk-mq wants to determine if it's possible a request can be queued. Neither requires precise data. Yes, caller should be aware returned data isn't very precise. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Btrfs
Hi Linus, We've got more bug fixes in my for-linus branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus One of these fixes another corner of the compression oops from last time. Miao nailed down some problems with concurrent snapshot deletion and drive balancing. I kept out one of his patches for more testing, but these are all stable. Josef Bacik (2) commits (+5/-9): Btrfs: limit delalloc pages outside of find_delalloc_range (+4/-8) Btrfs: use right root when checking for hash collision (+1/-1) Miao Xie (2) commits (+20/-12): Btrfs: fix oops caused by the space balance and dead roots (+17/-7) Btrfs: insert orphan roots into fs radix tree (+3/-5) Total: (4) commits (+25/-21) fs/btrfs/disk-io.c| 9 + fs/btrfs/disk-io.h| 13 +++-- fs/btrfs/extent_io.c | 12 fs/btrfs/inode.c | 2 +- fs/btrfs/relocation.c | 2 +- fs/btrfs/root-tree.c | 8 +++- 6 files changed, 25 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/4] percpu_ida: make percpu_ida percpu size/batch configurable
On Fri, Oct 11, 2013 at 01:31:52PM -0700, Kent Overstreet wrote: > On Fri, Oct 11, 2013 at 03:18:03PM +0800, Shaohua Li wrote: > > Make percpu_ida percpu size/batch configurable. The block-mq-tag will use > > it. > > Can you explain the justification for this? Performance...? The performance using percpu_ida for tag management? Please see the patch 4 thread. If you ask the justification of making the size/batch configurable, the answer is we might have no enough tags, and default cache size/batch is too aggressive. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/39] 3.0.100-stable review
On Fri, Oct 11, 2013 at 03:14:05PM -0700, Greg Kroah-Hartman wrote: > On Fri, Oct 11, 2013 at 12:34:44PM -0700, Greg Kroah-Hartman wrote: > > > > NOTE: This is going to be the next-to-last 3.0.x release that I do. > > You should be moving off to the 3.4.x or 3.10.x longterm kernels > > by now, and not use the 3.0.x kernel unless you have to for some > > reason. If anyone has any problems with this, please let me know. > > > > > > This is the start of the stable review cycle for the 3.0.100 release. > > There are 39 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Oct 13 19:30:52 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.100-rc1.gz > > and the diffstat can be found below. > > Due to a powerpc build breakage in -rc1, I've reverted one patch and > created a -rc2 patch: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.100-rc2.gz > Build results for -rc2: total: 98 pass: 71 skipped: 16 fail: 11 qemu tests all pass. Results are as expected. Details are at http://server.roeck-us.net:8010/builders. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/48] 3.4.66-stable review
On Fri, Oct 11, 2013 at 03:12:41PM -0700, Greg Kroah-Hartman wrote: > On Fri, Oct 11, 2013 at 02:56:19PM -0700, Guenter Roeck wrote: > > On Fri, Oct 11, 2013 at 12:36:07PM -0700, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.4.66 release. > > > There are 48 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Oct 13 19:35:35 UTC 2013. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.66-rc1.gz > > > and the diffstat can be found below. > > > > > Less than perfect test results: > > total: 103 pass: 83 skipped: 10 fail: 10 > > > > New failures appear to be due to: > > 'powerpc: Restore registers on error exit from > > csum_partial_copy_generic()'. > > which causes six of the powerpc builds to fail. > > Ick, that also looks to break the 3.0 build. I'll go drop it from both > trees and do a -rc2 release, thanks for letting me know. > -rc2 looks better: total: 103 pass: 89 skipped: 10 fail: 4 qemu tests all pass. This matches previous results. Please see http://server.roeck-us.net:8010/builders for details. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/4] blk-mq: switch to percpu-ida for tag menagement
On Fri, Oct 11, 2013 at 08:28:54AM -0600, Jens Axboe wrote: > On 10/11/2013 01:18 AM, Shaohua Li wrote: > > Using percpu-ida to manage blk-mq tags. the percpu-ida has similar algorithm > > like the blk-mq-tag. The difference is when a cpu can't allocate tags > > blk-mq-tag uses ipi to purge remote cpu cache and percpu-ida directly purges > > remote cpu cache. In practice (testing null_blk), the percpu-ida approach is > > much faster when total tags aren't enough. > > I'm not surprised it's a lot faster the the pathological case of needing > to prune tags, the IPI isn't near ideal for that. I'm assuming the > general performance is the same for the non-full case? Yep. My test is done in a 2 sockets machine, 12 process cross the 2 sockets. So if there is lock contention or ipi, should be stressed heavily. Testing is done for null-blk. hw_queue_depth nopatch iopspatch iops 64 ~800k/s ~1470k/s 2048~4470k/s~4340k/s In the 2048 case, perf doesn't should any percpu-ida function is hot (no one use > 1% cpu time), so the small difference should be drift. So yes, the general performance is the same. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] xhci: Ensure a command structure points to the correct trb on the command ring
Sarah,
As you said, I make a mistake and send wrong patch. I am sorry for it.
On Fri, 2013-10-11 at 10:28 -0700, Sarah Sharp wrote:
> On Fri, Oct 11, 2013 at 10:25:23AM -0700, Sarah Sharp wrote:
> > Hi Xiao,
> >
> > I think you did something odd when you tried to send me the latest
> > revision of your patch "xhci: correct the usage of
> > USB_CTRL_SET_TIMEOUT". You sent this patch instead. On the plus side,
> > it looks like git-send-email works.
> >
> > Can you try again?
>
> Ah, nevermind, I saw the v2 patch you sent later.
>
> Sarah
>
> > On Fri, Oct 11, 2013 at 08:47:54AM +0800, xiao jin wrote:
> > > From: Mathias Nyman
> > >
> > > If a command on the command ring needs to be cancelled before it is
> > > handled
> > > it can be turned to a no-op operation when the ring is stopped.
> > > We want to store the command ring enqueue pointer in the command structure
> > > when the command in enqueued for the cancellation case.
> > >
> > > Some commands used to store the command ring dequeue pointers instead of
> > > enqueue
> > > (these often worked because enqueue happends to equal dequeue quite often)
> > >
> > > Other commands correctly used the enqueue pointer but did not check if it
> > > pointed
> > > to a valid trb or a link trb, this caused for example stop endpoint
> > > command to timeout in
> > > xhci_stop_device() in about 2% of suspend/resume cases.
> > >
> > > This should also solve some weird behavior happening in command
> > > cancellation cases.
> > >
> > > This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
> > > then forgotten:
> > > http://marc.info/?l=linux-usb=136269803207465=2
> > >
> > > This patch should be backported to kernels as old as 3.7, that contain
> > > the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
> > > command ring function"
> > >
> > > Signed-off-by: Mathias Nyman
> > > Signed-off-by: Sarah Sharp
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > drivers/usb/host/xhci-hub.c |2 +-
> > > drivers/usb/host/xhci-ring.c | 10 ++
> > > drivers/usb/host/xhci.c | 25 +
> > > drivers/usb/host/xhci.h |1 +
> > > 4 files changed, 17 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > > index fae697e..ccf0a06 100644
> > > --- a/drivers/usb/host/xhci-hub.c
> > > +++ b/drivers/usb/host/xhci-hub.c
> > > @@ -287,7 +287,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci,
> > > int slot_id, int suspend)
> > > if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
> > > xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
> > > }
> > > - cmd->command_trb = xhci->cmd_ring->enqueue;
> > > + cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
> > > list_add_tail(>cmd_list, _dev->cmd_list);
> > > xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
> > > xhci_ring_cmd_db(xhci);
> > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > index aaa2906..9ac9672 100644
> > > --- a/drivers/usb/host/xhci-ring.c
> > > +++ b/drivers/usb/host/xhci-ring.c
> > > @@ -123,6 +123,16 @@ static int enqueue_is_link_trb(struct xhci_ring
> > > *ring)
> > > return TRB_TYPE_LINK_LE32(link->control);
> > > }
> > >
> > > +union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
> > > +{
> > > + /* Enqueue pointer can be left pointing to the link TRB,
> > > + * we must handle that
> > > + */
> > > + if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
> > > + return ring->enq_seg->next->trbs;
> > > + return ring->enqueue;
> > > +}
> > > +
> > > /* Updates trb to point to the next TRB in the ring, and updates seg if
> > > the next
> > > * TRB is in a new segment. This does not skip over link TRBs, and it
> > > does not
> > > * effect the ring dequeue or enqueue pointers.
> > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > > index 49b6edb..1e36dbb 100644
> > > --- a/drivers/usb/host/xhci.c
> > > +++ b/drivers/usb/host/xhci.c
> > > @@ -2598,15 +2598,7 @@ static int xhci_configure_endpoint(struct xhci_hcd
> > > *xhci,
> > > if (command) {
> > > cmd_completion = command->completion;
> > > cmd_status = >status;
> > > - command->command_trb = xhci->cmd_ring->enqueue;
> > > -
> > > - /* Enqueue pointer can be left pointing to the link TRB,
> > > - * we must handle that
> > > - */
> > > - if (TRB_TYPE_LINK_LE32(command->command_trb->link.control))
> > > - command->command_trb =
> > > - xhci->cmd_ring->enq_seg->next->trbs;
> > > -
> > > + command->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
> > > list_add_tail(>cmd_list, _dev->cmd_list);
> > > } else {
> > > cmd_completion = _dev->cmd_completion;
> > > @@ -2614,7 +2606,7 @@ static int
[patch 2/2] hung_task: add method to reset detector
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
===
--- kvm.orig/kernel/hung_task.c
+++ kvm/kernel/hung_task.c
@@ -203,6 +203,14 @@ int proc_dohung_task_timeout_secs(struct
return ret;
}
+static atomic_t reset_hung_task = ATOMIC_INIT(0);
+
+void reset_hung_task_detector(void)
+{
+ atomic_set(_hung_task, 1);
+}
+EXPORT_SYMBOL_GPL(reset_hung_task_detector);
+
/*
* kthread which checks for tasks stuck in D state
*/
@@ -216,6 +224,9 @@ static int watchdog(void *dummy)
while (schedule_timeout_interruptible(timeout_jiffies(timeout)))
timeout = sysctl_hung_task_timeout_secs;
+ if (atomic_xchg(_hung_task, 0))
+ continue;
+
check_hung_uninterruptible_tasks(timeout);
}
Index: kvm/include/linux/sched.h
===
--- kvm.orig/include/linux/sched.h
+++ kvm/include/linux/sched.h
@@ -285,6 +285,14 @@ static inline void lockup_detector_init(
}
#endif
+#ifdef CONFIG_DETECT_HUNG_TASK
+void reset_hung_task_detector(void);
+#else
+static inline void reset_hung_task_detector(void)
+{
+}
+#endif
+
/* Attach to any functions which should be ignored in wchan output. */
#define __sched__attribute__((__section__(".sched.text")))
Index: kvm/arch/x86/kernel/pvclock.c
===
--- kvm.orig/arch/x86/kernel/pvclock.c
+++ kvm/arch/x86/kernel/pvclock.c
@@ -48,6 +48,7 @@ void pvclock_touch_watchdogs(void)
touch_softlockup_watchdog_sync();
clocksource_touch_watchdog();
rcu_cpu_stall_reset();
+ reset_hung_task_detector();
}
static atomic64_t last_value = ATOMIC64_INIT(0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/2] generic kernel watchdog reset at pvclock read (v2)
v2: - do not create hung_task.h, move defines to sched.h (Don Zickus) - switch patch order (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/
[PATCH] writeback: fix negative bdi max pause
Toralf runs trinity on UML/i386.
After some time it hangs and the last message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large.
More than 10 pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied > 20);
BUG_ON(pages_dirtied > 10); <-
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the max_pause
calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and
the min_t(long, ...) check failed to protect it falling under 0. Fix
all of them by using "unsigned long" throughout the function.
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Signed-off-by: Fengguang Wu
---
mm/page-writeback.c | 10 +-
mm/readahead.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f0c895..241a746 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1104,11 +1104,11 @@ static unsigned long dirty_poll_interval(unsigned long
dirty,
return 1;
}
-static long bdi_max_pause(struct backing_dev_info *bdi,
- unsigned long bdi_dirty)
+static unsigned long bdi_max_pause(struct backing_dev_info *bdi,
+ unsigned long bdi_dirty)
{
- long bw = bdi->avg_write_bandwidth;
- long t;
+ unsigned long bw = bdi->avg_write_bandwidth;
+ unsigned long t;
/*
* Limit pause time for small memory systems. If sleeping for too long
@@ -1120,7 +1120,7 @@ static long bdi_max_pause(struct backing_dev_info *bdi,
t = bdi_dirty / (1 + bw / roundup_pow_of_two(1 + HZ / 8));
t++;
- return min_t(long, t, MAX_PAUSE);
+ return min_t(unsigned long, t, MAX_PAUSE);
}
static long bdi_min_pause(struct backing_dev_info *bdi,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] pvclock: detect watchdog reset at pvclock read
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kernel/kvmclock.c
===
--- kvm.orig/arch/x86/kernel/kvmclock.c
+++ kvm/arch/x86/kernel/kvmclock.c
@@ -139,6 +139,7 @@ bool kvm_check_and_clear_guest_paused(vo
src = _clock[cpu].pvti;
if ((src->flags & PVCLOCK_GUEST_STOPPED) != 0) {
src->flags &= ~PVCLOCK_GUEST_STOPPED;
+ pvclock_touch_watchdogs();
ret = true;
}
Index: kvm/arch/x86/kernel/pvclock.c
===
--- kvm.orig/arch/x86/kernel/pvclock.c
+++ kvm/arch/x86/kernel/pvclock.c
@@ -43,6 +43,13 @@ unsigned long pvclock_tsc_khz(struct pvc
return pv_tsc_khz;
}
+void pvclock_touch_watchdogs(void)
+{
+ touch_softlockup_watchdog_sync();
+ clocksource_touch_watchdog();
+ rcu_cpu_stall_reset();
+}
+
static atomic64_t last_value = ATOMIC64_INIT(0);
void pvclock_resume(void)
@@ -74,6 +81,11 @@ cycle_t pvclock_clocksource_read(struct
version = __pvclock_read_cycles(src, , );
} while ((src->version & 1) || version != src->version);
+ if (unlikely((flags & PVCLOCK_GUEST_STOPPED) != 0)) {
+ src->flags &= ~PVCLOCK_GUEST_STOPPED;
+ pvclock_touch_watchdogs();
+ }
+
if ((valid_flags & PVCLOCK_TSC_STABLE_BIT) &&
(flags & PVCLOCK_TSC_STABLE_BIT))
return ret;
Index: kvm/arch/x86/include/asm/pvclock.h
===
--- kvm.orig/arch/x86/include/asm/pvclock.h
+++ kvm/arch/x86/include/asm/pvclock.h
@@ -14,6 +14,8 @@ void pvclock_read_wallclock(struct pvclo
struct timespec *ts);
void pvclock_resume(void);
+void pvclock_touch_watchdogs(void);
+
/*
* Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
* yielding a 64-bit result.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Fri, 11 Oct 2013 20:18:58 -0400 Scott Lovenberg wrote: > > On Oct 11, 2013, at 19:49, Jeremy Allison wrote: > > > On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > >>> > >>> At this point, my main questions are: > >>> > >>> 1) does this look useful, particularly for fileserver implementors? > > > > Yes from the Samba perspective. We'll have to keep the old > > code around for compatibility with non-Linux OS'es, but this > > will allow Linux Samba to short-circuit a bunch of logic > > we have to get around the insane POSIX locking semantics > > on close. > > > > Jeremy. > > From the peanut gallery, IIRC from college a few years back, wasn't the POSIX > file locking stuff passed by all parties because they intended to do their > own thing regardless of the standard? The reason that all locks are blown on > a release is mostly because there were already implementations and no one > wanted to push the issue, or am I misunderstanding/forgetting the history of > file locks in POSIX? This blog post of Jeremy's explains some of the history: http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html See the section entitled "First Implementation Past the Post". -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Oct 11, 2013, at 19:49, Jeremy Allison wrote: > On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: >>> >>> At this point, my main questions are: >>> >>> 1) does this look useful, particularly for fileserver implementors? > > Yes from the Samba perspective. We'll have to keep the old > code around for compatibility with non-Linux OS'es, but this > will allow Linux Samba to short-circuit a bunch of logic > we have to get around the insane POSIX locking semantics > on close. > > Jeremy. >From the peanut gallery, IIRC from college a few years back, wasn't the POSIX >file locking stuff passed by all parties because they intended to do their own >thing regardless of the standard? The reason that all locks are blown on a >release is mostly because there were already implementations and no one wanted >to push the issue, or am I misunderstanding/forgetting the history of file >locks in POSIX?-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] drivers: usb: core: Adapt source to styleguide
On Thu, Oct 10, 2013 at 11:41:26PM +0200, Matthias Beyer wrote: > Hi, > > I patches several files in drivers/usb/core/ to adapt them to the kernel > styleguide. > > Most of these patches are whitespace/indention fixes. > > As these patches are only style-patches, I just compiled the kernel, no > compile > errors or warnings. So I think everything seems to be okay! > > Note: I did not fix all ERROR messages from the scripts/checkpatch.pl script, > as > I don't know what to do with "do not use assignments in if-condition" > messages. You can fix those up if you want. An example would be: bad code: if ((x = foo() == NULL) do_something(); good code: x = foo(); if (x == NULL) do_something(); Hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] drivers: usb: core: devio.c: Braces around switch
On Thu, Oct 10, 2013 at 11:41:31PM +0200, Matthias Beyer wrote: > Added braces around switch statement as the styleguide tells us. > Indented the switch-block for it and split a function call > (driver->unlocked_ioctl() on line 1876) arguments to several lines to > fit the 80-column convention. > > Signed-off-by: Matthias Beyer > --- > drivers/usb/core/devio.c | 60 > ++-- This patch has fuzz, due to me not applying your previous one, so I can't apply it. Can you fix it up, and resend the remaining patches that I didn't apply in this series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] drivers: usb: core: devio.c: Coding style fixes
On Thu, Oct 10, 2013 at 11:41:30PM +0200, Matthias Beyer wrote:
> @@ -1838,9 +1838,10 @@ static int proc_ioctl(struct dev_state *ps, struct
> usbdevfs_ioctl *ctl)
> return -ENODEV;
> }
>
> - if (ps->dev->state != USB_STATE_CONFIGURED)
> + if (ps->dev->state != USB_STATE_CONFIGURED) {
> retval = -EHOSTUNREACH;
> - else if (!(intf = usb_ifnum_to_if(ps->dev, ctl->ifno)))
> + }
> + else if (!(intf = usb_ifnum_to_if(ps->dev, ctl->ifno))) {
> retval = -EINVAL;
> else switch (ctl->ioctl_code) {
I don't think you actually built the code after you made this change :(
drivers/usb/core/devio.c: In function ‘proc_ioctl’:
drivers/usb/core/devio.c:1844:2: error: expected ‘}’ before ‘else’
Please be more careful.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/135] 3.11.5-stable review
On Fri, Oct 11, 2013 at 04:58:06PM -0700, Guenter Roeck wrote: > On Fri, Oct 11, 2013 at 12:38:01PM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.5 release. > > There are 135 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Oct 13 19:38:31 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.5-rc1.gz > > and the diffstat can be found below. > > > Build test looks good: > total: 110 pass: 108 skipped: 2 fail: 0 > > qemu tests all pass (with the known warning for the sh target). Great, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 000/135] 3.11.5-stable review
On Fri, Oct 11, 2013 at 12:38:01PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.11.5 release. > There are 135 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Oct 13 19:38:31 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.5-rc1.gz > and the diffstat can be found below. > Build test looks good: total: 110 pass: 108 skipped: 2 fail: 0 qemu tests all pass (with the known warning for the sh target). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/6] PowerCap: Documentation
Added power cap framework documentation. This explains the use of power capping framework, sysfs and programming interface. There are two documents: Documentation/power/powercap/powercap.txt : Explains use case and APIs. Documentation/ABI/testing/sysfs-class-powercap: Explains ABIs. Reviewed-by: Rafael J. Wysocki Reviewed-by: Len Brown Signed-off-by: Srinivas Pandruvada Signed-off-by: Jacob Pan Signed-off-by: Arjan van de Ven --- Documentation/ABI/testing/sysfs-class-powercap | 152 Documentation/power/powercap/powercap.txt | 236 + 2 files changed, 388 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-powercap create mode 100644 Documentation/power/powercap/powercap.txt diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap new file mode 100644 index 000..db3b3ff --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-powercap @@ -0,0 +1,152 @@ +What: /sys/class/powercap/ +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + The powercap/ class sub directory belongs to the power cap + subsystem. Refer to + Documentation/power/powercap/powercap.txt for details. + +What: /sys/class/powercap/ +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + A is a unique name under /sys/class/powercap. + Here determines how the power is going to be + controlled. A can contain multiple power zones. + +What: /sys/class/powercap//enabled +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + This allows to enable/disable power capping for a "control type". + This status affects every power zone using this "control_type. + +What: /sys/class/powercap// +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + A power zone is a single or a collection of devices, which can + be independently monitored and controlled. A power zone sysfs + entry is qualified with the name of the . + E.g. intel-rapl:0:1:1. + +What: /sys/class/powercap/// +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Power zones may be organized in a hierarchy in which child + power zones provide monitoring and control for a subset of + devices under the parent. For example, if there is a parent + power zone for a whole CPU package, each CPU core in it can + be a child power zone. + +What: /sys/class/powercap/...//name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Specifies the name of this power zone. + +What: /sys/class/powercap/...//energy_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Current energy counter in micro-joules. Write "0" to reset. + If the counter can not be reset, then this attribute is + read-only. + +What: /sys/class/powercap/...//max_energy_range_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Range of the above energy counter in micro-joules. + + +What: /sys/class/powercap/...//power_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Current power in micro-watts. + +What: /sys/class/powercap/...//max_power_range_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Range of the above power value in micro-watts. + +What: /sys/class/powercap/...//constraint_X_name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Each power zone can define one or more constraints. Each + constraint can have an optional name. Here "X" can have values + from 0 to max integer. + +What: /sys/class/powercap/...//constraint_X_power_limit_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org +Description: + Power limit in micro-watts should be applicable for + the time window specified by "constraint_X_time_window_us". + Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/...//constraint_X_time_window_us +Date: September 2013 +KernelVersion: 3.13 +Contact: linux...@vger.kernel.org
[PATCH v3 6/6] Introduce Intel RAPL power capping driver
From: Jacob Pan
The Intel Running Average Power Limit(RAPL) technology provides platform
software with the ability to monitor, control, and get notifications on
power usage.
This feature is present in all Sandy Bridge and later Intel processors.
Newer models allow more fine grained controls to be applied.
In RAPL, power control is divided into domains, which include
package, DRAM controller, CPU core (Power Plane 0), graphics uncore
(power plane 1), etc.
The purpose of this driver is to expose the RAPL settings to userspace.
Overall, RAPL fits in the new powercap class driver in
that platform level power capping controls are exposed via this
generic interface.
This driver is based on an earlier patch from Zhang Rui.
https://lkml.org/lkml/2011/5/26/93
However, while the previous work was mainly focused on thermal monitoring
the focus here is on the usability from user space perspective.
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jacob Pan
---
drivers/powercap/Kconfig | 12 +
drivers/powercap/Makefile |1 +
drivers/powercap/intel_rapl.c | 1395 +
3 files changed, 1408 insertions(+)
create mode 100644 drivers/powercap/intel_rapl.c
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index a37055e..dd6a4bf 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -15,5 +15,17 @@ menuconfig POWERCAP
if POWERCAP
# Client driver configurations go here.
+config INTEL_RAPL
+ tristate "Intel RAPL Support"
+ default n
+ ---help---
+ This enables support for the Intel Running Average Power Limit (RAPL)
+ technology which allows power limits to be enforced and monitored on
+ modern Intel processors (Sandy Bridge and later).
+
+ In RAPL, the platform level settings are divided into domains for
+ fine grained control. These domains include processor package, DRAM
+ controller, CPU core (Power Plance 0), graphics uncore (Power Plane
+ 1), etc.
endif
diff --git a/drivers/powercap/Makefile b/drivers/powercap/Makefile
index 6defbc8..0a21ef3 100644
--- a/drivers/powercap/Makefile
+++ b/drivers/powercap/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_POWERCAP) += powercap_sys.o
+obj-$(CONFIG_INTEL_RAPL) += intel_rapl.o
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
new file mode 100644
index 000..887a492
--- /dev/null
+++ b/drivers/powercap/intel_rapl.c
@@ -0,0 +1,1395 @@
+/*
+ * Intel Running Average Power Limit (RAPL) Driver
+ * Copyright (c) 2013, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.
+ *
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/* bitmasks for RAPL MSRs, used by primitive access functions */
+#define ENERGY_STATUS_MASK 0x
+
+#define POWER_LIMIT1_MASK 0x7FFF
+#define POWER_LIMIT1_ENABLE BIT(15)
+#define POWER_LIMIT1_CLAMP BIT(16)
+
+#define POWER_LIMIT2_MASK (0x7FFFULL<<32)
+#define POWER_LIMIT2_ENABLE BIT_ULL(47)
+#define POWER_LIMIT2_CLAMP BIT_ULL(48)
+#define POWER_PACKAGE_LOCK BIT_ULL(63)
+#define POWER_PP_LOCK BIT(31)
+
+#define TIME_WINDOW1_MASK (0x7FULL<<17)
+#define TIME_WINDOW2_MASK (0x7FULL<<49)
+
+#define POWER_UNIT_OFFSET 0
+#define POWER_UNIT_MASK0x0F
+
+#define ENERGY_UNIT_OFFSET 0x08
+#define ENERGY_UNIT_MASK 0x1F00
+
+#define TIME_UNIT_OFFSET 0x10
+#define TIME_UNIT_MASK 0xF
+
+#define POWER_INFO_MAX_MASK (0x7fffULL<<32)
+#define POWER_INFO_MIN_MASK (0x7fffULL<<16)
+#define POWER_INFO_MAX_TIME_WIN_MASK (0x3fULL<<48)
+#define POWER_INFO_THERMAL_SPEC_MASK 0x7fff
+
+#define PERF_STATUS_THROTTLE_TIME_MASK 0x
+#define PP_POLICY_MASK 0x1F
+
+/* Non HW constants */
+#define RAPL_PRIMITIVE_DERIVED BIT(1) /* not from raw data */
+#define RAPL_PRIMITIVE_DUMMY BIT(2)
+
+/* scale RAPL units to avoid floating point math inside kernel */
+#define POWER_UNIT_SCALE (100)
+#define ENERGY_UNIT_SCALE(100)
+#define TIME_UNIT_SCALE (100)
+
+#define TIME_WINDOW_MAX_MSEC 4
+#define TIME_WINDOW_MIN_MSEC 250
+
+enum unit_type {
+ ARBITRARY_UNIT, /* no
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > > > > At this point, my main questions are: > > > > 1) does this look useful, particularly for fileserver implementors? Yes from the Samba perspective. We'll have to keep the old code around for compatibility with non-Linux OS'es, but this will allow Linux Samba to short-circuit a bunch of logic we have to get around the insane POSIX locking semantics on close. Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/6] Power Capping Framework and RAPL Driver
Overview With the evolution of technologies, which enables power monitoring and limiting, more and more devices are able to constrain their power consumption under certain limits. There are several use cases for such technologies: - Power monitoring: Each device can report its power consumption. - Power Limiting: Setting power limits on the devices allows users to guard against platform reaching max system power level. - Maximize performance: While staying below a power limit, it allows devices to automatically adjust performance to meet demands - Dynamic control and re-budgeting: If each device can be constrained to some power, extra power can redistributed to other devices, which needs additional performance. One such example of technologies is RAPL (Running Average Power Limit) mechanism available in the latest Intel processors. Intel is slowly adding many devices under RAPL control. Also there are other technologies available, for power capping various devices. Soon it is very likely that other vendors are also adding or considering such implementation. Power Capping framework is an effort to have a uniform interface available to Linux drivers, which will enable - A uniform sysfs interface for all devices which can offer power capping - A common API for drivers, which will avoid code duplication and easy implementation of client drivers. Also submitting Intel RAPL driver using power capping framework. History: v3 As suggested changed DEVICE_ATTR to DEVICE_ATTR_RO/RW Minor change in RAPL driver for TIME_WINDOW1_MASK to change to ULL v2 As suggested, added BIT_ULL_MASK and BIT_ULL_WORD v1 Incorporated changes suggested during RFC stage Jacob Pan (2): x86/msr: add 64bit _on_cpu access functions Introduce Intel RAPL power capping driver Srinivas Pandruvada (4): PowerCap: Documentation PowerCap: Add class driver PowerCap: Added to drivers build bitops: Introduce BIT_ULL Documentation/ABI/testing/sysfs-class-powercap | 152 +++ Documentation/power/powercap/powercap.txt | 236 arch/x86/include/asm/msr.h | 22 + arch/x86/lib/msr-smp.c | 62 ++ drivers/Kconfig|2 + drivers/Makefile |1 + drivers/powercap/Kconfig | 31 + drivers/powercap/Makefile |2 + drivers/powercap/intel_rapl.c | 1395 drivers/powercap/powercap_sys.c| 683 include/linux/bitops.h |3 + include/linux/powercap.h | 325 ++ 12 files changed, 2914 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-powercap create mode 100644 Documentation/power/powercap/powercap.txt create mode 100644 drivers/powercap/Kconfig create mode 100644 drivers/powercap/Makefile create mode 100644 drivers/powercap/intel_rapl.c create mode 100644 drivers/powercap/powercap_sys.c create mode 100644 include/linux/powercap.h -- 1.8.3.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 v3 2/6] PowerCap: Add class driver
The power capping framework providing a consistent interface between the
kernel and user space that allows power capping drivers to expose their
settings to user space in a uniform way.
The overall design of the framework is described in the documentation
added by the previous patch in this series.
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jacob Pan
---
drivers/powercap/Kconfig| 19 ++
drivers/powercap/Makefile | 1 +
drivers/powercap/powercap_sys.c | 683
include/linux/powercap.h| 325 +++
4 files changed, 1028 insertions(+)
create mode 100644 drivers/powercap/Kconfig
create mode 100644 drivers/powercap/Makefile
create mode 100644 drivers/powercap/powercap_sys.c
create mode 100644 include/linux/powercap.h
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
new file mode 100644
index 000..a37055e
--- /dev/null
+++ b/drivers/powercap/Kconfig
@@ -0,0 +1,19 @@
+#
+# Generic power capping sysfs interface configuration
+#
+
+menuconfig POWERCAP
+ bool "Generic powercap sysfs driver"
+ help
+ The power capping sysfs interface allows kernel subsystems to expose
power
+ capping settings to user space in a consistent way. Usually, it
consists
+ of multiple control types that determine which settings may be
exposed and
+ power zones representing parts of the system that can be subject to
power
+ capping.
+
+ If you want this code to be compiled in, say Y here.
+
+if POWERCAP
+# Client driver configurations go here.
+
+endif
diff --git a/drivers/powercap/Makefile b/drivers/powercap/Makefile
new file mode 100644
index 000..6defbc8
--- /dev/null
+++ b/drivers/powercap/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_POWERCAP) += powercap_sys.o
diff --git a/include/linux/powercap.h b/include/linux/powercap.h
new file mode 100644
index 000..4e25041
--- /dev/null
+++ b/include/linux/powercap.h
@@ -0,0 +1,325 @@
+/*
+ * powercap.h: Data types and headers for sysfs power capping interface
+ * Copyright (c) 2013, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.
+ *
+ */
+
+#ifndef __POWERCAP_H__
+#define __POWERCAP_H__
+
+#include
+#include
+
+/*
+ * A power cap class device can contain multiple powercap control_types.
+ * Each control_type can have multiple power zones, which can be independently
+ * controlled. Each power zone can have one or more constraints.
+ */
+
+struct powercap_control_type;
+struct powercap_zone;
+struct powercap_zone_constraint;
+
+/**
+ * struct powercap_control_type_ops - Define control type callbacks
+ * @set_enable:Enable/Disable whole control type.
+ * Default is enabled. But this callback allows all zones
+ * to be in disable state and remove any applied power
+ * limits. If disabled power zone can only be monitored
+ * not controlled.
+ * @get_enable:get Enable/Disable status.
+ * @release: Callback to inform that last reference to this
+ * control type is closed. So it is safe to free data
+ * structure associated with this control type.
+ * This callback is mandatory if the client own memory
+ * for the control type.
+ *
+ * This structure defines control type callbacks to be implemented by client
+ * drivers
+ */
+struct powercap_control_type_ops {
+ int (*set_enable) (struct powercap_control_type *, bool mode);
+ int (*get_enable) (struct powercap_control_type *, bool *mode);
+ int (*release) (struct powercap_control_type *);
+};
+
+/**
+ * struct powercap_control_type- Defines a powercap control_type
+ * @name: name of control_type
+ * @dev: device for this control_type
+ * @idr: idr to have unique id for its child
+ * @root_node: Root holding power zones for this control_type
+ * @ops: Pointer to callback struct
+ * @node_lock: mutex for control type
+ * @allocated: This is possible that client owns the memory
+ * used by this structure. In this case
+ * this flag is set to false by framework to
+ * prevent deallocation during release process.
+ *
[PATCH v3 3/6] PowerCap: Added to drivers build
Added changes to Makefile and Kconfig to include in driver build. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jacob Pan Acked-by: Rafael J. Wysocki --- drivers/Kconfig | 2 ++ drivers/Makefile | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/Kconfig b/drivers/Kconfig index aa43b91..969e987 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -166,4 +166,6 @@ source "drivers/reset/Kconfig" source "drivers/fmc/Kconfig" +source "drivers/powercap/Kconfig" + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index ab93de8..34c1d55 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -152,3 +152,4 @@ obj-$(CONFIG_VME_BUS) += vme/ obj-$(CONFIG_IPACK_BUS)+= ipack/ obj-$(CONFIG_NTB) += ntb/ obj-$(CONFIG_FMC) += fmc/ +obj-$(CONFIG_POWERCAP) += powercap/ -- 1.8.3.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 v3 4/6] x86/msr: add 64bit _on_cpu access functions
From: Jacob Pan
Having 64-bit MSR access methods on given CPU can avoid shifting and
simplify MSR content manipulation. We already have other combinations
of rdmsrl_xxx and wrmsrl_xxx but missing the _on_cpu version.
Reviewed-by: H. Peter Anvin
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jacob Pan
Acked-by: Rafael J. Wysocki
---
arch/x86/include/asm/msr.h | 22
arch/x86/lib/msr-smp.c | 62 ++
2 files changed, 84 insertions(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index cb75028..e139b13 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -218,10 +218,14 @@ void msrs_free(struct msr *msrs);
#ifdef CONFIG_SMP
int rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
int wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
+int rdmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 *q);
+int wrmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 q);
void rdmsr_on_cpus(const struct cpumask *mask, u32 msr_no, struct msr *msrs);
void wrmsr_on_cpus(const struct cpumask *mask, u32 msr_no, struct msr *msrs);
int rdmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
int wrmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
+int rdmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 *q);
+int wrmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 q);
int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]);
int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]);
#else /* CONFIG_SMP */
@@ -235,6 +239,16 @@ static inline int wrmsr_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
wrmsr(msr_no, l, h);
return 0;
}
+static inline int rdmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 *q)
+{
+ rdmsrl(msr_no, *q);
+ return 0;
+}
+static inline int wrmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 q)
+{
+ wrmsrl(msr_no, q);
+ return 0;
+}
static inline void rdmsr_on_cpus(const struct cpumask *m, u32 msr_no,
struct msr *msrs)
{
@@ -254,6 +268,14 @@ static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
{
return wrmsr_safe(msr_no, l, h);
}
+static inline int rdmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 *q)
+{
+ return rdmsrl_safe(msr_no, q);
+}
+static inline int wrmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 q)
+{
+ return wrmsrl_safe(msr_no, q);
+}
static inline int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8])
{
return rdmsr_safe_regs(regs);
diff --git a/arch/x86/lib/msr-smp.c b/arch/x86/lib/msr-smp.c
index a6b1b86..518532e 100644
--- a/arch/x86/lib/msr-smp.c
+++ b/arch/x86/lib/msr-smp.c
@@ -47,6 +47,21 @@ int rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32
*h)
}
EXPORT_SYMBOL(rdmsr_on_cpu);
+int rdmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 *q)
+{
+ int err;
+ struct msr_info rv;
+
+ memset(, 0, sizeof(rv));
+
+ rv.msr_no = msr_no;
+ err = smp_call_function_single(cpu, __rdmsr_on_cpu, , 1);
+ *q = rv.reg.q;
+
+ return err;
+}
+EXPORT_SYMBOL(rdmsrl_on_cpu);
+
int wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h)
{
int err;
@@ -63,6 +78,22 @@ int wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h)
}
EXPORT_SYMBOL(wrmsr_on_cpu);
+int wrmsrl_on_cpu(unsigned int cpu, u32 msr_no, u64 q)
+{
+ int err;
+ struct msr_info rv;
+
+ memset(, 0, sizeof(rv));
+
+ rv.msr_no = msr_no;
+ rv.reg.q = q;
+
+ err = smp_call_function_single(cpu, __wrmsr_on_cpu, , 1);
+
+ return err;
+}
+EXPORT_SYMBOL(wrmsrl_on_cpu);
+
static void __rwmsr_on_cpus(const struct cpumask *mask, u32 msr_no,
struct msr *msrs,
void (*msr_func) (void *info))
@@ -159,6 +190,37 @@ int wrmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 l,
u32 h)
}
EXPORT_SYMBOL(wrmsr_safe_on_cpu);
+int wrmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 q)
+{
+ int err;
+ struct msr_info rv;
+
+ memset(, 0, sizeof(rv));
+
+ rv.msr_no = msr_no;
+ rv.reg.q = q;
+
+ err = smp_call_function_single(cpu, __wrmsr_safe_on_cpu, , 1);
+
+ return err ? err : rv.err;
+}
+EXPORT_SYMBOL(wrmsrl_safe_on_cpu);
+
+int rdmsrl_safe_on_cpu(unsigned int cpu, u32 msr_no, u64 *q)
+{
+ int err;
+ struct msr_info rv;
+
+ memset(, 0, sizeof(rv));
+
+ rv.msr_no = msr_no;
+ err = smp_call_function_single(cpu, __rdmsr_safe_on_cpu, , 1);
+ *q = rv.reg.q;
+
+ return err ? err : rv.err;
+}
+EXPORT_SYMBOL(rdmsrl_safe_on_cpu);
+
/*
* These variants are significantly slower, but allows control over
* the entire 32-bit GPR set.
--
1.8.3.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
[PATCH v3 5/6] bitops: Introduce BIT_ULL
Adding BIT(x) equivalent for unsigned long long type, BIT_ULL(x). Also added BIT_ULL_MASK and BIT_ULL_WORD. Suggested-by: Joe Perches Signed-off-by: Srinivas Pandruvada Signed-off-by: Jacob Pan Acked-by: Rafael J. Wysocki --- include/linux/bitops.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index a3b6b82..5a1c8b7 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -4,8 +4,11 @@ #ifdef __KERNEL__ #define BIT(nr)(1UL << (nr)) +#define BIT_ULL(nr)(1ULL << (nr)) #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) +#define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG)) +#define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG) #define BITS_PER_BYTE 8 #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) #endif -- 1.8.3.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: [BUG] WARN_ON(!context) in drivers/pci/hotplug/acpiphp_glue.c
On Friday, October 11, 2013 11:58:48 PM Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 10:21:35 AM Linus Torvalds wrote:
> > On Fri, Oct 11, 2013 at 4:13 AM, Rafael J. Wysocki
> > wrote:
[...]
> > Or am I misreading the code? It's more readable, and no longer makes
> > me homicidal, but I don't actually know the code itself.
>
> I think you're reading it correctly, it really makes acpiphp see all slots
> even if pciehp sees them too. So the change is somewhat risky.
>
> That said the risk doesn't seem to be huge and there seem to be cases in
> which it actually would be useful to have both acpiphp and pciehp signaling
> available for the same device. For example, even if the BIOS told us that
> we could use the native mechanism (pciehp), it may not actually work. That
> is,
> we may not get any hotplug interrupts from PCIe ports due to platform bugs of
> some sort and we may get ACPI notifications instead (because the platform
> designer knew about those bugs and thought it would be smart to use ACPI to
> work around them).
>
> There are bug reports indicating thinks like that, so we were going to allow
> acpiphp and pciehp to handle the same devices anyway at one point. I thought
> we might as well try to do it now and see how it goes. Still, if you think
> it's too risky for this stage of the cycle, I'll just send a patch removing
> the WARN_ON() and we'll revisit that thing in 3.13.
Having reconsidered this I think it's best to just drop the WARN_ON() for now
after all and sort out the coexistence between acpiphp and pciehp later, so
that we don't run into a weird corner case late in the cycle.
So the one below is what I'm going to do for 3.12.
Rafael
---
From: Rafael J. Wysocki
Subject: ACPI / hotplug / PCI: Drop WARN_ON() from acpiphp_enumerate_slots()
The WARN_ON() in acpiphp_enumerate_slots() triggers unnecessarily for
devices whose bridges are going to be handled by native PCIe hotplug
(pciehp) and the simplest way to prevent that from happening is to
drop the WARN_ON().
References: https://bugzilla.kernel.org/show_bug.cgi?id=62831
Reported-by: Steven Rostedt
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -999,12 +999,13 @@ void acpiphp_enumerate_slots(struct pci_
/*
* This bridge should have been registered as a hotplug function
-* under its parent, so the context has to be there. If not, we
-* are in deep goo.
+* under its parent, so the context should be there, unless the
+* parent is going to be handled by pciehp, in which case this
+* bridge is not interesting to us either.
*/
mutex_lock(_context_lock);
context = acpiphp_get_context(handle);
- if (WARN_ON(!context)) {
+ if (!context) {
mutex_unlock(_context_lock);
put_device(>dev);
kfree(bridge);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] Drivers: hv: vmbus: Fix a bug in channel rescind code
Rescind of subchannels were not being correctly handled. Fix the bug.
Signed-off-by: K. Y. Srinivasan
Cc: [3.11+]
---
drivers/hv/channel_mgmt.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index bbff5f2..eebf566 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -203,7 +203,8 @@ static void vmbus_process_rescind_offer(struct work_struct
*work)
struct vmbus_channel *primary_channel;
struct vmbus_channel_relid_released msg;
- vmbus_device_unregister(channel->device_obj);
+ if (channel->device_obj)
+ vmbus_device_unregister(channel->device_obj);
memset(, 0, sizeof(struct vmbus_channel_relid_released));
msg.child_relid = channel->offermsg.child_relid;
msg.header.msgtype = CHANNELMSG_RELID_RELEASED;
@@ -213,11 +214,6 @@ static void vmbus_process_rescind_offer(struct work_struct
*work)
spin_lock_irqsave(_connection.channel_lock, flags);
list_del(>listentry);
spin_unlock_irqrestore(_connection.channel_lock, flags);
- } else {
- primary_channel = channel->primary_channel;
- spin_lock_irqsave(_channel->sc_lock, flags);
- list_del(>listentry);
- spin_unlock_irqrestore(_channel->sc_lock, flags);
}
free_channel(channel);
}
--
1.7.4.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: [PATCHv3 6/8] ARM: dts: OMAP4: Add hwspinlock node
* Suman Anna [131010 14:24]: > Add the hwspinlock device tree node for OMAP4 family > of SoCs. Suman, can you please post the .dts changes separately from the driver changes next time so driver maintainers don't accidentally pick them up. That leads to unnecessary merge conflicts with the .dts files. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: N900: TWL4030 Keypad Matrix definition
* Sebastian Reichel [131009 14:26]: > Add Keyboard Matrix information to N900's DTS file. > This patch maps the keys exactly as the original > board code. This should be queued by Benoit along with other .dts changes, not via the input tree: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: twl4030_keypad - add device tree support
* Sebastian Reichel [131009 14:25]:
> Add device tree support for twl4030 keypad driver and update the
> Documentation with twl4030 keypad device tree binding information.
>
> This patch also adds a twl4030 keypad node to the twl4030.dtsi file,
> so that board files can just add the keymap.
>
> Tested on Nokia N900.
Nice :) Just few cosmetic comments below.
>
> +#ifdef CONFIG_OF
> +static int twl4030_keypad_parse_dt(struct device *dev,
> + struct twl4030_keypad *keypad_data)
> +{
I guess the way to go nowadays is to use #IS_ENABLED(CONFIG_OF) here
and later on in this patch.
> @@ -331,20 +358,12 @@ static int twl4030_kp_program(struct twl4030_keypad *kp)
> static int twl4030_kp_probe(struct platform_device *pdev)
> {
> struct twl4030_keypad_data *pdata = pdev->dev.platform_data;
> - const struct matrix_keymap_data *keymap_data;
> + const struct matrix_keymap_data *keymap_data = NULL;
> struct twl4030_keypad *kp;
> struct input_dev *input;
> u8 reg;
> int error;
>
> - if (!pdata || !pdata->rows || !pdata->cols || !pdata->keymap_data ||
> - pdata->rows > TWL4030_MAX_ROWS || pdata->cols > TWL4030_MAX_COLS) {
> - dev_err(>dev, "Invalid platform_data\n");
> - return -EINVAL;
> - }
> -
> - keymap_data = pdata->keymap_data;
> -
> kp = kzalloc(sizeof(*kp), GFP_KERNEL);
> input = input_allocate_device();
> if (!kp || !input) {
I assume you have tested the above so it does not break things
for legacy booting?
Other than that:
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [patch x86/hyperv] x86, hyperv: Fix build error
> -Original Message-
> From: David Rientjes [mailto:rient...@google.com]
> Sent: Friday, October 11, 2013 4:29 PM
> To: KY Srinivasan
> Cc: Ingo Molnar; H. Peter Anvin; t...@linutronix.de; H. Peter Anvin; Olaf
> Hering;
> linux-kernel@vger.kernel.org; linux-tip-comm...@vger.kernel.org
> Subject: RE: [patch x86/hyperv] x86, hyperv: Fix build error
>
> On Fri, 11 Oct 2013, KY Srinivasan wrote:
>
> > > From: David Rientjes [mailto:rient...@google.com]
> > > Sent: Friday, October 11, 2013 4:08 PM
> > > To: Ingo Molnar; H. Peter Anvin; t...@linutronix.de; H. Peter Anvin
> > > Cc: KY Srinivasan; Olaf Hering; linux-kernel@vger.kernel.org; linux-tip-
> > > comm...@vger.kernel.org
> > > Subject: [patch x86/hyperv] x86, hyperv: Fix build error
> > >
> > > 9e7827b5ea4c ("x86, hyperv: Get the local APIC timer frequency from the
> > > hypervisor") breaks the build with some configs because apic.h isn't
> > > directly included:
> > >
> > > arch/x86/kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform':
> > > arch/x86/kernel/cpu/mshyperv.c:90:3: error: 'lapic_timer_frequency'
> undeclared
> > > (first use in this function)
> > > arch/x86/kernel/cpu/mshyperv.c:90:3: note: each undeclared identifier is
> > > reported only once for each function it appears in
> > >
> > > Fix it by including asm/apic.h.
> >
> > Thank you. The issue was configuration related - local APIC was not
> > configured.
> This has already been fixed.
> >
>
> Yeah, it's config related as stated in the changelog. If you're referring
> to 90ab9d551093 ("x86, hyperv: Correctly guard the local APIC calibration
> code ")as "fixing" it, it does not. (I'm left to wonder what you mean by
> it being fixed since you didn't elaborate.) You can trigger this build
> breakage even with CONFIG_X86_LOCAL_APIC=y.
>
> Let me be explicit: this file includes desc.h, which includes linux/smp.h,
> which includes asm/smp.h iff CONFIG_SMP is enabled. That's what you're
> relying upon to get asm/apic.h when CONFIG_X86_LOCAL_APIC is enabled. It
> will break when CONFIG_SMP is disabled.
>
> So you need to include asm/apic.h directly for such a configuration.
Thank you for the details.
Signed-off-by: K. Y. Srinivasan
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][TRIVIAL] treewide: Fix common typo in "identify"
Correct common misspelling of "identify" as "indentify" throughout
the kernel
Signed-off-by: Maxime Jayat
---
arch/mips/include/asm/octeon/cvmx-pip.h |4 ++--
arch/x86/kernel/cpu/intel_cacheinfo.c |2 +-
arch/x86/kernel/cpu/scattered.c |2 +-
drivers/media/rc/keymaps/rc-dib0700-nec.c |2 +-
drivers/media/rc/keymaps/rc-dib0700-rc5.c |2 +-
drivers/net/irda/ali-ircc.c |2 +-
drivers/net/irda/nsc-ircc.c |2 +-
drivers/s390/scsi/zfcp_dbf.c |6 +++---
drivers/scsi/bnx2i/bnx2i_hwi.c| 16
drivers/scsi/bnx2i/bnx2i_iscsi.c | 14 +++---
drivers/scsi/ncr53c8xx.c |2 +-
drivers/scsi/sym53c8xx_2/sym_glue.h |2 +-
drivers/staging/iio/adc/ad7606.h |2 +-
include/linux/amba/serial.h |2 +-
include/linux/mfd/si476x-core.h |2 +-
include/linux/netdevice.h |2 +-
include/net/bluetooth/l2cap.h |2 +-
net/can/af_can.c |2 +-
net/netfilter/xt_set.c|4 ++--
19 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/mips/include/asm/octeon/cvmx-pip.h
b/arch/mips/include/asm/octeon/cvmx-pip.h
index a76fe5a..df69bfd 100644
--- a/arch/mips/include/asm/octeon/cvmx-pip.h
+++ b/arch/mips/include/asm/octeon/cvmx-pip.h
@@ -192,13 +192,13 @@ typedef struct {
/* Number of packets processed by PIP */
uint32_t packets;
/*
-* Number of indentified L2 multicast packets. Does not
+* Number of identified L2 multicast packets. Does not
* include broadcast packets. Only includes packets whose
* parse mode is SKIP_TO_L2
*/
uint32_t multicast_packets;
/*
-* Number of indentified L2 broadcast packets. Does not
+* Number of identified L2 broadcast packets. Does not
* include multicast packets. Only includes packets whose
* parse mode is SKIP_TO_L2
*/
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 1414c90..0641113 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -1,5 +1,5 @@
/*
- * Routines to indentify caches on Intel CPU.
+ * Routines to identify caches on Intel CPU.
*
* Changes:
* Venkatesh Pallipadi : Adding cache identification through cpuid(4)
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index f2cc63e..b6f794a 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -1,5 +1,5 @@
/*
- * Routines to indentify additional cpu features that are scattered in
+ * Routines to identify additional cpu features that are scattered in
* cpuid space.
*/
#include
diff --git a/drivers/media/rc/keymaps/rc-dib0700-nec.c
b/drivers/media/rc/keymaps/rc-dib0700-nec.c
index 4d13a7f..492a05a 100644
--- a/drivers/media/rc/keymaps/rc-dib0700-nec.c
+++ b/drivers/media/rc/keymaps/rc-dib0700-nec.c
@@ -5,7 +5,7 @@
* TODO: This table is a real mess, as it merges RC codes from several
* devices into a big table. It also has both RC-5 and NEC codes inside.
* It should be broken into small tables, and the protocols should properly
- * be indentificated.
+ * be identificated.
*
* The table were imported from dib0700_devices.c.
*
diff --git a/drivers/media/rc/keymaps/rc-dib0700-rc5.c
b/drivers/media/rc/keymaps/rc-dib0700-rc5.c
index ba81d96..454ea59 100644
--- a/drivers/media/rc/keymaps/rc-dib0700-rc5.c
+++ b/drivers/media/rc/keymaps/rc-dib0700-rc5.c
@@ -5,7 +5,7 @@
* TODO: This table is a real mess, as it merges RC codes from several
* devices into a big table. It also has both RC-5 and NEC codes inside.
* It should be broken into small tables, and the protocols should properly
- * be indentificated.
+ * be identificated.
*
* The table were imported from dib0700_devices.c.
*
diff --git a/drivers/net/irda/ali-ircc.c b/drivers/net/irda/ali-ircc.c
index 7bbd318..befa45f 100644
--- a/drivers/net/irda/ali-ircc.c
+++ b/drivers/net/irda/ali-ircc.c
@@ -627,7 +627,7 @@ static int ali_ircc_setup(chipio_t *info)
/*
* Function ali_ircc_read_dongle_id (int index, info)
*
- * Try to read dongle indentification. This procedure needs to be executed
+ * Try to read dongle identification. This procedure needs to be executed
* once after power-on/reset. It also needs to be used whenever you suspect
* that the user may have plugged/unplugged the IrDA Dongle.
*/
diff --git a/drivers/net/irda/nsc-ircc.c b/drivers/net/irda/nsc-ircc.c
index ceeb537..66bc03b 100644
--- a/drivers/net/irda/nsc-ircc.c
+++ b/drivers/net/irda/nsc-ircc.c
@@ -1035,7 +1035,7 @@ static int nsc_ircc_setup(chipio_t *info)
/*
* Function nsc_ircc_read_dongle_id (void)
*
- * Try to read dongle indentification. This procedure needs to be
RE: [patch x86/hyperv] x86, hyperv: Fix build error
On Fri, 11 Oct 2013, KY Srinivasan wrote:
> > From: David Rientjes [mailto:rient...@google.com]
> > Sent: Friday, October 11, 2013 4:08 PM
> > To: Ingo Molnar; H. Peter Anvin; t...@linutronix.de; H. Peter Anvin
> > Cc: KY Srinivasan; Olaf Hering; linux-kernel@vger.kernel.org; linux-tip-
> > comm...@vger.kernel.org
> > Subject: [patch x86/hyperv] x86, hyperv: Fix build error
> >
> > 9e7827b5ea4c ("x86, hyperv: Get the local APIC timer frequency from the
> > hypervisor") breaks the build with some configs because apic.h isn't
> > directly included:
> >
> > arch/x86/kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform':
> > arch/x86/kernel/cpu/mshyperv.c:90:3: error: 'lapic_timer_frequency'
> > undeclared
> > (first use in this function)
> > arch/x86/kernel/cpu/mshyperv.c:90:3: note: each undeclared identifier is
> > reported only once for each function it appears in
> >
> > Fix it by including asm/apic.h.
>
> Thank you. The issue was configuration related - local APIC was not
> configured. This has already been fixed.
>
Yeah, it's config related as stated in the changelog. If you're referring
to 90ab9d551093 ("x86, hyperv: Correctly guard the local APIC calibration
code ")as "fixing" it, it does not. (I'm left to wonder what you mean by
it being fixed since you didn't elaborate.) You can trigger this build
breakage even with CONFIG_X86_LOCAL_APIC=y.
Let me be explicit: this file includes desc.h, which includes linux/smp.h,
which includes asm/smp.h iff CONFIG_SMP is enabled. That's what you're
relying upon to get asm/apic.h when CONFIG_X86_LOCAL_APIC is enabled. It
will break when CONFIG_SMP is disabled.
So you need to include asm/apic.h directly for such a configuration.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 tip/core/rcu 03/14] bridge: Apply ACCESS_ONCE() to avoid sparse false positive
From: "Paul E. McKenney" The sparse checking for rcu_assign_pointer() was recently upgraded to reject non-__kernel address spaces. This also rejects __rcu, which is almost always the right thing to do. However, the uses in br_multicast_del_pg() and br_multicast_new_port_group() are legitimate: They are assigning a pointer to an element from an RCU-protected list, and all elements of this list are already visible to caller. This commit therefore silences these false positives by laundering the pointers using ACCESS_ONCE() as suggested by Eric Dumazet and Josh Triplett. Reported-by: kbuild test robot Signed-off-by: Paul E. McKenney Cc: Stephen Hemminger Cc: "David S. Miller" Cc: bri...@lists.linux-foundation.org Cc: net...@vger.kernel.org --- net/bridge/br_multicast.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c index d1c578630678..bcc4bbc16498 100644 --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -267,7 +267,7 @@ static void br_multicast_del_pg(struct net_bridge *br, if (p != pg) continue; - rcu_assign_pointer(*pp, p->next); + ACCESS_ONCE(*pp) = p->next; /* OK: Both --rcu and visible. */ hlist_del_init(>mglist); del_timer(>timer); call_rcu_bh(>rcu, br_multicast_free_pg); @@ -646,7 +646,7 @@ struct net_bridge_port_group *br_multicast_new_port_group( p->addr = *group; p->port = port; p->state = state; - rcu_assign_pointer(p->next, next); + ACCESS_ONCE(p->next) = next; /* OK: Both --rcu and visible. */ hlist_add_head(>mglist, >mglist); setup_timer(>timer, br_multicast_port_group_expired, (unsigned long)p); -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 tip/core/rcu 12/14] bonding/bond_main: Apply ACCESS_ONCE() to avoid sparse false positive
From: "Paul E. McKenney"
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the uses in
bond_change_active_slave(), bond_enslave(), and __bond_release_one()
are legitimate: They are assigning a pointer to an element from an
RCU-protected list (or a NULL pointer), and all elements of this list
are already visible to caller.
This commit therefore silences these false positives either by laundering
the pointers using ACCESS_ONCE() as suggested by Eric Dumazet and Josh
Triplett, or by using RCU_INIT_POINTER() for NULL pointer assignments.
Reported-by: kbuild test robot
Signed-off-by: Paul E. McKenney
Cc: Stephen Hemminger
Cc: "David S. Miller"
Cc: bri...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
---
drivers/net/bonding/bond_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 72df399c4ab3..e4270ae1c0a8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -890,7 +890,8 @@ void bond_change_active_slave(struct bonding *bond, struct
slave *new_active)
if (new_active)
bond_set_slave_active_flags(new_active);
} else {
- rcu_assign_pointer(bond->curr_active_slave, new_active);
+ /* Both --rcu and visible, so ACCESS_ONCE() is OK. */
+ ACCESS_ONCE(bond->curr_active_slave) = new_active;
}
if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
@@ -1601,7 +1602,8 @@ int bond_enslave(struct net_device *bond_dev, struct
net_device *slave_dev)
* so we can change it without calling change_active_interface()
*/
if (!bond->curr_active_slave && new_slave->link == BOND_LINK_UP)
- rcu_assign_pointer(bond->curr_active_slave, new_slave);
+ /* Both --rcu and visible, so ACCESS_ONCE() is OK. */
+ ACCESS_ONCE(bond->curr_active_slave) = new_slave;
break;
} /* switch(bond_mode) */
@@ -1801,7 +1803,7 @@ static int __bond_release_one(struct net_device *bond_dev,
}
if (all) {
- rcu_assign_pointer(bond->curr_active_slave, NULL);
+ RCU_INIT_POINTER(bond->curr_active_slave, NULL);
} else if (oldcurrent == slave) {
/*
* Note that we hold RTNL over this sequence, so there
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks
On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > On Fri, Oct 11, 2013 at 08:25:17AM -0400, Jeff Layton wrote: > > At LSF this year, there was a discussion about the "wishlist" for > > userland file servers. One of the things brought up was the goofy and > > problematic behavior of POSIX locks when a file is closed. Boaz started > > a thread on it here: > > > >http://permalink.gmane.org/gmane.linux.file-systems/73364 > > > > Userland fileservers often need to maintain more than one open file > > descriptor on a file. The POSIX spec says: > > > > "All locks associated with a file for a given process shall be removed > > when a file descriptor for that file is closed by that process or the > > process holding that file descriptor terminates." > > > > This is problematic since you can't close any file descriptor without > > dropping all your POSIX locks. Most userland file servers therefore > > end up opening the file with more access than is really necessary, and > > keeping fd's open for longer than is necessary to work around this. > > > > This patchset is a first stab at an approach to address this problem by > > adding two new l_type values -- F_RDLCKP and F_WRLCKP (the 'P' is short > > for "private" -- I'm open to changing that if you have a better > > mnemonic). > > > > For all intents and purposes these lock types act just like their > > "non-P" counterpart. The difference is that they are only implicitly > > released when the fd against which they were acquired is closed. As a > > side effect, these locks cannot be merged with "non-P" locks since they > > have different semantics on close. > > It isn't explicitly stated here, but will the POSIX and non-POSIX > locks interact with each other? For example, if one process is using > the old POSIX semantics for lock release, but another process is using > the new non-POSIX semantics for lock release, will the two locks > otherwise behave as expected and conflict with each other if needed? > > Cheers, Andreas > Yes, they'll still conflict with "legacy" POSIX locks. The idea is to keep mutual exclusion with "legacy" POSIX locks, but give them more flock()-like semantics with respect to dealing with multiple open file descriptors. By doing this, we allow these programs to keep working in parallel with those that don't use the new lock types. > > I've given this patchset some very basic smoke testing and it seems to > > do the right thing, but it is still pretty rough. If this looks > > reasonable I'll plan to do some documentation updates and will take a > > stab at trying to get these new lock types added to the POSIX spec (as > > HCH recommended). > > > > At this point, my main questions are: > > > > 1) does this look useful, particularly for fileserver implementors? > > > > 2) does this look OK API-wise? We could consider different "cmd" values > > or even different syscalls, but I figured this makes it clearer that > > "P" and "non-P" locks will still conflict with one another. > > > Cheers, Andreas > > > > > -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 tip/core/rcu 01/14] rcu: Add comment on evaluate-once properties of rcu_assign_pointer().
From: "Paul E. McKenney" The rcu_assign_pointer() macro, as with most cpp macros, must not evaluate its argument more than once. And it in fact does not. But this might not be obvious to the casual observer, because one of the arguments appears no less than three times. However, but one expansion is only visible to sparse (__CHECKER__), and one lives inside a typeof (where it will never be evaluated), so this is in fact safe. This commit therefore adds a comment making this explicit. Reported-by: Josh Triplett Signed-off-by: Paul E. McKenney --- include/linux/rcupdate.h | 8 1 file changed, 8 insertions(+) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index f1f1bc39346b..f4da2175cde0 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -911,6 +911,14 @@ static inline notrace void rcu_read_unlock_sched_notrace(void) * rcu_assign_pointer() is a very bad thing that results in * impossible-to-diagnose memory corruption. So please be careful. * See the RCU_INIT_POINTER() comment header for details. + * + * Note that rcu_assign_pointer() evaluates each of its arguments only + * once, appearances notwithstanding. One of the "extra" evaluations + * is in typeof() and the other visible only to sparse (__CHECKER__), + * neither of which actually execute the argument. As with most cpp + * macros, this execute-arguments-only-once property is important, so + * please be careful when making changes to rcu_assign_pointer() and the + * other macros that it invokes. */ #define rcu_assign_pointer(p, v) \ __rcu_assign_pointer((p), (v), __rcu) -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 tip/core/rcu 06/14] ipv4/ip_socketglue: Apply ACCESS_ONCE() to avoid sparse false positive
From: "Paul E. McKenney" The sparse checking for rcu_assign_pointer() was recently upgraded to reject non-__kernel address spaces. This also rejects __rcu, which is almost always the right thing to do. However, the use in ip_ra_control() is legitimate: It is assigning a pointer to an element from an RCU-protected list, and all elements of this list are already visible to caller. This commit therefore silences this false positive by laundering the pointer using ACCESS_ONCE() as suggested by Eric Dumazet and Josh Triplett. Reported-by: kbuild test robot Signed-off-by: Paul E. McKenney Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: James Morris Cc: Hideaki YOSHIFUJI Cc: Patrick McHardy Cc: net...@vger.kernel.org --- net/ipv4/ip_sockglue.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c index d9c4f113d709..a0e7f176e9c8 100644 --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -269,7 +269,8 @@ int ip_ra_control(struct sock *sk, unsigned char on, } /* dont let ip_call_ra_chain() use sk again */ ra->sk = NULL; - rcu_assign_pointer(*rap, ra->next); + /* Both --rcu and visible, so ACCESS_ONCE() is OK. */ + ACCESS_ONCE(*rap) = ra->next; spin_unlock_bh(_ra_lock); if (ra->destructor) -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
