Re: [PATCH v6 0/4] add syscon driver based on regmap for general registers access
Hi Samuel, The series needs to go via mfd or arm-soc tree as a whole. In case you want to take it through mfd tree, here is my ack. Acked-by: Shawn Guo Otherwise, I can take it via arm-soc tree with your ack. Regards, Shawn On Wed, Sep 05, 2012 at 10:57:12AM +0800, Dong Aisheng wrote: > This patch series mainly adds an syscon driver which is used to access > general system controller registers like FSL IOMUXC GPR and ANATOP, > after that, we convert all the exist private access general registers code to > use > standard API from regmap to access registers. > Finally we remove the old mfd anatop driver which is only for anatop register > access. > > The patch series is based on linus's tree 3.6-rc4 since commit 5b716ac. > > ChangeLog v5->v6: > * put node after call syscon_node_to_regmap in anatop regulator driver > * using dev instead of >dev in syscon probe > ChangeLog v4->v5: > * change syscon driver depends on OF > * do not call of_node_put in syscon_node_to_regmap > * renamed: include/linux/fsl/imx6q-iomuxc-gpr.h -> > include/linux/mfd/syscon/imx6q-iomuxc-gpr.h > ChangeLog v3->v4: > Only '[PATCH v4 1/7] mfd: add syscon driver based on regmap' is changed. > > Dong Aisheng (4): > mfd: add syscon driver based on regmap > ARM: imx6q: add iomuxc gpr support into syscon > regulator: anatop-regulator: convert to use syscon to access anatop > register > mfd: anatop-mfd: remove anatop driver > > Documentation/devicetree/bindings/mfd/syscon.txt | 20 ++ > arch/arm/boot/dts/imx6q.dtsi |9 +- > arch/arm/mach-imx/Kconfig|2 +- > arch/arm/mach-imx/mach-imx6q.c | 47 ++-- > drivers/mfd/Kconfig | 12 +- > drivers/mfd/Makefile |2 +- > drivers/mfd/anatop-mfd.c | 124 - > drivers/mfd/syscon.c | 176 > drivers/regulator/Kconfig|2 +- > drivers/regulator/anatop-regulator.c | 31 ++- > include/linux/mfd/anatop.h | 40 --- > include/linux/mfd/syscon.h | 23 ++ > include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 319 > ++ > 13 files changed, 593 insertions(+), 214 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/syscon.txt > delete mode 100644 drivers/mfd/anatop-mfd.c > create mode 100644 drivers/mfd/syscon.c > delete mode 100644 include/linux/mfd/anatop.h > create mode 100644 include/linux/mfd/syscon.h > create mode 100644 include/linux/mfd/syscon/imx6q-iomuxc-gpr.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] virtio-blk: Fix kconfig option
On 09/05/2012 01:48 PM, Michael S. Tsirkin wrote: > On Wed, Sep 05, 2012 at 12:22:58PM +0800, Asias He wrote: >> On 09/04/2012 02:23 PM, Rusty Russell wrote: >>> Kent Overstreet writes: >>> CONFIG_VIRTIO isn't exposed, everything else is supposed to select it instead. >>> >>> This is a slight mis-understanding. It's supposed to be selected by >>> the particular driver, probably virtio_pci in your case. >> >> virtio_mmio selects virtio as well. >> >> drivers/virtio/Kconfig >> config VIRTIO_MMIO >>select VIRTIO >> config VIRTIO_PCI >>select VIRTIO >> >> How about this: >> config VIRTIO_BLK >>depends on EXPERIMENTAL && (VIRTIO_PCI || VIRTIO_MMIO) > > Isn't this exactly what depends on VIRTIO achieves? Yes. But this gives the information that virtio_blk depends on one of the virtio transport: virito_pci or virtio_mmio. -- Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: A workaround for request_firmware() stuck in module_init
At Wed, 5 Sep 2012 09:15:34 +0800, Ming Lei wrote: > > On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote: > > At Tue, 4 Sep 2012 23:52:15 +0800, > > Ming Lei wrote: > >> > >> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote: > >> > Hi, > >> > > >> > as I've got recently a few bug reports regarding the stuck with > >> > request_firmware() in module_init of some sound drivers, I started > >> > looking at the issue. Strangely, the problem doesn't happen on > >> > openSUSE 12.2 although it has the same udev version with libkmod as > >> > Fedora. So I installed Fedora 17, and indeed I could see a problem > >> > there. > >> > >> It should be a bug in udev, as discussed in the below link: > >> > >> http://marc.info/?t=13455274512=1=2 > > > > Yeah, if udev has a fix, I'm fine. I'll proactively ignore these bug > > reports. But did it really happen...? > > Linus has expressed that it should be fixed by udev, maybe we can > wait some time to see if it will happen, :-) Kay, what is the status? > There are more than 300 request_firmware called in probe(), even > adding 2 line code in these drivers will involve much workload, since > you need to find the matched probe() for one request_firmware and > sometimes it is not easy. Well, this depends on from which perspective you look at the issue. See below. > >> > Obviously a solution would be to rewrite the driver code to use > >> > request_firmware_nowait() instead. But it'd need a lot of code > >> > shuffling, and most of such drivers are old stuff I don't want to do a > >> > serious surgery. > >> > > >> > So I tried an easier workaround by using the deferred probing. > >> > An experimental patch is below. As you can see, from the driver side, > >> > it's simple: just add two lines at the head of each probe function. > >> > >> In fact, the defer probe should only be applied in situations which > >> driver is built in kernel and request_firmware is called in .probe(). > > > > Is it? I thought the deferred probe is basically not for this problem > > but rather for the dependency problem with other modules. That's the > > reason it's triggered only upon the successful binding. > > Sorry, could you explain the dependency in a bit detail? When a device has some implicit dependency on another hardware component (e.g. SDHCI depends on I2C GPIO controller, as in comment in drivers/base/dd.c), the driver needs to wait until another one gets ready. -EPROBE_DEFER was introduced for such a purpose. So, using this mechanism for the firmware issue is a kind of abuse. > >From your patch, I understand you just convert the caller of > request_firmware from module_init into deferred_probe_work_func(), > so the udev problem is avoided, isn't it? Yes, that was a hack. The idea is just offloading the probe, and the deferred probe is an existing simple way for that. > Looks making all .probe() run non-module_init context is still a solution, :-) Sounds interesting. > > And IMO, the deferred probe for the built-in kernel is also silly. > > Did anyone really make it working for built-in kernel driver and > > external firmware files? (For the resume, it's of course a different > > Yes, my original patch does work for the built-in situations. > > > issue. And I guess it's been solved by your fw cache patch, right?) > > > >> > Do you think this kind of hack is OK? If not, any better (IOW easier) > >> > solution? > >> > >> Looks your solution is a bit complicated, and I have wrote a similar > >> patch to address the problem, but Linus thought that it may hide the > >> problem of drivers. > >> > >> http://marc.info/?t=13427879084=1=2 > >> > >> IMO, driver core needn't to be changed, and the defer probe can be > >> supported just by changes in request_firmware() and its caller. > > > > Ideally, yes. But it won't work in some drivers like sound drivers, > > that have its own device number counting changed at each probe call. > > For such drivers, the deferred probe check must be done before > > entering the normal probe procedure, and returning -EPROBE_DEFER would > > be too late (or need more complex fallbacks). > > Simply, you can put the firmware loading at the start of probe to > avoid the specific > sound problem, :-) Well, I can't buy it. Changing the call order can be often more problematic. Anyway... IMO, the primary question is whether we still regard the request_firmware() call in module_init as a driver bug. Or, looking at the usage numbers, we should accept it as a de facto standard use case? If we still see it as a bug, the only right way is to fix the drivers, not the core. That's why I suggested to put some fix to each driver. In that way, it shows obvious that the driver is a kind of buggy but fixed in a very lazy way (the function name should have been more obvious one like i_may_call_request_firmware_so_call_me_later()). The difference is that this fixes the bug, not hiding the problem. OTOH, if we see it no
Re: [PATCH 1/1] Input: joydev - fix axes values sent in initial js_event
Hi Vojtech,
On Tue, Aug 14, 2012 at 12:11:54AM +0200, Vojtech Bocek wrote:
> Initial input event has not yet arrived in joydev_connect()
> where values are set, which means default values of input_absinfo
> are used for init event, not the actual values from joystick.
So what guarantees that joystick events will arrive in time, before
joydev_generate_startup_event() is called? It looks like your solution
is racy...
I wonder if we should not generate the startup event until we have seen
at least one EV_SYN, i.e. entire device state has been transmitted to
us.
>
> Signed-off-by: Vojtech Bocek
> ---
> drivers/input/joydev.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c
> index 26043cc..11f24b4 100644
> --- a/drivers/input/joydev.c
> +++ b/drivers/input/joydev.c
> @@ -318,9 +318,14 @@ static int joydev_generate_startup_event(struct
> joydev_client *client,
> event->value = !!test_bit(joydev->keypam[event->number],
> input->key);
> } else {
> + int evnum = client->startup - joydev->nkey;
> + int val = input_abs_get_val(input,
> joydev->abspam[evnum]);
> +
> + joydev->abs[evnum] = joydev_correct(val,
> >corr[evnum]);
> +
> event->type = JS_EVENT_AXIS | JS_EVENT_INIT;
> - event->number = client->startup - joydev->nkey;
> - event->value = joydev->abs[event->number];
> + event->number = evnum;
> + event->value = joydev->abs[evnum];
> }
> client->startup++;
> }
> --
> 1.7.10.4
>
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 05/14] x86, mm: Find early page table only one time
Should not do that in every calling of init_memory_mapping.
Actually in early time, only need do once.
Also move down early_memtest.
-v2: fix one early_memtest with 32bit by passing max_pfn_mapped instead.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c | 72 ++-
1 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index cca9b7d..0ada295 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -37,7 +37,7 @@ struct map_range {
static int page_size_mask;
-static void __init find_early_table_space(struct map_range *mr,
+static void __init find_early_table_space(unsigned long begin,
unsigned long end)
{
unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
@@ -64,8 +64,8 @@ static void __init find_early_table_space(struct map_range
*mr,
extra += PMD_SIZE;
#endif
/* The first 2/4M doesn't use large pages. */
- if (mr->start < PMD_SIZE)
- extra += mr->end - mr->start;
+ if (begin < PMD_SIZE)
+ extra += (PMD_SIZE - begin) >> PAGE_SHIFT;
ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
} else
@@ -265,16 +265,6 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
nr_range = 0;
nr_range = split_mem_range(mr, nr_range, start, end);
- /*
-* Find space for the kernel direct mapping tables.
-*
-* Later we should allocate these tables in the local node of the
-* memory mapped. Unfortunately this is done currently before the
-* nodes are discovered.
-*/
- if (!after_bootmem)
- find_early_table_space([0], end);
-
for (i = 0; i < nr_range; i++)
ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
mr[i].page_size_mask);
@@ -287,6 +277,36 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
__flush_tlb_all();
+ return ret >> PAGE_SHIFT;
+}
+
+void __init init_mem_mapping(void)
+{
+ probe_page_size_mask();
+
+ /*
+* Find space for the kernel direct mapping tables.
+*
+* Later we should allocate these tables in the local node of the
+* memory mapped. Unfortunately this is done currently before the
+* nodes are discovered.
+*/
+#ifdef CONFIG_X86_64
+ find_early_table_space(0, max_pfn< max_low_pfn) {
+ max_pfn_mapped = init_memory_mapping(1UL<<32,
+max_pfn< pgt_buf_start)
+ if (pgt_buf_end > pgt_buf_start)
x86_init.mapping.pagetable_reserve(PFN_PHYS(pgt_buf_start),
PFN_PHYS(pgt_buf_end));
- if (!after_bootmem)
- early_memtest(start, end);
+ /* stop the wrong using */
+ pgt_buf_top = 0;
- return ret >> PAGE_SHIFT;
-}
-
-void __init init_mem_mapping(void)
-{
- probe_page_size_mask();
-
- /* max_pfn_mapped is updated here */
- max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< max_low_pfn) {
- max_pfn_mapped = init_memory_mapping(1UL<<32,
-max_pfn
Re: [PATCH] virtio-blk: Fix kconfig option
On Wed, Sep 05, 2012 at 12:22:58PM +0800, Asias He wrote: > On 09/04/2012 02:23 PM, Rusty Russell wrote: > > Kent Overstreet writes: > > > >> CONFIG_VIRTIO isn't exposed, everything else is supposed to select it > >> instead. > > > > This is a slight mis-understanding. It's supposed to be selected by > > the particular driver, probably virtio_pci in your case. > > virtio_mmio selects virtio as well. > > drivers/virtio/Kconfig > config VIRTIO_MMIO >select VIRTIO > config VIRTIO_PCI >select VIRTIO > > How about this: > config VIRTIO_BLK >depends on EXPERIMENTAL && (VIRTIO_PCI || VIRTIO_MMIO) Isn't this exactly what depends on VIRTIO achieves? > -- > Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 06/14] x86, mm: Separate out calculate_table_space_size()
it should take physical address range that will need to be mapped.
and find_early_table_space should take range that pgt buff should be in.
Separate those two to reduce confusion.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 39 ---
1 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 0ada295..fcb44c5 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -37,11 +37,10 @@ struct map_range {
static int page_size_mask;
-static void __init find_early_table_space(unsigned long begin,
+static unsigned long __init calculate_table_space_size(unsigned long begin,
unsigned long end)
{
- unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
- phys_addr_t base;
+ unsigned long puds, pmds, ptes, tables;
puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
@@ -76,9 +75,17 @@ static void __init find_early_table_space(unsigned long
begin,
#ifdef CONFIG_X86_32
/* for fixmap */
tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
- good_end = max_pfn_mapped << PAGE_SHIFT;
#endif
+ return tables;
+}
+
+static void __init find_early_table_space(unsigned long start,
+ unsigned long good_end,
+ unsigned long tables)
+{
+ phys_addr_t base;
+
base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
if (!base)
panic("Cannot find space for the kernel page tables");
@@ -86,10 +93,6 @@ static void __init find_early_table_space(unsigned long
begin,
pgt_buf_start = base >> PAGE_SHIFT;
pgt_buf_end = pgt_buf_start;
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
-
- printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @ [mem
%#010lx-%#010lx]\n",
- end - 1, pgt_buf_start << PAGE_SHIFT,
- (pgt_buf_top << PAGE_SHIFT) - 1);
}
static void __init probe_page_size_mask(void)
@@ -282,6 +285,8 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
void __init init_mem_mapping(void)
{
+ unsigned long tables, good_end, end;
+
probe_page_size_mask();
/*
@@ -292,10 +297,18 @@ void __init init_mem_mapping(void)
* nodes are discovered.
*/
#ifdef CONFIG_X86_64
- find_early_table_space(0, max_pfn< pgt_buf_start)
+ if (pgt_buf_end > pgt_buf_start) {
+ printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @
[mem %#010lx-%#010lx] final\n",
+ end - 1, pgt_buf_start << PAGE_SHIFT,
+ (pgt_buf_end << PAGE_SHIFT) - 1);
x86_init.mapping.pagetable_reserve(PFN_PHYS(pgt_buf_start),
PFN_PHYS(pgt_buf_end));
+ }
/* stop the wrong using */
pgt_buf_top = 0;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 07/14] x86, mm: Move down two calculate_table_space_size down.
So later could make it call split_mem_range...
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 116 ++--
1 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index fcb44c5..a475d7f 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -37,64 +37,6 @@ struct map_range {
static int page_size_mask;
-static unsigned long __init calculate_table_space_size(unsigned long begin,
- unsigned long end)
-{
- unsigned long puds, pmds, ptes, tables;
-
- puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
- tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
-
- if (page_size_mask & (1 << PG_LEVEL_1G)) {
- unsigned long extra;
-
- extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
- pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
- } else
- pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
-
- tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
-
- if (page_size_mask & (1 << PG_LEVEL_2M)) {
- unsigned long extra;
-
- extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
-#ifdef CONFIG_X86_32
- extra += PMD_SIZE;
-#endif
- /* The first 2/4M doesn't use large pages. */
- if (begin < PMD_SIZE)
- extra += (PMD_SIZE - begin) >> PAGE_SHIFT;
-
- ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
- } else
- ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
-
- tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
-
-#ifdef CONFIG_X86_32
- /* for fixmap */
- tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
-#endif
-
- return tables;
-}
-
-static void __init find_early_table_space(unsigned long start,
- unsigned long good_end,
- unsigned long tables)
-{
- phys_addr_t base;
-
- base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
- if (!base)
- panic("Cannot find space for the kernel page tables");
-
- pgt_buf_start = base >> PAGE_SHIFT;
- pgt_buf_end = pgt_buf_start;
- pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
-}
-
static void __init probe_page_size_mask(void)
{
#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
@@ -249,6 +191,64 @@ static int __meminit split_mem_range(struct map_range *mr,
int nr_range,
return nr_range;
}
+static unsigned long __init calculate_table_space_size(unsigned long begin,
+ unsigned long end)
+{
+ unsigned long puds, pmds, ptes, tables;
+
+ puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
+ tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+
+ if (page_size_mask & (1 << PG_LEVEL_1G)) {
+ unsigned long extra;
+
+ extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
+ pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
+ } else
+ pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+
+ tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
+
+ if (page_size_mask & (1 << PG_LEVEL_2M)) {
+ unsigned long extra;
+
+ extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
+#ifdef CONFIG_X86_32
+ extra += PMD_SIZE;
+#endif
+ /* The first 2/4M doesn't use large pages. */
+ if (begin < PMD_SIZE)
+ extra += (PMD_SIZE - begin) >> PAGE_SHIFT;
+
+ ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ } else
+ ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+
+ tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
+
+#ifdef CONFIG_X86_32
+ /* for fixmap */
+ tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
+#endif
+
+ return tables;
+}
+
+static void __init find_early_table_space(unsigned long start,
+ unsigned long good_end,
+ unsigned long tables)
+{
+ phys_addr_t base;
+
+ base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
+ if (!base)
+ panic("Cannot find space for the kernel page tables");
+
+ pgt_buf_start = base >> PAGE_SHIFT;
+ pgt_buf_end = pgt_buf_start;
+ pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
+}
+
/*
* Setup the direct mapping of the physical memory at PAGE_OFFSET.
* This runs before bootmem is initialized and gets pages directly from
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 08/14] x86, mm: set memblock initial limit to 1M
memblock_x86_fill() could double memory array. and we set max_pfn_mapped to 512M, so memory array could be around 512M. So kdump will not get big range (like 512M) under 1024M. Try to put it down under 1M, it could use about 4k or so. Also we need this one when we try to only map ram range only later. if the early double the range near 512M, and later init_mem_mapping() first several range could under 512M, then after mapping get reset, we will lose access the memblock memory array. but we are using memblock memory array for iteration. Signed-off-by: Yinghai Lu --- arch/x86/kernel/setup.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index c30c78c..68d1b2c 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -889,7 +889,7 @@ void __init setup_arch(char **cmdline_p) cleanup_highmap(); - memblock.current_limit = get_max_mapped(); + memblock.current_limit = ISA_END_ADDRESS; memblock_x86_fill(); /* -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 02/14] x86, mm: Split out split_mem_range
from init_memory_mapping, so make init_memory_mapping readable.
Suggested-by: Ingo Molnar
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 42 ++
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 838e9bc..7d05e28 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -143,25 +143,13 @@ static int __meminit save_mr(struct map_range *mr, int
nr_range,
return nr_range;
}
-/*
- * Setup the direct mapping of the physical memory at PAGE_OFFSET.
- * This runs before bootmem is initialized and gets pages directly from
- * the physical memory. To access them they are temporarily mapped.
- */
-unsigned long __init_refok init_memory_mapping(unsigned long start,
- unsigned long end)
+static int __meminit split_mem_range(struct map_range *mr, int nr_range,
+unsigned long start,
+unsigned long end)
{
unsigned long start_pfn, end_pfn;
- unsigned long ret = 0;
unsigned long pos;
- struct map_range mr[NR_RANGE_MR];
- int nr_range, i;
-
- printk(KERN_INFO "init_memory_mapping: [mem %#010lx-%#010lx]\n",
- start, end - 1);
-
- memset(mr, 0, sizeof(mr));
- nr_range = 0;
+ int i;
/* head if not big page alignment ? */
start_pfn = start >> PAGE_SHIFT;
@@ -255,6 +243,28 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
(mr[i].page_size_mask & (1
[PATCH -v3 01/14] x86, mm: Add global page_size_mask
detect if need to use 1G or 2M and store them in page_size_mask.
Only probe them one time.
Suggested-by: Ingo Molnar
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/include/asm/pgtable.h |1 +
arch/x86/kernel/setup.c|1 +
arch/x86/mm/init.c | 66 +++-
3 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..e47e4db 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -597,6 +597,7 @@ static inline int pgd_none(pgd_t pgd)
#ifndef __ASSEMBLY__
extern int direct_gbpages;
+void probe_page_size_mask(void);
/* local pte updates need not use xchg for locking */
static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..d6e8c03 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -912,6 +912,7 @@ void __init setup_arch(char **cmdline_p)
setup_real_mode();
init_gbpages();
+ probe_page_size_mask();
/* max_pfn_mapped is updated here */
max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<> PUD_SHIFT;
tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
- if (use_gbpages) {
+ if (page_size_mask & (1 << PG_LEVEL_1G)) {
unsigned long extra;
extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
@@ -54,7 +56,7 @@ static void __init find_early_table_space(struct map_range
*mr, unsigned long en
tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
- if (use_pse) {
+ if (page_size_mask & (1 << PG_LEVEL_2M)) {
unsigned long extra;
extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
@@ -90,6 +92,30 @@ static void __init find_early_table_space(struct map_range
*mr, unsigned long en
(pgt_buf_top << PAGE_SHIFT) - 1);
}
+void probe_page_size_mask(void)
+{
+#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
+ /*
+* For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
+* This will simplify cpa(), which otherwise needs to support splitting
+* large pages into small in interrupt context, etc.
+*/
+ if (direct_gbpages)
+ page_size_mask |= 1 << PG_LEVEL_1G;
+ if (cpu_has_pse)
+ page_size_mask |= 1 << PG_LEVEL_2M;
+#endif
+
+ /* Enable PSE if available */
+ if (cpu_has_pse)
+ set_in_cr4(X86_CR4_PSE);
+
+ /* Enable PGE if available */
+ if (cpu_has_pge) {
+ set_in_cr4(X86_CR4_PGE);
+ __supported_pte_mask |= _PAGE_GLOBAL;
+ }
+}
void __init native_pagetable_reserve(u64 start, u64 end)
{
memblock_reserve(start, end - start);
@@ -125,45 +151,15 @@ static int __meminit save_mr(struct map_range *mr, int
nr_range,
unsigned long __init_refok init_memory_mapping(unsigned long start,
unsigned long end)
{
- unsigned long page_size_mask = 0;
unsigned long start_pfn, end_pfn;
unsigned long ret = 0;
unsigned long pos;
-
struct map_range mr[NR_RANGE_MR];
int nr_range, i;
- int use_pse, use_gbpages;
printk(KERN_INFO "init_memory_mapping: [mem %#010lx-%#010lx]\n",
start, end - 1);
-#if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KMEMCHECK)
- /*
-* For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
-* This will simplify cpa(), which otherwise needs to support splitting
-* large pages into small in interrupt context, etc.
-*/
- use_pse = use_gbpages = 0;
-#else
- use_pse = cpu_has_pse;
- use_gbpages = direct_gbpages;
-#endif
-
- /* Enable PSE if available */
- if (cpu_has_pse)
- set_in_cr4(X86_CR4_PSE);
-
- /* Enable PGE if available */
- if (cpu_has_pge) {
- set_in_cr4(X86_CR4_PGE);
- __supported_pte_mask |= _PAGE_GLOBAL;
- }
-
- if (use_gbpages)
- page_size_mask |= 1 << PG_LEVEL_1G;
- if (use_pse)
- page_size_mask |= 1 << PG_LEVEL_2M;
-
memset(mr, 0, sizeof(mr));
nr_range = 0;
@@ -267,7 +263,7 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
* nodes are discovered.
*/
if (!after_bootmem)
- find_early_table_space([0], end, use_pse, use_gbpages);
+ find_early_table_space([0], end);
for (i = 0; i < nr_range; i++)
ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH -v3 00/14] x86, mm: init_memory_mapping cleanup
Only create mapping for E820_820 and E820_RESERVED_KERN. Seperate calculate_table_space_size and find_early_page_table out with init_memory_mapping. For all ranges, will allocate page table one time, but init mapping only for E820 RAM and E820_RESERVED_KERN. Could be found at: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-mm Thanks Yinghai Jacob Shin (4): x86: if kernel .text .data .bss are not marked as E820_RAM, complain and fix x86: Fixup code testing if a pfn is direct mapped x86: Only direct map addresses that are marked as E820_RAM x86/mm: calculate_table_space_size based on memory ranges that are being mapped Yinghai Lu (10): x86, mm: Add global page_size_mask x86, mm: Split out split_mem_range x86, mm: Moving init_memory_mapping calling x86, mm: Revert back good_end setting for 64bit x86, mm: Find early page table only one time x86, mm: Separate out calculate_table_space_size() x86, mm: Move down two calculate_table_space_size down. x86, mm: set memblock initial limit to 1M x86, mm: Use func pointer to table size calculation and mapping x86, mm: Map ISA area with connected ram range at the same time arch/x86/include/asm/init.h |1 - arch/x86/include/asm/page_types.h |2 + arch/x86/include/asm/pgtable.h|1 + arch/x86/kernel/cpu/amd.c |8 +- arch/x86/kernel/setup.c | 36 +++-- arch/x86/mm/init.c| 357 + arch/x86/mm/init_64.c |6 +- arch/x86/platform/efi/efi.c |8 +- 8 files changed, 280 insertions(+), 139 deletions(-) -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 10/14] x86: Fixup code testing if a pfn is direct mapped
From: Jacob Shin
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
-v2: change applying sequence to keep git bisecting working.
so add dummy pfn_range_is_mapped(). - Yinghai Lu
Signed-off-by: Jacob Shin
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page_types.h |8
arch/x86/kernel/cpu/amd.c |8 +++-
arch/x86/platform/efi/efi.c |8
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h
b/arch/x86/include/asm/page_types.h
index e21fdd1..45aae6e 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -51,6 +51,14 @@ static inline phys_addr_t get_max_mapped(void)
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
}
+static inline bool pfn_range_is_mapped(unsigned long start_pfn,
+ unsigned long end_pfn)
+{
+ return end_pfn <= max_low_pfn_mapped ||
+ (end_pfn > (1UL << (32 - PAGE_SHIFT)) &&
+ end_pfn <= max_pfn_mapped);
+}
+
extern unsigned long init_memory_mapping(unsigned long start,
unsigned long end);
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9d92e19..4235553 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -676,12 +676,10 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
* benefit in doing so.
*/
if (!rdmsrl_safe(MSR_K8_TSEG_ADDR, )) {
+ unsigned long pfn = tseg >> PAGE_SHIFT;
+
printk(KERN_DEBUG "tseg: %010llx\n", tseg);
- if ((tseg>>PMD_SHIFT) <
- (max_low_pfn_mapped>>(PMD_SHIFT-PAGE_SHIFT)) ||
- ((tseg>>PMD_SHIFT) <
- (max_pfn_mapped>>(PMD_SHIFT-PAGE_SHIFT)) &&
- (tseg>>PMD_SHIFT) >= (1ULL<<(32 - PMD_SHIFT
+ if (pfn_range_is_mapped(pfn, pfn + 1))
set_memory_4k((unsigned long)__va(tseg), 1);
}
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 92660eda..f1facde 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -776,7 +776,7 @@ void __init efi_enter_virtual_mode(void)
efi_memory_desc_t *md, *prev_md = NULL;
efi_status_t status;
unsigned long size;
- u64 end, systab, addr, npages, end_pfn;
+ u64 end, systab, addr, npages, start_pfn, end_pfn;
void *p, *va, *new_memmap = NULL;
int count = 0;
@@ -827,10 +827,10 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
+ start_pfn = PFN_DOWN(md->phys_addr);
end_pfn = PFN_UP(end);
- if (end_pfn <= max_low_pfn_mapped
- || (end_pfn > (1UL << (32 - PAGE_SHIFT))
- && end_pfn <= max_pfn_mapped))
+
+ if (pfn_range_is_mapped(start_pfn, end_pfn))
va = __va(md->phys_addr);
else
va = efi_ioremap(md->phys_addr, size, md->type);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 09/14] x86: if kernel .text .data .bss are not marked as E820_RAM, complain and fix
From: Jacob Shin
There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM, as reported here:
https://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
Signed-off-by: Jacob Shin
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/kernel/setup.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 68d1b2c..de72acc 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -831,6 +831,20 @@ void __init setup_arch(char **cmdline_p)
insert_resource(_resource, _resource);
insert_resource(_resource, _resource);
+ /*
+* Complain if .text .data and .bss are not marked as E820_RAM and
+* attempt to fix it by adding the range. We may have a confused BIOS,
+* or the user may have incorrectly supplied it via memmap=exactmap. If
+* we really are running on top non-RAM, we will crash later anyways.
+*/
+ if (!e820_all_mapped(code_resource.start, __pa(__brk_limit), E820_RAM))
{
+ pr_warn(".text .data .bss are not marked as E820_RAM!\n");
+
+ e820_add_region(code_resource.start,
+ __pa(__brk_limit) - code_resource.start + 1,
+ E820_RAM);
+ }
+
trim_bios_range();
#ifdef CONFIG_X86_32
if (ppro_with_ram_bug()) {
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (staging tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/staging/ipack/ipack.c: In function 'ipack_device_read_id':
drivers/staging/ipack/ipack.c:291:2: error: implicit declaration of function
'ioread8' [-Werror=implicit-function-declaration]
drivers/staging/ipack/ipack.c:309:3: error: implicit declaration of function
'ioread16be' [-Werror=implicit-function-declaration]
Caused by commit 187e47824013 ("Staging: ipack: Read the ID space during
device registration").
I have added the following patch for today:
From: Stephen Rothwell
Date: Wed, 5 Sep 2012 15:44:11 +1000
Subject: [PATCH] Staging: ipack: disable due to build error
The powerpc allyesconfig build gives this:
drivers/staging/ipack/ipack.c: In function 'ipack_device_read_id':
drivers/staging/ipack/ipack.c:291:2: error: implicit declaration of function
'ioread8' [-Werror=implicit-function-declaration]
drivers/staging/ipack/ipack.c:309:3: error: implicit declaration of function
'ioread16be' [-Werror=implicit-function-declaration]
Signed-off-by: Stephen Rothwell
---
drivers/staging/ipack/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ipack/Kconfig b/drivers/staging/ipack/Kconfig
index af32178..5c428d7 100644
--- a/drivers/staging/ipack/Kconfig
+++ b/drivers/staging/ipack/Kconfig
@@ -4,6 +4,7 @@
menuconfig IPACK_BUS
tristate "IndustryPack bus support"
+ depends on BROKEN
---help---
If you say Y here you get support for the IndustryPack Framework
for drivers for many types of boards that support this industrial
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnZAMUWIgu4.pgp
Description: PGP signature
[PATCH -v3 12/14] x86/mm: calculate_table_space_size based on memory ranges that are being mapped
From: Jacob Shin
Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()
This patch also reportedly fixes suspend/resume issue reported in:
https://lkml.org/lkml/2012/8/11/83
-v2: update with calculate_table_space_size()
clear max_pfn_mapped before init_all_memory_mapping to get right value
-Yinghai Lu
Signed-off-by: Jacob Shin
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/mm/init.c | 51 ++-
1 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 47b6e41..852023f 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -191,39 +191,48 @@ static int __meminit split_mem_range(struct map_range
*mr, int nr_range,
return nr_range;
}
-static unsigned long __init calculate_table_space_size(unsigned long begin,
+static unsigned long __init calculate_table_space_size(unsigned long start,
unsigned long end)
{
- unsigned long puds, pmds, ptes, tables;
+ unsigned long puds = 0, pmds = 0, ptes = 0, tables;
+ struct map_range mr[NR_RANGE_MR];
+ int nr_range, i;
- puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
- tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+ pr_info("calculate_table_space_size: [mem %#010lx-%#010lx]\n",
+ start, end - 1);
- if (page_size_mask & (1 << PG_LEVEL_1G)) {
- unsigned long extra;
+ memset(mr, 0, sizeof(mr));
+ nr_range = 0;
+ nr_range = split_mem_range(mr, nr_range, start, end);
- extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
- pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
- } else
- pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+ for (i = 0; i < nr_range; i++) {
+ unsigned long range, extra;
- tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
+ range = mr[i].end - mr[i].start;
+ puds += (range + PUD_SIZE - 1) >> PUD_SHIFT;
- if (page_size_mask & (1 << PG_LEVEL_2M)) {
- unsigned long extra;
+ if (mr[i].page_size_mask & (1 << PG_LEVEL_1G)) {
+ extra = range - ((range >> PUD_SHIFT) << PUD_SHIFT);
+ pmds += (extra + PMD_SIZE - 1) >> PMD_SHIFT;
+ } else
+ pmds += (range + PMD_SIZE - 1) >> PMD_SHIFT;
- extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
+ if (mr[i].page_size_mask & (1 << PG_LEVEL_2M)) {
+ extra = range - ((range >> PMD_SHIFT) << PMD_SHIFT);
#ifdef CONFIG_X86_32
- extra += PMD_SIZE;
+ extra += PMD_SIZE;
#endif
- /* The first 2/4M doesn't use large pages. */
- if (begin < PMD_SIZE)
- extra += (PMD_SIZE - begin) >> PAGE_SHIFT;
+ /* The first 2/4M doesn't use large pages. */
+ if (mr[i].start < PMD_SIZE)
+ extra += PMD_SIZE - mr[i].start;
- ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
- } else
- ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ ptes += (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ } else
+ ptes += (range + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ }
+ tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+ tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
#ifdef CONFIG_X86_32
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 13/14] x86, mm: Use func pointer to table size calculation and mapping
They all need to go over ram range in same sequence. So add shared function
to reduce duplicated code.
-v2: Change to walk_ram_ranges() according to Pekka Enberg.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c | 64 ++-
1 files changed, 23 insertions(+), 41 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 852023f..6663f61 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -243,14 +243,15 @@ static unsigned long __init
calculate_table_space_size(unsigned long start,
return tables;
}
-static unsigned long __init calculate_all_table_space_size(void)
+static void __init walk_ram_ranges(
+ void (*work_fn)(unsigned long, unsigned long, void *),
+ void *data)
{
unsigned long start_pfn, end_pfn;
- unsigned long tables;
int i;
/* the ISA range is always mapped regardless of memory holes */
- tables = calculate_table_space_size(0, ISA_END_ADDRESS);
+ work_fn(0, ISA_END_ADDRESS, data);
for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
u64 start = start_pfn << PAGE_SHIFT;
@@ -269,10 +270,15 @@ static unsigned long __init
calculate_all_table_space_size(void)
if ((end >> PAGE_SHIFT) > max_low_pfn)
end = max_low_pfn << PAGE_SHIFT;
#endif
- tables += calculate_table_space_size(start, end);
+ work_fn(start, end, data);
}
+}
- return tables;
+static void __init size_work_fn(unsigned long start, unsigned long end, void
*data)
+{
+ unsigned long *size = data;
+
+ *size += calculate_table_space_size(start, end);
}
static void __init find_early_table_space(unsigned long start,
@@ -361,45 +367,15 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
* Depending on the alignment of E820 ranges, this may possibly result in using
* smaller size (i.e. 4K instead of 2M or 1G) page tables.
*/
-static void __init init_all_memory_mapping(void)
+static void __init mapping_work_fn(unsigned long start, unsigned long end,
+void *data)
{
- unsigned long start_pfn, end_pfn;
- int i;
-
- /* the ISA range is always mapped regardless of memory holes */
- init_memory_mapping(0, ISA_END_ADDRESS);
-
- for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
- u64 start = start_pfn << PAGE_SHIFT;
- u64 end = end_pfn << PAGE_SHIFT;
-
- if (end <= ISA_END_ADDRESS)
- continue;
-
- if (start < ISA_END_ADDRESS)
- start = ISA_END_ADDRESS;
-#ifdef CONFIG_X86_32
- /* on 32 bit, we only map up to max_low_pfn */
- if ((start >> PAGE_SHIFT) >= max_low_pfn)
- continue;
-
- if ((end >> PAGE_SHIFT) > max_low_pfn)
- end = max_low_pfn << PAGE_SHIFT;
-#endif
- init_memory_mapping(start, end);
- }
-
-#ifdef CONFIG_X86_64
- if (max_pfn > max_low_pfn) {
- /* can we preseve max_low_pfn ?*/
- max_low_pfn = max_pfn;
- }
-#endif
+ init_memory_mapping(start, end);
}
void __init init_mem_mapping(void)
{
- unsigned long tables, good_end, end;
+ unsigned long tables = 0, good_end, end;
probe_page_size_mask();
@@ -417,15 +393,21 @@ void __init init_mem_mapping(void)
end = max_low_pfn << PAGE_SHIFT;
good_end = max_pfn_mapped << PAGE_SHIFT;
#endif
- tables = calculate_all_table_space_size();
+ walk_ram_ranges(size_work_fn, );
find_early_table_space(0, good_end, tables);
printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @ [mem
%#010lx-%#010lx] prealloc\n",
end - 1, pgt_buf_start << PAGE_SHIFT,
(pgt_buf_top << PAGE_SHIFT) - 1);
max_pfn_mapped = 0; /* will get exact value next */
- init_all_memory_mapping();
+ walk_ram_ranges(mapping_work_fn, NULL);
+#ifdef CONFIG_X86_64
+ if (max_pfn > max_low_pfn) {
+ /* can we preseve max_low_pfn ?*/
+ max_low_pfn = max_pfn;
+ }
+#endif
/*
* Reserve the kernel pagetable pages we used (pgt_buf_start -
* pgt_buf_end) and free the other ones (pgt_buf_end - pgt_buf_top)
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 14/14] x86, mm: Map ISA area with connected ram range at the same time
so could reduce one loop.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 6663f61..e69f832 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -248,20 +248,27 @@ static void __init walk_ram_ranges(
void *data)
{
unsigned long start_pfn, end_pfn;
+ bool isa_done = false;
int i;
- /* the ISA range is always mapped regardless of memory holes */
- work_fn(0, ISA_END_ADDRESS, data);
-
for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
u64 start = start_pfn << PAGE_SHIFT;
u64 end = end_pfn << PAGE_SHIFT;
- if (end <= ISA_END_ADDRESS)
- continue;
+ if (!isa_done && start > ISA_END_ADDRESS) {
+ work_fn(0, ISA_END_ADDRESS, data);
+ isa_done = true;
+ } else {
+ if (end < ISA_END_ADDRESS)
+ continue;
+
+ if (start <= ISA_END_ADDRESS &&
+ end >= ISA_END_ADDRESS) {
+ start = 0;
+ isa_done = true;
+ }
+ }
- if (start < ISA_END_ADDRESS)
- start = ISA_END_ADDRESS;
#ifdef CONFIG_X86_32
/* on 32 bit, we only map up to max_low_pfn */
if ((start >> PAGE_SHIFT) >= max_low_pfn)
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -v3 03/14] x86, mm: Moving init_memory_mapping calling
from setup.c to mm/init.c
So could update all related calling together later
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/include/asm/init.h|1 -
arch/x86/include/asm/pgtable.h |2 +-
arch/x86/kernel/setup.c| 13 +
arch/x86/mm/init.c | 19 ++-
4 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
index adcc0ae..4f13998 100644
--- a/arch/x86/include/asm/init.h
+++ b/arch/x86/include/asm/init.h
@@ -12,7 +12,6 @@ kernel_physical_mapping_init(unsigned long start,
unsigned long end,
unsigned long page_size_mask);
-
extern unsigned long __initdata pgt_buf_start;
extern unsigned long __meminitdata pgt_buf_end;
extern unsigned long __meminitdata pgt_buf_top;
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index e47e4db..ae2cabb 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -597,7 +597,7 @@ static inline int pgd_none(pgd_t pgd)
#ifndef __ASSEMBLY__
extern int direct_gbpages;
-void probe_page_size_mask(void);
+void init_mem_mapping(void);
/* local pte updates need not use xchg for locking */
static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d6e8c03..c30c78c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -912,20 +912,9 @@ void __init setup_arch(char **cmdline_p)
setup_real_mode();
init_gbpages();
- probe_page_size_mask();
- /* max_pfn_mapped is updated here */
- max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< max_low_pfn) {
- max_pfn_mapped = init_memory_mapping(1UL<<32,
-max_pfn<> PAGE_SHIFT;
}
+void __init init_mem_mapping(void)
+{
+ probe_page_size_mask();
+
+ /* max_pfn_mapped is updated here */
+ max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< max_low_pfn) {
+ max_pfn_mapped = init_memory_mapping(1UL<<32,
+max_pfn
[PATCH -v3 11/14] x86: Only direct map addresses that are marked as E820_RAM
From: Jacob Shin
Currently direct mappings are created for [ 0 to max_low_pfn<
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
---
arch/x86/include/asm/page_types.h |8 +--
arch/x86/kernel/setup.c |8 ++-
arch/x86/mm/init.c| 119 +
arch/x86/mm/init_64.c |6 +-
4 files changed, 116 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h
b/arch/x86/include/asm/page_types.h
index 45aae6e..54c9787 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -51,13 +51,7 @@ static inline phys_addr_t get_max_mapped(void)
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
}
-static inline bool pfn_range_is_mapped(unsigned long start_pfn,
- unsigned long end_pfn)
-{
- return end_pfn <= max_low_pfn_mapped ||
- (end_pfn > (1UL << (32 - PAGE_SHIFT)) &&
- end_pfn <= max_pfn_mapped);
-}
+bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn);
extern unsigned long init_memory_mapping(unsigned long start,
unsigned long end);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index de72acc..9ccef07 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -115,9 +115,11 @@
#include
/*
- * end_pfn only includes RAM, while max_pfn_mapped includes all e820 entries.
- * The direct mapping extends to max_pfn_mapped, so that we can directly access
- * apertures, ACPI and other tables without having to play with fixmaps.
+ * max_low_pfn_mapped: highest direct mapped pfn under 4GB
+ * max_pfn_mapped: highest direct mapped pfn over 4GB
+ *
+ * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
+ * represented by pfn_mapped
*/
unsigned long max_low_pfn_mapped;
unsigned long max_pfn_mapped;
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index a475d7f..47b6e41 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -234,6 +234,38 @@ static unsigned long __init
calculate_table_space_size(unsigned long begin,
return tables;
}
+static unsigned long __init calculate_all_table_space_size(void)
+{
+ unsigned long start_pfn, end_pfn;
+ unsigned long tables;
+ int i;
+
+ /* the ISA range is always mapped regardless of memory holes */
+ tables = calculate_table_space_size(0, ISA_END_ADDRESS);
+
+ for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
+ u64 start = start_pfn << PAGE_SHIFT;
+ u64 end = end_pfn << PAGE_SHIFT;
+
+ if (end <= ISA_END_ADDRESS)
+ continue;
+
+ if (start < ISA_END_ADDRESS)
+ start = ISA_END_ADDRESS;
+#ifdef CONFIG_X86_32
+ /* on 32 bit, we only map up to max_low_pfn */
+ if ((start >> PAGE_SHIFT) >= max_low_pfn)
+ continue;
+
+ if ((end >> PAGE_SHIFT) > max_low_pfn)
+ end = max_low_pfn << PAGE_SHIFT;
+#endif
+ tables += calculate_table_space_size(start, end);
+ }
+
+ return tables;
+}
+
static void __init find_early_table_space(unsigned long start,
unsigned long good_end,
unsigned long tables)
@@ -249,6 +281,33 @@ static void __init find_early_table_space(unsigned long
start,
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
}
+static struct range pfn_mapped[E820_X_MAX];
+static int nr_pfn_mapped;
+
+static void add_pfn_range_mapped(unsigned long start_pfn, unsigned long
end_pfn)
+{
+ nr_pfn_mapped = add_range_with_merge(pfn_mapped, E820_X_MAX,
+nr_pfn_mapped, start_pfn, end_pfn);
+ nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
+
+ max_pfn_mapped = max(max_pfn_mapped, end_pfn);
+
+ if (end_pfn <= (1UL << (32 - PAGE_SHIFT)))
+ max_low_pfn_mapped = max(max_low_pfn_mapped, end_pfn);
+}
+
+bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
+{
+ int i;
+
+ for (i = 0; i < nr_pfn_mapped; i++)
+ if ((start_pfn >= pfn_mapped[i].start) &&
+ (end_pfn <= pfn_mapped[i].end))
+ return true;
+
+ return false;
+}
+
/*
* Setup the direct mapping of the physical memory at PAGE_OFFSET.
* This runs before bootmem is initialized and gets pages directly from
@@ -280,9 +339,55 @@ unsigned long __init_refok init_memory_mapping(unsigned
long start,
__flush_tlb_all();
+ add_pfn_range_mapped(start >> PAGE_SHIFT, ret >> PAGE_SHIFT);
+
return ret >> PAGE_SHIFT;
}
+/*
+ * Iterate through E820 memory map and create direct mappings for only E820_RAM
+ * regions. We cannot simply create direct mappings for all
[PATCH -v3 04/14] x86, mm: Revert back good_end setting for 64bit
So we could put page table high again for 64bit. Signed-off-by: Yinghai Lu --- arch/x86/mm/init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 15a6a38..cca9b7d 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -76,8 +76,8 @@ static void __init find_early_table_space(struct map_range *mr, #ifdef CONFIG_X86_32 /* for fixmap */ tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE); -#endif good_end = max_pfn_mapped << PAGE_SHIFT; +#endif base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE); if (!base) -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/3] powerpc: Uprobes port to powerpc
On Wed, Sep 05, 2012 at 03:26:59PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2012-08-24 at 13:01 +0530, Ananth N Mavinakayanahalli wrote: > > From: Ananth N Mavinakayanahalli > > > > This is the port of uprobes to powerpc. Usage is similar to x86. > > Guys, can you do a minimum of build testing ? > > This one breaks due to uprobe_get_swbp_addr() being defined in both > asm and include/linux when CONFIG_UPROBE isn't set. You don't need > to define it at all in fact, the generic code takes care of both the > declaration for CONFIG_UPROBE and the empty inline for !CONFIG_UPROBE. > > I'm fixing that one up myself but please, please, get yourself a test > build script or something to make sure you don't at least break the > build when the stuff you're adding isn't enabled (among others). Sorry Ben. That was an oversight. Won't happen again. Regards, Ananth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] gpio fixes for v3.6
Hi Linus, these are some smallish GPIO regression fixes for the v3.6 series, should be no big deal, please pull them in! Details in the tag. Yours, Linus Walleij The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-fixes-for-v3.6 for you to fetch changes up to 1146f8822ae6601e24f9072d6cd74f76506142cd: gpio: rdc321x: Prevent removal of modules exporting active GPIOs (2012-09-01 12:52:24 +0200) These are some GPIO regression fixes for v3.6: - Erroneous debug message from of_get_named_gpio_flags() - Make sure the MC9S08DZ60 GPIO driver depend on I2C being compiled in (not module) or allmodconfig breaks. - Check return value from irq_alloc_descs() in the Emma Mobile GPIO driver. - Assign the owner field for the rdc321x driver so the module won't be removed if it has active GPIOs. Axel Lin (3): gpio: mc9s08dz60: Fix build error if I2C=m gpio: em: Fix checking return value of irq_alloc_descs gpio: rdc321x: Prevent removal of modules exporting active GPIOs Thierry Reding (1): gpio: Fix debug message in of_get_named_gpio_flags() drivers/gpio/Kconfig| 2 +- drivers/gpio/gpio-em.c | 4 ++-- drivers/gpio/gpio-rdc321x.c | 1 + drivers/gpio/gpiolib-of.c | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xen: fix logical error in tlb flushing
> -Original Message- > From: Shi, Alex > Sent: Wednesday, September 05, 2012 1:35 PM > To: Jan Beulich > Cc: Konrad Rzeszutek Wilk; t...@linutronix.de; mi...@redhat.com; > linux-kernel@vger.kernel.org; h...@zytor.com; Ren, Yongjie > Subject: Re: [PATCH] xen: fix logical error in tlb flushing > > On 08/25/2012 03:45 AM, Jan Beulich wrote: > > On 24.08.12 at 20:17, Konrad Rzeszutek Wilk > wrote: > >> On Fri, Aug 24, 2012 at 04:16:39PM +0100, Jan Beulich wrote: > >> On 24.08.12 at 10:55, Alex Shi wrote: > While TLB_FLUSH_ALL gets passed as 'end' argument to > flush_tlb_others(), the Xen code was made to check its 'start' > parameter. That may give a incorrect op.cmd to > MMUEXT_INVLPG_MULTI > instead of MMUEXT_TLB_FLUSH_MULTI. Then it causes some page > can not > be flushed from TLB. > > This patch fixed this issue. > > Reported-by: Jan Beulich > Signed-off-by: Alex Shi > >>> > >>> Acked-by: Jan Beulich > Tested-by: Yongjie Ren > > CC to Yongjie, > Could you like to test this patch on PV guest > Xen Dom0 and a PV guest kernel with this patch can boot up correctly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (net-next tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c: In function 'nf_nat_ipv6_csum_recalc':
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:144:4: error: implicit declaration of
function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
Caused by commit 58a317f1061c ("netfilter: ipv6: add IPv6 NAT support").
(I always thought IPv6 NAT was a bad idea ;-))
I have applied the following patch for today:
From: Stephen Rothwell
Date: Wed, 5 Sep 2012 15:34:58 +1000
Subject: [PATCH] netfilter: ipv6: using csum_ipv6_magic requires
net/ip6_checksum.h
Fixes this build error:
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c: In function 'nf_nat_ipv6_csum_recalc':
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c:144:4: error: implicit declaration of
function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
Signed-off-by: Stephen Rothwell
---
net/ipv6/netfilter/nf_nat_l3proto_ipv6.c |1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
index 81a2d1c..abfe75a 100644
--- a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpdpyeIi1XDy.pgp
Description: PGP signature
Re: [PATCH] xen: fix logical error in tlb flushing
On 08/25/2012 03:45 AM, Jan Beulich wrote: On 24.08.12 at 20:17, Konrad Rzeszutek Wilk wrote: >> On Fri, Aug 24, 2012 at 04:16:39PM +0100, Jan Beulich wrote: >> On 24.08.12 at 10:55, Alex Shi wrote: While TLB_FLUSH_ALL gets passed as 'end' argument to flush_tlb_others(), the Xen code was made to check its 'start' parameter. That may give a incorrect op.cmd to MMUEXT_INVLPG_MULTI instead of MMUEXT_TLB_FLUSH_MULTI. Then it causes some page can not be flushed from TLB. This patch fixed this issue. Reported-by: Jan Beulich Signed-off-by: Alex Shi >>> >>> Acked-by: Jan Beulich CC to Yongjie, Could you like to test this patch on PV guest >> >> How can I reproduce this > > I don't know, I spotted this while looking at the code. Again, since the old buggy code doesn't cause trouble in PV guest, guess the hypercall for MMUEXT_INVLPG_MULTI was translated or treated as MMUEXT_TLB_FLUSH_MULTI. If so, believe correct this will bring a big performance benefit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/3] powerpc: Uprobes port to powerpc
On Fri, 2012-08-24 at 13:01 +0530, Ananth N Mavinakayanahalli wrote: > From: Ananth N Mavinakayanahalli > > This is the port of uprobes to powerpc. Usage is similar to x86. Guys, can you do a minimum of build testing ? This one breaks due to uprobe_get_swbp_addr() being defined in both asm and include/linux when CONFIG_UPROBE isn't set. You don't need to define it at all in fact, the generic code takes care of both the declaration for CONFIG_UPROBE and the empty inline for !CONFIG_UPROBE. I'm fixing that one up myself but please, please, get yourself a test build script or something to make sure you don't at least break the build when the stuff you're adding isn't enabled (among others). Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf: allow user to indicate path to objdump in command line
On Wed, 2012-09-05 at 12:11 +1000, Michael Ellerman wrote: > On Tue, 2012-09-04 at 10:05 -0600, David Ahern wrote: > > On 9/4/12 4:32 AM, Maciek Borzecki wrote: > > > When analyzing perf data from hosts of other architecture than one of the > > > local > > > host it's useful to call objdump that is part of a toolchain for that > > > architecture. Instead of calling regular objdump, call one that user > > > specified > > > in command line. > > > > Why not set the PATH to make the toolchain's version the one used by perf? > > At least one reason is that cross toolchains are usually built such that > the resulting binaries are called -objdump, -gcc etc. Correct, PATH won't work. First I thought, why not hardcode objdump based on CROSS. But then, I'd need to rebuild perf for each toolchain, bad idea. Passing objdump in command line seems like a good compromise to me, especially as I haven't noticed any other binutils tools to be used by perf same way as objdump is. -- Maciek Borzecki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] userns: Add basic quota support v4
Dave Chinner writes: > On Wed, Aug 29, 2012 at 02:31:26AM -0700, Eric W. Biederman wrote: >> >> Dave thanks for taking the time to take a detailed look at this code. >> >> Dave Chinner writes: >> >> > On Tue, Aug 28, 2012 at 12:09:56PM -0700, Eric W. Biederman wrote: >> > How did you test that this all works? >> >> By making it a compile error if you get a conversion wrong and making it >> a rule not to make any logic changes. >> >> That combined with code review >> and running the code a bit to make certain I did not horribly mess up. > > But no actual regression testing. You're messing with code that I > will have to triage when it goes wrong for a user, so IMO your code > has to pass the same bar as the code I write has to pass for review > - please regression test your code and write new regression tests > for new functionality. I like the idea of regression tests. In practice and also with xfstests I find that I spend lots of time debugging and fixing and improving tests and at the end of the day I find regression tests tell me very little. But I did figure I should give them a try since I have a rather substantial xfs patch in my queue. I added tests 111 and 232 to the expunged file because the don't run to completion. ltp/rwtest.sh needs to be run with #!/bin/bash instead of #!/bin/sh as it contains serveral bashisms. You need to have gawk installed instead of mawk because of a non-posix call to asort somewhere in the test framework. On my branch userns-always-map-user-v53 or on v3.6-rc1+ xfs: check for possible overflow in xfs_ioc_trim xfs: unlock the AGI buffer when looping in xfs_dialloc xfs: fix uninitialised variable in xfs_rtbuf_get() When I run ./check in the from xfstests I get Tue Sep 4 05:06:12 PDT 2012 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 Not run:2 Failures: 018 081 082 106 107 136 167 171 206 219 229 234 250 280 Failed 14 of 165 tests But since the results came back the same either way I think the tests told me all they can. The 14 failed tests and 1 bug don't seem to say good things about xfs in general though. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
On Tue, Sep 04, 2012 at 09:33:31PM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > The full implementation should trust keys that are trusted by the > > platform, so it'd boot any kexec image you cared to sign. Or simply > > patch this code out and rebuild and self-sign, or disable the code that > > turns off the capability when in secure boot mode. I've no objection to > > putting that behind an #ifdef. > > I will be happy to see a version of kexec that accepts signed images, > allowing the functionality to work in your brave new world where > everything must be signed. > > Until then I don't see a point in merging anything else. Fine. We'll just carry this one out of tree for now. -- Matthew Garrett | mj...@srcf.ucam.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/
[PATCH 3/7] perf header: Swap pmu mapping numbers if needed
From: Namhyung Kim
Like others, the numbers can be saved in a different endian format
than a host machine. Swap them if needed.
Cc: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 05c9310c3da1..43425b75f0c9 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1440,6 +1440,9 @@ static void print_pmu_mappings(struct perf_header *ph,
int fd, FILE *fp)
if (ret != sizeof(pmu_num))
goto error;
+ if (ph->needs_swap)
+ pmu_num = bswap_32(pmu_num);
+
if (!pmu_num) {
fprintf(fp, "# pmu mappings: not available\n");
return;
@@ -1448,6 +1451,9 @@ static void print_pmu_mappings(struct perf_header *ph,
int fd, FILE *fp)
while (pmu_num) {
if (read(fd, , sizeof(type)) != sizeof(type))
break;
+ if (ph->needs_swap)
+ type = bswap_32(type);
+
name = do_read_string(fd, ph);
if (!name)
break;
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] perf header: Save and reuse feature information in header (v2)
Hi, This is a v2 of my perf header cleanup series. The v1 can be found here [1]. Currently the perf header information is used only at initial setup time and discarded. If it's saved we could reuse the information for various purpose in the future. The patch 1-3 are cleanups so that they can be applied independently. I also put the series on my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git perf/header-v2 Any comments are welcome, thanks. Namhyung [1] https://lkml.org/lkml/2012/7/21/75 v1 -> v2: * not touch EVENT_DESC feature handling * split out struct perf_header_info * simplify multi-string handling * add some cleanup patches Namhyung Kim (7): perf header: Use evlist->nr_entries on write_event_desc() perf header: Set tracepoint event name only if not set perf header: Swap pmu mapping numbers if needed perf header: Add struct perf_header_info perf header: Add ->process callbacks to most of features perf header: Use pre-processed header info when printing perf header: Remove unused @feat arg from ->process callback tools/perf/util/header.c | 528 +-- tools/perf/util/header.h | 24 +++ 2 files changed, 393 insertions(+), 159 deletions(-) -- 1.7.11.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] perf header: Use evlist->nr_entries on write_event_desc()
From: Namhyung Kim
Number of events (evsels) in a evlist is kept on nr_entries field
so that we don't need to recalculate it.
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 9696e64c9dbd..a124b9328170 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -610,11 +610,10 @@ static int write_event_desc(int fd, struct perf_header *h
__used,
struct perf_evlist *evlist)
{
struct perf_evsel *evsel;
- u32 nre = 0, nri, sz;
+ u32 nre, nri, sz;
int ret;
- list_for_each_entry(evsel, >entries, node)
- nre++;
+ nre = evlist->nr_entries;
/*
* write number of events
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] perf header: Add struct perf_header_info
From: Namhyung Kim
The struct perf_header_info will preserve environment information at
the time of perf record. It can be accessed anytime after parsing a
perf.data file if needed.
Cc: Stephane Eranian
Cc: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.h | 24
1 file changed, 24 insertions(+)
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index 9d5eedceda72..420403b57307 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -58,6 +58,29 @@ struct perf_header;
int perf_file_header__read(struct perf_file_header *header,
struct perf_header *ph, int fd);
+struct perf_header_info {
+ char*hostname;
+ char*os_release;
+ char*version;
+ char*arch;
+ int nr_cpus_online;
+ int nr_cpus_avail;
+ char*cpu_desc;
+ char*cpuid;
+ unsigned long long total_mem;
+
+ int nr_cmdline;
+ char*cmdline;
+ int nr_sibling_cores;
+ char*sibling_cores;
+ int nr_sibling_threads;
+ char*sibling_threads;
+ int nr_numa_nodes;
+ char*numa_nodes;
+ int nr_pmu_mappings;
+ char*pmu_mappings;
+};
+
struct perf_header {
int frozen;
boolneeds_swap;
@@ -67,6 +90,7 @@ struct perf_header {
u64 event_offset;
u64 event_size;
DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
+ struct perf_header_info info;
};
struct perf_evlist;
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] perf header: Set tracepoint event name only if not set
From: Namhyung Kim
The event name can be set already by processing a event_desc data.
So check it before setting to prevent possible leak.
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index a124b9328170..05c9310c3da1 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2314,7 +2314,7 @@ static int perf_evlist__set_tracepoint_names(struct
perf_evlist *evlist,
struct perf_evsel *pos;
list_for_each_entry(pos, >entries, node) {
- if (pos->attr.type == PERF_TYPE_TRACEPOINT &&
+ if (pos->attr.type == PERF_TYPE_TRACEPOINT && !pos->name &&
perf_evsel__set_tracepoint_name(pos, pevent))
return -1;
}
--
1.7.11.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 v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari, Thanks for the review. On Wednesday 05 September 2012 12:42 AM, Sakari Ailus wrote: > Hi Prabhakar, > > Thanks for the patch. I've got a few comments below. > > On Tue, Sep 04, 2012 at 11:07:52AM +0530, Prabhakar Lad wrote: >> From: Lad, Prabhakar >> >> add V4L2_CID_DPCM_PREDICTOR control of type menu, which >> determines the dpcm predictor. The predictor can be either >> simple or advanced. >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli >> Acked-by: Hans Verkuil >> Reviewed-by: Sylwester Nawrocki >> Cc: Sakari Ailus >> Cc: Laurent Pinchart >> Cc: Mauro Carvalho Chehab >> Cc: Hans de Goede >> Cc: Kyungmin Park >> Cc: Rob Landley >> --- >> This patches has one checkpatch warning for line over >> 80 characters altough it can be avoided I have kept it >> for consistency. >> >> Changes for v4: >> 1: Aligned the description to fit appropriately in the >> para tag, pointed by Sylwester. >> >> Changes for v3: >> 1: Added better explanation for DPCM, pointed by Hans. >> >> Changes for v2: >> 1: Added documentaion in controls.xml pointed by Sylwester. >> 2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED >>pointed by Sakari. >> >> Documentation/DocBook/media/v4l/controls.xml | 46 >> +- >> drivers/media/v4l2-core/v4l2-ctrls.c |9 + >> include/linux/videodev2.h|5 +++ >> 3 files changed, 59 insertions(+), 1 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index 93b9c68..ad873ea 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -4267,7 +4267,51 @@ interface and may change in the future. >> pixels / second. >> >> >> - >> + >> +> spanname="id">V4L2_CID_DPCM_PREDICTOR >> +menu >> + >> + >> + Differential pulse-code modulation (DPCM) >> is a signal >> +encoder that uses the baseline of pulse-code modulation (PCM) but >> adds some >> +functionalities based on the prediction of the samples of the >> signal. The input >> +can be an analog signal or a digital signal. >> + >> +If the input is a continuous-time analog signal, it needs to >> be sampled >> +first so that a discrete-time signal is the input to the DPCM >> encoder. >> + >> +Simple: take the values of two consecutive samples; if they >> are analog >> +samples, quantize them; calculate the difference between the first >> one and the >> +next; the output is the difference, and it can be further entropy >> coded. >> + >> +Advanced: instead of taking a difference relative to a >> previous input sample, >> +take the difference relative to the output of a local model of the >> decoder process; >> +in this option, the difference can be quantized, which allows a >> good way to >> +incorporate a controlled loss in the encoding. > > This is directly from Wikipedia, isn't it? > Yes. > What comes to the content, DPCM in the context of V4L2 media bus codes, as a > digital interface, is always digital. So there's no need to document it. > Entropy coding is also out of the question: the samples of the currently > defined formats are equal in size. > Ok. > Another thing what I'm not sure is the definition of the simple and advanced > encoders. I've seen sensors that allow you to choose which one to use, but > the documentation hasn't stated what the actual implementation is. Does TI > documentation do so? > Couldn't find much apart from this 'The DPCM compression system uses two different predictors; one is simple and the other is complex. Predictor1 is very simple, so the processing power and the memory requirements are reduced with it (when the image quality is already high enough). Predictor2 gives a slightly better prediction for pixel value and the image quality can be improved with it.' > In V4L2 documentation we should state what is common in the hardware > documentation, and that is mostly limited to "simple" and "advanced". I > really don't know enough that I could say what the exact implamentation of > those two are in all of the cases. > > I suggest we leave just a few words of the DPCM compression itself (roughly > the factual content of the first paragraph with the exception of the > reference to analogue signal) and a link to Wikipedia. > Ok. >> +Applying one of these two processes, short-term redundancy >> (positive correlation of >> +nearby values) of the signal is eliminated; compression ratios on >> the order of 2 to 4 >> +can be achieved if differences are subsequently entropy coded, >> because the entropy of >> +the difference signal is much smaller than that of the original >> discrete signal treated >> +as independent samples.For more
[PATCH 7/7] perf header: Remove unused @feat arg from ->process callback
From: Namhyung Kim
As the @feat arg is not used anywhere, get rid of it from the signature.
Cc: Stephane Eranian
Cc: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 59
1 file changed, 25 insertions(+), 34 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 2cc0954d984c..06ecd577d1b8 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1541,16 +1541,15 @@ out:
}
static int process_tracing_data(struct perf_file_section *section __unused,
- struct perf_header *ph __unused,
- int feat __unused, int fd, void *data)
+ struct perf_header *ph __unused, int fd,
+ void *data)
{
trace_report(fd, data, false);
return 0;
}
static int process_build_id(struct perf_file_section *section,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
if (perf_header__read_build_ids(ph, fd, section->offset, section->size))
pr_debug("Failed to read buildids, continuing...\n");
@@ -1558,40 +1557,35 @@ static int process_build_id(struct perf_file_section
*section,
}
static int process_hostname(struct perf_file_section *section __unused,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
ph->info.hostname = do_read_string(fd, ph);
return ph->info.hostname ? 0 : -ENOMEM;
}
static int process_osrelease(struct perf_file_section *section __unused,
-struct perf_header *ph,
-int feat __unused, int fd, void *data __used)
+struct perf_header *ph, int fd, void *data __used)
{
ph->info.os_release = do_read_string(fd, ph);
return ph->info.os_release ? 0 : -ENOMEM;
}
static int process_version(struct perf_file_section *section __unused,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
ph->info.version = do_read_string(fd, ph);
return ph->info.version ? 0 : -ENOMEM;
}
static int process_arch(struct perf_file_section *section __unused,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
ph->info.arch = do_read_string(fd, ph);
return ph->info.arch ? 0 : -ENOMEM;
}
static int process_nrcpus(struct perf_file_section *section __unused,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
size_t ret;
u32 nr;
@@ -1617,24 +1611,21 @@ static int process_nrcpus(struct perf_file_section
*section __unused,
}
static int process_cpudesc(struct perf_file_section *section __unused,
- struct perf_header *ph,
- int feat __unused, int fd, void *data __used)
+ struct perf_header *ph, int fd, void *data __used)
{
ph->info.cpu_desc = do_read_string(fd, ph);
return ph->info.cpu_desc ? 0 : -ENOMEM;
}
static int process_cpuid(struct perf_file_section *section __unused,
-struct perf_header *ph,
-int feat __unused, int fd, void *data __used)
+struct perf_header *ph, int fd, void *data __used)
{
ph->info.cpuid = do_read_string(fd, ph);
return ph->info.cpuid ? 0 : -ENOMEM;
}
static int process_total_mem(struct perf_file_section *section __unused,
-struct perf_header *ph,
-int feat __unused, int fd, void *data __used)
+struct perf_header *ph, int fd, void *data __used)
{
uint64_t mem;
size_t ret;
@@ -1664,7 +1655,8 @@ perf_evlist__find_by_index(struct perf_evlist *evlist,
int idx)
}
static void
-perf_evlist__set_event_name(struct perf_evlist *evlist, struct perf_evsel
*event)
+perf_evlist__set_event_name(struct perf_evlist *evlist,
+ struct perf_evsel *event)
{
struct perf_evsel *evsel;
@@ -1683,15 +1675,15 @@ perf_evlist__set_event_name(struct perf_evlist *evlist,
struct perf_evsel *event
static int
process_event_desc(struct perf_file_section *section __unused,
- struct perf_header *header, int feat
[PATCH 5/7] perf header: Add ->process callbacks to most of features
>From now on each feature information is processed and saved in perf
header so that it can be used wherever needed. The BRANCH_STACK
feature is an exception since it needs nothing to be done.
Cc: Stephane Eranian
Cc: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 318 +--
1 file changed, 307 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 43425b75f0c9..9c6ab1b52a07 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -21,6 +21,7 @@
#include "debug.h"
#include "cpumap.h"
#include "pmu.h"
+#include "strbuf.h"
static bool no_buildid_cache = false;
@@ -1638,6 +1639,99 @@ static int process_build_id(struct perf_file_section
*section,
return 0;
}
+static int process_hostname(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ ph->info.hostname = do_read_string(fd, ph);
+ return ph->info.hostname ? 0 : -ENOMEM;
+}
+
+static int process_osrelease(struct perf_file_section *section __unused,
+struct perf_header *ph,
+int feat __unused, int fd, void *data __used)
+{
+ ph->info.os_release = do_read_string(fd, ph);
+ return ph->info.os_release ? 0 : -ENOMEM;
+}
+
+static int process_version(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ ph->info.version = do_read_string(fd, ph);
+ return ph->info.version ? 0 : -ENOMEM;
+}
+
+static int process_arch(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ ph->info.arch = do_read_string(fd, ph);
+ return ph->info.arch ? 0 : -ENOMEM;
+}
+
+static int process_nrcpus(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ size_t ret;
+ u32 nr;
+
+ ret = read(fd, , sizeof(nr));
+ if (ret != sizeof(nr))
+ return -1;
+
+ if (ph->needs_swap)
+ nr = bswap_32(nr);
+
+ ph->info.nr_cpus_online = nr;
+
+ ret = read(fd, , sizeof(nr));
+ if (ret != sizeof(nr))
+ return -1;
+
+ if (ph->needs_swap)
+ nr = bswap_32(nr);
+
+ ph->info.nr_cpus_avail = nr;
+ return 0;
+}
+
+static int process_cpudesc(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ ph->info.cpu_desc = do_read_string(fd, ph);
+ return ph->info.cpu_desc ? 0 : -ENOMEM;
+}
+
+static int process_cpuid(struct perf_file_section *section __unused,
+struct perf_header *ph,
+int feat __unused, int fd, void *data __used)
+{
+ ph->info.cpuid = do_read_string(fd, ph);
+ return ph->info.cpuid ? 0 : -ENOMEM;
+}
+
+static int process_total_mem(struct perf_file_section *section __unused,
+struct perf_header *ph,
+int feat __unused, int fd, void *data __used)
+{
+ uint64_t mem;
+ size_t ret;
+
+ ret = read(fd, , sizeof(mem));
+ if (ret != sizeof(mem))
+ return -1;
+
+ if (ph->needs_swap)
+ mem = bswap_64(mem);
+
+ ph->info.total_mem = mem;
+ return 0;
+}
+
static struct perf_evsel *
perf_evlist__find_by_index(struct perf_evlist *evlist, int idx)
{
@@ -1688,6 +1782,208 @@ process_event_desc(struct perf_file_section *section
__unused,
return 0;
}
+static int process_cmdline(struct perf_file_section *section __unused,
+ struct perf_header *ph,
+ int feat __unused, int fd, void *data __used)
+{
+ size_t ret;
+ char *str;
+ u32 nr, i;
+ struct strbuf sb;
+
+ ret = read(fd, , sizeof(nr));
+ if (ret != sizeof(nr))
+ return -1;
+
+ if (ph->needs_swap)
+ nr = bswap_32(nr);
+
+ ph->info.nr_cmdline = nr;
+ strbuf_init(, 128);
+
+ for (i = 0; i < nr; i++) {
+ str = do_read_string(fd, ph);
+ if (!str)
+ goto error;
+
+ /* include a NULL character at the end */
+ strbuf_add(, str, strlen(str) + 1);
+ free(str);
+ }
+ ph->info.cmdline = strbuf_detach(, NULL);
+ return 0;
+
+error:
+ strbuf_release();
+ return -1;
+}
+
+static int process_cpu_topology(struct perf_file_section *section __unused,
+
[PATCH 6/7] perf header: Use pre-processed header info when printing
>From now on each feature information is processed and saved in perf
header so that it can be used for printing. The event desc and branch
stack features are not touched since they're not saved.
Cc: Stephane Eranian
Cc: Robert Richter
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 196 ++-
1 file changed, 57 insertions(+), 139 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 9c6ab1b52a07..2cc0954d984c 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1073,118 +1073,73 @@ static int write_branch_stack(int fd __used, struct
perf_header *h __used,
return 0;
}
-static void print_hostname(struct perf_header *ph, int fd, FILE *fp)
+static void print_hostname(struct perf_header *ph, int fd __used, FILE *fp)
{
- char *str = do_read_string(fd, ph);
- fprintf(fp, "# hostname : %s\n", str);
- free(str);
+ fprintf(fp, "# hostname : %s\n", ph->info.hostname);
}
-static void print_osrelease(struct perf_header *ph, int fd, FILE *fp)
+static void print_osrelease(struct perf_header *ph, int fd __used, FILE *fp)
{
- char *str = do_read_string(fd, ph);
- fprintf(fp, "# os release : %s\n", str);
- free(str);
+ fprintf(fp, "# os release : %s\n", ph->info.os_release);
}
-static void print_arch(struct perf_header *ph, int fd, FILE *fp)
+static void print_arch(struct perf_header *ph, int fd __used, FILE *fp)
{
- char *str = do_read_string(fd, ph);
- fprintf(fp, "# arch : %s\n", str);
- free(str);
+ fprintf(fp, "# arch : %s\n", ph->info.arch);
}
-static void print_cpudesc(struct perf_header *ph, int fd, FILE *fp)
+static void print_cpudesc(struct perf_header *ph, int fd __used, FILE *fp)
{
- char *str = do_read_string(fd, ph);
- fprintf(fp, "# cpudesc : %s\n", str);
- free(str);
+ fprintf(fp, "# cpudesc : %s\n", ph->info.cpu_desc);
}
-static void print_nrcpus(struct perf_header *ph, int fd, FILE *fp)
+static void print_nrcpus(struct perf_header *ph, int fd __used, FILE *fp)
{
- ssize_t ret;
- u32 nr;
-
- ret = read(fd, , sizeof(nr));
- if (ret != (ssize_t)sizeof(nr))
- nr = -1; /* interpreted as error */
-
- if (ph->needs_swap)
- nr = bswap_32(nr);
-
- fprintf(fp, "# nrcpus online : %u\n", nr);
-
- ret = read(fd, , sizeof(nr));
- if (ret != (ssize_t)sizeof(nr))
- nr = -1; /* interpreted as error */
-
- if (ph->needs_swap)
- nr = bswap_32(nr);
-
- fprintf(fp, "# nrcpus avail : %u\n", nr);
+ fprintf(fp, "# nrcpus online : %u\n", ph->info.nr_cpus_online);
+ fprintf(fp, "# nrcpus avail : %u\n", ph->info.nr_cpus_avail);
}
-static void print_version(struct perf_header *ph, int fd, FILE *fp)
+static void print_version(struct perf_header *ph, int fd __used, FILE *fp)
{
- char *str = do_read_string(fd, ph);
- fprintf(fp, "# perf version : %s\n", str);
- free(str);
+ fprintf(fp, "# perf version : %s\n", ph->info.version);
}
-static void print_cmdline(struct perf_header *ph, int fd, FILE *fp)
+static void print_cmdline(struct perf_header *ph, int fd __used, FILE *fp)
{
- ssize_t ret;
+ int nr, i;
char *str;
- u32 nr, i;
- ret = read(fd, , sizeof(nr));
- if (ret != (ssize_t)sizeof(nr))
- return;
-
- if (ph->needs_swap)
- nr = bswap_32(nr);
+ nr = ph->info.nr_cmdline;
+ str = ph->info.cmdline;
fprintf(fp, "# cmdline : ");
for (i = 0; i < nr; i++) {
- str = do_read_string(fd, ph);
fprintf(fp, "%s ", str);
- free(str);
+ str += strlen(str) + 1;
}
fputc('\n', fp);
}
-static void print_cpu_topology(struct perf_header *ph, int fd, FILE *fp)
+static void print_cpu_topology(struct perf_header *ph, int fd __used, FILE *fp)
{
- ssize_t ret;
- u32 nr, i;
+ int nr, i;
char *str;
- ret = read(fd, , sizeof(nr));
- if (ret != (ssize_t)sizeof(nr))
- return;
-
- if (ph->needs_swap)
- nr = bswap_32(nr);
+ nr = ph->info.nr_sibling_cores;
+ str = ph->info.sibling_cores;
for (i = 0; i < nr; i++) {
- str = do_read_string(fd, ph);
fprintf(fp, "# sibling cores : %s\n", str);
- free(str);
+ str += strlen(str) + 1;
}
- ret = read(fd, , sizeof(nr));
- if (ret != (ssize_t)sizeof(nr))
- return;
-
- if (ph->needs_swap)
- nr = bswap_32(nr);
+ nr = ph->info.nr_sibling_threads;
+ str = ph->info.sibling_threads;
for (i = 0; i < nr; i++) {
- str = do_read_string(fd, ph);
fprintf(fp, "# sibling threads : %s\n", str);
-
Re: linux-next: manual merge of the net-next tree with the vfs tree
Hi,
How can I see source files applied your patch?
(I'm very new to kernel development.)
You patch looks like a patch for another patch.
Masatake YAMATO
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> net/socket.c between commits f8a78429cc70 ("take descriptor handling from
> sock_alloc_file() to callers") and 32b529f92ea7 ("unexport sock_map_fd(),
> switch to sock_alloc_file()") from the vfs tree and commit 600e177920df
> ("net: Providing protocol type via system.sockprotoname xattr
> of /proc/PID/fd entries") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. I also had
> to add this merge fix patch:
>
> From: Stephen Rothwell
> Date: Wed, 5 Sep 2012 11:52:06 +1000
> Subject: [PATCH] net: cope with sock_alloc_file() API change
>
> Signed-off-by: Stephen Rothwell
> ---
> include/linux/net.h |3 ++-
> net/9p/trans_fd.c |2 +-
> net/sctp/socket.c |2 +-
> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index c8a9708..a3831f3 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -247,7 +247,8 @@ extern int sock_sendmsg(struct socket *sock,
> struct msghdr *msg,
> size_t len);
> extern intsock_recvmsg(struct socket *sock, struct msghdr *msg,
> size_t size, int flags);
> -extern struct file *sock_alloc_file(struct socket *sock, int flags);
> +extern struct file *sock_alloc_file(struct socket *sock, int flags,
> + const char *dname);
> extern struct socket *sockfd_lookup(int fd, int *err);
> extern struct socket *sock_from_file(struct file *file, int *err);
> #define sockfd_put(sock) fput(sock->file)
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index 8c4e0b5..1c8b557 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -801,7 +801,7 @@ static int p9_socket_open(struct p9_client *client,
> struct socket *csocket)
> return -ENOMEM;
>
> csocket->sk->sk_allocation = GFP_NOIO;
> - file = sock_alloc_file(csocket, 0);
> + file = sock_alloc_file(csocket, 0, NULL);
> if (IS_ERR(file)) {
> pr_err("%s (%d): failed to map fd\n",
> __func__, task_pid_nr(current));
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5ba739e..59d16ea 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4313,7 +4313,7 @@ static int sctp_getsockopt_peeloff(struct sock *sk, int
> len, char __user *optval
> goto out;
> }
>
> - newfile = sock_alloc_file(newsock, 0);
> + newfile = sock_alloc_file(newsock, 0, NULL);
> if (unlikely(IS_ERR(newfile))) {
> put_unused_fd(retval);
> sock_release(newsock);
> --
> 1.7.10.280.gaa39
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc net/socket.c
> index 79170dc,977c0f4..000
> --- a/net/socket.c
> +++ b/net/socket.c
> @@@ -346,15 -347,30 +347,23 @@@ static struct file_system_type sock_fs_
>* but we take care of internal coherence yet.
>*/
>
> - struct file *sock_alloc_file(struct socket *sock, int flags)
> -static int sock_alloc_file(struct socket *sock, struct file **f, int flags,
> - const char *dname)
> ++struct file *sock_alloc_file(struct socket *sock, int flags,
> ++ const char *dname)
> {
> struct qstr name = { .name = "" };
> struct path path;
> struct file *file;
> -int fd;
> -
> -fd = get_unused_fd_flags(flags);
> -if (unlikely(fd < 0))
> -return fd;
>
> + if (dname) {
> + name.name = dname;
> + name.len = strlen(name.name);
> + } else if (sock->sk) {
> + name.name = sock->sk->sk_prot_creator->name;
> + name.len = strlen(name.name);
> + }
> path.dentry = d_alloc_pseudo(sock_mnt->mnt_sb, );
> -if (unlikely(!path.dentry)) {
> -put_unused_fd(fd);
> -return -ENOMEM;
> -}
> +if (unlikely(!path.dentry))
> +return ERR_PTR(-ENOMEM);
> path.mnt = mntget(sock_mnt);
>
> d_instantiate(path.dentry, SOCK_INODE(sock));
> @@@ -373,26 -390,22 +382,26 @@@
> file->f_flags = O_RDWR | (flags & O_NONBLOCK);
> file->f_pos = 0;
> file->private_data = sock;
> -
> -*f = file;
> -return fd;
> +return file;
> }
> +EXPORT_SYMBOL(sock_alloc_file);
>
> -int sock_map_fd(struct socket *sock, int flags)
> +static int sock_map_fd(struct socket *sock, int flags)
> {
> struct file *newfile;
> -int fd = sock_alloc_file(sock, , flags, NULL);
> +int fd = get_unused_fd_flags(flags);
> +if (unlikely(fd < 0))
> +return fd;
>
> - newfile = sock_alloc_file(sock, flags);
> -if
[PATCH 3/5] regulator: lp872x: initialize the DVS mode
The platform specific configuration(general_config) is optional. However, the DVS settings should be configured explicitly while loading the driver. This patch enables configuring the default DVS mode even though the platform data is not defined. Signed-off-by: Milo(Woogyom) Kim --- drivers/regulator/lp872x.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c index d86b6a3..b16a941 100644 --- a/drivers/regulator/lp872x.c +++ b/drivers/regulator/lp872x.c @@ -796,13 +796,14 @@ static int lp872x_config(struct lp872x *lp) struct lp872x_platform_data *pdata = lp->pdata; int ret; - if (!pdata->update_config) - return 0; + if (!pdata || !pdata->update_config) + goto init_dvs; ret = lp872x_write_byte(lp, LP872X_GENERAL_CFG, pdata->general_config); if (ret) return ret; +init_dvs: return lp872x_init_dvs(lp); } -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: tegra: move smmu.h into SMMU driver
On Wed, 5 Sep 2012 00:36:15 +0200 Stephen Warren wrote: > From: Stephen Warren > > There's no need to place these defines into arch/arm/mach-tegra/include/. > Move them into the SMMU driver to clean up mach-tegra, as a pre-requisite > for single-zImage. > > Signed-off-by: Stephen Warren > Cc: Hiroshi Doyu Ok to me. Acked-by: Hiroshi Doyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/5] regulator: lp872x: remove unnecessary function
The lp872x_check_dvs_validity() is used for checking DVS platform data.
If the DVS platform data is not defined, return as error code.
Now, this is unnecessary because the default DVS mode is set in this case.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp872x.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 86485e8..708f4b6 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -729,28 +729,6 @@ static struct regulator_desc lp8725_regulator_desc[] = {
},
};
-static int lp872x_check_dvs_validity(struct lp872x *lp)
-{
- struct lp872x_dvs *dvs = lp->pdata->dvs;
- u8 val = 0;
- int ret;
-
- ret = lp872x_read_byte(lp, LP872X_GENERAL_CFG, );
- if (ret)
- return ret;
-
- ret = 0;
- if (lp->chipid == LP8720) {
- if (val & LP8720_EXT_DVS_M)
- ret = dvs ? 0 : -EINVAL;
- } else {
- if ((val & LP8725_DVS1_M) == EXTERN_DVS_USED)
- ret = dvs ? 0 : -EINVAL;
- }
-
- return ret;
-}
-
static int lp872x_init_dvs(struct lp872x *lp)
{
int ret, gpio;
@@ -762,12 +740,6 @@ static int lp872x_init_dvs(struct lp872x *lp)
if (!dvs)
goto set_default_dvs_mode;
- ret = lp872x_check_dvs_validity(lp);
- if (ret) {
- dev_warn(lp->dev, "invalid dvs data: %d\n", ret);
- return ret;
- }
-
gpio = dvs->gpio;
if (!gpio_is_valid(gpio)) {
dev_err(lp->dev, "invalid gpio: %d\n", gpio);
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] regulator: lp872x: fix NULL pointer access problem
The lp872x_set_dvs() is used for changing the DVS pin state.
This function works only when the DVS platform data is defined.
So don't assume that DVS data is always valid.
In case the platform data is not defined, the DVS data is set to NULL
for skipping the DVS pin control.
DVS selection and GPIO pin number are used for the LP872x DVS pin control.
For better readability, DVS selection argument is added in lp872x_set_dvs().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp872x.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index b16a941..86485e8 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -273,9 +273,9 @@ static int lp872x_regulator_enable_time(struct
regulator_dev *rdev)
return val > MAX_DELAY ? 0 : val * time_step_us;
}
-static void lp872x_set_dvs(struct lp872x *lp, int gpio)
+static void lp872x_set_dvs(struct lp872x *lp, enum lp872x_dvs_sel dvs_sel,
+ int gpio)
{
- enum lp872x_dvs_sel dvs_sel = lp->pdata->dvs->vsel;
enum lp872x_dvs_state state;
state = dvs_sel == SEL_V1 ? DVS_HIGH : DVS_LOW;
@@ -343,10 +343,10 @@ static int lp872x_buck_set_voltage_sel(struct
regulator_dev *rdev,
struct lp872x *lp = rdev_get_drvdata(rdev);
enum lp872x_regulator_id buck = rdev_get_id(rdev);
u8 addr, mask = LP872X_VOUT_M;
- struct lp872x_dvs *dvs = lp->pdata->dvs;
+ struct lp872x_dvs *dvs = lp->pdata ? lp->pdata->dvs : NULL;
if (dvs && gpio_is_valid(dvs->gpio))
- lp872x_set_dvs(lp, dvs->gpio);
+ lp872x_set_dvs(lp, dvs->vsel, dvs->gpio);
addr = lp872x_select_buck_vout_addr(lp, buck);
if (!lp872x_is_valid_buck_addr(addr))
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] regulator: lp872x: set the default DVS mode
The lp872x driver has the DVS platform data which select the register address
of the BUCK voltage.
This patch enables updating the default DVS mode when the DVS platform data
is not defined.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp872x.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index ddd60c6..d86b6a3 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -86,6 +86,10 @@
#define EXTERN_DVS_USED0
#define MAX_DELAY 6
+/* Default DVS Mode */
+#define LP8720_DEFAULT_DVS 0
+#define LP8725_DEFAULT_DVS BIT(2)
+
/* dump registers in regmap-debugfs */
#define MAX_REGISTERS 0x0F
@@ -750,8 +754,13 @@ static int lp872x_check_dvs_validity(struct lp872x *lp)
static int lp872x_init_dvs(struct lp872x *lp)
{
int ret, gpio;
- struct lp872x_dvs *dvs = lp->pdata->dvs;
+ struct lp872x_dvs *dvs = lp->pdata ? lp->pdata->dvs : NULL;
enum lp872x_dvs_state pinstate;
+ u8 mask[] = { LP8720_EXT_DVS_M, LP8725_DVS1_M | LP8725_DVS2_M };
+ u8 default_dvs_mode[] = { LP8720_DEFAULT_DVS, LP8725_DEFAULT_DVS };
+
+ if (!dvs)
+ goto set_default_dvs_mode;
ret = lp872x_check_dvs_validity(lp);
if (ret) {
@@ -776,6 +785,10 @@ static int lp872x_init_dvs(struct lp872x *lp)
lp->dvs_gpio = gpio;
return 0;
+
+set_default_dvs_mode:
+ return lp872x_update_bits(lp, LP872X_GENERAL_CFG, mask[lp->chipid],
+ default_dvs_mode[lp->chipid]);
}
static int lp872x_config(struct lp872x *lp)
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] regulator: lp872x: remove regulator platform data dependency
This patch enables registering the regulator driver even though
the regulator_init_data is not defined in the platform side.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp872x.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 6199d0f..ddd60c6 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -796,11 +796,15 @@ static int lp872x_config(struct lp872x *lp)
static struct regulator_init_data
*lp872x_find_regulator_init_data(int id, struct lp872x *lp)
{
+ struct lp872x_platform_data *pdata = lp->pdata;
int i;
+ if (!pdata)
+ return NULL;
+
for (i = 0; i < lp->num_regulators; i++) {
- if (lp->pdata->regulator_data[i].id == id)
- return lp->pdata->regulator_data[i].init_data;
+ if (pdata->regulator_data[i].id == id)
+ return pdata->regulator_data[i].init_data;
}
return NULL;
@@ -861,18 +865,12 @@ static const struct regmap_config lp872x_regmap_config = {
static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
struct lp872x *lp;
- struct lp872x_platform_data *pdata = cl->dev.platform_data;
int ret, size, num_regulators;
const int lp872x_num_regulators[] = {
[LP8720] = LP8720_NUM_REGULATORS,
[LP8725] = LP8725_NUM_REGULATORS,
};
- if (!pdata) {
- dev_err(>dev, "no platform data\n");
- return -EINVAL;
- }
-
lp = devm_kzalloc(>dev, sizeof(struct lp872x), GFP_KERNEL);
if (!lp)
goto err_mem;
@@ -892,7 +890,7 @@ static int lp872x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
}
lp->dev = >dev;
- lp->pdata = pdata;
+ lp->pdata = cl->dev.platform_data;
lp->chipid = id->driver_data;
lp->num_regulators = num_regulators;
i2c_set_clientdata(cl, lp);
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] regulator: lp872x: remove platform data dependency
This patch-set removes the platform data dependency. The LP872x driver should be run even if the platform data is not defined. 5 patches enable running the driver in case the LP8720/8725 platform data has no configuration. [PATCH 1/5] regulator: lp872x: remove regulator platform data dependency [PATCH 2/5] regulator: lp872x: set the default DVS mode [PATCH 3/5] regulator: lp872x: initialize the DVS mode [PATCH 4/5] regulator: lp872x: fix NULL pointer access problem [PATCH 5/5] regulator: lp872x: remove unnecessary function Thank you. Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
Hello, Dave. On Wed, Sep 05, 2012 at 01:57:59PM +1000, Dave Chinner wrote: > > But, yeah, this can't be solved by enlarging the stack size. The > > upper limit is unbound. > > Sure, but recursion issue is isolated to the block layer. > > If we can still submit IO directly through the block layer without > pushing it off to a work queue, then the overall stack usage problem > still exists. But if the block layer always pushes the IO off into > another workqueue to avoid stack overflows, then the context > switches are going to cause significant performance regressions for > high IOPS workloads. I don't really like either situation. Kent's proposed solution doesn't do that. The rescuer work item is used iff mempool allocation fails w/o GFP_WAIT. IOW, we're already under severe memory pressure and stalls are expected all around the kernel (somehow this sounds festive...) It doesn't alter the breadth-first walk of bio decomposition and shouldn't degrade performance in any noticeable way. > So while you are discussing stack issues, think a little about the > bigger picture outside of the immediate issue at hand - a better > solution for everyone might pop up It's probably because I haven't been bitten much from stack overflow but I'd like to keep thinking that stack overflows are extremely unusual and the ones causing them are the bad ones. Thank you very much. :p -- 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: WARNING: cpu_is_offline() at native_smp_send_reschedule()
Hi, Feng Guang On 09/05/2012 09:11 AM, Fengguang Wu wrote: > Hi, > > Here is an old problem that happens also in 3.4. It's very unreliable: > it may only happen once per 3000 boots.. > > [ 10.968565] reboot: machine restart > [ 10.983510] [ cut here ] > [ 10.984218] WARNING: at > /c/kernel-tests/src/stable/arch/x86/kernel/smp.c:123 > native_smp_send_reschedule+0x46/0x50() > [ 10.985880] Pid: 88, comm: kpktgend_0 Not tainted 3.6.0-rc3-5-gb374aa1 > #10 > [ 10.987185] Call Trace: > [ 10.987506] [<7902f42a>] warn_slowpath_common+0x5a/0x80 > [ 10.987506] [<7901ee16>] ? native_smp_send_reschedule+0x46/0x50 > [ 10.987506] [<7901ee16>] ? native_smp_send_reschedule+0x46/0x50 > [ 10.987506] [<7902f4fd>] warn_slowpath_null+0x1d/0x20 > [ 10.987506] [<7901ee16>] native_smp_send_reschedule+0x46/0x50 So this cpu try to fire a nohz balance kick ipi to an offline cpu? May be we are choosing a wrong cpu to kick but that's not the point, what I can't understand is why this cpu could do this kick. We have nohz_kick_needed() to check whether current cpu should do kick , and the first condition we need to match is that current cpu should be idle, but the trace show current pid is 88 not 0. We should add Peter to cc list, may be he will be interested on what happened. Regards, Michael Wang > [ 10.987506] [<7905fdad>] trigger_load_balance+0x1bd/0x250 > [ 10.987506] [<79056d14>] scheduler_tick+0xd4/0x100 > [ 10.987506] [<7903bde5>] update_process_times+0x55/0x70 > [ 10.987506] [<79071187>] tick_sched_timer+0x57/0xb0 > [ 10.987506] [<793accee>] ? do_raw_spin_unlock+0x4e/0x90 > [ 10.987506] [<7904e0b7>] __run_hrtimer.isra.29+0x57/0x100 > [ 10.987506] [<79071130>] ? tick_nohz_handler+0xe0/0xe0 > [ 10.987506] [<7904ed45>] hrtimer_interrupt+0xe5/0x280 > [ 10.987506] [<7905a5a7>] ? sched_clock_cpu+0xc7/0x150 > [ 10.987506] [<7901f9a4>] smp_apic_timer_interrupt+0x54/0x90 > [ 10.987506] [<79882631>] apic_timer_interrupt+0x31/0x40 > [ 10.987506] [<7905007b>] ? call_srcu+0x2b/0x70 > [ 10.987506] [<793a00e0>] ? __bitmap_intersects+0x10/0x80 > [ 10.987506] [<7988194f>] ? _raw_spin_unlock_irq+0x1f/0x40 > [ 10.987506] [<7905307f>] finish_task_switch+0x7f/0xd0 > [ 10.987506] [<79053038>] ? finish_task_switch+0x38/0xd0 > [ 10.987506] [<7988044a>] __schedule+0x38a/0x770 > [ 10.987506] [<7905a5a7>] ? sched_clock_cpu+0xc7/0x150 > [ 10.987506] [<7987ea40>] ? schedule_timeout+0x100/0x1b0 > [ 10.987506] [<793accee>] ? do_raw_spin_unlock+0x4e/0x90 > [ 10.987506] [<7988084e>] schedule+0x1e/0x50 > [ 10.987506] [<7987ea45>] schedule_timeout+0x105/0x1b0 > [ 10.987506] [<7903adb0>] ? __internal_add_timer+0xb0/0xb0 > [ 10.987506] [<796842f2>] pktgen_thread_worker+0x1342/0x1390 > [ 10.987506] [<7988044a>] ? __schedule+0x38a/0x770 > [ 10.987506] [<793accee>] ? do_raw_spin_unlock+0x4e/0x90 > [ 10.987506] [<793accee>] ? do_raw_spin_unlock+0x4e/0x90 > [ 10.987506] [<7904aa40>] ? abort_exclusive_wait+0x80/0x80 > [ 10.987506] [<7904aa40>] ? abort_exclusive_wait+0x80/0x80 > [ 10.987506] [<79682fb0>] ? pktgen_if_write+0x2210/0x2210 > [ 10.987506] [<79049ff8>] kthread+0x78/0x80 > [ 10.987506] [<7988>] ? __up.isra.0+0xd/0x2d > [ 10.987506] [<79049f80>] ? insert_kthread_work+0x70/0x70 > [ 10.987506] [<798830c6>] kernel_thread_helper+0x6/0xd > > Here are all the oops messages I collected in the past days: > > [4.815145] Restarting system. > [4.815644] reboot: machine restart > [4.824591] [ cut here ] > [4.825423] WARNING: at /c/wfg/linux/arch/x86/kernel/smp.c:123 > native_smp_send_reschedule+0x46/0x50() > [4.826881] Pid: 18, comm: kworker/0:1 Not tainted > 3.6.0-rc3-bisect-7-g6320675 #25 > [4.828116] Call Trace: > [4.828533] [<7902f42a>] warn_slowpath_common+0x5a/0x80 > [4.828585] [<7901ee16>] ? native_smp_send_reschedule+0x46/0x50 > [4.828585] [<7901ee16>] ? native_smp_send_reschedule+0x46/0x50 > [4.828585] [<7902f4fd>] warn_slowpath_null+0x1d/0x20 > [4.828585] [<7901ee16>] native_smp_send_reschedule+0x46/0x50 > [4.828585] [<7905fdad>] trigger_load_balance+0x1bd/0x250 > [4.828585] [<79056d14>] scheduler_tick+0xd4/0x100 > [4.828585] [<7903bde5>] update_process_times+0x55/0x70 > [4.828585] [<79071187>] tick_sched_timer+0x57/0xb0 > [4.828585] [<793accee>] ? do_raw_spin_unlock+0x4e/0x90 > [4.828585] [<7904e0b7>] __run_hrtimer.isra.29+0x57/0x100 > [4.828585] [<79071130>] ? tick_nohz_handler+0xe0/0xe0 > [4.828585] [<7904ed45>] hrtimer_interrupt+0xe5/0x280 > [4.828585] [<7905a5a7>] ? sched_clock_cpu+0xc7/0x150 > [4.828585] [<7901f9a4>] smp_apic_timer_interrupt+0x54/0x90 > [4.828585] [<79882401>] apic_timer_interrupt+0x31/0x40 > [4.828585] [<7905007b>] ? call_srcu+0x2b/0x70 > [4.828585] [<793a00e0>] ? __bitmap_intersects+0x10/0x80 > [4.828585] [<7988171f>] ?
Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Matthew Garrett writes: > On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > The driving force behind this code right now is that our choices are >> > either (1) do something like this, or (2) disable kexec entirely. >> >> Actually there is an interesting question here. Why does even EFI secure >> boot justify this? If I install my own key in EFI I should be able to >> boot a kernel that does anything I want it to. My machine doing what I >> want it to is the point of trusted boot is it not? > > The full implementation should trust keys that are trusted by the > platform, so it'd boot any kexec image you cared to sign. Or simply > patch this code out and rebuild and self-sign, or disable the code that > turns off the capability when in secure boot mode. I've no objection to > putting that behind an #ifdef. I will be happy to see a version of kexec that accepts signed images, allowing the functionality to work in your brave new world where everything must be signed. Until then I don't see a point in merging anything else. I will be happy to see some reasonable patchs for signing support on the kexec path. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-blk: Fix kconfig option
On 09/04/2012 02:23 PM, Rusty Russell wrote: > Kent Overstreet writes: > >> CONFIG_VIRTIO isn't exposed, everything else is supposed to select it >> instead. > > This is a slight mis-understanding. It's supposed to be selected by > the particular driver, probably virtio_pci in your case. virtio_mmio selects virtio as well. drivers/virtio/Kconfig config VIRTIO_MMIO select VIRTIO config VIRTIO_PCI select VIRTIO How about this: config VIRTIO_BLK depends on EXPERIMENTAL && (VIRTIO_PCI || VIRTIO_MMIO) -- Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clkdev: Add default clkdev.h
Ease the deployment of clkdev by providing a default asm/clkdev.h for use if the arch does not have an include/asm/clkdev.h. Due to limitations in Kbuild we manually add clkdev.h to all architectures that don't have one rather than having the header appear by default. Signed-off-by: Mark Brown Reviewed-by: Stephen Rothwell --- Resending as the addition of exec.h introduce a bunch of conflicts, plus I spotted a typo. arch/alpha/include/asm/Kbuild |2 ++ arch/avr32/include/asm/Kbuild |2 ++ arch/cris/include/asm/Kbuild |1 + arch/frv/include/asm/Kbuild|1 + arch/h8300/include/asm/Kbuild |1 + arch/hexagon/include/asm/Kbuild|1 + arch/ia64/include/asm/Kbuild |1 + arch/m32r/include/asm/Kbuild |1 + arch/m68k/include/asm/Kbuild |1 + arch/microblaze/include/asm/Kbuild |1 + arch/mn10300/include/asm/Kbuild|1 + arch/openrisc/include/asm/Kbuild |1 + arch/parisc/include/asm/Kbuild |1 + arch/powerpc/include/asm/Kbuild|1 + arch/s390/include/asm/Kbuild |2 ++ arch/score/include/asm/Kbuild |2 ++ arch/sparc/include/asm/Kbuild |1 + arch/tile/include/asm/Kbuild |1 + arch/um/include/asm/Kbuild |2 +- arch/unicore32/include/asm/Kbuild |1 + arch/x86/include/asm/Kbuild|2 ++ arch/xtensa/include/asm/Kbuild |1 + include/asm-generic/clkdev.h | 28 23 files changed, 55 insertions(+), 1 deletion(-) create mode 100644 include/asm-generic/clkdev.h diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index 3bae7c9..64ffc9e 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -1,5 +1,7 @@ include include/asm-generic/Kbuild.asm +generic-y += clkdev.h + header-y += compiler.h header-y += console.h header-y += fpu.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index aa47fff..be0433e 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -1,4 +1,6 @@ include include/asm-generic/Kbuild.asm +generic-y += clkdev.h generic-y += exec.h + header-y += cachectl.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index f5ae9de..94c496a 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -8,5 +8,6 @@ header-y += etraxgpio.h header-y += rs485.h header-y += sync_serial.h +generic-y += clkdev.h generic-y += module.h generic-y += exec.h diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild index 32c1646..251bd71 100644 --- a/arch/frv/include/asm/Kbuild +++ b/arch/frv/include/asm/Kbuild @@ -2,4 +2,5 @@ include include/asm-generic/Kbuild.asm header-y += registers.h header-y += termios.h +generic-y += clkdev.h generic-y += exec.h diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild index 883a0be..67c4b8f 100644 --- a/arch/h8300/include/asm/Kbuild +++ b/arch/h8300/include/asm/Kbuild @@ -1,4 +1,5 @@ include include/asm-generic/Kbuild.asm +generic-y += clkdev.h generic-y += module.h generic-y += exec.h diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild index 0690642..3364b696 100644 --- a/arch/hexagon/include/asm/Kbuild +++ b/arch/hexagon/include/asm/Kbuild @@ -7,6 +7,7 @@ header-y += user.h generic-y += auxvec.h generic-y += bug.h generic-y += bugs.h +generic-y += clkdev.h generic-y += cputime.h generic-y += current.h generic-y += device.h diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild index 98efd48..562f593 100644 --- a/arch/ia64/include/asm/Kbuild +++ b/arch/ia64/include/asm/Kbuild @@ -13,4 +13,5 @@ header-y += ptrace_offsets.h header-y += rse.h header-y += ucontext.h header-y += ustack.h +generic-y += clkdev.h generic-y += exec.h diff --git a/arch/m32r/include/asm/Kbuild b/arch/m32r/include/asm/Kbuild index 883a0be..67c4b8f 100644 --- a/arch/m32r/include/asm/Kbuild +++ b/arch/m32r/include/asm/Kbuild @@ -1,4 +1,5 @@ include include/asm-generic/Kbuild.asm +generic-y += clkdev.h generic-y += module.h generic-y += exec.h diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild index a9d1bf1..ecb5408 100644 --- a/arch/m68k/include/asm/Kbuild +++ b/arch/m68k/include/asm/Kbuild @@ -2,6 +2,7 @@ include include/asm-generic/Kbuild.asm header-y += cachectl.h generic-y += bitsperlong.h +generic-y += clkdev.h generic-y += cputime.h generic-y += device.h generic-y += emergency-restart.h diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild index 5a0e72b..8653072 100644 --- a/arch/microblaze/include/asm/Kbuild +++ b/arch/microblaze/include/asm/Kbuild @@ -1,4 +1,5 @@ include include/asm-generic/Kbuild.asm header-y += elf.h +generic-y += clkdev.h generic-y += exec.h diff --git a/arch/mn10300/include/asm/Kbuild
Re: [PATCH v3 2/4] misc: Generic on-chip SRAM allocation driver
On Mon, Sep 03, 2012 at 06:02:06PM +0200, Philipp Zabel wrote:
> +static struct platform_driver sram_driver = {
> + .driver = {
> + .name = "sram",
> + .of_match_table = of_match_ptr(sram_dt_ids),
> + },
> + .probe = sram_probe,
> + .remove = __devexit_p(sram_remove),
> +};
> +
> +module_platform_driver(sram_driver);
I think we'd better make it a postcore_initcall time driver, so that
it can be ensured that when the client drivers call gen_pool_* API
the pool has been created by sram_driver.
--
Regards,
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Tue, Sep 04, 2012 at 11:26:33AM -0700, Tejun Heo wrote: > Hello, > > On Tue, Sep 04, 2012 at 09:54:23AM -0400, Vivek Goyal wrote: > > > Given that we are working around stack depth issues in the > > > filesystems already in several places, and now it seems like there's > > > a reason to work around it in the block layers as well, shouldn't we > > > simply increase the default stack size rather than introduce > > > complexity and performance regressions to try and work around not > > > having enough stack? > > > > Dave, > > > > In this particular instance, we really don't have any bug reports of > > stack overflowing. Just discussing what will happen if we make > > generic_make_request() recursive again. > > I think there was one and that's why we added the bio_list thing. There was more than one - it was a regular enough to be considered a feature... :/ > > > I mean, we can deal with it like the ia32 4k stack issue was dealt > > > with (i.e. ignore those stupid XFS people, that's an XFS bug), or > > > we can face the reality that storage stacks have become so complex > > > that 8k is no longer a big enough stack for a modern system > > > > So first question will be, what's the right stack size? If we make > > generic_make_request() recursive, then at some storage stack depth we will > > overflow stack anyway (if we have created too deep a stack). Hence > > keeping current logic kind of makes sense as in theory we can support > > arbitrary depth of storage stack. > > But, yeah, this can't be solved by enlarging the stack size. The > upper limit is unbound. Sure, but recursion issue is isolated to the block layer. If we can still submit IO directly through the block layer without pushing it off to a work queue, then the overall stack usage problem still exists. But if the block layer always pushes the IO off into another workqueue to avoid stack overflows, then the context switches are going to cause significant performance regressions for high IOPS workloads. I don't really like either situation. So while you are discussing stack issues, think a little about the bigger picture outside of the immediate issue at hand - a better solution for everyone might pop up 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/
linux-next: manual merge of the rcu tree with the tip tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in
kernel/sched/core.c between commit f319da0c6894 ("sched: Fix load avg vs
cpu-hotplug") from the tip tree and commit ead504e5600e ("sched: Fix load
avg vs cpu-hotplug") from the rcu tree.
These are 2 slightly different versions of the same patch :-( Same author
time, different commit times ... The rcu tree version contains this
extra bit in the commit message:
"[ paulmck: Move call to calc_load_migration to CPU_DEAD to avoid
miscounting noted by Rakib. ]"
So I used it. Let me know if this is not correct.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpMJOzQESILA.pgp
Description: PGP signature
Re: linux-next: manual merge of the spi-mb tree with the mmc tree
Dear Stephen Rothwell,
> Hi Mark,
>
> Today's linux-next merge of the spi-mb tree got a conflict in
> drivers/mmc/host/mxs-mmc.c between commit fc108d24d3a6 ("mmc: mxs-mmc:
> fix deadlock caused by recursion loop") from the mmc tree and commit
> 829c1bf40b92 ("mmc: spi: Pull out parts shared between MMC and SPI") from
> the spi-mb tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
On a quick glance, it seems correct. Thank you!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb: otg: Move phy interface to separate file.
Hi Greg, Initially I pushed patch to linux-next with https://lkml.org/lkml/2012/8/29/40 . In this patch, my mail id for "Signed-off-by" is correctly shown. However as Felipe wanted me to push the patch to his branch, I synced to his code base and pushed the patch. Am still not sure, why my mail id against signed-off-by got corrupted that way in this patch. Please let me know if the patch is to be resent. Thanks, Venu > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Tuesday, September 04, 2012 10:51 PM > To: Venu Byravarasu > Cc: ba...@ti.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org > Subject: Re: [PATCH] usb: otg: Move phy interface to separate file. > > On Tue, Sep 04, 2012 at 02:25:58PM +0530, Venu Byravarasu wrote: > > As otg.h is containing lots of phy interface related > > stuff, moving all phy interface related stuff to new > > file named phy.h > > > > Signed-off-by: Venu Byravarasu > > For some reason, I don't think that is a valid email address :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: RCU warning during UBI file system mount
On Tue, Sep 04, 2012 at 08:43:12AM -0700, Subodh Nijsure wrote: > MX28 is ARM device. I removed following from my config and these > warnings went away. > > CONFIG_CPU_IDLE=y > CONFIG_CPU_IDLE_GOV_LADDER=y > CONFIG_CPU_IDLE_GOV_MENU=y > There is no cpuidle implemented on imx28. I do not understand how these options influence the result here. > I have attached the kernel configuration file I used. > > It doesn't affect specific hw I am working with as device is not > required to enter idle mode. > I am Cc-ing linux-arm folks, in case someone on arm platform > requires CPU idele &, RCU to work. > I just ran a case with CONFIG_CPU_IDLE and RCU support and failed to reproduce the warning. Is this something specific to gpmi-nand or we can see it with any other imx28 drivers/cases? Sorry, I do not have NAND flash set up on my imx28 board. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb: otg: Move phy interface to separate file.
Not sure, why it appeared like that. However my actual mail id is: vbyravar...@nvidia.com Shall I resend the patch, or this mail id can be added in the patch? Thanks, Venu > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Tuesday, September 04, 2012 10:51 PM > To: Venu Byravarasu > Cc: ba...@ti.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org > Subject: Re: [PATCH] usb: otg: Move phy interface to separate file. > > On Tue, Sep 04, 2012 at 02:25:58PM +0530, Venu Byravarasu wrote: > > As otg.h is containing lots of phy interface related > > stuff, moving all phy interface related stuff to new > > file named phy.h > > > > Signed-off-by: Venu Byravarasu > > For some reason, I don't think that is a valid email address :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] drivers/char/tpm: Add new device driver to support IBM vTPM
On Wed, 2012-08-22 at 16:42 -0500, Kent Yoder wrote:
> On Wed, Aug 22, 2012 at 04:17:43PM -0500, Ashley Lai wrote:
> > This patch adds a new device driver to support IBM virtual TPM
> > (vTPM) for PPC64. IBM vTPM is supported through the adjunct
> > partition with firmware release 740 or higher. With vTPM
> > support, each lpar is able to have its own vTPM without the
> > physical TPM hardware.
> >
> > This driver provides TPM functionalities by communicating with
> > the vTPM adjunct partition through Hypervisor calls (Hcalls)
> > and Command/Response Queue (CRQ) commands.
>
> Thanks Ashley, I'll include this in my next pull request to James.
Oh ? I was about to put it in the powerpc tree ... But yeah, I notice
there's a change to tpm.h so it probably should be at least acked by the
TPM folks. As for the subsequent patches, they are powerpc specific so I
can add them, I don't think there's a strict dependency, is there ?
Now, while having a look at the driver, I found a few things that I'm
not sure I'm happy with:
Mainly:
> > + */
> > +static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > +{
> > + struct ibmvtpm_dev *ibmvtpm;
> > + u16 len;
> > +
> > + ibmvtpm = (struct ibmvtpm_dev *)chip->vendor.data;
> > +
> > + if (!ibmvtpm->rtce_buf) {
> > + dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
> > + return 0;
> > + }
> > +
> > + wait_event_interruptible(wq, ibmvtpm->crq_res.len != 0);
> > +
> > + if (count < ibmvtpm->crq_res.len) {
That doesn't look right. The "other side" as far as I can tell is:
> > + case VTPM_TPM_COMMAND_RES:
> > + ibmvtpm->crq_res.valid = crq->valid;
> > + ibmvtpm->crq_res.msg = crq->msg;
> > + ibmvtpm->crq_res.len = crq->len;
> > + ibmvtpm->crq_res.data = crq->data;
> > + wake_up_interruptible();
That looks racy to me. At the very least it should be doing:
ibmvtpm->crq_res.data = crq->data;
smp_wmb();
ibmvtpm->crq_res.len = crq->len;
IE. Ensure that "len" is written last, and possibly have an
corresponding smp_rmb() after wait_event_interruptible() in the receive
case.
Also, I dislike having a global symbol called "wq". You also don't seem
to have any synchronization on access to that wq, can't you end up with
several clients trying to send messages & wait for responses getting all
mixed up ? You might need to make sure that at least you do a
wake_up_interruptible_all() to ensure you wake them all up (inefficient
but works). Unless you can track per-client ?
Or is the above TPM layer making sure only one command/response happens
at a given point in time ?
You also do an interruptible wait but don't seem to be checking for
signals (and not testing the result from wait_event_interruptible which
might be returning -ERESTARTSYS in this case).
That all sound a bit wrong to me ...
> > +static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
> > +{
> > + struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>lock, flags);
> > + vio_disable_interrupts(ibmvtpm->vdev);
> > + tasklet_schedule(>tasklet);
> > + spin_unlock_irqrestore(>lock, flags);
> > +
> > + return IRQ_HANDLED;
> > +}
Tasklets ? We still use those things ? That's softirq iirc, do you
really need to offload ? I mean, it allows to limit the amount of time
an interrupt is disabled, but that's only useful if you assume you'll
have quite a lot of traffic here, is that the case ?
You might be actually increasing latency here in favor of throughput, is
that what you are aiming for ? Also keep in mind that
vio_disable/enable_interrupt() being an hcall, it can have significant
overhead. So again, only worth it if you're going to process a bulk of
data at a time.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] device_cgroup: replace internally whitelist with exception list
Quoting Aristeu Rozanski (a...@redhat.com): > The original model of device_cgroup is having a whitelist where all the > allowed devices are listed. The problem with this approach is that is > impossible to have the case of allowing everything but few devices. > > The reason for that lies in the way the whitelist is handled internally: > since there's only a whitelist, the "all devices" entry would have to be > removed and replaced by the entire list of possible devices but the ones > that are being denied. Since dev_t is 32 bits long, representing the allowed > devices as a bitfield is not memory efficient. > > This patch replaces the "whitelist" by a "exceptions" list and the default > policy is kept as "deny_all" variable in dev_cgroup structure. > > The current interface determines that whenever "a" is written to devices.allow > or devices.deny, the entry masking all devices will be added or removed, > respectively. This behavior is kept and it's what will determine the default > policy: > > # cat devices.list > a *:* rwm > # echo a >devices.deny > # cat devices.list > # echo a >devices.allow > # cat devices.list > a *:* rwm > > The interface is also preserved. For example, if one wants to block only > access > to /dev/null: > # ls -l /dev/null > crw-rw-rw- 1 root root 1, 3 Jul 24 16:17 /dev/null > # echo a >devices.allow > # echo "c 1:3 rwm" >devices.deny > # cat /dev/null > cat: /dev/null: Operation not permitted > # echo >/dev/null > bash: /dev/null: Operation not permitted > # mknod /tmp/null c 1 3 > mknod: /tmp/null: Operation not permitted > # echo "c 1:3 r" >devices.allow > # cat /dev/null > # echo >/dev/null > bash: /dev/null: Operation not permitted > # mknod /tmp/null c 1 3 > mknod: /tmp/null: Operation not permitted > # echo "c 1:3 rw" >devices.allow > # echo >/dev/null > # cat /dev/null > # mknod /tmp/null c 1 3 > mknod: /tmp/null: Operation not permitted > # echo "c 1:3 rwm" >devices.allow > # echo >/dev/null > # cat /dev/null > # mknod /tmp/null c 1 3 > # > > v2: > - stop using simple_strtoul() > - fix checkpatch warnings > - rename deny_all to behavior > - updated documentation > - added new files to cgroupfs to better reflect the internal state > > Documentation/cgroups/devices.txt | 73 -- > security/device_cgroup.c | 443 > +++--- > 2 files changed, 333 insertions(+), 183 deletions(-) > > -- > Aristeu Thanks, Aristeu, very nice. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] extcon: extcon-arizona depends on INPUT
On Tue, Sep 04, 2012 at 04:51:00PM -0700, Randy Dunlap wrote: > This build error still happens in linux-next of 20120904. > Can we get the patch merged for linux-next? Greg's the one managing extcon in -next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] device_cgroup: introduce a new, more consistent interface for device_cgroup
Quoting Aristeu Rozanski (a...@redhat.com):
> Internally device_cgroup now uses a default rule (behavior) and an exception
> list and this interface reflects it.
>
> The new files, devices.behavior ('allow' or 'deny') and devices.exceptions map
> directly to the internal state.
>
> Also, update documentation about the new interface.
>
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: James Morris
> Cc: Pavel Emelyanov
> Cc: Serge Hallyn
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> ---
> Documentation/cgroups/devices.txt | 73
> --
> security/device_cgroup.c | 63 +++-
> 2 files changed, 107 insertions(+), 29 deletions(-)
>
> --- a/security/device_cgroup.c2012-08-30 11:53:54.214675713 -0400
> +++ b/security/device_cgroup.c2012-08-30 11:53:54.227682064 -0400
> @@ -214,6 +214,8 @@ static void devcgroup_destroy(struct cgr
> #define DEVCG_ALLOW 1
> #define DEVCG_DENY 2
> #define DEVCG_LIST 3
> +#define DEVCG_BEHAVIOR 4
> +#define DEVCG_EXCEPTIONS 5
>
> #define MAJMINLEN 13
> #define ACCLEN 4
> @@ -249,11 +251,25 @@ static void set_majmin(char *str, unsign
> sprintf(str, "%u", m);
> }
>
> +static void __devcg_seq_list_exceptions(struct dev_cgroup *devcg,
> + struct seq_file *m)
> +{
> + struct dev_exception_item *ex;
> + char maj[MAJMINLEN], min[MAJMINLEN], acc[ACCLEN];
> +
> + list_for_each_entry_rcu(ex, >exceptions, list) {
> + set_access(acc, ex->access);
> + set_majmin(maj, ex->major);
> + set_majmin(min, ex->minor);
> + seq_printf(m, "%c %s:%s %s\n", type_to_char(ex->type),
> +maj, min, acc);
> + }
> +}
> +
> static int devcgroup_seq_read(struct cgroup *cgroup, struct cftype *cft,
> struct seq_file *m)
> {
> struct dev_cgroup *devcgroup = cgroup_to_devcgroup(cgroup);
> - struct dev_exception_item *ex;
> char maj[MAJMINLEN], min[MAJMINLEN], acc[ACCLEN];
>
> rcu_read_lock();
> @@ -269,20 +285,37 @@ static int devcgroup_seq_read(struct cgr
> set_majmin(min, ~0);
> seq_printf(m, "%c %s:%s %s\n", type_to_char(DEV_ALL),
> maj, min, acc);
> - } else {
> - list_for_each_entry_rcu(ex, >exceptions, list) {
> - set_access(acc, ex->access);
> - set_majmin(maj, ex->major);
> - set_majmin(min, ex->minor);
> - seq_printf(m, "%c %s:%s %s\n", type_to_char(ex->type),
> -maj, min, acc);
> - }
> - }
> + } else
> + __devcg_seq_list_exceptions(devcgroup, m);
> +
> rcu_read_unlock();
>
> return 0;
> }
>
> +static int devcg_seq_read_behavior(struct cgroup *cgroup,
> +struct cftype *cft, struct seq_file *m)
> +{
> + struct dev_cgroup *devcgroup = cgroup_to_devcgroup(cgroup);
> +
> + if (devcgroup->behavior == DEVCG_DEFAULT_ALLOW)
> + seq_printf(m, "allow\n");
> + else
> + seq_printf(m, "deny\n");
> +
> + return 0;
> +}
> +
> +static int devcg_seq_read_exceptions(struct cgroup *cgroup,
> + struct cftype *cft, struct seq_file *m)
> +{
> + struct dev_cgroup *devcgroup = cgroup_to_devcgroup(cgroup);
> +
> + __devcg_seq_list_exceptions(devcgroup, m);
> +
> + return 0;
> +}
> +
> /**
> * may_access - verifies if a new exception is part of what is allowed
> * by a dev cgroup based on the default policy +
> @@ -521,6 +554,16 @@ static struct cftype dev_cgroup_files[]
> .read_seq_string = devcgroup_seq_read,
> .private = DEVCG_LIST,
> },
> + {
> + .name = "behavior",
> + .read_seq_string = devcg_seq_read_behavior,
> + .private = DEVCG_BEHAVIOR,
> + },
> + {
> + .name = "exceptions",
> + .read_seq_string = devcg_seq_read_exceptions,
> + .private = DEVCG_EXCEPTIONS,
> + },
> { } /* terminate */
> };
>
> --- a/Documentation/cgroups/devices.txt 2012-06-18 14:33:03.913651049
> -0400
> +++ b/Documentation/cgroups/devices.txt 2012-08-30 12:20:46.25872
> -0400
> @@ -3,37 +3,65 @@ Device Whitelist Controller
> 1. Description:
>
> Implement a cgroup to track and enforce open and mknod restrictions
> -on device files. A device cgroup associates a device access
> -whitelist with each cgroup. A whitelist entry has 4 fields.
> -'type' is a (all), c (char), or b (block). 'all' means it applies
> -to all types and all major and minor numbers. Major and minor are
> -either an integer or * for all. Access is a composition of r
> -(read), w (write), and m (mknod).
> -
> -The root device cgroup starts with rwm to 'all'. A child device
Re: [PATCH v2 5/6] device_cgroup: rename whitelist to exception list
Quoting Aristeu Rozanski (a...@redhat.com):
> This patch replaces the "whitelist" usage in the code and comments and replace
> them by exception list related information.
>
> v2:
> - fix checkpatch warnings
>
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: James Morris
> Cc: Pavel Emelyanov
> Cc: Serge Hallyn
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> ---
> security/device_cgroup.c | 198
> +++
> 1 file changed, 99 insertions(+), 99 deletions(-)
>
> Index: github/security/device_cgroup.c
> ===
> --- github.orig/security/device_cgroup.c 2012-08-21 10:51:15.0
> -0400
> +++ github/security/device_cgroup.c 2012-08-21 10:54:16.509079085 -0400
> @@ -26,12 +26,12 @@
> static DEFINE_MUTEX(devcgroup_mutex);
>
> /*
> - * whitelist locking rules:
> + * exception list locking rules:
> * hold devcgroup_mutex for update/read.
> * hold rcu_read_lock() for read.
> */
>
> -struct dev_whitelist_item {
> +struct dev_exception_item {
> u32 major, minor;
> short type;
> short access;
> @@ -41,7 +41,7 @@
>
> struct dev_cgroup {
> struct cgroup_subsys_state css;
> - struct list_head whitelist;
> + struct list_head exceptions;
> enum {
> DEVCG_DEFAULT_ALLOW,
> DEVCG_DEFAULT_DENY,
> @@ -78,12 +78,12 @@
> /*
> * called under devcgroup_mutex
> */
> -static int dev_whitelist_copy(struct list_head *dest, struct list_head *orig)
> +static int dev_exceptions_copy(struct list_head *dest, struct list_head
> *orig)
> {
> - struct dev_whitelist_item *wh, *tmp, *new;
> + struct dev_exception_item *ex, *tmp, *new;
>
> - list_for_each_entry(wh, orig, list) {
> - new = kmemdup(wh, sizeof(*wh), GFP_KERNEL);
> + list_for_each_entry(ex, orig, list) {
> + new = kmemdup(ex, sizeof(*ex), GFP_KERNEL);
> if (!new)
> goto free_and_exit;
> list_add_tail(>list, dest);
> @@ -92,9 +92,9 @@
> return 0;
>
> free_and_exit:
> - list_for_each_entry_safe(wh, tmp, dest, list) {
> - list_del(>list);
> - kfree(wh);
> + list_for_each_entry_safe(ex, tmp, dest, list) {
> + list_del(>list);
> + kfree(ex);
> }
> return -ENOMEM;
> }
> @@ -102,50 +102,50 @@
> /*
> * called under devcgroup_mutex
> */
> -static int dev_whitelist_add(struct dev_cgroup *dev_cgroup,
> - struct dev_whitelist_item *wh)
> +static int dev_exception_add(struct dev_cgroup *dev_cgroup,
> + struct dev_exception_item *ex)
> {
> - struct dev_whitelist_item *whcopy, *walk;
> + struct dev_exception_item *excopy, *walk;
>
> - whcopy = kmemdup(wh, sizeof(*wh), GFP_KERNEL);
> - if (!whcopy)
> + excopy = kmemdup(ex, sizeof(*ex), GFP_KERNEL);
> + if (!excopy)
> return -ENOMEM;
>
> - list_for_each_entry(walk, _cgroup->whitelist, list) {
> - if (walk->type != wh->type)
> + list_for_each_entry(walk, _cgroup->exceptions, list) {
> + if (walk->type != ex->type)
> continue;
> - if (walk->major != wh->major)
> + if (walk->major != ex->major)
> continue;
> - if (walk->minor != wh->minor)
> + if (walk->minor != ex->minor)
> continue;
>
> - walk->access |= wh->access;
> - kfree(whcopy);
> - whcopy = NULL;
> + walk->access |= ex->access;
> + kfree(excopy);
> + excopy = NULL;
> }
>
> - if (whcopy != NULL)
> - list_add_tail_rcu(>list, _cgroup->whitelist);
> + if (excopy != NULL)
> + list_add_tail_rcu(>list, _cgroup->exceptions);
> return 0;
> }
>
> /*
> * called under devcgroup_mutex
> */
> -static void dev_whitelist_rm(struct dev_cgroup *dev_cgroup,
> - struct dev_whitelist_item *wh)
> +static void dev_exception_rm(struct dev_cgroup *dev_cgroup,
> + struct dev_exception_item *ex)
> {
> - struct dev_whitelist_item *walk, *tmp;
> + struct dev_exception_item *walk, *tmp;
>
> - list_for_each_entry_safe(walk, tmp, _cgroup->whitelist, list) {
> - if (walk->type != wh->type)
> + list_for_each_entry_safe(walk, tmp, _cgroup->exceptions, list) {
> + if (walk->type != ex->type)
> continue;
> - if (walk->major != wh->major)
> + if (walk->major != ex->major)
> continue;
> - if (walk->minor != wh->minor)
> + if (walk->minor != ex->minor)
> continue;
>
> - walk->access &= ~wh->access;
> + walk->access &= ~ex->access;
> if (!walk->access) {
>
Re: [PATCH v2 4/6] device_cgroup: stop using simple_strtoul()
Quoting Aristeu Rozanski (a...@redhat.com):
> This patch converts the code to use kstrtou32() instead of simple_strtoul()
> which is deprecated. The real size of the variables are u32, so use kstrtou32
> instead of kstrtoul
>
> Signed-off-by: Aristeu Rozanski
phew, i'm afraid i'm not up on the latest 'best parsing techniques'
but the end result looks correct (just not sure it's optimal).
Acked-by: Serge Hallyn
>
> ---
> security/device_cgroup.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> Index: github/security/device_cgroup.c
> ===
> --- github.orig/security/device_cgroup.c 2012-08-21 10:51:05.751689805
> -0400
> +++ github/security/device_cgroup.c 2012-08-21 10:51:15.015951623 -0400
> @@ -361,8 +361,8 @@
> int filetype, const char *buffer)
> {
> const char *b;
> - char *endp;
> - int count;
> + char temp[12]; /* 11 + 1 characters needed for a u32 */
> + int count, rc;
> struct dev_whitelist_item wh;
>
> if (!capable(CAP_SYS_ADMIN))
> @@ -405,8 +405,16 @@
> wh.major = ~0;
> b++;
> } else if (isdigit(*b)) {
> - wh.major = simple_strtoul(b, , 10);
> - b = endp;
> + memset(temp, 0, sizeof(temp));
> + for (count = 0; count < sizeof(temp) - 1; count++) {
> + temp[count] = *b;
> + b++;
> + if (!isdigit(*b))
> + break;
> + }
> + rc = kstrtou32(temp, 10, );
> + if (rc)
> + return -EINVAL;
> } else {
> return -EINVAL;
> }
> @@ -419,8 +427,16 @@
> wh.minor = ~0;
> b++;
> } else if (isdigit(*b)) {
> - wh.minor = simple_strtoul(b, , 10);
> - b = endp;
> + memset(temp, 0, sizeof(temp));
> + for (count = 0; count < sizeof(temp) - 1; count++) {
> + temp[count] = *b;
> + b++;
> + if (!isdigit(*b))
> + break;
> + }
> + rc = kstrtou32(temp, 10, );
> + if (rc)
> + return -EINVAL;
> } else {
> return -EINVAL;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sata_fsl: add workaround for data length mismatch on freescale V2 controller
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Tuesday, September 04, 2012 10:51 PM
> To: Xie Shaohui-B21989; jgar...@pobox.com; linux-...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Bhartiya
> Anju-B07263
> Subject: RE: [PATCH] sata_fsl: add workaround for data length mismatch on
> freescale V2 controller
>
> > + /* Read command completed register */
> > + done_mask = ioread32(hcr_base + CC);
> > +
> > + if (host_priv->quirks & SATA_FSL_QUIRK_V2_ERRATA) {
> > + if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
> > + for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
> > + qc = ata_qc_from_tag(ap, tag);
> > + if (qc && ata_is_atapi(qc->tf.protocol))
> {
> > + atapi_flag = 1;
> > + break;
> > + }
> > + }
> > + }
> > + }
> > +
> > + /* Workaround for data length mismatch errata */
> > + if (atapi_flag) {
>
> Seems to me like the conditionals for this code are all in the wrong
> order - adding code to the normal path.
>
> The whole lot should probably be inside:
> if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) { and the
> 'atapi_flag' boolean removed.
[S.H] OK. But I need to move the "done_mask = ioread32(hcr_base + CC);" before
these codes,
because these codes will clean command completed register.
>
> I also wonder it this is worthy of an actual quirk?
> Might be worth doing anyway.
[S.H] The quirk is useful for our internal use(there is another errata but got
fixed by silicon upgrade),
but you are right it's worth doing anyway in upstream, since the upstream code
only handles this errata.
Best Regards,
Shaohui Xie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 4/4] mfd: anatop-mfd: remove anatop driver
From: Dong Aisheng
The anatop registers are accessed via syscon now, no one will use
mfd anatop driver anymore, remove it.
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
drivers/mfd/Kconfig|8 ---
drivers/mfd/Makefile |1 -
drivers/mfd/anatop-mfd.c | 124
include/linux/mfd/anatop.h | 40 --
4 files changed, 0 insertions(+), 173 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82247b7..0b5c0cc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -985,14 +985,6 @@ config MFD_STA2X11
depends on STA2X11
select MFD_CORE
-config MFD_ANATOP
- bool "Support for Freescale i.MX on-chip ANATOP controller"
- depends on SOC_IMX6Q
- help
- Select this option to enable Freescale i.MX on-chip ANATOP
- MFD controller. This controller embeds regulator and
- thermal devices for Freescale i.MX platforms.
-
config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
depends on OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8384bc9..0f10a95 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -130,6 +130,5 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
-obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/anatop-mfd.c b/drivers/mfd/anatop-mfd.c
deleted file mode 100644
index 5576e07..000
--- a/drivers/mfd/anatop-mfd.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * Anatop MFD driver
- *
- * Copyright (C) 2012 Ying-Chun Liu (PaulLiu)
- * Copyright (C) 2012 Linaro
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-u32 anatop_read_reg(struct anatop *adata, u32 addr)
-{
- return readl(adata->ioreg + addr);
-}
-EXPORT_SYMBOL_GPL(anatop_read_reg);
-
-void anatop_write_reg(struct anatop *adata, u32 addr, u32 data, u32 mask)
-{
- u32 val;
-
- data &= mask;
-
- spin_lock(>reglock);
- val = readl(adata->ioreg + addr);
- val &= ~mask;
- val |= data;
- writel(val, adata->ioreg + addr);
- spin_unlock(>reglock);
-}
-EXPORT_SYMBOL_GPL(anatop_write_reg);
-
-static const struct of_device_id of_anatop_match[] = {
- { .compatible = "fsl,imx6q-anatop", },
- { },
-};
-
-static int __devinit of_anatop_probe(struct platform_device *pdev)
-{
- struct device *dev = >dev;
- struct device_node *np = dev->of_node;
- void *ioreg;
- struct anatop *drvdata;
-
- ioreg = of_iomap(np, 0);
- if (!ioreg)
- return -EADDRNOTAVAIL;
- drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata)
- return -ENOMEM;
- drvdata->ioreg = ioreg;
- spin_lock_init(>reglock);
- platform_set_drvdata(pdev, drvdata);
- of_platform_populate(np, NULL, NULL, dev);
-
- return 0;
-}
-
-static int __devexit of_anatop_remove(struct platform_device *pdev)
-{
- struct anatop *drvdata;
- drvdata = platform_get_drvdata(pdev);
- iounmap(drvdata->ioreg);
-
- return 0;
-}
-
-static struct platform_driver anatop_of_driver = {
- .driver = {
-
[PATCH v6 2/4] ARM: imx6q: add iomuxc gpr support into syscon
From: Dong Aisheng
Include headfile for easy using.
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog v4-v5:
* renamed: include/linux/fsl/imx6q-iomuxc-gpr.h ->
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
* a minor typo fix
---
arch/arm/boot/dts/imx6q.dtsi|5 +
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 319 +++
2 files changed, 324 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index fd57079..bea21bc 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -507,6 +507,11 @@
interrupts = <0 89 0x04 0 90 0x04>;
};
+ gpr: iomuxc-gpr@020e {
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ reg = <0x020e 0x38>;
+ };
+
iomuxc@020e {
compatible = "fsl,imx6q-iomuxc";
reg = <0x020e 0x4000>;
diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
new file mode 100644
index 000..dab34a1
--- /dev/null
+++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#ifndef __LINUX_IMX6Q_IOMUXC_GPR_H
+#define __LINUX_IMX6Q_IOMUXC_GPR_H
+
+#include
+
+#define IOMUXC_GPR00x00
+#define IOMUXC_GPR10x04
+#define IOMUXC_GPR20x08
+#define IOMUXC_GPR30x0c
+#define IOMUXC_GPR40x10
+#define IOMUXC_GPR50x14
+#define IOMUXC_GPR60x18
+#define IOMUXC_GPR70x1c
+#define IOMUXC_GPR80x20
+#define IOMUXC_GPR90x24
+#define IOMUXC_GPR10 0x28
+#define IOMUXC_GPR11 0x2c
+#define IOMUXC_GPR12 0x30
+#define IOMUXC_GPR13 0x34
+
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_MASK(0x3 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_AUDMUX_RXCLK_P7_MUXED (0x0 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_AUDMUX_RXCLK_P7 (0x1 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_SSI3_SSI_SRCK (0x2 << 30)
+#define IMX6Q_GPR0_CLOCK_8_MUX_SEL_SSI3_RX_BIT_CLK (0x3 << 30)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_MASK(0x3 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_IND_SCKR_MUXED(0x0 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_IND_SCKR (0x1 << 28)
+#define IMX6Q_GPR0_CLOCK_0_MUX_SEL_ESAI1_IPP_DO_SCKR (0x2 << 28)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_MASK(0x3 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_AUDMUX_TXCLK_P7_MUXED (0x0 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_AUDMUX_TXCLK_P7 (0x1 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_SSI3_SSI_STCK (0x2 << 26)
+#define IMX6Q_GPR0_CLOCK_B_MUX_SEL_SSI3_TX_BIT_CLK (0x3 << 26)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_MASK(0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_AUDMUX_RXCLK_P7_MUXED (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_AUDMUX_RXCLK_P7 (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_SSI3_SSI_SRCK (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_3_MUX_SEL_SSI3_RX_BIT_CLK (0x3 << 24)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_MASK(0x3 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_AUDMUX_TXCLK_P2_MUXED (0x0 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_AUDMUX_TXCLK_P2 (0x1 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_SSI2_SSI_STCK (0x2 << 22)
+#define IMX6Q_GPR0_CLOCK_A_MUX_SEL_SSI2_TX_BIT_CLK (0x3 << 22)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_MASK(0x3 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_AUDMUX_RXCLK_P2_MUXED (0x0 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_AUDMUX_RXCLK_P2 (0x1 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_SSI2_SSI_SRCK (0x2 << 20)
+#define IMX6Q_GPR0_CLOCK_2_MUX_SEL_SSI2_RX_BIT_CLK (0x3 << 20)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_MASK(0x3 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_AUDMUX_TXCLK_P1_MUXED (0x0 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_AUDMUX_TXCLK_P1 (0x1 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_SSI1_SSI_STCK (0x2 << 18)
+#define IMX6Q_GPR0_CLOCK_9_MUX_SEL_SSI1_SSI_TX_BIT_CLK (0x3 << 18)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_MASK(0x3 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_AUDMUX_RXCLK_P1_MUXED (0x0 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_AUDMUX_RXCLK_P1 (0x1 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_SSI1_SSI_SRCK (0x2 << 16)
+#define IMX6Q_GPR0_CLOCK_1_MUX_SEL_SSI1_SSI_RX_BIT_CLK (0x3 << 16)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_MASK(0x3 << 14)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_ASRCK_CLK1 (0x0 << 14)
+#define IMX6Q_GPR0_TX_CLK2_MUX_SEL_ASRCK_CLK2
[PATCH v6 3/4] regulator: anatop-regulator: convert to use syscon to access anatop register
From: Dong Aisheng
Using syscon to access anatop register.
Acked-by: Mark Brown
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog v5->v6:
* of_node_put after using syscon_node_to_regmap
ChangeLog v4->v5:
* merge patch 3,4,5,6 to avoid break bisect.
ChangeLog v2->v3:
* update to use syscon_node_to_regmap and use of_get_parent to get anatop node.
ChangeLog v1-v2:
* update to use generic regmap api
---
arch/arm/boot/dts/imx6q.dtsi |4 +-
arch/arm/mach-imx/Kconfig|2 +-
arch/arm/mach-imx/mach-imx6q.c | 47 +-
drivers/regulator/Kconfig|2 +-
drivers/regulator/anatop-regulator.c | 31 +++---
5 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index bea21bc..52ed4d1 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -378,8 +378,8 @@
interrupts = <0 87 0x04 0 88 0x04>;
};
- anatop@020c8000 {
- compatible = "fsl,imx6q-anatop";
+ anatop: anatop@020c8000 {
+ compatible = "fsl,imx6q-anatop", "syscon",
"simple-bus";
reg = <0x020c8000 0x1000>;
interrupts = <0 49 0x04 0 54 0x04 0 127 0x04>;
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..7bba253 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -839,7 +839,7 @@ config SOC_IMX6Q
select HAVE_IMX_MMDC
select HAVE_IMX_SRC
select HAVE_SMP
- select MFD_ANATOP
+ select MFD_SYSCON
select PINCTRL
select PINCTRL_IMX6Q
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 045b3f6..eaf56b4 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -24,8 +24,9 @@
#include
#include
#include
+#include
#include
-#include
+#include
#include
#include
#include
@@ -120,20 +121,7 @@ static void __init imx6q_sabrelite_init(void)
static void __init imx6q_usb_init(void)
{
- struct device_node *np;
- struct platform_device *pdev = NULL;
- struct anatop *adata = NULL;
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
- if (np)
- pdev = of_find_device_by_node(np);
- if (pdev)
- adata = platform_get_drvdata(pdev);
- if (!adata) {
- if (np)
- of_node_put(np);
- return;
- }
+ struct regmap *anatop;
#define HW_ANADIG_USB1_CHRG_DETECT 0x01b0
#define HW_ANADIG_USB2_CHRG_DETECT 0x0210
@@ -141,20 +129,21 @@ static void __init imx6q_usb_init(void)
#define BM_ANADIG_USB_CHRG_DETECT_EN_B 0x0010
#define BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B 0x0008
- /*
-* The external charger detector needs to be disabled,
-* or the signal at DP will be poor
-*/
- anatop_write_reg(adata, HW_ANADIG_USB1_CHRG_DETECT,
- BM_ANADIG_USB_CHRG_DETECT_EN_B
- | BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B,
- ~0);
- anatop_write_reg(adata, HW_ANADIG_USB2_CHRG_DETECT,
- BM_ANADIG_USB_CHRG_DETECT_EN_B |
- BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B,
- ~0);
-
- of_node_put(np);
+ anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
+ if (!IS_ERR(anatop)) {
+ /*
+* The external charger detector needs to be disabled,
+* or the signal at DP will be poor
+*/
+ regmap_write(anatop, HW_ANADIG_USB1_CHRG_DETECT,
+ BM_ANADIG_USB_CHRG_DETECT_EN_B
+ | BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
+ regmap_write(anatop, HW_ANADIG_USB2_CHRG_DETECT,
+ BM_ANADIG_USB_CHRG_DETECT_EN_B |
+ BM_ANADIG_USB_CHRG_DETECT_CHK_CHRG_B);
+ } else {
+ pr_warn("failed to find fsl,imx6q-anatop regmap\n");
+ }
}
static void __init imx6q_init_machine(void)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 4e932cc..2ae1d97 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -112,7 +112,7 @@ config REGULATOR_DA9052
config REGULATOR_ANATOP
tristate "Freescale i.MX on-chip ANATOP LDO regulators"
- depends on MFD_ANATOP
+ depends on MFD_SYSCON
help
Say y here to support Freescale i.MX on-chip ANATOP LDOs
regulators. It is recommended that this option be
diff --git a/drivers/regulator/anatop-regulator.c
[PATCH v6 1/4] mfd: add syscon driver based on regmap
From: Dong Aisheng
Add regmap based syscon driver.
This is usually used for access misc bits in registers which does not belong
to a specific module, for example, IMX IOMUXC GPR and ANATOP.
With this driver, client can use generic regmap API to access registers
which are registered into syscon.
Reviewed-by: Mark Brown
Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
---
ChangeLog:
v5->v6:
* using dev instead of >dev in probe
v4->v5:
* depends on OF
* do not call of_node_put in syscon_node_to_regmap
v3->v4:
* add more description about syscon(provided by Stephen Warren) in binding doc.
* fix a minor code indent error and remove set cache type code since the cache
is disabled by default.
v2->v3:
* export regmap lookup APIs including syscon_node_to_regmap
* fix a few typo
v1->v2:
* provide a way of retrieving the regmap, suggested by Mark Brown.
* delete imx-syscon io accessors and using generic regmap API for client
drivers.
* change to a more generic name for other SoCs to use.
---
Documentation/devicetree/bindings/mfd/syscon.txt | 20 +++
drivers/mfd/Kconfig |8 +
drivers/mfd/Makefile |1 +
drivers/mfd/syscon.c | 176 ++
include/linux/mfd/syscon.h | 23 +++
5 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
b/Documentation/devicetree/bindings/mfd/syscon.txt
new file mode 100644
index 000..fe8150b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/syscon.txt
@@ -0,0 +1,20 @@
+* System Controller Registers R/W driver
+
+System controller node represents a register region containing a set
+of miscellaneous registers. The registers are not cohesive enough to
+represent as any specific type of device. The typical use-case is for
+some other node's driver, or platform-specific code, to acquire a
+reference to the syscon node (e.g. by phandle, node path, or search
+using a specific compatible value), interrogate the node (or associated
+OS driver) to determine the location of the registers, and access the
+registers directly.
+
+Required properties:
+- compatible: Should contain "syscon".
+- reg: the register region can be accessed from syscon
+
+Examples:
+gpr: iomuxc-gpr@020e {
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ reg = <0x020e 0x38>;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..82247b7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -993,6 +993,14 @@ config MFD_ANATOP
MFD controller. This controller embeds regulator and
thermal devices for Freescale i.MX platforms.
+config MFD_SYSCON
+ bool "System Controller Register R/W Based on Regmap"
+ depends on OF
+ select REGMAP_MMIO
+ help
+ Select this option to enable accessing system control registers
+ via regmap.
+
config MFD_PALMAS
bool "Support for the TI Palmas series chips"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..8384bc9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -131,4 +131,5 @@ obj-$(CONFIG_MFD_PALMAS)+= palmas.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
+obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
new file mode 100644
index 000..65fe609
--- /dev/null
+++ b/drivers/mfd/syscon.c
@@ -0,0 +1,176 @@
+/*
+ * System Control Driver
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Linaro Ltd.
+ *
+ * Author: Dong Aisheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct platform_driver syscon_driver;
+
+struct syscon {
+ struct device *dev;
+ void __iomem *base;
+ struct regmap *regmap;
+};
+
+static int syscon_match(struct device *dev, void *data)
+{
+ struct syscon *syscon = dev_get_drvdata(dev);
+ struct device_node *dn = data;
+
+ return (syscon->dev->of_node == dn) ? 1 : 0;
+}
+
+struct regmap *syscon_node_to_regmap(struct device_node *np)
+{
+ struct syscon *syscon;
+ struct device *dev;
+
+ dev = driver_find_device(_driver.driver, NULL, np,
+syscon_match);
+ if (!dev)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ syscon = dev_get_drvdata(dev);
+
+ return syscon->regmap;
+}
[PATCH v6 0/4] add syscon driver based on regmap for general registers access
This patch series mainly adds an syscon driver which is used to access general system controller registers like FSL IOMUXC GPR and ANATOP, after that, we convert all the exist private access general registers code to use standard API from regmap to access registers. Finally we remove the old mfd anatop driver which is only for anatop register access. The patch series is based on linus's tree 3.6-rc4 since commit 5b716ac. ChangeLog v5->v6: * put node after call syscon_node_to_regmap in anatop regulator driver * using dev instead of >dev in syscon probe ChangeLog v4->v5: * change syscon driver depends on OF * do not call of_node_put in syscon_node_to_regmap * renamed: include/linux/fsl/imx6q-iomuxc-gpr.h -> include/linux/mfd/syscon/imx6q-iomuxc-gpr.h ChangeLog v3->v4: Only '[PATCH v4 1/7] mfd: add syscon driver based on regmap' is changed. Dong Aisheng (4): mfd: add syscon driver based on regmap ARM: imx6q: add iomuxc gpr support into syscon regulator: anatop-regulator: convert to use syscon to access anatop register mfd: anatop-mfd: remove anatop driver Documentation/devicetree/bindings/mfd/syscon.txt | 20 ++ arch/arm/boot/dts/imx6q.dtsi |9 +- arch/arm/mach-imx/Kconfig|2 +- arch/arm/mach-imx/mach-imx6q.c | 47 ++-- drivers/mfd/Kconfig | 12 +- drivers/mfd/Makefile |2 +- drivers/mfd/anatop-mfd.c | 124 - drivers/mfd/syscon.c | 176 drivers/regulator/Kconfig|2 +- drivers/regulator/anatop-regulator.c | 31 ++- include/linux/mfd/anatop.h | 40 --- include/linux/mfd/syscon.h | 23 ++ include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 319 ++ 13 files changed, 593 insertions(+), 214 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/syscon.txt delete mode 100644 drivers/mfd/anatop-mfd.c create mode 100644 drivers/mfd/syscon.c delete mode 100644 include/linux/mfd/anatop.h create mode 100644 include/linux/mfd/syscon.h create mode 100644 include/linux/mfd/syscon/imx6q-iomuxc-gpr.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/
linux-next: manual merge of the spi-mb tree with the mmc tree
Hi Mark,
Today's linux-next merge of the spi-mb tree got a conflict in
drivers/mmc/host/mxs-mmc.c between commit fc108d24d3a6 ("mmc: mxs-mmc:
fix deadlock caused by recursion loop") from the mmc tree and commit
829c1bf40b92 ("mmc: spi: Pull out parts shared between MMC and SPI") from
the spi-mb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/mmc/host/mxs-mmc.c
index ad3fcea,4da9966..000
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@@ -281,12 -193,10 +193,12 @@@ static irqreturn_t mxs_mmc_irq_handler(
spin_lock(>lock);
- stat = readl(host->base + HW_SSP_CTRL1(host));
+ stat = readl(ssp->base + HW_SSP_CTRL1(ssp));
writel(stat & MXS_MMC_IRQ_BITS,
- host->base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_CLR);
+ ssp->base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_CLR);
+ spin_unlock(>lock);
+
if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN))
mmc_signal_sdio_irq(host->mmc);
@@@ -641,22 -523,22 +523,22 @@@ static void mxs_mmc_enable_sdio_irq(str
if (enable) {
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
- host->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
+ ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
- host->base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_SET);
+ ssp->base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_SET);
-
- if (readl(ssp->base + HW_SSP_STATUS(ssp)) &
- BM_SSP_STATUS_SDIO_IRQ)
- mmc_signal_sdio_irq(host->mmc);
-
} else {
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
- host->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
+ ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
- host->base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_CLR);
+ ssp->base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_CLR);
}
spin_unlock_irqrestore(>lock, flags);
+
- if (enable && readl(host->base + HW_SSP_STATUS(host)) &
++ if (enable && readl(ssp->base + HW_SSP_STATUS(ssp)) &
+ BM_SSP_STATUS_SDIO_IRQ)
+ mmc_signal_sdio_irq(host->mmc);
+
}
static const struct mmc_host_ops mxs_mmc_ops = {
pgpCPw2DDq4Sn.pgp
Description: PGP signature
Re: [PATCH v2 3/6] device_cgroup: convert device_cgroup internally to policy + exceptions
Quoting Aristeu Rozanski (a...@redhat.com):
> The original model of device_cgroup is having a whitelist where all the
> allowed devices are listed. The problem with this approach is that is
> impossible to have the case of allowing everything but few devices.
>
> The reason for that lies in the way the whitelist is handled internally:
> since there's only a whitelist, the "all devices" entry would have to be
> removed and replaced by the entire list of possible devices but the ones
> that are being denied. Since dev_t is 32 bits long, representing the allowed
> devices as a bitfield is not memory efficient.
>
> This patch replaces the "whitelist" by a "exceptions" list and the default
> policy is kept as "behavior" variable in dev_cgroup structure.
>
> The current interface determines that whenever "a" is written to devices.allow
> or devices.deny, the entry masking all devices will be added or removed,
> respectively. This behavior is kept and it's what will determine the default
> policy:
>
> # cat devices.list
> a *:* rwm
> # echo a >devices.deny
> # cat devices.list
> # echo a >devices.allow
> # cat devices.list
> a *:* rwm
>
> The interface is also preserved. For example, if one wants to block only
> access
> to /dev/null:
> # ls -l /dev/null
> crw-rw-rw- 1 root root 1, 3 Jul 24 16:17 /dev/null
> # echo a >devices.allow
> # echo "c 1:3 rwm" >devices.deny
> # cat /dev/null
> cat: /dev/null: Operation not permitted
> # echo >/dev/null
> bash: /dev/null: Operation not permitted
> # mknod /tmp/null c 1 3
> mknod: /tmp/null: Operation not permitted
> # echo "c 1:3 r" >devices.allow
> # cat /dev/null
> # echo >/dev/null
> bash: /dev/null: Operation not permitted
> # mknod /tmp/null c 1 3
> mknod: /tmp/null: Operation not permitted
> # echo "c 1:3 rw" >devices.allow
> # echo >/dev/null
> # cat /dev/null
> # mknod /tmp/null c 1 3
> mknod: /tmp/null: Operation not permitted
> # echo "c 1:3 rwm" >devices.allow
> # echo >/dev/null
> # cat /dev/null
> # mknod /tmp/null c 1 3
> #
>
> Note that I didn't rename the functions/variables in this patch, but in the
> next one to make reviewing easier.
>
> v2:
> - convert code to use behavior instead of deny_all
(Note - I'm going by the changelog which says use of 'behavior' instead
of deny_all is the only difference from v1)
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: James Morris
> Cc: Pavel Emelyanov
> Cc: Serge Hallyn
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> ---
> security/device_cgroup.c | 228
> +++
> 1 file changed, 132 insertions(+), 96 deletions(-)
>
> Index: github/security/device_cgroup.c
> ===
> --- github.orig/security/device_cgroup.c 2012-08-21 10:50:37.526892088
> -0400
> +++ github/security/device_cgroup.c 2012-08-21 10:50:48.967215436 -0400
> @@ -99,7 +99,6 @@
> return -ENOMEM;
> }
>
> -/* Stupid prototype - don't bother combining existing entries */
> /*
> * called under devcgroup_mutex
> */
> @@ -139,16 +138,13 @@
> struct dev_whitelist_item *walk, *tmp;
>
> list_for_each_entry_safe(walk, tmp, _cgroup->whitelist, list) {
> - if (walk->type == DEV_ALL)
> - goto remove;
> if (walk->type != wh->type)
> continue;
> - if (walk->major != ~0 && walk->major != wh->major)
> + if (walk->major != wh->major)
> continue;
> - if (walk->minor != ~0 && walk->minor != wh->minor)
> + if (walk->minor != wh->minor)
> continue;
>
> -remove:
> walk->access &= ~wh->access;
> if (!walk->access) {
> list_del_rcu(>list);
> @@ -188,19 +184,9 @@
> INIT_LIST_HEAD(_cgroup->whitelist);
> parent_cgroup = cgroup->parent;
>
> - if (parent_cgroup == NULL) {
> - struct dev_whitelist_item *wh;
> - wh = kmalloc(sizeof(*wh), GFP_KERNEL);
> - if (!wh) {
> - kfree(dev_cgroup);
> - return ERR_PTR(-ENOMEM);
> - }
> - wh->minor = wh->major = ~0;
> - wh->type = DEV_ALL;
> - wh->access = ACC_MASK;
> + if (parent_cgroup == NULL)
> dev_cgroup->behavior = DEVCG_DEFAULT_ALLOW;
> - list_add(>list, _cgroup->whitelist);
> - } else {
> + else {
> parent_dev_cgroup = cgroup_to_devcgroup(parent_cgroup);
> mutex_lock(_mutex);
> ret = dev_whitelist_copy(_cgroup->whitelist,
> @@ -271,33 +257,48 @@
> char maj[MAJMINLEN], min[MAJMINLEN], acc[ACCLEN];
>
> rcu_read_lock();
> -
Re: [PATCH v2 2/6] device_cgroup: introduce dev_whitelist_clean()
Quoting Aristeu Rozanski (a...@redhat.com):
> This function cleans all the items in a whitelist and will be used by the next
> patches.
>
> v2:
> - no changes
>
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: James Morris
> Cc: Pavel Emelyanov
> Cc: Serge Hallyn
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> ---
> security/device_cgroup.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> Index: github/security/device_cgroup.c
> ===
> --- github.orig/security/device_cgroup.c 2012-08-21 10:50:34.650810797
> -0400
> +++ github/security/device_cgroup.c 2012-08-21 10:50:37.526892088 -0400
> @@ -157,6 +157,22 @@
> }
> }
>
> +/**
> + * dev_whitelist_clean - frees all entries of the whitelist
> + * @dev_cgroup: dev_cgroup with the whitelist to be cleaned
> + *
> + * called under devcgroup_mutex
> + */
> +static void dev_whitelist_clean(struct dev_cgroup *dev_cgroup)
> +{
> + struct dev_whitelist_item *wh, *tmp;
> +
> + list_for_each_entry_safe(wh, tmp, _cgroup->whitelist, list) {
> + list_del(>list);
> + kfree(wh);
> + }
> +}
> +
> /*
> * called from kernel/cgroup.c with cgroup_lock() held.
> */
> @@ -203,13 +219,9 @@
> static void devcgroup_destroy(struct cgroup *cgroup)
> {
> struct dev_cgroup *dev_cgroup;
> - struct dev_whitelist_item *wh, *tmp;
>
> dev_cgroup = cgroup_to_devcgroup(cgroup);
> - list_for_each_entry_safe(wh, tmp, _cgroup->whitelist, list) {
> - list_del(>list);
> - kfree(wh);
> - }
> + dev_whitelist_clean(dev_cgroup);
> kfree(dev_cgroup);
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] device_cgroup: add "behavior" in dev_cgroup structure
Quoting Aristeu Rozanski (a...@redhat.com):
> behavior will determine if the default policy is to deny all device access
> unless for the ones in the exception list.
>
> This variable will be used in the next patches to convert device_cgroup
> internally into a default policy + rules.
>
> v2:
> - renamed deny_all to behavior
>
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: James Morris
> Cc: Pavel Emelyanov
> Cc: Serge Hallyn
Acked-by: Serge Hallyn
> Signed-off-by: Aristeu Rozanski
>
> ---
> security/device_cgroup.c |8
> 1 file changed, 8 insertions(+)
>
> Index: github/security/device_cgroup.c
> ===
> --- github.orig/security/device_cgroup.c 2012-08-21 09:49:38.698415513
> -0400
> +++ github/security/device_cgroup.c 2012-08-21 10:50:34.650810797 -0400
> @@ -42,6 +42,10 @@
> struct dev_cgroup {
> struct cgroup_subsys_state css;
> struct list_head whitelist;
> + enum {
> + DEVCG_DEFAULT_ALLOW,
> + DEVCG_DEFAULT_DENY,
> + } behavior;
> };
>
> static inline struct dev_cgroup *css_to_devcgroup(struct cgroup_subsys_state
> *s)
> @@ -178,12 +182,14 @@
> wh->minor = wh->major = ~0;
> wh->type = DEV_ALL;
> wh->access = ACC_MASK;
> + dev_cgroup->behavior = DEVCG_DEFAULT_ALLOW;
> list_add(>list, _cgroup->whitelist);
> } else {
> parent_dev_cgroup = cgroup_to_devcgroup(parent_cgroup);
> mutex_lock(_mutex);
> ret = dev_whitelist_copy(_cgroup->whitelist,
> _dev_cgroup->whitelist);
> + dev_cgroup->behavior = parent_dev_cgroup->behavior;
> mutex_unlock(_mutex);
> if (ret) {
> kfree(dev_cgroup);
> @@ -409,9 +415,11 @@
> case DEVCG_ALLOW:
> if (!parent_has_perm(devcgroup, ))
> return -EPERM;
> + devcgroup->behavior = DEVCG_DEFAULT_ALLOW;
> return dev_whitelist_add(devcgroup, );
> case DEVCG_DENY:
> dev_whitelist_rm(devcgroup, );
> + devcgroup->behavior = DEVCG_DEFAULT_DENY;
> break;
> default:
> return -EINVAL;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc: fix personality handling in ppc64_personality()
On Thu, 2012-08-02 at 09:10 +0200, Jiri Kosina wrote: > Directly comparing current->personality against PER_LINUX32 doesn't work > in cases when any of the personality flags stored in the top three bytes > are used. > > Directly forcefully setting personality to PER_LINUX32 or PER_LINUX > discards any flags stored in the top three bytes > > Use personality() macro to compare only PER_MASK bytes and make sure that > we are setting only the bits that should be set, instead of > overwriting the whole value. > > Signed-off-by: Jiri Kosina > --- > > changed since v1: fix the bit ops to reflect the fact that PER_LINUX is > actually 0 Had already merged v1 (oops.. didn't spot the issue with PER_LINUX being 0). Can you send an incremental fixup ? Cheers, Ben. > arch/powerpc/kernel/syscalls.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c > index f2496f2..dc1558e 100644 > --- a/arch/powerpc/kernel/syscalls.c > +++ b/arch/powerpc/kernel/syscalls.c > @@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality) > long ret; > > if (personality(current->personality) == PER_LINUX32 > - && personality == PER_LINUX) > - personality = PER_LINUX32; > + && personality(personality) == PER_LINUX) > + personality |= PER_LINUX32; > ret = sys_personality(personality); > - if (ret == PER_LINUX32) > - ret = PER_LINUX; > + if (personality(ret) == PER_LINUX32) > + ret &= ~PER_LINUX32; > return ret; > } > #endif > -- > 1.7.3.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] slab: fix the DEADLOCK issue on l3 alien lock
From: Michael Wang DEADLOCK will be report while running a kernel with NUMA and LOCKDEP enabled, the process of this fake report is: kmem_cache_free()//free obj in cachep -> cache_free_alien() //acquire cachep's l3 alien lock -> __drain_alien_cache() -> free_block() -> slab_destroy() -> kmem_cache_free()//free slab in cachep->slabp_cache -> cache_free_alien() //acquire cachep->slabp_cache's l3 alien lock Since the cachep and cachep->slabp_cache's l3 alien are in the same lock class, fake report generated. This should not happen since we already have init_lock_keys() which will reassign the lock class for both l3 list and l3 alien. However, init_lock_keys() was invoked at a wrong position which is before we invoke enable_cpucache() on each cache. Since until set slab_state to be FULL, we won't invoke enable_cpucache() on caches to build their l3 alien while creating them, so although we invoked init_lock_keys(), the l3 alien lock class won't change since we don't have them until invoked enable_cpucache() later. This patch will invoke init_lock_keys() after we done enable_cpucache() instead of before to avoid the fake DEADLOCK report. Signed-off-by: Michael Wang --- mm/slab.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index d4715e5..cc679ef 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -1780,9 +1780,6 @@ void __init kmem_cache_init_late(void) slab_state = UP; - /* Annotate slab for lockdep -- annotate the malloc caches */ - init_lock_keys(); - /* 6) resize the head arrays to their final sizes */ mutex_lock(_mutex); list_for_each_entry(cachep, _caches, list) @@ -1790,6 +1787,9 @@ void __init kmem_cache_init_late(void) BUG(); mutex_unlock(_mutex); + /* Annotate slab for lockdep -- annotate the malloc caches */ + init_lock_keys(); + /* Done! */ slab_state = FULL; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/4] PCI: Add support for non-BAR ROMs
On Tue, Sep 04, 2012 at 10:18:48PM -0400, Don Dutile wrote:
> > /*
> >+ * Some devices may provide ROMs via a source other than the BAR
> >+ */
> >+if (pdev->rom&& pdev->romlen) {
> >+*size = pdev->romlen;
> >+return phys_to_virt((phys_addr_t)pdev->rom);
>^
> ioremap_nocache() ? ... or is caching rom ok?
If it's appearing through this pathway then it's not actually in ROM,
the platform has pulled it out of somewhere else.
--
Matthew Garrett | mj...@srcf.ucam.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 V4 05/10] Tools: hv: Add an example script to retrieve dhcp state
> -Original Message- > From: devel [mailto:devel-boun...@linuxdriverproject.org] On Behalf Of KY > Srinivasan > Sent: Tuesday, September 04, 2012 8:29 PM > To: Greg KH > Cc: o...@aepfle.de; tho...@redhat.com; linux-kernel@vger.kernel.org; > d...@redhat.com; a...@canonical.com; de...@linuxdriverproject.org; > b...@decadent.org.uk > Subject: RE: [PATCH V4 05/10] Tools: hv: Add an example script to retrieve > dhcp > state > > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Tuesday, September 04, 2012 8:04 PM > > To: KY Srinivasan > > Cc: o...@aepfle.de; tho...@redhat.com; linux-kernel@vger.kernel.org; > > d...@redhat.com; a...@canonical.com; de...@linuxdriverproject.org; > > b...@decadent.org.uk > > Subject: Re: [PATCH V4 05/10] Tools: hv: Add an example script to retrieve > > dhcp > > state > > > > On Tue, Sep 04, 2012 at 11:39:12PM +, KY Srinivasan wrote: > > > > > > > > > > -Original Message- > > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > > Sent: Tuesday, September 04, 2012 6:59 PM > > > > To: KY Srinivasan > > > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > > o...@aepfle.de; > > > > a...@canonical.com; b...@decadent.org.uk; tho...@redhat.com; > > > > d...@redhat.com > > > > Subject: Re: [PATCH V4 05/10] Tools: hv: Add an example script to > > > > retrieve > > dhcp > > > > state > > > > > > > > On Tue, Sep 04, 2012 at 02:46:37PM -0700, K. Y. Srinivasan wrote: > > > > > To keep the KVP daemon code free of distro specific details, we > > > > > invoke an > > > > > external script to retrieve the DHCP state. This is an example script > > > > > that > > > > > was used to test the KVP code. This script has to be implemented in a > Distro > > > > > specific fashion. For instance on distros that ship with Network > > > > > Manager > > > > enabled, > > > > > this script can be based on NM APIs. > > > > > > > > > > Signed-off-by: K. Y. Srinivasan > > > > > Reviewed-by: Haiyang Zhang > > > > > --- > > > > > tools/hv/hv_get_dhcp_info.sh | 25 + > > > > > 1 files changed, 25 insertions(+), 0 deletions(-) > > > > > create mode 100755 tools/hv/hv_get_dhcp_info.sh > > > > > > > > > > diff --git a/tools/hv/hv_get_dhcp_info.sh > b/tools/hv/hv_get_dhcp_info.sh > > > > > new file mode 100755 > > > > > index 000..3de4587 > > > > > --- /dev/null > > > > > +++ b/tools/hv/hv_get_dhcp_info.sh > > > > > @@ -0,0 +1,25 @@ > > > > > +#!/bin/bash > > > > > + > > > > > +# This example script retrieves the DHCP state of a given interface. > > > > > +# In the interest of keeping the KVP daemon code free of distro > > > > > specific > > > > > +# information; the kvp daemon code invokes this external script to > gather > > > > > +# DHCP setting for the specific interface. > > > > > +# > > > > > +# Input: Name of the interface > > > > > +# > > > > > +# Output: The script prints the string "Enabled" to stdout to > > > > > indicate > > > > > +#that DHCP is enabled on the interface. > > > > > > > > What happens if DHCP is not enabled on the interface? Shouldn't that > > > > also return something other than "success"? > > > > > > The script is expected to write "Enabled" to stdout to indicate if DHCP is > > enabled; if this > > > is not the case, implicitly we assume DHCP is not enabled (since this is > > > a binary > > state). > > > > It's not really "binary" given that you are expecting "Enabled" or > > nothing, right? "Disabled" would make a bit more sense perhaps? > > In the KVP daemon code, I currently only check for "Enabled" to see if > DHCP is enabled. > > > > > Having a script return "nothing at all" to show the failure of a state > > doesn't seem the wisest thing, does it? > > I can certainly resubmit this patch with the change you are suggesting. This > patch > adds a new file > and does not impact any of the other patches that follows this. Would you want > me to resubmit all of the > remaining patches starting with this one. I have resent this patch with the change you have suggested. Since this patch is a standalone patch I have not resent the other patches that follow this patch. Let me know if you want me to resend the remaining patches. Regards, K. Y > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 05/10] Tools: hv: Add an example script to retrieve dhcp state
To keep the KVP daemon code free of distro specific details, we invoke an external script to retrieve the DHCP state. This is an example script that was used to test the KVP code. This script has to be implemented in a Distro specific fashion. For instance on distros that ship with Network Manager enabled, this script can be based on NM APIs. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang --- tools/hv/hv_get_dhcp_info.sh | 28 1 files changed, 28 insertions(+), 0 deletions(-) create mode 100755 tools/hv/hv_get_dhcp_info.sh diff --git a/tools/hv/hv_get_dhcp_info.sh b/tools/hv/hv_get_dhcp_info.sh new file mode 100755 index 000..ccd3e95 --- /dev/null +++ b/tools/hv/hv_get_dhcp_info.sh @@ -0,0 +1,28 @@ +#!/bin/bash + +# This example script retrieves the DHCP state of a given interface. +# In the interest of keeping the KVP daemon code free of distro specific +# information; the kvp daemon code invokes this external script to gather +# DHCP setting for the specific interface. +# +# Input: Name of the interface +# +# Output: The script prints the string "Enabled" to stdout to indicate +# that DHCP is enabled on the interface. If DHCP is not enabled, +# the script prints the string "Disabled" to stdout. +# +# Each Distro is expected to implement this script in a distro specific +# fashion. For instance on Distros that ship with Network Manager enabled, +# this script can be based on the Network Manager APIs for retrieving DHCP +# information. + +if_file="/etc/sysconfig/network-scripts/ifcfg-"$1 + +dhcp=$(grep "dhcp" $if_file 2>/dev/null) + +if [ "$dhcp" != "" ]; +then +echo "Enabled" +else +echo "Disabled" +fi -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] HID: hid-lcpower: Use HID_UP_LOGIVENDOR instead of hard coded 0x0ffbc0000
Signed-off-by: Axel Lin
---
drivers/hid/hid-lcpower.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lcpower.c b/drivers/hid/hid-lcpower.c
index c4fe9bd0..22bc14a 100644
--- a/drivers/hid/hid-lcpower.c
+++ b/drivers/hid/hid-lcpower.c
@@ -24,7 +24,7 @@ static int ts_input_mapping(struct hid_device *hdev, struct
hid_input *hi,
struct hid_field *field, struct hid_usage *usage,
unsigned long **bit, int *max)
{
- if ((usage->hid & HID_USAGE_PAGE) != 0x0ffbc)
+ if ((usage->hid & HID_USAGE_PAGE) != HID_UP_LOGIVENDOR)
return 0;
switch (usage->hid & HID_USAGE) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/4] PCI: Add support for non-BAR ROMs
On 08/23/2012 12:36 PM, Matthew Garrett wrote:
Platforms may provide their own mechanisms for obtaining ROMs. Add support
for using data provided by the platform in that case.
Signed-off-by: Matthew Garrett
---
drivers/pci/rom.c | 11 +--
include/linux/pci.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 48ebdb2..46026e4 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -118,11 +118,17 @@ void __iomem *pci_map_rom(struct pci_dev *pdev, size_t
*size)
void __iomem *rom;
/*
+* Some devices may provide ROMs via a source other than the BAR
+*/
+ if (pdev->rom&& pdev->romlen) {
+ *size = pdev->romlen;
+ return phys_to_virt((phys_addr_t)pdev->rom);
^
ioremap_nocache() ? ... or is caching rom ok?
+ /*
* IORESOURCE_ROM_SHADOW set on x86, x86_64 and IA64 supports legacy
* memory map if the VGA enable bit of the Bridge Control register is
* set for embedded VGA.
*/
- if (res->flags& IORESOURCE_ROM_SHADOW) {
+ } else if (res->flags& IORESOURCE_ROM_SHADOW) {
/* primary video rom always starts here */
start = (loff_t)0xC;
*size = 0x2; /* cover C000:0 through E000:0 */
@@ -219,7 +225,8 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom)
if (res->flags& (IORESOURCE_ROM_COPY | IORESOURCE_ROM_BIOS_COPY))
return;
- iounmap(rom);
+ if (!pdev->rom || !pdev->romlen)
+ iounmap(rom);
/* Disable again before continuing, leave enabled if pci=rom */
if (!(res->flags& (IORESOURCE_ROM_ENABLE | IORESOURCE_ROM_SHADOW)))
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6a2625c..2668bb9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -355,6 +355,8 @@ struct pci_dev {
};
struct pci_ats *ats; /* Address Translation Service */
#endif
+ void *rom; /* Physical pointer to ROM if it's not from the BAR */
+ size_t romlen; /* Length of ROM if it's not from the BAR */
};
static inline struct pci_dev *pci_physfn(struct pci_dev *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] perf: allow user to indicate path to objdump in command line
On Tue, 2012-09-04 at 10:05 -0600, David Ahern wrote: > On 9/4/12 4:32 AM, Maciek Borzecki wrote: > > When analyzing perf data from hosts of other architecture than one of the > > local > > host it's useful to call objdump that is part of a toolchain for that > > architecture. Instead of calling regular objdump, call one that user > > specified > > in command line. > > Why not set the PATH to make the toolchain's version the one used by perf? At least one reason is that cross toolchains are usually built such that the resulting binaries are called -objdump, -gcc etc. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Make the generic clock API available by default
On Tue, 2012-08-28 at 13:35 -0700, Mark Brown wrote: > Rather than requiring platforms to select the generic clock API to make > it available make the API available as a user selectable option unless the > user either selects HAVE_CUSTOM_CLK (if they have their own implementation) > or selects COMMON_CLK (if they depend on the generic implementation). > > All current architectures that HAVE_CLK but don't use the common clock > framework have selects of HAVE_CUSTOM_CLK added. > > This allows drivers to use the generic API on platforms which have no need > for the clock API at platform level. > > Signed-off-by: Mark Brown > --- For powerpc: Acked-by: Benjamin Herrenschmidt Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the vfs tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/socket.c between commits f8a78429cc70 ("take descriptor handling from
sock_alloc_file() to callers") and 32b529f92ea7 ("unexport sock_map_fd(),
switch to sock_alloc_file()") from the vfs tree and commit 600e177920df
("net: Providing protocol type via system.sockprotoname xattr
of /proc/PID/fd entries") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. I also had
to add this merge fix patch:
From: Stephen Rothwell
Date: Wed, 5 Sep 2012 11:52:06 +1000
Subject: [PATCH] net: cope with sock_alloc_file() API change
Signed-off-by: Stephen Rothwell
---
include/linux/net.h |3 ++-
net/9p/trans_fd.c |2 +-
net/sctp/socket.c |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index c8a9708..a3831f3 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -247,7 +247,8 @@ extern int sock_sendmsg(struct socket *sock,
struct msghdr *msg,
size_t len);
extern int sock_recvmsg(struct socket *sock, struct msghdr *msg,
size_t size, int flags);
-extern struct file *sock_alloc_file(struct socket *sock, int flags);
+extern struct file *sock_alloc_file(struct socket *sock, int flags,
+const char *dname);
extern struct socket *sockfd_lookup(int fd, int *err);
extern struct socket *sock_from_file(struct file *file, int *err);
#define sockfd_put(sock) fput(sock->file)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 8c4e0b5..1c8b557 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -801,7 +801,7 @@ static int p9_socket_open(struct p9_client *client, struct
socket *csocket)
return -ENOMEM;
csocket->sk->sk_allocation = GFP_NOIO;
- file = sock_alloc_file(csocket, 0);
+ file = sock_alloc_file(csocket, 0, NULL);
if (IS_ERR(file)) {
pr_err("%s (%d): failed to map fd\n",
__func__, task_pid_nr(current));
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 5ba739e..59d16ea 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4313,7 +4313,7 @@ static int sctp_getsockopt_peeloff(struct sock *sk, int
len, char __user *optval
goto out;
}
- newfile = sock_alloc_file(newsock, 0);
+ newfile = sock_alloc_file(newsock, 0, NULL);
if (unlikely(IS_ERR(newfile))) {
put_unused_fd(retval);
sock_release(newsock);
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/socket.c
index 79170dc,977c0f4..000
--- a/net/socket.c
+++ b/net/socket.c
@@@ -346,15 -347,30 +347,23 @@@ static struct file_system_type sock_fs_
*but we take care of internal coherence yet.
*/
- struct file *sock_alloc_file(struct socket *sock, int flags)
-static int sock_alloc_file(struct socket *sock, struct file **f, int flags,
- const char *dname)
++struct file *sock_alloc_file(struct socket *sock, int flags,
++ const char *dname)
{
struct qstr name = { .name = "" };
struct path path;
struct file *file;
- int fd;
-
- fd = get_unused_fd_flags(flags);
- if (unlikely(fd < 0))
- return fd;
+ if (dname) {
+ name.name = dname;
+ name.len = strlen(name.name);
+ } else if (sock->sk) {
+ name.name = sock->sk->sk_prot_creator->name;
+ name.len = strlen(name.name);
+ }
path.dentry = d_alloc_pseudo(sock_mnt->mnt_sb, );
- if (unlikely(!path.dentry)) {
- put_unused_fd(fd);
- return -ENOMEM;
- }
+ if (unlikely(!path.dentry))
+ return ERR_PTR(-ENOMEM);
path.mnt = mntget(sock_mnt);
d_instantiate(path.dentry, SOCK_INODE(sock));
@@@ -373,26 -390,22 +382,26 @@@
file->f_flags = O_RDWR | (flags & O_NONBLOCK);
file->f_pos = 0;
file->private_data = sock;
-
- *f = file;
- return fd;
+ return file;
}
+EXPORT_SYMBOL(sock_alloc_file);
-int sock_map_fd(struct socket *sock, int flags)
+static int sock_map_fd(struct socket *sock, int flags)
{
struct file *newfile;
- int fd = sock_alloc_file(sock, , flags, NULL);
+ int fd = get_unused_fd_flags(flags);
+ if (unlikely(fd < 0))
+ return fd;
- newfile = sock_alloc_file(sock, flags);
- if (likely(fd >= 0))
++ newfile = sock_alloc_file(sock, flags, NULL);
+ if (likely(!IS_ERR(newfile))) {
fd_install(fd, newfile);
+ return fd;
+ }
- return fd;
+ put_unused_fd(fd);
+ return PTR_ERR(newfile);
}
-EXPORT_SYMBOL(sock_map_fd);
[Patch 1/1]drm_irq: Introducing the irq_thread support
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.
The changes include:
1/ Change the request_irq to request_thread_irq, and add new callback
irq_handler_t;
2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
this option in drm_irq;
Cc: Shi Yang
Signed-off-by: liu chuansheng
---
drivers/gpu/drm/drm_irq.c |8 ++--
include/drm/drmP.h|2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..bc105fe 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;
+ if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
+ sh_flags |= IRQF_ONESHOT;
+
if (dev->devname)
irqname = dev->devname;
else
irqname = dev->driver->name;
- ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
- sh_flags, irqname, dev);
+ ret = request_threaded_irq(drm_dev_to_irq(dev),
+ dev->driver->irq_handler, dev->driver->irq_handler_t,
+ sh_flags, irqname, dev);
if (ret < 0) {
mutex_lock(>struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..b28be4b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
#define DRIVER_GEM 0x1000
#define DRIVER_MODESET 0x2000
#define DRIVER_PRIME 0x4000
+#define DRIVER_IRQ_ONESHOT 0x8000
#define DRIVER_BUS_PCI 0x1
#define DRIVER_BUS_PLATFORM 0x2
@@ -872,6 +873,7 @@ struct drm_driver {
/* these have to be filled in */
irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
+ irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 0/1]drm_irq: Introducing the irq_thread support
This patch is for introducing the irq thread support in drm_irq. Why we need irq thread in drm_irq code? In our GPU system, the gpu interrupt handler need some time even > 1ms to finish, in that case, the whole system will stay in irq disable status. One case is: when audio is playing, it sometimes effects the audio quality. So we have to introduce the irq thread in drm_irq, it can help us move some heavy work into irq thread and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is helpful for irq thread. Include one patch: [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10 V4] workqueue: merge the role of rebind_hold to idle_done
On 09/05/2012 09:15 AM, Tejun Heo wrote: > On Sun, Sep 02, 2012 at 12:28:28AM +0800, Lai Jiangshan wrote: >> Currently is single pass, we can wait on idle_done instead wait on >> rebind_hold. >> So we can remove rebind_hold and make the code simpler. > > As I wrote before, in general, I do like this approach; however, the > implementation in this series seems to make the code longer, which > kinda defeats its purpose of simplifying the implementation. It could > be because the series is mixing fixes with restructuring. > Can you > please re-spin the restructuring part once fixes are settled? Let's > see if that actually makes things simpler. OK for me. Patch 5: -4 Patch 6: -9Patch 5,6 simplify idle rebind(benefit from Patch 2) Patch 7: +31 Patch 8: +14 Patch 7,8 make busy worker wait idle worker's rebinding Patch 9: -7 Patch 10: -13 Patch 9,10 single pass total: +11 single pass allows us clean up more, example narrow the critical critical section of manage_mutex. I will add it in next round. thank, Lai > > 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: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
At 09/05/2012 07:16 AM, Andrew Morton Wrote:
> On Mon, 03 Sep 2012 13:51:10 +0800
> Wen Congyang wrote:
>
+static void release_firmware_map_entry(struct kobject *kobj)
+{
+ struct firmware_map_entry *entry = to_memmap_entry(kobj);
+ struct page *page;
+
+ page = virt_to_page(entry);
+ if (PageSlab(page) || PageCompound(page))
>>>
>>> That PageCompound() test looks rather odd. Why is this done?
>>
>> Liu Jiang and Christoph Lameter discussed how to find slab page
>> in this mail:
>> https://lkml.org/lkml/2012/7/6/333.
>
> Well, please add a code comment to release_firmware_map_entry() which
> fully explains these things.
>
> I see that Christoph and I agree: "It would be cleaner if memory
> hotplug had an indicator which allocation mechanism was used and would
> use the corresponding free action". You didn't respond to this
> suggestion when he made it, nor when I made it. What are your thoughts
> on this?
Hmm, I think it is better to use an indicator which allocation mechanism was
used. I will do it in the next version.
Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10 V4] workqueue: fix deadlock in rebind_workers()
Hello, On Wed, Sep 05, 2012 at 09:28:38AM +0800, Lai Jiangshan wrote: > I see that this patch's idea is same as mine but reuses > @idle_rebind.cnt and @idle_rebind.done. > > I don't think it is consistent to avoid adding new field > and to reuse old field for different purpose It's not necessarily the reuse which seems more consistent to me but where the driving logic is. It's now better contained in rebind_workers(). > > - /* > > -* All idle workers are rebound and waiting for %WORKER_REBIND to > > -* be cleared inside idle_worker_rebind(). Clear and release. > > -* Clearing %WORKER_REBIND from this foreign context is safe > > -* because these workers are still guaranteed to be idle. > > -*/ > > - for_each_worker_pool(pool, gcwq) > > - list_for_each_entry(worker, >idle_list, entry) > > - worker->flags &= ~WORKER_REBIND; > > - > > - wake_up_all(>rebind_hold); > > don't need to move down. Yeap, but cleaner that way. With the moving separated into another patch, the addition of another handshake stage becomes easier to follow. 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 02/10 V4] workqueue: fix deadlock in rebind_workers()
On 09/05/2012 08:54 AM, Tejun Heo wrote:
> How about something like the following? This is more consistent with
> the existing code and as the fixes need to go separately through
> for-3.6-fixes, it's best to stay consistent regardless of the end
> result after all the restructuring. It's not tested yet. If you
> don't object, I'll split it into two patches, test and route them
> through for-3.6-fixes w/ your Original-patch-by.
>
I see that this patch's idea is same as mine but reuses
@idle_rebind.cnt and @idle_rebind.done.
I don't think it is consistent to avoid adding new field
and to reuse old field for different purpose
Thanks
Lai
> Thanks.
> ---
> kernel/workqueue.c | 51 ++-
> 1 file changed, 38 insertions(+), 13 deletions(-)
>
> Index: work/kernel/workqueue.c
> ===
> --- work.orig/kernel/workqueue.c
> +++ work/kernel/workqueue.c
> @@ -1326,6 +1326,15 @@ static void idle_worker_rebind(struct wo
>
> /* we did our part, wait for rebind_workers() to finish up */
> wait_event(gcwq->rebind_hold, !(worker->flags & WORKER_REBIND));
> +
> + /*
> + * rebind_workers() shouldn't finish until all workers passed the
> + * above WORKER_REBIND wait. Tell it when done.
> + */
> + spin_lock_irq(>pool->gcwq->lock);
> + if (!--worker->idle_rebind->cnt)
> + complete(>idle_rebind->done);
> + spin_unlock_irq(>pool->gcwq->lock);
> }
>
> /*
> @@ -1422,19 +1431,7 @@ retry:
> goto retry;
> }
>
> - /*
> - * All idle workers are rebound and waiting for %WORKER_REBIND to
> - * be cleared inside idle_worker_rebind(). Clear and release.
> - * Clearing %WORKER_REBIND from this foreign context is safe
> - * because these workers are still guaranteed to be idle.
> - */
> - for_each_worker_pool(pool, gcwq)
> - list_for_each_entry(worker, >idle_list, entry)
> - worker->flags &= ~WORKER_REBIND;
> -
> - wake_up_all(>rebind_hold);
don't need to move down.
> -
> - /* rebind busy workers */
> + /* all idle workers are rebound, rebind busy workers */
> for_each_busy_worker(worker, i, pos, gcwq) {
> struct work_struct *rebind_work = >rebind_work;
> unsigned long worker_flags = worker->flags;
> @@ -1454,6 +1451,34 @@ retry:
> worker->scheduled.next,
> work_color_to_flags(WORK_NO_COLOR));
> }
> +
> + /*
> + * All idle workers are rebound and waiting for %WORKER_REBIND to
> + * be cleared inside idle_worker_rebind(). Clear and release.
> + * Clearing %WORKER_REBIND from this foreign context is safe
> + * because these workers are still guaranteed to be idle.
> + *
> + * We need to make sure all idle workers passed WORKER_REBIND wait
> + * in idle_worker_rebind() before returning; otherwise, workers can
> + * get stuck at the wait if hotplug cycle repeats.
> + */
> + idle_rebind.cnt = 1;
> + INIT_COMPLETION(idle_rebind.done);
> +
> + for_each_worker_pool(pool, gcwq) {
> + list_for_each_entry(worker, >idle_list, entry) {
> + worker->flags &= ~WORKER_REBIND;
> + idle_rebind.cnt++;
> + }
> + }
> +
> + wake_up_all(>rebind_hold);
> +
> + if (--idle_rebind.cnt) {
> + spin_unlock_irq(>lock);
> + wait_for_completion(_rebind.done);
> + spin_lock_irq(>lock);
> + }
> }
>
> static struct worker *alloc_worker(void)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 tip/core/rcu 02/23] rcu: Allow RCU grace-period initialization to be preempted
On Sat, Sep 01, 2012 at 06:09:35PM -0700, Josh Triplett wrote:
> On Thu, Aug 30, 2012 at 11:18:17AM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > RCU grace-period initialization is currently carried out with interrupts
> > disabled, which can result in 200-microsecond latency spikes on systems
> > on which RCU has been configured for 4096 CPUs. This patch therefore
> > makes the RCU grace-period initialization be preemptible, which should
> > eliminate those latency spikes. Similar spikes from grace-period cleanup
> > and the forcing of quiescent states will be dealt with similarly by later
> > patches.
> >
> > Reported-by: Mike Galbraith
> > Reported-by: Dimitri Sivanich
> > Signed-off-by: Paul E. McKenney
>
> Does it make sense to have cond_resched() right before the continues,
> which lead right back up to the wait_event_interruptible at the top of
> the loop? Or do you expect to usually find that event already
> signalled?
Given that the event might have already signaled, I need to put the
cond_resched() into the loop. Otherwise, we get back long latencies.
Thanx, Paul
> In any case:
>
> Reviewed-by: Josh Triplett
>
> > kernel/rcutree.c | 17 ++---
> > 1 files changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index e1c5868..ef56aa3 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> > @@ -1069,6 +1069,7 @@ static int rcu_gp_kthread(void *arg)
> > * don't start another one.
> > */
> > raw_spin_unlock_irqrestore(>lock, flags);
> > + cond_resched();
> > continue;
> > }
> >
> > @@ -1079,6 +1080,7 @@ static int rcu_gp_kthread(void *arg)
> > */
> > rsp->fqs_need_gp = 1;
> > raw_spin_unlock_irqrestore(>lock, flags);
> > + cond_resched();
> > continue;
> > }
> >
> > @@ -1089,10 +1091,10 @@ static int rcu_gp_kthread(void *arg)
> > rsp->fqs_state = RCU_GP_INIT; /* Stop force_quiescent_state. */
> > rsp->jiffies_force_qs = jiffies + RCU_JIFFIES_TILL_FORCE_QS;
> > record_gp_stall_check_time(rsp);
> > - raw_spin_unlock(>lock); /* leave irqs disabled. */
> > + raw_spin_unlock_irqrestore(>lock, flags);
> >
> > /* Exclude any concurrent CPU-hotplug operations. */
> > - raw_spin_lock(>onofflock); /* irqs already disabled. */
> > + get_online_cpus();
> >
> > /*
> > * Set the quiescent-state-needed bits in all the rcu_node
> > @@ -1112,7 +1114,7 @@ static int rcu_gp_kthread(void *arg)
> > * due to the fact that we have irqs disabled.
> > */
> > rcu_for_each_node_breadth_first(rsp, rnp) {
> > - raw_spin_lock(>lock); /* irqs already disabled. */
> > + raw_spin_lock_irqsave(>lock, flags);
> > rcu_preempt_check_blocked_tasks(rnp);
> > rnp->qsmask = rnp->qsmaskinit;
> > rnp->gpnum = rsp->gpnum;
> > @@ -1123,15 +1125,16 @@ static int rcu_gp_kthread(void *arg)
> > trace_rcu_grace_period_init(rsp->name, rnp->gpnum,
> > rnp->level, rnp->grplo,
> > rnp->grphi, rnp->qsmask);
> > - raw_spin_unlock(>lock); /* irqs remain disabled. */
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > + cond_resched();
> > }
> >
> > rnp = rcu_get_root(rsp);
> > - raw_spin_lock(>lock); /* irqs already disabled. */
> > + raw_spin_lock_irqsave(>lock, flags);
> > /* force_quiescent_state() now OK. */
> > rsp->fqs_state = RCU_SIGNAL_INIT;
> > - raw_spin_unlock(>lock); /* irqs remain disabled. */
> > - raw_spin_unlock_irqrestore(>onofflock, flags);
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > + put_online_cpus();
> > }
> > return 0;
> > }
> > --
> > 1.7.8
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
On Tue, Sep 4, 2012 at 5:28 AM, Liu Qiang-B32616 wrote: >> Will this engine be coordinating with another to handle memory copies? >> The dma mapping code for async_tx/raid is broken when dma mapping >> requests overlap or cross dma device boundaries [1]. >> >> [1]: http://marc.info/?l=linux-arm-kernel=129407269402930=2 > Yes, it needs fsl-dma to handle memcpy copies. > I read your link, the unmap address is stored in talitos hwdesc, the address > will be unmapped when async_tx ack this descriptor, I know fsl-dma won't wait > this ack flag in current kernel, so I fix it in fsl-dma patch 5/8. Do you > mean that? Unfortunately no. I'm open to other suggestions. but as far as I can see it requires deeper changes to rip out the dma mapping that happens in async_tx and the automatic unmapping done by drivers. It should all be pushed to the client (md). Currently async_tx hides hardware details from md such that it doesn't even care if the operation is offloaded to hardware at all, but that takes things too far. In the worst case an copy->xor chain handled by multiple channels results in : 1/ dma_map(copy_chan...) 2/ dma_map(xor_chan...) 3/ 4/ dma_unmap(copy_chan...) 5/ <---initiated by the copy_chan 6/ dma_unmap(xor_chan...) Step 2 violates the dma api since the buffers belong to the xor_chan until unmap. Step 5 also causes the random completion context of the copy channel to bleed into submission context of the xor channel which is problematic. So the order needs to be: 1/ dma_map(copy_chan...) 2/ 3/ dma_unmap(copy_chan...) 4/ dma_map(xor_chan...) 5/ <--initiated by md in a static context 6/ dma_unmap(xor_chan...) Also, if xor_chan and copy_chan lie with the same dma mapping domain (iommu or parent device) then we can map the stripe once and skip the extra maintenance for the duration of the chain of operations. This dumps a lot of hardware details on md, but I think it is the only way to get consistent semantics when arbitrary offload devices are involved. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2] trace: Move trace event enable from fs_initcall to early_initcall
Hi Steven, On 8/17/12, Steven Rostedt wrote: > On Fri, 2012-08-17 at 09:03 -0300, Ezequiel Garcia wrote: >> This patch splits trace event initialization in two stages: >> * ftrace enable >> * sysfs event entry creation >> >> This allows to capture trace events from an earlier point >> by using 'trace_event' kernel parameter and is important >> to trace boot-up allocations. >> > > This is much better, I'll give it some tests and add it to my 3.7 queue. > Ping? Will you add this to your tree? Thanks! Ezequiel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic
Hello, Lai. On Wed, Sep 05, 2012 at 09:05:37AM +0800, Lai Jiangshan wrote: > Thank you for accepting this one. Thanks a lot for bearing with me. I was at kernel summit / plumbers last week so my reviews were shaky. My apologies. > I'm waiting for your comments on the other patches. > I need to rebase the other patches(on top of wq/for-3.7 and this merged one), > but I think it is not good to seed to new version patchset without considering > your comments. so I'm still waiting. Or should I rebase them at first? Let's get the fixes down first. The fixes and restructuring need to be routed separately, so we need to separate them into different patch serieses. Once the fix part is done, I'll pull the fixes into for-3.7 on which restructuring can happen. 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: A workaround for request_firmware() stuck in module_init
On Wed, Sep 5, 2012 at 12:10 AM, Takashi Iwai wrote: > At Tue, 4 Sep 2012 23:52:15 +0800, > Ming Lei wrote: >> >> On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote: >> > Hi, >> > >> > as I've got recently a few bug reports regarding the stuck with >> > request_firmware() in module_init of some sound drivers, I started >> > looking at the issue. Strangely, the problem doesn't happen on >> > openSUSE 12.2 although it has the same udev version with libkmod as >> > Fedora. So I installed Fedora 17, and indeed I could see a problem >> > there. >> >> It should be a bug in udev, as discussed in the below link: >> >> http://marc.info/?t=13455274512=1=2 > > Yeah, if udev has a fix, I'm fine. I'll proactively ignore these bug > reports. But did it really happen...? Linus has expressed that it should be fixed by udev, maybe we can wait some time to see if it will happen, :-) There are more than 300 request_firmware called in probe(), even adding 2 line code in these drivers will involve much workload, since you need to find the matched probe() for one request_firmware and sometimes it is not easy. > >> > Obviously a solution would be to rewrite the driver code to use >> > request_firmware_nowait() instead. But it'd need a lot of code >> > shuffling, and most of such drivers are old stuff I don't want to do a >> > serious surgery. >> > >> > So I tried an easier workaround by using the deferred probing. >> > An experimental patch is below. As you can see, from the driver side, >> > it's simple: just add two lines at the head of each probe function. >> >> In fact, the defer probe should only be applied in situations which >> driver is built in kernel and request_firmware is called in .probe(). > > Is it? I thought the deferred probe is basically not for this problem > but rather for the dependency problem with other modules. That's the > reason it's triggered only upon the successful binding. Sorry, could you explain the dependency in a bit detail? >From your patch, I understand you just convert the caller of request_firmware from module_init into deferred_probe_work_func(), so the udev problem is avoided, isn't it? Looks making all .probe() run non-module_init context is still a solution, :-) > > And IMO, the deferred probe for the built-in kernel is also silly. > Did anyone really make it working for built-in kernel driver and > external firmware files? (For the resume, it's of course a different Yes, my original patch does work for the built-in situations. > issue. And I guess it's been solved by your fw cache patch, right?) > >> > Do you think this kind of hack is OK? If not, any better (IOW easier) >> > solution? >> >> Looks your solution is a bit complicated, and I have wrote a similar >> patch to address the problem, but Linus thought that it may hide the >> problem of drivers. >> >> http://marc.info/?t=13427879084=1=2 >> >> IMO, driver core needn't to be changed, and the defer probe can be >> supported just by changes in request_firmware() and its caller. > > Ideally, yes. But it won't work in some drivers like sound drivers, > that have its own device number counting changed at each probe call. > For such drivers, the deferred probe check must be done before > entering the normal probe procedure, and returning -EPROBE_DEFER would > be too late (or need more complex fallbacks). Simply, you can put the firmware loading at the start of probe to avoid the specific sound problem, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec/kdump kernel fails to start
On Tue, Sep 4, 2012 at 5:01 PM, Flavio Leitner wrote: > On Tue, 4 Sep 2012 15:25:45 -0700 > kdump works when using your branch: > > [0.00] Linux version 3.6.0-rc4-00012-g9389673 (r...@f17i7.rh) (gcc > version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Tue Sep 4 20:36:43 > BRT 2012 > ... > [0.00] initial memory mapped: [mem 0x-0x1fff] > [0.00] Base memory trampoline at [88097000] 97000 size 24576 > [0.00] calculate_table_space_size: [mem 0x-0x000f] > [0.00] [mem 0x-0x000f] page 4k > [0.00] calculate_table_space_size: [mem 0x0010-0xbf4bcfff] > [0.00] [mem 0x0010-0x001f] page 4k > [0.00] [mem 0x0020-0xbf3f] page 2M > [0.00] [mem 0xbf40-0xbf4bcfff] page 4k > [0.00] calculate_table_space_size: [mem 0xbf4bf000-0xbf4c5fff] > [0.00] [mem 0xbf4bf000-0xbf4c5fff] page 4k > [0.00] calculate_table_space_size: [mem 0xbf7bf000-0xbf7d] > [0.00] [mem 0xbf7bf000-0xbf7d] page 4k > [0.00] calculate_table_space_size: [mem 0xbf7ff000-0xbf7f] > [0.00] [mem 0xbf7ff000-0xbf7f] page 4k > [0.00] calculate_table_space_size: [mem 0x1-0x43fff] > [0.00] [mem 0x1-0x43fff] page 2M > [0.00] kernel direct mapping tables up to 0x43fff @ [mem > 0x43ffe1000-0x43fff] prealloc > [0.00] init_memory_mapping: [mem 0x-0x000f] > [0.00] [mem 0x-0x000f] page 4k > [0.00] init_memory_mapping: [mem 0x0010-0xbf4bcfff] > [0.00] [mem 0x0010-0x001f] page 4k > [0.00] [mem 0x0020-0xbf3f] page 2M > [0.00] [mem 0xbf40-0xbf4bcfff] page 4k > [0.00] init_memory_mapping: [mem 0xbf4bf000-0xbf4c5fff] > [0.00] [mem 0xbf4bf000-0xbf4c5fff] page 4k > [0.00] init_memory_mapping: [mem 0xbf7bf000-0xbf7d] > [0.00] [mem 0xbf7bf000-0xbf7d] page 4k > [0.00] init_memory_mapping: [mem 0xbf7ff000-0xbf7f] > [0.00] [mem 0xbf7ff000-0xbf7f] page 4k > [0.00] init_memory_mapping: [mem 0x1-0x43fff] > [0.00] [mem 0x1-0x43fff] page 2M > [0.00] kernel direct mapping tables up to 0x43fff @ [mem > 0x43ffe1000-0x43fff2fff] final > [0.00] RAMDISK: [mem 0x34ffa000-0x367f4fff] thanks. assume when we have good_end setting for 64 bit, page table for [4g, TOMH) will be just under 512M, and later when first first 2M lines changes, will push that page table range a little low, and will make kdump not happy. BTW the first 2M change commit is useless should be reverted. because even it is in 2M page mapping at first, later kernel will change to 4k page. and with other change in this patchset, init_memory_mapping(0, ISA_END_ADDR) will always make sure first 2M use 4K page. Thanks 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 10/10 V4] workqueue: merge the role of rebind_hold to idle_done
On Sun, Sep 02, 2012 at 12:28:28AM +0800, Lai Jiangshan wrote: > Currently is single pass, we can wait on idle_done instead wait on > rebind_hold. > So we can remove rebind_hold and make the code simpler. As I wrote before, in general, I do like this approach; however, the implementation in this series seems to make the code longer, which kinda defeats its purpose of simplifying the implementation. It could be because the series is mixing fixes with restructuring. Can you please re-spin the restructuring part once fixes are settled? Let's see if that actually makes things simpler. 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 04/10 V4] workqueue: add manage_workers_slowpath()
Hello, Lai. On Sun, Sep 02, 2012 at 12:28:22AM +0800, Lai Jiangshan wrote: > If hotplug code grabbed the manager_mutex and worker_thread try to create > a worker, the manage_worker() will return false and worker_thread go to > process work items. Now, on the CPU, all workers are processing work items, > no idle_worker left/ready for managing. It breaks the concept of workqueue > and it is bug. > > So when manage_worker() failed to grab the manager_mutex, it should > try to enter normal process contex and then compete on the manager_mutex > instead of return false. > > To safely do this, we add manage_workers_slowpath() and the worker > go to process work items mode to do the managing jobs. thus > managing jobs are processed via work item and can free to compete > on manager_mutex. Ummm this seems overly complicated. How about scheduling rebind work to a worker and forcing it to break out of the work processing loop? I think it can be done fairly easily using POOL_MANAGE_WORKERS - set it from the rebind function, break out of work processing loop if it's set, replace need_to_manage_workers() with POOL_MANAGE_WORKERS test (the function really isn't necessary) and always jump back to recheck afterwards. It might need a bit more mangling here and there but that should be the essence of it. I'll give a stab at it later today. 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 tip/core/rcu 01/26] rcu: New rcu_user_enter() and rcu_user_exit() APIs
On Fri, Aug 31, 2012 at 12:07:33PM -0700, Josh Triplett wrote:
> On Thu, Aug 30, 2012 at 02:05:18PM -0700, Paul E. McKenney wrote:
> > From: Frederic Weisbecker
> >
> > RCU currently insists that only idle tasks can enter RCU idle mode, which
> > prohibits an adaptive tickless kernel (AKA nohz cpusets), which in turn
> > would mean that usermode execution would always take scheduling-clock
> > interrupts, even when there is only one task runnable on the CPU in
> > question.
> >
> > This commit therefore adds rcu_user_enter() and rcu_user_exit(), which
> > allow non-idle tasks to enter RCU idle mode. These are quite similar
> > to rcu_idle_enter() and rcu_idle_exit(), respectively, except that they
> > omit the idle-task checks.
> >
> > [ Updated to use "user" flag rather than separate check functions. ]
> >
> > Signed-off-by: Frederic Weisbecker
> > Signed-off-by: Paul E. McKenney
> > Cc: Alessio Igor Bogani
> > Cc: Andrew Morton
> > Cc: Avi Kivity
> > Cc: Chris Metcalf
> > Cc: Christoph Lameter
> > Cc: Daniel Lezcano
> > Cc: Geoff Levand
> > Cc: Gilad Ben Yossef
> > Cc: Hakan Akkan
> > Cc: Ingo Molnar
> > Cc: Kevin Hilman
> > Cc: Max Krasnyansky
> > Cc: Peter Zijlstra
> > Cc: Stephen Hemminger
> > Cc: Steven Rostedt
> > Cc: Sven-Thorsten Dietrich
> > Cc: Thomas Gleixner
>
> A few suggestions below: an optional microoptimization and some bugfixes.
> With the bugfixes, and with or without the microoptimization:
Good catches! Due to conflicts with later commits, I added these as
a separate commit.
Thanx, Paul
> Reviewed-by: Josh Triplett
>
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> [...]
> > -static void rcu_idle_enter_common(struct rcu_dynticks *rdtp, long long
> > oldval)
> > +static void rcu_eqs_enter_common(struct rcu_dynticks *rdtp, long long
> > oldval,
> > + bool user)
> > {
> > trace_rcu_dyntick("Start", oldval, 0);
> > - if (!is_idle_task(current)) {
> > + if (!is_idle_task(current) && !user) {
>
> Microoptimization: putting the !user check first (here and in the exit
> function) would allow the compiler to partially inline rcu_eqs_*_common
> into the two trivial wrappers and constant-fold away the test for !user.
>
> > +void rcu_idle_enter(void)
> > +{
> > + rcu_eqs_enter(0);
> > +}
>
> s/0/false/
>
> > +void rcu_user_enter(void)
> > +{
> > + rcu_eqs_enter(1);
> > +}
>
> s/1/true/
>
> > -static void rcu_idle_exit_common(struct rcu_dynticks *rdtp, long long
> > oldval)
> > +static void rcu_eqs_exit_common(struct rcu_dynticks *rdtp, long long
> > oldval,
> > + int user)
> > {
> > smp_mb__before_atomic_inc(); /* Force ordering w/previous sojourn. */
> > atomic_inc(>dynticks);
> > @@ -464,7 +490,7 @@ static void rcu_idle_exit_common(struct rcu_dynticks
> > *rdtp, long long oldval)
> > WARN_ON_ONCE(!(atomic_read(>dynticks) & 0x1));
> > rcu_cleanup_after_idle(smp_processor_id());
> > trace_rcu_dyntick("End", oldval, rdtp->dynticks_nesting);
> > - if (!is_idle_task(current)) {
> > + if (!is_idle_task(current) && !user) {
>
> Same micro-optimization as the enter function.
>
> > +void rcu_idle_exit(void)
> > +{
> > + rcu_eqs_exit(0);
> > +}
>
> s/0/false/
>
> > +void rcu_user_exit(void)
> > +{
> > + rcu_eqs_exit(1);
> > +}
>
> s/1/true/
>
> > @@ -539,7 +586,7 @@ void rcu_irq_enter(void)
> > if (oldval)
> > trace_rcu_dyntick("++=", oldval, rdtp->dynticks_nesting);
> > else
> > - rcu_idle_exit_common(rdtp, oldval);
> > + rcu_eqs_exit_common(rdtp, oldval, 1);
>
> s/1/true/, and likewise in rcu_irq_exit.
>
> - Josh Triplett
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
