Re: [PATCH v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special RAM,
so add gen_pool_first_fit_align to genalloc,
meanwhile add gen_pool_alloc_data to pass data to
gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang
---
Changes for v6:
- patches set v6 include a new patch because of using
- genalloc to manage QE MURAM, patch 0001 is the new
- patch, adding bytes alignment for allocation for use.
include/linux/genalloc.h | 23 +++
lib/genalloc.c | 58 +++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..55da07e 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -34,6 +34,7 @@
struct device;
struct device_node;
+struct gen_pool;
/**
* Allocation callback function type definition
@@ -47,7 +48,7 @@ typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
- void *data);
+ void *data, struct gen_pool *pool);
/*
* General purpose special memory pool descriptor.
@@ -73,6 +74,13 @@ struct gen_pool_chunk {
unsigned long bits[0]; /* bitmap for allocating memory chunk */
};
+/*
+ * gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+ int align; /* alignment by bytes for starting address */
+};
+
(sorry for chiming in late, I've been traveling)
Is there an advantage here to wrapping this in a structure instead of just
passing a pointer to an align integer?
Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mmotm 2015-08-24-16-12 uploaded
The mm-of-the-moment snapshot 2015-08-24-16-12 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.2-rc8: (patches marked "*" will be included in linux-next) arch-alpha-kernel-systblss-remove-debug-check.patch drivers-gpu-drm-i915-intel_spritec-fix-build.patch drivers-gpu-drm-i915-intel_tvc-fix-build.patch net-netfilter-ipset-work-around-gcc-444-initializer-bug.patch arm-mm-do-not-use-virt_to_idmap-for-nommu-systems.patch * memhp-add-hot-added-memory-ranges-to-memblock-before-allocate-node_data-for-a-node.patch * memhp-add-hot-added-memory-ranges-to-memblock-before-allocate-node_data-for-a-node-checkpatch-fixes.patch * ocfs2-direct-write-will-call-ocfs2_rw_unlock-twice-when-doing-aiodio.patch * kernel-kthreadc-kthread_create_on_node-clarify-documentation.patch * kernel-kthreadc-kthread_create_on_node-clarify-documentation-fix.patch * capabilities-ambient-capabilities.patch * capabilities-add-a-securebit-to-disable-pr_cap_ambient_raise.patch * clk_register_clkdev-handle-callers-needing-format-string.patch * arc-add-negative-dependency-for-vga_console.patch * fs-optimize-inotify-fsnotify-code-for-unwatched-files.patch * fsnotify-fix-check-in-inotify-fdinfo-printing.patch * fsnotify-document-mark-locking.patch * fsnotify-remove-mark-free_list.patch * fsnotify-get-rid-of-fsnotify_destroy_mark_locked.patch * scripts-spellingtxt-adding-misspelled-word-for-check.patch * scripts-spellingtxt-adding-misspelled-word-for-check-fix.patch * scripts-spellingtxt-spelling-of-uninitialized.patch * kerneldoc-convert-error-messages-to-gnu-error-message-format.patch * lindent-handle-missing-indent-gracefully.patch * scripts-decode_stacktrace-fix-arm-architecture-decoding.patch * add-some-typo-words-in-patch-into-spellingtxt.patch * ntfs-deletion-of-unnecessary-checks-before-the-function-call-iput.patch * sh-use-pfn_down-macro.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-fix-race-between-dio-and-recover-orphan.patch * ocfs2-fix-several-issues-of-append-dio.patch * ocfs2-do-not-bug-if-buffer-not-uptodate-in-__ocfs2_journal_access.patch * ocfs2-do-not-log-twice-error-messages.patch * ocfs2-clean-up-unused-local-variables-in-ocfs2_file_write_iter.patch * ocfs2-adjust-code-to-match-locking-unlocking-order.patch * ocfs2-remove-unneeded-code-in-ocfs2_dlm_init.patch * ocfs2-fix-bug-when-o2hb_register_callback-fails.patch * ocfs2-remove-unneeded-code-in-dlm_register_domain_handlers.patch * ocfs2-dlm-use-list_for_each_entry-instead-of-list_for_each.patch * ocfs2-set-filesytem-read-only-when-ocfs2_delete_entry-failed.patch * ocfs2-trusted-xattr-missing-cap_sys_admin-check.patch * ocfs2-flush-inode-data-to-disk-and-free-inode-when-i_cou
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo wrote: > Hello, > > On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: >> > Hmm... I was hoping for an actual configurations and usage scenarios. >> > Preferably something people can set up and play with. >> >> This is much easier to set up and play with synthetically. Just >> create the 10 threads and 100 threads above then experiment with >> configurations designed at guaranteeing the set of 100 threads >> relatively uniform throughput regardless of how many are active. I >> don't think trying to run a VM stack adds anything except complexity >> of reproduction here. > > Well, but that loses most of details and why such use cases matter to > begin with. We can imagine up stuff to induce arbitrary set of > requirements. All that's being proved or disproved here is that it's difficult to coordinate the consumption of asymmetric thread pools using nice. The constraints here were drawn from a real-world example. > >> > I take that the >> > CPU intensive helper threads are usually IO workers? Is the scenario >> > where the VM is set up with a lot of IO devices and different ones may >> > consume large amount of CPU cycles at any given point? >> >> Yes, generally speaking there are a few major classes of IO (flash, >> disk, network) that a guest may invoke. Each of these backends is >> separate and chooses its own threading. > > Hmmm... if that's the case, would limiting iops on those IO devices > (or classes of them) work? qemu already implements IO limit mechanism > after all. No. 1) They should proceed at the maximum rate that they can that's still within their provisioning budget. 2) The cost/IO is both inconsistent and changes over time. Attempting to micro-optimize every backend for this is infeasible, this is exactly the type of problem that the scheduler can usefully help arbitrate. 3) Even pretending (2) is fixable, dynamically dividing these right-to-work tokens between different I/O device backends is extremely complex. > > Anyways, a point here is that threads of the same process competing > isn't a new problem. There are many ways to make those threads play > nice as the application itself often has to be involved anyway, > especially for something like qemu which is heavily involved in > provisioning resources. It's certainly not a new problem, but it's a real one, and it's _hard_. You're proposing removing the best known solution. > > cgroups can be a nice brute-force add-on which lets sysadmins do wild > things but it's inherently hacky and incomplete for coordinating > threads. For example, what is it gonna do if qemu cloned vcpus and IO > helpers dynamically off of the same parent thread? We're talking about sub-process usage here. This is the application coordinating itself, NOT the sysadmin. Processes are becoming larger and larger, we need many of the same controls within them that we have between them. > It requires > application's cooperation anyway but at the same time is painful to > actually interact from those applications. As discussed elsewhere on thread this is really not a problem if you define consistent rules with respect to which parts are managed by who. The argument of potential interference is no different to messing with an application's on-disk configuration behind its back. Alternate strawmen which greatly improve this from where we are today have also been proposed. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
new file mode 100644
index 000..7f1762c
--- /dev/null
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -0,0 +1,193 @@
+/*
+ * common qe code
+ *
+ * author: scott wood
+ *
+ * copyright 2007-2008,2010 freescale Semiconductor, Inc.
+ *
+ * some parts derived from commproc.c/qe2_common.c, which is:
+ * copyright (c) 1997 dan error_act (dma...@jlc.net)
+ * copyright (c) 1999-2001 dan Malek
+ * copyright (c) 2000 montavista Software, Inc (sou...@mvista.com)
+ * 2006 (c) montavista software, Inc.
+ * vitaly bordug
+ *
+ * this program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the free software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct gen_pool *muram_pool;
+static struct genpool_data_align muram_pool_data;
+static spinlock_t qe_muram_lock;
+static u8 __iomem *muram_vbase;
+static phys_addr_t muram_pbase;
+
+struct muram_block {
+ struct list_head head;
+ unsigned long start;
+ int size;
+};
+
+static LIST_HEAD(muram_block_list);
+
+/* max address size we deal with */
+#define OF_MAX_ADDR_CELLS 4
+
+int qe_muram_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+ u32 zero[OF_MAX_ADDR_CELLS] = {};
+ resource_size_t max = 0;
+ int i = 0;
+ int ret = 0;
+
+ if (muram_pbase)
+ return 0;
+
+ muram_pool = gen_pool_create(1, -1);
+ gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
+ &muram_pool_data);
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
+ if (!np) {
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, "data-only");
+ if (!np) {
+ pr_err("Cannot find CPM muram data node");
+ ret = -ENODEV;
+ goto out;
+ }
+ }
+
+ muram_pbase = of_translate_address(np, zero);
+ if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
+ pr_err("Cannot translate zero through CPM muram node");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ while (of_address_to_resource(np, i++, &r) == 0) {
+ if (r.end > max)
+ max = r.end;
+ ret = gen_pool_add(muram_pool, r.start - muram_pbase,
+ resource_size(&r), -1);
+ if (ret) {
+ pr_err("QE MURAM: could not add muram ");
+ pr_err("remainder to pool!\n");
Don't split the error string over two lines
+ return ret;
returning here misses the error path
+ }
+
+ }
+
+ muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
+ if (!muram_vbase) {
+ pr_err("Cannot map CPM muram");
+ ret = -ENOMEM;
+ }
+
gen_pool_destroy on the error path
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(&qe_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could
pass in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry->start = start;
+ entry->size = size;
+ list_add(&entry->head, &muram_block_list);
What's the point of keeping the block list anyway? It's used only in
this file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a gen_alloc
API to do so?
+ spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+ return start;
+out:
+ gen_pool_free(muram_pool, start, size);
+ return (unsigned long) -ENOMEM;
+}
+EXPORT_SYMBOL(qe_muram_alloc);
+
+/**
+ * qe_muram_free - free a chunk of multi-user ram
+ * @offset: The beginni
[PATCH 3/3] arch/x86: make kernel/check.c explicitly non-modular
The Kconfig currently controlling compilation of this code is: arch/x86/Kconfig:config X86_CHECK_BIOS_CORRUPTION arch/x86/Kconfig: bool "Check for low memory corruption" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/kernel/check.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/check.c b/arch/x86/kernel/check.c index 58118e207a69..145863d4d343 100644 --- a/arch/x86/kernel/check.c +++ b/arch/x86/kernel/check.c @@ -1,4 +1,4 @@ -#include +#include #include #include #include @@ -163,6 +163,5 @@ static int start_periodic_check_for_corruption(void) schedule_delayed_work(&bios_check_work, 0); return 0; } - -module_init(start_periodic_check_for_corruption); +device_initcall(start_periodic_check_for_corruption); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] x86: fix instances of non-modular code using modular fcns
In the previous merge window, we made changes to allow better
delineation between modular and non-modular code in commit
0fd972a7d91d6e15393c449492a04d94c0b89351 ("module: relocate module_init
from init.h to module.h"). This allows us to now ensure module code
looks modular and non-modular code does not accidentally look modular
without suffering build breakage from header entanglement.
Here we target x86 code that is, by nature of the Kconfig/Makefile, only
available to be built-in, but implicitly presenting itself as being
possibly modular by way of using modular headers and macros.
The goal here is to remove that illusion of modularity from these
files, but in a way that leaves the actual runtime unchanged.
We also get the side benefit of a reduced CPP overhead, since the
removal of module.h from a file can reduce the number of lines emitted
by 20k.
Two of the three are the trivial mapping of module_init onto the
equivalent device_initcall ; the pmc_atom change is that too, but also
includes the removal of a no-op MODULE_DEVICE_TABLE and a corrected
comment relating to that, hence the larger diffstat there.
Paul.
---
Cc: Andy Shevchenko
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: x...@kernel.org
Paul Gortmaker (3):
x86/platform: make atom/pmc_atom.c explicitly non-modular
arch/x86: make mm/pageattr[-test].c explicitly non-modular
arch/x86: make kernel/check.c explicitly non-modular
arch/x86/kernel/check.c | 5 ++---
arch/x86/mm/pageattr-test.c | 4 ++--
arch/x86/mm/pageattr.c| 1 -
arch/x86/platform/atom/pmc_atom.c | 13 -
4 files changed, 8 insertions(+), 15 deletions(-)
--
2.5.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 2/3] arch/x86: make mm/pageattr[-test].c explicitly non-modular
The file pageattr.c is obj-y and it includes pageattr-test.c based on CPA_DEBUG (a bool), meaning that no code here is currently being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/mm/pageattr-test.c | 4 ++-- arch/x86/mm/pageattr.c | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c index 8ff686aa7e8c..5f169d5d76a8 100644 --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include @@ -256,5 +257,4 @@ static int start_pageattr_test(void) return 0; } - -module_init(start_pageattr_test); +device_initcall(start_pageattr_test); diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 727158cb3b3c..2c44c0792301 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -4,7 +4,6 @@ */ #include #include -#include #include #include #include -- 2.5.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 3.12 00/82] 3.12.47-stable review
On 08/24/2015 03:09 AM, Jiri Slaby wrote: > This is the start of the stable review cycle for the 3.12.47 release. > There are 82 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Aug 26 11:08:59 CEST 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.47-rc1.xz > and the diffstat can be found below. > > thanks, > js Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: > On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: > > > > On 24/08/15 10:22, Vinod Koul wrote: > > > On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: > > >> > > >> On 23/08/15 15:17, Vinod Koul wrote: > > >>> On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: > > >>> > > @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device > > *dev) > > int ret; > > > > /* Enable clock before accessing register */ > > - ret = tegra_dma_runtime_resume(dev); > > + ret = pm_runtime_get_sync(dev); > > >>> > > >>> why is this required ? > > >> > > >> Because the clock could be disabled when this function is called. This > > >> function saves the DMA context so that if the context is lost during > > >> suspend, it can be restored. > > > > > > Have you verified this? Coz my understanding is that when PM does suspend > > > it > > > will esnure you are runtime resume if runtime suspended and then will do > > > suspend. > > > So you do not need to do above > > > > I see what you are saying. I did some testing with ftrace today to trace > > rpm and suspend/resume calls. If the dma controller is runtime suspended > > and I do not call pm_runtime_get_sync() above then I do not see any > > runtime resume of the dma controller prior to suspend. Now I was hoping > > that this would cause a complete kernel crash but it did not and so the > > DMA clock did not appear to be needed here (at least on the one board I > > tested). However, I would not go as far as to remove this and prefer to > > keep as above. > > Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. > I have tested in past and if my driver was runtime suspended we were resumed > prior to being suspended. So I am not sure why you did not see that > behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86/platform: make atom/pmc_atom.c explicitly non-modular
The Kconfig currently controlling compilation of this code is:
config PMC_ATOM
def_bool y
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We leave some tags like MODULE_AUTHOR for documentation purposes.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We correct a comment that indicates the data was only used by that
macro, as it actually is used by the code directly.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andy Shevchenko
Cc: x...@kernel.org
Signed-off-by: Paul Gortmaker
---
arch/x86/platform/atom/pmc_atom.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/platform/atom/pmc_atom.c
b/arch/x86/platform/atom/pmc_atom.c
index e814d341a703..964ff4fc61f9 100644
--- a/arch/x86/platform/atom/pmc_atom.c
+++ b/arch/x86/platform/atom/pmc_atom.c
@@ -15,7 +15,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
#include
#include
#include
@@ -422,10 +421,7 @@ static int pmc_setup_dev(struct pci_dev *pdev, const
struct pci_device_id *ent)
/*
* Data for PCI driver interface
*
- * This data only exists for exporting the supported
- * PCI ids via MODULE_DEVICE_TABLE. We do not actually
- * register a pci_driver, because lpc_ich will register
- * a driver on the same PCI id.
+ * used by pci_match_id() call below.
*/
static const struct pci_device_id pmc_pci_ids[] = {
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_VLV_PMC),
(kernel_ulong_t)&byt_reg_map },
@@ -433,8 +429,6 @@ static const struct pci_device_id pmc_pci_ids[] = {
{ 0, },
};
-MODULE_DEVICE_TABLE(pci, pmc_pci_ids);
-
static int __init pmc_atom_init(void)
{
struct pci_dev *pdev = NULL;
@@ -457,9 +451,10 @@ static int __init pmc_atom_init(void)
return -ENODEV;
}
-module_init(pmc_atom_init);
-/* no module_exit, this driver shouldn't be unloaded */
+device_initcall(pmc_atom_init);
+/*
MODULE_AUTHOR("Aubrey Li ");
MODULE_DESCRIPTION("Intel Atom SOC Power Management Controller Interface");
MODULE_LICENSE("GPL v2");
+*/
--
2.5.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 v4 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck wrote:
> On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu wrote:
>
>> Can you boot with "debug ignore_loglevel" so we can see following print out
>> for vmemmap?
>
> See attached. There are a few extra messages from my own debug printk()
> calls. It seems that we successfully deal with node 0 from topology_init()
> but die walking node 1. I see that the NODE_DATA limits for memory
> on node 1 were from 1d7 to 3a0. But when we get into
> register_mem_sect_under_node() we have rounded the start pfn down to
> 1d0 ... and we panic processing that range (which is in a hole in e820).
>
> We seem to die here:
>
> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> int page_nid;
>
> page_nid = get_nid_for_pfn(pfn);
oh, no.
register_mem_sect_under_node() is assuming:
first section in the block is present and first page in that section is present.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] selftests/capabilities: Add tests for capability evolution
On Mon, Aug 24, 2015 at 4:03 PM, Andy Lutomirski wrote:
> This test focuses on ambient capabilities. It requires either root
> or the ability to create user namespaces. Some of the test cases
> will be skipped for nonroot users.
>
> Signed-off-by: Andy Lutomirski
Looks great! Thanks for this!
Acked-by: Kees Cook
-Kees
> ---
>
> I took taking advantage of the extra week to make my test case work :)
>
> tools/testing/selftests/capabilities/.gitignore| 2 +
> tools/testing/selftests/capabilities/Makefile | 19 +
> tools/testing/selftests/capabilities/test_execve.c | 427
> +
> .../testing/selftests/capabilities/validate_cap.c | 73
> 4 files changed, 521 insertions(+)
> create mode 100644 tools/testing/selftests/capabilities/.gitignore
> create mode 100644 tools/testing/selftests/capabilities/Makefile
> create mode 100644 tools/testing/selftests/capabilities/test_execve.c
> create mode 100644 tools/testing/selftests/capabilities/validate_cap.c
>
> diff --git a/tools/testing/selftests/capabilities/.gitignore
> b/tools/testing/selftests/capabilities/.gitignore
> new file mode 100644
> index ..b732dd0d4738
> --- /dev/null
> +++ b/tools/testing/selftests/capabilities/.gitignore
> @@ -0,0 +1,2 @@
> +test_execve
> +validate_cap
> diff --git a/tools/testing/selftests/capabilities/Makefile
> b/tools/testing/selftests/capabilities/Makefile
> new file mode 100644
> index ..5b90ed14cccb
> --- /dev/null
> +++ b/tools/testing/selftests/capabilities/Makefile
> @@ -0,0 +1,19 @@
> +all:
> +
> +include ../lib.mk
> +
> +.PHONY: all clean
> +
> +TARGETS := validate_cap test_execve
> +TEST_PROGS := test_execve
> +
> +CFLAGS := -O2 -g -std=gnu99 -Wall -lcap-ng
> +
> +all: $(TARGETS)
> +
> +clean:
> + $(RM) $(TARGETS)
> +
> +$(TARGETS): %: %.c
> + $(CC) -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
> +
> diff --git a/tools/testing/selftests/capabilities/test_execve.c
> b/tools/testing/selftests/capabilities/test_execve.c
> new file mode 100644
> index ..10a21a958aaf
> --- /dev/null
> +++ b/tools/testing/selftests/capabilities/test_execve.c
> @@ -0,0 +1,427 @@
> +#define _GNU_SOURCE
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifndef PR_CAP_AMBIENT
> +#define PR_CAP_AMBIENT 47
> +# define PR_CAP_AMBIENT_IS_SET 1
> +# define PR_CAP_AMBIENT_RAISE 2
> +# define PR_CAP_AMBIENT_LOWER 3
> +# define PR_CAP_AMBIENT_CLEAR_ALL 4
> +#endif
> +
> +static int nerrs;
> +
> +static void vmaybe_write_file(bool enoent_ok, char *filename, char *fmt,
> va_list ap)
> +{
> + char buf[4096];
> + int fd;
> + ssize_t written;
> + int buf_len;
> +
> + buf_len = vsnprintf(buf, sizeof(buf), fmt, ap);
> + if (buf_len < 0) {
> + err(1, "vsnprintf failed");
> + }
> + if (buf_len >= sizeof(buf)) {
> + errx(1, "vsnprintf output truncated");
> + }
> +
> + fd = open(filename, O_WRONLY);
> + if (fd < 0) {
> + if ((errno == ENOENT) && enoent_ok)
> + return;
> + err(1, "open of %s failed", filename);
> + }
> + written = write(fd, buf, buf_len);
> + if (written != buf_len) {
> + if (written >= 0) {
> + errx(1, "short write to %s", filename);
> + } else {
> + err(1, "write to %s failed", filename);
> + }
> + }
> + if (close(fd) != 0) {
> + err(1, "close of %s failed", filename);
> + }
> +}
> +
> +static void maybe_write_file(char *filename, char *fmt, ...)
> +{
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vmaybe_write_file(true, filename, fmt, ap);
> + va_end(ap);
> +}
> +
> +static void write_file(char *filename, char *fmt, ...)
> +{
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vmaybe_write_file(false, filename, fmt, ap);
> + va_end(ap);
> +}
> +
> +static bool create_and_enter_ns(uid_t inner_uid)
> +{
> + uid_t outer_uid;
> + gid_t outer_gid;
> + int i;
> + bool have_outer_privilege;
> +
> + outer_uid = getuid();
> + outer_gid = getgid();
> +
> + /*
> +* TODO: If we're already root, we could skip creating the userns.
> +*/
> +
> + if (unshare(CLONE_NEWNS) == 0) {
> + printf("[NOTE]\tUsing global UIDs for tests\n");
> + if (prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0) != 0)
> + err(1, "PR_SET_KEEPCAPS");
> + if (setresuid(inner_uid, inner_uid, -1) != 0)
> + err(1, "setresuid");
> +
> + // Re-enable effective caps
> + capng_get_caps_process();
>
Lockups with 4.2-rc kernels and qemu
(Cc'ing qemu-devel, please keep me in the Cc). TL;DR - qemu locks up my machine when I use 4.2-rc kernels. I only use qemu from time to time, mostly to test changes to my own scripts, or new package versions, in beyond.linuxfromscratch.org. A few days ago I came back to that, building an LFS system from the beginning of this month and then using that to try out my changes. In the beginning I built a 4.2-rc5 kernel and booted that system in qemu-2.4.0. I had several lockups along the way from a minimal system to the end of my attempts to build a full desktop, and in fact I dropped back to a 4.1 kernel and qemu-2.3.0 before I completed the build. Mostly, the qemu system appeared to have been idle when the box locked up, or else idle apart from xscreensaver, but on one occasion it ran through several steps to build Xorg protocol header packages - I write a 'stamp' file so that I can resume after a failure, and several of these were created, but empty (instead of a small amount of version, time, space data) and it later turned out that nothing had been installed for those packages. In all cases I have nothing relevant in either the guest or the host logs. On one or two occasions I got the flashing keyboard LEDs. After the initial problems I ran memtest86+ for 10 hours without any errors. In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0 because my concern was to finish the build. I was thinking - erroneously, of course - that this was a qemu problem. Gradually, I moved to 4.2-rc kernels and things appeared to be ok. But today I installed 4.2-rc8 and thought about trying to create a test-case to see if the kernel+qemu combination is probably ok. I decided to start qemu, login, run startx [ xscreensaver will be invoked, otherwise userspace is idle ], and leave it for 3 hours - lockups varied in how long they took to appear, but all were in 2 hours or less. So, I left -rc8 and qemu-2.3.0, and when I returned to it after about 3 and a quarter hours the box had locked up. The machine is an AMD phenom (not always the most reliable, I had to drop caches today to get it to reliably build -rc8 with make -j 4 but otherwise it seems to have not needed that in the past month). I'll attach the kernel config. I compiled qemu-2.3.0 with: sed -i '/resource/ i#include ' \ fsdev/virtfs-proxy-helper.c ./configure --prefix=/usr \ --sysconfdir=/etc \ --docdir=/usr/share/doc/qemu-2.3.0 \ --target-list=x86_64-softmmu \ --audio-drv-list=alsa and I use a wrapper script for qemu which tells me that what I am actually running is: qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb svn-logging-tools.img -m 2G -usb -usbdevice tablet -show-cursor -display sdl -cpu kvm32 -monitor stdio -smp 4 -vga std That was for building a new system, later runs only use a -hda image. And all of the uses have been for i686 guests. The host (and the initial guest used to build the new system) is gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1; glibc 2.21 throughout. Because I need to leave the system running for up to 3 hours to get an idea if a particular kernel is ok, I don't think this problem lends itself to bisection. Any suggestions, please ? ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction. # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.2.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZI
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On Mon, Aug 24, 2015 at 01:19:24PM -0400, Jeff Moyer wrote: > Brian Norris writes: > > > On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote: > >> Now, some user-space fails when direct I/O is not supported. > > > > I think the whole argument rested on what it means when "some user space > > fails"; apparently that "user space" is just a test suite (which > > can/should be fixed). > > Even if it wasn't a test suite it should still fail. Either the fs > supports O_DIRECT or it doesn't. Right now, the only way an application > can figure this out is to try an open and see if it fails. Don't break > that. Who cares how a filesystem implements O_DIRECT as long as it does not corrupt data? ext3 fell back to buffered IO in many situations, yet the only complaints about that were performance. IOWs, it's long been true that if the user cares about O_DIRECT *performance* then they have to be careful about their choice of filesystem. But if it's only 5 lines of code per filesystem to support O_DIRECT *correctly* via buffered IO, then exactly why should userspace have to jump through hoops to explicitly handle open(O_DIRECT) failure? Especially when you consider that all they can do is fall back to buffered IO themselves Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Fix error message and present UFS variant
Hi Yaniv, 2015-08-23 22:09 GMT+09:00 Yaniv Gardi : > V3: fixes a few minor issues. > > V2: fixes a few issues of unnecessary EXPORT_SYMBOL, > types of parameters in routine definition, > build errors in case CONFIG_PM is not defined and some > other minor fixes. I've checked outstanding issues I reported for v1 and v2 are fixed in this version of series. So please feel free to add: Reviewed-by: Akinobu Mita I still think that we should introduce print_hex_dump_io() or something simpler for dumping __iomem pointer instead of casting 'void __force *'. But it is only used for debug dump function, so I don't too much worry about it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] Documentation: drm/bridge: add document for analogix_dp
On 24.08.2015 21:48, Yakir Yang wrote: > Hi Krzysztof, > > 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道: >> On 24.08.2015 11:42, Yakir Yang wrote: >>> Hi Krzysztof, >>> >>> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道: 2015-08-24 8:23 GMT+09:00 Rob Herring : > On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang > wrote: >> Analogix dp driver is split from exynos dp driver, so we just >> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt >> >> Beside update some exynos dtsi file with the latest change >> according to the devicetree binding documents. > You can't just change the exynos bindings and break compatibility. Is > there some agreement with exynos folks to do this? No, there is no agreement. This wasn't even sent to Exynos maintainers. >>> Sorry about this one, actually I have add Exynos maintainers in version >>> 1 & version 2, >>> but lose some maintainers in version 3, I would fix it in bellow >>> versions. >>> Additionally the patchset did not look interesting to me because of misleading subject - Documentation instead of "ARM: dts:". Yakir, please: 1. Provide backward compatibility. Mark old properties as deprecated but still support them. >>> Do you mean that I should keep the old properties declare in >>> exynos-dp.txt, >>> but just mark them as deprecated flag. >> That is one of ways how to do this. However more important is that >> driver should still support old bindings so such code: >> - if (of_property_read_u32(dp_node, "samsung,color-space", >> + if (of_property_read_u32(dp_node, "analogix,color-space", >> >> is probably wrong. Will the driver support old DTB in the same way as it >> was supporting before the change? > > Okay, I got your means. So document is not the focus, the most important > is that > driver should support the old dts prop. Right, the focus is on the driver. > If so the new analogix dp driver > should keep > the "samsung,color-space", rather then just mark it with [DEPRECATED] flag. If you are replacing a binding/property then it should be marked deprecated. This means that the old property is still working but new users of it should not be added. > > But from your follow suggest, I think you agree to update driver code, > and just mark > old prop with deprecated flag. If so I think such code would not be wrong > > - if (of_property_read_u32(dp_node, "samsung,color-space", > + if (of_property_read_u32(dp_node, "analogix,color-space", It looks wrong because it breaks backward compatibility with existing DTB. As I said before: >>> 1. Provide backward compatibility. Mark old properties >>> as deprecated but still support them. > And actually @Rob have suggest me to remove the prefix, just use > "color-space" here. For new bindings I don't mind. But please remember about existing users, existing DTB and bisectability. > >> >>> Let me show same examples, make >>> me understand your suggest rightly. >> exynos-dp already contains deprecated properties. Other ways of doing >> this would be: >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt >> Documentation/devicetree/bindings/rtc/s3c-rtc.txt >> >> It depends up to you. The "touchscreen" looks good because it organizes >> old properties in a common section. In case of exynos-dp.txt you can add >> at beginning of file information about new bindings and mark everything >> deprecated. > > Whoops, thanks for your remind, I prefer the "touchscreen" style. > >>> 1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver, >>> absolutely >>> I should not carry this to analogix-dp.txt document. But I should >>> keep this in >>> exynos-dp.txt document, and mark them with an little >>> "deprecated" flag. >>> >>> [Documentation/devicetree/bindings/video/exynos_dp.txt] >>> Required properties for dp-controller: >>> [...] >>> -samsung,ycbcr-coeff (DEPRECATED): >>> YCbCr co-efficients for input video. >>> COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 >>> >>> Is it right ? >> Yes, this is right. >> 2. Separate all DTS changes to a separate patch, unless bisectability would be hurt. Anyway you should prepare it in a such way that separation would be possible without breaking bisectability. >>> So I should separate this patch into two parts, one is name "Document:", >>> the other is "ARM: dts: ". >> Yes. >> >>> Honestly, I don't understand what the "bisectability" means in this >>> case. >> I was referring to bisectability in general. The patchset should be >> fully bisectable which means that it does not introduce any issues >> during "git bisect". This effectively means that at each intermediate >> step (after applying each patch, one by one) every existing stuff works >> the same as previously without any regression. Including booting with >> old DTB. > > Oh, thanks for your careful explain, so I guess your first comment is > talking about >
Re: [BUG] arm: kgdb: patch_text() in kgdb_arch_set_breakpoint() may sleep
Kees, On Mon, Aug 24, 2015 at 10:46 AM, Kees Cook wrote: > On Sun, Aug 23, 2015 at 7:45 PM, Doug Anderson wrote: >> On Wed, Aug 5, 2015 at 8:50 AM, Aapo Vienamo wrote: >>> Hi, >>> >>> The breakpoint setting code in arch/arm/kernel/kgdb.c calls >>> patch_text(), which ends up trying to sleep while in interrupt context. >>> The bug was introduced by commit: 23a4e40 arm: kgdb: Handle read-only >>> text / modules. The resulting behavior is "BUG: scheduling while >>> atomic..." when setting a breakpoint in kgdb. This was tested on an >>> Nvidia Jetson TK1 board with 4.2.0-rc5-next-20150805 kernel. >>> >>> Regards, >>> Aapo Vienamo >> >> Aapo, >> >> Including the stack trace with this would have been helpful, though >> it's not too hard to reproduce. Here it is: >> >> [ 416.510559] BUG: scheduling while atomic: swapper/0/0/0x00010007 >> [ 416.516554] Modules linked in: >> [ 416.519614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 4.2.0-rc7-00133-geb63b34 #1073 >> [ 416.527341] Hardware name: Rockchip (Device Tree) >> [ 416.532042] [] (unwind_backtrace) from [] >> (show_stack+0x20/0x24) >> [ 416.539772] [] (show_stack) from [] >> (dump_stack+0x84/0xb8) >> [ 416.546983] [] (dump_stack) from [] >> (__schedule_bug+0x54/0x6c) >> [ 416.554540] [] (__schedule_bug) from [] >> (__schedule+0x80/0x668) >> [ 416.562183] [] (__schedule) from [] >> (schedule+0xb8/0xd4) >> [ 416.569219] [] (schedule) from [] >> (schedule_timeout+0x2c/0x234) >> [ 416.576861] [] (schedule_timeout) from [] >> (wait_for_common+0xf4/0x188) >> [ 416.585109] [] (wait_for_common) from [] >> (wait_for_completion+0x20/0x24) >> [ 416.593531] [] (wait_for_completion) from [] >> (__stop_cpus+0x58/0x70) >> [ 416.601608] [] (__stop_cpus) from [] >> (stop_cpus+0x3c/0x54) >> [ 416.608817] [] (stop_cpus) from [] >> (__stop_machine+0xcc/0xe8) >> [ 416.616286] [] (__stop_machine) from [] >> (stop_machine+0x34/0x44) >> [ 416.624016] [] (stop_machine) from [] >> (patch_text+0x28/0x34) >> [ 416.631399] [] (patch_text) from [] >> (kgdb_arch_set_breakpoint+0x40/0x4c) >> [ 416.639823] [] (kgdb_arch_set_breakpoint) from >> [] (kgdb_validate_break_address+0x2c/0x60) >> [ 416.649719] [] (kgdb_validate_break_address) from >> [] (dbg_set_sw_break+0x1c/0xdc) >> [ 416.658922] [] (dbg_set_sw_break) from [] >> (gdb_serial_stub+0x9c4/0xba4) >> [ 416.667259] [] (gdb_serial_stub) from [] >> (kgdb_cpu_enter+0x1f8/0x60c) >> [ 416.675423] [] (kgdb_cpu_enter) from [] >> (kgdb_handle_exception+0x19c/0x1d0) >> [ 416.684106] [] (kgdb_handle_exception) from [] >> (kgdb_compiled_brk_fn+0x30/0x3c) >> [ 416.693135] [] (kgdb_compiled_brk_fn) from [] >> (do_undefinstr+0x1a4/0x20c) >> [ 416.701643] [] (do_undefinstr) from [] >> (__und_svc_finish+0x0/0x34) >> [ 416.709543] Exception stack(0xc07c1ce8 to 0xc07c1d30) >> [ 416.714584] 1ce0: c07c6504 c086e290 >> c086e294 c086e294 c086e290 >> [ 416.722745] 1d00: c07c6504 0067 0001 c07c2100 0027 >> c07c1d4c c07c1d50 c07c1d30 >> [ 416.730905] 1d20: c00a0990 c00a08d0 6193 >> [ 416.735947] [] (__und_svc_finish) from [] >> (kgdb_breakpoint+0x58/0x94) >> [ 416.744110] [] (kgdb_breakpoint) from [] >> (sysrq_handle_dbg+0x58/0x6c) >> [ 416.752273] [] (sysrq_handle_dbg) from [] >> (__handle_sysrq+0xac/0x15c) >> [ 416.760437] [] (__handle_sysrq) from [] >> (handle_sysrq+0x30/0x34) >> >> >> Kees: I think you've dealt with a lot more of these types of issues >> than I have. Any quick thoughts? If not I can put it on my long-term >> list of things to do, but until then we could always just post a >> Revert... > > I don't think a revert is in order here. CONFIG_DEBUG_RODATA could be > turned off for builds where you need kgdb while this bug gets found. I don't think that's right. In my testing I don't have CONFIG_DEBUG_RODATA. I think I did the right grep: $ grep ARM_KERNMEM_PERMS .config # CONFIG_ARM_KERNMEM_PERMS is not set Basically no matter what we'll call: - kgdb_arch_set_breakpoint -- patch_text --- stop_machine ...no dependencies on RODATA. > I > don't actually see where we've gone wrong, though. Looks like > scheduling happened while waiting for CPUs to stop? Where did we enter > atomic? We're in kdb. That's a stop mode debugger. No sleeping allowed while in the debugger. > Perhaps we need to test if we're already atomic in patch_text, and > only call stop_machine if we need to? > > Untested (and likely mangled by gmail): > > diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c > index 69bda1a5707e..855696bfe072 100644 > --- a/arch/arm/kernel/patch.c > +++ b/arch/arm/kernel/patch.c > @@ -124,5 +124,8 @@ void __kprobes patch_text(void *addr, unsigned int insn) > .insn = insn, > }; > > - stop_machine(patch_text_stop_machine, &patch, NULL); > + if (unlikely(in_atomic_preempt_off())) > + patch_text_stop_machine(&patch); > + else > + stop_machine(patch_text_stop_machine, &patch,
[PATCH] ARM: probes: Don't stop the machine if we're in the debugger
If we're in kgdb then the machine is already stopped. Trying to stop it again will cause us to try to sleep, which is not allowed while in kgdb. To avoid this problem, only stop the machine when we're not in kgdb. Reported-by: Aapo Vienamo Suggested-by: Kees Cook Signed-off-by: Douglas Anderson --- arch/arm/kernel/patch.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c index 69bda1a..abf30ec 100644 --- a/arch/arm/kernel/patch.c +++ b/arch/arm/kernel/patch.c @@ -1,5 +1,6 @@ #include #include +#include #include #include #include @@ -124,6 +125,9 @@ void __kprobes patch_text(void *addr, unsigned int insn) .insn = insn, }; - stop_machine(patch_text_stop_machine, &patch, NULL); + /* Stop machine before patching; but not if in the debugger */ + if (unlikely(in_dbg_master())) + patch_text_stop_machine(&patch); + else + stop_machine(patch_text_stop_machine, &patch, NULL); } -- 2.5.0.457.gab17608 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Mon, Aug 24, 2015 at 4:41 PM, Yinghai Lu wrote:
> On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck wrote:
>> On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu wrote:
>>
>>> Can you boot with "debug ignore_loglevel" so we can see following print out
>>> for vmemmap?
>>
>> See attached. There are a few extra messages from my own debug printk()
>> calls. It seems that we successfully deal with node 0 from topology_init()
>> but die walking node 1. I see that the NODE_DATA limits for memory
>> on node 1 were from 1d7 to 3a0. But when we get into
>> register_mem_sect_under_node() we have rounded the start pfn down to
>> 1d0 ... and we panic processing that range (which is in a hole in e820).
>>
>> We seem to die here:
>>
>> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
>> int page_nid;
>>
>> page_nid = get_nid_for_pfn(pfn);
>
> oh, no.
> register_mem_sect_under_node() is assuming:
> first section in the block is present and first page in that section is
> present.
attached should fix the problem:
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 31df474d..cc910ad 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block *mem_blk, int nid)
sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
- int page_nid;
+ int page_nid, scn_nr;
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+ PAGES_PER_SECTION) - 1;
+ continue;
+ }
page_nid = get_nid_for_pfn(pfn);
if (page_nid < 0)
continue;
@@ -426,10 +432,18 @@ int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
return -ENOMEM;
nodes_clear(*unlinked_nodes);
- sect_start_pfn = section_nr_to_pfn(phys_index);
- sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
+ sect_start_pfn = section_nr_to_pfn(mem_blk->start_section_nr);
+ sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
+ sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
- int nid;
+ int nid, scn_nr;
+
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+ PAGES_PER_SECTION) - 1;
+ continue;
+ }
nid = get_nid_for_pfn(pfn);
if (nid < 0)
Re: [PATCH v4 13/52] PCI, acpiphp: Add missing realloc list checking after resource allocation
On Monday, August 24, 2015 03:14:26 PM Yinghai Lu wrote:
> On Mon, Aug 24, 2015 at 3:09 PM, Rafael J. Wysocki wrote:
> > On Thursday, August 20, 2015 11:20:28 PM Yinghai Lu wrote:
> >> We check the realloc list, as list must be empty after allocation.
> >>
> >> Add missing one acpiphp driver.
> >>
> >> Signed-off-by: Yinghai Lu
> >> Cc: "Rafael J. Wysocki"
> >> Cc: Len Brown
> >> Cc: linux-a...@vger.kernel.org
> >> ---
> >> drivers/pci/hotplug/acpiphp_glue.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> >> b/drivers/pci/hotplug/acpiphp_glue.c
> >> index ff53856..1c7c1d7 100644
> >> --- a/drivers/pci/hotplug/acpiphp_glue.c
> >> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> >> @@ -507,6 +507,7 @@ static void enable_slot(struct acpiphp_slot *slot)
> >> }
> >> }
> >> __pci_bus_assign_resources(bus, &add_list, NULL);
> >> + BUG_ON(!list_empty(&add_list));
> >
> > Is crashing the kernel the best we can do here?
> >
> > What about bailing out with a WARN_ON() instead? Surely, the kernel can
> > work
> > without the new device?
>
> That should not happen.
> If that list is not empty, we could have broken the assign logic for
> optional or additional
> resource allocation.
>
> We have other two BUG_ON checking in drivers/pci/setup-bus.c.
>
> Do we need to change them all to WARN_ON()?
>
> or you prefer this version instead:
I like this patch better, but the question really is how bad things can get
if we continue. And if they can get critically bad, whether or not we still
are able to catch that critical error later on.
> ---
>
> Subject: [PATCH] PCI: Separate realloc list checking after allocation
>
> We check the realloc list, as list must be empty after allocation.
>
> Separate the realloc list checking to another function.
>
> Add checking that is missed in acpiphp driver.
>
> -v2: change to WARN_ON addording to Rafael.
>
> Signed-off-by: Yinghai Lu
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/pci/hotplug/acpiphp_glue.c |1 +
> drivers/pci/pci.h |1 +
> drivers/pci/setup-bus.c| 12 +---
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
> ===
> --- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
> +++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
> @@ -507,6 +507,7 @@ static void enable_slot(struct acpiphp_s
> }
> }
> __pci_bus_assign_resources(bus, &add_list, NULL);
> +pci_bus_check_realloc(&add_list);
>
> acpiphp_sanitize_bus(bus);
> pcie_bus_configure_settings(bus);
> Index: linux-2.6/drivers/pci/pci.h
> ===
> --- linux-2.6.orig/drivers/pci/pci.h
> +++ linux-2.6/drivers/pci/pci.h
> @@ -237,6 +237,7 @@ void __pci_bus_size_bridges(struct pci_b
> void __pci_bus_assign_resources(const struct pci_bus *bus,
> struct list_head *realloc_head,
> struct list_head *fail_head);
> +void pci_bus_check_realloc(struct list_head *realloc_head);
> bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
>
> void pci_reassigndev_resource_alignment(struct pci_dev *dev);
> Index: linux-2.6/drivers/pci/setup-bus.c
> ===
> --- linux-2.6.orig/drivers/pci/setup-bus.c
> +++ linux-2.6/drivers/pci/setup-bus.c
> @@ -349,6 +349,12 @@ out:
> }
> }
>
> +void pci_bus_check_realloc(struct list_head *realloc_head)
> +{
> +if (WARN_ON(!list_empty(realloc_head)))
> +free_list(realloc_head);
> +}
> +
> /**
> * assign_requested_resources_sorted() - satisfy resource requests
> *
> @@ -1860,7 +1866,7 @@ again:
> /* Depth last, allocate resources and update the hardware. */
> __pci_bus_assign_resources(bus, add_list, &fail_head);
> if (add_list)
> -BUG_ON(!list_empty(add_list));
> +pci_bus_check_realloc(add_list);
> tried_times++;
>
> /* any device complain? */
> @@ -1935,7 +1941,7 @@ void pci_assign_unassigned_bridge_resour
> again:
> __pci_bus_size_bridges(parent, &add_list);
> __pci_bridge_assign_resources(bridge, &add_list, &fail_head);
> -BUG_ON(!list_empty(&add_list));
> +pci_bus_check_realloc(&add_list);
> tried_times++;
>
> if (list_empty(&fail_head))
> @@ -1994,6 +2000,6 @@ void pci_assign_unassigned_bus_resources
> &add_list);
> up_read(&pci_bus_sem);
> __pci_bus_assign_resources(bus, &add_list, NULL);
> -BUG_ON(!list_empty(&add_list));
> +pci_bus_check_realloc(&add_list);
> }
> EXPORT_SYMBOL_GPL(pci_assign_unassigned_bus_resources);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular
On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker wrote: >The Kconfig currently controlling compilation of this code is: > >config CLEANCACHE >bool "Enable cleancache driver to cache clean pages if tmem is present" > >...meaning that it currently is not being built as a module by anyone. Why not make it a tristate? > >Lets remove the couple traces of modularity so that when reading the >driver there is no doubt it is builtin-only. > >Since module_init translates to device_initcall in the non-modular >case, the init ordering remains unchanged with this commit. > >Cc: Konrad Rzeszutek Wilk >Cc: linux...@kvack.org >Signed-off-by: Paul Gortmaker >--- > mm/cleancache.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/mm/cleancache.c b/mm/cleancache.c >index 8fc5089b..ee0646d1c2fa 100644 >--- a/mm/cleancache.c >+++ b/mm/cleancache.c >@@ -11,7 +11,7 @@ > * This work is licensed under the terms of the GNU GPL, version 2. > */ > >-#include >+#include > #include > #include > #include >@@ -316,4 +316,4 @@ static int __init init_cleancache(void) > #endif > return 0; > } >-module_init(init_cleancache) >+device_initcall(init_cleancache) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v2 02/11] soc/fsl: Introduce DPAA BMan device management driver
On Wed, 2015-08-12 at 16:14 -0400, Roy Pledge wrote: > From: Geoff Thorpe > > This driver enables the Freescale DPAA 1.0 Buffer Manager block. BMan > is a hardware buffer pool manager that allows accelerators > connected to the SoC datapath to acquire and release buffers during > data processing. > > Signed-off-by: Geoff Thorpe > Signed-off-by: Emil Medve > Signed-off-by: Roy Pledge > --- > drivers/soc/Kconfig |1 + > drivers/soc/Makefile |1 + > drivers/soc/fsl/Kconfig |5 + > drivers/soc/fsl/Makefile |3 + > drivers/soc/fsl/qbman/Kconfig | 25 ++ > drivers/soc/fsl/qbman/Makefile|1 + > drivers/soc/fsl/qbman/bman.c | 553 > + > drivers/soc/fsl/qbman/bman_priv.h | 53 > drivers/soc/fsl/qbman/dpaa_sys.h | 55 > 9 files changed, 697 insertions(+) > create mode 100644 drivers/soc/fsl/Kconfig > create mode 100644 drivers/soc/fsl/Makefile > create mode 100644 drivers/soc/fsl/qbman/Kconfig > create mode 100644 drivers/soc/fsl/qbman/Makefile > create mode 100644 drivers/soc/fsl/qbman/bman.c > create mode 100644 drivers/soc/fsl/qbman/bman_priv.h > create mode 100644 drivers/soc/fsl/qbman/dpaa_sys.h > > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig > index 96ddecb..4e3c8f4 100644 > --- a/drivers/soc/Kconfig > +++ b/drivers/soc/Kconfig > @@ -1,6 +1,7 @@ > menu "SOC (System On Chip) specific Drivers" > > source "drivers/soc/mediatek/Kconfig" > +source "drivers/soc/fsl/Kconfig" > source "drivers/soc/qcom/Kconfig" > source "drivers/soc/sunxi/Kconfig" > source "drivers/soc/ti/Kconfig" > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile > index 7dc7c0d..7adcd97 100644 > --- a/drivers/soc/Makefile > +++ b/drivers/soc/Makefile > @@ -3,6 +3,7 @@ > # > > obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ > +obj-$(CONFIG_FSL_SOC)+= fsl/ > obj-$(CONFIG_ARCH_QCOM) += qcom/ > obj-$(CONFIG_ARCH_SUNXI) += sunxi/ > obj-$(CONFIG_ARCH_TEGRA) += tegra/ > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig > new file mode 100644 > index 000..daa9c0d > --- /dev/null > +++ b/drivers/soc/fsl/Kconfig > @@ -0,0 +1,5 @@ > +menu "Freescale SOC (System On Chip) specific Drivers" > + > +source "drivers/soc/fsl/qbman/Kconfig" > + > +endmenu > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile > new file mode 100644 > index 000..19e74bb > --- /dev/null > +++ b/drivers/soc/fsl/Makefile > @@ -0,0 +1,3 @@ > +# Common > +obj-$(CONFIG_FSL_DPA)+= qbman/ > + > diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig > new file mode 100644 > index 000..be4ae01 > --- /dev/null > +++ b/drivers/soc/fsl/qbman/Kconfig > @@ -0,0 +1,25 @@ > +menuconfig FSL_DPA > + bool "Freescale DPAA support" > + depends on FSL_SOC || COMPILE_TEST > + default n Drop the COMPILE_TEST -- this driver still has PPCisms that will break the build elsewhere. > + help > + FSL Data-Path Acceleration Architecture drivers > + > + These are not the actual Ethernet driver(s) > + > +if FSL_DPA > + > +config FSL_DPA_CHECKING > + bool "additional driver checking" > + default n > + help > + Compiles in additional checks to sanity-check the drivers and > + any use of it by other code. Not recommended for performance > + > +config FSL_BMAN > + tristate "BMan device management" > + default n > + help > + FSL DPAA BMan driver Please describe here what BMan is and when it should be enabled. Why isn't it always enabled when DPA is enabled? > +endif # FSL_DPA > diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile > new file mode 100644 > index 000..02014d9 > --- /dev/null > +++ b/drivers/soc/fsl/qbman/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_FSL_BMAN) += bman.o > diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c > new file mode 100644 > index 000..9a500ce > --- /dev/null > +++ b/drivers/soc/fsl/qbman/bman.c > @@ -0,0 +1,553 @@ > +/* Copyright (c) 2009 - 2015 Freescale Semiconductor, Inc. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are > met: > + * * Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * * Neither the name of Freescale Semiconductor nor the > + *names of its contributors may be used to endorse or promote products > + *derived from this software without specific prior writte
Re: [PATCH v4 13/52] PCI, acpiphp: Add missing realloc list checking after resource allocation
On Mon, Aug 24, 2015 at 5:37 PM, Rafael J. Wysocki wrote: > On Monday, August 24, 2015 03:14:26 PM Yinghai Lu wrote: > > I like this patch better, but the question really is how bad things can get > if we continue. And if they can get critically bad, whether or not we still > are able to catch that critical error later on. Some devices BARs could have not been assigned. Then drivers would not work properly. And if we want to go on, we at least need to avoid memory leaking with calling free_list(). Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF
Hi Vinod
> > 5fa422c ("dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c")
> > moved OF base DMAEngine code to of-dma.c, then it based on CONFIG_DMA_OF.
> > But, OF base DMAEngine API on of_dma.h still based on CONFIG_OF now.
> > So, current kernel can't find OF base DMAEngine API if .config has
> > CONFIG_OF,
> > but not have CONFIG_DMA_OF. This patch tidyup it.
>
> I did a quick build with arm config, but didn't see any failures. But still
> am worried about random config and other builds may find.
>
> So I think it would be safer to merge this patch after merge window so that
> we have ample time to fix any issue
OK, 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/
Warning in irq_work_queue_on()
Hello, Tejun, As discussed last week, I am getting an occasional warning out of irq_work_queue_on() WARN_ON_ONCE(cpu_is_offline(cpu)). The repeat-by seems to be a week or so of rcutorture runs on 16-CPU KVM instances on x86. So please see below on the off-chance that this is of use. I have also attached a .config file. Thoughts? Thanx, Paul [ 875.702254] [ cut here ] [ 875.703111] WARNING: CPU: 0 PID: 768 at /home/paulmck/public_git/bisect-linux-rcu/kernel/irq_work.c:69 irq_work_queue_on+0xd4/0x110() [ 875.703227] Modules linked in: [ 875.703227] CPU: 0 PID: 768 Comm: rcu_torture_rea Tainted: GW 4.1.0-rc4+ #1 [ 875.703227] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 875.703227] 81baadd8 88001dc5fce8 81895418 00aa [ 875.703227] 88001dc5fd28 810517d5 00015bc0 [ 875.703227] 0004 0004 88001fc8f980 88001fc8d500 [ 875.703227] Call Trace: [ 875.703227] [] dump_stack+0x45/0x57 [ 875.703227] [] warn_slowpath_common+0x85/0xc0 [ 875.703227] [] warn_slowpath_null+0x15/0x20 [ 875.703227] [] irq_work_queue_on+0xd4/0x110 [ 875.703227] [] tick_nohz_full_kick_cpu+0x44/0x50 [ 875.703227] [] wake_up_nohz_cpu+0xb4/0x100 [ 875.703227] [] internal_add_timer+0x86/0xa0 [ 875.703227] [] mod_timer+0xf1/0x1e0 [ 875.703227] [] rcu_torture_reader+0x2a4/0x2e0 [ 875.703227] [] ? rcu_torture_reader+0x2e0/0x2e0 [ 875.703227] [] ? rcutorture_trace_dump.part.10+0x20/0x20 [ 875.703227] [] kthread+0xcd/0xf0 [ 875.703227] [] ? kthread_create_on_node+0x180/0x180 [ 875.703227] [] ret_from_fork+0x42/0x70 [ 875.703227] [] ? kthread_create_on_node+0x180/0x180 [ 875.703227] ---[ end trace 74175128740d0113 ]--- # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0-rc4 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y # CONFIG_NO_HZ_FULL_ALL is not set CONF
Re: [PATCH] Input: edt-ft5x06 - Switch to newer gpio framework
On Mon, Aug 24, 2015 at 05:16:15PM -0500, Franklin S Cooper Jr. wrote:
>
>
> On 08/24/2015 03:56 PM, Dmitry Torokhov wrote:
> > On Mon, Aug 24, 2015 at 03:23:43PM -0500, Franklin S Cooper Jr. wrote:
> >>
> >> On 08/24/2015 03:16 PM, Franklin S Cooper Jr. wrote:
> >>> On 08/24/2015 03:01 PM, Dmitry Torokhov wrote:
> On Mon, Aug 24, 2015 at 02:48:36PM -0500, Franklin S Cooper Jr. wrote:
> > On 08/24/2015 02:41 PM, Dmitry Torokhov wrote:
> >> On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
> >>> The current/old gpio framework used doesn't properly listen to
> >>> ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
> >>> account these flags when setting gpio values.
> >>>
> >>> Also use gpiod_set_value_cansleep since wake and reset pins can be
> >>> provided by bus based io expanders.
> >>>
> >>> Signed-off-by: Franklin S Cooper Jr
> >>> ---
> >>> .../bindings/input/touchscreen/edt-ft5x06.txt | 4 +-
> >>> drivers/input/touchscreen/edt-ft5x06.c | 115
> >>> +++--
> >>> include/linux/input/edt-ft5x06.h | 4 +-
> >>> 3 files changed, 43 insertions(+), 80 deletions(-)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> >>> b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> >>> index 76db967..9330d4d 100644
> >>> ---
> >>> a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> >>> +++
> >>> b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> >>> @@ -50,6 +50,6 @@ Example:
> >>> pinctrl-0 = <&edt_ft5x06_pins>;
> >>> interrupt-parent = <&gpio2>;
> >>> interrupts = <5 0>;
> >>> - reset-gpios = <&gpio2 6 1>;
> >>> - wake-gpios = <&gpio4 9 0>;
> >>> + reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
> >>> + wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> >>> };
> >>> diff --git a/drivers/input/touchscreen/edt-ft5x06.c
> >>> b/drivers/input/touchscreen/edt-ft5x06.c
> >>> index 394b1de..6b128b3 100644
> >>> --- a/drivers/input/touchscreen/edt-ft5x06.c
> >>> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> >>> @@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
> >>> u16 num_x;
> >>> u16 num_y;
> >>>
> >>> - int reset_pin;
> >>> - int irq_pin;
> >>> - int wake_pin;
> >>> + struct gpio_desc *reset_pin;
> >>> + struct gpio_desc *wake_pin;
> >>> + struct gpio_desc *irq_pin;
> >>>
> >>> #if defined(CONFIG_DEBUG_FS)
> >>> struct dentry *debug_dir;
> >>> @@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct
> >>> edt_ft5x06_ts_data *tsdata)
> >>> static int edt_ft5x06_ts_reset(struct i2c_client *client,
> >>> struct edt_ft5x06_ts_data *tsdata)
> >>> {
> >>> - int error;
> >>> -
> >>> - if (gpio_is_valid(tsdata->wake_pin)) {
> >>> - error = devm_gpio_request_one(&client->dev,
> >>> - tsdata->wake_pin,
> >>> GPIOF_OUT_INIT_LOW,
> >>> - "edt-ft5x06 wake");
> >>> - if (error) {
> >>> - dev_err(&client->dev,
> >>> - "Failed to request GPIO %d as wake pin,
> >>> error %d\n",
> >>> - tsdata->wake_pin, error);
> >>> - return error;
> >>> - }
> >>> -
> >>> + if (tsdata->wake_pin) {
> >>> msleep(5);
> >>> - gpio_set_value(tsdata->wake_pin, 1);
> >>> + gpiod_set_value_cansleep(tsdata->wake_pin, 1);
> >>> }
> >>> - if (gpio_is_valid(tsdata->reset_pin)) {
> >>> - /* this pulls reset down, enabling the low active reset
> >>> */
> >>> - error = devm_gpio_request_one(&client->dev,
> >>> - tsdata->reset_pin,
> >>> GPIOF_OUT_INIT_LOW,
> >>> - "edt-ft5x06 reset");
> >>> - if (error) {
> >>> - dev_err(&client->dev,
> >>> - "Failed to request GPIO %d as reset
> >>> pin, error %d\n",
> >>> - tsdata->reset_pin, error);
> >>> - return error;
> >>> - }
> >>>
> >>> + if (tsdata->reset_pin) {
> >>> msleep(5);
> >>> - gpio_set_value(tsdata->reset_pin, 1);
> >>> + gpiod_set_value_cansleep(tsdata->reset_pin, 1);
> >> So this leaves the reset pin active. How exactly was this tested?
> > Normall
Re: [PATCH] ARM: probes: Don't stop the machine if we're in the debugger
On 08/24/2015 04:58 PM, Douglas Anderson wrote: If we're in kgdb then the machine is already stopped. Trying to stop it again will cause us to try to sleep, which is not allowed while in kgdb. To avoid this problem, only stop the machine when we're not in kgdb. Reported-by: Aapo Vienamo Suggested-by: Kees Cook Signed-off-by: Douglas Anderson --- Can you add the backtrace? arch/arm/kernel/patch.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c index 69bda1a..abf30ec 100644 --- a/arch/arm/kernel/patch.c +++ b/arch/arm/kernel/patch.c @@ -1,5 +1,6 @@ #include #include +#include #include #include #include @@ -124,6 +125,9 @@ void __kprobes patch_text(void *addr, unsigned int insn) .insn = insn, }; - stop_machine(patch_text_stop_machine, &patch, NULL); + /* Stop machine before patching; but not if in the debugger */ + if (unlikely(in_dbg_master())) + patch_text_stop_machine(&patch); + else + stop_machine(patch_text_stop_machine, &patch, NULL); } Perhaps it would be better to add a different function for the kgdb call site? Then it's explicit what's going on without us having to figure out when in_dbg_master() is true. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: qcom: add mdio bus on IPQ806x/AP148
On 08/19, Mathieu Olivari wrote:
> diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> index 6886d09..d73df24 100644
> --- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> +++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> @@ -19,8 +19,9 @@
> };
> };
>
> - alias {
> + aliases {
Good catch!
> serial0 = &uart4;
> + mdio-gpio0 = &mdio0;
> };
>
> chosen {
> @@ -93,5 +103,24 @@
> sata@2900 {
> status = "ok";
> };
> +
> + mdio0: mdio {
This node should be at the root level, not inside the soc node.
> + compatible = "virtual,mdio-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + gpios = <&qcom_pinmux 1 0 &qcom_pinmux 0 0>;
> + pinctrl-0 = <&mdio0_pins>;
> + pinctrl-names = "default";
> +
> + phy0: ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> +
> + phy4: ethernet-phy@4 {
> + device_type = "ethernet-phy";
> + reg = <4>;
> + };
> + };
> };
> };
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts
On 08/18, Mathieu Olivari wrote: > Add one new node to the ipq806x.dtsi file to declare & register the > hardware spinlock devices. This mechanism is required to be used by > other drivers such as SMEM. > > Signed-off-by: Mathieu Olivari > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ARM: qcom: add SMEM device node to IPQ806x dts
On 08/18, Mathieu Olivari wrote: > SMEM is used on IPQ806x to store various board related information such > as boot device and flash partition layout. We'll declare it as a device > so we can make use of it thanks to the new SMEM soc driver. > > Signed-off-by: Mathieu Olivari > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] clk: bcm2835: Add binding docs for the Raspberry Pi clock provider
Eric Anholt writes: > The hardware clocks are not controllable by the ARM, so we have to > make requests to the firmware to do so from the VPU side. This will > let us replace fixed clocks in our DT with actual clock control (and > correct frequency information). Gordon from the Raspberry Pi Foundation just asked me "what do you mean, you can't access the clocks from the ARM?" I'd been assured I couldn't by another developer (who was originally going to write a Linux driver for this), and my own testing had also indicated I couldn't, but after a new round of hacking together some tests, I see things that look a lot like clockman registers. Looks like we're going to get a native driver, instead. signature.asc Description: PGP signature
[PATCHv5 net-next 00/10] OVS conntrack support
The goal of this series is to allow OVS to send packets through the Linux kernel connection tracker, and subsequently match on fields populated by conntrack. This version addresses the feedback from v4, mostly minor fixes, including shifting the conntrack init into the per-namespace functions rather than per-datapath and ensuring the ct_mark/ct_label attributes are re-serialized when userspace dumps the actions. Users attempting to specify actions that set ct_labels with a length longer than the supported length will now get flow rejections. This series also rebases against the latest conntrack zone changes. This functionality is enabled through the CONFIG_OPENVSWITCH_CONNTRACK option. The branch below has been updated with the corresponding userspace pieces: https://github.com/joestringer/ovs dev/ct_20150818 Joe Stringer (10): openvswitch: Serialize acts with original netlink len openvswitch: Move MASKED* macros to datapath.h ipv6: Export nf_ct_frag6_gather() dst: Add __skb_dst_copy() variation openvswitch: Add conntrack action openvswitch: Allow matching on conntrack mark netfilter: Always export nf_connlabels_replace() netfilter: connlabels: Export setting connlabel length openvswitch: Allow matching on conntrack label openvswitch: Allow attaching helpers to ct action include/net/dst.h | 9 +- include/net/netfilter/nf_conntrack_labels.h | 4 + include/uapi/linux/openvswitch.h| 58 +++ net/ipv6/netfilter/nf_conntrack_reasm.c | 1 + net/netfilter/nf_conntrack_labels.c | 34 +- net/netfilter/xt_connlabel.c| 16 +- net/openvswitch/Kconfig | 11 + net/openvswitch/Makefile| 2 + net/openvswitch/actions.c | 229 +++-- net/openvswitch/conntrack.c | 723 net/openvswitch/conntrack.h | 78 +++ net/openvswitch/datapath.c | 86 +++- net/openvswitch/datapath.h | 13 + net/openvswitch/flow.c | 6 +- net/openvswitch/flow.h | 11 +- net/openvswitch/flow_netlink.c | 129 - net/openvswitch/flow_netlink.h | 13 +- net/openvswitch/vport.c | 1 + 18 files changed, 1317 insertions(+), 107 deletions(-) create mode 100644 net/openvswitch/conntrack.c create mode 100644 net/openvswitch/conntrack.h -- 2.1.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/
[PATCHv5 net-next 03/10] ipv6: Export nf_ct_frag6_gather()
Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
Acked-by: Pravin B Shelar
---
v4: Add ack.
v5: No change.
---
net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c
b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 6d02498..701cd2b 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -633,6 +633,7 @@ ret_orig:
kfree_skb(clone);
return skb;
}
+EXPORT_SYMBOL_GPL(nf_ct_frag6_gather);
void nf_ct_frag6_consume_orig(struct sk_buff *skb)
{
--
2.1.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/
[PATCHv5 net-next 08/10] netfilter: connlabels: Export setting connlabel length
Add functions to change connlabel length into nf_conntrack_labels.c so
they may be reused by other modules like OVS and nftables without
needing to jump through xt_match_check() hoops.
Suggested-by: Florian Westphal
Signed-off-by: Joe Stringer
Acked-by: Florian Westphal
Acked-by: Thomas Graf
---
v2: Protect connlabel modification with spinlock.
Fix reference leak in error case.
Style fixups.
v3: No change.
v4-v5: Add acks.
---
include/net/netfilter/nf_conntrack_labels.h | 4
net/netfilter/nf_conntrack_labels.c | 32 +
net/netfilter/xt_connlabel.c| 16 ---
3 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_labels.h
b/include/net/netfilter/nf_conntrack_labels.h
index dec6336..7e2b1d0 100644
--- a/include/net/netfilter/nf_conntrack_labels.h
+++ b/include/net/netfilter/nf_conntrack_labels.h
@@ -54,7 +54,11 @@ int nf_connlabels_replace(struct nf_conn *ct,
#ifdef CONFIG_NF_CONNTRACK_LABELS
int nf_conntrack_labels_init(void);
void nf_conntrack_labels_fini(void);
+int nf_connlabels_get(struct net *net, unsigned int n_bits);
+void nf_connlabels_put(struct net *net);
#else
static inline int nf_conntrack_labels_init(void) { return 0; }
static inline void nf_conntrack_labels_fini(void) {}
+static inline int nf_connlabels_get(struct net *net, unsigned int n_bits) {
return 0; }
+static inline void nf_connlabels_put(struct net *net) {}
#endif
diff --git a/net/netfilter/nf_conntrack_labels.c
b/net/netfilter/nf_conntrack_labels.c
index daa7c13..3ce5c31 100644
--- a/net/netfilter/nf_conntrack_labels.c
+++ b/net/netfilter/nf_conntrack_labels.c
@@ -14,6 +14,8 @@
#include
#include
+static spinlock_t nf_connlabels_lock;
+
static unsigned int label_bits(const struct nf_conn_labels *l)
{
unsigned int longs = l->words;
@@ -89,6 +91,35 @@ int nf_connlabels_replace(struct nf_conn *ct,
}
EXPORT_SYMBOL_GPL(nf_connlabels_replace);
+int nf_connlabels_get(struct net *net, unsigned int n_bits)
+{
+ size_t words;
+
+ if (n_bits > (NF_CT_LABELS_MAX_SIZE * BITS_PER_BYTE))
+ return -ERANGE;
+
+ words = BITS_TO_LONGS(n_bits);
+
+ spin_lock(&nf_connlabels_lock);
+ net->ct.labels_used++;
+ if (words > net->ct.label_words)
+ net->ct.label_words = words;
+ spin_unlock(&nf_connlabels_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nf_connlabels_get);
+
+void nf_connlabels_put(struct net *net)
+{
+ spin_lock(&nf_connlabels_lock);
+ net->ct.labels_used--;
+ if (net->ct.labels_used == 0)
+ net->ct.label_words = 0;
+ spin_unlock(&nf_connlabels_lock);
+}
+EXPORT_SYMBOL_GPL(nf_connlabels_put);
+
static struct nf_ct_ext_type labels_extend __read_mostly = {
.len= sizeof(struct nf_conn_labels),
.align = __alignof__(struct nf_conn_labels),
@@ -97,6 +128,7 @@ static struct nf_ct_ext_type labels_extend __read_mostly = {
int nf_conntrack_labels_init(void)
{
+ spin_lock_init(&nf_connlabels_lock);
return nf_ct_extend_register(&labels_extend);
}
diff --git a/net/netfilter/xt_connlabel.c b/net/netfilter/xt_connlabel.c
index 9f8719d..bb9cbeb 100644
--- a/net/netfilter/xt_connlabel.c
+++ b/net/netfilter/xt_connlabel.c
@@ -42,10 +42,6 @@ static int connlabel_mt_check(const struct xt_mtchk_param
*par)
XT_CONNLABEL_OP_SET;
struct xt_connlabel_mtinfo *info = par->matchinfo;
int ret;
- size_t words;
-
- if (info->bit > XT_CONNLABEL_MAXBIT)
- return -ERANGE;
if (info->options & ~options) {
pr_err("Unknown options in mask %x\n", info->options);
@@ -59,19 +55,15 @@ static int connlabel_mt_check(const struct xt_mtchk_param
*par)
return ret;
}
- par->net->ct.labels_used++;
- words = BITS_TO_LONGS(info->bit+1);
- if (words > par->net->ct.label_words)
- par->net->ct.label_words = words;
-
+ ret = nf_connlabels_get(par->net, info->bit + 1);
+ if (ret < 0)
+ nf_ct_l3proto_module_put(par->family);
return ret;
}
static void connlabel_mt_destroy(const struct xt_mtdtor_param *par)
{
- par->net->ct.labels_used--;
- if (par->net->ct.labels_used == 0)
- par->net->ct.label_words = 0;
+ nf_connlabels_put(par->net);
nf_ct_l3proto_module_put(par->family);
}
--
2.1.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/
[PATCHv5 net-next 07/10] netfilter: Always export nf_connlabels_replace()
The following patches will reuse this code from OVS.
Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
Acked-by: Thomas Graf
---
v2-v4: No change.
v5: Add acks.
---
net/netfilter/nf_conntrack_labels.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_labels.c
b/net/netfilter/nf_conntrack_labels.c
index bb53f12..daa7c13 100644
--- a/net/netfilter/nf_conntrack_labels.c
+++ b/net/netfilter/nf_conntrack_labels.c
@@ -48,7 +48,6 @@ int nf_connlabel_set(struct nf_conn *ct, u16 bit)
}
EXPORT_SYMBOL_GPL(nf_connlabel_set);
-#if IS_ENABLED(CONFIG_NF_CT_NETLINK)
static void replace_u32(u32 *address, u32 mask, u32 new)
{
u32 old, tmp;
@@ -89,7 +88,6 @@ int nf_connlabels_replace(struct nf_conn *ct,
return 0;
}
EXPORT_SYMBOL_GPL(nf_connlabels_replace);
-#endif
static struct nf_ct_ext_type labels_extend __read_mostly = {
.len= sizeof(struct nf_conn_labels),
--
2.1.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/
[PATCHv5 net-next 06/10] openvswitch: Allow matching on conntrack mark
Allow matching and setting the ct_mark field. As with ct_state and
ct_zone, these fields are populated when the CT action is executed. To
write to this field, a value and mask can be specified as a nested
attribute under the CT action. This data is stored with the conntrack
entry, and is executed after the lookup occurs for the CT action. The
conntrack entry itself must be committed using the COMMIT flag in the CT
action flags for this change to persist.
Signed-off-by: Justin Pettit
Signed-off-by: Joe Stringer
---
v1-v3: No change.
v4: Only allow setting conntrack mark via ct action.
Documentation tweaks.
v5: Rebase against conntrack zone changes.
Add ct_mark to ct action serialization
Replace some #ifdefs with IS_ENABLED.
---
include/uapi/linux/openvswitch.h | 5
net/openvswitch/actions.c| 1 +
net/openvswitch/conntrack.c | 63 ++--
net/openvswitch/conntrack.h | 1 +
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 15 +-
6 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 55f5997..7a185b5 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -325,6 +325,7 @@ enum ovs_key_attr {
* the accepted length of the array. */
OVS_KEY_ATTR_CT_STATE, /* u8 bitmask of OVS_CS_F_* */
OVS_KEY_ATTR_CT_ZONE, /* u16 connection tracking zone. */
+ OVS_KEY_ATTR_CT_MARK, /* u32 connection tracking mark */
#ifdef __KERNEL__
OVS_KEY_ATTR_TUNNEL_INFO, /* struct ip_tunnel_info */
@@ -613,11 +614,15 @@ struct ovs_action_hash {
* enum ovs_ct_attr - Attributes for %OVS_ACTION_ATTR_CT action.
* @OVS_CT_ATTR_FLAGS: u32 connection tracking flags.
* @OVS_CT_ATTR_ZONE: u16 connection tracking zone.
+ * @OVS_CT_ATTR_MARK: u32 value followed by u32 mask. For each bit set in the
+ * mask, the corresponding bit in the value is copied to the connection
+ * tracking mark field in the connection.
*/
enum ovs_ct_attr {
OVS_CT_ATTR_UNSPEC,
OVS_CT_ATTR_FLAGS, /* u8 bitmask of OVS_CT_F_*. */
OVS_CT_ATTR_ZONE, /* u16 zone id. */
+ OVS_CT_ATTR_MARK, /* mark to associate with this connection. */
__OVS_CT_ATTR_MAX
};
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 72ca2c4..9741d2c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -968,6 +968,7 @@ static int execute_masked_set_action(struct sk_buff *skb,
case OVS_KEY_ATTR_CT_STATE:
case OVS_KEY_ATTR_CT_ZONE:
+ case OVS_KEY_ATTR_CT_MARK:
err = -EINVAL;
break;
}
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 4b7c4d7..daea29e 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -28,12 +28,19 @@ struct ovs_ct_len_tbl {
size_t minlen;
};
+/* Metadata mark for masked write to conntrack mark */
+struct md_mark {
+ u32 value;
+ u32 mask;
+};
+
/* Conntrack action context for execution. */
struct ovs_conntrack_info {
struct nf_conntrack_zone zone;
struct nf_conn *ct;
u32 flags;
u16 family;
+ struct md_mark mark;
};
static u16 key_to_nfproto(const struct sw_flow_key *key)
@@ -84,10 +91,12 @@ static u8 ovs_ct_get_state(enum ip_conntrack_info ctinfo)
}
static void __ovs_ct_update_key(struct sw_flow_key *key, u8 state,
- const struct nf_conntrack_zone *zone)
+ const struct nf_conntrack_zone *zone,
+ const struct nf_conn *ct)
{
key->ct.state = state;
key->ct.zone = zone->id;
+ key->ct.mark = ct ? ct->mark : 0;
}
/* Update 'key' based on skb->nfct. If 'post_ct' is true, then OVS has
@@ -110,7 +119,7 @@ static void ovs_ct_update_key(const struct sk_buff *skb,
} else if (post_ct) {
state = OVS_CS_F_TRACKED | OVS_CS_F_INVALID;
}
- __ovs_ct_update_key(key, state, zone);
+ __ovs_ct_update_key(key, state, zone, ct);
}
void ovs_ct_fill_key(const struct sk_buff *skb, struct sw_flow_key *key)
@@ -118,6 +127,31 @@ void ovs_ct_fill_key(const struct sk_buff *skb, struct
sw_flow_key *key)
ovs_ct_update_key(skb, key, false);
}
+static int ovs_ct_set_mark(struct sk_buff *skb, struct sw_flow_key *key,
+ u32 ct_mark, u32 mask)
+{
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct;
+ u32 new_mark;
+
+ if (!IS_ENABLED(CONFIG_NF_CONNTRACK_MARK))
+ return -ENOTSUPP;
+
+ /* The connection could be invalid, in which case set_mark is no-op. */
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct)
+ return 0;
+
+ new_mark = ct_mark | (ct->mark & ~(mask));
+ if (ct->mark !=
[PATCHv5 net-next 10/10] openvswitch: Allow attaching helpers to ct action
Add support for using conntrack helpers to assist protocol detection.
The new OVS_CT_ATTR_HELPER attribute of the CT action specifies a helper
to be used for this connection. If no helper is specified, then helpers
will be automatically applied as per the sysctl configuration of
net.netfilter.nf_conntrack_helper.
The helper may be specified as part of the conntrack action, eg:
ct(helper=ftp). Initial packets for related connections should be
committed to allow later packets for the flow to be considered
established.
Example ovs-ofctl flows allowing FTP connections from ports 1->2:
in_port=1,tcp,action=ct(helper=ftp,commit),2
in_port=2,tcp,ct_state=-trk,action=ct(recirc)
in_port=2,tcp,ct_state=+trk-new+est,action=1
in_port=2,tcp,ct_state=+trk+rel,action=1
Signed-off-by: Joe Stringer
---
v2-v3: No change.
v4: Change error code for unknown helper ENOENT->EINVAL.
v5: Fix rcu access of helpers.
Rebase.
---
include/uapi/linux/openvswitch.h | 3 ++
net/openvswitch/conntrack.c | 109 ++-
2 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 9d52058..32e07d8 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -626,6 +626,7 @@ struct ovs_action_hash {
* @OVS_CT_ATTR_LABEL: %OVS_CT_LABEL_LEN value followed by %OVS_CT_LABEL_LEN
* mask. For each bit set in the mask, the corresponding bit in the value is
* copied to the connection tracking label field in the connection.
+ * @OVS_CT_ATTR_HELPER: variable length string defining conntrack ALG.
*/
enum ovs_ct_attr {
OVS_CT_ATTR_UNSPEC,
@@ -633,6 +634,8 @@ enum ovs_ct_attr {
OVS_CT_ATTR_ZONE, /* u16 zone id. */
OVS_CT_ATTR_MARK, /* mark to associate with this connection. */
OVS_CT_ATTR_LABEL, /* label to associate with this connection. */
+ OVS_CT_ATTR_HELPER, /* netlink helper to assist detection of
+ related connections. */
__OVS_CT_ATTR_MAX
};
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 8cb0987..ac6d1d2 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,6 +44,7 @@ struct md_label {
/* Conntrack action context for execution. */
struct ovs_conntrack_info {
+ struct nf_conntrack_helper *helper;
struct nf_conntrack_zone zone;
struct nf_conn *ct;
u32 flags;
@@ -213,6 +215,51 @@ static int ovs_ct_set_label(struct sk_buff *skb, struct
sw_flow_key *key,
return 0;
}
+/* 'skb' should already be pulled to nh_ofs. */
+static int ovs_ct_helper(struct sk_buff *skb, u16 proto)
+{
+ const struct nf_conntrack_helper *helper;
+ const struct nf_conn_help *help;
+ enum ip_conntrack_info ctinfo;
+ unsigned int protoff;
+ struct nf_conn *ct;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct || ctinfo == IP_CT_RELATED_REPLY)
+ return NF_ACCEPT;
+
+ help = nfct_help(ct);
+ if (!help)
+ return NF_ACCEPT;
+
+ helper = rcu_dereference(help->helper);
+ if (!helper)
+ return NF_ACCEPT;
+
+ switch (proto) {
+ case NFPROTO_IPV4:
+ protoff = ip_hdrlen(skb);
+ break;
+ case NFPROTO_IPV6: {
+ u8 nexthdr = ipv6_hdr(skb)->nexthdr;
+ __be16 frag_off;
+
+ protoff = ipv6_skip_exthdr(skb, sizeof(struct ipv6hdr),
+ &nexthdr, &frag_off);
+ if (protoff < 0 || (frag_off & htons(~0x7)) != 0) {
+ pr_debug("proto header not found\n");
+ return NF_ACCEPT;
+ }
+ break;
+ }
+ default:
+ WARN_ONCE(1, "helper invoked on non-IP family!");
+ return NF_DROP;
+ }
+
+ return helper->help(skb, protoff, ct, ctinfo);
+}
+
static int handle_fragments(struct net *net, struct sw_flow_key *key,
u16 zone, struct sk_buff *skb)
{
@@ -285,6 +332,13 @@ static bool skb_nfct_cached(const struct net *net, const
struct sk_buff *skb,
return false;
if (!nf_ct_zone_equal_any(info->ct, nf_ct_zone(ct)))
return false;
+ if (info->helper) {
+ struct nf_conn_help *help;
+
+ help = nf_ct_ext_find(ct, NF_CT_EXT_HELPER);
+ if (help && rcu_access_pointer(help->helper) != info->helper)
+ return false;
+ }
return true;
}
@@ -313,6 +367,11 @@ static int __ovs_ct_lookup(struct net *net, const struct
sw_flow_key *key,
if (nf_conntrack_in(net, info->family, NF_INET_PRE_ROUTING,
skb) != NF_ACCEPT)
[PATCHv5 net-next 02/10] openvswitch: Move MASKED* macros to datapath.h
This will allow the ovs-conntrack code to reuse these macros.
Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
Acked-by: Pravin B Shelar
---
v4: Add ack.
v5: No change.
---
net/openvswitch/actions.c | 52 ++
net/openvswitch/datapath.h | 4
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 4f42007..520438b 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -185,10 +185,6 @@ static int pop_mpls(struct sk_buff *skb, struct
sw_flow_key *key,
return 0;
}
-/* 'KEY' must not have any bits set outside of the 'MASK' */
-#define MASKED(OLD, KEY, MASK) ((KEY) | ((OLD) & ~(MASK)))
-#define SET_MASKED(OLD, KEY, MASK) ((OLD) = MASKED(OLD, KEY, MASK))
-
static int set_mpls(struct sk_buff *skb, struct sw_flow_key *flow_key,
const __be32 *mpls_lse, const __be32 *mask)
{
@@ -201,7 +197,7 @@ static int set_mpls(struct sk_buff *skb, struct sw_flow_key
*flow_key,
return err;
stack = (__be32 *)skb_mpls_header(skb);
- lse = MASKED(*stack, *mpls_lse, *mask);
+ lse = OVS_MASKED(*stack, *mpls_lse, *mask);
if (skb->ip_summed == CHECKSUM_COMPLETE) {
__be32 diff[] = { ~(*stack), lse };
@@ -244,9 +240,9 @@ static void ether_addr_copy_masked(u8 *dst_, const u8
*src_, const u8 *mask_)
const u16 *src = (const u16 *)src_;
const u16 *mask = (const u16 *)mask_;
- SET_MASKED(dst[0], src[0], mask[0]);
- SET_MASKED(dst[1], src[1], mask[1]);
- SET_MASKED(dst[2], src[2], mask[2]);
+ OVS_SET_MASKED(dst[0], src[0], mask[0]);
+ OVS_SET_MASKED(dst[1], src[1], mask[1]);
+ OVS_SET_MASKED(dst[2], src[2], mask[2]);
}
static int set_eth_addr(struct sk_buff *skb, struct sw_flow_key *flow_key,
@@ -338,10 +334,10 @@ static void update_ipv6_checksum(struct sk_buff *skb, u8
l4_proto,
static void mask_ipv6_addr(const __be32 old[4], const __be32 addr[4],
const __be32 mask[4], __be32 masked[4])
{
- masked[0] = MASKED(old[0], addr[0], mask[0]);
- masked[1] = MASKED(old[1], addr[1], mask[1]);
- masked[2] = MASKED(old[2], addr[2], mask[2]);
- masked[3] = MASKED(old[3], addr[3], mask[3]);
+ masked[0] = OVS_MASKED(old[0], addr[0], mask[0]);
+ masked[1] = OVS_MASKED(old[1], addr[1], mask[1]);
+ masked[2] = OVS_MASKED(old[2], addr[2], mask[2]);
+ masked[3] = OVS_MASKED(old[3], addr[3], mask[3]);
}
static void set_ipv6_addr(struct sk_buff *skb, u8 l4_proto,
@@ -358,15 +354,15 @@ static void set_ipv6_addr(struct sk_buff *skb, u8
l4_proto,
static void set_ipv6_fl(struct ipv6hdr *nh, u32 fl, u32 mask)
{
/* Bits 21-24 are always unmasked, so this retains their values. */
- SET_MASKED(nh->flow_lbl[0], (u8)(fl >> 16), (u8)(mask >> 16));
- SET_MASKED(nh->flow_lbl[1], (u8)(fl >> 8), (u8)(mask >> 8));
- SET_MASKED(nh->flow_lbl[2], (u8)fl, (u8)mask);
+ OVS_SET_MASKED(nh->flow_lbl[0], (u8)(fl >> 16), (u8)(mask >> 16));
+ OVS_SET_MASKED(nh->flow_lbl[1], (u8)(fl >> 8), (u8)(mask >> 8));
+ OVS_SET_MASKED(nh->flow_lbl[2], (u8)fl, (u8)mask);
}
static void set_ip_ttl(struct sk_buff *skb, struct iphdr *nh, u8 new_ttl,
u8 mask)
{
- new_ttl = MASKED(nh->ttl, new_ttl, mask);
+ new_ttl = OVS_MASKED(nh->ttl, new_ttl, mask);
csum_replace2(&nh->check, htons(nh->ttl << 8), htons(new_ttl << 8));
nh->ttl = new_ttl;
@@ -392,7 +388,7 @@ static int set_ipv4(struct sk_buff *skb, struct sw_flow_key
*flow_key,
* makes sense to check if the value actually changed.
*/
if (mask->ipv4_src) {
- new_addr = MASKED(nh->saddr, key->ipv4_src, mask->ipv4_src);
+ new_addr = OVS_MASKED(nh->saddr, key->ipv4_src, mask->ipv4_src);
if (unlikely(new_addr != nh->saddr)) {
set_ip_addr(skb, nh, &nh->saddr, new_addr);
@@ -400,7 +396,7 @@ static int set_ipv4(struct sk_buff *skb, struct sw_flow_key
*flow_key,
}
}
if (mask->ipv4_dst) {
- new_addr = MASKED(nh->daddr, key->ipv4_dst, mask->ipv4_dst);
+ new_addr = OVS_MASKED(nh->daddr, key->ipv4_dst, mask->ipv4_dst);
if (unlikely(new_addr != nh->daddr)) {
set_ip_addr(skb, nh, &nh->daddr, new_addr);
@@ -488,7 +484,8 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key
*flow_key,
*(__be32 *)nh & htonl(IPV6_FLOWINFO_FLOWLABEL);
}
if (mask->ipv6_hlimit) {
- SET_MASKED(nh->hop_limit, key->ipv6_hlimit, mask->ipv6_hlimit);
+ OVS_SET_MASKED(nh->hop_limit, key->ipv6_hlimit,
+ mask->ipv6_hlimit);
flow_key->ip.ttl = nh->hop_limit;
}
return 0;
@@ -517,8 +514,8 @@ static int
[PATCHv5 net-next 05/10] openvswitch: Add conntrack action
Expose the kernel connection tracker via OVS. Userspace components can
make use of the CT action to populate the connection state (ct_state)
field for a flow. This state can be subsequently matched.
Exposed connection states are OVS_CS_F_*:
- NEW (0x01) - Beginning of a new connection.
- ESTABLISHED (0x02) - Part of an existing connection.
- RELATED (0x04) - Related to an established connection.
- INVALID (0x20) - Could not track the connection for this packet.
- REPLY_DIR (0x40) - This packet is in the reply direction for the flow.
- TRACKED (0x80) - This packet has been sent through conntrack.
When the CT action is executed by itself, it will send the packet
through the connection tracker and populate the ct_state field with one
or more of the connection state flags above. The CT action will always
set the TRACKED bit.
When the COMMIT flag is passed to the conntrack action, this specifies
that information about the connection should be stored. This allows
subsequent packets for the same (or related) connections to be
correlated with this connection. Sending subsequent packets for the
connection through conntrack allows the connection tracker to consider
the packets as ESTABLISHED, RELATED, and/or REPLY_DIR.
The CT action may optionally take a zone to track the flow within. This
allows connections with the same 5-tuple to be kept logically separate
from connections in other zones. If the zone is specified, then the
"ct_zone" match field will be subsequently populated with the zone id.
IP fragments are handled by transparently assembling them as part of the
CT action. The maximum received unit (MRU) size is tracked so that
refragmentation can occur during output.
IP frag handling contributed by Andy Zhou.
Signed-off-by: Joe Stringer
Signed-off-by: Justin Pettit
Signed-off-by: Andy Zhou
---
This can be tested with the corresponding userspace component here:
https://www.github.com/justinpettit/openvswitch conntrack
v2: Don't take references to devs or dsts in output path.
Shift ovs_ct_init()/ovs_ct_exit() into this patch
Handle output case where flow key is invalidated
Store the entire L2 header to apply to fragments
Various minor simplifications
Improve comments/logs
Style fixes
Rebase
v3: Clone dst in output, free final dst reference properly.
Handle CHECKSUM_COMPLETE after fragmentation
Restore L2 skb metadata after fragmentation
Make MRU types more consistent
Better cleanup in error paths
Fix sparse warnings
v4: Reject set_field actions for ct_state,ct_zone
Combine key->ct update from skb->nfct into a single function.
Minor documentation tweaks.
Simplify some codepaths.
v5: Fix ovs_ct_verify().
Don't take references on nf_conntrack_ipv[46]
Replace some #ifdefs with IS_ENABLED.
Remove unused functions.
Rebase.
---
include/uapi/linux/openvswitch.h | 40
net/openvswitch/Kconfig | 11 +
net/openvswitch/Makefile | 2 +
net/openvswitch/actions.c| 175 +++-
net/openvswitch/conntrack.c | 442 +++
net/openvswitch/conntrack.h | 70 +++
net/openvswitch/datapath.c | 66 --
net/openvswitch/datapath.h | 6 +
net/openvswitch/flow.c | 2 +
net/openvswitch/flow.h | 6 +
net/openvswitch/flow_netlink.c | 72 +--
net/openvswitch/flow_netlink.h | 4 +-
net/openvswitch/vport.c | 1 +
13 files changed, 860 insertions(+), 37 deletions(-)
create mode 100644 net/openvswitch/conntrack.c
create mode 100644 net/openvswitch/conntrack.h
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index d6b8854..55f5997 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -164,6 +164,9 @@ enum ovs_packet_cmd {
* %OVS_USERSPACE_ATTR_EGRESS_TUN_PORT attribute, which is sent only if the
* output port is actually a tunnel port. Contains the output tunnel key
* extracted from the packet as nested %OVS_TUNNEL_KEY_ATTR_* attributes.
+ * @OVS_PACKET_ATTR_MRU: Present for an %OVS_PACKET_CMD_ACTION and
+ * %OVS_PACKET_ATTR_USERSPACE action specify the Maximum received fragment
+ * size.
*
* These attributes follow the &struct ovs_header within the Generic Netlink
* payload for %OVS_PACKET_* commands.
@@ -180,6 +183,7 @@ enum ovs_packet_attr {
OVS_PACKET_ATTR_UNUSED2,
OVS_PACKET_ATTR_PROBE, /* Packet operation is a feature probe,
error logging should be suppressed. */
+ OVS_PACKET_ATTR_MRU,/* Maximum received IP fragment size. */
__OVS_PACKET_ATTR_MAX
};
@@ -319,6 +323,8 @@ enum ovs_key_attr {
OVS_KEY_ATTR_MPLS, /* array of struct ovs_key_mpls.
* The implementation may restrict
* the accepted length of the array. */
+ OVS_KEY_ATTR_CT_STATE, /* u8 bitmask of OVS_CS_
Re: [PATCH v4 3/3] mtd: add SMEM parser for QCOM platforms
On 08/18, Mathieu Olivari wrote: > On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is > used to store partition layout. This new parser can now be used to read > SMEM and use it to register an MTD layout according to its content. > > Signed-off-by: Mathieu Olivari > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 net-next 09/10] openvswitch: Allow matching on conntrack label
Allow matching and setting the ct_label field. As with ct_mark, this is
populated by executing the CT action. The label field may be modified by
specifying a label and mask nested under the CT action. It is stored as
metadata attached to the connection. Label modification occurs after
lookup, and will only persist when the conntrack entry is committed by
providing the COMMIT flag to the CT action. Labels are currently fixed
to 128 bits in size.
Signed-off-by: Joe Stringer
---
v2: Split out setting the connlabel size for the current namespace.
v3: No change.
v4: Only allow setting label via ct action.
Update documentation.
v5: Fix ovs_ct_verify().
Add label to ct action serialization.
Free label bit length/reference properly.
Configure OVS label length per-netns, not per-dp.
Reject ct actions with label length longer than supported.
Replace some #ifdefs with IS_ENABLED.
Rebase.
---
include/uapi/linux/openvswitch.h | 10
net/openvswitch/actions.c| 1 +
net/openvswitch/conntrack.c | 123 ++-
net/openvswitch/conntrack.h | 11 +++-
net/openvswitch/datapath.c | 18 +++---
net/openvswitch/datapath.h | 3 +
net/openvswitch/flow.c | 4 +-
net/openvswitch/flow.h | 3 +-
net/openvswitch/flow_netlink.c | 50 +++-
net/openvswitch/flow_netlink.h | 9 +--
10 files changed, 198 insertions(+), 34 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 7a185b5..9d52058 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -326,6 +326,7 @@ enum ovs_key_attr {
OVS_KEY_ATTR_CT_STATE, /* u8 bitmask of OVS_CS_F_* */
OVS_KEY_ATTR_CT_ZONE, /* u16 connection tracking zone. */
OVS_KEY_ATTR_CT_MARK, /* u32 connection tracking mark */
+ OVS_KEY_ATTR_CT_LABEL, /* 16-octet connection tracking label */
#ifdef __KERNEL__
OVS_KEY_ATTR_TUNNEL_INFO, /* struct ip_tunnel_info */
@@ -438,6 +439,11 @@ struct ovs_key_nd {
__u8nd_tll[ETH_ALEN];
};
+#define OVS_CT_LABEL_LEN 16
+struct ovs_key_ct_label {
+ __u8ct_label[OVS_CT_LABEL_LEN];
+};
+
/* OVS_KEY_ATTR_CT_STATE flags */
#define OVS_CS_F_NEW 0x01 /* Beginning of a new connection. */
#define OVS_CS_F_ESTABLISHED 0x02 /* Part of an existing connection. */
@@ -617,12 +623,16 @@ struct ovs_action_hash {
* @OVS_CT_ATTR_MARK: u32 value followed by u32 mask. For each bit set in the
* mask, the corresponding bit in the value is copied to the connection
* tracking mark field in the connection.
+ * @OVS_CT_ATTR_LABEL: %OVS_CT_LABEL_LEN value followed by %OVS_CT_LABEL_LEN
+ * mask. For each bit set in the mask, the corresponding bit in the value is
+ * copied to the connection tracking label field in the connection.
*/
enum ovs_ct_attr {
OVS_CT_ATTR_UNSPEC,
OVS_CT_ATTR_FLAGS, /* u8 bitmask of OVS_CT_F_*. */
OVS_CT_ATTR_ZONE, /* u16 zone id. */
OVS_CT_ATTR_MARK, /* mark to associate with this connection. */
+ OVS_CT_ATTR_LABEL, /* label to associate with this connection. */
__OVS_CT_ATTR_MAX
};
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 9741d2c..736a113 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -969,6 +969,7 @@ static int execute_masked_set_action(struct sk_buff *skb,
case OVS_KEY_ATTR_CT_STATE:
case OVS_KEY_ATTR_CT_ZONE:
case OVS_KEY_ATTR_CT_MARK:
+ case OVS_KEY_ATTR_CT_LABEL:
err = -EINVAL;
break;
}
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index daea29e..8cb0987 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,12 @@ struct md_mark {
u32 mask;
};
+/* Metadata label for masked write to conntrack label. */
+struct md_label {
+ struct ovs_key_ct_label value;
+ struct ovs_key_ct_label mask;
+};
+
/* Conntrack action context for execution. */
struct ovs_conntrack_info {
struct nf_conntrack_zone zone;
@@ -41,6 +48,7 @@ struct ovs_conntrack_info {
u32 flags;
u16 family;
struct md_mark mark;
+ struct md_label label;
};
static u16 key_to_nfproto(const struct sw_flow_key *key)
@@ -90,6 +98,24 @@ static u8 ovs_ct_get_state(enum ip_conntrack_info ctinfo)
return ct_state;
}
+static void ovs_ct_get_label(const struct nf_conn *ct,
+struct ovs_key_ct_label *label)
+{
+ struct nf_conn_labels *cl = ct ? nf_ct_labels_find(ct) : NULL;
+
+ if (cl) {
+ size_t len = cl->words * sizeof(long);
+
+ if (len > OVS_CT_LABEL_LEN)
+ len = OVS_CT_LABEL_LEN;
+ else if (le
[PATCH v2] clk: rockchip: reset init state before mmc card initialization
mmc host controller's IO input/output timing is unpredictable if
bootloader execute tuning for HS200 mode. It might make kernel failed
to initialize mmc card in identification mode. The root cause is
tuning phase and degree setting for HS200 mode in bootloader aren't
applicable to that of identification mode in kernel stage. Anyway, we
can't force all bootloaders to reset tuning phase and degree setting
before into kernel. Simply reset it in rockchip_clk_register_mmc.
Signed-off-by: Shawn Lin
---
Changes in v2:
- rename to rockchip_clk_mmc_reset
- simplifying the code
drivers/clk/rockchip/clk-mmc-phase.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/rockchip/clk-mmc-phase.c
b/drivers/clk/rockchip/clk-mmc-phase.c
index e9f8df32..1d3e8fe6 100644
--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -38,6 +38,8 @@ static unsigned long rockchip_mmc_recalc(struct clk_hw *hw,
#define ROCKCHIP_MMC_DEGREE_MASK 0x3
#define ROCKCHIP_MMC_DELAYNUM_OFFSET 2
#define ROCKCHIP_MMC_DELAYNUM_MASK (0xff << ROCKCHIP_MMC_DELAYNUM_OFFSET)
+#define ROCKCHIP_MMC_INIT_STATE_RESET 0x1
+#define ROCKCHIP_MMC_INIT_STATE_SHIFT 1
#define PSECS_PER_SEC 1LL
@@ -119,6 +121,14 @@ static const struct clk_ops rockchip_mmc_clk_ops = {
.set_phase = rockchip_mmc_set_phase,
};
+static void rockchip_clk_mmc_reset(struct rockchip_mmc_clock *mmc_clock)
+{
+ if (mmc_clock->shift == ROCKCHIP_MMC_INIT_STATE_SHIFT)
+ writel(HIWORD_UPDATE(ROCKCHIP_MMC_INIT_STATE_RESET,
+ROCKCHIP_MMC_INIT_STATE_RESET,
+mmc_clock->shift), mmc_clock->reg);
+}
+
struct clk *rockchip_clk_register_mmc(const char *name,
const char *const *parent_names, u8 num_parents,
void __iomem *reg, int shift)
@@ -139,6 +149,12 @@ struct clk *rockchip_clk_register_mmc(const char *name,
mmc_clock->reg = reg;
mmc_clock->shift = shift;
+ /*
+ * Assert init_state to soft reset the CLKGEN
+ * for mmc tuning phase and degree
+ */
+ rockchip_clk_mmc_reset(mmc_clock);
+
if (name)
init.name = name;
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 net-next 04/10] dst: Add __skb_dst_copy() variation
This variation on skb_dst_copy() doesn't require two skbs.
Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
---
v4: Add ack.
v5: No change.
---
include/net/dst.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 0a9a723..6f282e7 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -286,13 +286,18 @@ static inline void skb_dst_drop(struct sk_buff *skb)
}
}
-static inline void skb_dst_copy(struct sk_buff *nskb, const struct sk_buff
*oskb)
+static inline void __skb_dst_copy(struct sk_buff *nskb, unsigned long refdst)
{
- nskb->_skb_refdst = oskb->_skb_refdst;
+ nskb->_skb_refdst = refdst;
if (!(nskb->_skb_refdst & SKB_DST_NOREF))
dst_clone(skb_dst(nskb));
}
+static inline void skb_dst_copy(struct sk_buff *nskb, const struct sk_buff
*oskb)
+{
+ __skb_dst_copy(nskb, oskb->_skb_refdst);
+}
+
/**
* skb_dst_force - makes sure skb dst is refcounted
* @skb: buffer
--
2.1.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/
[PATCHv5 net-next 01/10] openvswitch: Serialize acts with original netlink len
Previously, we used the kernel-internal netlink actions length to
calculate the size of messages to serialize back to userspace.
However,the sw_flow_actions may not be formatted exactly the same as the
actions on the wire, so store the original actions length when
de-serializing and re-use the original length when serializing.
Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
---
v2: No change.
v3: Preserve original length across buffer resize.
v4: Add ack.
v5: No change.
---
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 2 ++
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index ffe984f..d5b5473 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -713,7 +713,7 @@ static size_t ovs_flow_cmd_msg_size(const struct
sw_flow_actions *acts,
/* OVS_FLOW_ATTR_ACTIONS */
if (should_fill_actions(ufid_flags))
- len += nla_total_size(acts->actions_len);
+ len += nla_total_size(acts->orig_len);
return len
+ nla_total_size(sizeof(struct ovs_flow_stats)) /*
OVS_FLOW_ATTR_STATS */
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index b62cdb3..082a87b 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -144,6 +144,7 @@ struct sw_flow_id {
struct sw_flow_actions {
struct rcu_head rcu;
+ size_t orig_len;/* From flow_cmd_new netlink actions size */
u32 actions_len;
struct nlattr actions[];
};
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 4e7a3f7..c182b28 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1619,6 +1619,7 @@ static struct nlattr *reserve_sfa_size(struct
sw_flow_actions **sfa,
memcpy(acts->actions, (*sfa)->actions, (*sfa)->actions_len);
acts->actions_len = (*sfa)->actions_len;
+ acts->orig_len = (*sfa)->orig_len;
kfree(*sfa);
*sfa = acts;
@@ -2223,6 +2224,7 @@ int ovs_nla_copy_actions(const struct nlattr *attr,
if (IS_ERR(*sfa))
return PTR_ERR(*sfa);
+ (*sfa)->orig_len = nla_len(attr);
err = __ovs_nla_copy_actions(attr, key, 0, sfa, key->eth.type,
key->eth.tci, log);
if (err)
--
2.1.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] ipmi: add of_device_id in MODULE_DEVICE_TABLE
Well, I should have compile tested first. On x86_64:
CC [M] drivers/char/ipmi/ipmi_si_intf.o
In file included from ../drivers/char/ipmi/ipmi_si_intf.c:42:0:
../drivers/char/ipmi/ipmi_si_intf.c:2804:25: error: ‘ipmi_match’
undeclared here (not in a function)
MODULE_DEVICE_TABLE(of, ipmi_match);
^
../include/linux/module.h:223:21: note: in definition of macro
‘MODULE_DEVICE_TABLE’
extern const typeof(name) __mod_##type##__##name##_device_table \
^
../include/linux/module.h:223:27: error:
‘__mod_of__ipmi_match_device_table’ aliased to undefined symbol ‘ipmi_match’
extern const typeof(name) __mod_##type##__##name##_device_table \
^
../drivers/char/ipmi/ipmi_si_intf.c:2804:1: note: in expansion of macro
‘MODULE_DEVICE_TABLE’
MODULE_DEVICE_TABLE(of, ipmi_match);
This has to compile on all arches. I'm not sure what is wrong, but I've
removed the patch.
-corey
On 08/24/2015 09:15 AM, Brijesh Singh wrote:
> Fix autoloading ipmi modules when using device tree.
>
> Signed-off-by: Brijesh Singh
> ---
> drivers/char/ipmi/ipmi_si_intf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 8a45e92..cddc7b0 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2785,6 +2785,7 @@ static struct platform_driver ipmi_driver = {
> .probe = ipmi_probe,
> .remove = ipmi_remove,
> };
> +MODULE_DEVICE_TABLE(of, ipmi_match);
>
> #ifdef CONFIG_PARISC
> static int ipmi_parisc_probe(struct parisc_device *dev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: edt-ft5x06 - Switch to newer gpio framework
On 08/24/2015 07:17 PM, Dmitry Torokhov wrote:
> On Mon, Aug 24, 2015 at 05:16:15PM -0500, Franklin S Cooper Jr. wrote:
>>
>> On 08/24/2015 03:56 PM, Dmitry Torokhov wrote:
>>> On Mon, Aug 24, 2015 at 03:23:43PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:16 PM, Franklin S Cooper Jr. wrote:
> On 08/24/2015 03:01 PM, Dmitry Torokhov wrote:
>> On Mon, Aug 24, 2015 at 02:48:36PM -0500, Franklin S Cooper Jr. wrote:
>>> On 08/24/2015 02:41 PM, Dmitry Torokhov wrote:
On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
> The current/old gpio framework used doesn't properly listen to
> ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
> account these flags when setting gpio values.
>
> Also use gpiod_set_value_cansleep since wake and reset pins can be
> provided by bus based io expanders.
>
> Signed-off-by: Franklin S Cooper Jr
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 4 +-
> drivers/input/touchscreen/edt-ft5x06.c | 115
> +++--
> include/linux/input/edt-ft5x06.h | 4 +-
> 3 files changed, 43 insertions(+), 80 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> index 76db967..9330d4d 100644
> ---
> a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> +++
> b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> @@ -50,6 +50,6 @@ Example:
> pinctrl-0 = <&edt_ft5x06_pins>;
> interrupt-parent = <&gpio2>;
> interrupts = <5 0>;
> - reset-gpios = <&gpio2 6 1>;
> - wake-gpios = <&gpio4 9 0>;
> + reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c
> b/drivers/input/touchscreen/edt-ft5x06.c
> index 394b1de..6b128b3 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
> u16 num_x;
> u16 num_y;
>
> - int reset_pin;
> - int irq_pin;
> - int wake_pin;
> + struct gpio_desc *reset_pin;
> + struct gpio_desc *wake_pin;
> + struct gpio_desc *irq_pin;
>
> #if defined(CONFIG_DEBUG_FS)
> struct dentry *debug_dir;
> @@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct
> edt_ft5x06_ts_data *tsdata)
> static int edt_ft5x06_ts_reset(struct i2c_client *client,
> struct edt_ft5x06_ts_data *tsdata)
> {
> - int error;
> -
> - if (gpio_is_valid(tsdata->wake_pin)) {
> - error = devm_gpio_request_one(&client->dev,
> - tsdata->wake_pin,
> GPIOF_OUT_INIT_LOW,
> - "edt-ft5x06 wake");
> - if (error) {
> - dev_err(&client->dev,
> - "Failed to request GPIO %d as wake pin,
> error %d\n",
> - tsdata->wake_pin, error);
> - return error;
> - }
> -
> + if (tsdata->wake_pin) {
> msleep(5);
> - gpio_set_value(tsdata->wake_pin, 1);
> + gpiod_set_value_cansleep(tsdata->wake_pin, 1);
> }
> - if (gpio_is_valid(tsdata->reset_pin)) {
> - /* this pulls reset down, enabling the low active reset
> */
> - error = devm_gpio_request_one(&client->dev,
> - tsdata->reset_pin,
> GPIOF_OUT_INIT_LOW,
> - "edt-ft5x06 reset");
> - if (error) {
> - dev_err(&client->dev,
> - "Failed to request GPIO %d as reset
> pin, error %d\n",
> - tsdata->reset_pin, error);
> - return error;
> - }
>
> + if (tsdata->reset_pin) {
> msleep(5);
> - gpio_set_value(tsdata->reset_pin, 1);
> + gpiod_set_value_cansleep(tsdata->reset_pin, 1);
So this leaves the reset pin active.
linux-next: build failure after merge of the i2c tree
Hi Wolfram,
After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "of_irq_get_byname" [drivers/i2c/i2c-core.ko] undefined!
Caused by commit
efb6a10b761e ("i2c: allow specifying separate wakeup interrupt in device
tree")
I have used the i2c tree from next-20150824 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/7] ARM: EXYNOS: remove unused static mapping of CMU for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused static mapping of exynos5 CMU and related code. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/exynos.c | 5 - > arch/arm/mach-exynos/include/mach/map.h | 1 - > 2 files changed, 6 deletions(-) Looks good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] ARM: EXYNOS: code cleanup in map.h
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused exynos5440 uart offset macro. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/include/mach/map.h | 4 > 1 file changed, 4 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
An application from HuaWei which works fine on 2.6 encounters this
issue on 3.0 or later kernel.
Test code:
#include
#include
#include
#include
#include
#include
#include
#define MAXLEN (100)
int main(int argc, char** argv)
{
int fd = 0;
int len = 0;
char pathname[MAXLEN] = {0};
char buf[2] = {0};
int ret = 0xF;
int value = 0xF;
if (argc < 2)
{
printf("Input param error, less 2 param: %s, %s.\n",
argv[0], argv[1]);
return 1;
}
printf("Input: %s, %s \n", argv[0], argv[1]);
ret = sprintf(pathname,
"/proc/sys/net/ipv4/conf/%s/rp_filter", argv[1]);
if (ret < 0)
printf("sprintf error, errno %d, %s\n", errno, strerror(errno));
printf("file is: %s. \n", pathname);
fd = open(pathname, O_RDWR, S_IRUSR);
if (fd <=0 )
{
printf("open %s failed, errno=%d, %s.\n", pathname,
errno, strerror(errno));
return 1;
}
printf("open %s ok, fd=%d\n", pathname, fd);
len = write(fd, "0\0", 2);
printf("write %d: len=%d, errno=%d, %s\n", fd, len, errno,
strerror(errno));
close(fd);
return 0;
}
On Tue, Aug 25, 2015 at 12:59 AM, Steven Rostedt wrote:
> On Mon, 24 Aug 2015 16:56:13 +0800
> Sean Fu wrote:
>
>> when the input argument "count" including the terminating byte "\0",
>> The write system call return EINVAL on proc file.
>> But it return success on regular file.
>>
>> E.g. Writting two bytes ("1\0") to "/proc/sys/net/ipv4/conf/eth0/rp_filter".
>> write(fd, "1\0", 2) return EINVAL.
>
> And what would do that? What tool broke because of this?
>
> echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
>
> works just fine. strlen("string") would not include the nul character.
> The only thing I could think of would be a sizeof(str), but then that
> would include someone hardcoding an integer in a string, like:
>
> char val[] = "1"
>
> write(fd, val, sizeof(val));
>
> Again, what tool does that?
>
> If there is a tool out in the wild that use to work on 2.6 (and was
> running on 2.6 then, and not something that was created after that
> change), then we can consider this fix.
>
> -- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] memhp: Add hot-added memory ranges to memblock before allocate node_data for a node.
On 2015/8/24 17:22, Xishi Qiu wrote: > On 2015/8/24 1:06, Tang Chen wrote: > >> The commit below adds hot-added memory range to memblock, after >> creating pgdat for new node. >> >> commit f9126ab9241f66562debf69c2c9d8fee32ddcc53 >> Author: Xishi Qiu >> Date: Fri Aug 14 15:35:16 2015 -0700 >> >> memory-hotplug: fix wrong edge when hot add a new node >> >> But there is a problem: >> >> add_memory() >> |--> hotadd_new_pgdat() >> |--> free_area_init_node() >> |--> get_pfn_range_for_nid() >>|--> find start_pfn and end_pfn in memblock >> |--> .. >> |--> memblock_add_node(start, size, nid)Here, just too late. >> >> get_pfn_range_for_nid() will find that start_pfn and end_pfn are both 0. >> As a result, when adding memory, dmesg will give the following wrong message. >> Hi Tang, Another question, if we add cpu first, there will be print error too. cpu_up() try_online_node() hotadd_new_pgdat() So how about just skip the print if the size is empty or just print "node xx is empty now, will update when online memory"? Thanks, Xishi Qiu >> [ 2007.577000] Initmem setup node 5 [mem >> 0x-0x] >> [ 2007.584000] On node 5 totalpages: 0 >> [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on. Total >> pages: 32588823 >> [ 2007.594000] Policy zone: Normal >> [ 2007.598000] init_memory_mapping: [mem 0x600-0x607] >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular
[Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular] On 24/08/2015 (Mon 20:10) Konrad Rzeszutek Wilk wrote: > On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker > wrote: > >The Kconfig currently controlling compilation of this code is: > > > >config CLEANCACHE > >bool "Enable cleancache driver to cache clean pages if tmem is present" > > > >...meaning that it currently is not being built as a module by anyone. > > Why not make it a tristate? Simple. I'm making the code consistent with its current behaviour. I'm not looking to extend functionality in code that I don't know intimately. I can't do that and do it reliably and guarantee it works as a module when it has never been used as such before. I've got about 130 of these and counting. Some of them have been bool since before git history ; before the turn of the century. If there was demand for them to be tristate, then it would have happened by now. So clearly there is no point in looking at making _those_ tristate. I did have one uart driver author indicate that he _meant_ his code to be tristate, and he tested it as such, and asked if I would convert it to tristate on his behalf. And that was fine and I did exactly that. But unless there are interested users who want their code tristate and can vouch that their code works OK as such, I can only make the code consistent with the implicit non-modular behaviour that the Kconfig and Makefiles have dictated up to now. Are there such users for CLEANCACHE? Paul. -- > > > > > >Lets remove the couple traces of modularity so that when reading the > >driver there is no doubt it is builtin-only. > > > >Since module_init translates to device_initcall in the non-modular > >case, the init ordering remains unchanged with this commit. > > > >Cc: Konrad Rzeszutek Wilk > >Cc: linux...@kvack.org > >Signed-off-by: Paul Gortmaker > >--- > > mm/cleancache.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >diff --git a/mm/cleancache.c b/mm/cleancache.c > >index 8fc5089b..ee0646d1c2fa 100644 > >--- a/mm/cleancache.c > >+++ b/mm/cleancache.c > >@@ -11,7 +11,7 @@ > > * This work is licensed under the terms of the GNU GPL, version 2. > > */ > > > >-#include > >+#include > > #include > > #include > > #include > >@@ -316,4 +316,4 @@ static int __init init_cleancache(void) > > #endif > > return 0; > > } > >-module_init(init_cleancache) > >+device_initcall(init_cleancache) > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG/RFC] perf test fails on AMD CPUs
On 08/18/2015 05:10 AM, Jiri Olsa wrote: On Mon, Aug 17, 2015 at 09:06:59AM -0700, Andy Lutomirski wrote: On Sun, Aug 16, 2015 at 9:36 PM, Borislav Petkov wrote: On Mon, Aug 17, 2015 at 12:29:56AM +0200, Jiri Olsa wrote: hi, 'perf test 18' is failing on systems with AMD processor. Hmm, still using that b0rked test box? :-) Also, which kernel? There have been substantial changes to the entry code recently. Although I don't see anything being done differently on AMD there except X86_BUG_SYSRET_SS_ATTRS but that should be unrelated. The only reason I could find is that AMD does not set 'resume flag' in RFLAGS register the way the Intel CPU does. (simplified) test scenario: - create breakpoint (on test_function) perf event with SIGIO signal to be delivered any time the breakpoint is hit - run test_function expected course of actions is: 1) CPU hits 'test_function' 2) DB exception is triggered, with RFLAGS.RF=0 3) DB exception handler sets regs->RFLAGS.RF=1 and perf handler triggers irq_work pending work 4) DB exception executes iretd 5) irq_work interrupt is triggered, with RFLAGS.RF=1 6) irq_work interrupt calls kill_fasync with SIGIO signal 7) irq_work interrupt on return to userspace calls prepare_exit_to_usermode which actually delivers the SIGIO signal 8) sigreturn syscall prepare registers to return to the instruction from step 1) and sets RFLAGS.RF to the its original value from step 5) (RFLAGS.RF=1) 9) CPU hits 'test_function' and DB exception is NOT triggered due to RFLAGS.RF=1 this is how I see it works on Intel But AMD gives me RFLAGS.RF=0 on step 5, which makes the step 9 to trigger the DB exception once again and makes the test fail. Adding Andy, he might have an idea. Leaving in the rest for reference. Gee thanks :-p Jiri, did you instrument the code and observe do_IRQ sees RF clear in its pt_regs? Also, it might be worth checking that regs->ip in the irq_work matches regs->ip. yep, thats what I saw.. once irq_work interrupt was triggered the regs->ip was same as for the previous debug exception but the RFLAGS.RF was 0 It's *possible* that I messed up and broke RF restore with opportunistic sysret, but the code looks correct: testq $(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11 jnz opportunistic_sysret_failed AFAICS the problematic paths did not hit syscalls buut anyway, it looks like latest AMD firmware issue: [root@amd-pike-07 ~]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000822 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : Ok [root@amd-pike-07 perf]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000832 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : FAILED! [root@amd-pike-07 ~]# cat /proc/cpuinfo processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 3380 stepping: 0 microcode : 0x6000832 SNIP AMD description of RF flag (SDM 3.1.6): === Resume Flag (RF) Bit. Bit 16. The RF bit allows an instruction to be restarted following an instruction breakpoint resulting in a debug exception (#DB). This bit prevents multiple debug exceptions from occurring on the same instruction. The processor clears the RF bit after every instruction is successfully executed, except when the instruction is: • • An IRET that sets the RF bit. JMP, CALL, or INTn through a task gate. In both of the above cases, RF is not cleared to 0 until the next instruction successfully executes. When an exception occurs (or when a string instruction is interrupted), the processor normally sets RF=1 in the RFLAGS image saved on the interrupt stack. However, when a #DB exception occurs as a result of an instruction breakpoint, the processor clears the RF bit to 0 in the interrupt-stack RFLAGS image. That's a little weird, I think. Shouldn't RF be zero on #DB due to a *watchpoint* so that a watchpoint followed immediately by a breakpoint works? the AMD description looked to be more vague (compared to Intels) • For other cases, the value pushed for RF is the value that was in EFLAG.RF at the time the event handler was called. This includes: — Debug exceptions generated in response to instruction breakpoints — Hardware-generated interrupts arriving between instructions (including those arriving after the last iteration of a repeated string instruction) This appears to be why it works on Intel. Does AMD not do that? We could probably work around this in software (by not using irq work for this), but yuck. yep, but hopefuly it's the issue microcode ;-) Cc-ing guys from linux-firmware git Sherry, Suravee, any idea? thanks, jirka Jiri, I have duplicated your problem and asked the HW architect that wrote 832 to review the diff between the 822 an
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
在 2015/8/24 22:48, Rob Herring 写道:
On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
wrote:
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
+ -analogix,color-depth:
+ number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.
Please think about this some more. What does "color-depth" mean? Does it
mean the number of bits per colour _component_, or does it mean the total
number of bits to represent a particular colour. It's confusing as it
stands.
Then "component-color-bpp" perhaps?
Actually this "color-bpp" should come from crtc driver, maybe should
come from
"struct drm_crtc {".
Like rockchip stuffs, analogix_dp-rockchip call an mode_config from
rockchip_drm_vop
driver and set output mode to RGB[10:10:10], then vop driver just store
the output mode
type to the private struct "vop->connecot_out_mode". do think that this
outmode should
store into crtc, not just come from DT prop.
- Yakir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v2 03/11] soc/fsl: Introduce the DPAA BMan portal driver
On Wed, Aug 12, 2015 at 04:14:49PM -0400, Roy Pledge wrote:
> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> index 9a500ce..d6e2204 100644
> --- a/drivers/soc/fsl/qbman/bman.c
> +++ b/drivers/soc/fsl/qbman/bman.c
> @@ -165,11 +165,11 @@ static struct bman *bm_create(void *regs)
>
> static inline u32 __bm_in(struct bman *bm, u32 offset)
> {
> - return in_be32((void *)bm + offset);
> + return ioread32be((void *)bm + offset);
> }
> static inline void __bm_out(struct bman *bm, u32 offset, u32 val)
> {
> - out_be32((void *)bm + offset, val);
> + iowrite32be(val, (void*) bm + offset);
> }
Don't introduce a problem in one patch and then fix it in another. What
does this change have to do with introducing the portal driver?
> #define bm_in(reg) __bm_in(bm, REG_##reg)
> #define bm_out(reg, val) __bm_out(bm, REG_##reg, val)
> @@ -341,6 +341,7 @@ u32 bm_pool_free_buffers(u32 bpid)
> {
> return bm_in(POOL_CONTENT(bpid));
> }
> +EXPORT_SYMBOL(bm_pool_free_buffers);
If you're exporting this (or even making it global), where's the
documentation?
> +/* BTW, the drivers (and h/w programming model) already obtain the required
> + * synchronisation for portal accesses via lwsync(), hwsync(), and
> + * data-dependencies. Use of barrier()s or other order-preserving primitives
> + * simply degrade performance. Hence the use of the __raw_*() interfaces,
> which
> + * simply ensure that the compiler treats the portal registers as volatile
> (ie.
> + * non-coherent). */
volatile does not mean "non-coherent".
Be careful with this regarding endian, e.g. on ARM we can run the CPU in
big or little endian on the same chip, and the raw accessors also
unfortunately bypass endian conversion.
> +
> +/* Cache-inhibited register access. */
> +#define __bm_in(bm, o) __raw_readl((bm)->addr_ci + (o))
> +#define __bm_out(bm, o, val) __raw_writel((val), (bm)->addr_ci + (o))
> +#define bm_in(reg) __bm_in(&portal->addr, BM_REG_##reg)
> +#define bm_out(reg, val) __bm_out(&portal->addr, BM_REG_##reg, val)
Don't have multiple implementations of bm_in/out, with the same name,
where bm in both refers to "bman", but which have different functions.
> +/* Cache-enabled (index) register access */
> +#define __bm_cl_touch_ro(bm, o) dcbt_ro((bm)->addr_ce + (o))
> +#define __bm_cl_touch_rw(bm, o) dcbt_rw((bm)->addr_ce + (o))
> +#define __bm_cl_in(bm, o)__raw_readl((bm)->addr_ce + (o))
> +#define __bm_cl_out(bm, o, val) \
> + do { \
> + u32 *__tmpclout = (bm)->addr_ce + (o); \
> + __raw_writel((val), __tmpclout); \
> + dcbf(__tmpclout); \
> + } while (0)
> +#define __bm_cl_invalidate(bm, o) dcbi((bm)->addr_ce + (o))
> +#define bm_cl_touch_ro(reg) __bm_cl_touch_ro(&portal->addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_touch_rw(reg) __bm_cl_touch_rw(&portal->addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_in(reg)__bm_cl_in(&portal->addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_out(reg, val) __bm_cl_out(&portal->addr, BM_CL_##reg##_CENA,
> val)
> +#define bm_cl_invalidate(reg)\
> + __bm_cl_invalidate(&portal->addr, BM_CL_##reg##_CENA)
Define these using functions to operate on pointers, and pass the pointer
in without all the token-pasting. Some extra explanation of the cache
manipulation would also be helpful.
> +/* --- RCR API --- */
> +
> +/* Bit-wise logic to wrap a ring pointer by clearing the "carry bit" */
> +#define RCR_CARRYCLEAR(p) \
> + (void *)((unsigned long)(p) & (~(unsigned long)(BM_RCR_SIZE << 6)))
This could be a function.
Where does 6 come from? You use it again in the next function. Please
define it symbolically.
> +
> +/* Bit-wise logic to convert a ring pointer to a ring index */
> +static inline u8 RCR_PTR2IDX(struct bm_rcr_entry *e)
> +{
> + return ((uintptr_t)e >> 6) & (BM_RCR_SIZE - 1);
> +}
This is a function, so don't use ALLCAPS.
> +/* Increment the 'cursor' ring pointer, taking 'vbit' into account */
> +static inline void RCR_INC(struct bm_rcr *rcr)
> +{
> + /* NB: this is odd-looking, but experiments show that it generates
> + * fast code with essentially no branching overheads. We increment to
> + * the next RCR pointer and handle overflow and 'vbit'. */
> + struct bm_rcr_entry *partial = rcr->cursor + 1;
> +
> + rcr->cursor = RCR_CARRYCLEAR(partial);
> + if (partial != rcr->cursor)
> + rcr->vbit ^= BM_RCR_VERB_VBIT;
> +}
> +
> +static inline int bm_rcr_init(struct bm_portal *portal, enum bm_rcr_pmode
> pmode,
> + __maybe_unused enum bm_rcr_cmode cmode)
> +{
> + /* This use of 'register', as well as all other occurrences, is because
> + * it has been observed to generate much faster code with gcc than is
> + * otherwise the case. */
> + register struct bm_rcr *rcr = &portal->rcr;
What version of GCC? Normal optimization settings?
Has the seemingly excessive use of inlin
Re: [PATCH v2 3/7] drivers: soc: add support for exynos SROM driver
On 24.08.2015 17:02, Pankaj Dubey wrote:
> This patch adds Exynos SROM controller driver which will handle
> save restore of SROM registers during S2R.
>
> Signed-off-by: Pankaj Dubey
Hi,
Thanks for the fixes. I got some more questions. Sorry that I did not
bring up them before.
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/samsung/Kconfig | 13
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-srom.c | 143
> ++
> drivers/soc/samsung/exynos-srom.h | 51 ++
> 6 files changed, 210 insertions(+)
> create mode 100644 drivers/soc/samsung/Kconfig
> create mode 100644 drivers/soc/samsung/Makefile
> create mode 100644 drivers/soc/samsung/exynos-srom.c
> create mode 100644 drivers/soc/samsung/exynos-srom.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 96ddecb..69107c9 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/samsung/Kconfig"
> source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 7dc7c0d..34c4398 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> obj-$(CONFIG_ARCH_QCOM) += qcom/
> +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> new file mode 100644
> index 000..ea4bc2a
> --- /dev/null
> +++ b/drivers/soc/samsung/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# SAMSUNG SoC drivers
> +#
> +menu "Samsung SOC driver support"
> +
> +config SOC_SAMSUNG
> + bool
> +
> +config EXYNOS_SROM
> + bool
> + depends on ARM && ARCH_EXYNOS
> +
> +endmenu
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> new file mode 100644
> index 000..9c554d5
> --- /dev/null
> +++ b/drivers/soc/samsung/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_EXYNOS_SROM)+= exynos-srom.o
> diff --git a/drivers/soc/samsung/exynos-srom.c
> b/drivers/soc/samsung/exynos-srom.c
> new file mode 100644
> index 000..d7c4aa7
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-srom.c
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * EXYNOS - SROM Controller support
> + * Author: Pankaj Dubey
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "exynos-srom.h"
> +
> +static void __iomem *exynos_srom_base;
> +
> +static const unsigned long exynos_srom_offsets[] = {
> + /* SROM side */
> + EXYNOS_SROM_BW,
> + EXYNOS_SROM_BC0,
> + EXYNOS_SROM_BC1,
> + EXYNOS_SROM_BC2,
> + EXYNOS_SROM_BC3,
> +};
> +
> +/**
> + * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
> + * @offset: srom register offset from the controller base address.
> + * @value: the value of register under the offset.
> + */
> +struct exynos_srom_reg_dump {
> + u32 offset;
> + u32 value;
> +};
> +
> +static struct exynos_srom_reg_dump *exynos_srom_regs;
> +
> +static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
> + const unsigned long *rdump,
> + unsigned long nr_rdump)
> +{
> + struct exynos_srom_reg_dump *rd;
> + unsigned int i;
> +
> + rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
> + if (!rd)
> + return NULL;
> +
> + for (i = 0; i < nr_rdump; ++i)
> + rd[i].offset = rdump[i];
> +
> + return rd;
> +}
> +
> +static const struct of_device_id of_exynos_srom_ids[] = {
> + {
> + .compatible = "samsung,exynos-srom",
> + },
> + {},
> +};
> +
> +static int exynos_srom_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct device *dev = &pdev->dev;
> +
> + np = dev->of_node;
> + exynos_srom_base = of_iomap(np, 0);
The existing file-scope "exynos_srom_base" would be overwritten for any
consecutive device bind. There shouldn't be more binds than one (there
is only one SROM on board) but still someone may create such DTB. By
mistake or by booting with some newer DTB (where for example two SROMs
would be allowed) with older kernel.
The question is should we handle such case?
E.g.
if (exynos_srom_base)
return -EINVAL; /* Doubled bind */
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On Tue, Aug 25, 2015 at 09:46:11AM +1000, Dave Chinner wrote: > On Mon, Aug 24, 2015 at 01:19:24PM -0400, Jeff Moyer wrote: > > Brian Norris writes: > > > > > On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote: > > >> Now, some user-space fails when direct I/O is not supported. > > > > > > I think the whole argument rested on what it means when "some user space > > > fails"; apparently that "user space" is just a test suite (which > > > can/should be fixed). > > > > Even if it wasn't a test suite it should still fail. Either the fs > > supports O_DIRECT or it doesn't. Right now, the only way an application > > can figure this out is to try an open and see if it fails. Don't break > > that. > > Who cares how a filesystem implements O_DIRECT as long as it does > not corrupt data? ext3 fell back to buffered IO in many situations, > yet the only complaints about that were performance. IOWs, it's long been > true that if the user cares about O_DIRECT *performance* then they > have to be careful about their choice of filesystem. > > But if it's only 5 lines of code per filesystem to support O_DIRECT > *correctly* via buffered IO, then exactly why should userspace have > to jump through hoops to explicitly handle open(O_DIRECT) failure? > Especially when you consider that all they can do is fall back to > buffered IO themselves This is what btrfs already does for O_DIRECT plus compressed, or other cases where people don't want their applications to break on top of new features that aren't quite compatible with it. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Krzysztof,
在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
On 24.08.2015 21:48, Yakir Yang wrote:
Hi Krzysztof,
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop.
Right, the focus is on the driver.
If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
If you are replacing a binding/property then it should be marked
deprecated. This means that the old property is still working but new
users of it should not be added.
Okay, so just quote Heiko's reply, such code would be need in analogix
dp driver.
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
It looks wrong because it breaks backward compatibility with existing
DTB. As I said before:
1. Provide backward compatibility. Mark old properties
as deprecated but still support them.
And actually @Rob have suggest me to remove the prefix, just use
"color-space" here.
For new bindings I don't mind. But please remember about existing users,
existing DTB and bisectability.
Let me show same examples, make
me understand your suggest rightly.
exynos-dp already contains deprecated properties. Other ways of doing
this would be:
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Documentation/devicetree/bindings/rtc/s3c-rtc.txt
It depends up to you. The "touchscreen" looks good because it organizes
old properties in a common section. In case of exynos-dp.txt you can add
at beginning of file information about new bindings and mark everything
deprecated.
Whoops, thanks for your remind, I prefer the "touchscreen" style.
1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver,
absolutely
I should not carry this to analogix-dp.txt document. But I should
keep this in
exynos-dp.txt document, and mark them with an little
"deprecated" flag.
[Documentation/devicetree/bindings/video/exynos_dp.txt]
Required properties for dp-controller:
[...]
-samsung,ycbcr-coeff (DEPRECATED):
YCbCr co-efficients for input video.
COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
Is it right ?
Yes, this is right.
2. Separate all DTS changes to a separate patch, unless bisectability
would be hurt. Anyway you should prepare it in a such way that
separation would be possible without breaking bisectability.
So I should separate this patch into two parts, one is name "Document:",
the other is "ARM: dts: ".
Yes.
Honestly, I don't understand what the "bisectability" means in this
case.
I was referring to bisectability in general. The patchset should be
fully bisectable which means that it does not introduce any issues
during "git bisect". This effectively means that at each intermediate
step (after applying eac
Re: parse_args() is too unforgivable?
Oleg Nesterov writes:
> On 08/24, Oleg Nesterov wrote:
>>
>> I booted the kernel with the additional patch below, and nothing bad has
>> happened,
>
> Until I tried reboot it once with "locktorture.verbose=true" paramater.
> It didn't boot.
>
> This is because parse_args() just aborts after it hits the error, so other
> arguments at the same initcall level are simply ignored.
>
> Fixed by the patch below, but I simply can't believe nobody hit this (imo)
> bug before.
>
> Why does parse_args() do this?? I simply can't understand why parse_args()
> adds more random and hard-to-understand problems if one of the args ("=true"
> in this particular case) is wrong.
>
> Yes, the patch below is probably oversimplified / incomplete but imho the
> current behaviour is confusing. At least I was greatly confused ;) At least
> (I think) it makes sense to let the user know that the rest of command line
> was probably ignored.
This is nice, but please save and return the error properly; modules need
this too.
I think nobody hit this before because they notice that they screwed up
the commandline and it didn't boot.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On 25.08.2015 10:33, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
>> On 24.08.2015 21:48, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
>> 2015-08-24 8:23 GMT+09:00 Rob Herring :
>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
>>> wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
>>> You can't just change the exynos bindings and break
>>> compatibility. Is
>>> there some agreement with exynos folks to do this?
>> No, there is no agreement. This wasn't even sent to Exynos
>> maintainers.
> Sorry about this one, actually I have add Exynos maintainers in
> version
> 1 & version 2,
> but lose some maintainers in version 3, I would fix it in bellow
> versions.
>
>> Additionally the patchset did not look interesting to me because of
>> misleading subject - Documentation instead of "ARM: dts:".
>>
>> Yakir, please:
>> 1. Provide backward compatibility. Mark old properties as deprecated
>> but still support them.
> Do you mean that I should keep the old properties declare in
> exynos-dp.txt,
> but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way
as it
was supporting before the change?
>>> Okay, I got your means. So document is not the focus, the most important
>>> is that
>>> driver should support the old dts prop.
>> Right, the focus is on the driver.
>>
>>> If so the new analogix dp driver
>>> should keep
>>> the "samsung,color-space", rather then just mark it with [DEPRECATED]
>>> flag.
>> If you are replacing a binding/property then it should be marked
>> deprecated. This means that the old property is still working but new
>> users of it should not be added.
>
> Okay, so just quote Heiko's reply, such code would be need in analogix
> dp driver.
>
>if (of_property_read_u32(dp_node, "analogix,color-space",
> &dp_video_config->color_space))
>if (of_property_read_u32(dp_node, "samsung,color-space",
> &dp_video_config->color_space)) {
>
> dev_err(dev, "failed to get color-space\n");
> return ERR_PTR(-EINVAL);
> }
Yes. It does not look pretty but something like this is needed.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations
Hi Russell, Olof, 2015-08-25 6:44 GMT+09:00 Olof Johansson : > On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux > wrote: >> On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: >>> Easiest of all would probably be to get the sub-arch patches into one >>> release, then switch the prototypes and function definitions in the >>> next. If you switch prototypes first you'll get a bunch of warnings, >>> right? >> >> Wrong way around. :) >> >> If you change the sub-arches to declare the smp operations as const, >> and try and pass them into a function which doesn't take a const-pointer, >> you'll get a warning. The core bits need to go in first before the >> sub-arch patches. > > Ah yes, my bad. > >> I think the series has limited value - it allows us to (a) check that a >> small quantity of code doesn't write to these things, and (b) allows us >> to move the SMP operations structure from __initdata to __initconstdata. >> It's still going to end up in the init region which is read/write in any >> case, and still gets thrown away. >> >> Given where we are, I don't think we need to rush this in during the >> last week before the merge window opens, even though it's trivial. > > Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5. > OK. I will put 01 and 02 to Russell's patch tracker (after waiting for a bit more comments just in case). I will do the rest later. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Heiko,
在 2015/8/24 21:03, Heiko Stuebner 写道:
Hi Yakir,
Am Montag, 24. August 2015, 20:48:01 schrieb Yakir Yang:
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop. If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
In a generic driver, the property should have either none, or the analogix
prefix. But DT-properties need to be backwards compatible, meaning an older
Exynos devicetree should run unmodified with a newer kernel.
So the common course of action is to mark the old one as deprecated but still
test for both, so something like:
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
Wow, thanks a lot for your explain and code, it do help me to understand
this suggest rightly :-)
Thanks,
- Yakir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] f2fs: fix to release inode correctly
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, August 25, 2015 12:54 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] f2fs: fix to release inode correctly
>
[snip]
> > +* if we skip truncate_node in remove_inode_page bacause we failed
> > +* before, it's better to find another way to release resource of
> > +* this inode (e.g. valid block count, node block or nid). Here we
> > +* choose to add this inode to orphan list, so that we can call iput
> > +* for releasing in orphan recovery flow.
> > +*
> > +* Note: we should add inode to orphan list before f2fs_unlock_op()
> > +* so we can prevent losing this orphan when encoutering checkpoint
> > +* and following suddenly power-off.
> > +*/
> > + if (err && err != -ENOENT) {
> > + err = acquire_orphan_inode(sbi);
> > + if (!err)
> > + add_orphan_inode(sbi, inode->i_ino);
>
> Need this too?
>
> if (err)
> set_sbi_flag(sbi, SBI_NEED_FSCK);
We have another chance to release inode resource in following path:
- handle_failed_inode
- iput
- f2fs_evict_inode
- f2fs_truncate
- remove_inode_page
So I choose to set SBI_NEED_FSCK in the end of f2fs_evict_inode.
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 linux-next v4 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller
>+ nor->read_reg = atmel_qspi_read_reg;
>+ nor->write_reg = atmel_qspi_write_reg;
>+ nor->read = atmel_qspi_read;
>+ nor->write = atmel_qspi_write;
>+ nor->erase = atmel_qspi_erase;
>+ nor->set_protocol = atmel_qspi_set_protocol;
This is very good, the structure of spi_nor should add a hook function to
notify spi controller
That spi nor transfer protocol already changed.
>+
>+ if (of_modalias_node(child, modalias, sizeof(modalias)) < 0) {
>+ err = -ENODEV;
>+ goto release_channel;
>+ }
>+
>+ err = of_property_read_u32(child, "spi-max-frequency", &aq->clk_rate);
>+ if (err < 0)
>+ goto release_channel;
>+
>+ err = atmel_qspi_init(aq);
>+ if (err)
>+ goto release_channel;
>+
>+ nor->dev->of_node = child;
>+ err = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
> goto release_channel;
>+
...
>static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd) {
return mtd->priv;
>@@ -944,6 +960,11 @@ static int micron_quad_enable(struct spi_nor *nor)
> return ret;
> }
>
>+ /* switch protocol to Quad CMD 4-4-4 */
>+ ret = spi_nor_set_protocol(nor, SPI_PROTO_4_4_4);
>+ if (ret)
>+ return ret;
>+
This make sense,from spi nor side,once its protocol being changed,
Mtd layer must notify this status to spi nor controller immediately,
And spi nor controller also should re-adjust its protocol.
Otherwise, following reading SR operation will fail.
>
> ret = spi_nor_wait_till_ready(nor);
> if (ret)
> return ret;
If my ack has any value in here, feel free to add it.
Acked-by: Bean Huo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] zsmalloc: use page->private instead of page->first_page
Add Minchan to the thread. -ss On (08/17/15 18:09), Kirill A. Shutemov wrote: > We are going to rework how compound_head() work. It will not use > page->first_page as we have it now. > > The only other user of page->fisrt_page beyond compound pages is > zsmalloc. > > Let's use page->private instead of page->first_page here. It occupies > the same storage space. > > Signed-off-by: Kirill A. Shutemov > --- > mm/zsmalloc.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index 0a7f81aa2249..a85754e69879 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -16,7 +16,7 @@ > * struct page(s) to form a zspage. > * > * Usage of struct page fields: > - * page->first_page: points to the first component (0-order) page > + * page->private: points to the first component (0-order) page > * page->index (union with page->freelist): offset of the first object > * starting in this page. For the first page, this is > * always 0, so we use this field (aka freelist) to point > @@ -26,8 +26,7 @@ > * > * For _first_ page only: > * > - * page->private (union with page->first_page): refers to the > - * component page after the first page > + * page->private: refers to the component page after the first page > * If the page is first_page for huge object, it stores handle. > * Look at size_class->huge. > * page->freelist: points to the first free object in zspage. > @@ -770,7 +769,7 @@ static struct page *get_first_page(struct page *page) > if (is_first_page(page)) > return page; > else > - return page->first_page; > + return (struct page *)page_private(page); > } > > static struct page *get_next_page(struct page *page) > @@ -955,7 +954,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) >* Allocate individual pages and link them together as: >* 1. first page->private = first sub-page >* 2. all sub-pages are linked together using page->lru > - * 3. each sub-page is linked to the first page using page->first_page > + * 3. each sub-page is linked to the first page using page->private >* >* For each size class, First/Head pages are linked together using >* page->lru. Also, we set PG_private to identify the first page > @@ -980,7 +979,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) > if (i == 1) > set_page_private(first_page, (unsigned long)page); > if (i >= 1) > - page->first_page = first_page; > + set_page_private(first_page, (unsigned long)first_page); > if (i >= 2) > list_add(&page->lru, &prev_page->lru); > if (i == class->pages_per_zspage - 1) /* last page */ > -- > 2.5.0 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, 2015-08-25 6:47 GMT+09:00 Olof Johansson : > Hi, > > On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada > wrote: >> 1/3: add outer cache support >> 2/3: rework SMP operations >> 3/3: add device tree nodes > > Timing of this is unfortunate, please resend after 4.3-rc1 is out and > we can queue it up. Given that rc8 is out and the merge window has been delayed, is it still too late for 4.3-rc1? >> Because 2/3 highly depends on 1/3, I hope whole of this series >> is applied to ARM-SOC tree. > > Review or acked-by from Russell would be appreciated in that case. > >> Olof, >> From this series, I am using "ARM: uniphier:" rather than "ARM: UniPhier:" >> for the subject prefixes because I noticed you often rephased so when you >> applied my patches. >> Are sub-arch names in lower cases preferable in subject prefixes? > > If you look at "git log --no-merges --oneline arch/arm/mach-*" you'll > see that most platforms use either all-caps or all-lowercase. I see. But, we use "UniPhier" (with only U and P capitalized) in our official documents. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]
Hi Laura,
You can find the patch here:
http://patchwork.kernerl.xyz/patch/6967161/
I will send this patch again and cc to you.
Best regards
Haibo
> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Tuesday, August 25, 2015 12:27 AM
> To: Chen Haibo-B51421; Jiri Slaby; Ulf Hansson
> Cc: linux-...@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
>
> On 08/06/2015 02:17 AM, Chen Bough wrote:
> > I will format a patch based on your diff file firstly. I will test
> > this on my side, If any issue, like dma issue or performance issue, I
> will add some modification.
> > Then I will send the patch for review, and you can test the patch on
> your platform.
> >
> > Best Regards
> > Haibo Chen
> >
>
> Did I miss the follow up patch or is this still pending? If it's still
> pending, would you mind Ccing me when it's available for testing?
>
> Thanks,
> Laura
>
> >
> >> -Original Message-
> >> From: Jiri Slaby [mailto:jsl...@suse.cz]
> >> Sent: Thursday, August 06, 2015 5:07 PM
> >> To: Chen Haibo-B51421; Ulf Hansson
> >> Cc: linux-...@vger.kernel.org; Linux kernel mailing list
> >> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy
> >> (thousands) DMA leaks]
> >>
> >> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> >>> I read your attached log and patch, yes, dma memory leak will happen
> >>> when more than one pre_request execute. The method of ++next->cookie
> >>> is not good, your patch seems good, but I still need some time to
> >>> test the patch, because you unmap the dma in sdhci_finish_data
> >>> rather than
> >> the sdhci_post_req.
> >>
> >> Hi,
> >>
> >> yes, this is not correct. We can perhaps differentiate according to
> >> the COOKIE value. Should I fix it or are you going to prepare a patch
> >> based on my RFC?
> >>
> >> thanks,
> >> --
> >> js
> >> suse labs
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 4/7] ARM: EXYNOS: Remove SROM related register settings from mach-exynos
On 24.08.2015 17:02, Pankaj Dubey wrote: > As now we have dedicated driver for SROM controller, it will take care > of saving register banks during S2R so we can safely remove these > settings from mach-exynos. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/Kconfig | 2 ++ > arch/arm/mach-exynos/common.h| 2 -- > arch/arm/mach-exynos/exynos.c| 17 - > arch/arm/mach-exynos/include/mach/map.h | 3 -- > arch/arm/mach-exynos/regs-srom.h | 53 > > arch/arm/mach-exynos/suspend.c | 20 ++- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > 7 files changed, 4 insertions(+), 94 deletions(-) > delete mode 100644 arch/arm/mach-exynos/regs-srom.h The order of patches looks wrong. Is this fully bisectable? You are removing here support for SROM but DTS bindings are not added yet. > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 3a10f1a..7c917ef 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -27,6 +27,8 @@ menuconfig ARCH_EXYNOS > select SRAM > select THERMAL > select MFD_SYSCON > + select SOC_SAMSUNG > + select EXYNOS_SROM > help > Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) > > diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h > index 1534925..1c04741 100644 > --- a/arch/arm/mach-exynos/common.h > +++ b/arch/arm/mach-exynos/common.h > @@ -108,8 +108,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, > EXYNOS5_SOC_MASK) > > #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \ > soc_is_exynos4412()) > -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \ > - soc_is_exynos5420() || soc_is_exynos5800()) That wasn't here in v1. I see that it is not used any more and of_machine_is_compatible is preferred but I would prefer to leave it. In certain cases you cannot use of_machine_is_compatible (e.g. in platform_do_lowpower). Rest looks good. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SCSI: DTC: Adding KERN_ facility level
On Tue, 30 Jun 2015, Rudhresh Kumar J wrote:
> Fixed coding style issue by adding KERN_ facility level to some of
> the printk functions.
>
> Signed-off-by: Rudhresh Kumar J
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..a3a2a71 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -156,7 +156,7 @@ static int __init dtc_setup(char *str)
>
> get_options(str, ARRAY_SIZE(ints), ints);
> if (ints[0] != 2)
> - printk("dtc_setup: usage dtc=address,irq\n");
> + printk(KERN_DEBUG "dtc_setup: usage dtc=address,irq\n");
No, that is an error message that the user needs to see.
> else if (commandline_current < NO_OVERRIDES) {
> overrides[commandline_current].address = ints[1];
> overrides[commandline_current].irq = ints[2];
> @@ -272,7 +272,7 @@ found:
> instance->irq = NO_IRQ;
> #endif
> #if defined(DTCDEBUG) && (DTCDEBUG & DTCDEBUG_INIT)
> - printk("scsi%d : irq = %d\n", instance->host_no, instance->irq);
> + printk(KERN_DEBUG "scsi%d : irq = %d\n", instance->host_no,
> instance->irq);
> #endif
>
> ++current_override;
>
I have a better patch for this, which makes use of the dprintk macro to
replace {DTC,P,T}DEBUG_INIT with NDEBUG_INIT. Thanks anyway.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] SCSI: DTC: Removed 0 initialization for statics
On Mon, 29 Jun 2015, Rudhresh wrote:
> Removed unneccessary initialization of zero to a static variable
>
> Signed-off-by: Rudhresh Kumar J
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..99164d6 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -150,7 +150,7 @@ static const struct signature {
>
> static int __init dtc_setup(char *str)
> {
> - static int commandline_current = 0;
> + static int commandline_current;
> int i;
> int ints[10];
>
> @@ -188,7 +188,7 @@ __setup("dtc=", dtc_setup);
>
> static int __init dtc_detect(struct scsi_host_template * tpnt)
> {
> - static int current_override = 0, current_base = 0;
> + static int current_override, current_base;
> struct Scsi_Host *instance;
> unsigned int addr;
> void __iomem *base;
>
This issue affects all four copies of this code in the NCR5380 drivers:
drivers/scsi/t128.c:static int commandline_current = 0;
drivers/scsi/t128.c:static int current_override = 0, current_base = 0;
drivers/scsi/dtc.c: static int commandline_current = 0;
drivers/scsi/dtc.c: static int current_override = 0, current_base = 0;
drivers/scsi/g_NCR5380.c: static int commandline_current = 0;
drivers/scsi/g_NCR5380.c: static int current_override = 0;
drivers/scsi/pas16.c:static int commandline_current = 0;
drivers/scsi/pas16.c:static int current_override = 0;
drivers/scsi/pas16.c:static unsigned short current_base = 0;
And there are more instances of redundant initialization in pas16.c,
NCR5380.c and sun3_scsi.c.
All of these drivers have the same maintainers, so I'd prefer a single
patch to fix this.
You must address your patches to all of the interested parties (see
scripts/get_maintainer.pl).
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] SCSI: dtc: Fixed a brace issue on return 0
On Sun, 28 Jun 2015, Rudhresh wrote:
> From: rudhresh
>
> Return is not a function so parenthesis is not required
>
> Signed-off-by: Rudhresh
Can you put your full name here?
You must address your patches to all of the interested parties (see
scripts/get_maintainer.pl).
Please read Documentation/SubmittingPatches and adhere to the instructions
therein.
--
>
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..c793ecf 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -363,7 +363,7 @@ static inline int NCR5380_pread(struct Scsi_Host
> *instance, unsigned char *dst,
> NCR5380_read(RESET_PARITY_INTERRUPT_REG);
> if (i > hostdata->spin_max_r)
> hostdata->spin_max_r = i;
> - return (0);
> + return 0;
> }
>
> /
> @@ -417,7 +417,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host
> *instance, unsigned char *src,
> rtrc(0);
> if (i > hostdata->spin_max_w)
> hostdata->spin_max_w = i;
> - return (0);
> + return 0;
> }
>
> MODULE_LICENSE("GPL");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/7] ARM: dts: add SROM device node for exynos4
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add device node of SROM controller for exynos4. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos4.dtsi | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for suspend
Hi, Boris,thanks for your review
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, August 24, 2015 4:50 PM
> To: Chen, Yu C
> Cc: r...@rjwysocki.net; pa...@ucw.cz; t...@linutronix.de;
> mi...@redhat.com; h...@zytor.com; Zhang, Rui; l...@kernel.org;
> x...@kernel.org; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for
> suspend
>
> On Fri, Aug 21, 2015 at 07:53:34PM +0800, Chen Yu wrote:
> > +struct msr_type {
> > + unsigned int msr_id;
> > + bool msr_saved;
> > + u64 msr_value;
> > +};
>
> These definitions look awfully close to struct msr_info in include/asm/msr.h
>
> Maybe reuse them instead of growing yet another type...
>
OK, I'll use msr_info instead of msr_id and msr_value:
struct msr_type {
bool msr_saved;
struct msr_info rv;
};
> > +static void msr_save_context(struct saved_context *ctxt) {
> > + int i = 0;
> > +
> > + for (i = 0; i < ctxt->msr_for_save.num; i++) {
> > + struct msr_type *msr =
> > + &ctxt->msr_for_save.msr_array[i];
>
> No need for the line breaks here, let them stick out for better readability.
>
OK, will do.
> > + msr->msr_saved = !rdmsrl_safe(msr->msr_id,
> > + &msr->msr_value);
> > + }
> > + struct msr_type *msr =
> > + &ctxt->msr_for_save.msr_array[i];
> > + if (msr->msr_saved)
> > + wrmsrl(msr->msr_id, msr->msr_value);
>
> Ditto.
>
OK, will do.
Best Regards,
Yu
[PATCH] mmc: sdhci: fix dma memory leak in sdhci_pre_req()
Currently one mrq->data maybe execute dma_map_sg() twice
when mmc subsystem prepare over one new request, and the
following log show up:
sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req
for the first time, and map another dma-memory(2) in sdhci_prepare_data
for the second time. But driver only unmap the dma-memory(2), and
dma-memory(1) never unmapped, which cause the dma memory leak issue.
This patch use another method to map the dma memory for the mrq->data
which can fix this dma memory leak issue.
Fixes: commit 348487cb28e66b0 ("mmc: sdhci: use pipeline mmc requests to
improve performance")
Cc: sta...@vger.kernel.org # 4.0+
Reported-and-tested-by: Jiri Slaby
Signed-off-by: Haibo Chen
---
drivers/mmc/host/sdhci.c | 67 ++--
drivers/mmc/host/sdhci.h | 8 +++---
2 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c83d110..8d2864b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -54,8 +54,7 @@ static void sdhci_finish_command(struct sdhci_host *);
static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
static void sdhci_enable_preset_value(struct sdhci_host *host, bool enable);
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next);
+ struct mmc_data *data);
static int sdhci_do_get_cd(struct sdhci_host *host);
#ifdef CONFIG_PM
@@ -495,7 +494,7 @@ static int sdhci_adma_table_pre(struct sdhci_host *host,
goto fail;
BUG_ON(host->align_addr & host->align_mask);
- host->sg_count = sdhci_pre_dma_transfer(host, data, NULL);
+ host->sg_count = sdhci_pre_dma_transfer(host, data);
if (host->sg_count < 0)
goto unmap_align;
@@ -634,9 +633,11 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
}
}
- if (!data->host_cookie)
+ if (data->host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host->mmc), data->sg,
data->sg_len, direction);
+ data->host_cookie = COOKIE_UNMAPPED;
+ }
}
static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
@@ -832,7 +833,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
} else {
int sg_cnt;
- sg_cnt = sdhci_pre_dma_transfer(host, data, NULL);
+ sg_cnt = sdhci_pre_dma_transfer(host, data);
if (sg_cnt <= 0) {
/*
* This only happens when someone fed
@@ -948,11 +949,13 @@ static void sdhci_finish_data(struct sdhci_host *host)
if (host->flags & SDHCI_USE_ADMA)
sdhci_adma_table_post(host, data);
else {
- if (!data->host_cookie)
+ if (data->host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host->mmc),
data->sg, data->sg_len,
(data->flags & MMC_DATA_READ) ?
DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ data->host_cookie = COOKIE_UNMAPPED;
+ }
}
}
@@ -2105,49 +2108,36 @@ static void sdhci_post_req(struct mmc_host *mmc, struct
mmc_request *mrq,
struct mmc_data *data = mrq->data;
if (host->flags & SDHCI_REQ_USE_DMA) {
- if (data->host_cookie)
+ if (data->host_cookie == COOKIE_GIVEN ||
+ data->host_cookie == COOKIE_MAPPED)
dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
data->flags & MMC_DATA_WRITE ?
DMA_TO_DEVICE : DMA_FROM_DEVICE);
- mrq->data->host_cookie = 0;
+ data->host_cookie = COOKIE_UNMAPPED;
}
}
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next)
+ struct mmc_data *data)
{
int sg_count;
- if (!next && data->host_cookie &&
- data->host_cookie != host->next_data.cookie) {
- pr_debug(DRIVER_NAME "[%s] invalid cookie: %d, next-cookie
%d\n",
- __func__, data->host_cookie, host->next_data.cookie);
- data->host_cookie = 0;
+ if (data->host_cookie == COOKIE_MAPPED) {
+
Re: [PATCH 1/2] cgroup: get a ref to source csses when migrating
> Have you verified that the scenario you're describing can actually > happen? AFAICS, cgroup_migrate_add_src() already does the pinning. Hmmm. Looking at it, group_migrate_add_src() does grab a ref on the css_set which contains the css, and the comments mention that grabbing a ref on the css_set will stop the css from being dropped. I must've misunderstood one of your previous emails (where you said that such code was not safe in the ->can_fork(), ->cancel_fork() and ->fork()) path. You also mentioned that depending on the css_set's ref being bumped to protect the contained csses is "sort of implementation detail. It can be implemented in different ways." Which made me think that depending on that is not a good idea. But if it's safe to depend on the cgroup_migrate_add_src() pinning the ref on the css_set, I'll drop this patch and fix up the other one accordingly. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/7] ARM: dts: add SROM device node for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add SROM controller device node for exynos5. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos5.dtsi | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/7] Documentation: dt-bindings: add exynos-srom binding information
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch adds exynos-srom binding information for SROM Controller > driver on Exynos SoCs. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > .../devicetree/bindings/arm/samsung/exynos-srom.txt | 12 > > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ipmi: add of_device_id in MODULE_DEVICE_TABLE
> On Aug 25, 2015, at 08:48, Corey Minyard wrote: > > Well, I should have compile tested first. On x86_64: > > > CC [M] drivers/char/ipmi/ipmi_si_intf.o > In file included from ../drivers/char/ipmi/ipmi_si_intf.c:42:0: > ../drivers/char/ipmi/ipmi_si_intf.c:2804:25: error: ‘ipmi_match’ > undeclared here (not in a function) > MODULE_DEVICE_TABLE(of, ipmi_match); > ^ > ../include/linux/module.h:223:21: note: in definition of macro > ‘MODULE_DEVICE_TABLE’ > extern const typeof(name) __mod_##type##__##name##_device_table \ > ^ > ../include/linux/module.h:223:27: error: > ‘__mod_of__ipmi_match_device_table’ aliased to undefined symbol ‘ipmi_match’ > extern const typeof(name) __mod_##type##__##name##_device_table \ > ^ > ../drivers/char/ipmi/ipmi_si_intf.c:2804:1: note: in expansion of macro > ‘MODULE_DEVICE_TABLE’ > MODULE_DEVICE_TABLE(of, ipmi_match); > > > This has to compile on all arches. I'm not sure what is wrong, but I've > removed the patch. > > -corey it seems should be : MODULE_DEVICE_TABLE(of, of_ipmi_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] memory-hotplug: fix comment in zone_spanned_pages_in_node() and zone_spanned_pages_in_node()
When hotadd a node from add_memory(), we will add memblock first, so the
node is not empty. But when from cpu_up(), the node should be empty.
Signed-off-by: Xishi Qiu
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ec3ca3..d370445 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5051,7 +5051,7 @@ static unsigned long __meminit
zone_spanned_pages_in_node(int nid,
{
unsigned long zone_start_pfn, zone_end_pfn;
- /* When hotadd a new node, the node should be empty */
+ /* When hotadd a new node from cpu_up(), the node should be empty */
if (!node_start_pfn && !node_end_pfn)
return 0;
@@ -5118,7 +5118,7 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];
unsigned long zone_start_pfn, zone_end_pfn;
- /* When hotadd a new node, the node should be empty */
+ /* When hotadd a new node from cpu_up(), the node should be empty */
if (!node_start_pfn && !node_end_pfn)
return 0;
--
2.0.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: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen wrote: > MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster > share the same power and clock domain. This series tries to add cpufreq > support > for MT8173 SoC. The v6 of this series is resent with Acks added. Hi Rafael, Not sure if I has missed the merge window. Do I have chance to have this series merged for 4.3? Would you please take [1,2] of this series? Thanks. Best Regards, Pi-Cheng > > changes in v6: > - Move clock and regulator consumer properties document to the device tree > bindings documents of MT8173 CPU DVFS clock driver > - Add change log to describe what is implemented in the MT8173 cpufreq driver > - Add missed rcu_read_unlock() in the error path > - Move of_init_opp_table() call to make sure all required hardware resources > are already there before it is called > - Add comments to describe why both platform driver and deivce registration > codes are put in the initcall function > - Use the term "voltage tracking" instead of "voltage trace" according to an > internal SoC document > > changes in v5: > - Move resource allocation code from init() into probe() and remove some > unused > functions due to this change > - Fix descriptions for device tree binding document > - Address review comments for last version > - Register CPU cooling device > > Changes in v4: > - Add bindings for MT8173 cpufreq driver > - Move OPP table back into device tree > - Address comments for last version > > Changes in v3: > - Implement MT8173 specific standalone cpufreq driver instead of using > cpufreq-dt driver > - Define OPP table in the driver source code until new OPP binding is ready > > Changes in v2: > - Add intermediate frequency support in cpufreq-dt driver > - Use voltage scaling code of cpufreq-dt for little cluster instead of > implementaion in notifier of mtk-cpufreq driver > - Code refinement for mtk-cpufreq driver > > Pi-Cheng Chen (3): > dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings > cpufreq: mediatek: Add MT8173 cpufreq driver > arm64: dts: mt8173: Add mt8173 cpufreq driver support > > .../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 > arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 18 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 64 +++ > drivers/cpufreq/Kconfig.arm| 7 + > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/mt8173-cpufreq.c | 524 > + > 6 files changed, 697 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > create mode 100644 drivers/cpufreq/mt8173-cpufreq.c > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] xen/blkfront: convert to blk-mq APIs
Hi Rafal, Please have a try adding "--iodepth_batch=32 --iodepth_batch_complete=32" to the fio command line. I didn't see this issue any more, neither for domU. Thanks, -Bob On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote: > On 19/08/15 12:12, Bob Liu wrote: >> Hi Jens & Christoph, >> >> Rafal reported an issue about this patch, that's after this patch no more >> merges happen and the performance dropped if "modprobe null_blk irqmode=2 >> completion_nsec=100", >> but works fine if "modprobe null_blk". >> >> I'm not sure whether it's as expect or not. >> Do you have any suggestions? Thank you! >> >> Here is the test result: >> >> fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ >> --time_based=1 --runtime=30 --bs=4KB --filename=/dev/xvdb \ >> --direct=1 --group_reporting=1 --iodepth_batch=16 >> >> >> modprobe null_blk >> >> >> *no patch* (avgrq-sz = 8.00 avgqu-sz=5.00) >> >> READ: io=10655MB, aggrb=363694KB/s, minb=363694KB/s, maxb=363694KB/s, >> mint=30001msec, maxt=30001msec >> >> Disk stats (read/write): >> xvdb: ios=2715852/0, merge=1089/0, ticks=126572/0, in_queue=127456, >> util=100.00% >> >> >> *with patch* (avgrq-sz = 8.00 avgqu-sz=8.00) >> >> READ: io=20655MB, aggrb=705010KB/s, minb=705010KB/s, maxb=705010KB/s, >> mint=30001msec, maxt=30001msec >> >> Disk stats (read/write): >> xvdb: ios=5274633/0, merge=22/0, ticks=243208/0, in_queue=242908, >> util=99.98% >> >> >> modprobe null_blk irqmode=2 completion_nsec=100 >> >> >> *no patch* (avgrq-sz = 34.00 avgqu-sz=38.00) >> >> READ: io=10372MB, aggrb=354008KB/s, minb=354008KB/s, maxb=354008KB/s, >> mint=30003msec, maxt=30003msec >> >> Disk stats (read/write): >> xvdb: ios=621760/0, *merge=1988170/0*, ticks=1136700/0, in_queue=1146020, >> util=99.76% >> >> >> *with patch* (avgrq-sz = 8.00 avgqu-sz=28.00) >> >> READ: io=2876.8MB, aggrb=98187KB/s, minb=98187KB/s, maxb=98187KB/s, >> mint=30002msec, maxt=30002msec >> >> Disk stats (read/write): >> xvdb: ios=734048/0, merge=0/0, ticks=843584/0, in_queue=843080, util=99.72% >> >> Regards, >> -Bob > > Hello, > > We got a problem with the lack of merges also when we tested on null_blk > device in dom0 directly. > When we enabled multi queue block-layer we got no merges, even when we set > the number of submission queues to 1. > > If I don't miss anything, that could suggest the problem lays somewhere in > the blk-mq layer itself? > > Please take a look at the results below: > > fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ > --time_based=1 --runtime=30 --bs=4KB --filename=/dev/nullb0 \ > --direct=1 --group_reporting=1 > > > modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=1 > submit_queues=1 > >READ: io=13692MB, aggrb=467320KB/s, minb=467320KB/s, maxb=467320KB/s, > mint=30002msec, maxt=30002msec > > Disk stats (read/write): > nullb0: ios=991026/0, merge=2499524/0, ticks=1846952/0, in_queue=900012, > util=100.00% > > > modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=2 > submit_queues=1 > >READ: io=6839.1MB, aggrb=233452KB/s, minb=233452KB/s, maxb=233452KB/s, > mint=30002msec, maxt=30002msec > > Disk stats (read/write): > nullb0: ios=1743967/0, merge=0/0, ticks=1712900/0, in_queue=1839072, > util=100.00% > > Thanks, > Rafal > >> >> On 07/13/2015 05:55 PM, Bob Liu wrote: >>> Note: This patch is based on original work of Arianna's internship for >>> GNOME's Outreach Program for Women. >>> >>> Only one hardware queue is used now, so there is no performance change. >>> >>> The legacy non-mq code is deleted completely which is the same as other >>> drivers like virtio, mtip, and nvme. >>> >>> Also dropped one unnecessary holding of info->io_lock when calling >>> blk_mq_stop_hw_queues(). >>> >>> Changes in v2: >>> - Reorgan
Re: [PATCHv2 2/4] zsmalloc: use page->private instead of page->first_page
On (08/17/15 18:09), Kirill A. Shutemov wrote: [..] > @@ -980,7 +979,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) > if (i == 1) > set_page_private(first_page, (unsigned long)page); > if (i >= 1) > - page->first_page = first_page; > + set_page_private(first_page, (unsigned long)first_page); This patch breaks zram/zsmalloc. Shouldn't it be `page->private = first_page' instead of `first_page->private = first_page'? IOW: - set_page_private(first_page, (unsigned long)first_page); + set_page_private(page, (unsigned long)first_page); ? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/7] Add support for Exynos SROM Controller driver
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch set adds support for Exynos SROM controller DT based driver. > Currently SROM register sets are used only during S2R, so driver > basically added for taking care of S2R. It will help us in removing > static mapping from exynos.c and other extra code handline during S2R. > > This patch set also updated exynos4 and exynos5 dtsi files for with device > node for srom, and added binding documentation for the same. > > First two patches are some minor cleanup in mach-exynos. > > Patchset v1 was posted here[1] > [1]: https://lkml.org/lkml/2015/4/29/98 > > Changes since v1: > - Rebased to latest kgene tree. > - Addressed review comments from Krzysztof Kozlowski. > - Add two new patches for minor cleanup in exynos.c and map.h > > Pankaj Dubey (7): > ARM: EXYNOS: remove unused static mapping of CMU for exynos5 > ARM: EXYNOS: code cleanup in map.h > drivers: soc: add support for exynos SROM driver > ARM: EXYNOS: Remove SROM related register settings from mach-exynos > ARM: dts: add SROM device node for exynos4 > ARM: dts: add SROM device node for exynos5 > Documentation: dt-bindings: add exynos-srom binding information One more thing: please update the existing Exynos entry in maintainers so it would cover drivers/soc/samsung. Best regards, Krzysztof > > .../bindings/arm/samsung/exynos-srom.txt | 12 ++ > arch/arm/boot/dts/exynos4.dtsi | 5 + > arch/arm/boot/dts/exynos5.dtsi | 5 + > arch/arm/mach-exynos/Kconfig | 2 + > arch/arm/mach-exynos/common.h | 2 - > arch/arm/mach-exynos/exynos.c | 22 > arch/arm/mach-exynos/include/mach/map.h| 8 -- > arch/arm/mach-exynos/regs-srom.h | 53 > arch/arm/mach-exynos/suspend.c | 20 +-- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > drivers/soc/Kconfig| 1 + > drivers/soc/Makefile | 1 + > drivers/soc/samsung/Kconfig| 13 ++ > drivers/soc/samsung/Makefile | 1 + > drivers/soc/samsung/exynos-srom.c | 143 > + > drivers/soc/samsung/exynos-srom.h | 51 > 16 files changed, 236 insertions(+), 104 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > delete mode 100644 arch/arm/mach-exynos/regs-srom.h > create mode 100644 drivers/soc/samsung/Kconfig > create mode 100644 drivers/soc/samsung/Makefile > create mode 100644 drivers/soc/samsung/exynos-srom.c > create mode 100644 drivers/soc/samsung/exynos-srom.h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On August 24, 2015 6:57:57 PM MDT, Sean Fu wrote: >An application from HuaWei which works fine on 2.6 encounters this >issue on 3.0 or later kernel. My sympathies. Being stuck with a 3rd party application you can barely talk about that has been broken for 5years and no one reported it. Ordinarily we would fix a regression like this. As it has been 5years the challenge now is how do we tell if there are applications that depend on the current behavior. Before we can change the behavior back we need a convincing argument that we won't cause a regression in another application by making the change. I do not see how such an argument can be made. So you have my sympathies but I do not see how we can help you. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/20] ACPICA: Correctly cleanup after a ACPI table load failure.
From: Bob Moore
ACPICA commit ed7769e832de6c7ba90615480d916c85fd100422
If a table load fails, delete all namespace objects created by the
table, otherwise these objects will be uninitialized, causing
problems later. This appears to be a very rare problem.
Also handle the unitialized node problem to prevent possible
faults. ACPICA BZ 1185.
Link: https://github.com/acpica/acpica/commit/ed7769e8
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/exresnte.c |2 +-
drivers/acpi/acpica/exresolv.c | 16 +++-
drivers/acpi/acpica/nseval.c |1 +
drivers/acpi/acpica/nsload.c | 16 +++-
drivers/acpi/acpica/tbxfload.c | 29 ++---
include/acpi/acexcep.h |7 +--
6 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/acpica/exresnte.c b/drivers/acpi/acpica/exresnte.c
index c7e3b92..1b372ef 100644
--- a/drivers/acpi/acpica/exresnte.c
+++ b/drivers/acpi/acpica/exresnte.c
@@ -126,7 +126,7 @@ acpi_ex_resolve_node_to_value(struct acpi_namespace_node
**object_ptr,
if (!source_desc) {
ACPI_ERROR((AE_INFO, "No object attached to node [%4.4s] %p",
node->name.ascii, node));
- return_ACPI_STATUS(AE_AML_NO_OPERAND);
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
}
/*
diff --git a/drivers/acpi/acpica/exresolv.c b/drivers/acpi/acpica/exresolv.c
index b6b7f3a..7b10912 100644
--- a/drivers/acpi/acpica/exresolv.c
+++ b/drivers/acpi/acpica/exresolv.c
@@ -337,8 +337,9 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
acpi_object_type * return_type,
union acpi_operand_object **return_desc)
{
- union acpi_operand_object *obj_desc = (void *)operand;
- struct acpi_namespace_node *node;
+ union acpi_operand_object *obj_desc = ACPI_CAST_PTR(void, operand);
+ struct acpi_namespace_node *node =
+ ACPI_CAST_PTR(struct acpi_namespace_node, operand);
acpi_object_type type;
acpi_status status;
@@ -355,9 +356,7 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
case ACPI_DESC_TYPE_NAMED:
type = ((struct acpi_namespace_node *)obj_desc)->type;
- obj_desc =
- acpi_ns_get_attached_object((struct acpi_namespace_node *)
- obj_desc);
+ obj_desc = acpi_ns_get_attached_object(node);
/* If we had an Alias node, use the attached object for type
info */
@@ -368,6 +367,13 @@ acpi_ex_resolve_multiple(struct acpi_walk_state
*walk_state,
acpi_namespace_node *)
obj_desc);
}
+
+ if (!obj_desc) {
+ ACPI_ERROR((AE_INFO,
+ "[%4.4s] Node is unresolved or
uninitialized",
+ acpi_ut_get_node_name(node)));
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
+ }
break;
default:
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 80670cb..88822b7a 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -274,6 +274,7 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info
*info)
acpi_ex_exit_interpreter();
if (ACPI_FAILURE(status)) {
+ info->return_object = NULL;
goto cleanup;
}
diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index bd6cd4a..14ab836 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -111,7 +111,21 @@ acpi_ns_load_table(u32 table_index, struct
acpi_namespace_node *node)
if (ACPI_SUCCESS(status)) {
acpi_tb_set_table_loaded_flag(table_index, TRUE);
} else {
- (void)acpi_tb_release_owner_id(table_index);
+ /*
+* On error, delete any namespace objects created by this table.
+* We cannot initialize these objects, so delete them. There are
+* a couple of expecially bad cases:
+* AE_ALREADY_EXISTS - namespace collision.
+* AE_NOT_FOUND - the target of a Scope operator does not
+* exist. This target of Scope must already exist in the
+* namespace, as per the ACPI specification.
+*/
+ (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ acpi_ns_delete_namespace_by_owner(acpi_gbl_root_table_list.
+ tables[table_index].owner_id);
+ acpi_tb_release_owner_id(table_index);
+
+ return_ACPI_STATUS(status);
[PATCH 00/20] ACPICA: 20150818 Release
The 20150818 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. i386 + allyes + CONFIG_ACPI=y 3. i386 + default + COFNIG_ACPI=n 4. i386 + allyes + CONFIG_ACPI=n 5. x86_64 + default + COFNIG_ACPI=y 6. x86_64 + allyes + CONFIG_ACPI=y 7. x86_64 + default + COFNIG_ACPI=n 8. x86_64 + allyes + CONFIG_ACPI=n Boot tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. x86_64 + default + COFNIG_ACPI=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150717 Release): 518 lines After applying (20150818 Release): 517 lines Bob Moore (14): ACPICA: Correctly cleanup after a ACPI table load failure. ACPICA: Disassembler: Remove duplicate code in _PLD processing. ACPICA: Update parameter validation for data_table_region and load_table. ACPICA: Disassembler: Update for new listing mode. ACPICA: Update info messages during ACPICA init. ACPICA: Headers: Fix some comments, no functional change. ACPICA: acpinames: Add new options and wildcard support. ACPICA: acpiexec/acpinames: Support very large number of ACPI tables. ACPICA: Table handling: Cleanup and update debug output for tools. ACPICA: Add additional debug info/statements. ACPICA: Debugger: Add option to display namespace summary/counts. ACPICA: Make the max-number-of-loops runtime configurable. ACPICA: Header support to improve compatibility with MSVC. ACPICA: Update version to 20150818. Lv Zheng (6): ACPICA: Tables: Fix global table list issues by removing fixed table indexes. ACPICA: Tables: Cleanup to reduce FACS globals. ACPICA: Debugger: Split debugger initialization/termination APIs. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_verbose acpiexec usage. ACPICA: Debugger: Cleanup debugging outputs to dump name path without trailing underscores. drivers/acpi/acpica/acdebug.h |7 --- drivers/acpi/acpica/acglobal.h | 19 +--- drivers/acpi/acpica/aclocal.h | 17 +-- drivers/acpi/acpica/actables.h | 14 -- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/dscontrol.c |2 +- drivers/acpi/acpica/dsdebug.c |2 +- drivers/acpi/acpica/dsinit.c| 20 ++--- drivers/acpi/acpica/dsopcode.c | 31 - drivers/acpi/acpica/evregion.c | 22 +++-- drivers/acpi/acpica/exconfig.c |8 drivers/acpi/acpica/exdump.c|2 +- drivers/acpi/acpica/exresnte.c |2 +- drivers/acpi/acpica/exresolv.c | 16 --- drivers/acpi/acpica/hwxfsleep.c | 15 +-- drivers/acpi/acpica/nseval.c|4 +- drivers/acpi/acpica/nsload.c| 16 ++- drivers/acpi/acpica/nsutils.c | 19 +++- drivers/acpi/acpica/psloop.c| 14 +- drivers/acpi/acpica/tbfadt.c|6 +-- drivers/acpi/acpica/tbfind.c| 15 ++- drivers/acpi/acpica/tbinstal.c | 40 + drivers/acpi/acpica/tbutils.c | 73 -- drivers/acpi/acpica/tbxfload.c | 93 +-- drivers/acpi/acpica/utfileio.c |2 +- drivers/acpi/acpica/utinit.c|1 + drivers/acpi/acpica/utmisc.c|4 +- drivers/acpi/acpica/utxface.c | 12 ++--- drivers/acpi/acpica/utxfinit.c | 11 - include/acpi/acbuffer.h |1 + include/acpi/acconfig.h |4 -- include/acpi/acexcep.h |7 ++- include/acpi/acpixf.h |5 ++- include/acpi/actypes.h |2 + include/acpi/platform/acenv.h | 19 35 files changed, 330 insertions(+), 197 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/20] ACPICA: Disassembler: Update for new listing mode.
From: Bob Moore ACPICA commit 2ed09bb7619d25f5a5c065c33a8a775a6db3a856 ACPICA commit 2fefacf73825b0ec96bbfc4f70a256735b715d6c This mode emits AML code along with the ASL code. A new global was needed to ensure the listing mode is completely separate from the debugger verbose mode. Emits the correct AML offset for the AML code. The -l option now works for both the compiler and disassembler. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/2fefacf7 Link: https://github.com/acpica/acpica/commit/2ed09bb7 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 79eb35d..1283b19 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -307,9 +307,9 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_INIT_GLOBAL(union acpi_parse_object *, acpi_gbl_previous_op, NULL); ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); ACPI_GLOBAL(u32, acpi_gbl_resolved_external_methods); -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/20] ACPICA: Tables: Fix global table list issues by removing fixed table indexes.
ACPICA commit c0b38b4c3982c2336ee92a2a14716107248bd941
The fixed table indexes leave holes in the global table list:
1. One hole can be seen when there is only 1 FACS provided by the BIOS.
2. Tow holes can be seen when it is a reduced hardware platform.
The holes do not break OSPMs but have broken ACPI debugger "tables"
command.
Also the "fixed table indexes" mechanism may make the descriptors of the
standard tables installed earlier than DSDT to be overwritten by the
descriptors of the fixed tables. For example, FACP disappears from the
global table list after DSDT is installed.
This patch fixes all above issues by removing the "fixed table indexes"
mechanism which is too complicated to be maintained in a regression safe
manner. After removal, the table loader will determine the indexes of the
fixed tables. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c0b38b4c
Cc:
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |3 +++
drivers/acpi/acpica/aclocal.h |6 ++
drivers/acpi/acpica/actables.h |7 +++
drivers/acpi/acpica/tbfadt.c |6 +++---
drivers/acpi/acpica/tbinstal.c | 40 +---
drivers/acpi/acpica/tbutils.c | 37 ++---
drivers/acpi/acpica/tbxfload.c | 10 +-
7 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 1283b19..e78667e 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -58,6 +58,9 @@ ACPI_GLOBAL(struct acpi_table_list, acpi_gbl_root_table_list);
ACPI_GLOBAL(struct acpi_table_header *, acpi_gbl_DSDT);
ACPI_GLOBAL(struct acpi_table_header, acpi_gbl_original_dsdt_header);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_dsdt_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_facs_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index, ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index a6b6887..92cbaee 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -213,11 +213,9 @@ struct acpi_table_list {
#define ACPI_ROOT_ORIGIN_ALLOCATED (1)
#define ACPI_ROOT_ALLOW_RESIZE (2)
-/* Predefined (fixed) table indexes */
+/* Predefined table indexes */
-#define ACPI_TABLE_INDEX_DSDT (0)
-#define ACPI_TABLE_INDEX_FACS (1)
-#define ACPI_TABLE_INDEX_X_FACS (2)
+#define ACPI_INVALID_TABLE_INDEX(0x)
struct acpi_find_context {
char *search_for;
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 58497b7..ab7f3a0 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -154,13 +154,12 @@ void acpi_tb_check_dsdt_header(void);
struct acpi_table_header *acpi_tb_copy_dsdt(u32 table_index);
void
-acpi_tb_install_table_with_override(u32 table_index,
- struct acpi_table_desc *new_table_desc,
- u8 override);
+acpi_tb_install_table_with_override(struct acpi_table_desc *new_table_desc,
+ u8 override, u32 *table_index);
acpi_status
acpi_tb_install_fixed_table(acpi_physical_address address,
- char *signature, u32 table_index);
+ char *signature, u32 *table_index);
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 6253001..455a070 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -345,7 +345,7 @@ void acpi_tb_parse_fadt(u32 table_index)
/* Obtain the DSDT and FACS tables via their addresses within the FADT
*/
acpi_tb_install_fixed_table((acpi_physical_address) acpi_gbl_FADT.Xdsdt,
- ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);
+ ACPI_SIG_DSDT, &acpi_gbl_dsdt_index);
/* If Hardware Reduced flag is set, there is no FACS */
@@ -354,13 +354,13 @@ void acpi_tb_parse_fadt(u32 table_index)
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.facs,
ACPI_SIG_FACS,
- ACPI_TABLE_INDEX_FACS);
+ &acpi_gbl_facs_index);
}
if (acpi_gbl_FADT.Xfacs) {
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.Xfacs,
ACPI_SIG_FACS,
-
[PATCH 05/20] ACPICA: Update info messages during ACPICA init.
From: Bob Moore
ACPICA commit 4ccf8a1cc499ec8f00345f662a5887483980e1dd
Small cleanup of messages.
Link: https://github.com/acpica/acpica/commit/4ccf8a1c
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dsinit.c |9 +
drivers/acpi/acpica/tbxfload.c |4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 95779e8..bbf52f0 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -237,6 +237,15 @@ acpi_ds_initialize_objects(u32 table_index,
return_ACPI_STATUS(status);
}
+ /* DSDT is always the first AML table */
+
+ if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT)) {
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
+ "\nInitializing Namespace objects:\n"));
+ }
+
+ /* Summary of objects initialized */
+
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
"Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices, "
"%3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 7862cf0..6cbb2f7 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -208,11 +208,11 @@ static acpi_status acpi_tb_load_namespace(void)
if (!tables_failed) {
ACPI_INFO((AE_INFO,
- "All (%u) ACPI AML tables successfully loaded",
+ "%u ACPI AML tables successfully acquired and
loaded",
tables_loaded));
} else {
ACPI_ERROR((AE_INFO,
- "%u ACPI AML tables loaded, %u failed",
+ "%u ACPI AML tables successfully acquired and
loaded, %u failed",
tables_loaded, tables_failed));
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/20] ACPICA: Disassembler: Remove duplicate code in _PLD processing.
From: Bob Moore
ACPICA commit 6d9c827b540837b6e54059e17756a06985e4a196
ACPICA BZ 1176.
Link: https://bugs.acpica.org/show_bug.cgi?id=1176
Link: https://github.com/acpica/acpica/commit/6d9c827b
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/utxface.c |5 +++--
include/acpi/acbuffer.h |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index 51cf52d..c2bd5e2 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -517,7 +517,8 @@ acpi_decode_pld_buffer(u8 *in_buffer,
/* Parameter validation */
- if (!in_buffer || !return_buffer || (length < 16)) {
+ if (!in_buffer || !return_buffer
+ || (length < ACPI_PLD_REV1_BUFFER_SIZE)) {
return (AE_BAD_PARAMETER);
}
@@ -567,7 +568,7 @@ acpi_decode_pld_buffer(u8 *in_buffer,
pld_info->rotation = ACPI_PLD_GET_ROTATION(&dword);
pld_info->order = ACPI_PLD_GET_ORDER(&dword);
- if (length >= ACPI_PLD_BUFFER_SIZE) {
+ if (length >= ACPI_PLD_REV2_BUFFER_SIZE) {
/* Fifth 32-bit DWord (Revision 2 of _PLD) */
diff --git a/include/acpi/acbuffer.h b/include/acpi/acbuffer.h
index 6b040f4..fcf9080 100644
--- a/include/acpi/acbuffer.h
+++ b/include/acpi/acbuffer.h
@@ -147,6 +147,7 @@ struct acpi_pld_info {
*(Intended for BIOS use only)
*/
#define ACPI_PLD_REV1_BUFFER_SIZE 16 /* For Revision 1 of
the buffer (From ACPI spec) */
+#define ACPI_PLD_REV2_BUFFER_SIZE 20 /* For Revision 2 of
the buffer (From ACPI spec) */
#define ACPI_PLD_BUFFER_SIZE20 /* For Revision 2 of
the buffer (From ACPI spec) */
/* First 32-bit dword, bits 0:32 */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/20] ACPICA: Tables: Cleanup to reduce FACS globals.
ACPICA commit 3f42ba76e2a0453976d3108296d5f656fdf2bd6e
In this patch, FACS table mapping is also tuned a bit so that only the
selected FACS table will be mapped by the OSPM (mapped on demand) and the
FACS related global variables can be reduced. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3f42ba76
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |2 --
drivers/acpi/acpica/hwxfsleep.c | 15 ++-
drivers/acpi/acpica/tbutils.c |9 +
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index e78667e..95ed861 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -64,8 +64,6 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index,
ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs32);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs64);
#endif /* !ACPI_REDUCED_HARDWARE */
diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
index 52dfd0d..d62a616 100644
--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -160,19 +160,8 @@ acpi_set_firmware_waking_vectors(acpi_physical_address
physical_address,
ACPI_FUNCTION_TRACE(acpi_set_firmware_waking_vectors);
- /* If Hardware Reduced flag is set, there is no FACS */
-
- if (acpi_gbl_reduced_hardware) {
- return_ACPI_STATUS (AE_OK);
- }
-
- if (acpi_gbl_facs32) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs32,
- physical_address,
- physical_address64);
- }
- if (acpi_gbl_facs64) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs64,
+ if (acpi_gbl_FACS) {
+ (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_FACS,
physical_address,
physical_address64);
}
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index b1d500e..4337990 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -68,6 +68,7 @@ acpi_tb_get_root_table_entry(u8 *table_entry, u32
table_entry_size);
acpi_status acpi_tb_initialize_facs(void)
{
+ struct acpi_table_facs *facs;
/* If Hardware Reduced flag is set, there is no FACS */
@@ -80,14 +81,14 @@ acpi_status acpi_tb_initialize_facs(void)
(void)acpi_get_table_by_index(acpi_gbl_xfacs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
&acpi_gbl_facs32));
- acpi_gbl_FACS = acpi_gbl_facs32;
+&facs));
+ acpi_gbl_FACS = facs;
} else if (acpi_gbl_FADT.facs) {
(void)acpi_get_table_by_index(acpi_gbl_facs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
&acpi_gbl_facs64));
- acpi_gbl_FACS = acpi_gbl_facs64;
+&facs));
+ acpi_gbl_FACS = facs;
}
/* If there is no FACS, just continue. There was already an error msg */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/20] ACPICA: Table handling: Cleanup and update debug output for tools.
From: Bob Moore
ACPICA commit 93862bd7a227543bc617d822ef5c4f8a5d68b519
Add output of table OEM ID along with signature to support lots
of SSDTs.
Cleanup use of table pointers.
Link: https://github.com/acpica/acpica/commit/93862bd7
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dsinit.c | 11 +
drivers/acpi/acpica/tbxfload.c | 53 ++--
2 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index bbf52f0..920f1b1 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -247,11 +247,12 @@ acpi_ds_initialize_objects(u32 table_index,
/* Summary of objects initialized */
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
- "Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices, "
- "%3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
- table->signature, owner_id, info.object_count,
- info.device_count, info.op_region_count,
- info.method_count, info.serial_method_count,
+ "Table [%4.4s:%8.8s] (id %.2X) - %4u Objects with
%3u Devices, "
+ "%3u Regions, %4u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
+ table->signature, table->oem_table_id, owner_id,
+ info.object_count, info.device_count,
+ info.op_region_count, info.method_count,
+ info.serial_method_count,
info.non_serial_method_count,
info.serialized_method_count));
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 96b82a8..55ee14c 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -105,6 +105,7 @@ acpi_status acpi_tb_load_namespace(void)
acpi_status status;
u32 i;
struct acpi_table_header *new_dsdt;
+ struct acpi_table_desc *table;
u32 tables_loaded = 0;
u32 tables_failed = 0;
@@ -116,15 +117,11 @@ acpi_status acpi_tb_load_namespace(void)
* Load the namespace. The DSDT is required, but any SSDT and
* PSDT tables are optional. Verify the DSDT.
*/
+ table = &acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index];
+
if (!acpi_gbl_root_table_list.current_table_count ||
- !ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index].signature),
- ACPI_SIG_DSDT)
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(&acpi_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index]))) {
+ !ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_DSDT) ||
+ ACPI_FAILURE(acpi_tb_validate_table(table))) {
status = AE_NO_ACPI_TABLES;
goto unlock_and_exit;
}
@@ -135,8 +132,7 @@ acpi_status acpi_tb_load_namespace(void)
* array can change dynamically as tables are loaded at run-time. Note:
* .Pointer field is not validated until after call to
acpi_tb_validate_table.
*/
- acpi_gbl_DSDT =
- acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index].pointer;
+ acpi_gbl_DSDT = table->pointer;
/*
* Optionally copy the entire DSDT to local memory (instead of simply
@@ -174,21 +170,15 @@ acpi_status acpi_tb_load_namespace(void)
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
+ table = &acpi_gbl_root_table_list.tables[i];
+
if (!acpi_gbl_root_table_list.tables[i].address ||
- (!ACPI_COMPARE_NAME
-(&(acpi_gbl_root_table_list.tables[i].signature),
- ACPI_SIG_SSDT)
-&&
-!ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_PSDT)
-&&
-!ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_OSDT))
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(&acpi_gbl_root_table_list.tables[i]))) {
+ (!ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_SSDT)
+&& !ACPI_COMPARE_NAME(table->signature.ascii,
+ ACPI_SIG_PSDT)
+&& !ACPI_COMPARE_NAME(table->signature.ascii,
+ ACPI_S
[PATCH 12/20] ACPICA: Add additional debug info/statements.
From: Bob Moore
ACPICA commit 74094ca9f51e2652a9b5f01722d8640a653cc75a
For _REG methods and module-level code blocks.
For acpiexec, add deletion of module-level blocks in case
of an early abort.
Link: https://github.com/acpica/acpica/commit/74094ca9
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |7 +++
drivers/acpi/acpica/evregion.c | 22 ++
drivers/acpi/acpica/nseval.c |3 ++-
drivers/acpi/acpica/nsutils.c | 17 +
drivers/acpi/acpica/psloop.c | 14 +-
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 92cbaee..acbf68b 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -406,6 +406,13 @@ struct acpi_simple_repair_info {
#define ACPI_NUM_RTYPES 5 /* Number of actual object
types */
+/* Info for running the _REG methods */
+
+struct acpi_reg_walk_info {
+ acpi_adr_space_type space_id;
+ u32 reg_run_count;
+};
+
/*
*
* Event typedefs and structs
diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index 2ba28a6..5ee79a1 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -626,9 +626,17 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_adr_space_type space_id)
{
acpi_status status;
+ struct acpi_reg_walk_info info;
ACPI_FUNCTION_TRACE(ev_execute_reg_methods);
+ info.space_id = space_id;
+ info.reg_run_count = 0;
+
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ "Running _REG methods for SpaceId %s\n",
+ acpi_ut_get_region_name(info.space_id)));
+
/*
* Run all _REG methods for all Operation Regions for this space ID.
This
* is a separate walk in order to handle any interdependencies between
@@ -637,7 +645,7 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
*/
status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, node, ACPI_UINT32_MAX,
ACPI_NS_WALK_UNLOCK, acpi_ev_reg_run,
- NULL, &space_id, NULL);
+ NULL, &info, NULL);
/* Special case for EC: handle "orphan" _REG methods with no region */
@@ -645,6 +653,11 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_ev_orphan_ec_reg_method(node);
}
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ "Executed %u _REG methods for SpaceId %s\n",
+ info.reg_run_count,
+ acpi_ut_get_region_name(info.space_id)));
+
return_ACPI_STATUS(status);
}
@@ -664,10 +677,10 @@ acpi_ev_reg_run(acpi_handle obj_handle,
{
union acpi_operand_object *obj_desc;
struct acpi_namespace_node *node;
- acpi_adr_space_type space_id;
acpi_status status;
+ struct acpi_reg_walk_info *info;
- space_id = *ACPI_CAST_PTR(acpi_adr_space_type, context);
+ info = ACPI_CAST_PTR(struct acpi_reg_walk_info, context);
/* Convert and validate the device handle */
@@ -696,13 +709,14 @@ acpi_ev_reg_run(acpi_handle obj_handle,
/* Object is a Region */
- if (obj_desc->region.space_id != space_id) {
+ if (obj_desc->region.space_id != info->space_id) {
/* This region is for a different address space, just ignore it
*/
return (AE_OK);
}
+ info->reg_run_count++;
status = acpi_ev_execute_reg_method(obj_desc, ACPI_REG_CONNECT);
return (status);
}
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 88822b7a..7eba578 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -465,7 +465,8 @@ acpi_ns_exec_module_code(union acpi_operand_object
*method_obj,
status = acpi_ns_evaluate(info);
- ACPI_DEBUG_PRINT((ACPI_DB_INIT, "Executed module-level code at %p\n",
+ ACPI_DEBUG_PRINT((ACPI_DB_INIT_NAMES,
+ "Executed module-level code at %p\n",
method_obj->method.aml_start));
/* Delete a possible implicit return value (in slack mode) */
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 9a34c5f..d1261fe 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -596,6 +596,23 @@ void acpi_ns_terminate(void)
ACPI_FUNCTION_TRACE(ns_terminate);
+#ifdef ACPI_EXEC_APP
+ {
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
+
+ /* Delete any module-level code blocks */
+
+
[PATCH 10/20] ACPICA: acpiexec/acpinames: Support very large number of ACPI tables.
From: Bob Moore
ACPICA commit ca3bd4c5cdc39a9009280032adbbc20f34e94c47
Fix a couple of issues with >40 ACPI tables.
Return exit error for acpinames to enable use with BIOS builds.
The new exported function is used by acpinames. For Linux kernel, this
change is a no-op.
Link: https://github.com/acpica/acpica/commit/ca3bd4c5
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/actables.h |5 +
drivers/acpi/acpica/tbxfload.c | 17 -
drivers/acpi/acpica/utfileio.c |2 +-
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index ab7f3a0..f7731f2 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -165,4 +165,9 @@ acpi_status acpi_tb_parse_root_table(acpi_physical_address
rsdp_address);
u8 acpi_is_valid_signature(char *signature);
+/*
+ * tbxfload
+ */
+acpi_status acpi_tb_load_namespace(void);
+
#endif /* __ACTABLES_H__ */
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index fb4d4e6..96b82a8 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -51,9 +51,6 @@
#define _COMPONENT ACPI_TABLES
ACPI_MODULE_NAME("tbxfload")
-/* Local prototypes */
-static acpi_status acpi_tb_load_namespace(void);
-
/***
*
* FUNCTION:acpi_load_tables
@@ -65,7 +62,6 @@ static acpi_status acpi_tb_load_namespace(void);
* DESCRIPTION: Load the ACPI tables from the RSDT/XSDT
*
**/
-
acpi_status __init acpi_load_tables(void)
{
acpi_status status;
@@ -75,6 +71,13 @@ acpi_status __init acpi_load_tables(void)
/* Load the namespace from the tables */
status = acpi_tb_load_namespace();
+
+ /* Don't let single failures abort the load */
+
+ if (status == AE_CTRL_TERMINATE) {
+ status = AE_OK;
+ }
+
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"While loading namespace from ACPI tables"));
@@ -97,7 +100,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_load_tables)
* the RSDT/XSDT.
*
**/
-static acpi_status acpi_tb_load_namespace(void)
+acpi_status acpi_tb_load_namespace(void)
{
acpi_status status;
u32 i;
@@ -214,6 +217,10 @@ static acpi_status acpi_tb_load_namespace(void)
ACPI_ERROR((AE_INFO,
"%u ACPI AML tables successfully acquired and
loaded, %u failed",
tables_loaded, tables_failed));
+
+ /* Indicate at least one failure */
+
+ status = AE_CTRL_TERMINATE;
}
unlock_and_exit:
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index 857af82..75a94f5 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -312,7 +312,7 @@ acpi_ut_read_table_from_file(char *filename, struct
acpi_table_header ** table)
/* Get the entire file */
fprintf(stderr,
- "Reading ACPI table from file %10s - Length %.8u (0x%06X)\n",
+ "Reading ACPI table from file %12s - Length %.8u (0x%06X)\n",
filename, file_size, file_size);
status = acpi_ut_read_table(file, table, &table_length);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/20] ACPICA: Debugger: Add option to display namespace summary/counts.
From: Bob Moore
ACPICA commit bba222c15c2ce79076eb3a5e9d4d5f7120db8a00
If "Objects" command is invoked with no arguments, the counts
for each object type are displayed.
Linux kernel is not affected by this commit as currently debugger is
not enabled in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/bba222c1
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |4 ++--
drivers/acpi/acpica/aclocal.h |4
include/acpi/actypes.h |2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 95ed861..c597192 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -346,8 +346,8 @@ ACPI_GLOBAL(char,
acpi_gbl_db_debug_filename[ACPI_DB_LINE_BUFFER_SIZE]);
/*
* Statistic globals
*/
-ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
-ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
+ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TOTAL_TYPES]);
+ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TOTAL_TYPES]);
ACPI_GLOBAL(u16, acpi_gbl_obj_type_count_misc);
ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc);
ACPI_GLOBAL(u32, acpi_gbl_num_nodes);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index acbf68b..6f70826 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -1131,6 +1131,10 @@ struct acpi_integrity_info {
#define ACPI_DB_CONSOLE_OUTPUT 0x02
#define ACPI_DB_DUPLICATE_OUTPUT0x03
+struct acpi_object_info {
+ u32 types[ACPI_TOTAL_TYPES];
+};
+
/*
*
* Debug
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 531eca4..f914958 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -662,6 +662,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_DEBUG_OBJECT 0x10
#define ACPI_TYPE_EXTERNAL_MAX 0x10
+#define ACPI_NUM_TYPES (ACPI_TYPE_EXTERNAL_MAX + 1)
/*
* These are object types that do not map directly to the ACPI
@@ -683,6 +684,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_LOCAL_SCOPE 0x1B /* 1 Name, multiple object_list
Nodes */
#define ACPI_TYPE_NS_NODE_MAX 0x1B /* Last typecode used within a
NS Node */
+#define ACPI_TOTAL_TYPES(ACPI_TYPE_NS_NODE_MAX + 1)
/*
* These are special object types that never appear in
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/20] ACPICA: Headers: Fix some comments, no functional change.
From: Bob Moore ACPICA commit 539f8c03fe64305725bd85343e42f3b6c42aad14 A couple typos and long lines. Link: https://github.com/acpica/acpica/commit/539f8c03 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/platform/acenv.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h index 3cedd43..1332537 100644 --- a/include/acpi/platform/acenv.h +++ b/include/acpi/platform/acenv.h @@ -89,8 +89,8 @@ #endif /* - * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example configuration. - * All single threaded. + * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example + * configuration. All single threaded. */ #if (defined ACPI_BIN_APP) || \ (defined ACPI_DUMP_APP) || \ @@ -123,7 +123,7 @@ #define ACPI_USE_NATIVE_RSDP_POINTER #endif -/* acpi_dump configuration. Native mapping used if provied by OSPMs */ +/* acpi_dump configuration. Native mapping used if provided by the host */ #ifdef ACPI_DUMP_APP #define ACPI_USE_NATIVE_MEMORY_MAPPING @@ -323,8 +323,8 @@ * ACPI_USE_STANDARD_HEADERS - Define this if linking to a C library and * the standard header files may be used. * - * The ACPICA subsystem only uses low level C library functions that do not call - * operating system services and may therefore be inlined in the code. + * The ACPICA subsystem only uses low level C library functions that do not + * call operating system services and may therefore be inlined in the code. * * It may be necessary to tailor these include files to the target * generation environment. -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/20] ACPICA: acpinames: Add new options and wildcard support.
From: Bob Moore ACPICA commit 0ecf5b5a41c3d2e09af48f0fdbc9ae784f631788 - Add wilcard support for input filenames. - Add -l option to load tables and exit, no display. This is useful for validation of the namespace during BIOS generation. - Add -x option for specifying debug level. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/0ecf5b5a Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/utmisc.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h index 566ff4df..fb2aa50 100644 --- a/drivers/acpi/acpica/acutils.h +++ b/drivers/acpi/acpica/acutils.h @@ -517,7 +517,7 @@ const struct acpi_exception_info *acpi_ut_validate_exception(acpi_status u8 acpi_ut_is_pci_root_bridge(char *id); -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) u8 acpi_ut_is_aml_table(struct acpi_table_header *table); #endif diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c index 98087ea..517a5ec 100644 --- a/drivers/acpi/acpica/utmisc.c +++ b/drivers/acpi/acpica/utmisc.c @@ -75,7 +75,7 @@ u8 acpi_ut_is_pci_root_bridge(char *id) return (FALSE); } -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) /*** * * FUNCTION:acpi_ut_is_aml_table -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/20] ACPICA: Make the max-number-of-loops runtime configurable.
From: Bob Moore
ACPICA commit a9d9c2d0c2d077bb3175ec9c252cf0e5da3efd45
Was previously compile-time only.
Add support option for acpiexec.
Link: https://github.com/acpica/acpica/commit/a9d9c2d0
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |4
drivers/acpi/acpica/dscontrol.c |2 +-
drivers/acpi/acpica/utinit.c|1 +
include/acpi/acconfig.h |4
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index c597192..03c443b 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -236,6 +236,10 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_nesting_level, 0);
ACPI_GLOBAL(struct acpi_thread_state *, acpi_gbl_current_walk_list);
+/* Maximum number of While() loop iterations before forced abort */
+
+ACPI_GLOBAL(u16, acpi_gbl_max_loop_iterations);
+
/* Control method single step flag */
ACPI_GLOBAL(u8, acpi_gbl_cm_single_step);
diff --git a/drivers/acpi/acpica/dscontrol.c b/drivers/acpi/acpica/dscontrol.c
index 39da9da..435fc16 100644
--- a/drivers/acpi/acpica/dscontrol.c
+++ b/drivers/acpi/acpica/dscontrol.c
@@ -212,7 +212,7 @@ acpi_ds_exec_end_control_op(struct acpi_walk_state *
walk_state,
*/
control_state->control.loop_count++;
if (control_state->control.loop_count >
- ACPI_MAX_LOOP_ITERATIONS) {
+ acpi_gbl_max_loop_iterations) {
status = AE_AML_INFINITE_LOOP;
break;
}
diff --git a/drivers/acpi/acpica/utinit.c b/drivers/acpi/acpica/utinit.c
index 7f897c6..28ab3a1 100644
--- a/drivers/acpi/acpica/utinit.c
+++ b/drivers/acpi/acpica/utinit.c
@@ -207,6 +207,7 @@ acpi_status acpi_ut_init_globals(void)
acpi_gbl_debugger_configuration = DEBUGGER_THREADING;
acpi_gbl_osi_mutex = NULL;
acpi_gbl_reg_methods_executed = FALSE;
+ acpi_gbl_max_loop_iterations = 0x;
/* Hardware oriented */
diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index 03aacfb..e11611c 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -136,10 +136,6 @@
#define ACPI_ROOT_TABLE_SIZE_INCREMENT 4
-/* Maximum number of While() loop iterations before forced abort */
-
-#define ACPI_MAX_LOOP_ITERATIONS0x
-
/* Maximum sleep allowed via Sleep() operator */
#define ACPI_MAX_SLEEP 2000 /* 2000 millisec == two seconds
*/
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/20] ACPICA: Update version to 20150818.
From: Bob Moore ACPICA commit d93470de8febeecdc20633fde11cb0b200fa773b Version 20150818. Link: https://github.com/acpica/acpica/commit/d93470de Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index d3d7ea0..c33eeab 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150717 +#define ACPI_CA_VERSION 0x20150818 #include #include -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 17/20] ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm.
ACPICA commit 969989cf7f85e2a2a0cd048cd25fc706246a48a2 This patch cleans up the following global variable - acpi_gbl_db_opt_disasm: The setting is used to control the full disassembly feature for iasl. ACPI debugger (acpiexec) shall have nothing to do with it. Actually, acpiexec never links to ad_aml_disassemble(). This patch thus renames this global option to acpi_gbl_dm_opt_disasm and removes all acpiexec and debugger references on it. Lv Zheng. This patch doesn't affect Linux kernel. Link: https://github.com/acpica/acpica/commit/969989cf Signed-off-by: Lv Zheng Signed-off-by: Bob Moore --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 03c443b..0007eb7 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -313,7 +313,7 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_disasm); ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
