Re: [RFC/PATCH RESEND -next 14/21] mm: slub: kasan: disable kasan when touching unaccessible memory
On Wed, Jul 09, 2014 at 03:30:08PM +0400, Andrey Ryabinin wrote:
> Some code in slub could validly touch memory marked by kasan as unaccessible.
> Even though slub.c doesn't instrumented, functions called in it are
> instrumented,
> so to avoid false positive reports such places are protected by
> kasan_disable_local()/kasan_enable_local() calls.
>
> Signed-off-by: Andrey Ryabinin
> ---
> mm/slub.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 6ddedf9..c8dbea7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -560,8 +560,10 @@ static void print_tracking(struct kmem_cache *s, void
> *object)
> if (!(s->flags & SLAB_STORE_USER))
> return;
>
> + kasan_disable_local();
> print_track("Allocated", get_track(s, object, TRACK_ALLOC));
> print_track("Freed", get_track(s, object, TRACK_FREE));
> + kasan_enable_local();
I don't think that this is needed since print_track() doesn't call
external function with object pointer. print_track() call pr_err(), but,
before calling, it retrieve t->addrs[i] so memory access only occurs
in slub.c.
> }
>
> static void print_page_info(struct page *page)
> @@ -604,6 +606,8 @@ static void print_trailer(struct kmem_cache *s, struct
> page *page, u8 *p)
> unsigned int off; /* Offset of last byte */
> u8 *addr = page_address(page);
>
> + kasan_disable_local();
> +
> print_tracking(s, p);
>
> print_page_info(page);
> @@ -632,6 +636,8 @@ static void print_trailer(struct kmem_cache *s, struct
> page *page, u8 *p)
> /* Beginning of the filler is the free pointer */
> print_section("Padding ", p + off, s->size - off);
>
> + kasan_enable_local();
> +
> dump_stack();
> }
And, I recommend that you put this hook on right place.
At a glance, the problematic function is print_section() which have
external function call, print_hex_dump(), with object pointer.
If you disable kasan in print_section, all the below thing won't be
needed, I guess.
Thanks.
>
> @@ -1012,6 +1018,8 @@ static noinline int alloc_debug_processing(struct
> kmem_cache *s,
> struct page *page,
> void *object, unsigned long addr)
> {
> +
> + kasan_disable_local();
> if (!check_slab(s, page))
> goto bad;
>
> @@ -1028,6 +1036,7 @@ static noinline int alloc_debug_processing(struct
> kmem_cache *s,
> set_track(s, object, TRACK_ALLOC, addr);
> trace(s, page, object, 1);
> init_object(s, object, SLUB_RED_ACTIVE);
> + kasan_enable_local();
> return 1;
>
> bad:
> @@ -1041,6 +1050,7 @@ bad:
> page->inuse = page->objects;
> page->freelist = NULL;
> }
> + kasan_enable_local();
> return 0;
> }
>
> @@ -1052,6 +1062,7 @@ static noinline struct kmem_cache_node
> *free_debug_processing(
>
> spin_lock_irqsave(>list_lock, *flags);
> slab_lock(page);
> + kasan_disable_local();
>
> if (!check_slab(s, page))
> goto fail;
> @@ -1088,6 +1099,7 @@ static noinline struct kmem_cache_node
> *free_debug_processing(
> trace(s, page, object, 0);
> init_object(s, object, SLUB_RED_INACTIVE);
> out:
> + kasan_enable_local();
> slab_unlock(page);
> /*
>* Keep node_lock to preserve integrity
> @@ -1096,6 +1108,7 @@ out:
> return n;
>
> fail:
> + kasan_enable_local();
> slab_unlock(page);
> spin_unlock_irqrestore(>list_lock, *flags);
> slab_fix(s, "Object at 0x%p not freed", object);
> @@ -1371,8 +1384,11 @@ static void setup_object(struct kmem_cache *s, struct
> page *page,
> void *object)
> {
> setup_object_debug(s, page, object);
> - if (unlikely(s->ctor))
> + if (unlikely(s->ctor)) {
> + kasan_disable_local();
> s->ctor(object);
> + kasan_enable_local();
> + }
> }
> static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> @@ -1425,11 +1441,12 @@ static void __free_slab(struct kmem_cache *s, struct
> page *page)
>
> if (kmem_cache_debug(s)) {
> void *p;
> -
> + kasan_disable_local();
> slab_pad_check(s, page);
> for_each_object(p, s, page_address(page),
> page->objects)
> check_object(s, page, p, SLUB_RED_INACTIVE);
> + kasan_enable_local();
> }
>
> kmemcheck_free_shadow(page, compound_order(page));
> --
> 1.8.5.5
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line
Re: linux-next: build failure after merge of the v4l-dvb tree
Hi Guenter,
On Mon, 14 Jul 2014 22:43:42 -0700 Guenter Roeck wrote:
>
> On 07/14/2014 08:29 PM, Stephen Rothwell wrote:
> >
> > After merging the v4l-dvb tree, today's linux-next build (powerpc
> > ppc64_defconfig)
> > failed like this:
> >
> > arch/powerpc/kernel/smp.c:764:2: error: initialization from incompatible
> > pointer type [-Werror]
> >{ cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> >^
> > arch/powerpc/kernel/smp.c:764:2: error: (near initialization for
> > 'powerpc_topology[0].sd_flags') [-Werror]
> >
> > Caused by commit 6a0b50087a89 ("Merge branch 'patchwork' into
> > to_next"). The change to include/linux/sched.h in this merge commit
> > does not seem to appear in either of the parents of the merge.
> >
> > Its also a change that (when suggested) was shown to cause more
> > problems than it was worth and dropped. I can't imagine how it ended
> > up in the merge commit.
> >
>
> Do you mean b6220ad66 (sched: Fix compiler warnings) ? I thought that was
> accepted
> a week or so ago.
That is in the tip tree and includes the fixups to powerpc and arm. I
don't merge the tip tree till well after the v4l-dvb tree. The merge
in the v4l-dvb tree included only the change to include/linus/sched.h
and neither parent fo that merge was based on the tip tree ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 15 July 2014 11:06, Saravana Kannan wrote: > Btw, I tried to take a stab at removing any assumption in cpufreq code about > policy->cpu being ONLINE. There are 160 instances of those of with 23 are in > cpufreq.c > > So, even if we are sure cpufreq.c is fine, it's 137 other uses spread across > all the other files. I definitely don't want to try and fix those as part of > this patch. Way too risky and hard to get the test coverage it would need. > Even some of the acpi cpufreq drivers seem to be making this assumption. Hmm, yeah that would be an issue. So this is what you should do now: - Left policy->cpu as it is, i.e. updated only when policy->cpu goes down. - Just make sure sysfs nodes are untouched when any cpu goes down > Btw, I think v3 is done. I did some testing and it was fine. But made some > minor changes. Will test tomorrow to make sure I didn't break anything with > the minor changes and then send them out. Ok, just comply to the above comments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Support for ASP DM6446 in main-line Linux Kernel
On 07/14/2014 06:58 PM, abhijit naik wrote: > Hi, > > I am studying ASP driver of DM6446 EVM in main line kernel 3.14. > I referred to both sound/soc/davinci/davinci-mcasp.c > and sound/soc/davinci/davinci-i2s.c For DM6446 the correct driver would be the davinci-i2s. The audio interface is named as ASP in DM6446 which is an early version of McBSP - really basic IP (according to the TRMs). AFAIK there is no users of davinci-i2s in mainline and I do not have and I do not have HW where I can test it. Because of this lack of users there is no DT bindings for davinci-i2s - which should be renamed as davinci-asp IMHO. But the code looks like something which might work so at least w/o DT boot should be trivial to enable. If you look at arch/arm/mach-davinci/dm644x.c and board-dm644x-evm.c it is setting up davinci-mcbsp (which is implemented within davinci-i2s driver). So at least non DT boot should work with audio. > Which one among the two is correct for DM6446 ASP and I am seeing that there > is a device tree code in sound/soc/davinci/davinci-evm.c but corresponding > support code is not present in sound/soc/davinci/davinci-mcasp.c > > Please let me know whether this support is complete or can some one guide me > to working code for DM6446 ASP For what I see is that mainline should work with audio on dm644x-evm. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND -next 10/21] mm: slab: share virt_to_cache() between slab and slub
On Wed, Jul 09, 2014 at 03:30:04PM +0400, Andrey Ryabinin wrote: > This patch shares virt_to_cache() between slab and slub and > it used in cache_from_obj() now. > Later virt_to_cache() will be kernel address sanitizer also. I think that this patch won't be needed. See comment in 15/21. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 2/4] Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver
On 07/15/2014 03:48 AM, Iyappan Subramanian wrote:
This patch adds documentation for APM X-Gene SoC ethernet DTS binding.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/net/apm-xgene-enet.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
new file mode 100644
index 000..3e2a295
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -0,0 +1,72 @@
+APM X-Gene SoC Ethernet nodes
+
+Ethernet nodes are defined to describe on-chip ethernet interfaces in
+APM X-Gene SoC.
+
+Required properties:
+- compatible: Should be "apm,xgene-enet"
+- reg: Address and length of the register set for the device. It contains the
+ information of registers in the same order as described by reg-names
+- reg-names: Should contain the register set names
These are not aligned properly...
Required properties:
- compatble : Should be "apm,xgene-enet"
- reg : Address and length of the register set for the device.
It contains the information of registers in the same
order
as described by reg-names
.
+ "enet_csr":Ethernet control and status register address space
+ "ring_csr":Descriptor ring control and status register
address space
+ "ring_cmd":Descriptor ring command register address space
+- interrupts: Ethernet main interrupt
+- clocks: Reference to the clock entry.
+- local-mac-address: MAC address assigned to this device
+- phy-connection-type: Interface type between ethernet device and PHY device
+- phy-handle: Reference to a PHY node connected to this device
+
+- mdio:Device tree subnode with the following required
+ properties:
+
+ - compatible: Must be "apm,xgene-mdio".
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+
+ For the phy on the mdio bus, there must be a node with the following
+ fields:
+
+ - compatible: PHY identifier. Please refer ./phy.txt for the format.
+ - reg: The ID number for the phy.
+
alignment... :-)
+Optional properties:
+- status : Should be "ok" or "disabled" for enabled/disabled.
+ Default is "ok".
+
+
+Example:
+ menetclk: menetclk {
+ compatible = "apm,xgene-device-clock";
+ clock-output-names = "menetclk";
+ status = "ok";
+ };
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+ reg-names = "enet_csr", "ring_csr", "ring_cmd";
+ interrupts = <0x0 0x3c 0x4>;
+ clocks = < 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-connection-type = "rgmii";
+ phy-handle = <>;
+ mdio {
+ compatible = "apm,xgene-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ menetphy: menetphy@3 {
+ compatible = "ethernet-phy-id001c.c915";
+ reg = <0x3>;
+ };
+
+ };
+ };
+
+/* Board-specific peripheral configurations */
+ {
+status = "ok";
+};
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH RESEND -next 08/21] mm: page_alloc: add kasan hooks on alloc and free pathes
On Wed, Jul 09, 2014 at 03:30:02PM +0400, Andrey Ryabinin wrote:
> Add kernel address sanitizer hooks to mark allocated page's addresses
> as accessible in corresponding shadow region.
> Mark freed pages as unaccessible.
>
> Signed-off-by: Andrey Ryabinin
> ---
> include/linux/kasan.h | 6 ++
> mm/Makefile | 2 ++
> mm/kasan/kasan.c | 18 ++
> mm/kasan/kasan.h | 1 +
> mm/kasan/report.c | 7 +++
> mm/page_alloc.c | 4
> 6 files changed, 38 insertions(+)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 7efc3eb..4adc0a1 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -17,6 +17,9 @@ void kasan_disable_local(void);
> void kasan_alloc_shadow(void);
> void kasan_init_shadow(void);
>
> +void kasan_alloc_pages(struct page *page, unsigned int order);
> +void kasan_free_pages(struct page *page, unsigned int order);
> +
> #else /* CONFIG_KASAN */
>
> static inline void unpoison_shadow(const void *address, size_t size) {}
> @@ -28,6 +31,9 @@ static inline void kasan_disable_local(void) {}
> static inline void kasan_init_shadow(void) {}
> static inline void kasan_alloc_shadow(void) {}
>
> +static inline void kasan_alloc_pages(struct page *page, unsigned int order)
> {}
> +static inline void kasan_free_pages(struct page *page, unsigned int order) {}
> +
> #endif /* CONFIG_KASAN */
>
> #endif /* LINUX_KASAN_H */
> diff --git a/mm/Makefile b/mm/Makefile
> index dbe9a22..6a9c3f8 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for the linux memory manager.
> #
>
> +KASAN_SANITIZE_page_alloc.o := n
> +
> mmu-y:= nommu.o
> mmu-$(CONFIG_MMU):= gup.o highmem.o madvise.o memory.o mincore.o \
> mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index e2cd345..109478e 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -177,6 +177,24 @@ void __init kasan_init_shadow(void)
> }
> }
>
> +void kasan_alloc_pages(struct page *page, unsigned int order)
> +{
> + if (unlikely(!kasan_initialized))
> + return;
> +
> + if (likely(page && !PageHighMem(page)))
> + unpoison_shadow(page_address(page), PAGE_SIZE << order);
> +}
> +
> +void kasan_free_pages(struct page *page, unsigned int order)
> +{
> + if (unlikely(!kasan_initialized))
> + return;
> +
> + if (likely(!PageHighMem(page)))
> + poison_shadow(page_address(page), PAGE_SIZE << order,
> KASAN_FREE_PAGE);
> +}
> +
> void *kasan_memcpy(void *dst, const void *src, size_t len)
> {
> if (unlikely(len == 0))
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 711ae4f..be9597e 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -5,6 +5,7 @@
> #define KASAN_SHADOW_SCALE_SIZE (1UL << KASAN_SHADOW_SCALE_SHIFT)
> #define KASAN_SHADOW_MASK (KASAN_SHADOW_SCALE_SIZE - 1)
>
> +#define KASAN_FREE_PAGE 0xFF /* page was freed */
> #define KASAN_SHADOW_GAP0xF9 /* address belongs to shadow memory */
>
> struct access_info {
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 2430e05..6ef9e57 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -46,6 +46,9 @@ static void print_error_description(struct access_info
> *info)
> case 0 ... KASAN_SHADOW_SCALE_SIZE - 1:
> bug_type = "buffer overflow";
> break;
> + case KASAN_FREE_PAGE:
> + bug_type = "use after free";
> + break;
> case KASAN_SHADOW_GAP:
> bug_type = "wild memory access";
> break;
> @@ -67,6 +70,10 @@ static void print_address_description(struct access_info
> *info)
> page = virt_to_page(info->access_addr);
>
> switch (shadow_val) {
> + case KASAN_FREE_PAGE:
> + dump_page(page, "kasan error");
> + dump_stack();
> + break;
> case KASAN_SHADOW_GAP:
> pr_err("No metainfo is available for this access.\n");
> dump_stack();
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8c9eeec..67833d1 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -747,6 +748,7 @@ static bool free_pages_prepare(struct page *page,
> unsigned int order)
>
> trace_mm_page_free(page, order);
> kmemcheck_free_shadow(page, order);
> + kasan_free_pages(page, order);
>
> if (PageAnon(page))
> page->mapping = NULL;
> @@ -2807,6 +2809,7 @@ out:
> if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
> goto retry_cpuset;
>
> + kasan_alloc_pages(page, order);
> return page;
> }
> EXPORT_SYMBOL(__alloc_pages_nodemask);
> @@ -6415,6 +6418,7 @@ int alloc_contig_range(unsigned long
Re: linux-next: build failure after merge of the v4l-dvb tree
On 07/14/2014 08:29 PM, Stephen Rothwell wrote:
Hi Mauro,
After merging the v4l-dvb tree, today's linux-next build (powerpc
ppc64_defconfig)
failed like this:
arch/powerpc/kernel/smp.c:764:2: error: initialization from incompatible
pointer type [-Werror]
{ cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
^
arch/powerpc/kernel/smp.c:764:2: error: (near initialization for
'powerpc_topology[0].sd_flags') [-Werror]
Caused by commit 6a0b50087a89 ("Merge branch 'patchwork' into
to_next"). The change to include/linux/sched.h in this merge commit
does not seem to appear in either of the parents of the merge.
Its also a change that (when suggested) was shown to cause more
problems than it was worth and dropped. I can't imagine how it ended
up in the merge commit.
Do you mean b6220ad66 (sched: Fix compiler warnings) ? I thought that was
accepted
a week or so ago.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 07/14/2014 09:35 PM, Viresh Kumar wrote: On 15 July 2014 00:38, Saravana Kannan wrote: Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the mutex would be uninitialized if it's stopped after boot or it would never have been initialized (depending on how you fix policy->cpu at boot). Look at this snippet on the actual tree and it should be pretty evident. Yeah, I missed it. So the problem is we initialize timer_mutex's for policy->cpus. So we need to do that just for policy->cpu and also we don't need a per-cpu timer_mutex anymore. Btw, I tried to take a stab at removing any assumption in cpufreq code about policy->cpu being ONLINE. There are 160 instances of those of with 23 are in cpufreq.c So, even if we are sure cpufreq.c is fine, it's 137 other uses spread across all the other files. I definitely don't want to try and fix those as part of this patch. Way too risky and hard to get the test coverage it would need. Even some of the acpi cpufreq drivers seem to be making this assumption. Btw, I think v3 is done. I did some testing and it was fine. But made some minor changes. Will test tomorrow to make sure I didn't break anything with the minor changes and then send them out. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 2/2] dt/bindings: Add the DT binding documentation for endianness
> > +For one device driver, which will run in different scenarios above
> > +on different SoCs using the devicetree, we need one way to simplify
> > +this.
> > +
> > +Required properties:
> > +- {big,little}-endian: these are boolean properties, if absent
> > + meaning that the CPU and the Device are in the same endianness mode,
> > + these properties are for register values and all the buffers only.
> > +
>
> It would be more readable if its like this:
> Required properties:
> - {big,little}-endian:These are boolean properties, if absent meaning
> that the CPU and the Device are in the same
> endianness mode, these propperties are for
> values and all the buffers only.
>
Yes, it is.
See the next verison.
Thanks,
BRs
Xiubo
> > +Examples:
> > +Scenario 1 : CPU in LE mode & device in LE mode.
> > +dev: dev@40031000 {
> > + compatible = "name";
> > + reg = <0x40031000 0x1000>;
> > + ...
> > +};
> > +
> > +Scenario 2 : CPU in LE mode & device in BE mode.
> > +dev: dev@40031000 {
> > + compatible = "name";
> > + reg = <0x40031000 0x1000>;
> > + ...
> > + big-endian;
> > +};
> > +
> > +Scenario 3 : CPU in BE mode & device in BE mode.
> > +dev: dev@40031000 {
> > + compatible = "name";
> > + reg = <0x40031000 0x1000>;
> > + ...
> > +};
> > +
> > +Scenario 4 : CPU in BE mode & device in LE mode.
> > +dev: dev@40031000 {
> > + compatible = "name";
> > + reg = <0x40031000 0x1000>;
> > + ...
> > + little-endian;
> > +};
>
>
> --
> Regards,
> Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6 2/2] dt/bindings: Add the DT binding documentation for endianness
On 07/15/2014 09:53 AM, Xiubo Li wrote:
Device-Tree binding for device endianness
Index Device Endianness properties
---
1 BE 'big-endian'
2 LE 'little-endian'
For one device driver, which will run in different scenarios above
on different SoCs using the devicetree, we need one way to simplify
this.
Signed-off-by: Xiubo Li
---
.../devicetree/bindings/regmap/regmap.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt
diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt
b/Documentation/devicetree/bindings/regmap/regmap.txt
new file mode 100644
index 000..b494f8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/regmap.txt
@@ -0,0 +1,47 @@
+Device-Tree binding for regmap
+
+The endianness mode of CPU & Device scenarios:
+Index Device Endianness properties
+---
+1 BE 'big-endian'
+2 LE 'little-endian'
+
+For one device driver, which will run in different scenarios above
+on different SoCs using the devicetree, we need one way to simplify
+this.
+
+Required properties:
+- {big,little}-endian: these are boolean properties, if absent
+ meaning that the CPU and the Device are in the same endianness mode,
+ these properties are for register values and all the buffers only.
+
It would be more readable if its like this:
Required properties:
- {big,little}-endian: These are boolean properties, if absent meaning
that the CPU and the Device are in the same
endianness mode, these propperties are for
values and all the buffers only.
+Examples:
+Scenario 1 : CPU in LE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 2 : CPU in LE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ big-endian;
+};
+
+Scenario 3 : CPU in BE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 4 : CPU in BE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ little-endian;
+};
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuidle: fix permission for driver name sysfs node
Hi Rafael/Daniel,
Did you get a chance to review the patch?
--
Thanks,
-Meraj
On Sat, Jul 12, 2014 at 7:29 PM, Mohammad Merajul Islam Molla
wrote:
> cpuidle driver name sysfs node is read-only. So permission should be 0444.
>
> Signed-off-by: Mohammad Merajul Islam Molla
> ---
> drivers/cpuidle/sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> index efe2f17..97c5903 100644
> --- a/drivers/cpuidle/sysfs.c
> +++ b/drivers/cpuidle/sysfs.c
> @@ -445,7 +445,7 @@ static void cpuidle_remove_state_sysfs(struct
> cpuidle_device *device)
>
> #define define_one_driver_ro(_name, show) \
> static struct cpuidle_driver_attr attr_driver_##_name = \
> - __ATTR(_name, 0644, show, NULL)
> + __ATTR(_name, 0444, show, NULL)
>
> struct cpuidle_driver_kobj {
> struct cpuidle_driver *drv;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuidle: Fix Coding style reported by checkpatch.pl
On Mon, Jul 14, 2014 at 11:38 PM, Rafael J. Wysocki wrote:
> On Monday, July 14, 2014 12:40:24 PM pramod gurav wrote:
>> Hi Rafael,
>>
>> Can we consider these changes if there are no issues with this?
>
> Well, are you "fixing" checkpatch.pl warnings just for the sake of
> this or is there a deeper reason?
>
I was browsing through the source code and found couple of them. Then
ran checkpatch.pl to see if there are more. And thought the error
"Fixed: ERROR: do not use assignment in if condition" must be fixed.
Otherwise there is no reason.
> Rafael
>
>
>> On Fri, Jun 20, 2014 at 4:28 PM, pramod gurav
>> wrote:
>> > +linux-pm
>> >
>> > On Fri, Jun 20, 2014 at 4:27 PM, Pramod Gurav
>> > wrote:
>> >> Fixed: ERROR: do not use assignment in if condition
>> >> Fixed: WARNING: EXPORT_SYMBOL should immediately follow its function
>> >> Fixed: WARNING: line over 80 characters in a comment
>> >>
>> >> CC: Rafael J. Wysocki
>> >> CC: Daniel Lezcano
>> >>
>> >> Signed-off-by: Pramod Gurav
>> >> ---
>> >> drivers/cpuidle/cpuidle.c | 18 --
>> >> 1 file changed, 8 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> >> index 8236746..2c8752e 100644
>> >> --- a/drivers/cpuidle/cpuidle.c
>> >> +++ b/drivers/cpuidle/cpuidle.c
>> >> @@ -179,7 +179,9 @@ void cpuidle_reflect(struct cpuidle_device *dev, int
>> >> index)
>> >> void cpuidle_install_idle_handler(void)
>> >> {
>> >> if (enabled_devices) {
>> >> - /* Make sure all changes finished before we switch to new
>> >> idle */
>> >> + /*
>> >> +* Make sure all changes finished before we switch to new
>> >> idle
>> >> +*/
>> >> smp_wmb();
>> >> initialized = 1;
>> >> }
>> >> @@ -204,7 +206,6 @@ void cpuidle_pause_and_lock(void)
>> >> mutex_lock(_lock);
>> >> cpuidle_uninstall_idle_handler();
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_pause_and_lock);
>> >>
>> >> /**
>> >> @@ -215,7 +216,6 @@ void cpuidle_resume_and_unlock(void)
>> >> cpuidle_install_idle_handler();
>> >> mutex_unlock(_lock);
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_resume_and_unlock);
>> >>
>> >> /* Currently used in suspend/resume path to suspend cpuidle */
>> >> @@ -267,9 +267,11 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
>> >> if (ret)
>> >> return ret;
>> >>
>> >> - if (cpuidle_curr_governor->enable &&
>> >> - (ret = cpuidle_curr_governor->enable(drv, dev)))
>> >> - goto fail_sysfs;
>> >> + if (cpuidle_curr_governor->enable) {
>> >> + ret = cpuidle_curr_governor->enable(drv, dev);
>> >> + if (ret)
>> >> + goto fail_sysfs;
>> >> + }
>> >>
>> >> smp_wmb();
>> >>
>> >> @@ -283,7 +285,6 @@ fail_sysfs:
>> >>
>> >> return ret;
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_enable_device);
>> >>
>> >> /**
>> >> @@ -311,7 +312,6 @@ void cpuidle_disable_device(struct cpuidle_device
>> >> *dev)
>> >> cpuidle_remove_device_sysfs(dev);
>> >> enabled_devices--;
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_disable_device);
>> >>
>> >> static void __cpuidle_unregister_device(struct cpuidle_device *dev)
>> >> @@ -399,7 +399,6 @@ out_unregister:
>> >> __cpuidle_unregister_device(dev);
>> >> goto out_unlock;
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_register_device);
>> >>
>> >> /**
>> >> @@ -423,7 +422,6 @@ void cpuidle_unregister_device(struct cpuidle_device
>> >> *dev)
>> >>
>> >> cpuidle_resume_and_unlock();
>> >> }
>> >> -
>> >> EXPORT_SYMBOL_GPL(cpuidle_unregister_device);
>> >>
>> >> /**
>> >> --
>> >> 1.7.9.5
>> >>
>> >
>> >
>> >
>> > --
>> > Thanks and Regards
>> > Pramod
>>
>>
>>
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
Thanks and Regards
Pramod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BISECTED][REGRESSION] Loading Hyper-V network drivers is racy in 3.14+ on Hyper-V 2012 R2
On Mon, Jul 14, 2014 at 10:39:48PM +, Haiyang Zhang wrote: > > -Original Message- > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > Sent: Monday, July 14, 2014 5:31 PM > > To: Haiyang Zhang > > Cc: KY Srinivasan; David S. Miller; de...@linuxdriverproject.org; linux- > > ker...@vger.kernel.org; net...@vger.kernel.org > > Subject: Re: [BISECTED][REGRESSION] Loading Hyper-V network drivers is > > racy in 3.14+ on Hyper-V 2012 R2 > > Thanks for the tests! I will make a patch that can automatically retry > smaller memory allocs when memory is insufficient. This concerns me a bit - why would there be insufficient memory on a 64 bit VM with 4 GBytes of RAM just after startup (presumably the host's memory isn't the issue)? Additionally, while things might fail just when things are starting up, doing ifup eth0 at some point later succeeds so whatever issue it had seems temporary. Perhaps it would be wise to adding some debugging output to see if the allocation really failed and why... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] hwrng, virtio-rng: init-time fixes
On (Tue) 15 Jul 2014 [12:45:56], Herbert Xu wrote: > On Tue, Jul 15, 2014 at 10:10:28AM +0530, Amit Shah wrote: > > On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote: > > > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote: > > > > v3: > > > > - Kees Cook pointed out a weird side-effect: devices which have > > > >->init() registered get their randomness added to the system each > > > >time they're switched in, but devices that don't have the init > > > >callback don't contribute to system randomness more than once. The > > > >weirdness is resolved here by using the randomness each time > > > >hwrng_init() is attempted, irrespective of the existence of the > > > >device's ->init() callback. > > > > > > All applied to crypto. Thanks! > > > > Thanks, Herbert. I didn't mention it, but pls queue it up for 3.16. > > Yes that's why it's in crypto as opposed to cryptodev. Ah; thanks! Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, thp: only collapse hugepages to nodes with affinity
On 07/14/2014 06:09 PM, David Rientjes wrote:
> + if (node == NUMA_NO_NODE) {
> + node = page_to_nid(page);
> + } else {
> + int distance = node_distance(page_to_nid(page), node);
> +
> + /*
> + * Do not migrate to memory that would not be reclaimed
> + * from.
> + */
> + if (distance > RECLAIM_DISTANCE)
> + goto out_unmap;
> + }
Isn't the reclaim behavior based on zone_reclaim_mode and not
RECLAIM_DISTANCE directly? And isn't that reclaim behavior disabled by
default?
I think you should at least be consulting zone_reclaim_mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] hwrng, virtio-rng: init-time fixes
On Tue, Jul 15, 2014 at 10:10:28AM +0530, Amit Shah wrote: > On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote: > > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote: > > > v3: > > > - Kees Cook pointed out a weird side-effect: devices which have > > >->init() registered get their randomness added to the system each > > >time they're switched in, but devices that don't have the init > > >callback don't contribute to system randomness more than once. The > > >weirdness is resolved here by using the randomness each time > > >hwrng_init() is attempted, irrespective of the existence of the > > >device's ->init() callback. > > > > All applied to crypto. Thanks! > > Thanks, Herbert. I didn't mention it, but pls queue it up for 3.16. Yes that's why it's in crypto as opposed to cryptodev. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] hwrng, virtio-rng: init-time fixes
On (Mon) 14 Jul 2014 [20:50:06], Herbert Xu wrote: > On Thu, Jul 10, 2014 at 03:42:33PM +0530, Amit Shah wrote: > > v3: > > - Kees Cook pointed out a weird side-effect: devices which have > >->init() registered get their randomness added to the system each > >time they're switched in, but devices that don't have the init > >callback don't contribute to system randomness more than once. The > >weirdness is resolved here by using the randomness each time > >hwrng_init() is attempted, irrespective of the existence of the > >device's ->init() callback. > > All applied to crypto. Thanks! Thanks, Herbert. I didn't mention it, but pls queue it up for 3.16. Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One bug of SDHCI driver
From: Chris Ball
Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio
thread
781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
the use of our own custom threaded IRQ handler, but left in an
unconditional wake_up_process() on that handler at resume-time.
Reported-by: Fu, Zhonghui
[Patch suggested by Jaehoon Chung]
Signed-off-by: Chris Ball
---
drivers/mmc/core/sdio.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index e636d9e..11cc4e0 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -992,7 +992,8 @@ static int mmc_sdio_resume(struct mmc_host *host)
}
}
- if (!err && host->sdio_irqs)
+ if (!err && host->sdio_irqs &&
+ !(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD))
wake_up_process(host->sdio_irq_thread);
mmc_release_host(host);
--
1.7.9.5
On 07/15/2014 01:14 PM, Jaehoon Chung wrote:
> On 07/15/2014 11:54 AM, Fu, Zhonghui wrote:
>>
>> Hi,
>>
>> The data type of "host" is "struct mmc_host", and there is not "quirks"
>> member in this structure.
> Sorry for wrong typo.
> You use the "host->caps2" instead of "host->quirks".
>
>
> Best Regards,
> Jaehoon Chung
>>
>>
>> Thanks,
>> Zhonghui
>>
>> On 2014/7/14 21:26, Chris Ball wrote:
>>> Hi Zhonghui,
>>>
>>> On Tue, Jul 08 2014, Fu, Zhonghui wrote:
Why add "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" ? How to fix this bug?
Could you please give out some idea about this bug?
>>> Jaehoon already gave you a patch to fix this bug. Here it is again in
>>> proper patch form. Please can you test it and let us know whether it
>>> fixes the crash? Thanks.
>>>
>>>
>>> From: Chris Ball
>>> Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on
>>> sdio thread
>>>
>>> 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
>>> bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
>>> the use of our own custom threaded IRQ handler, but left in an
>>> unconditional wake_up_process() on that handler at resume-time.
>>>
>>> Reported-by: Fu, Zhonghui
>>> [Patch suggested by Jaehoon Chung]
>>> Signed-off-by: Chris Ball
>>> ---
>>> drivers/mmc/core/sdio.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>>> index e636d9e..2a128e2 100644
>>> --- a/drivers/mmc/core/sdio.c
>>> +++ b/drivers/mmc/core/sdio.c
>>> @@ -992,7 +992,8 @@ static int mmc_sdio_resume(struct mmc_host *host)
>>> }
>>> }
>>>
>>> - if (!err && host->sdio_irqs)
>>> + if (!err && host->sdio_irqs &&
>>> + !(host->quirks & MMC_CAP2_SDIO_IRQ_NOTHREAD))
>>> wake_up_process(host->sdio_irq_thread);
>>> mmc_release_host(host);
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG_ON drivers/char/random.c:986
On Fri, May 16, 2014 at 10:18:40PM -0400, Theodore Ts'o wrote:
> On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
> > This should do the trick:
> > dd if=/dev/urandom of=/dev/zero bs=67108707
> >
> > I suspect ee1de406ba6eb1 ("random: simplify accounting logic") as the
> > culprit.
>
> Yep, that it's it. Thanks for noticing this so quickly! I'll push
> the following patch to Linus.
>
> - Ted
>
> commit 29fb0ca5b3922288fba3f4c975a55032a51df0f0
> Author: Theodore Ts'o
> Date: Fri May 16 21:40:41 2014 -0400
>
> random: fix BUG_ON caused by accounting simplification
I just hit this bug again on 3.16rc5, which has this patch, so
there's still some corner case that isn't happy..
(old thread is here for reference: https://lkml.org/lkml/2014/5/16/724)
kernel BUG at drivers/char/random.c:986!
invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 2 PID: 29845 Comm: trinity-c65 Not tainted 3.16.0-rc5+ #22
task: 880096f45880 ti: 88017dfe8000 task.ti: 88017dfe8000
RIP: 0010:[] [] account+0x14c/0x150
RSP: 0018:88017dfebd38 EFLAGS: 00010206
RAX: 2000 RBX: 0027ae6c RCX:
RDX: RSI: 0027ae6c RDI: 8dcb6840
RBP: 88017dfebd98 R08: 8d423490 R09:
R10: 8dcb68a4 R11: R12: 7fe396cec000
R13: R14: 8dcb6840 R15: 8da85638
FS: 7fe39a1e2700() GS:88024d10() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00012e5a3000 CR4: 001407e0
DR0: 0111b000 DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0600
Stack:
8d423340 a4c39e97 8dcb6840
0002 a4c39e97 7fe396cec000
0027ae6c 005a 0027ae6c 8d423490
Call Trace:
[] ? extract_entropy_user+0x60/0x1b0
[] ? extract_entropy_user+0x1b0/0x1b0
[] urandom_read+0x37/0x110
[] ? extract_entropy_user+0x1b0/0x1b0
[] do_loop_readv_writev+0x63/0x90
[] ? extract_entropy_user+0x1b0/0x1b0
[] do_readv_writev+0x268/0x280
[] ? __acct_update_integrals+0x8b/0x120
[] ? preempt_count_sub+0xab/0x100
[] ? __this_cpu_preempt_check+0x13/0x20
[] vfs_readv+0x36/0x50
[] SyS_readv+0x5c/0x100
[] tracesys+0xdd/0xe2
Code: cb 8d e8 d8 e0 c9 ff ba 02 00 02 00 be 1d 00 00 00 48 c7 c7 40 20 00 8e
e8 d2 45 dc ff 48 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 66 90 0f 1f 44
00 00 55 48 89 e5 41 57 41 56 49 89 fe 41
RIP [] account+0x14c/0x150
RSP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 2/2] dt/bindings: Add the DT binding documentation for endianness
Device-Tree binding for device endianness
Index Device Endianness properties
---
1 BE 'big-endian'
2 LE 'little-endian'
For one device driver, which will run in different scenarios above
on different SoCs using the devicetree, we need one way to simplify
this.
Signed-off-by: Xiubo Li
---
.../devicetree/bindings/regmap/regmap.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt
diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt
b/Documentation/devicetree/bindings/regmap/regmap.txt
new file mode 100644
index 000..cc5f7f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/regmap.txt
@@ -0,0 +1,48 @@
+Device-Tree binding for device endianness
+
+The endianness mode of CPU & Device scenarios:
+IndexCPU Device Endianness properties
+
+1LELE -
+2LEBE 'big-endian{,-*}'
+3BEBE -
+4BELE 'little-endian{,-*}'
+
+For one device driver, which will run in different scenarios above
+on different SoCs using the devicetree, we need one way to simplify
+this.
+
+Required properties:
+- {big,little}-endian{,-*}: these are boolean properties, if absent
+ meaning that the CPU and the Device are in the same endianness mode.
+
+Examples:
+Scenario 1 : CPU in LE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 2 : CPU in LE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ big-endian{,-*};
+};
+
+Scenario 3 : CPU in BE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 4 : CPU in BE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ little-endian{,-*};
+};
--
1.8.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 00/83] AMD HSA kernel driver
On 14 July 2014 18:37, Christian König wrote: >> I vote for HSA module that expose ioctl and is an intermediary with the >> kernel driver that handle the hardware. This gives a single point for >> HSA hardware and yes this enforce things for any hardware manufacturer. >> I am more than happy to tell them that this is it and nothing else if >> they want to get upstream. > > I think we should still discuss this single point of entry a bit more. > > Just to make it clear the plan is to expose all physical HSA capable devices > through a single /dev/hsa device node to userspace. This is why we don't design kernel interfaces in secret foundations, and expect anyone to like them. So before we go any further, how is this stuff planned to work for multiple GPUs/accelerators? Do we have a userspace to exercise this interface so we can see how such a thing would look? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 15 July 2014 00:38, Saravana Kannan wrote: > Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the > mutex would be uninitialized if it's stopped after boot or it would never > have been initialized (depending on how you fix policy->cpu at boot). > > Look at this snippet on the actual tree and it should be pretty evident. Yeah, I missed it. So the problem is we initialize timer_mutex's for policy->cpus. So we need to do that just for policy->cpu and also we don't need a per-cpu timer_mutex anymore. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv5 2/2] dt/bindings: Add the DT binding documentation for endianness
Hi,
Please ignore this V5 patch series.
Thanks,
BRs
> -Original Message-
> From: Xiubo Li [mailto:li.xi...@freescale.com]
> Sent: Tuesday, July 15, 2014 12:18 PM
> To: broo...@kernel.org; mark.rutl...@arm.com
> Cc: robh...@kernel.org; pawel.m...@arm.com; ijc+devicet...@hellion.org.uk;
> ga...@codeaurora.org; gre...@linuxfoundation.org;
> linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Xiubo Li-B47053
> Subject: [PATCHv5 2/2] dt/bindings: Add the DT binding documentation for
> endianness
>
> Device-Tree binding for device endianness
> Index Device Endianness properties
> ---
> 1 BE 'big-endian'
> 2 LE 'little-endian'
>
> For one device driver, which will run in different scenarios above
> on different SoCs using the devicetree, we need one way to simplify
> this.
>
> Signed-off-by: Xiubo Li
> ---
> .../devicetree/bindings/regmap/regmap.txt | 48
> ++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt
>
> diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt
> b/Documentation/devicetree/bindings/regmap/regmap.txt
> new file mode 100644
> index 000..cc5f7f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regmap/regmap.txt
> @@ -0,0 +1,48 @@
> +Device-Tree binding for device endianness
> +
> +The endianness mode of CPU & Device scenarios:
> +IndexCPU Device Endianness properties
> +
> +1LELE -
> +2LEBE 'big-endian{,-*}'
> +3BEBE -
> +4BELE 'little-endian{,-*}'
> +
> +For one device driver, which will run in different scenarios above
> +on different SoCs using the devicetree, we need one way to simplify
> +this.
> +
> +Required properties:
> +- {big,little}-endian{,-*}: these are boolean properties, if absent
> + meaning that the CPU and the Device are in the same endianness mode.
> +
> +Examples:
> +Scenario 1 : CPU in LE mode & device in LE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> +};
> +
> +Scenario 2 : CPU in LE mode & device in BE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> + big-endian{,-*};
> +};
> +
> +Scenario 3 : CPU in BE mode & device in BE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> +};
> +
> +Scenario 4 : CPU in BE mode & device in LE mode.
> +dev: dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + ...
> + little-endian{,-*};
> +};
> --
> 1.8.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] x86,cpu-hotplug: assign same CPU number to readded CPU
Hi Borislav,
(2014/07/11 19:59), Borislav Petkov wrote:
On Fri, Jul 11, 2014 at 09:48:27AM +0900, Yasuaki Ishimatsu wrote:
+static int get_cpuid(int apicid)
Btw this "cpuid" is misleading. Call it "cpu_num" or so.
O.K.
I'll update it.
+{
+ int cpuid;
+
+ cpuid = apicid_to_cpuid[apicid];
+ if (cpuid < 0)
+ cpuid = cpumask_next_zero(-1, cpu_used_mask);
Why do you need additional cpu bitmask?
To assing new CPU number, I prepared new cpu bitmask.
The following two steps are necessary to assign CPU number to APIC ID.
1. Check whether APIC ID has been assigned CPU number
2. Assign new CPU number if ACPI ID has not been assigned CPU number (it
means apicid_to_cpuid[] returns -1)
Step 1. is checked by apicid_to_cpuid[]. And step 2. assigns new CPU
number by using cpu_used_mask.
To keep cpu number, cpumask must not be cleared by hot removing CPU.
If cpumask is cleared by hot removing CPU, the cpumask cannot be used
to keep CPU number.
Currently, cpu_present_map is used to assign CPU number. But the cpumask
is cleared by hot removing CPU since the mask is prepared to remember
existed CPUs in the system. So the cpu_present_map must be cleared
at CPU hot remove.
I confirmed whether present cpumasks (cpu_possible_map, cpu_online_map
et al) is usable or not for this purpose. But there is no cpumask that
can be used to keep CPU number. So I prepared new cpu bitmask.
How about just finding the first apicid_to_cpuid[apicid] < 0
and dropping not needed anymore bitmask.
When apicid_to_cpuid[] return -1, kernel assigns new CPU number. For
this, the cpu_used_mask is necessary.
And we can't have that - we cannot have cores which had number X get
number Y after hotplug.
Can you send a full dmesg after you've done a physical node hotplug on a
machine? Privately is fine too.
O.K.
I'll send dmesg.
Thanks,
Yasuaki Ishimatsu
Boot with
"ignore_loglevel log_buf_len=10M debug apic=debug show_lapic=all"
please.
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/
[PATCHv6 0/2] add DT endianness binding support for regmap
Changes in V6: - there is some mistake for V5 patch series, resend it. Changes in V5: - remove the register's dt endianness support for it will always be BE for now. - only support the register values buffers dt endianness support. Xiubo Li (2): regmap: add DT endianness binding support. dt/bindings: Add the DT binding documentation for endianness .../devicetree/bindings/regmap/regmap.txt | 48 + drivers/base/regmap/regmap-i2c.c | 2 + drivers/base/regmap/regmap-spi.c | 2 + drivers/base/regmap/regmap.c | 117 +++-- 4 files changed, 158 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt -- 1.8.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/
[PATCHv6 2/2] dt/bindings: Add the DT binding documentation for endianness
Device-Tree binding for device endianness
Index Device Endianness properties
---
1 BE 'big-endian'
2 LE 'little-endian'
For one device driver, which will run in different scenarios above
on different SoCs using the devicetree, we need one way to simplify
this.
Signed-off-by: Xiubo Li
---
.../devicetree/bindings/regmap/regmap.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt
diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt
b/Documentation/devicetree/bindings/regmap/regmap.txt
new file mode 100644
index 000..b494f8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/regmap.txt
@@ -0,0 +1,47 @@
+Device-Tree binding for regmap
+
+The endianness mode of CPU & Device scenarios:
+Index Device Endianness properties
+---
+1 BE 'big-endian'
+2 LE 'little-endian'
+
+For one device driver, which will run in different scenarios above
+on different SoCs using the devicetree, we need one way to simplify
+this.
+
+Required properties:
+- {big,little}-endian: these are boolean properties, if absent
+ meaning that the CPU and the Device are in the same endianness mode,
+ these properties are for register values and all the buffers only.
+
+Examples:
+Scenario 1 : CPU in LE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 2 : CPU in LE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ big-endian;
+};
+
+Scenario 3 : CPU in BE mode & device in BE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+};
+
+Scenario 4 : CPU in BE mode & device in LE mode.
+dev: dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ ...
+ little-endian;
+};
--
1.8.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/
[PATCHv6 1/2] regmap: add DT endianness binding support.
For many drivers which will support rich endianness of Devices
need define DT properties by itself with the binding support.
The endianness using regmap:
Index Device Properties if needs bytes-swap,
or just ignore it
-
1 BE 'big-endian'
2 LE 'little-endian'
The properties include all the register values and the buffers.
And these properties are very usful for the MMIO devices:
Such as: a memory-mapped device, on one SoC is in BE mode, while
in another SoC will be in LE mode, and the CPU will always in LE
mode.
For the first case, we must use cpu_to_be32/be32_to_cpu for
32-bit registers accessing, so the 'big-endian' property is needed.
For the second case, we can just ignore the bytes-swap
functions like cpu_to_le32/le32_to_cpu, so the 'little-endian'
property could be abscent.
And vice versa...
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regmap-i2c.c | 2 +
drivers/base/regmap/regmap-spi.c | 2 +
drivers/base/regmap/regmap.c | 117 +++
3 files changed, 110 insertions(+), 11 deletions(-)
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index ca193d1..053150a 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -168,6 +168,8 @@ static struct regmap_bus regmap_i2c = {
.write = regmap_i2c_write,
.gather_write = regmap_i2c_gather_write,
.read = regmap_i2c_read,
+ .reg_format_endian_default = REGMAP_ENDIAN_BIG,
+ .val_format_endian_default = REGMAP_ENDIAN_BIG,
};
static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
diff --git a/drivers/base/regmap/regmap-spi.c b/drivers/base/regmap/regmap-spi.c
index 0eb3097..53d1148 100644
--- a/drivers/base/regmap/regmap-spi.c
+++ b/drivers/base/regmap/regmap-spi.c
@@ -109,6 +109,8 @@ static struct regmap_bus regmap_spi = {
.async_alloc = regmap_spi_async_alloc,
.read = regmap_spi_read,
.read_flag_mask = 0x80,
+ .reg_format_endian_default = REGMAP_ENDIAN_BIG,
+ .val_format_endian_default = REGMAP_ENDIAN_BIG,
};
/**
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 74d8c06..c033766 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -448,6 +449,102 @@ int regmap_attach_dev(struct device *dev, struct regmap
*map,
}
EXPORT_SYMBOL_GPL(regmap_attach_dev);
+enum regmap_endian_type {
+ REGMAP_ENDIAN_REG,
+ REGMAP_ENDIAN_VAL,
+};
+
+static int of_regmap_get_endian(struct device *dev,
+ const struct regmap_bus *bus,
+ const struct regmap_config *config,
+ enum regmap_endian_type type,
+ enum regmap_endian *endian)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!endian || !config)
+ return -EINVAL;
+
+ /*
+* Firstly, try to parse the endianness from driver's config,
+* this is to be compatible with the none DT or the old drivers.
+* From the driver's config the endianness value maybe:
+* REGMAP_ENDIAN_BIG,
+* REGMAP_ENDIAN_LITTLE,
+* REGMAP_ENDIAN_NATIVE,
+* REGMAP_ENDIAN_DEFAULT.
+*/
+ switch (type) {
+ case REGMAP_ENDIAN_REG:
+ *endian = config->reg_format_endian;
+ break;
+ case REGMAP_ENDIAN_VAL:
+ *endian = config->val_format_endian;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+* If the endianness parsed from driver config is
+* REGMAP_ENDIAN_DEFAULT, that means maybe we are using the DT
+* node to specify the endianness information.
+*/
+ if (*endian != REGMAP_ENDIAN_DEFAULT)
+ return 0;
+
+ /*
+* Secondly, try to parse the endianness from DT node if the
+* driver config does not specify it.
+* From the DT node the endianness value maybe:
+* REGMAP_ENDIAN_BIG,
+* REGMAP_ENDIAN_LITTLE,
+* REGMAP_ENDIAN_NATIVE,
+*/
+ switch (type) {
+ case REGMAP_ENDIAN_VAL:
+ if (of_property_read_bool(np, "big-endian"))
+ *endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ *endian = REGMAP_ENDIAN_LITTLE;
+ else
+ *endian = REGMAP_ENDIAN_NATIVE;
+ break;
+ case REGMAP_ENDIAN_REG:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+* If the endianness parsed from DT node is REGMAP_ENDIAN_NATIVE, that
+* maybe means
[PATCHv5 1/2] regmap: add DT endianness binding support.
For many drivers which will support rich endianness of Devices
need define DT properties by itself with the binding support.
The endianness using regmap:
Index Device Properties if needs bytes-swap,
or just ignore it
-
1 BE 'big-endian'
2 LE 'little-endian'
The properties include all the register values and the buffers.
And these properties are very usful for the MMIO devices:
Such as: a memory-mapped device, on one SoC is in BE mode, while
in another SoC will be in LE mode, and the CPU will always in LE
mode.
For the first case, we must use cpu_to_be32/be32_to_cpu for
32-bit registers accessing, so the 'big-endian' property is needed.
For the second case, we can just ignore the bytes-swap
functions like cpu_to_le32/le32_to_cpu, so the 'little-endian'
property could be abscent.
And vice versa...
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regmap-i2c.c | 2 +
drivers/base/regmap/regmap-spi.c | 2 +
drivers/base/regmap/regmap.c | 117 +++
3 files changed, 110 insertions(+), 11 deletions(-)
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index ca193d1..053150a 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -168,6 +168,8 @@ static struct regmap_bus regmap_i2c = {
.write = regmap_i2c_write,
.gather_write = regmap_i2c_gather_write,
.read = regmap_i2c_read,
+ .reg_format_endian_default = REGMAP_ENDIAN_BIG,
+ .val_format_endian_default = REGMAP_ENDIAN_BIG,
};
static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
diff --git a/drivers/base/regmap/regmap-spi.c b/drivers/base/regmap/regmap-spi.c
index 0eb3097..53d1148 100644
--- a/drivers/base/regmap/regmap-spi.c
+++ b/drivers/base/regmap/regmap-spi.c
@@ -109,6 +109,8 @@ static struct regmap_bus regmap_spi = {
.async_alloc = regmap_spi_async_alloc,
.read = regmap_spi_read,
.read_flag_mask = 0x80,
+ .reg_format_endian_default = REGMAP_ENDIAN_BIG,
+ .val_format_endian_default = REGMAP_ENDIAN_BIG,
};
/**
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 74d8c06..c033766 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -448,6 +449,102 @@ int regmap_attach_dev(struct device *dev, struct regmap
*map,
}
EXPORT_SYMBOL_GPL(regmap_attach_dev);
+enum regmap_endian_type {
+ REGMAP_ENDIAN_REG,
+ REGMAP_ENDIAN_VAL,
+};
+
+static int of_regmap_get_endian(struct device *dev,
+ const struct regmap_bus *bus,
+ const struct regmap_config *config,
+ enum regmap_endian_type type,
+ enum regmap_endian *endian)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!endian || !config)
+ return -EINVAL;
+
+ /*
+* Firstly, try to parse the endianness from driver's config,
+* this is to be compatible with the none DT or the old drivers.
+* From the driver's config the endianness value maybe:
+* REGMAP_ENDIAN_BIG,
+* REGMAP_ENDIAN_LITTLE,
+* REGMAP_ENDIAN_NATIVE,
+* REGMAP_ENDIAN_DEFAULT.
+*/
+ switch (type) {
+ case REGMAP_ENDIAN_REG:
+ *endian = config->reg_format_endian;
+ break;
+ case REGMAP_ENDIAN_VAL:
+ *endian = config->val_format_endian;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+* If the endianness parsed from driver config is
+* REGMAP_ENDIAN_DEFAULT, that means maybe we are using the DT
+* node to specify the endianness information.
+*/
+ if (*endian != REGMAP_ENDIAN_DEFAULT)
+ return 0;
+
+ /*
+* Secondly, try to parse the endianness from DT node if the
+* driver config does not specify it.
+* From the DT node the endianness value maybe:
+* REGMAP_ENDIAN_BIG,
+* REGMAP_ENDIAN_LITTLE,
+* REGMAP_ENDIAN_NATIVE,
+*/
+ switch (type) {
+ case REGMAP_ENDIAN_VAL:
+ if (of_property_read_bool(np, "big-endian"))
+ *endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ *endian = REGMAP_ENDIAN_LITTLE;
+ else
+ *endian = REGMAP_ENDIAN_NATIVE;
+ break;
+ case REGMAP_ENDIAN_REG:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /*
+* If the endianness parsed from DT node is REGMAP_ENDIAN_NATIVE, that
+* maybe means
[PATCHv5 0/2] add DT endianness binding support for regmap
Changes in V5: - remove the register's dt endianness support for it will always be BE for now. - only support the register values buffers dt endianness support. Xiubo Li (2): regmap: add DT endianness binding support. dt/bindings: Add the DT binding documentation for endianness .../devicetree/bindings/regmap/regmap.txt | 48 + drivers/base/regmap/regmap-i2c.c | 2 + drivers/base/regmap/regmap-spi.c | 2 + drivers/base/regmap/regmap.c | 117 +++-- 4 files changed, 158 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/regmap/regmap.txt -- 1.8.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC]Pid conversion between pid namespace
Quoting chenhanx...@cn.fujitsu.com (chenhanx...@cn.fujitsu.com): > Hi, > > Let me summarize our discussions of ID conversion by pros/cons: > > A) make new system call for translation > A-1) systemcall(ID, NS1, NS2) into (ID). > pros: > - has a reference ns(NS2) > We could get any lower level ID directly. > > cons: > - lack of hierarchy information. > CRIU need hierarchy info for checkpoint/restore in nested > containers. > - not easy for debug. > And a lot of tools/libs need be modified. > > A-2) syscall pid_t getnspid(pid_t query_pid, pid_t observer_pid) > pros: > - ns procfs free, easy to use. > We could get rid of mounted ns procfs. > > cons: > - may find multiple results in nested ns. > We wished the new API could tell us the exact answer. > But if getnspid return more than one results will bring trouble to > admins, (See below for more, but) the question being posed to getnspid has precisely one answer. > they had to make another decision. > Or we marked the deepest level for translation as prerequisite. > > -based on current pidns, no reference ns. Hm, no. The intent here was that observer_pid would be in current ns query_pid would be in observer_pid's ns. So this would be ideal for "I got a pid in a logfile created by rsyslog in a nested contaner, what is the logged pid in my pidns." Taking a set of tasks (like a container with nesting) and bulding a tree of all pids shouldn't be too difficult either. Start with the init pid, call getnspid($pid, $init_pid) for every $pid in the container; to figure out whether any $pid is itself a nested init_pid, we can compare the /proc/$$/ns/pid, as well as look at getnspid($pid, $pid). > B) make/change proc file/directories > B-1) expand /proc/pid/status > pros: > - easy to use and to debug > - already had existed interface in kernel > > cons: > - based on current ns > for middle level, we had to make another decision. > - do not have hierarchy info. > > B-2) /proc//ns/proc/ which would contain everything > pros: > - have enough info from /proc in container > > cons: > - Requirements unclear. > We need more discussion to decide which items should not be exposed. > - do not have hierarchy info. > > > How about do these things in two steps: > > C) 1. expose all sets of pid, pgid, sid and tgid > via expanded /proc/PID/status > We could get translated IDs from container like: > NStgid: 16465 5 1 > NSpid:16465 5 1 > NSpgid: 16465 5 1 > NSsid:16423 1 0 > (a set of IDs with 3 level of ns) > > 2. add hierarchy info under /proc > We lacked of method of getting hierarchy info, which is useful. > Then we could know the relationship of ns. > How about adding a new proc file just under /proc > to show the hierarchy like readlink did: > pid:[4026531836]-> [4026532390] -> [4026532484] > pid:[4026531836]-> [4026532491] > (A 3 level pid and 2 level pid_ > > Any comments would be appreciated. > > Thanks, > - Chen > > > -Original Message- > > Subject: [RFC]Pid conversion between pid namespace > > > > Hi, > > > > We had some discussions on how to carry out > > pid conversion between pid namespace via: > > syscall[1] and procfs[2]. > > > > Pavel suggested that a syscall like > > (ID, NS1, NS2) into (ID). > > > > Serge suggested that a syscall > > pid_t getnspid(pid_t query_pid, pid_t observer_pid). > > > > > > Eric and Richard suggested a procfs solution is > > more appropriate. > > > > Oleg suggested that we should expand /proc/pid/status > > to report this kind of information. > > > > And Richard suggested adding a directory like > > /proc//ns/proc/ which would contain everything > > from /proc//. > > > > As procfs provided a more user friendly interface, > > how about expose all sets of tgid, pid, pgid, sid > > by expanding /proc/PID/status in procfs? > > And we could also expose ns hierarchy under /proc, > > which could be another reference. > > > > Ex: > > init_pid_nsns1 ns2 > > t1 2 > > t2 `- 3 1 > > t3 `- 4 `- 51 > > > > We could get in /proc/t3/status: > > NSpid: 4 5 1 > > We knew that pid 1 in container is pid 4 in init ns. > > > > And we could get ns hierarchy under /proc/ns_hierarchy like: > > init_ns->ns1->ns2 (as the result of readlink) > > ->ns3 > > We knew that t3 in ns2, and its hierarchy. > > > > How these ideas looks like? > > Any comments would be appreciated. > > > > Thanks, > > - Chen > > > > > > a) syscall > > http://lwn.net/Articles/602987/ > > > > b) procfs > > http://www.spinics.net/lists/kernel/msg1751688.html > >
Re: Is espfix64's double-fault thing OK on Xen?
On 07/14/2014 07:46 PM, Andy Lutomirski wrote: > > On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS > always fails. Native (32-bit or 64-bit, according to the binary) CS > with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I > find this somewhat odd. Native ss always passes. > espfix32 is disabled on Xen. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: One bug of SDHCI driver
On 07/15/2014 11:54 AM, Fu, Zhonghui wrote:
>
> Hi,
>
> The data type of "host" is "struct mmc_host", and there is not "quirks"
> member in this structure.
Sorry for wrong typo.
You use the "host->caps2" instead of "host->quirks".
Best Regards,
Jaehoon Chung
>
>
> Thanks,
> Zhonghui
>
> On 2014/7/14 21:26, Chris Ball wrote:
>> Hi Zhonghui,
>>
>> On Tue, Jul 08 2014, Fu, Zhonghui wrote:
>>> Why add "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" ? How to fix this bug?
>>>
>>> Could you please give out some idea about this bug?
>> Jaehoon already gave you a patch to fix this bug. Here it is again in
>> proper patch form. Please can you test it and let us know whether it
>> fixes the crash? Thanks.
>>
>>
>> From: Chris Ball
>> Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on
>> sdio thread
>>
>> 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
>> bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
>> the use of our own custom threaded IRQ handler, but left in an
>> unconditional wake_up_process() on that handler at resume-time.
>>
>> Reported-by: Fu, Zhonghui
>> [Patch suggested by Jaehoon Chung]
>> Signed-off-by: Chris Ball
>> ---
>> drivers/mmc/core/sdio.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>> index e636d9e..2a128e2 100644
>> --- a/drivers/mmc/core/sdio.c
>> +++ b/drivers/mmc/core/sdio.c
>> @@ -992,7 +992,8 @@ static int mmc_sdio_resume(struct mmc_host *host)
>> }
>> }
>>
>> -if (!err && host->sdio_irqs)
>> +if (!err && host->sdio_irqs &&
>> +!(host->quirks & MMC_CAP2_SDIO_IRQ_NOTHREAD))
>> wake_up_process(host->sdio_irq_thread);
>> mmc_release_host(host);
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf, x86: Don't mark DataLA addresses as store
On Tue, Jul 15, 2014 at 12:50:27AM +0200, Stephane Eranian wrote: > On Tue, Jul 15, 2014 at 12:49 AM, Stephane Eranian wrote: > > On Tue, Jul 15, 2014 at 12:39 AM, Andi Kleen wrote: > >>> I have a problem with this patch. > >>> > >>> It makes: perf mem -t store rec record OP_NA for the store. > >>> It was recording OP_STORE before. > >>> > >>> I think we need to keep LD/ST info. This is useful for analysis > >>> especially if we collect loads/stores simultaneously. > >>> > >>> Was working before for the mem-loads, mem-stores events. > >> > >> Ok. Would it be enough if it only worked for "mem-stores" and not > >> all PEBS events? > >> > > Ok, do that at a minimum. > > > But if I recall the PEBS stores events were not that many to begin with. Yes, there are only three store events: MEM_UOPS_RETIRED.STLB_MISS_STORES MEM_UOPS_RETIRED.SPLIT_STORES MEM_UOPS_RETIRED.ALL_STORES These can be added. But most others are loads, so if you wanted loads too (besides mem-loads) it would be nearly a full list. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6 v2] autofs4: factor should_expire() out of autofs4_expire_indirect.
On Tue, 15 Jul 2014 11:48:33 +0800 Ian Kent wrote: ... > So far I've tracked this to something that was introduced between 3.11 > and 3.12. One change that went into 3.12 was Jeff Laytons' umount > specific path resolution for umount. I've found this is also broken on > recent RHEL-6 kernels and that change is present in them too so the > evidence is leaning toward that being the problem. Just how could happen > with this change I have no clue so far, it just doesn't make sense. Such a familiar story! I've not yet failed to find bugs like that, but sometimes it takes a long time. Good luck! > > Anyway that's going to make testing these patches impossible until I can > work out what the problem is and fix it. > > Very sorry to hold you up on this but it can't be avoided. Thanks a lot for letting me know the situation! While I always appreciate upstream review I've learnt not to depend on it. I'll proceed with my customers based on my judgement and look forward to any input you can provide whenever you are able to provide it. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH 2/2] staging: comedi: addi_apci_1564: use addi_watchdog module to init watchdog subdevice
On Mon, Jul 14, 2014 at 4:22 AM, Ian Abbott wrote: > On 2014-07-12 23:44, Chase Southwood wrote: >> >> Use the addi_watchdog module to provide support for the watchdog >> subdevice. >> >> Also, rearrange the subdevice init blocks so that the order makes sense. >> Digital input/output subdevices and subdevices for DI/DO interrupt >> support, followed by timer/counter/watchdog subdevices is the new order. >> >> Signed-off-by: Chase Southwood >> Cc: Ian Abbott >> Cc: H Hartley Sweeten >> --- >> drivers/staging/comedi/drivers/addi_apci_1564.c | 34 >> +++-- >> 1 file changed, 20 insertions(+), 14 deletions(-) > > > I don't think the subdevice order matters that much, and I prefer to keep > them stable, but since this driver is in such a state of flux, it doesn't > really matter. > Hi Ian! Quick question here about this. First off, duly noted that grouping subdevices by function isn't necessary and I won't shuffle them around like this in the future. Second, the reason I stuck the watchdog at the end is because it causes an early return if addi_watchdog_init() returns an error and it seemed appropriate at the end so it doesn't prevent the initialization of any other subdevices if that call should fail. Now I realize that it is very unlikely that that call fails, but in any case should I put future subdevice inits above the watchdog for the same reason (so they aren't at risk of not getting initialized), or does that count for subdevice order not being stable and you would prefer them all to go at the end? Thanks, Chase > Reviewed-by: Ian Abbott > > -- > -=( Ian Abbott @ MEV Ltd.E-mail: )=- > -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 pm tree with the ia64 tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
drivers/acpi/acpi_extlog.c between commits 2dfb7d51a61d ("trace, RAS:
Add eMCA trace event interface") and d6cae935ec5b ("trace, eMCA: Add a
knob to adjust where to save event log") from the ia64 tree and commit
0a00fd5e20fd ("ACPICA: Restore error table definitions to reduce code
differences between Linux and ACPICA upstream") from the pm tree.
I fixed it up (hopefully - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/acpi/acpi_extlog.c
index 0ad6f389d922,340d09518f8e..
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@@ -139,12 -137,8 +139,12 @@@ static int extlog_print(struct notifier
struct mce *mce = (struct mce *)data;
int bank = mce->bank;
int cpu = mce->extcpu;
- struct acpi_generic_status *estatus, *tmp;
- struct acpi_generic_data *gdata;
- struct acpi_hest_generic_status *estatus;
- int rc;
++ struct acpi_hest_generic_status *estatus, *tmp;
++ struct acpi_hest_generic_data *gdata;
+ const uuid_le *fru_id = _UUID_LE;
+ char *fru_text = "";
+ uuid_le *sec_type;
+ static u32 err_seq;
estatus = extlog_elog_entry_check(cpu, bank);
if (estatus == NULL)
@@@ -154,29 -148,8 +154,29 @@@
/* clear record status to enable BIOS to update it again */
estatus->block_status = 0;
- tmp = (struct acpi_generic_status *)elog_buf;
- rc = print_extlog_rcd(NULL, (struct acpi_hest_generic_status
*)elog_buf, cpu);
++ tmp = (struct acpi_hest_generic_status *)elog_buf;
+
+ if (!ras_userspace_consumers()) {
+ print_extlog_rcd(NULL, tmp, cpu);
+ goto out;
+ }
+
+ /* log event via trace */
+ err_seq++;
- gdata = (struct acpi_generic_data *)(tmp + 1);
++ gdata = (struct acpi_hest_generic_data *)(tmp + 1);
+ if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
+ fru_id = (uuid_le *)gdata->fru_id;
+ if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
+ fru_text = gdata->fru_text;
+ sec_type = (uuid_le *)gdata->section_type;
+ if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+ struct cper_sec_mem_err *mem = (void *)(gdata + 1);
+ if (gdata->error_data_length >= sizeof(*mem))
+ trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,
+ (u8)gdata->error_severity);
+ }
+out:
return NOTIFY_STOP;
}
signature.asc
Description: PGP signature
Re: [PATCH v2] drivers: staging: lustre: Use 'force_die' instead of 'die' to avoid compiling issue
在 2014年7月15日，上午9:40，Greg Kroah-Hartman 写道：
> On Mon, Jul 14, 2014 at 08:04:15PM +0800, Chen Gang wrote:
>>
>> For drivers/staging/lustre/lustre/include/lustre_sec.h:391:
>>
>> - staging tree: use '\t ' between 'die' and '('.
>>
>> - linux-next tree: use ' ' between 'die' and '('.
>>
>> So the patch made under linux-next tree, can not apply to staging-next
>> or staging tree.
>
> It seems to work just fine here, I don't see a problem...
>
Yeah, the latest linux-next tree also uses ‘\t “, but the previous one not.
:-)
Thanks.
—
Chen Gang
Open, share, and attitude like air, water, and life which God blessed--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6 v2] autofs4: factor should_expire() out of autofs4_expire_indirect.
On Mon, 2014-07-14 at 10:53 +1000, NeilBrown wrote:
> Here is a revised version of this one patch.
> This one fixes a problem with refcounts on dentry and adds a comment to
> clarify the behaviour of should_expire().
I have some bad news I'm afraid, not about the patches.
As I mentioned I'm well behind in some time sensitive work I need to do
and I've suddenly run into a completely unexpected and quite serious
problem related to the amd map format parser I've added to autofs.
I did most of the development for that on the 3.10 series kernel and
that worked fine, and since I made hardly any kernel changes, I expected
there wouldn't be further problems.
Now I come to develop RHEL-6 tests for it for QA purposes (which I
started to do on Fedora 20, 3.14 series kernel) and the symlink handling
is suddenly broken.
The symptom is an autofs mount that has contained a symlink (whether
it's still present or not) can't be umounted and I use symlinks a lot
with the amd parser.
So far I've tracked this to something that was introduced between 3.11
and 3.12. One change that went into 3.12 was Jeff Laytons' umount
specific path resolution for umount. I've found this is also broken on
recent RHEL-6 kernels and that change is present in them too so the
evidence is leaning toward that being the problem. Just how could happen
with this change I have no clue so far, it just doesn't make sense.
Anyway that's going to make testing these patches impossible until I can
work out what the problem is and fix it.
Very sorry to hold you up on this but it can't be avoided.
>
> thanks,
> NeilBrown
>
>
> From: NeilBrown Date: Tue, 8 Jul 2014 17:14:53 +1000
> Subject: [PATCH] autofs4: factor should_expire() out of
> autofs4_expire_indirect.
>
> Future patch will potentially call this twice, so make it
> separate.
>
> Signed-off-by: NeilBrown
>
> diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
> index 7e2f22ce6954..402ee7f1461a 100644
> --- a/fs/autofs4/expire.c
> +++ b/fs/autofs4/expire.c
> @@ -345,6 +345,89 @@ out:
> return NULL;
> }
>
> +/* Check if 'dentry' should expire, or return a nearby
> + * dentry that is suitable.
> + * If returned dentry is different from arg dentry,
> + * then a dget() reference was taken, else not.
> + */
> +static struct dentry *should_expire(struct dentry *dentry,
> + struct vfsmount *mnt,
> + unsigned long timeout,
> + int how)
> +{
> + int do_now = how & AUTOFS_EXP_IMMEDIATE;
> + int exp_leaves = how & AUTOFS_EXP_LEAVES;
> + struct autofs_info *ino = autofs4_dentry_ino(dentry);
> + unsigned int ino_count;
> +
> + /* No point expiring a pending mount */
> + if (ino->flags & AUTOFS_INF_PENDING)
> + return NULL;
> +
> + /*
> + * Case 1: (i) indirect mount or top level pseudo direct mount
> + * (autofs-4.1).
> + * (ii) indirect mount with offset mount, check the "/"
> + * offset (autofs-5.0+).
> + */
> + if (d_mountpoint(dentry)) {
> + DPRINTK("checking mountpoint %p %.*s",
> + dentry, (int)dentry->d_name.len, dentry->d_name.name);
> +
> + /* Can we umount this guy */
> + if (autofs4_mount_busy(mnt, dentry))
> + return NULL;
> +
> + /* Can we expire this guy */
> + if (autofs4_can_expire(dentry, timeout, do_now))
> + return dentry;
> + return NULL;
> + }
> +
> + if (dentry->d_inode && S_ISLNK(dentry->d_inode->i_mode)) {
> + DPRINTK("checking symlink %p %.*s",
> + dentry, (int)dentry->d_name.len, dentry->d_name.name);
> + /*
> + * A symlink can't be "busy" in the usual sense so
> + * just check last used for expire timeout.
> + */
> + if (autofs4_can_expire(dentry, timeout, do_now))
> + return dentry;
> + return NULL;
> + }
> +
> + if (simple_empty(dentry))
> + return NULL;
> +
> + /* Case 2: tree mount, expire iff entire tree is not busy */
> + if (!exp_leaves) {
> + /* Path walk currently on this dentry? */
> + ino_count = atomic_read(>count) + 1;
> + if (d_count(dentry) > ino_count)
> + return NULL;
> +
> + if (!autofs4_tree_busy(mnt, dentry, timeout, do_now))
> + return dentry;
> + /*
> + * Case 3: pseudo direct mount, expire individual leaves
> + * (autofs-4.1).
> + */
> + } else {
> + /* Path walk currently on this dentry? */
> + struct dentry *expired;
> + ino_count = atomic_read(>count) + 1;
> + if (d_count(dentry) > ino_count)
> + return NULL;
> +
> + expired =
[PATCH 2/5] alpha: Checkpatch warnings on lines 71 and 72
In bootp.c I am hitting lots of warnings this fixes two on lines 71,72
in order to pass checkpatch and follow kernel coding style.
---
arch/alpha/boot/bootp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/boot/bootp.c b/arch/alpha/boot/bootp.c
index 8eb821e..3ee529d 100644
--- a/arch/alpha/boot/bootp.c
+++ b/arch/alpha/boot/bootp.c
@@ -68,8 +68,8 @@ void
pal_init(void)
{
unsigned long i, rev;
- struct percpu_struct * percpu;
- struct pcb_struct * pcb_pa;
+ struct percpu_struct *percpu;
+ struct pcb_struct *pcb_pa;
/* Create the dummy PCB. */
pcb_va->ksp = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] alpha: Remove whitespace issues and turn spaces into tabs
This patch removes all the whitespace an tab issues that this file
has when running checkpatch
---
arch/alpha/boot/bootp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/alpha/boot/bootp.c b/arch/alpha/boot/bootp.c
index 3ee529d..6227e4f 100644
--- a/arch/alpha/boot/bootp.c
+++ b/arch/alpha/boot/bootp.c
@@ -48,7 +48,7 @@ find_pa(unsigned long *vptb, void *ptr)
result <<= 13;
result |= address & 0x1fff;
return (void *) result;
-}
+}
/*
* This function moves into OSF/1 pal-code, and has a temporary
@@ -152,7 +152,7 @@ start_kernel(void)
srm_printk("Linux/AXP bootp loader for Linux " UTS_RELEASE "\n");
if (INIT_HWRPB->pagesize != 8192) {
srm_printk("Expected 8kB pages, got %ldkB\n",
- INIT_HWRPB->pagesize >> 10);
+ INIT_HWRPB->pagesize >> 10);
return;
}
if (INIT_HWRPB->vptb != (unsigned long) VPTB) {
@@ -162,7 +162,7 @@ start_kernel(void)
}
pal_init();
- /* The initrd must be page-aligned. See below for the
+ /* The initrd must be page-aligned. See below for the
cause of the magic number 5. */
initrd_start = ((START_ADDR + 5*KERNEL_SIZE + PAGE_SIZE) |
(PAGE_SIZE-1)) + 1;
@@ -200,8 +200,8 @@ start_kernel(void)
#ifdef INITRD_IMAGE_SIZE
load(initrd_start, KERNEL_ORIGIN+KERNEL_SIZE, INITRD_IMAGE_SIZE);
#endif
-load(START_ADDR+(4*KERNEL_SIZE), KERNEL_ORIGIN, KERNEL_SIZE);
-load(START_ADDR, START_ADDR+(4*KERNEL_SIZE), KERNEL_SIZE);
+ load(START_ADDR+(4*KERNEL_SIZE), KERNEL_ORIGIN, KERNEL_SIZE);
+ load(START_ADDR, START_ADDR+(4*KERNEL_SIZE), KERNEL_SIZE);
memset((char*)ZERO_PGE, 0, PAGE_SIZE);
strcpy((char*)ZERO_PGE, envval);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] alpha: checkpatch gives errors and warnings in bootp.c
When running checkpatch on this file I get lots of warnings and even a few errors. This patch cleans up the coding style warning I get on line 26. --- arch/alpha/boot/bootp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/alpha/boot/bootp.c b/arch/alpha/boot/bootp.c index 2a542a5..8eb821e 100644 --- a/arch/alpha/boot/bootp.c +++ b/arch/alpha/boot/bootp.c @@ -23,7 +23,7 @@ #include "ksize.h" extern unsigned long switch_to_osf_pal(unsigned long nr, - struct pcb_struct * pcb_va, struct pcb_struct * pcb_pa, + struct pcb_struct *pcb_va, struct pcb_struct *pcb_pa, unsigned long *vptb); extern void move_stack(unsigned long new_stack); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] alpha: Cleanpatch Remove Errors
This patch removes errors on lines 205,206 to fit kernel coding style. --- arch/alpha/boot/bootp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/alpha/boot/bootp.c b/arch/alpha/boot/bootp.c index 47e33cb..ac0351d 100644 --- a/arch/alpha/boot/bootp.c +++ b/arch/alpha/boot/bootp.c @@ -202,8 +202,8 @@ start_kernel(void) load(START_ADDR+(4*KERNEL_SIZE), KERNEL_ORIGIN, KERNEL_SIZE); load(START_ADDR, START_ADDR+(4*KERNEL_SIZE), KERNEL_SIZE); - memset((char*)ZERO_PGE, 0, PAGE_SIZE); - strcpy((char*)ZERO_PGE, envval); + memset((char *)ZERO_PGE, 0, PAGE_SIZE); + strcpy((char *)ZERO_PGE, envval); #ifdef INITRD_IMAGE_SIZE ((long *)(ZERO_PGE+256))[0] = initrd_start; ((long *)(ZERO_PGE+256))[1] = INITRD_IMAGE_SIZE; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCH] ASoC: cs42xx8: Add SND_SOC_DAIFMT_DSP_A support
Hi all Sorry, add more maintainers. Best regards Wang shengjiu -Original Message- From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel-boun...@alsa-project.org] On Behalf Of Shengjiu Wang Sent: Monday, July 14, 2014 6:40 PM To: broo...@linaro.org Cc: alsa-de...@alsa-project.org Subject: [alsa-devel] [PATCH] ASoC: cs42xx8: Add SND_SOC_DAIFMT_DSP_A support According to the spec, the definition of TDM and ONELINE_24 for CS42XX8_INTF_DAC and CS42XX8_INTF_ADC is wrong. correct them and enable SND_SOC_DAIFMT_DSP_A support. Signed-off-by: Shengjiu Wang --- sound/soc/codecs/cs42xx8.c | 3 +++ sound/soc/codecs/cs42xx8.h | 8 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/cs42xx8.c b/sound/soc/codecs/cs42xx8.c index ec53ffc..02b1520 100644 --- a/sound/soc/codecs/cs42xx8.c +++ b/sound/soc/codecs/cs42xx8.c @@ -219,6 +219,9 @@ static int cs42xx8_set_dai_fmt(struct snd_soc_dai *codec_dai, case SND_SOC_DAIFMT_RIGHT_J: val = CS42XX8_INTF_DAC_DIF_RIGHTJ | CS42XX8_INTF_ADC_DIF_RIGHTJ; break; + case SND_SOC_DAIFMT_DSP_A: + val = CS42XX8_INTF_DAC_DIF_TDM | CS42XX8_INTF_ADC_DIF_TDM; + break; default: dev_err(codec->dev, "unsupported dai format\n"); return -EINVAL; diff --git a/sound/soc/codecs/cs42xx8.h b/sound/soc/codecs/cs42xx8.h index da0b94a..b2c10e5 100644 --- a/sound/soc/codecs/cs42xx8.h +++ b/sound/soc/codecs/cs42xx8.h @@ -128,8 +128,8 @@ int cs42xx8_probe(struct device *dev, struct regmap *regmap); #define CS42XX8_INTF_DAC_DIF_RIGHTJ(2 << CS42XX8_INTF_DAC_DIF_SHIFT) #define CS42XX8_INTF_DAC_DIF_RIGHTJ_16 (3 << CS42XX8_INTF_DAC_DIF_SHIFT) #define CS42XX8_INTF_DAC_DIF_ONELINE_20(4 << CS42XX8_INTF_DAC_DIF_SHIFT) -#define CS42XX8_INTF_DAC_DIF_ONELINE_24(6 << CS42XX8_INTF_DAC_DIF_SHIFT) -#define CS42XX8_INTF_DAC_DIF_TDM (7 << CS42XX8_INTF_DAC_DIF_SHIFT) +#define CS42XX8_INTF_DAC_DIF_ONELINE_24(5 << CS42XX8_INTF_DAC_DIF_SHIFT) +#define CS42XX8_INTF_DAC_DIF_TDM (6 << CS42XX8_INTF_DAC_DIF_SHIFT) #define CS42XX8_INTF_ADC_DIF_SHIFT 0 #define CS42XX8_INTF_ADC_DIF_WIDTH 3 #define CS42XX8_INTF_ADC_DIF_MASK (((1 << CS42XX8_INTF_ADC_DIF_WIDTH) - 1) << CS42XX8_INTF_ADC_DIF_SHIFT) @@ -138,8 +138,8 @@ int cs42xx8_probe(struct device *dev, struct regmap *regmap); #define CS42XX8_INTF_ADC_DIF_RIGHTJ(2 << CS42XX8_INTF_ADC_DIF_SHIFT) #define CS42XX8_INTF_ADC_DIF_RIGHTJ_16 (3 << CS42XX8_INTF_ADC_DIF_SHIFT) #define CS42XX8_INTF_ADC_DIF_ONELINE_20(4 << CS42XX8_INTF_ADC_DIF_SHIFT) -#define CS42XX8_INTF_ADC_DIF_ONELINE_24(6 << CS42XX8_INTF_ADC_DIF_SHIFT) -#define CS42XX8_INTF_ADC_DIF_TDM (7 << CS42XX8_INTF_ADC_DIF_SHIFT) +#define CS42XX8_INTF_ADC_DIF_ONELINE_24(5 << CS42XX8_INTF_ADC_DIF_SHIFT) +#define CS42XX8_INTF_ADC_DIF_TDM (6 << CS42XX8_INTF_ADC_DIF_SHIFT) /* ADC Control & DAC De-Emphasis (Address 05h) */ #define CS42XX8_ADCCTL_ADC_HPF_FREEZE_SHIFT7 -- 1.8.0 ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-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 4/5] alpha: Fix if statment in bootp.c
This patch fixes the if statement on line 180 to be changed to having
no brackets as defined by kernel coding style for one line if statements.
---
arch/alpha/boot/bootp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/alpha/boot/bootp.c b/arch/alpha/boot/bootp.c
index 6227e4f..47e33cb 100644
--- a/arch/alpha/boot/bootp.c
+++ b/arch/alpha/boot/bootp.c
@@ -177,9 +177,8 @@ start_kernel(void)
move_stack(initrd_start - PAGE_SIZE);
nbytes = callback_getenv(ENV_BOOTED_OSFLAGS, envval, sizeof(envval));
- if (nbytes < 0 || nbytes >= sizeof(envval)) {
+ if (nbytes < 0 || nbytes >= sizeof(envval))
nbytes = 0;
- }
envval[nbytes] = '\0';
srm_printk("Loading the kernel...'%s'\n", envval);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: android: Clean up else statement from sync_fence_poll()
Kernel coding style. Remove useless else statement after return. Signed-off-by: Lucas Tanure --- drivers/staging/android/sync.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index c9a0c2c..e7b2e02 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -555,8 +555,7 @@ static unsigned int sync_fence_poll(struct file *file, poll_table *wait) return POLLIN; else if (status < 0) return POLLERR; - else - return 0; + return 0; } static long sync_fence_ioctl_wait(struct sync_fence *fence, unsigned long arg) -- 2.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the v4l-dvb tree
Hi Mauro,
After merging the v4l-dvb tree, today's linux-next build (powerpc
ppc64_defconfig)
failed like this:
arch/powerpc/kernel/smp.c:764:2: error: initialization from incompatible
pointer type [-Werror]
{ cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
^
arch/powerpc/kernel/smp.c:764:2: error: (near initialization for
'powerpc_topology[0].sd_flags') [-Werror]
Caused by commit 6a0b50087a89 ("Merge branch 'patchwork' into
to_next"). The change to include/linux/sched.h in this merge commit
does not seem to appear in either of the parents of the merge.
Its also a change that (when suggested) was shown to cause more
problems than it was worth and dropped. I can't imagine how it ended
up in the merge commit.
I have used the v4l-dvb tree from next-20140714 for today. Please fix
this up.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: Is espfix64's double-fault thing OK on Xen?
On Mon, Jul 14, 2014 at 7:46 PM, Andy Lutomirski wrote: > On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin wrote: >> On 07/14/2014 02:35 PM, Andy Lutomirski wrote: >>> Presumably the problem is here: >>> >>> ENTRY(xen_iret) >>> pushq $0 >>> 1:jmp hypercall_iret >>> ENDPATCH(xen_iret) >>> >>> This seems rather unlikely to work on the espfix stack. >>> >>> Maybe espfix64 should be disabled when running on Xen and Xen should >>> implement its own espfix64 in the hypervisor. >> >> Perhaps the first question is: is espfix even necessary on Xen? How >> does the Xen PV IRET handle returning to a 16-bit stack segment? >> > > Test case here: > > https://gitorious.org/linux-test-utils/linux-clock-tests/source/dbfe196a0f6efedc119deb1cdbb0139dbdf609ee: > > It's sigreturn_32 and sigreturn_64. Summary: > > (sigreturn_64 always fails unless my SS patch is applied. results > below for sigreturn_64 assume the patch is applied. This is on KVM > (-cpu host) on Sandy Bridge.) > > On Xen with espfix, both OOPS intermittently. > > On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS > always fails. Native (32-bit or 64-bit, according to the binary) CS > with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I > find this somewhat odd. Native ss always passes. > > So I think that Xen makes no difference here, aside from the bug. > > That being said, I don't know whether Linux can do espfix64 at all > when Xen is running -- for all I know, the IRET hypercall switches > stacks to a Xen stack. Microcode is weird. Without espfix: [RUN]64-bit CS (33), 32-bit SS (2b) SP: 8badf00d5aadc0de -> 8badf00d5aadc0de [OK]all registers okay [RUN]32-bit CS (23), 32-bit SS (2b) SP: 8badf00d5aadc0de -> 5aadc0de [OK]all registers okay [RUN]16-bit CS (7), 32-bit SS (2b) SP: 8badf00d5aadc0de -> 5aadc0de [OK]all registers okay [RUN]64-bit CS (33), 16-bit SS (f) SP: 8badf00d5aadc0de -> 8badf00d5aadc0de [OK]all registers okay [RUN]32-bit CS (23), 16-bit SS (f) SP: 8badf00d5aadc0de -> 5ae3c0de [FAIL]Reg 15 mismatch: requested 0x8badf00d5aadc0de; got 0x5ae3c0de [RUN]16-bit CS (7), 16-bit SS (f) SP: 8badf00d5aadc0de -> 5ae3c0de [FAIL]Reg 15 mismatch: requested 0x8badf00d5aadc0de; got 0x5ae3c0de --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Wed, 2014-07-02 at 07:00 +, Masami Hiramatsu wrote: > On ia64 and ppc64, the function pointer does not point the > entry address of the function, but the address of function > discriptor (which contains the entry address and misc > data.) Since the kprobes passes the function pointer stored > by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for > initalizing its blacklist, it fails and reports many errors > as below. > > Failed to find blacklist 000101316830 > Failed to find blacklist 0001013000f0a000 > Failed to find blacklist 000101315f70a000 > Failed to find blacklist 000101324c80a000 > Failed to find blacklist 0001013063f0a000 > Failed to find blacklist 000101327800a000 > Failed to find blacklist 0001013277f0a000 > Failed to find blacklist 000101315a70a000 > Failed to find blacklist 0001013277e0a000 > Failed to find blacklist 000101305a20a000 > Failed to find blacklist 0001013277d0a000 > Failed to find blacklist 00010130bdc0a000 > Failed to find blacklist 00010130dc20a000 > Failed to find blacklist 000101309a00a000 > Failed to find blacklist 0001013277c0a000 > Failed to find blacklist 0001013277b0a000 > Failed to find blacklist 0001013277a0a000 > Failed to find blacklist 000101327790a000 > Failed to find blacklist 000101303140a000 > Failed to find blacklist 0001013a3280a000 > > To fix this bug, this introduces function_entry() macro to > retrieve the entry address from the given function pointer, > and uses for kallsyms_lookup_size_offset() while initializing > blacklist. > > Changes in v5: > - Use arch_deref_entry_point() instead of function_entry(). > > Changes in v4: > - Add kernel_text_address() check for verifying the address. > - Moved on the latest linus tree. > > Changes in v3: > - Fix a bug to get blacklist address based on function entry >instead of function descriptor. (Suzuki's work, Thanks!) > > Changes in V2: > - Use function_entry() macro when lookin up symbols instead >of storing it. > - Update for the latest -next. > > Signed-off-by: Masami Hiramatsu > Reported-by: Tony Luck > Tested-by: Tony Luck > Cc: Michael Ellerman Tested-by: Michael Ellerman Acked-by: Michael Ellerman (for powerpc) Ben, can you take this in your tree? 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/
[PATCH 93/93] Staging: comedi: adl_pci9118: fixed style issues
From: Sam Asadi several style issues fixed. Signed-off-by: Sam Asadi modified: drivers/staging/comedi/drivers/adl_pci9118.c --- drivers/staging/comedi/drivers/adl_pci9118.c | 124 +- 1 file changed, 62 insertions(+), 62 deletions(-) diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c b/drivers/staging/comedi/drivers/adl_pci9118.c index 59a65cb..7139f87 100644 --- a/drivers/staging/comedi/drivers/adl_pci9118.c +++ b/drivers/staging/comedi/drivers/adl_pci9118.c @@ -8,59 +8,63 @@ * Author: Michal Dobes * */ -/* -Driver: adl_pci9118 -Description: Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR -Author: Michal Dobes -Devices: [ADLink] PCI-9118DG (pci9118dg), PCI-9118HG (pci9118hg), - PCI-9118HR (pci9118hr) -Status: works - -This driver supports AI, AO, DI and DO subdevices. -AI subdevice supports cmd and insn interface, -other subdevices support only insn interface. -For AI: -- If cmd->scan_begin_src=TRIG_EXT then trigger input is TGIN (pin 46). -- If cmd->convert_src=TRIG_EXT then trigger input is EXTTRG (pin 44). -- If cmd->start_src/stop_src=TRIG_EXT then trigger input is TGIN (pin 46). -- It is not necessary to have cmd.scan_end_arg=cmd.chanlist_len but - cmd.scan_end_arg modulo cmd.chanlist_len must by 0. -- If return value of cmdtest is 5 then you've bad channel list - (it isn't possible mixture S.E. and DIFF inputs or bipolar and unipolar - ranges). - -There are some hardware limitations: -a) You cann't use mixture of unipolar/bipoar ranges or differencial/single - ended inputs. -b) DMA transfers must have the length aligned to two samples (32 bit), - so there is some problems if cmd->chanlist_len is odd. This driver tries - bypass this with adding one sample to the end of the every scan and discard - it on output but this cann't be used if cmd->scan_begin_src=TRIG_FOLLOW - and is used flag TRIG_WAKE_EOS, then driver switch to interrupt driven mode - with interrupt after every sample. -c) If isn't used DMA then you can use only mode where - cmd->scan_begin_src=TRIG_FOLLOW. - -Configuration options: - [0] - PCI bus of device (optional) - [1] - PCI slot of device (optional) - If bus/slot is not specified, then first available PCI - card will be used. - [2] - 0= standard 8 DIFF/16 SE channels configuration - n = external multiplexer connected, 1 <= n <= 256 - [3] - 0=autoselect DMA or EOC interrupts operation - 1 = disable DMA mode - 3 = disable DMA and INT, only insn interface will work - [4] - sample signal - card can generate signal for external S board - 0 = use SSHO(pin 45) signal is generated in onboard hardware S logic - 0 != use ADCHN7(pin 23) signal is generated from driver, number say how - long delay is requested in ns and sign polarity of the hold - (in this case external multiplexor can serve only 128 channels) - [5] - 0=stop measure on all hardware errors - 2 | = ignore ADOR - A/D Overrun status - 8|=ignore Bover - A/D Burst Mode Overrun status - 256|=ignore nFull - A/D FIFO Full status +/* + Driver: adl_pci9118 + Description: Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR + Author: Michal Dobes + Devices: [ADLink] PCI-9118DG (pci9118dg), PCI-9118HG (pci9118hg), + PCI-9118HR (pci9118hr) + Status: works + + This driver supports AI, AO, DI and DO subdevices. + AI subdevice supports cmd and insn interface, + other subdevices support only insn interface. + For AI: + - If cmd->scan_begin_src=TRIG_EXT then trigger input is TGIN (pin 46). + - If cmd->convert_src=TRIG_EXT then trigger input is EXTTRG (pin 44). + - If cmd->start_src/stop_src=TRIG_EXT then trigger input is TGIN (pin 46). + - It is not necessary to have cmd.scan_end_arg=cmd.chanlist_len but + cmd.scan_end_arg modulo cmd.chanlist_len must by 0. + - If return value of cmdtest is 5 then you've bad channel list + (it isn't possible mixture S.E. and DIFF inputs or bipolar and unipolar + ranges). + + There are some hardware limitations: + a) You cann't use mixture of unipolar/bipoar ranges or differencial/single + ended inputs. + b) DMA transfers must have the length aligned to two samples (32 bit), + so there is some problems if cmd->chanlist_len is odd. This driver + tries bypass this with adding one sample to the end of the every scan + and discard it on output but this cann't be used if + cmd->scan_begin_src=TRIG_FOLLOW and is used flag TRIG_WAKE_EOS, then + driver switch to interrupt driven mode with interrupt after every + sample. + c) If isn't used DMA then you can use only mode where + cmd->scan_begin_src=TRIG_FOLLOW. + + Configuration options: + [0] - PCI bus of device (optional) + [1] - PCI slot of device (optional) +If bus/slot is not specified, then first available PCI +card will be used. +
[PATCH V6 1/2] perf ignore LBR and extra_rsp
From: Kan Liang
x86, perf: Protect LBR and extra_regs against KVM lying
With -cpu host, KVM reports LBR and extra_regs support, if the host has
support.
When the guest perf driver tries to access LBR or extra_regs MSR,
it #GPs all MSR accesses,since KVM doesn't handle LBR and extra_regs support.
So check the related MSRs access right once at initialization time to avoid
the error access at runtime.
For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y
(for host kernel).
And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel).
Start the guest with -cpu host.
Run perf record with --branch-any or --branch-filter in guest to trigger LBR
Run perf stat offcore events (E.g. LLC-loads/LLC-load-misses ...) in guest to
trigger offcore_rsp #GP
Signed-off-by: Kan Liang
---
V2: Move the check code to initialization time.
V3: Add flag for each extra register.
Check all LBR MSRs at initialization time.
V4: Remove lbr_msr_access.
For LBR msr, simply set lbr_nr to 0 if check_msr failed.
Disable all extra msrs in creation places if check_msr failed.
V5: Fix check_msr broken
Don't check any more MSRs after the first fail
Return error when checking fail to stop creating the event
Remove the checking code path which never get
V6: Move extra_msr_access to struct extra_reg
Modify and move check_msr function to perf_event_intel.c
Other minor code changes
arch/x86/kernel/cpu/perf_event.c | 3 ++
arch/x86/kernel/cpu/perf_event.h | 20
arch/x86/kernel/cpu/perf_event_intel.c| 66 ++-
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 4 +-
4 files changed, 81 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 2bdfbff..2879ecd 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -118,6 +118,9 @@ static int x86_pmu_extra_regs(u64 config, struct perf_event
*event)
continue;
if (event->attr.config1 & ~er->valid_mask)
return -EINVAL;
+ /* Check if the extra msrs can be safely accessed*/
+ if (!er->extra_msr_access)
+ return -ENXIO;
reg->idx = er->idx;
reg->config = event->attr.config1;
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 3b2f9bd..2e613b2 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -295,22 +295,24 @@ struct extra_reg {
u64 config_mask;
u64 valid_mask;
int idx; /* per_xxx->regs[] reg index */
+ boolextra_msr_access;
};
-#define EVENT_EXTRA_REG(e, ms, m, vm, i) { \
- .event = (e), \
- .msr = (ms),\
- .config_mask = (m), \
- .valid_mask = (vm), \
- .idx = EXTRA_REG_##i, \
+#define EVENT_EXTRA_REG(e, ms, m, vm, i, a) { \
+ .event = (e), \
+ .msr = (ms),\
+ .config_mask = (m), \
+ .valid_mask = (vm), \
+ .idx = EXTRA_REG_##i, \
+ .extra_msr_access = (a),\
}
#define INTEL_EVENT_EXTRA_REG(event, msr, vm, idx) \
- EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT, vm, idx)
+ EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT, vm, idx, true)
#define INTEL_UEVENT_EXTRA_REG(event, msr, vm, idx) \
EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT | \
- ARCH_PERFMON_EVENTSEL_UMASK, vm, idx)
+ ARCH_PERFMON_EVENTSEL_UMASK, vm, idx, true)
#define INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG(c) \
INTEL_UEVENT_EXTRA_REG(c, \
@@ -318,7 +320,7 @@ struct extra_reg {
0x, \
LDLAT)
-#define EVENT_EXTRA_END EVENT_EXTRA_REG(0, 0, 0, 0, RSP_0)
+#define EVENT_EXTRA_END EVENT_EXTRA_REG(0, 0, 0, 0, RSP_0, false)
union perf_capabilities {
struct {
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index adb02aa..9c234d1 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2173,6 +2173,40 @@ static void intel_snb_check_microcode(void)
}
}
+/*
+ * Under certain circumstances, access certain MSR may cause #GP.
+ * The function tests if the input MSR can be safely accessed.
+ */
+static bool check_msr(unsigned long msr, u64 mask)
+{
+ u64 val_old, val_new, val_tmp;
+
+ /*
+* Read the current value, change it and read it back to see if it
+* matches, this is needed to detect certain hardware emulators
+* (qemu/kvm) that don't trap on the MSR access and always return 0s.
+*/
+ if
[PATCH v2 05/10] ACPI/EC: Add reference counting for query handlers.
This patch adds reference counting for query handlers in order to eliminate
kmalloc()/kfree() usage.
Signed-off-by: Lv Zheng
Tested-by: Steffen Weber
---
drivers/acpi/ec.c | 46 --
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d4c07b9..cf83872 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -105,6 +105,7 @@ struct acpi_ec_query_handler {
acpi_handle handle;
void *data;
u8 query_bit;
+ struct kref kref;
};
struct transaction {
@@ -119,6 +120,10 @@ struct transaction {
u8 flags;
};
+static struct acpi_ec_query_handler *
+acpi_ec_get_query_handler(struct acpi_ec_query_handler *handler);
+static void acpi_ec_put_query_handler(struct acpi_ec_query_handler *handler);
+
struct acpi_ec *boot_ec, *first_ec;
EXPORT_SYMBOL(first_ec);
@@ -590,6 +595,26 @@ static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *
data)
/* --
Event Management
--
*/
+static struct acpi_ec_query_handler *
+acpi_ec_get_query_handler(struct acpi_ec_query_handler *handler)
+{
+ if (handler)
+ kref_get(>kref);
+ return handler;
+}
+
+static void acpi_ec_query_handler_release(struct kref *kref)
+{
+ struct acpi_ec_query_handler *handler =
+ container_of(kref, struct acpi_ec_query_handler, kref);
+ kfree(handler);
+}
+
+static void acpi_ec_put_query_handler(struct acpi_ec_query_handler *handler)
+{
+ kref_put(>kref, acpi_ec_query_handler_release);
+}
+
int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
acpi_handle handle, acpi_ec_query_func func,
void *data)
@@ -604,6 +629,7 @@ int acpi_ec_add_query_handler(struct acpi_ec *ec, u8
query_bit,
handler->func = func;
handler->data = data;
mutex_lock(>mutex);
+ kref_init(>kref);
list_add(>node, >list);
mutex_unlock(>mutex);
return 0;
@@ -614,14 +640,17 @@ EXPORT_SYMBOL_GPL(acpi_ec_add_query_handler);
void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8 query_bit)
{
struct acpi_ec_query_handler *handler, *tmp;
+ LIST_HEAD(free_list);
mutex_lock(>mutex);
list_for_each_entry_safe(handler, tmp, >list, node) {
if (query_bit == handler->query_bit) {
- list_del(>node);
- kfree(handler);
+ list_del_init(>node);
+ list_add(>node, _list);
}
}
mutex_unlock(>mutex);
+ list_for_each_entry(handler, _list, node)
+ acpi_ec_put_query_handler(handler);
}
EXPORT_SYMBOL_GPL(acpi_ec_remove_query_handler);
@@ -637,14 +666,14 @@ static void acpi_ec_run(void *cxt)
else if (handler->handle)
acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
pr_debug("stop query execution\n");
- kfree(handler);
+ acpi_ec_put_query_handler(handler);
}
static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data)
{
u8 value = 0;
int status;
- struct acpi_ec_query_handler *handler, *copy;
+ struct acpi_ec_query_handler *handler;
status = acpi_ec_query_unlocked(ec, );
if (data)
@@ -655,15 +684,12 @@ static int acpi_ec_sync_query(struct acpi_ec *ec, u8
*data)
list_for_each_entry(handler, >list, node) {
if (value == handler->query_bit) {
/* have custom handler for this bit */
- copy = kmalloc(sizeof(*handler), GFP_KERNEL);
- if (!copy)
- return -ENOMEM;
- memcpy(copy, handler, sizeof(*copy));
+ handler = acpi_ec_get_query_handler(handler);
pr_debug("push query execution (0x%2x) on queue\n",
value);
- return acpi_os_execute((copy->func) ?
+ return acpi_os_execute((handler->func) ?
OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
- acpi_ec_run, copy);
+ acpi_ec_run, handler);
}
}
return 0;
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/10] ACPI/EC: Refine command storm prevention support.
This patch refines EC command storm prevention support.
Ideally, we should only enable storm prevention for the current command so
that the next command can try the efficient interrupt mode again.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 5049981..d4c07b9 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -76,7 +76,6 @@ enum ec_command {
enum {
EC_FLAGS_QUERY_PENDING, /* Query is pending */
- EC_FLAGS_GPE_STORM, /* GPE storm detected */
EC_FLAGS_HANDLERS_INSTALLED,/* Handlers for GPE and
* OpReg are installed */
EC_FLAGS_STARTED, /* Driver is started */
@@ -243,8 +242,14 @@ err:
* otherwise will take a not handled IRQ as a false one.
*/
if (!(status & ACPI_EC_FLAG_SCI)) {
- if (in_interrupt() && t)
- ++t->irq_count;
+ if (in_interrupt() && t) {
+ if (t->irq_count < ec_storm_threshold)
+ ++t->irq_count;
+ if (t->irq_count == ec_storm_threshold) {
+ pr_debug("+ Polling enabled +\n");
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
+ }
+ }
}
return wakeup;
}
@@ -318,23 +323,15 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec
*ec,
acpi_enable_gpe(NULL, ec->gpe);
pr_debug("* Command(%s) started *\n",
acpi_ec_cmd_string(t->command));
- if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
- pr_debug("+ Polling enabled +\n");
- acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
- }
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
- if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
+ if (t->irq_count == ec_storm_threshold) {
acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
pr_debug("+ Polling disabled +\n");
- } else if (t->irq_count > ec_storm_threshold) {
- pr_debug("+ Polling scheduled (%d GPE) +\n",
-t->irq_count);
- set_bit(EC_FLAGS_GPE_STORM, >flags);
}
pr_debug("* Command(%s) stopped *\n",
acpi_ec_cmd_string(t->command));
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/10] ACPI/EC: Refine event/query debugging messages.
This patch refines event/query debugging messages to use a unified format
as commands. Developers can clearly find different processes by checking
different log seperators. No functional changes.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 8817836..2340ac2 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -329,8 +329,10 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
pr_debug("* Command(%s) started *\n",
acpi_ec_cmd_string(t->command));
start_transaction(ec);
- if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
+ if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
+ pr_debug("* Event stopped *\n");
+ }
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
@@ -660,12 +662,12 @@ static void acpi_ec_run(void *cxt)
struct acpi_ec_query_handler *handler = cxt;
if (!handler)
return;
- pr_debug("start query execution\n");
+ pr_debug("# Query(0x%02x) started #\n", handler->query_bit);
if (handler->func)
handler->func(handler->data);
else if (handler->handle)
acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
- pr_debug("stop query execution\n");
+ pr_debug("# Query(0x%02x) stopped #\n", handler->query_bit);
acpi_ec_put_query_handler(handler);
}
@@ -677,8 +679,8 @@ static int acpi_ec_notify_query_handlers(struct acpi_ec
*ec, u8 query_bit)
if (query_bit == handler->query_bit) {
/* have custom handler for this bit */
handler = acpi_ec_get_query_handler(handler);
- pr_debug("push query execution (0x%2x) on queue\n",
-query_bit);
+ pr_debug("# Query(0x%02x) scheduled #\n",
+handler->query_bit);
return acpi_os_execute((handler->func) ?
OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
acpi_ec_run, handler);
@@ -716,7 +718,7 @@ static int ec_check_sci(struct acpi_ec *ec, u8 state)
{
if (state & ACPI_EC_FLAG_SCI) {
if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, >flags)) {
- pr_debug("push gpe query to the queue\n");
+ pr_debug("* Event started *\n");
return acpi_os_execute(OSL_NOTIFY_HANDLER,
acpi_ec_gpe_query, ec);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Tue, 2014-07-15 at 11:24 +0900, Masami Hiramatsu wrote: > (2014/07/15 11:11), Michael Ellerman wrote: > > On Mon, 2014-07-14 at 10:17 -0700, Tony Luck wrote: > >> On Tue, Jul 8, 2014 at 5:07 AM, Masami Hiramatsu > >> wrote: > >>> Ping? > >>> > >>> This patch can be applied without 1/2, and will fix ia64/ppc64 problem. > >> > >> Is somebody going to push this upstream? Another week has gone by, > >> we are at -rc5, and I'm still seeing the > >> > >> Failed to find blacklist a0010133b150 > >> > >> messages on ia64. > > > > I don't see those messages on ppc64, I don't know where the original report > > that it was broken on ppc64 came from. So I'm a bit lukewarm on the patch. > > Right, on ppc64(ABIv1) it may be silently failed. Because each function > descriptor has another entry on kallsyms, original code can't detect > that. OK, that would have been good to know :) It's actually much worse than you describe. On ppc64 (ABIv1) we are successfully blacklisting the function descriptors. But that doesn't prevent you from probing the text address. So basically NOKPROBE_SYMBOL() does nothing useful for us. $ head -2 ../kprobes/blacklist 0xc0d4cff8-0xc0d4d010 notify_die 0xc0d4cf80-0xc0d4cf98 atomic_notifier_call_chain $ echo "p:atomic_notifier_call_chain .atomic_notifier_call_chain" > kprobe_events $ echo 1 > events/kprobes/enable $ ls available_events instances saved_cmdlines trace_options available_tracers kprobe_events saved_cmdlines_size trace_pipe buffer_size_kbkprobe_profile set_eventtracing_cpumask buffer_total_size_kb options snapshot tracing_max_latency current_tracerper_cpu tracetracing_on eventsprintk_formats trace_clock tracing_thresh free_buffer README trace_marker $ Dumping ftrace buffer: cpu 0x2: Vector: 400 (Instruction Access) at [c001defaf830] pc: lr: 0001 sp: c001defafab0 msr: 800140009032 current = 0xc001def57e40 paca= 0xcfe00800 softe: 0irq_happened: 0x01 pid = 1, comm = swapper/2 cpu 0x3: Vector: 400 (Instruction Access) at [c001ddbcc640] pc: lr: sp: c001ddbcc8c0 msr: 800040001032 current = 0xc001def5a100 paca= 0xcfe00c00 softe: 0irq_happened: 0x01 pid = -554326528, comm = Dead machine. With your patch: $ head -2 kprobes/blacklist 0xc00bf860-0xc00bf8b0 .notify_die 0xc00bf750-0xc00bf780 .atomic_notifier_call_chain $ echo "p:notify_die .notify_die" > tracing/kprobe_events -bash: echo: write error: Invalid argument So that is much better. 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/
[PATCH v2 09/10] ACPI/EC: Add event storm prevention support.
There are cases that BIOS doesn't provide _Qxx handler for the returned
query value, in this case, acpi_set_gpe(ACPI_GPE_DISABLE) need to be
invoked to prevent event IRQ storms.
This patch implements such storm prevention using new GPE APIs.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 50 ++
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 936424a..b98474f 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -80,6 +80,10 @@ enum {
* OpReg are installed */
EC_FLAGS_STARTED, /* Driver is started */
EC_FLAGS_STOPPED, /* Driver is stopped */
+ EC_FLAGS_COMMAND_STORM, /* GPE storms occurred to the
+* current command processing */
+ EC_FLAGS_EVENT_STORM, /* GPE storms occurred to the
+* current event processing */
};
#define ACPI_EC_COMMAND_POLL 0x01 /* Available for command byte */
@@ -158,6 +162,31 @@ static void acpi_ec_disable_gpe(struct acpi_ec *ec)
wake_up(>wait);
}
+static void acpi_ec_set_storm(struct acpi_ec *ec, u8 flag)
+{
+ if (!test_bit(flag, >flags)) {
+ if (!test_bit(EC_FLAGS_EVENT_STORM, >flags) &&
+ !test_bit(EC_FLAGS_COMMAND_STORM, >flags)) {
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
+ pr_debug("+ Polling enabled +\n");
+ }
+ set_bit(flag, >flags);
+ }
+}
+
+
+static void acpi_ec_clear_storm(struct acpi_ec *ec, u8 flag)
+{
+ if (test_bit(flag, >flags)) {
+ clear_bit(flag, >flags);
+ if (!test_bit(EC_FLAGS_EVENT_STORM, >flags) &&
+ !test_bit(EC_FLAGS_COMMAND_STORM, >flags)) {
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
+ pr_debug("+ Polling disabled +\n");
+ }
+ }
+}
+
/* --
Transaction Management
--
*/
@@ -276,10 +305,8 @@ err:
if (in_interrupt() && t) {
if (t->irq_count < ec_storm_threshold)
++t->irq_count;
- if (t->irq_count == ec_storm_threshold) {
- pr_debug("+ Polling enabled +\n");
- acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
- }
+ if (t->irq_count == ec_storm_threshold)
+ acpi_ec_set_storm(ec, EC_FLAGS_COMMAND_STORM);
}
}
return wakeup;
@@ -362,10 +389,8 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
- if (t->irq_count == ec_storm_threshold) {
- acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
- pr_debug("+ Polling disabled +\n");
- }
+ if (t->irq_count == ec_storm_threshold)
+ acpi_ec_clear_storm(ec, EC_FLAGS_COMMAND_STORM);
pr_debug("* Command(%s) stopped *\n",
acpi_ec_cmd_string(t->command));
/* Disable GPE for command processing (IBF=0/OBF=1) */
@@ -563,6 +588,8 @@ static void acpi_ec_stop(struct acpi_ec *ec)
spin_unlock_irqrestore(>lock, flags);
wait_event(ec->wait, acpi_ec_stopped(ec));
spin_lock_irqsave(>lock, flags);
+ /* Event storm may still be indicated */
+ acpi_ec_clear_storm(ec, EC_FLAGS_EVENT_STORM);
/* Disable GPE for event processing (EVT_SCI=1) */
acpi_ec_disable_gpe(ec);
clear_bit(EC_FLAGS_STARTED, >flags);
@@ -714,10 +741,14 @@ static void acpi_ec_run(void *cxt)
static int acpi_ec_notify_query_handlers(struct acpi_ec *ec, u8 query_bit)
{
+ unsigned long flags;
struct acpi_ec_query_handler *handler;
list_for_each_entry(handler, >list, node) {
if (query_bit == handler->query_bit) {
+ spin_lock_irqsave(>lock, flags);
+ acpi_ec_clear_storm(ec, EC_FLAGS_EVENT_STORM);
+ spin_unlock_irqrestore(>lock, flags);
/* have custom handler for this bit */
handler = acpi_ec_get_query_handler(handler);
pr_debug("# Query(0x%02x) scheduled #\n",
@@ -728,6 +759,9 @@ static int acpi_ec_notify_query_handlers(struct acpi_ec
*ec, u8 query_bit)
}
}
pr_warn_once("BIOS bug: no handler
[PATCH v2 06/10] ACPI/EC: Add a warning message to indicate event storms.
This patch splits query handler scheduling into a new seperate function
acpi_ec_notify_query_handlers() and adds a warning message in it to
indicate a BIOS bug. It is reported that EC event storm can happen in case
there is no handler prepared for the event. No functional changes.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78091
Reported-by: Steffen Weber
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index cf83872..8817836 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -669,32 +669,39 @@ static void acpi_ec_run(void *cxt)
acpi_ec_put_query_handler(handler);
}
-static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data)
+static int acpi_ec_notify_query_handlers(struct acpi_ec *ec, u8 query_bit)
{
- u8 value = 0;
- int status;
struct acpi_ec_query_handler *handler;
- status = acpi_ec_query_unlocked(ec, );
- if (data)
- *data = value;
- if (status)
- return status;
-
list_for_each_entry(handler, >list, node) {
- if (value == handler->query_bit) {
+ if (query_bit == handler->query_bit) {
/* have custom handler for this bit */
handler = acpi_ec_get_query_handler(handler);
pr_debug("push query execution (0x%2x) on queue\n",
- value);
+query_bit);
return acpi_os_execute((handler->func) ?
OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
acpi_ec_run, handler);
}
}
+ pr_warn_once("BIOS bug: no handler for query (0x%02x)\n", query_bit);
return 0;
}
+static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data)
+{
+ u8 value = 0;
+ int status;
+
+ status = acpi_ec_query_unlocked(ec, );
+ if (data)
+ *data = value;
+ if (status)
+ return status;
+
+ return acpi_ec_notify_query_handlers(ec, value);
+}
+
static void acpi_ec_gpe_query(void *ec_cxt)
{
struct acpi_ec *ec = ec_cxt;
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 92/93] Staging: comedi: 8255: fixed by adding an empthy line
From: Sam Asadi fixed a coding style issue. Signed-off-by: Sam Asadi modified: drivers/staging/comedi/drivers/8255.c --- drivers/staging/comedi/drivers/8255.c | 150 - 1 file changed, 74 insertions(+), 76 deletions(-) diff --git a/drivers/staging/comedi/drivers/8255.c b/drivers/staging/comedi/drivers/8255.c index 46113a3..de273c7 100644 --- a/drivers/staging/comedi/drivers/8255.c +++ b/drivers/staging/comedi/drivers/8255.c @@ -1,77 +1,73 @@ /* -comedi/drivers/8255.c -Driver for 8255 - -COMEDI - Linux Control and Measurement Device Interface -Copyright (C) 1998 David A. Schleef - -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. + comedi/drivers/8255.c + Driver for 8255 + + COMEDI - Linux Control and Measurement Device Interface + Copyright (C) 1998 David A. Schleef + + 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. + + Driver: 8255 + Description: generic 8255 support + Devices: [standard] 8255 (8255) + Author: ds + Status: works + Updated: Fri, 7 Jun 2002 12:56:45 -0700 + + The classic in digital I/O. The 8255 appears in Comedi as a single + digital I/O subdevice with 24 channels. The channel 0 corresponds + to the 8255's port A, bit 0; channel 23 corresponds to port C, bit + 7. Direction configuration is done in blocks, with channels 0-7, + 8-15, 16-19, and 20-23 making up the 4 blocks. The only 8255 mode + supported is mode 0. + + You should enable compilation this driver if you plan to use a board + that has an 8255 chip. For multifunction boards, the main driver will + configure the 8255 subdevice automatically. + + This driver also works independently with ISA and PCI cards that + directly map the 8255 registers to I/O ports, including cards with + multiple 8255 chips. To configure the driver for such a card, the + option list should be a list of the I/O port bases for each of the + 8255 chips. For example, + + comedi_config /dev/comedi0 8255 0x200,0x204,0x208,0x20c + + Note that most PCI 8255 boards do NOT work with this driver, and + need a separate driver as a wrapper. For those that do work, the + I/O port base address can be found in the output of 'lspci -v'. + + This file contains an exported subdevice for driving an 8255. + + To use this subdevice as part of another driver, you need to + set up the subdevice in the attach function of the driver by + calling: + + subdev_8255_init(device, subdevice, io_function, iobase) + + device and subdevice are pointers to the device and subdevice + structures. io_function will be called to provide the + low-level input/output to the device, i.e., actual register + access. io_function will be called with the value of iobase + as the last parameter. If the 8255 device is mapped as 4 + consecutive I/O ports, you can use NULL for io_function + and the I/O port base for iobase, and an internal function will + handle the register access. + + In addition, if the main driver handles interrupts, you can + enable commands on the subdevice by calling subdev_8255_init_irq() + instead. Then, when you get an interrupt that is likely to be + from the 8255, you should call subdev_8255_interrupt(), which + will copy the latched value to a Comedi buffer. */ -/* -Driver: 8255 -Description: generic 8255 support -Devices: [standard] 8255 (8255) -Author: ds -Status: works -Updated: Fri, 7 Jun 2002 12:56:45 -0700 - -The classic in digital I/O. The 8255 appears in Comedi as a single -digital I/O subdevice with 24 channels. The channel 0 corresponds -to the 8255's port A, bit 0; channel 23 corresponds to port C, bit -7. Direction configuration is done in blocks, with channels 0-7, -8-15, 16-19, and 20-23 making up the 4 blocks. The only 8255 mode -supported is mode 0. - -You should
[PATCH v2 10/10] ACPI/EC: Add unit test support for EC driver hotplug.
This patch adds facility to test future EC modification.
All EC commits should enable TEST_HOTPLUG, and try a build/boot test.
Since EC is currently a built-in module, this is the only mean for us to
test the hotplug code.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index b98474f..d3b1bd7 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -31,6 +31,7 @@
/* Uncomment next line to get verbose printout */
/* #define DEBUG */
+/* #define TEST_HOTPLUG */
#define pr_fmt(fmt) "ACPI : EC: " fmt
#include
@@ -128,6 +129,9 @@ static struct acpi_ec_query_handler *
acpi_ec_get_query_handler(struct acpi_ec_query_handler *handler);
static void acpi_ec_put_query_handler(struct acpi_ec_query_handler *handler);
+static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
+ u32 gpe_number, void *data);
+
struct acpi_ec *boot_ec, *first_ec;
EXPORT_SYMBOL(first_ec);
@@ -787,6 +791,21 @@ static void acpi_ec_gpe_query(void *ec_cxt)
mutex_lock(>mutex);
acpi_ec_sync_query(ec, NULL);
mutex_unlock(>mutex);
+
+#ifdef TEST_HOTPLUG
+
+ /* Unit testing for driver hotplugging */
+
+ pr_info("Removing EC handlers...\n");
+ acpi_ec_stop(ec);
+ acpi_remove_gpe_handler(NULL, ec->gpe,
+ _ec_gpe_handler);
+ pr_info("Installing EC handlers...\n");
+ acpi_install_gpe_handler(NULL, ec->gpe,
+ ACPI_GPE_EDGE_TRIGGERED,
+ _ec_gpe_handler, ec);
+ acpi_ec_start(ec);
+#endif
}
static int ec_check_sci(struct acpi_ec *ec, u8 state)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/10] ACPI/EC: Add command flushing support.
This patch implements command flushing support. It's better to wait all
command transactions to be completed before disabling the EC GPE when the
system is going to be suspended. By doing so, the EC hardware can be
ensured to be in the idle state when the system is resumed.
The system suspending/resuming test result is as follows:
[ 24.950829] ACPI : EC: + Stopping EC +
[ 24.950836] ACPI : EC: + EC stopped +
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 49 +++
drivers/acpi/internal.h |1 +
2 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2340ac2..936424a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -133,6 +133,32 @@ static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS
survive early DSDT scan */
static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */
/* --
+ GPE Enhancement
+ --
*/
+
+static bool acpi_ec_flushed(struct acpi_ec *ec)
+{
+ return !!(ec->reference_count == 1);
+}
+
+static void acpi_ec_enable_gpe(struct acpi_ec *ec)
+{
+ acpi_enable_gpe(NULL, ec->gpe);
+ ec->reference_count++;
+}
+
+static void acpi_ec_disable_gpe(struct acpi_ec *ec)
+{
+ bool flushed = false;
+
+ ec->reference_count--;
+ acpi_disable_gpe(NULL, ec->gpe);
+ flushed = acpi_ec_flushed(ec);
+ if (flushed)
+ wake_up(>wait);
+}
+
+/* --
Transaction Management
--
*/
@@ -325,7 +351,7 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
/* following two actions should be kept atomic */
ec->curr = t;
/* Enable GPE for command processing (IBF=0/OBF=1) */
- acpi_enable_gpe(NULL, ec->gpe);
+ acpi_ec_enable_gpe(ec);
pr_debug("* Command(%s) started *\n",
acpi_ec_cmd_string(t->command));
start_transaction(ec);
@@ -343,7 +369,7 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
pr_debug("* Command(%s) stopped *\n",
acpi_ec_cmd_string(t->command));
/* Disable GPE for command processing (IBF=0/OBF=1) */
- acpi_disable_gpe(NULL, ec->gpe);
+ acpi_ec_disable_gpe(ec);
ec->curr = NULL;
unlock:
spin_unlock_irqrestore(>lock, tmp);
@@ -508,12 +534,24 @@ static void acpi_ec_start(struct acpi_ec *ec)
if (!test_and_set_bit(EC_FLAGS_STARTED, >flags)) {
pr_debug("+ Starting EC +\n");
/* Enable GPE for event processing (EVT_SCI=1) */
- acpi_enable_gpe(NULL, ec->gpe);
+ acpi_ec_enable_gpe(ec);
pr_info("+ EC started +\n");
}
spin_unlock_irqrestore(>lock, flags);
}
+static bool acpi_ec_stopped(struct acpi_ec *ec)
+{
+ unsigned long flags;
+ bool flushed;
+
+ spin_lock_irqsave(>lock, flags);
+ flushed = acpi_ec_flushed(ec);
+ spin_unlock_irqrestore(>lock, flags);
+
+ return flushed;
+}
+
static void acpi_ec_stop(struct acpi_ec *ec)
{
unsigned long flags;
@@ -522,8 +560,11 @@ static void acpi_ec_stop(struct acpi_ec *ec)
if (test_bit(EC_FLAGS_STARTED, >flags) &&
!test_and_set_bit(EC_FLAGS_STOPPED, >flags)) {
pr_debug("+ Stopping EC +\n");
+ spin_unlock_irqrestore(>lock, flags);
+ wait_event(ec->wait, acpi_ec_stopped(ec));
+ spin_lock_irqsave(>lock, flags);
/* Disable GPE for event processing (EVT_SCI=1) */
- acpi_disable_gpe(NULL, ec->gpe);
+ acpi_ec_disable_gpe(ec);
clear_bit(EC_FLAGS_STARTED, >flags);
clear_bit(EC_FLAGS_STOPPED, >flags);
pr_info("+ EC stopped +\n");
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 151f3e7..2348f9c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -118,6 +118,7 @@ struct acpi_ec {
unsigned long data_addr;
unsigned long global_lock;
unsigned long flags;
+ unsigned long reference_count;
struct mutex mutex;
wait_queue_head_t wait;
struct list_head list;
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/10] ACPI/EC: Deploy the new GPE handling model.
This patch deploys the following GPE handling model:
1. acpi_enable_gpe()/acpi_disable_gpe():
This set of APIs are used for EC usage reference counting.
2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE):
This set of APIs are used for preventing GPE storm.
Note that this patch only converts current storm prevention implementations
using new APIs without correcting them.
For the EC driver, GPE is enabled for the following users:
1. Event monitoring (HW exception):
If we want to query events in interrupt mode, acpi_enable_gpe() is
invoked to allow EVT_SCI IRQs.
2. Command processing (IO request):
When we receive an upper layer command submission, acpi_enable_gpe() is
invoked to allow IBF=0,OBF=1 IRQs.
Comments are updated to reflect this model.
For the EC driver, GPE is disabled for the following storms:
1. Command errors:
If there are too many IRQs coming during a command processing period and
such IRQs are not related to the event (EVT_SCI),
acpi_set_gpe(ACPI_GPE_DISABLE) is invoked to prevent further storms
during the same command transaction. This is not implemented in a good
style. Ideally, we should only enable storm prevention for the current
command so that the next command can try the efficient interrupt mode
again. This patch doesn't change this logic, it will be done by further
patches. Such correction will be implemented by further patches.
2. Event errors:
There are cases that BIOS doesn't provide _Qxx handler for the returned
query value, in this case, acpi_set_gpe(ACPI_GPE_DISABLE) need to be
invoked to prevent event IRQ storms. This patch doesn't implement this
logic, it will be done by further patches. Such gap will be implemented
by further patches.
The acpi_set_gpe() should be invoked for an outstanding command,
which means it should be invoked inside of a pair of acpi_enable_gpe()/
acpi_disable_gpe() invocation. This patch thus also moves the storm
prevention logic into acpi_ec_transaction_unlocked().
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 323a178..5049981 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -314,16 +314,32 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec
*ec,
}
/* following two actions should be kept atomic */
ec->curr = t;
+ /* Enable GPE for command processing (IBF=0/OBF=1) */
+ acpi_enable_gpe(NULL, ec->gpe);
pr_debug("* Command(%s) started *\n",
acpi_ec_cmd_string(t->command));
+ if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
+ pr_debug("+ Polling enabled +\n");
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
+ }
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
+ if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
+ pr_debug("+ Polling disabled +\n");
+ } else if (t->irq_count > ec_storm_threshold) {
+ pr_debug("+ Polling scheduled (%d GPE) +\n",
+t->irq_count);
+ set_bit(EC_FLAGS_GPE_STORM, >flags);
+ }
pr_debug("* Command(%s) stopped *\n",
acpi_ec_cmd_string(t->command));
+ /* Disable GPE for command processing (IBF=0/OBF=1) */
+ acpi_disable_gpe(NULL, ec->gpe);
ec->curr = NULL;
unlock:
spin_unlock_irqrestore(>lock, tmp);
@@ -346,26 +362,11 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
goto unlock;
}
}
- /* disable GPE during transaction if storm is detected */
- if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
- /* It has to be disabled, so that it doesn't trigger. */
- acpi_disable_gpe(NULL, ec->gpe);
- }
status = acpi_ec_transaction_unlocked(ec, t);
/* check if we received SCI during transaction */
ec_check_sci_sync(ec, acpi_ec_read_status(ec));
- if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
- msleep(1);
- /* It is safe to enable the GPE outside of the transaction. */
- acpi_enable_gpe(NULL, ec->gpe);
- } else if (t->irq_count > ec_storm_threshold) {
- pr_info("GPE storm detected(%d GPEs), "
- "transactions will use polling mode\n",
- t->irq_count);
- set_bit(EC_FLAGS_GPE_STORM, >flags);
- }
if (ec->global_lock)
acpi_release_global_lock(glk);
unlock:
@@ -500,8 +501,12 @@ static void
[PATCH V6 2/2] kvm: ignore LBR and extra rsp
From: Kan Liang
With -cpu host KVM reports LBR and extra_regs support, so the perf driver may
accesses the LBR and extra_regs MSRs.
However, there is no LBR and extra_regs virtualization support yet. This could
causes guest to crash.
As a workaround, KVM just simply ignore the LBR and extra_regs MSRs to lie the
guest.
For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y
(for host kernel).
And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel).
Start the guest with -cpu host.
Run perf record with --branch-any or --branch-filter in guest to trigger LBR
Run perf stat offcore events (E.g. LLC-loads/LLC-load-misses ...) in guest to
trigger offcore_rsp #GP
Signed-off-by: Andi Kleen
Signed-off-by: Kan Liang
---
V3: add MSR_LBR_TOS
V4: add MSR_LBR_SELECT and MSR_PEBS_LD_LAT_THRESHOLD
V5: set_msr should return 0 to lie the guest
arch/x86/kvm/pmu.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index cbecaa9..5fd5b44 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -331,6 +331,18 @@ bool kvm_pmu_msr(struct kvm_vcpu *vcpu, u32 msr)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
ret = pmu->version > 1;
break;
+ case MSR_OFFCORE_RSP_0:
+ case MSR_OFFCORE_RSP_1:
+ case MSR_LBR_SELECT:
+ case MSR_PEBS_LD_LAT_THRESHOLD:
+ case MSR_LBR_TOS:
+ /* At most 8-deep LBR for core and atom */
+ case MSR_LBR_CORE_FROM ... MSR_LBR_CORE_FROM + 7:
+ case MSR_LBR_CORE_TO ... MSR_LBR_CORE_TO + 7:
+ /* 16-deep LBR for core i3/i5/i7 series processors */
+ case MSR_LBR_NHM_FROM ... MSR_LBR_NHM_FROM + 15:
+ case MSR_LBR_NHM_TO ... MSR_LBR_NHM_TO + 15:
+ return 1; /* to avoid crashes */
default:
ret = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)
|| get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0)
@@ -358,6 +370,19 @@ int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 index, u64
*data)
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
*data = pmu->global_ovf_ctrl;
return 0;
+ case MSR_OFFCORE_RSP_0:
+ case MSR_OFFCORE_RSP_1:
+ case MSR_LBR_SELECT:
+ case MSR_PEBS_LD_LAT_THRESHOLD:
+ case MSR_LBR_TOS:
+ /* At most 8-deep LBR for core and atom */
+ case MSR_LBR_CORE_FROM ... MSR_LBR_CORE_FROM + 7:
+ case MSR_LBR_CORE_TO ... MSR_LBR_CORE_TO + 7:
+ /* 16-deep LBR for core i3/i5/i7 series processors */
+ case MSR_LBR_NHM_FROM ... MSR_LBR_NHM_FROM + 15:
+ case MSR_LBR_NHM_TO ... MSR_LBR_NHM_TO + 15:
+ *data = 0;
+ return 0;
default:
if ((pmc = get_gp_pmc(pmu, index, MSR_IA32_PERFCTR0)) ||
(pmc = get_fixed_pmc(pmu, index))) {
@@ -409,6 +434,19 @@ int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data
*msr_info)
return 0;
}
break;
+ case MSR_OFFCORE_RSP_0:
+ case MSR_OFFCORE_RSP_1:
+ case MSR_LBR_SELECT:
+ case MSR_PEBS_LD_LAT_THRESHOLD:
+ case MSR_LBR_TOS:
+ /* At most 8-deep LBR for core and atom */
+ case MSR_LBR_CORE_FROM ... MSR_LBR_CORE_FROM + 7:
+ case MSR_LBR_CORE_TO ... MSR_LBR_CORE_TO + 7:
+ /* 16-deep LBR for core i3/i5/i7 series processors */
+ case MSR_LBR_NHM_FROM ... MSR_LBR_NHM_FROM + 15:
+ case MSR_LBR_NHM_TO ... MSR_LBR_NHM_TO + 15:
+ /* dummy for now */
+ return 0;
default:
if ((pmc = get_gp_pmc(pmu, index, MSR_IA32_PERFCTR0)) ||
(pmc = get_fixed_pmc(pmu, index))) {
--
1.8.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 v2 02/10] ACPI/EC: Add detailed command/query debugging information.
Developers really don't need to translate EC commands in mind. This patch
adds detailed debugging information for the EC commands.
The address can be found in the follow-up sequential EC_DATA(W) accesses,
thus this patch also removes some of the redundant address information.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 1a94ba9..323a178 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -165,6 +165,27 @@ static inline void acpi_ec_write_data(struct acpi_ec *ec,
u8 data)
outb(data, ec->data_addr);
}
+#ifdef DEBUG
+static const char *acpi_ec_cmd_string(u8 cmd)
+{
+ switch (cmd) {
+ case 0x80:
+ return "RD_EC";
+ case 0x81:
+ return "WR_EC";
+ case 0x82:
+ return "BE_EC";
+ case 0x83:
+ return "BD_EC";
+ case 0x84:
+ return "QR_EC";
+ }
+ return "UNKNOWN";
+}
+#else
+#define acpi_ec_cmd_string(cmd)"UNDEF"
+#endif
+
static int ec_transaction_completed(struct acpi_ec *ec)
{
unsigned long flags;
@@ -293,16 +314,16 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec
*ec,
}
/* following two actions should be kept atomic */
ec->curr = t;
- pr_debug("* transaction started (cmd=0x%02x, addr=0x%02x) *\n",
-t->command, t->wdata ? t->wdata[0] : 0);
+ pr_debug("* Command(%s) started *\n",
+acpi_ec_cmd_string(t->command));
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
- pr_debug("* transaction stopped (cmd=0x%02x, addr=0x%02x) *\n",
-t->command, t->wdata ? t->wdata[0] : 0);
+ pr_debug("* Command(%s) stopped *\n",
+acpi_ec_cmd_string(t->command));
ec->curr = NULL;
unlock:
spin_unlock_irqrestore(>lock, tmp);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/10] ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.
By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be blocked.
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 56 +++--
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index a66ab65..1a94ba9 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -79,7 +79,8 @@ enum {
EC_FLAGS_GPE_STORM, /* GPE storm detected */
EC_FLAGS_HANDLERS_INSTALLED,/* Handlers for GPE and
* OpReg are installed */
- EC_FLAGS_BLOCKED, /* Transactions are blocked */
+ EC_FLAGS_STARTED, /* Driver is started */
+ EC_FLAGS_STOPPED, /* Driver is stopped */
};
#define ACPI_EC_COMMAND_POLL 0x01 /* Available for command byte */
@@ -285,15 +286,25 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec
*ec,
udelay(ACPI_EC_MSI_UDELAY);
/* start transaction */
spin_lock_irqsave(>lock, tmp);
+ if (!test_bit(EC_FLAGS_STARTED, >flags) ||
+ test_bit(EC_FLAGS_STOPPED, >flags)) {
+ ret = -EINVAL;
+ goto unlock;
+ }
/* following two actions should be kept atomic */
ec->curr = t;
+ pr_debug("* transaction started (cmd=0x%02x, addr=0x%02x) *\n",
+t->command, t->wdata ? t->wdata[0] : 0);
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
+ pr_debug("* transaction stopped (cmd=0x%02x, addr=0x%02x) *\n",
+t->command, t->wdata ? t->wdata[0] : 0);
ec->curr = NULL;
+unlock:
spin_unlock_irqrestore(>lock, tmp);
return ret;
}
@@ -307,10 +318,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
if (t->rdata)
memset(t->rdata, 0, t->rlen);
mutex_lock(>mutex);
- if (test_bit(EC_FLAGS_BLOCKED, >flags)) {
- status = -EINVAL;
- goto unlock;
- }
if (ec->global_lock) {
status = acpi_acquire_global_lock(ACPI_EC_UDELAY_GLK, );
if (ACPI_FAILURE(status)) {
@@ -318,8 +325,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
goto unlock;
}
}
- pr_debug("transaction start (cmd=0x%02x, addr=0x%02x)\n",
- t->command, t->wdata ? t->wdata[0] : 0);
/* disable GPE during transaction if storm is detected */
if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
/* It has to be disabled, so that it doesn't trigger. */
@@ -340,7 +345,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
t->irq_count);
set_bit(EC_FLAGS_GPE_STORM, >flags);
}
- pr_debug("transaction end\n");
if (ec->global_lock)
acpi_release_global_lock(glk);
unlock:
@@ -470,6 +474,30 @@ static void acpi_ec_clear(struct acpi_ec *ec)
pr_info("%d stale EC events cleared\n", i);
}
+static void acpi_ec_start(struct acpi_ec *ec)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ if (!test_and_set_bit(EC_FLAGS_STARTED, >flags))
+ acpi_enable_gpe(NULL, ec->gpe);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+static void acpi_ec_stop(struct acpi_ec *ec)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ if (test_bit(EC_FLAGS_STARTED, >flags) &&
+ !test_and_set_bit(EC_FLAGS_STOPPED, >flags)) {
+ acpi_disable_gpe(NULL, ec->gpe);
+ clear_bit(EC_FLAGS_STARTED, >flags);
+ clear_bit(EC_FLAGS_STOPPED, >flags);
+ }
+ spin_unlock_irqrestore(>lock, flags);
+}
+
void acpi_ec_block_transactions(void)
{
struct acpi_ec *ec = first_ec;
@@ -479,7 +507,7 @@ void acpi_ec_block_transactions(void)
mutex_lock(>mutex);
/* Prevent transactions from being carried out */
- set_bit(EC_FLAGS_BLOCKED, >flags);
+ acpi_ec_stop(ec);
mutex_unlock(>mutex);
}
@@ -492,7 +520,7 @@ void acpi_ec_unblock_transactions(void)
mutex_lock(>mutex);
/* Allow transactions to be carried out again */
- clear_bit(EC_FLAGS_BLOCKED, >flags);
+ acpi_ec_start(ec);
if (EC_FLAGS_CLEAR_ON_RESUME)
acpi_ec_clear(ec);
@@ -507,7 +535,7 @@ void acpi_ec_unblock_transactions_early(void)
* atomic context during wakeup, so we don't need to acquire the mutex).
*/
if (first_ec)
-
[PATCH v2 00/10] ACPI/EC: Add event storm prevention and cleanup command storm prevention.
This patchset is based on the previous ACPI/EC bug fixes series and the GPE API enhancement series. During the bug fix, there is a dmesg showing Linux EC driver doesn't support EC event storm prevention. https://bugzilla.kernel.org/show_bug.cgi?id=70891 The comment 55 contains the dmesg log that shows a 0x0D event storm, for which there is no _Q0D method provided by the ACPI table to handle. This becomes a GPE storm and slows down the machine a lot, it tooks longer time for Linux to boot (see comment 80). This patchset implements event storm prevention, turning EC driver into polling mode when the storm happens so that other tasks can be processed by the CPU without being affected by this GPE storm. In current EC driver, we only have command storm prevention implemented, this patch also refines the command storm prevention support. All of the above storm prevention support are implemented using the ideal GPE handling model provided by the previous GPE API enhancement series. The ideal GPE handling model should be able to handle the following cases: This patchset also contains an EC commands flushing support. This is required to implement event storm prevention. By utilizing the GPE APIs, we need to invoke acpi_set_gpe() before invoking acpi_disable_gpe() to prevent storms. Without implementing flushing, there is no such a point invoking acpi_disable_gpe() before all commands have been completed. By implementing EC commands flushing, we now achieve an additional benefit: Some EC driven ACPI devices may require all submitted EC commands to be completed before they can be safely suspended or unplugged. Otherwise the state of such devices will be broken. When implementing IO flushing, there always need to be 2 flags to indicate an intermediate state - old IO submissions observe the (STARTED) flag to continue; new IO submissions observe the (STOPPED) flag to be discarded. After introducing the 2 flags, a "stop waiter" is implemented for the suspending/removing operations of the EC driver. The refined patches are also passed the runtime/suspend tests carried out on the following platforms: "Dell Inspiron Mini 1010" - i386 kernel "Dell Latitude 6430u" - x86_64 kernel This patchset also includes a unit test facility, I used it to test the hotplug support code in the driver. It's useful for future EC development. Lv Zheng (10): ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag. ACPI/EC: Add detailed command/query debugging information. ACPI/EC: Deploy the new GPE handling model. ACPI/EC: Refine command storm prevention support. ACPI/EC: Add reference counting for query handlers. ACPI/EC: Add a warning message to indicate event storms. ACPI/EC: Refine event/query debugging messages. ACPI/EC: Add command flushing support. ACPI/EC: Add event storm prevention support. ACPI/EC: Add unit test support for EC driver hotplug. drivers/acpi/ec.c | 293 ++- drivers/acpi/internal.h |1 + 2 files changed, 239 insertions(+), 55 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 91/93] Staging: comedi: 8253.h fixed by removing 'return' from generic func
From: Sam Asadi
Signed-off-by: Sam Asadi
modified: drivers/staging/comedi/drivers/8253.h
---
drivers/staging/comedi/drivers/8253.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/8253.h
b/drivers/staging/comedi/drivers/8253.h
index 5829b46..f6b8607 100644
--- a/drivers/staging/comedi/drivers/8253.h
+++ b/drivers/staging/comedi/drivers/8253.h
@@ -55,7 +55,7 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* check for overflow */
divider > div1 && divider > div2 &&
divider * i8253_osc_base > divider &&
- divider * i8253_osc_base > i8253_osc_base) {
+ divider * i8253_osc_base > i8253_osc_base) {
return;
}
@@ -118,7 +118,6 @@ static inline void i8253_cascade_ns_to_timer(int
i8253_osc_base,
/* masking is done since counter maps zero to 0x1 */
*d1 = div1 & 0x;
*d2 = div2 & 0x;
- return;
}
#ifndef CMDTEST
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/9] ACPICA: Events: Fix an issue that status of GPEs are unexpectedly cleared.
The stale GPE indication is not a problem. Drivers should always check the
underlying hardware status and be ready to handle invalid status.
The GPE clearing implemented in acpi_ev_enable_gpe() on the contrary
introduces issues for acpi_enable_gpe() logic. When the usage count of GPE is
increased by suspend/resume code, GPE status shouldn't be cleared, or a GPE
loss could happen when the driver relies on the interrupt mode.
With previous cleanup, all acpi_ev_enable_gpe() usages are removed, this patch
also removes this internal API. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/evgpe.c | 46 +++
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index d629a21..64f6d41 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -98,48 +98,6 @@ acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info
*gpe_event_info)
/***
*
- * FUNCTION:acpi_ev_enable_gpe
- *
- * PARAMETERS: gpe_event_info - GPE to enable
- *
- * RETURN: Status
- *
- * DESCRIPTION: Clear a GPE of stale events and enable it.
- *
-
**/
-
-acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
-{
- acpi_status status;
-
- ACPI_FUNCTION_TRACE(ev_enable_gpe);
-
- /*
-* We will only allow a GPE to be enabled if it has either an associated
-* method (_Lxx/_Exx) or a handler, or is using the implicit notify
-* feature. Otherwise, the GPE will be immediately disabled by
-* acpi_ev_gpe_dispatch the first time it fires.
-*/
- if ((gpe_event_info->flags & ACPI_GPE_DISPATCH_MASK) ==
- ACPI_GPE_DISPATCH_NONE) {
- return_ACPI_STATUS(AE_NO_HANDLER);
- }
-
- /* Clear the GPE (of stale events) */
-
- status = acpi_hw_clear_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
- }
-
- /* Enable the requested GPE */
-
- status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
- return_ACPI_STATUS(status);
-}
-
-/***
- *
* FUNCTION:acpi_ev_add_gpe_reference
*
* PARAMETERS: gpe_event_info - Add a reference to this GPE
@@ -169,7 +127,9 @@ acpi_ev_add_gpe_reference(struct acpi_gpe_event_info
*gpe_event_info)
status = acpi_ev_update_gpe_enable_mask(gpe_event_info);
if (ACPI_SUCCESS(status)) {
- status = acpi_ev_enable_gpe(gpe_event_info);
+ status =
+ acpi_hw_low_set_gpe(gpe_event_info,
+ ACPI_GPE_ENABLE);
}
if (ACPI_FAILURE(status)) {
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in deferred handlers.
The acpi_os_wait_events_complete() is used for flushing the deferred executed handlers, invoking it for GPE interrupt handlers doesn't help to protect GPE handler callback. On the contrary, it prevents GPE APIs from being invoked in the deferred notify handlers. Actually, the GPE interrupt handlers' invocation is protected by the previous implemented reference counting mechanism. This patch fixes this GPE APIs invocation issue in a seperate commit other than the reference counting one, so that if any regressions are reported, this patch can be temporarily reverted before the regressions are root caused. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/evxface.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c index a538b03..fc075a5 100644 --- a/drivers/acpi/acpica/evxface.c +++ b/drivers/acpi/acpica/evxface.c @@ -919,10 +919,6 @@ acpi_remove_gpe_handler(acpi_handle gpe_device, acpi_os_release_lock(acpi_gbl_gpe_lock, flags); (void)acpi_ut_release_mutex(ACPI_MTX_EVENTS); - /* Make sure all deferred GPE tasks are completed */ - - acpi_os_wait_events_complete(); - /* Now we can free the handler object */ ACPI_FREE(handler); -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 8/9] ACPICA: Events: Add a flag to disable internal auto GPE clearing.
Clearing the status bit means OSPM acknowledges the GPE and the hardware
then can bring follow-up events up. Acklowdging it too early causes OSPM
seeing level triggered GPE storms or missing edge-triggered GPEs if the
OSPM driver responds slowly. Some drivers may choose to implement GPE
condition clearing code in a position that is different from where it
should be disabled or re-enabled, in which case, the internal auto GPE
clearing operations should be abandoned.
This flag facilitates such driver designs and implementations.
Note that drivers will need to invoke acpi_clear_gpe() manually in a proper
position where the causes and conditions of the GPE have been solved and
the GPE status can be safely cleared. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/evgpe.c |6 --
include/acpi/actypes.h | 16 +---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 64f6d41..7589956 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -633,7 +633,8 @@ acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info *
gpe_event_info)
{
acpi_status status;
- if ((gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
+ if (!(gpe_event_info->flags & ACPI_GPE_NO_AUTO_CLEAR) &&
+ (gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
ACPI_GPE_LEVEL_TRIGGERED) {
/*
* GPE is level-triggered, we clear the GPE status bit after
@@ -719,7 +720,8 @@ acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
* If edge-triggered, clear the GPE status bit now. Note that
* level-triggered events are cleared after the GPE is serviced.
*/
- if ((gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
+ if (!(gpe_event_info->flags & ACPI_GPE_NO_AUTO_CLEAR) &&
+ (gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
ACPI_GPE_EDGE_TRIGGERED) {
status = acpi_hw_clear_gpe(gpe_event_info);
if (ACPI_FAILURE(status)) {
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 608a040..18f341f 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -738,13 +738,14 @@ typedef u32 acpi_event_status;
/*
* GPE info flags - Per GPE
- * +---+-+-+---+
- * | 7:4 |3|2|1:0|
- * +---+-+-+---+
- * || | |
- * || | +-- Type of dispatch:to method, handler, notify, or none
- * || +- Interrupt type: edge or level triggered
- * |+--- Is a Wake GPE
+ * +---+-+-+-+---+
+ * | 7:5 |4|3|2|1:0|
+ * +---+-+-+-+---+
+ * || | | |
+ * || | | +-- Type of dispatch:to method, handler, notify, or none
+ * || | +- Interrupt type: edge or level triggered
+ * || +--- Is a Wake GPE
+ * |+- Do not clear GPE automatically
* +
*/
#define ACPI_GPE_DISPATCH_NONE (u8) 0x00
@@ -758,6 +759,7 @@ typedef u32 acpi_event_status;
#define ACPI_GPE_XRUPT_TYPE_MASK(u8) 0x04
#define ACPI_GPE_CAN_WAKE (u8) 0x08
+#define ACPI_GPE_NO_AUTO_CLEAR (u8) 0x10
/*
* Flags for GPE and Lock interfaces
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/9] ACPICA: Events: Fix an issue that originally_enabled check is not paired.
The originally_enabled check is not paired between acpi_install_gpe_handler()
and acpi_remove_gpe_handler(). Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/evxface.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
index fc075a5..e090dd1 100644
--- a/drivers/acpi/acpica/evxface.c
+++ b/drivers/acpi/acpica/evxface.c
@@ -794,11 +794,19 @@ acpi_install_gpe_handler(acpi_handle gpe_device,
* automatically during initialization, in which case it has to be
* disabled now to avoid spurious execution of the handler.
*/
-
- if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD)
- && gpe_event_info->runtime_count) {
- handler->originally_enabled = 1;
+ if (((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
+(handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
+ gpe_event_info->runtime_count) {
+ handler->originally_enabled = TRUE;
(void)acpi_ev_remove_gpe_reference(gpe_event_info);
+
+ /* Sanity check of original type against new type */
+
+ if (type !=
+ (u32)(gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK)) {
+ ACPI_WARNING((AE_INFO,
+ "GPE type mismatch (level/edge)"));
+ }
}
/* Install the handler */
@@ -903,7 +911,8 @@ acpi_remove_gpe_handler(acpi_handle gpe_device,
* enabled, it should be enabled at this point to restore the
* post-initialization configuration.
*/
- if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) &&
+ if (((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
+(handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
handler->originally_enabled) {
(void)acpi_ev_add_gpe_reference(gpe_event_info);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] ACPI: Update interrupt handler to honor new ACPI_REENABLE_GPE bit.
The return value of ACPICA SCI will contain ACPI_REENABLE_GPE. This patch
cleans up the OSL code to reflect this change.
Signed-off-by: Lv Zheng
---
drivers/acpi/osl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index bad25b0..b524186 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -788,7 +788,7 @@ static irqreturn_t acpi_irq(int irq, void *dev_id)
handled = (*acpi_irq_handler) (acpi_irq_context);
- if (handled) {
+ if (handled & ACPI_INTERRUPT_HANDLED) {
acpi_irq_handled++;
return IRQ_HANDLED;
} else {
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/9] ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences.
This can help to reduce source code differences between Linux and ACPICA
upstream. Further driver cleanups also require these APIs to eliminate GPE
storms.
1. acpi_set_gpe(): An API that driver should invoke in the case it wants
to disable/enable IRQ without honoring the reference
count implemented in the acpi_disable_gpe() and
acpi_enable_gpe(). Note that this API should only be
invoked inside a acpi_enable_gpe()/acpi_disable_gpe()
pair.
2. acpi_finish_gpe(): Drivers returned ACPI_REENABLE_GPE unset from the
GPE handler should use this API instead of
invoking acpi_set_gpe()/acpi_enable_gpe() to
re-enable the GPE.
The GPE APIs can be invoked inside of a GPE handler or in the task context
with a driver provided lock held. This driver provided lock is safe to be
held in the GPE handler by the driver.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/evxfgpe.c | 105 +
1 file changed, 105 insertions(+)
diff --git a/drivers/acpi/acpica/evxfgpe.c b/drivers/acpi/acpica/evxfgpe.c
index cb534fa..d66d50b 100644
--- a/drivers/acpi/acpica/evxfgpe.c
+++ b/drivers/acpi/acpica/evxfgpe.c
@@ -176,6 +176,68 @@ acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32
gpe_number)
ACPI_EXPORT_SYMBOL(acpi_disable_gpe)
+/***
+ *
+ * FUNCTION:acpi_set_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device. NULL for GPE0/GPE1
+ * gpe_number - GPE level within the GPE block
+ * action - ACPI_GPE_ENABLE or ACPI_GPE_DISABLE
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Enable or disable an individual GPE. This function bypasses
+ * the reference count mechanism used in the acpi_enable_gpe and
+ * acpi_disable_gpe interfaces -- and should be used with care.
+ *
+ * Note: Typically used to disable a runtime GPE for short period of time,
+ * then re-enable it, without disturbing the existing reference counts. This
+ * is useful, for example, in the Embedded Controller (EC) driver.
+ *
+
**/
+acpi_status acpi_set_gpe(acpi_handle gpe_device, u32 gpe_number, u8 action)
+{
+ struct acpi_gpe_event_info *gpe_event_info;
+ acpi_status status;
+ acpi_cpu_flags flags;
+
+ ACPI_FUNCTION_TRACE(acpi_set_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ /* Perform the action */
+
+ switch (action) {
+ case ACPI_GPE_ENABLE:
+
+ status = acpi_ev_enable_gpe(gpe_event_info);
+ break;
+
+ case ACPI_GPE_DISABLE:
+
+ status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE);
+ break;
+
+ default:
+
+ status = AE_BAD_PARAMETER;
+ break;
+ }
+
+unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ return_ACPI_STATUS(status);
+}
+
+ACPI_EXPORT_SYMBOL(acpi_set_gpe)
/***
*
@@ -479,6 +541,49 @@ unlock_and_exit:
ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
+/***
+ *
+ * FUNCTION:acpi_finish_gpe
+ *
+ * PARAMETERS: gpe_device - Namespace node for the GPE Block
+ *(NULL for FADT defined GPEs)
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Clear and conditionally reenable a GPE. This completes the GPE
+ * processing. Intended for use by asynchronous host-installed
+ * GPE handlers. The GPE is only reenabled if the enable_for_run
bit
+ * is set in the GPE info.
+ *
+
**/
+acpi_status acpi_finish_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ struct acpi_gpe_event_info *gpe_event_info;
+ acpi_status status;
+ acpi_cpu_flags flags;
+
+ ACPI_FUNCTION_TRACE(acpi_finish_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ status = acpi_ev_finish_gpe(gpe_event_info);
+
+unlock_and_exit:
+
[PATCH v2 5/9] ACPICA: Events: Fix an issue that acpi_set_gpe() cannot unconditionally enable GPEs.
This patch adds unconditional GPE enabling support into acpi_set_gpe().
Originally this function checks if the GPE has been enabled with handlers
and performs acknowledging before enabling it.
First, IRQ enabling/disabling has 2 use cases:
1. When upper layers (the users of the driver) submit requests to the
drivers, it means they care about the underlying hardware. For this
case, acpi_enable_gpe() should be invoked. When the reference count is
increased from 0 to 1, driver enables the hardware IRQ. And
acpi_disable_gpe() is used as the reversal when the users have completed
the submitted requests.
2. Driver may temporarily disables the IRQ and wants to re-enable it later,
this case is normally used in order to prevent IRQ storm. When a driver
cannot fully solve the condition that triggered the IRQ in the IRQ
context, in order not to trigger IRQ storm, driver has to disable IRQ
and re-enables it in the defered execution environment - which should be
in a task context. This API should be used exactly for this purpose.
Second, since the acpi_set_gpe() should be invoked from an IRQ handler, the
handler check is useless for this API.
Third, given the fact that drivers should complete all outstanding requests
before putting themselves into the sleep states, as this API is executed for
outstanding requests, it should also have nothing to do with the
"RUN"/"WAKE" distinguishing. That's why the acpi_set_gpe(ACPI_GPE_ENABLE)
should not be implemented by acpi_hw_low_set_gpe(ACPI_GPE_CONDITIONAL_ENABLE).
Fourth, GPE clearing is used to acknowledge the GPE. The combination of
acknowledging and enabling may not be expected by the hardware drivers. For
GPE clearing, we have a seperate API acpi_clear_gpe(). There are cases
drivers do want the 2 operations to be split. For example, a high IO
throughput IRQ requires the IRQ to be cleared in the IRQ context. In order
to avoid GPE storm, same driver need to invoke IRQ re-enabling in the task
context. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have acpi_finish_gpe() ready to be invoked.
This patch converts acpi_set_gpe(ACPI_GPE_ENABLE) into
acpi_hw_low_set_gpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers are encouraged to use this API when they need to handle the above
mentioned cases. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/evxfgpe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/evxfgpe.c b/drivers/acpi/acpica/evxfgpe.c
index d66d50b..6c53633 100644
--- a/drivers/acpi/acpica/evxfgpe.c
+++ b/drivers/acpi/acpica/evxfgpe.c
@@ -218,7 +218,7 @@ acpi_status acpi_set_gpe(acpi_handle gpe_device, u32
gpe_number, u8 action)
switch (action) {
case ACPI_GPE_ENABLE:
- status = acpi_ev_enable_gpe(gpe_event_info);
+ status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
break;
case ACPI_GPE_DISABLE:
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/9] ACPICA: Improve GPE handling model.
This patchset enables the ideal GPE handling model. The ideal GPE handling model should be able to handle the following cases: 1. When upper layers (the users of the driver) submit requests to the drivers, it means they care about the underlying hardware. For this case, acpi_enable_gpe() should be invoked. When the reference count is increased from 0 to 1, driver enables the hardware IRQ. And acpi_disable_gpe() is used as the reversal when the users have completed the submitted requests. 2. Driver may temporarily disables the IRQ and wants to re-enable it later, this case is normally used in order to prevent IRQ storm. When a driver cannot fully solve the condition that triggered the IRQ in the IRQ context, in order not to trigger IRQ storm, driver has to disable IRQ and re-enables it in the deferred execution environment - which should be in a task context. The acpi_set_gpe() API should be used exactly for this purpose. The reason why this model hasn't been enabled for the current Linux ACPI drivers is: In ACPICA, the same GPE lock is held while invoking the GPE handler callback, it's thus impossible to invoke GPE APIs in the GPE handler because the APIs require to hold the GPE lock. The recursive locking leads to dead locks. This is a simple design defect, callbacks should always be invoked in a lockless environment, normally in Linux, this is achieved by RCU locking, and in ACPICA, we achieve this using reference counting. After fixing the above bug and doing necessary cleanups in the ACPICA GPE handling code, we now can enable this ideal GPE handling model for the EC driver to implement "commands flushing" and "storm prevention" (the EC driver enabling is not included in this patchset). The refined patches are passed the runtime/suspend tests carried out on the following platforms with EC driver enhanced: "Dell Inspiron Mini 1010" - i386 kernel "Dell Latitude 6430u" - x86_64 kernel Lv Zheng (9): ACPICA: Events: Reduce indent divergences of events files. ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in atomic context. ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in deferred handlers. ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences. ACPICA: Events: Fix an issue that acpi_set_gpe() cannot unconditionally enable GPEs. ACPICA: Events: Fix an issue that status of GPEs are unexpectedly cleared. ACPICA: Events: Fix an issue that originally_enabled check is not paired. ACPICA: Events: Add a flag to disable internal auto GPE clearing. ACPI: Update interrupt handler to honor new ACPI_REENABLE_GPE bit. drivers/acpi/acpica/acevents.h |1 + drivers/acpi/acpica/aclocal.h |5 +- drivers/acpi/acpica/evgpe.c| 136 +--- drivers/acpi/acpica/evxface.c | 41 drivers/acpi/acpica/evxfgpe.c | 105 +++ drivers/acpi/osl.c |2 +- include/acpi/actypes.h | 16 ++--- 7 files changed, 219 insertions(+), 87 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/9] ACPICA: Events: Reduce indent divergences of events files.
This patch reduces indent divergences first in order to reduce human
intervention work for the follow-up linuxized event patches.
This patch reduces indent divergences of the event files. Though the
divergences report doesn't care about these differences, they do hurt
patches maintanence.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |4 ++--
drivers/acpi/acpica/evgpe.c | 23 ---
drivers/acpi/acpica/evxface.c |8
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 91f801a..a9fa666 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -412,8 +412,8 @@ struct acpi_gpe_handler_info {
acpi_gpe_handler address; /* Address of handler, if any */
void *context; /* Context to be passed to handler */
struct acpi_namespace_node *method_node;/* Method node for this
GPE level (saved) */
- u8 original_flags; /* Original (pre-handler) GPE info */
- u8 originally_enabled; /* True if GPE was originally enabled */
+ u8 original_flags; /* Original (pre-handler) GPE info */
+ u8 originally_enabled; /* True if GPE was originally enabled */
};
/* Notify info for implicit notify, multiple device objects */
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index e4ba4de..2095dfb 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -100,13 +100,14 @@ acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info
*gpe_event_info)
*
* FUNCTION:acpi_ev_enable_gpe
*
- * PARAMETERS: gpe_event_info - GPE to enable
+ * PARAMETERS: gpe_event_info - GPE to enable
*
* RETURN: Status
*
* DESCRIPTION: Clear a GPE of stale events and enable it.
*
**/
+
acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
{
acpi_status status;
@@ -125,6 +126,7 @@ acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info
*gpe_event_info)
}
/* Clear the GPE (of stale events) */
+
status = acpi_hw_clear_gpe(gpe_event_info);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
@@ -136,7 +138,6 @@ acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info
*gpe_event_info)
return_ACPI_STATUS(status);
}
-
/***
*
* FUNCTION:acpi_ev_add_gpe_reference
@@ -212,7 +213,7 @@ acpi_ev_remove_gpe_reference(struct acpi_gpe_event_info
*gpe_event_info)
if (ACPI_SUCCESS(status)) {
status =
acpi_hw_low_set_gpe(gpe_event_info,
-ACPI_GPE_DISABLE);
+ ACPI_GPE_DISABLE);
}
if (ACPI_FAILURE(status)) {
@@ -334,7 +335,7 @@ struct acpi_gpe_event_info
*acpi_ev_get_gpe_event_info(acpi_handle gpe_device,
*
**/
-u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * gpe_xrupt_list)
+u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *gpe_xrupt_list)
{
acpi_status status;
struct acpi_gpe_block_info *gpe_block;
@@ -427,7 +428,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *
gpe_xrupt_list)
/* Check if there is anything active at all in this
register */
- enabled_status_byte = (u8) (status_reg & enable_reg);
+ enabled_status_byte = (u8)(status_reg & enable_reg);
if (!enabled_status_byte) {
/* No active GPEs in this register, move on */
@@ -450,7 +451,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *
gpe_xrupt_list)
acpi_ev_gpe_dispatch(gpe_block->
node,
_block->
- event_info[((acpi_size) i *
ACPI_GPE_REGISTER_WIDTH) + j], j + gpe_register_info->base_gpe_number);
+
event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j +
gpe_register_info->base_gpe_number);
}
}
}
@@ -636,7 +637,7 @@ static void ACPI_SYSTEM_XFACE
acpi_ev_asynch_enable_gpe(void *context)
*
**/
-acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info *gpe_event_info)
+acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info * gpe_event_info)
{
acpi_status status;
[PATCH v2 2/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in atomic context.
The GPE APIs should be invoked inside of an IRQ context GPE handler or in
the task context with a driver provided lock held. This driver provided
lock should be safe to be held in the GPE handler by the driver.
While currently we cannot do this, thus we can only use the GPE APIs for
limitted cases.
This patch adds reference counting for struct acpi_gpe_handler_info. Then the
GPE
handler can be safely invoked without holding the GPE lock, thus
facilitates GPE APIs to be invoked in any atomic environment. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acevents.h |1 +
drivers/acpi/acpica/aclocal.h |1 +
drivers/acpi/acpica/evgpe.c| 71
drivers/acpi/acpica/evxface.c | 10 ++
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 7a7811a..a3d5276 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -123,6 +123,7 @@ ACPI_HW_DEPENDENT_RETURN_OK(acpi_status
u32
acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
struct acpi_gpe_event_info *gpe_event_info,
+struct acpi_gpe_handler_info *gpe_handler_info,
u32 gpe_number);
/*
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index a9fa666..7363e2c 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -414,6 +414,7 @@ struct acpi_gpe_handler_info {
struct acpi_namespace_node *method_node;/* Method node for this
GPE level (saved) */
u8 original_flags; /* Original (pre-handler) GPE info */
u8 originally_enabled; /* True if GPE was originally enabled */
+ u16 reference_count;/* For deletion management */
};
/* Notify info for implicit notify, multiple device objects */
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 2095dfb..d629a21 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -339,6 +339,8 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info
*gpe_xrupt_list)
{
acpi_status status;
struct acpi_gpe_block_info *gpe_block;
+ struct acpi_gpe_event_info *gpe_event_info;
+ struct acpi_gpe_handler_info *gpe_handler_info;
struct acpi_gpe_register_info *gpe_register_info;
u32 int_status = ACPI_INTERRUPT_NOT_HANDLED;
u8 enabled_status_byte;
@@ -443,15 +445,45 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info
*gpe_xrupt_list)
/* Examine one GPE bit */
if (enabled_status_byte & (1 << j)) {
+ gpe_event_info =
+ _block->
+ event_info[((acpi_size) i *
+ ACPI_GPE_REGISTER_WIDTH)
+ + j];
+ gpe_handler_info =
+ gpe_event_info->dispatch.handler;
+
+ /* Acquire the reference to protect the
invocations */
+
+ if (gpe_handler_info) {
+ gpe_handler_info->
+ reference_count++;
+ }
+
/*
* Found an active GPE. Dispatch the
event to a handler
-* or method.
+* or method. Invoke without GPE lock
held.
*/
+ acpi_os_release_lock(acpi_gbl_gpe_lock,
+flags);
int_status |=
acpi_ev_gpe_dispatch(gpe_block->
node,
-_block->
-
event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j +
gpe_register_info->base_gpe_number);
+gpe_event_info,
+
gpe_handler_info,
+j +
+
gpe_register_info->
+
base_gpe_number);
+ flags =
+ acpi_os_acquire_lock
+
[PATCH 8/8] staging: dgap: fix memory leak in dgap_parsefile()
The p->u.board.status is allocated and set a string as
"No" once within allocating a node of BNODE type.
But it also set again with kstrdup() in case of "STATUS"
or "ID". If it is not allocated yet, use kstrdup().
If not, use just memcpy().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index a207bd7..cedf4b3 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -6598,7 +6598,11 @@ static int dgap_parsefile(char **in)
pr_err("dgap: parse: unexpected end of file\n");
return -1;
}
- p->u.board.status = kstrdup(s, GFP_KERNEL);
+
+ if (p->u.board.status)
+ memcpy(p->u.board.status, s, strlen(s) + 1);
+ else
+ p->u.board.status = kstrdup(s, GFP_KERNEL);
break;
case NPORTS:/* number of ports */
@@ -6648,7 +6652,10 @@ static int dgap_parsefile(char **in)
return -1;
}
- p->u.board.status = kstrdup(s, GFP_KERNEL);
+ if (p->u.board.status)
+ memcpy(p->u.board.status, s, strlen(s) + 1);
+ else
+ p->u.board.status = kstrdup(s, GFP_KERNEL);
if (p->type == CNODE) {
p->u.conc.id = kstrdup(s, GFP_KERNEL);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] staging: dgap: introduce dgap_cleanup_nodes()
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
Making a node will allocate node memory and strings for saving
configrations with kstrdup().
So these are freed when dgap is unloaded or failed to initialize.
Signed-off-by: Daeseok Youn
---
It MUST be needed to prevent memory leaks but
I'm not sure that I fix properly.
Please review.
drivers/staging/dgap/dgap.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 61baee1..a207bd7 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -200,6 +200,7 @@ static int dgap_test_fep(struct board_t *brd);
static int dgap_tty_register_ports(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type,
struct board_t *brd);
+static void dgap_cleanup_nodes(void);
static void dgap_cleanup_module(void);
@@ -618,6 +619,7 @@ unregister_tty:
free_flipbuf:
dgap_free_flipbuf(brd);
cleanup_brd:
+ dgap_cleanup_nodes();
dgap_release_remap(brd);
kfree(brd);
@@ -658,6 +660,8 @@ static void dgap_cleanup_module(void)
dgap_cleanup_board(dgap_board[i]);
}
+ dgap_cleanup_nodes();
+
if (dgap_numboards)
pci_unregister_driver(_driver);
}
@@ -6322,6 +6326,49 @@ static void dgap_remove_tty_sysfs(struct device *c)
sysfs_remove_group(>kobj, _tty_attribute_group);
}
+static void dgap_cleanup_nodes(void)
+{
+ struct cnode *p;
+
+ p = _head;
+
+ while (p) {
+ struct cnode *tmp = p->next;
+
+ switch (p->type) {
+ case BNODE:
+ kfree(p->u.board.portstr);
+ kfree(p->u.board.addrstr);
+ kfree(p->u.board.pcibusstr);
+ kfree(p->u.board.pcislotstr);
+ kfree(p->u.board.method);
+ break;
+ case CNODE:
+ kfree(p->u.conc.id);
+ kfree(p->u.conc.connect);
+ break;
+ case MNODE:
+ kfree(p->u.module.id);
+ break;
+ case TNODE:
+ kfree(p->u.ttyname);
+ break;
+ case CUNODE:
+ kfree(p->u.cuname);
+ break;
+ case LNODE:
+ kfree(p->u.line.cable);
+ break;
+ case PNODE:
+ kfree(p->u.printname);
+ break;
+ }
+
+ kfree(p->u.board.status);
+ kfree(p);
+ p = tmp;
+ }
+}
/*
* Parse a configuration file read into memory as a string.
*/
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] staging: dgap: remove unneeded dgap_err()
The dgap_err() is printing a message with pr_err(),
so all those are replaced.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 226 --
1 files changed, 108 insertions(+), 118 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 06c55cb..61baee1 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -153,7 +153,6 @@ static void dgap_firmware_reset_port(struct channel_t *ch);
static int dgap_gettok(char **in);
static char *dgap_getword(char **in);
static int dgap_checknode(struct cnode *p);
-static void dgap_err(char *s);
/*
* Function prototypes from dgap_sysfs.h
@@ -6343,7 +6342,7 @@ static int dgap_parsefile(char **in)
/* file must start with a BEGIN */
while ((rc = dgap_gettok(in)) != BEGIN) {
if (rc == 0) {
- dgap_err("unexpected EOF");
+ pr_err("dgap: parse: unexpected EOF\n");
return -1;
}
}
@@ -6351,13 +6350,13 @@ static int dgap_parsefile(char **in)
for (; ;) {
rc = dgap_gettok(in);
if (rc == 0) {
- dgap_err("unexpected EOF");
+ pr_err("dgap: parse: unexpected EOF\n");
return -1;
}
switch (rc) {
case BEGIN: /* should only be 1 begin */
- dgap_err("unexpected config_begin\n");
+ pr_err("dgap: parse: unexpected config_begin\n");
return -1;
case END:
@@ -6369,7 +6368,7 @@ static int dgap_parsefile(char **in)
p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
- dgap_err("out of memory");
+ pr_err("dgap: parse: out of memory\n");
return -1;
}
p = p->next;
@@ -6383,7 +6382,7 @@ static int dgap_parsefile(char **in)
case APORT2_920P: /* AccelePort_4 */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_2r_920 string");
+ pr_err("dgap: parse: unexpected Digi_2r_920
string\n");
return -1;
}
p->u.board.type = APORT2_920P;
@@ -6392,7 +6391,7 @@ static int dgap_parsefile(char **in)
case APORT4_920P: /* AccelePort_4 */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_4r_920 string");
+ pr_err("dgap: parse: unexpected Digi_4r_920
string\n");
return -1;
}
p->u.board.type = APORT4_920P;
@@ -6401,7 +6400,7 @@ static int dgap_parsefile(char **in)
case APORT8_920P: /* AccelePort_8 */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_8r_920 string");
+ pr_err("dgap: parse: unexpected Digi_8r_920
string\n");
return -1;
}
p->u.board.type = APORT8_920P;
@@ -6410,7 +6409,7 @@ static int dgap_parsefile(char **in)
case PAPORT4: /* AccelePort_4 PCI */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_4r(PCI) string");
+ pr_err("dgap: parse: unexpected Digi_4r(PCI)
string\n");
return -1;
}
p->u.board.type = PAPORT4;
@@ -6419,7 +6418,7 @@ static int dgap_parsefile(char **in)
case PAPORT8: /* AccelePort_8 PCI */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_8r string");
+ pr_err("dgap: parse: unexpected Digi_8r
string\n");
return -1;
}
p->u.board.type = PAPORT8;
@@ -6428,7 +6427,7 @@ static int dgap_parsefile(char **in)
case PCX: /* PCI C/X */
if (p->type != BNODE) {
- dgap_err("unexpected Digi_C/X_(PCI) string");
+ pr_err("dgap: parse: unexpected Digi_C/X_(PCI)
string\n");
return -1;
}
p->u.board.type = PCX;
@@ -6441,7 +6440,7 @@ static int dgap_parsefile(char **in)
case PEPC: /* PCI EPC/X */
if (p->type != BNODE) {
- dgap_err("unexpected
[PATCH 5/8] staging: dgap: remove dgap_newnode()
The dgap_newnode() is useless for creating new node.
So just use kzalloc and set a type in case statement.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 104 ++
1 files changed, 74 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 1e52092..06c55cb 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -152,7 +152,6 @@ static void dgap_firmware_reset_port(struct channel_t *ch);
*/
static int dgap_gettok(char **in);
static char *dgap_getword(char **in);
-static struct cnode *dgap_newnode(int t);
static int dgap_checknode(struct cnode *p);
static void dgap_err(char *s);
@@ -6367,13 +6366,15 @@ static int dgap_parsefile(char **in)
case BOARD: /* board info */
if (dgap_checknode(p))
return -1;
- p->next = dgap_newnode(BNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
p = p->next;
+ p->type = BNODE;
p->u.board.status = kstrdup("No", GFP_KERNEL);
line = conc = NULL;
brd = p;
@@ -6658,12 +6659,16 @@ static int dgap_parsefile(char **in)
case TTYN: /* tty name prefix */
if (dgap_checknode(p))
return -1;
- p->next = dgap_newnode(TNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
+
p = p->next;
+ p->type = TNODE;
+
s = dgap_getword(in);
if (!s) {
dgap_err("unexpeced end of file");
@@ -6679,12 +6684,16 @@ static int dgap_parsefile(char **in)
case CU:/* cu name prefix */
if (dgap_checknode(p))
return -1;
- p->next = dgap_newnode(CUNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
+
p = p->next;
+ p->type = CUNODE;
+
s = dgap_getword(in);
if (!s) {
dgap_err("unexpeced end of file");
@@ -6709,12 +6718,15 @@ static int dgap_parsefile(char **in)
dgap_err("line not vaild for PC/em");
return -1;
}
- p->next = dgap_newnode(LNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
+
p = p->next;
+ p->type = LNODE;
conc = NULL;
line = p;
linecnt++;
@@ -6727,13 +6739,17 @@ static int dgap_parsefile(char **in)
dgap_err("must specify line info before
concentrator");
return -1;
}
- p->next = dgap_newnode(CNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
+
p = p->next;
+ p->type = CNODE;
conc = p;
+
if (linecnt)
brd->u.board.conc2++;
else
@@ -6776,12 +6792,15 @@ static int dgap_parsefile(char **in)
return -1;
}
}
- p->next = dgap_newnode(MNODE);
+
+ p->next = kzalloc(sizeof(struct cnode), GFP_KERNEL);
if (!p->next) {
dgap_err("out of memory");
return -1;
}
p = p->next;
+ p->type = MNODE;
+
if (linecnt)
[PATCH 4/8] staging: dgap: remove unused a parameter in dgap_gettok()
The "p" as parameter is unused.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 17514c8..1e52092 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -150,7 +150,7 @@ static void dgap_firmware_reset_port(struct channel_t *ch);
/*
* Function prototypes from dgap_parse.c.
*/
-static int dgap_gettok(char **in, struct cnode *p);
+static int dgap_gettok(char **in);
static char *dgap_getword(char **in);
static struct cnode *dgap_newnode(int t);
static int dgap_checknode(struct cnode *p);
@@ -6342,7 +6342,7 @@ static int dgap_parsefile(char **in)
p = p->next;
/* file must start with a BEGIN */
- while ((rc = dgap_gettok(in, p)) != BEGIN) {
+ while ((rc = dgap_gettok(in)) != BEGIN) {
if (rc == 0) {
dgap_err("unexpected EOF");
return -1;
@@ -6350,7 +6350,7 @@ static int dgap_parsefile(char **in)
}
for (; ;) {
- rc = dgap_gettok(in, p);
+ rc = dgap_gettok(in);
if (rc == 0) {
dgap_err("unexpected EOF");
return -1;
@@ -7100,7 +7100,7 @@ static char *dgap_sindex(char *string, char *group)
/*
* Get a token from the input file; return 0 if end of file is reached
*/
-static int dgap_gettok(char **in, struct cnode *p)
+static int dgap_gettok(char **in)
{
char *w;
struct toklist *t;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] clk: exynos-audss: Use samsung clock APIs to register/unregister clocks
On Mon, Jul 14, 2014 at 9:04 PM, Sylwester Nawrocki
wrote:
> On 11/07/14 14:00, Tushar Behera wrote:
>> @@ -103,17 +140,11 @@ static int exynos_audss_clk_probe(struct
>> platform_device *pdev)
>> return PTR_ERR(reg_base);
>> }
>>
>> - clk_table = devm_kzalloc(>dev,
>> - sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
>> - GFP_KERNEL);
>> - if (!clk_table)
>> + ctx = samsung_clk_init(pdev->dev.of_node, reg_base, nr_clks);
>
> There is an issue here that this registers the clk provider before all
> its clocks are registered with the clk core. Therefore it introduces
> a race condition.
>
> Please have a look at patch [1], you may want to rebase this series
> onto that patch.
>
Thanks for the pointer. I will re-post.
>> + samsung_clk_register_div(ctx, exynos_audss_div_clks,
>> + ARRAY_SIZE(exynos_audss_div_clks));
> [...]
>> + samsung_clk_register_gate(ctx, exynos_audss_gate_clks,
>> + ARRAY_SIZE(exynos_audss_gate_clks));
> [...]
>> - ret = of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get,
>> - _data);
>> - if (ret) {
>> - dev_err(>dev, "failed to add clock provider\n");
>> - goto unregister;
>> + samsung_clk_register_gate(ctx, exynos5420_audss_gate_clks,
>> +
>> ARRAY_SIZE(exynos5420_audss_gate_clks));
>> }
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/tfiga/samsung-clk.git/commit/?h=samsung-clk-next=d5e136a21b2028fb1f45143ea7112d5869bfc6c7
>
> --
> Regards,
> Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] staging: dgap: fix a typo in dgap_gettok()
The "boar" should be "board".
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 470ae7b..17514c8 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -7105,7 +7105,7 @@ static int dgap_gettok(char **in, struct cnode *p)
char *w;
struct toklist *t;
- if (strstr(dgap_cword, "boar")) {
+ if (strstr(dgap_cword, "board")) {
w = dgap_getword(in);
snprintf(dgap_cword, MAXCWORD, "%s", w);
for (t = dgap_tlist; t->token != 0; t++) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] staging: dgap: remove unused case value in dgap_parsefile()
If rc is zero, this function will returns with an error and
cannot reach switch-case statement.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 10bd0f2..470ae7b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -6357,10 +6357,6 @@ static int dgap_parsefile(char **in)
}
switch (rc) {
- case 0:
- dgap_err("unexpected end of file");
- return -1;
-
case BEGIN: /* should only be 1 begin */
dgap_err("unexpected config_begin\n");
return -1;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] staging: dgap: remove redundant error value check
The retval in dgap_block_til_ready() is initialized to zero, and if no error has occurred in this function, the retval has a zero. So it doesn't need to check "retval" itself. Signed-off-by: Daeseok Youn --- drivers/staging/dgap/dgap.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c index 32988a8..10bd0f2 100644 --- a/drivers/staging/dgap/dgap.c +++ b/drivers/staging/dgap/dgap.c @@ -2181,10 +2181,7 @@ static int dgap_block_til_ready(struct tty_struct *tty, struct file *file, spin_unlock_irqrestore(>ch_lock, lock_flags); - if (retval) - return retval; - - return 0; + return retval; } /* -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: One bug of SDHCI driver
Hi,
The data type of "host" is "struct mmc_host", and there is not "quirks" member
in this structure.
Thanks,
Zhonghui
On 2014/7/14 21:26, Chris Ball wrote:
> Hi Zhonghui,
>
> On Tue, Jul 08 2014, Fu, Zhonghui wrote:
>> Why add "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" ? How to fix this bug?
>>
>> Could you please give out some idea about this bug?
> Jaehoon already gave you a patch to fix this bug. Here it is again in
> proper patch form. Please can you test it and let us know whether it
> fixes the crash? Thanks.
>
>
> From: Chris Ball
> Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio
> thread
>
> 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
> bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
> the use of our own custom threaded IRQ handler, but left in an
> unconditional wake_up_process() on that handler at resume-time.
>
> Reported-by: Fu, Zhonghui
> [Patch suggested by Jaehoon Chung]
> Signed-off-by: Chris Ball
> ---
> drivers/mmc/core/sdio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index e636d9e..2a128e2 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -992,7 +992,8 @@ static int mmc_sdio_resume(struct mmc_host *host)
> }
> }
>
> - if (!err && host->sdio_irqs)
> + if (!err && host->sdio_irqs &&
> + !(host->quirks & MMC_CAP2_SDIO_IRQ_NOTHREAD))
> wake_up_process(host->sdio_irq_thread);
> mmc_release_host(host);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Is espfix64's double-fault thing OK on Xen?
On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin wrote: > On 07/14/2014 02:35 PM, Andy Lutomirski wrote: >> Presumably the problem is here: >> >> ENTRY(xen_iret) >> pushq $0 >> 1:jmp hypercall_iret >> ENDPATCH(xen_iret) >> >> This seems rather unlikely to work on the espfix stack. >> >> Maybe espfix64 should be disabled when running on Xen and Xen should >> implement its own espfix64 in the hypervisor. > > Perhaps the first question is: is espfix even necessary on Xen? How > does the Xen PV IRET handle returning to a 16-bit stack segment? > Test case here: https://gitorious.org/linux-test-utils/linux-clock-tests/source/dbfe196a0f6efedc119deb1cdbb0139dbdf609ee: It's sigreturn_32 and sigreturn_64. Summary: (sigreturn_64 always fails unless my SS patch is applied. results below for sigreturn_64 assume the patch is applied. This is on KVM (-cpu host) on Sandy Bridge.) On Xen with espfix, both OOPS intermittently. On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS always fails. Native (32-bit or 64-bit, according to the binary) CS with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I find this somewhat odd. Native ss always passes. So I think that Xen makes no difference here, aside from the bug. That being said, I don't know whether Linux can do espfix64 at all when Xen is running -- for all I know, the IRET hypercall switches stacks to a Xen stack. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] hso: fix deadlock when receiving bursts of data
From: Olivier Sobrie Date: Mon, 14 Jul 2014 12:08:50 +0200 > When the module sends bursts of data, sometimes a deadlock happens in > the hso driver when the tty buffer doesn't get the chance to be flushed > quickly enough. > > Remove the endless while loop in function put_rxbuf_data() which is > called by the urb completion handler. > If there isn't enough room in the tty buffer, discards all the data > received in the URB. > > Cc: David Miller > Cc: David Laight > Cc: One Thousand Gnomes > Cc: Dan Williams > Cc: Jan Dumon > Signed-off-by: Olivier Sobrie > --- > Changes in v2: > - remove the unthrottle timer added in the previous patch version > - drop entire rx urb data if there is not enough space in tty buffer > - remove variable curr_rx_urb_offset from hso_serial structure Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] hso: remove unused workqueue
From: Olivier Sobrie Date: Mon, 14 Jul 2014 12:08:49 +0200 > The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere > in the code. So, remove it. > > Signed-off-by: Olivier Sobrie Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(2014/07/15 11:11), Michael Ellerman wrote: > On Mon, 2014-07-14 at 10:17 -0700, Tony Luck wrote: >> On Tue, Jul 8, 2014 at 5:07 AM, Masami Hiramatsu >> wrote: >>> Ping? >>> >>> This patch can be applied without 1/2, and will fix ia64/ppc64 problem. >> >> Is somebody going to push this upstream? Another week has gone by, >> we are at -rc5, and I'm still seeing the >> >> Failed to find blacklist a0010133b150 >> >> messages on ia64. > > I don't see those messages on ppc64, I don't know where the original report > that it was broken on ppc64 came from. So I'm a bit lukewarm on the patch. Right, on ppc64(ABIv1) it may be silently failed. Because each function descriptor has another entry on kallsyms, original code can't detect that. On the other hand, ia64's function descriptors have no entries, so it can detect the failure on boot. This patch adds new detection code using kernel_text_address() and translates function descriptor to function entry. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression, 3.16-rc] rwsem: optimistic spinning causing performance degradation
On Mon, Jul 14, 2014 at 11:55:39AM +0200, Peter Zijlstra wrote: > On Mon, Jul 14, 2014 at 05:37:13PM +0800, Xie Miao wrote: > > Hi, Jason > > > > Could you re-sent this patch? Because it seems it is ignored. > > Its not ignored; its not merged because of unrelated stability issues. Is it going to be merged? If not, can you please revert the optimistic spinning patch that caused the regression? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Revert removing of _INIT_GLOBAL(), _STATIC() and _INIT_STATIC()
On Tue, 15 Jul 2014 12:05:55 +1000 Benjamin Herrenschmidt wrote: > Cheers, > Ben. > While I got your attention, could you please ack my patch with subject: [RFA][PATCH 09/27] powerpc/ftrace: Add call to ftrace_graph_is_dead() in function graph code so that I can push it through my tree. Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 0/6] cleanup for AMD8111E ethernet driver
From: varkabhad...@gmail.com Date: Mon, 14 Jul 2014 14:09:03 +0530 > This series cleanup for AMD8111E ethernet driver > > v1: fix checkpatch warnings. > v2: added new line in debug messages Series applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Revert removing of _INIT_GLOBAL(), _STATIC() and _INIT_STATIC()
On Tue, 15 Jul 2014 12:05:55 +1000 Benjamin Herrenschmidt wrote: > On Mon, 2014-07-14 at 20:12 -0400, Steven Rostedt wrote: > > I wanted to test some new ftrace code on my PASemi electra powerpc box. > > But unfortunately it failed to build. It failed with this: > > > > LD init/built-in.o > > arch/powerpc/kernel/head_64.o:arch/powerpc/kernel/exceptions-64s.S:874: > > relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 > > Makefile:864: recipe for target 'vmlinux' failed > > Weird ... what are your gcc and binutils versions ? Smells like a > toolchain issue to me but I need to dig a bit more. Doesn't hit any > of my test configs here. > I built it from scratch from the mainline source repos. dist-ppc-gcc (GCC) 4.6.0 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU assembler (GNU Binutils) 2.21 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `powerpc64-unknown-linux'. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Mon, 2014-07-14 at 10:17 -0700, Tony Luck wrote: > On Tue, Jul 8, 2014 at 5:07 AM, Masami Hiramatsu > wrote: > > Ping? > > > > This patch can be applied without 1/2, and will fix ia64/ppc64 problem. > > Is somebody going to push this upstream? Another week has gone by, > we are at -rc5, and I'm still seeing the > > Failed to find blacklist a0010133b150 > > messages on ia64. I don't see those messages on ppc64, I don't know where the original report that it was broken on ppc64 came from. So I'm a bit lukewarm on the patch. 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/
[PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages
Pages allocated using the DMA API have a coherent memory mapping. Make
this mapping visible to drivers so they can decide to use it instead of
creating their own redundant one.
This is not a mere optimization: for instance, on ARM it is illegal to
have several memory mappings to the same memory with different protection.
The mapping provided by dma_alloc_coherent() and exposed by this patch is
guaranteed to be safe, but subsequent mappings performed by drivers are
not. Thus drivers using the DMA page allocator should use this mapping
instead of creating their own.
Signed-off-by: Alexandre Courbot
---
This patch was previously part of a series but I figured it would make more
sense to send it separately. It is to be used by Nouveau (and hopefully
other drivers) on ARM.
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 ++
drivers/gpu/drm/ttm/ttm_tt.c | 6 +-
include/drm/ttm/ttm_bo_driver.h | 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index fb8259f69839..0301fac5badd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -847,6 +847,7 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
if (count) {
d_page = list_first_entry(>free_list, struct dma_page,
page_list);
ttm->pages[index] = d_page->p;
+ ttm_dma->cpu_address[index] = d_page->vaddr;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
r = 0;
@@ -978,6 +979,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
INIT_LIST_HEAD(_dma->pages_list);
for (i = 0; i < ttm->num_pages; i++) {
ttm->pages[i] = NULL;
+ ttm_dma->cpu_address[i] = 0;
ttm_dma->dma_address[i] = 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 75f319090043..341594ede596 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -58,6 +58,8 @@ static void ttm_dma_tt_alloc_page_directory(struct ttm_dma_tt
*ttm)
ttm->ttm.pages = drm_calloc_large(ttm->ttm.num_pages, sizeof(void*));
ttm->dma_address = drm_calloc_large(ttm->ttm.num_pages,
sizeof(*ttm->dma_address));
+ ttm->cpu_address = drm_calloc_large(ttm->ttm.num_pages,
+ sizeof(*ttm->cpu_address));
}
#ifdef CONFIG_X86
@@ -228,7 +230,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct
ttm_bo_device *bdev,
INIT_LIST_HEAD(_dma->pages_list);
ttm_dma_tt_alloc_page_directory(ttm_dma);
- if (!ttm->pages || !ttm_dma->dma_address) {
+ if (!ttm->pages || !ttm_dma->dma_address || !ttm_dma->cpu_address) {
ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
@@ -243,6 +245,8 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
drm_free_large(ttm->pages);
ttm->pages = NULL;
+ drm_free_large(ttm_dma->cpu_address);
+ ttm_dma->cpu_address = NULL;
drm_free_large(ttm_dma->dma_address);
ttm_dma->dma_address = NULL;
}
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 202f0a7171e8..1d9f0f1ff52d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -133,6 +133,7 @@ struct ttm_tt {
* struct ttm_dma_tt
*
* @ttm: Base ttm_tt struct.
+ * @cpu_address: The CPU address of the pages
* @dma_address: The DMA (bus) addresses of the pages
* @pages_list: used by some page allocation backend
*
@@ -142,6 +143,7 @@ struct ttm_tt {
*/
struct ttm_dma_tt {
struct ttm_tt ttm;
+ void **cpu_address;
dma_addr_t *dma_address;
struct list_head pages_list;
};
--
2.0.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] powerpc: Revert removing of _INIT_GLOBAL(), _STATIC() and _INIT_STATIC()
On Mon, 2014-07-14 at 20:12 -0400, Steven Rostedt wrote: > I wanted to test some new ftrace code on my PASemi electra powerpc box. > But unfortunately it failed to build. It failed with this: > > LD init/built-in.o > arch/powerpc/kernel/head_64.o:arch/powerpc/kernel/exceptions-64s.S:874: > relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 > Makefile:864: recipe for target 'vmlinux' failed Weird ... what are your gcc and binutils versions ? Smells like a toolchain issue to me but I need to dig a bit more. Doesn't hit any of my test configs here. Cheers, Ben. > Bisecting it lead me down to this commit: > > commit 6a3bab90cf78bc579638525cb76ac240f8253803 > Author: Anton Blanchard > Date: Tue Feb 4 16:06:11 2014 +1100 > > powerpc: Remove some unnecessary uses of _GLOBAL() and _STATIC() > > There is no need to create a function descriptor for functions > called locally out of assembly. > > > And by reverting this and: > > commit a0e971ffb9d9dae3b9892fb548bd2497db758f60 > Author: Anton Blanchard > Date: Tue Feb 4 16:06:25 2014 +1100 > > powerpc: Remove _INIT_GLOBAL(), _STATIC() and _INIT_STATIC() > > Now there are no users of _INIT_GLOBAL(), _STATIC() and > _INIT_STATIC() we can remove them. > > My box builds and boots again. > > Signed-off-by: Steven Rostedt > --- > diff --git a/arch/powerpc/include/asm/ppc_asm.h > b/arch/powerpc/include/asm/ppc_asm.h > index 9ea266e..1baf197 100644 > --- a/arch/powerpc/include/asm/ppc_asm.h > +++ b/arch/powerpc/include/asm/ppc_asm.h > @@ -217,6 +217,20 @@ name: \ > addi r2,r2,(.TOC.-0b)@l; \ > .localentry name,.-name > > +#define _INIT_GLOBAL(name) \ > + __REF; \ > + .align 2 ; \ > + .globl name; \ > + .globl GLUE(.,name); \ > + .section ".opd","aw"; \ > +name: \ > + .quad GLUE(.,name); \ > + .quad .TOC.@tocbase; \ > + .quad 0; \ > + .previous; \ > + .type GLUE(.,name),@function; \ > +GLUE(.,name): > + > #define _KPROBE(name) \ > .section ".kprobes.text","a"; \ > .align 2 ; \ > @@ -265,6 +279,30 @@ GLUE(.,name): > > #endif > > +#define _STATIC(name) \ > + .section ".text"; \ > + .align 2 ; \ > + .section ".opd","aw"; \ > +name: \ > + .quad GLUE(.,name); \ > + .quad .TOC.@tocbase; \ > + .quad 0; \ > + .previous; \ > + .type GLUE(.,name),@function; \ > +GLUE(.,name): > + > +#define _INIT_STATIC(name) \ > + __REF; \ > + .align 2 ; \ > + .section ".opd","aw"; \ > +name: \ > + .quad GLUE(.,name); \ > + .quad .TOC.@tocbase; \ > + .quad 0; \ > + .previous; \ > + .type GLUE(.,name),@function; \ > +GLUE(.,name): > + > #else /* 32-bit */ > > #define _ENTRY(n)\ > diff --git a/arch/powerpc/kernel/exceptions-64e.S > b/arch/powerpc/kernel/exceptions-64e.S > index bb9cac6..ce0c55d 100644 > --- a/arch/powerpc/kernel/exceptions-64e.S > +++ b/arch/powerpc/kernel/exceptions-64e.S > @@ -1580,14 +1580,14 @@ _GLOBAL(book3e_secondary_thread_init) > mflrr28 > b 3b > > -init_core_book3e: > +_STATIC(init_core_book3e) > /* Establish the interrupt vector base */ > LOAD_REG_IMMEDIATE(r3, interrupt_base_book3e) > mtspr SPRN_IVPR,r3 > sync > blr > > -init_thread_book3e: > +_STATIC(init_thread_book3e) > lis r3,(SPRN_EPCR_ICM | SPRN_EPCR_GICM)@h > mtspr SPRN_EPCR,r3 > > diff --git a/arch/powerpc/kernel/exceptions-64s.S > b/arch/powerpc/kernel/exceptions-64s.S > index a7d36b1..220c5a9 100644 > --- a/arch/powerpc/kernel/exceptions-64s.S > +++ b/arch/powerpc/kernel/exceptions-64s.S > @@ -1586,7 +1586,7 @@ power4_fixup_nap: > * Hash table stuff > */ > .align 7 > -do_hash_page: > +_STATIC(do_hash_page) > std r3,_DAR(r1) > std r4,_DSISR(r1) > > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > index a95145d..b8986af 100644 > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -299,7 +299,7 @@ generic_secondary_common_init: > * Assumes we're mapped EA == RA if the MMU is on. > */ > #ifdef CONFIG_PPC_BOOK3S > -__mmu_off: > +_STATIC(__mmu_off) > mfmsr r3 > andi. r0,r3,MSR_IR|MSR_DR > beqlr > @@ -324,7 +324,7 @@ __mmu_off: > * DT block, r4 is a physical pointer to the kernel itself > * > */ > -__start_initialization_multiplatform: > +_GLOBAL(__start_initialization_multiplatform) > /* Make sure we are running in 64 bits mode */ > bl enable_64b_mode > > @@ -376,7 +376,7 @@ __start_initialization_multiplatform: > b __after_prom_start > #endif /* CONFIG_PPC_BOOK3E */ > > -__boot_from_prom: > +_INIT_STATIC(__boot_from_prom) > #ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE > /* Save parameters */ > mr r31,r3 > @@ -414,7 +414,7 @@ __boot_from_prom: >* from OF while CONFIG_PPC_OF_BOOT_TRAMPOLINE isn't selected */ > trap > >
Re: [PATCH v10 0/11] seccomp: add thread sync ability
On 07/15/2014 04:59 AM, Kees Cook wrote: Hi James, Is this series something you would carry in the security-next tree? That has traditionally been where seccomp features have landed in the past. -Kees On Fri, Jul 11, 2014 at 10:55 AM, Kees Cook wrote: On Fri, Jul 11, 2014 at 9:49 AM, Oleg Nesterov wrote: On 07/10, Kees Cook wrote: This adds the ability for threads to request seccomp filter synchronization across their thread group (at filter attach time). For example, for Chrome to make sure graphic driver threads are fully confined after seccomp filters have been attached. To support this, locking on seccomp changes via thread-group-shared sighand lock is introduced, along with refactoring of no_new_privs. Races with thread creation are handled via delayed duplication of the seccomp task struct field and cred_guard_mutex. This includes a new syscall (instead of adding a new prctl option), as suggested by Andy Lutomirski and Michael Kerrisk. I do not not see any problems in this version, Awesome! Thank you for all the reviews. :) If Andy and Michael are happy with this too, I think this is in good shape. \o/ -Kees Reviewed-by: Oleg Nesterov -- Kees Cook Chrome OS Security Yep, certainly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] In the Denali NAND controller driver, use 8 bytes for READID command.
On Mon, Jun 23, 2014 at 02:50:15PM -0500, Dinh Nguyen wrote: > On Mon, 2014-06-23 at 14:21 -0500, Graham Moore wrote: > > The Denali NAND driver reads only 5 bytes of ID, but some Hynix and Samsung > > have size parameters in the 6th byte. As a result, the page and oob size > > for a Hynix H27UAG8T2B were calculated incorrectly and the driver failed to > > load. > > > > The solution is to read 8 bytes of ID, as expected by the nand framework. > > > > Signed-off-by: Graham Moore > > -- > > V2: Increase size of id_bytes array to 8. > > --- > > drivers/mtd/nand/denali.c |6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > Your commit header should have "mtd: denali:" > > i.e: "mtd: denali: use 8 bytes for READID command" Modified the subject and pushed to l2-mtd.git. Thanks! Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: phram: Fix whitespace issues
On Sun, Jul 13, 2014 at 09:14:21PM +0100, Rob Ward wrote: > From ae6ea29f112475aa1e2da20caabe36e318fd51c4 Mon Sep 17 00:00:00 2001 > From: Rob Ward > Date: Sun, 13 Jul 2014 20:39:01 +0100 > Subject: [PATCH] mtd: phram: Fix whitespace issues > > Fix various whitespace issues. > > No functional changes. > > Signed-off-by: Rob Ward Pushed to l2-mtd.git. Thanks. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
