Re: [PATCH V2] ata: Disabling the async PM for JMicron chips
On 09/24/2014 03:22 PM, Chuansheng Liu wrote:
> Like the commit e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip
> 363/361"),
> Barto found the similar issue for JMicron chip 368, that 363/368 has no
> parent-children relationship, but they have the power dependency.
>
> So here we can exclude the JMicron chips out of pm_async method directly,
> to avoid further similar issues.
>
> Details in:
> https://bugzilla.kernel.org/show_bug.cgi?id=84861
I think we can disable the async PM for JMicron chips in PCI subsystem:
pci_pm_init, check if it is JMicron chip and then enable_async
accordingly. The problem doesn't have much to do with ATA, so move them
to PCI may be more appropriate.
Thanks,
Aaron
>
> Reported-and-tested-by: Barto
> Signed-off-by: Chuansheng Liu
> ---
> drivers/ata/ahci.c | 11 +--
> drivers/ata/pata_jmicron.c | 11 +--
> 2 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index a0cc0ed..85aa6ec 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1340,15 +1340,14 @@ static int ahci_init_one(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
>
> /*
> - * The JMicron chip 361/363 contains one SATA controller and one
> + * The JMicron chip 361/363/368 contains one SATA controller and one
>* PATA controller,for powering on these both controllers, we must
>* follow the sequence one by one, otherwise one of them can not be
> - * powered on successfully, so here we disable the async suspend
> - * method for these chips.
> + * powered on successfully.
> + * Here we can exclude the Jmicron family directly out of pm_async
> + * method to follow the power-on sequence.
>*/
> - if (pdev->vendor == PCI_VENDOR_ID_JMICRON &&
> - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 ||
> - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361))
> + if (pdev->vendor == PCI_VENDOR_ID_JMICRON)
> device_disable_async_suspend(>dev);
>
> /* acquire resources */
> diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
> index 47e418b..1d685b6 100644
> --- a/drivers/ata/pata_jmicron.c
> +++ b/drivers/ata/pata_jmicron.c
> @@ -144,15 +144,14 @@ static int jmicron_init_one (struct pci_dev *pdev,
> const struct pci_device_id *i
> const struct ata_port_info *ppi[] = { , NULL };
>
> /*
> - * The JMicron chip 361/363 contains one SATA controller and one
> + * The JMicron chip 361/363/368 contains one SATA controller and one
>* PATA controller,for powering on these both controllers, we must
>* follow the sequence one by one, otherwise one of them can not be
> - * powered on successfully, so here we disable the async suspend
> - * method for these chips.
> + * powered on successfully.
> + * Here we can exclude the Jmicron family directly out of pm_async
> + * method to follow the power-on sequence.
>*/
> - if (pdev->vendor == PCI_VENDOR_ID_JMICRON &&
> - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 ||
> - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361))
> + if (pdev->vendor == PCI_VENDOR_ID_JMICRON)
> device_disable_async_suspend(>dev);
>
> return ata_pci_bmdma_init_one(pdev, ppi, _sht, NULL, 0);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linus GIT - 3.17.0-rc6+ - BUG: unable to handle kernel NULL pointer dereference - IP: [] thermal_get_trip_type+0x17/0x84 [thermal]
On Sun, 2014-09-28 at 01:24 -0400, Miles Lane wrote: > This occurs during the boot process. It is not triggered by userspace > as far as I can tell. There are other OOPS messages. I can send the > full list if it will help. > yes, please do. is this 100% reproducible for every boot? what is the latest kernel version you've tried that does not have this problem? does the problem still exist if you blacklist the acpi thermal driver, aka, thermal.ko? what do you get in dmesg if you blacklist the thermal driver and modprobe it manually AFTER boot? thanks, rui > > [2.364611] BUG: unable to handle kernel NULL pointer dereference > at 0039 > [2.364615] IP: [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364616] PGD 374d6067 PUD 374d7067 PMD 0 > [2.364618] Oops: [#1] PREEMPT SMP > [2.364621] Modules linked in: thermal(+) mmc_core > [2.364623] CPU: 0 PID: 971 Comm: systemd-udevd Not tainted 3.17.0-rc6+ #6 > [2.364624] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 > 11/14/2013 > [2.364625] task: 8802155f8cf0 ti: 8800374f4000 task.ti: > 8800374f4000 > [2.364628] RIP: 0010:[] [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364629] RSP: 0018:8800374f7b50 EFLAGS: 00010202 > [2.364629] RAX: 0001 RBX: 0001 RCX: > > [2.364630] RDX: 8800374f7b7c RSI: RDI: > 880216a67800 > [2.364631] RBP: 8800374f7b50 R08: R09: > 0700 > [2.364631] R10: 8802156c7300 R11: 0001 R12: > > [2.364632] R13: R14: R15: > 880216a67800 > [2.364633] FS: 7f85e4b55880() GS:88021fa0() > knlGS: > [2.364634] CS: 0010 DS: ES: CR0: 80050033 > [2.364635] CR2: 0039 CR3: 374d5000 CR4: > 001407f0 > [2.364635] Stack: > [2.364637] 8800374f7ba8 813cd140 > 880216a67804 > [2.364638] 880216a67818 8800374f7bb8 880216a67000 > 8802168721e0 > [2.364639] 88021630e860 88021630e890 88021630e830 > 8800374f7c10 > [2.364640] Call Trace: > [2.364645] [] thermal_zone_device_register+0x479/0x75a > [2.364649] [] acpi_thermal_add+0x24d/0x427 [thermal] > [2.364653] [] acpi_device_probe+0x4a/0xf0 > [2.364655] [] driver_probe_device+0xb2/0x1e8 > [2.364657] [] __driver_attach+0x58/0x7a > [2.364659] [] ? __device_attach+0x38/0x38 > [2.364662] [] bus_for_each_dev+0x68/0x80 > [2.364663] [] driver_attach+0x19/0x1b > [2.364664] [] bus_add_driver+0x103/0x1c2 > [2.364666] [] driver_register+0x89/0xc5 > [2.364669] [] acpi_bus_register_driver+0x38/0x3a > [2.364671] [] acpi_thermal_init+0x67/0x81 [thermal] > [2.364673] [] ? 0xc0159000 > [2.364675] [] do_one_initcall+0x183/0x198 > [2.364678] [] ? __vunmap+0xa4/0xac > [2.364681] [] load_module+0x16d3/0x1c4e > [2.364683] [] SyS_finit_module+0x59/0x66 > [2.364685] [] ? SyS_finit_module+0x59/0x66 > [2.364688] [] tracesys+0xdd/0xe2 > [2.364705] Code: 74 10 31 c0 83 ba 48 05 00 00 00 0f 95 c0 89 06 > 31 c0 5d c3 89 f1 55 48 8b 87 e8 02 00 00 c1 e9 1f 48 89 e5 75 6b 48 > 85 c0 74 66 40 38 01 74 0e 85 f6 75 08 c7 02 03 00 00 00 eb 50 ff > ce f6 > [2.364708] RIP [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364708] RSP > [2.364709] CR2: 0039 > > [2.393720] BUG: unable to handle kernel NULL pointer dereference > at 0030 > [2.394613] IP: [] add_disk+0x88/0x3ff > [2.395490] PGD 375b1067 PUD 375b2067 PMD 0 > [2.396371] Oops: [#2] PREEMPT SMP > [2.397150] Modules linked in: sr_mod(+) atkbd cdrom mii thermal(+) > mmc_core > [2.397935] CPU: 0 PID: 974 Comm: systemd-udevd Tainted: G D > 3.17.0-rc6+ #6 > [2.398738] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 > 11/14/2013 > [2.399547] task: 8802155fcda0 ti: 88003749 task.ti: > 88003749 > [2.400336] RIP: 0010:[] [] > add_disk+0x88/0x3ff > [2.401142] RSP: 0018:880037493b60 EFLAGS: 00010202 > [2.401987] RAX: RBX: 8800376ee800 RCX: > 0009 > [2.402793] RDX: 000b RSI: 880037493b64 RDI: > 8800376ee848 > [2.403591] RBP: 880037493ba8 R08: R09: > > [2.40] R10: 880037493b78 R11: 81672240 R12: > 8800376ee800 > [2.405248] R13: 8800376ee80c R14: R15: > 88021629237c > [2.406049] FS: 7f85e4b55880() GS:88021fa0() > knlGS: > [2.406909] CS: 0010 DS: ES: CR0: 80050033 > [2.407726] CR2: 0030 CR3: 375b CR4: > 001407f0 > [2.408558] Stack: > [2.409458]
Linus GIT - 3.17.0-rc6+ - BUG: unable to handle kernel NULL pointer dereference - IP: [] thermal_get_trip_type+0x17/0x84 [thermal]
This occurs during the boot process. It is not triggered by userspace as far as I can tell. There are other OOPS messages. I can send the full list if it will help. [2.364611] BUG: unable to handle kernel NULL pointer dereference at 0039 [2.364615] IP: [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364616] PGD 374d6067 PUD 374d7067 PMD 0 [2.364618] Oops: [#1] PREEMPT SMP [2.364621] Modules linked in: thermal(+) mmc_core [2.364623] CPU: 0 PID: 971 Comm: systemd-udevd Not tainted 3.17.0-rc6+ #6 [2.364624] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [2.364625] task: 8802155f8cf0 ti: 8800374f4000 task.ti: 8800374f4000 [2.364628] RIP: 0010:[] [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364629] RSP: 0018:8800374f7b50 EFLAGS: 00010202 [2.364629] RAX: 0001 RBX: 0001 RCX: [2.364630] RDX: 8800374f7b7c RSI: RDI: 880216a67800 [2.364631] RBP: 8800374f7b50 R08: R09: 0700 [2.364631] R10: 8802156c7300 R11: 0001 R12: [2.364632] R13: R14: R15: 880216a67800 [2.364633] FS: 7f85e4b55880() GS:88021fa0() knlGS: [2.364634] CS: 0010 DS: ES: CR0: 80050033 [2.364635] CR2: 0039 CR3: 374d5000 CR4: 001407f0 [2.364635] Stack: [2.364637] 8800374f7ba8 813cd140 880216a67804 [2.364638] 880216a67818 8800374f7bb8 880216a67000 8802168721e0 [2.364639] 88021630e860 88021630e890 88021630e830 8800374f7c10 [2.364640] Call Trace: [2.364645] [] thermal_zone_device_register+0x479/0x75a [2.364649] [] acpi_thermal_add+0x24d/0x427 [thermal] [2.364653] [] acpi_device_probe+0x4a/0xf0 [2.364655] [] driver_probe_device+0xb2/0x1e8 [2.364657] [] __driver_attach+0x58/0x7a [2.364659] [] ? __device_attach+0x38/0x38 [2.364662] [] bus_for_each_dev+0x68/0x80 [2.364663] [] driver_attach+0x19/0x1b [2.364664] [] bus_add_driver+0x103/0x1c2 [2.364666] [] driver_register+0x89/0xc5 [2.364669] [] acpi_bus_register_driver+0x38/0x3a [2.364671] [] acpi_thermal_init+0x67/0x81 [thermal] [2.364673] [] ? 0xc0159000 [2.364675] [] do_one_initcall+0x183/0x198 [2.364678] [] ? __vunmap+0xa4/0xac [2.364681] [] load_module+0x16d3/0x1c4e [2.364683] [] SyS_finit_module+0x59/0x66 [2.364685] [] ? SyS_finit_module+0x59/0x66 [2.364688] [] tracesys+0xdd/0xe2 [2.364705] Code: 74 10 31 c0 83 ba 48 05 00 00 00 0f 95 c0 89 06 31 c0 5d c3 89 f1 55 48 8b 87 e8 02 00 00 c1 e9 1f 48 89 e5 75 6b 48 85 c0 74 66 40 38 01 74 0e 85 f6 75 08 c7 02 03 00 00 00 eb 50 ff ce f6 [2.364708] RIP [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364708] RSP [2.364709] CR2: 0039 [2.393720] BUG: unable to handle kernel NULL pointer dereference at 0030 [2.394613] IP: [] add_disk+0x88/0x3ff [2.395490] PGD 375b1067 PUD 375b2067 PMD 0 [2.396371] Oops: [#2] PREEMPT SMP [2.397150] Modules linked in: sr_mod(+) atkbd cdrom mii thermal(+) mmc_core [2.397935] CPU: 0 PID: 974 Comm: systemd-udevd Tainted: G D 3.17.0-rc6+ #6 [2.398738] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [2.399547] task: 8802155fcda0 ti: 88003749 task.ti: 88003749 [2.400336] RIP: 0010:[] [] add_disk+0x88/0x3ff [2.401142] RSP: 0018:880037493b60 EFLAGS: 00010202 [2.401987] RAX: RBX: 8800376ee800 RCX: 0009 [2.402793] RDX: 000b RSI: 880037493b64 RDI: 8800376ee848 [2.403591] RBP: 880037493ba8 R08: R09: [2.40] R10: 880037493b78 R11: 81672240 R12: 8800376ee800 [2.405248] R13: 8800376ee80c R14: R15: 88021629237c [2.406049] FS: 7f85e4b55880() GS:88021fa0() knlGS: [2.406909] CS: 0010 DS: ES: CR0: 80050033 [2.407726] CR2: 0030 CR3: 375b CR4: 001407f0 [2.408558] Stack: [2.409458] 00b0814e22e5 880037493b90 81352deb 88021552 [2.410372] 880216292300 8800376ee800 880216b00968 [2.411297] 88021629237c 880037493c30 c01a1d40 8808200e [2.412205] Call Trace: [2.413057] [] ? __pm_runtime_use_autosuspend+0x5e/0x65 [2.413935] [] sr_probe+0x480/0x4d2 [sr_mod] [2.414853] [] driver_probe_device+0xb2/0x1e8 [2.415732] [] __driver_attach+0x58/0x7a [2.416657] [] ? __device_attach+0x38/0x38 [2.417539] [] bus_for_each_dev+0x68/0x80 [2.418421] [] driver_attach+0x19/0x1b [2.419341] []
Re: [PATCH v5 RESEND 1/3] ARM: EXYNOS: Move code from hotplug.c to platsmp.c
On 09/27/14 17:39, Krzysztof Kozlowski wrote:
W dniu 26.09.2014 o 23:13, Arnd Bergmann pisze:
On Friday 05 September 2014, Krzysztof Kozlowski wrote:
The commit only moves code around with one additional observable change:
the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These
CFLAGS are not necessary any more.
This turns out to be wrong, and your change broke 'allmodconfig' builds
in linux-next. Please apply this patch on top.
Arnd, Krzysztof commented its fix has been submitted and landed in my
-test tree not -next because it should be handled in rmk's tree I think.
I sent the patch to RMK patch tracking system just now and it should be
fine in there.
BTW, I just applied the fix in my -next until its ladning in RMK tree
but as you know it will be not be sent to arm-soc via samsung tree...
One more, Arnd please pull my pull-request 2nd round and 3rd round for
samsung stuff for 3.18.
My patch definitely needed more testing.
I posted a fix here:
https://lkml.org/lkml/2014/9/24/163
However it seems that it wasn't picked up by anyone yet.
Russell, could you pick up the patch (with acks from Nicolas and Kukjin)?
I believe Russell will take the patch in his tree.
Thanks,
Kukjin
8<--
From 4ba6bf8806caec386e35930314dbad071284c837 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Fri, 26 Sep 2014 23:09:38 +0200
Subject: [PATCH] ARM: EXYNOS: fix build error in platsmp.c
/tmp/ccYeWL3V.s: Assembler messages:
/tmp/ccYeWL3V.s:659: Error: selected processor does not support ARM
mode `isb '
/tmp/ccYeWL3V.s:664: Error: selected processor does not support ARM
mode `isb '
/tmp/ccYeWL3V.s:665: Error: selected processor does not support ARM
mode `dsb '
make[3]: *** [arch/arm/mach-exynos/platsmp.o] Error 1
Signed-off-by: Arnd Bergmann
Fixes: 17342534e1d932 ("ARM: EXYNOS: Move code from hotplug.c to
platsmp.c")
diff --git a/arch/arm/mach-exynos/Makefile
b/arch/arm/mach-exynos/Makefile
index 4e49d4efb264..64324bf5edb4 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PM_SLEEP) += suspend.o
obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+CFLAGS_platsmp.o := -march=armv7-a
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: perf: perf_fuzzer triggers instant reboot
On 09/25/2014 12:38 PM, Cong Wang wrote:
> On Wed, Sep 24, 2014 at 9:59 PM, Vince Weaver
> wrote:
>> >
>> > So I noticed Cong Wang's patch (3577af70a2ce4853d58e57d832e687d739281479)
>> > perf: Fix a race condition in perf_remove_from_context()
>> >
>> > and that sounds a lot like the weird fork()/memory-corruption bug that the
>> > fuzzer has been triggering.
>> >
>> > So I applied that patch alone on top of the 3.17-rc4 kernel that I could
>> > reproducibly reboot... and with the patch I can't trigger the problem
>> > anymore.
>> >
>> > Now that just might mean the patch pushed the code around enough so my
>> > test doesn't trigger, but there is hope that maybe this fixes things.
> I read this as it fixes your crash as well?
Cong, I *suspect* that that commit also triggers the following lockdep warning.
I haven't confirmed that, but hopefully it'll help:
[ 690.800861] ==
[ 690.800864] [ INFO: possible circular locking dependency detected ]
[ 690.800877] 3.17.0-rc6-next-20140926-sasha-00051-g9253dff-dirty #1242 Not
tainted
[ 690.800881] ---
[ 690.800887] trinity-c95/17888 is trying to acquire lock:
[ 690.800925] (&(>lock)->rlock){..-.-.}, at: __queue_work
(kernel/workqueue.c:1325)
[ 690.800929]
[ 690.800929] but task is already holding lock:
[ 690.800955] (>lock){-.-...}, at: perf_lock_task_context
(kernel/events/core.c:988)
[ 690.800958]
[ 690.800958] which lock already depends on the new lock.
[ 690.800958]
[ 690.800960]
[ 690.800960] the existing dependency chain (in reverse order) is:
[ 690.800971]
[ 690.800971] -> #3 (>lock){-.-...}:
[ 690.800990] lock_acquire (kernel/locking/lockdep.c:3610)
[ 690.801006] _raw_spin_lock (include/linux/spinlock_api_smp.h:143
kernel/locking/spinlock.c:151)
[ 690.801023] __perf_event_task_sched_out (kernel/events/core.c:2419
kernel/events/core.c:2445)
[ 690.801040] perf_event_task_sched_out (include/linux/perf_event.h:714)
[ 690.801051] __schedule (kernel/sched/core.c:2178 kernel/sched/core.c:2216
kernel/sched/core.c:2336 kernel/sched/core.c:2858)
[ 690.801061] preempt_schedule_irq (./arch/x86/include/asm/paravirt.h:814
kernel/sched/core.c:2975)
[ 690.801075] retint_kernel (arch/x86/kernel/entry_64.S:920)
[ 690.801086] perf_swevent_init (kernel/events/core.c:5963
kernel/events/core.c:5983 kernel/events/core.c:6043)
[ 690.801100] perf_init_event (kernel/events/core.c:6841)
[ 690.801110] perf_event_alloc (kernel/events/core.c:6996)
[ 690.801124] SYSC_perf_event_open (kernel/events/core.c:7291)
[ 690.801136] SyS_perf_event_open (kernel/events/core.c:7210)
[ 690.801149] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
[ 690.801163]
[ 690.801163] -> #2 (>lock){-.-.-.}:
[ 690.801185] lock_acquire (kernel/locking/lockdep.c:3610)
[ 690.801194] _raw_spin_lock (include/linux/spinlock_api_smp.h:143
kernel/locking/spinlock.c:151)
[ 690.801206] wake_up_new_task (include/linux/sched.h:2932
kernel/sched/core.c:320 kernel/sched/core.c:2128)
[ 690.801220] do_fork (kernel/fork.c:1690)
[ 690.801233] kernel_thread (kernel/fork.c:1712)
[ 690.801250] rest_init (init/main.c:404)
[ 690.801265] start_kernel (init/main.c:682)
[ 690.801280] x86_64_start_reservations (arch/x86/kernel/head64.c:199)
[ 690.801297] x86_64_start_kernel (arch/x86/kernel/head64.c:188)
[ 690.801315]
[ 690.801315] -> #1 (>pi_lock){-.-.-.}:
[ 690.801326] lock_acquire (kernel/locking/lockdep.c:3610)
[ 690.801340] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:117
kernel/locking/spinlock.c:159)
[ 690.801350] try_to_wake_up (kernel/sched/core.c:1692)
[ 690.801364] wake_up_process (kernel/sched/core.c:1787 (discriminator 3))
[ 690.801377] create_worker (include/linux/spinlock.h:359
kernel/workqueue.c:1713)
[ 690.801401] init_workqueues (kernel/workqueue.c:4861)
[ 690.801415] do_one_initcall (init/main.c:792)
[ 690.801427] kernel_init_freeable (init/main.c:893 init/main.c:999)
[ 690.801436] kernel_init (init/main.c:937)
[ 690.801457] ret_from_fork (arch/x86/kernel/entry_64.S:348)
[ 690.801474]
[ 690.801474] -> #0 (&(>lock)->rlock){..-.-.}:
[ 690.801488] __lock_acquire (kernel/locking/lockdep.c:1842
kernel/locking/lockdep.c:1947 kernel/locking/lockdep.c:2133
kernel/locking/lockdep.c:3184)
[ 690.801499] lock_acquire (kernel/locking/lockdep.c:3610)
[ 690.801507] _raw_spin_lock (include/linux/spinlock_api_smp.h:143
kernel/locking/spinlock.c:151)
[ 690.801517] __queue_work (kernel/workqueue.c:1325)
[ 690.801525] queue_work_on (kernel/workqueue.c:1403)
[ 690.801542] free_object (lib/debugobjects.c:209)
[ 690.801552] __debug_check_no_obj_freed (lib/debugobjects.c:718)
[ 690.801561] debug_check_no_obj_freed (lib/debugobjects.c:727)
[ 690.801574] kmem_cache_free (mm/slub.c:2687 mm/slub.c:2715)
[ 690.801583] free_task (kernel/fork.c:221)
[ 690.801594] __put_task_struct (kernel/fork.c:251)
[ 690.801609] put_ctx
Re: [PATCH] arm: Remove read of issue in sa1111.c in sa1111_resume
On 14-09-27 11:31 PM, Randy Dunlap wrote:
> On 09/27/14 19:50, Nicholas Krause wrote:
>> This removes the FIXME message and issue with reading in this driver before
>> resuming
>> in the function, sa_resume.
>
> You need to explain why this makes any sense.
> Hint: it doesn't.
>
>> Signed-off-by: Nicholas Krause
>> ---
>> arch/arm/common/sa.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
>> index e57d7e5..0c4b9a9 100644
>> --- a/arch/arm/common/sa.c
>> +++ b/arch/arm/common/sa.c
>> @@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev)
>>
>> /*
>> * Ensure that the SA is still here.
>> - * FIXME: shouldn't do this here.
>> */
>> -id = sa_readl(sachip->base + SA_SKID);
>> if ((id & SKID_ID_MASK) != SKID_SA_ID) {
>> __sa_remove(sachip);
>> platform_set_drvdata(dev, NULL);
>>
>
>
Thanks for the reply Randy. I was wondering if was what the FIX ME meant if it
meant something else please let me
known.
Sorry,
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 2/3] ARM: dts: vf610: Add SNVS node
On Fri, Sep 26, 2014 at 06:44:00PM +0530, Sanchayan Maity wrote:
> This adds a devicetree node for RTC support
> for the VF610 platform.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/vf610.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index 4d2ec32..3c0c757 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -381,6 +381,21 @@
> < VF610_CLK_DMAMUX3>;
> };
>
> + snvs0: snvs@400a7000 {
> + compatible = "fsl,sec-v4.0-mon", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x400a7000 0x2000>;
> +
> + snvs-rtc-lp@34 {
> + compatible = "fsl,sec-v4.0-mon-rtc-lp";
> + reg = <0x34 0x58>;
> + interrupts = <0 100
> IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < VF610_CLK_SNVS>;
> + clock-names = "snvs";
The name should describe the clock usage inside the block, so "snvs" is
not a good description.
Shawn
> + };
> + };
> +
> uart4: serial@400a9000 {
> compatible = "fsl,vf610-lpuart";
> reg = <0x400a9000 0x1000>;
> --
> 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 3/3] drivers/rtc/rtc-snvs: Add clock support
On Fri, Sep 26, 2014 at 06:44:01PM +0530, Sanchayan Maity wrote:
> This patch adds clock enable and disable support
> for the SNVS peripheral which is required by the
> SNVS RTC.
>
> Signed-off-by: Sanchayan Maity
> ---
> drivers/rtc/rtc-snvs.c | 48
> +++-
> 1 file changed, 39 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c
> index fa384fe..f3e8f05 100644
> --- a/drivers/rtc/rtc-snvs.c
> +++ b/drivers/rtc/rtc-snvs.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> /* These register offsets are relative to LP (Low Power) range */
> #define SNVS_LPCR0x04
> @@ -39,6 +40,7 @@ struct snvs_rtc_data {
> void __iomem *ioaddr;
> int irq;
> spinlock_t lock;
> + struct clk *clk;
> };
>
> static u32 rtc_read_lp_counter(void __iomem *ioaddr)
> @@ -260,8 +262,31 @@ static int snvs_rtc_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> + ret = devm_request_irq(>dev, data->irq, snvs_rtc_irq_handler,
> +IRQF_SHARED, "rtc alarm", >dev);
> + if (ret) {
> + dev_err(>dev, "failed to request irq %d: %d\n",
> + data->irq, ret);
> + return ret;
> + }
> +
> + data->clk = devm_clk_get(>dev, "snvs");
> + if (IS_ERR(data->clk)) {
> + dev_err(>dev, "failed getting clock, err = %ld\n",
> + PTR_ERR(data->clk));
> + ret = PTR_ERR(data->clk);
> + return ret;
> + }
No. This will break all i.MX6 devices running a DTB without clock
definition.
Shawn
> +
> platform_set_drvdata(pdev, data);
>
> + ret = clk_prepare_enable(data->clk);
> + if (ret) {
> + dev_err(>dev,
> + "Could not prepare or enable the snvs clock\n");
> + return ret;
> + }
> +
> spin_lock_init(>lock);
>
> /* Initialize glitch detect */
> @@ -275,23 +300,20 @@ static int snvs_rtc_probe(struct platform_device *pdev)
>
> device_init_wakeup(>dev, true);
>
> - ret = devm_request_irq(>dev, data->irq, snvs_rtc_irq_handler,
> -IRQF_SHARED, "rtc alarm", >dev);
> - if (ret) {
> - dev_err(>dev, "failed to request irq %d: %d\n",
> - data->irq, ret);
> - return ret;
> - }
> -
> data->rtc = devm_rtc_device_register(>dev, pdev->name,
> _rtc_ops, THIS_MODULE);
> if (IS_ERR(data->rtc)) {
> ret = PTR_ERR(data->rtc);
> dev_err(>dev, "failed to register rtc: %d\n", ret);
> - return ret;
> + goto error_rtc_device_register;
> }
>
> return 0;
> +
> +error_rtc_device_register:
> + clk_disable_unprepare(data->clk);
> +
> + return ret;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -302,16 +324,24 @@ static int snvs_rtc_suspend(struct device *dev)
> if (device_may_wakeup(dev))
> enable_irq_wake(data->irq);
>
> + clk_disable_unprepare(data->clk);
> +
> return 0;
> }
>
> static int snvs_rtc_resume(struct device *dev)
> {
> + int ret;
> +
> struct snvs_rtc_data *data = dev_get_drvdata(dev);
>
> if (device_may_wakeup(dev))
> disable_irq_wake(data->irq);
>
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> return 0;
> }
> #endif
> --
> 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] i2c designware add support of I2C standard mode
On Sat, 20 Sep 2014, Wolfram Sang wrote: > On Wed, Aug 20, 2014 at 04:29:08PM +0200, Romain Baeriswyl wrote: > > From: Romain Baeriswyl > > > > Some legacy devices support ony I2C standard mode at 100kHz. > > This patch allows to select the standard mode through the DTS > > with the use of the existing clock-frequency parameter. > > > > When clock-frequency parameter is not set, the fast mode is selected. > > Only when the parameter is set at 10, the standard mode is selected. > > > > Signed-off-by: Romain Baeriswyl > > Reviewed-by: Christian Ruppert > > Applied to for-next, thanks to all involved! > > I don't see this in git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git Is this in i2c/i2c/for-next? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, MCE: support raising machine check poll for software MCE injection in IRQ context
On Tue, 2014-08-12 at 20:45 +0800, Chen Yucong wrote:
> At present MCJ_NMI_BROADCAST(same for raise_local) supports both
> raise_exception()
> and raise_poll(), but MCJ_IRQ_BROADCAST only supports raise_exception(). The
> goal
> of this patch is that MCJ_IRQ_BROADCAST can support raising machine check
> poll.
>
> Signed-off-by: Chen Yucong
> ---
> arch/x86/kernel/cpu/mcheck/mce-inject.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce-inject.c
> b/arch/x86/kernel/cpu/mcheck/mce-inject.c
> index 5ac2d1f..97e4f7a 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce-inject.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce-inject.c
> @@ -99,11 +99,13 @@ static void mce_irq_ipi(void *info)
> int cpu = smp_processor_id();
> struct mce *m = &__get_cpu_var(injectm);
>
> - if (cpumask_test_cpu(cpu, mce_inject_cpumask) &&
> - m->inject_flags & MCJ_EXCEPTION) {
> - cpumask_clear_cpu(cpu, mce_inject_cpumask);
> + if (!cpumask_test_cpu(cpu, mce_inject_cpumask))
> + return;
> + cpumask_clear_cpu(cpu, mce_inject_cpumask);
> + if (m->inject_flags & MCJ_EXCEPTION)
> raise_exception(m, NULL);
> - }
> + else if (m->status)
> + raise_poll(m);
> }
>
> /* Inject mce on current CPU */
Hi Chen Gong,
Can you review the above patch?
thx!
cyc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regmap: debugfs: fix possbile NULL pointer dereference
If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer
dereference. So before dev_name(), we need to have check of the map->dev
pionter.
We also should make sure that the 'name' pointer shouldn't be NULL for
debugfs_create_dir(). So here using one default "dummy" debugfs name when
the 'name' pointer and 'map->dev' are both NULL.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regmap-debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 0c94b66..5799a0b 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -473,6 +473,7 @@ void regmap_debugfs_init(struct regmap *map, const char
*name)
{
struct rb_node *next;
struct regmap_range_node *range_node;
+ const char *devname = "dummy";
/* If we don't have the debugfs root yet, postpone init */
if (!regmap_debugfs_root) {
@@ -491,12 +492,15 @@ void regmap_debugfs_init(struct regmap *map, const char
*name)
INIT_LIST_HEAD(>debugfs_off_cache);
mutex_init(>cache_lock);
+ if (map->dev)
+ devname = dev_name(map->dev);
+
if (name) {
map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
- dev_name(map->dev), name);
+ devname, name);
name = map->debugfs_name;
} else {
- name = dev_name(map->dev);
+ name = devname;
}
map->debugfs = debugfs_create_dir(name, regmap_debugfs_root);
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: Remove read of issue in sa1111.c in sa1111_resume
On 09/27/14 19:50, Nicholas Krause wrote:
> This removes the FIXME message and issue with reading in this driver before
> resuming
> in the function, sa_resume.
You need to explain why this makes any sense.
Hint: it doesn't.
> Signed-off-by: Nicholas Krause
> ---
> arch/arm/common/sa.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
> index e57d7e5..0c4b9a9 100644
> --- a/arch/arm/common/sa.c
> +++ b/arch/arm/common/sa.c
> @@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev)
>
> /*
>* Ensure that the SA is still here.
> - * FIXME: shouldn't do this here.
>*/
> - id = sa_readl(sachip->base + SA_SKID);
> if ((id & SKID_ID_MASK) != SKID_SA_ID) {
> __sa_remove(sachip);
> platform_set_drvdata(dev, NULL);
>
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] SPI: spi-pxa2xx: SPI support for Intel Quark X1000
>
> >
> > > +/* see Quark SPI data sheet for implementation rationale */ static
> > > +u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) {
> >
> > Please document this in the driver - I don't know if this datasheet is
> > public but even if it is it may not stay that way.
>
> Datasheet is public.
> I'm just wondering if we can use just a formula instead of table.
>
As I said before, there are two formulas, but for the given rate, from the
formulas, we can get a lot of pairs,
and we also need to select them according to the guidelines which is not
formula. The table the datasheet given should be
the best one to meet the jitter and duty cycles as the datasheet documented.
Re: [PATCH 0/9] ARM: vf610: Suspend/resume support
On Mon, Sep 22, 2014 at 07:09:21PM +0200, Stefan Agner wrote: > This patchset provides suspend/resume support for Freescale Vybrid > SoC (vf610). The code is generally aligned to the implementation > for i.MX6. The subsystems SRC and GPC need some changes to support > the Vybrid specific implementation. > > This patchset relies on GPIO driver to be present (in order to > provide a wakeup source) as well as using the ARM Global Timer > clock source (the Vybrid specifc PIT clock source, vf_pit_timer.c > does not support shutdown). > > The implemented sleep states (LP-RUN and STOP), are not the most > power saving functions available on Vybrid. Especially for > suspend-to-memory one of the LPSTOP modes looks more appropriate. > However, the complexity is somewhat higher (we would need to move > execution path to SRAM and store IOMUX and DDRMC configuration). > Currently, I have not the resources to look into that so I hope > that this initial code qualifies as power saving functions to be > applied. So you have quite a lot of unnecessary code which is only needed by suspend from SRAM (store IOMUX and DDRMC configuration). Not happy with that. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SPI: spi-pxa2xx: SPI support for Intel Quark X1000
>
> > +static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data
> > +*drv_data) {
> > + if (!is_quark_x1000_ssp(drv_data))
> > + return SSCR1_CHANGE_MASK;
> > +
> > + return QUARK_X1000_SSCR1_CHANGE_MASK; }
>
> These functions would be much better written as switch statements - think
> how they're going to look when we've got another controller which needs
> custom values. It might also be helpful for review to have two patches, one
> splitting things out into the functions and another adding the Quark support.
>
OK. Let me use switch. BTW, for two patches, actually, using helpers is due to
we support quark.
Do you mean the first patch just introduce helpers, maybe it only support one
type, then another patch to add
quark supporting. Am I right?
> > +/* see Quark SPI data sheet for implementation rationale */ static
> > +u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) {
>
> Please document this in the driver - I don't know if this datasheet is public
> but
> even if it is it may not stay that way.
OK. I will document it.
>
> > @@ -613,6 +759,8 @@ static void pump_transfers(unsigned long data)
> > u32 cr1;
> > u32 dma_thresh = drv_data->cur_chip->dma_threshold;
> > u32 dma_burst = drv_data->cur_chip->dma_burst_size;
> > + u32 change_mask = pxa2xx_spi_get_ssrc1_change_mask(drv_data);
> > +
> >
>
> Extra blank line being added here.
>
I will remove it.
> > @@ -145,6 +147,9 @@ static inline int pxa25x_ssp_comp(struct driver_data
> *drv_data)
> > return 1;
> > if (drv_data->ssp_type == CE4100_SSP)
> > return 1;
> > + if (drv_data->ssp_type == QUARK_X1000_SSP)
> > + return 1;
> > +
> > return 0;
> > }
>
> Things like this should also be refactored into switch statements - in general
> anything that's deciding what to do based on ssp_type probably ought to be
> using switch statements.
OK. I will use switch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] soc/fsl: add ftm alarm driver for ls1021a platform
Thanks for your review. :) > -Original Message- > From: Kumar Gala [mailto:ga...@codeaurora.org] > Sent: Friday, September 26, 2014 10:04 PM > To: Wang Dongsheng-B40534 > Cc: Santosh Shilimkar; Sandeep Nair; Olof Johansson; shawn@linaro.org; > Greg > KH; Paul Walmsley; Arnd Bergmann; linux-kernel@vger.kernel.org; Guo > Shawn-R65073 > Subject: Re: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform > > > On Sep 26, 2014, at 1:48 AM, Dongsheng Wang > wrote: > > > From: Wang Dongsheng > > > > Only Ftm0 can be used when system going to deep sleep. So this driver > > to support ftm0 as a wakeup source. > > > > Signed-off-by: Wang Dongsheng > > How does this differ from drivers/clocksource/fsl_ftm_timer.c Fsl_ftm_timer.c is only for system to provide a clock driver. FTM ip-block can be used by other functions such as PWM. I think we should not put all of functions into a .c file. So ftm0 alarm function as a specific block driver in SOC dir. > > Why not extend that with the alarm functionality you need? The framework of clocksource not provide sys interface to set alarm. And codes of ftm0-alarm not touch on clocksource framework. > > Also, where is the DT binding spec for this (if you plan on having a separate > driver)? Yes, now only a driver. My DT depend on LS1 device tree patches, now LS1 DT is upstreaming but not apply. After LS1 DT apply, I will add ftm alarm device node. Regards, -Dongsheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crude Oil Exploration
Good day, I have an oil exportation proposition contract for you.If you don't mind, reply my email for full details of contract proposal. Sincerely, Adel Salman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: Remove read of issue in sa1111.c in sa1111_resume
This removes the FIXME message and issue with reading in this driver before
resuming
in the function, sa_resume.
Signed-off-by: Nicholas Krause
---
arch/arm/common/sa.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index e57d7e5..0c4b9a9 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev)
/*
* Ensure that the SA is still here.
-* FIXME: shouldn't do this here.
*/
- id = sa_readl(sachip->base + SA_SKID);
if ((id & SKID_ID_MASK) != SKID_SA_ID) {
__sa_remove(sachip);
platform_set_drvdata(dev, NULL);
--
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: Legacy Code in gpmc-onenand.c
On Sat, Sep 27, 2014 at 10:37:02PM -0400, nick wrote: > Greetings Kevin and others, > I am wondering if the below code is legacy I can remove it as stated it the > fix me. > Cheers Nick Nick, could you take that to more appropriate forum? alt.sex.fetish.FIXME would probably be a good starting point... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clocksource: Add BE APIs support for clocksource counter reading.
Hi,
> Subject: Re: [PATCH v2] clocksource: Add BE APIs support for clocksource
> counter reading.
>
> On Fri, 26 Sep 2014, Xiubo Li wrote:
> > For now I just added _be() support using ioread{16,32}be.
> > And i have a check of the clocksource drivers, didn't find anyone
> > using LE mode on one BE SoC, so _le() APIs is not needed.
>
> Nonsense. The existing clocksource_mmio accessor function are
> providing LE access independent of the CPU endianess. So we don't need
> an _le() API simply because we have it already.
>
> > cycle_t clocksource_mmio_readl_up(struct clocksource *c)
> > {
> > - return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg);
> > + return (cycle_t)ioread32(to_mmio_clksrc(c)->reg);
>
> And how exactly is this change related to adding BE support?
>
Actually not very much, since the _be() APIs are using ioread{16,32}be(),
so I think using ioread{16,32}() will be less odd to having two different
accessors here.
Wouldn't this be more unified somehow ?
Thanks very much,
BRs
Xiubo
> Thanks,
>
> tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Legacy Code in gpmc-onenand.c
Greetings Kevin and others,
I am wondering if the below code is legacy I can remove it as stated it the fix
me.
Cheers Nick
else {
/*
* FIX ME: Appears to be legacy code from initial ONENAND commit.
* Unclear what boards this is for and if this can be removed.
*/
if (!cpu_is_omap34xx())
onenand_sync.wait_on_read = 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: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map, >> compose MSI msg ..., in different platform, many arch specific MSI irq >> details in it. >> It's difficult to extract the common data and code. >> >> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, >> currently, >> HPET, DMAR and PCI have their own irq_chip and MSI related functions, >> write_msi_msg(), >> mask_msi_irq(), etc... I want to extract the common data set for that, so we >> can >> remove lots of unnecessary MSI code. > > That makes sense. Can you please make sure that this does not conflict > with the ongoing work Jiang is doing in the x86 irq area with > hierarchical irqdomains to distangle layered levels like MSI from the > underlying vector/irqremap mechanics. Yes, I'm reviewing Jiang hierarchical irqdomains series, I'm interested in that changes. Thanks! Yijing. > > Thanks, > > tglx > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
> -Original Message-
> From: Linuxppc-dev
> [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On
> Behalf Of Mike Turquette
> Sent: Saturday, September 27, 2014 7:29 AM
> To: Wood Scott-B07421
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
> Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
> CLK_OF_DECLARE support
>
> Quoting Scott Wood (2014-09-25 15:56:20)
> > On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> > > Quoting Scott Wood (2014-09-25 13:08:00)
> > > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made
> > > > to work on PPC rather than have the driver carry around two
> > > > binding methods.
> > >
> > > I guess that is an existing problem, and not related directly to
> > > this patch? This patch is essentially just renames (though the
> > > V1.0/V2.0 stuff seems weird).
> >
> > This patch is adding CLK_OF_DECLARE.
>
> I'm fine taking this patch but your comments are still unresolved. What do you
> think needs to be done to fix the problems that you see?
>
CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch.
Regarding V1.0 and V2.0, it is not wired just same for now. But we are not sure
if it is same for v3.0 in the future.
Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I am
not comfortable with:
This patch uses " fixed-clock" as sysclk's compatible string, while on PPC we
treated it as " fsl,qoriq-sysclk-[1-2].0".
That's inconsistent on both ARM and PPC platforms, neither did on bindings.
Thanks,
Yuantian
> Regards,
> Mike
>
> >
> > -Scott
> >
> >
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On 2014/9/26 17:05, Thierry Reding wrote: > On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote: > [...] >> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus() >> directly (patch attached). > > Really attached this time. > > Thierry > It looks good to me, so I will update the arm pci hostbridge driver to assign pci root bus the msi chip instead of current pcibios_add_bus(). But for other platforms which only have a one msi chip, I will kept the arch_find_msi_chip() temporarily for more comments, especially from Bjorn. Thanks! Yijing. -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] block: Add support for Sony SxS cards
On 2014-09-27 17:43, Kieran Kunhya wrote:
+static void sxs_memcpy_read(struct sxs_device *dev, unsigned long sector,
+ unsigned long nsect, char *buffer)
+{
+ struct pci_dev *pdev = dev->pci_dev;
+ u32 status;
+ u32 data[4];
+ u16 *tmp;
+ u32 *tmp2;
+
+ void *dma2;
+ dma_addr_t dma2_handle;
+ void *dma3;
+ dma_addr_t dma3_handle;
+
+ sector >>= dev->sector_shift;
+ nsect >>= dev->sector_shift;
+
+ /* Read */
+ dma2 = pci_alloc_consistent(pdev, 8192, _handle);
+ dma3 = pci_alloc_consistent(pdev, 8192, _handle);
+
+ tmp = dma2;
+ tmp2 = dma3;
+ tmp2[0] = dma2_handle;
+ tmp2[2] = dma3_handle;
+
+ dev_dbg_ratelimited(>dev, "CALL %lu %lu\n",
+ sector & 0x, nsect & 0x);
+
+ reinit_completion(>irq_response);
+ status = readl(dev->mmio+SXS_STATUS_REG);
+ data[0] = cpu_to_le32(0x00010028);
+ data[1] = cpu_to_le32(sector & 0x);
+ data[2] = 0x0;
+ data[3] = cpu_to_le32(nsect & 0x);
+ memcpy_toio(dev->mmio, data, sizeof(data));
+ writel(0xa0, dev->mmio+SXS_ENABLE_REG);
+ writel(0x80, dev->mmio+SXS_CONTROL_REG);
+
+ if (!wait_for_completion_timeout(>irq_response,
+msecs_to_jiffies(5000))) {
+ dev_dbg(>dev, "No IRQ\n");
+ }
+
+ reinit_completion(>irq_response);
+ writel(dma3_handle, dev->mmio+SXS_MASTER_LINK_REG_L);
+ writel(0x0, dev->mmio+SXS_MASTER_LINK_REG_H);
+ writel(0x20, dev->mmio+SXS_CONTROL_REG);
+
+ if (!wait_for_completion_timeout(>irq_response,
+msecs_to_jiffies(5000))) {
+ dev_dbg(>dev, "No IRQ\n");
+ }
+
+ /* FIXME: Use DMA properly */
+ memcpy(buffer, dma2, dev->sector_size * nsect);
+
+ dev_dbg_ratelimited(>dev, "boot-signature %x\n",
+ tmp[255]);
+
+ writel(0, dev->mmio+SXS_ENABLE_REG);
+
+ pci_free_consistent(pdev, 8192, dma3, dma3_handle);
+ pci_free_consistent(pdev, 8192, dma2, dma2_handle);
+}
+
+static void sxs_request(struct request_queue *q, struct bio *bio)
+{
+ struct bvec_iter iter;
+ struct bio_vec bvec;
+ char *buffer;
+ unsigned long flags;
+ struct sxs_device *dev = q->queuedata;
+ struct pci_dev *pdev = dev->pci_dev;
+ sector_t sector = bio->bi_iter.bi_sector;
+
+ bio_for_each_segment(bvec, bio, iter) {
+ dev_dbg_ratelimited(>dev, "REQUEST %i %i %i\n",
+ bio_cur_bytes(bio), bio->bi_vcnt,
+ bvec.bv_len);
+ buffer = bvec_kmap_irq(, );
+ sxs_memcpy_read(dev, sector, bio_cur_bytes(bio) >> 9,
+ buffer);
+ sector += bio_cur_bytes(bio) >> 9;
+ bvec_kunmap_irq(buffer, );
+ }
+
+ bio_endio(bio, 0);
So a few questions here... This device only does reads? And it seems to
be assuming that only reads end up in the request handler? How so?
Second question. IO never fails? There's no status checking and IO is
always ended successfully. This too seems odd.
Third, this wong work as-is, at least not of HIGHMEM is used. After the
bvec_kmap_irq(), irqs will be disabled. But your sxs_memcpy_read()
invokes schedule through the completion waits, that will instantly go bad.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 0/2] regulator: get voltage & duty table from dts for pwm-regulator
get voltage & duty table from device tree might be better, other platforms
can also use this driver without any modify.
Tested on a rk3288 sdk board as logic voltage regulator.
Changes in v7:
Adviced by Mark Brown
- re-edit changelog
- re-edit changelog
Changes in v6:
Adviced by Mark Rutland
- fix a spelling error
Changes in v4:
Adviced by Doug Anderson
- improve kconfig
- add const for desc structure
Adviced by Doug Anderson
- remove regulator-always-on and regulator-boot-on from the Example
Changes in v3:
Adviced by Doug Anderson
- Make Kconfig & Makefile alphabetical
- remove pwm_reg_period from pwm_regulator_data
- modify the calculation in pwm_regulator_set_voltage_sel
- add length validity check
Adviced by Doug Anderson
- update the Example
Changes in v2:
Adviced by Lee Jones
- rename the file
- remove all the prefix st_
- add depend on PWM in Kconfig
Adviced by Lee Jones
- rename the documentation
Adviced by Doug Anderson
- update the example
Adviced by Mark Rutland
- remove pwm-reg-period
Chris Zhong (2):
regulator: pwm-regulator: get voltage and duty table from dts
dt-bindings: add devicetree bindings for pwm regulator
.../bindings/regulator/pwm-regulator.txt | 27
drivers/regulator/Kconfig | 13 +-
drivers/regulator/Makefile |2 +-
drivers/regulator/{st-pwm.c => pwm-regulator.c}| 147 ++--
4 files changed, 112 insertions(+), 77 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/pwm-regulator.txt
rename drivers/regulator/{st-pwm.c => pwm-regulator.c} (44%)
--
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 v7 2/2] dt-bindings: add devicetree bindings for pwm regulator
Document the pwm regulator
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
---
Changes in v7:
- re-edit changelog
Changes in v6:
Adviced by Mark Rutland
- fix a spelling error
Changes in v4:
Adviced by Doug Anderson
- remove regulator-always-on and regulator-boot-on from the Example
Changes in v3:
Adviced by Doug Anderson
- update the Example
Changes in v2:
Adviced by Lee Jones
- rename the documentation
Adviced by Doug Anderson
- update the example
Adviced by Mark Rutland
- remove pwm-reg-period
.../bindings/regulator/pwm-regulator.txt | 27
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/pwm-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
new file mode 100644
index 000..ce91f61
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -0,0 +1,27 @@
+pwm regulator bindings
+
+Required properties:
+- compatible: Should be "pwm-regulator"
+- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
+- voltage-table: voltage and duty table, include 2 members in each set of
+ brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+ pwm_regulator {
+ compatible = "pwm-regulator;
+ pwms = < 0 8448 0>;
+
+ voltage-table = <1114000 0>,
+ <1095000 10>,
+ <1076000 20>,
+ <1056000 30>,
+ <1036000 40>,
+ <1016000 50>;
+
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt = <1114000>;
+ regulator-name = "vdd_logic";
+ };
--
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 v7 1/2] regulator: pwm-regulator: get voltage and duty table from dts
rename st-pwm to pwm-regulator. And support getting voltage & duty table from
device tree, other platforms can also use this driver without any modify.
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
---
Changes in v7:
Adviced by Mark Brown
- re-edit changelog
Changes in v6: None
Changes in v4:
Adviced by Doug Anderson
- improve kconfig
- add const for desc structure
Changes in v3:
Adviced by Doug Anderson
- Make Kconfig & Makefile alphabetical
- remove pwm_reg_period from pwm_regulator_data
- modify the calculation in pwm_regulator_set_voltage_sel
- add length validity check
Changes in v2:
Adviced by Lee Jones
- rename the file
- remove all the prefix st_
- add depend on PWM in Kconfig
drivers/regulator/Kconfig | 13 +-
drivers/regulator/Makefile |2 +-
drivers/regulator/{st-pwm.c => pwm-regulator.c} | 147 ---
3 files changed, 85 insertions(+), 77 deletions(-)
rename drivers/regulator/{st-pwm.c => pwm-regulator.c} (44%)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index fb32bab..b927cab 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -449,6 +449,13 @@ config REGULATOR_PFUZE100
Say y here to support the regulators found on the Freescale
PFUZE100/PFUZE200 PMIC.
+config REGULATOR_PWM
+ tristate "PWM voltage regulator"
+ depends on PWM
+ help
+ This driver supports PWM controlled voltage regulators. PWM
+ duty cycle can increase or decrease the voltage.
+
config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
@@ -493,12 +500,6 @@ config REGULATOR_S5M8767
via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and
supports DVS mode with 8bits of output voltage control.
-config REGULATOR_ST_PWM
- tristate "STMicroelectronics PWM voltage regulator"
- depends on ARCH_STI
- help
-This driver supports ST's PWM controlled voltage regulators.
-
config REGULATOR_TI_ABB
tristate "TI Adaptive Body Bias on-chip LDO"
depends on ARCH_OMAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 236fdbb..f3cf5a5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
+obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o
obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
@@ -66,7 +67,6 @@ obj-$(CONFIG_REGULATOR_RK808) += rk808-regulator.o
obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
-obj-$(CONFIG_REGULATOR_ST_PWM) += st-pwm.o
obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
diff --git a/drivers/regulator/st-pwm.c b/drivers/regulator/pwm-regulator.c
similarity index 44%
rename from drivers/regulator/st-pwm.c
rename to drivers/regulator/pwm-regulator.c
index 5ea78df..d3f55ea 100644
--- a/drivers/regulator/st-pwm.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -1,5 +1,5 @@
/*
- * Regulator driver for ST's PWM Regulators
+ * Regulator driver for PWM Regulators
*
* Copyright (C) 2014 - STMicroelectronics Inc.
*
@@ -20,43 +20,40 @@
#include
#include
-#define ST_PWM_REG_PERIOD 8448
-
-struct st_pwm_regulator_pdata {
- const struct regulator_desc *desc;
- struct st_pwm_voltages *duty_cycle_table;
-};
-
-struct st_pwm_regulator_data {
- const struct st_pwm_regulator_pdata *pdata;
+struct pwm_regulator_data {
+ struct regulator_desc desc;
+ struct pwm_voltages *duty_cycle_table;
struct pwm_device *pwm;
bool enabled;
int state;
};
-struct st_pwm_voltages {
+struct pwm_voltages {
unsigned int uV;
unsigned int dutycycle;
};
-static int st_pwm_regulator_get_voltage_sel(struct regulator_dev *dev)
+static int pwm_regulator_get_voltage_sel(struct regulator_dev *dev)
{
- struct st_pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+ struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
return drvdata->state;
}
-static int st_pwm_regulator_set_voltage_sel(struct regulator_dev *dev,
- unsigned selector)
+static int pwm_regulator_set_voltage_sel(struct regulator_dev *dev,
+unsigned selector)
{
- struct st_pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+ struct pwm_regulator_data *drvdata =
SKB Documentation Ideas and How to Write Docs for Kernel
Hello to the maintainers of the file,skb.c , I am wondering about making it easier for new developers including myself by writing a file in the docs on networking related to skb_buff and it's various methods of use to developing in the kernel's various networking subsystems. If one of the maintainers would like to help give me feedback on my writing of these docs this would be helpful and make it easier for everyone as from my experience skb_buff is one of the most asked about things in the networking lists and would allow people more thing for other work, including the maintainers of lots of the networking code. I understand you guys are very busy so feel free to respond whenever you get free time during the next few weeks. Thanks 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 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
What I would like to see is a way of creating the pci_host_bridge structure outside the pci_create_root_bus(). That would then allow us to pass this sort of platform details like associated msi_chip into the host bridge and the child busses will have an easy way of finding the information needed by finding the root bus and then the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly) everyone and the drivers can remove their kludges that try to work around the current limitations. >> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate. > > Except that arch sysdata at the moment is an opaque pointer. I am all in > favour in > changing the type of sysdata from void* into pci_host_bridge* and arches can > wrap their old > sysdata around the pci_host_bridge*. I inspected every arch and found there are almost no common stuff, and generic data struct should be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more, almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn. Thanks! Yijing. > > Best regards, > Liviu > >> >>> >>> I think both issues are orthogonal. Last time I checked a lot of work >>> was still necessary to unify host bridges enough so that it could be >>> shared across architectures. But perhaps some of that work has >>> happened in the meantime. >>> >>> But like I said, when you create the root bus, you can easily attach the >>> MSI chip to it. >>> >>> Thierry >>> >> >> >> -- >> Thanks! >> Yijing >> >> > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] ARM: imx: clk-gate2: allow custom gate configuration
On Mon, Sep 22, 2014 at 07:09:29PM +0200, Stefan Agner wrote:
> The 2-bit gates found i.MX and Vybrid SoC support different clock
> configuration:
>
> 0b00: clk disabled
> 0b01: clk enabled in RUN mode but disabled in WAIT and STOP mode
> 0b10: clk enabled in RUN, WAIT and STOP mode (only Vybrid)
> 0b11: clk enabled in RUN and WAIT mode
>
> For some clocks, we might want to configure different behaviour,
> e.g. a memory clock should be on even in STOP mode. Add a new
> function imx_clk_gate2_cgr which allow to configure specific
> gate values through the cgr_val parameter.
>
> Signed-off-by: Stefan Agner
> ---
> arch/arm/mach-imx/clk-gate2.c | 7 +--
> arch/arm/mach-imx/clk-vf610.c | 3 +++
> arch/arm/mach-imx/clk.h | 13 ++---
> include/dt-bindings/clock/vf610-clock.h | 3 ++-
The patch should be split into two, one for clk-gate2 and the other for
clk-vf610 driver change. Other than that, the patch looks good to me.
Shawn
> 4 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-gate2.c b/arch/arm/mach-imx/clk-gate2.c
> index 84acdfd..8c22a84 100644
> --- a/arch/arm/mach-imx/clk-gate2.c
> +++ b/arch/arm/mach-imx/clk-gate2.c
> @@ -31,6 +31,7 @@ struct clk_gate2 {
> struct clk_hw hw;
> void __iomem*reg;
> u8 bit_idx;
> + u8 cgr_val;
> u8 flags;
> spinlock_t *lock;
> unsigned int*share_count;
> @@ -50,7 +51,8 @@ static int clk_gate2_enable(struct clk_hw *hw)
> goto out;
>
> reg = readl(gate->reg);
> - reg |= 3 << gate->bit_idx;
> + reg &= ~(3 << gate->bit_idx);
> + reg |= gate->cgr_val << gate->bit_idx;
> writel(reg, gate->reg);
>
> out:
> @@ -110,7 +112,7 @@ static struct clk_ops clk_gate2_ops = {
>
> struct clk *clk_register_gate2(struct device *dev, const char *name,
> const char *parent_name, unsigned long flags,
> - void __iomem *reg, u8 bit_idx,
> + void __iomem *reg, u8 bit_idx, u8 cgr_val,
> u8 clk_gate2_flags, spinlock_t *lock,
> unsigned int *share_count)
> {
> @@ -125,6 +127,7 @@ struct clk *clk_register_gate2(struct device *dev, const
> char *name,
> /* struct clk_gate2 assignments */
> gate->reg = reg;
> gate->bit_idx = bit_idx;
> + gate->cgr_val = cgr_val;
> gate->flags = clk_gate2_flags;
> gate->lock = lock;
>
> diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
> index a178184..1034e78 100644
> --- a/arch/arm/mach-imx/clk-vf610.c
> +++ b/arch/arm/mach-imx/clk-vf610.c
> @@ -103,6 +103,7 @@ static struct clk_onecell_data clk_data;
> static unsigned int const clks_init_on[] __initconst = {
> VF610_CLK_SYS_BUS,
> VF610_CLK_DDR_SEL,
> + VF610_CLK_DDRMC,
> };
>
> static void __init vf610_clocks_init(struct device_node *ccm_node)
> @@ -171,6 +172,8 @@ static void __init vf610_clocks_init(struct device_node
> *ccm_node)
> clk[VF610_CLK_PLL4_MAIN_DIV] = clk_register_divider_table(NULL,
> "pll4_main_div", "pll4_main", 0, CCM_CACRR, 6, 3, 0, pll4_main_div_table,
> _ccm_lock);
> clk[VF610_CLK_PLL6_MAIN_DIV] = imx_clk_divider("pll6_main_div",
> "pll6_main", CCM_CACRR, 21, 1);
>
> + clk[VF610_CLK_DDRMC] = imx_clk_gate2_cgr("ddrmc", "ddr_sel", CCM_CCGR6,
> CCM_CCGRx_CGn(14), 0x2);
> +
> clk[VF610_CLK_USBPHY0] = imx_clk_gate("usbphy0", "pll3_main",
> PLL3_CTRL, 6);
> clk[VF610_CLK_USBPHY1] = imx_clk_gate("usbphy1", "pll7_main",
> PLL7_CTRL, 6);
>
> diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
> index 4cdf8b6..d22e339 100644
> --- a/arch/arm/mach-imx/clk.h
> +++ b/arch/arm/mach-imx/clk.h
> @@ -29,7 +29,7 @@ struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const
> char *name,
>
> struct clk *clk_register_gate2(struct device *dev, const char *name,
> const char *parent_name, unsigned long flags,
> - void __iomem *reg, u8 bit_idx,
> + void __iomem *reg, u8 bit_idx, u8 cgr_val,
> u8 clk_gate_flags, spinlock_t *lock,
> unsigned int *share_count);
>
> @@ -43,7 +43,7 @@ static inline struct clk *imx_clk_gate2(const char *name,
> const char *parent,
> void __iomem *reg, u8 shift)
> {
> return clk_register_gate2(NULL, name, parent, CLK_SET_RATE_PARENT, reg,
> - shift, 0, _ccm_lock, NULL);
> + shift, 0x3, 0, _ccm_lock, NULL);
> }
>
> static inline struct clk *imx_clk_gate2_shared(const char *name,
> @@ -51,7 +51,14 @@ static inline struct clk *imx_clk_gate2_shared(const char
> *name,
> unsigned int *share_count)
> {
> return clk_register_gate2(NULL, name, parent, CLK_SET_RATE_PARENT, reg,
> - shift, 0, _ccm_lock, share_count);
> + shift, 0x3, 0, _ccm_lock, share_count);
> +}
> +
> +static
[PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable
Quad spi transfer by clear EVCR(Enhanced
Volatile Configuration Register) Quad I/O
protocol bit.
Signed-off-by: bean huo
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..0c3b4fd 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return -EINVAL;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] MAINTAINERS: add atmel ssc driver maintainer entry
Signed-off-by: Bo Shen --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3705430..c004e6f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1703,6 +1703,13 @@ M: Nicolas Ferre S: Supported F: drivers/spi/spi-atmel.* +ATMEL SSC DRIVER +M: Bo Shen +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Supported +F: drivers/misc/atmel-ssc.c +F: include/linux/atmel-ssc.h + ATMEL Timer Counter (TC) AND CLOCKSOURCE DRIVERS M: Nicolas Ferre L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: add atmel audio alsa driver maintainer entry
Signed-off-by: Bo Shen --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c004e6f..30f92cf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1665,6 +1665,12 @@ M: Nicolas Ferre S: Supported F: drivers/tty/serial/atmel_serial.c +ATMEL Audio ALSA driver +M: Bo Shen +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +S: Supported +F: sound/soc/atmel + ATMEL DMA DRIVER M: Nicolas Ferre L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] unicore32: Remove unneeded Kconfig entry NO_IOPORT_MAP
Sorry for late reply. I checked this config, and it's only used for HAS_IOPORT_MAP in lib/Kconfig Sure, removing it means no different for .config file. I think a better way is reserving it or moving it into arch/Kconfig Cc: linux-a...@vger.kernel.org Xuetao Guan - Paul Bolle 写道： > Architectures only need a Kconfig entry for NO_IOPORT_MAP if it is > possible that its value will be 'y'. For unicore32 its value will always > be 'n', making it pointless. Remove it. > > Signed-off-by: Paul Bolle > --- > Tested by playing with arch/unicore32/configs/unicore32_defconfig. This > patch made no difference whatsoever to the generated .config file. > Please note that it has > CONFIG_HAS_IOPORT_MAP=y > > set after invoking "make oldconfig" both before and after this patch. > > arch/unicore32/Kconfig | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig > index 928237a7b9ca..2322cc87e7cb 100644 > --- a/arch/unicore32/Kconfig > +++ b/arch/unicore32/Kconfig > @@ -27,9 +27,6 @@ config UNICORE32 > config GENERIC_CSUM > def_bool y > > -config NO_IOPORT_MAP > - bool > - > config STACKTRACE_SUPPORT > def_bool y > > -- > 1.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH resend] arm:extend the reserved memory for initrd to be page aligned
> -Original Message- > On Thu, Sep 25, 2014 at 03:31:42PM +0100, Russell King - ARM Linux wrote: > > On Fri, Sep 19, 2014 at 11:00:02AM +0100, Catalin Marinas wrote: > > > On Fri, Sep 19, 2014 at 08:09:47AM +0100, Wang, Yalin wrote: > > > > this patch extend the start and end address of initrd to be page > > > > aligned, so that we can free all memory including the un-page > > > > aligned head or tail page of initrd, if the start or end address > > > > of initrd are not page aligned, the page can't be freed by > free_initrd_mem() function. > > > > > > > > Signed-off-by: Yalin Wang > > > > > > Acked-by: Catalin Marinas > > > > > > (as I said, if Russell doesn't have any objections please send the > > > patch to his patch system) > > > > I now have an objection. The patches in the emails were properly > formatted. > > They were so close ;) > > I can see three patches but none of them exactly right: > > 8157/1 - wrong diff format > 8159/1 - correct format, does not have my ack (you can take this one if >you want) > 8162/1 - got my ack this time but with the wrong diff format again > > Maybe a pull request is a better idea. > I have resend the 2 patches: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8167/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8168/1 please have a look. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ASoC: rockchip-max98090: add documentation for rockchip-max98090 driver
在 09/12/2014 09:44 PM, Mark Brown 写道:
> On Fri, Sep 12, 2014 at 03:30:36PM +0800, Jianqun wrote:
>> Add documentation for rockchip-max98090 driver, which is need by rockchip
>> board using a max98090.
>
> Can this use simple-card (perhaps after a bit of extension)?
I haven't ever try simple-card, is there any sample usage for me from other
vendor ?
>
>> +- rockchip,audio-codec : The phandle of the MAX98090 audio codec.
>
> Is the driver really specific to this CODEC?
I think yes, we need to add two gpio for mic and hp detect, but simple-card
driver hasn't them
>
>> +
>> +Optional properties:
>> +- rockchip,hp-det-gpios : The GPIO that detect headphones are plugged in
>> +- rockchip,mic-det-gpios : The GPIO that detect micphones are plugged in
>> +
>> +Example:
>> +
>> +sound {
>> +compatible = "rockchip,rockchip-audio-max98090";
>> +rockchip,model = "ROCKCHIP-I2S";
>> +rockchip,i2s-controller = <>;
>> +rockchip,audio-codec = <>;
>> +rockchip,hp-det-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +rockchip,mic-det-gpios = < 11 GPIO_ACTIVE_HIGH>;
>> +};
>> --
>> 1.9.1
>>
>>
>>
--
Jianqun Xu
*IMPORTANT NOTICE:*This email is from Fuzhou Rockchip Electronics Co.,
Ltd .The contents of this email and any attachments may contain
information that is privileged, confidential and/or exempt from
disclosure under applicable law and relevant NDA. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information is STRICTLY PROHIBITED.
Please immediately contact the sender as soon as possible and destroy
the material in its entirety in any format. Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: fsl_ifc_nand: use devm_ functions consistently
+ linux-mtd
FYI, I addressed a similar patch over here:
http://lists.infradead.org/pipermail/linux-mtd/2014-September/055563.html
I'm pretty sure this patch is wrong, and the semantic match is
incorrect (or at least, it has false positives). Just because devm_*
is used in some part of the driver doesn't mean that all allocations
should be. Admittedly, this driver is not the best written (this patch
drew my attention to at least one bug), but I just wanted to let y'all
know.
Regards,
Brian
On Sun, Aug 3, 2014 at 3:17 AM, Himangi Saraogi wrote:
> Use devm_kzalloc for all calls to kzalloc and not just the first. Use
> devm functions for other allocations as well. The calls to free the
> allocated memory in the remove function are done away with.
>
> The semantic match that finds the inconsistency is as follows:
>
> //
> @@
> @@
>
> *devm_kzalloc(...)
> ...
> *kzalloc(...)
> //
>
> Signed-off-by: Himangi Saraogi
> Acked-by: Julia Lawall
> ---
> Not compile tested.
> drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index 2338124..b403a77 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -995,11 +995,6 @@ static int fsl_ifc_chip_remove(struct fsl_ifc_mtd *priv)
> {
> nand_release(>mtd);
>
> - kfree(priv->mtd.name);
> -
> - if (priv->vbase)
> - iounmap(priv->vbase);
> -
> ifc_nand_ctrl->chips[priv->bank] = NULL;
>
> return 0;
> @@ -1062,7 +1057,8 @@ static int fsl_ifc_nand_probe(struct platform_device
> *dev)
>
> mutex_lock(_ifc_nand_mutex);
> if (!fsl_ifc_ctrl_dev->nand) {
> - ifc_nand_ctrl = kzalloc(sizeof(*ifc_nand_ctrl), GFP_KERNEL);
> + ifc_nand_ctrl = devm_kzalloc(>dev,
> sizeof(*ifc_nand_ctrl),
> +GFP_KERNEL);
> if (!ifc_nand_ctrl) {
> mutex_unlock(_ifc_nand_mutex);
> return -ENOMEM;
> @@ -1085,7 +1081,7 @@ static int fsl_ifc_nand_probe(struct platform_device
> *dev)
> priv->ctrl = fsl_ifc_ctrl_dev;
> priv->dev = >dev;
>
> - priv->vbase = ioremap(res.start, resource_size());
> + priv->vbase = devm_ioremap(>dev, res.start, resource_size());
> if (!priv->vbase) {
> dev_err(priv->dev, "%s: failed to map chip region\n",
> __func__);
> ret = -ENOMEM;
> @@ -1104,7 +1100,8 @@ static int fsl_ifc_nand_probe(struct platform_device
> *dev)
> IFC_NAND_EVTER_INTR_FTOERIR_EN |
> IFC_NAND_EVTER_INTR_WPERIR_EN,
> >ifc_nand.nand_evter_intr_en);
> - priv->mtd.name = kasprintf(GFP_KERNEL, "%llx.flash", (u64)res.start);
> + priv->mtd.name = devm_kasprintf(>dev, GFP_KERNEL, "%llx.flash",
> + (u64)res.start);
> if (!priv->mtd.name) {
> ret = -ENOMEM;
> goto err;
> @@ -1148,10 +1145,8 @@ static int fsl_ifc_nand_remove(struct platform_device
> *dev)
>
> mutex_lock(_ifc_nand_mutex);
> ifc_nand_ctrl->counter--;
> - if (!ifc_nand_ctrl->counter) {
> + if (!ifc_nand_ctrl->counter)
> fsl_ifc_ctrl_dev->nand = NULL;
> - kfree(ifc_nand_ctrl);
> - }
> mutex_unlock(_ifc_nand_mutex);
>
> 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] Remove GFP_DMA and GFP_DMA32 from flags before passing it into kmalloc.
On Sat, Sep 27, 2014 at 11:13 PM, Catalin Marinas wrote: > On 27 Sep 2014, at 16:09, Miles MH Chen wrote: >> Signed-off-by: Min-Hua Chen >> --- >> arch/arm64/mm/dma-mapping.c |3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c >> index 4164c5a..273cf6d 100644 >> --- a/arch/arm64/mm/dma-mapping.c >> +++ b/arch/arm64/mm/dma-mapping.c >> @@ -103,7 +103,8 @@ static void *__dma_alloc_noncoherent(struct device *dev, >> size_t size, >> ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs); >> if (!ptr) >> goto no_mem; >> -map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA); >> +map = kmalloc(sizeof(struct page *) << order, >> +flags & ~(GFP_DMA | GFP_DMA32)); > > Do you have an explanation on why this is needed (and such explanation > should also be included in the commit log)? We don’t use ZONE_DMA32 on > arm64 (we did initially but it was for the wrong reasons). If GFP_DMA32 is passed to dma_alloc_coherent, the flag will go to kmalloc and trigger a BUG_ON check in slab allocator: __dma_alloc_noncoherent kmalloc new_slab BUG_ON(flags & GFP_SLAB_BUG_MASK); It can be avoided this by removing GFP_DMA32 before passing it to kmalloc or we should block GFP_DMA32 flag earlier in arch/arm64/dma-mapping.c if GFP_DMA32 is not allowed in arch/arm64/dma-mapping.c. Thanks, MH > > Thanks, > > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Thu, Sep 25, 2014 at 07:37:50PM -0500, Felipe Balbi wrote:
> HI,
>
> On Fri, Sep 26, 2014 at 07:39:34AM +0800, Peter Chen wrote:
> > On Thu, Sep 25, 2014 at 09:15:53AM -0500, Felipe Balbi wrote:
> > > On Wed, Sep 24, 2014 at 02:23:38PM +0200, Arnd Bergmann wrote:
> > > > On Wednesday 24 September 2014 19:29:05 Peter Chen wrote:
> > > > >
> > > > > So, it is IP CORE LIB (you suggest) vs IP CORE Platform Driver
> > > > > (dwc3, musb, chipidea) you are talking about, right? Except for
> > > > > creating another platform driver as well as related DT node
> > > > > (optional),
> > > > > are there any advantages compared to current IP core driver structure?
> > > >
> > > > Having a library module usually requires less code, and is more
> > > > consistent with other drivers, which helps new developers understand
> > > > what the driver is doing.
> > >
> > > I beg to differ. You end-up having to pass function pointers through
> > > platform_data to handle differences which could be handled by the core
> > > IP.
> > >
> > > > The most important aspect though is the DT binding: once the structure
> > > > with separate kernel drivers leaks out into the DT format, you can't
> > > > easily change the driver any more, e.g. to make a property that was
> > > > introduced for one glue driver more general so it can get handled by
> > > > the common part. Having a single node lets us convert to the library
> > > > model later, so that would be a strong reason to keep the DT binding
> > > > simple, without child nodes.
> > > >
> > > > Following that logic, it turns into another reason for using the library
> > > > model to start with, because otherwise the child device does not have
> > > > any DT properties itself and has to rely on the parent device
> > > > properties,
> > > > which somewhat complicates the driver structure.
> > >
> > > this is bullcrap. Take a look at
> > > Documentation/devicetree/bindings/usb/dwc3.txt:
> > >
> > > synopsys DWC3 CORE
> > >
> > > DWC3- USB3 CONTROLLER
> > >
> > > Required properties:
> > > - compatible: must be "snps,dwc3"
> > > - reg : Address and length of the register set for the device
> > > - interrupts: Interrupts used by the dwc3 controller.
> > >
> > > Optional properties:
> > > - usb-phy : array of phandle for the PHY device. The first element
> > >in the array is expected to be a handle to the USB2/HS PHY and
> > >the second element is expected to be a handle to the USB3/SS PHY
> > > - phys: from the *Generic PHY* bindings
> > > - phy-names: from the *Generic PHY* bindings
> > > - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
> > >
> > > This is usually a subnode to DWC3 glue to which it is connected.
> > >
> > > dwc3@4a03 {
> > > compatible = "snps,dwc3";
> > > reg = <0x4a03 0xcfff>;
> > > interrupts = <0 92 4>
> > > usb-phy = <_phy>, <,phy>;
> > > tx-fifo-resize;
> > > };
> > >
> > > This contains all the attributes it needs to work. In fact, this could
> > > be used without any glue.
> > >
> >
> > If you want to add "vbus-supply" core node to support ID switch, what's
> > the plan for that?
>
> send a patch ? Just make sure it's optional because not everybody needs
> a vbus-supply. Also, DRD will still take a few merge windows to become a
> reality. I don't want to merge something before considering it carefuly,
> otherwise we will having which is broken and doesn't work for everybody
> ;-)
>
> > Is it possible that the glue layer needs to access core register
> > (eg, portsc.phcd during suspend)? The wrapper IP may wait some signals
> > at core IP to change.
>
> why would a glue layer need to access registers from the core ? That
> sounds very odd. I haven't seen that and will, definitely, NACK such a
> patch :-)
>
> can you further describe why you think a glue layer might need to access
> core IP's registers ?
>
My mistake, we can just wait core layer for finishing before doing PHY
and wrapper operation.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] enhance DMA CMA on x86
2014-09-27 23:30 GMT+09:00 Peter Hurley : > On 04/15/2014 09:08 AM, Akinobu Mita wrote: >> This patch set enhances the DMA Contiguous Memory Allocator on x86. >> >> Currently the DMA CMA is only supported with pci-nommu dma_map_ops >> and furthermore it can't be enabled on x86_64. But I would like to >> allocate big contiguous memory with dma_alloc_coherent() and tell it >> to the device that requires it, regardless of which dma mapping >> implementation is actually used in the system. >> >> So this makes it work with swiotlb and intel-iommu dma_map_ops, too. >> And this also extends "cma=" kernel parameter to specify placement >> constraint by the physical address range of memory allocations. For >> example, CMA allocates memory below 4GB by "cma=64M@0-4G", it is >> required for the devices only supporting 32-bit addressing on 64-bit >> systems without iommu. >> >> * Changes from v2 >> - Rebased on current Linus tree >> - Add Acked-by line >> - Fix gfp flags check for __GFP_ATOMIC, reported by Marek Szyprowski >> - Avoid CMA area on highmem with cma= option, reported by Marek Szyprowski >> >> * Changes from v1 >> - fix dma_alloc_coherent() with __GFP_ZERO >> - add placement specifier for "cma=" kernel parameter >> >> Akinobu Mita (5): >> x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled >> x86: enable DMA CMA with swiotlb >> intel-iommu: integrate DMA CMA >> memblock: introduce memblock_alloc_range() >> cma: add placement specifier for "cma=" kernel parameter > > This patchset breaks every x86 iommu configuration when CONFIG_DMA_CMA is > on, which is the base configuration for Ubuntu x86 and amd64 distro kernels. > > Granted, the patchset leveraged existing code from the nommu configuration, > but that base (ie., calling dma_alloc_from_contiguous() in > dma_generic_alloc_config()) was an ill-conceived test configuration designed > to allow ARM developers to validate the CMA allocator on x86 boxen and > KVM guests, not as a general-purpose replacement for the existing page > allocator. The test code should have had a separate CONFIG_ knob. > > What this patchset does is restrict all iommu configurations which can > map all of system memory to one _very_ small physical region, thus disabling > the whole point of an iommu. > > Now I know why my GPU is causing paging to disk! And why my RAID controller > stalls for ages when I do a git log at the same time as a kernel build! The solution I have for this is that instead of trying to dma_alloc_from_contiguous() firstly, call alloc_pages() in dma_alloc_coherent(). dma_alloc_from_contiguous() should be called only when alloc_pages() is failed or DMA_ATTR_FORCE_CONTIGUOUS is specified in dma_attr. > And the apparent goal of this patchset is to enable DMA allocation below > 4GB, which is already supported in the existing page allocator with the > GFP_DMA32 flag?! The goal of this patchset is to enable huge DMA allocation which alloc_pages() can't (> MAX_ORDER) for the devices that require it. Thanks for the notification. I'll prepare a patch described above. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ktest doc: Automated test of linux kernel by using ktest v1.1.3
Hi, I revised ktest documentation. v1.1.2->v1.1.3: Support not only debian/jessy, but also CentOS7 as target system http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mtd: fsl_ifc_nand: Use devm_* throughout driver
Hi Aaron,
Hmm, you're not the only one to send a patch like this. But I'm not sure
if it's correct; this driver is written awkwardly.
On Fri, Aug 15, 2014 at 07:46:44PM -0500, Aaron Sierra wrote:
> For consistency, use managed resources for allocations and remaps
> throughout the driver.
>
> Signed-off-by: Aaron Sierra
> ---
> drivers/mtd/nand/fsl_ifc_nand.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index 2338124..7861909 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -997,9 +997,6 @@ static int fsl_ifc_chip_remove(struct fsl_ifc_mtd *priv)
>
> kfree(priv->mtd.name);
>
> - if (priv->vbase)
> - iounmap(priv->vbase);
> -
> ifc_nand_ctrl->chips[priv->bank] = NULL;
>
> return 0;
> @@ -1062,7 +1059,8 @@ static int fsl_ifc_nand_probe(struct platform_device
> *dev)
>
> mutex_lock(_ifc_nand_mutex);
> if (!fsl_ifc_ctrl_dev->nand) {
> - ifc_nand_ctrl = kzalloc(sizeof(*ifc_nand_ctrl), GFP_KERNEL);
> + ifc_nand_ctrl = devm_kzalloc(>dev,
> + sizeof(*ifc_nand_ctrl), GFP_KERNEL);
This structure is static, and it looks like it's written with an attempt
of sharing the same controller structure across potentially many
instances of the device (multiple banks / chip selects?). And it has a
refcount for freeing the struct, but that refcount is wrong (see below).
> if (!ifc_nand_ctrl) {
> mutex_unlock(_ifc_nand_mutex);
> return -ENOMEM;
> @@ -1085,7 +1083,7 @@ static int fsl_ifc_nand_probe(struct platform_device
> *dev)
> priv->ctrl = fsl_ifc_ctrl_dev;
> priv->dev = >dev;
>
> - priv->vbase = ioremap(res.start, resource_size());
> + priv->vbase = devm_ioremap(priv->dev, res.start, resource_size());
> if (!priv->vbase) {
> dev_err(priv->dev, "%s: failed to map chip region\n", __func__);
> ret = -ENOMEM;
> @@ -1148,10 +1146,8 @@ static int fsl_ifc_nand_remove(struct platform_device
> *dev)
>
> mutex_lock(_ifc_nand_mutex);
> ifc_nand_ctrl->counter--;
> - if (!ifc_nand_ctrl->counter) {
> + if (!ifc_nand_ctrl->counter)
Notice here, that there is an attempt at refcounting the ->nand
structure. It is wrong (see how 'counter' is never incremented, only
decremented). I don't know if anyone uses this driver in a "removed"
context (e.g., rmmod or device unbinding), but this patch is potentially
circumventing the (incorrect) refcounting, and instead will free the
memory when it's possibly still used by another device.
IMO, it's better to have a potential memory leak than a potential
use-after-free, so I will not apply this patch. Feel free to provide an
actual bugfix for this driver to fix the refcounting instead, though! Or
work with the original authors/users to see if this driver actually
needs all the global/static info that's being used here. Perhaps the
driver could be refactored.
> fsl_ifc_ctrl_dev->nand = NULL;
> - kfree(ifc_nand_ctrl);
> - }
> mutex_unlock(_ifc_nand_mutex);
>
> return 0;
BTW, I see that an earlier incarnation of this type of patch says it was
based on an automated semantic patch. I'd suggest taking a hard look at
the automated tools you're using, so you don't inadverently add more
bugs while you're making "cleanups."
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3] block: Add support for Sony SxS cards
Signed-off-by: Kieran Kunhya
---
MAINTAINERS|5 +
drivers/block/Kconfig |9 +
drivers/block/Makefile |1 +
drivers/block/sxs.c| 494
4 files changed, 509 insertions(+)
create mode 100644 drivers/block/sxs.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3705430..f3a5231 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8539,6 +8539,11 @@ M: Maxim Levitsky
S: Maintained
F: drivers/memstick/core/ms_block.*
+SONY SXS CARD SUPPORT
+M: Kieran Kunhya
+S: Maintained
+F: drivers/block/sxs.c
+
SOUND
M: Jaroslav Kysela
M: Takashi Iwai
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 014a1cf..0b41ee0 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -356,6 +356,15 @@ config BLK_DEV_SX8
Use devices /dev/sx8/$N and /dev/sx8/$Np$M.
+config BLK_DEV_SXS
+ tristate "Sony SxS card support"
+ depends on PCI
+ ---help---
+ Saying Y or M here will enable support for reading
+ from Sony SxS cards.
+
+ It creates a device called /dev/sxs
+
config BLK_DEV_RAM
tristate "RAM block device support"
---help---
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 02b688d..59b9c79 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
obj-$(CONFIG_BLK_DEV_HD) += hd.o
+obj-$(CONFIG_BLK_DEV_SXS) += sxs.o
obj-$(CONFIG_XEN_BLKDEV_FRONTEND) += xen-blkfront.o
obj-$(CONFIG_XEN_BLKDEV_BACKEND) += xen-blkback/
diff --git a/drivers/block/sxs.c b/drivers/block/sxs.c
new file mode 100644
index 000..a2da71d
--- /dev/null
+++ b/drivers/block/sxs.c
@@ -0,0 +1,494 @@
+/*
+ * sxs.c: Driver for Sony SxS cards
+ *
+ * Copyright 2014 Kieran Kunhya
+ *
+ * Author/maintainer: Kieran Kunhya
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#define DRV_NAME "sxs"
+
+#define PCI_DEVICE_ID_SXS_81CE 0x81ce
+#define PCI_DEVICE_ID_SXS_905C 0x905c
+
+#define SXS_MASTER_LINK_REG_L 0x10
+#define SXS_MASTER_LINK_REG_H 0x14
+#define SXS_MASTER_ADDR_REG_L 0x18
+#define SXS_MASTER_ADDR_REG_H 0x1c
+#define SXS_MASTER_SIZE_REG 0x20
+#define SXS_ENABLE_REG 0x28
+#define SXS_CONTROL_REG 0x2c
+#define SXS_STATUS_REG 0x6c
+#define SXS_RESPONSE_BUF 0x40
+
+#define KERNEL_SECTOR_SIZE 512
+
+static struct pci_device_id ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_81CE), },
+ { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_905C), },
+ { 0, }
+};
+MODULE_DEVICE_TABLE(pci, ids);
+
+struct sxs_device {
+ struct pci_dev *pci_dev;
+ spinlock_t lock;
+ void __iomem *mmio;
+
+ intsxs_major;
+ struct gendisk *disk;
+ intsector_size;
+ intnum_sectors;
+ intsector_shift;
+ struct request_queue *queue;
+
+ struct completion irq_response;
+};
+
+static int sxs_getgeo(struct block_device *bdev, struct hd_geometry *geo)
+{
+ struct sxs_device *dev = bdev->bd_disk->private_data;
+ long size;
+
+ /* Make something up here */
+ size = dev->num_sectors*(dev->sector_size/KERNEL_SECTOR_SIZE);
+ geo->cylinders = (size & ~0x3f) >> 6;
+ geo->heads = 4;
+ geo->sectors = 16;
+
+ return 0;
+}
+
+static const struct block_device_operations sxs_opts = {
+ .owner = THIS_MODULE,
+ .getgeo = sxs_getgeo
+};
+
+static void sxs_memcpy_read(struct sxs_device *dev, unsigned long sector,
+ unsigned long nsect, char *buffer)
+{
+ struct pci_dev *pdev = dev->pci_dev;
+ u32 status;
+ u32 data[4];
+ u16 *tmp;
+ u32 *tmp2;
+
+ void *dma2;
+ dma_addr_t dma2_handle;
+ void *dma3;
+ dma_addr_t dma3_handle;
+
+ sector >>= dev->sector_shift;
+ nsect >>= dev->sector_shift;
+
+ /* Read */
+ dma2 = pci_alloc_consistent(pdev, 8192, _handle);
+ dma3 = pci_alloc_consistent(pdev, 8192, _handle);
+
+ tmp = dma2;
+ tmp2 = dma3;
+ tmp2[0] = dma2_handle;
+ tmp2[2] = dma3_handle;
+
+ dev_dbg_ratelimited(>dev, "CALL %lu %lu\n",
+ sector & 0x, nsect & 0x);
+
+ reinit_completion(>irq_response);
+ status = readl(dev->mmio+SXS_STATUS_REG);
+ data[0] = cpu_to_le32(0x00010028);
+ data[1] = cpu_to_le32(sector & 0x);
+ data[2] = 0x0;
+ data[3] = cpu_to_le32(nsect & 0x);
+ memcpy_toio(dev->mmio, data, sizeof(data));
+
[PATCH] ACPI / SBS: Fix check in acpi_ac_get_present()
From: Rafael J. Wysocki Parentheses are missing under an if () statement in acpi_ac_get_present() which makes the check work differently from what was intended (at least according to the comment right above it). Add the missing parens. The problem was found by sparse. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/sbs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/acpi/sbs.c === --- linux-pm.orig/drivers/acpi/sbs.c +++ linux-pm/drivers/acpi/sbs.c @@ -441,7 +441,7 @@ static int acpi_ac_get_present(struct ac * The spec requires that bit 4 always be 1. If it's not set, assume * that the implementation doesn't support an SBS charger */ - if (!(status >> 4) & 0x1) + if (!((status >> 4) & 0x1)) return -ENODEV; sbs->charger_present = (status >> 15) & 0x1; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/7] clk: at91: add a driver for the h32mx clock
Quoting Boris BREZILLON (2014-09-22 02:04:25) > On Fri, 19 Sep 2014 14:33:19 +0200 > Nicolas Ferre wrote: > > > On 15/09/2014 18:15, Alexandre Belloni : > > > Newer SoCs have two different AHB interconnect. The AHB 32 bits Matrix > > > interconnect (h32mx) has a clock that can be setup at the half of the > > > h64mx > > > clock (which is mck). The h32mx clock can not exceed 90 MHz. > > > > > > Signed-off-by: Alexandre Belloni > > > > Okay on my side: > > > > Acked-by: Nicolas Ferre > > > > > > > --- > > > Cc:Mike Turquette > > > > Mike, > > > > I guess that you didn't get this v3. Can you "Ack" this one of should we > > re-sent to you? > > > > I would like to take this patch with the rest of the SAMA5D4 series: is > > it okay for you? > > > Hi Mike, > > I gave my ack to this patch, so, if you don't mind letting Nicolas > take it through his tree, I think it will ease integration of the > sama5d4 support (no external dependencies on the clk tree). Acked-by: Mike Turquette > > Best Regards, > > Boris > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.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 1/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss
On 09/27/14 09:46, Felipe Balbi wrote: On Fri, Sep 26, 2014 at 06:10:52PM -0700, Behan Webster wrote: Replace the use of nested functions where a normal function will suffice. Nested functions are not liked by upstream kernel developers in general. Their use breaks the use of clang as a compiler, and doesn't make the code any better. This code now works for both gcc and clang. Signed-off-by: Behan Webster Suggested-by: Arnd Bergmann Cc: Arnd Bergmann another one that make sense :-) And probably also deserves checkpatch/coccinelle/sparse. Indeed! That would be very appreciated. The clang static analyzer already points this one out. :) Behan -- Behan Webster beh...@converseincode.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 3.12 000/142] 3.12.29-stable review
At Fri, 26 Sep 2014 08:45:36 -0700, Guenter Roeck wrote: > > On Fri, Sep 26, 2014 at 11:45:33AM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.29 release. > > There are 142 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Sep 30 11:45:24 CEST 2014. > > Anything received after that time might be too late. > > > > Hi Jiri, > > Build results: > total: 135 pass: 135 fail: 0 > > Qemu test results: > total: 21 pass: 21 fail: 0 > > Both obviously look good, however my tree doesn't match your review request. > It includes 245 patches instead of just 142. > > Looks like your tree is a bit ahead of time, so I guess that is ok. > Is there a way for me to avoid this when pulling in your pending changes ? > So far I pull the changes from the stable-3.12-queue branch in your > repository at kernel.org. > > Thanks, > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs.git for 3.17-rc7
Assorted fixes + unifying __d_move() and __d_materialise_dentry() + minimal regression fix for d_path() of victims of overwriting rename() ported on top of that. Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (7): ufs: deal with nfsd/iget races pull rehashing and unlocking the target dentry into __d_materialise_dentry() don't open-code d_rehash() in d_materialise_unique() __d_move(): fold manipulations with ->d_child/->d_subdirs __d_materialise_dentry(): flip the order of arguments kill __d_materialise_dentry() fold unlocking the children into dentry_unlock_parents_for_move() Linus Torvalds (1): fold swapping ->d_name.hash into switch_names() Mikhail Efremov (1): vfs: Don't exchange "short" filenames unconditionally. Miklos Szeredi (2): shmem: fix nlink for rename overwrite directory fuse: honour max_read and max_write in direct_io mode Diffstat: fs/dcache.c | 112 +-- fs/direct-io.c |2 +- fs/fuse/file.c |1 + fs/ufs/ialloc.c |6 ++- fs/ufs/namei.c |4 ++ include/linux/uio.h |2 +- mm/iov_iter.c | 14 --- mm/shmem.c |4 +- 8 files changed, 60 insertions(+), 85 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/
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git
On Wed, Sep 24, 2014 at 12:58 AM, Roland Dreier wrote: > Hi Linus, [..] > This is later and bigger than I would like, and the blame is all on > me: I got very busy with other stuff for a few weeks during the 3.17 > cycle, and didn't prepare this tree as soon as I should have. However > I don't think there's anything risky here, and no one really cares if > we break InfiniBand in 3.17 anyway... Roland, sorry, but I don't understand the joke @ the last sentence, can you elaborate? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] wireless: Remove unnessary write over of register 11 in rt2800lib.c
This removes the unnecessary overwrite of register 11 in the function,
rt2800_config_channel as we are already writing a correct value to the
register with rt2800_rfcsr_write(rt2x00dev,11.rfcsr).
Signed-off-by: Nicholas Krause
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 893c9d5..fb0ae38 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2787,8 +2787,6 @@ static void rt2800_config_channel_rf55xx(struct
rt2x00_dev *rt2x00dev,
if (rf->channel <= 14) {
rt2800_rfcsr_write(rt2x00dev, 10, 0x90);
- /* FIXME: RF11 owerwrite ? */
- rt2800_rfcsr_write(rt2x00dev, 11, 0x4A);
rt2800_rfcsr_write(rt2x00dev, 12, 0x52);
rt2800_rfcsr_write(rt2x00dev, 13, 0x42);
rt2800_rfcsr_write(rt2x00dev, 22, 0x40);
--
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 net-next] r8169:add support for RTL8168EP
Chun-Hao Lin :
> RTL8168EP is Realtek PCIe Gigabit Ethernet controller.
> It is a successor chip of RTL8168DP.
>
> This patch add support for this chip.
It does more than that.
Did Hayes review it ?
> Signed-off-by: Chun-Hao Lin
> ---
> drivers/net/ethernet/realtek/r8169.c | 611
> +--
> 1 file changed, 514 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 1d81238..0ead9a7 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -155,6 +155,9 @@ enum mac_version {
> RTL_GIGA_MAC_VER_46,
> RTL_GIGA_MAC_VER_47,
> RTL_GIGA_MAC_VER_48,
> + RTL_GIGA_MAC_VER_49,
> + RTL_GIGA_MAC_VER_50,
> + RTL_GIGA_MAC_VER_51,
> RTL_GIGA_MAC_NONE = 0xff,
> };
>
> @@ -302,6 +305,15 @@ static const struct {
> [RTL_GIGA_MAC_VER_48] =
> _R("RTL8107e", RTL_TD_1, FIRMWARE_8107E_2,
> JUMBO_1K, false),
> + [RTL_GIGA_MAC_VER_49] =
> + _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
> + JUMBO_9K, false),
> + [RTL_GIGA_MAC_VER_50] =
> + _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
> + JUMBO_9K, false),
> + [RTL_GIGA_MAC_VER_51] =
> + _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
> + JUMBO_9K, false),
> };
> #undef _R
>
> @@ -400,6 +412,10 @@ enum rtl_registers {
> FuncEvent = 0xf0,
> FuncEventMask = 0xf4,
> FuncPresetState = 0xf8,
> + IBCR0 = 0xf8,
> + IBCR2 = 0xf9,
> + IBIMR0 = 0xfa,
> + IBISR0 = 0xfb,
> FuncForceEvent = 0xfc,
> };
>
> @@ -467,6 +483,7 @@ enum rtl8168_registers {
> #define ERIAR_EXGMAC (0x00 << ERIAR_TYPE_SHIFT)
> #define ERIAR_MSIX (0x01 << ERIAR_TYPE_SHIFT)
> #define ERIAR_ASF(0x02 << ERIAR_TYPE_SHIFT)
> +#define ERIAR_OOB(0x02 << ERIAR_TYPE_SHIFT)
> #define ERIAR_MASK_SHIFT 12
> #define ERIAR_MASK_0001 (0x1 << ERIAR_MASK_SHIFT)
> #define ERIAR_MASK_0011 (0x3 << ERIAR_MASK_SHIFT)
> @@ -935,93 +952,10 @@ static const struct rtl_cond name = {
> \
> \
> static bool name ## _check(struct rtl8169_private *tp)
>
> -DECLARE_RTL_COND(rtl_ocpar_cond)
> -{
> - void __iomem *ioaddr = tp->mmio_addr;
> -
> - return RTL_R32(OCPAR) & OCPAR_FLAG;
> -}
Feel free to move this function around but please do it in a separate
patch. You are adding extra noise and thus making this stuff harder
to review than it should be.
> -
> -static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
> -{
> - void __iomem *ioaddr = tp->mmio_addr;
> -
> - RTL_W32(OCPAR, ((u32)mask & 0x0f) << 12 | (reg & 0x0fff));
> -
> - return rtl_udelay_loop_wait_high(tp, _ocpar_cond, 100, 20) ?
> - RTL_R32(OCPDR) : ~0;
> -}
(this one is modified)
> -
> -static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
> -{
> - void __iomem *ioaddr = tp->mmio_addr;
> -
> - RTL_W32(OCPDR, data);
> - RTL_W32(OCPAR, OCPAR_FLAG | ((u32)mask & 0x0f) << 12 | (reg & 0x0fff));
> -
> - rtl_udelay_loop_wait_low(tp, _ocpar_cond, 100, 20);
> -}
(this one is modified)
> -
> -DECLARE_RTL_COND(rtl_eriar_cond)
> -{
> - void __iomem *ioaddr = tp->mmio_addr;
> -
> - return RTL_R32(ERIAR) & ERIAR_FLAG;
> -}
Feel free to move this function around but please do it in a separate
patch.
> -
> -static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
> -{
> - void __iomem *ioaddr = tp->mmio_addr;
> -
> - RTL_W8(ERIDR, cmd);
> - RTL_W32(ERIAR, 0x800010e8);
> - msleep(2);
> -
> - if (!rtl_udelay_loop_wait_low(tp, _eriar_cond, 100, 5))
> - return;
> -
> - ocp_write(tp, 0x1, 0x30, 0x0001);
> -}
This one is modified but it is also modified for the existing 8168DP.
Mantra: please do it in a separate patch.
> -
> #define OOB_CMD_RESET0x00
> #define OOB_CMD_DRIVER_START 0x05
> #define OOB_CMD_DRIVER_STOP 0x06
>
> -static u16 rtl8168_get_ocp_reg(struct rtl8169_private *tp)
> -{
> - return (tp->mac_version == RTL_GIGA_MAC_VER_31) ? 0xb8 : 0x10;
> -}
> -
> -DECLARE_RTL_COND(rtl_ocp_read_cond)
> -{
> - u16 reg;
> -
> - reg = rtl8168_get_ocp_reg(tp);
> -
> - return ocp_read(tp, 0x0f, reg) & 0x0800;
> -}
(this one is simply moved around)
> -
> -static void rtl8168_driver_start(struct rtl8169_private *tp)
> -{
> - rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START);
> -
> - rtl_msleep_loop_wait_high(tp, _ocp_read_cond, 10, 10);
> -}
(this one is modified)
> -
Re: [PATCH v12 08/12] PCI: OF: Introduce helper function for retrieving PCI domain numbers
[+cc Yinghai] On Fri, Sep 26, 2014 at 4:47 PM, Liviu Dudau wrote: > On Fri, Sep 26, 2014 at 10:53:26PM +0100, Rob Herring wrote: >> I thought Bjorn already applied the series. Who's agreement are you >> waiting for specifically. > > Looks like he only applied about 60% of the series. I applied it all but Yinghai pointed out a problem with a patch in the middle, so I dropped that patch and everything after it because I didn't have time to work out whether the later patches depended on anything in the one I dropped. 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] clk: Add PWM clock driver
Quoting Thierry Reding (2014-09-23 01:51:31) > On Wed, Sep 10, 2014 at 10:05:17PM +0200, Janusz Użycki wrote: > > Hi, > > > > http://patchwork.ozlabs.org/patch/359069/ > > https://lkml.org/lkml/2014/6/12/186 > > > > Will the patch ever included to linux-next? > > I've never seen this patch before. From a quick look it doesn't seem > like it would work as is, but the idea is certainly interesting. If > somebody decides to continue work on it, please Cc me and the linux-pwm > mailing list. I just merged a gpio-controlled clock gate and I'm fine with a PWM clock output. Janusz, how are you testing the clock driver? Regards, Mike > > > pwm_config() API could be extended to support > > not only period [ns] and duty [ns] time > > but also frequency [Hz] and duty cycle fraction [1/1000?] > > (instead of time in ns) as parameters. > > Then ns (rounded by pwm) to freq. conversion problem > > inclk_pwm_recalc_rate() usingpwm_get_period() > > could be avoided. > > To extend the API pwm_config() can support > > new flags forduty_ns and period_ns, > > eg. PWM_DUTY_PERCENT and PWM_PERIOD_HZ. > > Is that rounding really a problem? Also the PWM chips will most likely > use the concept of period and duty-cycle internally anyway, so it will > convert back from Hz/percentage to nanoseconds and fall victim to > similar rounding effects. > > Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:49 PM, Al Viro wrote: > > Fine by me. How about that s-o-b? Right now it's Sure, add my sign-off too. Not that I feel I even need the credit, so you could just have done it as yourself. But I'll take it, so.. Signed-off-by: Linus Torvalds Thanks, 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/
[GIT PULL] ARM: SoC fixes for 3.17
Hi Linus, The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd: Linux 3.17-rc4 (2014-09-07 16:09:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to fa9eb3241895d2771b87f20dd23b40de664c5e4e: drivers/soc: qcom: do not disable the iface clock in probe (2014-09-23 21:38:32 -0700) ARM: SoC fixes for 3.17 Here's our last set of fixes for 3.17. Most of these are for TI platforms, fixing some noisy Kconfig issues, runtime clock and power issues on several platforms and NAND timings on DRA7. There are also a couple of bug fixes for i.MX, one for QCOM and a small fix to avoid section mismatch noise on PXA. Diffstat looks large, partially due to some tables being updated and thus touching many lines. The qcom gsbi change also restructures clock management a bit and thus touches a bunch of lines. All in all, a bit more changes than we'd like at this point, but nothing stands out as risky either so it seems like the right thing to send it up now instead of holding it to the merge window. Arnd Bergmann (1): ARM: pxa: fix section mismatch warning for pxa_timer_nodt_init Dmitry Lifshitz (1): ARM: dts: cm-t54: fix serial console power supply. Markus Niebel (1): ARM: DT: imx53: fix lvds channel 1 port Murali Karicheri (1): ARM: keystone: dts: fix bindings for pcie and usb clock nodes Nishanth Menon (1): bus: omap_l3_noc: Fix connID for OMAP4 Olof Johansson (3): Merge tag 'fixes-v3.17-rc4' of git://git.kernel.org/.../ssantosh/linux-keystone into fixes Merge tag 'fixes-v3.17-rc4' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'fix-v3.17-io-chain-v3' of git://git.kernel.org/.../tmlind/linux-omap into fixes Roger Quadros (1): ARM: dts: dra7-evm: Fix NAND GPMC timings Shawn Guo (1): ARM: imx: fix .is_enabled() of shared gate clock Srinivas Kandagatla (1): drivers/soc: qcom: do not disable the iface clock in probe Tony Lindgren (2): ARM: OMAP: Fix Kconfig warning for omap1 ARM: OMAP3: Fix I/O chain clock line assertion timed out error .../devicetree/bindings/staging/imx-drm/ldb.txt| 15 ++- arch/arm/boot/dts/dra7-evm.dts | 27 ++-- arch/arm/boot/dts/imx53.dtsi | 12 +- arch/arm/boot/dts/k2e-clocks.dtsi | 6 +-- arch/arm/boot/dts/omap5-cm-t54.dts | 5 +-- arch/arm/mach-imx/clk-gate2.c | 6 +-- arch/arm/mach-omap2/Kconfig| 3 -- arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/prm3xxx.c | 39 +++-- arch/arm/mach-pxa/generic.c| 2 +- arch/arm/plat-omap/Kconfig | 3 ++ drivers/bus/omap_l3_noc.h | 50 +++--- drivers/soc/qcom/qcom_gsbi.c | 46 ++-- 13 files changed, 139 insertions(+), 77 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:39:02PM -0700, Linus Torvalds wrote:
> On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds
> wrote:
> >
> > But yeah, I guess we can/should do the trivial ugly thing for 3.17.
> > Send me a proper pull-request,
>
> .. and if it can happen before tomorrow, that would be good. I had to
> give up on my wish to release 3.17 tomorrow due to the current size of
> changes anyway, so there will be a rc7 (and my travel inconveniences
> be damned), but I'd like this to be in that rc7. Works for you?
Fine by me. How about that s-o-b? Right now it's
commit 4f78a56cd96a3d421852b5a03e10355b0cbe764b
Author: Linus Torvalds
Date: Wed Sep 24 12:27:39 2014 -0700
fold swapping ->d_name.hash into switch_names()
and do it along with ->d_name.len there
Signed-off-by: Al Viro
diff --git a/fs/dcache.c b/fs/dcache.c
index 92f7d76..7599d35 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2412,7 +2412,7 @@ static void switch_names(struct dentry *dentry, struct
dentry *target)
}
}
}
- swap(dentry->d_name.len, target->d_name.len);
+ swap(dentry->d_name.hash_len, target->d_name.hash_len);
}
static void dentry_lock_for_move(struct dentry *dentry, struct dentry *target)
@@ -2510,7 +2510,6 @@ static void __d_move(struct dentry *dentry, struct dentry
*target,
/* Switch the names.. */
switch_names(dentry, target);
- swap(dentry->d_name.hash, target->d_name.hash);
/* ... and switch them in the tree */
if (IS_ROOT(dentry)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 08:16:57PM +0100, Al Viro wrote:
> On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote:
>
> > We can get the long name cases right, and I agree that it'll make the
> > things nicer, but it might take a couple of days to get right. The thing
> > I'm concerned about is not screwing DCACHE_RCUACCESS up.
>
> FWIW, I suspect that the right approach is to put refcount + rcu_head in
> front of external name and do the following:
> * __d_free() checks if we have an external name, gets its containing
> structure and does if (atomic_dec_and_test(>count)) kfree(name);
> * switch_names() in non-exchange case (I'd probably call it copy_name,
> not move_names, but anyway) sets DCACHE_RCUACCESS on target (source has
> already gotten it from __d_rehash()), increments refcount on target's name
> if external and, if the source old name is external, decrements its refcount
> and calls kfree_rcu() if it has hit zero.
>
> AFAICS, it guarantees that we'll schedule an RCU callback on name's rch_head
> at most once, that we won't free it while RCU callback on it is scheduled
> and we won't free it until a grace period has expired since the last time
> it had been referenced by observable dentries. Do you see any holes in that?
We probably want to put a union of refcount and rcu_head there, actually...
Gives the right alignment without padding. As in
struct ext_name {
union {
atomic_t count;
struct rcu_head head;
};
char name[0];
};
->count corresponds to the number of dentries that have ->d_name.name
pointing to the sucker's ->name. And we use ->head only when it reaches
zero in __d_move(). That's 2 words per external name; somewhat unpleasant
on 64bit, but I don't see how to avoid an rcu_head in there... The cutoff
for external names is 32 bytes on 64bit boxen. That way we get 16 bytes
of overhead per long-named dentry... OTOH, we allocate them with kmalloc(),
so it means that 32-character names lead to 64-bytes actual allocation.
Hmmm... So the old behaviour is
32--63 => 64 byte allocation
64--95 => 96
96--127=> 128
and the new one
32--47 => 64 byte allocation
48--79 => 96
80--111=> 128
112--127=> 192
(components longer than 128 characters are definitely too rare to worry about)
IOW, the main worry is about the names in range from 48 to 64 characters;
for those we push the allocation from size-64 to size-96...
Note, BTW, that git hits external name case on everything except 32-bit UP;
a _lot_ of 38-character names there. And IIRC there had been some plans for
possible replacement of SHA1 with something wider, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
On Saturday, September 27, 2014 01:32:59 PM Wang Weidong wrote:
> On 2014/9/27 7:21, Rafael J. Wysocki wrote:
> > On Thursday, August 21, 2014 01:55:15 PM Wang Weidong wrote:
> >> As the initialized freq_tables maybe different from the p-states
> >> values, so the array index is different as well.
> >>
> >> p-states value: [2400 2400 2000 ...], while the freq_tables:
> >> [2400 2000 ... CPUFREQ_TABLE_END]. After setted the freqs 2000,
> >> the perf->state is 3 while the freqs_table's index should be 2.
> >> So when call the get_cur_freq_on_cpu, the freqs value we get
> >> is 2400.
> >>
> >> So, fix the problem with the correct tables.
> >
> > What you're saying is basically that freq_table and perf->states
> > diverge at one point. Shouldn't we re-generate freq_table in that
> > case instead of fixing up get_cur_freq_on_cpu() only in a quite
> > indirect way?
> >
> Hi Rafael,
>
> Thanks for your reply.
>
> You mean that we should re-generate the freq_table in that case?
> Could we fix the table init like this:
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
>
> /* table init */
> for (i = 0; i < perf->state_count; i++) {
> - if (i > 0 && perf->states[i].core_frequency >=
> + if (i > 0 && perf->states[i].core_frequency >
> data->freq_table[valid_states-1].frequency / 1000)
> continue;
>
> when the value is same, we just keep the value into the freq_table.
That would only be OK if it is guaranteed that the set of available
states hasn't changed, which I'm not sure is the case.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds wrote: > > But yeah, I guess we can/should do the trivial ugly thing for 3.17. > Send me a proper pull-request, .. and if it can happen before tomorrow, that would be good. I had to give up on my wish to release 3.17 tomorrow due to the current size of changes anyway, so there will be a rc7 (and my travel inconveniences be damned), but I'd like this to be in that rc7. Works for you? 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: BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
On Saturday, September 27, 2014 08:14:46 AM Mike Galbraith wrote:
> On Sat, 2014-09-27 at 00:44 +0200, Rafael J. Wysocki wrote:
>
> > Shouldn't that be pcc-cpufreq.c rather?
>
> Yeah, silly mouse copy/pasted the wrong gitk bits.
>
> > Also moving the spin_lock(_lock) after the
> > cpufreq_freq_transition_begin()
> > should fix the problem too (like the below). Have you tried that?
>
> Have now. Yup, works and is prettier.
OK, thanks!
Below it goes again with full changelog.
---
From: Rafael J. Wysocki
Subject: cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():
BUG: sleeping function called from invalid context at
drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200
[pcc_cpufreq]
[ 51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: GE 3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
88026c46b828 81589dbd
880037978090 88026c46b848 8108e1df 880037978090
88026c46b878 8108e298 88026d73ec00
Call Trace:
[] dump_stack+0x4d/0x90
[] ___might_sleep+0x10f/0x180
[] __might_sleep+0x48/0xd0
[] cpufreq_freq_transition_begin+0x75/0x140
drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait,
!policy->transition_ongoing);
[] ? preempt_count_add+0xb9/0xc0
[] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq]
drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(_lock);
[] ? update_ts_time_stats+0x7f/0xb0
[] __cpufreq_driver_target+0x85/0x170
[] od_check_cpu+0xa8/0xb0
[] dbs_check_cpu+0x180/0x1d0
[] cpufreq_governor_dbs+0x3b0/0x720
[] od_cpufreq_governor_dbs+0x33/0xe0
[] __cpufreq_governor+0xa9/0x210
[] cpufreq_set_policy+0x1e2/0x2e0
[] cpufreq_init_policy+0x8c/0x110
[] ? cpufreq_update_policy+0x1b0/0x1b0
[] ? preempt_count_sub+0xb9/0x100
[] __cpufreq_add_dev+0x596/0x6b0
[] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
[] cpufreq_add_dev+0xe/0x10
[] subsys_interface_register+0xc1/0xf0
[] ? preempt_count_sub+0xb9/0x100
[] cpufreq_register_driver+0x117/0x2a0
[] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
[] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
[] do_one_initcall+0xc8/0x1f0
[] ? __vunmap+0x9d/0x100
[] do_init_module+0x30/0x1b0
[] load_module+0x686/0x710
[] ? do_init_module+0x1b0/0x1b0
[] SyS_init_module+0x9b/0xc0
[] system_call_fastpath+0x16/0x1b
Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use
cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith
Cc: 3.15+ # 3.15+
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/pcc-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/drivers/cpufreq/pcc-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/pcc-cpufreq.c
+++ linux-pm/drivers/cpufreq/pcc-cpufreq.c
@@ -204,7 +204,6 @@ static int pcc_cpufreq_target(struct cpu
u32 input_buffer;
int cpu;
- spin_lock(_lock);
cpu = policy->cpu;
pcc_cpu_data = per_cpu_ptr(pcc_cpu_info, cpu);
@@ -216,6 +215,7 @@ static int pcc_cpufreq_target(struct cpu
freqs.old = policy->cur;
freqs.new = target_freq;
cpufreq_freq_transition_begin(policy, );
+ spin_lock(_lock);
input_buffer = 0x1 | (((target_freq * 100)
/ (ioread32(_hdr->nominal) * 1000)) << 8);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:16 PM, Al Viro wrote: > > FWIW, I suspect that the right approach is to put refcount + rcu_head in > front of external name and do the following: That's actually fancier than I was expecting. I was just thinking doing a whole new allocation and freeing the old one using RCU. But I guess you're right, you do need the rcu_head even for that, and once you start adding fields you might as well just add a refcount too, and then you don't have the annoyance of a potential memory allocation in that code. So your approach is better and doesn't sound too painful at all. But yeah, I guess we can/should do the trivial ugly thing for 3.17. Send me a proper pull-request, 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/
[PATCH v3 3/4] mm/balloon_compaction: add vmstat counters and kpageflags bit
From: Konstantin Khlebnikov
Always mark pages with PageBalloon even if balloon compaction is
disabled and expose this mark in /proc/kpageflags as KPF_BALLOON.
Also this patch adds three counters into /proc/vmstat: "balloon_inflate",
"balloon_deflate" and "balloon_migrate". They accumulate balloon activity.
Current size of balloon is (balloon_inflate - balloon_deflate) pages.
All generic balloon code now gathered under option CONFIG_MEMORY_BALLOON.
It should be selected by ballooning driver which wants use this feature.
Currently virtio-balloon is the only user.
Signed-off-by: Konstantin Khlebnikov
Cc: Rafael Aquini
Cc: Andrew Morton
---
drivers/virtio/Kconfig |1 +
drivers/virtio/virtio_balloon.c|1 +
fs/proc/page.c |3 +++
include/linux/balloon_compaction.h |2 ++
include/linux/vm_event_item.h |7 +++
include/uapi/linux/kernel-page-flags.h |1 +
mm/Kconfig |7 ++-
mm/Makefile|3 ++-
mm/balloon_compaction.c|2 ++
mm/vmstat.c| 12 +++-
tools/vm/page-types.c |1 +
11 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index c6683f2..00b2286 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -25,6 +25,7 @@ config VIRTIO_PCI
config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
+ select MEMORY_BALLOON
---help---
This driver supports increasing and decreasing the amount
of memory within a KVM guest.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 2bad7f9..f893148 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -396,6 +396,7 @@ static int virtballoon_migratepage(struct balloon_dev_info
*vb_dev_info,
spin_lock_irqsave(_dev_info->pages_lock, flags);
balloon_page_insert(vb_dev_info, newpage);
vb_dev_info->isolated_pages--;
+ __count_vm_event(BALLOON_MIGRATE);
spin_unlock_irqrestore(_dev_info->pages_lock, flags);
vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
set_page_pfns(vb->pfns, newpage);
diff --git a/fs/proc/page.c b/fs/proc/page.c
index e647c55..1e3187d 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -133,6 +133,9 @@ u64 stable_page_flags(struct page *page)
if (PageBuddy(page))
u |= 1 << KPF_BUDDY;
+ if (PageBalloon(page))
+ u |= 1 << KPF_BALLOON;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
u |= kpf_copy_bit(k, KPF_SLAB, PG_slab);
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloon_compaction.h
index bc3d298..9b0a15d 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -166,11 +166,13 @@ static inline gfp_t balloon_mapping_gfp_mask(void)
static inline void balloon_page_insert(struct balloon_dev_info *balloon,
struct page *page)
{
+ __SetPageBalloon(page);
list_add(>lru, >pages);
}
static inline void balloon_page_delete(struct page *page)
{
+ __ClearPageBalloon(page);
list_del(>lru);
}
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index ced9234..730334c 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -72,6 +72,13 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_ZERO_PAGE_ALLOC,
THP_ZERO_PAGE_ALLOC_FAILED,
#endif
+#ifdef CONFIG_MEMORY_BALLOON
+ BALLOON_INFLATE,
+ BALLOON_DEFLATE,
+#ifdef CONFIG_BALLOON_COMPACTION
+ BALLOON_MIGRATE,
+#endif
+#endif
#ifdef CONFIG_DEBUG_TLBFLUSH
#ifdef CONFIG_SMP
NR_TLB_REMOTE_FLUSH,/* cpu tried to flush others' tlbs */
diff --git a/include/uapi/linux/kernel-page-flags.h
b/include/uapi/linux/kernel-page-flags.h
index 5116a0e..2f96d23 100644
--- a/include/uapi/linux/kernel-page-flags.h
+++ b/include/uapi/linux/kernel-page-flags.h
@@ -31,6 +31,7 @@
#define KPF_KSM21
#define KPF_THP22
+#define KPF_BALLOON23
#endif /* _UAPILINUX_KERNEL_PAGE_FLAGS_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 886db21..83250e4 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -228,11 +228,16 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
boolean
#
+# support for memory balloon
+config MEMORY_BALLOON
+ boolean
+
+#
# support for memory balloon compaction
config BALLOON_COMPACTION
bool "Allow for balloon memory compaction/migration"
def_bool y
- depends on COMPACTION && VIRTIO_BALLOON
+ depends on COMPACTION && MEMORY_BALLOON
help
Memory fragmentation introduced by ballooning might reduce
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote: > We can get the long name cases right, and I agree that it'll make the > things nicer, but it might take a couple of days to get right. The thing > I'm concerned about is not screwing DCACHE_RCUACCESS up. FWIW, I suspect that the right approach is to put refcount + rcu_head in front of external name and do the following: * __d_free() checks if we have an external name, gets its containing structure and does if (atomic_dec_and_test(>count)) kfree(name); * switch_names() in non-exchange case (I'd probably call it copy_name, not move_names, but anyway) sets DCACHE_RCUACCESS on target (source has already gotten it from __d_rehash()), increments refcount on target's name if external and, if the source old name is external, decrements its refcount and calls kfree_rcu() if it has hit zero. AFAICS, it guarantees that we'll schedule an RCU callback on name's rch_head at most once, that we won't free it while RCU callback on it is scheduled and we won't free it until a grace period has expired since the last time it had been referenced by observable dentries. Do you see any holes in that? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] mm/balloon_compaction: remove balloon mapping and flag AS_BALLOON_MAP
From: Konstantin Khlebnikov
Now ballooned pages are detected using PageBalloon(). Fake mapping
is no longer required. This patch links ballooned pages to balloon
device using field page->private instead of page->mapping. Also this
patch embeds balloon_dev_info directly into struct virtio_balloon.
Signed-off-by: Konstantin Khlebnikov
Cc: Rafael Aquini
Cc: Andrew Morton
---
drivers/virtio/virtio_balloon.c| 60 +--
include/linux/balloon_compaction.h | 72 +++
include/linux/pagemap.h| 18 ---
mm/balloon_compaction.c| 95 ++--
4 files changed, 39 insertions(+), 206 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index c3eb93fc..2bad7f9 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -59,7 +59,7 @@ struct virtio_balloon
* Each page on this list adds VIRTIO_BALLOON_PAGES_PER_PAGE
* to num_pages above.
*/
- struct balloon_dev_info *vb_dev_info;
+ struct balloon_dev_info vb_dev_info;
/* Synchronize access/update to this struct virtio_balloon elements */
struct mutex balloon_lock;
@@ -127,7 +127,7 @@ static void set_page_pfns(u32 pfns[], struct page *page)
static void fill_balloon(struct virtio_balloon *vb, size_t num)
{
- struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
+ struct balloon_dev_info *vb_dev_info = >vb_dev_info;
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -171,7 +171,7 @@ static void release_pages_by_pfn(const u32 pfns[], unsigned
int num)
static void leak_balloon(struct virtio_balloon *vb, size_t num)
{
struct page *page;
- struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
+ struct balloon_dev_info *vb_dev_info = >vb_dev_info;
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -353,12 +353,11 @@ static int init_vqs(struct virtio_balloon *vb)
return 0;
}
-static const struct address_space_operations virtio_balloon_aops;
#ifdef CONFIG_BALLOON_COMPACTION
/*
* virtballoon_migratepage - perform the balloon page migration on behalf of
* a compation thread. (called under page lock)
- * @mapping: the page->mapping which will be assigned to the new migrated page.
+ * @vb_dev_info: the balloon device
* @newpage: page that will replace the isolated page after migration finishes.
* @page : the isolated (old) page that is about to be migrated to newpage.
* @mode : compaction mode -- not used for balloon page migration.
@@ -373,17 +372,13 @@ static const struct address_space_operations
virtio_balloon_aops;
* This function preforms the balloon page migration task.
* Called through balloon_mapping->a_ops->migratepage
*/
-static int virtballoon_migratepage(struct address_space *mapping,
+static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info,
struct page *newpage, struct page *page, enum migrate_mode mode)
{
- struct balloon_dev_info *vb_dev_info = balloon_page_device(page);
- struct virtio_balloon *vb;
+ struct virtio_balloon *vb = container_of(vb_dev_info,
+ struct virtio_balloon, vb_dev_info);
unsigned long flags;
- BUG_ON(!vb_dev_info);
-
- vb = vb_dev_info->balloon_device;
-
/*
* In order to avoid lock contention while migrating pages concurrently
* to leak_balloon() or fill_balloon() we just give up the balloon_lock
@@ -399,7 +394,7 @@ static int virtballoon_migratepage(struct address_space
*mapping,
/* balloon's page migration 1st step -- inflate "newpage" */
spin_lock_irqsave(_dev_info->pages_lock, flags);
- balloon_page_insert(newpage, mapping, _dev_info->pages);
+ balloon_page_insert(vb_dev_info, newpage);
vb_dev_info->isolated_pages--;
spin_unlock_irqrestore(_dev_info->pages_lock, flags);
vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
@@ -418,18 +413,11 @@ static int virtballoon_migratepage(struct address_space
*mapping,
return MIGRATEPAGE_SUCCESS;
}
-
-/* define the balloon_mapping->a_ops callback to allow balloon page migration
*/
-static const struct address_space_operations virtio_balloon_aops = {
- .migratepage = virtballoon_migratepage,
-};
#endif /* CONFIG_BALLOON_COMPACTION */
static int virtballoon_probe(struct virtio_device *vdev)
{
struct virtio_balloon *vb;
- struct address_space *vb_mapping;
- struct balloon_dev_info *vb_devinfo;
int err;
vdev->priv = vb = kmalloc(sizeof(*vb), GFP_KERNEL);
@@ -445,30 +433,14 @@ static int virtballoon_probe(struct virtio_device *vdev)
vb->vdev = vdev;
vb->need_stats_update = 0;
- vb_devinfo =
[PATCH v3 4/4] selftests/vm/transhuge-stress: stress test for memory compaction
This tool induces memory fragmentation via sequential allocation of
transparent huge pages and splitting off everything except their last
sub-pages. It easily generates pressure to the memory compaction code.
$ perf stat -e 'compaction:*' -e 'migrate:*' ./transhuge-stress
transhuge-stress: allocate 7858 transhuge pages, using 15716 MiB virtual memory
and 61 MiB of ram
transhuge-stress: 1.653 s/loop, 0.210 ms/page, 9504.828 MiB/s 7858 succeed,
0 failed, 2439 different pages
transhuge-stress: 1.537 s/loop, 0.196 ms/page, 10226.227 MiB/s 7858 succeed,
0 failed, 2364 different pages
transhuge-stress: 1.658 s/loop, 0.211 ms/page, 9479.215 MiB/s 7858 succeed,
0 failed, 2179 different pages
transhuge-stress: 1.617 s/loop, 0.206 ms/page, 9716.992 MiB/s 7858 succeed,
0 failed, 2421 different pages
^C./transhuge-stress: Interrupt
Performance counter stats for './transhuge-stress':
1.744.051 compaction:mm_compaction_isolate_migratepages
1.014 compaction:mm_compaction_isolate_freepages
1.744.051 compaction:mm_compaction_migratepages
1.647 compaction:mm_compaction_begin
1.647 compaction:mm_compaction_end
1.744.051 migrate:mm_migrate_pages
0 migrate:mm_numa_migrate_ratelimit
7,964696835 seconds time elapsed
Signed-off-by: Konstantin Khlebnikov
Cc: Rafael Aquini
Cc: Andrey Ryabinin
Cc: Shuah Khan
Cc: Andrew Morton
---
tools/testing/selftests/vm/Makefile |1
tools/testing/selftests/vm/transhuge-stress.c | 144 +
2 files changed, 145 insertions(+)
create mode 100644 tools/testing/selftests/vm/transhuge-stress.c
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index 3f94e1a..4c4b1f6 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -3,6 +3,7 @@
CC = $(CROSS_COMPILE)gcc
CFLAGS = -Wall
BINARIES = hugepage-mmap hugepage-shm map_hugetlb thuge-gen hugetlbfstest
+BINARIES += transhuge-stress
all: $(BINARIES)
%: %.c
diff --git a/tools/testing/selftests/vm/transhuge-stress.c
b/tools/testing/selftests/vm/transhuge-stress.c
new file mode 100644
index 000..fd7f1b4
--- /dev/null
+++ b/tools/testing/selftests/vm/transhuge-stress.c
@@ -0,0 +1,144 @@
+/*
+ * Stress test for transparent huge pages, memory compaction and migration.
+ *
+ * Authors: Konstantin Khlebnikov
+ *
+ * This is free and unencumbered software released into the public domain.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PAGE_SHIFT 12
+#define HPAGE_SHIFT 21
+
+#define PAGE_SIZE (1 << PAGE_SHIFT)
+#define HPAGE_SIZE (1 << HPAGE_SHIFT)
+
+#define PAGEMAP_PRESENT(ent) (((ent) & (1ull << 63)) != 0)
+#define PAGEMAP_PFN(ent) ((ent) & ((1ull << 55) - 1))
+
+int pagemap_fd;
+
+int64_t allocate_transhuge(void *ptr)
+{
+ uint64_t ent[2];
+
+ /* drop pmd */
+ if (mmap(ptr, HPAGE_SIZE, PROT_READ | PROT_WRITE,
+ MAP_FIXED | MAP_ANONYMOUS |
+ MAP_NORESERVE | MAP_PRIVATE, -1, 0) != ptr)
+ errx(2, "mmap transhuge");
+
+ if (madvise(ptr, HPAGE_SIZE, MADV_HUGEPAGE))
+ err(2, "MADV_HUGEPAGE");
+
+ /* allocate transparent huge page */
+ *(volatile void **)ptr = ptr;
+
+ if (pread(pagemap_fd, ent, sizeof(ent),
+ (uintptr_t)ptr >> (PAGE_SHIFT - 3)) != sizeof(ent))
+ err(2, "read pagemap");
+
+ if (PAGEMAP_PRESENT(ent[0]) && PAGEMAP_PRESENT(ent[1]) &&
+ PAGEMAP_PFN(ent[0]) + 1 == PAGEMAP_PFN(ent[1]) &&
+ !(PAGEMAP_PFN(ent[0]) & ((1 << (HPAGE_SHIFT - PAGE_SHIFT)) - 1)))
+ return PAGEMAP_PFN(ent[0]);
+
+ return -1;
+}
+
+int main(int argc, char **argv)
+{
+ size_t ram, len;
+ void *ptr, *p;
+ struct timespec a, b;
+ double s;
+ uint8_t *map;
+ size_t map_len;
+
+ ram = sysconf(_SC_PHYS_PAGES);
+ if (ram > SIZE_MAX / sysconf(_SC_PAGESIZE) / 4)
+ ram = SIZE_MAX / 4;
+ else
+ ram *= sysconf(_SC_PAGESIZE);
+
+ if (argc == 1)
+ len = ram;
+ else if (!strcmp(argv[1], "-h"))
+ errx(1, "usage: %s [size in MiB]", argv[0]);
+ else
+ len = atoll(argv[1]) << 20;
+
+ warnx("allocate %zd transhuge pages, using %zd MiB virtual memory"
+ " and %zd MiB of ram", len >> HPAGE_SHIFT, len >> 20,
+ len >> (20 + HPAGE_SHIFT - PAGE_SHIFT - 1));
+
+ pagemap_fd = open("/proc/self/pagemap", O_RDONLY);
+ if (pagemap_fd < 0)
+ err(2, "open pagemap");
+
+ len -= len % HPAGE_SIZE;
+ ptr = mmap(NULL, len + HPAGE_SIZE, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_NORESERVE | MAP_PRIVATE, -1, 0);
+ if (ptr ==
[PATCH v3 0/4] mm/balloon_compaction: fixes and cleanups
Here is reworked and resplitted patchset. patches agains current mmotm. I've merged fixes into first patch. It appyies clearly to v3.16, older kernels has a trivial conflict in mm/migrate.c. Reference counting during isolation and migration of ballooned pages reorganized and now looks similar to scheme used for normal pages (grab extra reference, isolate, migrate, putback/drop extra reference). Changes since v2: * PagePrivate used for fixing race between isolation and deflation * all fixes merged into first patch second patch contains only cleanup third patch adds new interfaces (vmstat, kpageflags) transhuge-stress: no changes except commit message bloat-o-meter (x86_64, defconfig + balloon-compaction): add/remove: 0/7 grow/shrink: 7/9 up/down: 134/-1045 (-911) function old new delta virtballoon_migratepage 322 357 +35 vmstat_text 824 848 +24 vm_event_states 496 520 +24 stable_page_flags378 401 +23 balloon_page_enqueue 138 154 +16 balloon_page_migrate 162 168 +6 balloon_page_dequeue 287 293 +6 leak_balloon 254 246 -8 balloon_page_putback 205 193 -12 __ksymtab_balloon_mapping_alloc 16 - -16 __ksymtab_balloon_devinfo_alloc 16 - -16 virtballoon_remove70 48 -22 __kstrtab_balloon_mapping_alloc 22 - -22 __kstrtab_balloon_devinfo_alloc 22 - -22 balloon_page_isolate 291 243 -48 virtballoon_probe382 318 -64 balloon_devinfo_alloc 96 - -96 isolate_migratepages_block 16821578-104 reclaim_clean_pages_from_list435 330-105 putback_movable_pages312 207-105 migrate_pages 19921875-117 balloon_mapping_alloc128 --128 virtio_balloon_aops 160 --160 even allnoconfig is smaller now: add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-291 (-291) function old new delta balloon_devinfo_alloc 63 - -63 balloon_page_enqueue 82 - -82 balloon_page_dequeue 146 --146 --- Konstantin Khlebnikov (4): mm/balloon_compaction: redesign ballooned pages management mm/balloon_compaction: remove balloon mapping and flag AS_BALLOON_MAP mm/balloon_compaction: add vmstat counters and kpageflags bit selftests/vm/transhuge-stress: stress test for memory compaction drivers/virtio/Kconfig|1 drivers/virtio/virtio_balloon.c | 76 +++ fs/proc/page.c|3 include/linux/balloon_compaction.h| 169 +++-- include/linux/migrate.h | 11 -- include/linux/mm.h| 19 +++ include/linux/pagemap.h | 18 --- include/linux/vm_event_item.h |7 + include/uapi/linux/kernel-page-flags.h|1 mm/Kconfig|7 + mm/Makefile |3 mm/balloon_compaction.c | 123 +++--- mm/compaction.c |2 mm/migrate.c | 16 +- mm/vmstat.c | 12 ++ tools/testing/selftests/vm/Makefile |1 tools/testing/selftests/vm/transhuge-stress.c | 144 + tools/vm/page-types.c |1 18 files changed, 288 insertions(+), 326 deletions(-) create mode 100644 tools/testing/selftests/vm/transhuge-stress.c -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management
From: Konstantin Khlebnikov
Sasha Levin reported KASAN splash inside isolate_migratepages_range().
Problem is in the function __is_movable_balloon_page() which tests
AS_BALLOON_MAP in page->mapping->flags. This function has no protection
against anonymous pages. As result it tried to check address space flags
inside struct anon_vma.
Further investigation shows more problems in current implementation:
* Special branch in __unmap_and_move() never works: balloon_page_movable()
checks page flags and page_count. In __unmap_and_move() page is locked,
reference counter is elevated, thus balloon_page_movable() always fails.
As a result execution goes to the normal migration path.
virtballoon_migratepage() returns MIGRATEPAGE_BALLOON_SUCCESS instead of
MIGRATEPAGE_SUCCESS, move_to_new_page() thinks this is an error code and
assigns newpage->mapping to NULL. Newly migrated page lose connectivity
with balloon an all ability for further migration.
* lru_lock erroneously required in isolate_migratepages_range() for
isolation ballooned page. This function releases lru_lock periodically,
this makes migration mostly impossible for some pages.
* balloon_page_dequeue have a tight race with balloon_page_isolate:
balloon_page_isolate could be executed in parallel with dequeue between
picking page from list and locking page_lock. Race is rare because they
use trylock_page() for locking.
This patch fixes all of them.
Instead of fake mapping with special flag this patch uses special state
of page->_mapcount: PAGE_BALLOON_MAPCOUNT_VALUE = -256. Buddy allocator
uses PAGE_BUDDY_MAPCOUNT_VALUE = -128 for similar purpose. Storing mark
directly in struct page makes everything safer and easier.
PagePrivate is used to mark pages present in page list (i.e. not isolated,
like PageLRU for normal pages). It replaces special rules for reference
counter and makes balloon migration similar to migration of normal pages.
This flag is protected by page_lock together with link to the balloon device.
Signed-off-by: Konstantin Khlebnikov
Reported-by: Sasha Levin
Link: http://lkml.kernel.org/p/53e6ceaa.9020...@oracle.com
Cc: Rafael Aquini
Cc: Andrey Ryabinin
Cc: Stable (v3.8+)
Cc: Andrew Morton
---
drivers/virtio/virtio_balloon.c| 15 +++---
include/linux/balloon_compaction.h | 97 +---
include/linux/migrate.h| 11
include/linux/mm.h | 19 +++
mm/balloon_compaction.c| 26 --
mm/compaction.c|2 -
mm/migrate.c | 16 +-
7 files changed, 68 insertions(+), 118 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 25ebe8e..c3eb93fc 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -163,8 +163,8 @@ static void release_pages_by_pfn(const u32 pfns[], unsigned
int num)
/* Find pfns pointing at start of each page, get pages and free them. */
for (i = 0; i < num; i += VIRTIO_BALLOON_PAGES_PER_PAGE) {
struct page *page = balloon_pfn_to_page(pfns[i]);
- balloon_page_free(page);
adjust_managed_page_count(page, 1);
+ put_page(page); /* balloon reference */
}
}
@@ -395,6 +395,8 @@ static int virtballoon_migratepage(struct address_space
*mapping,
if (!mutex_trylock(>balloon_lock))
return -EAGAIN;
+ get_page(newpage); /* balloon reference */
+
/* balloon's page migration 1st step -- inflate "newpage" */
spin_lock_irqsave(_dev_info->pages_lock, flags);
balloon_page_insert(newpage, mapping, _dev_info->pages);
@@ -404,12 +406,7 @@ static int virtballoon_migratepage(struct address_space
*mapping,
set_page_pfns(vb->pfns, newpage);
tell_host(vb, vb->inflate_vq);
- /*
-* balloon's page migration 2nd step -- deflate "page"
-*
-* It's safe to delete page->lru here because this page is at
-* an isolated migration list, and this step is expected to happen here
-*/
+ /* balloon's page migration 2nd step -- deflate "page" */
balloon_page_delete(page);
vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
set_page_pfns(vb->pfns, page);
@@ -417,7 +414,9 @@ static int virtballoon_migratepage(struct address_space
*mapping,
mutex_unlock(>balloon_lock);
- return MIGRATEPAGE_BALLOON_SUCCESS;
+ put_page(page); /* balloon reference */
+
+ return MIGRATEPAGE_SUCCESS;
}
/* define the balloon_mapping->a_ops callback to allow balloon page migration
*/
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloon_compaction.h
index 089743a..38aa07d 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -27,10 +27,13 @@
* counter raised only while it is under our special handling;
*
* iii. after the lockless scan step
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping
when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to
the source location will fault and cause fresh pages to be mapped in.
For consistency, the old_len >= new_len case could decommit the pages
instead of unmapping. However, userspace can accomplish the same thing
via madvise and a coherent definition of the flag is possible without
the extra complexity.
Motivation:
TCMalloc and jemalloc avoid releasing virtual memory in order to reduce
virtual memory fragmentation. A call to munmap or mremap would leave a
hole in the address space. Instead, unused pages are lazily returned to
the operating system via MADV_DONTNEED.
Since mremap cannot be used to elide copies, TCMalloc and jemalloc end
up being significantly slower for patterns like repeated vector / hash
table reallocations. Consider the typical vector building pattern:
#include
#include
int main(void) {
void *ptr = NULL;
size_t old_size = 0;
for (size_t size = 4; size < (1 << 30); size *= 2) {
ptr = realloc(ptr, size);
if (!ptr) return 1;
memset(ptr + old_size, 0xff, size - old_size);
old_size = size;
}
}
glibc: 0.135s
jemalloc: 0.226s
TCMalloc: 0.238s
In practice, in-place growth never occurs because the heap grows in the
downwards direction for all 3 allocators. TCMalloc and jemalloc pay for
enormous copies while glibc is only spending time writing new elements
to the vector. Even if it was grown in the other direction, real-world
applications would end up blocking in-place growth with new allocations.
The allocators could attempt to map the source location again after an
mremap call, but there is no guarantee of success in a multi-threaded
program and fragmentating memory over time is considered unacceptable.
Signed-off-by: Daniel Micay
---
include/uapi/linux/mman.h | 1 +
mm/mremap.c | 18 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index ade4acd..4e9a546 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -5,6 +5,7 @@
#define MREMAP_MAYMOVE 1
#define MREMAP_FIXED 2
+#define MREMAP_RETAIN 4
#define OVERCOMMIT_GUESS 0
#define OVERCOMMIT_ALWAYS 1
diff --git a/mm/mremap.c b/mm/mremap.c
index 05f1180..c01bab6 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -235,7 +235,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
static unsigned long move_vma(struct vm_area_struct *vma,
unsigned long old_addr, unsigned long old_len,
- unsigned long new_len, unsigned long new_addr, bool *locked)
+ unsigned long new_len, unsigned long new_addr, bool retain,
+ bool *locked)
{
struct mm_struct *mm = vma->vm_mm;
struct vm_area_struct *new_vma;
@@ -287,6 +288,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
old_len = new_len;
old_addr = new_addr;
new_addr = -ENOMEM;
+ retain = false;
}
/* Conceal VM_ACCOUNT so old reservation is not undone */
@@ -310,7 +312,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
hiwater_vm = mm->hiwater_vm;
vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT);
- if (do_munmap(mm, old_addr, old_len) < 0) {
+ if (retain || do_munmap(mm, old_addr, old_len) < 0) {
/* OOM: unable to split vma, just get accounts right */
vm_unacct_memory(excess >> PAGE_SHIFT);
excess = 0;
@@ -392,7 +394,8 @@ Eagain:
}
static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
- unsigned long new_addr, unsigned long new_len, bool *locked)
+ unsigned long new_addr, unsigned long new_len, bool retain,
+ bool *locked)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
@@ -442,7 +445,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned
long old_len,
if (ret & ~PAGE_MASK)
goto out1;
- ret = move_vma(vma, addr, old_len, new_len, new_addr, locked);
+ ret = move_vma(vma, addr, old_len, new_len, new_addr, retain, locked);
if (!(ret & ~PAGE_MASK))
goto out;
out1:
@@ -482,7 +485,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long,
old_len,
unsigned long charged = 0;
bool locked = false;
- if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
+ if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_RETAIN))
return ret;
if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
@@ -506,7 +509,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long,
old_len,
if (flags & MREMAP_FIXED) {
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 10:56:57AM -0700, Linus Torvalds wrote:
> - make a new "move_name(src,dst)" that explicitly moves names, and
> explicitly knows that the source needs to be kept alive (although it
> *could* also look at the source dentry refcount to decide whether it
> needs to be careful or not). And do it right for the long names too,
> not just the inline case.
Er? Source dentry refcount doesn't matter at all - *that* one gets
rehashed, so we must get its name right, no matter what. The target
one is where it becomes interesting. And I doubt it's worth bothering
with refcount checks on that either, TBH...
The reason why we really can't get it right for long names without more
serious surgery is that currently the lifetime of external name is
the same as of dentry having that name. And that makes "just copy them
over, long or not" a problem - we suddenly get two dentries sharing the
external name. And we hit that under a shitload of spinlocks, so
allocating a separate copy isn't attractive. Mikhail (IIRC - I hadn't
watched this thread all that closely back then, so I might be misattributing)
had proposed refcounting the external names. That would work, but we'll
need to get it right. Sure, we can make that refcount atomic_t; it's not
as if we'll be playing with it a lot. However, if the *source* name had
been external, we need to drop the refcount on that, and we need to
RCU-delay actual freeing. Right now the delay comes from RCU-delaying
__d_free(), with some optimisations for dentries that had never been hashed;
this will be somewhat hairier.
> Al (or Mikhail) - willing to do that extra cleanup? Please?
See above. I can do that, but it will be less trivial than you seem to
expect it to be. Anyway, the situation right now: vfs.git#for-linus
survives the testing (and I'd like your S-o-b on the last one-liner there;
if you have saner commit message - even better). That can go in right
now, as far as I'm concerned.
The minimal port of Mikhail's patch on top of that is below; it doesn't
include what you are asking for, it's just an update to the situation past
merging __d_move() and __d_materialise_dentry().
We can get the long name cases right, and I agree that it'll make the
things nicer, but it might take a couple of days to get right. The thing
I'm concerned about is not screwing DCACHE_RCUACCESS up.
BTW, the comments about being more careful with ->d_name.hash than with
->d_name.name are from back in 2.3.40s; they became obsolete by 2.3.60s,
when we started to unhash the target instead of swapping hash chain positions
followed by d_delete() as we used to do when dcache was first introduced.
It's a really old piece of detritus...
diff --git a/fs/dcache.c b/fs/dcache.c
index 7599d35..cb25a1a 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2372,7 +2372,8 @@ void dentry_update_name_case(struct dentry *dentry,
struct qstr *name)
}
EXPORT_SYMBOL(dentry_update_name_case);
-static void switch_names(struct dentry *dentry, struct dentry *target)
+static void switch_names(struct dentry *dentry, struct dentry *target,
+bool exchange)
{
if (dname_external(target)) {
if (dname_external(dentry)) {
@@ -2406,6 +2407,12 @@ static void switch_names(struct dentry *dentry, struct
dentry *target)
*/
unsigned int i;
BUILD_BUG_ON(!IS_ALIGNED(DNAME_INLINE_LEN,
sizeof(long)));
+ if (!exchange) {
+ memcpy(dentry->d_iname, target->d_name.name,
+ target->d_name.len + 1);
+ dentry->d_name.hash_len =
target->d_name.hash_len;
+ return;
+ }
for (i = 0; i < DNAME_INLINE_LEN / sizeof(long); i++) {
swap(((long *) >d_iname)[i],
((long *) >d_iname)[i]);
@@ -2456,12 +2463,15 @@ static void dentry_unlock_for_move(struct dentry
*dentry, struct dentry *target)
* When switching names, the actual string doesn't strictly have to
* be preserved in the target - because we're dropping the target
* anyway. As such, we can just do a simple memcpy() to copy over
- * the new name before we switch.
- *
- * Note that we have to be a lot more careful about getting the hash
- * switched - we have to switch the hash value properly even if it
- * then no longer matches the actual (corrupted) string of the target.
- * The hash value has to match the hash queue that the dentry is on..
+ * the new name before we switch, unless we are going to rehash
+ * it. Note that if we *do* unhash the target, we are not allowed
+ * to rehash it without giving it a new name/hash key - whether
+ * we swap or overwrite the names here, resulting name won't match
+ * the reality in filesystem; it's only there for d_path() purposes.
+ * Note that
Re: [PATCH v3 1/3] cap11xx: make driver generic for variant support
On 09/25/2014 07:24 AM, Matt Ranostay wrote: > cap1106 driver can support much more one device make the driver > generic for support of similiar parts. > > Signed-off-by: Matt Ranostay > --- > .../devicetree/bindings/input/cap1106.txt | 53 > .../devicetree/bindings/input/cap11xx.txt | 54 > drivers/input/keyboard/Kconfig | 8 +- > drivers/input/keyboard/Makefile| 2 +- > drivers/input/keyboard/cap1106.c | 341 > - > drivers/input/keyboard/cap11xx.c | 340 > 6 files changed, 399 insertions(+), 399 deletions(-) As I've said, such a patch is really a whole lot more readable if you use the -M switch for git format-patch to detect renames. Other than that, the series now looks good to me. I can't test it, however, as I don't have access to the hardware anymore. Reviewed-by: Daniel Mack 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] fork.c: copy_process(): fix cleanup WRT perf_event_free_task()
On 09/26, Sylvain 'ythier' Hitier wrote: > > retval = sched_fork(clone_flags, p); > if (retval) > // // mustn't perf_event_free_task() > goto bad_fork_cleanup_policy; Agreed, this is wrong. Good catch. but, unless I missed something, > retval = perf_event_init_task(p); > if (retval) > // // mustn't perf_event_free_task() ^^ this is not right and thus the patch is not right too. Suppose that perf_event_init_task() -> perf_event_init_context(ctxn => 0) succeeds and then perf_event_init_context(ctxn => 1) fails, we need perf_event_free_task() to cleanup ->perf_event_ctxp[0]. So if perf_event_init_task() fails, we still need "goto bad_fork_cleanup_perf". No? Or, probably better, we need to change perf_event_init_context() to call perf_event_free_task() on failure. Or. We can simply move memset(child->perf_event_ctxp, 0, ...) from perf_event_init_context() up. This reminds that we really need to cleanup copy_process(), in particular I think it asks for the new copy_xxx() helper which should do misc simple initializations which can't fail. What do you think? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping
when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to
the source location will fault and cause fresh pages to be mapped in.
For consistency, the old_len >= new_len case could decommit the pages
instead of unmapping. However, userspace can accomplish the same thing
via madvise and a coherent definition of the flag is possible without
the extra complexity.
Motivation:
TCMalloc and jemalloc avoid releasing virtual memory in order to reduce
virtual memory fragmentation. A call to munmap or mremap would leave a
hole in the address space. Instead, unused pages are lazily returned to
the operating system via MADV_DONTNEED.
Since mremap cannot be used to elide copies, TCMalloc and jemalloc end
up being significantly slower for patterns like repeated vector / hash
table reallocations. Consider the typical vector building pattern:
#include
#include
int main(void) {
void *ptr = NULL;
size_t old_size = 0;
for (size_t size = 4; size < (1 << 30); size *= 2) {
ptr = realloc(ptr, size);
if (!ptr) return 1;
memset(ptr, 0xff, size - old_size);
old_size = size;
}
}
glibc: 0.115s
jemalloc: 0.199s
TCMalloc: 0.202s
In practice, in-place growth never occurs because the heap grows in the
downwards direction for all 3 allocators. TCMalloc and jemalloc pay for
enormous copies while glibc is only spending time writing new elements
to the vector. Even if it was grown in the other direction, real-world
applications would end up blocking in-place growth with new allocations.
The allocators could attempt to map the source location again after an
mremap call, but there is no guarantee of success in a multi-threaded
program and fragmentating memory over time is considered unacceptable.
Signed-off-by: Daniel Micay
---
include/uapi/linux/mman.h | 1 +
mm/mremap.c | 18 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index ade4acd..4e9a546 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -5,6 +5,7 @@
#define MREMAP_MAYMOVE 1
#define MREMAP_FIXED 2
+#define MREMAP_RETAIN 4
#define OVERCOMMIT_GUESS 0
#define OVERCOMMIT_ALWAYS 1
diff --git a/mm/mremap.c b/mm/mremap.c
index 05f1180..c01bab6 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -235,7 +235,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
static unsigned long move_vma(struct vm_area_struct *vma,
unsigned long old_addr, unsigned long old_len,
- unsigned long new_len, unsigned long new_addr, bool *locked)
+ unsigned long new_len, unsigned long new_addr, bool retain,
+ bool *locked)
{
struct mm_struct *mm = vma->vm_mm;
struct vm_area_struct *new_vma;
@@ -287,6 +288,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
old_len = new_len;
old_addr = new_addr;
new_addr = -ENOMEM;
+ retain = false;
}
/* Conceal VM_ACCOUNT so old reservation is not undone */
@@ -310,7 +312,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
hiwater_vm = mm->hiwater_vm;
vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT);
- if (do_munmap(mm, old_addr, old_len) < 0) {
+ if (retain || do_munmap(mm, old_addr, old_len) < 0) {
/* OOM: unable to split vma, just get accounts right */
vm_unacct_memory(excess >> PAGE_SHIFT);
excess = 0;
@@ -392,7 +394,8 @@ Eagain:
}
static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
- unsigned long new_addr, unsigned long new_len, bool *locked)
+ unsigned long new_addr, unsigned long new_len, bool retain,
+ bool *locked)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
@@ -442,7 +445,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned
long old_len,
if (ret & ~PAGE_MASK)
goto out1;
- ret = move_vma(vma, addr, old_len, new_len, new_addr, locked);
+ ret = move_vma(vma, addr, old_len, new_len, new_addr, retain, locked);
if (!(ret & ~PAGE_MASK))
goto out;
out1:
@@ -482,7 +485,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long,
old_len,
unsigned long charged = 0;
bool locked = false;
- if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
+ if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_RETAIN))
return ret;
if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
@@ -506,7 +509,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long,
old_len,
if (flags & MREMAP_FIXED) {
ret =
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Fri, Sep 26, 2014 at 9:45 PM, Al Viro wrote: > > Linus, it's a real userland regression. That's not the part I'm arguing against. I think the patch itself was too ugly to live. Yes, we had that hack before, but we didn't make it conditional. It historically was more of a "it's easier to just memcpy the name" than switch things around. Then that became accidental semantics, and that's all normal. But then when we make this explicit and intentional, I really think we should do it *right*, and either switch() the names around or just copy it. Having a "switch_names()" function that *neither* switches *nor* copies, and giving it an argument to decide which, but not even do it *right*? That's just too f*cking disgusting for words. So seriously, I think we should: - keep the "switch_names()" as is, since it actually does what the name says it does, and some callers want to statically do exactly that. - make a new "move_name(src,dst)" that explicitly moves names, and explicitly knows that the source needs to be kept alive (although it *could* also look at the source dentry refcount to decide whether it needs to be careful or not). And do it right for the long names too, not just the inline case. - make that __d_move() caller just pick one or the other explicitly. See what my complaint is? Not this half-assery that used to be a small random detail, and that the patch makes into an institutionalized and explicit half-assery. (And Mikhail - I'm not ragging on you, even if I'm ragging on the patch. I understand why you did it the way you did, and it makes sense exactly in the "let's reinstate old hackery" model. I just think we can and should do better than that, now that the "exchange" vs "move over" semantics are so explicit). Al (or Mikhail) - willing to do that extra cleanup? Please? 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 2/2] perf: Userspace software event and ioctl
2014-09-25 20:33 GMT+02:00 Ingo Molnar : > > * Pawel Moll wrote: > >> On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote: >> > * Pawel Moll wrote: >> > >> > > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote: >> > > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type, >> > > > which can be generated by user with PERF_EVENT_IOC_ENTRY >> > > > ioctl command, which injects an event of said type into >> > > > the perf buffer. >> > > >> > > It occurred to me last night that currently perf doesn't handle "write" >> > > syscall at all, while this seems like the most natural way of >> > > "injecting" userspace events into perf buffer. >> > > >> > > An ioctl would still be needed to set a type of the following events, >> > > something like: >> > > >> > > ioctl(SET_TYPE, 0x42); >> > > write(perf_fd, binaryblob, size); >> > > ioctl(SET_TYPE, 0); >> > > dprintf(perf_fd, "String"); >> > > >> > > which is fine for use cases when the type doesn't change often, >> > > but would double the amount of syscalls when every single event >> > > is of a different type. Perhaps there still should be a >> > > "generating ioctl" taking both type and data/size in one go? >> > >> > Absolutely, there should be a single syscall. >> >> Yeah, it's my gut feeling as well. I just wonder if we still want to >> keep write() handler for operations on perf fds? This seems natural - >> takes data buffer and its size. The only issue is the type. >> >> > I'd even argue it should be a new prctl(): that way we could both >> > generate user events for specific perf fds, but also into any >> > currently active context (that allows just generation/injection >> > of user events). In the latter case we might have no fd to work >> > off from. >> >> When Arnaldo suggested that the "user events" could be used by perf >> trace, it was exactly my first thought. I just didn't have answer how to >> present it to the user (an extra syscall didn't seem like a good idea), >> but prctl seems interesting, something like this? >> >> prctl(PR_TRACE_UEVENT, type, size, data, 0); > > Exactly! > >> How would we select tasks that can write to a given buffer? Maybe an >> ioctl() on a perf fd? Something like this? >> >> ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid); >> ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid); > > No, I think there's a simpler way: this should be a regular > perf_attr flag, which defaults to '0' (tasks cannot do this), but > which can be set to 1 if the profiler explicitly allows such > event injection. Maybe we just don't even need any permission at all. Which harm can that do if this only ever generate events to those interested in the relevant perf context? It could be a simple tracepoint BTW. Oh and I really like the fact we don't use a syscall that requires an fd. The tracee really shouldn't be aware of the tracer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86: irq: Duplicate interrupt name THR
Hello. The interrupt name "THR" used twice for x86 architecture. It is used for "Threshold APIC interrupts" and "Hypervisor callback interrupts". I don't know if duplicates are a valid for /proc/interrupt table, but this could lead to problems with user space applications, as they have to parse not only interrupt name, but a description too. The duplicate was introduced by commit 929320e4b4c10708d3477d7e395f0ce7b0cc8744 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched/nohz: add debugfs control over sched_tick_max_deferment
On Fri, Sep 26, 2014 at 12:45:32PM -0700, Kevin Hilman wrote:
> From: Kevin Hilman
>
> Allow debugfs override of sched_tick_max_deferment in order to ease
> finding/fixing the remaining issues with full nohz.
>
> The value to be written is in jiffies, and -1 means the max deferment
> is disabled (scheduler_tick_max_deferment() returns KTIME_MAX.)
>
> Cc: Frederic Weisbecker
> Signed-off-by: Kevin Hilman
So, I'm worried that it becomes a hack that everybody uses to shutdown
the tick completely then nobody will come and fix the issue that prevents
from doing it properly.
I seriously doubt this will be used for development purpose to help
fixing the real problem. Quite the opposite. If developers want to do
testing, they can as well comment out the call to
scheduler_max_tick_deferment().
> ---
> kernel/sched/core.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index bc1638b33449..dee044a5d447 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2514,6 +2514,8 @@ void scheduler_tick(void)
> }
>
> #ifdef CONFIG_NO_HZ_FULL
> +static u32 sched_tick_max_deferment = HZ;
> +
> /**
> * scheduler_tick_max_deferment
> *
> @@ -2532,13 +2534,25 @@ u64 scheduler_tick_max_deferment(void)
> struct rq *rq = this_rq();
> unsigned long next, now = ACCESS_ONCE(jiffies);
>
> - next = rq->last_sched_tick + HZ;
> + if (sched_tick_max_deferment == -1)
> + return KTIME_MAX;
> +
> + next = rq->last_sched_tick + sched_tick_max_deferment;
>
> if (time_before_eq(next, now))
> return 0;
>
> return jiffies_to_nsecs(next - now);
> }
> +
> +static __init int sched_nohz_full_init_debug(void)
> +{
> + debugfs_create_u32("sched_tick_max_deferment", 0644, NULL,
> +_tick_max_deferment);
> +
> + return 0;
> +}
> +late_initcall(sched_nohz_full_init_debug);
> #endif
>
> notrace unsigned long get_parent_ip(unsigned long addr)
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 02/16] perf, core: introduce pmu context switch callback
On Sun, Jan 07, 2001 at 09:29:31PM -0500, kan.li...@intel.com wrote:
> From: Kan Liang
>
> The callback is invoked when process is scheduled in or out.
> It provides mechanism for later patches to save/store the LBR
> stack. For the schedule in case, the callback is invoked at
> the same place that flush branch stack callback is invoked.
> So it also can replace the flush branch stack callback. To
> avoid unnecessary overhead, the callback is enabled only when
> there are events use the LBR stack.
>
> Signed-off-by: Yan, Zheng
> ---
> arch/x86/kernel/cpu/perf_event.c | 7 +
> arch/x86/kernel/cpu/perf_event.h | 2 ++
> include/linux/perf_event.h | 10 +++
> kernel/events/core.c | 59
>
> 4 files changed, 78 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/perf_event.c
> b/arch/x86/kernel/cpu/perf_event.c
> index 0646d3b..4c572e8 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -1877,6 +1877,12 @@ static const struct attribute_group
> *x86_pmu_attr_groups[] = {
> NULL,
> };
>
> +static void x86_pmu_sched_task(struct perf_event_context *ctx, bool sched_in)
> +{
> + if (x86_pmu.sched_task)
> + x86_pmu.sched_task(ctx, sched_in);
> +}
> +
> static void x86_pmu_flush_branch_stack(void)
> {
> if (x86_pmu.flush_branch_stack)
> @@ -1910,6 +1916,7 @@ static struct pmu pmu = {
>
> .event_idx = x86_pmu_event_idx,
> .flush_branch_stack = x86_pmu_flush_branch_stack,
> + .sched_task = x86_pmu_sched_task,
> };
>
> void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
> diff --git a/arch/x86/kernel/cpu/perf_event.h
> b/arch/x86/kernel/cpu/perf_event.h
> index 86c675c..0617abb 100644
> --- a/arch/x86/kernel/cpu/perf_event.h
> +++ b/arch/x86/kernel/cpu/perf_event.h
> @@ -467,6 +467,8 @@ struct x86_pmu {
>
> void(*check_microcode)(void);
> void(*flush_branch_stack)(void);
> + void(*sched_task)(struct perf_event_context *ctx,
> + bool sched_in);
>
> /*
>* Intel Arch Perfmon v2+
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 893a0d0..be0e870 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -263,6 +263,14 @@ struct pmu {
>* flush branch stack on context-switches (needed in cpu-wide mode)
>*/
> void (*flush_branch_stack) (void);
> +
> + /*
> + * context-switches callback for CPU PMU. Other PMUs shouldn't set
> + * this callback
> + */
> + void (*sched_task) (struct perf_event_context *ctx,
> + bool sched_in);
> +
> };
>
> /**
> @@ -562,6 +570,8 @@ extern void perf_event_delayed_put(struct task_struct
> *task);
> extern void perf_event_print_debug(void);
> extern void perf_pmu_disable(struct pmu *pmu);
> extern void perf_pmu_enable(struct pmu *pmu);
> +extern void perf_sched_cb_disable(struct pmu *pmu);
> +extern void perf_sched_cb_enable(struct pmu *pmu);
> extern int perf_event_task_disable(void);
> extern int perf_event_task_enable(void);
> extern int perf_event_refresh(struct perf_event *event, int refresh);
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1212cc4..15d640e 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -154,6 +154,7 @@ enum event_type_t {
> struct static_key_deferred perf_sched_events __read_mostly;
> static DEFINE_PER_CPU(atomic_t, perf_cgroup_events);
> static DEFINE_PER_CPU(atomic_t, perf_branch_stack_events);
> +static DEFINE_PER_CPU(int, perf_sched_cb_usages);
>
> static atomic_t nr_mmap_events __read_mostly;
> static atomic_t nr_comm_events __read_mostly;
> @@ -2427,6 +2428,58 @@ unlock:
> }
> }
>
> +void perf_sched_cb_disable(struct pmu *pmu)
> +{
> + this_cpu_dec(perf_sched_cb_usages);
> +}
> +
> +void perf_sched_cb_enable(struct pmu *pmu)
> +{
> + this_cpu_inc(perf_sched_cb_usages);
> +}
> +
> +/*
> + * This function provides the context switch callback to the lower code
> + * layer. It is invoked ONLY when the context switch callback is enabled.
> + */
> +static void perf_pmu_sched_task(struct task_struct *prev,
> + struct task_struct *next,
> + bool sched_in)
> +{
> + struct perf_cpu_context *cpuctx;
> + struct pmu *pmu;
> + unsigned long flags;
> +
> + if (prev == next)
> + return;
> +
> + local_irq_save(flags);
> +
> + rcu_read_lock();
> +
> + list_for_each_entry_rcu(pmu, , entry) {
> + if (pmu->sched_task) {
> + cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
> +
> + perf_ctx_lock(cpuctx, cpuctx->task_ctx);
> +
> + perf_pmu_disable(pmu);
> +
> +
Re: [PATCH 2/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omapfb
On Fri, Sep 26, 2014 at 06:10:53PM -0700, Behan Webster wrote: > Replace the use of nested functions where a normal function will suffice. > > Nested functions are not liked by upstream kernel developers in general. Their > use breaks the use of clang as a compiler, and doesn't make the code any > better. > > This code now works for both gcc and clang. > > Signed-off-by: Behan Webster > Suggested-by: Arnd Bergmann > Cc: Arnd Bergmann Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss
On Fri, Sep 26, 2014 at 06:10:52PM -0700, Behan Webster wrote: > Replace the use of nested functions where a normal function will suffice. > > Nested functions are not liked by upstream kernel developers in general. Their > use breaks the use of clang as a compiler, and doesn't make the code any > better. > > This code now works for both gcc and clang. > > Signed-off-by: Behan Webster > Suggested-by: Arnd Bergmann > Cc: Arnd Bergmann another one that make sense :-) And probably also deserves checkpatch/coccinelle/sparse. Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
[PATCH 1/1 linux-next] fs/hfs/hfs_fs.h: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h Cc: Andrew Morton Signed-off-by: Fabian Frederick --- fs/hfs/hfs_fs.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h index 0524cda..95d2552 100644 --- a/fs/hfs/hfs_fs.h +++ b/fs/hfs/hfs_fs.h @@ -242,8 +242,6 @@ extern int hfs_mac2asc(struct super_block *, char *, const struct hfs_name *); /* super.c */ extern void hfs_mark_mdb_dirty(struct super_block *sb); -extern struct timezone sys_tz; - /* * There are two time systems. Both are based on seconds since * a particular time/date. -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/3] ARM: dts: rockchip: Enable power off in pmic for Radxa Rock
Add "active-semi,system-power-controller" property to act8846 node.
shutdown/poweroff commands are now handled for this board.
Signed-off-by: Romain Perier
---
arch/arm/boot/dts/rk3188-radxarock.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
b/arch/arm/boot/dts/rk3188-radxarock.dts
index e04bf8f..5b6a937 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -115,6 +115,8 @@
pinctrl-names = "default";
pinctrl-0 = <_dvs0_ctl>;
+ active-semi,system-power-controller;
+
regulators {
vcc_ddr: REG1 {
regulator-name = "VCC_DDR";
--
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 v1 3/3] dt-bindings: Document the property system-power-controller for act8865 regulator
Signed-off-by: Romain Perier --- Documentation/devicetree/bindings/regulator/act8865-regulator.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index 865614b..653ddc1 100644 --- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt @@ -5,6 +5,10 @@ Required properties: - compatible: "active-semi,act8846" or "active-semi,act8865" - reg: I2C slave address +Optional properties: +- active-semi,system-power-controller: Telling whether or not this pmic is controlling + the system power + Any standard regulator properties can be used to configure the single regulator. The valid names for regulators are: -- 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 v1 1/3] regulator: act8865: Add support to turn off all outputs
When the property "active-semi,system-power-controller" is found in the
devicetree, the function pm_power_off is defined. This function sends the
rights bit fields to the global off control register. shutdown/poweroff
commands are now supported for hardware components which use these PMU.
Signed-off-by: Romain Perier
---
drivers/regulator/act8865-regulator.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index afd06f9..6cf202d 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -61,6 +61,8 @@
#defineACT8846_REG12_VSET 0xa0
#defineACT8846_REG12_CTRL 0xa1
#defineACT8846_REG13_CTRL 0xb1
+#defineACT8846_GLB_OFF_CTRL0xc3
+#defineACT8846_OFF_SYSMASK 0x18
/*
* ACT8865 Global Register Map.
@@ -84,6 +86,7 @@
#defineACT8865_LDO3_CTRL 0x61
#defineACT8865_LDO4_VSET 0x64
#defineACT8865_LDO4_CTRL 0x65
+#defineACT8865_MSTROFF 0x20
/*
* Field Definitions.
@@ -98,6 +101,8 @@
struct act8865 {
struct regmap *regmap;
+ int off_reg;
+ int off_mask;
};
static const struct regmap_config act8865_regmap_config = {
@@ -275,6 +280,16 @@ static struct regulator_init_data
return NULL;
}
+static struct i2c_client *act8865_i2c_client;
+static void act8865_power_off(void)
+{
+ struct act8865 *act8865;
+
+ act8865 = i2c_get_clientdata(act8865_i2c_client);
+ regmap_write(act8865->regmap, act8865->off_reg, act8865->off_mask);
+ while (1);
+}
+
static int act8865_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
{
@@ -285,6 +300,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
int i, ret, num_regulators;
struct act8865 *act8865;
unsigned long type;
+ int off_reg, off_mask;
pdata = dev_get_platdata(dev);
@@ -304,10 +320,14 @@ static int act8865_pmic_probe(struct i2c_client *client,
case ACT8846:
regulators = act8846_regulators;
num_regulators = ARRAY_SIZE(act8846_regulators);
+ off_reg = ACT8846_GLB_OFF_CTRL;
+ off_mask = ACT8846_OFF_SYSMASK;
break;
case ACT8865:
regulators = act8865_regulators;
num_regulators = ARRAY_SIZE(act8865_regulators);
+ off_reg = ACT8865_SYS_CTRL;
+ off_mask = ACT8865_MSTROFF;
break;
default:
dev_err(dev, "invalid device id %lu\n", type);
@@ -345,6 +365,15 @@ static int act8865_pmic_probe(struct i2c_client *client,
return ret;
}
+ if (dev->of_node &&
+ of_property_read_bool(dev->of_node,
+ "active-semi,system-power-controller")) {
+ act8865_i2c_client = client;
+ act8865->off_reg = off_reg;
+ act8865->off_mask = off_mask;
+ pm_power_off = act8865_power_off;
+ }
+
/* Finally register devices */
for (i = 0; i < num_regulators; i++) {
const struct regulator_desc *desc = [i];
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 linux-next] udf: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h
Cc: Jan Kara
Signed-off-by: Fabian Frederick
---
fs/udf/udftime.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/udf/udftime.c b/fs/udf/udftime.c
index 1f11483..77c331f 100644
--- a/fs/udf/udftime.c
+++ b/fs/udf/udftime.c
@@ -81,8 +81,6 @@ static time_t year_seconds[MAX_YEAR_SECONDS] = {
/*2038*/ SPY(68, 17, 0)
};
-extern struct timezone sys_tz;
-
#define SECS_PER_HOUR (60 * 60)
#define SECS_PER_DAY (SECS_PER_HOUR * 24)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 linux-next] fs/ncpfs/dir.c: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h
Cc: Petr Vandrovec
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/ncpfs/dir.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
index 08b8ea8..1beb761 100644
--- a/fs/ncpfs/dir.c
+++ b/fs/ncpfs/dir.c
@@ -1182,9 +1182,6 @@ static int day_n[] =
{0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 0, 0, 0, 0};
/* Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec */
-
-extern struct timezone sys_tz;
-
static int utc2local(int time)
{
return time - sys_tz.tz_minuteswest * 60;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 linux-next] fs/affs: remove redundant sys_tz declarations
sys_tz is already declared in include/linux/time.h
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/affs/amigaffs.c | 2 --
fs/affs/inode.c| 1 -
fs/affs/super.c| 2 --
3 files changed, 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c
index 406b298..abc8539 100644
--- a/fs/affs/amigaffs.c
+++ b/fs/affs/amigaffs.c
@@ -10,8 +10,6 @@
#include "affs.h"
-extern struct timezone sys_tz;
-
static char ErrorBuffer[256];
/*
diff --git a/fs/affs/inode.c b/fs/affs/inode.c
index bec2d1a..31c2e37 100644
--- a/fs/affs/inode.c
+++ b/fs/affs/inode.c
@@ -14,7 +14,6 @@
#include "affs.h"
extern const struct inode_operations affs_symlink_inode_operations;
-extern struct timezone sys_tz;
struct inode *affs_iget(struct super_block *sb, unsigned long ino)
{
diff --git a/fs/affs/super.c b/fs/affs/super.c
index 51f1a95..314b3ff 100644
--- a/fs/affs/super.c
+++ b/fs/affs/super.c
@@ -20,8 +20,6 @@
#include
#include "affs.h"
-extern struct timezone sys_tz;
-
static int affs_statfs(struct dentry *dentry, struct kstatfs *buf);
static int affs_remount (struct super_block *sb, int *flags, char *data);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/slab: use IS_ENABLED() instead of ZONE_DMA_FLAG
On Sat, 27 Sep 2014, Paul Bolle wrote: > Do your comments require the patch to be redone (partially or entirely)? > In that case someone else should probably take it and improve it, as I > hardly understand the issues you raise. Or is the patch already queued > somewhere, with Cristoph's Ack attached? Please respin the patch taking Johannes feedback into consideration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Remove GFP_DMA and GFP_DMA32 from flags before passing it into kmalloc.
On 27 Sep 2014, at 16:09, Miles MH Chen wrote: > Signed-off-by: Min-Hua Chen > --- > arch/arm64/mm/dma-mapping.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c > index 4164c5a..273cf6d 100644 > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c > @@ -103,7 +103,8 @@ static void *__dma_alloc_noncoherent(struct device *dev, > size_t size, > ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs); > if (!ptr) > goto no_mem; > -map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA); > +map = kmalloc(sizeof(struct page *) << order, > +flags & ~(GFP_DMA | GFP_DMA32)); Do you have an explanation on why this is needed (and such explanation should also be included in the commit log)? We don’t use ZONE_DMA32 on arm64 (we did initially but it was for the wrong reasons). Thanks, Catalin-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: android: sw_sync: fixed a coding style issues
On Fri, Sep 26, 2014 at 12:11:56AM +0100, Mike Roocroft wrote:
you forgot to write the commit message and also mention there what kind of
warning you have fixed.
thanks
sudip
> Signed-off-by: Mike Roocroft
> ---
> drivers/staging/android/sw_sync.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/android/sw_sync.c
> b/drivers/staging/android/sw_sync.c
> index a76db3f..863d4b1 100644
> --- a/drivers/staging/android/sw_sync.c
> +++ b/drivers/staging/android/sw_sync.c
> @@ -97,6 +97,7 @@ static void sw_sync_pt_value_str(struct sync_pt *sync_pt,
> char *str, int size)
> {
> struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
> +
> snprintf(str, size, "%d", pt->value);
> }
>
> @@ -156,6 +157,7 @@ static int sw_sync_open(struct inode *inode, struct file
> *file)
> static int sw_sync_release(struct inode *inode, struct file *file)
> {
> struct sw_sync_timeline *obj = file->private_data;
> +
> sync_timeline_destroy(>obj);
> return 0;
> }
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Help Out and Issues with the Community
On Fri, Sep 26, 2014 at 03:26:54PM -0400, nick wrote: > > > On 14-09-25 10:20 PM, David Lang wrote: > >> Hello Developers, > >> For the last week or two I have been trying to contact people for help > >> and/or learning in order to help out > >> more. I am unable to get any emails back from them, I am assuming this is > >> due to my issues with the community. > >> If someone would like to explain a way to either resolve this or help me > >> me learn the community rules and how > >> to do things the right way that would be great. > > > > Going over the archives a bit, it looks like there are a lot of people who > > have taken the time to reply to you. > > > > It looks like you are falling into a common trap of looking at particular > > bug reports or FIXME items and trying to silence them. But you are doing so > > without understanding the code or functionality being provided. As a > > result, you are doing exactly what people are afraid that static checking > > will result in, a local fix to silence the checker that doesn't actually > > fix the overall problem. > > > > In addition to the various places you've already been pointed at, I'd > > suggest that you look at the kernel janitors pages and mailing list > > (http://kernelnewbies.org/KernelJanitors), the linux-kernel list has a huge > > membership and a high volume of traffic, so learning as you work here is > > not always the best thing to do. > > > > David Lang > David, > That wasn't my idea, it was to help out and ask questions if I don't > understand something first. I will start with kernel janitors and go from > their. > Thanks Nick hey nick, allow me to remind you that few days back you were in the kernelnewbies, and you have tried to send your patches there also. And newbies like us were able to find problems with your patch. if i remember correctly one patch was corrupt , one patch didnt even apply to linux-next, in another patch you could not explain why you have removed an error message. thanks sudip > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] checkkconfigsymbols.sh: reimplementation in python
The scripts/checkkconfigsymbols.sh script searches Kconfig features
in the source code that are not defined in Kconfig. Such identifiers
always evaluate to false and are the source of various kinds of bugs.
However, the shell script is slow and it does not detect such broken
references in Kbuild and Kconfig files (e.g., ``depends on UNDEFINED´´).
Furthermore, it generates false positives. The script is also hard to
read and understand, and is thereby difficult to maintain.
This patch replaces the shell script with an implementation in Python,
which:
(a) detects the same bugs, but does not report previous false positives
(b) additionally detects broken references in Kconfig and all
non-Kconfig files, such as Kbuild, .[cSh], .txt, .sh, defconfig, etc.
(c) is up to 75 times faster than the shell script
(d) only checks files under version control
The new script reduces the runtime on my machine (i7-2620M, 8GB RAM, SSD)
from 3m47s to 0m3s, and reports 938 broken references in Linux v3.17-rc1;
419 additional reports of which 16 are located in Kconfig files,
287 in defconfigs, 63 in ./Documentation, 1 in Kbuild.
Moreover, we intentionally include references in comments, which have been
ignored until now. Such comments may be leftovers of features that have
been removed or renamed in Kconfig (e.g., ``#endif /* CONFIG_MPC52xx */´´).
These references can be misleading and should be removed or replaced.
Note that the output format changed from (file list feature) to
(feature file list) as it simplifies the detection of the Kconfig
feature for long file lists.
Signed-off-by: Valentin Rothberg
Signed-off-by: Stefan Hengelein
---
Changelog:
v2: Fix of regular expressions
v3: Changelog replacement, and add changes of v2
v4: Based on comments from Paul Bolle
- Inclusion of all non-Kconfig files, such as .txt, .sh, etc.
- Changes of regular expressions
- Increases additional reports from 49 to 229 compared to v3
- Change of output format from (file list feature) to
(feature file list)·
v5: Only analyze files under version control ('git ls-files')
v6: Cover features with numbers and small letters (e.g., 4xx)
---
scripts/checkkconfigsymbols.py | 142 +
scripts/checkkconfigsymbols.sh | 59 -
2 files changed, 142 insertions(+), 59 deletions(-)
create mode 100644 scripts/checkkconfigsymbols.py
delete mode 100755 scripts/checkkconfigsymbols.sh
diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
new file mode 100644
index 000..f944089
--- /dev/null
+++ b/scripts/checkkconfigsymbols.py
@@ -0,0 +1,142 @@
+#!/usr/bin/env python
+
+"""Find Kconfig identifieres that are referenced but not defined."""
+
+# Copyright (C) 2014 Valentin Rothberg
+# Copyright (C) 2014 Stefan Hengelein
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+
+
+import os
+import re
+from subprocess import Popen, PIPE, STDOUT
+
+# REGEX EXPRESSIONS
+OPERATORS = r"&|\(|\)|\||\!"
+FEATURE = r"\w*[A-Z]{1}\w*"
+CONFIG_DEF = r"^\s*(?:menu){,1}config\s+(" + FEATURE + r")\s*"
+EXPR = r"(?:" + OPERATORS + r"|\s|" + FEATURE + r")+"
+STMT = r"^\s*(?:if|select|depends\s+on)\s+" + EXPR
+
+# REGEX OBJECTS
+REGEX_FILE_KCONFIG = re.compile(r".*Kconfig[\.\w+\-]*$")
+REGEX_FEATURE = re.compile(r"(" + FEATURE + r")")
+REGEX_SOURCE_FEATURE = re.compile(r"(?:D|\W|\b)+CONFIG_(" + FEATURE + r")")
+REGEX_KCONFIG_DEF = re.compile(CONFIG_DEF)
+REGEX_KCONFIG_EXPR = re.compile(EXPR)
+REGEX_KCONFIG_STMT = re.compile(STMT)
+REGEX_KCONFIG_HELP = re.compile(r"^\s+(help|---help---)\s*$")
+REGEX_FILTER_FEATURES = re.compile(r"[A-Za-z0-9]$")
+
+
+def main():
+"""Main function of this module."""
+source_files = []
+kconfig_files = []
+defined_features = set()
+referenced_features = dict()
+
+# use 'git ls-files' to get the worklist
+pop = Popen("git ls-files", stdout=PIPE, stderr=STDOUT, shell=True)
+(stdout, _) = pop.communicate() # wait until finished
+if len(stdout) > 0 and stdout[-1] == "\n":
+stdout = stdout[:-1]
+
+for gitfile in stdout.rsplit("\n"):
+if ".git" in gitfile or "ChangeLog" in gitfile or \
+os.path.isdir(gitfile):
+continue
+if REGEX_FILE_KCONFIG.match(gitfile):
+kconfig_files.append(gitfile)
+else:
+# All non-Kconfig files are checked for consistency
+source_files.append(gitfile)
+
+for sfile in source_files:
+parse_source_file(sfile, referenced_features)
+
+for kfile in kconfig_files:
Re: [PATCH v3 0/5] enhance DMA CMA on x86
On 04/15/2014 09:08 AM, Akinobu Mita wrote: > This patch set enhances the DMA Contiguous Memory Allocator on x86. > > Currently the DMA CMA is only supported with pci-nommu dma_map_ops > and furthermore it can't be enabled on x86_64. But I would like to > allocate big contiguous memory with dma_alloc_coherent() and tell it > to the device that requires it, regardless of which dma mapping > implementation is actually used in the system. > > So this makes it work with swiotlb and intel-iommu dma_map_ops, too. > And this also extends "cma=" kernel parameter to specify placement > constraint by the physical address range of memory allocations. For > example, CMA allocates memory below 4GB by "cma=64M@0-4G", it is > required for the devices only supporting 32-bit addressing on 64-bit > systems without iommu. > > * Changes from v2 > - Rebased on current Linus tree > - Add Acked-by line > - Fix gfp flags check for __GFP_ATOMIC, reported by Marek Szyprowski > - Avoid CMA area on highmem with cma= option, reported by Marek Szyprowski > > * Changes from v1 > - fix dma_alloc_coherent() with __GFP_ZERO > - add placement specifier for "cma=" kernel parameter > > Akinobu Mita (5): > x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled > x86: enable DMA CMA with swiotlb > intel-iommu: integrate DMA CMA > memblock: introduce memblock_alloc_range() > cma: add placement specifier for "cma=" kernel parameter This patchset breaks every x86 iommu configuration when CONFIG_DMA_CMA is on, which is the base configuration for Ubuntu x86 and amd64 distro kernels. Granted, the patchset leveraged existing code from the nommu configuration, but that base (ie., calling dma_alloc_from_contiguous() in dma_generic_alloc_config()) was an ill-conceived test configuration designed to allow ARM developers to validate the CMA allocator on x86 boxen and KVM guests, not as a general-purpose replacement for the existing page allocator. The test code should have had a separate CONFIG_ knob. What this patchset does is restrict all iommu configurations which can map all of system memory to one _very_ small physical region, thus disabling the whole point of an iommu. Now I know why my GPU is causing paging to disk! And why my RAID controller stalls for ages when I do a git log at the same time as a kernel build! And the apparent goal of this patchset is to enable DMA allocation below 4GB, which is already supported in the existing page allocator with the GFP_DMA32 flag?! Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tip:perf/core] perf callchain: Move some parser functions to callchain.c
Hi Namhyung, 2014-09-27 9:26 GMT+02:00 tip-bot for Namhyung Kim : > Commit-ID: f7f084f4d3c29b0f9877a32fc6e2feacd47695b9 > Gitweb: http://git.kernel.org/tip/f7f084f4d3c29b0f9877a32fc6e2feacd47695b9 > Author: Namhyung Kim > AuthorDate: Tue, 23 Sep 2014 10:01:42 +0900 > Committer: Arnaldo Carvalho de Melo > CommitDate: Fri, 26 Sep 2014 12:41:57 -0300 > > perf callchain: Move some parser functions to callchain.c Please Cc me on callchain stuff. I may not be very verbose but I still keep an eye on evolutions there. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page allocator bug in 3.16?
On 09/26/2014 11:12 AM, Leann Ogasawara wrote: > On Fri, Sep 26, 2014 at 7:10 AM, Peter Hurley > wrote: >> [ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ] >> >> On 09/26/2014 08:40 AM, Rik van Riel wrote: >>> On 09/26/2014 08:28 AM, Rob Clark wrote: On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom wrote: > On 09/26/2014 12:40 PM, Chuck Ebbert wrote: >> On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom >> wrote: >> >>> On 09/26/2014 01:52 AM, Peter Hurley wrote: On 09/25/2014 03:35 PM, Chuck Ebbert wrote: > There are six ttm patches queued for 3.16.4: > > drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch > > >>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch > drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch > > >>> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch > drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch > drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch > >>> Thanks for info, Chuck. Unfortunately, none of these fix TTM dma allocation doing CMA dma allocation, which is the root problem. Regards, Peter Hurley >>> The problem is not really in TTM but in CMA, There was a guy >>> offering to fix this in the CMA code but I guess he didn't >>> probably because he didn't receive any feedback. >>> >> Yeah, the "solution" to this problem seems to be "don't enable >> CMA on x86". Maybe it should even be disabled in the config >> system. > Or, as previously suggested, don't use CMA for order 0 (single > page) allocations On devices that actually need CMA pools to arrange for memory to be in certain ranges, I think you probably do want to have order 0 pages come from the CMA pool. Seems like disabling CMA on x86 (where it should be unneeded) is the better way, IMO >>> >>> CMA has its uses on x86. For example, CMA is used to allocate 1GB huge >>> pages. >>> >>> There may also be people with devices that do not scatter-gather, and >>> need a large physically contiguous buffer, though there should be >>> relatively few of those on x86. >>> >>> I suspect it makes most sense to do DMA allocations up to PAGE_ORDER >>> through the normal allocator on x86, and only invoking CMA for larger >>> allocations. >> >> The code that uses CMA to satisfy DMA allocations on x86 is >> specific to the x86 arch and was added in 2011 as a means of _testing_ >> CMA in KVM: >> >> commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 >> Author: Marek Szyprowski >> Date: Thu Dec 29 13:09:51 2011 +0100 >> >> X86: integrate CMA with DMA-mapping subsystem >> >> This patch adds support for CMA to dma-mapping subsystem for x86 >> architecture that uses common pci-dma/pci-nommu implementation. This >> allows to test CMA on KVM/QEMU and a lot of common x86 boxes. >> >> Signed-off-by: Marek Szyprowski >> Signed-off-by: Kyungmin Park >> CC: Michal Nazarewicz >> Acked-by: Arnd Bergmann >> >> (no x86 maintainer acks?). >> >> Unfortunately, this code is enabled whenever CMA is enabled, rather >> than as a separate test configuration. >> >> So, while enabling CMA may have other purposes on x86, using it for >> x86 swiotlb and nommu dma allocations is not one of the them. >> >> And Ubuntu should not be enabling CONFIG_DMA_CMA for their i386 >> and amd64 configurations, as this is trying to drive _all_ dma mapping >> allocations through a _very_ small window (which is killing GPU >> performance). > > Thanks for the note Peter. We do have this disabled for our upcoming > Ubuntu 14.10 release. It is however still enabled in the previous 14.04 > release. We have been tracking this in > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362261 but users > able to reproduce performance impacts in 14.10 were unable to reproduce > in 14.04 which is why we hadn't yet disabled it there. Leann, Thanks for that important clue. The missing piece specific to 3.16+ is these patches which impact every iommu config: Akinobu Mita (5): x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled x86: enable DMA CMA with swiotlb intel-iommu: integrate DMA CMA memblock: introduce memblock_alloc_range() cma: add placement specifier for "cma=" kernel parameter These patches take the pre-existing nommu CMA test configuration and hook it up to all the x86 iommus, effectively reducing 10GB of DMA-able memory to 64MB, and hooks it all up to an allocator that's not nearly as effective as the page allocator. All to enable DMA allocation below 4GB which is already supported with the GFP_DMA32 flag to dma_alloc_coherent(). Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
[GIT PULL] late cgroup fixes for v3.17-rc6
Hello, Linus.
This is quite late but these need to be backported anyway. This is
the fix for a long-standing cpuset bug which existed from 2009.
cpuset makes use of PF_SPREAD_{PAGE|SLAB} flags to modify the task's
memory allocation behavior according to the settings of the cpuset it
belongs to; unfortunately, when those flags have to be changed, cpuset
did so directly even whlie the target task is running, which is
obviously racy as task->flags may be modified by the task itself at
any time. This obscure bug manifested as corrupt PF_USED_MATH flag
leading to a weird crash.
The bug is fixed by moving the flag to task->atomic_flags. The first
two are prepatory ones to help defining atomic_flags accessors and the
third one is the actual fix.
Thanks.
The following changes since commit eb4aec84d6bdf98d00cedb41c18000f7a31e648a:
cgroup: fix unbalanced locking (2014-09-18 12:32:52 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.17-fixes
for you to fetch changes up to 2ad654bc5e2b211e92f66da1d819e47d79a866f0:
cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags (2014-09-24
22:16:06 -0400)
Zefan Li (3):
sched: fix confusing PFA_NO_NEW_PRIVS constant
sched: add macros to define bitops for task atomic flags
cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags
Documentation/cgroups/cpusets.txt | 6 +++---
include/linux/cpuset.h| 4 ++--
include/linux/sched.h | 38 +-
kernel/cpuset.c | 9 +
mm/slab.c | 4 ++--
scripts/tags.sh | 6 ++
6 files changed, 43 insertions(+), 24 deletions(-)
diff --git a/Documentation/cgroups/cpusets.txt
b/Documentation/cgroups/cpusets.txt
index 7740038..3c94ff3 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -345,14 +345,14 @@ the named feature on.
The implementation is simple.
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
-PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
+PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
joins that cpuset. The page allocation calls for the page cache
-is modified to perform an inline check for this PF_SPREAD_PAGE task
+is modified to perform an inline check for this PFA_SPREAD_PAGE task
flag, and if set, a call to a new routine cpuset_mem_spread_node()
returns the node to prefer for the allocation.
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
-PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
+PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
pages from the node returned by cpuset_mem_spread_node().
The cpuset_mem_spread_node() routine is also simple. It uses the
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index ade2390..6e39c9b 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -93,12 +93,12 @@ extern int cpuset_slab_spread_node(void);
static inline int cpuset_do_page_mem_spread(void)
{
- return current->flags & PF_SPREAD_PAGE;
+ return task_spread_page(current);
}
static inline int cpuset_do_slab_mem_spread(void)
{
- return current->flags & PF_SPREAD_SLAB;
+ return task_spread_slab(current);
}
extern int current_cpuset_is_being_rebound(void);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..7b1cafe 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1903,8 +1903,6 @@ extern void thread_group_cputime_adjusted(struct
task_struct *p, cputime_t *ut,
#define PF_KTHREAD 0x0020 /* I am a kernel thread */
#define PF_RANDOMIZE 0x0040 /* randomize virtual address space */
#define PF_SWAPWRITE 0x0080 /* Allowed to write to swap */
-#define PF_SPREAD_PAGE 0x0100 /* Spread page cache over cpuset */
-#define PF_SPREAD_SLAB 0x0200 /* Spread some slab caches over cpuset
*/
#define PF_NO_SETAFFINITY 0x0400 /* Userland is not allowed to meddle
with cpus_allowed */
#define PF_MCE_EARLY0x0800 /* Early kill for mce process policy */
#define PF_MUTEX_TESTER0x2000 /* Thread belongs to the rt
mutex tester */
@@ -1957,17 +1955,31 @@ static inline void memalloc_noio_restore(unsigned int
flags)
}
/* Per-process atomic flags. */
-#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
-
-static inline bool task_no_new_privs(struct task_struct *p)
-{
- return test_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
-}
-
-static inline void task_set_no_new_privs(struct task_struct *p)
-{
- set_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
-}
+#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
+#define PFA_SPREAD_PAGE 1 /* Spread page cache over
Re: [PATCH v2 1/3] drivers: of: add return value to of_reserved_mem_device_init (fixup)
Hi Marek, On Fri, Sep 26, 2014 at 3:44 AM, Marek Szyprowski wrote: > This patch adds missing return value to error paths. > > Signed-off-by: Marek Szyprowski I have also sent a similar fix: http://www.spinics.net/lists/devicetree/msg51127.html > --- > drivers/of/of_reserved_mem.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > index 7e7de03..e975156 100644 > --- a/drivers/of/of_reserved_mem.c > +++ b/drivers/of/of_reserved_mem.c > @@ -250,13 +250,13 @@ int of_reserved_mem_device_init(struct device *dev) > > np = of_parse_phandle(dev->of_node, "memory-region", 0); > if (!np) > - return; > + return -ENODEV; > > rmem = __find_rmem(np); > of_node_put(np); > > if (!rmem || !rmem->ops || !rmem->ops->device_init) > - return; > + return -ENIVAL; ENIVAL does not exist. I guess you meant EINVAL ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/7] ARM: sunxi: Introduce Allwinner A80 support
On Thu, Sep 25, 2014 at 9:25 PM, Maxime Ripard wrote: > On Wed, Sep 24, 2014 at 10:48:55PM +0800, Chen-Yu Tsai wrote: >> The Allwinner A80 is a new Cortex octo-core A7/A15 big.LITTLE SoC. >> While it's processor cores and interconnecting bus are new, it >> re-uses many peripherals found in earlier Allwinner SoCs. >> >> Signed-off-by: Chen-Yu Tsai >> --- >> arch/arm/mach-sunxi/Kconfig | 5 + >> arch/arm/mach-sunxi/sunxi.c | 9 + >> 2 files changed, 14 insertions(+) >> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig >> index 1aaa1e1..72f222b 100644 >> --- a/arch/arm/mach-sunxi/Kconfig >> +++ b/arch/arm/mach-sunxi/Kconfig >> @@ -42,4 +42,9 @@ config MACH_SUN8I >> select MFD_SUN6I_PRCM >> select RESET_CONTROLLER >> >> +config MACH_SUN9I >> + bool "Allwinner A80 (sun9i) SoCs support" > > With the new naming scheme, I wonder wether it makes sense to have the > A80 displayed here and in the machine definition. I expect anything that falls under sun9i to be compatible, or a trimmed down version. But that's just me. We know that Allwinner has released the A33, which should be compatible with the A23, sun8i. And the A83 has been announced, which looks like a trimmed down version of the A80. The next SoC should be arm64, and would not matter here. Kevin, Shuge, could you provide us with the codenames for the A33 and A83, and what earlier SoC they are based on? Thanks ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
