Re: [PATCH 01/52] perf tools: Fix jump label always changing during tracing
On Wed, Jul 23, 2014 at 09:07:32AM +0300, Adrian Hunter wrote: > On 07/22/2014 05:11 PM, Peter Zijlstra wrote: > > On Tue, Jul 22, 2014 at 11:00:34AM -0300, Arnaldo Carvalho de Melo wrote: > >> Em Tue, Jul 22, 2014 at 04:17:10PM +0300, Adrian Hunter escreveu: > >>> Intel PT decoding walks the object code to reconstruct > >>> the trace. A jump label change during tracing causes > >>> decoding errors. > > > > You'd better fix that, jump_labels can change any time and they're all > > over the frigging place. > > > > Perhaps a general method is needed to be able to deal with kernel > self-modifying code. I know people are looking at doing the same to userspace, is that also a problem? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/16] cpufreq: Add cpufreq driver for Tegra124
On 23 July 2014 12:24, Thierry Reding wrote:
> On Wed, Jul 23, 2014 at 10:14:44AM +0530, Viresh Kumar wrote:
>> On 21 July 2014 21:09, Tuomas Tynkkynen wrote:
>>
>> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> > index 7364a53..df3c73e 100644
>> > --- a/drivers/cpufreq/Kconfig.arm
>> > +++ b/drivers/cpufreq/Kconfig.arm
>> > @@ -244,6 +244,7 @@ config ARM_SPEAR_CPUFREQ
>> > config ARM_TEGRA_CPUFREQ
>> > bool "TEGRA CPUFreq support"
>> > depends on ARCH_TEGRA
>> > + depends on GENERIC_CPUFREQ_CPU0
>>
>> Wouldn't this also disturb the existing cpufreq driver for earlier
>> tegra platforms? i.e. we don't need cpufreq-cpu0 for them
>> atleast as of now.
>
> Perhaps this should be "select" rather than "depends on"?
Don't know, its not optionaly for tegra124 and so a "depends on"
might fit better ?
>> > +static int tegra124_cpufreq_probe(struct platform_device *pdev)
>> > +{
>> > + int ret;
>> > +
>> > + cpu_dev = get_cpu_device(0);
>> > + if (!cpu_dev)
>> > + return -ENODEV;
>> > +
>>
>> Shouldn't we do a of_node_get() here?
>
> I think this would need to be get_device() since it's the struct device
> that's being used subsequently.
Probably I didn't write it well..
What I meant was after doing a get_cpu_device() we might also need
to do of_node_get(cpu_dev->of_node) as we would be using of_node
in further code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] futex: introduce an optimistic spinning futex
On Wed, Jul 23, 2014 at 06:55:03AM +0200, Mike Galbraith wrote: > On Mon, 2014-07-21 at 09:42 -0700, Andi Kleen wrote: > > > FWIW the main problem is currently that switch-through-idle is so > > slow. I think improving that would give a boost to far more > > situations. > > Two high frequency idle enter/exit suckage spots: > > 1) nohz (tick) - it's expensive to start/stop tick on every micro-idle, > throttle it or something. Yeah, so the idea was to use the cpuidle idle guestimator to control this, and now that we've moved it somewhat closer to the scheduler that might become possible. > 2) ondemand governor - tweak silly default settings to reflect the > reality that we routinely schedule communicating threads cross core. Yeah, so the plan is to shoot cpufreq in the head and base the replacement on smp aware metrics ;-) Its on a todo list somewhere.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc
On Tue, Jul 22, 2014 at 08:01:01AM -0700, Guenter Roeck wrote: > Both functions were introduced to let gpio drivers request their own > gpio pins. Without exporting the functions, this can however only be > used by gpio drivers built into the kernel. > > Secondary impact is that the functions can not currently be used by > platform initialization code associated with the gpio-pca953x driver. > This code permits auto-export of gpio pins through platform data, but > if this functionality is used, the module can no longer be unloaded due > to the problem solved with the introduction of gpiochip_request_own_desc > and gpiochip_free_own_desc. > > Export both function so they can be used from modules and from > platform initialization code. > > Cc: Mika Westerberg Looks good to me, thanks. Reviewed-by: Mika Westerberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/16] cpufreq: Add cpufreq driver for Tegra124
On Wed, Jul 23, 2014 at 10:14:44AM +0530, Viresh Kumar wrote:
> On 21 July 2014 21:09, Tuomas Tynkkynen wrote:
>
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index 7364a53..df3c73e 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -244,6 +244,7 @@ config ARM_SPEAR_CPUFREQ
> > config ARM_TEGRA_CPUFREQ
> > bool "TEGRA CPUFreq support"
> > depends on ARCH_TEGRA
> > + depends on GENERIC_CPUFREQ_CPU0
>
> Wouldn't this also disturb the existing cpufreq driver for earlier
> tegra platforms? i.e. we don't need cpufreq-cpu0 for them
> atleast as of now.
Perhaps this should be "select" rather than "depends on"?
> > +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> > +{
> > + int ret;
> > +
> > + cpu_dev = get_cpu_device(0);
> > + if (!cpu_dev)
> > + return -ENODEV;
> > +
>
> Shouldn't we do a of_node_get() here?
I think this would need to be get_device() since it's the struct device
that's being used subsequently.
Thierry
pgp3vOPVTVbVH.pgp
Description: PGP signature
Re: [PATCH v1 2/3] mtd: hisilicon: add a new nand controller driver for hisilicon hip04 Soc
On 2014年07月15日 18:58, Zhou Wang wrote: Signed-off-by: Zhou Wang --- drivers/mtd/nand/Kconfig |5 + drivers/mtd/nand/Makefile|1 + drivers/mtd/nand/hisi_nand.c | 836 ++ 3 files changed, 842 insertions(+) create mode 100644 drivers/mtd/nand/hisi_nand.c Hi David Woodhouse and Brian Norris, Is there anything I should modify about this NAND controller driver? It would be appreciated that I could get some comments from you. Best regarts, Zhou diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 90ff447..253f8c8 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -510,4 +510,9 @@ config MTD_NAND_XWAY Enables support for NAND Flash chips on Lantiq XWAY SoCs. NAND is attached to the External Bus Unit (EBU). +config MTD_NAND_HISI + tristate "Support for NAND controller on Hisilicon SoC" + help + Enables support for NAND controller on Hisilicon SoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 542b568..d0881cf 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ +obj-$(CONFIG_MTD_NAND_HISI)+= hisi_nand.o nand-objs := nand_base.o nand_bbt.o diff --git a/drivers/mtd/nand/hisi_nand.c b/drivers/mtd/nand/hisi_nand.c new file mode 100644 index 000..c5142bb --- /dev/null +++ b/drivers/mtd/nand/hisi_nand.c @@ -0,0 +1,836 @@ +/* + * Hisilicon NAND Flash controller driver + * + * Copyright © 2012-2014 HiSilicon Technologies Co., Ltd. + * http://www.hisilicon.com + * + * Author: Zhou Wang + * The initial developer of the original code is Zhiyong Cai + * + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HINFC504_MAX_CHIP (4) +#define HINFC504_W_LATCH(5) +#define HINFC504_R_LATCH(7) +#define HINFC504_RW_LATCH (3) + +#define HINFC504_NFC_TIMEOUT (2 * HZ) +#define HINFC504_NFC_DMA_TIMEOUT (5 * HZ) +#define HINFC504_CHIP_DELAY(25) + +#define HINFC504_REG_BASE_ADDRESS_LEN (0x100) +#define HINFC504_BUFFER_BASE_ADDRESS_LEN (2048 + 128) + +#define HINFC504_ADDR_CYCLE_MASK 0x4 + +#define HINFC504_CON 0x00 +#define HINFC504_CON_OP_MODE_NORMAL(1U << 0) +#define HINFC504_CON_PAGEISZE_SHIFT(1) +#define HINFC504_CON_PAGESIZE_MASK (0x07) +#define HINFC504_CON_BUS_WIDTH (1U << 4) +#define HINFC504_CON_READY_BUSY_SEL(1U << 8) +#define HINFC504_CON_ECCTYPE_SHIFT (9) +#define HINFC504_CON_ECCTYPE_MASK (0x07) + +#define HINFC504_PWIDTH0x04 +#define SET_HINFC504_PWIDTH(_w_lcnt, _r_lcnt, _rw_hcnt) \ + ((_w_lcnt) | (((_r_lcnt) & 0x0F) << 4) | (((_rw_hcnt) & 0x0F) << 8)) + +#define HINFC504_CMD 0x0C +#define HINFC504_ADDRL 0x10 +#define HINFC504_ADDRH 0x14 +#define HINFC504_DATA_NUM 0x18 + +#define HINFC504_OP0x1C +#define HINFC504_OP_READ_DATA_EN (1U << 1) +#define HINFC504_OP_WAIT_READY_EN (1U << 2) +#define HINFC504_OP_CMD2_EN(1U << 3) +#define HINFC504_OP_WRITE_DATA_EN (1U << 4) +#define HINFC504_OP_ADDR_EN(1U << 5) +#define HINFC504_OP_CMD1_EN(1U << 6) +#define HINFC504_OP_NF_CS_SHIFT(7) +#define HINFC504_OP_NF_CS_MASK (3) +#define HINFC504_OP_ADDR_CYCLE_SHIFT (9) +#define HINFC504_OP_ADDR_CYCLE_MASK(7) + +#define HINFC504_STATUS0x20 +#define
Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences
Am 23.07.2014 08:40, schrieb Maarten Lankhorst: op 22-07-14 17:59, Christian König schreef: Am 22.07.2014 17:42, schrieb Daniel Vetter: On Tue, Jul 22, 2014 at 5:35 PM, Christian König wrote: Drivers exporting fences need to provide a fence->signaled and a fence->wait function, everything else like fence->enable_signaling or calling fence_signaled() from the driver is optional. Drivers wanting to use exported fences don't call fence->signaled or fence->wait in atomic or interrupt context, and not with holding any global locking primitives (like mmap_sem etc...). Holding locking primitives local to the driver is ok, as long as they don't conflict with anything possible used by their own fence implementation. Well that's almost what we have right now with the exception that drivers are allowed (actually must for correctness when updating fences) the ww_mutexes for dma-bufs (or other buffer objects). In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. But how does that then work right now? My impression was that it's mandatory for drivers to call fence_signaled()? It's only mandatory to call fence_signal() if the .enable_signaling callback has been called, else you can get away with never calling signaling a fence at all before dropping the last refcount to it. This allows you to keep interrupts disabled when you don't need them. Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? Agreed that any shared locks are out of the way (especially stuff like dev->struct_mutex or other non-strictly driver-private stuff, i915 is really bad here still). Yeah that's also an point I've wanted to note on Maartens patch. Radeon grabs the read side of it's exclusive semaphore while waiting for fences (because it assumes that the fence it waits for is a Radeon fence). Assuming that we need to wait in both directions with Prime (e.g. Intel driver needs to wait for Radeon to finish rendering and Radeon needs to wait for Intel to finish displaying), this might become a perfect example of locking inversion. In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. That's actually not such a good idea. In case of a lockup we need to handle the lockup cause otherwise it could happen that radeon waits for the lockup to be resolved and the lockup handling needs to wait for a fence that's never signaled because of the lockup. Christian. This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. So from the core fence framework I think we already have exactly this, and we only need to adjust the radeon implementation a bit to make it less risky and invasive to the radeon driver logic. Agree. Well the biggest problem I see is that exclusive semaphore I need to take when anything calls into the driver. For the fence code I need to move that down into the fence->signaled handler, cause that now can be called from outside the driver. Maarten solved this by telling the driver in the lockup handler (where we grab the write side of the exclusive lock) that all interrupts are already enabled, so that fence->signaled hopefully wouldn't mess with the hardware at all. While this probably works, it just leaves me with a feeling that we are doing something wrong here. There is unfortunately no global mechanism to say 'this card is locked up, please don't call into any of my fences', and I don't associate fences with devices, and radeon doesn't keep a global list of fences. If all of that existed, it would complicate the interface and its callers a lot, while I like to keep things simple. So I did the best I could, and simply prevented the fence calls from fiddling with the hardware. Fortunately gpu lockup is not a common operation. :-) ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
On Tue, Jul 22, 2014 at 08:37:19PM -0500, Bruno Wolff III wrote: >build_sched_domain: cpu: 0 level: SMT cpu_map: 0-3 tl->mask: > 0,2 > [0.252441] build_sched_domain: cpu: 0 level: MC cpu_map: 0-3 tl->mask: 0,2 > [0.252526] build_sched_domain: cpu: 0 level: DIE cpu_map: 0-3 tl->mask: > 0-3 W00t! that seems to have cured it. Thanks Bruno, I'll go write up a proper changelog and such. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/25] AMDKFD kernel driver
On 22/07/14 14:15, Daniel Vetter wrote: On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote: On 22/07/14 12:21, Daniel Vetter wrote: On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay wrote: Exactly, just prevent userspace from submitting more. And if you have misbehaving userspace that submits too much, reset the gpu and tell it that you're sorry but won't schedule any more work. I'm not sure how you intend to know if a userspace misbehaves or not. Can you elaborate ? Well that's mostly policy, currently in i915 we only have a check for hangs, and if userspace hangs a bit too often then we stop it. I guess you can do that with the queue unmapping you've describe in reply to Jerome's mail. -Daniel What do you mean by hang ? Like the tdr mechanism in Windows (checks if a gpu job takes more than 2 seconds, I think, and if so, terminates the job). Essentially yes. But we also have some hw features to kill jobs quicker, e.g. for media workloads. -Daniel Yeah, so this is what I'm talking about when I say that you and Jerome come from a graphics POV and amdkfd come from a compute POV, no offense intended. For compute jobs, we simply can't use this logic to terminate jobs. Graphics are mostly Real-Time while compute jobs can take from a few ms to a few hours!!! And I'm not talking about an entire application runtime but on a single submission of jobs by the userspace app. We have tests with jobs that take between 20-30 minutes to complete. In theory, we can even imagine a compute job which takes 1 or 2 days (on larger APUs). Now, I understand the question of how do we prevent the compute job from monopolizing the GPU, and internally here we have some ideas that we will probably share in the next few days, but my point is that I don't think we can terminate a compute job because it is running for more than x seconds. It is like you would terminate a CPU process which runs more than x seconds. I think this is a *very* important discussion (detecting a misbehaved compute process) and I would like to continue it, but I don't think moving the job submission from userspace control to kernel control will solve this core problem. Oded -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] avr32: Remove unnessary variables from page.h
Around Wed 23 Jul 2014 02:42:36 -0400 or thereabout, Nicholas Krause wrote:
> This removes the unneeded variables memory_start and memory_end in
> order to fix this fix me message.
>
> Signed-off-by: Nicholas Krause
This is already applied to my local for-linus branch, it will be pushed once
Linus opens up for merges after 3.16 is released.
> ---
> arch/avr32/include/asm/page.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/avr32/include/asm/page.h b/arch/avr32/include/asm/page.h
> index f805d1c..701006f 100644
> --- a/arch/avr32/include/asm/page.h
> +++ b/arch/avr32/include/asm/page.h
> @@ -42,8 +42,6 @@ typedef struct page *pgtable_t;
> #define __pgd(x) ((pgd_t) { (x) })
> #define __pgprot(x) ((pgprot_t) { (x) })
>
> -/* FIXME: These should be removed soon */
> -extern unsigned long memory_start, memory_end;
>
> /* Pure 2^n version of get_order */
> static inline int get_order(unsigned long size)
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Random panic in load_balance() with 3.16-rc
On Tue, Jul 22, 2014 at 09:21:40PM -0700, Linus Torvalds wrote: > On Tue, Jul 22, 2014 at 8:53 PM, Michel Dänzer wrote: > > > > Just happened again with the same change on top of 3.16-rc6. > > The (maybe) related bugzilla entry is just odd. Bruno Wolff reports > that the BUG_ON() in his added patch triggers: > > + cpumask_clear(sched_group_cpus(sg)); > + sg->sgc->capacity = 0; > + BUG_ON(!cpumask_empty(sched_group_cpus(sg))); > > where it *just* did a cpumask_clear(), and now the BUG_ON() triggers > that it's no longer empty? > > That would imply an allocation error, but all the sched groups seem to > be properly allocated with the proper addition of cpumask_size(). > > And his config file even has NR_CPUS being 32, so it should be a > single word of bitmap, which triggers all the simple code. > > Completely insane, in other words. So we've had this other thread where the same happened: lkml.kernel.org/r/20140716145546.ga6...@wolff.to (pointed Michel to that earlier) And that seems to be sorted now (just found positive feedback in my Inbox this morning), it was a question of the arch code supplying completely 'broken' topology information, and the scheduler trusting it too much. The real fix in that thread is: lkml.kernel.org/r/20140722133514.gm12...@laptop.lan And I'll also add this to make the scheduler less trusting: lkml.kernel.org/r/20140722094740.gj12...@laptop.lan Michael, that's not going to tell us what's wrong with your machine, as you've not got the ancient dual P4 Xeon Bruno's got. Seeing how your cpuinfo says: model name : AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G but we can start the same debugging session I suppose. Could you run with this patch on top: lkml.kernel.org/r/20140718101633.gp9...@twins.programming.kicks-ass.net And provide us with the dmesg after boot? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: smp-cmp.c: CDFIXMES
On Wed, Jul 23, 2014 at 12:40:59AM -0400, Nick Krause wrote: > Are the lines with CDFIXME still needed? If not please tell me as I > will send in a patch removing these > two from this file in order to help you guys out :). > Cheers Nick Hi Nick, I imagine the only answer any of us can give you is "we don't know". If we did then we'd have removed the code or the comments already. Please do note that the smp-cmp.c file lives behind a Kconfig option that is now marked as deprecated, and that there is other work going on in areas related to clocksource & clock events on the applicable systems. So whilst someone could spend the time figuring out whether those lines are useful, I expect that cleaning up these old FIXMEs is not a particularly high priority for anyone right now. If you'll leave them alone for a while I expect they'll disappear one way or another in a few cycles time, along with the rest of the file. Thanks, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] ACPI/NVS: Not save NVS region for new machine to accelerate S3
NVS region is saved and restored unconditionally for machines without
nvs_nosave quirk during S3. Tested some new machines and the operation
is not necessary. Saving NVS region also affects S2RAM speed. The time of
NVS saving and restoring depends on the size of NVS region and it consumes
7~10ms normally.
This patch is to make machines produced from 2012 to now not saving NVS region
to accelerate S3.
Signed-off-by: Lan Tianyu
---
Change since V1:
Change the order between checking acpisleep quirk table and setting
the flag of nosaving nvs for S3.
drivers/acpi/sleep.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index b3e3cc7..54da4a3 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -322,6 +322,11 @@ static struct dmi_system_id acpisleep_dmi_table[]
__initdata = {
static void acpi_sleep_dmi_check(void)
{
+ int year;
+
+ if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year >= 2012)
+ acpi_nvs_nosave_s3();
+
dmi_check_system(acpisleep_dmi_table);
}
--
1.8.4.rc0.1.g8f6a3e5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: Remove unnessary variables from page.h
This removes the unneeded variables memory_start and memory_end in
order to fix this fix me message.
Signed-off-by: Nicholas Krause
---
arch/avr32/include/asm/page.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/avr32/include/asm/page.h b/arch/avr32/include/asm/page.h
index f805d1c..701006f 100644
--- a/arch/avr32/include/asm/page.h
+++ b/arch/avr32/include/asm/page.h
@@ -42,8 +42,6 @@ typedef struct page *pgtable_t;
#define __pgd(x) ((pgd_t) { (x) })
#define __pgprot(x)((pgprot_t) { (x) })
-/* FIXME: These should be removed soon */
-extern unsigned long memory_start, memory_end;
/* Pure 2^n version of get_order */
static inline int get_order(unsigned long size)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the scsi tree with the net-next tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/scsi/cxgbi/libcxgbi.h between commit fc8d0590d914 ("libcxgbi:
Add ipv6 api to driver") from the net-next tree and commit 1abf635d2f33
("scsi: use 64-bit value for 'max_luns'") from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/scsi/cxgbi/libcxgbi.h
index 8ad73d913f02,538d7a64e138..
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@@ -708,8 -692,7 +708,8 @@@ struct cxgbi_device *cxgbi_device_regis
void cxgbi_device_unregister(struct cxgbi_device *);
void cxgbi_device_unregister_all(unsigned int flag);
struct cxgbi_device *cxgbi_device_find_by_lldev(void *);
+struct cxgbi_device *cxgbi_device_find_by_netdev(struct net_device *, int *);
- int cxgbi_hbas_add(struct cxgbi_device *, unsigned int, unsigned int,
+ int cxgbi_hbas_add(struct cxgbi_device *, u64, unsigned int,
struct scsi_host_template *,
struct scsi_transport_template *);
void cxgbi_hbas_remove(struct cxgbi_device *);
signature.asc
Description: PGP signature
Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences
op 22-07-14 17:59, Christian König schreef: > Am 22.07.2014 17:42, schrieb Daniel Vetter: >> On Tue, Jul 22, 2014 at 5:35 PM, Christian König >> wrote: >>> Drivers exporting fences need to provide a fence->signaled and a fence->wait >>> function, everything else like fence->enable_signaling or calling >>> fence_signaled() from the driver is optional. >>> >>> Drivers wanting to use exported fences don't call fence->signaled or >>> fence->wait in atomic or interrupt context, and not with holding any global >>> locking primitives (like mmap_sem etc...). Holding locking primitives local >>> to the driver is ok, as long as they don't conflict with anything possible >>> used by their own fence implementation. >> Well that's almost what we have right now with the exception that >> drivers are allowed (actually must for correctness when updating >> fences) the ww_mutexes for dma-bufs (or other buffer objects). > > In this case sorry for so much noise. I really haven't looked in so much > detail into anything but Maarten's Radeon patches. > > But how does that then work right now? My impression was that it's mandatory > for drivers to call fence_signaled()? It's only mandatory to call fence_signal() if the .enable_signaling callback has been called, else you can get away with never calling signaling a fence at all before dropping the last refcount to it. This allows you to keep interrupts disabled when you don't need them. >> Locking >> correctness is enforced with some extremely nasty lockdep annotations >> + additional debugging infrastructure enabled with >> CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold >> dma-buf ww_mutexes while updating fences or waiting for them. And >> obviously for ->wait we need non-atomic context, not just >> non-interrupt. > > Sounds mostly reasonable, but for holding the dma-buf ww_mutex, wouldn't be > an RCU be more appropriate here? E.g. aren't we just interested that the > current assigned fence at some point is signaled? You can wait with RCU, without holding the ww_mutex, by calling reservation_object_wait_timeout_rcu on ttm_bo->resv. If you don't want to block you could test with reservation_object_test_signaled_rcu. Or if you want a copy of all fences without taking locks, try reservation_object_get_fences_rcu. (Might be out of date by the time the function returns if you don't hold ww_mutex, if you hold ww_mutex you probably don't need to call this function.) I didn't add non-rcu versions, but using the RCU functions would work with ww_mutex held too, probably with some small overhead. > Something like grab ww_mutexes, grab a reference to the current fence object, > release ww_mutex, wait for fence, release reference to the fence object. This is what I do currently. :-) The reservation_object that's embedded in TTM gets shared with the dma-buf, so there will be no special case needed for dma-buf at all, all objects can simply be shared and the synchronization is handled in the same way. ttm_bo_reserve and friends automatically end up locking the dma-buf too, and lockdep works on it. > >> Agreed that any shared locks are out of the way (especially stuff like >> dev->struct_mutex or other non-strictly driver-private stuff, i915 is >> really bad here still). > > Yeah that's also an point I've wanted to note on Maartens patch. Radeon grabs > the read side of it's exclusive semaphore while waiting for fences (because > it assumes that the fence it waits for is a Radeon fence). > > Assuming that we need to wait in both directions with Prime (e.g. Intel > driver needs to wait for Radeon to finish rendering and Radeon needs to wait > for Intel to finish displaying), this might become a perfect example of > locking inversion. In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. >> So from the core fence framework I think we already have exactly this, >> and we only need to adjust the radeon implementation a bit to make it >> less risky and invasive to the radeon driver logic. > > Agree. Well the biggest problem I see is that exclusive semaphore I need to > take when anything calls into the driver. For the fence code I need to move > that down into the fence->signaled handler, cause that now can be called from > outside the driver. > > Maarten solved this by telling the driver in the lockup handler (where we > grab the write side of the exclusive lock) that all interrupts are already > enabled, so that fence->signaled hopefully wouldn't mess with the hardware at > all. While this probably works, it just leaves me with a feeling that we are > doing something wrong here
[PATCH v3 1/2] pwm: rockchip: document RK3288 SoC compatible
Document new compatible for PWM founding on RK3288 SoC Signed-off-by: Caesar Wang --- Documentation/devicetree/bindings/pwm/pwm-rockchip.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt index 3182126..2b7c109 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt @@ -1,7 +1,10 @@ Rockchip PWM controller Required properties: - - compatible: should be "rockchip,rk2928-pwm" + - compatible: should be "rockchip,-pwm" + "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs + "rockchip,rk3288-pwm": found on RK3288 SoC + "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC - reg: physical base address and length of the controller's registers - clocks: phandle and clock specifier of the PWM reference clock - #pwm-cells: should be 2. See pwm.txt in this directory for a -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] This series adds support for RK3288 SoC integrated PWM
This patch will make applying on the top of Beniamino's submission, the Beniamino's submission come from [1]. [1]: https://git.kernel.org/cgit/linux/kernel/git/thierry.reding/linux-pwm.git/log/?h=for-next Beniamino's submission won't be used from genenation Rockchip SoCs. So I have to add the new pwm for next genenation Rockchip SoCs. Tested on RK3288 SDK board. Changes in v3: * address comments from Thierry Reding: - fix PWM document deccribes. - add a description for [PATCH v3 2/2]. - renamed the PWM registers - Changed in rockchip_pwm_data struct - remove the devm_ioremap(),fixed in lcdc driver. Changes in v2: * address comments from Beniamino Galvani: - remove #include . - of_iomap be removed,and devm_ioremap replace it. - remove a line no be used. Caesar Wang (2): pwm: rockchip: document RK3288 SoC compatible pwm: rockchip: Added to support for RK3288 SoC .../devicetree/bindings/pwm/pwm-rockchip.txt | 5 +- drivers/pwm/pwm-rockchip.c | 141 ++--- 2 files changed, 126 insertions(+), 20 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] pwm: rockchip: Added to support for RK3288 SoC
This patch added to support the PWM controller found on
RK3288 SoC.
Signed-off-by: Caesar Wang
---
drivers/pwm/pwm-rockchip.c | 141 +++--
1 file changed, 122 insertions(+), 19 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index eec2145..8d72a98 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -2,6 +2,7 @@
* PWM driver for Rockchip SoCs
*
* Copyright (C) 2014 Beniamino Galvani
+ * Copyright (C) 2014 Caesar Wang
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -12,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,17 +27,89 @@
#define PRESCALER 2
+#define PWM_ENABLE (1 << 0)
+#define PWM_CONTINUOUS (1 << 1)
+#define PWM_DUTY_POSITIVE (1 << 3)
+#define PWM_INACTIVE_NEGATIVE (0 << 4)
+#define PWM_OUTPUT_LEFT(0 << 5)
+#define PWM_LP_DISABLE (0 << 8)
+
struct rockchip_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
+ const struct rockchip_pwm_data *data;
void __iomem *base;
};
+struct rockchip_pwm_regs {
+ unsigned long duty;
+ unsigned long period;
+ unsigned long cntr;
+ unsigned long ctrl;
+};
+
+struct rockchip_pwm_data {
+ struct rockchip_pwm_regs regs;
+ unsigned int prescaler;
+
+ void (*set_enable)(struct pwm_chip *chip, bool enable);
+};
+
static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip
*c)
{
return container_of(c, struct rockchip_pwm_chip, chip);
}
+static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ u32 val = 0;
+ u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
+
+ val = readl_relaxed(pc->base + pc->data->regs.ctrl);
+
+ if (enable)
+ val |= enable_conf;
+ else
+ val &= ~enable_conf;
+
+ writel_relaxed(val, pc->base + pc->data->regs.ctrl);
+}
+
+static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip, bool enable)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ u32 val = 0;
+ u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
+ PWM_CONTINUOUS | PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
+
+ val = readl_relaxed(pc->base + pc->data->regs.ctrl);
+
+ if (enable)
+ val |= enable_conf;
+ else
+ val &= ~enable_conf;
+
+ writel_relaxed(val, pc->base + pc->data->regs.ctrl);
+}
+
+static void rockchip_pwm_set_enable_vop(struct pwm_chip *chip, bool enable)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ u32 val = 0;
+ u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
+ PWM_CONTINUOUS | PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
+
+ val = readl_relaxed(pc->base + pc->data->regs.ctrl);
+
+ if (enable)
+ val |= enable_conf;
+ else
+ val &= ~enable_conf;
+
+ writel_relaxed(val, pc->base + pc->data->regs.ctrl);
+}
+
static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
@@ -52,20 +126,20 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
* default prescaler value for all practical clock rate values.
*/
div = clk_rate * period_ns;
- do_div(div, PRESCALER * NSEC_PER_SEC);
+ do_div(div, pc->data->prescaler * NSEC_PER_SEC);
period = div;
div = clk_rate * duty_ns;
- do_div(div, PRESCALER * NSEC_PER_SEC);
+ do_div(div, pc->data->prescaler * NSEC_PER_SEC);
duty = div;
ret = clk_enable(pc->clk);
if (ret)
return ret;
- writel(period, pc->base + PWM_LRC);
- writel(duty, pc->base + PWM_HRC);
- writel(0, pc->base + PWM_CNTR);
+ writel(period, pc->base + pc->data->regs.period);
+ writel(duty, pc->base + pc->data->regs.duty);
+ writel(0, pc->base + pc->data->regs.cntr);
clk_disable(pc->clk);
@@ -76,15 +150,12 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
int ret;
- u32 val;
ret = clk_enable(pc->clk);
if (ret)
return ret;
- val = readl_relaxed(pc->base + PWM_CTRL);
- val |= PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
- writel_relaxed(val, pc->base + PWM_CTRL);
+ pc->data->set_enable(chip, true);
return 0;
}
@@ -92,11 +163,8 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
static void rockchip_pwm_disable(struct pw
[PATCH] tty/n_gsm.c: get gsm->num after gsm_activate_mux
gsm->num is the index of gsm_mux[], it's invalid before calling
gsm_activate_mux.
Signed-off-by: xinhui.pan
---
drivers/tty/n_gsm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 2ebe47b..81e7ccb 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2230,8 +2230,7 @@ static int gsmld_output(struct gsm_mux *gsm, u8 *data,
int len)
static int gsmld_attach_gsm(struct tty_struct *tty, struct gsm_mux *gsm)
{
- int ret, i;
- int base = gsm->num << 6; /* Base for this MUX */
+ int ret, i, base;
gsm->tty = tty_kref_get(tty);
gsm->output = gsmld_output;
@@ -2241,6 +2240,7 @@ static int gsmld_attach_gsm(struct tty_struct *tty,
struct gsm_mux *gsm)
else {
/* Don't register device 0 - this is the control channel and not
a usable tty interface */
+ base = gsm->num << 6; /* Base for this MUX */
for (i = 1; i < NUM_DLCI; i++)
tty_register_device(gsm_tty_driver, base + i, NULL);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes wrote: >> I like the sound of going to the standard ttyS notation and only >> providing ports for ones that exist, but is this userspace-visible > > ttyS is 8250 compatible UARTS. > > If the Samsung is not an 8250 compatible UART then it doesn't belong as > ttyS from the kernel perspective. OK, thanks for pointing that out. So we stick with the ttySAC namespace. And by doing that, and sticking to the existing and documented behaviour, it seems like we have already addressed Russells's concern: > The problem you're raising is very much the same problem you have when > there are multiple USB serial devices connected to the machine - you > just get a bunch of /dev/ttyUSB* devices which are unordered (they can > change on each boot, or change order if you disconnect and reconnect > them.) In this case, we have a dedicated namespace and the path information is already fully encoded in the device name. The order and number of ports are fixed, they can't be disconnected and reconnected. There is no real risk of an additional serial controller driver coming to play in the ttySAC namespace. So I think Tomasz's approach is good - although I haven't looked at the code in detail. Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/52] perf evlist: Add perf_evlist__set_tracking_event()
On 07/22/2014 10:22 PM, Jiri Olsa wrote:
> On Tue, Jul 22, 2014 at 04:17:26PM +0300, Adrian Hunter wrote:
>
> SNIP
>
>> }
>> +
>> +int perf_evlist__set_tracking_event(struct perf_evlist *evlist,
>> +struct perf_evsel *tracking_evsel)
>> +{
>> +struct perf_evsel *evsel;
>> +
>> +if (tracking_evsel->idx == 0)
>> +return 0;
>> +
>> +if (tracking_evsel->leader->nr_members > 1)
>> +return -EINVAL;
>> +
>> +list_for_each_entry(evsel, &evlist->entries, node) {
>> +if (evsel->idx < tracking_evsel->idx)
>> +evsel->idx += 1;
>> +}
>> +tracking_evsel->idx = 0;
>> +
>> +return 0;
>> +}
>
> wouldnt it be better to add evsel->is_tracking bool for this?
Yes, I will look at doing that instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/52] perf tools: Add perf_pmu__scan_file()
On 07/22/2014 10:09 PM, Jiri Olsa wrote:
> On Tue, Jul 22, 2014 at 04:17:22PM +0300, Adrian Hunter wrote:
>
> SNIP
>
>> +
>> +static FILE *perf_pmu__open_file(struct perf_pmu *pmu, const char *name)
>> +{
>> +struct stat st;
>> +char path[PATH_MAX];
>> +const char *sysfs;
>> +
>> +sysfs = sysfs__mountpoint();
>> +if (!sysfs)
>> +return NULL;
>> +
>> +snprintf(path, PATH_MAX,
>> + "%s" EVENT_SOURCE_DEVICE_PATH "%s/%s", sysfs, pmu->name, name);
>> +
>> +if (stat(path, &st) < 0)
>> +return NULL;
>> +
>> +return fopen(path, "r");
>> +}
>
> looks like this function could be used in pmu_cpumask and pmu_type
> and maybe others
There is existing code duplication between them. Given the large number of
patches I would say it is easier to deal with that separately.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] gpio: make gpiochip_get_desc() gpiolib-private
On 07/22/2014 10:39 PM, Alexandre Courbot wrote: On Wed, Jul 23, 2014 at 12:47 PM, Guenter Roeck wrote: On 07/22/2014 08:10 PM, Alexandre Courbot wrote: On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. If I implement a gpio chip driver built as module, and I want to use gpiochip_request_own_desc(), how am I supposed to get desc ? I understand that there is still gpio_to_desc(), but I would have thought that desc = gpiochip_get_desc(chip, pin); would be better than desc = gpio_to_desc(chip->base + pin); Not that it makes much of a difference for me, just asking. Actually I was thinking of changing the prototype of gpiochip_request_own_desc(), and your comment definitely strenghtens that idea. gpiochip functions should not work with descriptors, especially since we are going to switch to a multiple-consumer scheme where there won't be any canonical descriptor anymore. Thus, how about turning gpiochip_request_own_desc() into this: struct gpio_desc * gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label); which would basically do both the gpiochip_get_desc() and former gpiochip_request_own_desc() in one call. I think it should satisfy everybody and removes the need to have gpiochip_get_desc() (a not very useful function by itself) exposed out of gpiolib. I will send a patch taking care of this if you agree that makes sense. I think you also plan to remove the capability to retrieve the chip pointer, don't you ? If so, I won't be able to use the function from the pca953x platform init function, since I won't be able to get the pointer to the gpio chip. Even if you don't remove gpiod_to_chip(), things would become a bit messy, since I would first have to convert a pin to a desc and then to the chip pointer. Anyway, that change would mean that exporting gpiochip_request_own_desc or its replacement won't solve one of the problems addressed by my patch anymore, leaving me more or less in the dark :-(. Here is why this change is taking place: right now you have a clear descriptor/pin mapping, i.e. there is only one descriptor per pin, anytime. For various reasons this is going to change soon, and descriptors will be allocated the provided to GPIO consumers as an abstraction of the pin. Meaning that you cannot really "get the descriptor for that pin" anymore. Since gpiochip_request_own_desc()'s purpose is precisely to request one descriptor for drivers to use, the new prototype makes much more sense IMHO. Another reason to have it work on a gpio_chip is that the gpio_chip pointer is a token to doing certain "priviledged" operations. Like obtaining an arbitrary descriptor. If consumers can get a pointer to the gpio_chip of a descriptor, this means they can basically do anything. I understand, but my problem with pca953x platform initialization is that the code to do that is outside the gpio directory in platform code. Even though this is not consumer code, it still needs a means to perform operations on a gpio pin, whatever those means are. Being in the board code, it seems to be that you are in a good position to obtain a pointer to the gpio_chip, and without knowing better I'd say that's what you should try to do. But maybe I would understand your problem better if you could post a small patch of what you want to achieve here. Ok, but how do I get the pointer to the gpio chip from platform code if gpiod_to_chip is gone ? I attached the relevant parts of a platform file (scu.c), the one utilizing pca953x initialization code to auto-export gpio pins. It currently uses gpio_request_one(), which I am trying to replace. I can send you the complete file if you like, but it is 1,600 bytes long so I figured that would not help much. I also attached a patch that tries to replace gpio_request_one with gpiochip_request_own_desc in a gpio chip driver; maybe that gives you an idea of that part of the problem. I was thinking about implementing a separate platform driver which would enable me to auto-export (or initialize, if needed) gpio pins from arbitrary gpio drivers to user space. I could make this work with both devicetree data and platform data. Sure, that driver would not have a chance to get accepted upstream, since it would use devicetree data to, in a sense, configure the system, but on the upside it would be independent of gpio API changes, and it would work for _all_ gpio chips, not just for the ones with gpio driver support. Unfortunately this approach doesn't really work either, since exported pin names need to be configured with the chip driver, and can not be selected afterwards when a pin is actually exported. On the other side, would you agree to adding something like gpiod_export_name(), which w
[PATCH -next] staging/goldfish/goldfish_audio: fix a sparse warning
Fix a pointer check to use NULL instead of 0
Warning:
drivers/staging/goldfish/goldfish_audio.c:300:34: warning: Using plain
integer as NULL pointer
Signed-off-by: Robin Schroer
---
drivers/staging/goldfish/goldfish_audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/goldfish/goldfish_audio.c
b/drivers/staging/goldfish/goldfish_audio.c
index 9df4ad8..c89d0b8 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -297,7 +297,7 @@ static int goldfish_audio_probe(struct platform_device
*pdev)
}
data->buffer_virt = dmam_alloc_coherent(&pdev->dev,
COMBINED_BUFFER_SIZE, &buf_addr, GFP_KERNEL);
- if (data->buffer_virt == 0) {
+ if (data->buffer_virt == NULL) {
dev_err(&pdev->dev, "allocate buffer failed\n");
return -ENOMEM;
}
--
2.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: Re: [PATCH V4 1/5] trace-cmd/listen: Apply the trace-msg protocol for communication between a server and clients
Hi Steven, Thank you for your review. (2014/07/23 0:04), Steven Rostedt wrote: Sorry for taking so long to reply, I've been hacking on the kernel a bit and that takes precedence over user tools :-/ On Fri, 11 Jul 2014 00:58:26 + Yoshihiro YUNOMAE wrote: Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: listen to socket fd connect to socket fd accept the client send "tracecmd" +> receive "tracecmd" check "tracecmd" send cpus receive cpus <+ print "cpus=XXX" send pagesize | receive pagesize <+ print "pagesize=XXX" send option | receive option <--+ understand option send port_array +> receive port_array understand port_array send meta data receive meta data <---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) All messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: listen to socket fd connect to socket fd accept the client send "tracecmd" +> receive "tracecmd" check "tracecmd" send "V2\0\00" as the v2 protocol Lets change this to "-1V2\0\00" The -1 will cause an old server to exit as it will not accept a -1 for CPU count. Then you can check if the return of the next read is -1, as the client would have disconnected. Sure. The reason I ask this, is because once you send a valid CPU count (and unfortunately, 0 happens to be valid :-p, the server side creates a file. When you close it, that file stays around as zero length. By sending -1, the old server will error out and never create a file. Yes, I also thought this should be fixed. I'll submit fixed patch. Thank you, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] net: filter: split filter.c into two files
On 07/23/2014 11:31 AM, Alexei Starovoitov wrote: BPF is used in several kernel components. This split creates logical boundary between generic eBPF core and the rest kernel/bpf/core.c: eBPF interpreter net/core/filter.c: classic->eBPF converter, classic verifiers, socket filters This patch only moves functions. If we are moving the code also its good to do cleanup. Run checkpatch.pl on this... -- Regards, Varka Bhadram. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: synaptics-rmi4 - fix compiler warnings in F11
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_f11.c | 135 +++
1 file changed, 71 insertions(+), 64 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index b739d31..7af4f68 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -553,7 +553,7 @@ struct f11_data {
unsigned long *result_bits;
};
-enum finger_state_values {
+enum f11_finger_state {
F11_NO_FINGER = 0x00,
F11_PRESENT = 0x01,
F11_INACCURATE = 0x02,
@@ -563,12 +563,14 @@ enum finger_state_values {
/** F11_INACCURATE state is overloaded to indicate pen present. */
#define F11_PEN F11_INACCURATE
-static int get_tool_type(struct f11_2d_sensor *sensor, u8 finger_state)
+static int rmi_f11_get_tool_type(struct f11_2d_sensor *sensor,
+enum f11_finger_state finger_state)
{
if (IS_ENABLED(CONFIG_RMI4_F11_PEN) &&
sensor->sens_query.has_pen &&
finger_state == F11_PEN)
return MT_TOOL_PEN;
+
return MT_TOOL_FINGER;
}
@@ -603,36 +605,32 @@ static void rmi_f11_rel_pos_report(struct f11_2d_sensor
*sensor, u8 n_finger)
static void rmi_f11_abs_pos_report(struct f11_data *f11,
struct f11_2d_sensor *sensor,
- u8 finger_state, u8 n_finger)
+ enum f11_finger_state finger_state,
+ u8 n_finger)
{
struct f11_2d_data *data = &sensor->data;
+ struct input_dev *input = sensor->input;
struct rmi_f11_2d_axis_alignment *axis_align = &sensor->axis_align;
+ u8 *pos_data = &data->abs_pos[n_finger * RMI_F11_ABS_BYTES];
u16 x, y, z;
int w_x, w_y, w_max, w_min, orient;
- int temp;
- u8 abs_base = n_finger * RMI_F11_ABS_BYTES;
+ int tool_type = rmi_f11_get_tool_type(sensor, finger_state);
+
+ if (sensor->type_a) {
+ input_report_abs(input, ABS_MT_TRACKING_ID, n_finger);
+ input_report_abs(input, ABS_MT_TOOL_TYPE, tool_type);
+ } else {
+ input_mt_slot(input, n_finger);
+ input_mt_report_slot_state(input, tool_type,
+ finger_state != F11_NO_FINGER);
+ }
if (finger_state) {
- x = (data->abs_pos[abs_base] << 4) |
- (data->abs_pos[abs_base + 2] & 0x0F);
- y = (data->abs_pos[abs_base + 1] << 4) |
- (data->abs_pos[abs_base + 2] >> 4);
- w_x = data->abs_pos[abs_base + 3] & 0x0F;
- w_y = data->abs_pos[abs_base + 3] >> 4;
- w_max = max(w_x, w_y);
- w_min = min(w_x, w_y);
- z = data->abs_pos[abs_base + 4];
-
- if (axis_align->swap_axes) {
- temp = x;
- x = y;
- y = temp;
- temp = w_x;
- w_x = w_y;
- w_y = temp;
- }
+ x = (pos_data[0] << 4) | (pos_data[2] & 0x0F);
+ y = (pos_data[1] << 4) | (pos_data[2] >> 4);
- orient = w_x > w_y ? 1 : 0;
+ if (axis_align->swap_axes)
+ swap(x, y);
if (axis_align->flip_x)
x = max(sensor->max_x - x, 0);
@@ -641,13 +639,13 @@ static void rmi_f11_abs_pos_report(struct f11_data *f11,
y = max(sensor->max_y - y, 0);
/*
- * here checking if X offset or y offset are specified is
- * redundant. We just add the offsets or, clip the values
- *
- * note: offsets need to be done before clipping occurs,
- * or we could get funny values that are outside
- * clipping boundaries.
- */
+* Here checking if X offset or y offset are specified is
+* redundant. We just add the offsets or clip the values.
+*
+* Note: offsets need to be applied before clipping occurs,
+* or we could get funny values that are outside of
+* clipping boundaries.
+*/
x += axis_align->offset_x;
y += axis_align->offset_y;
x = max(axis_align->clip_x_low, x);
@@ -657,41 +655,44 @@ static void rmi_f11_abs_pos_report(struct f11_data *f11,
if (axis_align->clip_y_high)
y = min(axis_align->clip_y_high, y);
- }
+ w_x = pos_data[3] & 0x0f;
+ w_y = pos_data[3] >> 4;
- /* Some UIs ignore W of zero, so we fudge it to 1 for pens. This
-* only appears to be an issue when reporting pens, not plain old
-* fingers. */
-
Re: [PATCH 01/52] perf tools: Fix jump label always changing during tracing
On 07/22/2014 05:11 PM, Peter Zijlstra wrote: > On Tue, Jul 22, 2014 at 11:00:34AM -0300, Arnaldo Carvalho de Melo wrote: >> Em Tue, Jul 22, 2014 at 04:17:10PM +0300, Adrian Hunter escreveu: >>> Intel PT decoding walks the object code to reconstruct >>> the trace. A jump label change during tracing causes >>> decoding errors. > > You'd better fix that, jump_labels can change any time and they're all > over the frigging place. > Perhaps a general method is needed to be able to deal with kernel self-modifying code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/52] perf tools: Fix jump label always changing during tracing
On 07/22/2014 05:00 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 22, 2014 at 04:17:10PM +0300, Adrian Hunter escreveu: >> Intel PT decoding walks the object code to reconstruct >> the trace. A jump label change during tracing causes >> decoding errors. >> >> The "Enable close-on-exec flag on perf file descriptor" >> patch caused there to be always a jump label change. >> >> It was found that using a per-cpu context instead of a >> per-thread context for the probe of the close-on-exec >> feature, made the problem go away. > > And it is ok for our purposes, as this code just needs to figure out if > PERF_FLAG_FD_CLOEXEC is present, but I wonder when this kind of thing > will hit again... Possibly > > Anyway, I'll take this patch. Thanks! > > - Arnaldo > >> Signed-off-by: Adrian Hunter >> --- >> tools/perf/util/cloexec.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c >> index c5d05ec..6a37be5 100644 >> --- a/tools/perf/util/cloexec.c >> +++ b/tools/perf/util/cloexec.c >> @@ -1,3 +1,4 @@ >> +#include >> #include "util.h" >> #include "../perf.h" >> #include "cloexec.h" >> @@ -14,9 +15,13 @@ static int perf_flag_probe(void) >> }; >> int fd; >> int err; >> +int cpu = sched_getcpu(); >> + >> +if (cpu < 0) >> +cpu = 0; >> >> /* check cloexec flag */ >> -fd = sys_perf_event_open(&attr, 0, -1, -1, >> +fd = sys_perf_event_open(&attr, -1, cpu, -1, >> PERF_FLAG_FD_CLOEXEC); >> err = errno; >> >> @@ -30,7 +35,7 @@ static int perf_flag_probe(void) >>err, strerror(err)); >> >> /* not supported, confirm error related to PERF_FLAG_FD_CLOEXEC */ >> -fd = sys_perf_event_open(&attr, 0, -1, -1, 0); >> +fd = sys_perf_event_open(&attr, -1, cpu, -1, 0); >> err = errno; >> >> if (WARN_ONCE(fd < 0, >> -- >> 1.8.3.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 v4] fs: umount on symlink leaks mnt count
On Mon, 2014-07-21 at 12:30 +0400, Vasily Averin wrote: > v4: description corrected > v3: patch inline > > Currently umount on symlink blocks following umount: > > /vz is separate mount > > # ls /vz/ -al | grep test > drwxr-xr-x. 2 root root 4096 Jul 19 01:14 testdir > lrwxrwxrwx. 1 root root 11 Jul 19 01:16 testlink -> /vz/testdir > # umount -l /vz/testlink > umount: /vz/testlink: not mounted (expected) > > # lsof /vz > # umount /vz > umount: /vz: device is busy. (unexpected) > > In this case mountpoint_last() gets an extra refcount on path->mnt > > Signed-off-by: Vasily Averin Acked-by: Ian Kent I was working on this too. I prefer this patch over my own. Haven't tested it yet but it is very similar to the patch I was working with which had seen some basic testing. > --- > fs/namei.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/fs/namei.c b/fs/namei.c > index 985c6f3..9eb787e 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -2256,9 +2256,10 @@ done: > goto out; > } > path->dentry = dentry; > - path->mnt = mntget(nd->path.mnt); > + path->mnt = nd->path.mnt; > if (should_follow_link(dentry, nd->flags & LOOKUP_FOLLOW)) > return 1; > + mntget(path->mnt); > follow_mount(path); > error = 0; > out: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] serial/core: Fix too big allocation for attribute member
Current code allocates too much data for tty_groups member of uart_port struct,
so fix it.
Signed-off-by: Yoshihiro YUNOMAE
CC: Greg Kroah-Hartman
CC: Dan Carpenter
---
drivers/tty/serial/serial_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 4af764c..8ded213 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2617,7 +2617,7 @@ int uart_add_one_port(struct uart_driver *drv, struct
uart_port *uport)
if (uport->attr_group)
num_groups++;
- uport->tty_groups = kcalloc(num_groups, sizeof(**uport->tty_groups),
+ uport->tty_groups = kcalloc(num_groups, sizeof(*uport->tty_groups),
GFP_KERNEL);
if (!uport->tty_groups) {
ret = -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] net: filter: split filter.c into two files
BPF is used in several kernel components. This split creates logical boundary
between generic eBPF core and the rest
kernel/bpf/core.c: eBPF interpreter
net/core/filter.c: classic->eBPF converter, classic verifiers, socket filters
This patch only moves functions.
Signed-off-by: Alexei Starovoitov
---
kernel/Makefile |1 +
kernel/bpf/Makefile |1 +
kernel/bpf/core.c | 536 +++
net/core/filter.c | 511
4 files changed, 538 insertions(+), 511 deletions(-)
create mode 100644 kernel/bpf/Makefile
create mode 100644 kernel/bpf/core.c
diff --git a/kernel/Makefile b/kernel/Makefile
index f2a8b6246ce9..e7360b7c2c0e 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_RING_BUFFER) += trace/
obj-$(CONFIG_TRACEPOINTS) += trace/
obj-$(CONFIG_IRQ_WORK) += irq_work.o
obj-$(CONFIG_CPU_PM) += cpu_pm.o
+obj-$(CONFIG_NET) += bpf/
obj-$(CONFIG_PERF_EVENTS) += events/
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
new file mode 100644
index ..6a71145e2769
--- /dev/null
+++ b/kernel/bpf/Makefile
@@ -0,0 +1 @@
+obj-y := core.o
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
new file mode 100644
index ..77a240a1ce11
--- /dev/null
+++ b/kernel/bpf/core.c
@@ -0,0 +1,536 @@
+/*
+ * Linux Socket Filter - Kernel level socket filtering
+ *
+ * Based on the design of the Berkeley Packet Filter. The new
+ * internal format has been designed by PLUMgrid:
+ *
+ * Copyright (c) 2011 - 2014 PLUMgrid, http://plumgrid.com
+ *
+ * Authors:
+ *
+ * Jay Schulist
+ * Alexei Starovoitov
+ * Daniel Borkmann
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Andi Kleen - Fix a few bad bugs and races.
+ * Kris Katterjohn - Added many additional checks in sk_chk_filter()
+ */
+#include
+#include
+#include
+
+/* Registers */
+#define BPF_R0 regs[BPF_REG_0]
+#define BPF_R1 regs[BPF_REG_1]
+#define BPF_R2 regs[BPF_REG_2]
+#define BPF_R3 regs[BPF_REG_3]
+#define BPF_R4 regs[BPF_REG_4]
+#define BPF_R5 regs[BPF_REG_5]
+#define BPF_R6 regs[BPF_REG_6]
+#define BPF_R7 regs[BPF_REG_7]
+#define BPF_R8 regs[BPF_REG_8]
+#define BPF_R9 regs[BPF_REG_9]
+#define BPF_R10regs[BPF_REG_10]
+
+/* Named registers */
+#define DSTregs[insn->dst_reg]
+#define SRCregs[insn->src_reg]
+#define FP regs[BPF_REG_FP]
+#define ARG1 regs[BPF_REG_ARG1]
+#define CTXregs[BPF_REG_CTX]
+#define IMMinsn->imm
+
+/* No hurry in this branch
+ *
+ * Exported for the bpf jit load helper.
+ */
+void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k,
unsigned int size)
+{
+ u8 *ptr = NULL;
+
+ if (k >= SKF_NET_OFF)
+ ptr = skb_network_header(skb) + k - SKF_NET_OFF;
+ else if (k >= SKF_LL_OFF)
+ ptr = skb_mac_header(skb) + k - SKF_LL_OFF;
+ if (ptr >= skb->head && ptr + size <= skb_tail_pointer(skb))
+ return ptr;
+
+ return NULL;
+}
+
+/* Base function for offset calculation. Needs to go into .text section,
+ * therefore keeping it non-static as well; will also be used by JITs
+ * anyway later on, so do not let the compiler omit it.
+ */
+noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ return 0;
+}
+
+/**
+ * __sk_run_filter - run a filter on a given context
+ * @ctx: buffer to run the filter on
+ * @insn: filter to apply
+ *
+ * Decode and apply filter instructions to the skb->data. Return length to
+ * keep, 0 for none. @ctx is the data we are operating on, @insn is the
+ * array of filter instructions.
+ */
+static unsigned int __sk_run_filter(void *ctx, const struct sock_filter_int
*insn)
+{
+ u64 stack[MAX_BPF_STACK / sizeof(u64)];
+ u64 regs[MAX_BPF_REG], tmp;
+ static const void *jumptable[256] = {
+ [0 ... 255] = &&default_label,
+ /* Now overwrite non-defaults ... */
+ /* 32 bit ALU operations */
+ [BPF_ALU | BPF_ADD | BPF_X] = &&ALU_ADD_X,
+ [BPF_ALU | BPF_ADD | BPF_K] = &&ALU_ADD_K,
+ [BPF_ALU | BPF_SUB | BPF_X] = &&ALU_SUB_X,
+ [BPF_ALU | BPF_SUB | BPF_K] = &&ALU_SUB_K,
+ [BPF_ALU | BPF_AND | BPF_X] = &&ALU_AND_X,
+ [BPF_ALU | BPF_AND | BPF_K] = &&ALU_AND_K,
+ [BPF_ALU | BPF_OR | BPF_X] = &&ALU_OR_X,
+ [BPF_ALU | BPF_OR | BPF_K] = &&ALU_OR_K,
+ [BPF_ALU | BPF_LSH | BPF_X] = &&ALU_LSH_X,
+ [BPF_ALU | BPF_LSH | BPF_K] = &&ALU_LSH_K,
+ [BPF_ALU | BPF_RSH | BPF_X] = &&ALU_RSH_X,
+ [BPF_ALU | BPF_RSH | BPF_K] = &&ALU_RSH_K,
+ [BPF_ALU | BPF_XOR | BPF_X] = &&ALU
[PATCH net-next 0/2] net: filter: split eBPF interpreter out of core networking
Hi David, I believe my recent set of RFC/patches [1] provided good visibility on where I would like to take eBPF subsystem. These two trivial patches is a first step in that direction: patch 1 - mechanical split of eBPF interpreter out of filter.c patch 2 - nominate myself as a maintainer for eBPF core pieces In the foreseeable future eBPF patches will be going through net-next, so put netdev as a primary mailing list [1] git://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf master Alexei Starovoitov (2): net: filter: split filter.c into two files bpf: update MAINTAINERS entry MAINTAINERS |7 + kernel/Makefile |1 + kernel/bpf/Makefile |1 + kernel/bpf/core.c | 536 +++ net/core/filter.c | 511 5 files changed, 545 insertions(+), 511 deletions(-) create mode 100644 kernel/bpf/Makefile create mode 100644 kernel/bpf/core.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/2] bpf: update MAINTAINERS entry
Signed-off-by: Alexei Starovoitov --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 78215a5dea28..62bf15f6954f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1912,6 +1912,13 @@ S: Supported F: drivers/net/bonding/ F: include/uapi/linux/if_bonding.h +BPF (Safe dynamic programs and tools) +M: Alexei Starovoitov +L: net...@vger.kernel.org +L: linux-kernel@vger.kernel.org +S: Supported +F: kernel/bpf/ + BROADCOM B44 10/100 ETHERNET DRIVER M: Gary Zambrano L: net...@vger.kernel.org -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 3.16-rc6
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive a few fixups for the input subsystem. Changelog: - Bjorn Helgaas (1): Input: sirfsoc-onkey - fix GPL v2 license string typo Dmitry Torokhov (1): Input: fix defuzzing logic Felipe Balbi (1): Input: ti_am335x_tsc - warn about incorrect spelling Hans de Goede (1): Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) Jiri Kosina (1): Input: i8042 - add Acer Aspire 5710 to nomux blacklist Peter Hutterer (1): Input: document INPUT_PROP_TOPBUTTONPAD Ping Cheng (1): Input: wacom - cleanup multitouch code when touch_max is 2 Tobias Klauser (1): Input: st-keyscan - fix 'defined but not used' compiler warnings Diffstat: Documentation/input/event-codes.txt | 13 + drivers/input/input.c | 6 -- drivers/input/keyboard/st-keyscan.c | 2 ++ drivers/input/misc/sirfsoc-onkey.c| 2 +- drivers/input/mouse/synaptics.c | 5 +++-- drivers/input/serio/i8042-x86ia64io.h | 7 +++ drivers/input/tablet/wacom_wac.c | 28 +++- drivers/input/touchscreen/ti_am335x_tsc.c | 5 - 8 files changed, 41 insertions(+), 27 deletions(-) -- Dmitry signature.asc Description: Digital signature
Re: [PATCH v2 3/4] virtio: rng: delay hwrng_register() till driver is ready
Amit Shah writes: > On (Mon) 21 Jul 2014 [17:15:51], Amit Shah wrote: >> Instead of calling hwrng_register() in the probe routing, call it in the >> scan routine. This ensures that when hwrng_register() is successful, >> and it requests a few random bytes to seed the kernel's pool at init, >> we're ready to service that request. >> >> This will also enable us to remove the workaround added previously to >> check whether probe was completed, and only then ask for data from the >> host. The revert follows in the next commit. >> >> There's a slight behaviour change here on unsuccessful hwrng_register(). >> Previously, when hwrng_unregister() failed, the probe() routine would > > typo: should be hwrng_register(). > > Please fix this up when picking up the patch. Done. All 4 patches applied! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] module: return bool from within_module*()
Petr Mladek writes:
> The within_module*() functions return only true or false. Let's use bool as
> the return type.
>
> Note that it should not change kABI because these are inline functions.
>
> Signed-off-by: Petr Mladek
Thanks, applied both.
Cheers,
Rusty.
> ---
> include/linux/module.h | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 61d8fb2d0873..71f282a4e307 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -396,19 +396,21 @@ bool is_module_address(unsigned long addr);
> bool is_module_percpu_address(unsigned long addr);
> bool is_module_text_address(unsigned long addr);
>
> -static inline int within_module_core(unsigned long addr, const struct module
> *mod)
> +static inline bool within_module_core(unsigned long addr,
> + const struct module *mod)
> {
> return (unsigned long)mod->module_core <= addr &&
> addr < (unsigned long)mod->module_core + mod->core_size;
> }
>
> -static inline int within_module_init(unsigned long addr, const struct module
> *mod)
> +static inline bool within_module_init(unsigned long addr,
> + const struct module *mod)
> {
> return (unsigned long)mod->module_init <= addr &&
> addr < (unsigned long)mod->module_init + mod->init_size;
> }
>
> -static inline int within_module(unsigned long addr, const struct module *mod)
> +static inline bool within_module(unsigned long addr, const struct module
> *mod)
> {
> return within_module_init(addr, mod) || within_module_core(addr, mod);
> }
> --
> 1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, arc: remove obsolete pagefault oom killer comment
On Wednesday 23 July 2014 06:35 AM, David Rientjes wrote:
> Commit 609838cfed97 ("mm: invoke oom-killer from remaining unconverted page
> fault handlers") converted arc to call pagefault_out_of_memory(), so remove
> the comment about future conversion.
>
> Cc: Johannes Weiner
> Signed-off-by: David Rientjes
Thx David,
Applied to ARC for-next.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m68k: Remove printk statement and add return statement in q40ints.c
On 07/22/2014 09:56 PM, Nick Krause wrote:
On Wed, Jul 23, 2014 at 12:54 AM, Guenter Roeck wrote:
On 07/22/2014 09:08 PM, Nicholas Krause wrote:
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data
*data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
Returning -ENXIO from a function returning an unsigned int isn't really very
helpful,
don't you think ?
With all those FIXMEs, you might want to keep in mind that there is
typically a
good reason for it. If it was as easy as your proposed fix, you can assume
that the FIXME would not have been there in the first place.
Guenter
Sorry Guenter,
That's fine. can I can change the return type of the function or is
that going to break things?
Nick
Please have a look at the context. q40_irq_startup is used to initialize
struct irq_chip.irq_startup, which expects an unsigned int as return value.
To make things more interesting, the caller (function irq_startup) assigns
the result to an int. However, _callers_ of irq_startup either ignore
the return value, or assume that an interrupt is pending if the return
value is not 0.
So all your change accomplishes is to tell the caller that an interrupt
would be pending. Changing the return value to int will only result
in a compile warning but otherwise not change anything.
Unless you put in the effort to really analyze the code, and that applies
to each FIXME you are trying to fix, I would suggest to leave it alone.
Otherwise we just end up worse than before.
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] gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc
On Wed, Jul 23, 2014 at 12:01 AM, Guenter Roeck wrote: > Both functions were introduced to let gpio drivers request their own > gpio pins. Without exporting the functions, this can however only be > used by gpio drivers built into the kernel. > > Secondary impact is that the functions can not currently be used by > platform initialization code associated with the gpio-pca953x driver. > This code permits auto-export of gpio pins through platform data, but > if this functionality is used, the module can no longer be unloaded due > to the problem solved with the introduction of gpiochip_request_own_desc > and gpiochip_free_own_desc. > > Export both function so they can be used from modules and from > platform initialization code. > > Cc: Mika Westerberg > Signed-off-by: Guenter Roeck Makes sense to have them there. Reviewed-by: Alexandre Courbot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] gpio: make gpiochip_get_desc() gpiolib-private
On Wed, Jul 23, 2014 at 12:47 PM, Guenter Roeck wrote: > On 07/22/2014 08:10 PM, Alexandre Courbot wrote: >> >> On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: >>> >>> On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. >>> If I implement a gpio chip driver built as module, and I want to use >>> gpiochip_request_own_desc(), how am I supposed to get desc ? >>> >>> I understand that there is still gpio_to_desc(), but I would have thought >>> that >>> desc = gpiochip_get_desc(chip, pin); >>> would be better than >>> desc = gpio_to_desc(chip->base + pin); >>> >>> Not that it makes much of a difference for me, just asking. >> >> >> Actually I was thinking of changing the prototype of >> gpiochip_request_own_desc(), and your comment definitely strenghtens >> that idea. gpiochip functions should not work with descriptors, >> especially since we are going to switch to a multiple-consumer scheme >> where there won't be any canonical descriptor anymore. Thus, how about >> turning gpiochip_request_own_desc() into this: >> >> struct gpio_desc * >> gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char >> *label); >> >> which would basically do both the gpiochip_get_desc() and former >> gpiochip_request_own_desc() in one call. I think it should satisfy >> everybody and removes the need to have gpiochip_get_desc() (a not very >> useful function by itself) exposed out of gpiolib. >> >> I will send a patch taking care of this if you agree that makes sense. >> > > I think you also plan to remove the capability to retrieve the chip > pointer, don't you ? If so, I won't be able to use the function from > the pca953x platform init function, since I won't be able to get the > pointer to the gpio chip. Even if you don't remove gpiod_to_chip(), > things would become a bit messy, since I would first have to convert > a pin to a desc and then to the chip pointer. Anyway, that change > would mean that exporting gpiochip_request_own_desc or its replacement > won't solve one of the problems addressed by my patch anymore, leaving > me more or less in the dark :-(. Here is why this change is taking place: right now you have a clear descriptor/pin mapping, i.e. there is only one descriptor per pin, anytime. For various reasons this is going to change soon, and descriptors will be allocated the provided to GPIO consumers as an abstraction of the pin. Meaning that you cannot really "get the descriptor for that pin" anymore. Since gpiochip_request_own_desc()'s purpose is precisely to request one descriptor for drivers to use, the new prototype makes much more sense IMHO. Another reason to have it work on a gpio_chip is that the gpio_chip pointer is a token to doing certain "priviledged" operations. Like obtaining an arbitrary descriptor. If consumers can get a pointer to the gpio_chip of a descriptor, this means they can basically do anything. Being in the board code, it seems to be that you are in a good position to obtain a pointer to the gpio_chip, and without knowing better I'd say that's what you should try to do. But maybe I would understand your problem better if you could post a small patch of what you want to achieve here. > > I was thinking about implementing a separate platform driver which > would enable me to auto-export (or initialize, if needed) gpio pins > from arbitrary gpio drivers to user space. I could make this work > with both devicetree data and platform data. Sure, that driver > would not have a chance to get accepted upstream, since it would use > devicetree data to, in a sense, configure the system, but on the > upside it would be independent of gpio API changes, and it would > work for _all_ gpio chips, not just for the ones with gpio driver > support. Unfortunately this approach doesn't really work either, > since exported pin names need to be configured with the chip driver, > and can not be selected afterwards when a pin is actually exported. > > On the other side, would you agree to adding something like > gpiod_export_name(), which would export a gpio pin with given name, > not using the default or chip->names ? That might help solving > at least some of my problems, and I would no longer depend on > gpiochip_request_own_desc or any of the related functions. Isn't that what gpiod_export_link() does? > > For reference, I currently need the ability to auto-export > gpio pins to user space for pca953x, ich, and for various > to-be-published gpio drivers used by my employer. Under which criteria are the GPIOs auto-exported? Can't you have the board code simply request all the GPIOs as a regular consumer and export them to user-space? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org
Re: [PATCH] ACPI/NVS: Not save NVS region for new machines to accelerate S3
On 2014年07月23日 07:40, Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 01:55:22 PM Lan Tianyu wrote:
>> NVS region is saved and restored unconditionally for machines without
>> nvs_nosave quirk during S3. Tested some new machines and the operation
>> is not necessary. Saving NVS region also affects S2RAM speed. The time of
>> NVS saving and restoring depends on the size of NVS region and it consumes
>> 7~10ms normally.
>>
>> This patch is to make machines produced from 2012 to now not saving NVS
>> region
>> to accelerate S3.
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> drivers/acpi/sleep.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index b3e3cc7..896d8be 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -322,7 +322,12 @@ static struct dmi_system_id acpisleep_dmi_table[]
>> __initdata = {
>>
>> static void acpi_sleep_dmi_check(void)
>> {
>> +int year;
>> +
>> dmi_check_system(acpisleep_dmi_table);
>> +
>> +if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year >= 2012)
>> +acpi_nvs_nosave_s3();
>
> I'd prefer the ordering here to be different so that individual quirks
> could be used to change the date-based wholesale behavior.
Ok. I will update soon.
>
>> }
>>
>> /**
>>
>
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/14] arm64: eBPF JIT compiler
On Mon, Jul 21, 2014 at 8:49 AM, Alexei Starovoitov wrote: > On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote: [...] >>> This series applies against net-next and is tested working >>> with lib/test_bpf on ARMv8 Foundation Model. >> >> Looks like it works on my Juno board too, so: >> >> Acked-by: Will Deacon >> >> for the series. Thanks Will! I've added your acked-by to the entire series, also tweaked 14/14's commit log to indicate that it's been tested on Juno as well. >> >> It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which >> also means the dependency on -next isn't an issue). Perhaps you could repost >> around -rc3? > > Thanks for testing! Nice to see it working on real hw. > I'm not sure why you're proposing a 4+ week delay. The patches > will rot instead of getting used and tested. Imo it makes sense to > get them into net-next now for 3.17. > JIT is disabled by sysctl by default anyway. Hmm... if net-next is still open, and David is willing to pull in this series, I share Alexei's opinion -- don't see why a delay is necessary. David, any chance of pulling this series into net-next for 3.17? BTW, I also tried merging 'git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core' with this series. The example merge is available at 'https://github.com/zlim/linux.git arm64/bpf-merge'. The merge conflict resolution is really trivial: 8< diff --cc arch/arm64/Kconfig index 7534a80a,ce6e733..c165c91 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@@ -32,8 -33,8 +34,9 @@@ config ARM6 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK - select HAVE_C_RECORDMCOUNT + select HAVE_BPF_JIT + select HAVE_C_RECORDMCOUNT + select HAVE_CC_STACKPROTECTOR select HAVE_DEBUG_BUGVERBOSE select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_API_DEBUG >8 Anyway, here's an updated branch (with Will's acks, commit log tweak noting Will's testing on real hardware, rebase on net-next). I can repost entire patch series if needed. The following changes since commit 52c4f0ec662bbf02f1b0bcb311a48af2c8e5ee89: drivers: net: cpsw: add support to dump ALE table via ethtool register dump (2014-07-22 19:58:25 -0700) are available in the git repository at: https://github.com/zlim/linux.git arm64/bpf for you to fetch changes up to 533f668ff3e8d69f22c6e5432e0eb1005f2e8970: arm64: eBPF JIT compiler (2014-07-22 21:52:09 -0700) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: sirf-usp: Fixed a bug for playback and capture work at the same time
1. The startup function invoked when the playback and capture.
If start playback when capturing, the registers are re-initinitialised.
That cause the playback fail. So move the startup code into runtime resume.
2. Modified: If non RUNTIME_PM support, the probe need enable clock and
initinitialise registers.
3. Refine code.
Signed-off-by: Rongjun Ying
---
sound/soc/sirf/sirf-usp.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/soc/sirf/sirf-usp.c b/sound/soc/sirf/sirf-usp.c
index 9693bc2..3a73037 100644
--- a/sound/soc/sirf/sirf-usp.c
+++ b/sound/soc/sirf/sirf-usp.c
@@ -103,11 +103,8 @@ static int sirf_usp_pcm_set_dai_fmt(struct snd_soc_dai
*dai,
return 0;
}
-static int sirf_usp_i2s_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
+static void sirf_usp_i2s_init(struct sirf_usp *usp)
{
- struct sirf_usp *usp = snd_soc_dai_get_drvdata(dai);
-
/* Configure RISC mode */
regmap_update_bits(usp->regmap, USP_RISC_DSP_MODE,
USP_RISC_DSP_SEL, ~USP_RISC_DSP_SEL);
@@ -119,19 +116,16 @@ static int sirf_usp_i2s_startup(struct snd_pcm_substream
*substream,
regmap_write(usp->regmap, USP_TX_DMA_IO_LEN, 0);
regmap_write(usp->regmap, USP_RX_DMA_IO_LEN, 0);
- regmap_write(usp->regmap, USP_RX_FRAME_CTRL, USP_SINGLE_SYNC_MODE);
-
- regmap_write(usp->regmap, USP_TX_FRAME_CTRL, USP_TXC_SLAVE_CLK_SAMPLE);
-
/* Configure Mode2 register */
regmap_write(usp->regmap, USP_MODE2, (1 << USP_RXD_DELAY_LEN_OFFSET) |
- (0 << USP_TXD_DELAY_LEN_OFFSET));
+ (0 << USP_TXD_DELAY_LEN_OFFSET) |
+ USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE);
/* Configure Mode1 register */
regmap_write(usp->regmap, USP_MODE1,
USP_SYNC_MODE | USP_EN | USP_TXD_ACT_EDGE_FALLING |
USP_RFS_ACT_LEVEL_LOGIC1 | USP_TFS_ACT_LEVEL_LOGIC1 |
- USP_TX_UFLOW_REPEAT_ZERO);
+ USP_TX_UFLOW_REPEAT_ZERO | USP_CLOCK_MODE_SLAVE);
/* Configure RX DMA IO Control register */
regmap_write(usp->regmap, USP_RX_DMA_IO_CTRL, 0);
@@ -155,8 +149,6 @@ static int sirf_usp_i2s_startup(struct snd_pcm_substream
*substream,
/* Congiure TX FIFO Level Check register */
regmap_write(usp->regmap, USP_TX_FIFO_LEVEL_CHK,
TX_FIFO_SC(0x1B) | TX_FIFO_LC(0x0E) | TX_FIFO_HC(0x04));
-
- return 0;
}
static int sirf_usp_pcm_hw_params(struct snd_pcm_substream *substream,
@@ -204,23 +196,19 @@ static int sirf_usp_pcm_hw_params(struct
snd_pcm_substream *substream,
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
regmap_update_bits(usp->regmap, USP_TX_FRAME_CTRL,
USP_TXC_DATA_LEN_MASK | USP_TXC_FRAME_LEN_MASK
- | USP_TXC_SHIFTER_LEN_MASK,
+ | USP_TXC_SHIFTER_LEN_MASK | USP_TXC_SLAVE_CLK_SAMPLE,
((data_len - 1) << USP_TXC_DATA_LEN_OFFSET)
| ((frame_len - 1) << USP_TXC_FRAME_LEN_OFFSET)
- | ((shifter_len - 1) << USP_TXC_SHIFTER_LEN_OFFSET));
+ | ((shifter_len - 1) << USP_TXC_SHIFTER_LEN_OFFSET)
+ | USP_TXC_SLAVE_CLK_SAMPLE);
else
regmap_update_bits(usp->regmap, USP_RX_FRAME_CTRL,
USP_RXC_DATA_LEN_MASK | USP_RXC_FRAME_LEN_MASK
- | USP_RXC_SHIFTER_LEN_MASK,
+ | USP_RXC_SHIFTER_LEN_MASK | USP_SINGLE_SYNC_MODE,
((data_len - 1) << USP_RXC_DATA_LEN_OFFSET)
| ((frame_len - 1) << USP_RXC_FRAME_LEN_OFFSET)
- | ((shifter_len - 1) << USP_RXC_SHIFTER_LEN_OFFSET));
-
- regmap_update_bits(usp->regmap, USP_MODE1,
- USP_CLOCK_MODE_SLAVE, USP_CLOCK_MODE_SLAVE);
- regmap_update_bits(usp->regmap, USP_MODE2,
- USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE,
- USP_TFS_CLK_SLAVE_MODE | USP_RFS_CLK_SLAVE_MODE);
+ | ((shifter_len - 1) << USP_RXC_SHIFTER_LEN_OFFSET)
+ | USP_SINGLE_SYNC_MODE);
return 0;
}
@@ -253,7 +241,6 @@ static int sirf_usp_pcm_trigger(struct snd_pcm_substream
*substream, int cmd,
}
static const struct snd_soc_dai_ops sirf_usp_pcm_dai_ops = {
- .startup = sirf_usp_i2s_startup,
.trigger = sirf_usp_pcm_trigger,
.set_fmt = sirf_usp_pcm_set_dai_fmt,
.hw_params = sirf_usp_pcm_hw_params,
@@ -282,7 +269,6 @@ static struct snd_soc_dai_driver sirf_usp_pcm_dai = {
.ops = &sirf_usp_pcm_dai_ops,
};
-#ifdef CONFIG_PM
static int sirf_usp_pcm_runtime_suspend(struct device *dev)
{
struct sirf_usp *usp = dev_get_drvdata(dev);
@@ -293,9 +279,15 @@ static int sirf_usp_pcm_runtime_suspend(stru
[PATCH 00/16] rcu: Some minor fixes and cleanups
Hi Paul, This is a series of minor fixes and cleanup patches which I found while studying the code. All my previous pending (but not rejected ;) patches are superseded by this series, expect the rcutorture snprintf changes. I am still waiting for you to decide on that one :) These changes have been tested by the kvm rcutorture test setup. Some tests give me stall warnings, but otherwise have SUCCESS messages in the logs. But those are occuring even without these changes with the tip paul/rcu/dev. May be it is because I am running them for a duration of 4 minutes each only? -- Pranith. Pranith Kumar (16): rcu: Use rcu_num_nodes instead of NUM_RCU_NODES rcu: Check return value for cpumask allocation rcu: Fix comment for gp_state field values rcu: Remove redundant check for an online CPU rcu: Add noreturn attribute to boost kthread rcu: Clear gp_flags only when actually starting new gp rcu: Save and restore irq flags in rcu_gp_cleanup() rcu: Clean up rcu_spawn_one_boost_kthread() rcu: Remove redundant check for online cpu rcu: Check for RCU_FLAG_GP_INIT bit in gp_flags for spurious wakeup rcu: Check for spurious wakeup using return value rcu: Rename rcu_spawn_gp_kthread() to rcu_spawn_kthreads() rcu: Spawn nocb kthreads from rcu_prepare_kthreads() rcu: Remove redundant checks for rcu_scheduler_fully_active rcu: Check for a nocb cpu before trying to spawn nocb threads rcu: kvm.sh: Fix error when you pass --cpus argument kernel/rcu/tree.c | 42 ++- kernel/rcu/tree.h | 4 +-- kernel/rcu/tree_plugin.h | 40 + tools/testing/selftests/rcutorture/bin/kvm.sh | 4 +-- 4 files changed, 47 insertions(+), 43 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/16] rcu: Use rcu_num_nodes instead of NUM_RCU_NODES
NUM_RCU_NODES is set at build time and is usually a huge number. We calculate
the actual number of rcu nodes necessary at boot time based on nr_cpu_ids in
rcu_init_geometry() and store it in rcu_num_nodes. We should use this variable
instead of NUM_RCU_NODES.
This commit changes all such NUM_RCU_NODES uses to rcu_num_nodes.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index c31eb28..f07b643 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -885,7 +885,7 @@ void synchronize_rcu_expedited(void)
/* Snapshot current state of ->blkd_tasks lists. */
rcu_for_each_leaf_node(rsp, rnp)
sync_rcu_preempt_exp_init(rsp, rnp);
- if (NUM_RCU_NODES > 1)
+ if (rcu_num_nodes > 1)
sync_rcu_preempt_exp_init(rsp, rcu_get_root(rsp));
put_online_cpus();
@@ -1475,7 +1475,7 @@ static void __init rcu_spawn_boost_kthreads(void)
BUG_ON(smpboot_register_percpu_thread(&rcu_cpu_thread_spec));
rnp = rcu_get_root(rcu_state_p);
(void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
- if (NUM_RCU_NODES > 1) {
+ if (rcu_num_nodes > 1) {
rcu_for_each_leaf_node(rcu_state_p, rnp)
(void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] rcu: Remove redundant check for an online CPU
rcu_prcess_callbacks() is the softirq handler for RCU which is raised from
invoke_rcu_core() which is called from __call_rcu_core().
Each of these three functions checks if the cpu is online. We can remove the
redundant ones. This commit removes one of these redundant check.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 72e0b1f..044946e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2563,8 +2563,6 @@ static void rcu_process_callbacks(struct softirq_action
*unused)
{
struct rcu_state *rsp;
- if (cpu_is_offline(smp_processor_id()))
- return;
trace_rcu_utilization(TPS("Start RCU core"));
for_each_rcu_flavor(rsp)
__rcu_process_callbacks(rsp);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/16] rcu: Check return value for cpumask allocation
This commit add a check for return value of zalloc_cpumask_var() used while
allocating cpumask for rcu_nocb_mask.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index f07b643..bac9797 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -88,7 +88,10 @@ static void __init rcu_bootup_announce_oddness(void)
#ifdef CONFIG_RCU_NOCB_CPU
#ifndef CONFIG_RCU_NOCB_CPU_NONE
if (!have_rcu_nocb_mask) {
- zalloc_cpumask_var(&rcu_nocb_mask, GFP_KERNEL);
+ if (!zalloc_cpumask_var(&rcu_nocb_mask, GFP_KERNEL)) {
+ pr_info("rcu_nocb_mask allocation failed\n");
+ return;
+ }
have_rcu_nocb_mask = true;
}
#ifdef CONFIG_RCU_NOCB_CPU_ZERO
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/16] rcu: Fix comment for gp_state field values
The comment in the code states that the values are for gp_flags field, when the
values are actually for gp_state field. This commit fixes the inconsistency.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index f703ea8..9643f10 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -498,7 +498,7 @@ struct rcu_state {
#define RCU_GP_FLAG_INIT 0x1 /* Need grace-period initialization. */
#define RCU_GP_FLAG_FQS 0x2 /* Need grace-period quiescent-state forcing. */
-/* Values for rcu_state structure's gp_flags field. */
+/* Values for rcu_state structure's gp_state field. */
#define RCU_GP_WAIT_INIT 0 /* Initial state. */
#define RCU_GP_WAIT_GPS 1 /* Wait for grace-period start. */
#define RCU_GP_WAIT_FQS 2 /* Wait for force-quiescent-state time. */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/16] rcu: Add noreturn attribute to boost kthread
rcu_boost_kthread() runs in an infinite loop and does not return. This commit
adds the __noreturn attribute to the function.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index bac9797..dd53247 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1222,7 +1222,7 @@ static int rcu_boost(struct rcu_node *rnp)
* Priority-boosting kthread. One per leaf rcu_node and one for the
* root rcu_node.
*/
-static int rcu_boost_kthread(void *arg)
+static __noreturn int rcu_boost_kthread(void *arg)
{
struct rcu_node *rnp = (struct rcu_node *)arg;
int spincnt = 0;
@@ -1250,7 +1250,6 @@ static int rcu_boost_kthread(void *arg)
}
/* NOTREACHED */
trace_rcu_utilization(TPS("End boost kthread@notreached"));
- return 0;
}
/*
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/16] rcu: Clear gp_flags only when actually starting new gp
We are clearing the gp_flags before we check if a grace period is in progress.
If a grace period is in progress, we return after incorrectly clearing the
gp_flags. The code comments say that this is highly unlikely, but just to be
safe this commit moves the clearing of gp_flags to after the check for grace
period in progress.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 044946e..b14cecd 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1605,7 +1605,6 @@ static int rcu_gp_init(struct rcu_state *rsp)
raw_spin_unlock_irq(&rnp->lock);
return 0;
}
- ACCESS_ONCE(rsp->gp_flags) = 0; /* Clear all flags: New grace period. */
if (WARN_ON_ONCE(rcu_gp_in_progress(rsp))) {
/*
@@ -1616,6 +1615,8 @@ static int rcu_gp_init(struct rcu_state *rsp)
return 0;
}
+ ACCESS_ONCE(rsp->gp_flags) = 0; /* Clear all flags: New grace period. */
+
/* Advance to a new grace period and initialize state. */
record_gp_stall_check_time(rsp);
/* Record GP times before starting GP, hence smp_store_release(). */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/16] rcu: Remove redundant check for online cpu
There are two checks for an online CPU if two if() conditions. This commit
simplies this by replacing it with only one check for the online CPU.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 5dcbf36..8d598a2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2602,15 +2602,18 @@ static void __call_rcu_core(struct rcu_state *rsp,
struct rcu_data *rdp,
{
bool needwake;
+ if (!cpu_online(smp_processor_id()))
+ return;
+
/*
* If called from an extended quiescent state, invoke the RCU
* core in order to force a re-evaluation of RCU's idleness.
*/
- if (!rcu_is_watching() && cpu_online(smp_processor_id()))
+ if (!rcu_is_watching())
invoke_rcu_core();
- /* If interrupts were disabled or CPU offline, don't invoke RCU core. */
- if (irqs_disabled_flags(flags) || cpu_is_offline(smp_processor_id()))
+ /* If interrupts were disabled, don't invoke RCU core. */
+ if (irqs_disabled_flags(flags))
return;
/*
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/16] rcu: Check for spurious wakeup using return value
When the gp_kthread wakes up from the wait event, it returns 0 if the wake up is
due to the condition having been met. This commit checks this return value
for a spurious wake up before calling rcu_gp_init().
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f8847d9..3b20ad2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1790,11 +1790,11 @@ static int __noreturn rcu_gp_kthread(void *arg)
ACCESS_ONCE(rsp->gpnum),
TPS("reqwait"));
rsp->gp_state = RCU_GP_WAIT_GPS;
- wait_event_interruptible(rsp->gp_wq,
+ ret = wait_event_interruptible(rsp->gp_wq,
ACCESS_ONCE(rsp->gp_flags) &
RCU_GP_FLAG_INIT);
/* Locking provides needed memory barrier. */
- if (rcu_gp_init(rsp))
+ if (!ret && rcu_gp_init(rsp))
break;
cond_resched();
flush_signals(current);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/16] rcu: Save and restore irq flags in rcu_gp_cleanup()
We use raw_spin_lock_irqsave/restore() family of functions throughout the code
but for two locations. This commit replaces raw_spin_lock_irq()/unlock_irq()
with irqsave/restore() in one such location. This is not strictly necessary,
so I did not change the other location. I will update the other location if
this is accepted :)
This commit changes raw_spin_lock_irq()/unlock_irq() to
lock_irqsave()/restore().
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b14cecd..5dcbf36 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1706,13 +1706,13 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
*/
static void rcu_gp_cleanup(struct rcu_state *rsp)
{
- unsigned long gp_duration;
+ unsigned long gp_duration, flags;
bool needgp = false;
int nocb = 0;
struct rcu_data *rdp;
struct rcu_node *rnp = rcu_get_root(rsp);
- raw_spin_lock_irq(&rnp->lock);
+ raw_spin_lock_irqsave(&rnp->lock, flags);
smp_mb__after_unlock_lock();
gp_duration = jiffies - rsp->gp_start;
if (gp_duration > rsp->gp_max)
@@ -1726,7 +1726,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
* safe for us to drop the lock in order to mark the grace
* period as completed in all of the rcu_node structures.
*/
- raw_spin_unlock_irq(&rnp->lock);
+ raw_spin_unlock_irqrestore(&rnp->lock, flags);
/*
* Propagate new ->completed value to rcu_node structures so
@@ -1738,7 +1738,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
* grace period is recorded in any of the rcu_node structures.
*/
rcu_for_each_node_breadth_first(rsp, rnp) {
- raw_spin_lock_irq(&rnp->lock);
+ raw_spin_lock_irqsave(&rnp->lock, flags);
smp_mb__after_unlock_lock();
ACCESS_ONCE(rnp->completed) = rsp->gpnum;
rdp = this_cpu_ptr(rsp->rda);
@@ -1746,11 +1746,11 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
needgp = __note_gp_changes(rsp, rnp, rdp) || needgp;
/* smp_mb() provided by prior unlock-lock pair. */
nocb += rcu_future_gp_cleanup(rsp, rnp);
- raw_spin_unlock_irq(&rnp->lock);
+ raw_spin_unlock_irqrestore(&rnp->lock, flags);
cond_resched();
}
rnp = rcu_get_root(rsp);
- raw_spin_lock_irq(&rnp->lock);
+ raw_spin_lock_irqsave(&rnp->lock, flags);
smp_mb__after_unlock_lock(); /* Order GP before ->completed update. */
rcu_nocb_gp_set(rnp, nocb);
@@ -1767,7 +1767,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
ACCESS_ONCE(rsp->gpnum),
TPS("newreq"));
}
- raw_spin_unlock_irq(&rnp->lock);
+ raw_spin_unlock_irqrestore(&rnp->lock, flags);
}
/*
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/16] rcu: Rename rcu_spawn_gp_kthread() to rcu_spawn_kthreads()
We are currently spawning all the threads from this functions. This commit
renames the function so that it reflects the current scenario better.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3b20ad2..afd54e2 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3501,9 +3501,10 @@ static int rcu_pm_notify(struct notifier_block *self,
}
/*
- * Spawn the kthreads that handle each RCU flavor's grace periods.
+ * Spawn the kthreads that handle each RCU flavor's grace periods
+ * and the no-cb and boost kthreads.
*/
-static int __init rcu_spawn_gp_kthread(void)
+static int __init rcu_spawn_kthreads(void)
{
unsigned long flags;
struct rcu_node *rnp;
@@ -3523,7 +3524,7 @@ static int __init rcu_spawn_gp_kthread(void)
rcu_spawn_boost_kthreads();
return 0;
}
-early_initcall(rcu_spawn_gp_kthread);
+early_initcall(rcu_spawn_kthreads);
/*
* This function is invoked towards the end of the scheduler's initialization
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] rcu: kvm.sh: Fix error when you pass --cpus argument
When you pass --cpus argument to kvm.sh, it errors out as it assumes you have
all the requires CPUs to run a batch. This commit fixes this along with a minor
comment fix.
Signed-off-by: Pranith Kumar
---
tools/testing/selftests/rcutorture/bin/kvm.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
b/tools/testing/selftests/rcutorture/bin/kvm.sh
index 36534f9..1128d85 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -214,7 +214,7 @@ END {
batch = 0;
nc = -1;
- # Each pass through the following loop creates on test batch
+ # Each pass through the following loop creates one test batch
# that can be executed concurrently given ncpus. Note that a
# given test that requires more than the available CPUs will run in
# their own batch. Such tests just have to make do with what
@@ -228,7 +228,7 @@ END {
for (i = 0; i < njobs; i++) {
if (done[i])
continue; # Already part of a batch.
- if (nc >= cpus[i] || nc == ncpus) {
+ if (nc >= cpus[i]) {
# This test fits into the current batch.
done[i] = batch;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/16] rcu: Clean up rcu_spawn_one_boost_kthread()
Even though we pass on the return value of kthread_create, we do not
use it anywhere. This commit uses kthread_run() and adds BUG_ON() when we create
the kthread and changes the return type of this function to void.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.h| 2 +-
kernel/rcu/tree_plugin.h | 15 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 9643f10..fc21899 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -569,7 +569,7 @@ static void invoke_rcu_callbacks_kthread(void);
static bool rcu_is_callbacks_kthread(void);
#ifdef CONFIG_RCU_BOOST
static void rcu_preempt_do_callbacks(void);
-static int rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
+static void rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
struct rcu_node *rnp);
#endif /* #ifdef CONFIG_RCU_BOOST */
static void __init rcu_spawn_boost_kthreads(void);
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index dd53247..4d42791 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1330,7 +1330,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node
*rnp)
* already exist. We only create this kthread for preemptible RCU.
* Returns zero if all is well, a negated errno otherwise.
*/
-static int rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
+static void rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
struct rcu_node *rnp)
{
int rnp_index = rnp - &rsp->node[0];
@@ -1347,18 +1347,15 @@ static int rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
rsp->boost = 1;
if (rnp->boost_kthread_task != NULL)
return 0;
- t = kthread_create(rcu_boost_kthread, (void *)rnp,
+ t = kthread_run(rcu_boost_kthread, (void *)rnp,
"rcub/%d", rnp_index);
- if (IS_ERR(t))
- return PTR_ERR(t);
+ BUG_ON(IS_ERR(t));
raw_spin_lock_irqsave(&rnp->lock, flags);
smp_mb__after_unlock_lock();
rnp->boost_kthread_task = t;
raw_spin_unlock_irqrestore(&rnp->lock, flags);
sp.sched_priority = RCU_BOOST_PRIO;
sched_setscheduler_nocheck(t, SCHED_FIFO, &sp);
- wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
- return 0;
}
static void rcu_kthread_do_work(void)
@@ -1476,10 +1473,10 @@ static void __init rcu_spawn_boost_kthreads(void)
per_cpu(rcu_cpu_has_work, cpu) = 0;
BUG_ON(smpboot_register_percpu_thread(&rcu_cpu_thread_spec));
rnp = rcu_get_root(rcu_state_p);
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
if (rcu_num_nodes > 1) {
rcu_for_each_leaf_node(rcu_state_p, rnp)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
}
@@ -1490,7 +1487,7 @@ static void rcu_prepare_kthreads(int cpu)
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
if (rcu_scheduler_fully_active)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
#else /* #ifdef CONFIG_RCU_BOOST */
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/16] rcu: Remove redundant checks for rcu_scheduler_fully_active
rcu_scheduler_fully_active is set to true early in the boot process.
The check for this flag is only needed in rcu_prepare_kthreads() as this
function is called before the above flag is set. All other checks are redundant.
Hence this commit removes those redundant checks.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree_plugin.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 9a50e1d..541c776 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1341,7 +1341,7 @@ static void rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
if (&rcu_preempt_state != rsp)
return 0;
- if (!rcu_scheduler_fully_active || rnp->qsmaskinit == 0)
+ if (rnp->qsmaskinit == 0)
return 0;
rsp->boost = 1;
@@ -1486,9 +1486,10 @@ static void rcu_prepare_kthreads(int cpu)
struct rcu_node *rnp = rdp->mynode;
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
- if (rcu_scheduler_fully_active)
- rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ if (!rcu_scheduler_fully_active)
+ return;
+ rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
rcu_spawn_all_nocb_kthreads(cpu);
}
@@ -2508,9 +2509,8 @@ static void rcu_spawn_all_nocb_kthreads(int cpu)
{
struct rcu_state *rsp;
- if (rcu_scheduler_fully_active)
- for_each_rcu_flavor(rsp)
- rcu_spawn_one_nocb_kthread(rsp, cpu);
+ for_each_rcu_flavor(rsp)
+ rcu_spawn_one_nocb_kthread(rsp, cpu);
}
/*
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/16] rcu: Spawn nocb kthreads from rcu_prepare_kthreads()
rcu_prepare_kthreads() is called when a CPU hotplug event happens. We can also spawn the nocb kthreads from this function. This is preparation for the next patch which remove the redundant check for rcu_scheduler_fully_active. This commit moves the spawning of nocb kthreads to rcu_prepare_kthreads(). Signed-off-by: Pranith Kumar --- kernel/rcu/tree.c| 1 - kernel/rcu/tree_plugin.h | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index afd54e2..4dc449c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3453,7 +3453,6 @@ static int rcu_cpu_notify(struct notifier_block *self, case CPU_UP_PREPARE_FROZEN: rcu_prepare_cpu(cpu); rcu_prepare_kthreads(cpu); - rcu_spawn_all_nocb_kthreads(cpu); break; case CPU_ONLINE: case CPU_DOWN_FAILED: diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 4d42791..9a50e1d 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1488,6 +1488,8 @@ static void rcu_prepare_kthreads(int cpu) /* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */ if (rcu_scheduler_fully_active) rcu_spawn_one_boost_kthread(rcu_state_p, rnp); + + rcu_spawn_all_nocb_kthreads(cpu); } #else /* #ifdef CONFIG_RCU_BOOST */ -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] rcu: Check for a nocb cpu before trying to spawn nocb threads
This commit tries to spawn nocb kthreads only when the CPU is marked as a nocb cpu. This is a minor optimization. Signed-off-by: Pranith Kumar --- kernel/rcu/tree_plugin.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 541c776..8abff0a 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1490,7 +1490,8 @@ static void rcu_prepare_kthreads(int cpu) return; rcu_spawn_one_boost_kthread(rcu_state_p, rnp); - rcu_spawn_all_nocb_kthreads(cpu); + if (rcu_is_nocb_cpu(cpu)) + rcu_spawn_all_nocb_kthreads(cpu); } #else /* #ifdef CONFIG_RCU_BOOST */ -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/16] rcu: Check for RCU_FLAG_GP_INIT bit in gp_flags for spurious wakeup
rcu_gp_init() is called once the gp_kthread wakes up on the condition that
the init bit is set in the gp_flags. For a spurious wakeup we need to check that
it is actually set. This commit ensures that the RCU_GP_FLAG_INIT bit is set in
gp_flags.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 8d598a2..f8847d9 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1600,7 +1600,7 @@ static int rcu_gp_init(struct rcu_state *rsp)
rcu_bind_gp_kthread();
raw_spin_lock_irq(&rnp->lock);
smp_mb__after_unlock_lock();
- if (!ACCESS_ONCE(rsp->gp_flags)) {
+ if (!(ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_INIT)) {
/* Spurious wakeup, tell caller to go back to sleep. */
raw_spin_unlock_irq(&rnp->lock);
return 0;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm-intel tree with the drm tree
On Wed, Jul 23, 2014 at 5:06 AM, Stephen Rothwell wrote: > P.S. Daniel, that drm-intel tree commit has no Signed-off-by from its > author ... Oops, fixed. Thanks for pointing this out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] m68k: Remove printk statement and add return statement in q40ints.c
On Wed, Jul 23, 2014 at 12:54 AM, Guenter Roeck wrote:
> On 07/22/2014 09:08 PM, Nicholas Krause wrote:
>>
>> This removes the printk statement for irqs not defined by the hardware in
>> function q40_irq_startup and instead returns -ENXIO as stated by the fix
>> me message.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> arch/m68k/q40/q40ints.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
>> index 513f9bb..86f05c0 100644
>> --- a/arch/m68k/q40/q40ints.c
>> +++ b/arch/m68k/q40/q40ints.c
>> @@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data
>> *data)
>> switch (irq) {
>> case 1: case 2: case 8: case 9:
>> case 11: case 12: case 13:
>> - printk("%s: ISA IRQ %d not implemented by HW\n", __func__,
>> irq);
>> - /* FIXME return -ENXIO; */
>> + return -ENXIO;
>
>
> Returning -ENXIO from a function returning an unsigned int isn't really very
> helpful,
> don't you think ?
>
> With all those FIXMEs, you might want to keep in mind that there is
> typically a
> good reason for it. If it was as easy as your proposed fix, you can assume
> that the FIXME would not have been there in the first place.
>
> Guenter
>
Sorry Guenter,
That's fine. can I can change the return type of the function or is
that going to break things?
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex
On Mon, 2014-07-21 at 09:42 -0700, Andi Kleen wrote: > FWIW the main problem is currently that switch-through-idle is so > slow. I think improving that would give a boost to far more > situations. Two high frequency idle enter/exit suckage spots: 1) nohz (tick) - it's expensive to start/stop tick on every micro-idle, throttle it or something. 2) ondemand governor - tweak silly default settings to reflect the reality that we routinely schedule communicating threads cross core. (3. seek/destroy fastpath cycles, damn things multiply over time) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RE: [PATCH] lib : lz4 using put_unaligned_le16 instead of put_unaligned
> If your patch is applied, the data which is compressed > by your big-endian system won't be decompressed in other little-endian system. I can't understand this. Please, could you explain this more ? My patch just replaces put_unaligned with put_unaligned_le16. and this just write compression data in little endian byte-order regardless of machine byte-order, like ext file system. So, i guess there is no problem what you pointed Thanks.
Re: [PATCH] m68k: Remove printk statement and add return statement in q40ints.c
On 07/22/2014 09:08 PM, Nicholas Krause wrote:
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
Returning -ENXIO from a function returning an unsigned int isn't really very
helpful,
don't you think ?
With all those FIXMEs, you might want to keep in mind that there is typically a
good reason for it. If it was as easy as your proposed fix, you can assume
that the FIXME would not have been there in the first place.
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/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here is a handful of powerpc fixes for 3.16. They are all pretty simple and self contained and should still make this release. Cheers, Ben. The following changes since commit f56029410a13cae3652d1f34788045c40a13ffc7: powerpc/perf: Never program book3s PMCs with values >= 0x8000 (2014-07-11 13:50:47 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 6f5405bc2ee0102bb3856e2cdea64ff415db2e0c: powerpc: use _GLOBAL_TOC for memmove (2014-07-22 15:56:04 +1000) Aneesh Kumar K.V (1): powerpc: subpage_protect: Increase the array size to take care of 64TB Joel Stanley (1): powerpc: Disable doorbells on Power8 DD1.x Li Zhong (1): powerpc: use _GLOBAL_TOC for memmove Paul Mackerras (1): powerpc: Fix bugs in emulate_step() Tyrel Datwyler (1): powerpc/pseries: dynamically added OF nodes need to call of_node_init arch/powerpc/include/asm/cputable.h | 1 + arch/powerpc/include/asm/mmu-hash64.h | 3 ++- arch/powerpc/kernel/cputable.c| 20 arch/powerpc/lib/mem_64.S | 2 +- arch/powerpc/lib/sstep.c | 10 +- arch/powerpc/platforms/pseries/dlpar.c| 1 + arch/powerpc/platforms/pseries/reconfig.c | 1 + 7 files changed, 31 insertions(+), 7 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/
Work Ideas
I am working for some work in the kernel. I am new to the kernel but I am read Robert Love's book and another book on device drivers, so my theory is good is prettygood other then not being up to date on the newest features in the latest kernels. If anyone wants to give me something to do I don't mind what type of work . The one problem is I don'thave a budget for test hardware, so if hardware testing is needed someone else will need to test for me on the hardware that testing is needed . I am not asking for pay just to help you guys out more as some of my fix mes let's say wasted previous time. Cheers Nick :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/16] cpufreq: Add cpufreq driver for Tegra124
On 21 July 2014 21:09, Tuomas Tynkkynen wrote:
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 7364a53..df3c73e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -244,6 +244,7 @@ config ARM_SPEAR_CPUFREQ
> config ARM_TEGRA_CPUFREQ
> bool "TEGRA CPUFreq support"
> depends on ARCH_TEGRA
> + depends on GENERIC_CPUFREQ_CPU0
Wouldn't this also disturb the existing cpufreq driver for earlier
tegra platforms? i.e. we don't need cpufreq-cpu0 for them
atleast as of now.
> default y
> help
> This adds the CPUFreq driver support for TEGRA SOCs.
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index db6d9a2..3437d24 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
> obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra-cpufreq.o
> +obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra124-cpufreq.o
Maybe, you can update the same line if you want.
> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
>
>
> ##
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> b/drivers/cpufreq/tegra124-cpufreq.c
> +static struct cpufreq_frequency_table *freq_table;
> +
> +static struct device *cpu_dev;
> +static struct clk *cpu_clk;
> +static struct clk *pllp_clk;
> +static struct clk *pllx_clk;
> +static struct clk *dfll_clk;
The routines in this file are going to be called just once at boot, right?
In that case we are actually wasting some memory by creating globals.
Probably just move all these in a struct and allocate it at runtime.
> +static int tegra124_cpu_switch_to_dfll(void)
> +{
> + struct clk *original_cpu_clk_parent;
> + unsigned long rate;
> + struct dev_pm_opp *opp;
> + int ret;
> +
> + rate = clk_get_rate(cpu_clk);
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> +
> + ret = clk_set_rate(dfll_clk, rate);
> + if (ret)
> + return ret;
> +
> + original_cpu_clk_parent = clk_get_parent(cpu_clk);
> + clk_set_parent(cpu_clk, pllp_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(dfll_clk);
> + if (ret)
> + goto out_switch_to_original_parent;
> +
> + clk_set_parent(cpu_clk, dfll_clk);
> +
> + return 0;
> +
> +out_switch_to_original_parent:
> + clk_set_parent(cpu_clk, original_cpu_clk_parent);
> +
> + return ret;
> +}
> +
> +static struct platform_device_info cpufreq_cpu0_devinfo = {
> + .name = "cpufreq-cpu0",
> +};
> +
> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev)
> + return -ENODEV;
> +
Shouldn't we do a of_node_get() here?
> + cpu_clk = of_clk_get_by_name(cpu_dev->of_node, "cpu_g");
> + if (IS_ERR(cpu_clk))
> + return PTR_ERR(cpu_clk);
> +
> + dfll_clk = of_clk_get_by_name(cpu_dev->of_node, "dfll");
> + if (IS_ERR(dfll_clk)) {
> + ret = PTR_ERR(dfll_clk);
> + goto out_put_cpu_clk;
> + }
> +
> + pllx_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_x");
> + if (IS_ERR(pllx_clk)) {
> + ret = PTR_ERR(pllx_clk);
> + goto out_put_dfll_clk;
> + }
> +
> + pllp_clk = of_clk_get_by_name(cpu_dev->of_node, "pll_p");
> + if (IS_ERR(pllp_clk)) {
> + ret = PTR_ERR(pllp_clk);
> + goto out_put_pllx_clk;
> + }
> +
> + ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> + if (ret)
> + goto out_put_pllp_clk;
Why do you need this? cpufreq-cpu0 also does it and this freq_table is
just not getting used at all then.
> +
> + ret = tegra124_cpu_switch_to_dfll();
> + if (ret)
> + goto out_free_table;
> +
> + platform_device_register_full(&cpufreq_cpu0_devinfo);
> +
> + return 0;
> +
> +out_free_table:
> + dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
> +out_put_pllp_clk:
> + clk_put(pllp_clk);
> +out_put_pllx_clk:
> + clk_put(pllx_clk);
> +out_put_dfll_clk:
> + clk_put(dfll_clk);
> +out_put_cpu_clk:
> + clk_put(cpu_clk);
> +
> + return ret;
> +}
> +
> +static struct platform_driver tegra124_cpufreq_platdrv = {
> + .driver = {
> + .name = "cpufreq-tegra124",
> + .owner = THIS_MODULE,
> + },
> + .probe = tegra124_cpufreq_probe,
> +};
> +
> +static const struct of_device_id soc_of_matches[]
smp-cmp.c: CDFIXMES
Are the lines with CDFIXME still needed? If not please tell me as I will send in a patch removing these two from this file in order to help you guys out :). Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Fix false positives for --strict "space after cast" test
commit 89da401f6cff ("checkpatch: improve "no space after cast" test")
in -next improved the cast test for non pointer types, but also
introduced false positives for some types of static inlines.
Add a test for an open brace to the exclusions to avoid these
false positives.
Reported-by: Hartley Sweeten
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dc72a9b..7dcfc75 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2418,7 +2418,7 @@ sub process {
}
}
- if ($line =~ /^\+.*\(\s*$Type\s*\)[
\t]+(?!$Assignment|$Arithmetic)/) {
+ if ($line =~ /^\+.*\(\s*$Type\s*\)[
\t]+(?!$Assignment|$Arithmetic|{)/) {
if (CHK("SPACING",
"No space is necessary after a cast\n" .
$herecurr) &&
$fix) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] microblaze: Add comment for defines
This adds a comment for and removes a fix me by labeling these
defines as memory cache definitions.
Signed-off-by: Nicholas Krause
---
arch/microblaze/include/asm/pvr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/include/asm/pvr.h
b/arch/microblaze/include/asm/pvr.h
index 4bbdb4c..441f3a0 100644
--- a/arch/microblaze/include/asm/pvr.h
+++ b/arch/microblaze/include/asm/pvr.h
@@ -186,7 +186,7 @@ struct pvr_s {
#define PVR_DCACHE_USE_FSL(_pvr) (_pvr.pvr[5] & PVR5_DCACHE_USE_FSL_MASK)
#define PVR_DCACHE_ALLOW_WR(_pvr) \
(_pvr.pvr[5] & PVR5_DCACHE_ALLOW_WR_MASK)
-/* FIXME two shifts on one line needs any comment */
+/* memory caches */
#define PVR_DCACHE_LINE_LEN(_pvr) \
(1 << ((_pvr.pvr[5] & PVR5_DCACHE_LINE_LEN_MASK) >> 21))
#define PVR_DCACHE_BYTE_SIZE(_pvr) \
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Random panic in load_balance() with 3.16-rc
On Tue, Jul 22, 2014 at 8:53 PM, Michel Dänzer wrote: > > Just happened again with the same change on top of 3.16-rc6. The (maybe) related bugzilla entry is just odd. Bruno Wolff reports that the BUG_ON() in his added patch triggers: + cpumask_clear(sched_group_cpus(sg)); + sg->sgc->capacity = 0; + BUG_ON(!cpumask_empty(sched_group_cpus(sg))); where it *just* did a cpumask_clear(), and now the BUG_ON() triggers that it's no longer empty? That would imply an allocation error, but all the sched groups seem to be properly allocated with the proper addition of cpumask_size(). And his config file even has NR_CPUS being 32, so it should be a single word of bitmap, which triggers all the simple code. Completely insane, in other words. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/4] dra7: Add PCIe support
Hello Bjorn, > -Original Message- > From: Bjorn Helgaas [mailto:bhelg...@google.com] > Sent: Wednesday, July 23, 2014 3:03 AM > To: Kishon Vijay Abraham I > Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux- > p...@vger.kernel.org; jg1@samsung.com; Mohit KUMAR DCG; linux- > ker...@vger.kernel.org; grant.lik...@linaro.org > Subject: Re: [PATCH v3 0/4] dra7: Add PCIe support > > On Thu, Jul 17, 2014 at 02:30:39PM +0530, Kishon Vijay Abraham I wrote: > > Changes from v2: > > * Added myself as MAINTAINER of pcie dra7xx driver [...] > > I applied these to pci/host-designware for v3.17. This will not be in my > first > pull request because I'm going on vacation and won't have time to get > everything through -next and tagged. But I'm planning a second pull request > that will include this. > > Mohit, I applied your ack of "use untranslated address" from the v1 posting > (your mail of Jul 09) to the corresponding patch here, since Kishon didn't > carry it forward. Let me know if that's not OK. - yes, OK with me. Thanks Mohit > > I also squashed the last two patches into one so the DT binding > documentation goes along with the dra7xx driver addition. > > Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] aio: use iovec array rather than the single one
Hi Jeff,
On 07/22/2014 11:20 PM, Jeff Moyer wrote:
> Gu Zheng writes:
>
>> use an iovec array rather than the single one, so that we can avoid
>> to alloc more iovecs buffer in small(< 8) PREADV/PWRITEV cases.
>
> I did some basic functional testing of this change and the change in
> patch 1/4. That testing included using aio-stress to drive queue depths
> of 7, 8 and 9, and verify that it didn't fall over. I also ran xfstests
> './check -g aio', and libaio's 'make partcheck'.
>
> The change looks good to me, and passed testing, so:
>
> Reviewed-by: Jeff Moyer
Thanks for your review and test.
>
> However, I still would like some comment on the reasoning behind it, and
> whether there is some measurable performance advantage for some
> workload. Additionally, it would be nice if that comment made its way
> into the commit message.
I'll add more useful info, and send it out later.
Thanks,
Gu
>
> Cheers,
> Jeff
>
>>
>> Signed-off-by: Gu Zheng
>> ---
>> fs/aio.c | 10 +-
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 0cd0479..ef21efe 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -1260,12 +1260,12 @@ static ssize_t aio_setup_vectored_rw(struct kiocb
>> *kiocb,
>> if (compat)
>> ret = compat_rw_copy_check_uvector(rw,
>> (struct compat_iovec __user *)buf,
>> -*nr_segs, 1, *iovec, iovec);
>> +*nr_segs, UIO_FASTIOV, *iovec, iovec);
>> else
>> #endif
>> ret = rw_copy_check_uvector(rw,
>> (struct iovec __user *)buf,
>> -*nr_segs, 1, *iovec, iovec);
>> +*nr_segs, UIO_FASTIOV, *iovec, iovec);
>> if (ret < 0)
>> return ret;
>>
>> @@ -1302,7 +1302,7 @@ static ssize_t aio_run_iocb(struct kiocb *req,
>> unsigned opcode,
>> fmode_t mode;
>> aio_rw_op *rw_op;
>> rw_iter_op *iter_op;
>> -struct iovec inline_vec, *iovec = &inline_vec;
>> +struct iovec inline_vecs[UIO_FASTIOV], *iovec = inline_vecs;
>> struct iov_iter iter;
>>
>> switch (opcode) {
>> @@ -1337,7 +1337,7 @@ rw_common:
>> if (!ret)
>> ret = rw_verify_area(rw, file, &req->ki_pos,
>> req->ki_nbytes);
>> if (ret < 0) {
>> -if (iovec != &inline_vec)
>> +if (iovec != inline_vecs)
>> kfree(iovec);
>> return ret;
>> }
>> @@ -1384,7 +1384,7 @@ rw_common:
>> return -EINVAL;
>> }
>>
>> -if (iovec != &inline_vec)
>> +if (iovec != inline_vecs)
>> kfree(iovec);
>>
>> if (ret != -EIOCBQUEUED) {
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] aio: fix some comments
On 07/22/2014 10:12 PM, Benjamin LaHaise wrote: > On Tue, Jul 22, 2014 at 10:40:03AM +0800, Gu Zheng wrote: >> Signed-off-by: Gu Zheng > > Again, you're missing a commit message here. Please resubmit with a commit > message. Got it, I'll resend it later. Thanks, Gu > > -ben > >> --- >> fs/aio.c |7 +++ >> 1 files changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/fs/aio.c b/fs/aio.c >> index 1dc6158..0cd0479 100644 >> --- a/fs/aio.c >> +++ b/fs/aio.c >> @@ -1037,7 +1037,7 @@ void aio_complete(struct kiocb *iocb, long res, long >> res2) >> } >> EXPORT_SYMBOL(aio_complete); >> >> -/* aio_read_events >> +/* aio_read_events_ring >> * Pull an event off of the ioctx's event ring. Returns the number of >> * events fetched >> */ >> @@ -1289,9 +1289,8 @@ static ssize_t aio_setup_single_vector(struct kiocb >> *kiocb, >> } >> >> /* >> - * aio_setup_iocb: >> - * Performs the initial checks and aio retry method >> - * setup for the kiocb at the time of io submission. >> + * aio_run_iocb: >> + * Performs the initial checks and io submission. >> */ >> static ssize_t aio_run_iocb(struct kiocb *req, unsigned opcode, >> char __user *buf, bool compat) >> -- >> 1.7.7 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m68k: Remove printk statement and add return statement in q40ints.c
This removes the printk statement for irqs not defined by the hardware in
function q40_irq_startup and instead returns -ENXIO as stated by the fix
me message.
Signed-off-by: Nicholas Krause
---
arch/m68k/q40/q40ints.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 513f9bb..86f05c0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -48,8 +48,7 @@ static unsigned int q40_irq_startup(struct irq_data *data)
switch (irq) {
case 1: case 2: case 8: case 9:
case 11: case 12: case 13:
- printk("%s: ISA IRQ %d not implemented by HW\n", __func__, irq);
- /* FIXME return -ENXIO; */
+ return -ENXIO;
}
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth, On Tuesday 22 July 2014 10:15 PM, Nishanth Menon wrote: > On 07/16/2014 03:36 AM, Lokesh Vutla wrote: >> This series add seperate ocp interface lists that are specific to dra74x >> and dra72x, and moving USB OTG SS4 to dra74x only since its not present >> in dra72x. Without this USB OTG SS4 hwmod gives an abort on dra72x. >> >> Adding support for soc_is_dra74x() and soc_is_dra72x() in order to >> differentiate >> between dra74x and dra72x and pass the respective ocp interface lists. >> >> Verified on dra74x evm and dra72x evm using 3.16-rc5 based mainline kernel. >> >> Before: >> dra74x : http://paste.ubuntu.com/7802364/ >> dra72x : http://paste.ubuntu.com/7802334/ (Kernel panic) >> >> After- >> dra74x : http://paste.ubuntu.com/7802340/ >> dra72x : http://paste.ubuntu.com/7802338/ (booted) >> >> Rajendra Nayak (2): >> ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() >> varients >> ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists >> >> arch/arm/mach-omap2/omap_hwmod.c |3 +++ >> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 -- >> arch/arm/mach-omap2/soc.h |7 +++ >> 3 files changed, 30 insertions(+), 2 deletions(-) >> > Tested-by: Nishanth Menon Thanks.. > > BUT, I suggest a follow up series to do exactly the same (moving stuff > that are not common from dra7.dtsi to dra72x.dtsi and 74x.dtsi) as > well to ensure that dts indicates exactly the same information (only > the applicable IPs are present in dts). The separation of dra72x.dtsi and dra74x.dtsi is already happened and the patch is already present in mainline[1]. Looks like usb_otg_ss4 is still present in dra7.dtsi, but this should go into dra74x.dtsi. I ll take it up. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=38b248db60e32734417534b57f9ab687c445113a Thanks and regards, Lokesh > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth,
On Tuesday 22 July 2014 10:20 PM, Nishanth Menon wrote:
> On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
>> From: Rajendra Nayak
>>
>> To deal with IPs which are specific to dra74x and dra72x, maintain seperate
>> ocp interface lists, while keeping the common list for all common IPs.
>>
>> Move USB OTG SS4 to dra74x only list since its unavailable in
>> dra72x and is giving an abort during boot. The dra72x only list
>> is empty for now and a placeholder for future hwmod additions which
>> are specific to dra72x.
>>
>> Fixes: d904b38 ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
>
> please use a format as following:
> Fixes: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
>
>> Reported-by: Keerthy
>> Signed-off-by: Rajendra Nayak
>> Signed-off-by: Lokesh Vutla
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c |3 +++
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 --
>> 2 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 6c074f3..14f8370 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -3345,6 +3345,9 @@ int __init omap_hwmod_register_links(struct
>> omap_hwmod_ocp_if **ois)
>> if (!ois)
>> return 0;
>>
>> +if (ois[0] == NULL) /*empty list*/
> /* Empty list */ ?
>> +return 0;
>> +
>
> This change looks like a different patch?
Since we are introducing empty lists in this patch, I guess
this can go in the same patch.
>
>> if (!linkspace) {
>> if (_alloc_linkspace(ois)) {
>> pr_err("omap_hwmod: could not allocate link space\n");
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 284324f..c95033c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -35,6 +35,7 @@
>> #include "i2c.h"
>> #include "mmc.h"
>> #include "wd_timer.h"
>> +#include "soc.h"
>>
>> /* Base offset for all DRA7XX interrupts external to MPUSS */
>> #define DRA7XX_IRQ_GIC_START32
>> @@ -2705,7 +2706,6 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> &dra7xx_l4_per3__usb_otg_ss1,
>> &dra7xx_l4_per3__usb_otg_ss2,
>> &dra7xx_l4_per3__usb_otg_ss3,
>> -&dra7xx_l4_per3__usb_otg_ss4,
>> &dra7xx_l3_main_1__vcp1,
>> &dra7xx_l4_per2__vcp1,
>> &dra7xx_l3_main_1__vcp2,
>> @@ -2714,8 +2714,26 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> NULL,
>> };
>>
>> +static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
>> +&dra7xx_l4_per3__usb_otg_ss4,
>> +NULL,
>> +};
>> +
>> +static struct omap_hwmod_ocp_if *dra72x_hwmod_ocp_ifs[] __initdata = {
>> +NULL,
>> +};
>> +
>> int __init dra7xx_hwmod_init(void)
>> {
>> +int ret;
>> +
>> omap_hwmod_init();
>> -return omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
>> +ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
> if (ret)
> goto out;
>> +
>> +if (!ret && soc_is_dra74x())
> no need of !ret
>> +return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
>> +else if (!ret && soc_is_dra72x())
> no need of else and !ret
>> +return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
>> +
>
> out:
Ok. Will do this and repost.
Thanks and regards,
Lokesh
>> +return ret;
>> }
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] ACPI: Add support to force header inclusion rules for .
Hi Lv, On 2014-7-16 16:58, Lv Zheng wrote: > As there is only CONFIG_ACPI=n processing in the , it is not > safe to include directly for source out of Linux ACPI > subsystems. > > This patch adds error messaging to warn developers of such wrong > inclusions. Thanks for doing this, it makes life much easier for people who want to use ACPI but not so familiar with ACPI. Best Regards Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Random panic in load_balance() with 3.16-rc
On 22.07.2014 15:13, Michel Dänzer wrote: > On 18.07.2014 18:29, Michel Dänzer wrote: >> On 17.07.2014 16:58, Peter Zijlstra wrote: >>> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote: I've been running into the panic captured in the attached picture (hope it's legible) randomly while running 3.16-rc4 and -rc5. I haven't noticed any pattern as to when it happens; at least once it happened while the box was basically sitting idle. dmesg, .config and /proc/cpuinfo attached as well; let me know if you need anything else. >>> >>> Does lkml.kernel.org/r/20140716145546.ga6...@wolff.to cure things? >> >> Yes, adding back >> >>cpumask_clear(sched_group_cpus(sg)); >> >> seems to do the trick, thanks. > > I'm afraid it happened again with 3.16-rc5 plus the above change. It > seemed to last longer than before, but maybe that was just luck. > > Going to try 3.16-rc6 now. Just happened again with the same change on top of 3.16-rc6. Are there any other potential fixes yet? I hope this problem is on the radar as a showstopper for 3.16. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer signature.asc Description: OpenPGP digital signature
[PATCH net-next v3 0/2] cleanup for Realtek 8139CP
From: Varka Bhadram changes since v2: - making version info print once. changes sice v1: - remove unused varible warning Varka Bhadram (2): ethernet: realtek: use module_pci_driver ethernet: realtek: use pci_device_id drivers/net/ethernet/realtek/8139cp.c | 36 + 1 file changed, 9 insertions(+), 27 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] f2fs: Possible use-after-free when umount filesystem
Hi, On 07/23/2014 10:12 AM, Chao Yu wrote: > Hi Andrey Gu, > >> -Original Message- >> From: Andrey Tsyvarev [mailto:tsyva...@ispras.ru] >> Sent: Tuesday, July 22, 2014 6:04 PM >> To: Gu Zheng >> Cc: Jaegeuk Kim; linux-kernel; Alexey Khoroshilov; >> linux-f2fs-de...@lists.sourceforge.net >> Subject: Re: [f2fs-dev] f2fs: Possible use-after-free when umount filesystem >> >> Hi Gu, >> Investigation shows, that f2fs_evict_inode, when called for 'meta_inode', uses >> invalidate_mapping_pages() for 'node_inode'. But 'node_inode' is deleted before 'meta_inode' in f2fs_put_super via iput(). It seems that in common usage scenario this use-after-free is benign, because 'node_inode' >> remains partially valid data even after kmem_cache_free(). But things may change if, while 'meta_inode' is evicted in one f2fs filesystem, another (mounted) >> f2fs filesystem requests inode from cache, and formely 'node_inode' of the first filesystem is returned. >>> The analysis seems reasonable. Have you tried to swap the reclaim order of >>> node_inde >>> and meta_inode? >>> >>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c >>> index 870fe19..e114418 100644 >>> --- a/fs/f2fs/super.c >>> +++ b/fs/f2fs/super.c >>> @@ -430,8 +430,8 @@ static void f2fs_put_super(struct super_block *sb) >>> if (sbi->s_dirty && get_pages(sbi, F2FS_DIRTY_NODES)) >>> write_checkpoint(sbi, true); >>> >>> - iput(sbi->node_inode); >>> iput(sbi->meta_inode); >>> + iput(sbi->node_inode); >>> >>> /* destroy f2fs internal modules */ >>> destroy_node_manager(sbi); >>> >>> Thanks, >>> Gu >> >> With reclaim order of node_inode and meta_inode swapped, use-after-free >> error disappears. >> >> But shouldn't initialization order of these inodes be swapped too? >> As meta_inode uses node_inode, it seems logical that it should be >> initialized after it. The initialization order dose not affect anything, so swapping the order dose not make more sense here. > > IMO, it's not easy to exchange order of initialization between meta_inode and > node_inode, because we should use meta_inode in get_valid_checkpoint for valid > cp first for usual verification, then init node_inode. Yeah, but I think just moving node_inode's initialization to the front of meta_inode dose not break anything. > > As I checked, nids for both meta_inode and node_inode are reservation, so > it's not > necessary for us to invalidate pages which will never alloced. > > How about skipping it as following? It seems the right way to fix this issue. To Andrey: Could you please try this one? Thanks, Gu > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > index 2cf6962..cafba3c 100644 > --- a/fs/f2fs/inode.c > +++ b/fs/f2fs/inode.c > @@ -273,7 +273,7 @@ void f2fs_evict_inode(struct inode *inode) > > if (inode->i_ino == F2FS_NODE_INO(sbi) || > inode->i_ino == F2FS_META_INO(sbi)) > - goto no_delete; > + goto out_clear; > > f2fs_bug_on(get_dirty_dents(inode)); > remove_dirty_dir_inode(inode); > @@ -295,6 +295,7 @@ void f2fs_evict_inode(struct inode *inode) > > sb_end_intwrite(inode->i_sb); > no_delete: > - clear_inode(inode); > invalidate_mapping_pages(NODE_MAPPING(sbi), inode->i_ino, inode->i_ino); > +out_clear: > + clear_inode(inode); > } > >> >> -- >> Best regards, >> >> Andrey Tsyvarev >> Linux Verification Center, ISPRAS >> web:http://linuxtesting.org >> >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> ___ >> Linux-f2fs-devel mailing list >> linux-f2fs-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3 1/2] ethernet: realtek: use module_pci_driver
From: Varka Bhadram
This patch converts to use the macro module_pci_driver, which makes
the code smaller and simpler.
Previously in this driver we are having driver version info will be
printed log buffer based on whether the driver selected as module
or statically into image itself. By using the module_pci_driver that
part of the code removed. For the first time of the device init,
we are making the version info to be printed once.
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/realtek/8139cp.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index 2bc728e..be101ca 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1887,11 +1887,7 @@ static int cp_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
resource_size_t pciaddr;
unsigned int addr_len, i, pci_using_dac;
-#ifndef MODULE
- static int version_printed;
- if (version_printed++ == 0)
- pr_info("%s", version);
-#endif
+ pr_info_once("%s", version);
if (pdev->vendor == PCI_VENDOR_ID_REALTEK &&
pdev->device == PCI_DEVICE_ID_REALTEK_8139 && pdev->revision <
0x20) {
@@ -2121,18 +2117,4 @@ static struct pci_driver cp_driver = {
#endif
};
-static int __init cp_init (void)
-{
-#ifdef MODULE
- pr_info("%s", version);
-#endif
- return pci_register_driver(&cp_driver);
-}
-
-static void __exit cp_exit (void)
-{
- pci_unregister_driver (&cp_driver);
-}
-
-module_init(cp_init);
-module_exit(cp_exit);
+module_pci_driver(cp_driver);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3 2/2] ethernet: realtek: use pci_device_id
From: Varka Bhadram
This patch use the struct pci_device_id instead of using macro
DEFINE_PCI_DEVICE_TABLE which is deprecated and should not be used.
And also moves these ids after probe and remove functionalities.
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/realtek/8139cp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index be101ca..75b1693 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -382,13 +382,6 @@ static int cp_get_eeprom(struct net_device *dev,
static int cp_set_eeprom(struct net_device *dev,
struct ethtool_eeprom *eeprom, u8 *data);
-static DEFINE_PCI_DEVICE_TABLE(cp_pci_tbl) = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139), },
- { PCI_DEVICE(PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322), },
- { },
-};
-MODULE_DEVICE_TABLE(pci, cp_pci_tbl);
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -2106,6 +2099,13 @@ static int cp_resume (struct pci_dev *pdev)
}
#endif /* CONFIG_PM */
+static const struct pci_device_id cp_pci_tbl[] = {
+{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139), },
+{ PCI_DEVICE(PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322), },
+{ },
+};
+MODULE_DEVICE_TABLE(pci, cp_pci_tbl);
+
static struct pci_driver cp_driver = {
.name = DRV_NAME,
.id_table = cp_pci_tbl,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch V1 21/30] mm, irqchip: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Jason, Thanks for your review. According to review comments, we need to rework the patch set in another direction and will give up this patch. Regards! Gerry On 2014/7/18 20:40, Jason Cooper wrote: > On Fri, Jul 11, 2014 at 03:37:38PM +0800, Jiang Liu wrote: >> When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id() >> may return a node without memory, and later cause system failure/panic >> when calling kmalloc_node() and friends with returned node id. >> So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with >> memory for the/current cpu. >> >> If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id() >> is the same as cpu_to_node()/numa_node_id(). >> >> Signed-off-by: Jiang Liu >> --- >> drivers/irqchip/irq-clps711x.c |2 +- >> drivers/irqchip/irq-gic.c |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) > > Do you have anything depending on this? Can apply it to irqchip? If > you need to keep it with other changes, > > Acked-by: Jason Cooper > > But please do let me know if I can take it. > > thx, > > Jason. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] gpio: make gpiochip_get_desc() gpiolib-private
On 07/22/2014 08:10 PM, Alexandre Courbot wrote: On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. If I implement a gpio chip driver built as module, and I want to use gpiochip_request_own_desc(), how am I supposed to get desc ? I understand that there is still gpio_to_desc(), but I would have thought that desc = gpiochip_get_desc(chip, pin); would be better than desc = gpio_to_desc(chip->base + pin); Not that it makes much of a difference for me, just asking. Actually I was thinking of changing the prototype of gpiochip_request_own_desc(), and your comment definitely strenghtens that idea. gpiochip functions should not work with descriptors, especially since we are going to switch to a multiple-consumer scheme where there won't be any canonical descriptor anymore. Thus, how about turning gpiochip_request_own_desc() into this: struct gpio_desc * gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label); which would basically do both the gpiochip_get_desc() and former gpiochip_request_own_desc() in one call. I think it should satisfy everybody and removes the need to have gpiochip_get_desc() (a not very useful function by itself) exposed out of gpiolib. I will send a patch taking care of this if you agree that makes sense. I think you also plan to remove the capability to retrieve the chip pointer, don't you ? If so, I won't be able to use the function from the pca953x platform init function, since I won't be able to get the pointer to the gpio chip. Even if you don't remove gpiod_to_chip(), things would become a bit messy, since I would first have to convert a pin to a desc and then to the chip pointer. Anyway, that change would mean that exporting gpiochip_request_own_desc or its replacement won't solve one of the problems addressed by my patch anymore, leaving me more or less in the dark :-(. I was thinking about implementing a separate platform driver which would enable me to auto-export (or initialize, if needed) gpio pins from arbitrary gpio drivers to user space. I could make this work with both devicetree data and platform data. Sure, that driver would not have a chance to get accepted upstream, since it would use devicetree data to, in a sense, configure the system, but on the upside it would be independent of gpio API changes, and it would work for _all_ gpio chips, not just for the ones with gpio driver support. Unfortunately this approach doesn't really work either, since exported pin names need to be configured with the chip driver, and can not be selected afterwards when a pin is actually exported. On the other side, would you agree to adding something like gpiod_export_name(), which would export a gpio pin with given name, not using the default or chip->names ? That might help solving at least some of my problems, and I would no longer depend on gpiochip_request_own_desc or any of the related functions. For reference, I currently need the ability to auto-export gpio pins to user space for pca953x, ich, and for various to-be-published gpio drivers used by my employer. 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] usb-core: Remove Fix mes in file hcd.c
On Tue, Jul 22, 2014 at 8:44 PM, Sasha Levin wrote: > On 07/18/2014 10:52 PM, Nick Krause wrote: >> On Fri, Jul 18, 2014 at 10:45 PM, Nick Krause wrote: >>> Sorry didn't run spell check. I will resend this patch with the >>> correct information >>> as needed. Thanks for the advice, Sasha. >>> >>> Cheers Nick >>> >>> On Fri, Jul 18, 2014 at 10:36 PM, Sasha Levin wrote: On 07/18/2014 01:34 PM, Nicholas Krause wrote: > I am removing two fix mes in this file as after dicussing then it seems > there is no reason to check against Null for usb_device as it can never > be NULL and this is check is therefore not needed. > > Signed-off-by: Nicholas Krause Please explain exactly why it's not needed, why it can never be NULL, and what prevents it from being NULL. "after dicussing" (do you run spellcheck on your mails?) won't mean anything to someone looking at this commit in a year. Your commit message also mentions usb_device which has nothing to do with your patch. Thanks, Sasha >> >> Sasha , >> Greg seems to have signed it off. >> Cheers Nick > > Greg? > > Even if the patch is correct (and I'm not saying it is) the commit message is > way off. > > > Thanks, > Sasha Sasha, The patch is in the kernel now. I am not going through the trouble of removing it, if you want to fix the commit message go on ahead. Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] x86,cpu-hotplug: assign same CPU number to readded CPU
llc_shared_map is not cleared even if CPU is offline or hot removed.
So when hot-plugging CPU and assigning new CPU number to hot-added CPU,
the mask has wrong value. The mask is used by CSF schduler to create
sched_domain. So it breaks CFS scheduler.
Here is a example on my system.
My system has 4 sockets and each socket has 15 cores and HT is enabled.
In this case, each core of sockes is numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119
Then llc_shared_mask of CPU#30 has 0x3fff8001fffc000.
It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.
When hot-removing socket#2 and #3, each core of sockets is numbered
as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains
having 0x3fff8001fffc000.
After that, when hot-adding socket#2 and #3, each core of sockets is
numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119
Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffc000.
It means that last level cache of Socket#2 is shared with CPU#30-59
and 90-104. So the mask has wrong value.
At first, I cleared hot-removed CPU number's bit from llc_shared_map
when hot removing CPU. But Borislav suggested that the problem will
disappear if readded CPU is assigned same CPU number. And llc_shared_map
must not be changed.
So the patch assigns same CPU number to readded CPU by linking CPU
number to APIC ID. And by the patch, the problem disappers.
Signed-off-by: Yasuaki Ishimatsu
Suggested-by: Borislav Petkov
Reviewed-by: Toshi Kani
---
v2: change cpuid to cpunum
v3: fix Borislav's email address of Suggested-by
fix typo (ACPI ID to APIC ID)
v4: change cpu_used_xxx to cpu_number_xxx
---
arch/x86/kernel/apic/apic.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ad28db7..5cecc3b 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -220,6 +220,23 @@ static void apic_pm_activate(void);
static unsigned long apic_phys;
/*
+ * Bind APIC ID to Logical CPU number
+ * Logical CPU number to APIC ID does not change by this array
+ * even if CPU is hotplugged. So don't clear the array even if
+ * CPU is hot-removed
+ */
+static int apicid_to_cpunum[MAX_LOCAL_APIC] = {
+ [0 ... MAX_LOCAL_APIC-1] = -1,
+};
+
+/*
+ * Represent Logical CPU number bound to APIC ID
+ * Don't clear a bit even if CPU is hot-removed
+ */
+static DECLARE_BITMAP(cpu_number_bits, CONFIG_NR_CPUS);
+static struct cpumask *const cpu_number_mask = to_cpumask(cpu_number_bits);
+
+/*
* Get the LAPIC version
*/
static inline int lapic_get_version(void)
@@ -2122,6 +2139,17 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
+static int get_cpunum(int apicid)
+{
+ int cpu;
+
+ cpu = apicid_to_cpunum[apicid];
+ if (cpu < 0)
+ cpu = cpumask_next_zero(-1, cpu_number_mask);
+
+ return cpu;
+}
+
int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
@@ -2199,7 +2227,9 @@ int generic_processor_info(int apicid, int version)
*/
cpu = 0;
} else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+ cpu = get_cpunum(apicid);
+
+ apicid_to_cpunum[apicid] = cpu;
/*
* Validate version
@@ -2228,6 +2258,7 @@ int generic_processor_info(int apicid, int version)
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
apic->x86_32_early_logical_apicid(cpu);
#endif
+ cpumask_set_cpu(cpu, cpu_number_mask);
set_cpu_possible(cpu, true);
set_cpu_present(cpu, true);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Nishanth and Alexander, Thanks for review, will update the comments in next version. Regards! Gerry On 2014/7/22 5:09, Nishanth Aravamudan wrote: > On 21.07.2014 [12:53:33 -0700], Alexander Duyck wrote: >> I do agree the description should probably be changed. There shouldn't be >> any panics involved, only a performance impact as it will be reallocating >> always if it is on a node with no memory. > > Yep, thanks for the review. > >> My intention on this was to make certain that the memory used is from the >> closest node possible. As such I believe this change likely honours that. > > Absolutely, just wanted to make it explicit that it's not a functional > fix, just a performance fix (presuming this shows up at all on systems > that have memoryless NUMA nodes). > > I'd suggest an update to the comments, as well. > > Thanks, > Nish > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel: printk: fix bool assignements
Fix coccinelle warnings.
Signed-off-by: Neil Zhang
---
kernel/printk/printk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 13e839d..89894e5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -881,7 +881,7 @@ static bool __read_mostly ignore_loglevel;
static int __init ignore_loglevel_setup(char *str)
{
- ignore_loglevel = 1;
+ ignore_loglevel = true;
pr_info("debug: ignoring loglevel setting.\n");
return 0;
@@ -948,7 +948,7 @@ static inline void boot_delay_msec(int level)
#endif
#if defined(CONFIG_PRINTK_TIME)
-static bool printk_time = 1;
+static bool printk_time = true;
#else
static bool printk_time;
#endif
@@ -1959,12 +1959,12 @@ int update_console_cmdline(char *name, int idx, char
*name_new, int idx_new, cha
return -1;
}
-bool console_suspend_enabled = 1;
+bool console_suspend_enabled = true;
EXPORT_SYMBOL(console_suspend_enabled);
static int __init console_suspend_disable(char *str)
{
- console_suspend_enabled = 0;
+ console_suspend_enabled = false;
return 1;
}
__setup("no_console_suspend", console_suspend_disable);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Michal, Thanks for your comments! As discussed, we will rework the patch set in another direction to hide memoryless node from normal slab users. Regards! Gerry On 2014/7/18 15:36, Michal Hocko wrote: > On Fri 11-07-14 15:37:26, Jiang Liu wrote: >> When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id() >> may return a node without memory, and later cause system failure/panic >> when calling kmalloc_node() and friends with returned node id. >> So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with >> memory for the/current cpu. >> >> If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id() >> is the same as cpu_to_node()/numa_node_id(). > > The change makes difference only for really tiny memcgs. If we really > have all pages on unevictable list or anon with no swap allowed and that > is the reason why no node is set in scan_nodes mask then reclaiming > memoryless node or any arbitrary close one doesn't make any difference. > The current memcg might not have any memory on that node at all. > > So the change doesn't make any practical difference and the changelog is > misleading. > >> Signed-off-by: Jiang Liu >> --- >> mm/memcontrol.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index a2c7bcb0e6eb..d6c4b7255ca9 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1933,7 +1933,7 @@ int mem_cgroup_select_victim_node(struct mem_cgroup >> *memcg) >> * we use curret node. >> */ >> if (unlikely(node == MAX_NUMNODES)) >> -node = numa_node_id(); >> +node = numa_mem_id(); >> >> memcg->last_scanned_node = node; >> return node; >> -- >> 1.7.10.4 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit b19729617929 ("drm/i915:
fix psr match conditions screw ups") from the drm tree and commit
24acaf94ed4a ("drm/i915: Fix up PSR frontbuffer tracking") from the
drm-intel tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_dp.c
index eda73ea3002f,9274ddfd78c7..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1801,20 -1762,17 +1796,18 @@@ static bool intel_edp_psr_match_conditi
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_crtc *crtc = dig_port->base.base.crtc;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
- struct drm_i915_gem_object *obj;
- struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
- dev_priv->psr.source_ok = false;
+ lockdep_assert_held(&dev_priv->psr.lock);
+ lockdep_assert_held(&dev->struct_mutex);
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
++ crtc = dig_port->base.base.crtc;
+ WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
- if (!HAS_PSR(dev)) {
- DRM_DEBUG_KMS("PSR not supported on this platform\n");
- return false;
- }
+ dev_priv->psr.source_ok = false;
- if (IS_HASWELL(dev) && (intel_encoder->type != INTEL_OUTPUT_EDP ||
- dig_port->port != PORT_A)) {
+ if (IS_HASWELL(dev) && dig_port->port != PORT_A) {
DRM_DEBUG_KMS("HSW ties PSR to DDI A (eDP)\n");
return false;
}
@@@ -1847,11 -1786,6 +1821,7 @@@
if (IS_BROADWELL(dev))
goto out;
- if (I915_READ(SPRCTL(intel_crtc->pipe)) & SPRITE_ENABLE) {
- DRM_DEBUG_KMS("PSR condition failed: Sprite is Enabled\n");
- return false;
- }
-
++ intel_crtc = to_intel_crtc(crtc);
if (I915_READ(HSW_STEREO_3D_CTL(intel_crtc->config.cpu_transcoder)) &
S3D_ENABLE) {
DRM_DEBUG_KMS("PSR condition failed: Stereo 3D is Enabled\n");
@@@ -3712,10 -3620,7 +3753,8 @@@ intel_dp_detect(struct drm_connector *c
enum drm_connector_status status;
enum intel_display_power_domain power_domain;
struct edid *edid = NULL;
+ bool ret;
- intel_runtime_pm_get(dev_priv);
-
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
signature.asc
Description: PGP signature
Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Hi Tejun and Christoph, Thanks for your suggestions and discussion. Tejun really gives a good point to hide memoryless node interface from normal slab users. I will rework the patch set to go that direction. Regards! Gerry On 2014/7/12 3:11, Christoph Lameter wrote: > On Fri, 11 Jul 2014, Tejun Heo wrote: > >> On Fri, Jul 11, 2014 at 12:29:30PM -0500, Christoph Lameter wrote: >>> GFP_THISNODE is mostly used by allocators that need memory from specific >>> nodes. The use of numa_mem_id() there is useful because one will not >>> get any memory at all when attempting to allocate from a memoryless >>> node using GFP_THISNODE. >> >> As long as it's in allocator proper, it doesn't matter all that much >> but the changes are clearly not contained, are they? > > Well there is a proliferation of memory allocators recently. NUMA is often > a second thought in those. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params
On 2014/7/22 10:04, Alasdair G Kergon wrote: On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote: Unanswered. Let's ask the same question in a different way: A quick search for 'vold' returns: https://android.googlesource.com/platform/system/vold/ and the code there requests a fixed 64K allocation to hold the names of active volumes. So unlike libdevmapper-based applications where a smaller allocation is used at first and only extended if needed, Android just assumes that 64KB is enough for everyone. So is your claim that: 1. This 64KB allocation for the brief duration of the ioctl to store the names of active device-mapper volumes leads to memory problems? [Mustn't the system *already* be in a bad state if this pushes it over the limit?] It's a good question. 1) Usually, Android mobile runs for a long time. It's very command that users don't turn off the phones for months. Users might start lots of applications. memory is used up in the end. Kernel might recollect memory over and over again. 2) We never blames this Out of memory issue fully to DM. 3) We want to improve the OOM issue. and 2. The systems on which this memory shortage occurs have so many volumes (with long names?) that a smaller allocation would not suffice? 64K is small, comparing with 2GB, even 4GB total memory. However, this 64K by kmalloc has a strict criteria. It might be continuous physical memory and align with 64K. If memory is used up, freed memory is very fragmented. Such 64K criteria is a hard request. Usually, driver can allocate such memory at booting initialization. After that, it should allocate many sparse pages instead of continuous memory. Here 64K allocation is after booting. Thanks for the kind comments. Yanmin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] gpio: make gpiochip_get_desc() gpiolib-private
On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck wrote: > On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote: >> As GPIO descriptors are not going to remain unique anymore, having this >> function public is not safe. Restrain its use to gpiolib since we have >> no user outside of it. >> > If I implement a gpio chip driver built as module, and I want to use > gpiochip_request_own_desc(), how am I supposed to get desc ? > > I understand that there is still gpio_to_desc(), but I would have thought > that > desc = gpiochip_get_desc(chip, pin); > would be better than > desc = gpio_to_desc(chip->base + pin); > > Not that it makes much of a difference for me, just asking. Actually I was thinking of changing the prototype of gpiochip_request_own_desc(), and your comment definitely strenghtens that idea. gpiochip functions should not work with descriptors, especially since we are going to switch to a multiple-consumer scheme where there won't be any canonical descriptor anymore. Thus, how about turning gpiochip_request_own_desc() into this: struct gpio_desc * gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label); which would basically do both the gpiochip_get_desc() and former gpiochip_request_own_desc() in one call. I think it should satisfy everybody and removes the need to have gpiochip_get_desc() (a not very useful function by itself) exposed out of gpiolib. I will send a patch taking care of this if you agree that makes sense. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params
On 2014/7/22 9:23, Alasdair G Kergon wrote: On 2014/7/9 6:39, Mikulas Patocka wrote: Which ioctl with more than 16kB arguments do you use? Unanswered. Let's ask the same question in a different way: Please supply the output of these three commands on the real-world system on which you believe that that particular allocation is causing you a problem: dmsetup info -c dmsetup table dmsetup status Android doesn't include the command. We compiled lvm2-2_02_107.tar.gz and copy dmsetup to the board. But command reports No devices. # /data/bin/dmsetup info No devices found # cat /proc/devices Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 4 ttyMFD 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 21 sg 29 fb 81 video4linux 89 i2c 108 ppp 116 alsa 128 ptm 136 pts 153 spi 166 ttyACM 180 usb 188 ttyUSB 189 usb_device 202 cpu/msr 203 cpu/cpuid 226 drm 241 mdm_ctrl 242 sep54 243 roccat 244 hidraw 245 ttyGS 246 usbmon 247 ttyPTI 248 gsmtty 249 bsg 250 iio 251 ptp 252 pps 253 media 254 rtc Block devices: 1 ramdisk 259 blkext 7 loop 8 sd 9 md 11 sr 65 sd 66 sd 67 sd 68 sd 69 sd 70 sd 71 sd 128 sd 129 sd 130 sd 131 sd 132 sd 133 sd 134 sd 135 sd 179 mmc 253 device-mapper 254 mdp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit d05410f9a450
("drm/i915: split conversion function out into separate function") from
the drm tree and commit 6b09e72050b4 ("drm/i915: Power gating display
wells during i915_pm_suspend") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
P.S. Daniel, that drm-intel tree commit has no Signed-off-by from its
author ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index a5af732b87b8,1389d8a30f0a..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4314,27 -4300,6 +4314,23 @@@ static void i9xx_pfit_enable(struct int
I915_WRITE(BCLRPAT(crtc->pipe), 0);
}
+static enum intel_display_power_domain port_to_power_domain(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return POWER_DOMAIN_PORT_DDI_A_4_LANES;
+ case PORT_B:
+ return POWER_DOMAIN_PORT_DDI_B_4_LANES;
+ case PORT_C:
+ return POWER_DOMAIN_PORT_DDI_C_4_LANES;
+ case PORT_D:
+ return POWER_DOMAIN_PORT_DDI_D_4_LANES;
+ default:
+ WARN_ON_ONCE(1);
+ return POWER_DOMAIN_PORT_OTHER;
+ }
+}
+
- #define for_each_power_domain(domain, mask) \
- for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
- if ((1 << (domain)) & (mask))
-
enum intel_display_power_domain
intel_display_port_power_domain(struct intel_encoder *intel_encoder)
{
signature.asc
Description: PGP signature
[RESEND RFC PATCH v1 0/70] Gloabl CPU Hot-plug flag _FROZEN Clean up
Back to long time ago (about 1.5 years), Thomas began the work for CPU hot-plug, one first thing is CPU hotplug flag cleanup. Paul hoped all the _FROZEN variants of the notifier actions can be removed at that time. Now here it is. Patch 1 ~ 69: remove all kinds of XXX_FROZEN usages Patch 70: remove XXX_FROZEN from the kernel thoroughly Not sure if removing XXX_FROZEN flags thoroughly is overkilled. Fix me if I'm wrong. P.S. My last post is banned because of the capital Triple-X in subject :-( Chen, Gong (69): ia64, err_inject: _FROZEN Cleanup ia64, mca: _FROZEN Cleanup ia64, palinfo: _FROZEN Cleanup ia64, salinfo: _FROZEN Cleanup ia64, topology: _FROZEN Cleanup x86, intel_cacheinfo: _FROZEN Cleanup x86, mce, therm_throt: _FROZEN Cleanup x86, mce_amd: _FROZEN Cleanup x86, kvm: _FROZEN Cleanup x86, vsyscall_64: _FROZEN Cleanup x86, pci, amd_bus: _FROZEN Cleanup x86, x2apic_cluster: _FROZEN Cleanup x86, microcode, core: _FROZEN Cleanup x86, kernel, cpuid: _FROZEN Cleanup x86, kernel, msr: _FROZEN Cleanup arm, vfp, vfpmodule: _FROZEN Cleanup arm, kvm: _FROZEN Cleanup powerpc, sysfs: _FROZEN Cleanup powerpc, mm, numa: _FROZEN Cleanup powerpc, powermac, smp: _FROZEN Cleanup powerpc, mmu_context_nohash: _FROZEN Cleanup mips, loongson, smp: _FROZEN Cleanup s390, perf_cpum_sf: _FROZEN Cleanup sparc, sysfs: _FROZEN Cleanup rcu, tree: _FROZEN Cleanup kernel, padata: _FROZEN Cleanup kernel, profile: _FROZEN Cleanup kernel, sched, core: _FROZEN Cleanup kernel, hrtimer: _FROZEN Cleanup kernel, relay: _FROZEN Cleanup kernel, smp: _FROZEN Cleanup kernel, timer: _FROZEN Cleanup kernel, softirq: _FROZEN Cleanup mm, slab: _FROZEN Cleanup mm, vmscan: _FROZEN Cleanup mm, vmstat: _FROZEN Cleanup mm, memcontrol: _FROZEN Cleanup mm, page_alloc: _FROZEN Cleanup mm, slub: _FROZEN Cleanup fs, buffer: _FROZEN Cleanup xfs, xfs_mount: _FROZEN Cleanup net, iucv: _FROZEN Cleanup net, core, flow: _FROZEN Cleanup net, core, dev: _FROZEN Cleanup block, blk-mq: _FROZEN Cleanup block, blk-iopoll: _FROZEN Cleanup block, blk-softirq: _FROZEN Cleanup driver, base, topology: _FROZEN Cleanup clocksource, metag_generic: _FROZEN Cleanup powercap, intel_rapl: _FROZEN Cleanup cpuidle, cpuidle-powernv: _FROZEN Cleanup cpuidle, cpuidle-pseries: _FROZEN Cleanup cpufreq, acpi-cpufreq: _FROZEN Cleanup irqchip, irq-armada-370-xp: _FROZEN Cleanup irqchip, irq-gic: _FROZEN Cleanup scsi, bnx2fc, bnx2fc_fcoe: _FROZEN Cleanup scsi, bnx2i, bnx2i_init: _FROZEN Cleanup scsi, fcoe: _FROZEN Cleanup scsi, virtio_scsi: _FROZEN Cleanup md, raid5: _FROZEN Cleanup virt, kvm, arm, arch_timer: _FROZEN Cleanup virt, kvm, arm, vgic: _FROZEN Cleanup trace, ring_buffer: _FROZEN Cleanup oprofile, timer_int: _FROZEN Cleanup lib, cpu-notifier-error-inject: _FROZEN Cleanup lib, percpu_counter: _FROZEN Cleanup lib, radix-tree: _FROZEN Cleanup staging, lustre, linux-cpu: _FROZEN Cleanup cpu: Eliminate _FROZEN flags thoroughly Thomas Gleixner (1): cpu: Restructure FROZEN state handling arch/arm/kvm/arm.c | 3 +- arch/arm/vfp/vfpmodule.c | 6 +- arch/ia64/kernel/err_inject.c | 4 +- arch/ia64/kernel/mca.c | 3 +- arch/ia64/kernel/palinfo.c | 4 +- arch/ia64/kernel/salinfo.c | 4 +- arch/ia64/kernel/topology.c| 4 +- arch/mips/loongson/loongson-3/smp.c| 5 +- arch/powerpc/kernel/sysfs.c| 4 +- arch/powerpc/mm/mmu_context_nohash.c | 5 +- arch/powerpc/mm/numa.c | 5 +- arch/powerpc/platforms/powermac/smp.c | 11 ++-- arch/s390/kernel/perf_cpum_sf.c| 1 - arch/sparc/kernel/sysfs.c | 4 +- arch/x86/kernel/apic/x2apic_cluster.c | 11 +++- arch/x86/kernel/cpu/intel_cacheinfo.c | 4 +- arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 +- arch/x86/kernel/cpu/mcheck/therm_throt.c | 5 +- arch/x86/kernel/cpu/microcode/core.c | 8 +-- arch/x86/kernel/cpuid.c| 6 +- arch/x86/kernel/kvm.c | 9 +-- arch/x86/kernel/msr.c | 6 +- arch/x86/kernel/vsyscall_64.c | 2 +- arch/x86/pci/amd_bus.c | 3 +- block/blk-iopoll.c | 2 +- block/blk-mq.c
