Re: [PATCH 2/2] android: add sync_fence_create_dma
Hey, On 15-08-14 08:46, Greg Kroah-Hartman wrote: > On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote: >> This allows users of dma fences to create a android fence. > > Who is going to use these functions? I need an in-kernel user before I > can add new api calls. So I found a in-kernel user and PATCH 1/2 fixes a mem-leak with android out of tree drivers, and android's in-kernel sw-sync. Will you apply these patches? ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 18:37, schrieb Stephen Warren: Of course, there are probably cases where we could/should add some more phandles/... and likewise cases where we shouldn't. That's why detailed research is needed. Just because I'm curious, I wonder how this research does or shoud look like. Defered probes did come to light with 3.4, that was more than 2 years ago. Ok, most people (like me) just noticed it during the last months when they switched to DT and have run into a problem (the deferred probe mechanism is an error-message killer), but some must have seen it already 2 years ago. And I wonder how the ACPI world solves that problem. My guess would be hardcoded stuff in the firmware-blob (BIOS), just like it happened with board files, but I've never seen BIOS code and my knowledge about ACPI is almost zero. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] x86, fpu: copy_process's FPU paths cleanups
* H. Peter Anvin wrote: > Oleg, this is unacceptable. > > Last week was Kernel Summit and that was right on the heels of > a merge window. We are backlogged like crazy and being rude > doesn't help one iota. Also, the previous set of patches was under active review by Linus with objections, we very much wanted to wait for all that to conclude one way or another. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] x86: Speed up ioremap operations
* Andrew Morton wrote: > On Wed, 27 Aug 2014 17:59:27 -0500 Mike Travis wrote: > > > > > We have a large university system in the UK that is experiencing > > very long delays modprobing the driver for a specific I/O device. > > The delay is from 8-10 minutes per device and there are 31 devices > > in the system. This 4 to 5 hour delay in starting up those I/O > > devices is very much a burden on the customer. > > That's nuts. Agreed, and I'd suggest marking this for -stable, once it's all settled and tested. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC] x86 early_ioremap: increase FIX_BTMAPS_SLOTS to 8
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Dave Young > Sent: Tuesday, August 26, 2014 5:07 PM > > 3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the > bottom line of screen. > > Bisected, the first bad commit is below: > commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 > Author: Lv Zheng > Date: Fri Apr 4 12:38:57 2014 +0800 > > ACPICA: Tables: Fix table checksums verification before installation. > > > I did some debugging by enabling both serial and efi earlyprintk, below is > some debug dmesg, seems early_ioremap fails in scroll up function due to > no free slot, see below dmesg output: > > [snip] > [0.00] RAMDISK: [mem 0x3e1b-0x3e982fff] > [0.00] ACPI: Early table checksum verification disabled > [0.00] ACPI: RSDP 0xDB752000 24 (v02 HPQOEM) > [0.00] ACPI: XSDT 0xDB752088 8C (v01 HPQOEM SLIC-WKS > 01072009 AMI 00010013) > [0.00] ACPI: FACP 0xDB759590 00010C (v05 HPQOEM SLIC-WKS > 01072009 AMI 00010013) > [0.00] [ cut here ] > [0.00] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 > __early_ioremap+0x90/0x1c4() > [0.00] __early_ioremap(ed00c800, 0c80) not found slot > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-rc1+ #204 > [0.00] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS > J61 v03.15 05/09/2013 > [0.00] 8173b970 814bb919 > 8173b9b8 > [0.00] 8173b9a8 810638c9 8184ee81 > ff538000 > [0.00] 0c80 0003 0c80 > 8173ba08 > [0.00] Call Trace: > [0.00] [] dump_stack+0x4e/0x7a > [0.00] [] warn_slowpath_common+0x75/0x8e > [0.00] [] ? __early_ioremap+0x90/0x1c4 > [0.00] [] warn_slowpath_fmt+0x47/0x49 > [0.00] [] __early_ioremap+0x90/0x1c4 > [0.00] [] ? sprintf+0x46/0x48 > [0.00] [] early_ioremap+0x13/0x15 > [0.00] [] early_efi_map+0x24/0x26 > [0.00] [] early_efi_scroll_up+0x6d/0xc0 > [0.00] [] early_efi_write+0x1b0/0x214 > [0.00] [] > call_console_drivers.constprop.21+0x73/0x7e > [0.00] [] console_unlock+0x151/0x3b2 > [0.00] [] ? vprintk_emit+0x49f/0x532 > [0.00] [] vprintk_emit+0x521/0x532 > [0.00] [] ? console_unlock+0x383/0x3b2 > [0.00] [] printk+0x4f/0x51 > [0.00] [] acpi_os_vprintf+0x2b/0x2d > [0.00] [] acpi_os_printf+0x43/0x45 > [0.00] [] acpi_info+0x5c/0x63 > [0.00] [] ? __acpi_map_table+0x13/0x18 > [0.00] [] ? acpi_os_map_iomem+0x21/0x147 > [0.00] [] acpi_tb_print_table_header+0x177/0x186 > [0.00] [] > acpi_tb_install_table_with_override+0x4b/0x62 > [0.00] [] acpi_tb_install_standard_table+0xd9/0x215 > [0.00] [] ? early_ioremap+0x13/0x15 > [0.00] [] ? __acpi_map_table+0x13/0x18 > [0.00] [] acpi_tb_parse_root_table+0x16e/0x1b4 > [0.00] [] acpi_initialize_tables+0x57/0x59 > [0.00] [] acpi_table_init+0x50/0xce > [0.00] [] acpi_boot_table_init+0x1e/0x85 > [0.00] [] setup_arch+0x9b7/0xcc4 > [0.00] [] start_kernel+0x94/0x42d > [0.00] [] ? early_idt_handlers+0x120/0x120 > [0.00] [] x86_64_start_reservations+0x2a/0x2c > [0.00] [] x86_64_start_kernel+0xf3/0x100 > [0.00] ---[ end trace 48732c7db414b8fe ]--- > [0.00] [ cut here ] > [0.00] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 > __early_ioremap+0x90/0x1c4() > [0.00] __early_ioremap(ed00c800, 0c80) not found slot > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper Tainted: GW > 3.17.0-rc1+ #204 > [0.00] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS > J61 v03.15 05/09/2013 > [0.00] 8173b970 814bb919 > 8173b9b8 > [0.00] 8173b9a8 810638c9 8184ee81 > ff538000 > [0.00] 0c80 0003 0c80 > 8173ba08 > [0.00] Call Trace: > [0.00] [] dump_stack+0x4e/0x7a > [0.00] [] warn_slowpath_common+0x75/0x8e > [0.00] [] ? __early_ioremap+0x90/0x1c4 > [0.00] [] warn_slowpath_fmt+0x47/0x49 > [0.00] [] __early_ioremap+0x90/0x1c4 > [0.00] [] early_ioremap+0x13/0x15 > [0.00] [] early_efi_map+0x24/0x26 > [0.00] [] early_efi_scroll_up+0x6d/0xc0 > [0.00] [] early_efi_write+0x1b0/0x214 > [0.00] [] > call_console_drivers.constprop.21+0x73/0x7e > [0.00] [] console_unlock+0x1fa/0x3b2 > [0.00] [] vprintk_emit+0x521/0x532 > [0.00] [] ? co
Re: [PATCH v5] mm: softdirty: enable write notifications on VMAs after VM_SOFTDIRTY cleared
On Wed, Aug 27, 2014 at 04:12:43PM -0700, Hugh Dickins wrote: > > > > > > Weak argument to me. > > Yes. However rarely it's modified, we don't want any chance of it > corrupting another flag. > > VM_SOFTDIRTY is special in the sense that it's maintained in a very > different way from the other VM_flags. If we had a little alignment > padding space somewhere in struct vm_area_struct, I think I'd jump at > Kirill's suggestion to move it out of vm_flags and into a new field: > that would remove some other special casing, like the vma merge issue. > > But I don't think we have such padding space, and we'd prefer not to > bloat struct vm_area_struct for it; so maybe it should stay for now. > Besides, with Peter's patch, we're also talking about the locking on > modifications to vm_page_prot, aren't we? I think so. > > > What about walk through vmas twice: first with down_write() to modify > > > vm_flags and vm_page_prot, then downgrade_write() and do > > > walk_page_range() on every vma? > > > > I still it's undeeded, > > Yes, so long as nothing else is doing the same. > No bug yet, that we can see, but a bug in waiting. :-) > > > but for sure using write-lock/downgrade won't hurt, > > so no argues from my side. > > Yes, Kirill's two-stage suggestion seems the best: > > down_write > quickly scan vmas clearing VM_SOFT_DIRTY and updating vm_page_prot > downgrade_write (or up_write, down_read?) > slowly walk page tables write protecting and clearing soft-dirty on ptes > up_read > > But please don't mistake me for someone who has a good grasp of > soft-dirty: I don't. Thanks for sharing opinion, Hugh! (And thanks for second email about vma-flags) So lets move it to Kirill's way, otherwise indeed one day it might end up in a bug which for sure will not be easy to catch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk
Hi Hannes,
I tried to remove duplicated decoder of SCSI command, but the
output format of it in constants.c is different from it in traceevents.
I have two questions for it.
(Ex1)
traceevents: TEST_UNIT_READY
constants: Test Unit Ready
=> Which of "XXX_YYY_ZZZ" and "Xxx Yyy Zzz" should the kernel output
strings? This difference comes from difference of implementation.
The decoder in traceevents are using macro. So, it cannot define
separated words. On the other hand, the decoder in constants are using
constant string array table. So, it can define separated words.
(Ex2)
traceevents: (nothing)
constants: Set limits(12)
=> Should we merge those decoder?
I understand we use the decoder of constants, but we need to solve
these problems. Would you give me your comments?
Thanks,
Yoshihiro YUNOMAE
(2014/08/28 10:40), Yoshihiro YUNOMAE wrote:
(2014/08/27 23:16), Hannes Reinecke wrote:
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:
Previous printk messages of SCSI command can be mixed into other printk
messages because multiple printk messages are output for it. To avoid
the
problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local
buffer.
But using local buffers can induce stack overflow, so we want to solve
the
problem without local buffer if possible.
trace_seq_printf can add log messages without local buffer, so we use
it.
Note:
We don't need constans.c any more.
(*1)
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging
- Result examples
(printk)
sd 2:0:0:0: [sda] CDB: Read(10)
scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10))
Signed-off-by: Yoshihiro YUNOMAE
Cc: Hannes Reinecke
Cc: Doug Gilbert
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Hidehiro Kawai
Cc: Masami Hiramatsu
---
drivers/scsi/Makefile |2
drivers/scsi/constants.c| 425
---
drivers/scsi/scsi_trace.c | 408
+
include/scsi/scsi.h |8 +
include/trace/events/scsi.h | 45 +
5 files changed, 461 insertions(+), 427 deletions(-)
delete mode 100644 drivers/scsi/constants.c
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..c56f692 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
# This goes last, so that "real" scsi devices probe earlier
obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o
-scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o constants.o \
+scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o \
scsicam.o scsi_error.o scsi_lib.o
scsi_mod-$(CONFIG_SCSI_DMA)+= scsi_lib_dma.o
scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
deleted file mode 100644
index ce9ceb8..000
--- a/drivers/scsi/constants.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * ASCII values for a number of symbolic constants, printing functions,
- * etc.
- * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422)
- * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002)
- * by D. Gilbert and aeb (20020609)
- * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-/* Commands with service actions that change the command name */
-#define SERVICE_ACTION_IN_12 0xab
-#define SERVICE_ACTION_OUT_12 0xa9
-#define SERVICE_ACTION_BIDIRECTIONAL 0x9d
-#define SERVICE_ACTION_IN_16 0x9e
-#define SERVICE_ACTION_OUT_16 0x9f
-#define THIRD_PARTY_COPY_OUT 0x83
-#define THIRD_PARTY_COPY_IN 0x84
-
-
-
-#ifdef CONFIG_SCSI_CONSTANTS
-static const char * cdb_byte0_names[] = {
-/* 00-03 */ "Test Unit Ready", "Rezero Unit/Rewind", NULL, "Request
Sense",
-/* 04-07 */ "Format Unit/Medium", "Read Block Limits", NULL,
-"Reassign Blocks",
-/* 08-0d */ "Read(6)", NULL, "Write(6)", "Seek(6)", NULL, NULL,
-/* 0e-12 */ NULL, "Read Reverse", "Write Filemarks", "Space",
"Inquiry",
-/* 13-16 */ "Verify(6)", "Recover Buffered Data", "Mode Select(6)",
-"Reserve(6)",
-/* 17-1a */ "Release(6)", "Copy", "Erase", "Mode Sense(6)",
-/* 1b-1d */ "Start/Stop Unit", "Receive Diagnostic", "Send Diagnostic",
-/* 1e-1f */ "Prevent/Allow Medium Removal", NULL,
-/* 20-22 */ NULL, NULL, NULL,
-/* 23-28 */ "Read Format Capacities", "Set Window",
-"Read Capacity(10)", NULL, NULL, "Read(10)",
-/* 29-2d */ "Read Generation", "Write(10)", "Seek(10)", "Erase(10)",
-"Read updated block",
-/* 2e-31 */ "Write Verify(10)", "Verify(10)", "Search High", "Search
Equal",
-/* 32-34 */ "Search Low", "Set Limits", "Prefetch/Read Position",
-/* 35-37 */ "Synchronize Cache(10)", "Lock/Unlock Cache(10)",
-"Read Defect Data(10)",
-/* 38-3c */ "Medium Scan", "Compare", "Copy Verify", "Write Buffer",
-"Read Buffer",
-/* 3d-3f */ "Update Block", "Read Long(10)", "Write
Re: [PATCH 3/3] cpufreq: cpu0: Convert pr_ to dev_ as struct device is available
On Thu, Aug 28, 2014 at 12:00:12AM -0700, Pramod Gurav wrote:
> CC: Shawn Guo
> CC: "Rafael J. Wysocki"
> CC: Viresh Kumar
> Signed-off-by: Pramod Gurav
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 0652cea..8f0b02f 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -126,7 +126,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> np = of_node_get(cpu_dev->of_node);
> if (!np) {
> - pr_err("failed to find cpu0 node\n");
> + dev_err(cpu_dev, "failed to find cpu0 node\n");
There are more pr_* calls in the driver. Since you do not get rid of
all of them anyway, and pr_fmt(fmt) definition in the file also gives
good context of the messages, I'm not fond of the change.
Shawn
> return -ENOENT;
> }
>
> @@ -141,14 +141,14 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> ret = -EPROBE_DEFER;
> goto out_put_node;
> }
> - pr_warn("failed to get cpu0 regulator: %ld\n",
> + dev_warn(cpu_dev, "failed to get cpu0 regulator: %ld\n",
> PTR_ERR(cpu_reg));
> }
>
> cpu_clk = clk_get(cpu_dev, NULL);
> if (IS_ERR(cpu_clk)) {
> ret = PTR_ERR(cpu_clk);
> - pr_err("failed to get cpu0 clock: %d\n", ret);
> + dev_err(cpu_dev, "failed to get cpu0 clock: %d\n", ret);
> goto out_put_reg;
> }
>
> @@ -157,7 +157,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> if (ret) {
> - pr_err("failed to init cpufreq table: %d\n", ret);
> + dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> goto out_put_clk;
> }
>
> @@ -193,7 +193,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
>
> ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
> if (ret) {
> - pr_err("failed register driver: %d\n", ret);
> + dev_err(cpu_dev, "failed register driver: %d\n", ret);
> goto out_free_table;
> }
>
> @@ -204,7 +204,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> if (of_find_property(np, "#cooling-cells", NULL)) {
> cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
> if (IS_ERR(cdev))
> - pr_err("running cpufreq without cooling device: %ld\n",
> + dev_err(cpu_dev, "running cpufreq without cooling
> device: %ld\n",
> PTR_ERR(cdev));
> }
>
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/6] acerhdf: Use bang-bang thermal governor
On Thu, Aug 28, 2014 at 09:17:52AM +0800, Zhang Rui wrote: > No, I can not apply the whole series. > I should take patch 3/6, and the others should goto Matthew Garrett' > tree. Or I can take them with Matthew' Acked-by. So put him on CC. Matt, can you please ack those? Btw, I've added the new maintainer too :-) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq: cpu0: Removes unnecessary IS_ERR check on clk
On Thu, Aug 28, 2014 at 12:00:11AM -0700, Pramod Gurav wrote: > This removes unnecessary IS_ERR check on clk when in failure path > as execution wont reach till there with clk being a err. > > CC: Shawn Guo > CC: "Rafael J. Wysocki" > CC: Viresh Kumar > Signed-off-by: Pramod Gurav Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] ksm: provide support to use deferrable timers for scanner thread
Sorry for holding you up, I'm slow. and needed to think about this more, On Wed, 20 Aug 2014, Chintan Pandya wrote: > KSM thread to scan pages is scheduled on definite timeout. That wakes up > CPU from idle state and hence may affect the power consumption. Provide > an optional support to use deferrable timer which suites low-power > use-cases. > > Typically, on our setup we observed, 10% less power consumption with some > use-cases in which CPU goes to power collapse frequently. For example, > playing audio on Soc which has HW based Audio encoder/decoder, CPU > remains idle for longer duration of time. This idle state will save > significant CPU power consumption if KSM don't wakes them up > periodically. > > Note that, deferrable timers won't be deferred if any CPU is active and > not in IDLE state. > > By default, deferrable timers is enabled. To disable deferrable timers, > $ echo 0 > /sys/kernel/mm/ksm/deferrable_timer I have now experimented. And, much as I wanted to eliminate the tunable, and just have deferrable timers on, I have come right back to your original position. I was impressed by how quiet ksmd goes when there's nothing much happening on the machine; but equally, disappointed in how slow it then is to fulfil the outstanding merge work. I agree with your original assessment, that not everybody will want deferrable timer, the way it is working at present. I expect that can be fixed, partly by doing more work on wakeup from a deferred timer, according to how long it has been deferred; and partly by not deferring on idle until two passes of the list have been completed. But that's easier said than done, and might turn out to defeat deferring the timer in too many cases: a balance to be found. I hope that you or I or another will find time to do that work soon, maybe before 3.18 but likely not; but I think the advantage of your option is too important to delay it further. Once we are satisfied with later improvements, then I would like to remove the tunable, or at least default it to on. But for now, the default should be off. It's unclear whether I should still worry about ksmd's gross activity, when the system is not actually idle, but all the activity is in non- mergeable processes. I'm ashamed of that hyper-activity, and still think that fixing it would be better than using a deferrable timer - deferring work (particularly intensive work of the kind which ksmd does) until the system is otherwise busy, is not necessarily a good strategy (too much work to do all at once). But fixing that might require ksm hooks in hot locations where nobody else would want them: I'm rather hoping we can strike a good enough balance with your deferrable timer, that nobody will need any better. So, with a few changes here and below, please add my Acked-by: Hugh Dickins to patches 1 and 2, and resend to akpm - thank you! Here (above), it's restore the text to V3's To enable deferrable timer, $ echo 1 > /sys/kernel/mm/ksm/deferrable_timer > > Signed-off-by: Chintan Pandya > Cc: Thomas Gleixner > Cc: John Stultz > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Hugh Dickins > --- > Changes: Sorry, I'm asking for a V4-->V5 reversing V3-->V4! > > V3-->V4: > - Use deferrable timers by default > > V2-->V3: > - Handled error case properly > - Corrected indentation in Documentation > - Fixed build failure > - Removed left over process_timeout() > V1-->V2: > - allowing only valid values to be updated as use_deferrable_timer > - using only 'deferrable' and not 'deferred' > - moved out schedule_timeout code for deferrable timer into timer.c > > > Documentation/vm/ksm.txt | 6 ++ > mm/ksm.c | 36 ++-- > 2 files changed, 40 insertions(+), 2 deletions(-) > > diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt > index f34a8ee..23e26c3 100644 > --- a/Documentation/vm/ksm.txt > +++ b/Documentation/vm/ksm.txt > @@ -87,6 +87,12 @@ pages_sharing- how many more sites are sharing them > i.e. how much saved > pages_unshared - how many pages unique but repeatedly checked for merging > pages_volatile - how many pages changing too fast to be placed in a tree > full_scans - how many times all mergeable areas have been scanned > +deferrable_timer - whether to use deferrable timers or not > + e.g. "echo 1 > /sys/kernel/mm/ksm/deferrable_timer" > + Default: 1 (means, we are using deferrable timers. Users > +might want to clear deferrable_timer option if they want > +ksm thread to wakeup CPU to carryout ksm activities thus > +loosing on battery while gaining on memory savings.) Please move this section to between the "sleep_millisecs" and "merge_across_nodes" descriptions, separated from each by a blank line: deferrable_timer - whether to save power by using a deferrable timer
Re: [PATCH v4 02/16] clk: tegra: Add library for the DFLL clock source (open-loop mode)
Hi Tuomas,
A bunch of small nit picks from me.
On Wed, Aug 20, 2014 at 2:04 PM, Tuomas Tynkkynen wrote:
> Add shared code to support the Tegra DFLL clocksource in open-loop
> mode. This root clocksource is present on the Tegra124 SoCs. The
> DFLL is the intended primary clock source for the fast CPU cluster.
>
> This code is very closely based on a patch by Paul Walmsley from
> December (http://comments.gmane.org/gmane.linux.ports.tegra/15273),
> which in turn comes from the internal driver by originally created
> by Aleksandr Frid .
>
> Subsequent patches will add support for closed loop mode and drivers
> for the Tegra124 fast CPU cluster DFLL devices, which rely on this
> code.
>
> Signed-off-by: Paul Walmsley
> Signed-off-by: Tuomas Tynkkynen
> ---
> v4: Use correct accessor function for the DFLL_OUTPUT_CFG register
> v3: Fix incorrect order of arguments to dfll_scale_dvco_rate call
> ---
> drivers/clk/tegra/Makefile |1 +
> drivers/clk/tegra/clk-dfll.c | 1090
> ++
> drivers/clk/tegra/clk-dfll.h | 55 +++
> 3 files changed, 1146 insertions(+)
> create mode 100644 drivers/clk/tegra/clk-dfll.c
> create mode 100644 drivers/clk/tegra/clk-dfll.h
>
> diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
> index f7dfb72..47320ca 100644
> --- a/drivers/clk/tegra/Makefile
> +++ b/drivers/clk/tegra/Makefile
> @@ -1,5 +1,6 @@
> obj-y += clk.o
> obj-y += clk-audio-sync.o
> +obj-y += clk-dfll.o
> obj-y += clk-divider.o
> obj-y += clk-periph.o
> obj-y += clk-periph-gate.o
> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
> new file mode 100644
> index 000..fb21018
> --- /dev/null
> +++ b/drivers/clk/tegra/clk-dfll.c
> @@ -0,0 +1,1090 @@
> +/*
> + * clk-dfll.c - Tegra DFLL clock source common code
> + *
> + * Copyright (C) 2012-2014 NVIDIA Corporation. All rights reserved.
> + *
> + * Aleksandr Frid
> + * Paul Walmsley
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * This library is for the DVCO and DFLL IP blocks on the Tegra124
> + * SoC. These IP blocks together are also known at NVIDIA as
> + * "CL-DVFS". To try to avoid confusion, this code refers to them
> + * collectively as the "DFLL."
> + *
> + * The DFLL is a root clocksource which tolerates some amount of
> + * supply voltage noise. Tegra124 uses it to clock the fast CPU
> + * complex when the target CPU speed is above a particular rate. The
> + * DFLL can be operated in either open-loop mode or closed-loop mode.
> + * In open-loop mode, the DFLL generates an output clock appropriate
> + * to the supply voltage. In closed-loop mode, when configured with a
> + * target frequency, the DFLL minimizes supply voltage while
> + * delivering an average frequency equal to the target.
> + *
> + * Devices clocked by the DFLL must be able to tolerate frequency
> + * variation. In the case of the CPU, it's important to note that the
> + * CPU cycle time will vary. This has implications for
> + * performance-measurement code and any code that relies on the CPU
> + * cycle time to delay for a certain length of time.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-dfll.h"
> +
> +/*
> + * DFLL control registers - access via dfll_{readl,writel}
> + */
> +
> +/* DFLL_CTRL: DFLL control register */
> +#define DFLL_CTRL 0x00
> +#define DFLL_CTRL_MODE_MASK0x03
> +
> +/* DFLL_CONFIG: DFLL sample rate control */
> +#define DFLL_CONFIG0x04
> +#define DFLL_CONFIG_DIV_MASK 0xff
> +#define DFLL_CONFIG_DIV_PRESCALE 32
> +
> +/* DFLL_PARAMS: tuning coefficients for closed loop integrator */
> +#define DFLL_PARAMS0x08
> +#define DFLL_PARAMS_CG_SCALE (0x1 << 24)
> +#define DFLL_PARAMS_FORCE_MODE_SHIFT 22
> +#define DFLL_PARAMS_FORCE_MODE_MASK(0x3 << DFLL_PARAMS_FORCE_MODE_SHIFT)
> +#define DFLL_PARAMS_CF_PARAM_SHIFT 16
> +#define DFLL_PARAMS_CF_PARAM_MASK (0x3f << DFLL_PARAMS_CF_PARAM_SHIFT)
> +#define DFLL_PARAMS_CI_PARAM_SHIFT 8
> +#define DFLL_PARAMS_CI_PARAM_MASK (0x7 << DFLL_PARAMS_CI_PARAM_SHIFT)
> +#define DFLL_PARAMS_CG_PARAM_SHIFT 0
> +#define DFLL
Re: [PATCH 2/2] HID: picolcd: sanity check report size in raw_event() callback
On Wed, 27 Aug 2014 23:32:00 +0200 (CEST) Jiri Kosina wrote:
> On Wed, 27 Aug 2014, Jiri Kosina wrote:
>
> > > Is it worth adding report->id to this hid_warn()?
> > >
> > > A valid device is not expected to ever send >64 bytes reports but in
> > > case a firmware update would do so it would help to know for which
> > > report it was.
> >
> > It definitely wouldn't hurt. Pull request with the original patch is now
> > on its way to Linus though, so let's do this as a followup patch on top
> > once this is merged.
>
> I've just queued the below for 3.18.
Looks good,
Thanks
Bruno
> From: Jiri Kosina
> Subject: [PATCH] HID: picolcd: be more verbose when reporting report size
> error
>
> picolcd device is not expected to send any report with size larger than 64
> bytes.
>
> If this impossible event happens (sic!), print also a report ID to allow
> for easier debugging.
>
> Suggested-by: Bruno Prémont
> Signed-off-by: Jiri Kosina
> ---
> drivers/hid/hid-picolcd_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> index 020df3c..c1b29a9 100644
> --- a/drivers/hid/hid-picolcd_core.c
> +++ b/drivers/hid/hid-picolcd_core.c
> @@ -351,8 +351,8 @@ static int picolcd_raw_event(struct hid_device *hdev,
> return 1;
>
> if (size > 64) {
> - hid_warn(hdev, "invalid size value (%d) for picolcd raw
> event\n",
> - size);
> + hid_warn(hdev, "invalid size value (%d) for picolcd raw event
> (%d)\n",
> + size, report->id);
> return 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 (net-next) v3] net: stmmac: fix warning from Sparse for socfpga
On 8/28/2014 6:59 AM, Ley Foon Tan wrote:
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..ddc6115 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,8 +119,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
- &res_splitter);
+ dwmac->splitter_base = devm_ioremap_resource(dev,
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
return -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 1/3] cpufreq: cpu0: Release clk and regulator in remove function
On Thu, Aug 28, 2014 at 12:30 PM, Pramod Gurav wrote: > This function releases clk and regulator in remove function for clean > unloading. > > CC: Shawn Guo > CC: "Rafael J. Wysocki" > CC: Viresh Kumar > Signed-off-by: Pramod Gurav > --- > drivers/cpufreq/cpufreq-cpu0.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) I already have most of this queued up, have sent V3 and cc'd now. See if you need anything over 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/
Re: [PATCH] rcu: Make nocb leader kthreads process pending callbacks after spawning
On (Wed) 27 Aug 2014 [16:43:40], Pranith Kumar wrote:
> The nocb callbacks generated before the nocb kthreads are spawned are
> enqueued in the nocb queue for later processing. Commit fbce7497ee5af ("rcu:
> Parallelize and economize NOCB kthread wakeups") introduced nocb leader
> kthreads
> which checked the nocb_leader_wake flag to see if there were any such pending
> callbacks. A case was reported in which newly spawned leader kthreads were not
> processing the pending callbacks as this flag was not set, which led to a boot
> hang.
>
> The following commit ensures that the newly spawned nocb kthreads process the
> pending callbacks by allowing the kthreads to run immediately after spawning
> instead of waiting. This is done by inverting the logic of nocb_leader_wake
> tests to nocb_leader_sleep which allows us to use the default initialization
> of
> this flag to 0 to let the kthreads run.
>
> Reported-by: Amit Shah
> Signed-off-by: Pranith Kumar
> Link: http://www.spinics.net/lists/kernel/msg1802899.html
> ---
> kernel/rcu/tree.h| 2 +-
> kernel/rcu/tree_plugin.h | 24
> 2 files changed, 13 insertions(+), 13 deletions(-)
I'd have split this into two patches: one for the variable rename and
one for fixing the bug.
However, the backport Paul posted does work fine for me on master, so
you can add my
Tested-by: Amit Shah
Thanks,
Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Aug 28
Hi all, Changes since 20140827: The usb.current tree lost its build failure. The percpu tree lost its build failure. The staging tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 2146 2292 files changed, 58126 insertions(+), 36066 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 220 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ff0c57ac7043 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org backwards" error) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall) Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement no longer needed) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging sparc/master (451fd72219dd Merge tag 'pwm/for-3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm) Merging net/master (7a4cecf74c16 phy: fix EEE checks inside the phy_init_eee.) Merging ipsec/master (2d39d120781a mvneta: Add missing if_vlan.h include.) Merging sound-current/for-linus (1a22e7758eab ALSA: hda - Set up initial pins for Acer Aspire V5) Merging pci-current/for-linus (8d7004a6904c PCI: spear: Remove module option) Merging wireless/master (c66517165610 rtlwifi: rtl8192cu: Add new ID) Merging driver-core.current/driver-core-linus (52addcf9d666 Linux 3.17-rc2) Merging tty.current/tty-linus (52addcf9d666 Linux 3.17-rc2) Merging usb.current/usb-linus (a9ef803d740b USB: fix build error with CONFIG_PM_RUNTIME disabled) Merging usb-gadget-fixes/fixes (5d19703822da usb: gadget: remove $(PWD) in ccflags-y) Merging usb-serial-fixes/usb-linus (646907f5bfb0 USB: ftdi_sio: Added PID for new ekey device) Merging staging.current/staging-linus (a2fa6721c723 staging: r8188eu: Add new USB ID) Merging char-misc.current/char-misc-linus (72ad366f687d thunderbolt: Clear hops before overwriting) Merging input-current/for-linus (a2418fc4a13b Input: elantech - add support for trackpoint found on some v3 models) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of generating multiple of 2**16 bytes) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree fixup machine function) Merging rr-fixes/fixes (ff7e0055bb5d module: Clean up ro/nx after early module load failures) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging drm-intel-fixes/for-linux-next-fixes (813008cd3e93 drm/i915: don't warn if backlight unexpectedly enabled) Merging asm-generic/master (fb9de7ebc3a2 xtensa: Use generic asm/mmu.h for nommu) Merging arc/for-next (2a5e95d4181c
Re: [PATCH 1/3] cpufreq: cpu0: Release clk and regulator in remove function
On Thu, Aug 28, 2014 at 12:00:10AM -0700, Pramod Gurav wrote: > This function releases clk and regulator in remove function for clean > unloading. > > CC: Shawn Guo > CC: "Rafael J. Wysocki" > CC: Viresh Kumar > Signed-off-by: Pramod Gurav > --- > drivers/cpufreq/cpufreq-cpu0.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c > index 0d2172b..e1574f8 100644 > --- a/drivers/cpufreq/cpufreq-cpu0.c > +++ b/drivers/cpufreq/cpufreq-cpu0.c > @@ -229,6 +229,8 @@ static int cpu0_cpufreq_remove(struct platform_device > *pdev) > cpufreq_cooling_unregister(cdev); > cpufreq_unregister_driver(&cpu0_cpufreq_driver); > dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table); > + clk_put(cpu_clk); > + regulator_put(cpu_reg); cpu_reg is optional for the driver, so it's more logical to check the availability before actually putting it? Shawn > > return 0; > } > -- > 1.7.0.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] usb: gadget: Remove use of PWD in Makefiles
Using PWD breaks out-of-tree builds in certain circumstances [1], and other kernel Makefiles use relative paths just fine. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=83251 Signed-off-by: Shea Levy --- drivers/usb/gadget/Makefile | 2 +- drivers/usb/gadget/function/Makefile | 4 ++-- drivers/usb/gadget/legacy/Makefile | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index a186afe..9add915 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -3,7 +3,7 @@ # subdir-ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG subdir-ccflags-$(CONFIG_USB_GADGET_VERBOSE)+= -DVERBOSE_DEBUG -ccflags-y += -I$(PWD)/drivers/usb/gadget/udc +ccflags-y += -Idrivers/usb/gadget/udc obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o libcomposite-y := usbstring.o config.o epautoconf.o diff --git a/drivers/usb/gadget/function/Makefile b/drivers/usb/gadget/function/Makefile index 6d91f21..83ae106 100644 --- a/drivers/usb/gadget/function/Makefile +++ b/drivers/usb/gadget/function/Makefile @@ -2,8 +2,8 @@ # USB peripheral controller drivers # -ccflags-y := -I$(PWD)/drivers/usb/gadget/ -ccflags-y += -I$(PWD)/drivers/usb/gadget/udc/ +ccflags-y := -Idrivers/usb/gadget/ +ccflags-y += -Idrivers/usb/gadget/udc/ # USB Functions usb_f_acm-y:= f_acm.o diff --git a/drivers/usb/gadget/legacy/Makefile b/drivers/usb/gadget/legacy/Makefile index a11aad5..edba2d1 100644 --- a/drivers/usb/gadget/legacy/Makefile +++ b/drivers/usb/gadget/legacy/Makefile @@ -2,9 +2,9 @@ # USB gadget drivers # -ccflags-y := -I$(PWD)/drivers/usb/gadget/ -ccflags-y += -I$(PWD)/drivers/usb/gadget/udc/ -ccflags-y += -I$(PWD)/drivers/usb/gadget/function/ +ccflags-y := -Idrivers/usb/gadget/ +ccflags-y += -Idrivers/usb/gadget/udc/ +ccflags-y += -Idrivers/usb/gadget/function/ g_zero-y := zero.o g_audio-y := audio.o -- 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/
[PATCH (net-next) v3] net: stmmac: fix warning from Sparse for socfpga
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..ddc6115 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,8 +119,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
- &res_splitter);
+ dwmac->splitter_base = devm_ioremap_resource(dev,
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
return -EINVAL;
--
1.8.2.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] softlockup: Make detector be aware of task switch of processes hogging cpu
From: chai wen
For now, soft lockup detector warns once for each case of process softlockup.
But the thread 'watchdog/n' may not always get the cpu at the time slot between
the task switch of two processes hogging that cpu to reset soft_watchdog_warn.
An example would be two processes hogging the cpu. Process A causes the
softlockup warning and is killed manually by a user. Process B immediately
becomes the new process hogging the cpu preventing the softlockup code from
resetting the soft_watchdog_warn variable.
This case is a false negative of "warn only once for a process", as there may
be a different process that is going to hog the cpu. Resolve this by
saving/checking the task pointer of the hogging process and use that to reset
soft_watchdog_warn too.
Signed-off-by: chai wen
Signed-off-by: Don Zickus
---
kernel/watchdog.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index c3319bd..499f65f 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -47,6 +47,7 @@ static DEFINE_PER_CPU(bool, softlockup_touch_sync);
static DEFINE_PER_CPU(bool, soft_watchdog_warn);
static DEFINE_PER_CPU(unsigned long, hrtimer_interrupts);
static DEFINE_PER_CPU(unsigned long, soft_lockup_hrtimer_cnt);
+static DEFINE_PER_CPU(struct task_struct *, softlockup_task_ptr_saved);
#ifdef CONFIG_HARDLOCKUP_DETECTOR
static DEFINE_PER_CPU(bool, hard_watchdog_warn);
static DEFINE_PER_CPU(bool, watchdog_nmi_touch);
@@ -331,8 +332,20 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
return HRTIMER_RESTART;
/* only warn once */
- if (__this_cpu_read(soft_watchdog_warn) == true)
+ if (__this_cpu_read(soft_watchdog_warn) == true) {
+ /*
+* Handle the case where multiple processes are
+* causing softlockups but the duration is small
+* enough, the softlockup detector can not reset
+* itself in time. Use task pointers to detect this.
+*/
+ if (__this_cpu_read(softlockup_task_ptr_saved) !=
+ current) {
+ __this_cpu_write(soft_watchdog_warn, false);
+ __touch_watchdog();
+ }
return HRTIMER_RESTART;
+ }
if (softlockup_all_cpu_backtrace) {
/* Prevent multiple soft-lockup reports if one cpu is
already
@@ -348,6 +361,7 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
printk(KERN_EMERG "BUG: soft lockup - CPU#%d stuck for %us!
[%s:%d]\n",
smp_processor_id(), duration,
current->comm, task_pid_nr(current));
+ __this_cpu_write(softlockup_task_ptr_saved, current);
print_modules();
print_irqtrace_events(current);
if (regs)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables.
Dear Andrew, On 08/27/2014 06:31 AM, Andrew Morton wrote: > On Mon, 25 Aug 2014 09:57:33 +0900 Chanwoo Choi wrote: > >> Dear Andrew, >> >> On 08/23/2014 05:42 AM, Andrew Morton wrote: >>> On Tue, 12 Aug 2014 11:01:07 +0900 y...@samsung.com wrote: >>> This patch define s3c_rtc structure including necessary variables for S3C RTC device instead of global variables. This patch improves the readability by removing global variables. >>> >>> Below is the v1->v2 delta. >>> >>> Why were all those tests of info->base added? Can it really be zero? >>> I don't see how. >> >> If some functions (e.g., s3c_rtc_settime) accesses the rtc register >> by using info->base before the initialization of info->base in s3c_rtc_probe, >> I thought that null pointer error would happen. > > probe() should be called before anything else. If we're somehow > calling s3c_rtc_settime() before probe() has completed then something > very bad is happening - for example, the device may have been > registered far too early. But I don't think that's the case here. I means that existing rtc-s3c.c driver executed s3c_rtc_settime() in s3c_rtc_probe() before initialization of info->base. But, It is my mistake. so, I modified it just as following: - s3c_rtc_settime(NULL, &rtc_tm); + s3c_rtc_settime(&pdev->dev, &rtc_tm); > > That being said, it does seem strange that s3c_rtc_probe() calls > devm_rtc_device_register() *before* trying to request its IRQs. So if > IRQ requesting fails, we go and immediately unregister the device. > Some other drivers do it this way, others do not. Wouldn't it be > better to defer registration until we know that all the probe() setup > operations have succeeded? You're right. I missed this point. If rtc-s3c.c driver completed the probe function, info->base has always right address. + if (!info->base) + return -EINVAL; + As you said, checking state of 'info-base' is un-needed. I'll send new patchset(v3) to fix it. > >> But, I missed one point which info->base might have the garbate data instead >> of NULL. >> I'll add the initialization code for info->base. >> info->base = NULL; >> >> If you don't agree it, I'll drop this code checking the state of info->base >> on next patchset(v3). > > Well, we should have those checks in there unless we know they're > needed. And if they *are* needed, we should have a good understanding > of why they're needed, and we should be sure that we're not just > working around some underlying problem. You are right. Thanks for your comment and advice. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, slub: do not add duplicate sysfs
On 08/27/14 at 10:32am, Christoph Lameter wrote:
> Maybe something like this may be a proper fix:
>
> Subject: slub: Disable tracing of mergeable slabs
>
> Tracing of mergeable slabs is confusing since the objects
> of multiple slab caches will be traced. Moreover this creates
> a situation where a mergeable slab will become unmergeable.
>
> If tracing is desired then it may be best to switch merging
> off for starters.
>
> Signed-off-by: Christoph Lameter
>
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c 2014-08-08 11:52:30.039681592 -0500
> +++ linux/mm/slub.c 2014-08-27 10:30:16.508108726 -0500
> @@ -4604,6 +4604,14 @@ static ssize_t trace_show(struct kmem_ca
> static ssize_t trace_store(struct kmem_cache *s, const char *buf,
> size_t length)
> {
> + /*
> + * Tracing a merged cache is going to give confusing results
> + * as well as cause other issues like converting a mergeable
> + * cache into an umergeable one.
> + */
> + if (s->refcount > 1)
> + return -EINVAL;
> +
> s->flags &= ~SLAB_TRACE;
> if (buf[0] == '1') {
> s->flags &= ~__CMPXCHG_DOUBLE;
What about failslab_store()? SLAB_FAILSLAB is also a nomerge flag.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi Jingoo,
On Wed, Aug 27, 2014 at 7:28 AM, Jingoo Han wrote:
> On Thursday, August 21, 2014 11:55 PM, Vivek Gautam wrote:
>>
>> Adding phy calibrate callback, which facilitates setting certain
>> PHY settings post initialization of the PHY controller.
>> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
>> the Loss-of-Signal (LOS) Detector Threshold Level as well as
>> Tx-Vboost-Level should be controlled for Super-Speed operations.
>>
>> Additionally set proper time to wait for RxDetect measurement,
>> for desired PHY reference clock, so as to solve issue with enumeration
>> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
>> on the controller.
>> We are using CR_port for this purpose to send required data
>> to override the LOS values.
>>
>> On testing with USB 3.0 devices on USB 3.0 port present on
>> SMDK5420, and peach-pit boards should see following message:
>> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>
>> and without this patch, should see below shown message:
>> usb 1-1: new high-speed USB device number 2 using xhci-hcd
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/phy/phy-exynos5-usbdrd.c | 169
>> ++
>> 1 file changed, 169 insertions(+)
>>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> index 47f47fe..fa13784 100644
>> --- a/drivers/phy/phy-exynos5-usbdrd.c
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>> @@ -89,8 +89,20 @@
>> #define PHYCLKRST_COMMONONN BIT(0)
>>
>> #define EXYNOS5_DRD_PHYREG0 0x14
>> +
>> +#define EXYNOS5_DRD_PHYREG0_SSC_REF_CLK_SEL BIT(21)
>> +#define EXYNOS5_DRD_PHYREG0_SSC_RANGEBIT(20)
>> +#define EXYNOS5_DRD_PHYREG0_CR_WRITE BIT(19)
>> +#define EXYNOS5_DRD_PHYREG0_CR_READ BIT(18)
>> +#define EXYNOS5_DRD_PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
>> +#define EXYNOS5_DRD_PHYREG0_CR_CAP_DATA BIT(1)
>> +#define EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR BIT(0)
>> +
>> #define EXYNOS5_DRD_PHYREG1 0x18
>>
>> +#define EXYNOS5_DRD_PHYREG1_CR_DATA_OUT(_x) ((_x) << 1)
>> +#define EXYNOS5_DRD_PHYREG1_CR_ACK BIT(0)
>> +
>> #define EXYNOS5_DRD_PHYPARAM00x1c
>>
>> #define PHYPARAM0_REF_USE_PADBIT(31)
>> @@ -118,6 +130,26 @@
>> #define EXYNOS5_DRD_PHYRESUME0x34
>> #define EXYNOS5_DRD_LINKPORT 0x44
>>
>> +/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
>> +#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
>> +
>
> Please remove unnecessary line.
Sure will remove extra lines.
[snip]
>> +static void crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
>> + u32 addr, u32 data)
>> +{
>> + /* Write Address */
>> + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
>> + EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);
>
> According to the guidance from H/W team, before calling crport_handshake(),
> write access for EXYNOS5_DRD_PHYREG0 register is necessary.
>
> Please, add the write access as follows.
>
> + /* Write Address */
> + writel(EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
> + phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
> +EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);
Sure will add this, thanks for getting the information from H/W team
and suggesting.
>
> Best regards,
> Jingoo Han
>
>> +
>> + /* Write Data */
>> + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
>> + EXYNOS5_DRD_PHYREG0_CR_CAP_DATA);
>> + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
>> + EXYNOS5_DRD_PHYREG0_CR_WRITE);
>> +}
>> +
>> +/*
>> + * Override PHY paramaeters using CR_PORT register to calibrate settings
>> + * to meet meet SuperSpeed requirements, on Exynos5420 and Exynos5800
>> systems,
>> + * which have 28nm USB 3.0 DRD PHY.
>> + */
>> +static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy
>> *phy_drd)
>> +{
>> + u32 temp;
>> +
>> + /*
>> + * Change los_bias to (0x5) for 28nm PHY from a
>> + * default value (0x0); los_level is set as default
>> + * (0x9) as also reflected in los_level[30:26] bits
>> + * of PHYPARAM0 register.
>> + */
>> + temp = LOSLEVEL_OVRD_IN_LOS_BIAS_5420 |
>> + LOSLEVEL_OVRD_IN_EN |
>> + LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT;
>> + crport_ctrl_write(phy_drd,
>> + EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
>> + temp);
>> +
>> + /*
>> + * Set tx_vboost_lvl to (0x5) for 28nm PHY Tuning,
>> + * to raise Tx signal level from its default value of (0x4)
>> + */
>> + temp = TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420;
>> + crport_ctrl_write(phy_dr
Re: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
Dear Eduardo,
This patch is wrong. It is my mistake.
Please ignore only this patch because
the offset calculation of 'case 0' is different from 'case 2'.
Best Regards,
Chanwoo Choi
On 08/26/2014 10:31 AM, Chanwoo Choi wrote:
> This patch remove simply duplicate code when reading triminfo register of
> Exynos5440.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Amit Daniel Kachhap
> Reviewed-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_tmu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 64c702a..5888467 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
>*/
> switch (data->id) {
> case 0:
> + case 2:
> trim_info = readl(data->base +
> EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> break;
> case 1:
> trim_info = readl(data->base + reg->triminfo_data);
> break;
> - case 2:
> - trim_info = readl(data->base -
> - EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> }
> } else {
> /* On exynos5420 the triminfo register is in the shared space */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel: fix for checkpatch errors in sys file
From: "vishnu.ps"
This patch fixes minor errors and warning messages in sys.c file.
These errors were reported while working with some modifications in sys.c file.
Fixing this first will help me to improve my further patches.
ERROR: trailing whitespace - 9
ERROR: do not use assignment in if condition - 4
ERROR: spaces required around that '?' (ctx:VxO) - 10
ERROR: switch and case should be at the same indent - 3
total 26 errors & 3 warnings fixed.
Signed-off-by: vishnu.ps
---
kernel/sys.c | 265 ++-
1 file changed, 137 insertions(+), 128 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 14222a1..7f3518c 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -62,28 +62,28 @@
#include
#ifndef SET_UNALIGN_CTL
-# define SET_UNALIGN_CTL(a,b) (-EINVAL)
+# define SET_UNALIGN_CTL(a, b) (-EINVAL)
#endif
#ifndef GET_UNALIGN_CTL
-# define GET_UNALIGN_CTL(a,b) (-EINVAL)
+# define GET_UNALIGN_CTL(a, b) (-EINVAL)
#endif
#ifndef SET_FPEMU_CTL
-# define SET_FPEMU_CTL(a,b)(-EINVAL)
+# define SET_FPEMU_CTL(a, b) (-EINVAL)
#endif
#ifndef GET_FPEMU_CTL
-# define GET_FPEMU_CTL(a,b)(-EINVAL)
+# define GET_FPEMU_CTL(a, b) (-EINVAL)
#endif
#ifndef SET_FPEXC_CTL
-# define SET_FPEXC_CTL(a,b)(-EINVAL)
+# define SET_FPEXC_CTL(a, b) (-EINVAL)
#endif
#ifndef GET_FPEXC_CTL
-# define GET_FPEXC_CTL(a,b)(-EINVAL)
+# define GET_FPEXC_CTL(a, b) (-EINVAL)
#endif
#ifndef GET_ENDIAN
-# define GET_ENDIAN(a,b) (-EINVAL)
+# define GET_ENDIAN(a, b) (-EINVAL)
#endif
#ifndef SET_ENDIAN
-# define SET_ENDIAN(a,b) (-EINVAL)
+# define SET_ENDIAN(a, b) (-EINVAL)
#endif
#ifndef GET_TSC_CTL
# define GET_TSC_CTL(a)(-EINVAL)
@@ -182,39 +182,40 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who, int,
niceval)
rcu_read_lock();
read_lock(&tasklist_lock);
switch (which) {
- case PRIO_PROCESS:
- if (who)
- p = find_task_by_vpid(who);
- else
- p = current;
- if (p)
- error = set_one_prio(p, niceval, error);
- break;
- case PRIO_PGRP:
- if (who)
- pgrp = find_vpid(who);
- else
- pgrp = task_pgrp(current);
- do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
- error = set_one_prio(p, niceval, error);
- } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
- break;
- case PRIO_USER:
- uid = make_kuid(cred->user_ns, who);
- user = cred->user;
- if (!who)
- uid = cred->uid;
- else if (!uid_eq(uid, cred->uid) &&
-!(user = find_user(uid)))
+ case PRIO_PROCESS:
+ if (who)
+ p = find_task_by_vpid(who);
+ else
+ p = current;
+ if (p)
+ error = set_one_prio(p, niceval, error);
+ break;
+ case PRIO_PGRP:
+ if (who)
+ pgrp = find_vpid(who);
+ else
+ pgrp = task_pgrp(current);
+ do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
+ error = set_one_prio(p, niceval, error);
+ } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
+ break;
+ case PRIO_USER:
+ uid = make_kuid(cred->user_ns, who);
+ user = cred->user;
+ if (!who)
+ uid = cred->uid;
+ else if (!uid_eq(uid, cred->uid)) {
+ user = find_user(uid);
+ if (!user)
goto out_unlock;/* No processes for
this user */
-
- do_each_thread(g, p) {
- if (uid_eq(task_uid(p), uid))
- error = set_one_prio(p, niceval, error);
- } while_each_thread(g, p);
- if (!uid_eq(uid, cred->uid))
- free_uid(user); /* For find_user() */
- break;
+ }
+ do_each_thread(g, p) {
+ if (uid_eq(task_uid(p), uid))
+ error = set_one_prio(p, niceval, error);
+ } while_each_thread(g, p);
+ if (!uid_eq(uid, cred->uid))
+ free_uid(user); /* For find_user() */
+ break;
}
out_unlock:
read_unlock(&tasklist_lock);
@@ -244,47 +245,48 @@ SYSCALL_DEFINE2(getpriority, int, which
[xhci] kernel BUG at arch/x86/mm/physaddr.c:26!
c
[4.360029] RSP
[4.392028] ---[ end trace 68ef4c4340f54dcf ]---
[4.392651] Kernel panic - not syncing: Fatal exception
git bisect start 87e45e9aee6e16808da24d42620c30e62ef78f72
52addcf9d6669fa439387610bc65c92fa0980cef --
git bisect good 21e7954c90927f091ef81611f7f186d8f2f068a7 # 02:54 20+
0 Merge 'ipvs/master' into devel-hourly-2014082801
git bisect good db76ed1b63ae17ebfbbcac90a25e9b15d7c81593 # 03:02 20+
0 Merge 'robclark/msm-fixes-3.17' into devel-hourly-2014082801
git bisect bad d742d6a6a9ba64655ff7c57b5995f5e88e417c4d # 03:06 0-
20 Merge 'xen-tip/devel/for-linus-3.18' into devel-hourly-2014082801
git bisect good b590845ddf136fab351e0fbed14e3d1b1e655d56 # 03:13 20+
1 Merge 'regulator/for-next' into devel-hourly-2014082801
git bisect bad a768419190a3acf1db12e2e27d3589035d2ca713 # 03:24 0-
20 Merge 'djbw-usb/td-fragments-v1' into devel-hourly-2014082801
git bisect good e705f1f3500d34055a829cec1178012108c2b5aa # 03:28 20+
0 Merge 'stericsson/tcm' into devel-hourly-2014082801
git bisect good a75ef911cf100b8cf7d25baf6dac8052328a96e7 # 03:39 20+
0 xhci: clarify "ring valid" checks
git bisect good 652b7ee36207f186f3d701675483df43b4845c5c # 03:45 20+
0 xhci: kill ->num_trbs_free_temp in struct xhci_ring
git bisect good 1c11eb8545a3321e7ca27fc7ba8c56b6e6df2b57 # 03:51 20+
0 xhci: add xhci_ring_reap_td() helper
git bisect bad e65e21a542cab81d794db4e5fe919c4e1d624ea7 # 03:56 0-
20 xhci: unit test ring enqueue/dequeue routines
git bisect good fb6fa3e625e1e453aea9eeb97d58bee30e1c0781 # 04:07 20+
0 xhci: v1.0 scatterlist enqueue support (td-fragment rework)
# first bad commit: [e65e21a542cab81d794db4e5fe919c4e1d624ea7] xhci: unit test
ring enqueue/dequeue routines
git bisect good fb6fa3e625e1e453aea9eeb97d58bee30e1c0781 # 04:10 60+
0 xhci: v1.0 scatterlist enqueue support (td-fragment rework)
git bisect bad 87e45e9aee6e16808da24d42620c30e62ef78f72 # 04:10 0-
11 0day head guard for 'devel-hourly-2014082801'
git bisect good ff0c57ac70434bc936cb0110eaf033a0a1a62e52 # 04:19 60+
5 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect good d05446ae2128064a4bb8f74c84f6901ffb5c94bc # 04:22 60+
0 Add linux-next specific files for 20140827
This script may reproduce the error.
#!/bin/bash
kernel=$1
initrd=yocto-minimal-x86_64.cgz
wget --no-clobber
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-cpu kvm64
-enable-kvm
-kernel $kernel
-initrd $initrd
-m 320
-smp 1
-net nic,vlan=1,model=e1000
-net user,vlan=1
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
Thanks,
Fengguang
early console in setup code
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.16.0-rc5-00225-ge65e21a (kbuild@lkp-hsx01) (gcc
version 4.8.2 (Debian 4.8.2-18) ) #6 Thu Aug 28 11:54:57 CST 2014
[0.00] Command line: hung_task_panic=1 earlyprintk=ttyS0,115200 debug
apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal root=/dev/ram0
rw
link=/kbuild-tests/run-queue/kvm/x86_64-randconfig-hsxa2-08281025/linux-devel:devel-hourly-2014082801:e65e21a542cab81d794db4e5fe919c4e1d624ea7:bisect-linux-5/.vmlinuz-e65e21a542cab81d794db4e5fe919c4e1d624ea7-20140828115559-4-vp
branch=linux-devel/devel-hourly-2014082801
BOOT_IMAGE=/kernel/x86_64-randconfig-hsxa2-08281025/e65e21a542cab81d794db4e5fe919c4e1d624ea7/vmlinuz-3.16.0-rc5-00225-ge65e21a
drbd.minor_count=8
[0.00] KERNEL supported cpus:
[0.00] AMD AuthenticAMD
[0.00] Centaur CentaurHauls
[0.00] CPU: vendor_id 'GenuineIntel' unknown, using generic init.
[0.00] CPU: Your system may be unstable.
[0.00] e
Re: [PATCH v5 3/4] usb: hcd: Caibrate PHY post hcd reset
Hi, On Fri, Aug 22, 2014 at 4:19 PM, Andreas Färber wrote: > Hi, > > s/Caibrate/Calibrate/ Sure, will rectify the title, thanks for pointing it out. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] perf/sdt : Documentation for SDT events
Adds documentation for perf support to SDT events.
Signed-off-by : Hemant Kumar
---
tools/perf/Documentation/SDT-support.txt | 48 ++
tools/perf/Documentation/perf-list.txt |4 ++-
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/Documentation/SDT-support.txt
diff --git a/tools/perf/Documentation/SDT-support.txt
b/tools/perf/Documentation/SDT-support.txt
new file mode 100644
index 000..273912b
--- /dev/null
+++ b/tools/perf/Documentation/SDT-support.txt
@@ -0,0 +1,48 @@
+Support to perf for listing the SDT markers :
+
+This helps in listing dtrace style markers(SDT) present in user space
+applications through perf. SDT Notes/markers are placed at important places by
the
+developers. They have a negligible overhead when not enabled.
+We can enable them and probe at these places and find some important
information
+like the arguments' values, etc.
+
+How to add SDT markers into user applications:
+We need to have this header sys/sdt.h present.
+sys/sdt.h used is version 3.
+If not present, install systemtap-sdt-devel package (for fedora-18).
+
+A very simple example:
+
+$ cat user_app.c
+
+#include
+
+void main () {
+ /* ... */
+ /*
+* user_app is the provider name
+* test_probe is the marker name
+*/
+ STAP_PROBE(user_app, test_mark);
+ /* ... */
+}
+
+$ gcc user_app.c
+$ perf list sdt ./a.out
+./a.out:
+%user_app:test_mark
+
+For more information on usage of SDT markers, visit the following link:
+http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
+
+This link shows an example of marker probing with Systemtap:
+https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps
+
+- Markers in binaries :
+These SDT markers are present in the ELF in the section named
+".note.stapsdt".
+This section contains the name of the marker, its provider, type, location,
base
+address, semaphore address.
+We can retrieve these values using the members name_off and desc_off in
+Nhdr structure. If these markers are not enabled, they are present in the ELF
in
+the form of a "nop" instruction.
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index 6fce6a6..5c72785 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
SYNOPSIS
[verse]
-'perf list' [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [hw|sw|cache|tracepoint|pmu|sdt|event_glob]
DESCRIPTION
---
@@ -108,6 +108,8 @@ To limit the list use:
. 'pmu' to print the kernel supplied PMU events.
+. 'sdt' to print the SDT events present in a file. Takes a file_name as an
argument.
+
. If none of the above is matched, it will apply the supplied glob to all
events, printing the ones that match.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] perf/sdt : Support perf-list to print SDT events in a single file
This patch enables perf to look for SDT markers in a single file.
An individual file argument must be given to "perf list" to find out the SDT
markers
present in that file.
Usage is as below :
# perf list sdt /home/hemant/tmp
/home/hemant/tmp:
%user : foo
%user : bar
On using this command, perf looks for SDTs in that file using the ELF functions
from
the previous patch (in this series) and dumps them on stdout.
Signed-off-by : Hemant Kumar
---
tools/perf/Makefile.perf |1
tools/perf/builtin-list.c |2 +
tools/perf/util/parse-events.h |2 +
tools/perf/util/sdt.c | 113
4 files changed, 118 insertions(+)
create mode 100644 tools/perf/util/sdt.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 9670a16..e098dcd 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -373,6 +373,7 @@ LIB_OBJS += $(OUTPUT)util/stat.o
LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/sdt.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..85be3e3 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -53,6 +53,8 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, false);
+ else if (strcmp(argv[i], "sdt") == 0)
+ print_sdt_events(argv[++i]);
else if (strcmp(argv[i], "--raw-dump") == 0)
print_events(NULL, true);
else {
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index df094b4..fadc729 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -109,4 +109,6 @@ extern int is_valid_tracepoint(const char *event_string);
extern int valid_debugfs_mount(const char *debugfs);
+void print_sdt_events(const char *arg);
+
#endif /* __PERF_PARSE_EVENTS_H */
diff --git a/tools/perf/util/sdt.c b/tools/perf/util/sdt.c
new file mode 100644
index 000..12c16a0
--- /dev/null
+++ b/tools/perf/util/sdt.c
@@ -0,0 +1,113 @@
+/*
+ * util/sdt.c
+ * This contains the relevant functions needed to find the SDT markers
+ * in a binary.
+ *
+ * TODOS:
+ * - Listing SDT events in most of the binaries present in the system.
+ * - Build a cache for these SDT events.
+ * - Looking into directories provided by the user for binaries with SDTs, etc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "parse-events.h"
+#include "linux/list.h"
+#include "symbol.h"
+
+
+/*
+ * get_sdt_note_info(): flush the SDT notes onto stdout
+ */
+static void get_sdt_note_info(struct list_head *start, const char *target)
+{
+ struct sdt_note *pos;
+
+ if (list_empty(start))
+ return;
+
+ printf("%s :\n", target);
+ list_for_each_entry(pos, start, note_list) {
+ printf("%%%s : %s\n", pos->provider, pos->name);
+ }
+}
+
+/*
+ * Error displayed in case of query of a
+ * single file for SDT markers
+ */
+static int sdt_err(int val, const char *target)
+{
+ switch (-val) {
+ case 0:
+ break;
+ case ENOENT:
+ /* Absence of SDT markers */
+ printf("%s : No SDT events found\n", target);
+ break;
+ case EBADF:
+ printf("%s : Bad file name\n", target);
+ break;
+ default:
+ printf("%s\n", strerror(val));
+ }
+
+ return val;
+}
+
+/*
+ * cleanup_sdt_note_list() : Free the sdt note list
+ */
+static void cleanup_sdt_note_list(struct list_head *sdt_notes)
+{
+ struct sdt_note *tmp, *pos;
+
+ if (list_empty(sdt_notes))
+ return;
+
+ list_for_each_entry_safe(pos, tmp, sdt_notes, note_list) {
+ list_del(&pos->note_list);
+ free(pos->name);
+ free(pos->provider);
+ free(pos);
+ }
+}
+
+/*
+ * filename__find_sdt() : looks for sdt markers and the list is
+ * stored in sdt_notes
+ */
+static int filename__find_sdt(const char *target)
+{
+ int ret;
+
+ LIST_HEAD(sdt_notes);
+
+ ret = get_sdt_note_list(&sdt_notes, target);
+ if (!ret)
+ get_sdt_note_info(&sdt_notes, target);
+ else
+ sdt_err(ret, target);
+
+ cleanup_sdt_note_list(&sdt_notes);
+
+ return ret;
+}
+
+/*
+ * print_sdt_notes() : wrapper function
+ */
+void print_sdt_events(const char *arg)
+{
+ if (arg) {
+ filename__find_sdt(arg);
+ return;
+ }
+ pr_err("Error : File Name must be specified with \"sdt\" option!\n"
+ "Usage :\n perf list sdt \n");
+
+
Re: [Cocci] [PATCH] coccinelle: add pycocci wrapper for multithreaded support
On Thu, Apr 10, 2014 at 09:32:34PM +0200, Julia Lawall wrote: > > > On Thu, 10 Apr 2014, Luis R. Rodriguez wrote: > > > On Thu, Apr 10, 2014 at 07:51:29PM +0200, Johannes Berg wrote: > > > On Thu, 2014-04-10 at 10:48 -0700, Luis R. Rodriguez wrote: > > > > > > > You just pass it a cocci file, a target dir, and in git environments > > > > you always want --in-place enabled. Experiments and profiling random > > > > cocci files with the Linux kernel show that using just using number of > > > > CPUs doesn't scale well given that lots of buckets of files don't > > > > require > > > > work, as such this uses 10 * number of CPUs for its number of threads. > > > > For work that define more general ruler 3 * number of CPUs works better, > > > > but for smaller cocci files 3 * number of CPUs performs best right now. > > > > To experiment more with what's going on with the multithreading one can > > > > enable > > > > htop while kicking off a cocci task on the kernel, we want to keep > > > > these CPUs busy as much as possible. > > > > > > That's not really a good benchmark, you want to actually check how > > > quickly it finishes ... If you have some IO issues then just keeping the > > > CPUs busy trying to do IO won't help at all. > > > > I checked the profile results, the reason the jobs finish is some threads > > had no work or little work. Hence why I increased the number of threads, > > depending on the context (long or short cocci expected, in backports > > at least, the long being all cocci files in one, the short being > > --test-cocci > > flag to gentree.py). This wrapper uses the short assumption with 10 * > > num_cpus > > > > > > Since its just a helper I toss it into the python directory but don't > > > > install it. Hope is that we can evolve it there instead of carrying this > > > > helper within backports. > > > > > > If there's a plan to make coccinelle itself multi-threaded, what's the > > > point? > > > > To be clear, Coccinelle *has* a form of multithreaded support but requires > > manual > > spawning of jobs with references to the max count and also the number thread > > that this new process you are spawning belongs to. There's plans to consider > > reworking things to handle all this internally but as I discussed with Julia > > the changes required would require some structural changes, and as such we > > need to live with this for a bit longer. I need to use Coccinelle daily now, > > so figured I'd punt this out there in case others might make use of it. > > I agree with Luis. Multithreading inside Coccinelle is currently a > priority task, but not a highest priority one. Folks, anyone object to merging pycocci in the meantime? I keep using it outside of backports and it does what I think most kernel developers expect. This would be until we get proper parallelism support in place. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] perf/sdt : Raw SDT parsing functions
This patch serves as the initial support to identify and list SDT events in
binaries.
When programs containing SDT markers are compiled, gcc with the help of
assembler
directives identifies them and places them in the section ".note.stapsdt". To
find these
markers from the binaries, one needs to traverse through this section and parse
the
relevant details like the name, type and location of the marker. Also, the
original
location could be skewed due to the effect of prelinking. If that is the case,
the
locations need to be adjusted.
The functions in this patch open a given ELF, find out the SDT section, parse
the
relevant details, adjust the location (if necessary) and populate them in a
list.
Signed-off-by : Hemant Kumar
---
tools/perf/util/symbol-elf.c | 244 ++
tools/perf/util/symbol.h | 19 +++
2 files changed, 263 insertions(+)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 6864661..a875fdc 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1619,6 +1619,250 @@ void kcore_extract__delete(struct kcore_extract *kce)
unlink(kce->extract_filename);
}
+/*
+ * populate_sdt_note() : Responsible for parsing the section .note.stapsdt and
+ * after adjusting the note's location, returns that to the calling functions.
+ */
+static int populate_sdt_note(Elf **elf, const char *data, size_t len, int type,
+struct sdt_note **note)
+{
+ const char *provider, *name;
+ struct sdt_note *tmp = NULL;
+ GElf_Ehdr ehdr;
+ GElf_Addr base_off = 0;
+ GElf_Shdr shdr;
+ int ret = -1;
+ int i;
+
+ union {
+ Elf64_Addr a64[3];
+ Elf32_Addr a32[3];
+ } buf;
+
+ Elf_Data dst = {
+ .d_buf = &buf, .d_type = ELF_T_ADDR, .d_version = EV_CURRENT,
+ .d_size = gelf_fsize((*elf), ELF_T_ADDR, 3, EV_CURRENT),
+ .d_off = 0, .d_align = 0
+ };
+ Elf_Data src = {
+ .d_buf = (void *) data, .d_type = ELF_T_ADDR,
+ .d_version = EV_CURRENT, .d_size = dst.d_size, .d_off = 0,
+ .d_align = 0
+ };
+
+ /* Check the type of each of the notes */
+ if (type != SDT_NOTE_TYPE)
+ goto out_err;
+
+ tmp = (struct sdt_note *)calloc(1, sizeof(struct sdt_note));
+ if (!tmp) {
+ ret = -ENOMEM;
+ goto out_err;
+ }
+
+ INIT_LIST_HEAD(&tmp->note_list);
+
+ if (len < dst.d_size + 3)
+ goto out_free_note;
+
+ /* Translation from file representation to memory representation */
+ if (gelf_xlatetom(*elf, &dst, &src,
+ elf_getident(*elf, NULL)[EI_DATA]) == NULL)
+ printf("gelf_xlatetom : %s\n", elf_errmsg(-1));
+
+ /* Populate the fields of sdt_note */
+ provider = data + dst.d_size;
+
+ name = (const char *)memchr(provider, '\0', data + len - provider);
+ if (name++ == NULL)
+ goto out_free_note;
+
+ tmp->provider = strdup(provider);
+ if (!tmp->provider) {
+ ret = -ENOMEM;
+ goto out_free_note;
+ }
+ tmp->name = strdup(name);
+ if (!tmp->name) {
+ ret = -ENOMEM;
+ goto out_free_prov;
+ }
+
+ /* Obtain the addresses */
+ if (gelf_getclass(*elf) == ELFCLASS32) {
+ for (i = 0; i < 3; i++)
+ tmp->addr.a32[i] = buf.a32[i];
+ tmp->bit32 = true;
+ } else {
+ for (i = 0; i < 3; i++)
+ tmp->addr.a64[i] = buf.a64[i];
+ tmp->bit32 = false;
+ }
+
+ /* Now Adjust the prelink effect */
+ if (!gelf_getehdr(*elf, &ehdr)) {
+ pr_debug("%s : cannot get elf header.\n", __func__);
+ ret = -EBADF;
+ goto out_free_name;
+ }
+
+ /*
+* Find out the .stapsdt.base section.
+* This scn will help us to handle prelinking (if present).
+* Compare the retrieved file offset of the base section with the
+* base address in the description of the SDT note. If its different,
+* then accordingly, adjust the note location.
+*/
+ if (elf_section_by_name(*elf, &ehdr, &shdr, SDT_BASE_SCN, NULL)) {
+ base_off = shdr.sh_offset;
+ if (base_off) {
+ if (tmp->bit32)
+ tmp->addr.a32[0] = tmp->addr.a32[0] + base_off -
+ tmp->addr.a32[1];
+ else
+ tmp->addr.a64[0] = tmp->addr.a64[0] + base_off -
+ tmp->addr.a64[1];
+ }
+ }
+
+ *note = tmp;
+ return 0;
+
+out_free_name:
+ free(tmp->name);
+out_free_prov:
+ free(tmp->prov
Re: [PATCH] mm, slub: do not add duplicate sysfs
On 08/27/14 at 10:25am, Christoph Lameter wrote: > On Wed, 27 Aug 2014, WANG Chao wrote: > > > Mergeable slab can be changed to unmergeable after tuning its sysfs > > interface, for example echo 1 > trace. But the sysfs kobject with the unique > > name will be still there. > > Hmmm... Merging should be switched off if any debugging features are > enabled. Maybe we need to disable modifying debug options for an active > cache? This could cause other issues as well since the debug options will > then apply to multiple caches. Yes, currently merging is already switched off if there's any debug flag. It sounds a bit overkill to me to disable runtime configuration. I don't know how many people out there would trace a mergeable (multiple) caches. Well it sounds better if we give them the chance to that... Thanks WANG Chao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] perf/sdt : Support for SDT markers
The v3 patchset had some spacing errors because of my editor messing up during sending the patches. Resending the patchset again. This patchset helps in listing dtrace style markers(SDT) present in user space applications through perf. Notes/markers are placed at important places by the developers. They have a negligible overhead when not enabled. We can enable them and probe at these places and find some important information like the arguments' values, etc. We have lots of applications which use SDT markers today, like: Postgresql, MySql, Mozilla, Perl, Python, Java, Ruby, libvirt, QEMU, glib To add SDT markers into user applications: We need to have this header sys/sdt.h present. sys/sdt.h used is version 3. If not present, install systemtap-sdt-devel package (for fedora-18). Please refer to the Documentation patch (3rd patch in this series) to see how the SDT markers are added into a program. With this patchset, - Use perf to list the markers in the app: # perf list sdt ./user_app ./user_app : %user_app:foo_start %user_app:fun_start This link shows an example of marker probing with Systemtap: https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps Also, this link provides important info regarding SDT notes: http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation This patchset has undergone a lot of changes since it was first introduced. Hence, the patchset has now been subdivided for more simplicity and ease of review (thanks to the suggestion from Namhyung Kim). This contains the first 2 of the 4 patches as suggested here: https://lkml.org/lkml/2014/7/20/284 - Markers in binaries : These SDT markers are present in the ELF in the section named ".note.stapsdt". Here, the name of the marker, its provider, type, location, base address, semaphore address. We can retrieve these values using the members name_off and desc_off in Nhdr structure. If these are not enabled, they are present in the ELF as nop. Changes since last series : - Subdivided the previous patchset into 4 patches to make it easier to review as suggested by Namhyung Kim. (This set includes first two of the four patches) - Made the required changes and some optimizations suggested by Masami, Namhyung and Andi. TODO: - Listing SDT events present in most of the binaries present in a system. - Maintaining a cache of the SDT events for faster lookup. - Add support to probe these SDT markers and integrate with a previous patch (support to perf to probe SDT markers) posted in lkml. https://lkml.org/lkml/2013/10/23/10 - Recognizing arguments and support to probe on them. - Add semaphore support. --- Hemant Kumar (3): Raw SDT parsing functions Support perf-list to print SDT events in a single file Adds documentation for perf support to SDT events. tools/perf/Documentation/SDT-support.txt | 48 ++ tools/perf/Documentation/perf-list.txt |4 tools/perf/Makefile.perf |1 tools/perf/builtin-list.c|2 tools/perf/util/parse-events.h |2 tools/perf/util/sdt.c| 113 ++ tools/perf/util/symbol-elf.c | 244 ++ tools/perf/util/symbol.h | 19 ++ 8 files changed, 432 insertions(+), 1 deletion(-) create mode 100644 tools/perf/Documentation/SDT-support.txt create mode 100644 tools/perf/util/sdt.c -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)
> -Original Message- > From: Dexuan Cui > Sent: Wednesday, August 27, 2014 8:22 PM > To: KY Srinivasan; Sitsofe Wheeler > Cc: Greg Kroah-Hartman; Haiyang Zhang; de...@linuxdriverproject.org; > linux-kernel@vger.kernel.org > Subject: RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at > 88007784 (hv_ringbuffer_write) > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of KY Srinivasan > > Sent: Thursday, August 28, 2014 7:14 AM > > > > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > > > > Sent: Wednesday, August 27, 2014 9:19 AM > > > > > > > > > > > BTW, with the patch below, hyperv_fb can work now, BUT, > > > > > > *occasionally*, > > > > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to > > > > > > HV_STATUS_INVALID_ALIGNMENT... > > > > > > > > > > I applied your new patch on top of KY's pieces (it applied > > > > > cleanly) and while it doesn't blow up, one warning is printed > > > > > out and the UP boot seemed to stall after input: TPPS/2 message > > > > > (but pressing ctrl-alt-delete allows the system to reboot cleanly). > > > > > > > > First let me thank you guys for looking into this issue. Looking > > > > at your dmesg, it looked like storvsc probe failed as Dexuan had seen. > > > > Since the failure appears to be alignment related, perhaps we > > > > could test with allocating a page all the time (and getting rid of > > > > the kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If > > > > this works, I will probably minimize failure cases by > > > > pre-allocating per-cpu pages for this.: > > > > > > After some modifications to apply on top of your previous patches > > applying > > > this latest patch has cured the issues surrounding hyperv_fb issues > > > on > > boot. > > This always-use-page-allocation patch of KY works for me too. :-) > > > > > The only issue seen on boot now is similar to > > > https://lkml.org/lkml/2014/8/19/227 ... > Hi Sitsofe, > I don't see this issue. > Do you still see the issue for EVERY boot after you applied KY's always-use- > page-allocation patch? > I doubt that because in the log of the above link: > > [ 34.628072] hv_netvsc vmbus_0_15: net device safe to remove > [ 34.676573] hv_netvsc: hv_netvsc channel opened successfully > [ 34.860292] hv_netvsc vmbus_0_15 eth1: unable to establish send buffer's > gpadl > [ 34.948983] hv_netvsc vmbus_0_15 eth1: unable to connect to NetVSP - 4 > > Here the 4 is just HV_STATUS_INVALID_ALIGNMENT -- it should be fixed by > the patch. > > > > > That is good to hear. I was under the impression that this issue would > > be resolved with all the cleanup we have done. The last patch-set I > > posted earlier today has the fix for vmbus_open bug that Dexuan had > identified. > > > > If you could try with the BUG_ON elimination patch-set I sent out > > earlier today with the fix in hv.c that I had sent that would be great. > > > > > > How come previous alignment efforts weren't working out? > I'm not sure. > If we trust the hypervisor, I would guess in hv_post_message() > 1) We'd better add "aligned_msg->reserved = 0;" > 2) Should we make sure "aligned_msg->payload_size % 8 == 0"? IMO >aligned_msg->payload is an array of 8-byte. > > > I have chosen to always allocate a page and so alignment won't be an > > issue. I want to eliminate failure in this path and so, I will most > > likely do a per-cpu pre-allocation of this buffer. > This is a good idea! Thank you all. I will submit a patch with the pre-allocated per-cpu page for this. K. Y > > Thanks, > -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 13/17] arcmsr: fix ioctl data read/write error for adapter type C
On Wed, 2014-08-27 at 14:29 +0200, Tomas Henzl wrote:
> On 08/27/2014 10:19 PM, Ching Huang wrote:
> > On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote:
> >> On 08/26/2014 10:27 PM, Ching Huang wrote:
> >>> On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote:
> On 08/25/2014 07:59 PM, Ching Huang wrote:
> > On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote:
> >> On 08/19/2014 09:17 AM, Ching Huang wrote:
> >>> From: Ching Huang
> >>>
> >>> Rewrite ioctl entry and its relate function.
> >>> This patch fix ioctl data read/write error and change data I/O access
> >>> from byte to Dword.
> >>>
> >>> Signed-off-by: Ching Huang
> >>> ---
> >>>
> >>> diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c
> >>> b/drivers/scsi/arcmsr/arcmsr_attr.c
> >>> --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06
> >>> 17:47:24.0 +0800
> >>> +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29
> >>> 17:10:42.0 +0800
> >>> @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
> >>> struct AdapterControlBlock *acb = (struct AdapterControlBlock
> >>> *) host->hostdata;
> >>> uint8_t *pQbuffer,*ptmpQbuffer;
> >>> int32_t allxfer_len = 0;
> >>> + unsigned long flags;
> >>>
> >>> if (!capable(CAP_SYS_ADMIN))
> >>> return -EACCES;
> >>>
> >>> /* do message unit read. */
> >>> ptmpQbuffer = (uint8_t *)buf;
> >>> - while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
> >>> - && (allxfer_len < 1031)) {
> >>> + spin_lock_irqsave(&acb->rqbuffer_lock, flags);
> >>> + if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) {
> >> Hi - does this condition (acb->rqbuf_firstindex ==
> >> acb->rqbuf_lastindex) mean we could just release
> >> the spinlock and return ?
> >>
> > NO. We have to check the input buffer that may have message data come
> > from IOP.
> >>> pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex];
> >>> - memcpy(ptmpQbuffer, pQbuffer, 1);
> >>> - acb->rqbuf_firstindex++;
> >>> - acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
> >>> - ptmpQbuffer++;
> >>> - allxfer_len++;
> >>> + if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) {
> >>> + if ((ARCMSR_MAX_QBUFFER -
> >>> acb->rqbuf_firstindex) >= 1032) {
> >>> + memcpy(ptmpQbuffer, pQbuffer, 1032);
> >>> + acb->rqbuf_firstindex += 1032;
> >>> + acb->rqbuf_firstindex %=
> >>> ARCMSR_MAX_QBUFFER;
> >>> + allxfer_len = 1032;
> >>> + } else {
> >>> + if (((ARCMSR_MAX_QBUFFER -
> >>> acb->rqbuf_firstindex)
> >>> + + acb->rqbuf_lastindex) > 1032)
> >>> {
> >>> + memcpy(ptmpQbuffer, pQbuffer,
> >>> + ARCMSR_MAX_QBUFFER
> >>> + -
> >>> acb->rqbuf_firstindex);
> >>> + ptmpQbuffer +=
> >>> ARCMSR_MAX_QBUFFER
> >>> + - acb->rqbuf_firstindex;
> >>> + memcpy(ptmpQbuffer,
> >>> acb->rqbuffer, 1032
> >>> + - (ARCMSR_MAX_QBUFFER -
> >>> + acb->rqbuf_firstindex));
> >> This code looks like you were copying some data from a ring buffer,
> >> in that case - shouldn't be acb->rqbuf_lastindex used instead of
> >> firstindex?
> >>
> > Yes, there copying data from a ring buffer. firstindex and lastindex are
> > bad name. For readability, I rename the firstindex to getIndex,
> > lastindex to putIndex.
> My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER -
> acb->rqbuf_firstindex)+ acb->rqbuf_lastindex) > 1032)'
> you copy something twice and in both cases the 'firstindex' is used and
> never the 'lastindex'.
> Is this correct?
> >>> The firstindex is a get index and lastindex is a put index of a ring
> >>> buffer.
> >>> At here, firstindex > lastindex, so the data remain in buffer are
> >>> (ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex)+ acb->rqbuf_lastindex
> >> Yes, it's correct, I misinterpreted the from value with the amount of
> >> bytes to copy.
> >> But well it's also still overcomplicated and I believe that a copy like
> >> this could be
> >> rearranged with just few lines of code as a result - have you looked at
> >> the code I sent?
> >>
> >> Let's go with this patch as it is otherwise we will neve
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
Hi, On Wed, Aug 27, 2014 at 7:58 PM, Olof Johansson wrote: > On Wed, Aug 27, 2014 at 5:56 PM, Stephen Boyd wrote: >> On 08/27/14 15:33, Olof Johansson wrote: >>> On Wed, Aug 27, 2014 at 3:26 PM, Stephen Boyd wrote: >>> Is there any reason why the virtual counter can't be read? Maybe we're the hyp and we need to make sure we don't use the virtual timer so that the guest can use it, but that doesn't have any effect on the usage of the virtual counter for the clocksource. >>> There are several cases where virtual is unusable -- in particular it >>> might not have been configured properly (i.e. the phys/virt offset is >>> at a bad value). >>> >> >> Any specifics? It would be nice to say so in the commit text so that >> others using such devices know they need this patch. I'm guessing the >> firmware can't be fixed? Even if we could change things to use a virtual timer in some cases, Sonny's patch still fixes a bug. The code as written right now makes pretenses about supporting the physical timer, but it doesn't work. That should be fixed. > Yeah, there are a few. The big.LITTLE on the Chromebook 2 models have > this issue, due to the A7 cluster having an incorrect offset > programmed. However, arch timers aren't supported on that SoC in the > first place, so it's not a problem in reality. > > The other known platform is rk3288. It has products out in the wild > where firmware updates are unlikely. One other reason is that (I'm told) that the virtual offset is lost in certain power down conditions (powering down a core, going into S3, etc). When we power back up the offset is effectively reset to a random value. That means we need something to reprogram the virtual timer offset whenever we power things back up. If we've got a hypervisor then the hypervisor will definitely be involved in powering things back up and it can reset the virtual offset. ...but forcing systems to implement a hypervisor (or somehow adding an interface for the kernel to call back into firmware) is a huge effort and it means more hard-to-update code sitting in firmware. Note: having the virtual offset initted to a random value seems like an unfortunate design choice for the virtual timer offset (guaranteeing it was initted to 0 would have avoided the problem), but that's what we seem to have. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: stmmac: fix warning from Sparse for socfpga
On Thu, Aug 28, 2014 at 7:33 AM, David Miller wrote: > From: Ley Foon Tan > Date: Tue, 26 Aug 2014 15:11:16 +0800 > >> @@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac >> *dwmac, struct device * >> return -EINVAL; >> } >> >> - dwmac->splitter_base = (void *)devm_ioremap_resource(dev, >> + dwmac->splitter_base = >> + (void __iomem *)devm_ioremap_resource(dev, >> &res_splitter); > > Please either put this entire call on one line (it'll only be slightly > over 80 columns, which is fine), or indent it properly. > > And by properly I meant that the second and subsequent lines of a function > call must be indented precisely to the first column after the openning > parenthesis of the function call on the first line. You must use the > appropriate number of TAB and SPACE characters necessary to do so. > > If it is indented using only TAB characters, it is very likely that you > are doing it wrong. Okay, will send in new patch to fix this. 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] checkpatch: Allow commit descriptions on separate line from commit id
On Wed, 27 Aug 2014, Joe Perches wrote:
> The general form for commit id and description is
>
> 'Commit <12+hexdigits> ("commit description/subject line")'
>
> But commit logs often have relatively long commit ids and
> the commit description is on a separate line like:
>
> Some explanation as to why commit <12+hexdigits>
> ("commit description/subject line") is improved.
>
> Allow this form.
>
> Signed-off-by: Joe Perches
> Suggested-by: Joe Lawrence '. (Maybe another checkpatch validation
for another day?)
Thanks,
-- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of KY Srinivasan > Sent: Thursday, August 28, 2014 7:14 AM > > > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > > > Sent: Wednesday, August 27, 2014 9:19 AM > > > > > > > > > BTW, with the patch below, hyperv_fb can work now, BUT, > > > > > *occasionally*, > > > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to > > > > > HV_STATUS_INVALID_ALIGNMENT... > > > > > > > > I applied your new patch on top of KY's pieces (it applied cleanly) > > > > and while it doesn't blow up, one warning is printed out and the UP > > > > boot seemed to stall after input: TPPS/2 message (but pressing > > > > ctrl-alt-delete allows the system to reboot cleanly). > > > > > > First let me thank you guys for looking into this issue. Looking at > > > your dmesg, it looked like storvsc probe failed as Dexuan had seen. > > > Since the failure appears to be alignment related, perhaps we could > > > test with allocating a page all the time (and getting rid of the > > > kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If this > > > works, I will probably minimize failure cases by pre-allocating > > > per-cpu pages for this.: > > > > After some modifications to apply on top of your previous patches > applying > > this latest patch has cured the issues surrounding hyperv_fb issues on > boot. This always-use-page-allocation patch of KY works for me too. :-) > > The only issue seen on boot now is similar to > > https://lkml.org/lkml/2014/8/19/227 ... Hi Sitsofe, I don't see this issue. Do you still see the issue for EVERY boot after you applied KY's always-use-page-allocation patch? I doubt that because in the log of the above link: [ 34.628072] hv_netvsc vmbus_0_15: net device safe to remove [ 34.676573] hv_netvsc: hv_netvsc channel opened successfully [ 34.860292] hv_netvsc vmbus_0_15 eth1: unable to establish send buffer's gpadl [ 34.948983] hv_netvsc vmbus_0_15 eth1: unable to connect to NetVSP - 4 Here the 4 is just HV_STATUS_INVALID_ALIGNMENT -- it should be fixed by the patch. > > That is good to hear. I was under the impression that this issue would be > resolved with all the cleanup we have done. The last patch-set I posted > earlier today has the fix for vmbus_open bug that Dexuan had identified. > > If you could try with the BUG_ON elimination patch-set I sent out earlier > today with the fix in hv.c that I had sent that would be great. > > > > How come previous alignment efforts weren't working out? I'm not sure. If we trust the hypervisor, I would guess in hv_post_message() 1) We'd better add "aligned_msg->reserved = 0;" 2) Should we make sure "aligned_msg->payload_size % 8 == 0"? IMO aligned_msg->payload is an array of 8-byte. > I have chosen to always allocate a page and so alignment won't be > an issue. I want to eliminate failure in this path and so, I will most likely > do a per-cpu pre-allocation of this buffer. This is a good idea! Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESULT] sched: Rewrite per entity runnable load average tracking v5
Hi all, We finished a round of tests for AIM7 workload for the patch v5 by LKP, the result is as follows: Hostname: brickland3 Model: Brickland Ivy Bridge-E CPU: 120 Memory: 512G v3.16-rc7 rewrite-v5 testbox/testcase/testparams --- - --- %stddev%change %stddev \ | / 26317 ± 3% +34.7% 35437 ± 1% brickland3/aim7/2000-fork_test 43481 ± 0% +0.5% 43712 ± 0% brickland3/aim7/3000-brk_test 80810 ± 0% -0.2% 80625 ± 1% brickland3/aim7/3000-sieve 489830 ± 1% +14.7% 561691 ± 1% brickland3/aim7/8000-disk_src 1672643 ±12% -13.0%1455960 ± 6% brickland3/aim7/8000-disk_wrt 1193986 ± 0% -1.5%1175841 ± 0% brickland3/aim7/8000-mem_rtns_1 875113 ±13% +21.9%1067191 ±13% brickland3/aim7/8000-misc_rtns_1 1188420 ± 1% -3.2%1150624 ± 0% brickland3/aim7/8000-sort_rtns_1 807986 ± 0% -0.7% 802275 ± 0% brickland3/aim7/8000-string_rtns 6378589 ± 5% -0.1%6373359 ± 4% TOTAL aim7.jobs-per-min --- - 339 ± 7% -22.9%262 ± 0% brickland3/aim7/2000-fork_test 463 ± 0% +0.4%465 ± 0% brickland3/aim7/3000-brk_test 337 ± 9% -3.1%327 ± 6% brickland3/aim7/3000-disk_rd 534 ± 0% +0.9%539 ± 0% brickland3/aim7/3000-sieve 391 ± 0% -10.7%349 ± 1% brickland3/aim7/8000-disk_src 301 ± 4% +10.0%331 ± 5% brickland3/aim7/8000-disk_wrt 405 ± 1% +6.0%429 ± 0% brickland3/aim7/8000-mem_rtns_1 227 ±25% -0.8%225 ±12% brickland3/aim7/8000-misc_rtns_1 395 ± 1% +5.1%415 ± 0% brickland3/aim7/8000-sort_rtns_1 419 ± 0% +4.6%438 ± 0% brickland3/aim7/8000-string_rtns 3815 ± 3% -0.8% 3784 ± 2% TOTAL turbostat.Pkg_W --- - 90.79 ± 1% -15.1% 77.04 ± 0% brickland3/aim7/2000-fork_test 62.42 ± 0% -0.0% 62.41 ± 0% brickland3/aim7/3000-brk_test 61.69 ± 2% -1.3% 60.92 ± 2% brickland3/aim7/3000-disk_rd 137.13 ± 0% +0.2% 137.39 ± 0% brickland3/aim7/3000-sieve 66.03 ± 1% +0.6% 66.41 ± 0% brickland3/aim7/8000-disk_src 53.94 ± 2% +6.1% 57.21 ± 0% brickland3/aim7/8000-disk_wrt 54.43 ± 0% +4.8% 57.02 ± 0% brickland3/aim7/8000-mem_rtns_1 58.71 ± 2% +0.0% 58.72 ± 1% brickland3/aim7/8000-misc_rtns_1 53.78 ± 1% +4.8% 56.36 ± 0% brickland3/aim7/8000-sort_rtns_1 56.47 ± 2% +2.5% 57.89 ± 0% brickland3/aim7/8000-string_rtns 695.38 ± 1% -0.6% 691.37 ± 1% TOTAL turbostat.RAM_W --- - 23.40 ±22% -16.2% 19.60 ± 1% brickland3/aim7/2000-fork_test 97.28 ± 0% -0.0% 97.25 ± 0% brickland3/aim7/3000-brk_test 35.09 ±24% -8.7% 32.05 ±21% brickland3/aim7/3000-disk_rd 94.92 ± 0% -0.0% 94.88 ± 0% brickland3/aim7/3000-sieve 41.04 ± 2% -26.8% 30.06 ± 3% brickland3/aim7/8000-disk_src 36.54 ±11% -10.2% 32.82 ±12% brickland3/aim7/8000-disk_wrt 61.39 ± 2% -7.4% 56.87 ± 1% brickland3/aim7/8000-mem_rtns_1 62.57 ± 4% -11.1% 55.64 ± 3% brickland3/aim7/8000-sort_rtns_1 76.06 ± 2% -3.4% 73.51 ± 0% brickland3/aim7/8000-string_rtns 528.30 ± 4% -6.7% 492.67 ± 3% TOTAL turbostat.%c0 For performance, I think the overall is flat. For power, we can see some benefits. In perticular, the stddev indicates the variation is smaller than v3.16-rc7 (all subtests are done at least for 5 times). To Jason, the format or specific metric is not directly comparable with your tests. If you can specify how to get the same look as your tests, we are happy to try. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/7] MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/lantiq/
Move the Lantiq device-trees to arch/mips/boot/dts/lantiq/ and update
the Makefiles accordingly. There is currently only a single Lantiq
device-tree (EASY50712), and it's required to be built into the kernel,
so select BUILTIN_DTB for it.
Signed-off-by: Andrew Bresticker
---
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/lantiq/Makefile | 1 +
arch/mips/{lantiq/dts => boot/dts/lantiq}/danube.dtsi | 0
arch/mips/{lantiq/dts => boot/dts/lantiq}/easy50712.dts | 0
arch/mips/lantiq/Kconfig| 1 +
arch/mips/lantiq/Makefile | 2 --
arch/mips/lantiq/dts/Makefile | 1 -
7 files changed, 3 insertions(+), 3 deletions(-)
create mode 100644 arch/mips/boot/dts/lantiq/Makefile
rename arch/mips/{lantiq/dts => boot/dts/lantiq}/danube.dtsi (100%)
rename arch/mips/{lantiq/dts => boot/dts/lantiq}/easy50712.dts (100%)
delete mode 100644 arch/mips/lantiq/dts/Makefile
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index a8daed1..0f16e92 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,4 +1,5 @@
include arch/mips/boot/dts/cavium-octeon/Makefile
+include arch/mips/boot/dts/lantiq/Makefile
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/boot/dts/lantiq/Makefile
b/arch/mips/boot/dts/lantiq/Makefile
new file mode 100644
index 000..d68f45a
--- /dev/null
+++ b/arch/mips/boot/dts/lantiq/Makefile
@@ -0,0 +1 @@
+dtb-$(CONFIG_DT_EASY50712) += lantiq/easy50712.dtb
diff --git a/arch/mips/lantiq/dts/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
similarity index 100%
rename from arch/mips/lantiq/dts/danube.dtsi
rename to arch/mips/boot/dts/lantiq/danube.dtsi
diff --git a/arch/mips/lantiq/dts/easy50712.dts
b/arch/mips/boot/dts/lantiq/easy50712.dts
similarity index 100%
rename from arch/mips/lantiq/dts/easy50712.dts
rename to arch/mips/boot/dts/lantiq/easy50712.dts
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index c002191..e10d333 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -30,6 +30,7 @@ choice
config DT_EASY50712
bool "Easy50712"
depends on SOC_XWAY
+ select BUILTIN_DTB
endchoice
config PCI_LANTIQ
diff --git a/arch/mips/lantiq/Makefile b/arch/mips/lantiq/Makefile
index d6bdc57..690257a 100644
--- a/arch/mips/lantiq/Makefile
+++ b/arch/mips/lantiq/Makefile
@@ -6,8 +6,6 @@
obj-y := irq.o clk.o prom.o
-obj-y += dts/
-
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_SOC_TYPE_XWAY) += xway/
diff --git a/arch/mips/lantiq/dts/Makefile b/arch/mips/lantiq/dts/Makefile
deleted file mode 100644
index 6fa72dd..000
--- a/arch/mips/lantiq/dts/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_DT_EASY50712) := easy50712.dtb.o
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/netlogic/
Move the Netlogic XLP device-trees to arch/mips/boot/dts/netlogic/ and
update the Makefiles accordingly. A built-in device-tree is optional,
so select BUILTIN_DTB when it is requested.
Signed-off-by: Andrew Bresticker
---
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/netlogic/Makefile | 4
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_evp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_fvp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_gvp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_svp.dts | 0
arch/mips/netlogic/Kconfig| 4
arch/mips/netlogic/Makefile | 1 -
arch/mips/netlogic/dts/Makefile | 4
9 files changed, 9 insertions(+), 5 deletions(-)
create mode 100644 arch/mips/boot/dts/netlogic/Makefile
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_evp.dts (100%)
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_fvp.dts (100%)
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_gvp.dts (100%)
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_svp.dts (100%)
delete mode 100644 arch/mips/netlogic/dts/Makefile
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index e32cc0f..a861be5 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,6 +1,7 @@
include arch/mips/boot/dts/cavium-octeon/Makefile
include arch/mips/boot/dts/lantiq/Makefile
include arch/mips/boot/dts/mti/Makefile
+include arch/mips/boot/dts/netlogic/Makefile
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/boot/dts/netlogic/Makefile
b/arch/mips/boot/dts/netlogic/Makefile
new file mode 100644
index 000..d15f045
--- /dev/null
+++ b/arch/mips/boot/dts/netlogic/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_DT_XLP_EVP) += netlogic/xlp_evp.dtb
+dtb-$(CONFIG_DT_XLP_SVP) += netlogic/xlp_svp.dtb
+dtb-$(CONFIG_DT_XLP_FVP) += netlogic/xlp_fvp.dtb
+dtb-$(CONFIG_DT_XLP_GVP) += netlogic/xlp_gvp.dtb
diff --git a/arch/mips/netlogic/dts/xlp_evp.dts
b/arch/mips/boot/dts/netlogic/xlp_evp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_evp.dts
rename to arch/mips/boot/dts/netlogic/xlp_evp.dts
diff --git a/arch/mips/netlogic/dts/xlp_fvp.dts
b/arch/mips/boot/dts/netlogic/xlp_fvp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_fvp.dts
rename to arch/mips/boot/dts/netlogic/xlp_fvp.dts
diff --git a/arch/mips/netlogic/dts/xlp_gvp.dts
b/arch/mips/boot/dts/netlogic/xlp_gvp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_gvp.dts
rename to arch/mips/boot/dts/netlogic/xlp_gvp.dts
diff --git a/arch/mips/netlogic/dts/xlp_svp.dts
b/arch/mips/boot/dts/netlogic/xlp_svp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_svp.dts
rename to arch/mips/boot/dts/netlogic/xlp_svp.dts
diff --git a/arch/mips/netlogic/Kconfig b/arch/mips/netlogic/Kconfig
index 4eb683a..0823321 100644
--- a/arch/mips/netlogic/Kconfig
+++ b/arch/mips/netlogic/Kconfig
@@ -4,6 +4,7 @@ if NLM_XLP_BOARD
config DT_XLP_EVP
bool "Built-in device tree for XLP EVP boards"
default y
+ select BUILTIN_DTB
help
Add an FDT blob for XLP EVP boards into the kernel.
This DTB will be used if the firmware does not pass in a DTB
@@ -13,6 +14,7 @@ config DT_XLP_EVP
config DT_XLP_SVP
bool "Built-in device tree for XLP SVP boards"
default y
+ select BUILTIN_DTB
help
Add an FDT blob for XLP VP boards into the kernel.
This DTB will be used if the firmware does not pass in a DTB
@@ -22,6 +24,7 @@ config DT_XLP_SVP
config DT_XLP_FVP
bool "Built-in device tree for XLP FVP boards"
default y
+ select BUILTIN_DTB
help
Add an FDT blob for XLP FVP board into the kernel.
This DTB will be used if the firmware does not pass in a DTB
@@ -31,6 +34,7 @@ config DT_XLP_FVP
config DT_XLP_GVP
bool "Built-in device tree for XLP GVP boards"
default y
+ select BUILTIN_DTB
help
Add an FDT blob for XLP GVP board into the kernel.
This DTB will be used if the firmware does not pass in a DTB
diff --git a/arch/mips/netlogic/Makefile b/arch/mips/netlogic/Makefile
index 7602d13..36d169b 100644
--- a/arch/mips/netlogic/Makefile
+++ b/arch/mips/netlogic/Makefile
@@ -1,4 +1,3 @@
obj-$(CONFIG_NLM_COMMON) += common/
obj-$(CONFIG_CPU_XLR) += xlr/
obj-$(CONFIG_CPU_XLP) += xlp/
-obj-$(CONFIG_CPU_XLP) += dts/
diff --git a/arch/mips/netlogic/dts/Makefile b/arch/mips/netlogic/dts/Makefile
deleted file mode 100644
index 25c8e87..000
--- a/arch/mips/netlogic/dts/Makefile
+++ /dev/null
@@ -1,4 +0,0 @@
-obj-$(CONFIG_DT_XLP_EVP) := xlp_evp.dtb.o
-obj-$(CONFIG_DT_XLP_SVP) += xlp_svp.dtb.o
-obj-$(CONFIG_DT_XLP_FVP)
Re: [PATCH v5 3/4] zram: zram memory size limitation
On Wed, Aug 27, 2014 at 03:04:32PM -0400, Dan Streetman wrote:
> On Wed, Aug 27, 2014 at 12:59 PM, David Horner wrote:
> > On Wed, Aug 27, 2014 at 12:29 PM, Dan Streetman wrote:
> >> On Wed, Aug 27, 2014 at 11:35 AM, David Horner wrote:
> >>> On Wed, Aug 27, 2014 at 11:14 AM, Dan Streetman wrote:
> On Wed, Aug 27, 2014 at 10:44 AM, David Horner
> wrote:
> > On Wed, Aug 27, 2014 at 10:03 AM, Dan Streetman
> > wrote:
> >> On Tue, Aug 26, 2014 at 10:51 PM, Minchan Kim
> >> wrote:
> >>> Hey Joonsoo,
> >>>
> >>> On Wed, Aug 27, 2014 at 10:26:11AM +0900, Joonsoo Kim wrote:
> Hello, Minchan and David.
>
> On Tue, Aug 26, 2014 at 08:22:29AM -0400, David Horner wrote:
> > On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim
> > wrote:
> > > Hey Joonsoo,
> > >
> > > On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
> > >> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> > >> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram
> > >> > *zram, struct bio_vec *bvec, u32 index,
> > >> > ret = -ENOMEM;
> > >> > goto out;
> > >> > }
> > >> > +
> > >> > + if (zram->limit_pages &&
> > >> > + zs_get_total_pages(meta->mem_pool) >
> > >> > zram->limit_pages) {
> > >> > + zs_free(meta->mem_pool, handle);
> > >> > + ret = -ENOMEM;
> > >> > + goto out;
> > >> > + }
> > >> > +
> > >> > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
> > >>
> > >> Hello,
> > >>
> > >> I don't follow up previous discussion, so I could be wrong.
> > >> Why this enforcement should be here?
> > >>
> > >> I think that this has two problems.
> > >> 1) alloc/free happens unnecessarilly if we have used memory
> > >> over the
> > >> limitation.
> > >
> > > True but firstly, I implemented the logic in zsmalloc, not zram
> > > but
> > > as I described in cover-letter, it's not a requirement of
> > > zsmalloc
> > > but zram so it should be in there. If every user want it in
> > > future,
> > > then we could move the function into zsmalloc. That's what we
> > > concluded in previous discussion.
>
> Hmm...
> Problem is that we can't avoid these unnecessary overhead in this
> implementation. If we can implement this feature in zram efficiently,
> it's okay. But, I think that current form isn't.
> >>>
> >>>
> >>> If we can add it in zsmalloc, it would be more clean and efficient
> >>> for zram but as I said, at the moment, I didn't want to put zram's
> >>> requirement into zsmalloc because to me, it's weird to enforce max
> >>> limit to allocator. It's client's role, I think.
> >>>
> >>> If current implementation is expensive and rather hard to follow,
> >>> It would be one reason to move the feature into zsmalloc but
> >>> I don't think it makes critical trobule in zram usecase.
> >>> See below.
> >>>
> >>> But I still open and will wait others's opinion.
> >>> If other guys think zsmalloc is better place, I am willing to move
> >>> it into zsmalloc.
> >>
> >> Moving it into zsmalloc would allow rejecting new zsmallocs before
> >> actually crossing the limit, since it can calculate that internally.
> >> However, with the current patches the limit will only be briefly
> >> crossed, and it should not be crossed by a large amount. Now, if this
> >> is happening repeatedly and quickly during extreme memory pressure,
> >> the constant alloc/free will clearly be worse than a simple internal
> >> calculation and failure. But would it ever happen repeatedly once the
> >> zram limit is reached?
> >>
> >> Now that I'm thinking about the limit from the perspective of the zram
> >> user, I wonder what really will happen. If zram is being used for
> >> swap space, then when swap starts getting errors trying to write
> >> pages, how damaging will that be to the system? I haven't checked
> >> what swap does when it encounters disk errors. Of course, with no
> >> zram limit, continually writing to zram until memory is totally
> >> consumed isn't good either. But in any case, I would hope that swap
> >> would not repeatedly hammer on a disk when it's getting write failures
> >> from it.
> >>
> >> Alternately, if zram was being used as a compressed ram disk for
> >> regular file storage, it's entirely up to the application to handle
> >> write failures, so it may continue to try to write to a full zram
> >> disk.
> >>
> >> As
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
On Wed, Aug 27, 2014 at 5:56 PM, Stephen Boyd wrote: > On 08/27/14 15:33, Olof Johansson wrote: >> On Wed, Aug 27, 2014 at 3:26 PM, Stephen Boyd wrote: >> >>> Is there any reason why the virtual counter can't be read? Maybe we're >>> the hyp and we need to make sure we don't use the virtual timer so that >>> the guest can use it, but that doesn't have any effect on the usage of >>> the virtual counter for the clocksource. >> There are several cases where virtual is unusable -- in particular it >> might not have been configured properly (i.e. the phys/virt offset is >> at a bad value). >> > > Any specifics? It would be nice to say so in the commit text so that > others using such devices know they need this patch. I'm guessing the > firmware can't be fixed? Yeah, there are a few. The big.LITTLE on the Chromebook 2 models have this issue, due to the A7 cluster having an incorrect offset programmed. However, arch timers aren't supported on that SoC in the first place, so it's not a problem in reality. The other known platform is rk3288. It has products out in the wild where firmware updates are unlikely. Essentially, I expect many vendors who use BSP kernels by default to have firmware that forgets to setup the offset, since hardware doesn't come up with a default one, and their older BSP kernels doesn't access the virtual one. > In this particular case is there actually a virtual interrupt but we've > explicitly removed it from the DT so that the driver can be forced into > using the physical counter? Or are we getting saved by the hyp check? The SoC has the virtual timer, and if it has firmware that supports it there's a good reason to still have it there. After all, DT describes hardware. I have a patch I should post that adds a property to make the driver pick the physical timer instead, since right now it'll always use virtual if it's available. I'll try to get that posted later tonight. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/4] zram: zram memory size limitation
On Wed, Aug 27, 2014 at 12:29:22PM -0400, Dan Streetman wrote:
> On Wed, Aug 27, 2014 at 11:35 AM, David Horner wrote:
> > On Wed, Aug 27, 2014 at 11:14 AM, Dan Streetman wrote:
> >> On Wed, Aug 27, 2014 at 10:44 AM, David Horner wrote:
> >>> On Wed, Aug 27, 2014 at 10:03 AM, Dan Streetman wrote:
> On Tue, Aug 26, 2014 at 10:51 PM, Minchan Kim wrote:
> > Hey Joonsoo,
> >
> > On Wed, Aug 27, 2014 at 10:26:11AM +0900, Joonsoo Kim wrote:
> >> Hello, Minchan and David.
> >>
> >> On Tue, Aug 26, 2014 at 08:22:29AM -0400, David Horner wrote:
> >> > On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim
> >> > wrote:
> >> > > Hey Joonsoo,
> >> > >
> >> > > On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
> >> > >> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> >> > >> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram
> >> > >> > *zram, struct bio_vec *bvec, u32 index,
> >> > >> > ret = -ENOMEM;
> >> > >> > goto out;
> >> > >> > }
> >> > >> > +
> >> > >> > + if (zram->limit_pages &&
> >> > >> > + zs_get_total_pages(meta->mem_pool) >
> >> > >> > zram->limit_pages) {
> >> > >> > + zs_free(meta->mem_pool, handle);
> >> > >> > + ret = -ENOMEM;
> >> > >> > + goto out;
> >> > >> > + }
> >> > >> > +
> >> > >> > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
> >> > >>
> >> > >> Hello,
> >> > >>
> >> > >> I don't follow up previous discussion, so I could be wrong.
> >> > >> Why this enforcement should be here?
> >> > >>
> >> > >> I think that this has two problems.
> >> > >> 1) alloc/free happens unnecessarilly if we have used memory over
> >> > >> the
> >> > >> limitation.
> >> > >
> >> > > True but firstly, I implemented the logic in zsmalloc, not zram but
> >> > > as I described in cover-letter, it's not a requirement of zsmalloc
> >> > > but zram so it should be in there. If every user want it in future,
> >> > > then we could move the function into zsmalloc. That's what we
> >> > > concluded in previous discussion.
> >>
> >> Hmm...
> >> Problem is that we can't avoid these unnecessary overhead in this
> >> implementation. If we can implement this feature in zram efficiently,
> >> it's okay. But, I think that current form isn't.
> >
> >
> > If we can add it in zsmalloc, it would be more clean and efficient
> > for zram but as I said, at the moment, I didn't want to put zram's
> > requirement into zsmalloc because to me, it's weird to enforce max
> > limit to allocator. It's client's role, I think.
> >
> > If current implementation is expensive and rather hard to follow,
> > It would be one reason to move the feature into zsmalloc but
> > I don't think it makes critical trobule in zram usecase.
> > See below.
> >
> > But I still open and will wait others's opinion.
> > If other guys think zsmalloc is better place, I am willing to move
> > it into zsmalloc.
>
> Moving it into zsmalloc would allow rejecting new zsmallocs before
> actually crossing the limit, since it can calculate that internally.
> However, with the current patches the limit will only be briefly
> crossed, and it should not be crossed by a large amount. Now, if this
> is happening repeatedly and quickly during extreme memory pressure,
> the constant alloc/free will clearly be worse than a simple internal
> calculation and failure. But would it ever happen repeatedly once the
> zram limit is reached?
>
> Now that I'm thinking about the limit from the perspective of the zram
> user, I wonder what really will happen. If zram is being used for
> swap space, then when swap starts getting errors trying to write
> pages, how damaging will that be to the system? I haven't checked
> what swap does when it encounters disk errors. Of course, with no
> zram limit, continually writing to zram until memory is totally
> consumed isn't good either. But in any case, I would hope that swap
> would not repeatedly hammer on a disk when it's getting write failures
> from it.
>
> Alternately, if zram was being used as a compressed ram disk for
> regular file storage, it's entirely up to the application to handle
> write failures, so it may continue to try to write to a full zram
> disk.
>
> As far as what the zsmalloc api would look like with the limit added,
> it would need a setter and getter function (adding it as a param to
> the create function would be optional i think). But more importantly,
> it would need to handle multiple ways of specifying the limit. In our
> specific current use cases, zram and zswap, each handles their
> intern
Re: [PATCH v5 3/4] zram: zram memory size limitation
Hello,
On Wed, Aug 27, 2014 at 10:03:45AM -0400, Dan Streetman wrote:
> On Tue, Aug 26, 2014 at 10:51 PM, Minchan Kim wrote:
> > Hey Joonsoo,
> >
> > On Wed, Aug 27, 2014 at 10:26:11AM +0900, Joonsoo Kim wrote:
> >> Hello, Minchan and David.
> >>
> >> On Tue, Aug 26, 2014 at 08:22:29AM -0400, David Horner wrote:
> >> > On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim wrote:
> >> > > Hey Joonsoo,
> >> > >
> >> > > On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
> >> > >> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> >> > >> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram *zram,
> >> > >> > struct bio_vec *bvec, u32 index,
> >> > >> > ret = -ENOMEM;
> >> > >> > goto out;
> >> > >> > }
> >> > >> > +
> >> > >> > + if (zram->limit_pages &&
> >> > >> > + zs_get_total_pages(meta->mem_pool) > zram->limit_pages)
> >> > >> > {
> >> > >> > + zs_free(meta->mem_pool, handle);
> >> > >> > + ret = -ENOMEM;
> >> > >> > + goto out;
> >> > >> > + }
> >> > >> > +
> >> > >> > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
> >> > >>
> >> > >> Hello,
> >> > >>
> >> > >> I don't follow up previous discussion, so I could be wrong.
> >> > >> Why this enforcement should be here?
> >> > >>
> >> > >> I think that this has two problems.
> >> > >> 1) alloc/free happens unnecessarilly if we have used memory over the
> >> > >> limitation.
> >> > >
> >> > > True but firstly, I implemented the logic in zsmalloc, not zram but
> >> > > as I described in cover-letter, it's not a requirement of zsmalloc
> >> > > but zram so it should be in there. If every user want it in future,
> >> > > then we could move the function into zsmalloc. That's what we
> >> > > concluded in previous discussion.
> >>
> >> Hmm...
> >> Problem is that we can't avoid these unnecessary overhead in this
> >> implementation. If we can implement this feature in zram efficiently,
> >> it's okay. But, I think that current form isn't.
> >
> >
> > If we can add it in zsmalloc, it would be more clean and efficient
> > for zram but as I said, at the moment, I didn't want to put zram's
> > requirement into zsmalloc because to me, it's weird to enforce max
> > limit to allocator. It's client's role, I think.
> >
> > If current implementation is expensive and rather hard to follow,
> > It would be one reason to move the feature into zsmalloc but
> > I don't think it makes critical trobule in zram usecase.
> > See below.
> >
> > But I still open and will wait others's opinion.
> > If other guys think zsmalloc is better place, I am willing to move
> > it into zsmalloc.
>
> Moving it into zsmalloc would allow rejecting new zsmallocs before
> actually crossing the limit, since it can calculate that internally.
> However, with the current patches the limit will only be briefly
> crossed, and it should not be crossed by a large amount. Now, if this
> is happening repeatedly and quickly during extreme memory pressure,
> the constant alloc/free will clearly be worse than a simple internal
> calculation and failure. But would it ever happen repeatedly once the
> zram limit is reached?
Right. it depends on user.
If user writes continuously without any action to cover the situation
once the limit is over, it would be terrible but what I meant *terrible*
doesn't mean alloc/free cost. Actually, zsmalloc/zsfree cost is really
cheaper comparing to other mm reclaim, swap, vfs, fs, block layer's one.
What I meant *terrible* is slower system caused by swapout failure
on system but it try to reclaim anonymous pages continuously.
>
> Now that I'm thinking about the limit from the perspective of the zram
> user, I wonder what really will happen. If zram is being used for
> swap space, then when swap starts getting errors trying to write
> pages, how damaging will that be to the system? I haven't checked
> what swap does when it encounters disk errors. Of course, with no
> zram limit, continually writing to zram until memory is totally
> consumed isn't good either. But in any case, I would hope that swap
> would not repeatedly hammer on a disk when it's getting write failures
> from it.
Good point. Actually, it's my next step.
Curretly, VM doesn't handle congestion for anonymous page while it is
doing something for file-backed pages(but actually, it's really basic
stuff at this moment) so we could improve it with several ways.
I'm looking at it now.
>
> Alternately, if zram was being used as a compressed ram disk for
> regular file storage, it's entirely up to the application to handle
> write failures, so it may continue to try to write to a full zram
> disk.
>
> As far as what the zsmalloc api would look like with the limit added,
> it would need a setter and getter function (adding it as a param to
> the create function would be optional i think). But more importantly,
> it would need to handle multiple ways of specifying the limit. In our
> specific curr
[PATCH v2 2/7] MIPS: Add support for building device-tree binaries
Add a 'dtbs' Makefile target that just builds the device-tree binaries enabled by the configuration. Signed-off-by: Andrew Bresticker --- arch/mips/Makefile | 5 + arch/mips/boot/.gitignore | 1 + arch/mips/boot/dts/Makefile | 7 ++- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 72cdd6a..26672e1 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -330,6 +330,10 @@ core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/ %.dtb %.dtb.S %.dtb.o: | scripts $(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@ +PHONY += dtbs +dtbs: scripts + $(Q)$(MAKE) $(build)=arch/mips/boot/dts dtbs + archprepare: ifdef CONFIG_MIPS32_N32 @echo ' Checking missing-syscalls for N32' @@ -364,6 +368,7 @@ define archhelp echo ' vmlinuz.srec - SREC zboot image' echo ' uImage - U-Boot image' echo ' uImage.gz- U-Boot image (gzip)' + echo ' dtbs - Device-tree blobs for enabled boards' echo echo ' These will be default as appropriate for a configured platform.' endef diff --git a/arch/mips/boot/.gitignore b/arch/mips/boot/.gitignore index a73d6e2..d3962cd 100644 --- a/arch/mips/boot/.gitignore +++ b/arch/mips/boot/.gitignore @@ -5,3 +5,4 @@ zImage zImage.tmp calc_vmlinuz_load_addr uImage +*.dtb diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile index 0fef69d..dcb7810 100644 --- a/arch/mips/boot/dts/Makefile +++ b/arch/mips/boot/dts/Makefile @@ -1,3 +1,8 @@ obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y)) -clean-files+= */*.dtb.S +targets+= dtbs +targets+= $(dtb-y) + +dtbs: $(addprefix $(obj)/, $(dtb-y)) + +clean-files+= */*.dtb */*.dtb.S -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/3] jbd/jbd2: allocate buffer-cache for superblock inode in non-movable area
A long-lasting buffer-cache can distrub page migration so that
it must be allocated from non-movable area.
The journal_init_inode is creating a buffer-cache for superblock journaling.
The superblock exists until system shutdown so that the buffer-cache
for the superblock would also exist for a long time
and it can distrub page migration.
This patch make the buffer-cache be allocated from non-movable area
not to distrub page migration.
Signed-off-by: Gioh Kim
---
fs/jbd/journal.c |2 +-
fs/jbd2/journal.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 06fe11e..aab8549 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -886,7 +886,7 @@ journal_t * journal_init_inode (struct inode *inode)
goto out_err;
}
- bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+ bh = getblk_unmovable(journal->j_dev, blocknr, journal->j_blocksize);
if (!bh) {
printk(KERN_ERR
"%s: Cannot get buffer for journal superblock\n",
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 67b8e30..65bd3b1 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1237,7 +1237,7 @@ journal_t * jbd2_journal_init_inode (struct inode *inode)
goto out_err;
}
- bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+ bh = getblk_unmovable(journal->j_dev, blocknr, journal->j_blocksize);
if (!bh) {
printk(KERN_ERR
"%s: Cannot get buffer for journal superblock\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, Nothing major, one core oops fixes, some radeon oops fixes, some sti driver fixups, msm driver fixes and a minor Kconfig update for the ww mutex debugging. Dave. The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to b8d758d29fda0ece817237718909ed2622f024f1: drm/ast: Add missing entry to dclk_table[] (2014-08-28 12:26:42 +1000) Alex Deucher (1): drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2) Alex Williamson (1): radeon: Test for PCI root bus before assuming bus->self Christian König (1): drm/radeon: save/restore the PD addr on suspend/resume Dave Airlie (3): Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'msm-fixes-3.17' of git://people.freedesktop.org/~robclark/linux into drm-fixes Merge branch 'drm-3.17-rc2-sti-fixes' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-fixes David Herrmann (1): drm: fix division-by-zero on dumb_create() Jingoo Han (1): drm: sti: Add missing dependency on RESET_CONTROLLER Kiran Padwal (1): drm: sti: Make of_device_id array const Rob Clark (4): drm/msm: avoid flood of kernel logs on faults drm/msm/mdp4: request vblank during modeset drm/msm: fix compile error for non-dt builds ww-mutex: clarify help text for DEBUG_WW_MUTEX_SLOWPATH Wei Yongjun (5): drm: sti: tvout: fix return value check in sti_tvout_probe() drm: sti: hdmi: fix return value check in sti_hdmi_probe() drm: sti: hda: fix return value check in sti_hda_probe() drm: sti: Fix return value check in sti_drm_platform_probe() drm/msm: Fix missing unlock on error in msm_fbdev_create() Y.C. Chen (1): drm/ast: Add missing entry to dclk_table[] drivers/gpu/drm/ast/ast_tables.h | 1 + drivers/gpu/drm/drm_crtc.c | 3 ++- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 2 ++ drivers/gpu/drm/msm/msm_drv.c| 3 +-- drivers/gpu/drm/msm/msm_fbdev.c | 2 +- drivers/gpu/drm/msm/msm_iommu.c | 4 ++-- drivers/gpu/drm/radeon/cik.c | 26 +++--- drivers/gpu/drm/radeon/ni.c | 9 - drivers/gpu/drm/radeon/r600.c| 26 -- drivers/gpu/drm/radeon/radeon.h | 2 ++ drivers/gpu/drm/radeon/rv770.c | 23 --- drivers/gpu/drm/radeon/si.c | 21 ++--- drivers/gpu/drm/sti/Kconfig | 1 + drivers/gpu/drm/sti/sti_drm_drv.c| 4 ++-- drivers/gpu/drm/sti/sti_hda.c| 10 +- drivers/gpu/drm/sti/sti_hdmi.c | 10 +- drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- lib/Kconfig.debug| 4 18 files changed, 92 insertions(+), 65 deletions(-)
[PATCHv3 2/3] ext4: allocate buffer-cache for superblock in, non-movable area
A buffer-cache for superblock is disturbing page migration,
because the buffer-cache is not released until unmount.
The buffer-cache must be allocated from non-movable area.
Signed-off-by: Gioh Kim
---
fs/ext4/super.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 32b43ad..e4b62b3 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3435,7 +3435,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
logical_sb_block = sb_block;
}
- if (!(bh = sb_bread(sb, logical_sb_block))) {
+ if (!(bh = sb_bread_unmovable(sb, logical_sb_block))) {
ext4_msg(sb, KERN_ERR, "unable to read superblock");
goto out_fail;
}
@@ -3645,7 +3645,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
brelse(bh);
logical_sb_block = sb_block * EXT4_MIN_BLOCK_SIZE;
offset = do_div(logical_sb_block, blocksize);
- bh = sb_bread(sb, logical_sb_block);
+ bh = sb_bread_unmovable(sb, logical_sb_block);
if (!bh) {
ext4_msg(sb, KERN_ERR,
"Can't read superblock on 2nd try");
@@ -3867,7 +3867,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
for (i = 0; i < db_count; i++) {
block = descriptor_loc(sb, logical_sb_block, i);
- sbi->s_group_desc[i] = sb_bread(sb, block);
+ sbi->s_group_desc[i] = sb_bread_unmovable(sb, block);
if (!sbi->s_group_desc[i]) {
ext4_msg(sb, KERN_ERR,
"can't read group descriptor %d", i);
--
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/
[PATCHv3 1/3] fs/buffer.c: allocate buffer cache with user specific flag
A buffer cache is allocated from movable area
because it is referred for a while and released soon.
But some filesystems are taking buffer cache for a long time
and it can disturb page migration.
New APIs are introduced to allocate buffer cache
with user specific flag.
*_gfp APIs are for user want to set page allocation flag for page cache
allocation.
And *_unmovable APIs are for the user wants to allocate page cache from
non-movable area.
Signed-off-by: Gioh Kim
---
fs/buffer.c | 54 +--
include/linux/buffer_head.h | 14 ++-
2 files changed, 55 insertions(+), 13 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 8f05111..ee29bc4 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -993,7 +993,7 @@ init_page_buffers(struct page *page, struct block_device
*bdev,
*/
static int
grow_dev_page(struct block_device *bdev, sector_t block,
- pgoff_t index, int size, int sizebits)
+ pgoff_t index, int size, int sizebits, gfp_t gfp)
{
struct inode *inode = bdev->bd_inode;
struct page *page;
@@ -1002,10 +1002,10 @@ grow_dev_page(struct block_device *bdev, sector_t block,
int ret = 0;/* Will call free_more_memory() */
gfp_t gfp_mask;
- gfp_mask = mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS;
- gfp_mask |= __GFP_MOVABLE;
+ gfp_mask = (mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS) | gfp;
+
/*
-* XXX: __getblk_slow() can not really deal with failure and
+* XXX: __getblk_gfp() can not really deal with failure and
* will endlessly loop on improvised global reclaim. Prefer
* looping in the allocator rather than here, at least that
* code knows what it's doing.
@@ -1058,7 +1058,7 @@ failed:
* that page was dirty, the buffers are set dirty also.
*/
static int
-grow_buffers(struct block_device *bdev, sector_t block, int size)
+grow_buffers(struct block_device *bdev, sector_t block, int size, gfp_t gfp)
{
pgoff_t index;
int sizebits;
@@ -1085,11 +1085,12 @@ grow_buffers(struct block_device *bdev, sector_t block,
int size)
}
/* Create a page with the proper size buffers.. */
- return grow_dev_page(bdev, block, index, size, sizebits);
+ return grow_dev_page(bdev, block, index, size, sizebits, gfp);
}
-static struct buffer_head *
-__getblk_slow(struct block_device *bdev, sector_t block, int size)
+struct buffer_head *
+__getblk_gfp(struct block_device *bdev, sector_t block,
+unsigned size, gfp_t gfp)
{
/* Size must be multiple of hard sectorsize */
if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
@@ -,13 +1112,21 @@ __getblk_slow(struct block_device *bdev, sector_t
block, int size)
if (bh)
return bh;
- ret = grow_buffers(bdev, block, size);
+ ret = grow_buffers(bdev, block, size, gfp);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
}
+EXPORT_SYMBOL(__getblk_gfp);
+
+struct buffer_head *getblk_unmovable(struct block_device *bdev, sector_t block,
+unsigned size)
+{
+ return __getblk_gfp(bdev, block, size, 0);
+}
+EXPORT_SYMBOL(getblk_unmovable);
/*
* The relationship between dirty buffers and dirty pages:
@@ -1385,7 +1394,7 @@ __getblk(struct block_device *bdev, sector_t block,
unsigned size)
might_sleep();
if (bh == NULL)
- bh = __getblk_slow(bdev, block, size);
+ bh = __getblk_gfp(bdev, block, size, __GFP_MOVABLE);
return bh;
}
EXPORT_SYMBOL(__getblk);
@@ -1410,18 +1419,39 @@ EXPORT_SYMBOL(__breadahead);
* @size: size (in bytes) to read
*
* Reads a specified block, and returns buffer head that contains it.
+ * The page cache is allocated from movable area so that it can be migrated.
* It returns NULL if the block was unreadable.
*/
struct buffer_head *
__bread(struct block_device *bdev, sector_t block, unsigned size)
{
- struct buffer_head *bh = __getblk(bdev, block, size);
+ return __bread_gfp(bdev, block, size, __GFP_MOVABLE);
+}
+EXPORT_SYMBOL(__bread);
+
+/**
+ * __bread_gfp() - reads a specified block and returns the bh
+ * @bdev: the block_device to read from
+ * @block: number of block
+ * @size: size (in bytes) to read
+ * @gfp: page allocation flag
+ *
+ * Reads a specified block, and returns buffer head that contains it.
+ * The page cache can be allocated from non-movable area
+ * not to prevent page migration if you set gfp to zero.
+ * It returns NULL if the block was unreadable.
+ */
+struct buffer_head *
+__bread_gfp(struct block_device *bdev, sector_t block,
+ unsigned size, gfp_t gfp)
+{
+ struct buffer_head *bh = __getblk_gfp(bdev, block, size, gfp);
if (likely
[PATCH net-next v2] r8152: reduce the number of Tx
Because the Tx has the features of stopping queue and aggregation,
We don't need many tx buffers. Change the tx number from 10 to 4
to reduce the usage of the memory. This could save 16K * 6 bytes
memory.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 33dcc97..cc64dc0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -424,7 +424,7 @@ enum rtl_register_content {
FULL_DUP= 0x01,
};
-#define RTL8152_MAX_TX 10
+#define RTL8152_MAX_TX 4
#define RTL8152_MAX_RX 10
#define INTBUFSIZE 2
#define CRC_SIZE 4
--
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/
[PATCHv3 0/3] new APIs to allocate buffer-cache with user specific flag
Hello, This patch try to solve problem that a long-lasting page caches of ext4 superblock and journaling of superblock disturb page migration. I've been testing CMA feature on my ARM-based platform and found that two page caches cannot be migrated. They are page caches of superblock of ext4 filesystem and its journaling data. Current ext4 reads superblock with sb_bread() that allocates page from movable area. But the problem is that ext4 hold the page until it is unmounted. If root filesystem is ext4 the page cannot be migrated forever. And also the journaling data for the superblock cannot be migreated. I introduce new APIs that allocates page cache with specific flag passed by an argument. *_gfp APIs are for user want to set page allocation flag for page cache allocation. And *_unmovable APIs are for the user wants to allocate page cache from non-movable area. It is useful for ext4/ext3 and others that want to hold page cache for a long time. I have 3 patchs: 1. Patch 1/3: introduce a new API that create page cache with allocation flag 2. Patch 2/3: have ext4 use the new API to read superblock 3. Patch 3/3: have jbd/jbd2 use the new API to make journaling of superblock This patchset is based on linux-next-20140814. Thanks a lot. Gioh Kim (3): fs/buffer.c: allocate buffer cache with user specific flag ext4: allocate buffer-cache for superblock in non-movable area jbd-jbd2-allocate-buffer-cache-for-superblock-inode-.patch fs/buffer.c | 54 ++-- fs/ext4/super.c |6 ++-- fs/jbd/journal.c|2 - fs/jbd2/journal.c |2 - include/linux/buffer_head.h | 14 ++- 5 files changed, 60 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 04/16] ACPI: Rename processor_core.c as apic_id.c
Now all code in processor_core.c is APIC ID related, so rename it as
apic_id.c. Later IOAPIC ID related code will be added into apic_id.c.
Signed-off-by: Jiang Liu
---
drivers/acpi/Makefile |2 +-
drivers/acpi/apic_id.c| 202
drivers/acpi/processor_core.c | 205 -
include/acpi/processor.h |3 -
include/linux/acpi.h |3 +
5 files changed, 206 insertions(+), 209 deletions(-)
create mode 100644 drivers/acpi/apic_id.c
delete mode 100644 drivers/acpi/processor_core.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 505d4d79fe3e..03ddd03f2bcd 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -35,7 +35,7 @@ acpi-y+= bus.o glue.o
acpi-y += scan.o
acpi-y += resource.o
acpi-y += acpi_processor.o
-acpi-y += processor_core.o
+acpi-y += apic_id.o
acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
diff --git a/drivers/acpi/apic_id.c b/drivers/acpi/apic_id.c
new file mode 100644
index ..ada5fd48bad4
--- /dev/null
+++ b/drivers/acpi/apic_id.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2005 Intel Corporation
+ * Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
+ *
+ * Alex Chiang
+ * - Unified x86/ia64 implementations
+ */
+#include
+#include
+#include "internal.h"
+
+static int map_lapic_id(struct acpi_subtable_header *entry,
+u32 acpi_id, int *apic_id)
+{
+ struct acpi_madt_local_apic *lapic =
+ (struct acpi_madt_local_apic *)entry;
+
+ if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ return -ENODEV;
+
+ if (lapic->processor_id != acpi_id)
+ return -EINVAL;
+
+ *apic_id = lapic->id;
+ return 0;
+}
+
+static int map_x2apic_id(struct acpi_subtable_header *entry,
+int device_declaration, u32 acpi_id, int *apic_id)
+{
+ struct acpi_madt_local_x2apic *apic =
+ (struct acpi_madt_local_x2apic *)entry;
+
+ if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
+ return -ENODEV;
+
+ if (device_declaration && (apic->uid == acpi_id)) {
+ *apic_id = apic->local_apic_id;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int map_lsapic_id(struct acpi_subtable_header *entry,
+ int device_declaration, u32 acpi_id, int *apic_id)
+{
+ struct acpi_madt_local_sapic *lsapic =
+ (struct acpi_madt_local_sapic *)entry;
+
+ if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ return -ENODEV;
+
+ if (device_declaration) {
+ if ((entry->length < 16) || (lsapic->uid != acpi_id))
+ return -EINVAL;
+ } else if (lsapic->processor_id != acpi_id)
+ return -EINVAL;
+
+ *apic_id = (lsapic->id << 8) | lsapic->eid;
+ return 0;
+}
+
+static int map_madt_entry(int type, u32 acpi_id)
+{
+ unsigned long madt_end, entry;
+ static struct acpi_table_madt *madt;
+ static int read_madt;
+ int apic_id = -1;
+
+ if (!read_madt) {
+ if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
+ (struct acpi_table_header **)&madt)))
+ madt = NULL;
+ read_madt++;
+ }
+
+ if (!madt)
+ return apic_id;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ struct acpi_subtable_header *header =
+ (struct acpi_subtable_header *)entry;
+ if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
+ if (!map_lapic_id(header, acpi_id, &apic_id))
+ break;
+ } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+ if (!map_x2apic_id(header, type, acpi_id, &apic_id))
+ break;
+ } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
+ if (!map_lsapic_id(header, type, acpi_id, &apic_id))
+ break;
+ }
+ entry += header->length;
+ }
+ return apic_id;
+}
+
+static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
+{
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ struct acpi_subtable_header *header;
+ int apic_id = -1;
+
+ if (ACPI_FAILURE(acpi_evaluate_object(han
Re: [PATCH 1/5] usb: phy: twl4030-usb: Remove unused irq_enabled
Hi,
On Wed, Aug 27, 2014 at 04:28:07PM -0700, Tony Lindgren wrote:
> It's not being used any longer.
>
> Signed-off-by: Tony Lindgren
> ---
> drivers/phy/phy-twl4030-usb.c | 2 --
> drivers/usb/phy/phy-twl6030-usb.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> index 9cd33a4..bc28ecc 100644
> --- a/drivers/phy/phy-twl4030-usb.c
> +++ b/drivers/phy/phy-twl4030-usb.c
> @@ -164,7 +164,6 @@ struct twl4030_usb {
> enum omap_musb_vbus_id_status linkstat;
> boolvbus_supplied;
> u8 asleep;
> - boolirq_enabled;
>
> struct delayed_work id_workaround_work;
> };
> @@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>* set_host() and/or set_peripheral() ... OTG_capable boards
>* need both handles, otherwise just one suffices.
>*/
> - twl->irq_enabled = true;
> status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
> twl4030_usb_irq, IRQF_TRIGGER_FALLING |
> IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
can you split this into two patches ? drivers/phy will be taken by
Kishon and drivers/usb/phy by me. another possibility is that I get an
Acked-by from Kishon and I can take $subject as is.
--
balbi
signature.asc
Description: Digital signature
Re: Fwd: Re: [PATCH] staging:lustre:lnet: lib-md.c fix checkpath warnings and errors.
On 08/28/2014 10:20 AM, Janet Liu wrote:
Original Message
Subject: Re: [PATCH] staging:lustre:lnet: lib-md.c fix checkpath
warnings and errors.
Date: Tue, 26 Aug 2014 18:22:45 -0700
From: Greg KH
To: Janet Liu
CC: de...@driverdev.osuosl.org, linux-kernel@vger.kernel.org
On Mon, Aug 25, 2014 at 01:18:54AM +0800, Janet Liu wrote:
Sliences the following warning and error:
WARNING: line over 80 characters
WARNING: space prohibited between function name and open parenthesis
'('
ERROR: do not use C99 // comments
ERROR: trailing statements should be on next line
You changed 4 things, in one patch :(
Also, you sent 4 different patches, which one is correct?
Please only do one thing per patch and please resend with the one that
you wish to have reviewed.
thanks,
greg k-h
Hi Greg,
I'm very sorry for having troubled you.
The latest one is correct. It is send by my gmail box.
The first two is sent by this mailbox(janetliu...@qq.com) and is
rejected by linux-kernel@vger.kernel.org.
The third is tested by dan.carpen...@oracle.com, he told me it broke
build. So I fixed and send the fourth.
Those are all codestyle issue.
regards,
janet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 16/16] x86, irq, ACPI: Implement ACPI driver to support IOAPIC hotplug
Enable support of IOAPIC hotplug by:
1) reintroducing ACPI based IOAPIC driver
2) enhance pci_root driver to hook hotplug events
The ACPI IOAPIC driver is always enabled if all of ACPI, PCI and IOAPIC
are enabled.
Signed-off-by: Jiang Liu
---
drivers/acpi/Kconfig|6 ++
drivers/acpi/Makefile |1 +
drivers/acpi/internal.h |7 ++
drivers/acpi/ioapic.c | 236 +++
drivers/acpi/pci_root.c |3 +
5 files changed, 253 insertions(+)
create mode 100644 drivers/acpi/ioapic.c
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d0f3265fb85d..b7b87a1a2252 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -315,6 +315,12 @@ config ACPI_HOTPLUG_MEMORY
To compile this driver as a module, choose M here:
the module will be called acpi_memhotplug.
+config ACPI_HOTPLUG_IOAPIC
+ bool
+ depends on PCI
+ depends on X86_IO_APIC
+ default y
+
config ACPI_SBS
tristate "Smart Battery System"
depends on X86
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 03ddd03f2bcd..4189023fb777 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
obj-y += container.o
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
obj-y += acpi_memhotplug.o
+obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
obj-$(CONFIG_ACPI_BATTERY) += battery.o
obj-$(CONFIG_ACPI_SBS) += sbshc.o
obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4c5cf77e7576..817ab2d5975c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -34,6 +34,13 @@ void acpi_pnp_init(void);
int acpi_sysfs_init(void);
void acpi_container_init(void);
void acpi_memory_hotplug_init(void);
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_ioapic_add(struct acpi_pci_root *root);
+int acpi_ioapic_remove(struct acpi_pci_root *root);
+#else
+static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
+static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; }
+#endif
#ifdef CONFIG_ACPI_DOCK
void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
new file mode 100644
index ..66d87a61ee5c
--- /dev/null
+++ b/drivers/acpi/ioapic.c
@@ -0,0 +1,236 @@
+/*
+ * IOAPIC/IOxAPIC/IOSAPIC driver
+ *
+ * Copyright (C) 2009 Fujitsu Limited.
+ * (c) Copyright 2009 Hewlett-Packard Development Company, L.P.
+ *
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Based on original drivers/pci/ioapic.c
+ * Yinghai Lu
+ * Jiang Liu
+ */
+
+/*
+ * This driver manages I/O APICs added by hotplug after boot.
+ * We try to claim all I/O APIC devices, but those present at boot were
+ * registered when we parsed the ACPI MADT, so we'll fail when we try to
+ * re-register them.
+ */
+
+#define pr_fmt(fmt) "ACPI : IOAPIC: " fmt
+
+#include
+#include
+#include
+#include
+
+struct acpi_pci_ioapic {
+ acpi_handle root_handle;
+ acpi_handle handle;
+ u32 gsi_base;
+ struct resource res;
+ struct pci_dev *pdev;
+ struct list_head list;
+};
+
+static LIST_HEAD(ioapic_list);
+static DEFINE_MUTEX(ioapic_list_lock);
+
+static acpi_status setup_res(struct acpi_resource *acpi_res, void *data)
+{
+ struct resource *res = data;
+
+ memset(res, 0, sizeof(*res));
+ if (acpi_dev_resource_memory(acpi_res, res)) {
+ res->flags &= IORESOURCE_MEM;
+ if (res->flags)
+ return AE_OK;
+ } else if (acpi_dev_resource_address_space(acpi_res, res)) {
+ struct acpi_resource_address64 addr;
+
+ res->flags &= IORESOURCE_MEM;
+ if (res->flags &&
+ ACPI_SUCCESS(acpi_resource_to_address64(acpi_res, &addr)) &&
+ addr.info.mem.caching != ACPI_PREFETCHABLE_MEMORY) {
+ res->start += addr.translation_offset;
+ res->end += addr.translation_offset;
+ return AE_OK;
+ }
+ }
+ res->flags = 0;
+
+ return AE_OK;
+}
+
+static bool acpi_is_ioapic(acpi_handle handle, char **type)
+{
+ acpi_status status;
+ struct acpi_device_info *info;
+ char *hid = NULL;
+ bool match = false;
+
+ if (!acpi_has_method(handle, "_GSB"))
+ return false;
+
+ status = acpi_get_object_info(handle, &info);
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID)
+ hi
[Patch v4 14/16] x86, irq: Introduce helper to check whether an IOAPIC has been registered
Introduce acpi_ioapic_registered() to check whether an IOAPIC has already
been registered, it will be used when enabling IOAPIC hotplug.
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/io_apic.h |1 +
arch/x86/kernel/acpi/boot.c| 11 +++
arch/x86/kernel/apic/io_apic.c | 11 +++
include/linux/acpi.h |1 +
4 files changed, 24 insertions(+)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index ce63cf34c93c..0db2b7037e4b 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -191,6 +191,7 @@ extern void mp_unmap_irq(int irq);
extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
struct ioapic_domain_cfg *cfg);
extern int mp_unregister_ioapic(u32 gsi_base);
+extern int mp_ioapic_registered(u32 gsi_base);
extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 560a6d1cb0f4..6aa796f77b71 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -810,6 +810,17 @@ int acpi_unregister_ioapic(acpi_handle handle, u32
gsi_base)
}
EXPORT_SYMBOL(acpi_unregister_ioapic);
+int acpi_ioapic_registered(acpi_handle handle, u32 gsi_base)
+{
+ int ret;
+
+ down_write(&acpi_ioapic_rwsem);
+ ret = mp_ioapic_registered(gsi_base);
+ up_write(&acpi_ioapic_rwsem);
+
+ return ret;
+}
+
static int __init acpi_parse_sbf(struct acpi_table_header *table)
{
struct acpi_table_boot *sb;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index fc1e1f9567bc..e104993a2394 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4010,6 +4010,17 @@ int mp_unregister_ioapic(u32 gsi_base)
return 0;
}
+int mp_ioapic_registered(u32 gsi_base)
+{
+ int ioapic;
+
+ for_each_ioapic(ioapic)
+ if (ioapics[ioapic].gsi_config.gsi_base == gsi_base)
+ return 1;
+
+ return 0;
+}
+
int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b41c5aef5336..754d99d5f258 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -155,6 +155,7 @@ int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base,
u64 *phys_addr);
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
+int acpi_ioapic_registered(acpi_handle handle, u32 gsi_base);
void acpi_irq_stats_init(void);
extern u32 acpi_irq_handled;
extern u32 acpi_irq_not_handled;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 15/16] PCI: Remove PCI ioapic driver
To support IOAPIC hotplug on x86 and IA64 platforms, OS needs to figure
out global interrupt source number(GSI) and IOAPIC enumeration ID
through ACPI interfaces. So BIOS must implement an ACPI IOAPIC device
with _GSB/_UID or _MAT method to support IOAPIC hotplug. OS also needs
to figure out base physical address to access IOAPIC registers. OS may
get the base physical address through PCI BARs if IOAPIC device is
visible in PCI domain, otherwise OS may get the address by ACPI _CRS
method if IOAPIC device is hidden from PCI domain by BIOS.
When adding a PCI subtree, we need to add IOAPIC devices before enabling
all other PCI devices because other PCI devices may use the IOAPIC to
allocate PCI interrupts.
So we plan to reimplement IOAPIC driver as an ACPI instead of PCI driver
due to:
1) hot-pluggable IOAPIC devices are always visible in ACPI domain,
but may or may not be visible in PCI domain.
2) we could explicitly control the order between IOAPIC and other PCI
devices.
We also have another choice to use a PCI driver to manage IOAPIC device
if it's visible in PCI domain and use an ACPI driver if it's only
visible in ACPI domain. But this solution is a little complex.
It shouldn't cause serious backward compatibility issues because:
1) IOAPIC hotplug is never supported on x86 yet because it hasn't
implemented the required acpi_register_ioapic() and
acpi_unregister_ioapic().
2) Currently only ACPI based IOAPIC hotplug is possible on x86 and
IA64, we don't know other specifications and interfaces to support
IOAPIC hotplug yet.
3) We will reimplement an ACPI IOAPICｔdriver support IOAPIC hotplug.
This change also helps to get rid of the false alarm on all current
Linux distributions:
[6.952497] ioapic: probe of :00:05.4 failed with error -22
[6.959542] ioapic: probe of :80:05.4 failed with error -22
Signed-off-by: Jiang Liu
---
drivers/pci/Kconfig |7 ---
drivers/pci/Makefile |2 -
drivers/pci/ioapic.c | 121 --
3 files changed, 130 deletions(-)
delete mode 100644 drivers/pci/ioapic.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 893503fa1782..39866d18004e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -104,13 +104,6 @@ config PCI_PASID
If unsure, say N.
-config PCI_IOAPIC
- bool "PCI IO-APIC hotplug support" if X86
- depends on PCI
- depends on ACPI
- depends on X86_IO_APIC
- default !X86
-
config PCI_LABEL
def_bool y if (DMI || ACPI)
select NLS
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index e04fe2d9df3b..73e4af400a5a 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -13,8 +13,6 @@ obj-$(CONFIG_PCI_QUIRKS) += quirks.o
# Build PCI Express stuff if needed
obj-$(CONFIG_PCIEPORTBUS) += pcie/
-obj-$(CONFIG_PCI_IOAPIC) += ioapic.o
-
# Build the PCI Hotplug drivers if we were asked to
obj-$(CONFIG_HOTPLUG_PCI) += hotplug/
ifdef CONFIG_HOTPLUG_PCI
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
deleted file mode 100644
index f6219d36227f..
--- a/drivers/pci/ioapic.c
+++ /dev/null
@@ -1,121 +0,0 @@
-/*
- * IOAPIC/IOxAPIC/IOSAPIC driver
- *
- * Copyright (C) 2009 Fujitsu Limited.
- * (c) Copyright 2009 Hewlett-Packard Development Company, L.P.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/*
- * This driver manages PCI I/O APICs added by hotplug after boot. We try to
- * claim all I/O APIC PCI devices, but those present at boot were registered
- * when we parsed the ACPI MADT, so we'll fail when we try to re-register
- * them.
- */
-
-#include
-#include
-#include
-#include
-
-struct ioapic {
- acpi_handle handle;
- u32 gsi_base;
-};
-
-static int ioapic_probe(struct pci_dev *dev, const struct pci_device_id *ent)
-{
- acpi_handle handle;
- acpi_status status;
- unsigned long long gsb;
- struct ioapic *ioapic;
- int ret;
- char *type;
- struct resource *res;
-
- handle = ACPI_HANDLE(&dev->dev);
- if (!handle)
- return -EINVAL;
-
- status = acpi_evaluate_integer(handle, "_GSB", NULL, &gsb);
- if (ACPI_FAILURE(status))
- return -EINVAL;
-
- /*
-* The previous code in acpiphp evaluated _MAT if _GSB failed, but
-* ACPI spec 4.0 sec 6.2.2 requires _GSB for hot-pluggable I/O APICs.
-*/
-
- ioapic = kzalloc(sizeof(*ioapic), GFP_KERNEL);
- if (!ioapic)
- return -ENOMEM;
-
- ioapic->handle = handle;
- ioapic->gsi_base = (u32) gsb;
-
- if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
- type = "IOAPIC";
- else
- type = "IOxAPIC";
-
- ret = pci_enable_device(dev);
- if (ret < 0)
-
[Patch v4 11/16] x86, irq, ACPI: Introduce a rwsem to protect IOAPIC operations from hotplug
We are going to support ACPI based IOAPIC hotplug, so introduce a rwsem
to protect IOAPIC data structures from IOAPIC hotplug. We choose to
serialize in ACPI instead of in the IOAPIC core because:
1) currently we are only plan to support ACPI based IOAPIC hotplug
2) it's much more cleaner and easier
3) It does't affect IOAPIC discovered by devicetree, SFI and mpparse.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/acpi/boot.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b436fc735aa4..e23f7460c3f8 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -76,6 +76,8 @@ int acpi_fix_pin2_polarity __initdata;
static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
#endif
+static DECLARE_RWSEM(acpi_ioapic_rwsem);
+
/* --
Boot-time Configuration
--
*/
@@ -604,8 +606,11 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16
trigger)
int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
{
- int irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+ int irq;
+ down_read(&acpi_ioapic_rwsem);
+ irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+ up_read(&acpi_ioapic_rwsem);
if (irq >= 0) {
*irqp = irq;
return 0;
@@ -646,7 +651,9 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32
gsi,
int irq = gsi;
#ifdef CONFIG_X86_IO_APIC
+ down_read(&acpi_ioapic_rwsem);
irq = mp_register_gsi(dev, gsi, trigger, polarity);
+ up_read(&acpi_ioapic_rwsem);
#endif
return irq;
@@ -655,7 +662,9 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32
gsi,
static void acpi_unregister_gsi_ioapic(u32 gsi)
{
#ifdef CONFIG_X86_IO_APIC
+ down_read(&acpi_ioapic_rwsem);
mp_unregister_gsi(gsi);
+ up_read(&acpi_ioapic_rwsem);
#endif
}
@@ -1181,7 +1190,9 @@ static void __init acpi_process_madt(void)
/*
* Parse MADT IO-APIC entries
*/
+ down_write(&acpi_ioapic_rwsem);
error = acpi_parse_madt_ioapic_entries();
+ up_write(&acpi_ioapic_rwsem);
if (!error) {
acpi_set_irq_model_ioapic();
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 13/16] x86, irq, ACPI: Implement interfaces to support ACPI based IOAPIC hot-removal
Implement acpi_unregister_ioapic() to support ACPI based IOAPIC hot-removal.
An IOAPIC could only be removed when all its pins are unused.
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/io_apic.h |1 +
arch/x86/kernel/acpi/boot.c| 13 +++---
arch/x86/kernel/apic/io_apic.c | 55
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 94d05bd6586f..ce63cf34c93c 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -190,6 +190,7 @@ extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
extern void mp_unmap_irq(int irq);
extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
struct ioapic_domain_cfg *cfg);
+extern int mp_unregister_ioapic(u32 gsi_base);
extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 796cd9e31ef3..560a6d1cb0f4 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -794,15 +794,20 @@ int acpi_register_ioapic(acpi_handle handle, u64
phys_addr, u32 gsi_base)
return ret;
}
-
EXPORT_SYMBOL(acpi_register_ioapic);
int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
{
- /* TBD */
- return -EINVAL;
-}
+ int ret = -ENOSYS;
+
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+ down_write(&acpi_ioapic_rwsem);
+ ret = mp_unregister_ioapic(gsi_base);
+ up_write(&acpi_ioapic_rwsem);
+#endif
+ return ret;
+}
EXPORT_SYMBOL(acpi_unregister_ioapic);
static int __init acpi_parse_sbf(struct acpi_table_header *table)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b286461cabf9..fc1e1f9567bc 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -112,6 +112,7 @@ static struct ioapic {
struct ioapic_domain_cfg irqdomain_cfg;
struct irq_domain *irqdomain;
struct mp_pin_info *pin_info;
+ struct resource *iomem_res;
} ioapics[MAX_IO_APICS];
#define mpc_ioapic_ver(ioapic_idx) ioapics[ioapic_idx].mp_config.apicver
@@ -250,6 +251,12 @@ static void alloc_ioapic_saved_registers(int idx)
pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
}
+static void free_ioapic_saved_registers(int idx)
+{
+ kfree(ioapics[idx].saved_registers);
+ ioapics[idx].saved_registers = NULL;
+}
+
int __init arch_early_irq_init(void)
{
struct irq_cfg *cfg;
@@ -2972,6 +2979,16 @@ static int mp_irqdomain_create(int ioapic)
return 0;
}
+static void ioapic_destroy_irqdomain(int idx)
+{
+ if (ioapics[idx].irqdomain) {
+ irq_domain_remove(ioapics[idx].irqdomain);
+ ioapics[idx].irqdomain = NULL;
+ }
+ kfree(ioapics[idx].pin_info);
+ ioapics[idx].pin_info = NULL;
+}
+
void __init setup_IO_APIC(void)
{
int ioapic;
@@ -3733,6 +3750,7 @@ static struct resource * __init
ioapic_setup_resources(void)
snprintf(mem, IOAPIC_RESOURCE_NAME_SIZE, "IOAPIC %u", i);
mem += IOAPIC_RESOURCE_NAME_SIZE;
num++;
+ ioapics[i].iomem_res = res;
}
ioapic_resources = res;
@@ -3955,6 +3973,43 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
return 0;
}
+int mp_unregister_ioapic(u32 gsi_base)
+{
+ int ioapic, pin;
+ int found = 0;
+ struct mp_pin_info *pin_info;
+
+ for_each_ioapic(ioapic)
+ if (ioapics[ioapic].gsi_config.gsi_base == gsi_base) {
+ found = 1;
+ break;
+ }
+ if (!found) {
+ pr_warn("can't find IOAPIC for GSI %d\n", gsi_base);
+ return -ENODEV;
+ }
+
+ for_each_pin(ioapic, pin) {
+ pin_info = mp_pin_info(ioapic, pin);
+ if (pin_info->count) {
+ pr_warn("pin%d on IOAPIC%d is still in use.\n",
+ pin, ioapic);
+ return -EBUSY;
+ }
+ }
+
+ /* Mark entry not present */
+ ioapics[ioapic].nr_registers = 0;
+ ioapic_destroy_irqdomain(ioapic);
+ free_ioapic_saved_registers(ioapic);
+ if (ioapics[ioapic].iomem_res)
+ release_resource(ioapics[ioapic].iomem_res);
+ clear_fixmap(FIX_IO_APIC_BASE_0 + ioapic);
+ memset(&ioapics[ioapic], 0, sizeof(ioapics[ioapic]));
+
+ return 0;
+}
+
int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
[Patch v4 10/16] x86, irq: Refine mp_register_ioapic() to prepare for IOAPIC hotplug
Refine mp_register_ioapic() to prepare for IOAPIC hotplug by:
1) change return value from void to int.
2) check for gsi range conflicts
3) check for IOAPIC physical address conflicts
4) enhance the way to allocate IOAPIC index
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/io_apic.h |4 +-
arch/x86/kernel/apic/io_apic.c | 80
2 files changed, 51 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0b31aebd9405..94d05bd6586f 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -188,8 +188,8 @@ extern int mp_find_ioapic_pin(int ioapic, u32 gsi);
extern u32 mp_pin_to_gsi(int ioapic, int pin);
extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
extern void mp_unmap_irq(int irq);
-extern void mp_register_ioapic(int id, u32 address, u32 gsi_base,
- struct ioapic_domain_cfg *cfg);
+extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
+ struct ioapic_domain_cfg *cfg);
extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1ac868128a61..6e67af0c5f99 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3830,20 +3830,6 @@ int mp_find_ioapic_pin(int ioapic, u32 gsi)
return gsi - gsi_cfg->gsi_base;
}
-static int bad_ioapic(unsigned long address)
-{
- if (nr_ioapics >= MAX_IO_APICS) {
- pr_warn("WARNING: Max # of I/O APICs (%d) exceeded (found %d),
skipping\n",
- MAX_IO_APICS, nr_ioapics);
- return 1;
- }
- if (!address) {
- pr_warn("WARNING: Bogus (zero) I/O APIC address found in table,
skipping!\n");
- return 1;
- }
- return 0;
-}
-
static int bad_ioapic_register(int idx)
{
union IO_APIC_reg_00 reg_00;
@@ -3863,29 +3849,44 @@ static int bad_ioapic_register(int idx)
return 0;
}
-void mp_register_ioapic(int id, u32 address, u32 gsi_base,
- struct ioapic_domain_cfg *cfg)
+static int find_free_ioapic_entry(void)
{
- int idx = 0;
- int entries;
+ return nr_ioapics;
+}
+
+int mp_register_ioapic(int id, u32 address, u32 gsi_base,
+ struct ioapic_domain_cfg *cfg)
+{
+ u32 gsi_end;
+ int idx, ioapic, entries;
struct mp_ioapic_gsi *gsi_cfg;
- if (bad_ioapic(address))
- return;
+ if (!address) {
+ pr_warn("Bogus (zero) I/O APIC address found, skipping!\n");
+ return -EINVAL;
+ }
+ for_each_ioapic(ioapic)
+ if (ioapics[ioapic].mp_config.apicaddr == address) {
+ pr_warn("address 0x%x conflicts with IOAPIC%d\n",
+ address, ioapic);
+ return -EEXIST;
+ }
- idx = nr_ioapics;
+ idx = find_free_ioapic_entry();
+ if (idx >= MAX_IO_APICS) {
+ pr_warn("Max # of I/O APICs (%d) exceeded (found %d),
skipping\n",
+ MAX_IO_APICS, idx);
+ return -ENOSPC;
+ }
ioapics[idx].mp_config.type = MP_IOAPIC;
ioapics[idx].mp_config.flags = MPC_APIC_USABLE;
ioapics[idx].mp_config.apicaddr = address;
- ioapics[idx].irqdomain = NULL;
- ioapics[idx].irqdomain_cfg = *cfg;
set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
-
if (bad_ioapic_register(idx)) {
clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
- return;
+ return -ENODEV;
}
ioapics[idx].mp_config.apicid = io_apic_unique_id(idx, id);
@@ -3896,24 +3897,41 @@ void mp_register_ioapic(int id, u32 address, u32
gsi_base,
* and to prevent reprogramming of IOAPIC pins (PCI GSIs).
*/
entries = io_apic_get_redir_entries(idx);
+ gsi_end = gsi_base + entries - 1;
+ for_each_ioapic(ioapic) {
+ gsi_cfg = mp_ioapic_gsi_routing(ioapic);
+ if ((gsi_base >= gsi_cfg->gsi_base &&
+gsi_base <= gsi_cfg->gsi_end) ||
+ (gsi_end >= gsi_cfg->gsi_base &&
+gsi_end <= gsi_cfg->gsi_end)) {
+ pr_warn("GSI range [%u-%u] for new IOAPIC conflicts
with GSI[%u-%u]\n",
+ gsi_base, gsi_end,
+ gsi_cfg->gsi_base, gsi_cfg->gsi_end);
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ return -ENOSPC;
+ }
+ }
gsi_cfg = mp_ioapic_gsi_routing(idx);
gsi_cfg->gsi_base = gsi_base;
- gsi_cfg->gsi_end = gsi_base + en
[Patch v4 12/16] x86, irq, ACPI: Implement interface to support ACPI based IOAPIC hot-addition
Implement acpi_register_ioapic() and enhance mp_register_ioapic()
to support ACPI based IOAPIC hot-addition.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/acpi/boot.c| 31 +--
arch/x86/kernel/apic/io_apic.c | 27 ---
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e23f7460c3f8..796cd9e31ef3 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -764,8 +764,35 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
{
- /* TBD */
- return -EINVAL;
+ int ret = -ENOSYS;
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+ int ioapic_id;
+ u64 addr;
+ struct ioapic_domain_cfg cfg = {
+ .type = IOAPIC_DOMAIN_DYNAMIC,
+ .ops = &acpi_irqdomain_ops,
+ };
+
+ ioapic_id = acpi_get_ioapic_id(handle, gsi_base, &addr);
+ if (ioapic_id < 0) {
+ unsigned long long uid;
+ acpi_status status;
+
+ status = acpi_evaluate_integer(handle, METHOD_NAME__UID,
+ NULL, &uid);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_warn(handle, "failed to get IOAPIC ID.\n");
+ return -EINVAL;
+ }
+ ioapic_id = (int)uid;
+ }
+
+ down_write(&acpi_ioapic_rwsem);
+ ret = mp_register_ioapic(ioapic_id, phys_addr, gsi_base, &cfg);
+ up_write(&acpi_ioapic_rwsem);
+#endif
+
+ return ret;
}
EXPORT_SYMBOL(acpi_register_ioapic);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6e67af0c5f99..b286461cabf9 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3851,7 +3851,13 @@ static int bad_ioapic_register(int idx)
static int find_free_ioapic_entry(void)
{
- return nr_ioapics;
+ int idx;
+
+ for (idx = 0; idx < MAX_IO_APICS; idx++)
+ if (ioapics[idx].nr_registers == 0)
+ return idx;
+
+ return MAX_IO_APICS;
}
int mp_register_ioapic(int id, u32 address, u32 gsi_base,
@@ -3867,8 +3873,15 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
}
for_each_ioapic(ioapic)
if (ioapics[ioapic].mp_config.apicaddr == address) {
- pr_warn("address 0x%x conflicts with IOAPIC%d\n",
- address, ioapic);
+ /*
+* IOAPIC unit may also be visible in PCI scope.
+* When ioapic PCI driver's probe() is called,
+* the IOAPIC unit may have already been initialized
+* at boot time.
+*/
+ if (!ioapic_initialized)
+ pr_warn("address 0x%x conflicts with
IOAPIC%d\n",
+ address, ioapic);
return -EEXIST;
}
@@ -3918,6 +3931,14 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
ioapics[idx].irqdomain = NULL;
ioapics[idx].irqdomain_cfg = *cfg;
+ if (ioapic_initialized) {
+ if (mp_irqdomain_create(idx)) {
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ return -ENOMEM;
+ }
+ alloc_ioapic_saved_registers(idx);
+ }
+
if (gsi_cfg->gsi_end >= gsi_top)
gsi_top = gsi_cfg->gsi_end + 1;
if (nr_ioapics <= idx)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 06/16] x86, irq: Split out alloc_ioapic_save_registers()
From: Yinghai Lu
Split alloc_ioapic_save_registers() from early_irq_init(),
so it will be used per ioapic.
Will call that later for hot-added ioapic controller.
Signed-off-by: Yinghai Lu
Signed-off-by: Jiang Liu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 40a4aa3f4061..3faf9599ff29 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -237,6 +237,19 @@ static struct irq_pin_list *alloc_irq_pin_list(int node)
return kzalloc_node(sizeof(struct irq_pin_list), GFP_KERNEL, node);
}
+static void alloc_ioapic_saved_registers(int idx)
+{
+ size_t size;
+
+ if (ioapics[idx].saved_registers)
+ return;
+
+ size = sizeof(struct IO_APIC_route_entry) * ioapics[idx].nr_registers;
+ ioapics[idx].saved_registers = kzalloc(size, GFP_KERNEL);
+ if (!ioapics[idx].saved_registers)
+ pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
+}
+
int __init arch_early_irq_init(void)
{
struct irq_cfg *cfg;
@@ -245,13 +258,8 @@ int __init arch_early_irq_init(void)
if (!nr_legacy_irqs())
io_apic_irqs = ~0UL;
- for_each_ioapic(i) {
- ioapics[i].saved_registers =
- kzalloc(sizeof(struct IO_APIC_route_entry) *
- ioapics[i].nr_registers, GFP_KERNEL);
- if (!ioapics[i].saved_registers)
- pr_err("IOAPIC %d: suspend/resume impossible!\n", i);
- }
+ for_each_ioapic(i)
+ alloc_ioapic_saved_registers(i);
/*
* For legacy IRQ's, start with assigning irq0 to irq15 to
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 05/16] ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug
From: Yinghai Lu
We need to parse APIC ID for IOAPIC registration for IOAPIC hotplug.
ACPI _MAT method and MADT table are used to figure out IOAPIC ID, just
like parsing CPU APIC ID for CPU hotplug.
Signed-off-by: Yinghai Lu
Signed-off-by: Jiang Liu
---
drivers/acpi/apic_id.c | 96 +++-
include/linux/acpi.h |4 ++
2 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apic_id.c b/drivers/acpi/apic_id.c
index ada5fd48bad4..ad2e2679c104 100644
--- a/drivers/acpi/apic_id.c
+++ b/drivers/acpi/apic_id.c
@@ -4,11 +4,18 @@
*
* Alex Chiang
* - Unified x86/ia64 implementations
+ *
+ * I/O APIC hotplug support
+ * Yinghai Lu
+ * Jiang Liu
*/
#include
#include
#include "internal.h"
+static struct acpi_table_madt *madt;
+static int read_madt;
+
static int map_lapic_id(struct acpi_subtable_header *entry,
u32 acpi_id, int *apic_id)
{
@@ -64,8 +71,6 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
static int map_madt_entry(int type, u32 acpi_id)
{
unsigned long madt_end, entry;
- static struct acpi_table_madt *madt;
- static int read_madt;
int apic_id = -1;
if (!read_madt) {
@@ -200,3 +205,90 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
return acpi_map_cpuid(apic_id, acpi_id);
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+static int map_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
+u64 *phys_addr, int *ioapic_id)
+{
+ struct acpi_madt_io_apic *ioapic = (struct acpi_madt_io_apic *)entry;
+
+ if (ioapic->global_irq_base != gsi_base)
+ return 0;
+
+ *phys_addr = ioapic->address;
+ *ioapic_id = ioapic->id;
+ return 1;
+}
+
+static int map_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr)
+{
+ struct acpi_subtable_header *hdr;
+ unsigned long madt_end, entry;
+ int apic_id = -1;
+
+ if (!read_madt) {
+ if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
+ (struct acpi_table_header **)&madt)))
+ madt = NULL;
+ read_madt++;
+ }
+
+ if (!madt)
+ return apic_id;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ hdr = (struct acpi_subtable_header *)entry;
+ if (hdr->type == ACPI_MADT_TYPE_IO_APIC &&
+ map_ioapic_id(hdr, gsi_base, phys_addr, &apic_id))
+ break;
+ else
+ entry += hdr->length;
+ }
+
+ return apic_id;
+}
+
+static int map_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
+ u64 *phys_addr)
+{
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ struct acpi_subtable_header *header;
+ int apic_id = -1;
+
+ if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+ goto exit;
+
+ if (!buffer.length || !buffer.pointer)
+ goto exit;
+
+ obj = buffer.pointer;
+ if (obj->type != ACPI_TYPE_BUFFER ||
+ obj->buffer.length < sizeof(struct acpi_subtable_header))
+ goto exit;
+
+ header = (struct acpi_subtable_header *)obj->buffer.pointer;
+ if (header->type == ACPI_MADT_TYPE_IO_APIC)
+ map_ioapic_id(header, gsi_base, phys_addr, &apic_id);
+
+exit:
+ kfree(buffer.pointer);
+ return apic_id;
+}
+
+int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
+{
+ int apic_id;
+
+ apic_id = map_mat_ioapic_entry(handle, gsi_base, phys_addr);
+ if (apic_id == -1)
+ apic_id = map_madt_ioapic_entry(gsi_base, phys_addr);
+
+ return apic_id;
+}
+#endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 05ed6886f1f8..b41c5aef5336 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -149,6 +149,10 @@ int acpi_map_lsapic(acpi_handle handle, int physid, int
*pcpu);
int acpi_unmap_lsapic(int cpu);
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
+#endif
+
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
void acpi_irq_stats_init(void);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
[Patch v4 07/16] x86, irq: Prefer assigned ID in APIC ID register for x86_64
From: Yinghai Lu
Perfer the assigned ID in APIC ID register for x86_64 if it's still
available.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/io_apic.c | 38 +-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 3faf9599ff29..196d9c15fdec 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3575,26 +3575,54 @@ static int __init io_apic_get_unique_id(int ioapic, int
apic_id)
return apic_id;
}
-static u8 __init io_apic_unique_id(u8 id)
+static u8 io_apic_unique_id(int idx, u8 id)
{
if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
!APIC_XAPIC(apic_version[boot_cpu_physical_apicid]))
- return io_apic_get_unique_id(nr_ioapics, id);
+ return io_apic_get_unique_id(idx, id);
else
return id;
}
#else
-static u8 __init io_apic_unique_id(u8 id)
+static u8 io_apic_unique_id(int idx, u8 id)
{
int i;
+ u8 new_id;
+ unsigned long flags;
DECLARE_BITMAP(used, 256);
+ union IO_APIC_reg_00 reg_00;
bitmap_zero(used, 256);
for_each_ioapic(i)
__set_bit(mpc_ioapic_id(i), used);
if (!test_bit(id, used))
return id;
- return find_first_zero_bit(used, 256);
+
+ /* check register at first */
+ raw_spin_lock_irqsave(&ioapic_lock, flags);
+ reg_00.raw = io_apic_read(idx, 0);
+ raw_spin_unlock_irqrestore(&ioapic_lock, flags);
+ new_id = reg_00.bits.ID;
+ if (!test_bit(new_id, used)) {
+ apic_printk(APIC_VERBOSE, KERN_INFO
+ "IOAPIC[%d]: Using reg apic_id %d instead of %d\n",
+idx, new_id, id);
+ return new_id;
+ }
+
+ new_id = find_first_zero_bit(used, 256);
+ reg_00.bits.ID = new_id;
+ raw_spin_lock_irqsave(&ioapic_lock, flags);
+ io_apic_write(idx, 0, reg_00.raw);
+ reg_00.raw = io_apic_read(idx, 0);
+ raw_spin_unlock_irqrestore(&ioapic_lock, flags);
+
+ /* Sanity check */
+ if (reg_00.bits.ID != new_id)
+ pr_warn("IOAPIC[%d]: Unable to change apic_id to %d!\n",
+ idx, new_id);
+
+ return new_id;
}
#endif
@@ -3860,7 +3888,7 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base,
return;
}
- ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
+ ioapics[idx].mp_config.apicid = io_apic_unique_id(idx, id);
ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
/*
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 08/16] x86, irq: Remove __init marker for functions will be used by IOAPIC hotplug
Remove __init marker for functions which will be used by IOAPIC hotplug
at runtime.
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/io_apic.h |4 ++--
arch/x86/kernel/apic/io_apic.c | 14 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0aeed5ca356e..0b31aebd9405 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -188,8 +188,8 @@ extern int mp_find_ioapic_pin(int ioapic, u32 gsi);
extern u32 mp_pin_to_gsi(int ioapic, int pin);
extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
extern void mp_unmap_irq(int irq);
-extern void __init mp_register_ioapic(int id, u32 address, u32 gsi_base,
- struct ioapic_domain_cfg *cfg);
+extern void mp_register_ioapic(int id, u32 address, u32 gsi_base,
+ struct ioapic_domain_cfg *cfg);
extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 196d9c15fdec..1ac868128a61 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3454,7 +3454,7 @@ io_apic_setup_irq_pin(unsigned int irq, int node, struct
io_apic_irq_attr *attr)
return ret;
}
-static int __init io_apic_get_redir_entries(int ioapic)
+static int io_apic_get_redir_entries(int ioapic)
{
union IO_APIC_reg_01reg_01;
unsigned long flags;
@@ -3500,7 +3500,7 @@ int __init arch_probe_nr_irqs(void)
}
#ifdef CONFIG_X86_32
-static int __init io_apic_get_unique_id(int ioapic, int apic_id)
+static int io_apic_get_unique_id(int ioapic, int apic_id)
{
union IO_APIC_reg_00 reg_00;
static physid_mask_t apic_id_map = PHYSID_MASK_NONE;
@@ -3626,7 +3626,7 @@ static u8 io_apic_unique_id(int idx, u8 id)
}
#endif
-static int __init io_apic_get_version(int ioapic)
+static int io_apic_get_version(int ioapic)
{
union IO_APIC_reg_01reg_01;
unsigned long flags;
@@ -3830,7 +3830,7 @@ int mp_find_ioapic_pin(int ioapic, u32 gsi)
return gsi - gsi_cfg->gsi_base;
}
-static __init int bad_ioapic(unsigned long address)
+static int bad_ioapic(unsigned long address)
{
if (nr_ioapics >= MAX_IO_APICS) {
pr_warn("WARNING: Max # of I/O APICs (%d) exceeded (found %d),
skipping\n",
@@ -3844,7 +3844,7 @@ static __init int bad_ioapic(unsigned long address)
return 0;
}
-static __init int bad_ioapic_register(int idx)
+static int bad_ioapic_register(int idx)
{
union IO_APIC_reg_00 reg_00;
union IO_APIC_reg_01 reg_01;
@@ -3863,8 +3863,8 @@ static __init int bad_ioapic_register(int idx)
return 0;
}
-void __init mp_register_ioapic(int id, u32 address, u32 gsi_base,
- struct ioapic_domain_cfg *cfg)
+void mp_register_ioapic(int id, u32 address, u32 gsi_base,
+ struct ioapic_domain_cfg *cfg)
{
int idx = 0;
int entries;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 09/16] x86, irq: Keep balance of IOAPIC pin reference count
To keep balance of IOAPIC pin reference count, we need to protect
pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
from reentrance. There are two cases which will cause reentrance.
The first case is caused by suspend/hibernation. If pcibios_disable_irq
is called during suspending/hibernating, we don't release the assigned
IRQ number, otherwise it may break the suspend/hibernation. So late when
pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
number again.
The second case is that function acpi_pci_irq_enable() may be called
twice for PCI devices present at boot time as below:
1) pci_acpi_init()
--> acpi_pci_irq_enable() if pci_routeirq is true
2) pci_enable_device()
--> pcibios_enable_device()
--> acpi_pci_irq_enable()
We can't kill kernel parameter pci_routeirq yet because it's still
needed for debugging purpose.
So flag irq_managed is introduced to track whether IRQ number is
assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
and intel_mid_pci_irq_enable() from reentrance.
Signed-off-by: Jiang Liu
---
arch/x86/pci/intel_mid_pci.c |9 -
arch/x86/pci/irq.c |7 ++-
drivers/acpi/pci_irq.c | 11 +--
include/linux/pci.h |1 +
4 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 3865116c51fb..6a855fef78fc 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -210,6 +210,9 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
{
int polarity;
+ if (dev->irq_managed && dev->irq > 0)
+ return 0;
+
if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
polarity = 0; /* active high */
else
@@ -224,13 +227,17 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
if (mp_map_gsi_to_irq(dev->irq, IOAPIC_MAP_ALLOC) < 0)
return -EBUSY;
+ dev->irq_managed = 1;
+
return 0;
}
static void intel_mid_pci_irq_disable(struct pci_dev *dev)
{
- if (!dev->dev.power.is_prepared && dev->irq > 0)
+ if (!dev->dev.power.is_prepared && dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
+ dev->irq_managed = 0;
+ }
}
struct pci_ops intel_mid_pci_ops = {
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index bc1a2c341891..dd1369dbcc42 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,6 +1202,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
int irq;
struct io_apic_irq_attr irq_attr;
+ if (dev->irq_managed && dev->irq > 0)
+ return 0;
+
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
PCI_SLOT(dev->devfn),
pin - 1, &irq_attr);
@@ -1228,6 +1231,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
+ dev->irq_managed = 1;
dev->irq = irq;
dev_info(&dev->dev, "PCI->APIC IRQ transform: "
"INT %c -> IRQ %d\n", 'A' + pin - 1,
irq);
@@ -1257,8 +1261,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
static void pirq_disable_irq(struct pci_dev *dev)
{
if (io_apic_assign_pci_irqs && !dev->dev.power.is_prepared &&
- dev->irq) {
+ dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
+ dev->irq_managed = 0;
}
}
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c96887d5289e..4a89701dfe36 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -413,6 +413,9 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
+ if (dev->irq_managed && dev->irq > 0)
+ return 0;
+
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry) {
/*
@@ -456,6 +459,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return rc;
}
dev->irq = rc;
+ dev->irq_managed = 1;
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -478,7 +482,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
pin = dev->pin;
- if (!pin)
+ if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
/* Keep IOAPIC pin configuration when suspending */
@@ -502,6 +506,9 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
*/
dev_dbg(&dev->dev, "PCI INT %c disabled\n", pin_name(pin));
- if (gsi >= 0 && dev->irq > 0)
+ i
[Patch v4 03/16] ACPI: Fix minor syntax issues in processor_core.c
Fix minor syntax issues in processor.c to follow coding styles.
Signed-off-by: Jiang Liu
---
drivers/acpi/processor_core.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index e32321ce9a5c..b048f3752c2b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -125,13 +125,12 @@ static int map_mat_entry(acpi_handle handle, int type,
u32 acpi_id)
}
header = (struct acpi_subtable_header *)obj->buffer.pointer;
- if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
+ if (header->type == ACPI_MADT_TYPE_LOCAL_APIC)
map_lapic_id(header, acpi_id, &apic_id);
- } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
+ else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC)
map_lsapic_id(header, type, acpi_id, &apic_id);
- } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+ else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC)
map_x2apic_id(header, type, acpi_id, &apic_id);
- }
exit:
kfree(buffer.pointer);
@@ -164,7 +163,7 @@ int acpi_map_cpuid(int apic_id, u32 acpi_id)
* For example,
*
* Scope (_PR)
- * {
+* {
* Processor (CPU0, 0x00, 0x0410, 0x06) {}
* Processor (CPU1, 0x01, 0x0410, 0x06) {}
* Processor (CPU2, 0x02, 0x0410, 0x06) {}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 01/16] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
Private function resource_to_addr() is used to parse ACPI resources
for PCI host bridge. There are public interfaces available for that
purpose, so replace resource_to_addr() with public interfaces.
Reviewed-by: Bjorn Helgaas
Signed-off-by: Jiang Liu
---
arch/x86/pci/acpi.c | 142 ++-
1 file changed, 51 insertions(+), 91 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b132b8e3..0e716fa56ae5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -218,114 +218,74 @@ static void teardown_mcfg_map(struct pci_root_info *info)
}
#endif
-static acpi_status resource_to_addr(struct acpi_resource *resource,
- struct acpi_resource_address64 *addr)
-{
- acpi_status status;
- struct acpi_resource_memory24 *memory24;
- struct acpi_resource_memory32 *memory32;
- struct acpi_resource_fixed_memory32 *fixed_memory32;
-
- memset(addr, 0, sizeof(*addr));
- switch (resource->type) {
- case ACPI_RESOURCE_TYPE_MEMORY24:
- memory24 = &resource->data.memory24;
- addr->resource_type = ACPI_MEMORY_RANGE;
- addr->minimum = memory24->minimum;
- addr->address_length = memory24->address_length;
- addr->maximum = addr->minimum + addr->address_length - 1;
- return AE_OK;
- case ACPI_RESOURCE_TYPE_MEMORY32:
- memory32 = &resource->data.memory32;
- addr->resource_type = ACPI_MEMORY_RANGE;
- addr->minimum = memory32->minimum;
- addr->address_length = memory32->address_length;
- addr->maximum = addr->minimum + addr->address_length - 1;
- return AE_OK;
- case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
- fixed_memory32 = &resource->data.fixed_memory32;
- addr->resource_type = ACPI_MEMORY_RANGE;
- addr->minimum = fixed_memory32->address;
- addr->address_length = fixed_memory32->address_length;
- addr->maximum = addr->minimum + addr->address_length - 1;
- return AE_OK;
- case ACPI_RESOURCE_TYPE_ADDRESS16:
- case ACPI_RESOURCE_TYPE_ADDRESS32:
- case ACPI_RESOURCE_TYPE_ADDRESS64:
- status = acpi_resource_to_address64(resource, addr);
- if (ACPI_SUCCESS(status) &&
- (addr->resource_type == ACPI_MEMORY_RANGE ||
- addr->resource_type == ACPI_IO_RANGE) &&
- addr->address_length > 0) {
- return AE_OK;
- }
- break;
- }
- return AE_ERROR;
-}
-
static acpi_status count_resource(struct acpi_resource *acpi_res, void *data)
{
struct pci_root_info *info = data;
- struct acpi_resource_address64 addr;
- acpi_status status;
+ struct resource r = {
+ .flags = 0
+ };
- status = resource_to_addr(acpi_res, &addr);
- if (ACPI_SUCCESS(status))
+ if (!acpi_dev_resource_memory(acpi_res, &r) &&
+ !acpi_dev_resource_address_space(acpi_res, &r))
+ return AE_OK;
+
+ if ((r.flags & (IORESOURCE_IO | IORESOURCE_MEM)) && resource_size(&r))
info->res_num++;
+
return AE_OK;
}
static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
{
struct pci_root_info *info = data;
- struct resource *res;
- struct acpi_resource_address64 addr;
- acpi_status status;
- unsigned long flags;
- u64 start, orig_end, end;
+ struct resource *res = &info->res[info->res_num];
+ u64 translation_offset = 0;
+
+ memset(res, 0, sizeof(*res));
+ if (acpi_dev_resource_memory(acpi_res, res)) {
+ res->flags &= IORESOURCE_MEM | IORESOURCE_IO;
+ } else if (acpi_dev_resource_address_space(acpi_res, res)) {
+ u64 orig_end;
+ struct acpi_resource_address64 addr;
+
+ res->flags &= IORESOURCE_MEM | IORESOURCE_IO;
+ if (res->flags == 0)
+ return AE_OK;
- status = resource_to_addr(acpi_res, &addr);
- if (!ACPI_SUCCESS(status))
- return AE_OK;
+ if (ACPI_FAILURE(acpi_resource_to_address64(acpi_res, &addr)))
+ return AE_OK;
- if (addr.resource_type == ACPI_MEMORY_RANGE) {
- flags = IORESOURCE_MEM;
- if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
- flags |= IORESOURCE_PREFETCH;
- } else if (addr.resource_type == ACPI_IO_RANGE) {
- flags = IORESOURCE_IO;
- } else
- return AE_OK;
+ if (addr.resource_type == ACPI_MEMORY_RANGE &&
+ addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
+ res->flags |= IORESOURCE_PREFETCH;
-
[Patch v4 02/16] ACPI: Correct return value of acpi_dev_resource_address_space()
Change acpi_dev_resource_address_space() to return failure if the acpi_resource structure can't be converted to an ACPI address64 structure, so caller could correctly detect failure. Signed-off-by: Jiang Liu --- drivers/acpi/resource.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 2ba8f02ced36..782a0d15c25f 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -200,7 +200,7 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares, status = acpi_resource_to_address64(ares, &addr); if (ACPI_FAILURE(status)) - return true; + return false; res->start = addr.minimum; res->end = addr.maximum; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 00/16] Enable support of IOAPIC hotplug on x86 platforms
This patch set enhances IOAPIC core and ACPI drivers to support IOAPIC hotplug on x86 platforms. It's based on latest mainstream kernel at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git You may pull it from https://github.com/jiangliu/linux.git ioapic/hotplug_v4 We have pick up several patches from Yinghai's original IOAPIC hotplug patch set and reimplemented IOAPIC driver as an ACPI driver instead of a PCI driver. It has been tested on a 4-socket Intel SDV with socket hot-addition capability. Any suggestions are welcomed! Patch 1-5 are bugfixes and enhancements to ACPI subsystem Patch 6-14 enhances IOAPIC core to support IOAPIC hotplug Patch 15 killes PCI IOAPIC driver Patch 16 reimplements ACPI IOAPIC driver and enables IOAPIC hotplug V3->V4: 1) Fix a bug in manage IOAPIC reference count 2) Rebase to v3.17-rc2 3) Refine commit messages V2->V3: 1) Refine ACPI resource walk functions for PCI root bus and IOAPIC 2) Improve commit messages 3) Reorder patch order for better maintenence Jiang Liu (13): x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c ACPI: Correct return value of acpi_dev_resource_address_space() ACPI: Fix minor syntax issues in processor_core.c ACPI: Rename processor_core.c as apic_id.c x86, irq: Remove __init marker for functions will be used by IOAPIC hotplug x86, irq: Keep balance of IOAPIC pin reference count x86, irq: Refine mp_register_ioapic() to prepare for IOAPIC hotplug x86, irq, ACPI: Introduce a rwsem to protect IOAPIC operations from hotplug x86, irq, ACPI: Implement interface to support ACPI based IOAPIC hot-addition x86, irq, ACPI: Implement interfaces to support ACPI based IOAPIC hot-removal x86, irq: Introduce helper to check whether an IOAPIC has been registered PCI: Remove PCI ioapic driver x86, irq, ACPI: Implement ACPI driver to support IOAPIC hotplug Yinghai Lu (3): ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug x86, irq: Split out alloc_ioapic_save_registers() x86, irq: Prefer assigned ID in APIC ID register for x86_64 arch/x86/include/asm/io_apic.h |6 +- arch/x86/kernel/acpi/boot.c| 68 +- arch/x86/kernel/apic/io_apic.c | 235 +--- arch/x86/pci/acpi.c| 142 +++ arch/x86/pci/intel_mid_pci.c |9 +- arch/x86/pci/irq.c |7 +- drivers/acpi/Kconfig |6 + drivers/acpi/Makefile |3 +- drivers/acpi/apic_id.c | 294 drivers/acpi/internal.h|7 + drivers/acpi/ioapic.c | 236 drivers/acpi/pci_irq.c | 11 +- drivers/acpi/pci_root.c|3 + drivers/acpi/processor_core.c | 206 drivers/acpi/resource.c|2 +- drivers/pci/Kconfig|7 - drivers/pci/Makefile |2 - drivers/pci/ioapic.c | 121 - include/acpi/processor.h |3 - include/linux/acpi.h |8 ++ include/linux/pci.h|1 + 21 files changed, 885 insertions(+), 492 deletions(-) create mode 100644 drivers/acpi/apic_id.c create mode 100644 drivers/acpi/ioapic.c delete mode 100644 drivers/acpi/processor_core.c delete mode 100644 drivers/pci/ioapic.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeon: Test for PCI root bus before assuming bus->self
On Wed, Aug 27, 2014 at 9:32 PM, Dave Airlie wrote: >> On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson >> wrote: >>> If we assign a Radeon device to a virtual machine, we can no longer >>> assume a fixed hardware topology, like the GPU having a parent device. >>> This patch simply adds a few pci_is_root_bus() tests to avoid passing >>> a NULL pointer to PCI access functions, allowing the radeon driver to >>> work in a QEMU 440FX machine with an assigned HD8570 on the emulated >>> PCI root bus. >>> >>> Signed-off-by: Alex Williamson >> > > Does this mean inside a VM we can't enable pcie 2 speeds? > > This could lead to a quite disappointing speed decrease for DMA transfers. It depends on the sbios, but most boards negotiate the highest speed at boot. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] r8152: reduce the number of Tx
Because the Tx has the features of stopping queue and aggregation,
We don't need many tx buffers. Change the tx number from 10 to 4
to reduce the usage of the memory. This could save 16K * 10 bytes
memory.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 33dcc97..cc64dc0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -424,7 +424,7 @@ enum rtl_register_content {
FULL_DUP= 0x01,
};
-#define RTL8152_MAX_TX 10
+#define RTL8152_MAX_TX 4
#define RTL8152_MAX_RX 10
#define INTBUFSIZE 2
#define CRC_SIZE 4
--
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 v2 5/7] MIPS: sead3: Move device-trees to arch/mips/boot/dts/mti/
Move the SEAD-3 device-tree to arch/mips/boot/dts/mti/ and update the
Makefiles accordingly. Since SEAD-3 requires the device-tree to be
built into the kernel, select BUILTIN_DTB when building for SEAD-3.
Signed-off-by: Andrew Bresticker
---
arch/mips/Kconfig | 1 +
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/mti/Makefile | 1 +
arch/mips/{mti-sead3 => boot/dts/mti}/sead3.dts | 0
arch/mips/mti-sead3/Makefile| 4
5 files changed, 3 insertions(+), 4 deletions(-)
create mode 100644 arch/mips/boot/dts/mti/Makefile
rename arch/mips/{mti-sead3 => boot/dts/mti}/sead3.dts (100%)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index dbfcf35..a72c7c9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -353,6 +353,7 @@ config MIPS_SEAD3
bool "MIPS SEAD3 board"
select BOOT_ELF32
select BOOT_RAW
+ select BUILTIN_DTB
select CEVT_R4K
select CSRC_R4K
select CSRC_GIC
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 0f16e92..e32cc0f 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,5 +1,6 @@
include arch/mips/boot/dts/cavium-octeon/Makefile
include arch/mips/boot/dts/lantiq/Makefile
+include arch/mips/boot/dts/mti/Makefile
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/boot/dts/mti/Makefile b/arch/mips/boot/dts/mti/Makefile
new file mode 100644
index 000..913fac9
--- /dev/null
+++ b/arch/mips/boot/dts/mti/Makefile
@@ -0,0 +1 @@
+dtb-$(CONFIG_MIPS_SEAD3) += mti/sead3.dtb
diff --git a/arch/mips/mti-sead3/sead3.dts b/arch/mips/boot/dts/mti/sead3.dts
similarity index 100%
rename from arch/mips/mti-sead3/sead3.dts
rename to arch/mips/boot/dts/mti/sead3.dts
diff --git a/arch/mips/mti-sead3/Makefile b/arch/mips/mti-sead3/Makefile
index 071786f..febf433 100644
--- a/arch/mips/mti-sead3/Makefile
+++ b/arch/mips/mti-sead3/Makefile
@@ -19,9 +19,5 @@ obj-y += sead3-i2c-dev.o sead3-i2c.o \
obj-$(CONFIG_EARLY_PRINTK) += sead3-console.o
obj-$(CONFIG_USB_EHCI_HCD) += sead3-ehci.o
-obj-$(CONFIG_OF) += sead3.dtb.o
CFLAGS_sead3-setup.o = -I$(src)/../../../scripts/dtc/libfdt
-
-$(obj)/%.dtb: $(obj)/%.dts
- $(call if_changed,dtc)
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/7] MIPS: Octeon: Move device-trees to arch/mips/boot/dts/cavium-octeon/
Move the Octeon device-trees to arch/mips/boot/dts/cavium-octeon/ and
update the Makefiles accordingly. Since Octeon requires the device-tree
to be built into the kernel, select BUILTIN_DTB as well.
Signed-off-by: Andrew Bresticker
---
arch/mips/Kconfig | 1 +
arch/mips/boot/dts/Makefile| 2 ++
arch/mips/boot/dts/cavium-octeon/Makefile | 2 ++
arch/mips/{ => boot/dts}/cavium-octeon/octeon_3xxx.dts | 0
arch/mips/{ => boot/dts}/cavium-octeon/octeon_68xx.dts | 0
arch/mips/cavium-octeon/.gitignore | 2 --
arch/mips/cavium-octeon/Makefile | 10 --
7 files changed, 5 insertions(+), 12 deletions(-)
create mode 100644 arch/mips/boot/dts/cavium-octeon/Makefile
rename arch/mips/{ => boot/dts}/cavium-octeon/octeon_3xxx.dts (100%)
rename arch/mips/{ => boot/dts}/cavium-octeon/octeon_68xx.dts (100%)
delete mode 100644 arch/mips/cavium-octeon/.gitignore
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 19b8aac..dbfcf35 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -741,6 +741,7 @@ config CAVIUM_OCTEON_SOC
select ARCH_SPARSEMEM_ENABLE
select SYS_SUPPORTS_SMP
select NR_CPUS_DEFAULT_16
+ select BUILTIN_DTB
help
This option supports all of the Octeon reference boards from Cavium
Networks. It builds a kernel that dynamically determines the Octeon
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index dcb7810..a8daed1 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,3 +1,5 @@
+include arch/mips/boot/dts/cavium-octeon/Makefile
+
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
targets+= dtbs
diff --git a/arch/mips/boot/dts/cavium-octeon/Makefile
b/arch/mips/boot/dts/cavium-octeon/Makefile
new file mode 100644
index 000..4663d75
--- /dev/null
+++ b/arch/mips/boot/dts/cavium-octeon/Makefile
@@ -0,0 +1,2 @@
+dtb-$(CONFIG_CAVIUM_OCTEON_SOC)+= cavium-octeon/octeon_3xxx.dtb \
+ cavium-octeon/octeon_68xx.dtb
diff --git a/arch/mips/cavium-octeon/octeon_3xxx.dts
b/arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
similarity index 100%
rename from arch/mips/cavium-octeon/octeon_3xxx.dts
rename to arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
diff --git a/arch/mips/cavium-octeon/octeon_68xx.dts
b/arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
similarity index 100%
rename from arch/mips/cavium-octeon/octeon_68xx.dts
rename to arch/mips/boot/dts/cavium-octeon/octeon_68xx.dts
diff --git a/arch/mips/cavium-octeon/.gitignore
b/arch/mips/cavium-octeon/.gitignore
deleted file mode 100644
index 39c9686..000
--- a/arch/mips/cavium-octeon/.gitignore
+++ /dev/null
@@ -1,2 +0,0 @@
-*.dtb.S
-*.dtb
diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile
index 4e95204..42f5f1a 100644
--- a/arch/mips/cavium-octeon/Makefile
+++ b/arch/mips/cavium-octeon/Makefile
@@ -20,13 +20,3 @@ obj-y += executive/
obj-$(CONFIG_MTD)+= flash_setup.o
obj-$(CONFIG_SMP)+= smp.o
obj-$(CONFIG_OCTEON_ILM) += oct_ilm.o
-
-DTS_FILES = octeon_3xxx.dts octeon_68xx.dts
-DTB_FILES = $(patsubst %.dts, %.dtb, $(DTS_FILES))
-
-obj-y += $(patsubst %.dts, %.dtb.o, $(DTS_FILES))
-
-# Let's keep the .dtb files around in case we want to look at them.
-.SECONDARY: $(addprefix $(obj)/, $(DTB_FILES))
-
-clean-files += $(DTB_FILES) $(patsubst %.dtb, %.dtb.S, $(DTB_FILES))
--
2.1.0.rc2.206.gedb03e5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 5/9] block: loop: convert to blk-mq
On 8/28/14, Zach Brown wrote: > On Wed, Aug 27, 2014 at 09:19:36PM +0400, Maxim Patlasov wrote: >> On 08/27/2014 08:29 PM, Benjamin LaHaise wrote: >> >On Wed, Aug 27, 2014 at 08:08:59PM +0400, Maxim Patlasov wrote: >> >... >> >>1) /dev/loop0 of 3.17.0-rc1 with Ming's patches applied -- 11K iops >> >>2) the same as above, but call loop_queue_work() directly from >> >>loop_queue_rq() -- 270K iops >> >>3) /dev/nullb0 of 3.17.0-rc1 -- 380K iops >> >> >> >>Taking into account so big difference (11K vs. 270K), would it be >> >> worthy >> >>to implement pure non-blocking version of aio_kernel_submit() returning >> >>error if blocking needed? Then loop driver (or any other in-kernel >> >> user) >> >>might firstly try that non-blocking submit as fast-path, and, only if >> >>it's failed, fall back to queueing. >> >What filesystem is the backing file for loop0 on? O_DIRECT access as >> >Ming's patches use should be non-blocking, and if not, that's something >> >to fix. >> >> I used loop0 directly on top of null_blk driver (because my goal was to >> measure the overhead of processing requests in a separate thread). > > The relative overhead while doing nothing else. While zooming way down > in to micro benchmarks is fun and all, testing on an fs on brd might be > more representitive and so more compelling. > > (And you might start to stumble into the terrifying territory of > stacking fs write paths under fs write paths.. turn on lockdep! :)) > >> In case of real-life filesystems, e.g. ext4, aio_kernel_submit() may >> easily >> block on something like bh_submit_read(), when fs reads file metadata to >> calculate the offset on block device by position in the file. > > Yeah, there are a lot of rare potential blocking points throughout the > fs aio submission paths. In practice (aio+dio+block fs), I think > submission tends to block waiting for congested block queues most often. In case of null_blk, it shouldn't have blocked here since the defaul tag size is enough for the single job test if Maxim didn't change the default parameter of null_blk. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/7] MIPS: Create common infrastructure for building built-in device-trees
In preparation for moving the device-trees to a common location, introduce the config option BUILTIN_DTB, which can be selected by platforms that use a device-tree built into the kernel image, and create a Makefile to build the device-trees in arch/mips/boot/dts/. Signed-off-by: Andrew Bresticker --- arch/mips/Kconfig | 3 +++ arch/mips/Makefile | 6 ++ arch/mips/boot/dts/Makefile | 3 +++ 3 files changed, 12 insertions(+) create mode 100644 arch/mips/boot/dts/Makefile diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index df51e78..19b8aac 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2481,6 +2481,9 @@ config USE_OF select OF_EARLY_FLATTREE select IRQ_DOMAIN +config BUILTIN_DTB + bool + endmenu config LOCKDEP_SUPPORT diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 9336509..72cdd6a 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -324,6 +324,12 @@ endif CLEAN_FILES += vmlinux.32 vmlinux.64 +# device-trees +core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/ + +%.dtb %.dtb.S %.dtb.o: | scripts + $(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@ + archprepare: ifdef CONFIG_MIPS32_N32 @echo ' Checking missing-syscalls for N32' diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile new file mode 100644 index 000..0fef69d --- /dev/null +++ b/arch/mips/boot/dts/Makefile @@ -0,0 +1,3 @@ +obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y)) + +clean-files+= */*.dtb.S -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/7] MIPS: Move device-tree files to a common location
To be consistent with other architectures and to avoid unnecessary
makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
and build them with a common makefile. Per Olof's suggestion in v1,
device-trees are grouped into per-vendor subdirectories. Note that
since there is currently no Kbuild infrastructure for recursively
building dtbs like there is for object files, the top level Makefile
in arch/mips/boot/dts/ just includes the sub-Makefiles.
Patch 1 sets up the makefiles for building the DTs in arch/mips/boot/dts
and introduces the config option BUILTIN_DTB for platforms that require
it.
Patch 2 introduces the 'dtbs' makefile target to allow building of just
the DT binaries.
Patches 3-7 move the DTs out of the platform directores.
I've build tested this on all affected platforms (Octeon, Lantiq, SEAD3,
Netlogic, and Ralink) as well as Malta. For platforms where builtin DTBs
are optional (Netlogic and Ralink), I built with and without the builtin
DTBs.
Based on 3.17-rc2.
Changes from v1:
- moved to per-vendor subdirectories
- rebased on 3.17-rc2
Andrew Bresticker (7):
MIPS: Create common infrastructure for building built-in device-trees
MIPS: Add support for building device-tree binaries
MIPS: Octeon: Move device-trees to arch/mips/boot/dts/cavium-octeon/
MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/lantiq/
MIPS: sead3: Move device-trees to arch/mips/boot/dts/mti/
MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/netlogic/
MIPS: ralink: Move device-trees to arch/mips/boot/dts/ralink/
arch/mips/Kconfig | 5 +
arch/mips/Makefile | 11 +++
arch/mips/boot/.gitignore | 1 +
arch/mips/boot/dts/Makefile| 14 ++
arch/mips/boot/dts/cavium-octeon/Makefile | 2 ++
arch/mips/{ => boot/dts}/cavium-octeon/octeon_3xxx.dts | 0
arch/mips/{ => boot/dts}/cavium-octeon/octeon_68xx.dts | 0
arch/mips/boot/dts/lantiq/Makefile | 1 +
arch/mips/{lantiq/dts => boot/dts/lantiq}/danube.dtsi | 0
arch/mips/{lantiq/dts => boot/dts/lantiq}/easy50712.dts| 0
arch/mips/boot/dts/mti/Makefile| 1 +
arch/mips/{mti-sead3 => boot/dts/mti}/sead3.dts| 0
arch/mips/boot/dts/netlogic/Makefile | 4
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_evp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_fvp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_gvp.dts | 0
arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_svp.dts | 0
arch/mips/boot/dts/ralink/Makefile | 4
arch/mips/{ralink/dts => boot/dts/ralink}/mt7620a.dtsi | 0
arch/mips/{ralink/dts => boot/dts/ralink}/mt7620a_eval.dts | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt2880.dtsi | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt2880_eval.dts | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt3050.dtsi | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt3052_eval.dts | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt3883.dtsi | 0
arch/mips/{ralink/dts => boot/dts/ralink}/rt3883_eval.dts | 0
arch/mips/cavium-octeon/.gitignore | 2 --
arch/mips/cavium-octeon/Makefile | 10 --
arch/mips/lantiq/Kconfig | 1 +
arch/mips/lantiq/Makefile | 2 --
arch/mips/lantiq/dts/Makefile | 1 -
arch/mips/mti-sead3/Makefile | 4
arch/mips/netlogic/Kconfig | 4
arch/mips/netlogic/Makefile| 1 -
arch/mips/netlogic/dts/Makefile| 4
arch/mips/ralink/Kconfig | 4
arch/mips/ralink/Makefile | 2 --
arch/mips/ralink/dts/Makefile | 4
38 files changed, 52 insertions(+), 30 deletions(-)
create mode 100644 arch/mips/boot/dts/Makefile
create mode 100644 arch/mips/boot/dts/cavium-octeon/Makefile
rename arch/mips/{ => boot/dts}/cavium-octeon/octeon_3xxx.dts (100%)
rename arch/mips/{ => boot/dts}/cavium-octeon/octeon_68xx.dts (100%)
create mode 100644 arch/mips/boot/dts/lantiq/Makefile
rename arch/mips/{lantiq/dts => boot/dts/lantiq}/danube.dtsi (100%)
rename arch/mips/{lantiq/dts => boot/dts/lantiq}/easy50712.dts (100%)
create mode 100644 arch/mips/boot/dts/mti/Makefile
rename arch/mips/{mti-sead3 => boot/dts/mti}/sead3.dts (100%)
create mode 100644 arch/mips/boot/dts/netlogic/Makefile
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_evp.dts (100%)
rename arch/mips/{netlogic/dts => boot/dts/netlogic}/xlp_fvp.dts (100%)
rename arch/mips/{netlogic/dts => boot/dt
Re: [PATCH] radeon: Test for PCI root bus before assuming bus->self
On Thu, 2014-08-28 at 11:32 +1000, Dave Airlie wrote: > > On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson > > wrote: > >> If we assign a Radeon device to a virtual machine, we can no longer > >> assume a fixed hardware topology, like the GPU having a parent device. > >> This patch simply adds a few pci_is_root_bus() tests to avoid passing > >> a NULL pointer to PCI access functions, allowing the radeon driver to > >> work in a QEMU 440FX machine with an assigned HD8570 on the emulated > >> PCI root bus. > >> > >> Signed-off-by: Alex Williamson > > > > Does this mean inside a VM we can't enable pcie 2 speeds? Shouldn't the device already be set to something reasonable before it's assigned? > This could lead to a quite disappointing speed decrease for DMA transfers. We couldn't do it before anyway, there's no decrease. Even with a Q35 QEMU chipset the best we were doing was tweaking dummy registers on the upstream port. Should VFIO be doing bus tuning prior to exposing the device? I suppose our other option would be to let the link control bits of the emulated downstream port pass through to the host. In any case, I don't see that this patch limits performance any more than it already is for a VM. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 5/9] block: loop: convert to blk-mq
On 8/28/14, Maxim Patlasov wrote: > On 08/21/2014 09:44 AM, Ming Lei wrote: >> On Wed, Aug 20, 2014 at 4:50 AM, Jens Axboe wrote: >> >>> >>> Reworked a bit more: >>> >>> http://git.kernel.dk/?p=linux-block.git;a=commit;h=a323185a761b9a54dc340d383695b4205ea258b6 >> One big problem of the commit is that it is basically a serialized >> workqueue >> because of single &hctx->run_work, and per-req work_struct has to be >> used for concurrent implementation. So looks the approach isn't flexible >> enough compared with doing that in driver, or any idea about how to fix >> that? >> > > I'm interested what's the price of handling requests in a separate > thread at large. I used the following fio script: > > [global] > direct=1 > bsrange=512-512 > timeout=10 > numjobs=1 > ioengine=sync > > filename=/dev/loop0 # or /dev/nullb0 > > [f1] > rw=randwrite > > to compare the performance of: > > 1) /dev/loop0 of 3.17.0-rc1 with Ming's patches applied -- 11K iops If you enable BLK_MQ_F_WQ_CONTEXT, it isn't strange to see this result since blk-mq implements a serialized workqueue. > 2) the same as above, but call loop_queue_work() directly from > loop_queue_rq() -- 270K iops > 3) /dev/nullb0 of 3.17.0-rc1 -- 380K iops In my recent investigation and discussion with Jens, using workqueue may introduce some regression for cases like loop over null_blk, tmpfs. And 270K vs. 380K is a bit similar with my result, and it was observed that context switch is increased by more than 50% with introducing workqueue. I will post V3 which will use previous kthread, with blk-mq & kernel aio, which should make full use of blk-mq and kernel aio, and won't introduce regression for cases like above. > Taking into account so big difference (11K vs. 270K), would it be worthy > to implement pure non-blocking version of aio_kernel_submit() returning > error if blocking needed? Then loop driver (or any other in-kernel user) The kernel aio submit is very similar with user space's implementation, except for block plug&unplug usage in user space aio submit path. If it is blocked in aio_kernel_submit(), you should observe similar thing with io_submit() too. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] thermal: add more description for thermal-zones
On 08/27/2014 09:32 PM, Eduardo Valentin wrote: > Hello Wei, > > On Wed, Aug 27, 2014 at 10:54:07AM +0800, Wei Ni wrote: >> On 08/26/2014 08:12 PM, Eduardo Valentin wrote: >>> On Tue, Aug 26, 2014 at 10:17:29AM +0800, Wei Ni wrote: On 08/25/2014 07:07 PM, Eduardo Valentin wrote: > Hello Wei Ni, > > On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote: >> Add more description for the "polling-delay" property. >> Set "trips" and "cooling maps" as optional property, because >> if missing these two sub-nodes, the thermal zone device still >> work properly. >> >> Signed-off-by: Wei Ni >> --- >> Documentation/devicetree/bindings/thermal/thermal.txt | 10 ++ >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt >> b/Documentation/devicetree/bindings/thermal/thermal.txt >> index f5db6b7..e3d3ed9 100644 >> --- a/Documentation/devicetree/bindings/thermal/thermal.txt >> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt >> @@ -136,8 +136,8 @@ containing trip nodes and one sub-node containing >> all the zone cooling maps. >> >> Required properties: >> - polling-delay:The maximum number of milliseconds to wait >> between polls >> - Type: unsignedwhen checking this thermal zone. >> - Size: one cell >> + Type: unsignedwhen checking this thermal zone. If this value >> is 0, the >> + Size: one celldriver will not run polling queue, but just >> cancel it. >> > > The description above is specific to Linux kernel implementation > nomenclature. DT description needs to be OS agnostic. > >> - polling-delay-passive: The maximum number of milliseconds to wait >>Type: unsignedbetween polls when performing passive cooling. >> @@ -148,14 +148,16 @@ Required properties: >>phandles + sensor >>specifier >> >> +Optional property: >> - trips:A sub-node which is a container of only trip >> point nodes >>Type: sub-noderequired to describe the thermal zone. >> >> - cooling-maps: A sub-node which is a container of only cooling >> device >>Type: sub-nodemap nodes, used to describe the relation >> between trips >> -and cooling devices. >> +and cooling devices. If missing the "trips" >> property, >> +This sub-node will not be parsed, because no >> trips can >> +be bound to cooling devices. > > Do you mean if the thermal zone misses the "trips" property? Actually, > the binding describes both, cooling-maps and trips, as required > properties. Thus, both needs to be in place to consider the thermal zone > as a proper described zone. I moved the "trips" and "cooling-maps" to optional property, because if missing these two properties, the thermal zone devices still can be registered, and the driver can work properly, it has the basic function, can read temperature from thermal sysfs, although it doesn't have trips and bind with cooling devices. >>> >>> >>> If a thermal zone is used only for monitoring, then I believe it lost >>> its purpose. As Maybe a different framework shall be used, such as hwmon, >>> for instance? >> >> Yes, if we only use it for monitoring, we can use hwmon. But we have >> more functions base on these two thermal zone devices. We have a >> skin-temperature driver, which used nct1008's remote and local >> temperatures to estimator the skin temperature. As you know the thermal >> framework is more powerful, the remote/local sensors can be register as >> thermal zone, then the skin-temp driver can use thermal_zone_get_temp() >> to read their temperatures and then estimator skin's temp. We also will >> set trips and cooling devices for this skin-temp. > > In this case, don't you think it would make sense to create a thermal > zone for the skin temperature and add the required sensors (including > the nct1008) in it? Hi, Eduardo Yes, we will create a thermal zone for the skin-temp driver and add the required sensors in it, but in here we want to register these required sensors as thermal zone devices, then the thermal framework can export functions to read these sensors temperature. If use hwmon framework, it can't export nct1008's internal sensors, such as remote/local sensors, and no exported functions to read these temperatures. If we doesn't use the thermal/of-thermal framework, we have to develop a new framework to parse those sensor nodes, and I think this new one may only have slight difference with current thermal framework. If we set those two properties as optional property, then we can use it in this case simply. The skin-temp nodes w
Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to prevent accessing invalid inode
Hi Chao, I agree it's correct unlock_new_inode should be located after make_bad_inode. About this scenario, I think we should check some condition if this could be occured; A inode allocated newly could be victim by gc thread. Then, f2fs_iget called by Thread A have to fail because we handled it as bad_inode in Thread B. However, f2fs_iget could still get inode. How about check it using is_bad_inode() in f2fs_iget. Thanks, On Tue, Aug 26, 2014 at 06:35:29PM +0800, Chao Yu wrote: > As the race condition on the inode cache, following scenario can appear: > [Thread a][Thread b] > ->f2fs_mkdir > ->f2fs_add_link > ->__f2fs_add_link > ->init_inode_metadata failed here > ->gc_thread_func > ->f2fs_gc > ->do_garbage_collect > ->gc_data_segment > ->f2fs_iget > ->iget_locked > ->wait_on_inode > ->unlock_new_inode > ->move_data_page > ->make_bad_inode > ->iput > > When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode > should be set as bad to avoid being accessed by other thread. But in above > scenario, it allows f2fs to access the invalid inode before this inode was set > as bad. > This patch fix the potential problem, and this issue was found by code review. > > Signed-off-by: Chao Yu > --- > fs/f2fs/namei.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c > index 6b53ce9..845f1be 100644 > --- a/fs/f2fs/namei.c > +++ b/fs/f2fs/namei.c > @@ -134,8 +134,8 @@ static int f2fs_create(struct inode *dir, struct dentry > *dentry, umode_t mode, > return 0; > out: > clear_nlink(inode); > - unlock_new_inode(inode); > make_bad_inode(inode); > + unlock_new_inode(inode); > iput(inode); > alloc_nid_failed(sbi, ino); > return err; > @@ -267,8 +267,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry > *dentry, > return err; > out: > clear_nlink(inode); > - unlock_new_inode(inode); > make_bad_inode(inode); > + unlock_new_inode(inode); > iput(inode); > alloc_nid_failed(sbi, inode->i_ino); > return err; > @@ -308,8 +308,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry > *dentry, umode_t mode) > out_fail: > clear_inode_flag(F2FS_I(inode), FI_INC_LINK); > clear_nlink(inode); > - unlock_new_inode(inode); > make_bad_inode(inode); > + unlock_new_inode(inode); > iput(inode); > alloc_nid_failed(sbi, inode->i_ino); > return err; > @@ -354,8 +354,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry > *dentry, > return 0; > out: > clear_nlink(inode); > - unlock_new_inode(inode); > make_bad_inode(inode); > + unlock_new_inode(inode); > iput(inode); > alloc_nid_failed(sbi, inode->i_ino); > return err; > @@ -688,8 +688,8 @@ release_out: > out: > f2fs_unlock_op(sbi); > clear_nlink(inode); > - unlock_new_inode(inode); > make_bad_inode(inode); > + unlock_new_inode(inode); > iput(inode); > alloc_nid_failed(sbi, inode->i_ino); > return err; > -- > 2.0.0.421.g786a89d > > > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > Linux-f2fs-devel mailing list > linux-f2fs-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vme: remove redundant else condition
The else condition is redundant after a return. Remove these redundant else
conditions.
Signed-off-by: Fred Chou
---
drivers/staging/vme/devices/vme_pio2_gpio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_pio2_gpio.c
b/drivers/staging/vme/devices/vme_pio2_gpio.c
index f00af07..d8a118d 100644
--- a/drivers/staging/vme/devices/vme_pio2_gpio.c
+++ b/drivers/staging/vme/devices/vme_pio2_gpio.c
@@ -58,14 +58,14 @@ static int pio2_gpio_get(struct gpio_chip *chip, unsigned
int offset)
if (reg & PIO2_CHANNEL_BIT[offset]) {
if (card->bank[PIO2_CHANNEL_BANK[offset]].config != BOTH)
return 0;
- else
- return 1;
- } else {
- if (card->bank[PIO2_CHANNEL_BANK[offset]].config != BOTH)
- return 1;
- else
- return 0;
+
+ return 1;
}
+
+ if (card->bank[PIO2_CHANNEL_BANK[offset]].config != BOTH)
+ return 1;
+
+ return 0;
}
static void pio2_gpio_set(struct gpio_chip *chip, unsigned int offset,
--
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/
[RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
We need use the hrtimer, which need the arch-timer to be 'always-on'
Signed-off-by: Kever Yang
---
arch/arm/boot/dts/rk3288.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..698e6ea 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -76,6 +76,7 @@
,
;
clock-frequency = <2400>;
+ always-on;
};
i2c1: i2c@ff14 {
--
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: Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk
(2014/08/27 23:16), Hannes Reinecke wrote:
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:
Previous printk messages of SCSI command can be mixed into other printk
messages because multiple printk messages are output for it. To avoid the
problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer.
But using local buffers can induce stack overflow, so we want to solve
the
problem without local buffer if possible.
trace_seq_printf can add log messages without local buffer, so we use it.
Note:
We don't need constans.c any more.
(*1)
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging
- Result examples
(printk)
sd 2:0:0:0: [sda] CDB: Read(10)
scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10))
Signed-off-by: Yoshihiro YUNOMAE
Cc: Hannes Reinecke
Cc: Doug Gilbert
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Hidehiro Kawai
Cc: Masami Hiramatsu
---
drivers/scsi/Makefile |2
drivers/scsi/constants.c| 425
---
drivers/scsi/scsi_trace.c | 408
+
include/scsi/scsi.h |8 +
include/trace/events/scsi.h | 45 +
5 files changed, 461 insertions(+), 427 deletions(-)
delete mode 100644 drivers/scsi/constants.c
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..c56f692 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
# This goes last, so that "real" scsi devices probe earlier
obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o
-scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o constants.o \
+scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o \
scsicam.o scsi_error.o scsi_lib.o
scsi_mod-$(CONFIG_SCSI_DMA)+= scsi_lib_dma.o
scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
deleted file mode 100644
index ce9ceb8..000
--- a/drivers/scsi/constants.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * ASCII values for a number of symbolic constants, printing functions,
- * etc.
- * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422)
- * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002)
- * by D. Gilbert and aeb (20020609)
- * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-/* Commands with service actions that change the command name */
-#define SERVICE_ACTION_IN_12 0xab
-#define SERVICE_ACTION_OUT_12 0xa9
-#define SERVICE_ACTION_BIDIRECTIONAL 0x9d
-#define SERVICE_ACTION_IN_16 0x9e
-#define SERVICE_ACTION_OUT_16 0x9f
-#define THIRD_PARTY_COPY_OUT 0x83
-#define THIRD_PARTY_COPY_IN 0x84
-
-
-
-#ifdef CONFIG_SCSI_CONSTANTS
-static const char * cdb_byte0_names[] = {
-/* 00-03 */ "Test Unit Ready", "Rezero Unit/Rewind", NULL, "Request
Sense",
-/* 04-07 */ "Format Unit/Medium", "Read Block Limits", NULL,
-"Reassign Blocks",
-/* 08-0d */ "Read(6)", NULL, "Write(6)", "Seek(6)", NULL, NULL,
-/* 0e-12 */ NULL, "Read Reverse", "Write Filemarks", "Space", "Inquiry",
-/* 13-16 */ "Verify(6)", "Recover Buffered Data", "Mode Select(6)",
-"Reserve(6)",
-/* 17-1a */ "Release(6)", "Copy", "Erase", "Mode Sense(6)",
-/* 1b-1d */ "Start/Stop Unit", "Receive Diagnostic", "Send Diagnostic",
-/* 1e-1f */ "Prevent/Allow Medium Removal", NULL,
-/* 20-22 */ NULL, NULL, NULL,
-/* 23-28 */ "Read Format Capacities", "Set Window",
-"Read Capacity(10)", NULL, NULL, "Read(10)",
-/* 29-2d */ "Read Generation", "Write(10)", "Seek(10)", "Erase(10)",
-"Read updated block",
-/* 2e-31 */ "Write Verify(10)", "Verify(10)", "Search High", "Search
Equal",
-/* 32-34 */ "Search Low", "Set Limits", "Prefetch/Read Position",
-/* 35-37 */ "Synchronize Cache(10)", "Lock/Unlock Cache(10)",
-"Read Defect Data(10)",
-/* 38-3c */ "Medium Scan", "Compare", "Copy Verify", "Write Buffer",
-"Read Buffer",
-/* 3d-3f */ "Update Block", "Read Long(10)", "Write Long(10)",
-/* 40-41 */ "Change Definition", "Write Same(10)",
-/* 42-48 */ "Unmap/Read sub-channel", "Read TOC/PMA/ATIP",
-"Read density support", "Play audio(10)", "Get configuration",
-"Play audio msf", "Sanitize/Play audio track/index",
-/* 49-4f */ "Play track relative(10)", "Get event status notification",
-"Pause/resume", "Log Select", "Log Sense", "Stop play/scan",
-NULL,
-/* 50-55 */ "Xdwrite", "Xpwrite, Read disk info", "Xdread, Read track
info",
-"Reserve track", "Send OPC info", "Mode Select(10)",
-/* 56-5b */ "Reserve(10)", "Release(10)", "Repair track", "Read
master cue",
-"Mode Sense(10)", "Close track/session",
-/* 5c-5f */ "Read buffer capacity", "Send cue sheet", "Persistent
reserve in",
-"Persistent reserve out",
-/* 60-67 */ NULL, NULL, NULL, NULL, NU
Re: [PATCH v2] nfs: fix kernel warning when removing proc entry
On Tue, Aug 19, 2014 at 09:20:38PM -0700, Eric W. Biederman wrote:
> Cong Wang writes:
>
> > I saw the following kernel warning:
>
> Cong thanks for finding and tracking this. I was clearly asleep at the
> switch when I was testing my fix to the nfs client code :(
>
> I have applied this patch and will push it to Linus after it has a
> little bit to sit in linux-next.
Why does that code wank with one-by-one remove_proc_entry(), BTW?
remove_proc_subtree("nfsfs", net->proc_net) will take care of the whole pile
just fine, TYVM... While we are it, there's no need to keep ->proc_nfsfs
at all - just have it in a local variable in nfs_fs_proc_net_init().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point
(2014/08/27 23:16), Hannes Reinecke wrote:
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:
There are no mean that additional sense code and additional sense code
qualifier
are output as different messages of sense key, so those information
are added.
Note:
scsi_show_extd_sense() is changed from export symbol to non-export
symbol.
- Result examples
(printk)
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error
(ftrace, merged into scsi_print_sense traceevent)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key
(Medium Error [current]) Add. Sense (Unrecovered read error)
Signed-off-by: Yoshihiro YUNOMAE
Cc: Hannes Reinecke
Cc: Doug Gilbert
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Hidehiro Kawai
Cc: Masami Hiramatsu
---
drivers/scsi/constants.c| 932
---
drivers/scsi/scsi_trace.c | 920
++
include/scsi/scsi_dbg.h |2
include/trace/events/scsi.h | 10
4 files changed, 928 insertions(+), 936 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 85b75c8..ce9ceb8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -14,12 +14,6 @@
#include
#include
-#include
-#include
-#include
-#include
-
-#include
/* Commands with service actions that change the command name */
#define SERVICE_ACTION_IN_12 0xab
@@ -429,929 +423,3 @@ void scsi_print_command(struct scsi_cmnd *cmd)
print_opcode_name(cmd->device, devname, cmd->cmnd, cmd->cmd_len);
}
EXPORT_SYMBOL(scsi_print_command);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-struct error_info {
-unsigned short code12;/* 0x0302 looks better than 0x03,0x02 */
-const char * text;
-};
-
-/*
- * The canonical list of T10 Additional Sense Codes is available at:
- * http://www.t10.org/lists/asc-num.txt [most recent: 20130605]
- */
-
-static const struct error_info additional[] =
-{
-{0x, "No additional sense information"},
-{0x0001, "Filemark detected"},
-{0x0002, "End-of-partition/medium detected"},
-{0x0003, "Setmark detected"},
-{0x0004, "Beginning-of-partition/medium detected"},
-{0x0005, "End-of-data detected"},
-{0x0006, "I/O process terminated"},
-{0x0007, "Programmable early warning detected"},
-{0x0011, "Audio play operation in progress"},
-{0x0012, "Audio play operation paused"},
-{0x0013, "Audio play operation successfully completed"},
-{0x0014, "Audio play operation stopped due to error"},
-{0x0015, "No current audio status to return"},
-{0x0016, "Operation in progress"},
-{0x0017, "Cleaning requested"},
-{0x0018, "Erase operation in progress"},
-{0x0019, "Locate operation in progress"},
-{0x001A, "Rewind operation in progress"},
-{0x001B, "Set capacity operation in progress"},
-{0x001C, "Verify operation in progress"},
-{0x001D, "ATA pass through information available"},
-{0x001E, "Conflicting SA creation request"},
-{0x001F, "Logical unit transitioning to another power condition"},
-{0x0020, "Extended copy information available"},
-
-{0x0100, "No index/sector signal"},
-
-{0x0200, "No seek complete"},
-
-{0x0300, "Peripheral device write fault"},
-{0x0301, "No write current"},
-{0x0302, "Excessive write errors"},
-
-{0x0400, "Logical unit not ready, cause not reportable"},
-{0x0401, "Logical unit is in process of becoming ready"},
-{0x0402, "Logical unit not ready, initializing command required"},
-{0x0403, "Logical unit not ready, manual intervention required"},
-{0x0404, "Logical unit not ready, format in progress"},
-{0x0405, "Logical unit not ready, rebuild in progress"},
-{0x0406, "Logical unit not ready, recalculation in progress"},
-{0x0407, "Logical unit not ready, operation in progress"},
-{0x0408, "Logical unit not ready, long write in progress"},
-{0x0409, "Logical unit not ready, self-test in progress"},
-{0x040A, "Logical unit not accessible, asymmetric access state "
- "transition"},
-{0x040B, "Logical unit not accessible, target port in standby
state"},
-{0x040C, "Logical unit not accessible, target port in unavailable "
- "state"},
-{0x040D, "Logical unit not ready, structure check required"},
-{0x0410, "Logical unit not ready, auxiliary memory not accessible"},
-{0x0411, "Logical unit not ready, notify (enable spinup) required"},
-{0x0412, "Logical unit not ready, offline"},
-{0x0413, "Logical unit not ready, SA creation in progress"},
-{0x0414, "Logical unit not ready, space allocation in progress"},
-{0x0415, "Logical unit not ready, robotics disabled"},
-{0x0416, "Logical unit not ready, configuration required"},
-{0x0417, "Logical unit not ready, calibration required"},
-{0x0418, "Logical unit not ready, a door is open"},
-{0x0419, "Logical unit not ready, operating in sequential mode
Re: Re: [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense trace point instead of printk
(2014/08/27 23:15), Hannes Reinecke wrote:
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:
Previous sense messages can be mixed into other sense messages,
because continuous printk (KERN_CONT) was used. To avoid the problem,
patch d87f3a6f51 introduced a local buffer in Hannes's baranch (*1).
But using local buffers can induce stack overflow, so we want to solve
the
problem without local buffer if possible.
trace_seq_printf can add log messages without local buffer, so we use it.
(*1)
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging
- Result examples
(printk)
sd 2:0:0:0: [sda] Sense Key : Medium Error [current]
(ftrace)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key
(Medium Error [current])
Signed-off-by: Yoshihiro YUNOMAE
Cc: Hannes Reinecke
Cc: Doug Gilbert
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Hidehiro Kawai
Cc: Masami Hiramatsu
---
drivers/scsi/constants.c| 145
++-
drivers/scsi/scsi_trace.c | 140
--
include/scsi/scsi_eh.h |7 ++
include/trace/events/scsi.h | 48 ++
4 files changed, 195 insertions(+), 145 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index f7b7f32..85b75c8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -19,7 +19,7 @@
#include
#include
-
+#include
/* Commands with service actions that change the command name */
#define SERVICE_ACTION_IN_12 0xab
@@ -1267,58 +1267,8 @@ static const struct error_info2 additional2[] =
{0x70, 0x00, 0xff, "Decompression exception short algorithm id
of %x"},
{0, 0, 0, NULL}
};
-
-/* description of the sense key values */
-static const char * const snstext[] = {
-"No Sense",/* 0: There is no sense information */
-"Recovered Error", /* 1: The last command completed successfully
- but used error correction */
-"Not Ready",/* 2: The addressed target is not ready */
-"Medium Error",/* 3: Data error detected on the medium */
-"Hardware Error", /* 4: Controller or device failure */
-"Illegal Request", /* 5: Error in request */
-"Unit Attention", /* 6: Removable medium was changed, or
- the target has been reset, or ... */
-"Data Protect",/* 7: Access to the data is blocked */
-"Blank Check",/* 8: Reached unexpected written or unwritten
- region of the medium */
-"Vendor Specific(9)",
-"Copy Aborted",/* A: COPY or COMPARE was aborted */
-"Aborted Command", /* B: The target aborted the command */
-"Equal",/* C: A SEARCH DATA command found data equal,
- reserved in SPC-4 rev 36 */
-"Volume Overflow", /* D: Medium full with still data to be
written */
-"Miscompare",/* E: Source data and data on the medium
- do not agree */
-"Completed",/* F: command completed sense data reported,
- may occur for successful command */
-};
-#else
-static const char * const snstext[] = {
-"0x0", "0x1", "0x2", "0x3", "0x4", "0x5", "0x6", "0x7",
-"0x8", "0x9", "0xa", "0xb", "0xc", "0xd", "0xe", "0xf",
-};
#endif
-/* Get sense key string or NULL if not available */
-const char *
-scsi_sense_key_string(unsigned char key) {
-return snstext[key & 0xf];
-}
-EXPORT_SYMBOL(scsi_sense_key_string);
-
-const char *
-scsi_sense_type_string(struct scsi_sense_hdr *sshdr)
-{
-return scsi_sense_is_deferred(sshdr) ? "[deferred]" : "[current]";
-}
-
-const char *
-scsi_sense_format_string(struct scsi_sense_hdr *sshdr)
-{
-return sshdr->response_code >= 0x72 ? "[descriptor]" : "";
-}
-
/*
* Get additional sense code string or NULL if not available.
* This string may contain a "%x" and should be printed with ascq as
arg.
@@ -1375,105 +1325,22 @@ void
scsi_print_sense_hdr(struct scsi_device *sdev, const char *name,
struct scsi_sense_hdr *sshdr)
{
-sdev_printk(KERN_INFO, sdev, "[%s] Sense Key : %s %s%s\n", name,
-scsi_sense_key_string(sshdr->sense_key),
-scsi_sense_type_string(sshdr),
-scsi_sense_format_string(sshdr));
+trace_scsi_print_sense(sdev, name, sshdr, NULL, 0, 0);
scsi_show_extd_sense(sdev, name, sshdr->asc, sshdr->ascq);
}
EXPORT_SYMBOL(scsi_print_sense_hdr);
-static void
-scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix,
- const unsigned char *sense_buffer, int sense_len)
-{
-char linebuf[128];
-int i, linelen, remaining;
-
-if (sense_len < 32)
-sense_len = 32;
-
-remaining = sense_len;
-for (i = 0; i < sense_len; i += 16) {
-linelen = min(remaining, 16);
-remaining -= 16;
-
-hex_dump_to_buffer(sense_buffer + i, linelen, 16, 1,
- linebuf, sizeof(linebu
Re: Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk
(2014/08/27 23:12), Hannes Reinecke wrote:
On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:
Current SCSI trace has hostbyte table and driverbyte table, so we
don't need to
have the same table in scsi/constants.c.
- Result examples
(printk)
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
(ftrace)
scsi_show_result: host_no=2 channel=0 id=0 lun=0 [sda]
result=(driver=DRIVER_SENSE host=DID_OK)
Signed-off-by: Yoshihiro YUNOMAE
Cc: Hannes Reinecke
Cc: Doug Gilbert
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Hidehiro Kawai
Cc: Masami Hiramatsu
---
drivers/scsi/constants.c| 52
---
drivers/scsi/scsi_trace.c | 16 +
include/trace/events/scsi.h | 38 +++
3 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 6fad6b4..f7b7f32 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1488,55 +1488,3 @@ void scsi_print_sense(struct scsi_cmnd *cmd)
SCSI_SENSE_BUFFERSIZE);
}
EXPORT_SYMBOL(scsi_print_sense);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-static const char * const hostbyte_table[]={
-"DID_OK", "DID_NO_CONNECT", "DID_BUS_BUSY", "DID_TIME_OUT",
"DID_BAD_TARGET",
-"DID_ABORT", "DID_PARITY", "DID_ERROR", "DID_RESET", "DID_BAD_INTR",
-"DID_PASSTHROUGH", "DID_SOFT_ERROR", "DID_IMM_RETRY", "DID_REQUEUE",
-"DID_TRANSPORT_DISRUPTED", "DID_TRANSPORT_FAILFAST",
"DID_TARGET_FAILURE",
-"DID_NEXUS_FAILURE" };
-#define NUM_HOSTBYTE_STRS ARRAY_SIZE(hostbyte_table)
-
-static const char * const driverbyte_table[]={
-"DRIVER_OK", "DRIVER_BUSY", "DRIVER_SOFT", "DRIVER_MEDIA",
"DRIVER_ERROR",
-"DRIVER_INVALID", "DRIVER_TIMEOUT", "DRIVER_HARD", "DRIVER_SENSE"};
-#define NUM_DRIVERBYTE_STRS ARRAY_SIZE(driverbyte_table)
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
-{
-int hb = host_byte(result);
-int db = driver_byte(result);
-const char *hb_string;
-const char *db_string;
-
-hb_string = (hb < NUM_HOSTBYTE_STRS) ? hostbyte_table[hb] :
"invalid";
-db_string = (db < NUM_DRIVERBYTE_STRS) ?
-driverbyte_table[db] : "invalid";
-
-
-sdev_printk(KERN_INFO, sdev,
-"[%s] Result: hostbyte=%s driverbyte=%s\n",
-name, hb_string, db_string);
-}
-
-#else
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
-{
-sdev_printk(KERN_INFO, sdev,
-"[%s] Result: hostbyte=0x%02x driverbyte=0x%02x\n",
-name, host_byte(result), driver_byte(result));
-}
-
-#endif
-EXPORT_SYMBOL(scsi_show_result);
-
-void scsi_print_result(struct scsi_cmnd *cmd)
-{
-const char *devname = cmd->request->rq_disk ?
-cmd->request->rq_disk->disk_name : "scsi";
-scsi_show_result(cmd->device, devname, cmd->result);
-}
-EXPORT_SYMBOL(scsi_print_result);
diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
index 2bea4f0..6ffbc40 100644
--- a/drivers/scsi/scsi_trace.c
+++ b/drivers/scsi/scsi_trace.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+
#define SERVICE_ACTION16(cdb) (cdb[1] & 0x1f)
#define SERVICE_ACTION32(cdb) ((cdb[8] << 8) | cdb[9])
@@ -286,3 +288,17 @@ scsi_trace_parse_cdb(struct trace_seq *p,
unsigned char *cdb, int len)
return scsi_trace_misc(p, cdb, len);
}
}
+
+void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
+{
+trace_scsi_show_result(sdev, name, result);
+}
+EXPORT_SYMBOL(scsi_show_result);
+
+void scsi_print_result(struct scsi_cmnd *cmd)
+{
+const char *devname = cmd->request->rq_disk ?
+cmd->request->rq_disk->disk_name : "scsi";
+scsi_show_result(cmd->device, devname, cmd->result);
+}
+EXPORT_SYMBOL(scsi_print_result);
diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h
index 8aecdc2..0675195 100644
--- a/include/trace/events/scsi.h
+++ b/include/trace/events/scsi.h
@@ -123,7 +123,11 @@
scsi_hostbyte_name(DID_IMM_RETRY),\
scsi_hostbyte_name(DID_REQUEUE),\
scsi_hostbyte_name(DID_TRANSPORT_DISRUPTED),\
-scsi_hostbyte_name(DID_TRANSPORT_FAILFAST))
+scsi_hostbyte_name(DID_TRANSPORT_FAILFAST),\
+scsi_hostbyte_name(DID_TARGET_FAILURE),\
+scsi_hostbyte_name(DID_NEXUS_FAILURE),\
+scsi_hostbyte_name(DID_ALLOC_FAILURE),\
+scsi_hostbyte_name(DID_MEDIUM_ERROR))
#define scsi_driverbyte_name(result){ result, #result }
#define show_driverbyte_name(val)\
@@ -359,6 +363,38 @@ TRACE_EVENT(scsi_eh_wakeup,
TP_printk("host_no=%u", __entry->host_no)
);
+TRACE_EVENT(scsi_show_result,
+
+TP_PROTO(struct scsi_device *sdev, const char *devname, int result),
+
+TP_ARGS(sdev, devname, result),
+
+TP_STRUCT__entry(
+__field( unsigned int,host_no)
+__field( unsigned int,
[PATCH] checkpatch: Allow commit descriptions on separate line from commit id
The general form for commit id and description is
'Commit <12+hexdigits> ("commit description/subject line")'
But commit logs often have relatively long commit ids and
the commit description is on a separate line like:
Some explanation as to why commit <12+hexdigits>
("commit description/subject line") is improved.
Allow this form.
Signed-off-by: Joe Perches
Suggested-by: Joe Lawrence
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d89857d..4d869dd 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2133,7 +2133,10 @@ sub process {
# Check for improperly formed commit descriptions
if ($in_commit_log &&
$line =~ /\bcommit\s+[0-9a-f]{5,}/i &&
- $line !~ /\b[Cc]ommit [0-9a-f]{12,40} \("/) {
+ !($line =~ /\b[Cc]ommit [0-9a-f]{12,40} \("/ ||
+ ($line =~ /\b[Cc]ommit [0-9a-f]{12,40}\s*$/ &&
+ defined $rawlines[$linenr] &&
+ $rawlines[$linenr] =~ /^\s*\("/))) {
$line =~ /\b(c)ommit\s+([0-9a-f]{5,})/i;
my $init_char = $1;
my $orig_commit = lc($2);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Remove implicit nodev for new mounts in non-root userns
On Wed, Aug 13, 2014 at 5:03 PM, Andy Lutomirski wrote:
> Currently, creating a new mount (as opposed to bindmount) in a
> non-root userns will implicitly set nodev unless the fs is devpts.
> Something like this will be necessary for file systems that allow
> the mounter to create device nodes without using mknod (e.g. FUSE
> if/when that is allowed), but none of the currently allowed
> filesystems do this.
>
Any thoughts, Eric?
> Implicitly adding nodev is problematic, though. It will make it
> unsafe to ever remove the implicit addition, since userspace might
> start to rely on it.
>
> This fixes a minor regression in:
>
> 9566d6742852 mnt: Correct permission checks in do_remount
>
> Prior to that commit, MNT_NODEV wasn't enforced for remounts, so
> there is existing user code that creates a new mount in a userns
> without MS_NODEV and then expects a remount with matching options to
> work. That commit broke code that does this.
>
> Fortunately, since the implicit nodev has no effect on any existing
> filesystems, we can still safely remove it.
>
> This replaces the implicit nodev with an explicit nodev requirement:
> anyone who mounts a filesystem without FS_USERNS_DEV_MOUNT will get
> -EPERM unless they set nodev. If they set nodev, that setting will
> be locked.
>
> As an added benefit, if anything like device namespaces is ever
> added, then user code will be able to opt out of nodev by clearing
> nodev.
>
> To keep existing code working, this adds FS_USERNS_DEV_MOUNT to all
> FS_USERNS_MOUNT filesystems. All of the current filesystems with
> FS_USERNS_MOUNT set are safe.
>
> I confirmed that this is compatible with Sandstorm's revision
> 1bf0c4847b. That revision of Sandstorm does not work without this
> fix if 9566d6742852 is applied.
>
> Cc: Kenton Varda
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
> ---
> fs/namespace.c | 16
> fs/proc/root.c | 2 +-
> fs/ramfs/inode.c | 2 +-
> fs/sysfs/mount.c | 2 +-
> ipc/mqueue.c | 2 +-
> mm/shmem.c | 4 ++--
> 6 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 0acabea58319..835fa9e8307e 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2154,12 +2154,20 @@ static int do_new_mount(struct path *path, const char
> *fstype, int flags,
> put_filesystem(type);
> return -EPERM;
> }
> - /* Only in special cases allow devices from mounts
> -* created outside the initial user namespace.
> +
> + /*
> +* If a filesystem might allow the mounter to put
> +* device nodes on it without the checks in mknod,
> +* then require MS_NODEV to mount it.
> */
> if (!(type->fs_flags & FS_USERNS_DEV_MOUNT)) {
> - flags |= MS_NODEV;
> - mnt_flags |= MNT_NODEV | MNT_LOCK_NODEV;
> + if (!(mnt_flags & MNT_NODEV)) {
> + put_filesystem(type);
> + return -EPERM;
> + }
> +
> + /* Do not allow nodev to be cleared. */
> + mnt_flags |= MNT_LOCK_NODEV;
> }
> }
>
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index 094e44d4a6be..2313b280729e 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -159,7 +159,7 @@ static struct file_system_type proc_fs_type = {
> .name = "proc",
> .mount = proc_mount,
> .kill_sb= proc_kill_sb,
> - .fs_flags = FS_USERNS_MOUNT,
> + .fs_flags = FS_USERNS_MOUNT | FS_USERNS_DEV_MOUNT,
> };
>
> void __init proc_root_init(void)
> diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
> index d365b1c4eb3c..b95b7302d4cc 100644
> --- a/fs/ramfs/inode.c
> +++ b/fs/ramfs/inode.c
> @@ -261,7 +261,7 @@ static struct file_system_type ramfs_fs_type = {
> .name = "ramfs",
> .mount = ramfs_mount,
> .kill_sb= ramfs_kill_sb,
> - .fs_flags = FS_USERNS_MOUNT,
> + .fs_flags = FS_USERNS_MOUNT | FS_USERNS_DEV_MOUNT,
> };
>
> int __init init_ramfs_fs(void)
> diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
> index 8a49486bf30c..56ba59317e24 100644
> --- a/fs/sysfs/mount.c
> +++ b/fs/sysfs/mount.c
> @@ -58,7 +58,7 @@ static struct file_system_type sysfs_fs_type = {
> .name = "sysfs",
> .mount = sysfs_mount,
> .kill_sb= sysfs_kill_sb,
> - .fs_flags = FS_USERNS_MOUNT,
> + .fs_flags = FS_USERNS_MOUNT | FS_USERNS_DEV_MOUNT,
> };
>
> int __init sysfs_init(void)
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 4fcf39af1776..56abbc848d4c 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -1394,7 +1394,7 @@ static struct file_system_type m
Re: [PATCH] radeon: Test for PCI root bus before assuming bus->self
> On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson > wrote: >> If we assign a Radeon device to a virtual machine, we can no longer >> assume a fixed hardware topology, like the GPU having a parent device. >> This patch simply adds a few pci_is_root_bus() tests to avoid passing >> a NULL pointer to PCI access functions, allowing the radeon driver to >> work in a QEMU 440FX machine with an assigned HD8570 on the emulated >> PCI root bus. >> >> Signed-off-by: Alex Williamson > Does this mean inside a VM we can't enable pcie 2 speeds? This could lead to a quite disappointing speed decrease for DMA transfers. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 00/21] Support ext4 on NV-DIMMs
On 08/27/2014 02:46 PM, Andrew Morton wrote: > I assume (because I wasn't told!) that there are two objectives here: > > 1) reduce memory consumption by not maintaining pagecache and > 2) reduce CPU cost by avoiding the double-copies. > > These things are pretty easily quantified. And really they must be > quantified as part of the developer testing, because if you find > they've worsened then holy cow, what went wrong. > There are two more huge ones: 3) Writes via mmap are immediately durable (or at least they're durable after a *very* lightweight flush). 4) No page faults ever once a page is writable (I hope -- I'm not sure whether this series actually achieves that goal). A note on #3: there is ongoing work to enable write-through memory for things like this. Once that's done, then writes via mmap might actually be synchronously durable, depending on chipset details. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] Adding Skyworks SKY81452 MFD driver
On Wed, Aug 27, 2014 at 09:39:21AM +0100, Lee Jones wrote:
> On Wed, 27 Aug 2014, Gyungoh Yoo wrote:
> > On Tue, Aug 26, 2014 at 09:22:58AM +0100, Lee Jones wrote:
> > > On Mon, 25 Aug 2014, Gyungoh Yoo wrote:
> > > > On Thu, Aug 21, 2014 at 10:45:02AM +0100, Lee Jones wrote:
> > > > > When you send patch-sets, you should send them connected to one
> > > > > another AKA threaded. That way, when we're reviewing we can look at
> > > > > the other patches in the set for reference. See the man page for `git
> > > > > send-email` for details.
> > > > >
> > > > >
> > > > >
> > > > > > Signed-off-by: Gyungoh Yoo
> > > > > > ---
> > >
> > > [...]
> > >
> > > > > > +static int sky81452_register_devices(struct device *dev,
> > > > > > + const struct sky81452_platform_data *pdata)
> > > > > > +{
> > > > > > + struct mfd_cell cells[] = {
> > > > > > + {
> > > > > > + .name = "sky81452-bl",
> > > > > > + .platform_data = pdata->bl_pdata,
> > > > > > + .pdata_size = sizeof(*pdata->bl_pdata),
> > > > >
> > > > > Have you tested this with DT?
> > > > >
> > > > > You're not passing the compatible string and not using
> > > > > of_platform_populate() so I'm struggling to see how it would work
> > > > > properly.
> > > >
> > > > sky81452-bl and regulator-sky81452 is parsing the information
> > > > in regulator node of its parent node. So I thought these 2 drivers
> > > > don't need compatible attribute. That is what it didn't have
> > > > compatible string.
> > > > Is is mandatory that all drivers should have compatible attribute?
> > >
> > > How do they obtain their DT nodes?
> >
> > The backlight driver which is one of the child driver is obtain its DT node
> > like this
> >
> > np = of_get_child_by_name(dev->parent->of_node, "backlight");
>
> The MFD core provides infrastructure so you don't have to do this.
>
> Just place the compatible string in 'struct mfd_cell cells[]' and the
> core will match and populate dev->of_node for you.
I see. Thank you.
>
> > > [...]
> > >
> > > > > > + return mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells),
> > > > > > + NULL, 0, NULL);
> > > > >
> > > > > This doesn't really need to be in a function of its own. Please put
> > > > > it in .probe(). Also check for the return value and present the user
> > > > > with an error message if it fails.
> > > >
> > > > I think this need to be, in case of !CONFIG_OF.
> > > > Can you please explain more in details?
> > >
> > > Then how to you obtain the shared register map you created?
> >
> > regmap is stored in driver data in MFD.
> >
> > i2c_set_clientdata(client, regmap);
> >
> > The child drivers obain the regmap from the parent.
> >
> > struct regmap *regmap = dev_get_drvdata(dev->parent);
>
> Ah yes, of course you do. Silly of me to miss this.
>
> I also just noticed that you're also manually populating the
> chlidren's platform data. It's easier if you do this from the child
> device drivers:
>
> const struct sky81452_platform_data ppdata = dev_get_platdata(dev->parent);
> const struct sky81452_bl_platform_data = pdata = ppdata->bl_pdata;
I think it could be a good way for this. Thank you.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 27
Hi Laura, On Wed, 27 Aug 2014 17:56:13 -0700 Laura Abbott wrote: > > I sent fixes for this to Andrew yesterday, did those not get picked up > or fix the problem? Things do not migrate to mmotm (and hence linux-next) very quickly (depending on Andrew's load). I don't remember seeing the fix patch(es). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v5 4/6] acerhdf: Use bang-bang thermal governor
On Wed, 2014-08-27 at 10:01 +0200, Peter Feuerer wrote:
> Zhang Rui writes:
>
> > On Tue, 2014-07-22 at 17:37 +0200, Peter Feuerer wrote:
> >> acerhdf has been doing an on-off fan control using hysteresis by
> >> post-manipulating the outcome of thermal subsystem trip point handling.
> >> This patch enables acerhdf to use the bang-bang governor, which is
> >> intended for on-off controlled fans.
> >>
> >> Cc: Andrew Morton
> >> CC: Zhang Rui
> >> Cc: Andreas Mohr
> >> Cc: Javi Merino
> >> Acked-and-tested-by: Borislav Petkov
> >> Signed-off-by: Peter Feuerer
> >
> > Peter,
> >
> > will you take this patch, or do you want me to take this patch along
> > with Patch 3/6?
>
> Hi Rui,
>
> please apply the whole series. I don't have a git repository where Linus
> pulls from.
>
No, I can not apply the whole series.
I should take patch 3/6, and the others should goto Matthew Garrett'
tree. Or I can take them with Matthew' Acked-by.
thanks,
rui
> thanks and kind regards,
> --peter;
>
>
> >
> > thanks,
> > rui
> >> ---
> >> drivers/platform/x86/Kconfig | 3 ++-
> >> drivers/platform/x86/acerhdf.c | 36 +++-
> >> 2 files changed, 33 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> >> index 172f26c..b5e80dc 100644
> >> --- a/drivers/platform/x86/Kconfig
> >> +++ b/drivers/platform/x86/Kconfig
> >> @@ -38,7 +38,8 @@ config ACER_WMI
> >>
> >> config ACERHDF
> >>tristate "Acer Aspire One temperature and fan driver"
> >> - depends on THERMAL && ACPI
> >> + select THERMAL_GOV_BANG_BANG
> >> + depends on ACPI
> >>---help---
> >> This is a driver for Acer Aspire One netbooks. It allows to access
> >> the temperature sensor and to control the fan.
> >> diff --git a/drivers/platform/x86/acerhdf.c
> >> b/drivers/platform/x86/acerhdf.c
> >> index f30767f..7fe7dbf 100644
> >> --- a/drivers/platform/x86/acerhdf.c
> >> +++ b/drivers/platform/x86/acerhdf.c
> >> @@ -50,7 +50,7 @@
> >> */
> >> #undef START_IN_KERNEL_MODE
> >>
> >> -#define DRV_VER "0.5.30"
> >> +#define DRV_VER "0.7.0"
> >>
> >> /*
> >> * According to the Atom N270 datasheet,
> >> @@ -258,6 +258,14 @@ static const struct bios_settings_t bios_tbl[] = {
> >>
> >> static const struct bios_settings_t *bios_cfg __read_mostly;
> >>
> >> +/*
> >> + * this struct is used to instruct thermal layer to use bang_bang instead
> >> of
> >> + * default governor for acerhdf
> >> + */
> >> +static struct thermal_zone_params acerhdf_zone_params = {
> >> + .governor_name = "bang_bang",
> >> +};
> >> +
> >> static int acerhdf_get_temp(int *temp)
> >> {
> >>u8 read_temp;
> >> @@ -439,6 +447,17 @@ static int acerhdf_get_trip_type(struct
> >> thermal_zone_device *thermal, int trip,
> >>return 0;
> >> }
> >>
> >> +static int acerhdf_get_trip_hyst(struct thermal_zone_device *thermal, int
> >> trip,
> >> + unsigned long *temp)
> >> +{
> >> + if (trip != 0)
> >> + return -EINVAL;
> >> +
> >> + *temp = fanon - fanoff;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int
> >> trip,
> >> unsigned long *temp)
> >> {
> >> @@ -463,6 +482,7 @@ static struct thermal_zone_device_ops acerhdf_dev_ops
> >> = {
> >>.get_mode = acerhdf_get_mode,
> >>.set_mode = acerhdf_set_mode,
> >>.get_trip_type = acerhdf_get_trip_type,
> >> + .get_trip_hyst = acerhdf_get_trip_hyst,
> >>.get_trip_temp = acerhdf_get_trip_temp,
> >>.get_crit_temp = acerhdf_get_crit_temp,
> >> };
> >> @@ -515,9 +535,7 @@ static int acerhdf_set_cur_state(struct
> >> thermal_cooling_device *cdev,
> >>}
> >>
> >>if (state == 0) {
> >> - /* turn fan off only if below fanoff temperature */
> >> - if ((cur_state == ACERHDF_FAN_AUTO) &&
> >> - (cur_temp < fanoff))
> >> + if (cur_state == ACERHDF_FAN_AUTO)
> >>acerhdf_change_fanstate(ACERHDF_FAN_OFF);
> >>} else {
> >>if (cur_state == ACERHDF_FAN_OFF)
> >> @@ -696,11 +714,19 @@ static int acerhdf_register_thermal(void)
> >>return -EINVAL;
> >>
> >>thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
> >> -&acerhdf_dev_ops, NULL, 0,
> >> +&acerhdf_dev_ops,
> >> +&acerhdf_zone_params, 0,
> >> (kernelmode) ? interval*1000 : 0);
> >>if (IS_ERR(thz_dev))
> >>return -EINVAL;
> >>
> >> + if (strcmp(thz_dev->governor->name,
> >> + acerhdf_zone_params.governor_name)) {
> >> + pr_err("Didn't get thermal governor %s, perhaps not compiled
> >> into thermal subsystem.\n",
> >> + acerhdf_zone_params.governor_name);
> >> + retur
Re: [PATCH 0/4] x86, fpu: copy_process's FPU paths cleanups
On Wed, Aug 27, 2014 at 11:51 AM, Oleg Nesterov wrote: > > Who can review this? And where should I send FPU changes? FWIW, I have nothing against this series (or, indeed, the last series with the exception of 2/5 that got replaced by just the preemption disable). Although with the whole i387 state I always hope somebody else checks it too, and it's obviously not 3.17 material any more (possibly with the exception of the afore-mentioned preemption patch, although even that might be better off as 3.18 + stable) 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 3/3] GPIO: gpio-dwapb: Suspend & Resume PM enabling
> > Hi Weike, > > I tried out these patches on the current master branch (v3.17-rc2-9-g68e3702) > with a socfpga cyclone5 board. > > If I apply all 3 patches, the kernel doesn't boot. > > If I rebuild with only the first patch, I get only one gpio block showing up > (should > have 3 for this board) and these messages: > > > How are you testing this? The patches try to not change the current OF flow, and from the log message, the other two GPIO registered failed due to duplicate name. Let me check the code to see what happen. > > 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/
